Introducing node-validation

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

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

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:

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

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

Writing Fast, Memory-Efficient JavaScript

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

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

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

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

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

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

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

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

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

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

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

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.