Share the intellectual wealth

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.

The Cathedral and the Bazaar

noreply@blogger.com (Jan Van Ryswyck) — Fri, 14 Oct 2011 22:26:00 +0000

A couple of weeks ago, I ran into this website from Eric S. Raymond, the author of the book The Cathedral and the Bazaar. There’s a recording of a great presentation that anyone involved with software development, and especially open-source, should listen to. I highly recommended that you download this recording and at the very least listen to it twice! You can also read the book online.

Enjoy!

Presenting “Taking Baby Steps with Node.js” at Agile.NET 2011 Europe

noreply@blogger.com (Jan Van Ryswyck) — Fri, 23 Sep 2011 20:21:00 +0000

In a couple of weeks, I’ll be doing an introductory presentation on Node.js at the Agile.NET 2011 conference. While having a look at the other sessions and speakers, I’m quite honored to be able to join these smart bunch of craftsmen. In fact, I’m still amazed that the organizers accepted my proposal. But hey, they’ll probably let me do my talk somewhere in the basement anyway :-).

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

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

Hope to see you there.

My First Day at iChoosr

noreply@blogger.com (Jan Van Ryswyck) — Mon, 12 Sep 2011 19:23:00 +0000

Today was my very first day at iChoosr, a small internet startup that focuses on Vendor Relationship Management. I’ll be working there as a web developer in a small team of very bright people. Working for a small startup is a totally new experience for me. So I’m very excited about what the future will bring.

Pretty sure there’s lots of learning ahead of me

An Observation about TDD

noreply@blogger.com (Jan Van Ryswyck) — Fri, 09 Sep 2011 18:32:00 +0000

To me, developers that are not applying TDD practices during their day-to-day job always seem more in a hurry than developers that do apply red-green-refactor. In their hurry, they're the first to cut corners and start making messes while they rush to their goal. A while ago it dawned to me why that is. They subconsciously want to get feedback as soon as possible about the code they're writing. They cut corners and generally mess up their code in order to prevent spending those extra hours and days to keep things clean. Constantly refactoring and cleaning up their code is restraining them from having the feedback they so desperately want.

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

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

Just an observation ...

Book Review: The Clean Coder

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

Earlier this week I finished reading Uncle Bob’s latest book The Clean Coder. Robert C. Martin is a great writer and I very much enjoyed reading his previous books. His latest work is no exception and I found it to be yet again a fascinating read.

This book is all about professionalism. This is something that is very much needed in the field of software development. It describes how a professional software craftsman behaves, how he deals with tight schedules, irrational decisions made by managers (for those rare occasions that this happens), conflicts and so forth. The preface of the book takes you right by the throat, talking about the Challenger disaster. This has been applied to the field of software engineering many times already (check out this blog post from Gustavo Duarte which is one of my all-time favorites), but still, it definitely never wears off.

The book is filled with stories and anecdotes from the rich career of the author and the lessons he learned during these 40+ years in the IT industry. Some of the ideas in there are definitely challenging (like staying out of the zone and building up focus instead), but nonetheless they put a very interesting perspective on things.

Don’t let yourself get carried away by some of the hard statements but try to focus on the underlying ideas and try to think back on some of the good and bad situations that you ran into during your own career. Trying to reflect on those moments and considering how we could act more professionally lies at the heart of improving ourselves. I definitely learned a lot while reading this book and I encourage you to pick up a copy as soon as possible and take some time to read it.

Two thumbs up!

Book Reviews: CoffeeScript and JavaScript Web Applications

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

While catching up on my reading backlog, I particularly enjoyed reading two new books I bought recently which I’m going to briefly discuss in this blog post.

1. CoffeeScript - Accelerated JavaScript Development

CoffeeScript – Accelerated JavaScript Development, written by Trevor Burnham, gets you up and running with CoffeeScript in no time. This book was recently released by the excellent Pragmatic Programmers which only increased my expectations. And I must admit that Trevor did a tremendous job explaining the ins and outs of this fairly new programming language. With only a good 120 pages, it’s a very quick read so one is able to start coding away as soon as possible.

The book contains six chapters. The first four chapters basically cover the different language features of CoffeeScript. The last two chapters explain how to use CoffeeScript both on the client-side along with jQuery and the server-side with Node.js. At the end of each chapter there’s an example application (5x5 solitaire) that gets refactored throughout the book as more language features are covered. Every chapter also provides some exercises where you can put your teeth into.

Now, I have to warn you that in order to get the most out of this book, you need to have some decent knowledge of JavaScript. Some of this stuff isn’t trivial and being able to imagine how the underlying JavaScript would look like is almost required.

I highly recommend this book if you want to learn this great little programming language.

2. JavaScript Web Applications

By the time of this writing, JavaScript Web Applications by Alex MacCaw hasn’t officially been released yet. It’s still in the early release phase which means that there are still a good number of typos in there. That aside, this book contains some rock solid content on how to build client-side JavaScript applications.

This book isn’t about server-side applications with the occasional piece of JavaScript code used in only a couple of web pages. As it’s name implies, this book is all about building MVC applications for the browser using JavaScript.

After the obligatory introductory chapter, chapter 2 up to chapter 6 discuss each part of the MVC pattern and events. The author thoroughly explains each part of this design pattern while implementing his own client-side MVC library. Lots and lots of code here.

Chapter 7 provides a clear explanation on dependency management in JavaScript and how to use module loaders to mitigate this problem. Chapter 8 and 9 cover some of the API’s that come with the upcoming HTML 5 standard, particularly on how to deal with files using JavaScript as well as WebSockets. Chapter 10 deals with testing and debugging. But chapter 11 is definitely my favorite chapter of the book where the author shows a good number of techniques on deploying a JavaScript web application and how to deal with performance. This chapter alone was a real eye opener. Finally, the last three chapters provide an in-depth introduction to three of the most popular open-source client-side JavaScript libraries out there, namely Spine.js, Backbone.js and JavaScriptMVC.

Again I have to warn you that this book is definitely not for JavaScript beginners or the faint of heart. There were times that it even got me scratching my head from time to time. There’s some really neat JavaScript stuff in there, so I highly recommend that you pick up this book some time on your JavaScript learning path.

Happy reading an until next time.

Dynamic in C# is Broken

noreply@blogger.com (Jan Van Ryswyck) — Thu, 11 Aug 2011 10:00:00 +0000

Earlier this week, I ran into an issue while using the dynamic keyword in C#. I learned from C# in Depth that there are a couple of restrictions with dynamic, most notably when using extension methods or converting lambda expressions. But apparently there are more restrictions than meets the eye, which came as an unpleasant surprise. Let’s look at some code.

public interface IPresenter
{
    void Start(dynamic startupData);
}

public interface ISpecificPresenter : IPresenter
{}

public class SpecificPresenter : ISpecificPresenter
{
    public void Start(dynamic startupData)
    {
        // ...
    }
}

Here we have an interface called IPresenter with a single method on it named Start. Notice that the Start method has a single parameter which is defined as dynamic. We also have another interface called ISpecificPresenter that inherits from IPresenter. Finally we have a concrete class that implements the ISpecificPresenter interface. So far, so good.

