BrowserID is a hot new way of signing in to your favorite web applications without the need of typing in your password for each website. It lets users sign in once through BrowserID and then use different websites that use BrowserID without typing in their details again and again (a quick guide is located here). This NodeJS service, soon to be renamed Mozilla Persona, is super easy to implement with a lightweight authentication module called Passport. For this tutorial, we’ll go through a whirlwind tour of BrowserID and Passport and hopefully, this will show you just how easy it is to use BrowserID in your application. This tutorial is uploaded as a Github Gist and is located here if you want to have a look at the code as a whole.

1. Setting Up

The easiest way to start a NodeJS project is to install NodeJS and create a file called package.json with the following:

{
	"name": "browserid-tutorial",
	"description": "BrowserID: Logging in with BrowserID, Passport and NodeJS",
	"version": "0.1.0",
	"author": "Alexander Yuen <koo.studios@gmail.com> (http://www.koostudios.com/)",
	"main": "server.js",
        "node": "0.6.x",
	"dependencies": {
		"coffee-script"     : "1.2.x",
		"express"           : "2.5.x",
		"jade"              : "0.20.x",
		"passport"          : "0.1.x",
		"passport-browserid": "0.1.x"
	},
	"license": "MIT"
}

Now, simply change directory into the directory containing the package.json file using your terminal and run npm install to install all the dependencies in this file. Notice that Passport is located in two modules. This allows Passport to be very slim since we only need to include the particular system of authentication that we are using, called a ‘strategy’. In this case, it’s ‘passport-browserid’ which is the module required for BrowserID but there are many more strategies available (see the full list here).

Next, we create a file called server.js :

require('coffee-script');
require('./main');

This file is simple. It loads the CoffeeScript module and then the main part of the code, which will be located on a CoffeeScript file called ‘main.coffee’. The CoffeeScript module allows you to simply require ‘.coffee’ files throughout the NodeJS app without using the extension and will compile them on-the-fly when you run ‘node server’

2. Passport Up!

The bulk of the code, as you may have guessed is contained within the main.coffee file. This is quite a complex script at first but we will go through it bit by bit:

# Variables
exp = require 'express'
app = exp.createServer()
pass = require 'passport'
BrowserID = require('passport-browserid').Strategy	

# Passport Serialize and Deserialize Functions
pass.serializeUser (user, done) ->
	done null, user.email

pass.deserializeUser (email, done) ->
	done null, {email: email}

# Passport-BrowserID Strategy
pass.use 'browserid', new BrowserID {audience: 'http://dev.koostudios.com:1337'}, (email, done) ->
	# Interface with Database would go here
	done null, {email: email}

# App Configuration		
app.configure () ->
	app.set 'view engine', 'jade'
	app.set 'views', __dirname + '/views'
	app.use exp.static __dirname + '/public'
	app.use exp.cookieParser()
	app.use exp.bodyParser()
	app.use exp.methodOverride()
	app.use exp.session {secret: 'somesecretstringhere'}
	app.use pass.initialize()
	app.use pass.session()
	app.use app.router

# Run App	
app.listen '1337'
console.log 'Server running at port ' + app.address().port

# Routes
app.get '/', (req, res) ->
	if req.isAuthenticated()
		res.send "Congratulations! You've signed in as " + req.user.email
	else
		res.render 'index'

app.post '/login', pass.authenticate 'browserid',
	successRedirect: '/'
	failureRedirect: '/'
	failureFlash: true

Variables

These are pretty straightforward. We use the require function to include the Express framework, the Passport module and the BrowserID strategy. Note that the actual method of the BrowserID strategy that contains the class needed is ‘.Strategy’. Immediately after including the Express framework, we call on the createServer() function of Express which creates the application.

Passport Serialize and Deserialize Functions

To ensure that the server knows that a user is logged in as the user moves from page to page, the user’s browser is required to keep a string of characters in a cookie that is unique and identifiable to that user. This information is sent to the server each time a request is made so that the server knows who to send privileged information to but it must be serialized, or encoded before being sent to avoid misuse. Passport requires the developer to provide the necessary functions to ‘serialize’ and ‘deserialize’ this cookie with the session secret (see below) so that the information is kept safe on the client’s computer. This just means providing the done function with the email in the serializeUser function and checking the email matches with the done function in the deserializeUser function.

Passport-BrowserID Strategy

This is the major Passport function that contains the BrowserID strategy. Firstly we set the namespace of this strategy to ‘browserid’, which we will use later and then we create a new instance of the BrowserID class. This class requires an ‘audience’ variable and a verification function.

• The audience variable is used by BrowserID to identify the requesting party, which is your application. This should contain the website you are calling BrowserID from.
• The verification function ensures that the user requested is valid on both ends. It checks that the user activated from BrowserID is the same as the one in your database, or one that you have just created in your database. However, in the example code above, it just passes the done function with the same email straight back but normally, database functions should be included in this function.

App Configuration and Run App

This is the standard configuration and run app lines. Of note are the session secret which is required for serializing the user information into a session ID that is placed into the User’s cookies. Ensure the configuration lines appear in that order as they are needed in this order.

Routes

This simple application will only include 2 routes but only one page:

• The first route checks if the user is authenticated through the function req.isAuthenticated(). If the user is not authenticated, the route will display the ‘index’ file which will contain the button to sign in.
• The second route activates the authentication function of the BrowserID strategy by sending a POST to ‘/login’. The authentication strategy requires at least specifying where the user should redirect on failure through the ‘failureRedirect’ but you may like to add the ‘successRedirect’ if you wish. When failureFlash is set to true, it allows the developer to show the error messages on the jade file through the variable error.

3. The Front-End

Now that the NodeJS is out of the way, it is time to create the front-end. We use two files that will put in a views folder – layout.jade (that acts as a template) and index.jade (that contains the form):

!!! 5
html(lang= 'en')
	head
		meta(charset= 'utf-8')
		title= 'BrowserID with Passport and NodeJS'
	body
		!=body
		script(src= 'http://ajax.googleapis.com/ajax/libs/jquery/1.7.0/jquery.min.js')
		script(src= 'https://browserid.org/include.js')
		script(src= '/client.js')

