Full solutions

Update (12/07): This article has been getting a lot of link-love lately. For those of you who are looking for a full solution on handling and parsing forms in Node.js might be interested in:

• connect-form (docs) Form parsing middleware for Connect
• node-formidable Form parser w/ support for file-uploads
• The module page in the Node.js wiki where other alternatives may be found.

The rest that follows, the original article, explains what those modules are doing under the hood.

Server and routes setup

For our example we need a HTTP server instance with a request handler that defines two routes:

• ‘/’ A simple web page with a HTML form.
• ‘/formhandler’ which accepts POST requests and handles the body that is generated by the form

All other requests (such as GET requests for favicon.ico) will be answered by a 404 Not found message.

To get started we use the following code which handles our two routes by sending back a 501 Not implemented response.

If you’re running the code locally you should now be able to visit http://localhost:8080/ in your browser.

A simple form

In the next step we change the browser for the start URL ‘/’ to present the user with a little web form by exchanging that part of the switch statement with a 200 OK response together with the appropriate HTML:

The ‘/formhandler’ part remains unchanged for now. If you run the script and visit the page in your browser you’ll be presented with a form asking for name and age.

Notice that the enctype parameter of the form is set to application/x-www-form-urlencoded. This specifies how the data is encoded and sent by the browser. URL encoding is okay for simple forms without file upload capabilities for example. What’s even better is that node.js provides a built-in module to parse this type of data. We’ll use it in a later step. The other parameters specify that by submitting the form the data should be sent to the ‘/formhandler’ route inside a POST request.

Read the message body

In a HTTP request we’re only looking for the header part that tells us what the browser is requesting. The body, that may contain everything from the two key/value combinations we use in the example up to multiple files, is seperated from the header part by two line breaks. What follows is mostly either URL encoded data or multipart/form-data – which is basically data sent in distinguishable small chunks.

In node.js the request event we’re already handling is emitted when the header is fully received and parsed. This is at a time where the client’s browser may still be sending body data, if we want to use it or not. The only route we set up that has to handle this data on our side is the ‘/formhandler’ route (and even then it should only use the data if it is inside a POST request). We exchange our previous 501 code for this route with the following code:

