TrackMyRun is written using CoffeeScript, Node.js and Express. I’m also using the Bootstrap toolkit from Twitter for styling. I’m intending to actually use this small application for myself by hosting it on Heroku or some other cloud solution as soon as I’m able to finish the most essential features. It’s far from done yet, but you can already have a look at the source code on GitHub.  As always, suggestions are welcome.

Happy reading!

Express simply uses HTTP verbs for its routing API.

// Index
app.get('/runs', function(request, response) { });            

// New run 
app.get('/runs/new', function(request, response) { });

// Create a new run
app.post('/runs', function(request, response) { });

// Show run
app.get('/runs/:id', function(request, response) { });

// Edit run
app.get('/runs/:id/edit', function(request, response) { });

// Update run
app.put('/runs/:id', function(request, response) { });

// Delete run
app.delete('/runs/:id', function(request, response) { });

Well, that’s pretty much all that you need to get started. The routes that we specified here are treated as plain old regular expressions. Note that in order to make the put and delete routes work, we have to add a hidden field to the view.

<input name="_method" value="PUT" type="hidden">

But the thing that I personally struggled with the most was finding out a decent way to divide up these routes into separate modules without too much of a hassle. Most sample and demo applications out there that use Express usually have all their routes specified in a single app.js file. This is something that I don’t like very much as this can become unmaintainable faster that you might think. Roughly 2000 years ago, there was this great emperor (and many after him) who valued the principle of Divide and Conquer. In order to create maintainable applications, being able to divide up these routes is quite essential. There are several ways to do this.

Express Resource

This library enables us provide resourceful routing. As usual, express-resource can be installed using npm by using the following command:

 npm install express-resource

Using express-resource, we can create controller modules and use them from our main module. The following snippet shows how a simple controller looks like:

exports.index = function(request, response){
    response.send('Index runs');
};

exports.new = function(request, response){
    response.send('New run');
};

exports.create = function(request, response){
    response.send('Create run');
};

exports.show = function(request, response){
    response.send('Show run ' + request.params.id);
};

exports.edit = function(request response){
    response.send('Edit run ' + request.params.id);
};

exports.update = function(request, response){
    response.send('Update run ' + request.params.id);
};

exports.destroy = function(request, response){
    response.send('Delete run ' + request.params.id);
};

Now in the main module (app.js) we just have to add the following code:

var resource = require('express-resource')

// ...

application.resource('runs', require('./routes/runs'));

That’s it! Now all these routes are hooked up and ready to use. Express-resource has a few other neat features as well. Check out this episode from Node Tuts to learn more.

Although this seems like a good solution to divide up routes into controller modules, somehow it doesn’t resonate with me. All routes for a particular resource need to exist in the same module which still feels a bit unwieldy to me. I want to have an even more granular approach.

Super-duper Require

What I like to do is to separate routes based on their context:

• runs/index.js ( index route )
• runs/new.js ( new and create routes )
• runs/show.js ( show route )
• runs/edit.js ( edit and update routes )
• runs/delete.js ( delete route )

Wouldn’t it be cool if we could just “require” the runs directory and hook up all routes exported by all the modules that exist in this directory? Well, meet super_duper_require! While still using express-resource, we can now add all these routes like so:

application.resource('runs', super_duper_require(module, './routes/runs/'));

This is how the super_duper_require function looks like:

_ = require('underscore');

function super_duper_require(mod, path) {
    var mixin = {};
      fileSystem.readdirSync(path)
          .forEach(function(filename) {
            _.extend(mixin, mod.require(path + filename));
        });

      return mixin;
};

We just use the magnificent underscore.js library here to hook things up. This is just one of the fancy ways to solve the granularity problem. If we don’t want to use the express-resource library, we can always accomplish the same thing by going “plain old school” style.

Plain Old School

This is how I currently set up routing with Express. We no longer need the express-resource library for setting up our routes, but we can still use the same granularity as shown earlier. We also need underscore.js again, just as in the previous example, in order to stitch things together.

var routes = require('./routes');
var routes.runs = _.extend(require('./routes/runs'),
                           require('./routes/runs/new'),
                           require('./routes/runs/show'),
                           require('./routes/runs/edit'),
                           require('./routes/runs/delete'));

...

