But first the development environment

I started a series of blog posts about my work with node.js last week. And of course the thing I forgot to mention is the actual process of development. 

A lot of people seem to really like using Webstorm from Jetbrains. and it’s certainly a full featured tool. I tried it for ten days and just couldn’t get used to it. So I now spend my days living inside three different windows: Sublime Text for editing, Chrome for browser testing and the Terminal for running node.js.

If you’ve not yet used Sublime Text then it’s worth having a look, it’s a text editor but on steroids, so it will has awareness of different text file formats: JS, HTML, CSS etc etc and will offer basic code completion. But will also allow you to edit multiple lines of text at once, it has all sorts of plugins and so on.

Chrome has become my defacto standard for browser testing (although I actually use Safari for actual web browsing). Its developer tools are unmatched, and more recently it has also offered basic emulation of mobile devices. Definitely not the same as running on the real thing, but good for basic testing.

And then finally there is the terminal window. As my colleagues will testify, I am not a command line sort of geek, it just feels too much like a hair shirt to me. But with node.js development there really is no avoiding it so it’s worth learning a little. Although to be honest my usual workflow is to have two terminal tabs open: one in which I type “npm start” and the other in which I type “grunt watch”. The first of these launches my dev server running on port 3000. While it’s running in dev mode it will automatically pick up changes I make to source code and restart itself as required. I can also print out to the console if I need to do some debugging.

A screen capture of my working environment

The latter command launches GruntJS which is a task runner. This allows me to have scripts to run every time I make a change to a subset of files. In my dev environment, I want my JS and CSS files to be automatically minified. And then I can also have it automatically run unit tests against my code, or JS Lint checks to make sure I’m not introducing too many bugs.

The other thing that you need to get working with very early on (if it’s not already baked into your workflow) is some sort of source control system. You will be editing a lot of files and it’s easy to lose track, so why not offload that task onto a tool. In my case (as with 90% of the development world it seems) I use Git and Github. This has the nice advantage that Heroku (my application hosting platform) also allows me to push up changes from my Git client as and when I need to. Talking of Git clients, I am switching between Source Tree and Tower these days (see what I mean about avoiding the command line when I can).

Of course everyone has their own way of working and the dev workflow for node in particular it seems like you could spend your whole life perfecting the workflow rather than actually doing any work so don’t get too hung up on it, but this is what works for me.