Share the intellectual wealth

Introducing node-validation

noreply@blogger.com (Jan Van Ryswyck) — Fri, 03 May 2013 20:28:00 +0000

Some time ago I was looking for a validation library/module for use in a small Express application that I was writing at the time. I couldn’t find anything that suited my taste so I decided to write one myself just for kicks. The goal was learning how to publish a module to npm and making a futile attempt to contribute something back to the vibrant Node.js community. node-validation is a minimal but slightly opinionated validation library for Node.js.

Installing node-validation can be done using the canonical package manager:

$ npm install node-validation

Validation rules must be defined in a custom validator by deriving from the base Validator.

var MyObjectValidator = function() {
    Validator.call(this);

    this.ruleFor('stringProperty').isNotEmpty();
    this.ruleFor('otherStringProperty').hasMaximumLength(10);

    this.ruleFor('numericStringProperty').isNumber()
        .withMessage('Oops, something is wrong ...');
    this.ruleFor('dateStringProperty')
        .matches(/^(19|20)\d\d[-](0[1-9]|1[012])[-](0[1-9]|[12][0-9]|3[01])$/);

    this.ruleFor('numberProperty').isInteger();
    this.ruleFor('otherNumberProperty').isMaximum(5);

    this.ruleFor('exoticProperty').is(function(value) {
        return 3 === value.propertyA + value.propertyB;
    }).withMessage('Either propertyA or propertyB has an incorrect value.');
};

util.inherits(MyObjectValidator, Validator);

After creating a validator object, an object that needs to be validated (the subject) can be passed to the validate method. The validate method returns an array of validation errors specifying a message and the name of the violating property.

//
// Validation subject
//
var subject = {
    stringProperty: '',
    otherStringProperty: 'Some string value that is too long ...',

    numericStringProperty: '65.85 invalid',
    dateStringProperty: '2013-04-30 invalid',

    numberProperty: 'Some invalid number',
    otherNumberProperty: 48,

    exoticProperty: {
        propertyA: 1,
        propertyB: 1
    }
};

//
// Now it's time to validate
//
var validator = new MyObjectValidator();
var validationErrors = validator.validate(subject);

for(var i=0; i < validationErrors.length; i++) {
    console.log('Property name: ' + validationErrors[i].propertyName 
                + ', Message: ' + validationErrors[i].message);
}

There you go. Head over to the GitHub repository and give it a try. I’m definitely looking forward to hear your feedback.

Basic JavaScript: Prototypical Inheritance vs. Functional Inheritance

noreply@blogger.com (Jan Van Ryswyck) — Fri, 22 Mar 2013 22:16:00 +0000

Inheritance in JavaScript has been the topic of many discussions in the past and will continue to be the source of future debates and arguments. While we do value composition over inheritance, we don’t want to throw the baby out with the bathwater either. So, from time to time, we run into these cases where we want some notion of inheritance in JavaScript. Now what?

As with many things in JavaScript, there is not a single straight answer. We can choose between a couple of options and many different variations of these solutions. But one thing’s for sure: we can’t have it all!

In this blog post I want to discuss two different styles of inheritance that I have a hard time choosing from when programming JavaScript. And as with everything in life, both styles have their own pros and cons.

Prototypical inheritance

In ‘classical’ programming languages, one class can directly inherit from another class. JavaScript doesn’t have this notion of classes (yet). Instead, JavaScript has prototypes which you can augment to fit your own needs. This means that having a single augmented object as the prototype for other objects, which ‘inherit’ all members of the augmented prototype object, kind of simulates a pseudo-classical inheritance pattern. Let’s talk code in order to demystify this concept.

// validator.js
var Validator = exports.Validator = function() {
    this._rules = [];
};

Validator.prototype.addRule = function(rule) {
    this._rules.push(rule)
};

Validator.prototype.validate = function(instance) {
    ...
};

// specificValidator.js
var util = require('util');

var SpecificValidator = function() {
    Validator.call(this);
};

util.inherits(SpecificValidator, Validator);

SpecificValidator.prototype.filter = function(instance) {
    ...
};

// client.js
var validator = new SpecificValidator();

// Calls function on derived object
validator.filter( { ... } );        

// Calls function on base object
validator.validate( { ... } );

Here we have a constructor function named Validator which is the base object for other ‘derived’ objects. We augment the prototype with two functions (addRule and validate). Next we define another constructor function named SpecificValidator. We ‘derive’ this new constructor function by calling the base constructor function and wiring the prototype by using the util.inherits() function from the Node.js core library.

We have to use the new keyword in order to instantiate a SpecificValidator object. Now we can use the functions that we added to the prototype.

Functional inheritance

This pattern is advocated by Douglas Crockford in his book JavaScript, The Good Parts. There he offers this particular style as the way to go for inheriting objects. Let’s look at an example.

