Getting my Mongo on

Posted on by mookid8000 11 Comments

This is the sixth post in a small series on Node.js. In this post, I will take a look at how to use my MongoDB from a Node app.

First, let’s install a driver for MongoDB: node-mongodb-native:

NPM really make it easy to get going!

Now, in order to connect to MongoDB, do this:

This should be done only once when the application starts up.

Then, to access a collection, do this:

Inside the function above, coll gives you access to do all the usual stuff to a MongoDB collection. To name a few, there’s insert, find, findOne, ensureIndex, count, etc.

As the node-mongodb-native documentation is pretty sparse, I’ve found it useful to open up a Node.js shell and connect with the driver, allowing me to inspect the various objects’ properties and methods, e.g. by inspecting db.__proto__ like so:

and coll.__proto__ like so:

Of course this way of barfing functions all over the place is not pretty, but it makes it possible to get a glimpse of what kinds of operations that can be performed on the various objects.

What is that module thing again?

Posted on by mookid8000 3 Comments

This is the fourth post in a small series on Node.js. In this post, I will take a look at how the Node.js module mechanism works.

In my previous posts on Node.js, I nonchalantly went ahead and require(...)d something called http – but what was that? And what happened when I did that?

Well, require is one of the few globals when running a Node program, and it is used to import a module. The parameter is a string, which Node uses to look for a file to load.

The simplest usage refers directly to a file relative to the path of the currently running program. E.g., if I have a module residing in a file called importantBizLogic.js in the lib folder beneath my program’s directory, I can include its exports (which I’ll get back to in a moment :)) like so:

If I omit the ./, Node will go look for importantBizLogic in each directory in the require.paths array, which is a list of default paths to search for modules.

Let’s see what it contains… Go to a terminal and enter the Node shell:

Great – so that’ s where my global modules reside. Now, what was that export thing again?

Well, that’s related to how importantBizLogic.js is structured… in order to control how the import works, a module must explicitly export stuff – and that can be done like so:

– allowing this module to be imported and used like so:

Nifty!

Apparently – and I am almost embarrassed that I did not know that – there is a thing called CommonJS, which is an initiative that strives to create a JavaScript standards library – and the require stuff I’ve described here is actually just Node implementating the CommonJS Modules specification. Pretty sweet, actually!

Up and running with Express

Posted on by mookid8000 7 Comments

This is the third post in a small series on Node.js. In this post, I will take a look at how to get up and running with Express.

Let’s get Express installed – first, let’s install NPM – a package manager for Node:

That was easy. Now, Express can installed like this:

Too easy!

Now, let’s create a simple app like we did the last time:

Punch in the following few lines:

and run the app from the terminal like so:

and navigate to http://localhost:3000 – on my machine it looked like this:
Hello Express

That was easy. See how the API pretty much resembles Node’s builtin HTTP server, except it adds routes into the mix!

Now, in order to build a web site we need some kind of view engine to help generate some HTML for us. I have used Haml a couple of years ago, and I really liked it… and luckily, some nice people have made Haml available to Node apps, so let’s try installing that:

Now we configure Express by punching in the following stuff in the app:

As you can see, I tell Express to use Haml as the default view engine. Moreover, I configure Express to serve static content from the /public folder in my app dir, and then I install the bodyDecoder middleware which will parse incoming posts and make posted values available in req.body.

Now, let’s alter our action to render a view:

and now create two files, layout.haml and index.haml in the /views folder. Mine look like this – /views/layout.haml:

and /views/index.haml:

Now, let’s go to the terminal and node app.js and navigate to http://localhost:3000 – on my computer it looks like this:
Hello Express + Haml

As you can see, view models can be handed to the view via the locals object.

This was some basic web app stuff – only thing missing is some way to persist data, so next time I will take a look at how to get my Mongo on…

Getting started with Node.js

Posted on by mookid8000 Leave a comment

This is the second post in a small series on Node.js. In this post, I will take a look at how to get started and run the ubiquitous “Hello world” sample.

First, create a directory somewhere and Git clone Node… I did it like this:

Then, build and install Node like this:

If you get permission errors during the last step, you might need to do a

to grant yourself ownership of everything beneath /usr/local. Note however, that this should probably only be done if the machine is your own personal machine.

Now, try typing node -v in the terminal… I got this:

Now, let’s finish this post by creating a Node app like so (using TextMate or whatever you prefer):

Punch in the following few lines:

and go the terminal again and type

which yields

Now, when I navigate to http://localhost:8124 I get this:

Node.js HTTP Hello World

Nifty, huh?

In the next post, I will see if I can get up and running with Express – a simple but powerful Sinatra-like web framework for Node.

I want to learn Node.js

Posted on by mookid8000 2 Comments
Preface

More than three years ago, I watched a couple of videos with Douglas Crockford that changed my view on JavaScript completely!

I must admit that I too used to consider JavaScript a toy language, somehow inferior to “real programming languages” like Java and C#.

