In this post, we’re going to make that example slightly more complex by introducing dependencies within the modules. Now the code must be able to handle these dependencies for both the client side and the server side.

In the last post, we built a simple module consisting of a single function that returned a greeting:

var Greetings = function() { }
Greetings.prototype.hello = function(who) {
   return "Hello "+who;
}
module.exports = Greetings;

At this point, it would be very useful to sanitize and validate the parameter passed to the “hello” function. We could obviously build this functionality directly into the code, but this is exactly the sort of thing that should be abstracted into its own module(s).

For the purpose of this example, we’ll simply include the functionality to give the parameter passed a “trim”; after some hacking and snippet-borrowing from node-validator by Chris O’Hara, we can build another simple module called Tidy:

var Tidy = {
   whitespace: '\\r\\n\\t\\s',
 
   trim: function(str) {
      var whitespace =  '\\r\\n\\t\\s';
      str = str.replace(new RegExp('^['+this.whitespace+']+|['+this.whitespace+']+$', 'g'), '')
      return str;
   }
}
module.exports = Tidy;

We can now improve our Greetings module, including the dependency and functionality:

var Tidy = require('./tidy');
 
var Greetings = function() { }
Greetings.prototype.hello = function(who) {
   who = Tidy.trim(who);
   return this.hello(who);
}
module.exports = Greetings;

To see if this will work as expected, let’s add some spaces to the parameter passed in the NodeJS script:

var Greetings = require('./greetings');
var greetings = new Greetings();
console.log(greetings.hello('  Node   ')+"!");

When we run it, this is what we see:

$ node runner.js
Hello Node!

Good, so this works on the server side, but let’s test its behaviour on the client side. Again, we should add some spaces to the parameter passed to ensure that it is working:

<script type="text/javascript"> </script>
<script src="greetings.js" type="text/javascript"> </script>
<script type="text/javascript"> </script>

Unfortunately, we now see the following error:

require is not defined
[Break On This Error] var greetings = new Greetings();

Our attempt to “require” the dependency in the Greetings module has broken the client side. To fix this, we need to define our own require() function, much like we had to for the module object. We do this by creating a new front end-only script, which we’ll call “middle-end.js”.

var require = function(module) {
   document.write('<script src="'+module+'.js" type="text/javascript"> </script>');
}
 
var module = {
   exports: undefined
};

(Obviously we should include much more error checking, but this will be enough for our example).

We modify our html as follows:

<script src="middle-end.js" type="text/javascript"> </script>
<script type="text/javascript"> </script>
....

Now when we reload the page in the browser, all should work as expected. Huzzah!

This is just a very simple example of what can be done when JavaScript code is shared between the client and server sides—the “Middle End”. This concept becomes really exciting when you start thinking about potential approaches to form validation, session management, and even display logic. This is definitely something worth playing around with.

All of the code is available as a Gist.

In my previous post, I talked about Kyle Simpson’s concept of a Middle End—a layer between the front end and back end. Today, I’m going to sketch out my very simple experiments with constructing such a layer.

What I am focusing on here is simply a means of sharing JavaScript code between the client side and the server side.

Let’s start with a very simple NodeJS Module, greetings.js:

var Greetings = function() { }
Greetings.prototype.hello = function(who) {
   return "Hello "+who;
}
module.exports = Greetings;

Next, let’s create a very simple NodeJS script that imports this module, and uses it:

var Greetings = require('./greetings');
var greetings = new Greetings();
console.log(greetings.hello('Node')+"!");

When we run it, this is what we get:

$ node test.js
Hello Node!

All very simple stuff.

Now, suppose we want to use the Greetings module in our front end web app. 

<script src="greetings.js" type="text/javascript"> </script>

Well, it runs and we get the desired output. However, Firebug reports an error within the greetings.js file:

module is not defined
[Break On This Error] module.exports = Greetings;

The solution to this issue is to “mock up” the module object so the error isn’t thrown:

var module = {
   exports: undefined
};

Run it again, and now we see no errors.

Great, so it’s working. We can share simple modules between the client and the server sides.

But what if we want to have a more complex module? One that has some dependencies?

That will be discussed in the next post.

All of the code is available as a Gist.

What I have been working on is having a single parent process that runs constantly in the background, and this parent is responsible for child processes which actually do the work. One thing I found particularly interesting was how the parent can handle a child crashing, and also what happens to the children when the parent is killed. Below is the culmination of my hackings, it comprises of two simple scripts, a child script, and a parent. I have committed them to my GitHub account, so feel free to clone, fork, hack or whatever.

