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.

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

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!

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.

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.

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.

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.

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.

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 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.