You have written a node.js module lately? It has a test suite? Awesome! Time
to get yourself a nerd badge of honor:
But hang on nerdy warrior, this precious award has to be earned. So go ahead and
check out the sweetness that is Travis CI. Travis is an open
source, free to use, continuous integration server. Initially it was just
building ruby stuff, but these days it supports a ton of other languages,
including node.js.
And luckily, getting travis to run your tests on every GitHub push is really
easy as well:
Step 1: Go to Travis and login/connect with your GitHub account.
Step 2: Hover over your name on the top right, and select "Profile" from the
dropdown.
Thanks to Isaac, npm is getting more and more awesome by the hour. One of the
coolest recent additions (you need at least v1.0.26) is the ability to specify
private git repositories urls as a dependency in your package.json files.
At transloadit, we are currently using the feature to move some of our
infrastructure code into separate packages, allowing for those to be tested
and developed in isolation making our core application easier to maintain and
work on.
The syntax for referencing a git repository (and commit) is as follows:
With now more than 3000 modules, there are huge gaps in the quality of things you find in the npm registry. But more often than not, it's easy to find a module that is really close to what you need, except if it wasn't for that one bug or missing feature.
Now depending on who is maintaining this module, you may get the problem resolved by simply opening a GitHub issue and waiting for a few days. However, open source doesn't really work without community, nor do you always want to be at the mercy of someone else. So a much better approach is to actually roll up your sleeves, and fix the problem yourself.
Here is the proper way to do this while using npm to manage your forked version of the module:
We apologize for the short notice, but if you are looking to put node.js in production, this full day node.js workshop we are organizing is where it's at!
The workshop is happening on Friday June 10, one day before nodecamp.eu. Space is limited to 15 people and expected to sell out quickly.
As a reader of our blog, you can get a 15% discount on the regular ticket by using the code 'debuggable'.
Should you attend?
This workshop will teach you everything you need in order to write and deploy powerful node.js applications. We'll try to cover a lot of ground, so if you are interested in any of the following, you should definitly attend:
If you are a developer, and you have not switched to a SSD yet, what is your excuse?
Let me explain. I've switched to an SSD a little over a week ago, and it's a different world. You know that feeling of having just bought & setup a new machine and everything still runs very fast? Well, a SSD will make every single day feel just like that, except much faster.
But I already knew that, so why has it taken me, and apparently you who is reading this, so long?
Well, my main problem was that I have a few big things on my hard disk, namely music, photos and virtual machine images. This means that I need a hard disk of ~300 GB to work comfortably. However, the SSD I was interested in only comes in 40, 60, 120, 240 and 480 GB. The 480 GB costs ~$1.580 right now.
I've been in Atlanta for the past two weeks, and thanks to the kind help of a few folks, I was able to present at 2 meetups, as well as Startup Riot 2011.
First up was a new talk at the Atlanta Ruby Meetup:
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
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.
Last night I had the honor of speaking about node.js in front of Berlin's ruby community at the @rub_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 : ).