Linux Joysticks and Other System Devices in NodeJS

Everyone knows that NodeJS can be used to make über fast webservers. But did you know that it's good for low level tasks too? In this article we'll write a joystick driver for Linux. Technically it's not that low level, the kernel is handling the hard bits for us, but the results are still very cool.

Those who have seen my past experiments with SDL and OpenGL in NodeJS know that I love to give demos where I hook up a USB gamepad to a NodeJS server and do something cool with it. The problem was that I needed C++ bindings to libSDL to be able to talk to the gamepad.

It turns out I was wrong and (on Linux systems at least) it's trivial to read directly from the system device file and parse the protocol.

On Reading the Device

One nice thing about Unix systems is that everything is a file. Folders are files. Processes are represented as files. And USB gamepads are represented as files! So to test this theory, I ran cat on /dev/input/js0 which is the representation of my first joystick. I then moved the joystick around and stuff got emitted.

Hot dog, we're in business! Now if only there was a document that explained what all that binary nonesense meant.

Introducing The Great Wiki Challenge

In celebration of the official launch of Nodebits.org ("Our Commitment to the Node.js Community"), we’re introducing Nodebits’ first official contest – The Great Wiki Challenge.

The Rules

Ok, the goal of this contest is simple. Take this basic wiki (explained below) and turn it into something beautiful. The sky is the limit. You can add whatever features you think make for an awesome wiki.

The completed entry needs to be runnable in the Cloud9 development environment. Simply start by clicking on any of the "Edit in Cloud9" links on the code snippets and this git repo will automatically be cloned into your personal c9.io environment (don't worry, it's free). From there you can develop your additions and test your code.

Submitting an Entry

The due date for entries is the close of Node Summit. Your entry must be made before Monday, January 30th, at 12:01am PST (-8 GMT). Simply tag your git repository with wiki-contest and tweet a link to your c9.io project to @nodebits.

Judging

We will judge entries on the following criteria:

• Creativeness - Make it something neat. Think outside the box. Have fun.
• Beauty - Both the final interface and the source code that generates it should be pleasing to the eye.
• Usefulness - What good is a tool if it's not useful to anyone. Make it actually useful too.
• Simplicity - This is an often overlooked trait in software. Yes it often competes with the other goals, but it's a goal that must always be kept in mind. The code shouldn't be any more complicated than necessary. The user interface should be simple and easy to understand.

Prizes

I'm sure all of you don't need a prize to help motivate you in this endeavor, but I think prized make the competition funner.

I've always loved tinkering with small machines and making them do interesting things. Laptops and desktops are cool, but there is only so much they can do in the physical world. We will be giving away BeagleBone kits to the winners along with a slew of fun hardware add-ons to make really cool NodeJS powered robots.

If you enjoy using Cloud9 for developing your awesome wiki, the same environment (albeit a slightly older version) is used in the bundled SDK of the beaglebone. Node and a full IDE is run from an embedded device that fits into a used altoids can.

Enter for the glory, enter for the fun, enter to challenge yourself and learn more node!

Build a File Hoister

One of the goals of nodebits is to provide simple and easy to understand projects that can be taken apart and tinkered with. Click on the sample-app category link on the right to find other articles like this in the future.

In this edition, we will stack up a simple server that takes your filesystem and hoists it up on the internet via HTTP. You can download and browse files using GET requests and (when authenticated) DELETE files and PUT new files.

To keep things basic, we won't be using ExpressJS or even Connect. We'll be using simpler versions of those libraries, Stack and Creationix. Originally I developed these simpler versions both to scratch an itch and to run web servers on mobile phones.

Getting Started With a New App

Normally you would start by installing NodeJS, npm, and git and then running git init in a new folder. A nifty feature of this site is that the example code for all articles is already in git and you can edit and run the code directly in your browser.

First we'll create a package.json file so that we can declare our dependencies.

Here I filled in the minimal fields to get started. The only optional field was the private field. This is good for apps that aren't themselves libraries to be published to the npm repository.

Step Zero - An HTTP Server

As a setup step, let's get a web server up and running. We want to use the Stack and Creationix libraries to help us so we'll make a single-layer stack that logs all requests and responds with 404 codes.

Run this server, and then to test it, hit it with curl:

$ curl -i http://localhost:3000/
HTTP/1.1 404 Not Found
Content-Type: text/plain
Date: Thu, 05 Jan 2012 06:21:38 GMT
Server: NodeJS v0.6.6
X-Runtime: 0
Connection: keep-alive
Transfer-Encoding: chunked

Not Found

The server window has the output:

Serving /path/to/file-hoister at http://localhost:3000/
GET / 404 Content-Type=text/plain

Congratulations, you now have a working (and more importantly extensible) webserver running!

Distilled NodeJS Patterns

Every once in a while in the progress of a new technology, it's good to take a moment and reflect on good patterns that can be distilled from real world programs.

In this article I will explain a few of the patterns that I've discovered over the years. They mostly have to deal with control-flow and resource management.

On Power and Responsibility

NodeJS uses a very powerful I/O model where all operations are non-blocking. This makes many new things possible such as reading two files in parallel. It also creates many new pitfalls. For example, it's possible to run out of file descriptors because you opened the same file 10,000 times in parallel!

For example, using blocking I/O, this is safe:

Each call to FS.readFileSync waits for the disk I/O to complete before returning. This means that you will never have more than one file open at a time. Not so with non-blocking I/O:

If you run this script, you will get the following output:

/path/to/nonblockingloop.js:5
    if (err) throw err;
                   ^
Error: EMFILE, too many open files '/path/to/nonblockingloop.js'

The problem here is that since the async version of FS.readFile is non-blocking, each call starts a background reading of the file and returns immediately. The for loop will try to open the same file 10,000 times at once and run out of file descriptors on most systems.