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.
- Felix’s Node.js Beginners Guide: written by Felix Geisendörfer, early contributor to Node.js, this is very short by “to the point” introduction to Node.js.
- Felix's Node.js Style Guide: still by Felix, a list of guidelines, ranging from how many spaces for a tab to closures and EventEmitters.
- Programming Styles in the Node Community: A comparison of the styles of 3 prominent node.js opensource developers: Ryan Dahl, creator of Node, Isaac Z. Schlueter, author of npm, and TJ Holowaychuk, author of Express (and more).
- Bulletproof Node.js coding: very opinionated list of suggestions, some probably dictated by preferences of the developer that wrote it, other 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 advices on how to do it easily.
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.
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/
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.