Monthly Archives: October 2012

Under The Hood

I’m naturally curious. That is why I read and study so much and it is also why I am passionate about programming. When I’m working with a new library I’m constantly asking myself “how’s it doing that?”, and so I spend a lot of time looking under the hood, so to speak.

This article is all about me looking under the hood and reporting what I find there. This isn’t going to be a static document. I’ll keep appending new things to it as I learn rather than writing new articles for each, and so it is not a one time deal and you will need to check back here every once in a while if you are at all curious to find out what’s the newest thing I’ve discovered and what my ‘take away’ from it is.

Node Uses Both Prototypal and Pseudo Classical Styles – published 20012/10/27

In an Express.js based Node application, you typically see the following boilerplate code in app.js:

http.createServer(app).listen(app.get('port'), function(){
  console.log("Express server listening on port " + app.get('port'));

As tempting as it may be to just take it for granted that the code above sets up the listener for requests arriving on the specified port, I decided to dig a little deeper into the source code and perhaps learn a thing or two. What follows are some of the little tidbits of goodness that I’ve been able to spy.

From the boilerplate code above, for instance, the reference that createServer returns points to an instance of a Server object whose own prototype is inherited from net.Server’s prototype. How’s it doing that? To be able to answer that we have to look under the hood of the http module (http.js), beginning with its createServer method.

function Server(requestListener) {
  if (!(this instanceof Server)) return new Server(requestListener);, { allowHalfOpen: true });

  if (requestListener) {
    this.addListener('request', requestListener);

  // Similar option to this. Too lazy to write my own docs.
  this.httpAllowHalfOpen = false;

  this.addListener('connection', connectionListener);
util.inherits(Server, net.Server);

exports.Server = Server;

exports.createServer = function(requestListener) {
  return new Server(requestListener);

See the call to util.inherits(Server, net.Server) on line 16 above? Here’s the code from the util module (util.js) and guess what it is doing:

exports.inherits = function(ctor, superCtor) {
  ctor.super_ = superCtor;
  ctor.prototype = Object.create(superCtor.prototype, {
    constructor: {
      value: ctor,
      enumerable: false,
      writable: true,
      configurable: true

On line 3 above we see that the method inherits is calling the Object.create method, passing it a reference to net.Server’s prototype. The object reference that Object.create returns is an object whose own prototype inherits from net.Server’s prototype, and that reference is assigned to http.Server’s prototype property. So though htttp.Server doesn’t itself have a listen method, it inherits one now prototypically. If you are still confused, just think of net.Server’s prototype serving as http’s super prototype. I was going to say its superclass but I don’t want to confuse you even more than you might already be.

And the takeaway of this is

For me what’s worth noting here is that Node’s modules use both prototypal style and pseudo classical style in a  complimentary manner, thereby producing a utility whose sum is greater than what using either one alone might provide. This confirms to me, at least, that I should no longer have to pick one way or the other of modeling object hierarchies in JavaScript and that instead I should be thinking in more dynamic terms of using both styles, just as the code in Node’s modules are.


A Childhood Favorite — Tic Tac Toe

I’ve always wanted to recreate the simple games of my youth on the computer. Those games, the ones I played with pencil and paper and loved as a child, were as exciting to me then as the video games must be to the children playing them today.

So here’s Tic Tac Toe, which I chose to be the first game I’d recreate because out of all the childhood games of my youth none were as exciting and as much fun to play. The funny thing is, I still enjoy playing it today, and now, having written this, I won’t even need pencil and paper anymore. I don’t know if that’s a good or a bad thing but I do know I had a real blast cooking this game up.

So click on the link above and play a few games of Tic Tac Toe and see who’s really smarter, you or the computer.

I wrote Tic Tac Toe using 100% JavaScript. That means JavaScript on the server and JavaScript on the client. Here’s a few implementation details, just in case you are interested:

On the front end I employed:

  • A customized version of Twitter Bootstrap’s 12 column grid. I needed to eliminate the gutters between columns so the divs could buttress each other which was necessary for the game grid.
  • RequireJS for JavaScript modularity.
  • LESS for dynamic CSS stylesheets.
  •  JavaScript/jQuery for the Tic Tac Toe game engine. Nothing fancy here but I did intentionally dumb down the computer somewhat because I didn’t want it to be too one-sided in the computer’s favor. You can win if you are careful but I have to admit, the computer is pretty smart too 😉

And on the back end I used:

  • NodeJS for the http server.
  • Express Web Framework for simple http request routing.
  • EJS for dynamic embedded JavaScript HTML generation.
  • MongoDB for storing unique url hits and from which a visitor count is displayed in the footer of the page.
  • MongoSkin for its nice MongoDb wrapper employing the future pattern.

The source code for Tic Tac Toe is available on GitHub.

So that’s a wrap… Tic Tac Toe, anyone?


The Tools Of My Trade – WebStorm

I think it is a good idea to take stock of my tools every so often, to make sure they are in line with what I am trying to accomplish and aren’t themselves limiting me. Of all the tools in my tool box the most important to me are my IDE and code editor. Today, I’d like to focus on my IDE of choice.

WebStorm, the dedicated JavaScript Web development IDE from the good folks over at JetBrains, is a phenomenal JavaScript Web development environment and I’ve been champing at the bit wanting to write a raving review for a while now. Unfortunately I haven’t had the time to do an in depth review, so instead I will take a different approach and focus on only those features that in my opinion set WebStorm apart from its competition. I will also touch upon a few of its weaknesses that I would like to see addressed as well.

Where WebStorm Rocks:

1) Speed – My primary development tool has to be fast and anything less just wont cut it. WebStorm is the fastest IDE I’ve every worked with. It is quick to boot up and once booted it remains snappy. Project indexing which is often responsible for bringing an IDE to its knees is fast and I have never incurred any latency during the process.

2) Configurability – The folks over at JetBrains obviously recognize that we developers are a very picky and demanding bunch and that we will quickly reject any tool that doesn’t allow us to configure it to our specific likes, needs and work flow requirements. So not only did they provide us with a huge number of configuration options but they also made it very easy and accessible. From within configuration you can enter search criteria and WebStorm will return a list of configuration items that match your search criteria. Now that’s what I call a really smart approach to simplifying configuration.

3) The Editor Is My Canvas – The editor is where I often find myself in 8, 10, 12 or more hours a day. The quality or lack of it will either make or break a product for me. After all, I write code — that’s what I do. Writing code is my passion and the way I earn a living — and as such I demand more from my editor than from any other tool that I work with. My editor has to allow me to get as much work done without exiting out to some other application or tool which would just break my work flow and my concentration and that’s not a good thing. The way I see it, an artist never has to leave their canvas to paint and so a developer should never have to leave their editor to develop. WebStorm’s editor is my canvas.

4) Key Bindings and Keyboard Shortcuts – I’m a huge fan of VIM. I like VIM’s modal approach to editing. VIM allows me to be more productive because I rarely have to take my hands off of the keyboard and reach for my mouse or trackpad, which are actions that when repeated often can be distracting and physically challenging over the course of a long day.

WebStorm’s VIM key bindings duplicate many of VIM’s keyboard commands and though not a “hard core VIM” experience, it does provide enough of one and it works extremely well. Honestly, if it hadn’t I’d have rejected WebStorm outright which just goes to show you how serious I am about this.

In conjunction with good VIM support, WebStorm provides access to almost all of its features through handy keyboard shortcuts, which when used together with the VIM key bindings makes the physical act of typing in WebStorm quite productive and pleasant.

5) GIT Support – In a word, fantastic! Branching and shelving are well supported as is cloning from and pushing to github. I especially appreciate that WebStorm supports github Gists which I use as a repo for my code snippets.

6) Pretty and Nearly Distraction Free – Yeah, I said pretty. It shouldn’t seem odd that I would expect the environment I’m working in all day long to be visually appealing. Ugly is distracting and ultimately will affect my creativity and productivity. Therefore ugly is out. By using an assortment of WebStorm configurations I’m able to tailor WebStorm to be pretty and distraction free, eliminating most of its user interface. That’s how I like it!

7) Plugins – WebStorm is extensible through its plugin system. In fact, many of WebStorms features are provided through plugins. There are also numerous 3rd party plugins available as well. My favorite plugin is AceJump, written by John Lindquist, and the best description I can give it is that it is like search on steroids.

8) Live Templates – Live Templates are to WebStrorm as Snippets are to TextMate. They allow you to easily extend and add features to the editor.