function bootstrapRoutes(application) {
    app.get('/runs', routes.runs.index);
    app.get('/runs/new', routes.runs.new);
    app.post('/runs', routes.runs.create);
    app.get('/runs/:id', routes.runs.show);
    app.get('/runs/:id/edit', routes.runs.edit);
    app.put('/runs/:id', routes.runs.update);
    app.delete('/runs/:id', routes.runs.delete);
}

Up until now I’m pretty happy with this approach. I would love to hear how others divide up their routes into several modules. So please let me know if there are other awesomely cool ways to deal with this. In the mean time, I hope this helps.

Until next time.

Nonetheless, a lot of stuff happened this year, good and not so good. First of all, I changed jobs twice this year. I’ve been working at iChoosr for a couple of months now and it still feels like I’ve finally come home. I really enjoy working there, my colleagues are awesome folks and I learned a ton already. I do hope to have at least the same amount of fun next year.

While enjoying my .NET job during the day, I’ve been doing a lot of Node.js hacking in my spare time, which you could probably tell looking the amount of blog posts I’ve been writing on this topic this year. This has all been a lot of good fun. I have a couple of more blog posts on Node.js lined up for next year, so stay tuned.

The new programming language I learned this year was CoffeeScript, which looks a lot like Ruby. Unfortunately, Ruby is still on my wish list for new programming languages to learn as is Clojure and/or Scala. I wonder which of these I’m going to pick up in 2012?

One of the things that I’m eager to learn about is another operating system. I’ve been soaking in a lot of Unix/Linux stuff during the last couple of months. I’ve been using and developing software for the Windows platform like forever and learning an entire new OS has not been easy. But I must say that it’s well worth the time and effort. I’ve been developing Node.js libraries and applications in my spare time entirely on Ubuntu and I’m looking forward to take a peek at Linux Mint as well. Perhaps I’ll completely switch over to Linux next year, I’m not entirely sure about that yet.

I’ve been facilitating a good number of European VAN sessions throughout the year. 2011 has been the third year for the E-VAN and I must say that it’s been a fun ride. But I do feel that the time has come for me to move on. I must admit that I only opened Visual Studio a couple of times in my spare time, and then only by accident. Being really honest with myself, I’m just not that interested anymore in the latest and greatest in the .NET space compared to only a couple of years ago. I think I somehow hit a saturation point. So I’m no longer going to organize and/or host new E-VAN sessions. I’ll be more than happy to pass the torch to other developers out there who are willing to step up to the plate. I hereby want to thank all the speakers and those who contributed in the discussions for all their efforts. The recordings are still there and I do hope many folks were able to learn something. I know I most certainly did.

Having a job closer to home and also being able to work from home at least once a week ensures that I’m able to spend more time with my family. I’m probably most thankful for that. Working out has been a lot of fun this year as well. I was able to drastically improve myself by running longer distances and also running a lot faster. I’m planning to participate in even more street runs during the next year. I’m looking forward to sustainably improve even further without overloading my body. This is definitely one of the biggest challenges for the upcoming year. 

All that’s left for me here is to wish you all the best for the new year!

Until next year. 

There are several frameworks out there for building web applications with Node.js, one being more successful than the other. Express is probably the most popular and well known web development framework for Node.js. It’s heavily inspired by Sinatra and built on top of connect, which provides a middleware layer in order to easily add several capabilities and therefore extend your web application. As with most Node.js libraries, Express can be easily installed using npm.

npm install express

The following code snippet shows the most basic HTTP server example using Express:

var express = require('express');
var application = express.createServer();

application.get('/', function(request, response) {
    response.send('Hello Express!!');
});

application.listen(2455);

Notice that this doesn’t differ that much from most Node.js “Hello World” examples out there. So if we point our browser to localhost:2455, then the expected text message appears on the page. Now let’s add some middleware into the mix.

Suppose we want to serve some static content like HTML, CSS and/or JavaScript files. We can simply accomplish that by adding the following line of code.

application.use(express.static(__dirname + '/public'));

Now we simply have to add a new folder named “public” to the root folder of our application. In this folder we add an HTML file named “index.html” with the following content:

<html>
    <head>
        <title>Index</title>
    </head>
    <body>
        <h1>Hello Express!!</h1>
    </body>
</html>

Now we have to point our browser to localhost:2455/index.html and our static HTML file is served by Express. That’s how easy we can add capabilities to our web application. Express provides you with several built-in middleware like the one we just used in the last example, but there are also several other open-source middleware in the npm repository to choose from.

