Xiaoye Sherry Li

Xiaoye Sherry Li

Research interests:

 Design and optimization of algorithms on parallel machines 
 High performance algebraic solvers 
 Sparse matrix computations 
 Mathematical software

I do research and provide support for mathematical software on the parallel machines at NERSC. Currently, I am heavily involved in the DOE SciDACprojects. Previously I worked on NSFNPACI project. 
I received Ph.D. in Computer Sciencefrom UC Berkeley.

Li’s Google Scholar Citations

Selected papers:( Full list, over 90 papers)

 Sparse matrix computations 
 Floating-point, high-precision arithmetic 
 Performance evaluation 
 Numerical optimization 


 SuperLU — Sequential and parallel libraries to solve unsymmetric sparse linear systems using LU factorization. 
 PDSLin — Parallel Domain-decomposition, Schur complement based hybrid sparse linear solver. 
 XBLAS — A reference implementation for the Extended and Mixed precision BLAS standard. 
 ARPREC — A C++/F90 package for performing arbitrary precision arithmetic. 
 CLAPACK — Full set of LAPACK in C. 
 ieee_except — A set of condition estimation routines, which are faster than those in LAPACK, by utilizing floating-point exception handling. It contains routines to manipulate IEEE exception sticky flags.

Selected Honors:

SIAM Fellow, Society for Industrial and Applied Mathematics, 2016Elected to the SIAM Council, Jan. 2016 – Dec. 2018Invited Plenary Speaker, SIAM Conference on Applied Linear Algebra, October 26-30, 2015Invited Lecturer, the Fourth Gene Golub SIAM Summer School, July 22 – August 2, 2013Invited Plenary Speaker, SIAM Annual Meeting, July 12-16, 2010

Selected presentations:

