This was highly unexpected: Nine Algorithms That Changed the Future is a hell of a book!

The premise of the book is that it might be too boring for those familiar with the industry, but it’s one of the most fascinating books I’ve read over the past few months instead: sure, some topics were really basic and you could skip some chapters as they were explaining computing fundamentals to people with no prior knowledge, but the book got me hooked regardless, as it’s able to walk you through some very interesting topics such as Quantum Computing or software that fixes itself.

Read on →

I generally like to think of myself as a server-side guy but, since a few years, I’ve been more and more involved with the frontend — especially since logic, and not just UI, started to become a hot-topic for the client as well (this is all thanks to Angular, y’all remember that thingy?).

So, more often than I admit, I keep an eye on the upcoming features of various browsers through their platform status pages, and I’ve decided to start sharing a bunch of the stuff you should probably be excited as well. I plan of writing a couple articles like this one on a yearly basis, as browsers evolve quickly and there’s always lots of stuff to be looking forward to.

Read on →

If you’ve worked with Node long enough, chances are you probably grew fed up with the lack of plug-and-play benchmarking and profiling tools in its ecosystem: well, at least for debugging, say no more!

One of the most overlooked features that landed in Node over the past year is enhanced debuggability which, coupled with Chrome’s DevTools, makes it extremely easy to debug and profile server-side JavaScript: it comes with full support of the usual suspects such as breakpoints and CPU profiles, and it’s extremely easy to setup — no external dependency, no overhead, just Chrome.

Read on →

Exceptions happen everyday: the bigger (and the more distributed) the system, the higher the chances for things to go south.

Most of us already learned the lesson when we idealized architectures and they bit us back in the form of a catastrophic downtime that could have been avoided, maybe by just adding a required timeout or keeping a few best practices for distributed systems in mind: we are now better architects, who understand that failures are an option and we have to build resilient systems that embrace them and work towards mitigating their impact.

There is one thing, though, that most of us (including me) still suck at: throwing beautiful errors.

We have great infrastructures in place to log information and monitor our systems where, in theory, everything is taken care of; then the day comes when disaster, in the form of a nasty bug, strikes and we’re left trying to understand what’s going on with our software.

How many times, after fixing a bug, you find yourself saying “let’s add some more logs though”? If you’ve been as frustrated as I’ve been, I’d recommend you to read on.

Read on →

Yesterday, while profiling one of our NodeJS apps, I bumped into an interesting piece of code that seemed to take too long to run: interestingly enough, everything seemed to point to lodash’s pick function.

Read on →

Ever met this guy?

ERROR:  Loading command: install (LoadError)
  /usr/lib/x86_64-linux-gnu/ruby/2.1.0/ symbol SSLv2_method, version OPENSSL_1.0.0 not defined in file with link time reference - /usr/lib/x86_64-linux-gnu/ruby/2.1.0/
ERROR:  While executing gem ... (NoMethodError)
    undefined method `invoke_with_build_args' for nil:NilClass
Read on →