// validator.js
module.exports = function() {
    var rules = [], my = {};

    my.addRule = function(rule) {
        rules.push(rule);
    };

    my.validate = function(instance) {
        ...
    };

    return my;
};

// specificValidator.js
var validator = require('...').validator;

var specificValidator = function() {
    var my = validator();

    my.filter = function(instance) {
        ...
    };
    
    return my;
};

// client.js
var validator = specificValidator();

// Calls function on derived object
validator.filter( { ... } );    

// Calls function on base object
validator.validate( { ... } );

The base constructor function returns an object that is augmented with functions and is returned at the end. The derived constructor function simple calls the base constructor function and further augments the retrieved object before returning it to the calling code. Here we don’t have to use the new keyword to instantiate anything. Just calling the right constructor function gives us an object which we can use in our client code.

Conclusion

The most important benefit of prototypical inheritance, at least in my humble opinion, is performance. By augmenting the prototype with functions, we only create these functions once. Not matter how many times we instantiate a constructor function, the same functions get (re)used every single time. Functional inheritance on the other hand creates new functions every time a constructor function is called, which is several orders of magnitude slower compared to the prototypical inheritance pattern.

On the other hand, the prototypical approach doesn’t come with encapsulation. Looking at the example shown earlier, the ‘_rules’ property is publicly available to the client code and can be manipulated at will. By using a simple convention, like prefixing with an underscore, we can indicate that these private members should not be touched in order to guarantee a correct behavior. But again, nothing can be enforced. Using functional constructors, we can have private variables and functions that cannot be manipulated by the calling code.

There are more pros and cons, but for me, these are the most important ones to be aware of. You can see that both styles have their strengths and weaknesses. I usually tend to go with prototypical inheritance as this is the ‘JavaScript way’, but I like using the functional approach as well for those cases were I know in advance that not too many objects are created or when I don’t care about performance.

I would love to hear other takes on this. What particular styles do you use? When do you use them and why?

Until next time.

Confessions of a Sublime Text-aholic

noreply@blogger.com (Jan Van Ryswyck) — Fri, 22 Feb 2013 20:46:00 +0000

It’s true. I’m a Sublime Text addict. It’s by far my favorite development tool. End of story!

Just to illustrate, earlier this week, a member of our development team asked how to quickly remove all empty lines from a very large text file. I quickly came up with the following:

Press CTRL-F.
Enable regular expressions (the button entirely in the bottom-left corner).
Search for ^\s*$
Press ALT-ENTER (click on the “Find all” button).
Hit the backspace button.
Done!
Be merry …

Don’t just take my word for it. Just start using it!

Writing Fast, Memory-Efficient JavaScript

noreply@blogger.com (Jan Van Ryswyck) — Fri, 08 Feb 2013 19:45:00 +0000

Earlier this week, I read this great article titled “Writing Fast, Memory-Efficient JavaScript” by Addy Osmani. This is a highly recommended read for anyone involved in writing JavaScript code.

The topics that I found to be particularly interesting were the apparent fact that it’s better to avoid the delete keyword and cached functions in the module pattern. The major down-side that I see when using cached functions is that you can’t have any private variables within your module. But this is highly interesting stuff, nonetheless.

Taking Toddler Steps with Node.js - Express Routing Revisited

noreply@blogger.com (Jan Van Ryswyck) — Fri, 01 Feb 2013 21:25:00 +0000

Last year I wrote this blog post where I described a couple of ways on how to tackle routing with Express. In the mean while I moved on from the “Plain Old School” approach to an approach where I replaced underscore.js with node-require-directory.

Setting up node-require-directory is quite easy. In the routes folder, we just need to add an index.js module with the following two lines:

var requireDirectory = require('require-directory');
module.exports = requireDirectory(module);

Setting up the routes for Express then looks like this:

var routes = require('./../routes');

// Setting up an application ...

application.get('/', routes.root);
application.get('/home', routes.home);
application.get('/signin', routes.authentication.signin);
application.post('/signout', routes.authentication.signout);

// More route registrations

Here we simple reference the index.js module. The node-require-directory module takes care of building up a tree of functions which we can now access for our route registrations. Adding a new route is as simple as creating a new module somewhere inside the routes folder or one of its subfolders and creating a new route registration. Have a look at this example.

I found this little gem to be quite useful and it might be helpful for some of you as well.

Until next time.

Visual Studio Light Edition

noreply@blogger.com (Jan Van Ryswyck) — Fri, 30 Nov 2012 21:10:00 +0000

I noticed this blog post from Scott Hanselman the other day about Visual Studio Express 2012 for Windows Desktop. This post included a screenshot from the installation program. Something that really took me by the throat is this:

Notice that the Express edition of Visual Studio seems to require no less than 4.15 GB of hard disk space! So I decided to try out the Professional edition of Visual Studio just to find out that it needs 7.56 GB to install!