Invited Plenary SpeakerAccelerating Direct Linear Solvers with Algorithmic and Hardware Advances, SIAM Conf. on Applied Linear Algebra, Oct. 26-30, 2015, Atlanta. ( View presentation
Invited Lecturer, short course onFactorization-based sparse solvers and preconditioners, 4th Gene Golub SIAM Summer School, July 22-Aug. 9, 2013, Shanghai. (Videos and course materials,  Extended Summary (in book “Matrix Functions and Matrix Equations”, Z. Bai, W. Gao, Y. Su, editors, Series in Contemporary Applied Mathematics, World Scientific Publisher, Oct. 2015, pp. 109-137) 
Towards an optimal-order approximate sparse factorization exploiting data-sparseness in separatorsInvited Speaker, Workshop Celebrating 40 Years of Nested Dissection, July 22-23, 2013, Waterloo. 
Invited Plenary SpeakerFactorization-based sparse solvers and preconditioners, SIAM Annual Meeting, July 12-16, 2010. (View presentation
Towards an Optimal Parallel Approximate Factorization Using HSS Structures, Householder Symposium XVIII, June 13-17, 2011, Tahoe City, California.
A Supernodal Approach for ILU with Partial Pivoting, Sparse Days 2010 (Invited), CERFACS, June 15-17, 2010
Sparse matrix methods on high performance computers, Invited Lecture, CS267/Eng233, UCB, March 16, 2010.
Use of Semi-separable Approximate Factorization and Direction-preserving for Constructing Effective Preconditioners, SIAM Conference on Applied Linear Algebra, Monterey Bay-Seaside, Oct. 26-29, 2009. 
Performance Modeling Tools for Parallel Sparse Linear Algebra Computations, ParCo 2009, September 1-4, 2009, ENS-Lyon, France. 
Scalability Issues in Sparse Factorization and Triangular Solution, Sparse Days, June 23-24, 2008, CERFACS, Toulouse, France. 
Evaluation of sparse LU factorization and triangular solution on multicore architectures, VECPAR 2008, June 24-27, 2008, Toulouse, France. 
Algebraic Sub-structuring for Large-scale Electromagnetic Application, 16th International Conference on Domain Decomposition Methods, January 12-15, 2005, Courant Institute, New York University. 
A Comparison of Three High-Precision Quadrature Schemes, Experimental Math Workshop, March 29-30, 2004. Oakland, CA. 
Fill Reduction Algorithm Using Diagonal Markowitz Scheme with Local Symmetrization, SIAM Conference on Computational Science and Engineering, February 10-13, 2003, San Diego. 

Selected professional services:

 Associate Editor, ACM Trans. Math. Software (2006-present) 
 Associate Editor, SIAM J. Scientific Computing (2006-2009) 

Zach Holman

Zach Holman

I’m a developer and startup advisor living in San Francisco. I like it here because it’s usually pretty warm but not too warm where I worry about wearing shorts and junk.

You can find me on Twitter, on GitHub, on AngelList, and on Instagram.

I’m an advisor with Dockbit, a neat way to deploy software.

I joined GitHub in 2010 as one of their first engineering hires, and helped build and grow their product and culture over five years, from nine employees all the way to 250.

Before that, I worked at Gild for a few years after graduating from Carnegie Mellon University in Pittsburgh. Go Stillers.

I grew up in Fargo, North Dakota, which really is lovely, even though there’s a really good chance you’ll freeze to death there.

Want to chat? Feel free to email me, or if you have a question that other people might be interested in as well, open a GitHub issue on holman/ama so that others can read it, too.


I like building things… so much so that I was the top committer at GitHub for the last two years of my time there.

Here are a few of the things I’ve shipped over the years:

GitHub: Issues (2014)
GitHub Issues

Issues is GitHub’s most popular feature, but it hadn’t been touched for years and years. I laid out the direction, started working on a replacement, and led the team that shipped GitHub’s third iteration of Issues.
speaking.io (2014)

I’ve been fortunate to share my experiences with thousands of people at conferences and meetups through lots of talks I’ve given over the years. speaking.io is a place where I can share what I’ve learned about public speaking.
GitHub: Conversation Locking (2014)
Issue and thread locking

Dealing with problems in any community is tricky, and the programming community is unfortunately no different. I really wanted to give community leaders and project owners tools to help create a safe environment, and the ability to lock threads plays a big role with that.
GitHub: Web Flow (2012-2014)
GitHub Flow for the web

I love Git, but it’s pretty damn complicated sometimes. A big focus I had at GitHub was to take things from the command line and make them easier on the web. I shipped branch creation and helped out with other features, like file creation and populating a license.
GitHub: Jobs (2012-2013)
GitHub Jobs

I worked on GitHub Jobs for a few years between projects, mostly dealing with backend rewrites and refactoring. It was a fun little project to hack on from time to time.
GitHub: Various Talks (2011-2015)
Move Fast and Break Nothing talk

Even though I was focused on product development, I kind of fell into a public speaking role while at GitHub, too. Some of my more popular talks include How GitHub Uses GitHub to Build GitHub, Git and GitHub Secrets, and Move Fast and Break Nothing.
GitHub: Enterprise (2011)
GitHub Enterprise

After working on GitHub Firewall Install for a few years, I helped kickoff the transition of taking everything we had learned and rebuilding our enterprise offering. We also gave it a name that makes a lot more sense.
Good-Tutorials (2002-2012)

I founded and ran Good-Tutorials for a decade. It was the largest Photoshop tutorial site for quite some time before expanding into other software and languages. It was acquired in 2012.

medium.com: Being A Developer After 40

medium.com: Being A Developer After 40

Hi everyone, I am a forty-two years old self-taught developer, and this is my story.

A couple of weeks ago I came by the tweet below, and it made me think about my career, and those thoughts brought me back to where it all began for me:

I started my career as a software developer at precisely 10am, on Monday October 6th, 1997, somewhere in the city of Olivos, just north of Buenos Aires, Argentina. The moment was Unix Epoch 876142800. I had recently celebrated my 24th birthday.
The World In 1997

The world was a slightly different place back then.

Websites did not have cookie warnings. The future of the web were portals like Excite.com. AltaVista was my preferred search engine. My e-mail was kosmacze@sc2a.unige.ch, which meant that my first personal website was located in http://sc2a.unige.ch/~kosmacze. We were still mourning Princess Lady Diana. Steve Jobs had taken the role of CEO and convinced Microsoft to inject 150 million dollars into Apple Computer. Digital Equipment Corporation was suing Dell. The remains of Che Guevara had just been brought back to Cuba. The fourth season of “Friends” had just started. Gianni Versace had just been murdered in front of his house. Mother Teresa, Roy Lichtenstein and Jeanne Calment (the world’s oldest person ever) had just passed away. People were playing Final Fantasy 7 on their PlayStation like crazy. BBC 2 started broadcasting the Teletubbies. James Cameron was about to release Titanic. The Verve had just released their hit “Bitter Sweet Symphony” and then had to pay most royalties to the Rolling Stones.
Excite in 1997, courtesy of the Internet Archive

Smartphones looked like the Nokia 9000 Communicator; they had 8 MB of memory, a 24 MHz i386 CPU and run the GEOS operating system.

Smartwatches looked like the CASIO G-SHOCK DW-9100BJ. Not as many apps but the battery life was much longer.

IBM Deep Blue had defeated for the first time Garry Kasparov in a game of chess.

A hacker known as “_eci” published the C code for a Windows 3.1, 95 and NT exploit called “WinNuke,” a denial-of-service attack that on TCP port 139 (NetBIOS) causing a Blue Screen of Death.

Incidentally, 1997 is also the year Malala Yousafzai, Chloë Grace Moretz and Kylie Jenner were born.

Many film storylines take place in 1997, to name a few: Escape from New York, Predator 2, The Curious Case of Benjamin Button, Harry Potter and the Half-Blood Prince, The Godfather III and according to Terminator 2: Judgement Day, Skynet became self-aware at 2:14 am on August 29, 1997. That did not happen; however, in an interesting turn of events, the domain google.com had been registered on September 15th that year.

We were two years away from Y2K and the media were starting to get people nervous about it.
My First Developer Job

My first job consisted of writing ASP pages in various editors, ranging from Microsoft FrontPage, to HotMeTaL Pro to EditPlus, managing cross-browser compatibility between Netscape Navigator and Internet Explorer 4, and writing stored procedures in SQL Server 6.5 powering a commercial website published in Japanese, Russian, English and Spanish — without any consistent UTF-8 support across the software stack.

The product of these efforts ran in a Pentium II server hosted somewhere in the USA, with a stunning 2 GB hard disk drive and a whooping 256 MB of RAM. It was a single server running Windows NT 4, SQL Server 6.5 and IIS 2.0, serving around ten thousand visitors per day.

My first professional programming language was this mutant called VBScript, and of course a little bit of JavaScript on the client side, sprinkled with lots of “if this is Netscape do this, else do that” because back then I had no idea how to use JavaScript properly.

Interestingly, it’s 2016 and we are barely starting to understand how to do anything in JavaScript.

Unit tests were unheard of. The Agile Manifesto had not been written yet. Continuous integration was a dream. XML was not even a buzzword. Our QA strategy consisted of restarting the server once a week, because otherwise it would crash randomly. We developed our own COM+ component in Visual J++ to parse JPEG files uploaded to the server. As soon as JPEG 2000-encoded files started popping up, our component broke miserably.

We did not use source control, not even CVS, RCS or, God forbid, SourceSafe. Subversion did not exist yet. Our Joel Test score was minus 25.
6776 Days

For the past 6776 days I have had a cup of coffee in the morning and wrote code with things named VBScript, JavaScript, Linux, SQL, HTML, Makefiles, Node.js, CSS, XML, .NET, YAML, Podfiles, JSON, Markdown, PHP, Windows, Doxygen, C#, Visual Basic, Visual Basic.NET, Java, Socket.io, Ruby, unit tests, Python, shell scripts, C++, Objective-C, batch files, and lately Swift.

In those 6776 days lots of things happened; most importantly, my wife and I got married. I quit 6 jobs and I was fired twice. I started and closed my own business. I finished my Master Degree. I published a few open source projects, and one of them landed me an article on Ars Technica by Erica Sadun herself. I was featured in Swiss and Bolivian TV shows. I watched live keynotes by Bill Gates and by Steve Jobs in Seattle and San Francisco. I spoke at and co-organised conferences in four continents. I wrote and published two books. I burned out twice (not the books, myself,) and lots of other things happened, both wonderful and horrible.

I have often pondered about leaving the profession altogether. But somehow, code always calls me back after a while. I like to write apps, systems, software. To avoid burning out, I have had to develop strategies.

In this talk I will give you my secrets, so that you too can reach the glorious age of 40 as an experienced developer, willing to continue in this profession.
Advice For The Young At Heart

Some simple tips to reach the glorious age of 40 as a happy software developer.
1. Forget The Hype

The first advice I can give you all is, do not pay attention to hype. Every year there is a new programming language, framework, library, pattern, component architecture or paradigm that takes the blogosphere by storm. People get crazy about it. Conferences are given. Books are written. Gartner hype cycles rise and fall. Consultants charge insane amounts of money to teach, deploy or otherwise fuckup the lives of people in this industry. The press will support these horrors and will make you feel guilty if you do not pay attention to them.

In 1997 it was CORBA & RUP.

In 2000 it was SOAP & XML.

In 2003 it was Model Driven Architecture and Software Factories.

In 2006 it was Semantic Web and OLPC.

In 2009 it was Augmented Reality.

In 2012 it was Big Data.

In 2015… Virtual Reality? Bots?

Do not worry about hype. Keep doing your thing, keep learning what you were learning, and move on. Pay attention to it only if you have a genuine interest, or if you feel that it could bring you some benefit in the medium or long run.

The reason for this lies in the fact that, as the Romans said in the past, Nil nove sul sole. Most of what you see and learn in computer science has been around for decades, and this fact is purposedly hidden beneath piles of marketing, books, blog posts and questions on Stack Overflow. Every new architecture is just a reimagination and a readaptation of an idea that was floating around for decades.
2. Choose Your Galaxy Wisely

In our industry, every technology generates what I call a “galaxy.” These galaxies feature stars but also black holes; meteoric changes that fade in the night, many planets, only a tiny fraction of which harbour some kind of life, and lots of cosmic dust and dark matter.

Examples of galaxies are, for example, .NET, Cocoa, Node.js, PHP, Emacs, SAP, etc. Each of these features evangelists, developers, bloggers, podcasts, conferences, books, training courses, consulting services, and inclusion problems. Galaxies are built on the assumption that their underlying technology is the answer to all problems. Each galaxy, thus, is based in a wrong assumption.

The developers from those different galaxies embody the prototypical attitudes that have brought that technology to life. They adhere to the ideas, and will enthusiatically wear the t-shirts and evangelize others about the merits of their choice.

Actually, I use the term “galaxy” to avoid the slightly more appropriate if not less controversial term “religion,” which might describe this phenomenon better.

In my personal case, I spent the first ten years of my career in the Microsoft galaxy, and the following nine in the Apple galaxy.

I dare say, one of the biggest reasons why I changed galaxies was Steve Ballmer. I got tired of the general attitude of the Microsoft galaxy people against open source software.

On the other hand, I also have to say that the Apple galaxy is a delightful place, full of artists and musicians and writers who, by chance or ill luck, happen to write software as well.

I attended conferences in the Microsoft galaxy, like the Barcelona TechEd 2003, or various Tech Talks in Buenos Aires, Geneva or London. I even spoke at the Microsoft DevDays 2006 in Geneva. The general attitude of developers in the Microsoft galaxy is unfriendly, “corporate” and bound in secrecy, NDAs and cumbersome IT processes.

The Apple galaxy was to me, back in 2006, exactly the opposite; it was full of people who were musicians, artists, painters; they would write software to support their passion, and they would write software with passion. It made all the difference, and to this day, I still enjoy tremendously this galaxy, the one we are in, right now, and that has brought us all together.

And then the iPhone came out, and the rest is history.

So my recommendation to you is: choose your galaxy wisely, enjoy it as much or as little as you want, but keep your telescope pointed towards the other galaxies, and prepare to make a hyperjump to other places if needed.
3. Learn About Software History

This takes me to the next point: learn how your favorite technology came to be. Do you like C#? Do you know who created it? How did the .NET project came to be? Who was the lead architect? Which were the constraints of the project and why did the language turned out to be what it is now?

Apply the same recipe to any language or CPU architecture that you enjoy or love: Python, Ruby, Java, whatever the programming language; learn their origins, how they came up to be. The same for operating systems, networking technologies, hardware, anything. Go and learn how people came up with those ideas, and how long they took to grow and mature. Because good software takes ten years, you know.

The stories surrounding the genesis of our industry are fascinating, and will show you two things: first, that everything is a remix. Second, that you could be the one remixing the next big thing. No, scratch that: you are going to be the creators of the next big thing.

And to help you get there, here is my (highly biased) selection of history books that I like and recommend:

Dealers of Lightning by Michael A. Hiltzik
Revolution in the Valley by Andy Hertzfeld
The Cathedral and the Bazaar by Eric S. Raymond
The Success of Open Source by Steven Weber
The Old New Thing by Raymond Chen
The Mythical Man Month by Frederick P. Brooks Jr.

You will also learn to value those things that stood the test of time: Lisp, TeX, Unix, bash, C, Cocoa, Emacs, Vim, Python, ARM, GNU make, man pages. These are some examples of long-lasting useful things that are something to celebrate, cherish and learn from.
4. Keep on Learning

Learn. Anything will do. Wanna learn Fortran? Go for it. Find Erlang interesting? Excellent. Think COBOL might be the next big thing in your career? Fantastic. Need to know more about Functional Reactive Programming? Be my guest. Design? Of course. UX? You must. Poetry? You should.

Many common concepts in Computer Science have been around for decades, which makes it worthwhile to learn old programming languages and frameworks; even “arcane” ones. First, it will make you appreciate the current state of the industry (or hate it, it depends,) and second, you will learn how to use the current tools more effectively — if anything, because you will understand its legacy and origins.

Tip 1: learn at least one new programming language every year. I did not come up with this idea; The Pragmatic Programmer book did. And it works.

One new programming language every year. Simple, huh? Go beyond the typical “Hello, World” stage, and build something useful with it. I usually build a simple calculator with whatever new technology I learn. It helps me figure out the syntax, it makes me familiar with the APIs or the IDE, etc.

Tip 2: read at least 6 books per year. I have shown above a list of six must-read books; that should keep you busy for a year. Here goes the list for the second year:

Peopleware by Tom DeMarco and Tim Lister
The Psychology of Software Programming by Gerald M. Weinberg
Facts and Fallacies of Software Engineering by Robert L. Glass
The Design of Everyday Things by Don Norman
Agile!: The Good, the Hype and the Ugly by Bertrand Meyer
Rework by Jason Fried and David Heinemeier Hansson
Geekonomics by David Rice

(OK, those are seven books.)

Six books per year looks like a lot, but it only means one every 2 months. And most of the books I have mentioned in this presentation are not that long, and even better, they are outstandingly well written, they are fun and are full of insight.

Look at it this way: if you are now 20 years old, by the age of 30 you will have read over 60 books, and over 120 when you reach my age. And you will have played with at least 20 different programming languages. Think about it for a second.

Some of the twelve books I’ve selected for you have been written in the seventies, others in the eighties, some in the nineties and finally most of them are from the past decade. They represent the best writing I have come across in our industry.

But do not just read them; take notes. Bookmark. Write on the pages of the books. Then re-read them every so often. Borges used to say that a bigger pleasure than reading a book is re-reading it. And also, please, buy those books you really like in paper format. Believe me. eBooks are overrated. Nothing beats the real thing.

Of course, please know that as you will grow old, the number of things that qualify as new and/or important will drop dramatically. Prepare for this. It is OK to weep silently when you realise this.
5. Teach

Once you have learnt, teach. This is very important.

This does not mean that you should setup a classroom and invite people to hear your ramblings (although it would be awesome if you did!) It might mean that you give meaningful answers to questions in Stack Overflow; that you write a book; that you publish a podcast about your favorite technology; that you keep a blog; that you write on Medium; that you go to another continent and set up programming schools using Raspberry Pis; or that you help a younger developer by becoming their mentor (do not do this before the age of 30, though.)

Teaching will make you more humble, because it will painfully show you how limited your knowledge is. Teaching is the best way to learn. Only by testing your knowledge against others are you going to learn properly. This will also make you more respectful regarding other developers and other technologies; every language, no matter how humble or arcane, has its place within the Tao of Programming, and only through teaching will you be able to feel it.

And through teaching you can really, really make a difference in this world. Back in 2012 I received a mail from a person who had attended one of my trainings. She used to work as an Adobe Flash developer. Remember ActionScript and all that? Well, unsurprisingly after 12 years of working as a freelance Flash developer she suddenly found herself unemployed. Alone. With a baby to feed. She told me in her message that she had attended my training, that she had enjoyed it and also learnt something useful, and that after that she had found a job as a mobile web developer. She wrote to me to say thank you.

I cannot claim that I changed the world, but I might have nudged it a little bit, into something (hopefully) better. This thought has made every lesson I gave since then much more worthwhile and meaningful.
6. Workplaces Suck

Do not expect software corporations to offer any kind of career path. They might do this in the US, but I have never seen any of that in Europe. This means that you are solely responsible for the success of your career. Nobody will tell you “oh, well, next year you can grow to be team leader, then manager, then CTO…”

Not. At. All. Quite the opposite, actually: you were, are and will be a software developer, that is, a relatively expensive factory worker, whose tasks your managers would be happy to offshore no matter what they tell you.

Do not take a job just for the money. Software companies have become sweatshops where you are supposed to justify your absurdly high salary with insane hours and unreasonable expectations. And, at least in the case of Switzerland, there is no worker union to help you if things go bad. Actually there are worker unions in Switzerland, but they do not really care about situations that will not land them some kind of media exposure.

Even worse; in most workplaces you will be harassed, particularly if you are a woman, a member of the LGBT community or from a non-caucasian ethnic group. I have seen developers threatened to have their work visas not renewed if they did not work faster. I have witnessed harassment of women and gay colleagues.

Some parts of our industry are downright disgusting, and you do not need to be in Silicon Valley to live it. You do not need Medium to read it. You could experience that right here in Switzerland. Many banks have atrocious workplaces. Financial institutions want you to vomit code 15 hours a day, even if the Swiss working laws explicitly forbid such treatments. Pharmaceutical companies want you to write code to cheat test results and to help them bypass regulations. Startups want your skin, working for 18 hours for no compensation, telling you bullshit like “because we give you stock options” or “because we are all team players.”

It does not matter that you are Zach Holman and that you can claim in your CV that you literally wrote Github from scratch: you will be fired for the pettiest of reasons.

It does not matter that the app brings more than half of your employer traffic and revenues; the API team will treat you and your ideas with contempt and sloppiness.

I have been asked to work for free by very well known people in the industry, some of them even featured in Wikipedia, and it is simply appalling. I will not give out their names, but I will prevent any junior from getting close to them, because people working without ethics do not deserve anyone’s brain.

Whenever an HR manager tells you “you must do this (whatever wrong thing in your frame of reference) because we pay you a salary,” remember to answer the following: “you pay me a salary, but I give you my brain in exchange, and I refuse to comply with this order.”

And to top it all, they will put you in an open space, and for some reason they will be proud about it. Open spaces are a cancer. They are without a doubt the worst possible office layout ever invented, and the least appropriate for software development — or any type of brain work for that matter.

Remember this: the fact that you understand something does not imply that you have to agree to it.

Disobey authority. Say “fuck you, I won’t do what you tell me” and change jobs. There are fantastic workplaces out there; not a lot, but they exist. I have been lucky enough to work in some of them. Do not let a bad job kill your enthusiasm. It is not worth it. Disobey and move on.

Or, better yet, become independent.
7. Know Your Worth

You have probably heard about the “10x Software Engineer” myth, right? Well here is the thing: it is not a myth, but it does not work they way you think it works.

It works, however, from the point of view of the employer: a “10x Software Engineer” generates worth 10 times whatever the employer pays. That means that you she or he gets 100 KCHF per year, but she or he are actually creating a value worth over a million francs. And of course, they get the bonuses at the end of the fiscal year, because, you know, capitalism. Know your worth. Read Karl Marx and Thomas Piketty. Enough said.

Keep moving; be like the shark that keeps on swimming, because your skills are extremely valuable. Speak out your salary, say it loud, blog about it, so that your peers know how much their work is worth. Companies want you to shut up about that, so that women are paid 70% of what men are paid. So speak up! Blog about it! Tweet it! I am making 135 KCHF per year. That was my current salary. How about you? And you? The more we speak out, the less inequality there will be. Any person doing my job with my experience should get the same money, regardless of race, sex, age or preferred football team. End of the story. But it is not like that. It is not.
8. Send The Elevator Down

If you are a white male remember all the privilege you have enjoyed since birth just because you were born that way. It is your responsibility to change the industry and its bias towards more inclusion.

It is your duty to send the elevator down.

Take conscious decisions in your life. Be aware of your actions and their effect. Do not blush or be embarrased for changing your opinions. Say “I’m sorry” when required. Listen. Do not be a hotshot. Have integrity and self-respect.

Do not critisize or make fun of the technology choices of your peers; for other people will have their own reasons to choose them, and they must be respected. Be prepared to change your mind at any time through learning. One day you might like Windows. One day you might like Android. I am actually liking some parts of Android lately. And that is OK.


Everybody is raving about Swift, but in reality what I pay more attention to these days is LLVM itself.

I think LLVM is the most important software project today, as measured in its long-term impact. Objective-C blocks, Rust & Swift (the two most loved strongly typed and compiled programming languages in the 2016 StackOverflow developer survey,) Dropbox Pyston, the Clang Static Analyser, ARC, Google Souper, Emscripten, LLVMSharp, Microsoft LLILC, Rubymotion, cheerp, watchOS apps, the Android NDK, Metal, all of these things were born out or powered by LLVM. There are compilers using LLVM as a backend for pretty much all the most important languages of today. The .NET CLR will eventually interoperate with it, and Mono already uses it. Facebook has tried to integrate LLVM with HHVM, and WebKit recently switched from LLVM to the new B3 JIT JavaScript compiler.

LLVM is cross-platform, cross-CPU-architecture, cross-language, cross-compiler, cross-eyed-tested, free as in gratis and free as a bird.

Learn all you can about LLVM. This is the galaxy where true innovation is happening now. This is the foundation for the next 20 years.
10. Follow Your Gut

I had the gut feeling .NET was going to be big when I watched its introduction in June 2000. I had the gut feeling the iPhone was going to be big when I watched its introduction in 2007.

In both cases people laughed at my face, literally. In both cases I followed my gut feeling and I guess things worked out well.

Follow your gut. You might be lucky, too.
11. APIs Are King

Great APIs enable great apps. If the API sucks, the app will suck, too, no matter how beautiful the design.

Remember that chunky is better than chatty, and that clients should be dumb; push as much logic as you can down to the API.

Do not invent your own security protocols.

Learn a couple of server-side technologies, and make sure Node is one of those.

Leave REST aside and embrace Socket.io, ZeroMQ, RabbitMQ, Erlang, XMPP; explore realtime as the next step in app development. Realtime is not only for chat apps. Remove polling from the equation forever.

Oh, and start building bots around those APIs. Just saying.
12. Fight Complexity

Simpler is better. Always. Remember the KISS principle. And I do not mean only at the UI level, but all the way until the deepest layers of your code.

Refactoring, unit tests, code reviews, pull requests, all of these tools are at your disposal to make sure that the code you ship is the simplest possible architecture that works. This is how you build resilient systems for the long term.

The most important thing to remember is that your age does not matter.

One of my sons said to me, “Impossible, Dad. Mathematicians do all their best work by the time they’re 40. And you’re over 80. It’s impossible for you to have a good idea now.”

If you’re still awake and alert mentally when you’re over 80, you’ve got the advantage that you’ve lived a long time and you’ve seen many things, and you get perspective. I’m 86 now, and it’s in the last few years that I’ve had these ideas. New ideas come along and you pick up bits here and there, and the time is ripe now, whereas it might not have been ripe five or 10 years ago.

Michael Atiyah, Fields Medal and Abel Prize winner Mathematician, quoted in a Wired article.

As long as your heart tells you to keep on coding and building new things, you will be young, forever.

In 2035, exactly 19 years from now, somebody will give a talk at a software conference similar to this one, starting like this:

“Hi, I am 42 years old, and this is my story.”

Hopefully one of you will be giving that presentation; otherwise, it will be an AI bot. You will provide some anecdotical facts about 2016, for example that it was the year when David Bowie, Umberto Eco, Gato Barbieri and Johan Cruyff passed away, or when SQL Server was made available in Linux, or when Google AlphaGo beat a Go champion, or when the Panama Papers and the Turkish Citizenship Database were leaked the same day, or when Google considered using Swift for Android for the first time, or as the last year in which people enjoyed this useless thing called privacy.

We will be three years away from the Year 2038 Problem and people will be really nervous about it.

Of course I do not know what will happen 19 years from now, but I can tell you three things that will happen for sure:

Somebody will ask a question in Stack Overflow about how to filter email addresses using regular expressions.
Somebody will release a new JavaScript framework.
Somebody will build something cool on top of LLVM.

And maybe you will remember this talk with a smile.

Thank you so much for your attention.

Blog George Gritsouk

Blog George Gritsouk

I’m a web developer in Toronto, Canada. I have a degree in Nanotechnology Engineering from the University of Waterloo.

Human Git Aliases
Stubbornly Refusing to Speak The Computer’s Language

The most common .gitconfig I see is blank except for setting a username. The second most common is this:

ci = commit
cia = commit -a
cam = commit –amend
cama = commit –amend -a

cl = clean
cldf = clean -df

res = reset
resa = reset HEAD

# 82 more 4-character aliases

This config basically trades space in your head for keystrokes. Save on typing by remembering short command aliases. I don’t love that. I make typos, and sometimes I don’t get enough sleep, and generally this is just going to make life harder on me. I shouldn’t be bending to suit the computer’s language, the computer should learn mine. I don’t care so much about having short commands, I have a shell with autocomplete that works. Instead, I use real words and try to make the whole thing more human.

My goals with git aliases are:

smooth out git’s unwieldy UI
make a few common workflows faster

For example, in git, trying to just get a list of something in the repository is insanely inconsistent. I fix it like so:

branches = branch -a
tags = tag
stashes = stash list

How about common operations for undoing work? I never want to Google “how to unstage a file”, there should just be a %$&#ing command to unstage a file.

unstage = reset -q HEAD —
discard = checkout —
uncommit = reset –mixed HEAD~
amend = commit –amend

I even have a nuclear version:

nevermind = !git reset –hard HEAD && git clean -d -f

which unstages changes in the index, discards changes in the working directory, and removes any new files.

I also really like having

graph = log –graph -10 –branches –remotes –tags –format=format:’%Cgreen%h %Creset• %<(75,trunc)%s (%cN, %cr) %Cred%d' –date-order

to see real timeline of who is working on what and when. Another good example:

precommit = diff –cached –diff-algorithm=minimal -w

This is a key part of my workflow. I run this before every commit to make sure I don’t need to use the undo commands.

Bend the aliases to how you think and work, not the other way around. Let your aliases reflect your values, instead of just saving you keystrokes.

I got a few great suggestions from Reddit comments on this post:

unmerged = diff –name-only –diff-filter=U by kasbah and remotes = remote -v by WrongSubreddit are my favourites. Thank you!

A full list of my Git aliases is in my dotfiles repo.

bemycto.com: Building a blog with Jekyll in 5 points – Part 2: Templates

bemycto.com: Building a blog with Jekyll in 5 points – Part 2: Templates

This post is the continuation of a previous article: Building a blog with Jekyll in 5 points – Part 1: Presentation. Please be sure you read it first.
For the second part of this Building a blog with Jekyll series, we’ll take a look at the Liquid template system. It’s quite cool and powerful, I’m sure you will love it.

Basic overview
Liquid is a template engine written in Ruby and created by Shopify for theming purpose. As it’s a powerful library, Jekyll uses it as its template engine.

Liquid is based on three concepts:

Objects and variables that you can output, assign and modify
Filters that allow you to transform your objects and variables data before outputting
Tags that change template flow and do complex stuff
Jekyll provides a lot of objects, filters, and tags. Using them, you can customize your website with few efforts.

Output data
First thing first, we need to output our data. We’re assuming our page has a page.title property which is equal to My awesome Title.

If we want to display this in an h1 tag, we can add this in our template:

{{ page.title }}

Don’t worry about HTML escaping: Liquid does the job for us. If you want to display raw data, for example if you have HTML tags in your title and you’re absolutely sure that this data is safe. You can use this instead:

{{{ page.title }}}

These are the basics of Jekyll templating. Now, we’ll take a look at the filters.

Filters help you transform your data in a convenient way. For example, imagine we’re sticking to the Ruby On Rails paradigm Convention over configuration.

We decided that using a slug of the title we can find its associated picture using this pattern:

We can simply use the slugify filter to make this possible:

{{ page.title}}
Simply using the | operator we can process our data with the given filter to transform them. That’s incredibly powerful, and there is a ton of filters available. Don’t worry about the site.baseurl, we’ll talk about this in the part 3.

If you want a complete list of available filters, take a look at the documentation.

Tags are a powerful way to change your template flow. Typical tags are if blocks, for loops.

Tags are called like this:

{% my_tag and_some_optional_params %}
One of the most useful to reuse content is the include tag, especially combined with the for tag. For example:

{% for post in site.posts %}
{% include post_preview.html current_post=post %}
{% endfor %}
The file named _includes/post_preview.html will be loaded, and can access the include.post value. For example to only display post title:

{{ include.post.title }}

If you want a complete list of available tags, you get it, the documentation is here fo this.

If you want to go further and create your own filters and tags, Jekyll allows it. We won’t cover this topic here, but you can find a lot of plugins that add new filters, tags and a lot of cool stuff.

For example in The WebTechie Review, I use two plugins:

One for generating the tag cloud
One that modifies categories permalinks to slugify them
Wrapping up together
Summing it all up, here is a quick sample of how we can display a posts list:

# Content of the index.html file

My site posts

{% for post in site.posts %}
{% include post_preview.html current_post=post %}
{% endfor %}
The empty metadata block (surrounded with 3 dashes) is mandatory for Jekyll to parse your file. Without it, it will include it as plain text without parsing.

# Content of the post_preview.html file

{{ include.current_post.title }}

{{ include.current_post.title }}
{{ include.current_post.excerpt }}
{{ include.current_post.content | number_of_words }} words
{{ include.current_post.date | date_format_to_string }}
Given the following post:

# Content of _posts/2015-05-23-my-post.md

title: My post
date: 2015-05-23

This first paragraph will be the excerpt property. Please don’t truncate it without stripping tag before.

This second paragraph will only be displayed in the content property.
Will generate the following HTML:

My site posts

My post

My post

This first paragraph will be the excerpt property. Please don’t truncate it without stripping tag before.

27 words
2015-05-23 00:00:00 +0200
Pretty powerful, isn’t it?

Next time…
Now it could be a little clearer… But I imagine you have still many questions:

What are those variables like site.posts and such?
How can I build a real website using Jekyll?
How can I deploy it in production?
These three points are going to be explained in the next parts. If you have a question, please leave a comment 🙂