Next we have a class called Activator that we use to kick-off a particular presenter.

public class Activator
{
    public void Start<TPresenter>(dynamic startupData)
        where TPresenter : IPresenter
    {
        var presenter = ObjectFactory.GetInstance<TPresenter>();
        presenter.Start(startupData);
    }
}

The Activator class has a generic Start method with a parameter named startupData that is also dynamic. Here we simply get an instance of a requested presenter from StructureMap and call its Start method. This is how to call the Start method of the Activator class :

var activator = new Activator();
activator.Start<ISpecificPresenter>(new{});

When we run this code, we get the following exception:

Microsoft.CSharp.RuntimeBinder.RuntimeBinderException: 'ISpecificPresenter' does not contain a definition for 'Start'.

This had me stumped for a while until I added a cast from ISpecificPresenter to IPresenter in the Start method of the Activator class.

public class Activator
{
    public void Start<TPresenter>(dynamic startupData)
        where TPresenter : IPresenter
    {
        var presenter = (IPresenter)ObjectFactory.GetInstance<TPresenter>();
        presenter.Start(startupData);
    }
}

Now everything works as expected. But I’m not entirely sure why this isn’t behaving as I expected. I guess it has something to do with the fact that the Start method is defined on the IPresenter interface and not on the ISpecificPresenter interface.

Although I very much like the flexibility that dynamic objects bring to the C# language, I’m also starting to think that it might not be such a good idea to bring dynamic concepts to a statically typed language. Running into these kind of issues and limitations reinforces this growing opinion.

I would much appreciate it if anyone could enlighten me with a good explanation.

Until next time.

Exploring CoffeeScript Part 6 - Show Me the Goodies !

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

For the final blog post in this series, we’re going to go over a couple of cool little nuggets that one can use to write some elegant CoffeeScript code.

Also check out the previous installments:

Destructuring Assignments

Destructuring assignments are a great syntactic enhancement for those cases where we want to extract (deeply) nested property values from arrays or objects and store these values into variables.

First let’s have a look at a simple code example written in plain JavaScript where we simply assign some property values of an object to a couple of variables.

var podcast = {
    title: 'Astronomy Cast',
    description: 'A fact-based journey through the galaxy.',
    details: {
        homepage: 'http://www.astronomycast.com',
        rss: "http://www.astronomycast.com/feed/",
        atom: "http://www.astronomycast.com/feed/atom/"    
    }
};

var title = podcast.title;
var description = podcast.description;
var homepage = podcast.details.homepage;

console.log(title);
console.log(description);
console.log(homepage);

Using destructuring assignments in CoffeeScript, we can assign the property values of the object to the variables using a single line of code.

podcast =
    title: 'Astronomy Cast'
    description: 'A fact-based journey through the galaxy.'
    details:
        homepage: 'http://www.astronomycast.com'
        rss: 'http://www.astronomycast.com/feed/'
        atom: 'http://www.astronomycast.com/feed/atom/'

{title, description, details: { homepage } } = podcast

console.log title
console.log description
console.log homepage

Besides objects, destructuring assignments also works for arrays as well.

favoritePodcasts = ['Astronomy Cast', 'Hardcore History', 
                    'Talking Shop Down Under', 'The Changelog', 'Pluralcast'];
[favorite01, favorite02, favorite03, favorite04, favorite05] = favoritePodcasts

console.log favorite01
console.log favorite02
console.log favorite03
console.log favorite04
console.log favorite05

And of course, this can also be used when combine objects with arrays and vice versa.

customer =
    firstName: 'Chuck'
    lastName: 'Norris'
    orders: [
        { 
            Id: 1 
            Item: 'Knuckle Duster'
        },
        { 
            Id: 2
            Item: 'Shuriken' 
        }
    ]

{orders: [ {Item: item1}, {Item: item2}]} = customer

console.log item1
console.log item2

This small little language nugget has definitely come in handy quite more often than I first anticipated. So do keep the availability of destructuring assignments in the back of your head while developing CoffeeScript code.

String Interpolation

The syntax for string interpolation is heavily inspired on the Ruby syntax. Let’s have a look.

podcast = 
    title: 'Astronomy Cast'
    download: (episode) ->
        console.log "Downloading #{episode} of #{@title}."

podcast.download 'the first episode'

In this example we fill in the values of the episode parameter and the title property into the string that we send to the console.log method. Unfortunately string interpolation only works for double quoted strings. I personally prefer single-quoted strings when I’m writing CoffeeScript code. But I gladly make an exception when I want to use string interpolation.

Strict Equality

In JavaScript, we have the == and the === operator. Both equality operators behave the same way only the first performs type coercion while the latter enforces type equality. It's a common best practice in JavaScript to always use the strict equality operator and explicitly perform type casts if needed. CoffeeScript on the other hand only has only one equality operator which always translates to JavaScript's strict equality operator behind the scenes.

So the following equality comparison written in CoffeeScript translates to the JavaScript code shown bellow:

# CoffeeScript
x = 'str'
y = 12
console.log x == y        # Outputs 'false'


// JavaScript
var x, y;
x = 'str';
y = 12;
console.log(x === y);

As I already mentioned in one of the previous blog posts, CoffeeScript emits JavaScript that follows best practices and complies to JSLint without warnings. Always using the === operator is part of being compliant.

Conditionals

CoffeeScript adds some nicely readable syntactic sugar to be used with conditionals using keywords like unless, is, isnt, and and or. Let’s look at an example.

cobol = vb = false
cool = true

unless cobol is cool
    console.log 'CoffeeScript is awesome!'

if vb isnt cool
    console.log 'CoffeeScript is awesome!'

if cobol isnt cool and vb isnt cool
    console.log 'CoffeeScript is awesome!'

I really like how these keywords enable us to write fluently readable conditional statements in CoffeeScript.

The Existential Operator

The existential operator in CoffeeScript, expressed using the ? symbol, returns true except when a particular variable is null or undefined. Let’s look at some code.

someVariable = null
someOtherVariable = 12

console.log someVariable ? someOtherVariable        # Outputs 12

unless someVariable?
    console.log 'someVariable is null'

But the existential operator can also be used to check for null or undefined before accessing a property or the result of a function. This is also called a soak which is the accessor variant of the existential operator. Again some code to clarify things.

podcast =
    title: 'Astronomy Cast'
    description: 'A fact-based journey through the galaxy.'
    details:
        homepage: 'http://www.astronomycast.com'
        rss: 'http://www.astronomycast.com/feed/'
        atom: 'http://www.astronomycast.com/feed/atom/'

    download: -> null

# Outputs 'http://www.astronomycast.com'
console.log podcast.details.homepage    

# TypeError: Cannot read property 'publishingDate' of undefined            
console.log podcast.moreDetails.publishingDate        

# Outputs undefined
console.log podcast.moreDetails?.publishingDate     

# Also outputs undefined
console.log podcast.download()?.data

When the property in question has a valid value, then the expected result is returned. In case the property does not exist or contains null, then undefined is returned instead of a TypeError being thrown.

So that’s it for now. I hope that you enjoyed reading this blog series on CoffeeScript and perhaps you are now also convinced that using CoffeeScript is a viable and productive alternative for writing JavaScript based applications.

