Tech Radar October 2016

The technologies I keep an eye on and find interesting evolve over time. I thought it could be interesting to share the things I’m currently seeing, thinking about, and playing with. The things on my technological radar, if you will.

Here’s my list for this month. Previous editions can be found here.


One of the big issues I have with JavaScript these days — but I suppose it’s been like this for a decade — is that there’s too much setup time, and too much choice. This is one of the things that attracted me to Dart initially — having the foundations locked down, so we don’t have to debate the fundamentals over and over again (on an unrelated note — Dart is in the news again).

I don’t develop stuff day-to-day anymore. I only have time to prototype some things from time to time. If I have an evening from some JS hacking, in effect I end up spending it setting up webpack with babel with React with …

Next.js makes opinionated choices and hides the whole build, rebuild, production build process, handles server-side rendering and routing. Next time I have some time, this is for sure the library/framework/environment (not sure what to call it) I’d start-off with.

Let’s see if this gets some adoption, would be good. It comes from the great people of Zeit, creators of other interesting tools like now and HyperTerm.

The Beauty of Ugliness

I didn’t realize this, but Slack is yet another company that is heavily invested in PHP. Somehow I had the sense that PHP was really a thing of the past. Sure, Facebook is heavily invested in it too, but I assumed this was legacy. Perhaps not so much. Keith Adams at Slack has a nicely balanced post about the benefits and costs of building with PHP today.

As it turns out, if enough companies (or even just one significant one) become so reliant on a technology that has fundamental flaws — they really can be overcome. PHP is one example of this, with Facebook making it fast with HHVM, and more safe and friendly using Hack.

One other example of this is JavaScript. JavaScript isn’t all beauty. But if you throw enough committee time at it, and invest enough raw engineering time into it, you can fix most issues and make it pretty damn fast.

Anything can be fixed if you put your mind — or rather many thousands of incredible minds — to it.

Ops in a Serverless World

In last month’s tech radar I wrote about Serverless web apps. If the future of servers is no (visible) servers, then… will Ops people still have a job?

Susan Fowler writes about this Ops Identity Crisis:

A big theme in the keynotes and conversation during Velocity Conf in NYC a few weeks ago was the role of ops in an “ops-less” and “server-less” world. It’s also been a big feature in discussions on twitter and in conversations I’ve had with coworkers and friends in the industry. There are several things that stand out to me in these conversations: first, that some ops engineers (sysadmins, techops, devops, and SREs) are worried that they will be phased out if developers and software engineers are responsible for the operational tasks in their systems; second, that developers and software engineers do not have the skills needed to take over responsibility for operational tasks; and third, that building reliable systems is impossible without an operations organization.

From my perspective: serverless is a cool concept, but it will probably take a decade or more to go mainstream. It requires quite a drastic shift in how we build software systems from what we’re used to.

I suspect that there will be plenty of “ops related” work left — work that’s more interesting than “pure ops” work like “I’m getting an alert the disk of server A is full, let’s clean up some logs.” Somewhat related is my article about creating a super team, where the role of DevOps is to build tools rather than doing the operational work (which should be automated and done by the team). This idea is inspired by a book I discovered this month: “Site Reliability Engineering” Currently I’m 15% in. Good stuff so far. Definitely recommended if you care about the Ops/DevOps/SRE stuff (as I do).