Gary Robinson's Rants

There are 10 kinds of people in the world...

An observation found on a t-shirt my son owns, and which I also noticed today on Hacker News:

There are 10 people in this world, those who understand binary and those who don't.

 The first reply on Hacker News:

There are 10 kinds of people in this world: Those who understand ternary, those who don't, and those who mistake it for the binary system.

Unit Testing with Durandal

Durandal provides the Durandal Test Framework for unit testing. This test framework uses PhantomJS and Jasmine.

As shipped with Durandal, it's focused on testing Durandal's own internal components. But it can easily be adapted for your own unit testing needs.

You can obtain the test framework by downloading the entire Durandal project with

git clone https://github.com/BlueSpire/Durandal.git

(assuming, of course, you have git installed).

Note that if you're not on Windows, you'll also need to install PhantomJS on your system, since the PhantomJS that comes with the Test Framework is a .exe.

In your own work, you're probably not going to want to use the entire Durandal project -- you may start with a starter kit such as the HTML Starter Kit, or even with your own custom setup. The first challenge is that the Starter Kits don't include the Test Framework. Beyond that, since the Test Framework is configured out-of-the-box for Durandal's internal testing needs, its hardcoded paths don't work for the directory hierarchies you'll have as a developer.

But configuring the Test Framework for your own needs is very easy. Edit spec.html in the test directory. In that file, you'll see that require is configured with some paths:

    paths: {
        'specs': '../test/specs/',
        'text': '../lib/require/text',
        'durandal': 'durandal/js',
        'plugins' : 'plugins/js',
        'transitions' : 'transitions/js',
        'knockout': '../lib/knockout/knockout-2.3.0',
        'jquery': '../lib/jquery/jquery-1.9.1'
    }

For the HTML Starter Kit, with the test directory copied into the top-level directory at the same level as lib, css, and app, you only have to change three of them:

        'durandal': '../lib/durandal/js',
        'plugins' : '../lib/durandal/js/plugins',
        'transitions' : '/lib/durandal/js/transitions',

In general, you just need to find the durandal, plugins, and transitions directories and set the paths appropriately.

It's also helpful to add a path to the app directory where your code will live:

        'app': '../app',

You can test your paths by removing the existing test modules from test/specs (which will no longer work, since they are for Durandal's internal testing) and replacing them with a new, dummy test module such as:

define(['viewmodels/flickr'], function (flickr) {
    describe('', function(){
        it('returns true', function () {
            expect(true).toBe(true);
        });
    });
});

This sets up testing for the flickr module that ships with the HTML Starter Kit. If you're using some other setup, you'll need a different test. But this shows how it's done. It doesn't test every path, but since the flickr module uses the durandal and plugin paths, it tells you whether you're on the right track.

To run the test:

$ phantomjs spec.js

You'll know that you don't have the paths set correctly if you get a error like the fullowing, which leads to a hang of PhantomJS:

Running spec files: specs/mytest.spec
Error: Script error
http://requirejs.org/docs/errors.html#scripterror

  file:///Users/garyrob/Source/Durandal%20Projects/HTML%20StarterKit%20(Durandal%202.0)%20Exp%202/lib/require/require.js:32
  file:///Users/garyrob/Source/Durandal%20Projects/HTML%20StarterKit%20(Durandal%202.0)%20Exp%202/lib/require/require.js:12 in C
  file:///Users/garyrob/Source/Durandal%20Projects/HTML%20StarterKit%20(Durandal%202.0)%20Exp%202/lib/require/require.js:29

If all is well, you should see something like:

    Running spec files: specs/mytest.spec
    Starting...

    Finished
    -----------------
    1 spec, 0 failures in 0.002s.

And you'll be ready to unit test your new Durandal project!

Javascript and SPA's, as seen by a long-time Python developer

I love Python and have posted a number of Python tips on this blog. And I've been involved in the creation of sizable web sites using Django.

But I've come to feel that for many types of web sites, doing all the rendering on the server and shipping the rendered page to the browser is probably not be the best way to go. Certainly, I'm not the first to come to that conclusion. Google Docs is a phenomenal example of what can be done in a "single page app" (SPA) rendered in the browser. There are many others.

In the course of investigating the various technologies for creating SPA's, one thing I've come to appreciate about that strategy is that you may not need much of a server at all. If you use something like Firebase for your database, you may need nothing more than a means of serving static html and JavaScript files on your server. And then you can use a CDN like CloudFlare to keep you online even if that server is temporarily down. All these factors together can eliminate an enormous amount of overhead in server administration.

Eliminating such overhead seems like it could be very helpful for my goal of creating my next project entirely by myself.

Unfortunately, JavaScript is (IMO) not nearly as nice a language as Python. But if used according to certain patterns, such as described in the famous JavaScript: The Good Parts, a lot of its deficiencies are mitigated, and then it's really not so bad. And most modern JavaScript libraries use the language in that way, so the ecosystem as a whole supports you in that.

Javascript even has Python-like constructions such as list comprehensions. And there are other languages that compile to JavaScript and can be fairly easily integrated into JavaScript projects, such as CoffeeScript -- which itself is Python-like in a number of ways, including semantic indentation. 

You can put together tools such as Firebase, Knockout and KnockoutFire to cause changes in your database to automatically and near-instantaneously show up on-screen in your SPA with trivially little code through data-binding. Of course, there are ways of doing that with a framework like Django as well, but data-binding is integral to the way some SPA frameworks operate.

Lately I've been experimenting with Durandal as my SPA framework. It incorporates Knockout, and I'm using KnockoutFire to connect it to a Firebase database. Using a framework like Durandal provides organization for your code, and provides facilities like routing.

So far, I'm very impressed. The main drawback (other than already-noted inherent weaknesses in Javascript itself) is that the documentation and ecosystems of long-existing, high-profile projects like Django are much more evolved. But those things will get better in time, and I'm looking forward to continuing my explorations with Durandal and Firebase.