If you've used Node.js lately you've likely run across Vows, the asynchronous behavior driven development test framework for Node. Vows does a really nice job of forcing you to separate your setup logic from your assertions, but that's not what this post is about.

Vows can generate test coverage reports with its --cover-plain, --cover-html, and --cover-json options. Unfortunately, creating code coverage metrics isn't as straightforward as simply including these options in your call to vows. You need to

1. Pre-instrument your code using node-jscoverage.
2. Require the instrumented versions of your code from your tests.

The first prerequisite is fairly easy to satisfy, although you need to remember to re-run node-jscoverage any time you change the source files you're interested in covering. Setting up a script using something like watchr to re-instrument your files if anything changes might be a good option. Anyway, simply executing the following (assuming you've installed node-jscoverage and added it to your path) from the root of your node project will create the instrumented versions of the files in your lib directory:

node-jscoverage lib lib-cov

The second prerequisite is not as straightforward to resolve as you might expect unless you want to generate the code coverage on every test run. Why? Because requiring the instrumented code from your test is not the same as requiring the un-instrumented versions. Consider

// test/myfile_test.js
var fut = require('../lib/myfile.js'); // regular version
var fut = require('../lib-cov/myfile.js'); // instrumented version

Since the statement requiring the file under test is in every test you write, having to change it when you want to run the instrumented or un-instrumented files is, in my opinion, not an option. So, on my current project we wrote the following javascript to to serve as a replacement to requiring your files under test.

// test/coverage.js
var covererageOn = process.argv.some(function(arg) {
  return /^--cover/.test(arg);  
});

if (covererageOn) {
  console.log('Code coverage on');

  exports.require = function(path) {
    var instrumentedPath = path.replace('/lib', '/lib-cov');

    try {
      require.resolve(instrumentedPath);
      return require(instrumentedPath);
    } catch (e) {
      console.log('Coverage on, but no instrumented file found at ' 
        + instrumentedPath);
      return require(path);
    }
  }
} else {
  console.log('Code coverage off');
  exports.require = require;
}

In essence, the script checks the process arguments to see if one of the vows --cover-* arguments were passed and changes its require method to substitute /lib-cov for any /lib references. If none of the coverage arguments are detected it simply requires the file as usual. Since your files under test normally use relative references to other files in your lib directory, they get covered too. Check out the example below to see how you would use the script in a test.

// test/mytest.js
var vows = require('vows');
var assert = require('assert');
var coverage = require('coverage');
var fileUnderTest = coverage.require('../lib/myfile.js');

vows.describe('your test').addBatch({
    // do some testing
}).export(module);

On my current project we've been using Node.js for an app that does a lot of packet capture and processing. In the past we used node-pcap for packet capture but were looking for an easier way to simply parse raw pcap files. It turns out the pcap file format is pretty simple as was writing a node module to parse it.

The module, called pcap-parser, can be used to parse any pcap file or readable pcap stream, such as the piped output of tcpdump. As packets are parsed, pcap-parser emits relevant events to which your node program can listen. It's a really simple way to process a theoretically infinite stream of pcap data. The code below shows a basic example of it in action. Please check out the project page for more details.

var pcapp = require('pcap-parser');

var parser = new pcapp.Parser('/path/to/file.pcap');
// var parser = new pcapp.Parser(process.stdin);

parser.on('packet', function(packet) {
  console.log(packet.header);
  console.log(packet.data);
});

parser.parse(); // to kick things off

System Metrics is a new Rails 3 Engine providing a clean web interface to the performance metrics instrumented with ActiveSupport::Notifications. It will collect and display the notifications baked into Rails and any additional custom ones you add using ActiveSupport::Notification#instrument.

System Metrics is not intended to be a replacement for performance monitoring solutions such as New Relic. However, it is especially handy for quickly identifying performance problems in a development environment. It's also a great alternative for private networks disconnected from the Internet.

You can find more information about System Metrics on the System Metrics site. Please kick the tires and let us know what you think.

People often have a hard time determining if they're done with a software development task. It's a great idea to sit down with your team and together decide what you're going to consider as criteria for declaring a task done. If you haven't done that yet, here's one question you can ask yourself to help decide if you're done.

Is there any reason I'll need to think about this code again in the near future?

If you didn't quite implement all the unit tests you think you should have, the answer is yes and you're not done. If you cut a corner or two to squeeze it in before the end of the iteration, the answer is yes and you're not done. If you're uncomfortable with the implementation and would like to refactor it, the answer is yes and you're not done. If there are a few details on the UI you left out in the interest of time, the answer is yes and you're not done.

Too many times I've seen people close out a task only to revisit it the next week to polish up some loose ends, write a few more tests, refactor a confusing piece, etc. Don't do it.

Software development is hard enough without having to keep mental notes of all the needed tweaks and adjustments to things you've already done. Your goal should be to knock out a task so totally and completely that you can get it out of your brain and focus on the next one. Doing so will do wonders for your sense of accomplishment.

Ruby's default arguments are a really handy language feature that I recently discovered aren't as handy as I once thought. I was trying to track down an error I was getting in the following snippet of code in my ActiveRecord model object:

  1 def as_json(options={})
  2   options[:methods] ||= []
  3   options[:methods] << :full_name
  4   super(options)
  5 end

When this method was executed in order to convert the object into a JSON representation, I received this error (with line numbers adjusted for this example):

  NoMethodError: undefined method '[]' for nil:NilClass
    from MyModel:2:in 'as_json'

I stared at this for a while until it dawned on me that explicitly passing 'nil' to as_json might not result in options being set to the default empty hash, and indeed it does not. I suppose it's technically correct, since nil is an instance of NilClass in Ruby and not some special value as it is in many other languages. It's just not what I was expecting and not what I want. For all the books, blog posts, and tutorials I've read, you'd think I would have picked up on this somewhere along the way.

Curiously though, can anyone think of a valid use case for not assigning the default value to a nil argument? I'm sure there are some, but they're not coming to mind.