Multiple things are introduced here. First we check the HTTP headers if the request is a POST request (req.method). If that’s not the case (say because the user went to http://localhost:8080/formhandler without using the submit button) a simple 405 Method not supported error page is generated.

If the headers indicate that it’s really a POST request we start listening for two events of the request object:

• data: Is triggered whenever body data comes in at the TCP socket level. Note that this doesn’t neessarily contain all the data, hence it’s called a chunk.
• end: Is triggered when the HTTP request is completed. This indicates that all body data associated with it was read and the appropriate data events have been triggered.

Above code outputs every chunk of data it receives to the console (after converting it from a Buffer to String) and sends an empty 200 OK response to the client when the request is completely received.

Buffer and decode

So we learned that the body data of our HTTP request is encoded in someway, which means that we’ll have to decode it, as well as the fact that it may come in chunks of unknown size. The latter means that we will have to buffer each chunk of data until we have the data we need to decode it.

For the sake of simplicity we will do this by converting every chunk that comes in at a data event to a string variable and buffer that until the request is completed:

Note that the variable fullBody which contains all of the data is declared and initialized outside of the event handlers for data and end. This is essential because both need to have access to it.

Running this code will throw an error if you forgot to require the querystring module needed to decode the body data or the utils module which is just used to inspect() the decoded object. After adding those require() calls to the top of the code running the example will present the user with a JSON structure containing the username and userage keys and the data that has been entered into the form.

Okay that’s just weird, I want my $_POST

Granted, this blog post is intended to be really introductory and extensive for those who are just getting started with node.js.

If that’s inconvenient you should go with one of the previously mentioned frameworks that will do most of the work for you (e.g. the bodyDecoder middleware for connect).

What if I want file uploads & stuff?

If you have more complex or larger data structures in your HTTP body you might want to check the HTTP headers which encoding type is sent or process single key/value combinations as they get streamed in. If that’s the case and you are looking for a more convenient alternative you should check the body decoder middleware or module of one of the web server frameworks available in node.js or a standalone module that parses it.

For more details…

…check out the API docs at nodejs.org and join #Node.js on freenode or the mailing list if you get stuck. The full example code can be found in the gist.

Twitter

My primary twitter account was finally affected by Twitter’s rollout of their new interface – codenamed phoenix based on some filenames - yesterday. It seems like the interface already experienced some minor bugfixes in regards to usability since the rollout first started. The tech behind this new frontend has already been covered on their engineering blog.

Frontpage revamped

Besides the obvious design changes the frontpage of twitter suddenly becomes useful, at least for me. A quick overfew on the five latest followers provides a way to quickly decide wheter I want to follow them back or report that rarely dressed girl for spam.

It also features some filtered views on your timeline that shows retweets, mentions and provides quick access to saved searches. I really like that they integrated this set of features, especially because I was never a big fan of the column views that were offered by most desktop clients.

Pictures!

Your feed now contains little pictograms indicating the type of embedded content within some tweets. Pictures and other content from popular sites and media partners are now embedded directly in the view for single tweets – you’ll see these embeds when you click a tweet in your timeline or visit the URI for a single tweet.

Alas, you don’t get these embedded media when you embed single tweets with their tool Blackbirg Pie – which looks a bit antique now – but I assume they’ll change that after finishing the rollout.

Spotlight on: A tweet!

Viewing singular tweets by visiting their permalink gives you the previously mentioned embeds. Click a link in your timeline and you’ll get even more useful meta-information on the tweet as well as the accounts and hashtags it contains.

You’ll see other tweets from the original author, which might give you some context on what he/she wants to say with that funny picture in the tweet. It might also be interesting what that conference hashtag is all about or who else was mentioned in the tweet so you can easily decide if you want to follow those people. All this meta-information adds a whole new dimension of discovery (of topics, people & places) to browsing your timeline.

@reply / mention – It’s in a box!

When you mention a user or reply on a tweet it’s opened in a floating, resizable box which looks like the dialog boxes from jQueryUI. Those function previously redirected the user to the starting page.

Why this is a great change? Because the rest of the interface stays usable. You can browse to another persons profile, a search or any other view within the system to gather information you need to put those nasty 140 characters together. All without changing browser windows or tabs.

@replys? conversations!

The killer feature I see in the new twitter interface is that it finally turns @replys into useful and quickly comprehensible conversations. Clicking a tweet with the little chat-bubble symbol will now show the tweet in question, as well as the tweet it’s replying to.

When clicking an original piece of content, replies are now shown – even if you don’t follow the replying user. (Will we see a new form of reply-spam for influential users now?)

The earth keeps spinning

The old interface didn’t really emphasize location data within the Twitter platform. The new interface has it tightly integrated in singular tweet views and offers tools like “View Tweets at this place”. This makes their whole places database more useful for regular users – although it seems to lack mechanisms to “follow places” like you’d do with lists.

Anything I missed?

This article sure doesn’t cover all new / better integrated features of #NewTwitter – it’s what I find most useful at first glance. Did I miss anything really important? I’d love to hear your opinion. Let me know – here or directly on Twitter.

An example use case could be the start mode parameter of a script. A daemon that accepts the startup modes “help”, “start”, “stop” or “status” as the first and only parameter could look like this:

Example code (na-sample.js)

Usage

After providing the module with a list of words that should be checked in the constructor, the expand() function can be called to get a list of words that match or start with the term that was provided.

Module code (node-abbrev.js)

The complete gist with example and module code can be found here.

The code, which is available on JSBin, isn’t really optimized for anything but the whole thing is sure nice to watch.

node.js

Sadly the beamer showed only little contrast but I think I made a point showing the great development node.js is currently going through. It’s a nice alternative approach to scalable networking systems for real-time applications.

For information on the library visit nodejs.org and take a look at the great example applications like this one.

sshm rewrite with bash-completion

A quick script I hacked together because the default sshm implementation could not handle parameters, port parameters other than the default and it didn’t come with bash-completion. The code is far from optimal but it works. It mostly follows execution conventions that the traditional sshm proposed but the file format is incompatible.
The python file goes somewhere in $PATH, while the shell script should be put in /etc/bash_completion.d/ (or similar on your system).

Controlling your Ubuntu / Linux Mint desktop with a joystick (via pygame)

The pygame library for Python offers modules for joystick support and I had some time (obviously) on my hands so I hacked together a set of scripts to control my desktop machine with a gamepad / joystick. With 4 buttons and 2 axis I could give it some pretty neat functionality, even if I’m pretty sure I will never use it again.

The Python script starts a configurable process for each combination of button-click and axis-movements. For my tests I put together a shell script that uses wmctrl to navigate through my virtual desktops and added simulated keystrokes (with xte) to control my screen and irssi in a terminal.

Polls

When discussing parts text, graphics or other content elements many decisions can be accelerated by holding a quick poll. The default poll extension offers a choice between Yes/No/Maybe. There are other polls with customizable choices for those who seek a more advanced poll. I installed Yes/No/Maybe/+ because it mimics the design of the default extension.

Deadlines

The deadline extension shows a countdown to a specified date and time inside your wave. I have previously used this to track and limit my work inside a wave but it could come in handy for group edits, too.

Why not insert it into your wave the next time you use it to do a brain-storming? It can avoid endless discussions and help to focus on the task ahead.

Like / Dislike

When a poll simply isn’t enough or there are more complex decisions to make the Like / Dislike extension can be quite useful. The wave in the image below uses two of it to decide between two versions of a paragraph.

Syntax Highlighting

Being a developer I was searching for a way to add syntax highlighting to discuss code on Google Wave. Luckily the guys at Zen and the Art of Programming shared a bot to do just this.

For those who are not yet convinced, Gina Trapani and Adam Pash have compiled a nice (and more extensive) list in The Complete Guide To Google Wave.

Sometimes even the most productive developers need a time-out, I can really recommend the competitive game extensions for Sudoku and Chess. But they can get really addictive.

There were some pretty neat projects. Alas I haven’t had a chance to talk to all of them you can check out the full list (in German) over at the faculty website.

Distributed, fail-safe block devices

The guys researching distributed, fail-safe block devices did a great evaluation of current technologies and compiled a nice demonstration with three datastore nodes running virtual machine instances.

TeachRobot control

Some of the code for the “TeachRobot” robotic arm interface project is available over at 32leaves.net. I guess they’ll submit their work to Hack a Day soon. Meanwhile check out Christians Logic Analyzer project if you’re in lack of an oscilloscope.

SoapBubble Bot from 32leaves on Vimeo.

The goal of this semesters project, was to build a new interface for existing legacy hardware (actually 30 years old legacy). To demonstrate what we did, we came up with that little demo: making soap bubbles with a robot.

Lecture Podcasts

I really like the idea of multimedial learning in a way that’s up to date with current technologies. The guys who developed a neat lecture podcasting system presented quiet performant streaming and a neat, SilverLight based, web interface. Big plus was the video of my UnFUG lightning talk I gave yesterday to get in shape for my thesis presentation.

Others

Those were only three picks, even the first-semester project developing a touch-based information system for the faculty showed a decent progress this semester. Great work.