This view was of course induced by the sheer amount of JavaScript crap code available to copy/paste from the web, almost always operating on an equally crappy non-standards compliant DOM implementation in some crappy browser – but after watching those videos I actually began to understand that JavaScript was a pretty cool and powerful language.

Some time after, Crockford released JavaScript: The Good Parts which I immediately read, and at that time I remember saying to one of my colleagues: “I think it would be cool to build large systems in JavaScript”.

At that time, stuff like Rhino was around, but I had never heard of anyone actually using it, and executing JavaScript on the JVM by compiling JavaScript into Java into bytecode didn’t sound sexy at all to me.

Today

Recently, however, I have somehow come across Node.js at different occasions, and I have really been meaning to check it out. If you don’t know what Node is about, I can quote the homepage: Node is “Evented I/O for V8 JavaScript.”

That’s right! Let’s break that down:

  • Evented: There’s only one thread executing in a Node process, high throughput is achieved by doing asyncronous I/O, queueing callbacks to be executed upon completion.
  • I/O: Not usually what JavaScript is used for, but this covers the fact that Node has APIs that treat the file system and TCP and HTTP as first class citizens.
  • V8: The JavaScript is executed by the V8 JavaScript Engine that Google in Aarhus built for Chrome.

As an example, there’s the ubiquitous code sample that you’ll see everywhere – opening a HTTP server in Node:

As you can see, Node has a nice and thin API for working with HTTP, and as I envy Rubyists of having Rack and Sinatra, and as I am interested in how web frameworks work in general, this code sample has continued to spark my interest.

Therefore, in order to push myself through learning more about it, I have decided to see if I can write a couple of blog posts on Node.js. I will try to cover the necessary topics to develop a simple web app, and I expect to come across more or less of the following:

  • Acquiring Node.js and running a “Hello world” script. Can’t do anything without having done this.
  • Basic Node stuff, like how to structure code into files/modules/whatever and whatnot.
  • Bringing in external, possibly native libraries.
  • Building a web app, possibly with Express – a simple web framework for Node.
  • Persisting some data, probably using node-mongodb – a MongoDB driver for Node.
  • Unit testing my app – probably with the built-in assert API.
  • Hosting my app – probably with Nginx as a router and load balancer.

Wow! – that was a lot of words and almost no code… I promise that my next posts on Node will have more code in them.

When jQuery was released…

Posted on by mookid8000 Leave a comment

…web development changed forever! (to me at least :))

It’s amazing how the CSS-selector-based approach has proven its effectiveness and durability, and combined with the incredible wealth of extensions, choosing jQuery is simply a no-brainer.

By the way, jQuery 1.4 has been released. Check out this post for a walkthrough of some of the new features.

How JavaScript’s closures surprised me

Posted on by mookid8000 Leave a comment

Well, it happened when I was making a web page on which the user could pick a number of time slots. The time slots would be configured using a calendar and a couple of time entry controls, and the user would add the time slot by clicking a button. The selected time slots would be stored as a JSON serialized array of time slots in an input element.

The selected time slots would be shown in a list on the page, each one with an X on the side which could be used to remove the appropriate time slot. The problem was, that it did not remove the appropriate time slot. But why?

It’s because of the way JavaScript’s closures are implemented!

You see, my code was something like this (using Crockford’s JSON library and the incredible jQuery):

What happened when I tried to remove the time slots? The most recently added time slot would get removed all the time, even though I clicked the first and the second etc.

At this point, I knew it was due to some JavaScript function closure stuff, because I could see that my click event handler would call removeTimeSlot with the id of the most recently added time slot all the time.

But why was this happening? I made all kind of changes to the snippet, moved the variables around, made several temporary variables, but the problem persisted!

Then I searched around, and I discovered two things that I did not know about JavaScript (and would not have expected):

  1. Variables reside in the function in which they are declared.
  2. Functions get the closure of their containing function.

I am a C# guy, and in C# I know that an anonymous delegate gets the closure that it needs and nothing more. I also know that variables declared inside the scope of for instance a for loop are local to that loop. So doing stuff like this would not cause any unexpected behaviour:

To put it another way, it means that my code was actually equivalent to this (notice how all my variabled are “declared” at the top of the function):

To circumvent this, I created an inline function which would deliver the DOM element with the link. Something like this:

– and from now on, to avoid unnecessary confusion, I will stop declaring my variables anywhere except the beginning of each function.

Lastly, I would like to give some shoutouts to the Mozilla folks for driving us all forward. Firefox 2 actually implements JavaScript 1.7, in which let was introduced as a keyword. let creates a new lexical scope and fixes one or more variables, which will then be promoted to a closure if necessary. Using let, my code would look like this:

– which is a lot simpler than the inline function version I ended up using. However, JavaScript 1.7 is not implemented by other browsers than Firefox 2 and Safari 3.x (according to Wikipedia) so it’s not really an option yet.