Ask yourself, how on earth can an IDE that requires 7.56 GB to install be fast enough to even be usable at all? What kind of monster machine is required to not even choke to death when I accidentally open a second instance of Visual Studio? We've all seen those dreadful white screens of death, right?

Yes, I know that we're living in 2012 and that disk space is very cheap. Yes, I know that RAM memory grow on trees these days and that CPU power is growing increasingly. But is this kind of footprint justified for an IDE that proclaims productivity? Or is it just me?

After recovering from my amazement I tried installing SharpDevelop, an open-source IDE for building .NET applications.

SharpDevelop seems to be more than happy with just a mere 64 Mb of storage. I tried opening a large solution and it loads pretty darn fast. So, I should just shut up and go with SharpDevelop then? See, this is where I have to admit that I have a slight problem.

See, I depend heavily on Resharper for doing C# development. This amazing code-by-keystrokes tool is both a blessing and a curse. Any serious developer who builds .NET applications has to admit that whipping up some C# code without a tool like Resharper is incredibly painful, to say the least. This tool is truly a blessing and this is why I can't go with SharpDevelop as my IDE of choice when building application for the .NET platform. But on the other hand, Resharper is not a stand-alone tool as it needs Visual Studio to host it. To me, this is a curse.

Visual Studio 2012 in it's current form has become too heavily packed with features, which I don't use anyway, so that's it's no longer usable for me to host Resharper. I'm no longer willing to make that tradeoff. I tried using Visual Studio 2012 with Resharper, but I turned back to Visual Studio 2010 after a short while. From a performance point of view, Visual Studio 2010 isn't running great either. So I guess this is just a necessary evil that I have to overcome for building .NET 4.0 applications.

I understand that Microsoft's business model is building platforms and tools for the world to use. It's a business like any other business, focused on earning money. There's nothing wrong with that. This is why Anders is so keen on statically typed languages, because they require more tooling and tooling is what brings in the money for his division. It's as simple as that.

But it doesn't have to be all bad! What if the Visual Studio development team would come up with a stripped down version of Visual Studio? Think about how awesome this could be. What should be in the box? Just the basics! The code editor, the solution explorer, the debugger and the ability to host add-ons. No designers, no SQL Server integration, no TFS integration, etc. … Just the most basic features. That's it! The installation footprint should be no more than 500 Mb, ideally only 100Mb. Wouldn’t that be awesome? This would be would actually solve my current development needs!

I hereby tag my fellow Elegant Coder David Starr, who recently joined the Visual Studio team at Microsoft. You can do it David! The best is yet to come!

So I'm eagerly awaiting the next release cycle of Visual Studio in order to see whether I'm up for a treat ;-).

Until next time.

Steve Jobs - The Biography by Walter Isaacson

noreply@blogger.com (Jan Van Ryswyck) — Tue, 07 Aug 2012 10:00:00 +0000

At first I was a bit skeptical whether I should spend time listening to the audio version of this book. I’ve heard and read both great things as well as bad things about the book. A few people recommended it, while a couple of others discouraged me from reading it. But after getting through only a few chapters I was completely hooked.

The book tells the life story of Steve Jobs from birth until his sad passing, describing the important moments of his life in a very open and honest way.

The part that I personally found the most interesting were the early years of Apple. There’s a lot of computer history in there that stems from when I was just an infant. These fascinating stories alone, like how the Mac and the IBM PC were rubbing shoulders, makes the book worthwhile. I’ve actually learned a lot from this book, especially about the events from the past that made Apple the company that it is today.

I never really considered myself an Apple fan. Heck, I don’t even follow what they are announcing at their conferences or events. I usually read about it days after in the newspapers. But while I was reading the book, I started noticing all the Apple devices that me and my family are using on a day-to-day basis. When did that happen? Did they sneak up on me or what? When I told my wife about this, she told me that I start rambling about replacing my three year old desktop with an iMac every time we walk by an Apple store or a retailer. Wow! This certainly didn’t help either. Perhaps it’s inevitable, I don’t know.

But what I do know is that I really enjoy using their devices (iPod, iPad, MacBook Pro, etc. …) and now I learned about the rationale behind it. And the scary part was that it all made sense as well.

This book tells the remarkable story of a passionate individual with a firm vision that will be remembered for many generations to come. If you’re a technologist, you just owe it to yourself to pick up a copy and read it.

Now I’m off reading a book on Bill Gates .

Until next time.

Blitz

noreply@blogger.com (Jan Van Ryswyck) — Tue, 24 Jul 2012 10:00:00 +0000

The last couple of weeks I’ve been playing with a load testing tool called Blitz. You can create a free account which provides you the ability to ‘rush’ your web application with 250 concurrent users (or less) for 1 minute. And of course, you can increase both the number of concurrent users as well as the duration of the load tests after you specify a credit card number.

The interface is pretty slick, as it provides you with a kind of command line interface.

Here I specified to run a load test, increasing the number of concurrent users from 1 to 12 over a period of one minute. The test is going to run from their datacenter in Ireland. You can choose from a couple of places in the US as well.

