London Web Standards – slides and further info

Sorry for the delay, but I finally got around to sticking my presentation from last month’s London Web Standards meet-up on slideshare. Slideshare is a bit naff to be honest, but it’ll do for now. If you click through to the talk on slideshare, you’ll be able to get my notes which should hopefully make the pictures more useful. Jake‘s busy syncing up both of our presentations to the videos so that we can show them on the BBC developer blog, so as soon as they’re available I’ll link those up too and you can view me in full hand-flapping, ranting form.

I think I speak for both of us when I say that we really enjoyed the evening – everyone was lovely and friendly and asked really excellent questions. Highly recommendable meet-up, and we’re both intending to try and make it to some of the future sessions.

Some useful links from my stuff:

London Web Standards Talks

Jake and I will be guests at March’s London Web Standards meetup. We’re giving a pair of JavaScript themed talks that should give plenty of fodder for the latter half of the evening’s discussion. I’m doing “Pro bun-fighting“, covering how we manage working on a large scale JavaScript project with a small team, our process, the performance and quality testing we do, and how to integrate group hugs, and Jake will be doing “The events left behind“, talking about the horrors of keyboard events, how to work around them and what’s their future.

Although it’s not a Glow specific talk, we will be using Glow in our examples, so feel free to come along and talk to us about the library too, if you’re interested.

Tickets are available now for the event on Wednesday 31st March at The Square Pig in London.

JavaScript speed testing tutorial with Woosh

Friend and colleague, Jake Archibald, has been developing Woosh, which is a JavaScript speed testing framework. Essentially, it’s been developed for Glow because we want to make sure that Glow 2 kicks Glow 1’s ass (and any else who fancies a piece), but he’s open-sourced the work to let everyone benefit from it.

I thought I’d run you through how to set up some basic tests and start benchmarking your own code with Woosh. Bear with me, as it’s still quite new to us too.


Firstly, go and grab the latest copy of Woosh from the Github repo and pop it somewhere to work with it. You’re just running scripts, so there’s nothing to install or configure. Bear in mind that at the time of writing, Woosh isn’t at it’s first version yet – so, not that I’m doubting Jake’s work, you may find the odd bug and if you do, I’m sure logging it in the issues tracker would be marvellous.

If you’re a git user, feel free to include Woosh as a submodule of your own project.

Woosh is primarily designed for comparing libraries, but there’s no reason why you can’t use it to take a benchmark of your existing scripts and then work up optimised versions to compare. If your code can be unit tested well, it can be speed tested just as easily.

Firstly, you need to let Woosh know about the scripts you want to test. You can just add references to each of your scripts using the Woosh.libs property. For each script to test, though, just make sure they have a unique name so you can reference them later (have a sneaky look in Woosh.js to see which libraries already exist and the formats used – infact, if you’re taking your own copy of Woosh, you can just edit your files and add your scripts straight into this file and skip adding them in the test runner page).

Below is how your test runner HTML page should look (also available in the examples directory in the Woosh repo). Notice the reference to your script in the woosh include section, then beneath are links to your individual test files. To make it more manageable, it’s probably best to have one test JS for each script you’re comparing. Remember that Woosh looks for your scripts relative to where you’ve got woosh.js.

<html lang="en">
	<meta http-equiv="content-type" content="text/html; charset=utf-8">
	<title>My Tests</title>

	<!-- include woosh -->
	<script src="/where/youve/got/it/lib/woosh/woosh.js" type="text/javascript">
		woosh.libs['myTestScript1'] = ['/path/to/scripts/myTestScript.js']

	<!-- Add any CSS you need for the test, but restrict styles to #htmlForTest -->

	<!-- Add your tests. The first will be treated as the master -->
	<script src="MyTestScipt1-Tests.js" type="text/javascript"></script>

	<div id="wooshOutput"></div>
	<div id="htmlForTest">
			Put elements you want to use in your tests here. The page will be
			refreshed for each set of tests, so don't worry about one framework
			messing with another.

The final item in the example above would be your intitial test script to be benchmarked (MyTestScript1-Tests.js). This is just a JavaScript file which will call woosh.addTests (as further down).

Now you’ve got a choice: You can either make minor changes and incrementally watch the improvements, possibly using the save feature, or you can create a copy of your script. I’d recommend the latter, so create a copy of your script, and add a reference to it with Woosh.libs again and also create a file to add the actual tests to for it.

You can add and compare as many scripts as you like, so long as their methods are comparably the same.

Creating tests

Adding tests is easy and in a way, they become an extension of your unit tests, confirming that the return values or behaviours match across the board.

