You are currently browsing the See John Code posts tagged: nodejs


Mocha v1.0

My favorite JavaScript testing framework, Mocha – just hit v1.0 a few days ago.

No breaking changes (exactly how I think a 1.0 should be), compiler support, some new reporters.  If you’re using Mocha for JavaScript testing – time to upgrade.

Great Job TJ!

Natural Language Processing in JavaScript

If you’re doing anything with natural language processing in Node.js, natural is a great library that has some common algorithms all in one place.  They have everything from distance algorithms to phonetic-similarity algorithms like Soundex & Metaphone.

I just added a Dice’s Coefficient implementation today, and its really easy to use:


var natural = require(‘natural’);
console.log(natural.DiceCoefficient(‘thing’, ‘thing’)); // 1.0
console.log(natural.DiceCoefficient(‘not’, ‘the same’)); // 0.0
console.log(natural.DiceCoefficient(‘night’, ‘nacht’)); // 0.25

Using winston for logging in Node.js

I’ve been through a lot of different logging libraries in Node.js for different projects, but Winston is the one I always come back to.  Winston is asynchronous, offers support for multiple transports, and is damned easy to get set up.

First, add it to your dependencies:


"dependencies": {
"winston": "~ 0.5.10"
}

The basic usage would be just as you’d imagine:


var winston = require(‘winston’);

winston.info(‘this is some info’);
winston.debug(‘a debug message’);

You can also attach meta info to any log call, so that your calls can not have to block on building up custom strings:


winston.log(‘listening on ‘ + host + ‘:’ + port); // old
winston.log(‘listening’, { host: host, port: port }); // new

Its easy to configure and create custom logger objects too.  I love how simple the whole thing is.  I have a few commits on winston, and it’s inspired the work I’ve done so far on iolog (a similar logging library for Io).

SocketIO is Boss

It is time for the next installment of “___ is boss”. This time, I want to mention how “boss” SocketIO is.

There are a few different ways that we typically go about handling real-time (or near real-time) communication between a web browser and server. Depending on how modern the browser is, or what the application demands, some choices are:

  • WebSockets - A bidirectional protocol for communicating over a single TCP socket.
  • (Long) Polling – the traditional way to accomplish this type of communication, in which the client continually checks the server for updates.
  • Flash XMLSocket - Can communicate with JavaScript to provide WebSocket-like functionality through Flash.

Even where they’re supported — problems like unexpected disconnects can make working with them really tricky. Also, having to implement all of them just shouldn’t be something you have to worry about. SocketIO aims to abstract all of that (and more – like the ability to do broadcasts easily) away into a beautiful library.

It works extremely well, and makes this type of communication really fun and easy. A client that absorbs data coming from the server is as quick as:


var socket = io.connect(‘http://localhost’);
socket.on(‘update’, function (data) {
console.log(data);
});

JS Coverage

A coverage tool is something that I’ve always wanted for my Node.js development. I certainly don’t depend on one, but I like when a coverage tool can point out things I’ve obviously missed tests for.

Tools like this are tough in Javascript, because our tracing ability is limited. Yesterday, though — two new test runners were added for mocha, my favorite JS testing framework. They are js-cov and html-cov. They work really well, and you should definitely give them a look.

Wanting to know how they worked, I dug a bit deeper, and quickly found that they depend on output for jscoverage to work. What jscoverage does, is create an instrumented copy of your code, by breaking it up and inserting lines to track counters of what was touched during execution, and how many times. Imagine we had this simple code (file:example.js):


for (var i = 0; i < 10; i++) {
console.log(‘hello world’);
}

Running jscoverage lib lib-coverage will produce something like:


// …
_$jscoverage['example.js'][1]++;
for (var i = 0; (i < 10); (i++)) {
_$jscoverage['example.js'][2]++;
console.log("hello world");
}

So this is code that still works, but when run, will record which lines were touched. Then the mocha runner just runs the tests, parses the output and puts it in a pretty format. Really cool, useful stuff!

Pro tipjscoverage also highlights code by default and I found that it was messing up mocha’s output. You can turn it off with jscoverage --no-highlight.