Note: Node version at time of writing was v0.4.9 and running off a Debian machine.

Child Worker

For this experiment we need a really simple child script. It doesn’t have to do anything apart from tell us it is alive when it is running, and then kill itself so we can see how the parent handles this event.

The main bulk of this script is the loop:

var child_loop = function() {
   // report the current loop
   console.log("Child loop: "+NUMBER_OF_LOOPS);
 
   // to simulate the child exiting itself without just running
   // out of program, if we have completed the desired number of
   // loops, exit this process
   if( NUMBER_OF_LOOPS < 0 ) {
      console.log("Child finished loop");
      process.exit();
   }
 
   // sleep for a bit, then continue through the loops
   setTimeout(function() { child_loop() }, LOOP_SLEEP_TIME);
   NUMBER_OF_LOOPS--;
}
 
// start the loop
child_loop();

As you can see this loops for NUMBER_OF_LOOPS, outputting what loop it is currently on. At the end of the loop it kills itself, informing us whilst it does it.

So, this is fine whilst the child is running, but we also need to try and get the child to clean up after itself if it is killed by an external process – i.e. the parent. After some playing around and reading of the documentation, I ended up with this:

// detect and report if this child exited
process.on("exit", function() {
   console.log("Child exiting");
});
// detect and report if this child was killed
process.on("SIGTERM", function() {
   console.log("Child SIGTERM detected");
   process.exit();
});

I need to go more in depth, but whilst testing, this seemed to correctly handle the child being terminated externally.

So, that’s the child script. You can run this directly from the command line and it does what is expected. Good, so we’re all ready to build the parent so it can spawn multiple children.

Parent

This was the main focus of the experiment. The chief concerns were:

• Ensuring the process ran indefinitely as a daemon
• Spawning the children
• Handling a child that crashed or exited
• Cleaning up the children when the parent was exited

The first point is relatively simple, all we need is an indefinite loop:

loop = setInterval(function() {
   // functionality here
}, LOOP_SLEEP_TIME);

Handling the children was a little more complex. In the end I created an array that would contain the children. Within the main loop, I then ran through that array, checking to see if the child existed, if not then spawning it. Notice how the loop is returning itself into the variable “loop”. This will be important later.

