Unix and Node: IPC

26 Apr 2012 | By Alex Young | Comments | Tags node tutorials unix ipc

This tutorial explores the world of inter-process communication (IPC) in Unix, and solutions for Node developers. IPC actually covers a broad swathe of methods, including POSIX signals and pipes, which we’ve already covered in this series. Here I’m only going to cover IPC methods that are based on sockets or Unix domain sockets.

IPC

IPC enables structured data to be shared between processes. In terms of architecture, scaling software by creating smaller programs that communicate with each other using simple data formats fits in with the Unix philosophies mentioned previously in this series. Additionally, it may be desirable to use established Unix-based IPC systems from within Node.

Beyond modularity and performance, IPC can also be used to restrict privileged access to certain resources. For example, a Node web application could run on a registered port (above 1023) which is generally accessible by ordinary user accounts. Then another program with additional privileges to access port 80 could proxy requests to it, thereby limiting access and potentially improving security.

It’s likely that contemporary developers that don’t come from a Unix background will already use IPC and RPC. Message queues in particular are very popular now – ZeroMQ can be configured to communicate locally using its IPC transport that’s based on Unix domain sockets

D-Bus

D-Bus supports many POSIX operating systems. It’s most closely associated with KDE, but can be installed on Mac OS, and there’s even a Windows port. It can use Unix or IP sockets.

D-Bus generally runs as a system-level daemon, and also as a session daemon:

A GNOME environment normally runs two kinds of buses: a single system bus for miscellaneous system-wide communication, e.g. notifications when a new piece of hardware is hooked up; and a session bus used by a single user’s ongoing GNOME session.

The two most popular Node implementations are node-dbus (License: MIT, npm: dbus) by Shouqun Liu, and node-dbus (License: BSD, npm: node-dbus) from Motorola Mobility. They’re both built using C++ extensions that wrap around the libdbus APIs.

It’s unlikely that D-Bus is (or will be) a popular solution for IPC with Node developers, but it does allow us to integrate more tightly with desktop environments. For example, if I use a GNOME music player that exposes services through D-Bus, I could write Node scripts that monitor what I’m listening to and post the data to Last.fm. Linux Journal has a general article on this topic that serves as a basic introduction: Control Your Linux Desktop with D-Bus.

Homegrown IPC and RPC

There are dozens of modules that provide IPC and RPC solutions that are aimed at Node developers without integrating with existing high-level Unix daemons.

DNode by James Halliday is one such example that works with Unix domain sockets, TCP streams, or WebSocket. It’s an RPC implementation that uses a newline-terminated JSON protocol which is documented in the dnode-protocol module.

There’s also thintalk (License: MIT, npm: thintalk) by Andreas Madsen that implements a lightweight RPC layer. It’s aimed at pure Node environments, unlike DNode which can be called from different programming languages and browsers.

Easy IPC (License: MIT, npm: easy-ipc) by Oliver Leics is an event-based IPC implementation. It supports newline-terminated JSON streams, but can work with plain text as well.

Message Queuing

The ØMQ messaging library is lightweight, high-performance, and asynchronous. The zmq (License: MIT, npm: zmq) module by Justin Tulloss is a popular solution, with an idiomatic Node API.

ØMQ runs on Linux, Windows, and Mac OS, and specifically targets fast performance. In contemporary discussions on IPC, it’s often cited as a suitable alternative to legacy message brokers.

Conclusion

IPC is an incredibly broad term that covers using files for communication, signals, sockets, message queues, pipes, shared memory, and pretty much everything else. I’m still searching for a quantum-entanglement IPC solution for Unix.

It’s therefore difficult to keep this discussion focused on Unix, particularly as modern systems like ØMQ will run just about anywhere. However, I hope that by mentioning D-Bus, Node hackers who run desktop systems like KDE or GNOME might be inspired to rewire their desktops in all kinds of creative ways.

Node Roundup: node-webcl, node-webgl, node-glfw

25 Apr 2012 | By Mikael Bourges-Sevenier | Comments | Tags node modules webgl webcl
You can send in your Node projects for review through our contact form or @dailyjs.

Mikael Bourges-Sevenier has sent in three WebGL and WebCL modules that he’s written for Node. We’ll resume our regularly scheduled Node Roundup posts next week!