In layout, we specify a simple HTML5 template page which will include three important scripts that is placed after the main body markup: the jQuery library, the BrowserID library and the client.js script which we will write. Note that the BrowserID file is necessary in the frontend to login to BrowserID as we shall see later.

form(method= 'post', action= '/login')
	input(name= 'assertion', type= 'hidden')
	input#browserid(type= 'submit', value= 'Sign in with BrowserID')

The markup in the index.jade file goes exactly where the != body is in the previous layout.jade file. This markup is simply a form which posts to ‘/login’ (which was one of our routes) with a hidden input for an ‘assertion’ variable and a login button.

The final thing to gel everything together is the client-side script, which I am neatly calling client.js, containing the following. This file should be placed in a folder called public as we have specified that all static files should be in there.

$("#browserid").on('click', function(e) {
    e.preventDefault()
    navigator.id.getVerifiedEmail(function(assertion) {
        if (assertion) {
            $("input[name=assertion]").val(assertion);
            $("form").submit();
        } else {
            location.reload();
        }
   });
});

This file merely calls the function ‘navigator.id.getVerifiedEmail’ from the BrowserID file that we included before. This function activates the BrowserID process, showing a popup allowing the user to login. When the user successfully logs into the BrowserID service, the function sends back an assertion. This assertion is a password key that is sent back to the server through the hidden input with the form. The form activates the server-side process outlined above through the ‘/login’ route, completing the authentication process by verifying with BrowserID that the user has been found and logged in.

4. Running

No need to compile the CoffeeScript file, simply use the cd command to change to your director and run ‘node server’. If you see a message saying ‘Server running at port 1337′, you’ve done something right!

Now, simply point your browser to http://your-local-domain:1337 and then click on the login button that you’ve created! You should see a popup with BrowserID. From there, simply signup or login and then let BrowserID do its job. If you have been successful, you should get the message ‘Congratulations! You’ve signed in as <your email here>’.

Conclusion

BrowserID is a hot new authentication system that relieves developers of the need for complicated processes such as the OAuth system that requires the developer to deal with authentication tokens and secrets. Instead, an assertion is provided in the frontend and then the server sends it back to BrowserID to get the user information. It is a much more streamlined process that is made even simpler by the Passport-BrowserID strategy of the Passport module. This handles a lot of things for the developer, leaving more focus on the actual application itself.

Amazing World of Chat – Illustration by kdonovan_gaddy

Websockets is amazing technology in the new HTML5 specifications that allows for a new way of communicating between browsers and servers. Through this technology, applications can easily and quickly provide bi-directional communication in realtime. This allows developers to create all sorts of realtime applications (e.g. statistics, chat applications) without the need of relying on huge AJAX calls that continuously poll the server and take up large amounts of resources. With Socket.io, working with Websockets is astoundingly easy and works perfectly with the non-blocking and quick realtime server, NodeJS. Plus, with Socket.io, browser compatibility for Websockets is no longer an issue as it solves the problem by choosing whatever communication protocol available for the browser at hand. So, let’s have a peek at parts of an application that uses Socket.io, a program I am developing called LightChat.

The Aim

A chat application is the simplest way of demonstrating the deliciousness of Websockets and Socket.io. For this, we will just need the user to be able to:

• Send a chat message to be broadcasted to everyone that is ‘connected’
• Receive a chat message

This tutorial requires the following software / node modules. Be sure to download them through the links below or through npm.

• NodeJS (v 0.6.9)
• CoffeeScript (v 1.2.0)
• Express.js (v 0.5.8)
• Jade Template Engine (v 0.20.0)
• Socket.io (v 0.8.7)

1. Setting Up

Again, we can set up our project structure as in my previous two tutorials. If you need help with creating this structure again, please have a look at one of my previous posts. Next, we should create our application file in our root folder. I’m calling mine main.coffee:

exp = require 'express'
app = exp.createServer()
io = require('socket.io').listen app

app.configure ->
    app.set 'views', __dirname + '/views'
    app.set 'view engine', 'jade'
    app.use exp.static __dirname + '/public'

app.listen 1337
console.log 'Server running at http://localhost:1337'

If you have seen any NodeJS application before, this will be one of the most simple configurations but in this example, it is simply all we need. The only new thing is perhaps line 3 which requires Socket.io and then configures it to listen to the application created by Express. Apart from that, we are doing everything very standard here.

2. Fun with Socket.IO

Here comes the fun part. When Socket.io makes a connection as in the following script, it figures out the browser and chooses the most appropriate communication method, whether that be Websockets, Flash or whatever. So, we need code that triggers connection and that code that fits in main.coffee:

io.sockets.on 'connection', (socket) ->
    socket.on 'send', (data) ->
        socket.broadcast.emit 'distribute', data

Lines 2 and 3 are the awesomesauce and everything needed to run the chat application. Socket.io works on listeners and senders. However, in the language, these verbs become ‘on’ and ‘emit’, respectively. Line 2 serves as the listener function, waiting for the function ‘send’. When ‘send’ is emitted from the client side (see below), line 3 sends a function named ‘distribute’ which sends the data back. Using the broadcast tag, Socket sends the same data to everyone that is connected except for the user itself.

For the client side, I am going to write a jQuery file called client.coffee under the directory /public/js/:

$ ->
    socket = io.connect 'http://localhost'
    socket.on 'distribute', (data) ->
        $('#results').append('<div>' + data.message + '</div>')

    $('#chatter').on 'submit', (e) ->
        e.preventDefault & e.preventDefault()
        message = $('#message').val()
        socket.emit 'send', {'message': message}
        $('#results').append('<div>' + message + '</div>')

The client side is slightly more involved but no less simple.

In line 1, the variable socket must be connected to a file that is served automatically on the host. If you have installed socket.io correctly (remember this means globally), it should be served when you require it. In my case, it is on http://localhost.

