Running jasmine tests using jasmine-node and autotest

I’ve just started using Jasmine-node on a project I’m starting to help people build recursive-descent parsers. Jasmine-node is a neat little tool, because it allows you to write a command line like this;

jasmine-node spec/ --autotest

And it’ll start a process which monitors your tests. As you save your tests (the .spec.js files), the tests are all re-run, and this makes for a really tight development cycle. As you save, without anything other than ctrl+s, your tests run. Beautiful, really — the fact the test is running without any interference means that you don’t even think about a code-run-test cycle — it’s just code-code-code. Neat.

Special thanks to Clare for helping me get the first few Jasmine tests written. That initial understanding is the thing that cracks open a lot of possibility.

Advertisements

Is mercurial dying?

Is it me, or has Mercurial well and truly lost the race against git? 

A couple of things make me think that mercurial is no longer a particularly viable option. Firstly, I’m only really hearing about development on git, and particularly on GitHub. I regularly hear things like “I just pushed TCP support for <package X> to GitHub” but I don’t know that I’ve ever heard a similar “<package X> just got it’s tests fixed on BitBucket.” Maybe this is because I’m looking at a lot of JavaScript projects and not looking at Python projects, but it definitely seems that all the cool kids are on Github. 

Second, I just did a very quick scan for git and mercurial integration for Visual Studio. Microsoft are releasing a git extension in their next service pack (Visual Studio 2012 Update 2). Mercurial integration packages like VisualHG aren’t even compatible with Visual Studio 2012.

The disappointing thing here is that GitHub’s policy on private repos is so much tighter than BitBucket. In BitBucket, I get unlimited free private mercurial and git repos. In GitHub I have to pay to get any. I understand why GitHub needs to charge. Of course I do. It’s just that I’ve been avoiding Github because I have a lot of stuff that’s not fit for public consumption but which I want under source control.

Ah, well. First-world problem.

Using Twitter Bootstrap Typeahead to select a key/value pair, not a string

Twitter Bootstrap comes with a UI widget called Typeahead — an auto-complete textbox. Problem is, it works only with strings — you type a string, it searches a list of strings, when you choose one, it tells you you selected a string.

This is fine in some cases, but it’s not much cop if you want to select, say, a primary key field.

I’ve found an approach for this that lets you select in a more traditional manner — search names, return a different, unique value. It uses the ‘highlighter’ function and a little bit of JSON. Highlighter is a bit of a misnomer — it’s actually an arbitrary function for re-writing the text that appears in the dropdown.

So when you invoke, say, $(‘#mysearchbox’).typeahead(), you pass a set of options. Here’s what you need to do for each option;

source: Set the source option to a function returning an array of JSON-serialized name/value pairs;

return [
JSON.stringify({ name:”one”, value: 1 }},

    JSON.stringify({ name:”two”, value: 2 }},

    JSON.stringify({ name:”three”, value: 3 }},

    JSON.stringify({ name:”four”, value: 4 }},

    JSON.stringify({ name:”five”, value: 5 }}

];

highlighter: Set the highlighter to return just the name, not the value;

highlighter: function(item) {
return JSON.parse(item).name;
}

matcher: Set the matcher to return things that match the right name;

matcher: function (item) {
return

      JSON.parse(item).name.toLocaleLowerCase()

      .indexOf(this.query.toLocaleLowerCase()) != -1;
}

updater: Use the updater to catch the selected item;

updater: function (item) {
alert(JSON.parse(item).value);
return JSON.parse(item).name;
}

This pattern lets you search for text but return a corresponding key.