9) Frequent Updates and Bug Fixes – I’ve already received one major update and 2 minor updates. It’s obvious to me that JetBrains stands behind their tools.

10) Server and Client Side Debugging – Easily debug server side and client side JavaScript. Really handy for both server side Node development as well as for front-end development.

Some Improvement Needed: 

This is my short list of those items I would most like to see addressed in future releases of WebStorm. WebStorm is a broad product, it attempts to do many things very well and for the most part it does. In my opinion it doe so better than any other IDE in its category. However, as excellent as WebStorm is there is room for some improvement. So here’s a few of my top wish list items:

1) Plug a few gaps in the VIM key bindings – As good as WebStorm’s VIM key binding are, it is missing a few that I think it should have. Most notably it doesn’t implement the character case switching commands in full. Complete support for this group of VIM keyboard commands is important when writing code in programming languages that are case sensitive as is the case (no pun intended) with JavaScript.

2) Improve Code Completion – Code completion is still too often a hit and miss proposition, even with the inclusion of external libraries, and while I understand this is really hard to do with dynamic languages such as with JavaScript I am hoping that JetBrains can improve on this.

3) Provide Custom Scaffolding Templates – I need a way to describe to WebStorm how to generate projects. I want to define the files, libraries and their versions that I want WebStorm to include as well as the actual structure of the project itself, including the names of the folders. I should be able to include files that reside either on the web or locally. Sounds or feels like something along the lines of a package manager to me but in any case it would allow me to pick and chose the libraries and files I want to use along with their versions. Perhaps just integrating with NPM or one of the other popular package managers would provide what I’m looking for. Maybe not an easy thing to do but it can’t hurt to ask, right?