Using the socket variable, we are able to create listener and sender functions through either socket.on or socket.emit. This works exactly the same as the ones on the server. Now, we can define functions such as ‘send’ on line 9, which passes a variable ‘message’ to the server when a form is submitted. As we saw before, the server will be listening for the ‘send’ function and will broadcast the function ‘distribute’ in return. We can define what happens on functions such as ‘distribute’ as in line 3, in which we append the ‘message’ variable to a element called ‘#results’. Simple.

If that has you muddled up, think of the entire process of sending and receiving one chat message. The user types something in a form, submits it and client.coffee emits a function called send, which sends what the user typed as the variable ‘message’ to the server. The server, on main.coffee, listens for the ‘send’ function and when it receives the function, broadcasts a function called ‘distribute’ and sends the data along to everyone except the user. Everyone that is connected has client.coffee which listens for the ‘distribute’ function. On receipt of ‘distribute’, it appends the message to the screen in the ‘#results’ element.

3. Front-End

Now that we’ve created all the logic and understood it (Yes, that was all there was to it), let us create a simple interface for our chat application.

For this, let’s quickly render an index file in main.coffee when one goes to ‘/’:

app.get '/', (req, res) ->
res.render 'index', {locals: {title: 'LightChat'}}

Now, we can create a layout.jade and an index.jade. The layout.jade will be very simple with the bare basics:

!!! 5
html
    head
        title= title
    body
        != body

However, index.jade will be where all the magic happens:

#results
form#chatter
    input#message(type= "text", placeholder= "Type Something...")
    input(type= "submit", value= "Send")

script(src= "/js/jquery.min.js")
script(src= "/js/client.js")

As you can see, it is merely an element called ‘#results’, which we will use to append messages and a form called ‘#chatter’, which the user will type in the ‘message’ input to send to the server. Finally, in the last two lines, jQuery and the client file will be served.

4. More Complicated Please

If you’re complaining that this tutorial was too simple (I was!), here is a little bit more, before you go ahead and run everything. You can follow this if you want or jump right down to the next section if you have had enough. Either way, it should run perfectly well (we hope).

I want to show you how easy it is to create a multiroom chat application wherein users who have entered a chatroom only get the messages from people in the chatroom they are in. To simplify the chatroom experience, however, I am going to use URLs as the identifying factor. This means that separate chatrooms are going to separated by the pathname, everyone who is connected to the same pathname e.g. /abc is going to be in the same chatroom.

So, let’s modify the socket.io code in main.coffee and create a new app.get so that we serve index.jade when going to http://localhost:1337/ and then whatever id.

app.get '/:id', (req, res) ->
    res.render 'index', {locals: {title: req.params.id}}

io.sockets.on 'connection', (socket) ->
    socket.on 'switch', (room) ->
        socket.join room

    socket.on 'send', (data) ->
        socket.broadcast.to(data.room).emit 'distribute', data

You will notice there are some slight differences with this code and the last. Firstly, we grab the ID of the chatroom by calling req.params.id. This only serves to render the index.jade layout and set the title of the page to the ID of the chatroom.

Now, there are two different lines in the socket code. Lines 5 and 6 is where the magic happens. These lines allows us to join a room, when the function ‘switch’ is triggered, a function we are going to set when a person first comes onto a webpage. Then, the last line, Line 9 lets us broadcast the same way as before but only to the room that we are going to specify by adding it in the data.

Now that we’ve changed the server-side, let’s give the server what it needs. The first is to emit a function called ‘switch’ that happens when the user goes to a URL. This function, situated in client.coffee, will pass on the pathname:

room = window.location.pathname.slice 1
socket.emit 'switch', room

Since the pathname contains a slash, I am slicing it to avoid confusion. However, I am pretty sure everything would still run even without it. I am only doing this to keep consistent with the Node side.

Finally, we also have to pass on the room variable when something is sent. To do this, we only have to add the ‘room’ variable when sending in the previous client.coffee:

socket.emit 'send', {'message': message, 'room': room}

Done! Now, you have a chat application capable of multiple chatrooms all separated by simply the URL pathname. Everyone with the same pathname will be able to listen in but users in different pathnames will be in separated chatrooms. Very neat!

5. Running

Again, if you have not got the awesome command line coffee –watch –compile happening, then remember to compile the coffee files before running. Also remember that the client.coffee file needs to compile too. After this, you can go back to your project folder and run:

node main.js

To test it out, I recommend opening two browsers, preferably two different kinds side by side and then posting in one and then posting in the other. And voila! It is amazing in so little code is it not?!

Conclusion

Writing realtime applications like the chat application in this tutorial is amazingly simple with Websockets and Socket.io. And, added with the astounding asynchronous and non-blocking nature of NodeJS, it makes these applications super fast and super simple to write. In this example, we managed to create a chat application in which a user can broadcast a message and users can simultaneously talk to each other with two functions socket.on and socket.emit and around 10 lines of code related to it. With the same functions, any realtime communication between browser and server just became much, much simpler and real fun to write. So, dream up big because realtime communication is now all the more real with Socket.io and NodeJS.

Connecting to social networks is nearly a must have for every new fangled website in the works. And increasingly, many websites are using OAuth authentication of other social networks to log in to their websites, thereby alleviating users of the need to remember a separate username and password for your website. Using Node, it is surprisingly easy to hookup to your favourite social network with the node module, Everyauth.  So, without further ado, let’s demonstrate how to log into a website using Twitter.

The Aim

Let’s create a basic authentication system that allows:

• User to log in to the website using a button
• Display to the user a greeting with their name, like “Hi, KOOStudios!” (That’s my Twitter handle – Follow Me!)

1. Setting Up

Let’s do the configuration first. You may generate a project folder using the same structure as a normal NodeJS application. If you don’t  remember how, be sure to check my previous post. Now, we start with our file, main.coffee which will be pretty generic:

# Requires and Variables
exp = require 'express'
app = exp.createServer()

# App Configuration
app.configure () ->
    app.set 'view engine', 'jade'
    app.set 'views', __dirname + '/views'
    app.use exp.static __dirname + '/views'
    app.use exp.bodyParser()
    app.use exp.methodOverride()
    app.use exp.cookieParser()
    app.use exp.session {secret: 'bobsyouruncle'}
    app.use everyauth.middleware()
    app.use app.router