Middleware is usually added in a callback function that we provide with the configure method of the application object.

application.configure(function() {
    application.use(express.static(__dirname + '/public'));
});

Express also provides the ability to configure middleware targeted for specific environments like development, staging, production, etc. … .

application.configure(function() {
    // Shared configuration
    application.use(express.bodyParser());
});

application.configure('development', function() {
    console.log('Configuring middleware for the development environment.');
    application.use(express.static(__dirname + '/public_on_development'));
});

application.configure('staging', function() {
    console.log('Configuring middleware for the staging environment.');
    application.use(express.static(__dirname + '/public_on_staging'));
});

application.configure('production', function() {
    console.log('Configuring middleware for the production environment.');
    application.use(express.static(__dirname + '/public'));
});

Note that we can still provide a separate configuration function for shared configurations between different environments. When we start our web application in the staging environment, we just have to provide the NODE_ENV environment variable.

NODE_ENV=staging nodemon app.js

Now only the global configure function and the one for the staging environment are called.

Express also provides an executable for generating boilerplate code and setting up a basic web application. This is probably the quickest way to get up and running with Express.

node_modules/express/bin$ ./express –h

Usage: express [options] [path]

Options:

  -s, –sessions                  add session support

  -t, –template <engine>  add template <engine> support (jade|ejs). default=jade

  -c, –css <engine>          add stylesheet <engine> support (stylus). default=plain css

  -v, –version                    output framework version

  -h, –help                        output help information

So when I run the express executable with the default options, I get the following output:

./express /home/my_user/my_sample_app

create : /home/my_user/my_sample_app

create : /home/my_user/my_sample_app/package.json

create : /home/my_user/my_sample_app/app.js

create : /home/my_user/my_sample_app/public

create : /home/my_user/my_sample_app/views

create : /home/my_user/my_sample_app/views/layout.jade

create : /home/my_user/my_sample_app/views/index.jade

create : /home/my_user/my_sample_app/routes

create : /home/my_user/my_sample_app/routes/index.js

create : /home/my_user/my_sample_app/public/javascripts

create : /home/my_user/my_sample_app/public/images

create : /home/my_user/my_sample_app/public/stylesheets

create : /home/my_user/my_sample_app/public/stylesheets/style.css

don’t forget to install dependencies:

$ cd /home/my_user/my_sample_app && npm install

A package.json file is created for dependent modules, along with a public folder for JavaScript files and CSS stylesheets and even separate folders for views and routes. This is how the generated app.js file looks like:  

/**
 * Module dependencies.
 */

var express = require('express')
  , routes = require('./routes')

var app = module.exports = express.createServer();

// Configuration

app.configure(function(){
  app.set('views', __dirname + '/views');
  app.set('view engine', 'jade');
  app.use(express.bodyParser());
  app.use(express.methodOverride());
  app.use(app.router);
  app.use(express.static(__dirname + '/public'));
});

app.configure('development', function(){
  app.use(express.errorHandler({ dumpExceptions: true, showStack: true }));
});

app.configure('production', function(){
  app.use(express.errorHandler());
});

// Routes

app.get('/', routes.index);

app.listen(3000);
console.log("Express server listening on port %d in %s mode",
       app.address().port,
       app.settings.env);

As you can see, it’s very easy to get started with Express and adding more capabilities to your web application as you go along. Make sure to watch this short screencast in order to get up and running in no time.

I’m planning to put out a couple more blog posts on Express and some very useful middleware that you can use for your applications. So stay tuned.

Until next time.

I just wanted to share a very neat feature of npm that makes life quite a lot easier when developing libraries for Node.js. Suppose that we’re building our very own ORM library for Node.js (we all build an ORM at some point in our career, right?). In order to have our dog food and eat it too, we want to start using our ORM library in an application as soon as possible. As with all other modules, we want to use npm in order to add it as a dependency of our application. But we also don’t want to publicly publish our half-baked ORM package to the npm repository either. This is where creating an npm link saves the day.

In the local folder of our library we have to create a link by issuing the following command:

~/kick-ass-orm$  npm link

After that we can add this package to the node-modules folder of our application by executing the following command:

~/facebook-killer$ npm link kick-ass-orm

There you have it. Notice that a new folder with the name of the package is added to the node_modules folder of the application. This is simply a symlink to the package folder of our ORM library. This means that when we make changes to this library, those changes are also exposed to our application as well.