4) Debug Both The Back and Front Ends At The Same Time – Right now you can debug one or the other but not both at the same time. Well, at least I haven’t been able to get this to work. So when working with Node it would be extremely handy and a real productivity booster if WebStorm were able to debug both at the same time.


While there are numerous free and open source options available, in the end I chose to purchase a license for WebStorm because none of the other options appeared to me to be as feature rich and as refined as WebStorm is. The attention to detail in this product is excellent and the 49 bucks US I paid for WebStorm is in my opinion an incredible value, especially considering how much utility it provides me and how productive I am with it.

As far as JavaScript development is concerned, WebStorm sets the bar to which all other dedicated JavaScript Web development IDEs must be measured against. Kudos to JetBrains for producing the finest dedicated JavaScript Web development IDE I’ve had the pleasure of using.

Links To References:

Vim’s case switching commands
AceJump plugin by John Lindquist – download directly through WebStorm’s plugin system.  Informative video available at


Semantically Rich and Expressive JavaScript

One of the things that impresses me about JavaScript is how functions and closure allow for the creation of semantically rich and expressive code.

Recently I needed to develop code that could make a number of transformations on an image. The transformations were driven by ranges of numbers which were entered into the system by the user. These numbers represented a superset of transformation parameters and the software had to be able to create subsets of these numbers based on filters or predicates entered by the user. In addition, the actual transformations were selectable at runtime so even the function called to do the actual transformation had to be dynamic.