This command yields the following results.

Blitz also integrates with web application performance tools like New Relic which enables you to further analyze the results and see what’s going on in your web application.

This is actually the first time ever that I had so much fun doing load tests .

Until next time.

Outliers – The Story of Success

noreply@blogger.com (Jan Van Ryswyck) — Tue, 17 Jul 2012 10:00:00 +0000

A couple of weeks ago, I digested the audio version of Outliers – The Story of Success, written by Malcolm Gladwell. In this book, the author tells the story of a couple well-known and also lesser-known individuals that are considered to be successful. But what’s particularly interesting about this book, is the analysis the author makes to uncover the exact reason(s) that make these talented people stand out from the masses.

There seem to be several factors at play. Apparently, being talented isn’t enough on its own (duh). Getting opportunities and taking them, hard work (the famous 10.000 hour rule) and perseverance are just a couple of reasons that pop up regularly throughout the book. But more stunningly are reasons like the month of the year that some of the people discussed are born to even the particular year itself. The author claims that this is the very reason why early geeks like Bill Gates, Steve Jobs, Paul Allen, Bill Joy, etc. … were so successful. The very year that these guys were born turned out to be a major part of their success.

Interested? Check out this page on Wikipedia that is devoted to this fascinating book. Make sure to pick up a copy. You won’t regret it!

Until next time.

My Developers Life–The Social Media Diet

noreply@blogger.com (Jan Van Ryswyck) — Tue, 03 Jul 2012 10:00:00 +0000

In the previous blog posts I discussed the importance of getting enough sleep and physical exercise. For this post I want to provide a quick shout out of the social media diet that I’m currently trying out.

My name is Jan and I don’t have a Facebook or a Netlog account of some kind. I do have a Google+ account that I haven’t visited in like four months. I also have a Twitter account that I’ve used quite often in the past. Currently I’m checking my Twitter account no more than two times a day for only a couple of minutes. Quite often I don’t visit it at all. Why? Because I let it all go.

I did not gain as much free time as I initially anticipated. But what I did gain was my ability to focus on stuff that I kept postponing for some time and more efficiency while doing it. Looking back, my brain feels less flooded and I no longer have that nagging urge that I’m missing out on information that is not really that important in the first place.

Don’t get me wrong here. I’m not entirely condemning social media either. I do get some value out of it, at the very least some entertainment only when I’m open for it. But I just let myself take some benefit from social media in the most superficial way as I possible can without getting too much involved. That way I’m able to pick up or learn something new without feeling like an informationholic.

I no longer have a Twitter client constantly running in the background. I also disabled all other kinds of notifications popping up like e-mail, … etc. And I must say that it works like a charm.

Close your browser or social media client and get out there! Exercise. Read a book. Learn a new programming language. Play with your kids. Listen to some music. Garden. Anything. No one on his dead bed ever said, “I wish I had wasted more time using social media”. Don’t be afraid to miss out on that one tweet or message, because you’re probably already lost track of what’s really important.

Until next time.

My Developers Life - The Importance of Physical Exercise

noreply@blogger.com (Jan Van Ryswyck) — Tue, 12 Jun 2012 10:00:00 +0000

In the previous blog post, I discussed the importance of getting enough sleep every single night. For this post I want to emphasize the importance of physical exercise. I’m writing these words after having run approximately 15 kilometers. This I do three times a week, every week, throughout the whole year with only a few exceptions. And the reason for this is pretty obvious. Since I started running back in 2007, I never felt better.

As software developers, we basically sit at a desk whole day churning out code. The only form of physical movement we get is when we drag our bodies to the coffee machine, the water cooler or the vending machine when we want to get a snack. This means that we don’t get to burn as much calories as other people who have professions that involve more physical labor. For some of us, this is one of the many reasons why we chose this profession in the first place. I know I did ;-). Unfortunately, our text editor skills don’t cause us to burn any calories. What a bummer!

During my childhood, I practiced several sports like soccer and judo. But when I started going to graduate school this all stopped. I slowly gained weight over the years. I didn’t have any physical exercise for about fifteen years. But at some point, around September 2007, I just bought myself some running shoes and started running short distances twice a week. Since then, I stopped making excuses for myself and improved my physical shape and my overall health. I learned so many valuable lessons, which led me to write this blog post.

In hindsight, I can’t even remember what the actual tipping point was for me. What I do know is that this has been one of the best decisions I have ever made in my life. How do I keep this up? Quite frankly, this has always been the easy part. I started out by reserving 20 minutes in my agenda twice a week. I made some decent arrangements with my spouse and family about how and when. After settling on the best time frame, I treated these “appointments with myself” as non-negotiable. Now I reserve 1 hour and thirty minutes three times a week. I try to schedule all other appointments around these blocks of time. Again, have a good talk with your family and try to come up with the best possible time frame. I can’t emphasize this enough.