Until next time.

Moving from E-TextEditor to Sublime Text 2

noreply@blogger.com (Jan Van Ryswyck) — Fri, 05 Aug 2011 23:46:00 +0000

I’ve been using E-TextEditor for more than a year now for doing all my JavaScript, Node.js and CoffeeScript development. You can think of E-TextEditor as TextMate for the Windows platform. I’ve been pretty happy with it throughout this period as it can be extended pretty easily with a whole slew of bundles that are already available for TextMate. E-TextEditor requires you to install Cygwin which happens automatically during installation. Using the Cygwin command-line gave me enough (re-)exposure to a Linux-like environment in order for me wanting to (re-)learn about this other platform. More on that in later blog posts. Although there haven’t been any new versions of E-TextEditor for quite some time now, the current version enabled me to write JavaScript code in a productive way.

Only recently I found out about another editor called Sublime Text 2 (thanks to Ivan Porto Carrero). I downloaded this text editor in order to give it a try and I must say that I haven’t opened E-TextEditor ever since. This second version of Sublime Text is still in development but it’s pretty stable as I haven’t run into any issues so far. The cool part is that this editor is available for both Windows, Linux and OS X which enabled me to move all my Node.js and CoffeeScript development from Cygwin on Windows to Ubuntu Linux.

CoffeeScript isn’t supported out-of-the-box (yet), so I installed the CoffeeScript TextMate bundle written by Jeremy Ashkenas (yes, the same one from the CoffeeScript and Backbone.js fame). Also check out this page on the CoffeeScript wiki for more information on how to bring some CoffeeScript happiness to your own favorite text editor.

Setting up this TextMate bundle for use with Sublime Text 2 was actually pretty easy. Just navigate to /home/<my_user_name>/.config/sublime-text-2/Packages in a terminal (or the corresponding file path on Windows) and clone the source of the CoffeeScript TextMate bundle using git:

git clone git://github.com/jashkenas/coffee-script-tmbundle CoffeeScript

Next close all the .coffee files and restart Sublime Text 2. Now we have some nice syntax highlighting and some useful code snippets at our disposal.

It's also possible to hook into the build system of Sublime Text 2. You just need to create a new file named CoffeeScript.sublime-build at the following location:

/home/<my_user_name>/.config/sublime-text-2/Packages/User

You can add the following to this new file for compiling CoffeeScript

{
     "cmd": ["coffee", "-c", "$file"],
     "selector" : "source.coffee",
     "path" : "/usr/local/bin"
}

or the following for executing/running CoffeeScript code.

{
     "cmd": ["coffee", "$file"],
     "selector" : "source.coffee",
     "path" : "/usr/local/bin"
}

Now when you hit F7, this fresh build command is executed when a CoffeeScript source file is showing in the active tab. It’s also possible to change the build short-key to your own taste through the Preferences menu.

Unfortunately, there’s only one build command as I would love to create a separate command for compiling and running CoffeeScript code (or perhaps I missed this feature during the excitement ).

Some more usage is definitely needed for me to learn more about this excellent text editor, but currently I’m pretty happy with it. I also need to find out how well JavaScript is supported and perhaps see how far one can go when doing some C# development using Mono. I expect that there are a good number of productive features in there for me to discover.

I encourage you have a decent look at this excellent tool.

Until next time.

Exploring CoffeeScript Part 5 - Ranges, Loops and Comprehensions

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

For this blog post, we’re going to discuss ranges, loops and comprehensions in CoffeeScript.

Also check out the previous installments:

Ranges

Again a feature that is heavily inspired by Ruby. Using a range we can define an array of consecutive numbers by only specifying the first and the last number.

numbers = [1..10]
console.log numbers        # Outputs [ 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 ]

This is a so-called inclusive range which is denoted by the two dots separating the bounding numbers. CoffeeScript also provides the concept of an exclusive range which is denoted by three dots instead of two.

numbers = [1...10]
console.log numbers        # Outputs [ 1, 2, 3, 4, 5, 6, 7, 8, 9 ]

In this case the number of the upper boundary is excluded. Ranges are a small addition to the syntax that can come in handy from time to time.

Loops

As with JavaScript, CoffeeScript also provides us with two different kinds of for loops: one for iterating over an array and one for iterating over the properties of an object.

download = (podcast) ->
    console.log 'Downloading ' + podcast

favoritePodcasts = ['Astronomy Cast', 'Hardcore History', 
                    'Talking Shop Down Under', 'Pluralcast']

for podcast in favoritePodcasts
    download podcast

The for .. in syntax in CoffeeScript is used for iterating over an array while the next example show how a for .. of loop is used for iterating over the properties of an object.

podcasts = 
    'Astronomy Cast': 'http://www.astronomycast.com/',
    'Hardcore History': 'http://www.dancarlin.com/disp.php/hh',
    'Talking Shop Down Under': 'http://www.talkingshopdownunder.com/',
    'Pluralcast': 'http://www.pluralsight-training.net/microsoft/pluralcast/default.aspx'

for key, value of podcasts
    console.log key + ' - ' + value

A for .. in loop translates to a traditional for loop in JavaScript while the for .. of loop translates to a for .. in loop in JavaScript.

// Iterating over an array in JavaScript
for (_i = 0, _len = favoritePodcasts.length; _i < _len; _i++) {
    ...
}

// Iterating over the properties of an object in JavaScript
for (key in podcasts) {
    value = podcasts[key];
    ...
}

In the example where we iterate over an array, the for .. in loop can be more compact using the postfix notation.

download podcast for podcast in favoritePodcasts

How nice is that! Let’s look at some more sweet syntax that CoffeeScript brings us. We can use the ‘when’ keyword for filtering.

for number in [1..10] when number > 5
    console.log number        # Outputs '6, 7, 8, 9, 10'

Filters are supported by both for .. in and for .. of loops. We can also obtain the current index when looping over an array.

favoritePodcasts = ['Astronomy Cast', 'Hardcore History', 
                    'Talking Shop Down Under', 'Pluralcast']
for podcast, i in favoritePodcasts
    console.log (i+1) + '/ ' + podcast

This is only possible when using for .. in loops. We can also use the 'by' keyword to loop over an array with fixed-size steps.

for number in [0..100] by 10
    console.log number        # Outputs '10, 20, 30, ..., 100'

Again, this is only possible when using for .. in loops. Besides all these nice syntax additions for for … in loops, there is also a quite helpful keyword that’s only available when using for .. of loops. We can use the 'own' keyword for iterating over properties that are only defined on the object itself and not on any prototype(s).

Podcast = ->
    @name = 'Astronomy Cast'
    @url = 'http://www.astronomycast.com/'

Podcast::download = ->
    console.log 'Downloading ' + @name + ' from ' + @url

podcast = new Podcast()
for own key, value of podcast
    console.log key + ' : ' + value

Note that we use the :: operator as a shorthand for denoting the prototype property. In this example we used the ‘own’ keyword to skip over any properties defined on the prototype objects, which is simply some syntactic sugar for a hasOwnProperty check in JavaScript.

var Podcast, key, podcast, value;
var __hasProp = Object.prototype.hasOwnProperty;