app.listen 1337
console.log 'Server running at http://localhost:1337'

If you followed my previous blog post, most of this is the same. What appears different is that we’ve added four extra lines at the bottom of the configuration. Here’s a little explanation of what they are:

• Line 12 calls on the cookieParser. When the user logs in, the session information (explained below) will be saved into a cookie, allowing users to move from page to page. The cookieParser method allows us to deal with cookies.
• Line 13 calls on the session method which allows us to deal with sessions. When a user logs in to the site, a “session” is generated, like a temporary ID card that allows the site to recognise the user when they use it. The secret will be the secret passphrase that will hash it from prying eyes.
• Line 14 imports the everyauth middleware. We don’t expressly need this in this tutorial but this will lets us use express helpers which are functions which can determine if the user is logged in or let us access the user details.
• Line 15 is the app.router which tells the application to mount the routes. Normally we use app.get which is sufficient but everyauth uses default routes that can save all the trouble by using this one line.

2. Getting Cozy with the Twitter API

To work with Twitter, you actually need to sign up your application and get a username and password to access Twitter’s interface. These are called the consumer key and consumer secret. You can get these by signing up here. Keep the consumer key and secret handy, you will need them.

After you “create” your application with Twitter, there’s just one tiny little thing we have to do. Because Twitter sends users back to a callback URL, that URL has to be acceptable by Twitter. If you try putting in http://localhost, Twitter will reject it. It’s stingy like that. So we have to make Twitter believe that we have a real URL.

To do this, you can edit the host file. This process will depend on your operating system but the hosts file sets out the domains that are to be preferentially directed to certain locations. In our case, we will be directing something innocent like http://dev.koostudios.com, which is not a real location, to our localhost, 127.0.0.1. So, find your hosts file (try this if you don’t know where it is) and open it up in your favourite editor to add the following line. You may need root access.

127.0.0.1  dev.koostudios.com

Feel free to substitute your own namespace! Save the file and get ready for the awesomesauce.

3. Starting with Everyauth

Whoa! That was a lot of configuration wasn’t it? Let’s get on to the easy bit with the logging in part. First things first, this is the application logic to log into Twitter. Place this in the main.coffee file abovethe app configuration lines.

everyauth = require 'everyauth'
everyauth.twitter
    .consumerKey('')
    .consumerSecret('')
    .findOrCreateUser((session, token, secret, user) ->
        promise = @.Promise().fulfill user
    ).redirectPath '/'

Done! That’s it! This is the backend of the logging in process. We tell our application to include the package everyauth and use the twitter method (Lines 1 and 2). Then, we give it our consumer key and secret (Lines 3 and 4) and the real magic happens in the findOrCreateUser method. This allows you to log in to Twitter when the browser is turned to /auth/twitter and be returned straight back to the root location. Plus logging out is as easy as hitting up /logout. All Automagically!

What isn’t much explained is Line 6. OAuth requires you to send back information from your end of who is actually logging in. However, because NodeJS is asynchronous, that is, it keeps on going and does not wait for lines to stop, it is a tad too fast and sends out a promise that we will give it user information instead. The findOrCreateUser function must return a fulfilled promise so I’ve just sent the user information straight back in Line 6. Please note, normally we would have a few lines before fulfilling the promise to find the user on our database first (as we see later).

4. Fun with Front-End

Now that you have the entire login mechanism on the back-end, it is time to deal with the front-end. As mentioned previously, you only need a link to /auth/twitter to start the login process and a link to /logout to log out. So let us set up the link for logging in and logging out by determining whether we’ve logged in. Heck, let’s even add a greeting to say hi when they’ve logged in. Here is the routing done on main.coffee.

app.get '/', (res, req) ->
    if (req.session.auth)
        user = req.session.auth.twitter.screen_name