I can only encourage everyone who spends his days behind a desk to get some physical exercise at least every two days. Try choosing a sport that you actually like but also make sure that there is a low barrier of entry. This way you can get up and running in not time, and I mean that quite literally :-). You can also start out with some small and simple habits like taking the bike instead of the car for short distances, or taking the stairs instead of the elevator, etc. … and pick up on some more physical exercise along the way.

A professional software developer not only takes care of writing good code, but also takes care of himself.

Until next time and happy exercising!

My Developers Life - The Importance of Sleep

noreply@blogger.com (Jan Van Ryswyck) — Tue, 29 May 2012 10:00:00 +0000

When I was reading Just for Fun, I came across this paragraph in the book where Linus Torvalds stated that he never missed a good night’s sleep during the early days when he was hacking together the first version of the Linux kernel. In fact, he clearly stated in his book that he doesn’t allow his pet project to come between him and a minimum of eight hours of sleep each night.

Let’s think about this for a moment.

Here’s this guy who wrote an insane amount of complex code without pulling all night death marches. After I read that passage, I couldn’t help but reflect on my own behavior. I’ve been working on countless little pet projects over the past couple of years, often churning out code until 3 or 4 o’clock in the morning during the weekends or holidays. This made me realize that I needed to do something about it. And you know what the stupid part was? I had the right habits all along!

Those who know me know that I start my working days quite early. I usually arrive at the office around 7 o’clock in the morning, getting a fresh and quiet head start of my day. This implies that I go to sleep very early as well on working days, trying to get as much sleep as I possibly can every night.

So, now that I realized that I already had the right behaviors in place, the only thing that I needed to do was to extend this behavior to the weekends and holidays. And I must say that it works great! I instantly stopped hacking on code during the night and now I go to sleep early every day. I also get up early every single day which makes me feel more productive, more efficient and definitely more focused. After doing this for a couple of weeks, I could only come to the conclusion that I felt much better overall.

However, I’m still not entirely there yet. There are some nights that I don’t get to have a full eight hours of sleep, mostly on working days. This is something that I still need to work on, so I create the right habits in order to achieve this goal.

No more sleep deprivation for me. Everyone knows that working more than 8 hours a day is madness. Well, the same goes for writing code after midnight. I came to realize that a good night’s sleep is probably one of the most important tools you have as a developer. A well rested brain is more useful than a tired and a sleepy one.

I encourage you to try this for two weeks and reflect on your mood, productivity and your general well being.

Until next time and good night!

Taking Toddler Steps with Node.js – Passport

noreply@blogger.com (Jan Van Ryswyck) — Tue, 15 May 2012 10:00:00 +0000

Recently I added Twitter authentication to TrackMyRun using a library called Passport. I was pretty impressed how smooth this all went as I completely neglected all security concerns from the get go, which is definitely not recommended by the way. For this post I’ll walk you through the process of setting up Passport for Express using Twitter OAuth authentication.

Passport is actually the core library which provides support for OpenId and OAuth authentication. Instead of being one single monolithic library, Passport uses strategies that support authentication directly with specific OpenId/OAuth providers.

So in order to get up and running, we need to install passport as well as passport-twitter for Twitter OAuth authentication. After we install these modules using npm, we can start by configuring the Twitter strategy.

var express = require('express'),
    passport = require('passport'),
    TwitterStrategy = require('passport-twitter').Strategy;

var users = [];

passport.use(new TwitterStrategy({
        consumerKey: 'twitter-app-consumer-key',
        consumerSecret: 'twitter-app-consumer-secret',
        callbackURL: "http://test.passport-twitter.com:3000/auth/twitter/callback"
    },
    function(token, tokenSecret, profile, done) {
        var user = users[profile.id] || 
                   (users[profile.id] = { id: profile.id, name: profile.username });
        done(null, user);
    }
));

The strategy must be configured by providing the consumer key and consumer secret as well as the callback URL. I’m not going too much in depth on how OAuth works. Make sure to check out the Twitter for developers website on how to configure an application that uses the Twitter API.

Besides adding the strategy for Twitter, we also specified a callback function. In this callback, we’re supposed to find and verify a user that matches a specified set of credentials. Usually we have some code here that checks to see if the specified user exists in a database of some sort. In order not to clutter this example, I used a simple array here instead.

If we can find the requested user in our data store, we need to invoke done() to supply the Passport with the user.

done(null, user);

When the user cannot be found, we can simply pass false instead of a user object.

done(null, false);

In our example we always ensure that the specified credentials match a particular user object. Next we need to configure the Passport middleware for initialization and session management.

application.configure(function() {
    application.use(express.bodyParser());
    application.use(express.methodOverride());
    application.use(express.cookieParser());
    application.use(express.session( { secret: '498f99f3bbee4ae3a075eada02488464' } ));
    application.use(passport.initialize());
    application.use(passport.session());
    application.use(application.router);
    application.use(express.errorHandler({ showStack: true, dumpExceptions: true }));
    application.set('view engine', 'jade');
});

