Flow, Interruptions and Gold-Titanium Alloys

As I mentioned earlier, I've just had a very productive and fun weekend of hacking on testresources. But why was it so good?

Fast Commits

Because I was working offline using Bazaar, I could make commits to testresources and they'd be done before I could Alt-Tab back to Emacs.

Fast Tests

It takes about 0.15 seconds to run the test suite. This meant I was running it all the time, which in turn meant that I was totally certain about whether the code worked all the time.

Clarity of Purpose

I knew where I was and where I wanted to go.

No Rabbit Holes

The testresources code base is small enough that it is nearly impossible to get distracted by other systemic defects. If there is such a defect, it's probably the one that you're working on right now. This might be another way of saying...

No Blockers

I wasn't waiting on anyone to do anything. There weren't any other bugs that needed to get fixed before I could continue.

No Integration

The system is about as self-contained as it gets. No signals, subprocesses or sockets: just Python. The only dependency is pyunit3k, which is small, robust, well-tested and also pretty darn self-contained.

No Interruptions

I wasn't answering questions on IRC, taking Skype calls, handling incoming email, doing the washing, checking Facebook, catching up on my blogs, watching a film or wrestling a bear. "Fast Commits" and "Fast Tests" probably fall into this category too.

In other words:

There is nothing except this. There's no art opening, no charity, nothing to sign. There's the next mission, and nothing else.

testresources: fresh blood

Last weekend I spent a bunch of timing hacking on testresources with Rob over at Chris's place. testresources is an extension to unittest that allows tests to specify the resources they use declaratively, so that these resources can be cleanly shared between tests. On Saturday, we talked a bit about direction and decided on some goals. On Sunday, I got busy.

The idea isn't particularly new: zope.testing has had "layers" for a long time. The key differences between testresources and Zope layers are:

• You can use more than one TestResource. You can only use one layer. Allowing tests to specify many resources makes it easier to use only the resources that you need, which in turn makes for a faster test suite.
  
• A test that uses testresources can be used independently of other testresources machinery. With layers, you pretty much need the whole shebang. This means that you can use testresources with trial, bzr, nose, tribunal or unittest.TextTestRunner.
  
• Layers have magical inheritance stuff. testresources has no magic.
• Layers do some work in subprocesses to accommodate some setUps that can have no tearDown. testresources doesn't know what a process is.
  

That said, I'm mainly familiar with layers from Zope 3.2—they may have changed since then.

testresources itself is somewhat old. Rob hacked up the first version about three years ago and little has happened to it since. I've always agreed with the approach, but have also had a few qualms about implementation details that made me reluctant to use it or to recommend it. Now, it's well on its way to being something that I can trust and perhaps, love.

If you are interested, check out my branch or at least flick through the TODO file.

Cool Launchpad/Bazaar hack

If you push a lot of Bazaar branches to Launchpad, you might want to add something like this to your .bazaar/locations.conf:

[/home/jml/Code]
public_branch = lp:~jml
public_branch:policy = appendpath
push_location = lp:~jml
push_location:policy = appendpath

Once it's there, 'bzr push' will Just Work... as long as you want it to do something like:

jml@rhino:~$ cd ~/Code/pyunit3k/trunk
jml@rhino:~/Code/pyunit3k/trunk$ bzr push
Using saved location: lp:~jml/pyunit3k/trunk
No new revisions to push.

So if I've got a branch in ~/Code/<project-name>/<branch-name>, it'll be published at https://launchpad.net/~jml/<project-name>/<branch-name>. This is only a default, of course: you can override it for a given branch by doing:

bzr push --remember <new_location>

Or you can override it for a bunch of branches by hacking locations.conf.

Neat huh?

I Love Data

At work, we recently started to graph the time it takes to access a branch in Launchpad via SSH, both on our staging and production servers.

I love this so much. Having this data is liberating. It's like turning on a light in a dark room: suddenly I can go from uncertain, careful, hesitant steps to bold, confident strides.

In fact, the metaphor stretches further. This new light has revealed objects of interest (that is, spikes in the time taken) that I wasn't aware of before. I need to know how long these spikes last, how they correlate with load on the system and so forth. Soon there'll be more graphs, and I'll be able to correlate them and analyze them and suck on their delicious, numerical marrow (the light metaphor long abandoned).

Regardless of whether it's liberating illumination or nourishing, savoury meat, this new graph makes me wonder why I don't chart other things I care about. Having such graphs would help me see the impact of my actions. I could chart things like my bank balance, my waistline or the number of Latin words I learned this week. Then I could answer questions like "do I spend more on Tuesdays?" or "can I afford this iPod/cake/gerund?". This is important, because when I am tempted with a sleek/delicious/perplexing iPod/cake/gerund, I fall back on my own judgment. I think it's time to confess, dear reader, that my own judgment isn't very good. And yet I continue to trust it.

The reason I don't have such graphs is that they are inconvenient to maintain. A graph of branch access times is easy. All you need to do is describe how to get the measurement, and then do a bit of once-off set up. If you want to graph your body weight, you need to get on the scales at a fixed time and then look at the dial and adjust for parallax and then write a number down somewhere and maybe note down whether this is before or after a meal and then take the number and then add it to a spreadsheet. Most online banking sites I've seen are even less convenient than this.

Getting data on life is hard, but for programming it's easy. What things do you care about on your project? Features, user experience, how fast bugs get fixed? Can you quantify these things? Can you make a pretty picture out of it? If so, do it now! Post your answers here, set up something like Cricket and then profit!

P.S. I can't believe I got to the end of this post without saying how awesome the Canonical sysadmins are. Let me correct that now. The Canonical sysadmins are heck of awesome. They could simply walk into Mortor.

Somebody Do This Please

<jml> What's the difference between Gobby and a wiki?
<mwh> NAT

GMail feature request

First, where should I make these requests?

Second, I'd like to be able to open my GMail without seeing all the new mail in my inbox. Very often, I open up GMail just to look up some fact that I've forgotten, or to put a date to a particular event. Seeing new mail and an unempty inbox distracts me, leading me down a rabbit hole of processing.

I guess a GreaseMonkey hack wouldn't be too hard.

2008

Firefox 3 is awesome!