Every now and then I go back to do 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 is still valid … even the book Node.js in Action is still in 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” into 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 links that I found useful.

Coding and Development Guidelines

Here are some of the links I found useful.

• Felix’s Node.js Beginner's Guide: Written by Felix Geisendörfer, an early contributor to Node.js, this is a very short, “to the point” introduction to Node.js.
• Felix's Node.js Style Guide: Also by Felix, this is a list of guidelines, ranging from how many spaces to use in a tab, to closures and EventEmitters.
• Principles of Writing Consistent, Idiomatic JavaScript: A more detailed style guide, with more examples.
• Programming Styles in the Node Community: A comparison of the styles of 3 prominent Node.js open source developers: Ryan Dahl, creator of Node, Isaac Z. Schlueter, author of NPM, and TJ Holowaychuk, author of Express (and more).
• Node.js: Style and Structure: Enough with JavaScript code writing guidelines. This guide focuses more on Node.js-specific recommendations.
• Bulletproof Node.js Coding: A very opinionated list of suggestions, some probably dictated by preferences of the developer who wrote it, and others more widely adoptable.
• Bootstraping a Node.js App for Dev/Prod Environment: Something that I really wanted to understand better was how to configure different settings based on the environment in which the application is running--production, development, testing and so on. This page gives some good advice on how to do that easily.
• Why use "closure"?, and What is "this"?: These are two articles explaining in detail two fundamental concepts of JavaScript programming: this and closures.

One common idea that comes out from those pages is:

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 guide, 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 the Node.js version, jasmine-node). Jasmine is a BDD framework, 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 for Jasmine is well done, with samples of every aspect of the framework, and the wiki also explains 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 include Mocha and QUnit, the frameworks 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, useful because your application probably has 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 to add 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 it's 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 picks up every pull request and runs the same set of tests, thus immediately verifying whether the pull request broke something or not.

Deployment

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.

Conclusion

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

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