Every now and then I go back to doing something with Node.js, and when this happens I’ve already forgotten everything I did and all the little knowledge I acquired the previous time I used it. And I always have to start almost from the beginning again.

Two years ago I wrote about “How to get started with Node.js”: I think most of the information there are still valid… even the book Node.js in Action is still a MEAP (this time planned for release this month, August 2013).

This summer I’m planning on revising, during my holidays, the architecture of OpenROV, and given the huge number of people that are starting to use it, I want to inject" a bit more of “better ALM” in the mix, so I started to look around for coding conventions, development guidelines and how to do unit testing, continuous integration, build and so on: this post is a collection of some link that I found useful.

Coding and development guidelines

Here are some of the links I found useful.

One common idea that comes out from those pages is that:

All code in any code-base should look like a single person typed it, no matter how many people contributed.

So, when starting a project, either open source or proprietary, write a style guideline, possibly striving for maximum readability, especially if it’s open source, and make sure every contributor agrees and then follows it.

Testing framework

A testing library I’m looking into experimenting with is Jasmine (or actually it’s node.js version jasmine-node): it’s a BDD framework and the syntax looks pretty intuitive and, if text descriptions are carefully chosen, the report is very human readable and describes very well what each test is doing.

The documentation of jasmine is well done, with samples of every aspect of the framework, and the wiki explains also how to use Jasmine with other frameworks. If you want to do some tests you can also try it directly online at: http://tryjasmine.com/

Other JavaScript testing frameworks are Mocha and QUnit, the framework used to test jQuery, jQueryUI and jQuery Mobile. To use this last one with Node.js you need to use its port on Node.js: node-qunit.

And while not strictly a testing framework and also not needed with Node.js, Karma is a test runner for JavaScript. Because probably your application also have some JavaScript that runs in the browser and integrates with the DOM.

CI and build

One service I’ve tried a few times, mainly for testing purposes, is Travis CI: it automatically pulls changes from GitHub and can build projects on most platforms (except .NET). To configure it all you need is adding a .travis.yaml file on your repository.

OpenROV is already being built on Travis-CI, but at the moment it only installs all the needed packages, so not very useful. But once I add some tests I think it will become more interesting to use.

I’ve also noticed that Travis-CI also picks up every pull requests and run the same set of tests, thus immediately verifying whether the pull request broke something or not.


I usually deploy to Azure Websites, which can run Node.js without a problem. I gave a speech at the local node.js user group about how to deploy a MongoDB powered Node.js app on Windows Azure.


Let’s now see if I find the time to really build a prototype of the new structure of the OpenROV brain.

Do you have more links you want to share and think are useful? Please write a comment and I’ll add them to the post.