node-webcl

node-webcl (GitHub: Motorola-Mobility / node-webcl, License: BSD, npm: node-webcl) from Motorola Mobility is an implementation of the Khronos WebCL working draft using Node. It has been tested on Mac OS X 10.7 and Linux. It should also work on Windows 7. Its only dependency is node-webgl, another Node module that implements the WebGL standard.

The module contains various tests and sample applications to help developers leverage multiple CPU and GPU cores. It is also used as a tool to develop experimental features that may or may not be in the WebCL standard.

Installing node-webcl with npm will fetch node-webgl and node-glfw. Since they rely on native libraries, make sure they’re available:

There are more details in the project’s readme. Intel’s OpenCL SDK can also be installed as a pure WebCL implementation, and be sure to check you’ve got the latest drivers installed for your graphics card.

node-webgl

node-webgl (GitHub: mikeseven / node-webgl, License: BSD, npm: node-webgl) is an implementation of the Khronos WebGL specification. This is a fork of Tim Caswell’s WebGL project that started life as Blue GPU Lava at Node Knockout.

This module allows WebGL applications originally created for browsers to run using Node on the desktop without modification. It provides support for DOM methods commonly used to create WebGL content.

Like node-webcl, this module has been tested with Mac OS X and Linux. It relies on GLEW, GLFW, and AntTweakBar. Lots of samples have been included – some show how to use AntTweakBar to create a compelling GUI.

node-glfw

Finally, node-glfw (GitHub: mikeseven / node-glfw, License: BSD, npm: node-glfw) is a JavaScript wrapper around GLFW. This provides implementations, where possible, of WebGL methods on top of desktop OpenGL as well as a browser compliant event model.

Although this module will run on Node 0.6, at least 0.7.5 is recommended for the typed array support. This module is intended as a platform-level binding – node-webgl should be used to create OpenGL applications.

jQuery Roundup: SelectBoxIt, jQuery Hooks, jQuery contextMenu

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

SelectBoxIt

SelectBoxIt screenshot

SelectBoxIt (GitHub: gfranko / jQuery.selectBoxIt.js, License: MIT) by Greg Franko is a select box replacement that uses progressive enhancement and has some notable features:

  • Works with jQueryUI ThemeRoller
  • Supports jQuery and jQueryUI’s animations
  • ARIA support

It also includes Jasmine tests: SelectBoxIt tests.

The author has written a detailed post documenting SelectBoxIt, and the GitHub repository contains suitable CSS and images if you want to duplicate the style used in Greg’s examples.

jQuery Hooks

In jQuery Hooks, Rodney Rehm discusses jQuery’s hooks feature. The jQuery.cssHooks documentation covers adding hooks to CSS getters and setters, but there are other hooks in jQuery’s code, for .val(), .attr(), and .prop().

jQuery contextMenu

jQuery contextMenu (GitHub: medialize / jQuery-contextMenu, License: MIT and GPL3) from Medialize GbR (and also by Rodney Rehm) helps create menus that appear when an element is right-clicked.

The authors have written lots of examples showing the flexibility of the plugin, including using input elements, dynamically adding new triggers, and access keys.

Krasota.js, Drink, Limit.js

23 Apr 2012 | By Alex Young | Comments | Tags libraries cli node

Krasota.js

Krasota.js (GitHub: veged / krasota.js, npm: krasota) by Sergey Berezhnoy is a modular source beautifier that uses grammars written with a fork of OMeta. It can force semicolons, join or split var statements, or even remove trailing whitespace.

It can be used as a Node module, or as a command-line utility:

$ krasota -i tests/join-vars.js -b krasota/lib/beautifiers/trailing-whitespaces -b krasota/lib/beautifiers/join-vars

Custom beautifiers can also be called from the command-line by using the -b switch with a file name.

Drink

Drink (GitHub: Nijikokun / drink, License: AOL/MIT, npm: drink) by Nijiko Yonskai is a wrapper around process that helps write periodic console utilities. The API is themed around “coffee” – not CoffeeScript, but the brewed bean beverage, which is confusing because the author’s examples are written in CoffeeScript.