At first glance this seemed as if it would take lots of code and lots of time to be able to provide an implementation that could handle the dynamic nature of the problem domain. When my brain gets bogged down and starts to sizzle like bacon hitting a hot frying pan I like to go for long walks which helps me think. Well the fresh air helped and I realized that I could take advantage of functions (as fist class citizens) and closure to provide a solution that wouldn’t require lots of code, that could also be made generic and semantically eloquent as well.


The code below is a simplified implementation of the actual code but minus all the domain specific details. So, instead of a real image object I am using an object literal to mock a real image object and instead of obtaining transformational values, predicates and the transformations from the user I am hard coding them here. But in every other regard, this is the code that the application is actually using.

            (function ( window ) {

                "use strict";

                 * Using functions and closure to
                 * create idiomatic constructs.

                var makeForEachFilter = function ( filterFunc ) {
                    return function ( numberToCheck, index, array ) {
                        return filterFunc( numberToCheck );

                 * A make believe image object with a transform
                 * method which takes an array of values.
                var image = {
                    transform : function ( values ) {
                        // now transform the image using somehow the new numbers in the process ...
                        console.log( "transforming image using values: " + values );

                 * A function that generates a subset of
                 * values filtered from a superset and
                 * then calls a method with the generated
                 * subset.
                var doWith = function ( valuesToTransform, filter, transformationFunction ) {
                    var newVals = [];
                    valuesToTransform.forEach( function ( value, index, array ) {
                        if ( filter( value ) ) {
                            newVals.push( value );
                    } );
                    transformationFunction( newVals );

                * A superset of values from which subsets are made
                var valuesToFilter = [1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048];

                 * Do something with a subset of numbers
                 * that are all > 100
                var greaterThanOneHundred = makeForEachFilter( function ( numberToCheck ) {
                    return numberToCheck > 100;
                } );

                doWith( valuesToFilter, greaterThanOneHundred, image.transform );

                 * Do something with a subset of numbers
                 * that are all < 100
                var lessThanOneHundred = makeForEachFilter( function ( numberToCheck ) {
                    return numberToCheck < 100;
                } );

                doWith( valuesToFilter, lessThanOneHundred, image.transform );

                 * Do something with a subset of numbers
                 * that are > 4 & < 100
                var betweenFourAndOneHundred = makeForEachFilter( function ( numberToCheck ) {
                    return numberToCheck > 4 && numberToCheck < 100;
                } );

                doWith( valuesToFilter, betweenFourAndOneHundred, image.transform );

            }( window ));

The makeForEachFilter method is perhaps the most interesting of all the code in that it creates a closure whereby the inner function can access the filter function after its parent function is no longer in scope. So makeForEachFilter is really a filter factory — you hand it a function that acts as a filter and it returns a function that can filter numbers.

The remaining code is split between the doWith function and code to demo the implementation. As you can see, when doWith is called, it is passed an array of numbers which represents the superset (in the real application, these numbers represented all the transformational parameters that could be applied to an image), a filter function (one created by the makeForEachFilter method) used to create a subset of the superset, and a function that does something with the subset of numbers (in the real world, image objects have their own method to handle requests to do transformations on themselves). That’s a lot of functionality from 30 or so lines of implementation code, minus whitespace.

JavaScript isn’t Clojure and nor is it Scala but it certainly has some common roots with both of these Lisp and functional languages, respectively, and those are closure and first class functions which allows using JavaScript to create the kind of implementations as the one I present here.


It isn’t a stretch to suggest that understanding functions as objects (as first class citizens) and closure are key to mastering JavaScript.  If either or both of these concepts are foreign to you then may I humbly suggest that you haven’t really learned JavaScript, and that you are one of “those” people that Douglas Crockford talks about in his tutorials. Honestly, though, not too long ago I was one of “those” too. So all I can say is, “if Jeff can really learn to code JavaScript in a manner that even Douglas Crockford might noddingly approve of, so can you!”