debuggable

Last night I was giving a talk about node.js in production at the Berlinjs user group.

In the talk I shared some of our experiences at Transloadit, but also tried to cover the topic from a general angle.

I concluded that running node apps in production comes with certain challenges, most notably the lack of useful stack traces when things go wrong. But that's something Ryan is working on, and a little unit testing can go a long way to avoid most bugs : ).

Download: nodejs-in-production.pdf

Let me know if you have any questions!

--fg

In der aktuellen Ausgabe des t3n Magazins gibt es einen von mir verfassten Artikel zum Thema node.js:

Schubrakete für JavaScript - Wie Node.js JavaScript auf dem Server revolutioniert

Der Artikel richtet sich vor allem an komplette Neulinge, eignet sich von daher aber super um mit dem noch ein oder anderen skeptischen Kollegen ins Gespräch zu kommen.

Für alle die an einer kostenlosen Ausgabe des Heftes interessiert sind: Einfach den link re-tweeten und mir dann eine E-Mail schicken. Die ersten 3 tweets bekommen ein Exemplar per Post.

--fg

You have probably heard a few talks or read a few articles where test driven development is depicted as a magic unicorn that watches over your software and makes everybody happy. Well, about 18.000 lines of "magic unicorn" code later, I'd like to put things into perspective.

The truth is, test driven development is a huge pain in the ass. Writing those damn tests all the time takes a huge amount of discipline, and it doesn't really get a whole lot easier with time.

But do you know what sucks more? The liability that comes without those tests.

Let me clarify. I'm not trying to tell you that you should practice test driven development. What I will try to do however, is to give you a realistic idea about the work it takes and the kind of benefits you get from it.

At this point I basically think of test driven development as an insurance policy. It guarantees that your software will have a certain pre-defined quality mostly measured by the amount of bugs and the risks of changing the software. It can also reduce the costs of your main developer getting run over by a bus, or the same thing happening to the API of the platform you are building on.

However, there are also millions of people on this planet that live without any insurances whatsoever, so clearly this is not the only way of getting from point A to B. It all depends on your liability and how you can / want to deal with it.

At Transloadit 100% of our code is developed test driven. The main reason for that is that we are building on node.js which still is a very risky technology at this point and probably our biggest liability and advantage at the same time. Another big risk are third party tools such as ffmpeg and image magick that are insanely dangerous to upgrade since they love to change APIs and behavior all the time. And last but not least, some of the stuff we are doing is rather complex.

Now let me explain how test driven development lets us deal with those risks. First of all, new features always start out as a system test. Each system test boots up the entire REST service, sends an actual HTTP request to it, and evaluates the response as well as the files that were created in the process. Files are verified by looking at their meta data, as well as performing visual diffs on images against expected fixtures. For videos we are using thumbnails to do the visual comparisons.

Once that test is written (and failing), we start writing unit tests. Let me explain what we mean by "unit". A unit to us is the tiniest atomic piece of functionality we can possibly test. As soon as there is a function call, creation of a class, or even a callback closure - we stub it. Everything that can be isolated and tested separately is handled by itself. As you can imagine, that's the part where the pain and discipline come in.

However, there is a certain undeniable beauty resulting from it. Writing those tests feels like proofing mathematical theorems. Every step is just small enough to be broken down to raw logic. Everything builds upon the previous step. There is no need to test all numbers in between 1 - 1000000, unless there is a logical reason for expecting a different result.

Of course there is a good chance of you going crazy in the process and losing track of the original goal. That's where the system test comes to rescue. Whenever you don't know what needs to be done next, you simply run the system test and it will tell you what's missing.

Is this process perfect? No. We have had a few bugs here and there, but I can still count them on two hands. Last weekend we pushed a rather insane change into production: We replaced our underlaying MySql driver (we were using that of PHP, don't ask how that worked) with node-mysql. I've been working on node-mysql with the same care and TDD-masochism as we have on transloadit, so the update went without a single hickup (so far). Not bad for a change that involved 6000 lines of code.

And that's it. Our service is not necessarily better than our competitors' because we use TDD. However, our risk of breaking things is much smaller, and we can perform heart-surgeries like this without breaking a sweat. This gives us the confidence to charge money, and the ability to spend the rest of our limited resources (we are bootstrapping) on innovative new features rather than dealing with the shortcomings of our software all the time.

So, is TDD right for you? It depends. Writing code the TDD way requires a ton of discipline, and the unicorns aren't always around to make you feel better. So make sure you have good reasons to do it. Sometimes a few system tests can get you 80% of the results for 20% of the work. Other times you need the remaining 20%. Also keep in mind that we're lucky at Transloadit for using a flexible language and most of our interfaces are JSON. This makes testing cheaper for us than it might be for you.

--fg

PS: If I find some more time, I'd love to go into more details of our node.js unit testing. Leave a comment if you're interested. Meanwhile make sure to check out the tests for node-mysql, they are done exactly like our internal tests.

Last night I had the honor of speaking about node.js in front of Berlin's ruby community at the @rug_b user group meetup.

The meeting was well attended (~50 geeks), but wooga did a great job hosting the event and even let us use their main room after it became clear that we couldn't fit everybody in the initial room.

The slides of my talk are available on slideshare and as a pdf download. For those of you who have seen the previous version of the talk, this is a very much updated version. Basically I had to replace all previous "The Future" slides with new content since node has implemented all of those things by now : ).

Anyway, Tim and I had a great time talking to everybody and also enjoyed the other talks about Mongrel2 and Phusion Passenger 3.

--fg

The last two days at JSConf.eu can only be described as epic. Thanks to holger, jan and malte the whole event was perfectly planned and executed.

Node was in the air and managed to infiltrate a big part of the conference. But I also got a kick out of some of the fantastic frontend talks.

Microsoft was hard at work trying to convince developers that IE9 is going to be the real deal, but Douglas Crockford seemed skeptical, getting into a bit of a fight with one of the Microsoft representative during his talk. The efforts they are putting into making canvas fast seem good, but I'm skeptical if they can finally deliver an all-around decent browser.

Palm was showing of their new node-powered WebOS stuff, and if all works out I'll soon have a device which I'm looking forward to play with.

Ryan gave a presentation on a few of the problems the node projects needs to overcome in the near future, and Jed pulled of one of the best presentations I've seen at a conference so far - I'm very much looking forward to playing with his new version of fab.

I gave a talk about dirty, which is a tiny key-value store I've written in node.js, basically to test the waters for writing more serious databases with node. If you're interested in it, you can checkout the slides or download them directly.

Another fantastic part of the conference was getting the chance to meet some fantastic new people such as:

• Bryan Cantrill - He works with ryan at joyent and is one of the dtrace authors
• Philip Hofstetter - He is using node-paperboy to run tempalias.com
• Erik Corry - A member of the v8 team
• Mark Mayo - The node hosting stuff they do at Joyent is really fantastic
• Nicole Sullivan - She does object oriented css and is working on a cool CSS lint tool
• Tobias Schneider - The crazy guy who ports flash to JS
• Blaine Cook - Former twitter hacker and co-creator of OAuth

My brain is still somewhat damaged from partying until 5am last night, so the above list is missing a bunch of other people I really enjoyed meeting as well.

And of course we were also spreading plenty of transloadit propaganda, resulting in tons of good feedback - some people really seemed to dig our little project : ).

Anyway, if you weren't here - you should really keep your eyes open for the next JSConf.us which, depending on the volcano situation, I'll hopefully be at as well!

--fg

PS: Please let me know if you have any questions about dirty, I'd be happy to answer them.