Join the DZone community and get the full member experience.Join For Free
Bugsnag monitors application stability, so you can make data-driven decisions on whether you should be building new features, or fixing bugs. Learn more.
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.
- 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).
- 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.
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.
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/.
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.
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.
Published at DZone with permission of Simone Chiaretta , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.