Please note that the express.session() middleware needs be called before passport.session(). Next we add the routes necessary for authenticating requests and handling the token callback.

application.get('/auth/twitter', passport.authenticate('twitter'));

application.get('/auth/twitter/callback', 
    passport.authenticate('twitter', 
        { successRedirect: '/', 
          failureRedirect: '/auth/twitter' }));

Last but not least we also need to declare a serializeUser/deserializeUser callback function. These are necessary for supporting login sessions.

passport.serializeUser(function(user, done) {
    done(null, user.id);
});

passport.deserializeUser(function(id, done) {
    var user = users[id];
    done(null, user);
});

Instead of reading the requested user objects from the data store, we simply use the array that we incorporated earlier.

That’s basically the thing. We can add other authentication providers by simply configuring more strategies. Have a look at the full source code of this example and try to get it up and running.

Until next time.

Taking Toddler Steps with Node.js - Express Error Handling

noreply@blogger.com (Jan Van Ryswyck) — Fri, 06 Apr 2012 20:35:00 +0000

In the previous post I wrote about my personal routing flavor for Express. For this post, I want to briefly discuss how to set up error handling using Express.

In order to get up and going very quickly, we only need to add the errorHandler middleware provided by Connect.

application.use(express.errorHandler({ showStack: true, dumpExceptions: true }));

Here we configured the errorHandler middleware to report on exceptions and show the stack trace as well. This is quite handy during development as this setup provides us with enough detail.

But this is not very effective when we want to move our application to a production environment. When deployed into production, we usually want to show a user-friendly message instead of technical details, stack traces and what not. In this case we can use the application.error() method. This function receives all errors thrown by the regular route functions or errors passed to the next() function. In this catch-all-errors function we can simply render our own custom view.

application.error(function(error, request, response, next) {
    response.render('500', {
        status: 500,
        error: util.inspect(error),
        showDetails: application.settings.showErrorDetails
    });
});

This is how our custom error page looks like:

We can also use the application.error() function for rendering custom pages for all kinds of specific errors. Suppose we want to render a custom page for ‘404 – Page Not Found’ errors. Quite easy. We just need to register a catch-all route after all the regular route functions that simply throws a custom error.

function PageNotFoundError(message){
  this.name = 'PageNotFoundError';
  Error.call(this, message);
  Error.captureStackTrace(this, arguments.callee);
}

PageNotFoundError.prototype.__proto__ = Error.prototype;

application.use(function(request, response, next) {
    next(new PageNotFoundError())        
});

Next we need to enhance application.error() function so that it appropriately handles our PageNotFoundError.

application.error(function(error, request, response, next) {
    if (typeof error === typeof PageNotFoundError) {
      response.render('404', {
        status: 404
      });
    } 
    else {
        response.render('500', {
            status: 500,
            error: util.inspect(error),
            showDetails: application.settings.showErrorDetails
        });
    }
});

As you can see, error handling is quite easy to setup for different environments using Express.

Until next time.

Taking Toddler Steps with Node.js - Thou Shalt Not Deny Asynchrony

noreply@blogger.com (Jan Van Ryswyck) — Tue, 27 Mar 2012 11:00:00 +0000

A few of weeks ago, I ran into this awesome article “Understanding process.nextTick()” on the How To Node blog. In this article, the ever friendly Kishore Nallan shows a couple of common use cases for the process.nextTick() function of the core Node.js library. You should read this blog post three times, at the very least.

What I found to be particularly interesting at the time was the part on how to keep callbacks truly asynchronous. I admit that this is something that I’ve been struggling with for a while. At first I thought this was not a big deal, but this can become quite troublesome in your applications if you’re not careful.

Let’s look at some code.

var fileSystem = require('fs');

module.exports = (function() {
    function Configuration() {}
    Configuration.settings = null;

    Configuration.getSettings = function(callback) {
        var self = this;
        if(this.settings) {
            return callback(null, self.settings);
        }

        fileSystem.readFile(__dirname + '/config.json', 'utf8', 
            function(error, data) {
                var self = this;
                if(error) {
                    return callback(error);
                }

                this.settings = JSON.parse(data);
                return callback(null, self.settings);
        });
    };

    return Configuration;
})();

Here we’re looking at a simple module that exposes a single function named getSettings. When called for the first time, this function reads the content of a JSON file and stores the result in a static property. For all successive function calls, we simply serve the object stored in the static property without reading the JSON file again. This all looks very simple and everything works great. But this code is also highly inconsistent!

Let’s have a closer look.

When reading the content of the JSON file, we invoke the callback, specified as a parameter to getSettings, inside another callback (the anonymous function specified to the readFile function). This means that the invocation of the specified callback is asynchronous because the callback of the readFile function is also asynchronous. Nothing wrong here.