Podcast = function() {
    this.name = 'Astronomy Cast';
    return this.url = 'http://www.astronomycast.com/';
};

Podcast.prototype.download = function() {
    return console.log('Downloading ' + this.name + ' from ' + this.url);
};

podcast = new Podcast();
for (key in podcast) {
    if (!__hasProp.call(podcast, key)) continue;
    
    value = podcast[key];
    console.log(key + ' : ' + value);
}

Let’s take this a bit further by diving into comprehensions.

Comprehenions

Everything is an expression in CoffeeScript, which means that this also applies to loops. What better way to demonstrate this than a simple code example? Suppose we want to create an array with even numbers by looping over another array of numbers. This is how it can be solved using the CoffeeScript way.

evenNumbers = (number for number in [1..10] when number % 2 is 0)
console.log evenNumbers        # Outputs [ 2, 4, 6, 8, 10 ]

A for loop in CoffeeScript always returns an array with the result of every iteration which in this case are the even numbers from the first array. Note that we need to enclose this comprehension with parentheses because otherwise we only get the last even number instead of an array with all the even numbers.

If you’re not yet impressed by this language feature, then checkout the following one-line FizzBuzz implementation.

fizzbuzz = (['fizz' unless i%3] + ['buzz' unless i%5] or i for i in [1..100])
console.log fizzbuzz

The implementation comes from this blog post of Ricardo Tomasi which is highly recommended.

While

To make things complete, CoffeeScript also provides a while loop.

count = 0
tenfolds = while (count += 1) <= 10
    count * 10
    
console.log tenfolds

The while loop in CoffeeScript behaves the same as the one in JavaScript except that it also returns an array of values.

That’s it for now. Until next time.

Exploring CoffeeScript Part 4 - Objects and Classes

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

For this blog post, we’re going to continue our journey through the wonderful world of CoffeeScript, exploring objects and classes.

Also make sure to check out the previous installments:

Objects

Most of us have know how the object literal notation looks like using plain old JavaScript. Here’s a simple example:

var podcast = {
    title: 'Astronomy Cast',
    description: 'A fact-based journey through the galaxy.',
    details: {
        homepage: 'http://www.astronomycast.com',
        rss: 'http://www.astronomycast.com/feed/',
        atom: 'http://www.astronomycast.com/feed/atom/'    
    },
    
    toString: function() {
       return 'Title: ' + this.title;
    }
};

Lets have a look at how define the exact same object using CoffeeScript.

podcast =
    title: 'Astronomy Cast'
    description: 'A fact-based journey through the galaxy.'
    details:
        homepage: 'http://www.astronomycast.com'
        rss: 'http://www.astronomycast.com/feed/'
        atom: 'http://www.astronomycast.com/feed/atom/'
    
    toString: ->
       return "Title: " + @title

As you can see, the CoffeeScript equivalent involves less overhead which naturally results in a more compact syntax. For object literals we don't have to provide curly braces and commas, taking full advantage of significant whitespace.

In this basic example, we directly assign values for the different properties which is not very common. Suppose that we want to create podcast objects by calling a factory method specifying the necessary parameter values:

createPodcast = (title, description, homepage, rss, atom) ->
    title: title
    description: description
    details: 
        homepage: homepage
        rss: rss
        atom: atom    
        
    toString: -> return "Title: " + @title    

title = 'Astronomy Cast'
description = 'A fact-based journey through the galaxy.'
homepage = 'http://www.astronomycast.com'
rss = 'http://www.astronomycast.com/feed/'
atom = 'http://www.astronomycast.com/feed/atom/'

podcast = createPodcast title, description, homepage, rss, atom

console.log podcast
console.log podcast.toString()

Again, CoffeeScript can save us some typing here as we don’t need to provide both the property name and the corresponding variable name if they are both the same. In this case we can rely on conventions to create a new podcast object.

createPodcast = (title, description, homepage, rss, atom) ->
    {   
        title
        description
        details: {
            homepage
            rss
            atom
        } 
        
        toString: -> return "Title: " + @title    
    }

Note that we need to specify curly braces for both the resulting podcast object as for the nested details object because otherwise we’ll get some parser errors. Either way, CoffeeScript gets the most out of every keystroke :-).

Classes

JavaScript is not a ‘classical’ language but a prototypal object language. There are several JavaScript libraries out there that have made an attempt to bring some form of class like syntax into the language. It’s my personal belief that by fully embracing the prototypical nature of JavaScript that we can gain the true benefits of this great language. However I do recognize that a class like syntax can save us from the syntactical and mental burden that is often seen with prototypical inheritance in JavaScript. Again, CoffeeScript is here to save the day.

By providing a class-style syntax, CoffeeScript effectively provides us with a useful abstraction on top of JavaScript’s prototype capabilities, also applying all the well-known best practices in the process. This enables us to write code that is much more concise and therefore also more clear while still taking advantage of the benefits of the JavaScript object model.

Let’s talk code, shall we?

class Medium
    constructor: (@name) ->
    
    # Prototype method
    download: (episode) ->
        console.log 'Downloading ' + episode + ' of ' + @name
    
    # Static method
    @play: (episode, name) ->
        console.log 'Playing ' + episode + ' of ' + name         
        
    playOn: -> 
        console.log 'unknown'    
                
        
class Podcast extends Medium
    constructor: (name, @description) ->
        super name
                
    listen: -> 
        console.log 'Listening to ' + @name
    
    playOn: ->
        console.log 'iPod'
        
        
class Screencast extends Medium
    constructor: (name, @description, @author) ->
        super name
        
    watch: ->
        console.log 'Watching ' + @name
        
    playOn: ->
        console.log 'iPad'

Here we have three classes. Both the Podcast and the Screencast class derive from the Medium class using the extends keyword. First have a look at the constructor functions. CoffeeScript lets us define dedicated functions that will be executed upon instantiation. Notice the shorthand syntax for property initialization. Instead of constructor: (name) –> @name = name we can simply use the equivalent constructor: (@name). This shorthand will also work for normal functions outside of classes. Remember, every keystroke counts! The constructor functions of the derived classes invoke the constructor of the base class by simply calling super, which translates into a call to an ancestor method of the same name.

Instance methods and properties can be defined exactly the same way as we saw earlier when we discussed objects. Obviously, these can only be used after we create an instance of a class.

podcast = new Podcast('Astronomy Cast', 'A fact-based journey through the galaxy.')
podcast.download 'the first episode'
podcast.listen()

screencast = new Screencast('RailsCasts', 'Ruby on Rails Screencasts', 'Ryan Bates')
screencast.download 'the 267th episode'
screencast.watch()

But we can also have static methods and properties. These cannot be invoked on instances of a class but only directly on the class object itself.

# Static method
@play: (episode, name) ->
    console.log 'Playing ' + episode + ' of ' + name

...

# Object #<Podcast> has no method play
podcast.play 'the first episode'

Medium.play('the third episode', 'Hardcore History')
Podcast.play('the fourth episode', 'Astronomy Cast')

We’ve already used the shorthand syntax here. We could also use the following notation for defining this static method:

# Static method
this.play: (episode, name) ->
    console.log 'Playing ' + episode + ' of ' + name

Remember from the previous post that CoffeeScript uses the ‘@’ symbol to alias this. Every keystroke counts!

One of the key tenets of object-oriented programming using a classical language is polymorphism. Don’t worry, CoffeeScript got this covered as well.

play = (medium) ->
    medium.playOn()

play(podcast);       # Outputs 'iPod'
play(screencast);    # Outputs 'iPad'

Here we have a function that takes in a Medium object and simply invokes the playOn() function. The playOn() functions of the derived classes will be invoked and not the one defined in the base class.

In the previous post we mentioned that we can reuse methods from other objects using the call()/apply() methods defined on the prototype of Function. This can also be done when we’re using classes in CoffeeScript.

class PodcastStub
    constructor: ->
        @name = 'some funcky stub podcast'
        
podcastStub = new PodcastStub()
podcast.listen.apply podcastStub    # Outputs 'Listening to some funcky stub podcast'

We can use the hash rocket operator (or fat arrow) to prevent this behavior if we want. By using => instead of –> we can define a function to the current value of this.

class ContextSafePodcast extends Medium
    constructor: (name, @description) ->
        super name
                
    listen: => 
        console.log 'Listening to ' + @name
    
    playOn: ->
        console.log 'iPod'

contextSafePodcast = new ContextSafePodcast('Astronomy Cast',
                                            'A fact-based journey through the galaxy.')
contextSafePodcast.listen.apply podcastStub    # Outputs 'Listening to Astronomy Cast'

I’ll round of this post by showing you the equivalent JavaScript code for the small class hierarchy shown in our example.

var Medium, Podcast, Screencast;
var __hasProp = Object.prototype.hasOwnProperty, __extends = function(child, parent) {
for (var key in parent) { if (__hasProp.call(parent, key)) child[key] = parent[key]; }
function ctor() { this.constructor = child; }
ctor.prototype = parent.prototype;
child.prototype = new ctor;
child.__super__ = parent.prototype;
return child;
};

Medium = (function() {
function Medium(name) {
  this.name = name;
}
Medium.prototype.download = function(episode) {
  return console.log('Downloading ' + episode + ' of ' + this.name);
};
Medium.play = function(episode, name) {
  return console.log('Playing ' + episode + ' of ' + name);
};
Medium.prototype.playOn = function() {
  return console.log('unknown');
};
return Medium;
})();

Podcast = (function() {
__extends(Podcast, Medium);
function Podcast(name, description) {
  this.description = description;
  Podcast.__super__.constructor.call(this, name);
}
Podcast.prototype.listen = function() {
  return console.log('Listening to ' + this.name);
};
Podcast.prototype.playOn = function() {
  return console.log('iPod');
};
return Podcast;
})();

Screencast = (function() {
__extends(Screencast, Medium);
function Screencast(name, description, author) {
  this.description = description;
  this.author = author;
  Screencast.__super__.constructor.call(this, name);
}
Screencast.prototype.watch = function() {
  return console.log('Watching ' + this.name);
};
Screencast.prototype.playOn = function() {
  return console.log('iPad');
};
return Screencast;
})();

Did I mention that every keystroke counts? ;-)

Until next time.

Exploring CoffeeScript Part 3 - More on Functions

noreply@blogger.com (Jan Van Ryswyck) — Wed, 13 Jul 2011 10:00:00 +0000

For this blog post we’re going to continue where we previously left off, talking a bit more about functions in CoffeeScript. Let’s get things started by talking a bit about function scope.

Function scope

Like Ruby, CoffeeScript uses lexical scope. This means that a variable that is declared inside a function is invisible to outside code. From there on, a variable lives inside the scope in which a value is assigned to it without being able to be redeclared. Because we don't have access to the var keyword, we can't simply declare a variable and use it in a different scope without assigning a value to it.

Consider the following code:

someFunction = -> podcast = 'Hardcore history'

podcast = 'Astronomy cast'
someFunction()

console.log podcast        # This outputs 'Astronomy cast'

The output might come as a surprise to you, but it actually makes a lot of sense. A variable that is declared inside an inner scope cannot shadow a variable with the same name that is declared in an outer scope. I highly recommend that you avoid reusing variable names as shown by this example.

Function context

In JavaScript, the this keyword inside a function does not necessarily point to the object for which the function is declared. The object that is referenced by this depends on how the function is called. The same applies to CoffeeScript as well, only it uses the '@' symbol for denoting the this keyword in JavaScript. Let’s look at a couple of scenarios.

download = (podcast) -> 
    @podcast = podcast
    console.log @podcast    # This outputs 'Astronomy Cast'
    console.log @           # This outputs all properties of the global object
    
download 'Astronomy Cast'

Compiling this down to JavaScript results in the following code:

var download;
download = function(podcast) {
    this.podcast = podcast;
    console.log(this.podcast);
    return console.log(this);
};

download('Astronomy Cast');

As you can see, @podcast is the shorthand notation for this.podcast in JavaScript. For this example, this references the global object. Let’s have a look at another scenario.

Podcast = () ->
    @name = 'Astronomy Cast'
    @download = (episode) ->
        console.log 'Downloading ' + episode + ' of ' + @name
    return @

# Outputs 'Downloading the first episode of Astronomy Cast'
podcast = new Podcast
podcast.download 'the first episode'

This results in the following JavaScript code:

var Podcast, podcast;

Podcast = function() {
    this.name = 'Astronomy Cast';
    this.download = function(episode) {
        return console.log('Downloading ' + episode + ' of ' + this.name);
    };
    return this;
};

podcast = new Podcast;
podcast.download('the first episode');

When calling a constructor function using the new operator, this references the new object being created. We've also explicitly added 'return @' in order to return the new object. Otherwise the function assigned to the download property is implicitly returned. Let’s move on to the next case.

podcast = 
    name: 'Astronomy Cast'
    download: (episode) ->
        console.log 'Downloading ' + episode + ' of ' + @name 

otherPodcast = 
    name: 'Hardcore History'

# Outputs 'Downloading the first episode of Hardcore History'
podcast.download.apply otherPodcast, ['the first episode']

Compiling this to JavaScript results into the following code:

var otherPodcast, podcast;
podcast = {
    name: 'Astronomy Cast',
    download: function(episode) {
        return console.log('Downloading ' + episode + ' of ' + this.name);
    }
};

otherPodcast = {
    name: 'Hardcore History'
};

podcast.download.apply(otherPodcast, ['the first episode']);

As I already mentioned in a previous blog post, we can reuse methods from other objects using the call()/apply() methods defined on the prototype of Function. In this example we reuse the download function in the context of the otherPodcast object. This means that this now references otherPodcast instead of the podcast object. Let’s dive into the final and most common scenario.

podcast = 
    name: 'Astronomy Cast'
    download: (episode) ->
        console.log 'Downloading ' + episode + ' of ' + @name 
        
# Outputs 'Downloading the first episode of Astronomy Cast'
podcast.download('the first episode')

The equivalent JavaScript code looks like this:

var podcast;
podcast = {
    name: 'Astronomy Cast',
    download: function(episode) {
        return console.log('Downloading ' + episode + ' of ' + this.name);
    }
};