Test files look like this and you can either put all your tests in each file, with a block for each script, or put each block in it’s own file. So, below would be your contents of MyTestScript1-Tests.js. You’ll need a second for MyTestScript2-Tests.js etc.

	'Test name identifier 1': new woosh.Test(1000, function() {
		return myFunc();
	'Test name identifier 2': new woosh.Test(1000, function() {
		return myOtherFunc();

Things that matter about these files:

  1. The name identifier needs to match for each of the tests. Woosh isn’t looking for them in order – it’s matching on the names to know which should go into each row. i.e. “Test name identifier 1” should be the same in all test files for matching tests for that function.
  2. The first parameter of addTests should be the name you gave the script in the Woosh.libs command, so Woosh can find your script.
  3. The first parameter of woosh.Test is the number of times a test is to be run. This should be the same for sets of tests for the same thing. If it’s not, Woosh will flag up the test as being unfair.

The value for iteration times is important. It’s large because that’ll help shake out inaccuracies. Woosh will run the test for the number of times specified, then divide the result by this number to give the average run time for that function. You may find that some browsers don’t cope so well with very large numbers of iterations (uh.. IE, we’re looking at you) so don’t go mad with it and think that running it a million times will help your accuracy. On Glow, we tend to aim to run tests from 100 to 10000 times.

Saving tests

You can save one previous set of tests by clicking the floppy-disk icon. It’s just stored in a cookie, and will be over-written if you choose to save another column of tests, but it’s useful if you’re just doing some small changes and just want to compare before and after.

The hard work

Now, of course, it’s down to your hard work. Writing the speed tests is really the easy bit, made ever more so by the simplicity of Woosh. Try your optimisations in the second script and use Woosh to help you benchmark the new script against the old one. All you need to do is load up the test runner page and hit start. The results will pop up as they complete and become colour coded as the results are compared. Keep an eye out for tests that error (they’ll go slate grey) or test titles that turn yellow (the titles click to expand further test information). Either of these can indicate that the test isn’t fair because the iteration value isn’t matching, the return values aren’t the same or a method has failed all together. You should aim to have all your tests running without errors or warnings.

Another thing to note is that you’ll still need to run all of these tests in all of the browsers you want to optimise for. You’ll find massive varience in some cases and it’ll be up to you to decide where to keep the speed. Jake’s Full Frontal presentation covers some of the things to look out for, so that’s definitely worth a look over (most importantly, make sure you’re not running developer tools like Firebug when running your tests, since it’ll skew your results quite heavily).

Further reading

If you want to have a look at some real tests, Glow 2 has a fair few now for some of the basic modules. They’re all up on github, so have a dig around or feel free to clone the repo and run the tests yourself.

The full API has been documented for Woosh, too, although I believe that might be an exclusive as I cannot see reference to it from the github docs at the moment. I recommend taking a look through those to see about running async tests and preparing your code with setup functionality using $preTest, as well as a few other features you might find useful.

On another testing topic, Mat Hampson published an article on A-B testing on the new BBC Web Developer blog.

Github and QUnit

This year, Glow switched over to using Github as it’s code repository when it went open source to make collaboration easier. To be honest, getting used to git and github in general has been somewhat of an uphill battle for the team, but we’ve really found it’s come into it’s own recently now that we’ve adopted using submodules.

Glow 2 now includes Sizzle, Woosh and QUnit all as submodule projects of Glow, and doing so has instantly made Glow feel like a more team-playing product.

The whole many hands make light work approach is really quite good fun. For example, Jake started working up a design for Woosh, his new speed test framework for JS that he’s also open-sourced, which was making default QUnit look a bit… uh… under-loved, so I forked QUnit and started to reflect the designs, and over the last couple of weeks worked it up to something that the QUnit team have decided to accept back into the main project. Github made that extremely easy and now Glow, jQuery and the wider JS community benefits from a little bit of time spent making something that was essentially made to please just 3 pairs of eyes.

QUnit Theme, Screenshot by John Resig

Picture credits: QUnit Screenshot from John Resig’s Flickr Stream, designed by myself.

Full Frontal 2009

Last week I was lucky enough to get to attend Full Frontal 2009 in Brighton with a whole bunch of my colleagues to lend a bit of support to friend and fellow Glow developer, Jake, after his previous highly successful first foray into the world of speaking at last year’s @media ajax.

The range of topics was excellent. It was really good to see some more people speaking about server-side JavaScript and it seems that Simon Willison’s talk and demo of node.js was a particular highlight for a lot of people and certainly seemed inspiring (which is possibly why he’s always such a good last speaker).

I’m never terribly good at taking notes, but I didn’t think there was an off session of the day. PPK wowed us with the frankly impossible task that is mobile browser testing, Todd Kloots did one of the better and more thorough introductions to ARIA and accessible JavaScript development talks I’ve seen (and it’s a shame he ran out of time), and Robert Nyman did a gallant job of explaining closures and currying (amongst other things, via the inexplicable medium of Ben Affleck) – both of which I think are akin to explaining string-theory to primary-schoolers.

Of course, I’m slightly biased and I really want to tell you everyone else is just being kind and he actually sucked, but even though I’d already seen Jake’s “Optimising where it hurts” practice run-throughs and had already heard many of his jokes and examples, I still laughed throughout and thoroughly enjoyed his animated way of explaining the topic (which he does fluently and coherantly) and thought he stole the day.

Generally, I thought the day was a total success. The venue was lovely (although it’s a shame it wasn’t a slight bit more central, and the rain always sucks) as it was a fully-functional cinema – seats were comfortable and the quality of the screen and sound were excellent. Everything seemed to be organised extremely well and can’t really fault it, so big congrats to Remy and his lovely wife, and all the helpers. I really hope they organise one again next year – I’ll definitely be there.