var spawn = require('child_process').spawn;
var loop = setInterval(function() {
   for(i=0; i

This is fine for creating the children, but then what if a child dies? Simple really. The parent needs to listen for the exit event on the child. When detected, ensure that the array element for that child is cleaned out, and then in the next loop, the child will be respawned.

children[i].on('exit', function (code) {
   children[i] = undefined;
});

Next, what if the parent is killed. We need to make sure we don’t leave any orphaned children behind. After some playing around, I found that two events needed to be listened for. Again, the exit event, this time on parent, but also the SIGTERM event on the parent.

When a SIGTERM event is detected, we simply tell the script to exit cleanly:

process.on("SIGTERM", function() {
   console.log("Parent SIGTERM detected");
   // exit cleanly
   process.exit();
});

Now, when the exit event is triggered, we can clean up the children. One thing we must also do, is stop the Interval of the main loop. If we didn’t do this, when the children were killed, the next “tick” of the loop, then they would all be created again. It’s possible that this could happen before the main script has exited, orphaning the children. We can eaily do this as we have the variable that the setInterval call has been saved into.

process.on("exit", function() {
   // ensure no more "ticks"
   clearInterval(loop);
 
   // kill all children!
   for(i=0; i<TOTAL_CHILDREN; i++) {
      if(children[i] != undefined) {
         console.log("Kill child "+i);
         children[i].kill();
      }
   }
});

That is it for the main bulk of the script. As I’m testing and running it on Debian I am using start-stop-daemon to run the parent as a daemon. As such I’ve had to add the functionality for creating a .pid file. One issue I had with this, and I have no idea why, is when I tried to write the process.pid value to a file it filled the file up with nonsense. However, if I converted it to a string (which from what I can tell it already was) before writing it to the file, then it worked fine.

var pid = ""+process.pid; // need to turn into a string
fs.writeFile('/tmp/parent.pid', pid, function (err) {
   if (err) throw err;
});

You can see the complete parent and child scripts on my Github repository.

Running

Now we have our scripts, we need to run them to see if they actually behave as expected. In Debian (and derivatives) this is pretty simple:

To start

start-stop-daemon --start --exec /home/rob/workspace/NodeJS/process/parent.js --pidfile /tmp/parent.js.pid

And to stop

start-stop-daemon --stop --pidfile /tmp/parent.js.pid

As we are not running the process in the background then you will need to have two terminal windows open. Also, you will be able to see the output which explains what is going on.

You should be able to easily convert the script to log to a file (I recommend Vision Media’s Log.js) and then write an init.d script using the start-stop-daemon functionality to create a background daemon process .

You should be able to see that we now have the ability to run a Node.JS daemon process which can spawn multiple children, ensuring it can keep a consistent number of children available, and then handle the cleanup if that daemon process is killed. This opens up lots of possibilities!

Again, feel free to clone, fork, hack, improve, etc the code for this.

Not as easy as I first thought. It turns out that you have to empty buckets before you can delete them. Fair enough, but there didn’t seem to be a way to easily bulk delete hundreds of images.

After some Googling I found Robert LaThanh’s S3Nukem which looked like it would do the job. All I needed to do now was fire up an EC2 instance, install and run. The steps were as follows:

1. Create an EC2 instance on AWS (I used Ubuntu on a medium instance)
2. make sure it is all up-to-date

   apt-get update
   apt-get upgrade

3. install ruby (if not already installed)

   apt-get install ruby1.8 ruby1.8-dev

   (not sure about ruby1.8-dev, but added just in case)

4. install Ruby Gems

   apt-get install rubygems

5. install right_aws and s3nukem

   gem install right_aws
   cd /tmp
   wget http://github.com/lathanh/s3nukem/raw/master/s3nukem --no-check-certificate
   chmod +x s3nukem

6. run

   ./s3nukem -t 20 -a  -s

Several hours and over 15 million deleted images later it was all done and I shut down the instance.

.. extremely fast, small, dynamic and heavily extensible using the Lua programming language

I’ve never delved into Lua before, but since using Awesome I’ve had to play around with a bunch of config files. They have always looked very clean and simple so, this weekend, with a spare couple of hours to kill I thought I’d have a play around with Lua and see if Awesome really is as “heavily extensible” as the claims make out.

A couple of weeks ago I set up real time web analytics on a number of sites with Clicky. Clicky have an incredibly simple API which I thought would be perfect to play around with.

I decided to try and build a widget that displays the total visitors and actions for a specified website. Really simple, but also quite useful. I had never written anything in Lua before, or even played around with widgets too much in Awesome. Fortunately both Awesome and Lua made the whole thing fantastically easy and fun. What follows is the code I wrote, use it if you want to, it’s just an example of what I did with my first attempt, so feel free to extend it as you want.

First, include the code below in a file called “clicky.lua” in your ~/.config/awesome directory. Note, you will also need to add the dkjson.lua file there too, which you can find at http://www-users.rwth-aachen.de/David.Kolf/json-lua.

-- we need the dkjson library
-- can be found here:
-- http://www-users.rwth-aachen.de/David.Kolf/json-lua
json = require ("dkjson")
 
-- Site ID and Key for Clicky
site_id = "[YOUR-CLICKY-SITE-ID]"
site_key = "[YOUR-CLICKY-SITE-KEY]"
 
-- the clicky object
Clicky = {
   actions = "n/a",
   visitors = "n/a",
 
   update = function(self, widget)
               j = self:get_json()
               self:parse_json(j)
               widget.text = Clicky.visitors .. "/" .. Clicky.actions
            end,
 
   -- call the Clicky API, expecting JSON in return
   get_json = function(self)
               clicky_url = "http://api.getclicky.com/api/stats/4?site_id="..site_id.."&sitekey="..site_key.."&type=visitors,actions&date=today&output=json"
               -- get the visitors and actions for today
               command = 'curl -s "'..clicky_url..'"'
               f = io.popen(command)
               if (not f) then return 0 end
               -- store the returned json as a string
               return f:read("*all")
            end,
 
   -- parse the JSON from Clicky
   parse_json = function(self, j)
                   local obj, pos, err = json.decode (j, 1, nil)
                   if err then
                      self.actions = "e"
                      self.visitors = "e"
                   else
                      for k,v in pairs(obj) do
                         if v["type"] == "actions" then
                            self.actions = v["dates"][1]["items"][1]["value"]
                         end
                         if v["type"] == "visitors" then
                            self.visitors = v["dates"][1]["items"][1]["value"]
                         end
                      end
                   end
                end
}
 
-- init the widget
myclickystats = widget({ type = "textbox", name = "clicky", align = "right" })
myclickystats.text = "Clicky"
 
-- get the initial update
Clicky:update(myclickystats)
 
-- now poll every 15 minutes
minutes = 15
myclickytimer = timer({ timeout = 60 * minutes })
myclickytimer:add_signal("timeout", function() Clicky:update(myclickystats) end)
myclickytimer:start()

Now, in your ~/.config/awesome/rc.lua file you need to insert two snippets.

Towards the top of the file, add

-- Include my Clicky stats
require("clicky")

and within the screen loop add the myclickystats widget

for s = 1, screen.count() do
   ...
    -- Add widgets to the wibox - order matters
    mywibox[s].widgets = {
        ...
        s == 1 and myclickystats or nil,
        ...
    }
end

and that should be it. Restart awesome with <Super> – <Ctrl> – r and if you have done everything right you should see something like x/y in the top right of your screen. (Disclaimer: the above setup works for me on Ubuntu 9.10 and Arch, but if Awesome doesn’t restart you’re on your own!)

After building this simple widget I have learnt a lot about both Lua and Awesome.

On this, my first impression of Lua, it seems very simple and clean but also probably quite powerful, something I’ll definitely play with more.

Update: added screenshot after tweet from @getclicky.

In the first part of this tutorial we looked at reading a document from CouchDB and keeping our markup separate from our code using Haml templates. We arrived at the point where we clicked on a link, but nothing happened. Today we are going to put that right with some very simple routing.

The URL Module

The basis of all routing is the URL. Fortunately, Node has some basic functions which handle reading the URL so we can then decide what the user is actually trying to do.

First, we want to make sure we have included the URL module.

var sys = require('sys'),
fs = require('fs'),
http = require('http'),
url = require('url');

The next step is to extrapolate the path name from the URL that the user has visited:

var url_parts = url.parse(req.url);
sys.puts(url_parts.pathname);

Now, when I go to http://127.0.0.1:8000/create in Chromium, the system output is as follows:
/create
/favicon.ico

As you can see I have to deal with /create but also /favicon.ico – unfortunately I don’t have one. We’ll deal with that later by using a 404 error.

The pages we want to be dealing with are as follows:

• /
• create
• /edit

For simplicity’s sake we’ll put them into a switch statement:

switch(url_parts.pathname) {
case '/':
sys.puts("display root");
break;
case '/create':
sys.puts("display create");
break;
case '/edit':
sys.puts("display edit");
break;
default:
sys.puts("oh dear, 404");
}

If you test this out you should see the relevant text displayed in the standard output.

Tidy up Existing Code

Now we have a basic router telling us that it has detected which page the user wants to display, but is then displaying the default page regardless. To correct this we need to put our existing code within a function and then call that function in the relevant part of the switch statement.

So, create a new (sub) function called display_root() in the main bulk of the http.createServer() function, expecting a url, a server request object and aserver response object as parameters:

function display_root(url, req, res) {
...
}

Within the body of the function, you want to insert the main bulk of the application that we wrote last time. I have included the complete code at the bottom of this tutorial, and all code is of course on GitHub.

Now call this function within the switch statement:

display_root(url_parts.pathname, req, res);

Handling Missing Pages

As said, Chromium is looking for a favicon.ico file, but currently this application doesn’t have one. As such it needs to be able to handle missing files gracefully, with the correct 404 response.

Create a new function within the main bulk of the http.createServer() function:

function display_404(url, req, res) {
res.writeHead(404, {'Content-Type': 'text/html'});
res.write("<h1>404 Not Found</h1>");
res.end("The page you were looking for: "+url+" can not be found");
}

Notice that we have specified the header to be 404.

Now you can call this from within the switch:

display_404(url_parts.pathname, req, res);

You can test it out by going to http://127.0.0.1:8000/qwerty
You should see:

404 Not Found
The page you were looking for: /qwerty can not be found

We could use a Haml template to move the content out of the code, but for the purposes of this tutorial it will suffice.

The Form

Now we want to generate a “Create” page – which will be a form allowing us to enter a list name and 1-5 items. (Note: I have changed from 10 items to 5 for no other reason that I am lazy, and don’t particularly want 10 things on my list, also it keeps the code a bit more clean!)

First, create the Haml template that will be used. We’ll keep this very simple for now. The key part is the form generation. After some trial and error, this mark-up seemed to work:

%form(action=url method="post")
      :each i in [0,1,2,3,4]
        %p %label Item
           %input(type="text" name="item[]")
      %p
        %input(type="submit" value="Create List")

You may want to read up on Haml here: http://haml-lang.com

The function for displaying the page is as follows:

    function display_create(url, req, res) {
	res.writeHead(200, {'Content-Type': 'text/html'});
	fs.readFile('./templates/create.haml', function(e, c) {
	    var data = {
		title: "Create New List",
		message: "Please enter up to 5 things to remember",
		url: url
	    };
	    var html = haml.render(c.toString(), {locals: data});
	    res.end(html);
	});
    }

Now if you fill in the items and submit, the page simply refreshes itelf. We need to get hold of the posted form data and do something useful with it.

This will be what we’ll focus on next time.

Tutorial Recap Part 2

In part 2 of the Node JS tutorial, we started to explore some very basic routing techniques. A number of dedicated routing modules have sprung up, of two of which are listed here:

• Tim Caswell’s node-router
• Tom Hughes-Croucher’s node-routing
• Find more on the Node Modules wiki page

Complete Code

var sys = require('sys'),
    fs = require('fs'),
    http = require('http'),
    url = require('url');
 
// Node-CouchDB: http://github.com/felixge/node-couchdb
var couchdb = require('./libs/node-couchdb/lib/couchdb'),
    client = couchdb.createClient(5984, 'localhost'),
    db = client.db('erdnodeflips');
 
// Haml-js: http://github.com/creationix/haml-js
var haml = require('./libs/haml-js/lib/haml');
 
var doc_id = '2d36f401bc4b82c9160e1a4ea936aba3';
 
http.createServer(function (req, res) {
    var url_parts = url.parse(req.url);
 
    switch(url_parts.pathname) {
    case '/':
	display_root(url_parts.pathname, req, res);
	break;
    case '/create':
	display_create(url_parts.pathname, req, res);
	break;
    case '/edit':
	sys.puts("display edit");
	break;
    default:
	display_404(url_parts.pathname, req, res);
    }
    return;
 
    /**
     * Display the document root
     **/
    function display_root(url, req, res) {
	res.writeHead(200, {'Content-Type': 'text/html'});
	db.getDoc(doc_id, function(error, doc) {
	    if(error) {
		fs.readFile('./templates/no-doc.haml', function(e, c) {
		    var data = {
			title: "No Document Found",
			message: "No document could be found",
			link: "/create",
			link_text: "Create a new document"
		    };
		    var html = haml.render(c.toString(), {locals: data});
		    res.end(html);
		});
	    }
	    else {
		fs.readFile('./templates/doc.haml', function(e, c) {
		    var data = {
			title: "Erdnodeflip document: "+doc.name,
			message: "Your Erdnusflip document was found!",
			items: doc.items,
		    };
		    var html = haml.render(c.toString(), {locals: data});
		    res.end(html);
		});
	    }
	});
    }
 
    /**
     * Display the list creat page
     **/
    function display_create(url, req, res) {
	res.writeHead(200, {'Content-Type': 'text/html'});
	fs.readFile('./templates/create.haml', function(e, c) {
	    var data = {
		title: "Create New List",
		message: "Please enter up to 5 things to remember",
		url: url
	    };
	    var html = haml.render(c.toString(), {locals: data});
	    res.end(html);
	});
    }
 
    /**
     * Display the 404 page for content that can't be found
     **/
    function display_404(url, req, res) {
	res.writeHead(404, {'Content-Type': 'text/html'});
	res.write("
<h1>404 Not Found</h1>
");
	res.end("
 
The page you were looking for: "+url+" can not be found");
    }
}).listen(8000);
sys.puts('Server running at http://127.0.0.1:8000/');

1. To list a number of items
2. To remove an item from the list
3. To add an item to the list

Obviously, before getting cracking with this tutorial I had to think up a name for this “killer app” of the Node world.

So I give you ErdNodeFlips! In honour of erdnussflips – the strangely addictive Wotsit type things that taste of peanut butter and stick to the top of your mouth. Yum! (OMG – they even have their own Facebook page!)

All code is available on GitHub.

Directory Structure and Libraries

The first step is to create a directory structure for the application and bring in the relevant libraries. We need two directories underneath the top-level application root: templates (which will hold the haml files) and libs (which will contain 3rd party libraries). We are going to grab two libraries off GitHub:

• Felix Geisendörfer’s node-couchdb – this is what we’ll be using to interact with the Couch database
• Tim Caswell’s haml-js – this is our haml template engine

$ cd /
$ mkdir {libs,templates}
$ cd libs
$ git clone git://github.com/felixge/node-couchdb.git
$ git clone http://github.com/creationix/haml-js.git
$ cd ../

Basic Web Server

Now we can get started. Open up a new file called main.js in your favourite editor. Now, just to make sure that everything is working at this early stage you can copy and paste the http server example from the nodejs.org front page and run that.

http.createServer(function (req, res) {
  setTimeout(function () {
    res.writeHead(200, {'Content-Type': 'text/plain'});
    res.end('Hello World\n');
  }, 2000);
}).listen(8000);

$ node ./main.js

Navigate to http://127.0.0.1:8000/ and after 2 seconds you should see “Hello World” appear. If you see this, all is working. We have the (very basic) base of our application.

Talk to the Database

Once we know that our basic setup is working, we can try and interact with the database. Before we can do this, however, we actually need to create the database and add an record – or document.

CouchDB comes with a nifty little utility called Futon. We’ll use this to quickly create our database and add a document.

• Go to http://localhost:5984/_utils/
• Create a new database: erdnodeflips
• Create a new document
• Add Field – name it name
• Double click on the value for name, enter “Don’t forget” (including the quotes)
• Add another field – name it items
• Double click on the value for items enter: ["item 1", "item 2", "item 3"] (including quotes and square brackets)
• Click on Save Document – copy the _id value
• Navigate to: http://localhost:5984/erdnodeflips/[value of "_id"] to see something like: {”_id”:”2d36f401bc4b82c9160e1a4ea936aba3″,”_rev”:”2-3b9f738a50ff9928348ce32b0eb807b2″,”items”:["item 1","item 2","item 3"],”name”:”Rob’s List”}

To read this within node we simply need to know the _id of the document. Save this as a var for now:

var doc_id = ‘2d36f401bc4b82c9160e1a4ea936aba3′;

and replace the setTimeout function with the following:

db.getDoc(doc_id, function(error, doc) {
	if(error) {
	    res.write(JSON.stringify(error));
	}
	else {
	    res.write('Fetched my new doc from couch:');
	    res.write(JSON.stringify(doc));
	}
     res.end("-= Fin =-");
    });

This is pretty simple, and should be relatively straight forward to read. Essentially the code tries to get the document identified by doc_id, invoking a function when done: db.getDoc(doc_id, function(error, doc){});

The function that is invoked has 2 arguments, one containing the error (if any) and the second containing the actual document returned (if any).

Within this function we can then deal with the two arguments as needed. If there is an error, we output that to the browser, if no error and a doc is returned, output that instead.

Finally, we end the server response: res.end(”-= Fin =-”);. Note, we must end the server response within the callback of the getDoc() function. Due to the event driven, asynchronous nature of Node, if we end the response after that function then the server response will more than likely be closed before getDoc() has had a chance to write the additional server responses.

So the code now looks like this:

var sys = require('sys'),
    fs = require('fs'),
    http = require('http');
 
// Node-CouchDB: http://github.com/felixge/node-couchdb
var couchdb = require('./libs/node-couchdb/lib/couchdb'),
    client = couchdb.createClient(5984, 'localhost'),
    db = client.db('erdnodeflips');
 
// Haml-js: http://github.com/creationix/haml-js
var haml = require('./libs/haml-js/lib/haml');
 
var doc_id = '2d36f401bc4b82c9160e1a4ea936aba3';
 
http.createServer(function (req, res) {
    res.writeHead(200, {'Content-Type': 'text/html'});
    db.getDoc(doc_id, function(error, doc) {
	if(error) {
	    res.write(JSON.stringify(error));
	}
	else {
	    res.write('Fetched my new doc from couch:');
	    res.write(JSON.stringify(doc));
	}
     res.end("-= Fin =-");
    });
 
}).listen(8000);
sys.puts('Server running at http://127.0.0.1:8000/');

Generate Nicer Output

If you run the above code, you should get something along the lines of:

Fetched my new doc from couch:{”_id”:”2d36f401bc4b82c9160e1a4ea936aba3″,”_rev”:”2-3b9f738a50ff9928348ce32b0eb807b2″,”items”:["item 1","item 2","item 3"],”name”:”Rob’s List”}-= Fin =-

So it works, but it doesn’t look very good.

First, lets create a Haml template that we can use to output something better.

!!! Strict
%html(lang="en")
  %head
    %title&= title
  %body
    %h1&= title
    %p&= message
    :if items.length === 0
      %p There are no items to remember
    :if items.length > 0
      %ul
        :each item in items
          %li&=

I’m not going to go into great depth. You can find more information on Haml at the Haml homepage and also have a look at Tim’s excellent tutorial on his Haml-js library.

Essentially, this template is going to build an XHTML strict page that will have a title, a message and then should loop through the items in the list. To get this displayed, we then need to open up the template file, render it and then output it as a server response. The code to do that is:

fs.readFile('./templates/doc.haml', function(e, c) {
		var data = {
		    title: "Erdnodeflip document: "+doc.name,
		    message: "Your Erdnusflip document was found!",
		    items: doc.items,
		};
		var html = haml.render(c.toString(), {locals: data});
		res.end(html);
	    });

Notice that I am simply ending the response with the generated HTML. Again, it is worth keeping an eye on exactly where the response is being ended otherwise you might find you are trying to add to a conversation that has already ended.

We can do the same for the “document not found” route:

!!! Strict
%html(lang="en")
  %head
    %title&= title
  %body
    %h1&= title
    %p&= message
    %p %a{href: link}&= link_text

fs.readFile('./templates/no-doc.haml', function(e, c) {
		var data = {
		    title: "No Document Found",
		    message: "No document could be found",
		    link: "/create",
		    link_text: "Create a new document"
		};
		var html = haml.render(c.toString(), {locals: data});
		res.end(html);

Quick Recap for this Tutorial

In this tutorial we’ve only scratched the surface of what can be done. However, in a relatively short space of time we have our Node web server communicating with a CouchDB database and displaying some valid strict XHTML. Not bad for one sitting!

To recap, our code now looks like this:

var sys = require('sys'),
    fs = require('fs'),
    http = require('http');
 
// Node-CouchDB: http://github.com/felixge/node-couchdb
var couchdb = require('./libs/node-couchdb/lib/couchdb'),
    client = couchdb.createClient(5984, 'localhost'),
    db = client.db('erdnodeflips');
 
// Haml-js: http://github.com/creationix/haml-js
var haml = require('./libs/haml-js/lib/haml');
 
var doc_id = '2d36f401bc4b82c9160e1a4ea936aba3';
 
http.createServer(function (req, res) {
    res.writeHead(200, {'Content-Type': 'text/html'});
    db.getDoc(doc_id, function(error, doc) {
	if(error) {
	    fs.readFile('./templates/no-doc.haml', function(e, c) {
		var data = {
		    title: "No Document Found",
		    message: "No document could be found",
		    link: "/create",
		    link_text: "Create a new document"
		};
		var html = haml.render(c.toString(), {locals: data});
		res.end(html);
	    });
	}
	else {
	    fs.readFile('./templates/doc.haml', function(e, c) {
		var data = {
		    title: "Erdnodeflip document: "+doc.name,
		    message: "Your Erdnusflip document was found!",
		    items: doc.items,
		};
		var html = haml.render(c.toString(), {locals: data});
		res.end(html);
	    });
	}
    });
 
}).listen(8000);
sys.puts('Server running at http://127.0.0.1:8000/');

The exciting thing here is that we’ve thrown in a link! However, if you click on it, it will simply reload the page.

Being able to handle this kind of basic page navigation and actually adding stuff to the database is for next time.

Feedback always welcome. You can find all the code on my GitHub pages.

Valuable Node resources:

• The official Node JS site
• The Node Github page
• How To Node – a great place for tutorials and other tips
• Node Blogs – which appears to be down at the moment, but again is very useful
• NodeJS Google Group – keep your finger on the pulse

For example, one thing that has been bugging me is to validate a URL the user must type in the initial http://. But why? Can the validation not just assume that if, for example, www.robsearles.com is typed in, that the user actually meant http://www.robsearles.com?

Well, after a quick read of the documentation and a hack around this little irritant is now gone. It’s all down to addMethod() which lets you add a custom validation method. Lets create one called complete_url().

jQuery.validator.addMethod("complete_url", function(val, elem) {
    // will contain our validation code
}, 'You must enter a valid URL');

A quick word about return values. If the method returns true, everything is considered OK. However, if false is returned then validation is assumed to have failed.

Our new method needs to do three things:

1. If no url, don’t do anything
2. Check that the user had entered http:// in their URL, if not, add it in for them.
3. Check that the URL is now valid. For this I just used the source for the original url validation method.

Lets translate this into some code:

jQuery.validator.addMethod("complete_url", function(val, elem) {
    // if no url, don't do anything
    if (val.length == 0) { return true; }
 
    // if user has not entered http:// https:// or ftp:// assume they mean http://
    if(!/^(https?|ftp):\/\//i.test(val)) {
        val = 'http://'+val; // set both the value
        $(elem).val(val); // also update the form element
    }
    // now check if valid url
    // http://docs.jquery.com/Plugins/Validation/Methods/url
    // contributed by Scott Gonzalez: http://projects.scottsplayground.com/iri/
    return /^(https?|ftp):\/\/(((([a-z]|\d|-|\.|_|~|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])|(%[\da-f]{2})|[!\$&'\(\)\*\+,;=]|:)*@)?(((\d|[1-9]\d|1\d\d|2[0-4]\d|25[0-5])\.(\d|[1-9]\d|1\d\d|2[0-4]\d|25[0-5])\.(\d|[1-9]\d|1\d\d|2[0-4]\d|25[0-5])\.(\d|[1-9]\d|1\d\d|2[0-4]\d|25[0-5]))|((([a-z]|\d|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])|(([a-z]|\d|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])([a-z]|\d|-|\.|_|~|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])*([a-z]|\d|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])))\.)+(([a-z]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])|(([a-z]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])([a-z]|\d|-|\.|_|~|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])*([a-z]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])))\.?)(:\d*)?)(\/((([a-z]|\d|-|\.|_|~|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])|(%[\da-f]{2})|[!\$&'\(\)\*\+,;=]|:|@)+(\/(([a-z]|\d|-|\.|_|~|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])|(%[\da-f]{2})|[!\$&'\(\)\*\+,;=]|:|@)*)*)?)?(\?((([a-z]|\d|-|\.|_|~|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])|(%[\da-f]{2})|[!\$&'\(\)\*\+,;=]|:|@)|[\uE000-\uF8FF]|\/|\?)*)?(\#((([a-z]|\d|-|\.|_|~|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])|(%[\da-f]{2})|[!\$&'\(\)\*\+,;=]|:|@)|\/|\?)*)?$/i.test(val);
});

Validating the form with this new method is very straight forward:

$("#form1").validate({
    rules: {
        url: "complete_url"
    }
});

Feel free to use/copy/modify as you see fit. If you do use it, why not let me know, or drop me a trackback?

Have fun

Other jQuery Specific Posts

• IE 7 indexOf() Replacement
• Fixed – jQuery DatePicker not working in Thickbox
• jQuery: Link override with search box

Some of my most used shell commands are using SVN, such as add, revert etc. However, I couldn’t find anywhere to just add/revert the current file I am working on. Fortunately there is Stack Overflow! Someone with a very similar issue to me has had a couple of good answers, which I have “borrowed” and now adding files to my SVN repository is really easy.

First, add the following to your .emacs file

(define-key minibuffer-local-map [f3]
(lambda() (interactive) (insert (buffer-file-name (nth 1 (buffer-list))))))

Now either open up Emacs, or reload your .emacs file:

M-x load-file RET ~/.emacs RET

Now, when you are working on a new file you can easily add it to SVN with the following command:

M-! svn add F3 RET

Nice!

Why Arch?

There are three main reasons I’ve picked Arch over Ubuntu, or even Debian.

1. I really like the idea of Arch’s rolling release system. My laptop is currently running Jaunty and in order to get the latest packages I would have to upgrade to Karmic. With Arch this is less of an issue.
2. As mentioned in my initial post, the base system should be small, quick and light. With Arch you can pick and choose exactly what you want at installation time, keeping it bloat free.
3. Finally, Arch will be something new to play with!

After downloading and burning a Net Install ISO I followed the excellent installation guide in the Arch Wiki.

Installation was relatively painless, the only two slight issues being:

I chose Auto prepare for partitioning, but I didn’t really know what filesystem to choose. Eventually I opted for Ext4, with so far, no ill effects.

During Boot Device Selection, again I wasn’t really sure what to do, but after some Googling I found this page, whose advice I followed, but just pressing enter.

I restarted and was greeted with a shell prompt. I quickly pinged Google and my network was still up and running through the ethernet on DHCP.

The next step up a non-root user and X. Again, the Arch documentation is excellent.

Setting up X was relatively simple. I originally decided to not opt for hotplugging, which was a mistake because I only have a USB keyboard and mouse, neither of which I could use in X (muppet of the day award goes to me). After turning off the machine and setting up hotplugging, all was fine!

I have been using the Awesome window manager for about a month now. Awesome is a tiling window manager which is heavily geared towards being keyboard friendly, and as it’s name suggests, it is pretty awesome.

Unlike Jaunty, installing the latest stable version of Awesome was a breeze, I simply ran:

# pacman -S awesome

and edited my ~/.xinitrc file adding:

exec awesome

at the bottom. When I started X again, Awesome was there without any problem.

Sound was equally as simple to install, which was a nice surprise.

So my base system is now setup, with my window manager of choice in place and sound ready and waiting for my music collection. And all this running under 100MB of RAM!

After my first foray into the world of Arch I’m pretty impressed. Pacman is very straight forward to use, after a bit of tweaking here and there it has just worked.

Next time, file management tools.