podcast.download('the first episode');

Here this simply references the current object to which the executing function belongs to.

Function binding

Going over these different scenarios regarding the function context, it might be useful to be able to define a function that binds to the current value of this. In CoffeeScript we can use the => symbol instead of –> to accomplish just that. Let’s look at the code example from the CoffeeScript website.

Account = (customer, cart) ->
  @customer = customer
  @cart = cart

  $('.shopping_cart').bind 'click', (event) =>
    @customer.purchase @cart

This is especially helpful for event callbacks. The reason you might want to consider the ‘fat arrow’ in this case is that callbacks are executed in the context of the element, i.e. this references the element. When you want to keep this equal to the local context, without doing the self = this dance, then ‘fat arrows’ are the way to go.

Splats

Splats enable us to easily take a variable number of parameters in a function. JavaScript has a similar construct with the arguments object that is available in every function. But the major downside of the arguments object is that it lacks the semantics of an array which makes it pretty cumbersome to use. With splats, CoffeeScript provides us with a much better way to deal with a varying number of parameters.

download = (name, episodes..., epilogue) ->
    console.log 'Downloading ' + episodes.join(', ') + ' of ' + name;
    console.log epilogue

# Outputs 'Downloading the first, the second, and third episode of Astronomy Cast'
#          'What a hoot!'
download('Astronomy Cast', 'the first', 'the second', 'and third episode', 
         'What a hoot!')

This boils down to the following (nasty) JavaScript code:

var download;
var __slice = Array.prototype.slice;

download = function() {
    var epilogue, episodes, name, _i;
    name = arguments[0], 
    episodes = 3 <= arguments.length ? 
        __slice.call(arguments, 1, _i = arguments.length - 1) 
      : (_i = 1, []), epilogue = arguments[_i++];
    
    console.log('Downloading ' + episodes.join(', ') + ' of ' + name);
    return console.log(epilogue);
};
download('Astronomy Cast', 'the first', 'the second', 'and third episode', 
         'What a hoot!');

As you can see, splats don't have to be defined at the end of the parameter list. For this example, the first and last value get to be assigned to the regular parameters after which the remaining values in the middle of the list get assigned to the splat parameter. When we only specify two values, then these will be used for the regular parameters while the splat parameter will be null.

The values for the regular parameters get to be assigned first after which the remaining values all get to be passed to the splat parameter. This also implies that there can be only a single splat parameter for a given function definition.

Splats are not only available for function definitions, but also for calling functions as well.

download = (name, episode, epilogue) ->
    console.log 'Downloading ' + episode + ' of ' + name;
    console.log epilogue

# Outputs 'Downloading the first episode of Astronomy Cast'
#          'What a hoot!'
arguments = ['Astronomy Cast', 'the first episode', 'What a hoot!']
download(arguments...)

This simply boils down to calling the apply() method of the download function in the resulting JavaScript code:

var download;
download = function(name, episode, epilogue) {
    console.log('Downloading ' + episode + ' of ' + name);
    return console.log(epilogue);
};

arguments = ['Astronomy Cast', 'the first episode', 'What a hoot!'];
download.apply(null, arguments);

No doubt that CoffeeScript brings a lot of goodness to the table when it comes to functions. But there’s also a lot more. Stay tuned for the next couple of blog posts.

Until next time.

Taking Baby Steps with Node.js – Don’t Block The Event Loop

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

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

The basic premise of Node.js is that all I/O operations are expensive. That is why all I/O should be carried out asynchronously, at least according to the philosophy behind Node.js. What this basically boils down to is that we need to specify a callback function or bind to one or more events in order to get the outcome for a particular I/O related function that we want to execute. This means that things like file access, database operations, communication over HTTP, TCP or UDP, etc. … don’t block the main execution of a Node.js application.

One of the components that lies at the heart of Node.js is the event loop. This is basically a component that processes a queue of events and invokes an associated callback for each of these events. Tom Hughes-Croucher provides a very nice explanation in this article where he provides an analogy between the event loop in Node.js and a mail man:

To our event-loop postman, each letter is an event. He has a stack of events to deliver in order. For each letter (event) the postman gets, he walks to the route to deliver the letter. The route is the callback function assigned to that event (sometimes more than one). However, critically, since our mailman only has a single set of legs, he can only walk a single code path at once.

Since the event loop is running on a single thread, it is very important that we do not block it’s execution by doing heavy computations in callback functions or synchronous I/O. Going over a large collection of values/objects or performing time-consuming computations in a callback function prevents the event loop from further processing other events in the queue.

Doing synchronous I/O is also a bad thing for the same obvious reason that it blocks the event loop. There are a couple of synchronous I/O functions available in the Node.js built-in API. A few of these are exported by the file system (fs) module (the ones that end with …Sync). I strongly advise you to stay away from these functions.

There’s one synchronous, pseudo-global function that you probably have to use in any Node.js application besides the typical “hello world” example, and that is the require function. By executing the require function we can load another module into the process of our application. This means that the content of the corresponding JavaScript file for a requested module is read from disk. By caching this JavaScript content, Node.js ensures that such an expensive synchronous read doesn’t happen more than once when the require function is issued multiple times for the same module. Because we typically make a call to the require function at the beginning of a module, executing this synchronous function only affects the startup time of our application. Make sure that you do not call the require function inside a callback. In this scenario, the event loop is blocked until the requested JavaScript file is loaded from disk (unless the requested module is already in the cache, but don’t count on it).

The event loop that is baked into Node.js is a wonderful thing when building real-time applications. But it can turn into a nightmare when holding on to the paradigms of synchronous I/O. Node.js stands for asynchronous I/O and the event loop is the pumping heart that makes it happen.

Until next time.

Exploring CoffeeScript Part 2 - Variables and Functions

noreply@blogger.com (Jan Van Ryswyck) — Thu, 30 Jun 2011 10:00:00 +0000

As I mentioned in the previous blog post, CoffeeScript is a neat little language that compiles down to JavaScript code. Its syntax is heavily inspired by Ruby and next to bringing a lot of nice language features to the table, it also requires less amount of code than writing the equivalent directly in JavaScript. For this blog post, we’ll dive into some of this syntactic sugar by discussing variables and functions.

Variables

Declaring a variable in CoffeeScript is done like this:

podcast = 'Astronomy cast'

There’s no need to use the var keyword like in JavaScript. In fact, using the var keyword results in a compiler error. We also don’t need to provide a semi-colon at the end of the statement. These are added automatically for you during compilation. When we omit semi-colons in JavaScript, the engine also tries to add them at runtime but this behavior can cause a lot of grief. CoffeeScript correctly adds them for us, and although we no longer need to type in semi-colons, we’re still able to do so if we want to.

The variable declaration from above translates into the following JavaScript:

(function() {
  var podcast;
  podcast = 'Astronomy cast';
}).call(this);

The resulting code here is actually quite interesting. When we want to declare a local variable in JavaScript and we forget to specify the var keyword, then this variable ends up becoming a global variable instead.

/*var*/ f  = 'fubar';
console.log(window.f);    // Outputs 'fubar'