As soon as we feel comfortable enough about our ORM library, we can make it publicly available in the npm repository. We can then simply remove the link from our application by issuing the following command:

~/facebook-killer$ npm unlink kick-ass-orm

At this point we add our freshly published package to the package.json file of our application. We can also remove the link from our local package folder by executing the following command:

~/kick-ass-orm$ npm unlink

This particular feature has been very useful to me over the last couple of weeks.

npm – is there anything it can’t do?

Until next time.

In a previous blog post, I already wrote about BDD style unit tests for testing Node.js modules using Jasmine. I really like the conciseness, simplicity and readability of specification style unit tests using Jasmine. But when we pour CoffeeScript into the mix, then the syntax for BDD style unit tests really starts to get interesting.

Here’s a simple example of a Jasmine test suite written in CoffeeScript:

{ BurglarAlarm, BurglarAlarmState } = require('burglaralarm')
ControlRoom = require('controlroom')
should = require('should')
sinon = require('sinon')

describe 'An armed burglar alarm', ->
    _sut = null

    beforeEach ->
        _sut = new BurglarAlarm()
        _sut.arm()

    describe 'When a break in occurs', ->
        beforeEach ->
            _sut.breakIn()

        it 'should indicate that there is a burglary', ->
            _sut.state().should.equal(BurglarAlarmState.alarm)

        it 'should trigger the siren', ->
            _sut.siren().isRinging().should.be.ok

    describe 'When there is being tampered', ->
        _mockedControlRoom = null

        beforeEach ->
            _mockedControlRoom = sinon.mock(ControlRoom.getInstance())
            _mockedControlRoom.expects('notifyTamperAlarm').once()

            _sut.tamper()

        afterEach ->
            _mockedControlRoom.restore()

        it 'should indicate that there is a tamper alarm', ->
            _sut.state().should.equal(BurglarAlarmState.tamper)

        it 'should notify the control room', ->
            _mockedControlRoom.verify()

Personally, I really like this syntax. Notice the destructuring assignment on the first line. This is a small trick we can use when a particular module exports multiple types. We also used a mocking library called Sinon.js which is a very powerful library for test spies, stubs and mocks for JavaScript.

Here’s the code for the BurglarAlarm, ControlRoom and Siren modules. Note that this example code is also written using CoffeeScript, but this can be plain old JavaScript as well if you want.

##############################################
# BurglarAlarm module
##############################################
BurglarAlarmState =
    normal: 0
    armed: 1
    alarm: 2
    tamper: 3

exports.BurglarAlarmState = BurglarAlarmState

class exports.BurglarAlarm
    _siren = null
    _state = BurglarAlarmState.normal

    constructor: ->
        _siren = new Siren()    

    siren: -> _siren
    state: -> _state

    arm: -> _state = BurglarAlarmState.armed

    breakIn: ->
        _state = BurglarAlarmState.alarm
        _siren.makeSomeNoise()    

    tamper: ->
        _state = BurglarAlarmState.tamper
        ControlRoom.getInstance().notifyTamperAlarm()

##############################################
# ControlRoom module
##############################################
class ControlRoom
    notifyTamperAlarm: ->
        console.log('Tamper alarm noticed in the control room ...')

instance = null

module.exports = {
    getInstance: ->
        unless instance?
            instance = new ControlRoom()
        instance
}

##############################################
# Siren module
##############################################
module.exports = class Siren
    ringing = false

    isRinging: -> ringing
    makeSomeNoise: -> ringing = true

There you go. Until next time.

Enjoy!

You probably figured out by now that you can’t afford to miss these two days of high quality learning, especially if you live in the European part of the world. If you live in Belgium or the Netherlands, you simply don’t have any valid excuse for not attending.

If you haven’t registered yet, be sure to do this in the upcoming week in order to get an early-bird discount. And in addition, I can even hook you up with an additional 50 Euro discount. Just drop me a line.

Hope to see you there. 

Pretty sure there’s lots of learning ahead of me

Humans are in fact feedback junkies. We constantly want to know how we’re doing what we’re doing. I actually wrote a blog post about this a couple of years ago.

Since I adopted TDD as a discipline, I tend to feel less pressured which results in me taking the time to continuously refactor the code I’m working on, trying to keep everything clean. Why? Because I known that the code I wrote a minute ago works. The tests I write constantly give me a shot of feedback so that I’m constantly hooked.

Just an observation …