Code Kills

While developing remora (which will be released "soon") I had to load Google Closure libraries from Node.js. As it turns out, I'm the first one who has had to do this, so a blog post seemed in order.

I've loaded my Closure library in Node by creating a Node module which loads Closure's base.js, tells Closure how to load JavaScript files, loads my Closure library, then exports everything (the goog name space and my namespace) through module.exports.

First, an execfile function is needed, which will load and evaluate a JavaScript file using a particular namespace:

var vm = require("vm");
var fs = require("fs");

function execfile(path) {
  var data = fs.readFileSync(path);
  vm.runInThisContext(data, path);
}

Note: for various reasons (one of which being that you can't control the value of 'this' from the 'vm' module) vm.runInThisContext must be used to load the scripts into the global context. Trying to load the into a sandbox seems to fail for reasons I can't fully explain yet.

Next, the Closure base.js and deps.js files are loaded and CLOSURE_IMPORT_SCRIPT is set to a thin wrapper around execfile:

var base_basedir = "../src/browser/";
execfile(base_basedir + "base.js");
execfile(base_basedir + "deps.js");
goog.global.CLOSURE_IMPORT_SCRIPT = function(path) {
  execfile(base_basedir + path);
  return true;
};

Now Closure libraries which use goog.require(...) and goog.provide(...) can be loaded:

execfile("../src/remora.js");

(note: only the base library needs to be loaded; its dependencies will be taken care of by goog.require(...)).

Normal JavaScript packages can also be loaded:

execfile("../libs/underscore-1.2.3.js");

Finally, module.exports is set:

module.exports = {
    goog: GLOBAL.goog,
    remora: GLOBAL.remora,
};

Note: because Closure scripts expect that require/provide will inject items into the global namespace, the global names created (ex, goog and remora) cannot be deleted from the global namespace.

And that's all there is to it. This file can now be loaded like any other Node module (ex, var my_closure_library = require("./closure_compat.js")).

For a complete example, see remora/src/node/remora.dev.js.

I'm thinking about buying a 200+ GB SSD for my laptop, and this post summarizes my research. Note that it is current as of November 22, 2011 and will likely be irrelevant by 2012.

tl;dr The Corsair Force GT seems to be the fastest choice with Crucial m4 coming in a fairly close second. Data on failure rates for these drives/controllers has been hard to find, though, and all signs point to Intel drives being the most reliable (but also most expensive and slowest).

TechReport's SSD performance review which @samstokes sent me, which seems to find the two aforementioned drives to have the best performance, with the Corsair Force Series 3 making a decent showing as well. It also suggests that the Intel 500 series is a bit slower and significantly more expensive than the competition.

Tom's Hardware investigation on SSD reliability suggests that Intel's SSDs are much more reliable (specifically their X25-M series; a sentiment I've read in other places too), but it doesn't compare their failure rates to other manufacturers because "those are the drives that big businesses currently trust the most".

Friends on Twitter and Facebook generally recommended the m4.

It's also worth noting that I've read quite a few posts similar to The Hot/Crazy Solid State Drive Scale which suggest that failures can be fairly common. These posts have mostly been more than six months old, though, so I'm hoping that most of these problems have been sorted out in newer drives (it seems that there are often issues which can be fixed by a software update).

The net result is that I'm probably going to get a Force GT or m4, which ever I can find for a reasonable price from a local retailer with a good return policy.

Disclaimer: what you see is what you get. I've done enough research to convince myself that an SSD isn't a terrible idea, but that's definitely far from enough research to objectively show that an SSD isn't a terrible idea. Also, I've included links to Amazon for two reasons: 1) because prices change so often that quoting them here wouldn't be that useful, and 2) I've just setup a fancy affiliate account, so I stand a small chance of making a small amount of money from them.

Because I've done it a few times now and picked up a few tricks, I thought I would write a checklist for anyone who needs (or wants) to run the wifi and power at a medium sized (10 - 100 people) tech event.

I hope that this checklist will be a useful for events like Software Carpentry or Ladies Learning Code, as it will give someone with some networking knowledge [0] the nuts-and-bolts they need to setup and run a great (or at least functional) network.

I've published this document as a Gist on GitHub to make updates easy.

The document: Wifi and power for medium sized tech events: https://gist.github.com/1346886

Now that winter is coming, I'd like to share a tip that has been the difference between a terrible and a great day: hand warmers. Lots of hand warmers.

Here's what you do:

1. Buy hand warmers. Lots of them. Like fifteen pairs of them. They are $1.20 for a pair, so no banks will be broken by having a few extras.
2. Put a pair (or two?) in the pocket of each of your winter jackets.
3. Use them! Next time you (or your friend/spouse/child) is uncomfortably cold, just rip a hand warmer open. Ten minutes later you'll have a warm little bundle of joy to stick in your boot/glove/jacket/hat.

There are a bunch of reasons I've found step three to be hard: I don't want to admit to myself that I'm actually cold, I don't want to use them now because I may need them even more in the future, or because I don't feel like the warmth is worth the $1.20 it will cost... But since I have never regretted using one, I feel like it's worth tricking myself into using them more liberally by keeping lots of spares around, using it "for a friend", and telling myself that each one only costs 60¢ (that's like two quarters!).

A curious thing I've noticed recently is that a large number of startups don't include any information about the identity of the founders/employees.

I find this strange because, in my opinion, a big advantage of working with (or using the product of) a startup is that I can get to know the person (or people) behind the scenes. They might even be someone I know, or someone a friend knows.

I would go on, but I would just be repeating what Jason Cohen says in You're a little company, now act like one.

So, if you're part of a startup: please, include your identity and the identity of the other founders/employees somewhere on your website.