res.render('index', {
    layout: false
    locals: {user: user}
}

Notice that I am still rendering ‘index’ if I am logged in or not. The only difference is that the user variable will be set to their twitter screen name if they are logged in or will be undefined if they are logged out. We can use this information now to build index.jade.

!!! 5
html
    body
        - if (typeOf(user) != 'undefined')
            span= "Hi, " + user + " "
            a(href="/logout") = "Logout"
        - else
            a(href= "/auth/twitter")= "Login"

And that’s done! We’re using the neat JavaScript feature in index.jade to figure out whether user is defined or not and displaying a greeting with a logout button or a login button depending on the answer. Cool, huh?

5. Running

If you are using the awesome coffee –watch command, your amazing coffee files will have been compiled. However, if you are not, run the following in your project folder:

coffee --compile main.coffee

Now, you can run your little monster! Simply type:

node main.js

Remember the compiled version of the file is the one you need to run! And if you get your own lovely message of ‘Server running at http://localhost:1337′, you know you’ve got yourself a winner. Just hit up your browser and take a look at the magic!

Conclusion

Dealing with OAuth in NodeJS is dead simple. In fact, I think it is laughably simple. EveryAuth deals with everything and deals with everything automagically for you. You simply have to give it your API details and it logs the user in, saves their information in a cookie and lets you have default login and logout paths. The great thing about EveryAuth is that the process is pretty much the same for all the other APIs that it supports, so don’t stop with Twitter but keep going… Google, Facebook, LinkedIn… it all awaits!

The combination of CoffeeScript, Node.js and CouchDB as a language, a server-side environment and database isn’t just amazingly cool and hip. It’s cool and hip for a reason. And that reason is because it is outrageously simple and blazingly fast to write a very cool web application. But as fast and simple as it is, tutorials and documentation are somehow lacking or non-existent and following them just leave beginners frustrated. So here is a comprehensive tutorial on building a simple blog made with CoffeeScript, NodeJS and CouchDB. It’s not really for professionals but great for the curious and hobbyists who want to move from more traditional server-side technologies to Node.

Update: I have changed a couple of things to make it much more easier for first time CoffeeScript, NodeJS or CouchDB users. So if you find yourself in a bit of trouble, make sure you read the Tips before you start doing anything.

The Aim

Forget the “Hello Worlds!” let’s build a simple blog! For a simple blog I want to be able to:

• To view all the posts
• To add a post

Two simple objectives. To achieve this, we’re going to use the following software. If you want to follow along, I recommend installing these using the links given (most need the Node Package Manager).

• NodeJS (v 0.6.9)
• CouchDB (v 1.0.2)
• CoffeeScript (v 1.2.0)
• Express.js (v 0.5.8)
• Jade Template Engine (v 0.20.0)
• Cradle (v 0.5.8)

Tip: For CoffeeScript, Express and Jade, you can install them using the command “npm install ” in your terminal. Depending on your system and privileges, you may want to install CoffeeScript and Express globally by the command “sudo npm install -g ” to take advantage of their command-line interfaces. Or, you may install it locally to save it in your local node_modules folder. If you are unsure about installing packages globally, check out this

1. Setting Up

For this simple blog, I recommend creating a project folder “couchpress”, a subfolder called “views” and another one called “public”.

Now let’s understand this structure a bit. All the application logic, the CoffeeScript and JavaScript files go in the project folder, the root directory that I’ve called “couchpress”. The /views folder contains all the template files using the Jade Template Engine and the /public folder contains all the static content; images, client-side JavaScripts and stylesheets.

Now that we’re organised in our mind what goes where, let’s tell NodeJS, the server-side environment of our blog. Let’s create a file named “main.coffee” with the following in it:

# Requires and Variables
exp = require 'express'
app = exp.createServer()

# App Configuration
app.configure () ->
    app.set 'view engine', 'jade'
    app.set 'views', __dirname + '/views'
    app.use exp.static __dirname + '/public'
    app.use exp.bodyParser()
    app.use exp.methodOverride()

# Run App
app.listen 1337
console.log 'Server running at http://localhost:1337/'

Tip: While it looks like I’ve put the indentation (the tabs) on the file to make it look pretty, they are actually necessary in CoffeeScript. Make sure you follow the indentation as I have in this tutorial. As a rule of thumb, indent when you write the lines of a function or some other kind of block like an “if” statement. If you do not follow the indentation, CoffeeScript will not understand which lines are for which function and throw errors at you.

NodeJS can run off a single JavaScript file like this main.coffee which contains all the code to essentially create the server. I’m using Express, a web development framework for NodeJS, which essentially relieves me of creating all the server stuff over and over again for each project. Instead, the first two lines are nearly all that is necessary. The first to tell Node that we need Express and will call it ‘exp’ from now on and the second to create the server.

The configuration is pretty simple as well. Let’s go through it:

• Line 7 sets the template engine, Jade, as the view engine. We’ll talk about this later but it means we don’t have to add the “.jade” extension.
• Lines 8 and 9 sets the folders for views (template files) in the /views folder and the static folder as the /public folder. Notice the “__dirname” part sorts out the location of the current file and everything else is in relation to that.
• Line 10 tells Express to use methodOverride() that let’s us use Node using RESTful methods. With this, we will be able to post forms to a specific location and let Node handle it. We need this in our new post form.

2. Connecting Up the Database

Now that we’ve got the boring stuff out of the way, let’s have some fun with the database. If you’ve followed the installation guides for CouchDB well enough, you should be able to hit up http://localhost:5984/_utils/ to access Futon, the command centre for your database. Or, if you’re on a Mac, you can open up the application CouchDBX.

Let’s create a new database using the “New Database” button (I’ve called mine “couchpress”) and get straight on to creating our first viewto simply list all the posts. The quickest and easiest way to do this is to open up the database you’ve just created and select “Temporary view…” in the dropdown box in the top right. We just need to save this default view using the “Save As” button and save it in the design document “_design/couchpress” with the view name of “all“.

If you’re unfamiliar with views, they’re the lifeblood of CouchDB and makes querying very much faster because it generates the results of a query ahead of time. It’s really the equivalent of a report. But much cooler. If you want to know more, try the CouchDB Guide.

Tip: If you would like to learn how to add a new post through Futon (the name of this CouchDB utility), go back to the main screen and click on your database and create a new document using the “New Document” button. The “_id” of the document is automatically generated by CouchDB so we will let it be but let’s create two fields using the “Add Field” button. Create a “body” and a “title” field and put in there what you would like. A “Hello World” will do in each case.

Now that the database is set up (I know quick, right?), we need to connect with it. For this, I’m creating a class called “Articler” to handle all the article functions in a file called articler.coffee, also in the same folder as our main.coffee. This is what’s in it:

# Articler Class - Handles all article functions
cradle = require 'cradle'

class Articler
    constructor: (host, port) ->
        @connect = new cradle.Connection host, port, {
            cache: true
            raw: false
        }
        @db = @connect.database 'couchpress'

    findAll: (callback) ->
        @db.view 'couchpress/all', {descending: true}, (err, res) ->
            if (err)
                callback err
            else
                docs = []
                res.forEach (row) ->
                    docs.push row
                callback null, docs

    save: (articles, callback) ->
        @db.save articles, (err, res) ->
            if (err)
                callback err
            else
                callback null, articles

exports.Articler = Articler

Tip: Those ‘@’ signs look funny don’t they? An @ sign in CoffeeScript simply stands for “this.”. It is just a quick shortcut that is very useful to know.

Articler looks a bit complicated but everything is really easy. Articler has three methods: the constructor (which connects with database), findAll (which displays all the posts) and save (which saves, duh):

• The constructor method lets us do all the talking through the namespace @db as we set it to our database ‘couchpress’ and in the rest of the methods, we simply do an action towards the database.
• In findAll, we pointed to the view document we created just moments ago using:
  @db.view ‘couchpress/all’
• In save, we save the variable articles, which will be an array we will be putting in it using:
  @db.view articles

The rest is just callback functions so that we can pass on the variables gathered from the database. For example, in findAll, we put everything into the array called docs so that we can present it on the screen.

To join our newly created Articler class to our main.coffee file, we just need to add these lines after the configuration to grab the Articler class and then point in the direction of our CouchDB url in new instance of Articler:

# Articler Class
Articler = require('./articler').Articler
article = new Articler 'http://localhost', 5984

There we go! The great thing is that the Articler class can be copied and pasted in every app where you want to contact a CouchDB.

Tip: Before you continue, you may want to check that you have created the database correctly and the view correctly by going to your database folder through your browser. In my case, that is http://localhost:5984/couchpress/. If you see the doc_count to be greater than 0, then you should have done everything but if you have a doc_count of 0, try going over the steps to see if you have missed something.

3. Creating the Frontend

Now that we’ve got the server and the database, we can turn our attention to the displaying of our information. First, we’ll create a jade template file called layout.jade in the /views folder. Express uses this file as a template for every page. Therefore, you want to put things like the header and footer in there. I’ve also took the liberty of creating a CSS stylesheet but you should be able to do that. Remember create the stylesheet in the /public folder and link it as below:

!!! 5
html(lang="en")
    head
        title= title
        link(rel= 'stylesheet', href= '/style.css')
    body
        header
            a(href='/')
                h1= 'CouchPress'
        section.content
            != body

Jade is a templating engine that lets us create markup by just writing the tag and then putting the contents of that tag either after the equal signs (i.e. h1= ‘Couchpress’) or on the next lines marked by a tab (like the header tag). What’s more is that anything not in quotation marks can be a variable. For example, we will be changing the title of the page to reflect what we’re doing. Furthermore, the rest of the page is marked by the != body.

Tip: You will notice that there Jade includes a lot of logic. That is part of the beauty but also the font of most of your annoyance. Make sure you keep with the indentation and type everything, especially the symbols correctly. Jade will not be as sympathetic as HTML.

To fill the body, let’s create an index page called index.jade also in the /views folder where we will be listing all the posts:

- each article in articles
    .article
        h1= article.title
        span.created= article.created_at
        span.body= article.body

This is where Jade comes to its prime. It is able to use a bit of logic in the form of JavaScript to iterate over an array, like the JSON one that CouchDB is going to give us. The first line marked with the “-” is the JavaScript that tells Jade to go through every item in the array that we will pass to it.

Finally, I’ll create a quick form called new.jade also in the /views folder to create new posts:

form(method="post")
    input(type="text", name="title", placeholder="Title")

textarea(name="body", rows="20")
input(type="submit", value="Publish")

Great. We’ve created three files in the /views folder: layout.jade for the template, index.jade to list all the articles and new.jade to create a form to publish new posts.

4. The Final Bits

The last thing we have to do now is to join up what the user does in the browser to everything we’ve created. In Express, the easy way to do this is via routing. Routing uses the usual HTTP commands like “get” and “post” but allows us to code our own magic to each of these.

Ok, let’s start with the index. When people go to the domain (which we call “/”), we want to grab the findAll function of Articler and then put it all in the index.jade to show us all the post. For this, we need the following lines in main.coffee (after everything else we’ve done):

app.get '/', (req, res) ->
    article.findAll (err, docs) ->
        res.render 'index', {
            locals: {
                title: 'CouchPress'
                articles: docs
             }
        }

Notice that we render ‘index’ which is the ‘index.jade’. Because we set the view engine to jade and the view folder to /views, Express knows where to look and doesn’t need to extension ‘.jade’. And, remember the variables we put in the Jade files? Well, they’re the “local” variables. I want to set the page title to ‘Couchpress’ and the articles as the docs that Articler is going to give us.

Now, we can deal with posting a new post. First we have to display the form when the user goes to “/new” or in our case, “http://localhost:1337/new”. That’s as simple as this:

app.get '/new', (req, res) ->
    res.render 'new', {locals: {title: 'CouchPress / New Post'}}

And then to process the form, we grab the form details that will be posted to “/new” and then save it using the Articler method save. You can grab the form post parameters by using req.param and then the name of the input, like so:

app.post '/new', (req, res) ->
    article.save {
        title: req.param 'title'
        body: req.param 'body'
        created_at: new Date()
    }, (err, docs) ->
        res.redirect('/')

Don’t forget, the last line is the callback to tell the browser to redirect when it is all good and done!

5. Running

Wow it’s been quite a journey! Now let’s test it. First, if you haven’t been using the nifty CoffeeScript command “coffee –watch”, then we have to compile the files. Direct your terminal to the project folder (for me, that’s couchpress), and then use the following command:

coffee --compile main.coffee articler.coffee

If you look at the folder now, coffee has created two files into JavaScript for you. Awesome! Now, you can run your project (while double-crossing your fingers hoping that you’ve done nothing wrong). To run the project, just run:

node main.js

If you get your message “Server running at http://localhost:1337″, you can breathe a little easier. Now, you can try out your baby! Because we don’t have any posts, go to http://localhost:1337/new in your favourite browser and create a post. And, because we’ve made a redirect, so it should redirect you to http://locahost:1337/ and you can view your site!

Tip: Node will give you an error if go straight to “/” because there’s nothing in the database. But I am sure that you can now figure out how to deal with an empty database (hint: we’ve put in nice little error variables so you can pass on errors).

There it is! A quick blogging platform that let’s you view all the posts and save them!

Conclusion

While our blog is not quite production ready, we have managed to create a basic server, link it to a database, create a frontend and join it altogether in less than 100 lines of code (go on count it) and for me, under an hour. And, it works! Furthermore, this little blog software which can retrieve entries from a database, display it with Jade files and save entries into a database forms the basis of almost any application. So you’ve learnt quite enough to make your own applications! In under 100 lines! I hope this article shows that the combination of CoffeeScript, NodeJS and CouchDB (along with all the other technologies we’ve used) is an amazing mix of fast and innovative technology that allows one to create quick and elegant web applications.

I have to admit. My foray into Ruby and Python left me a little jealous. Here was two, very beautiful, elegant, succinct and whitespaced languages that shone in comparison with my language of choice, JavaScript. Of course, I could not be converted to Ruby or Python, simply because I enjoy client-side development and JavaScript, with its applications in CommonJS, NodeJS and others, is currently showing great promise as a all-round language, capable of many, many things. But there were so many things that you could like about Ruby and Python that just wasn’t in JavaScript. And then, I stumbled upon CoffeeScript.

CoffeeScript is not JavaScript. It’s a little language, inspired by both Ruby and Python, that allows you to write scripts quickly and then compile them to JavaScript, or to be technical, transcompile into JavaScript. There’s no interpreter at runtime, like Ruby or Python, but it means that you can use CoffeeScript everywhere where you use JavaScript. Compiled with the included Jison-based compiler (written in CoffeeScript!), CoffeeScript scripts are mostly faster than pure JavaScript and you can use it with any other existing JavaScript library seamlessly. Awesome.

How can a language that essentially uses nearly identical syntax as JavaScript be as awesome as Ruby or Python? It starts with removing the ugly things. Curly brackets are gone, replaced by whitespace, just like Python (which is my favourite feature). So are semi-colons, the most controversial character in the JavaScript writer’s arsenal. And then, there are the JavaScript improvements. The language gets rid of global variables, the nightmare that they are, and leaves only local variables. Functions are replaced with a simple arrow “->” and iterators are done Python and Ruby style with the “for i in array” line. They even replace the common “this” item with a simple “@”. Brilliant.

 What is interesting in CoffeeScript is that it encourages the use of classes with its simple class structure, as in Ruby and Python. JavaScript is actually a somewhat class-based object-orientated programming language, though using classes are very, very rare, most likely because of its near impossible syntax. However, classes are dead simple in CoffeeScript and uses the same conventions as any other programming language with a “class” declaration for once that is sure to improve scripting in general. Super simple and elegant.

To be honest, I had some reservations about using CoffeeScript. The first time I read the documentation, I did dismiss it a bit. I thought, rather wrongly, that it was another metalanguage, like Sass, Haml or Stylus that didn’t really change the language much and offered little drastic improvements. But I would argue CoffeeScript is quite different from JavaScript and tries to make JavaScript ever nicer and closer to Python or Ruby.

Then there’s the fact that it must be compiled, meaning there’s another step you have to do. But you don’t mind it after a while, especially after you write a quick AppleScript in your favourite editor to compile it. Plus, you can have the option to add a quick script in browser so that it runs on the page as a “text/coffeescript”. That is pretty neat. And, lastly, but most importantly, CoffeeScript is still JavaScript and will still have the problems of JavaScript as long as it has to be compiled back down to it. However, as I said before, that is what makes it particularly awesome as it means that you can use CoffeeScript basically anywhere that JavaScript can be used. Which these days, is pretty much anywhere.

People are raving about CoffeeScript. And I can see why. The language is pretty and elegant, it’s fast to write and run, and it goes everywhere JavaScript goes. The language brings pure joy to the writing of JavaScript applications and alleviates most of the gotchas of JavaScript. However, moving to CoffeeScript is going to be hard. And, as long as it is not supported in browsers or applications, it will be another language to switch between in development. Nevertheless, let’s start this brave adventure in a pretty, pretty land.

CoffeeScript is released under the MIT Licence. Try it out now at coffeescript.org.

The Dart Logo - Dartlang.org

Dart, a new structured programming language for the web, has just been announced today by Google. Despite the fact that Google has pretty much failed to introduce a widely-used programming language before, this new foray into web programming languages seems promising. Interestingly, the authors of Dart have been vague about its use and there are possible hints that Dart may be used for cloud-based applications in a standardised mobile platform. Most of the features, like types and the object-orientated structure hasn’t excited me as such, as they aren’t really innovations to programming languages. However, even in this early stage, some really awesome features have floated up and caught my eye.

1. Isolates

While Dart remains single-threaded like Javascript, it offers what they call isolates, or units for concurrency. Hence, blocks of code can be run concurrently with each other thereby creating several processes that can run at the same time. Additionally, separate isolates have their own memory and own thread of control so hopefully, an error in one thread won’t stop the entire application.

2. Server-side Dart

When I first heard of Dart (or Dash as it was called), I merely thought it was built to simply replace client-based javascript. However, its plans are much wider and greater than that. Dart was built from the ground up in the same idea as Javascript and NodeJS, a web programming language that could be run on both the server and the client. Additionally, because of its focus on web programming, it is tailored for quick performance and the authors aim to make it much faster.

3. Snapshot

Perhaps the most exciting news is the Snapshot feature, even though this isn’t exactly a feature of the language. This allows the VM to load code 10 times faster as it initialises the code beforehand and allows an application to start an instance at that point. This would be where the speed gains are most impressive, especially as you don’t have to wait for all the code to initialise.

Conclusion

While Dart, like Google’s previous attempt Go, represents a promising future in web programming languages, it still remains to be seen if it can be adopted as a standard. Sure, there are some cool features as outlined above but the real test is to see if Dart is adopted by other browsers so it can garner widespread use. At the moment, it’s certainly interesting to play with but Google should find  other ways of enticing us towards Dart.

For more information on Dart, be sure to check out its website and the GoogleCode website. Oh, and for once, the specification is worth reading and be sure to try the programming language out on the awesome Dartboard.

There’s a growing trend towards using what are called floating or sliding panels. What are floating panels? To put most simply, they are panels (most likely <div> tags) that stay in their position while the user is scrolling down. It is particularly useful for bringing into light important things such as information about the site, or bringing the attention of the user towards call to action buttons, like “Download Now” or “Sign Up” kind of buttons. How to? Well, Portamento is a neat jQuery plugin that lets you do just that – and do it simply.

Portamento needs only to be stuck on the end of a selector to work (after you include jQuery and the plugin of course):

$('div.element').portamento();

Simple! This plugin also lets you specify a wrapper that you want the sliding panel to stay within, and a gap from the top to make sure your new floating panel isn’t in the wrong place and covering another element.

Portamento is very simple and easy to use, and even includes a workaround for legacy browsers that don’t quite support the position: fixed CSS property (which is how a floating panel works). Visit their site to try it out and download it here.

CSS Gallery

Produced by the venerable Smashing Magazine, CSS Gallery is the site to be at because it is full of inspiration awesomeness. Sites selected always have an edge and the easy navigation of the site makes viewing amazing designs so easy!

CSS Mania

With a website that is so nice it deserves to be featured in another gallery, CSS Mania is a friendly-looking website with big thumbnails (big plus!). An important and useful feature is the ability to choose colours and their colour selector does it really well (it just needs a search function).

Awwwards

Not really an inspiration gallery, Awwwards features selected websites that have received the somewhat awkwardly named “Awwwards”. Selected daily by an international jury of talented designers, the websites have been rated so you get to see the best but also figure what the designers did best and what they could have done better.

One Page Love

Uniquely focussing on one page websites, One Page Love sports an easy blog-like interface that makes you just want to keep scrolling down, pressing the next page, rinse and repeat. The websites featured are always amazing and innovative with keeping everything on one page.

Web Creme

The design of Web Creme may be simple but the ease of the site is a big plus. All sites are given categories of colour so it is very easy to focus and look at just blue websites. Neat.

HTML5 and its lovely brother CSS3 are both very fun and easy to use and produces wonderful results. That is, until your client views your beautifully designed and coded site in the dreaded Internet Explorer. Audio and video elements don’t work, things go all over the place and don’t even mention the word semantics because I’m sorry, IE does not understand! Fortunately, there are many lifesaving ways to allow our sites to fallback on previous methods, or to “degrade” gracefully – so you wouldn’t notice there’s a difference. Keep reading to find out 5 ways of falling forward!

Conditional Statements

Want different stylesheets, or different scripts when you’re in a low-end browser? That’s easy with conditional statements. Normally, comments are ignored by browsers but some browsers (such as IE) can handle certain structures of comments as instructions. In this way, the browser can detect whether to include a certain stylesheet. So, if you want a stylesheet for a particular browser version, you just do this:

<!--[if IE 6]>
<link rel="stylesheet" src="ie6.css">
<![endif]-->

The statements can be even more dynamic to include groups of browsers like these:

<!--[if lt IE9]>
<!--[if lte IE8]>
<!--[if (IE6)|(IE7)]>

However, this method, though useful, is generally discouraged because it is a little browser hack that is not maintained or standardised and are not so great semantically (and there are many other reasons – something for another blog!)

HTML5 Natural Fallbacks

Some elements in HTML5 have a neat feature of allowing fallbacks within their own elements. The best example of this is the <audio> and the <video> tags. If you put a fallback like a flash object within these tags, legacy browsers will ignore the new tags and just read the middle stuff while new browsers will recognise the new tags and read the new tags. Have a look:

<video src="movie.mp4" controls>
     <embed src="movie.flv" type="application/x-shockwave-flash"  allowscriptaccess="always" allowfullscreen="true"></embed>
</video>

Of course, this won’t work on everything but keep an eye out for these special elements because it does save a bit of time.

Javascript Shiv

Probably the most popular way is to tack on what’s called a javascript shiv (or shim). In javascript, it is possible to add elements that a browser does not understand and using this feature, add the additional elements that HTML5 provides. Thankfully, we don’t have add each one individually as some good people have already done it for us. Simply tack this on at the end of your <head>:

<script src="http://html5shiv.googlecode.com/svn/trunk/html5.js"></script>

Keep in mind that IE will not suddenly recognise all your HTML5 features, but really this script gives you an ability to identify it within CSS and style it the way you like it. You can use a HTML5 Reset Stylesheet to make sure all the new elements will display consistently.

Modernizr

Modenizr is an awesome javascript library that allows you to detect if features are available and then gets the client to download the right file. The library can detect a huge list of features and then allows you to write your own workaround. Using Modenizr is as simple as:

Modernizr.load({
  test: Modernizr.geolocation,
  yep : 'geo.js',
  nope: 'geo-polyfill.js'
});

This tests if the browser supports geolocation, if yes, loads “geo.js” and if no loads “geo-polyfill.js”. Easy, no? Modenizr also allows you to fine tune responses for multiple features if necessary or even add your own test which you can script.

Google Chrome Frame

It’s not really a solution but if worse comes to worse, it is possible to use the Google Chrome Frame. The GCF (as it is more affectionately called) is an Internet Explorer plugin that allows IE to render exactly like the Google Chrome Browser. Therefore, it can support all your html5 just like that. To enable it for someone with GCF installed, you simply add:

<meta http-equiv="X-UA-Compatible" content="chrome=1">

You may also want to ask someone to install GCF and Google comes with a script handy to check for and ask to install if GCF is not enabled. Simply put the following in the body somewhere:

<script type="text/javascript"
     src="http://ajax.googleapis.com/ajax/libs/chrome-frame/1/CFInstall.min.js"></script>
<div id="prompt"></div>
<script>
     window.attachEvent("onload", function() {
       CFInstall.check({
         mode: "inline", // the default
         node: "prompt"
       });
     });
</script>

Conclusion

As you can see, there are many many ways to get around the annoyance of a browser not supporting a particular feature and most don’t take that much time. For most cases a shiv and some clever HTML and CSS is enough but for others, Modenizr is the way to go. However, these features are so important to keeping a consistent and better looking interface across all browsers. If you want to read or learn more about HTML5 fallbacks, be sure to check “The All-In-One Entirely-Not-Alphabetical No-Bullshit Guide to HTML5 Fallbacks” which has a whole heap of information on this topic.

The one thing I like as much as creating wallpapers is finding wallpapers. As a guy who changes wallpapers nearly every week, I find a lot of great looking wallpapers on a day to day basis. There’s no wallpaper more peaceful and more beautiful than a nice grass wallpaper. These are not mine, but a couple from the great community called the internet. Keep reading for download links!

Longhorn Bliss by DJMattRicks

Download Now

Grass Wallpaper by Uberfoto

Download Now

Minimal by Pete Harrison

Download Now

Longhorn Aero Grass by OsmosisChing

Download Now

Simpleness by Emats

Download Now