A session is started and potentially kept alive by passing drink a process object. Calling sip will pass data to stir without line breaks. Listeners for single character input can be added by calling onTap. The author suggests this could be used to keep any kind of session from dying, so it could be used with something like an IRC client.

Limit.js

Limit.js (GitHub: m-gagne / limit.js, License: MIT) by Marc Gagne is a reusable event debouncer. I’ve written similar code myself to sensibly handle certain client-side UI elements, and events like window resizing.

Marc’s implementation works by extending Function.prototype. There’s an example on jsFiddle that illustrates the usage: Limit.js demo.

$(document).bind('mousemove', function(e) {
    $("#debounce").children().last().text(debounceCalls++);
}.debounce(150)); // debounce with a 150 millisecond limit

$(document).bind('mousemove', function(e) {
    $("#throttle").children().last().text(throttleCalls++);
}.throttle(150)); // throttle with a 150 millisecond limit

Reznik, JSQA, Riloadr

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

Reznik

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

JSQA from PaquitoSoft uses JSHint to statically analyse your code using an Express/Bootstrap-powered web application. It uses Socket.IO and fs.watch 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

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

Introduction

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
foo()

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;
foo()

// 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
[1].push(a)

// 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 {
  doSomething();
}

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 {
  doSomething();
}
  • 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
  ;i++
  )
...
// 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 --
c
console.log('3)', a, b, c)

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

// 5) new lines v3
a = b = c = 1
a
++
b
--
c
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:

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

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

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:

throw
  new Error('Aieee!')
// interpreted as:
throw;
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(
  'Aieee!'
)

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) {
 return
   callback('Error while processing something that takes a lot of words to describe: ' + err)
}
somethingElseHere()

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) {
 return;
 callback('Error while processing something that takes a lot of words to describe: ' + err);
}
somethingElseHere();

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) {
  return
    (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) {
  return;
  (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
;[1].push(a)

// 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

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.

node-pad

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) {
  player.updateCameraDirection({
    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

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

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', 'legacy.zip', 'secrets.txt', 'etc.rar']

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

# 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

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 = ["yahoo.com", "google.com", "hotmail.com", "gmail.com", "me.com", "aol.com", "mac.com",
                      "live.com", "comcast.net", "googlemail.com", "msn.com", "hotmail.co.uk", "yahoo.co.uk",
                      "facebook.com", "verizon.net", "sbcglobal.net", "att.net", "gmx.com", "mail.com"];
var defaultTopLevelDomains = ["co.uk", "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

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 myapp.meteor.com

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 site:www.meteor.com). 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

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')
  .css({
    '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

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

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)');
posix.closelog();

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');

logger.info('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.

Conclusion

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

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

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 this.property + ' 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

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');
  console.log(data);

  try {
    data = fs.readFile_('invalid', 'utf8');
  } catch (err) {
    console.log(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

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

  Usage: jaded [options]

  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

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

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

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.

Checklist

  • 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

References

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

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);
match.day; // -> '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 xregexp.com and the XRegExp readme.

PlastronJS

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:

goog.require('mvc.Model');

/**
 * @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.

REPL

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.

Readline

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.setPrompt('➜');

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

  rl.prompt();
});

rl.on('close', function() {
  console.log('Bye');
  process.exit();
});

rl.prompt();

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.

ncurses

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);
    win.refresh();
    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

Alternatives

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:

cursor.hex('#660000').bold().underline();

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:

TermUI
  .pos(10,20)
  .fg(TermUI.C.w)
  .bg(TermUI.C.w)
  .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
  f="$HOME/.node-completion/$f"
  test -f "$f" && . "$f"
done

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

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

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:

flow()
 .par({
    a: function() {
      return 123;
    },
    b: function(cb) {
      setTimeout(function(){
        cb(null, 'I completed after 100ms');
      }, 100);
    }
    // and even more
  })
  .exec(function(err, results) {
    console.log(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

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
app.post '/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

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

pow.js

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

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

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

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 presentation.next(). 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

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('http://google.fr/', 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

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

<img
  data-src="real/image/src.jpg"
  src="data:image/gif;base64,R0lGODlhAQABAAAAACH5BAEKAAEALAAAAAABAAEAAAICTAEAOw=="
  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.