When calling the getSettings function a second time, we instantly invoke the specified callback with the object stored in the static variable. This means that the callback is executed synchronously. From the perspective of the client of our module, this is inconsistent behavior. The callback specified by the client code is executed asynchronously on the first call while it is executed synchronously on all successive calls.

In order to fix this inconsistent behavior, we can use the process.nextTick() function which defers the execution of our callback until the next iteration of the event loop.

Let’s have a look at the code that fixes this issue:

if(this.settings) {
    return process.nextTick(function() {
        return callback(null, self.settings);
    });
}

This is something that you need to think about when invoking callback functions.

Until next time.

Taking Toddler Steps with Node.js - Npm Police

noreply@blogger.com (Jan Van Ryswyck) — Fri, 23 Mar 2012 21:38:00 +0000

Earlier this week, I ran across this incredibly helpful utility called npm-police. It analyzes all packages that are specified in a package.json file and reports which packages need to be updated. It also leaves you with a couple of suggestions on how to improve the content of the analyzed package.json file.

Another great tool in our toolbox.

Book Review: Just for Fun

noreply@blogger.com (Jan Van Ryswyck) — Tue, 28 Feb 2012 11:00:00 +0000

A while ago, my colleague Wouter recommended this book titled Just for Fun – The Story of an Accidental Revolutionary written by Linus Torvalds. The author needs no further introduction as he’s well known as the initiator of the Linux kernel and the most excellent Git revision control system. I immediately ordered myself a copy of this book and finished reading it last weekend. I must admit that this was quite a fascinating read. The writing style is very entertaining and just plain witty at times.

The book consists of three major parts. The first part, titled “Birth of a Nerd”, describes the early life of the author in his home country Finland, how he got introduced to computers by his grandfather, etc. … .

The second part, titled “Birth of an Operating System”, is probably the most interesting part for us geeks. Here Linus describes how he started hacking on software while he was at university. At first he started working on a terminal emulator for Minix in order to learn about the x386 CPU instruction set for the PC he bought. This terminal emulator later grown into the first version of the Linux kernel after he implemented more and more Unix system functions. He further elaborates how these humble beginnings further evolved into the Linux operating system as we know it today. Truly an amazing story!

The last part of the book, titled “King of the ball”, discusses some varying topics like intellectual property, why open-source software makes sense and even the meaning of life. This section contains some very interesting perspectives regarding these topics.

In conclusion, I very much liked reading this book. It’s a fast and easy read and you don’t even have to be a geek to make sense of this great story. This book is definitely obligatory reading for everyone who’s even slightly involved with open-source software.

Two thumbs up!!

Book Review: The Unix Programming Environment

noreply@blogger.com (Jan Van Ryswyck) — Wed, 22 Feb 2012 11:00:00 +0000

A couple of weeks ago I finished reading The Unix Programming Environment, written by Brian W. Kernighan and Rob Pike. The main reason that I picked up this classic book was to learn more about the fundamentals of Unix. I must say that this book is an excellent guide to start learning more about this widespread operating system.

Ever since I started my programming career, I had this on and off relationship with Linux. There were times that I wanted to turn my back on Windows entirely and make the jump. Then there were also times that I couldn’t care less about Linux. But when I started playing with CouchDB and especially Node.js, this fascination for the other side has been growing steadily. In fact, I kind of made a small jump already. All of the code that I’ve developed during my spare time for the past 14 months have been hacked together on a Linux VM.

I don’t want you to fall into the impression that Windows is a bad operating system either, quite on the contrary. I’ve been doing professional software development on Windows for more than 12 years now and I still believe that it’s a rock solid operating system. Why am I not solely sticking to software development on Windows then? Well, for the simple reason that I’ve always had this nagging feeling that I’ve been missing out by not learning equally as much about Linux as I learned the past 12 years about Windows. So I kind of suspect that I’ll be running Windows in a VM on a Linux host in the not too distant future. I’m quite fascinated and determined to find my way in this mostly unknown environment.

Anyway, back to the book. There are basically two major parts in this book. The first part deals with the basics, the file system, the shell and an introduction to sed & awk. The second part discusses more advanced topics like shell programming, programming standard I/O and Unix system calls which I skipped entirely (for now). By completely focusing on the first part, I learned quite some stuff and also relearned a few things from the past.

The only thing that bothered me about this book is that its quite boring. The book was originally published in 1984. Perhaps authors of technical books from back then were not supposed to have an entertaining writing style. I’m not sure. I was probably too busy playing with Legos at the time to notice ;-).

I now realize that I have quite a long journey ahead of me. Good thing that I started this path sooner than later.

Until next time.

PS: I recently switched from Shelfari to GoodReads and I’m quite liking it so far. Just let me know if you have some interesting books to share.

View Collation in CouchDB

noreply@blogger.com (Jan Van Ryswyck) — Tue, 14 Feb 2012 11:00:00 +0000