This can no longer happen just by accident when using CoffeeScript as it wraps all generated JavaScript in a self-executing function and by automatically emitting the var keyword before the variable name. We’re still able to create global variables but the only way is to declare them explicitly.

window.f = 'fubar'

The use of global variables is strongly discouraged when using JavaScript. As a result, the same goes for CoffeeScript as well.

Functions

The tedious function keyword in JavaScript is not part of the CoffeeScript syntax. Instead it uses an arrow to define a function.

log = (message) -> console.log message
log 'Podcast downloader 2000'

The syntax for defining a function in CoffeeScript is an (optional) list of parameters, followed by an arrow and then the function body. In this case, the code for the entire function is put on the same line. Multiple lines are also possible off course, but then the code for the function body needs to be properly indented as the CoffeeScript compiler uses significant whitespace to delimit blocks of code. This is not only for functions, but also for conditions, loops, try/catch statements, etc. … . Also notice that we no longer need to specify any parenthesis for the passed arguments when calling our log function.

The code for this simple example is translated into the following JavaScript code:

var log;
log = function(message) {
    return console.log(message);
};

log('Podcast downloader 2000');

Did you notice that the result of the call to console.log is returned to the caller of our log function? CoffeeScript simply returns the last expression of each function by default unless we explicitly use the return keyword.

CoffeeScript also provides a nice and useful keyword in case that we have a function without any parameters that we want to invoke directly.

do -> console.log 'Podcast downloader 2000'

The do keyword just executes a function directly without having to assign it to a variable and invoke it on the next line. The resulting JavaScript code is a call to console.log wrapped in a self-executing function:

(function() {
    return console.log('Podcast downloader 2000');
})();

In JavaScript we have both function expressions and function declarations. You can read this blog post to learn more about both these concepts. CoffeeScript only supports function expressions.

download 'Astronomy cast'

download = (podcast) -> 
    console.log podcast

The first line of code for this example will give us the following compiler error:

TypeError: undefined is not a function

In order to get this code to compile, we need to change this code to the following:

download = (podcast) -> 
    console.log podcast
    
download 'Astronomy cast'

CoffeeScript also supports default parameter values, but this feature is implemented in a different way than what we’ve been used to see to in other programming languages.

download = (podcast = 'Astronomy Cast') ->
    console.log podcast

download 'Hardcore history'        # Outputs 'Hardcore history'
download()                         # Outputs 'Astronomy Cast'
do download                        # Another way of calling download, but without ()
download null                      # Still outputs 'Astronomy Cast'
download undefined                 # Still outputs 'Astronomy Cast'

In other programming languages, a default value for a parameter is used when a value is omitted in the function call. CoffeeScript takes this a bit further and also uses a default value if null or undefined is explicitly specified in the function call. This might look weird at first, but this also implies that the optional parameters do not have to appear last in the parameter list.

foo = (arg1 = 'default1', arg2 = 'default2', arg3 = 'default3') -> 
    ...
    
foo null, 'not_default', null

Fascinating language, isn’t it?

There is much more to be said about functions in CoffeeScript, but I will discuss those features in the next couple of blog posts.

Until next time

Book Review: Hands-on Node.js

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

Last week, I finished reading Hands-on Node.js written by Pedro Teixeira. I very much enjoyed reading this concise introduction to Node.js, and although it’s targeted towards beginners, I certainly managed to pick up a few nuggets myself here and there.

After the obligatory introduction, the first chapter opens up with an explanation of why Node.js runs on an event loop and why JavaScript eventually got chosen as the preferred language.

The next chapter shows how to install Node.js on different platforms and also how to get npm up and running.

Chapter 3 discusses the event loop and modules. These first three chapters make up the first part of the book, which provide you with a more theoretical understanding of what Node.js is all about.

The next part of the book contains the chapters that go over the different aspects of the 25 built-in modules that come with Node.js. As the title implies, these chapters contain a lot of code examples and also provide the reader with a good amount of exercises (and also solutions). There are even a chapters that discuss how to debug and unit test Node.js applications.

So, if you want to start out learning about Node.js then this book is your first stop. You can buy the ebook directly from the author for only $ 4.99! Pedro certainly knows his stuff when it comes to Node.js, so this is a real bargain. Also make sure to check out his excellent screencast series on this very topic which are free to watch and download.

Happy learning!

Exploring CoffeeScript Part 1 – And Then There Was Coffee

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

Those of you who have been reading this blog lately know that I’m quite enthusiastic when it comes to JavaScript. As the common behavioral language of the web, JavaScript has been making its way into other aspects of application programming over the last couple of years, notably with server-side frameworks like Node.js and NoSQL databases like CouchDB. I personally find JavaScript to be an awesome programming language, especially when you stick with the good parts. So I’m more than pleased that JavaScript is finally making its way out of the browser to fulfill other purposes as well.

But a couple of months ago I ran into another programming language called CoffeeScript. This neat little language, created by Jeremy Ashkenas, simply compiles its syntax into JavaScript code. In fact, there’s no interpretation of CoffeeScript code at runtime. CoffeeScript essentially builds on top of JavaScript as the core language while adding some syntactic niceties that are heavily inspired by Ruby. The CoffeeScript compiler emits very clean JavaScript code that not only follows best practices but also complies to JSLint without warnings. This all basically means that wherever you can use JavaScript, whether it’s in the browser, on the server-side or for a particular database, you can use CoffeeScript as well. In fact, you can use any JavaScript library right in your CoffeeScript code!

But why should one use CoffeeScript over JavaScript? Well, for starters, the CoffeeScript syntax is much more concise than its JavaScript equivalent. There’s a lot less typing involved for getting the equivalent JavaScript code. Check out this example on the CoffeeScript wiki.

Second, the CoffeeScript language is much richer than JavaScript. It add splats, classes, destructuring assignments and many more small details that makes your code more readable and fun.

And thirdly, because the creator of Ruby on Rails, David Heinemeier Hansson, says so :-). The upcoming 3.1 release of Ruby on Rails will include CoffeeScript in the box, which means that other web frameworks will probably also add support for CoffeeScript in the future.

Enough with the marketing talk already. Let’s have a quick look at how to get CoffeeScript up and running. For starters, you need to have Node.js and npm installed. Check out the installation guide or Matthew Podwysocki's on how to get Node.js up and running on Windows using Cygwin.

When you have node.js all set up, you can simply use the following command to install the CoffeeScript compiler using npm:

npm install -g coffee-script

Now that we have CoffeeScript installed, we can compile .coffee files into .js files or we can use the interactive REPL. Let’s go for the canonical “Hello Pluto” example here and create a file named hello.coffee with the following code:

console.log 'Hello CoffeeScript'

Notice that we don’t have to provide parentheses here in order to call the console.log function. Next we can use the following command to print the compiled JavaScript directly to our console window:

coffee -p hello.coffee

or we can use this next command to compile our hello.coffee file to a corresponding hello.js file at the same location in the file system:

coffee -c hello.coffee

The compiled JavaScript output looks like this:

(function() {
  console.log('Hello CoffeeScript');
}).call(this);

