Reznik, JSQA, Riloadr

20 Apr 2012 | By Alex Young | Comments | Tags node amd images responsive


Reznik (License: MIT, npm: reznik) by Alex Lawrence is a code analysis tool for AMD projects. Given a set of AMD modules, Reznik’s server-side component can resolve individual module dependencies on demand. It builds a module list, and then checks the code for circular or missing dependencies.

The author notes that Reznik was developed in Node, but also works in PhantomJS. There’s a command-line tool that can run under either of these environments and output module lists using various formats, including HTML and JSON.


JSQA from PaquitoSoft uses JSHint to statically analyse your code using an Express/Bootstrap-powered web application. It uses Socket.IO and or fs.watchFile so changes to source files are updated dynamically.

The lib/config.js file must be edited to include a path to a suitable JavaScript project.


Riloadr (License: MIT) by Túbal Martín is a cross-browser, framework-independent responsive image loader. The library supports quite a few options, but basic usage involves specifying “breakpoints” for loading the right images based on the viewport’s size:

var group1 = new Riloadr({
  breakpoints: [
    { name: '320px', maxWidth: 320 }, // iPhone 3
    { name: '640px', maxWidth: 320, minDevicePixelRatio: 2 }, // iPhone 4 Retina display
    { name: '640px', minWidth: 321, maxWidth: 640 },
    { name: '1024px', minWidth: 641 }

As this example demonstrates, Riloadr is a useful library for supporting high-density displays.

When Riloadr parses your breakpoints it mimics CSS behavior: Riloadr computes the browser’s viewport width in CSS pixels, then traverses your breakpoints to find out the appropiate image size to load and makes use of your breakpoint names to get the correct src (image URL) to load the image.

JavaScript and Semicolons

19 Apr 2012 | By Rod Vagg | Comments | Tags language ECMAScript ASI


In syntax terms, JavaScript is in the broad C-family of languages. The C-family is diverse and includes languages such as C (obviously), C++, Objective-C, Perl, Java, C# and the newer Go from Google and Rust from Mozilla. Common themes in these languages include:

  • The use of curly braces to surround blocks.
  • The general insignificance of white space (spaces, tabs, new lines) except in very limited cases. Indentation is optional and is therefore a matter of style and preference, plus programs can be written on as few or as many lines as you want.
  • The use of semicolons to end statements, expressions and other constructs. Semicolons become the delimiter that the new line character is in white-space-significant languages.

JavaScript’s rules for curly braces, white space and semicolons are consistent with the C-family and its formal specification, known as the ECMAScript Language Specification makes this clear:

Certain ECMAScript statements (empty statement, variable statement, expression statement, do-while statement, continue statement, break statement, return statement, and throw statement) must be terminated with semicolons.

But it doesn’t end there–JavaScript introduces what’s known as Automatic Semicolon Insertion (ASI). The specification continues:

Such semicolons may always appear explicitly in the source text. For convenience, however, such semicolons may be omitted from the source text in certain situations. These situations are described by saying that semicolons are automatically inserted into the source code token stream in those situations.

The general C-family rules for semicolons can be found in most teaching material for JavaScript and has been advocated by most of the prominent JavaScript personalities since 1995. In a recent post, JavaScript’s inventor, Brendan Eich, described ASI as “a syntactic error correction procedure”, (as in “parsing error”, rather than “user error”).

Recent Developments

There has been a growing trend in the last few years toward the omission semicolons, in some cases totally avoiding them. Perhaps largely inspired by the likes of CoffeeScript and Ruby where semicolons are used only if you want to chain multiple statements on a single line. This view of semicolons could perhaps be summarised as: the semicolon character is optional in most situations and therefore introduces unnecessary syntactic noise–unnecessary syntax can (and maybe should) be avoided.

Unfortunately the division between the semicolon and semicolon-free crowd has become very pronounced and is leading to some angry exchanges. A recent lightning rod for semicolon-related controversy is the most watched project on GitHub, Twitter’s Bootstrap and the author of its JavaScript code, Jacob Thornton who is a convert to the semicolon-free camp.

A short exchange this weekend on GitHub between Thornton and a cranky Douglas Crockford (author of perhaps the most-read JavaScript book, JavaScript: The Good Parts) erupted, on GitHub, Twitter and across the Internet.

The initial issue was a request for the addition of a semicolon in order to assist Crockford’s JavaScript minifier tool, JSMin, to properly compress the code. Like Crockford’s other popular JavaScript tool, JSLint, JSMin follows his rigid view of what the best parts of JavaScript are and reject the other, bad, parts, including treating semicolons as optional.

Crockford, after reviewing the code in question stated:

That is insanely stupid code. I am not going to dumb down JSMin for this case.

Learn to use semicolons properly. ! is not intended to be a statement separator. ; is.

To which Thornton replied:

i have learned to use them, that’s why there isn’t one present.

Rather than continue the debate, perhaps it’s best to review the rules surrounding semicolons in JavaScript so we can make informed decisions about our own coding style preference and we can learn to contend with code produced by programmers who have other preferences.

As an aside, it should be noted that both Bootstrap and JSMin have been patched to resolve the relevant issues in both.

Rules of ASI

The ECMAScript Language Specification deals with ASI in section 7.8 of editions 1 (PDF) and 2 (PDF) and section 7.9 of editions 3 (PDF), 5 (PDF) and the current drafts of edition 6. The text has stayed roughly the same through the different editions except for the inclusion of continue, break and throw statements in special cases that previously just applied to return. More on this below.

Simply put, the first basic rule of ASI is:

  • If the parser encounters a new line or curly brace, and it is used to break up tokens that otherwise don’t belong together, then it will insert a semicolon.

The new line character is the one most commonly used in taking advantage of ASI so we’ll restrict ourselves mainly to this case. The most common situation where you’ll see curly brace ASI occurring is in code such as: if (foo) { bar++ }. It should be noted, however, that you could surround all your statements, expressions, etc. in curly braces if you wanted to avoid semicolons, i.e. place everything in its own block; although this offers limited help in achieving the kinds of goals that the semicolon-free crowd advocate.

So, as a beginning example, the code:

a = b + c

has ASI applied because stringing the tokens together without the new line doesn’t help. Otherwise, it would be interpreted as c foo() which isn’t correct. The parser makes it look like this internally:

a = b + c;

// or

a = b + c; foo()

But here we find the most important alleged problems with taking advantage of ASI in your coding style. The important part of the first rule of ASI is that it will only apply if the parser needs to do so in order to make sense of the code in question. Consider the following code:

// example 1
a = b + c

// example 2
a = b + c
(options || {}).foo ? bar() : baz()

In both of these cases, the parser doesn’t need to apply ASI in order to have properly formed code. In the first example, it can ignore the new line and treat the [ as applying to c, likewise in the second example, the ( can apply to c. So we would end up running something quite different than we might be trying to achieve:

// example 1
a = b + c[1].push(a)
// i.e. fetch the first element of 'c' and execute the 'push' function on what it finds

// example 2
a = b + c(options || {}).foo ? bar() : baz()
// i.e. execute 'c' as a function and check for the existence of the property 'foo' on the returned object

Moving on in the language specification, there are a few of special cases:

  • ASI is never performed if it would result in an “empty statement”.

Empty statements ordinarily look like this (note the semicolons, there’s a statement there, it’s just “empty”):

for (counter = 0; counter < something(); counter++);
// or
if (condition);
else {

This is perfectly legal JavaScript and may even be useful in certain situations. However, ASI will never help you achieve this so if you have constructs that would lead to empty statements (if there were semicolons) then you’ll simply get an error:

if (condition)
else {
  • ASI is not performed within the head of a for loop, where semicolons are an integral part of the construct.

So no ASI is applied in cases such as:

for (var i = 0;
  i < a.length
// may as well be written as:
for (var i = 0; i < a.length; i++) ...
  • ASI is performed if the parser reaches the end of a file and a semicolon will help the code make sense. In other words, even if you don’t have a new line at the end of your file, it will perform ASI in the same way as if there was one.

There is one final rule in the language specification regarding ASI. This rule overrides the first rule in some special cases, called “restricted productions”. I’ll split this rule into two to separate out an uncommon case with a much more common case.

  • ASI is always performed on code where a new line character comes before a -- or a ++, even where removing the new line character would still make a valid construct.

This rule is arguably not so important to understand or remember because it doesn’t affect code that the majority of programmers would write. Consider the following program where each section contains identical sequence of ‘tokens’ except for the semicolons and white space characters. Try to predict the output for yourself:

var a, b, c;

// 1) plain
a = b = c = 1; a++; b--; c; console.log('1)', a, b, c)

// 2) extra spaces
a = b = c = 1; a ++ ; b -- ; c; console.log('2)', a, b, c)

// 3) new lines v1
a = b = c = 1
a ++
b --
console.log('3)', a, b, c)

// 4) new lines v2
a = b = c = 1
++ b
-- c
console.log('4)', a, b, c)

// 5) new lines v3
a = b = c = 1
console.log('5)', a, b, c)

As per our ASI rule, even though the new line character doesn’t interrupt a valid code construct (a ++ would be the same as a\n++ in most C-family languages), the parser will always insert a semicolon when it encounters a ++ or -- after a new line character. So instead of being postfix operators as in a++ and b--, they become prefix operators on the next variables in the token stream: ++b and --c.

The output from the above program is:

1) 2 0 1
2) 2 0 1
3) 2 0 1
4) 1 2 0
5) 1 2 0

The simple moral here is to follow standard C-family coding practice and keep your postfix and prefix operators attached to the variables they are applied to.

The second part of the final rule is more relevant as it can conflict with what you might encounter in standard C-family programs:

  • ASI is always performed where new line characters follow directly after any of the following statements: continue, break, return and throw.

While not common, both continue and break can be followed by a label, indicating where to jump to (labels with these two statements are the less ‘evil’ cousins of the much maligned goto found in many other languages). If you intend for the program to jump to a label then you must not separate the label from the continue or break by a new line character:

// not the same as:
continue foo;
// actually interpreted as:

// not the same as:
break foo;
// actually interpreted as:

The return and throw rules are much more interesting because, like the first rule of ASI, it can lead to non-obvious problems in common code. Generally, a stand-alone throw statement will lead to parse errors, so you should find out fairly quickly that this code is no good because you’ll get some kind of parse error:

  new Error('Aieee!')
// interpreted as:
new Error('Aieee!');

If you have a long line of code containing a throw statement and you wanted to improve readability by using new line characters. You cannot insert the new line straight after the throw or you’ll end up with invalid code, i.e. a throw that doesn’t have anything to throw. You’ll have to rewrite your code or find a different place to introduce the new line character that fits your coding style. For example:

throw new Error(

The most commonly used of the four statements we are considering is return. It is quite common to try and append a complex series of tokens to a return statement or even use return as an ‘early return’ from a function, sometimes leading to long lines that we may be tempted to break up with new lines. Consider:

// a common Node construct, an 'early return' after a callback upon receiving an error:
if (err) {
   callback('Error while processing something that takes a lot of words to describe: ' + err)

As per the ASI rule, the new line character directly following the return leads to the insertion of a semicolon so we actually end up with our ‘early return’ being a bit too early and our function call becomes dead code. The above code is interpreted as something that is clearly not intended:

if (err) {
 callback('Error while processing something that takes a lot of words to describe: ' + err);

The impact of ASI on this type of code is particularly sinister because it can be difficult to pick up. We were not intending to use return to actually return a value, but to halt execution of the current block. We’re not going to be needing or perhaps even using a return value from the containing function–discovering the error will need somethingElseHere() to have obvious side-effects, which is not always the case.

The same ASI procedure occurs when we try to fit too much into our return value and are tempted to break it up with new lines:

if (foo) {
    (something + complex()) - (enough[1] / to) << tempt + us(to - linebreak)

It’s clear here that we’re intending to return a value calculated by the long code string and we’ve attempted to improve readability by breaking it up with new line characters, or perhaps you have a vertical line in your editor that tempts you to do this kind of breaking.

We end up with an empty return and some dead code:

if (foo) {
  (something + complex()) - (enough[1] / to) << tempt + us(to - linebreak);

It’s important to remember that if you need to have long lines of code beginning with a return then you can’t start with a new line straight after the return, you’re going to have to find somewhere else to break if you really must break–or even better, avoid long return lines completely.

Gentle Advice

It should be clear, particularly from the last rule outlined above, that we don’t need to be following a semicolon-free coding style to fall foul of JavaScript’s ASI feature. Perfectly innocent line breaking can lead to semicolons being inserted into our token stream without our permissions so it’s important to be aware of the kinds of situations where this can happen. Much of the recent debate about semicolons misses this point. Additionally, love or hate ASI, it’s with us and is not going away so perhaps it would be more productive to embrace it as a feature and use it where it suits us and work around it where it doesn’t.

Regardless of your preference, ASI and other obscure rules in non-trivial languages such as JavaScript mean that our build tools should involve some kind of syntax checking mechanism. Strongly-typed languages such as Java have sophisticated editors that can understand the intent of your code and provide real-time feedback as you type. It’s a little more complex in JavaScript but we do have excellent tools that can analyse our code and point out potential problems or code style that may lead to common hazards.

JSLint by Douglas Crockford is perhaps the best known syntax checking tool available for JavaScript. It will encourage you to follow Crockford’s personal coding style, which he believes leads to fewer syntax-related errors.

JSHint was developed as a much-less-opinionated alternative to JSLint. It has many options that let you tailor it to your personal preferences while still steering you away from potential errors, ASI-related and other.

These tools can be run across source files at build time (via a Makefile or as part of your test runner for example), or embedded directly in the text editors most commonly used by JavaScript programmers. Vim, TextMate and SublimeText all have ways of running JSLint or JSHint as you edit, providing quick feedback on any potential code problems. Even the most experienced JavaScript developers can bump into occasional ASI-related problems, having build tools that can point us in the right direction is just common sense.

Semicolon-free Best Practice

If you lean towards a semicolon-free style, there are some well-established conventions that can help produce less error-prone code. One of the largest JavaScript projects following a semicolon-free style is npm by Isaac Schlueter who is now lead developer of the NodeJS project. npm is Node’s package manager and the code has a very particular coding style that is followed by many who advocate semicolon-free. Aside from minimal use of semicolons, this style is also characterised by comma-first, putting the emphasis on putting necessary syntax at the beginning of lines rather than at the end, where they can be easily overlooked.

To alleviate problems caused by ASI, Isaac advocates inserting a leading semicolon on lines that begin with syntax that could be interpreted as following on from the previous line. In particular the [ and ( characters. Our examples above involving these two characters can be rewritten as:

// example 1
a = b + c

// example 2
a = b + c
;(options || {}).foo ? bar() : baz()

By placing semicolons and commas at the beginning of the line, we elevate their importance in the token stream and potentially assist our own brains in identifying problems. Isaac has a great post dealing with this and other ASI issues.

Lastly, let’s try and keep things in perspective. The JavaScript community has generated a lot of heat over a single, humble, character. There are bigger mountains to climb and we would be better off expending all that energy on building awesome things!

Node Roundup: OneJS, node-pad, CouchPress, node-linq

18 Apr 2012 | By Alex Young | Comments | Tags node modules databases couchdb games linq
You can send in your Node projects for review through our contact form or @dailyjs.


OneJS (npm: one) by Azer Koculu is a command-line utility for converting CommonJS-style packages to browser-friendly JavaScript. It provides Node-compatible APIs, and the output can also be run with Node if required.

All it needs is a suitable package.json file:

$ onejs build package.json bundle.js

Some of Node’s standard library is technically supported by most browsers, and OneJS supports this by providing the install command:

$ onejs install assert

This will create a module in ./node_modules/assert/ with a package.json and a OneJS version of Node’s assert module.

Azer said he created this project for Multiplayer Chess, which is a web-based chess game that supports up to 25 players.


Do you like video games, or at least the DualShock 3 controller? node-pad (npm: node-pad) by Andre Tangen is a game controller library that currently supports Sony’s controller:

controller.rthumb.on('move', function(event) {
    x: event.x
  , y: event.y

The author has included Jasmine tests, and the project depends on Andre’s node-hid fork which is built using node-waf.


CouchPress (GitHub: koostudios / couchpress, License: MIT, npm: couchpress) by Alexander Yuen is a CouchDB and Express-based publishing platform. It’s currently very simple, but includes a minimal administration interface, a WYSIWYG editor, and the beginnings of a theming engine.

The author is planning on adding a Markdown editor, and support for plugins. He’s very open to suggestions, so if you’re interested in supporting a Node-based CMS then try getting in touch with him. Contact details are available in his 0.1 announcement post: CouchPress: Announcing Version 0.1.


node-linq (License: MIT, npm: node-linq) from Fractal is a LINQ implementation for node:

{LINQ} = require 'node-linq'
fs = require 'fs'
{extname} = require 'path'

files = ['test.txt', 'choni.txt', '', 'secrets.txt', 'etc.rar']

arr = new LINQ(files)
.Where((file) -> extname(file) is 'txt')
.OrderBy((file) -> fs.lstatSync(file).mtime)

# arr == [ 'choni.txt',  'text.txt', 'secrets.txt']

It also supports Asynchronous LINQ. The readme has examples, and there are Mocha tests.

jQuery Roundup: Touch Patents, Standalone Deferred, Mailcheck.js

17 Apr 2012 | By Alex Young | Comments | Tags jquery plugins touch mobile promises email
Note: You can send your plugins and articles in for review through our contact form or @dailyjs.

Touch Patents

In Getting Touchy About Patents on the official jQuery blog, the relationship between Apple and W3C’s efforts to standardise touch events is discussed. At the end of the aritcle, there are several calls to action, some of which DailyJS readers can help with:

We would also encourage the community to experiment with Touch and MSPointer. Play with the APIs, build apps, and provide feedback.

If you know of any prior art for multi-touch/touch lists, even outside of the Web, please get in touch with the W3C.

The distinctions between pointer events and touch events are also explored. This comment in particular is interesting:

It’s conceivable that in a few years developers could use Pointer Events as the only event model for pointers, leaving Mouse Events as a thing of the past.

Standalone Deferred

Standalone Deferred (License: MIT) by Otto Vehviläinen is a standalone implementation of jQuery.Deferred. The Deferred object is a chainable API based on the CommonJS Promises/A specification.

The project is distributed with Jasmine tests, and features the expected methods including when, then, resolve, and reject. The author has rewritten the library using CoffeeScript, so it’s not a quick and dirty extraction from jQuery’s code.


mailcheck.js (License: MIT) by Derrick Ko and Receivd, Inc., is designed to help reduce email address typos by checking input field values against a list of popular email providers:

var defaultDomains = ["", "", "", "", "", "", "",
                      "", "", "", "", "", "",
                      "", "", "", "", "", ""];
var defaultTopLevelDomains = ["", "com", "net", "org", "info", "edu", "gov", "mil"];

The author has written a post that claims this reduced confirmation email bounces by 50%.

Meteor, Qatrix, WebKit Remote Debugging 1.0

16 Apr 2012 | By Alex Young | Comments | Tags frameworks node animation debugging


Meteor (License: GPL v2, GitHub: meteor / meteor) is a web framework that provides the same APIs for both the client and the server. It has similar goals to other projects we’ve featured on DailyJS before, such as Derby, and already includes some great documentation.

Applications run using Node, but the authors have provided an installation script rather than distributing it with npm. Instead of using Node’s asynchronous API style, fibers have been used. Code that’s only suitable for the server is kept inside server/ directories. Rendering is performed client-side – server-side templates are generally lightweight.

An important aspect of Meteor application structure is the use of a client/server model. A MongoDB database is used, and data is distributed between the server and clients. Clients subscribe to messages that they’re interested in. Templates are data-driven, and this is modelled using the reactive programming paradigm.

Meteor comes with scripts to bundle and deploy applications, and applications can be deployed to Meteor’s servers for free:

$ meteor deploy

This can be used on a trial basis:

We provide this as a free service so you can try Meteor. It is also helpful for quickly putting up internal betas, demos, and so on.

For all the excitement around Meteor, and the famous developers who founded the project, there are a few glaringly obvious problems with it. For example, Google can’t see Meteor’s website at all (search for This may not be a problem for applications, but I’d consider developing the public pages with something else or as a static site. It also includes its own packaging system, which is confusing to me as a Node developer. Finally, authentication is not addressed, but the developers are working on it.


Qatrix (GitHub: qatrix / Qatrix, License: MIT) by Angel Lai is a client-side framework with some bold claims. There are four Qatrix benchmarks which will compare performance to jQuery 1.7.1, and it’s meant to support IE6-10, but there aren’t yet any unit tests so I’m not sure how solid these claims are right now.

The developers have written some pretty good documentation for Qatrix already, and after reviewing the code on GitHub I realised what their angle is: it’s jQuery without the friendly chainable API in order to boost performance.

Consider this jQuery example:

$('.box_wrap span')
  .text('I found this span!')
  .attr('title', 'this is title')
    'color': '#C15547',
    'font-size': '18px'

This is the equivalent in Qatrix:

$select('.box_wrap span', function(item) {
  $text(item, 'I found this span!');
  $attr.set(item, 'title', 'this is title');
  $css.set(item, {
    'color': '#C15547',
    'font-size': '18px'

It’s not a world apart from the jQuery example, and someone could build a chainable API wrapper around Qatrix if they really wanted to. The GitHub history only goes back to March 17th, so it’s a very young framework – I expect the authors would appreciate contributions from fellow client-side hackers.

WebKit Remote Debugger

Version 1.0 of the WebKit remote debugging protocol has been announced: Announcing Remote Debugging Protocol v1.0. Remote debugging can be enabled in Chrome, and WebSockets are used for communication with the debugger.

It’s even possible to connect one WebKit browser to another, because Chrome includes a small HTTP server – Web Inspector can be used as a remote debugging client.

Driving Google Chrome via WebSocket API is a tutorial by Ilya Grigorik that shows how to write a remote debugging client. His example is in Ruby, but it’s just HTTP requests and JSON:

The example above illustrates a very simple interaction with the Network API, but the protocol exposes much more. You can drive the JS debugger, control the V8 VM, modify and inspect the DOM, and track Timeline events amongst half a dozen other capabilities.

Colonne, n8iv, Three Bad Parts

13 Apr 2012 | By Alex Young | Comments | Tags backbone.js oo language


Colonne (GitHub: rtsinani / colonne, License: MIT) by “rtsinani” is a small Backbone.js library that extends Backbone.History to expose two new properties: path and params:

// URL fragment: /products/search?names=apple&names=nectarine&page=1

Backbone.history.path               // 'products/search'
Backbone.history.params['names']    // ['apple', 'nectarine']
Backbone.history.params['page']     // '1'

It also works with Backbone.history.navigateWith.

The author has included Backbone’s router tests to demonstrate that Backbone’s original functionality still works, and has added new tests for Colonne.


n8iv (License: MIT) by Christos Constandinou is an OO library that extends native objects with Object.defineProperty. The author has written lots of documentation that’s viewable on GitHub at constantology / n8iv / docs. The documentation shows what objects have been extended and what the n8iv classes provide.

For example, there’s an event library that works like this:

var observer = n8iv.Observer.create();
observer.log = console.log;

observer.on('foo', log)
        .on('foo', observer.log, observer)
        .broadcast('foo', 1, 2, 3);

The n8iv.Class library supports mixins, singletons, and super methods.

The author also notes that native methods are not overridden if they’re already defined. In addition, the other n8iv libraries like n8iv.Oo.js can be used without the native extensions.

Three Bad Parts

In JavaScript - Only Three “Bad” Parts, John Paul discusses Douglas Crockford’s JavaScript:The Good Parts and how there are only really three “bad” parts. His post is actually more about learning the language properly than problems inherent to JavaScript.

John argues that once this, prototypal inheritance, and functions are properly understood, then budding JavaScript developers can be more productive.

When was the last time that you had a really hard time using the void keyword or were foiled by type coercion?

Unix and Node: Syslog

12 Apr 2012 | By Alex Young | Comments | Tags node tutorials unix cli logging

Syslog is a standardised logging system that’s present in most BSD and Linux distributions. There are various implementations; syslog-ng is a popular one that I usually find myself using. The interesting thing about syslog is it can be configured to store messages anywhere – logs can be written to files or remote daemons.

The main reason for using syslog in your Unix-oriented projects is to separate the concerns between your application code and configuration. The same application logging to a local syslog daemon could log to a remote daemon without any changes to the application itself. In addition, syslog also has lots of useful features like log rotation, file compression, and interoperability with other applications that use syslog.

It’s amazing to think that syslog was originally created by Eric Allman as part of Sendmail. Over the years it’s found uses far beyond its origins, and as a result there are now several standards that pertain to syslog — RFC 5424 and RFC 3164 are probably the most important when it comes to looking for compliant implementations.

Syslog Basics

Writing a message to syslog is as simple as running logger in a shell:

$ logger Hello from DailyJS

On most systems this message should now be visible in /var/log/syslog, or /var/log/system.log on a Mac.

$ tail -f /var/log/system.log
Apr 12 14:45:18 b alex[15070]: Hello from DailyJS

The priority level can also be included with the message. Take a look at man logger to read more about priorities and facilities.

Syslog in Node

Most programs write to syslog using the openlog and syslog standard C library functions. That means it’s not trivial to use pure JavaScript to call these functions – a small binding is required. To get around this, some Node modules require syslog to be configured to accept TCP connections.

The node-posix (License: MIT, npm: posix) module by Mika Eloranta is one option for writing to syslog using the openlog and syslog functions:

var posix = require('posix');

posix.openlog('test-node-syslog', { cons: true, ndelay: true, pid: true }, 'local0');
posix.setlogmask({ info: 1, debug: 1 });
posix.setlogmask({ emerg: 1, alert: 1, crit: 1, err: 1, warning: 1, notice: 1, info: 1, debug: 1 });
posix.syslog('info', 'hello from node-posix (info)');

Note that if this is run on a Mac the result might be stored to /var/log/appfirewall.log because Apple’s configuration routes local0 messages here. The easiest way to view log messages on a Mac is to open the Console application and select “All Messages”. When I tried this example in Linux the message was written to /var/log/syslog.

This module actually uses the same signatures as the C functions. That means the last parameter for posix.openlog is ‘facility’ – the available and recommended options are documented in the project’s readme file.

An alternative is node-syslog (License: MIT, npm: syslog) by Alexis Sellier. This one uses TCP to communicate with syslog – the author has provided some configuration examples for setting up syslog-ng to accept TCP connections.

The API for node-syslog is very simple:

var syslog = require('syslog')
  , logger = syslog.createClient(514, 'localhost');'Hello from DailyJS');

If you already use winston for logging, then winston-syslog is a winston transport that can write messages to syslog over TCP.


There are other modules out there, but most either use the standard C library functions or TCP streams like the ones I’ve mentioned.

Some modules attempt to communicate with the datagram log socket /dev/log, but support for Unix datagram sockets was removed from Node so this won’t work anymore. Support for Unix datagram sockets has been provided by the node-unix-dgram module by Ben Noordhuis, but I haven’t found a syslog module that uses it.

Node Roundup: 0.6.15, node-inherit, Synchronize.js, jaded

11 Apr 2012 | By Alex Young | Comments | Tags node modules jade templating thumbnails images async fibers
You can send in your Node projects for review through our contact form or @dailyjs.

Node 0.6.15

Node 0.6.15 is out. It includes npm 1.1.16, and some platform-specific bug fixes for Windows and Mac OS.


Thumbbot (GitHub: vdemedes / thumbbot, License: MIT, npm: thumbbot) by Vadim Demedes is a thumbnail generator API built with PhantomJS, ImageMagick, and ffmpeg.

The Thumbbot class is instantiated with a source and output file:

bot = new Thumbbot 'video.mp4', 'video_thumb.png'
bot.set width: 200, height: 150
bot.set position: '00:05:04'
bot.snap (err) ->
    # done

The author has included Mocha tests, and various output formats are supported (png, jpg, gif).


node-inherit (License: MIT, npm: inherit) by Dmitry Filatov adds some sugar to help with class-like declarations, constructors, super calls, and static methods.

An inherited class looks like this:

var B = inherit(A, {
    getProperty: function() {
      return + ' of instanceB';

    getType: function() {
      return this.__base() + 'B';

  staticMethod: function() {
    return this.__base() + ' of staticB';

This example assumes a class called A – notice how the getType method can access A’s getType using this.__base. The full example can be viewed in the project’s readme.

Dmitry has included some Nodeunit tests that also demonstrate the main features of the library.


Synchronize.js (GitHub: alexeypetrushin / synchronize, License: MIT, npm: synchronize) by Alexey Petrushin is another library that’s built on fibers to attempt to “flatten” all of those pesky callbacks people like to talk about on Hacker News.

Existing methods can be wrapped with the sync method provided by the library:

var sync = require('synchronize')
  , fs = require('fs');

fs.readFile_ = sync(fs.readFile);

sync.fiber(function() {
  var data = fs.readFile_(__filename, 'utf8');

  try {
    data = fs.readFile_('invalid', 'utf8');
  } catch (err) {

Asynchronous methods can be used in a synchronous fashion within the sync.fiber callback. Wrapped functions will behave as if return and throw were called synchronously. The author has written Mocha tests, but the library itself is fairly small so it’s not too hard to figure out how it uses fibers to wrap functions: synchronize.js.


jaded (License: MIT, npm: jaded) from Fractal is an alternate command-line interface for Jade that includes AMD support:

  Usage: jaded [options]


    -h, --help            output usage information
    -V, --version         output the version number
    -i --input [folder]   Specify input folder
    -o --output [folder]  Specify output folder
    -d --development      Beautify output and insert line numbers
    -a --amd              Wrap output in AMD closure

jQuery Roundup: modplug, NailThumb, HiddenPosition

10 Apr 2012 | By Alex Young | Comments | Tags jquery plugins images thumbnails jqueryui
Note: You can send your plugins and articles in for review through our contact form or @dailyjs.


modplug (GitHub: lrsjng / modplug, License: MIT) by Lars Jung is an abstraction on top of jQuery plugins that makes adhering to jQuery’s Plugins/Authoring document a little bit easier.

Using modplug to define a plugin will automatically put methods under the same “namespace”. Static methods can also be defined:

modplug('color', {
  statics: {
    random: function() {
      return 'hsl(' + Math.floor(Math.random() * 360) + ',95%,75%)';

  methods: {
    back: function(col) {
      return this.each(function () {
        $(this).css('background-color', col);

$(selector).color('back', '#f00');

// get a hsl formatted color string
var col = $.color.random();


NailThumb (Repository: SourceForge / NailThumb, License: GPL v3) from Garralab is an image thumbnail plugin that can apply animation effects and a scrolling tooltip. A container is assumed, so basic usage looks like this: $('.nailthumb-container').nailthumb().

CSS has been supplied, and there are also LESS mixins.


HiddenPosition (Repository: SourceForge / HiddenPosition, License: GPL v3) also from the developers at Garralab is based on jQuery UI Position, but has been adapted to work with hidden elements. There’s an interactive demo on the project’s page that shows how it works.

The API is compatible with $().position, so existing jQuery UI projects can simply swap this with $().hiddenPosition.

Licensing for JavaScript Projects

09 Apr 2012 | By Alex Young | Comments | Tags tutorials licensing

Each project we feature on DailyJS includes the license. If your project doesn’t include a license, it may not be used by the wider community and commercial developers.

Why is licensing important? From the author’s perspective, it can be used to influence how the project is reused. From our perspective, as users of your software, the license determines whether we can legally reuse your software.

License Types

Licenses are split into permissive and copyleft. Permissive licenses have less restrictive requirements about how the software can be redistributed – copyleft licenses aim to preserve the freedoms dictated by the original license.

Under these broad categories, the GPL is a copyleft license. The MIT license is a permissive license.

GNU’s site explains how to use the GPL. Other initiatives aim to help configure the most appropriate license for a given project, such as the Creative Commons non-profit organisation. For a large list of licenses, see the OSI’s list here: Open Source Licenses by Category.

jQuery Plugins and Client-side Projects

Many of the jQuery plugins we receive for review are dual licensed under the GPL and MIT. Why? Well, this allows the author of a derivative work to choose either license for their work.

The jQuery project itself has some comments on this: jQuery License

The MIT License is recommended for most projects. It is simple and easy to understand and it places almost no restrictions on what you can do with a jQuery project. If the GPL suits your project better you are also free to use a jQuery project under that license.

If you’re writing a jQuery project, consider adopting this approach as it’s widely used by the community.

Node Modules

It’s pretty clear at this point that Node developers like permissive licensing. Almost all of the Node modules we receive are MIT licensed. Let’s take a look at the current top 5 projects according to npm’s stats:

  • Underscore: MIT
  • CoffeeScript: MIT
  • Request: Apache License Version 2.0
  • Express: MIT
  • Async.js: MIT

Notice that the Apache License is also a permissive license.

Isaac Schlueter wrote an interesting post about a modification to permissive licenses called “no-false-attribs”: Wanted: “no-false-attribs” OSS License. People are starting to include “MIT no-false-attribs” with their projects to denote that any derivatives must amend incorrect references like contact information and bug reporting links.

How to Include a License

It’s not acceptable to simply paste a license’s text into your readme, or a license file in the project. The license must be edited to include your name and the date of copyright.

Include the name of the license in your project’s readme and the license file. The name is important – people don’t want to have to memorise and recognise license text, they simply want to look for license names they know are compatible with their project’s policies. From my perspective, I want to be able to include the license name in my articles.

Also consider writing a package.json – even if it’s not a Node project! A well-written package.json includes a license, author information, homepage and repository links.


  • Choose a license based on your organisation’s policies, or your own opinions – have a look at some permissive or copyleft licenses and see what fits
  • Include the name of your license in your project’s readme
  • Add the license to your project as a text file, and edit it to include your name
  • Write a package.json that includes the license name even if it’s a client-side project


This article was inspired by Why I’d like a “license type” setting for GitHub projects by Thomas Fuchs.

Krisztian Toth's JavaScript Games, XRegExp, PlastronJS

06 Apr 2012 | By Alex Young | Comments | Tags games closure-library regex

Krisztian Toth’s JavaScript Games

JavaScript Boulder Dash

Krisztian Toth makes browser-based conversions of retro games. JavaScript Boulder Dash is an extremely elaborate version of the classic Boulder Dash which includes a level creator. Krisztian has made the source available (in non-minimised form) here:

This is built on jQuery 1.7.1, and provides some interesting insights for those looking for guidance with game engine architecture.

Wizard of Wor

He’s also ported the Commodore 64 version of Wizard of Wor, with source available in jWoW.js.

Krisztian builds these games with a manifesto of sorts, where he tries to create addictive gaming worlds by writing code that aims to make the illusion as solid as possible, without distracting the user with overly technical solutions. I definitely enjoyed playing his version of Boulder Dash, even though I’m actually pretty bad at it (I blame my keyboard, I need a controller!)


XRegExp (GitHub: slevithan / XRegExp, License: MIT, npm: xregexp) by Steven Levithan is an impressive regular expression library that works in Node and even Internet Explorer 5.5. Regular expressions must be represented as strings to make Steven’s extensions possible, but the examples are compelling:

// Using named capture and flag x (free-spacing and line comments)
var date = XRegExp('(?<year>  [0-9]{4}) -?  # year  \n\
                    (?<month> [0-9]{2}) -?  # month \n\
                    (?<day>   [0-9]{2})     # day   ', 'x');

// XRegExp.exec gives you named backreferences on the match result
var match = XRegExp.exec('2012-02-22', date);; // -> '22'

// In fact, all XRegExps are RegExps and work perfectly with native methods
date.test('2012-02-22'); // -> true

Native prototypes can be extended to use XRegExp, if required, by calling XRegExp.install('natives').

Optional Unicode libraries are included which can be used to add support for several useful expressions:

XRegExp('^\\p{Hiragana}+$').test('ひらがな'); // -> true

XRegExp includes a whole load more, which is documented on both the project’s website at and the XRegExp readme.


PlastronJS (License: MIT) by Rhys Brett-Bowen is a new framework built on the Google Closure Library for use with the Closure Compiler:

PlastronJS though is not just an MVC framework, it’s the start of an application framework. I’ve decided to include a mediator and a store with the package which will hopefully help in the construction of medium to large size applications.

Models can be created by inheriting from the mvc.Model class:


 * @constructor
 * @inheritDoc
var Person = function(firstName, lastName) {
    goog.base(this, {attr: {
        'firstName': firstName,
        'lastName': lastName
    this.meta('name', ['firstName','lastName'], function(firstName, lastName) {
        return lastName + ", " + firstName;
goog.inherits(Person, mvc.Model);

Getters and setters are available using the model.get and model.set methods. Exceptions are used to handle validation errors – full details can be found in the project’s readme.

Data can be saved by using mvc.Syncmvc.AjaxSync and mvc.LocalSync have been included, but other implementations could be created if required. The sync/ajax.js file currently shows how PlastronJS would effectively communicate with a server.

The Google Closure Library itself is the base JavaScript used for most of Google’s flagship projects. For those who are missing Backbone-like MVC from Closure Library, then PlastronJS should work well.

Unix and Node: Interfaces

05 Apr 2012 | By Alex Young | Comments | Tags node tutorials unix cli

Earlier in this series I covered command-line arguments, which are well-supported in Node. There are times when a more interactive interface is required, however.

Fortunately, various node modules give us the tools to create command-line Unix programs with many different console-based interfaces, from Read-Eval-Print-Loops to GUI-like terminal control libraries.


Node’s Read-Eval-Print-Loop (REPL) is available as a module, and can be used to create interactive JavaScript shells. Node’s documentation has a cool example that uses a TCP server, so clients can connect with telnet.

The documentation is currently slightly inaccurate with regard to REPL.start – the callback method actually takes four arguments and won’t work as advertised. This example should work with the current version of Node 0.6:

var repl = require('repl')
  , vm = require('vm');

repl.start('> ', process, function(code, context, file, callback) {
  var result
    , err;

  try {
    result = vm.runInThisContext(code, file);
  } catch (err) {
    console.error('Error:', err);
  callback(err, result);

The process global is passed as the stream argument to make the REPL read and write to stdin and stdout. The callback method can do anything that’s required. For example, you could allow access to your database objects and methods in a web application, or provide an interactive administration interface to a daemon.


The repl module works well when a JavaScript shell is required, but what about a custom REPL? Node actually includes a Readline module, which is perfect for this:

var readline = require('readline')
  , rl;

rl = readline.createInterface(process.stdin, process.stdout, null);


rl.on('line', function(cmd) {
  if (cmd === 'quit') {
    rl.question('Are you sure? (y/n) ', function(answer) {
      if (answer === 'y') {
      } else {
  } else {
    console.log('You typed:', cmd);
    console.log('Type "quit" to exit');


rl.on('close', function() {


Here I’ve used the readline module to create an interface, then listen for line events which denote a line of text was typed. The question method will display a prompt and invoke the callback with the response.

By using simple string matching, a completely customised command-line interface can be created. The readline module also has some useful built-in features like command history.


The ncurses module by Brian White provides bindings to the ncurses library. This is a popular method for creating text-based user interfaces. If your application needs things like windows, menus, and more elaborate widgets such as a calendar, then ncurses is a good solution.

These bindings require a level of familiarisation with the original ncurses API. One freely available resource for learning ncurses is the NCURSES Programming HOWTO – combined with the ncurses-node README it’s possible to work out how to apply these techniques to a Node project.

Brian has also written some reusable widgets that come with the node-ncurses module:

var ncurses = require('ncurses')
  , widgets = require('ncurses/lib/widgets')
  , win = new ncurses.Window();

widgets.InputBox('Enter your name:', {
    pos: 'center',
    style: {
      colors: {
        bg: 'blue',
        input: {
          fg: 'red',
          bg: 'black'
  }, function(input) {
    if (!input) {
      input = 'nothing';
    win.centertext(0, 'You entered: ' + input);
    setTimeout(function() { win.close(); }, 1000);

I’ve adapted this example from Brian’s code – it should work if you install the relevant module with npm install ncurses. The result looks like this:

node-ncurses screenshot


There are simpler alternatives to ncurses. Libraries we’ve covered before, like Commander.js have prompts and dialogs. Then there’s ansi.js (License: MIT, npm: ansi) which makes working with 256 ANSI colours relatively painless, particularly for web developers who are familiar with hex colours:


TermUI (npm: node-term-ui) by Josh Faul has a chainable event-based API that can move the cursor around and output text with various colours:

  .out('Hello, world!');

There’s even a tab completion module: complete (License: MIT, npm: complete) by hij1nx. It’s actually designed to work with bash completion, and will write to .bashrc or .bash_profile:

# Node Completion - Auto-generated, do not touch.
shopt -s progcomp
for f in $(command ls ~/.node-completion); do
  test -f "$f" && . "$f"

There are dozens more interesting command-line UI libraries out there. If you’ve written something that you’d like us to feature in a Node Roundup post, then please get in touch!

Node Roundup: Nodetime, Flow.js, Lox

You can send in your Node projects for review through our contact form or @dailyjs.


Nodetime screenshot

Nodetime (GitHub: dmelikyan / nodetime, License: MIT, npm: nodetime) by Dmitri Melikyan is an instrumentation service for profiling Node applications.

Once the nodetime module has been added to a project, running require('nodetime').profile() will cause it to start sending HTTP and database statistics to the Nodetime service:

The Nodetime profiler running within the application securely sends profiling data to the Nodetime server, where it is stored and sent to the browser in real-time. Profiling data is kept on the server for 10 minutes.

It’s also possible to avoid sending the profiling data to the server, by using require('nodetime').profile({ stdout: true }).

Nodetime is built on the author’s Timekit module, which adds some useful bindings to gettimeofday and getrusage.


Flow.js (License: MIT, npm: flow.js) by Tony Findeisen is inspired by Seq and Async.js, but is written from scratch rather than forking these projects. It’s based around the idea of creating ‘flows’ which can be executed synchronously or asynchronously. Results can be collected from each operation, and callbacks are used to signal the completion of parallel methods:

    a: function() {
      return 123;
    b: function(cb) {
        cb(null, 'I completed after 100ms');
      }, 100);
    // and even more
  .exec(function(err, results) {
    // results.a: 123;
    // results.b: 'I completed after 100ms');

This library uses the .length property of functions to determine if an argument has been supplied – if so, the function is considered asynchronous. Libraries like this benefit from the fact that functions in JavaScript are objects:

Every function in JavaScript is actually a Function object.

Flow.js comes with tests written with Mocha.

Function documentation at MDN


Lox (GitHub: reaktivo / lox, License: MIT, npm: lox) by Marcel Miranda is a Mongoose-based authentication middleware library for Express, and includes tests written with Mocha.

The lox function itself takes a MongoDB connection URI string, and the result can be passed to app.use. It needs suitable routes for managing users, but provides middleware for logging in and out:

# Sign in '/login', lox.routes.login('/success_uri', '/fail_uri')

# Sign out
app.get '/logout', lox.routes.logout('/success_uri', '/fail_uri')

jQuery Roundup: jQuery-CreditCardValidator, pow.js, idom

03 Apr 2012 | By Alex Young | Comments | Tags jquery plugins css validation templating
Note: You can send your plugins and articles in for review through our contact form or @dailyjs.


jQuery-CreditCardValidator (GitHub: PawelDecowski / jQuery-CreditCardValidator, License: CC BY-SA 3.0) by Pawel Decowski is a nicely presented credit card validator:

$('#cc_number').validateCreditCard(function(result) {
  alert('CC type: ' + result.card_type
    + '\nLength validation: ' + result.length_valid
    + '\nLuhn validation: + result.luhn_valid');

All the popular cards are supported, including debit cards.



pow.js (GitHub: greim / pow.js, License: MIT) by Greg Reimer is an “algorithmic sunburst generator”. It’s a bit of fun with CSS, but I really liked the way the plugin is presented by combining the API options with form fields to create a self-documenting interface.


idom (GitHub: idibidiart / idi.bidi.dom, License: BSD) by Marc Fawzi is a data-driven templating library. It caches elements that have an idom-node-id attribute, and will insert values from JSON where the idom$ prefix has been used.

This project extends built-in prototypes to make the syntax that the author wants possible, and adds some jQuery plugin methods if it’s available. The author has some interesting ideas, so I’m hoping to see a version that works more like jQuery (avoiding using native elements).

cld.js, Presenteer.js, Algorithmic MochiKit Extensions

02 Apr 2012 | By Alex Young | Comments | Tags node language libraries jquery MochiKit


cld.js (License: BSD) by Janne Aukia is a language detection library, ported from the Compact Language Detector in Chromium using Emscripten. It should work in Node and browsers, and has a simple API for detecting languages:

var cld = require('./cld-min.js');

console.log('Language:', cld.detectLanguage('上'));
// Chinese
console.log('Language:', cld.detectLanguage('上か'));
// Japanese


Presenteer.js (GitHub: willemmulder / Presenteer.js, License: CC BY-SA 3.0) by Willem Mulder is a presentation library that’s based around a class that applies CSS3 transforms and transitions to a set of elements:

var presentation = new Presenteer('#presentation', $('#presentation > div'));

The presentation instance can then be interacted with using the mouse, or programatically with methods like presentation.start() and The nice thing about this API is multiple presentations can be displayed on a page.

Algorithmic MochiKit Extensions

Fredrik Blomqvist sent in his functional programming extensions for MochiKit. It includes an alternative bind method inspired by the one in the Boost C++ library that supports placeholder arguments. Other methods have also been extended to include placeholder arguments.

Fredrik has written several other MochiKit modules, inspired by Python:

Spaceship Pilot, CARPE Slider, CasperJS, lazyload

30 Mar 2012 | By Alex Young | Comments | Tags node iOS images games

Spaceship Pilot

Spaceship Pilot screenshot

Spaceship Pilot from Webdigi is a browser-based game that’s controlled by tilting an iOS device. A QR code can be used to easily launch the site that’s used to collect accelerometer data – the Google iOS app is a relatively painless way of doing this (using the image search).

The authors have written a blog post about the client and server-side code – the server uses Node and Socket.IO.

CARPE Slider

CARPE Slider by Tom Hermansson Snickars is a cross-browser slider widget with no dependencies. It doesn’t require any image files, and works well with both the mouse and keyboard.

When used with HTML5, data attributes can be used to configure sliders without extra JavaScript. Multiple sliders can safely coexist on a single page as well.

The project is distributed free for open source or non-commercial projects, otherwise it costs $99 for a license.


CasperJS (GitHub: n1k0 / casperjs, License: MIT) by Nicolas Perriault is a testing tool for PhantomJS.

Using PhantomJS seems like the ideal solution for creating advanced browser-like scripting environments, and CasperJS has an appealing API:

casper.start('', function() {
  // search for 'casperjs' from google form
  this.fill('form[action="/search"]', { q: 'casperjs' }, true);

casper.then(function() {
  // aggregate results for the 'casperjs' search
  links = this.evaluate(getLinks);
  // now search for 'phantomjs' by filling the form again
  this.fill('form[action="/search"]', { q: 'phantomjs' }, true);

The author has written a tutorial including installation instructions on the CasperJS homepage, and the project includes tests.


lazyload (License: MIT) by Vincent Voyer and Stéphane Rios is an image loader that uses a temporary base64 image:

  onload="lzld(this)" />

The authors opted to use the inline onload so each image effectively registers itself with the lazy loading system, rather than calling something like getElementsByTagName or querySelectorAll.

Unix and Node: Daemons

29 Mar 2012 | By Alex Young | Comments | Tags node tutorials unix daemons

As we’ve seen over the last few weeks, Node is a great platform for building portable Unix programs. This makes it a useful tool for developing daemons. I often find myself dealing with daemons, whether working as a web developer, sysadmin, or general Unix developer.


Why bother making a Node process behave like a daemon? There are several reasons, but generally because it’s a service that should be running at all times, in the background, and will automatically start after a reboot.

There are different ways to do this depending on the operating system. Most Linux distributions use System V compatible init scripts with runlevels. An alternative is upstart which is installed by default on Ubuntu systems.

BSD’s init behaves differently – there are no run levels. Solaris has the Service Management Facility which describes services using XML service manifests – I often find myself writing a simple XML file that wraps around a start/stop init script.

Finally, Mac OS has launchd which is a system wide and user-oriented daemon manager. It uses XML plist files, and the documentation for these can be found in man launchd.plist.

Linux Standard Base

Guidance for writing init scripts can be found in the Linux Standard Base’s section on Init Script Actions. This states that applications conforming to the standard should accept a single argument which should include one of the following:

  • start
  • stop
  • restart
  • force-reload
  • status

The status action works by returning specific exit status codes:

  • 0: The service is running correctly
  • 1: The program is dead and a /var/run pid file exists
  • 2: The program is dead and a /var/lock lock file exists
  • 3: The program is not running
  • 150 to 199 are reserved for your own requirements

Other actions are also expected to return specific status codes:

  • 1: Unspecified error
  • 2: Invalid arguments
  • 3: Unimplemented feature
  • 4: Insufficient privileges
  • 5: Program is not installed
  • 6: Program is not configured
  • 7: Program is not running
  • 150 to 199 are reserved for your own requirements

Most daemons are distributed without implementing all of these actions and status codes, but it’s a good idea to be aware of them.

Node Examples

StatsD (License: MIT, npm: statsd) from Etsy is a network daemon for aggregating statistics. It comes with the files for a Debian package, and includes an upstart script:

description "statsd"
author      "rdio"

start on startup
stop on shutdown

    # We found $HOME is needed. Without it, we ran into problems
    export HOME="/root"

    exec sudo -u nobody /usr/share/statsd/scripts/start
end script

Part of the installation process sets up log files with the correct permissions, and installs a configuration file to /etc/statsd. It’s usually a good idea to support a system-wide configuration file that can be overridden for the purpose of distributing daemons.

The log file is created in /var/log/statsd/, which is standard as well.

This daemon loads the configuration file based on the command-line argument:

config.configFile(process.argv[2], function(config, oldConfig) {
  // Process the configuration file

Some daemons may opt to check for configuration files in default locations, loading them in order of preference:

  • /etc/mydaemon/config.js
  • $HOME/.mydaemon/config.js

Init Module

Developing a Linux-friendly init script is made easy by the Init Node module by Paul Driver. He’s actually implemented the correct status codes, and the daemon module has been used, so you essentially get a real background daemon with very little code:

var init = require('init');

  pidfile: '/var/run/',
  logfile: '/var/log/myprog.log',
  command: process.argv[3],
  run: function() {
    setInterval(function() {
      // Will be redirected to /var/log/myprog.log
    }, 1000);

Notice that console output will be redirected to a log file, so in this case “Running” will be printed to /var/log/myprog.log.

Wrapper Scripts

The Init module turns a Node script into a daemon, but what if your daemon needs to accept various command-line parameters rather than just start/stop/restart? In this case, most people either write a shell script to provide a System V init wrapper, or they might use an upstart script as we saw with StatsD.

Of course, other Unix systems have different init implementations, but a simple init script or init script-compatible Node module can usually be coerced into working with systems like Solaris’ SMF.

You’ll need basic shell scripting skills to write an init script, but there’s an example of one in Fedora’s packaging documentation: SysVInitScript.

Packaging Guidelines

If you want to reach a wider audience, packing guidelines often have useful tips on how to distribute daemons as well:

Node Roundup: 0.6.14, Mocha 1.0, ncluster, ENVy

28 Mar 2012 | By Alex Young | Comments | Tags node modules deployment mocha testing
You can send in your Node projects for review through our contact form or @dailyjs.

Node 0.6.14

Node 0.6.14 was released soon after 0.6.13. This release includes bug fixes and updates npm to 1.1.12.

Mocha 1.0

Mocha 1.0 has been released. There’s now a GitHub-flavoured Markdown reporter, and JavaScript “compilers” are now supported with mocha --compilers coffee:coffee-script.

An API has also been added, so it’s possible to programatically create tests:

var mocha = new Mocha;



ncluster (npm: ncluster) by Ben Murphy is a zero-downtime clustering solution. It’ll reload the application when a SIGHUP is issued, and gracefully quit when SIGQUIT is sent.

Ben has designed it to be used with Capistrano. He’s also created a Node/Ubuntu Vagrant deployment solution with instructions for deploying his demo app to a virtual machine (nodejs_vagrant_helloworld).


ENVy (npm: envy) by Elio Capella Sánchez is a small module for managing JSON settings files. It’ll use require to load a file called config.json in the project’s root directory.

It also uses a convention for automatically determining the environment and loading the appropriate properties. Given a JSON file like this:

  "environment": "development",

  "development": {
    "test": "Development property"

  "production": {
    "test": "Production property"

Then require('envy').config will load the development settings, so config.test will return “Development property”.

jQuery Roundup: 1.7.2, Filtrify, JsBehaviour, Rest Test Test

27 Mar 2012 | By Alex Young | Comments | Tags jquery plugins tags rest libraries debugging
Note: You can send your plugins and articles in for review through our contact form or @dailyjs.

jQuery 1.7.2

jQuery 1.7.2 has been released. This release mainly includes fixes, but there are also tweaks that improves API consistency. There’s an important note for jQuery Mobile users on which jQuery version to use:

If you’re using jQuery Mobile, please use jQuery 1.7.2 only with jQuery Mobile 1.1. For previous versions of jQuery Mobile, stay with jQuery core 1.7.1 or earlier.


Filtrify screenshot

Filtrify (GitHub: luis-almeida / filtrify, License: MIT) by Luís Almeida is a Chosen-inspired tag filtering plugin. It allows multiple tags to be selected and searched, and multiple Filtrify instances can be used on a single page.

The markup is based on data attributes:

<div id="placeHolder"></div>

<ul id="container">
  <li data-genre="pop, rock, british, classic rock"> The Beatles </li>
  <li data-genre="rock, british, blues, classic rock"> The Rolling Stones </li>
  <li data-genre="alternative, electronic, female vocalists"> Björk </li>
  <li data-genre="rock, alternative, grunge"> Foo Fighters </li>
  <li data-genre="rock, classic rock"> Bruce Springsteen </li>

Now calling $.filtrify('container', 'placeHolder') will add the selector to the page.

The plugin accepts lots of options, including a property for supplying a callback that fires when tags are added or removed.


JsBehaviour (License: MIT) by DracoBlue is similar to Declarative that we featured last week – both are essentially tools for associating complex behaviour with markup as unobtrusively as possible.

Handlers must be registered with jsb:

jsb.registerHandler('example', function(el, options) {
  element.textContent = 'I am loaded with name: ' +;

Then parameters can be supplied to JsBehaviour like this:

<span><input class="jsb_ jsb_example" type="hidden" value="{&quot;name&quot;:&quot;Jan&quot;}" />Are you loaded?</span>

Running this example would produce I am loaded with name: Jan.

JsBehaviour expects “enhanced” elements to include a jsb_ class. The author has written more about this library with examples on the JsBehaviour blog.

Rest Test Test

Rest Test Test (GitHub: jeroenooms / resttesttest) by Jeroen Ooms is a jQuery and Bootstrap-based HTTP testing tool. It allows various HTTP methods to be issued, along with parameters. The results are displayed with the associated HTTP headers.

The author recommends using this with Firebug for testing REST services and Cross Origin Resource Sharing (CORS).

Gazel, Heroku Node Versions, nios

26 Mar 2012 | By Alex Young | Comments | Tags node browser hosting indexeddb database iOS


Gazel (GitHub: matthewp / gazel, License: MPL 2.0) by Matthew Phillips is a key-value store for browsers, based on Redis. The API is similar to Redis, and has a friendly chainable syntax:

var client = gazel.createClient();

client.on('error', function(err) {
  console.error('Error:', err);

  .set('key', 1)
  .incrby('key', 10)
  .exec(function(results) {
    var key = results.pop()[0];

It uses IndexedDB for storage, and will attempt to use vendor-specific versions where available. The author has written a sizeable suite of Mocha tests that can be run in a browser.

Heroku Node Version Support

Heroku now permit Node and npm versions to be requested using your application’s package.json file:

  "name": "myapp",
  "version": "0.0.1",
  "engines": {
    "node": "0.6.x",
    "npm":  "1.0.x"

The available versions are listed here:

Heroku defaults to their oldest version of Node 0.4, so it’s probably a good idea to specify the latest 0.6 version.

Read more here: Specifying a version of Node.js / npm


Node iOS

nios by Sebastian Waisbrot is a Node port for iOS. The objective is to allow Node projects to run on an iOS device with minimal modifications. It uses WebViewJavascriptBridge to run Node’s libraries.

The example that comes with the project runs a Node HTTP server within a native iOS app.