A couple of weeks ago I learned about a very neat feature of CouchDB called view collations. Basically, view collations enables us to make joins between documents. Let’s look at a simple example here.

Suppose we have a customer-order model where a customer can have one or more orders. The data of the documents for our example looks like this:

{
   "_id": "807023fe77d927e1c222adfe4a0007ba",
   "_rev": "2-2eae48beb08acc72ed2ab64ccfbcb1c7",
   "type": "customer",
   "firstName": "Homer",
   "lastName": "Simpson"
}

{
   "_id": "807023fe77d927e1c222adfe4a0013c2",
   "_rev": "2-9fc81f3b250c514fbd7e1d5f4a44816b",
   "type": "order",
   "amount": 34,
   "customer": "807023fe77d927e1c222adfe4a0007ba"
}

{
   "_id": "807023fe77d927e1c222adfe4a001b53",
   "_rev": "2-9dbf739124353363d53d1ba6671aac4e",
   "type": "order",
   "amount": 58,
   "customer": "807023fe77d927e1c222adfe4a0007ba"
}

{
   "_id": "807023fe77d927e1c222adfe4a002516",
   "_rev": "1-5cb6d3729618eb7db0f9285237fd8308",
   "firstName": "Ned",
   "lastName": "Flanders",
   "type": "customer"
}

{
   "_id": "807023fe77d927e1c222adfe4a002a4f",
   "_rev": "1-cc5eb0d8c6db0f698c53f9078d16db3b",
   "type": "order",
   "amount": 75,
   "customer": "807023fe77d927e1c222adfe4a002516"
}

Here we have two customers with their respective orders. The first customer has two orders and the second customer has only one order. Notice that the documents for the orders each have an attribute that contains the ID of the corresponding customer document.

The final goal is that we want to retrieve all customers with their corresponding orders using a single view. In order to accomplish this we have to make use of complex keys in our map function:

function(document) {
  if(document.type == 'customer') {
    emit([document._id, 0], document);
  }
  else if(document.type == 'order') {
    emit([document.customer, 1], document);
  } 
}

The key is composed of the ID of a customer and an arbitrary number used for sorting (collating). For this number we’ve used 0 for customer documents and 1 for order documents. Because the orders will also be sorted by customer ID and their sorting number is higher than the equivalent number for customer documents, the order documents for a particular customer will always come after the customer document itself. This is how the output of the view looks like:

Here we see the first customer and his respective orders, followed by the second customer and his single order. This way we can have our cake and eat it too.

We can use extra filters as well. Suppose that we want to retrieve the data and all the associated orders for one specific customer, we can easily use the startkey/endkey query options in order to get a subset of the view rows:

?startkey=["807023fe77d927e1c222adfe4a0007ba"]&endkey=["807023fe77d927e1c222adfe4a0007ba", 2]

Using this technique can be quite useful for a couple of scenarios. Being able to make use of the sorting features for complex keys is actually quite nice.

Until next time

Introducing TrackMyRun

noreply@blogger.com (Jan Van Ryswyck) — Tue, 24 Jan 2012 11:00:00 +0000

I’ve been working on a small pet project for a couple of weeks now, which I named TrackMyRun. I’m quite fanatic when it comes to running, doing about 130 runs a year. Currently I’m keeping track of all these runs in a simple spreadsheet, but off course, that’s certainly not “the geek way”. Hence the start of yet another pet project.

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!

Taking Toddler Steps with Node.js - Express Routing

noreply@blogger.com (Jan Van Ryswyck) — Sat, 21 Jan 2012 00:17:00 +0000

In the previous post I provided a short introduction to Express, a web development framework built on top of connect that is heavily inspired by Sinatra. For this post we’ll dive into a couple of styles for dealing with routes in Express.

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.

Retrospective of 2011, Looking Ahead to 2012

noreply@blogger.com (Jan Van Ryswyck) — Fri, 30 Dec 2011 20:44:00 +0000

Yep, that time of the year again. Shiny new calendars and the accompanying festivities are upon us again. I can’t get rid of the feeling that every year passes by a lot faster than the year before. This year was definitely not an exception in that regard and I’m afraid that things are not going to improve in 2012.

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.

Taking Toddler Steps with Node.js – Express

noreply@blogger.com (Jan Van Ryswyck) — Fri, 23 Dec 2011 23:12:00 +0000

< The list of previous installments can be found here. >

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.

Taking Baby Steps with Node.js – Linking Local Packages with npm

noreply@blogger.com (Jan Van Ryswyck) — Fri, 16 Dec 2011 21:10:00 +0000

< The list of previous installments can be found here. >

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.

Taking Baby Steps with Node.js – BDD Style Unit Tests with Jasmine and CoffeeScript

noreply@blogger.com (Jan Van Ryswyck) — Tue, 18 Oct 2011 10:00:00 +0000

< The list of previous installments can be found here. >

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.