You might wonder why the call to console.log is wrapped into a self-executing function. The reason for this is to prevent naming collisions when using our code in conjunction with other JavaScript libraries. You can tell the CoffeeScript compiler to omit this self-executing function by specifying the –b, –bare command-line option.

We’re also able to keep the CoffeeScript compiler running with the –w, --watch command-line option. This basically lets the CoffeeScript compiler watch for the specified .coffee files and recompile them as soon as they’re changed.

coffee -cw hello.coffee

So these are the very basics on how to get up and running with CoffeeScript. Expect to see more of the interesting stuff that this amazing programming language has to offer as I’m going to be writing a couple of more blog posts about CoffeeScript. I certainly recommend that you have a decent knowledge of JavaScript before you pick up CoffeeScript. Being able to understand the JavaScript code that is emitted by the CoffeeScript compiler can be crucial at times.

Until next time.

Taking Baby Steps with Node.js – The E-VAN Presentation

noreply@blogger.com (Jan Van Ryswyck) — Wed, 15 Jun 2011 21:26:00 +0000

The recording of my very first E-VAN talk on Node.js is now available. If you want to hear me blabbering on about Node.js then I suggest you have a look.

A Quartet of Book Reviews

noreply@blogger.com (Jan Van Ryswyck) — Fri, 27 May 2011 23:09:00 +0000

Since a couple of months or so, the amount of time spent for my daily commute to and from work nearly tripled. I also decided to travel by train instead of using my car (which kind of explains the increase of my travelling time). So, trying to make the best of things, I decided to catch up on my reading backlog. For this blog post, I’m going to briefly discuss the books I’ve read so far.

1. The 48 Laws of Power

The 48 Laws of Power, written by Robert Greene, totally blew me away. I can’t remember where I picked it up or who brought this book to my attention, but kudos anyway. The basic premise of this book is that some strategies keep you in control, while other acts of human nature decrease your influence. This book isn’t necessarily about you gaining power over others, as it is more about actions that prevent others from manipulating or gaining control over you or your close environment. Every law is illustrated with real-life stories about historic figures and how their actions put them in a powerful position or how their mistakes drove them to a cliff.

I wish I had read this book many years ago, but better late than never, right? I’m definitely going to reread several portions of this book in the near future in order to get a better grasp of some these laws. I have to admit that sometimes, this book is a bit much when you read it for the first time.

2. Dinosaur Brains – Dealing with All Those Impossible People at Work

I had this book literally collecting dust on my bookshelf for several years now, so finally being able to read this book has been well overdue. Dinosaur Brains, written by Albert J. Bernstein and Sydney Craft Rozen, is all about how we sometimes react and behave purely by our primal instincts, when the cortex in our brain loses control and falls back on lizard logic in some situations. Funny enough, this book has taught me more about myself than about my current co-workers or former colleagues. This metaphor of a prehistoric creature illustrates how our brain triggers a fight, flight or freight response that is sometimes well beyond our control. But this isn’t a lost cause either. This book not only provides the rules of the dinosaur brain, but it also contains a lot of advice on how to use this knowledge to your own advantage. So, overall a very interesting read.

3. Drive - The Surprising Truth About What Motivates Us

I picked up Drive – The Surprising Truth About What Motivates Us after I watched this inspiring talk by Daniel Pink, which I briefly mentioned in this blog post. The author makes a very strong case for what he calls Motivation 3.0, which is based on three concepts:

Autonomy – based on the principles of self-direction, this lets knowledge workers decide how, when and where to do their job.
Mastery – getting people in a state of “flow” by letting them work on stuff that they’re passionate about. “Flow” is a state of mind that where time seems to be passing by without noticing. The author clearly explains why a restrictive working environment prevents people from getting into their “flow”.
Purpose – the believe that there’s more to work than just making money. The fact that there’s meaning in what you do day in and day out, enables our intrinsic motivation.

I also couldn’t help but notice that this book tends to lay out the basics of systems thinking, which is a topic that I definitely want to learn more about.

Do yourself a favor, pick up and read this book or at the very least, watch this excellent talk. Buy this book as a gift for your boss and tell him that all the cool managers are reading this book ;-).

4. Pragmatic Thinking and Learning – Refactor You Wetware

Pragmatic Thinking and Learning, written by Andy Hunt, is also a book that I wanted to read for quite some time now. As he is one of the co-authors of The Pragmatic Programmer, I had some very high expectations. And I must say that those expectations were only partially fulfilled. The first few chapters were a reiteration of Daniel Pink’s book A Whole New Mind, but then applied to the world of software development. There was even some content in there from the book Dinosaurs Brains, which I had just finished reading at the time. But if you haven’t read these two books before, then these first chapters will definitely be an eye opener.

Nonetheless, I did manage to pick up a few neat ideas about learning in general and how to apply those to my own learning activities. But I couldn’t get rid of the feeling that most of the content was just an iteration of what I already picked up from other books and articles.

Don’t get me wrong here. This is truly a great manuscript with a lot of gems in there. If you’re not already familiar with this stuff, then this book will definitely rock your boat and I would highly recommend it.

So, happy reading and until next time.

Taking Baby Steps with Node.js – npm 1.0

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

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

Isaac recently released version 1.0 of npm, which is a package manager for Node.js. I’ve been using npm very early on when I started fiddling with Node.js and I’ve come to rely on it quite heavily. After I upgraded to one of the release candidates, I noticed a big improvement in how and where packages are being installed.

With the old version that I was using (0.3.15), all packages where installed globally. You could install multiple versions of the same package, but this implied that we also had to take this into account when we loaded a particular module in our application:

var step = require(‘connect@0.2.7’);

Although this worked great, it’s still my humble opinion that all third-party modules should be right along the source code of the application that I’m building. With the npm 1.0 release, this has now become the default behavior.

Installing npm 1.0 is as simple as executing the following in the command-line:

curl http://npmjs.org/install.sh | sh

Executing this command asks the user whether any old versions of npm should be removed. You can also execute the following if you don’t like to be prompted:

curl http://npmjs.org/install.sh | clean=yes sh

In a previous post, I discussed a new convention introduced in version 4.0.x of Node.js for loading third-party modules from a folder named node_modules that is typically created in the root folder of a project. When installing a package, npm adheres to this convention by locally installing this package into this node_modules folder.

Say, for example, that we want to use Socket.IO in our application. We just need to run the following command from the root folder of our application:

npm install socket.io

This will locally install the requested third-party module into ./node_modules/socket.io. If a particular package includes a binary, then these will go into ./node_modules/.bin/. Now we can simply load the installed module without specifying a specific version number:

var socketIO = require('socket.io');

So what do we do if we want to install packages that are typically used from the shell and not by the source code of the application, like n, node-inspector or nodemon? Well, we can still get them installed globally using the –g command-line switch:

npm install -g n
npm install -g node-inspector
npm install -g nodemon

This ability to install packages either locally or globally is probably the most obvious new feature that has been shipped with the 1.0 release. There are several other new features and enhancements as well, but I haven’t ran into those (yet).

Apparently, there will also be no new major features or architectural changes for quite some time. So this gives us plenty of time to get to the bottom of all the new capabilities of npm. This local/global installation of packages alone is certainly worth upgrading to the 1.0 release.

Until next time.