Mere Code

testtools 0.9.14 released

2012-02-16T10:55:00.000Z

testtools's sister project, subunit, was using a private API that we deleted in the 0.9.13 release. This release restores that API in order to smooth out the upgrade path.

If you don't use subunit, then this release won't matter very much to you.

testtools 0.9.13 released

2012-02-06T15:55:00.000Z

It has been a while, but testtools 0.9.13 is finally out! Lots more matchers and bug fixes, as well as improved error reporting. Full release notes on Launchpad.

Thanks to James Westby, Graham Binns, Francesco Banconi and Robert Collins for making this release possible.

Simple made easy

2012-02-01T13:50:00.000Z

Rich Hickey did a great talk at Strange Loop called "Simple Made Easy". You should watch it.

When I tried to explain the talk to someone, I stumbled a lot and it was obvious to me that I didn't really understand it. So I'm going through it again and turning it into a blog post, purely for my own gain.

This is roughly the first half of the talk. Not much of my own analysis or opinion is inserted, and I've pretty much stuck with Hickey's illustrations and phrasings. Thus this post is pretty derivative. Oops.

Simple vs Easy

"Simple" means one thing, "easy" another. Simple is the opposite of complex. A thing is simple if it has no interleaving, if it has one purpose, one concept, one dimension, one task. Being simple does not imply one instance or one operation: it's about interleaving, not cardinality. Importantly, this means that simplicity is objective.

Easy is the opposite of hard, or difficult. A thing is easy if it's near to hand, if it's easy to get at (location), if it's near to our understanding (familiarity) or skill set or if it's within our capabilities. This means that ease is relative.

Speaking English is dead easy for me, but that doesn't mean that speaking English is intrinsically simple. I find French quite difficult. Little French children speak French all the time, and there's always a part of me that thinks, "Boy, those kids are clever, being able to speak a foreign language at that age", but that's silly. It's easy for them, it lies near to them.

This distinction between simple & easy is good one, and is useful in all sorts of areas. But how does it relate to software?

Constructs vs Artefacts

As programmers, when we make software we are working on constructs: source code, libraries, language concepts and so forth. Rich contends that we focus on the ease of use of those constructs: How many lines of code? How much boilerplate? Will new developers be familiar with our technology?

But all of this is secondary. What actually matters is the artefact, the running programs that users actually use. Does it do what it's supposed to do? Does it do it well? Can we rely on it working well? Can we fix problems when they occur? Can we change it? You know, the interesting problems.

Thus we need to be assessing our constructs – our code, our technology choices – based on the attributes of the artefacts that we'll create, not based on the experience of typing code in.

Limits

We can't make something reliable if we don't understand it. And, actually, everyone's understanding is pretty limited. We can all only hold a small number of things in our head at once.

When things are complex, many parts are tied together by definition. You can't pull out just one piece and consider it because it's intertwined with other pieces. This creates an extra burden to understanding a system and thus makes it difficult to reason about the system.

You do need to reason about a system, both to know what to change and to be able to do so without introducing defects. Tests, refactoring, rapid deployment and all that are great, but to make a change to the system safely & without fear still requires you to be able to reason about it. Every bug in your product that was found in the field passed the type checker and passed all of the tests. Your type system doesn't tell you what change to make next in order to get the software you want any more than guard rails on a highway tell you how to get to Grandma's.

Speed

Focusing on ease and ignoring simplicity means that you'll go really fast in the beginning, but will become slower and slower as the complexity builds.

Focusing on simplicity will mean that you'll go slower in the beginning, because you'll have to do some work to simplify the problem space, but making sure that you only have intrinsic complexity means that your rate of development will remain at a high constant.

There are no actual numbers for this.

Complicating constructs

Many complicating constructs are available, familiar, succinctly described and easy to use. But none of that matters to end users. What matters is the complexity they yield. This complexity is incidental, it's not intrinsic to the problem.

If we build things simply, then the resulting system is easier to debug, easier to change and easier to understand.

Compare a knitted castle to a castle made of Lego. The knitted castle might have been great fun to make, and might have been really easy if knitted using a loom and cutting edge knitting tools, but there's no way that it's easier to change than a Lego castle. It's not about the ease of construction, it's about the simplicity of the artefact.

How can we make software easier?

Well, we can install it to make it easier by location. We can learn it and try it to make it easier by familiarity. We can't do much about our capabilities though. If we want software to be easier to comprehend, we are going to have to bring it down to our level. We have to make it simpler.

Take Lisp as an example. It's hard for many people because they don't have a Lisp installed, or their editor doesn't support paren matching, but they can make it easier by installing a Lisp and getting a plugin for their editor. It's also hard because it's unfamiliar. Who'd have thought that parens could go on that side of the function? But you can gain that familiarity quickly enough.

But parens in Lisp are used for functions and for grouping data. That's hard to get your head around, and that's because it's complex. It braids together two distinct notions.

Undistract me

2012-01-23T14:32:00.001Z

Here's a thing that happens a lot to me: I'm doing some work, and as part of that work I need to run a command in my terminal that takes a little while. I run the command, look at it for about a second and then switch to doing something else – checking email, perhaps. I get deeply involved in my email checking, and then about twenty minutes later I switch back to the terminal and see the command has finished. For all I know, it finished nineteen minutes ago, and I was just too engrossed to notice it.

This is a big productivity sink for me, especially if the command happened to fail and need retrying. I'm not disciplined enough to just sit and watch the command, and I'm not prescient enough to add something to each invocation telling me when a command is done. What I want is something that alerts me whenever long running commands finish.

Well, that thing now exists, thanks to glyph's script that provides precmd and postcmd support to bash and a lot of help from Chris Jones of Terminator.

To use it right now:
$ bzr co lp:~jml/+junk/shell-tools
$ . shell-tools/long-running.bash
$ notify_when_long_running_commands_finish_install

You'll see that if you run a command that takes over 30 seconds to complete, it will pop up a notification, which should hopefully take you away from whatever it was you are doing and back to the task at hand.

If you look at the code, you'll see that it installs two hooks: precmd and preexec. preexec runs just before the shell launches a command, and precmd runs just before it prompts for the next command. Our preexec stores when the command was launched and the precmd checks to see if it finished within a certain time frame. If not, it sends out a notification.

Currently, you'll get a notification when you finish reading a long document, since the command finishes a long time after the command starts. Obviously this isn't ideal. I think the fix is to only send notifications when the shell doesn't have focus. Unfortunately, that's a little tricky and I think is going to be highly terminal specific.

Anyway, I'm a total shell newbie, so I'd love to know if there's any way this could be done better. Also let me know if you find this useful, or you know of someone who has already done this.

What are my projects?

2011-12-26T04:54:00.000Z

Launchpad doesn't really have any good mechanism for letting you review a list of "your" projects.

That's partly because there are a lot of different ways that it could do it. You could be the maintainer of a project, or its driver, or its bug supervisor, or you might have commit access to its trunk branch. All of this could be direct, or through membership of a team. It's tough.

Since it's that time of year when I review my projects, responsibilities, goals and the like and start to figure out what I want to do next year, I want to figure out what are my projects on Launchpad.

Luckily, Launchpad has an API. I can't use it to figure out what projects I'm the maintainer of, but I can use it to figure out what trunk branches I have commit access to. The link has the Python code for the script.

Really, Launchpad should allow me to curate my own list of projects, with input to that list coming from all of the sources mentioned above, as well as arbitrarily selecting projects.

pyflakes update

2011-11-21T12:44:00.001Z

Thanks to radix, exarkun & dash, my branch to pyflakes to warn about duplicate definitions of classes finally landed. I did the work a year ago as an outrage-powered, opportunistic fix after I saw a co-worker struggle with tests weirdly not failing (Turned out it was a huge test module and there was another class at the bottom with the same name). I'm very happy to see it landed.

For those who haven't been paying attention, official pyflakes development is now taking place on Launchpad as part of the divmod.org project. The trunk of that project now has the best version of pyflakes known to man.

pyflakes is the best static Python checker. It's fast, and has very few false positives.

Update: A couple of people have asked me about lp:pyflakes. It's dead. It died when the divmorg.org trac instance died ages ago. Don't use it. To get pyflakes or any other divmod project, use lp:divmod.org.

Automatic packaging update

2011-11-10T12:40:00.002Z

I just blogged on developer.ubuntu.com about the work we're doing with automatic packaging. Read it!

How to feel better (or, some tips on refactoring)

2011-11-04T18:29:00.000Z

A few months back I gave a lightning talk at the Launchpad Thunderdome about how I do refactoring. It's very opinionated, and mostly applies to big, old code bases, but worth writing up anyway.

The core idea here is that very few things make me feel as good as deleting code. I love cleaning up code and the clean code base that results, and I'm sure that many others feel like me. As such, this is a guide on how to feel better.

1. Know your enemy

“Functionality is an asset, code is a liability”. Truer words were never spoken. Every line of code is a potential source of bugs and a barrier to understanding, and thus carries a maintenance cost.

Maintain an awareness of things that need refactoring. Here's a quick and incomplete list:

unused code – this can be deleted
boilerplate – this should become a function or class
wrong documentation – these should be updated
two ways of doing something – perhaps there should be one
bad names – change them to something that makes you think less

2. Keep a "yak stack"

Yak shaving is "any seemingly pointless activity which is actually necessary to solve a problem which solves a problem which, several levels of recursion later, solves the real problem you're working on." (Jargon File)

A few of us have extended the concept beyond the "actually necessary" to include anything that's making the task at hand more difficult and less fun but is not worth fixing right now. Hence the yak stack. Here's how it works:

Whenever you come across something in your code base that is difficult to understand or that slows you down: make a note of it. When you've finished the task at hand, fix the problem. If you encounter other things that slow you down, write them down. Work through the list.

3. Every option is wrong

In a big, old code base, there are probably many, many areas that need refactoring. Don't worry about which is the "best" place to start – there is no best place.

4. Start from green, stay green

Never, ever refactor while your tests are failing. Refactoring is about changing the shape of code while preserving its behaviour. It's much harder to be sure you're keeping the behaviour if you are comparing one set of thirty tracebacks with another set of thirty tracebacks. Better to compare a passing ("green") test run with another passing test run.

Run tests frequently. More often then you think you should. Commit often – think of it like quick save in a tough level of a video game. It frees you up to experiment more and means you have less in your head at any one time.

5. Do not nest

Don't begin a refactoring while you are in the middle of another refactoring. If you find you must, use tools like 'bzr shelve' to store your current diff and then work from the clean head of your branch.

6. Keep moving, leave a trail

Don't get bogged down in details, otherwise you'll never finish. Literally. Someone will come along and distract you and before you know it, three months will pass and your refactoring branch will be full of conflicts. If you see something you are unsure of, mark it with a XXX or a FIXME or a TODO or whatever works for you and then continue with what you are doing.

Tools like 'bzr todo' can make it really easy to check to see if you've added any XXX comments.

7. Translate tests with care

As said above, refactoring is about changing the shape of code while preserving its behaviour. When you update tests, you risk changing your definition of the system's behaviour – so be careful.

8. Confront uncertainty with destruction

If you see some code and you are not sure if it's needed, delete it. Doesn't matter if it's a whole function or just an odd line. If you have a test suite, and it was important, that will catch the failure. If you have version control, and it was important, one of your collaborators will notice and revert the change.

If it was important and neither of these happened, then your whole project has learned something new about itself, and that's probably worth the hassle. (Oh, add tests & better docs after this happens.)

9. Good grep tools

Remember that symbols aren't only referenced from files that match *.py. In big code bases there are often other sorts of files that refer to symbols in the main code. In Launchpad, for example, we have ZCML and doctest files that refer to symbols. When you want to know how something is used or you want to rename something, make sure you use a grep command that actually finds everything.

Ideally, you should be able to run this command faster than you can think about wanting to do it.

Personally, I use 'bzr grep' a lot. Others recommend 'ack'.

10. There will be failures

Mentally prepare yourself for the fact that the first two or three full test runs after your refactoring will fail. This is especially important for code bases that have multi-hour test run times.

If you think this way, then you won't be as discouraged when it actually happens.

11. Finish the job

Busy people refactoring a big code base are often tempted to apply a refactoring to only a single part. For example, some useful function is extracted from repeated boilerplate in a few other functions. However, many, many other instances in the code base continue to use the repeated boilerplate.

This is almost worse than just leaving the repeated boilerplate. There are now two idiomatic ways of doing the activity. Further, other developers who work on other parts of the code base probably won't find out about it, and might end up repeating your refactoring. Ugh. How is anyone new expected to get to grips with this code?

Similarly, if a class, function or concept is renamed, rename it everywhere, especially in the documentation.

It's difficult and often tedious, but it really is worth taking refactorings to completion. Apply them to the whole code base, or not at all.

Note that I'm referring to completeness, not perfection. If you block on perfection, you never get anything useful done. If you aim for frequent incremental improvements, you soar.

12. Read these books

I highly recommend "Refactoring" by Martin Fowler and "TDD by Example" by Kent Beck. I stole many of these ideas from them.

Over to you

This was very much just a dump of how I do refactoring when hacking on Launchpad. I'm always keen to learn more, and would love to hear about what works for you.

testtools 0.9.12 out

2011-09-14T12:01:00.000+01:00

testtools 0.9.12 has just been released!

It's a huge release, this one. We normally try to release much more frequently, but for this release I wanted to wait until all of our known unicode handling bugs were fixed. Today, Martin [gz] finished off his heroic branch to fix up assertThat, and I figured it was time to release.

In addition to all of the unicode fixes, we've really cleaned up the way test failures are displayed. A lot of the boilerplate around the traceback has been removed, a lot of levels of the stack are gone (although you can get them back if you want), and assertThat is way less repetitive. This all really adds up. If you're using an old release, you want to upgrade right now. Honest.

For me, this release is the one where using matchers becomes really and properly fun. As such, all of our assertFoo methods are now implemented in terms of matchers.

Of course, we have our usual raft of fixes, helpers and new matchers too. The full changelog is on Launchpad.

In addition to Martin [gz], thanks to Christian Kampka, Robert Collins and Canonical for making this release what it is.

If you're new to testtools, it's basically a way to do serious, tasteful unit testing in Python.

Documentation lives at http://testtools.readthedocs.org/en/latest/.
PyPI: http://pypi.python.org/pypi/testtools
All development takes place on Launchpad: https://launchpad.net/testtools
Join us on #python-testing on Freenode

We don't currently have a release PPA, but we do have a daily builds PPA. The trunk is kept stable using Jenkins, so it's fairly safe to use.

doctest really isn't very good

2011-09-09T18:36:00.001+01:00

I just got sick of trying to decode obtuse doctest diff errors when using NORMALIZE_WHITESPACE and ELLIPSIS options. Although doctest gives you hooks to do something about this, it's really hard to actually write the logic.

See, NORMALIZE_WHITESPACE also normalizes line breaks, and '...' can match across multiple lines. That means that you can't take a line-based approach, which makes it really hard to clean up a diff. Anyway, here's my attempt: https://code.launchpad.net/~jml/testtools/better-doctest-output-checker/+merge/74842

It's a pain, because both of them would be very useful without their line-spanning behaviour. I guess without the line-spanning behaviour of '...' there'd be no way to indicate multiple lines of crap in output.

My suggestion in the mean time? Don't use doctest.

Progress on auto packaging

2011-08-23T19:09:00.000+01:00

Instead of a junk branch, the auto packaging code now has a proper home on Launchpad. I've filed bugs for all of the things that I could think of that were wrong with it. Actually, that's a lie. When I spot something wrong in code or behaviour I make a note, usually a XXX comment. The bugs up there are the ones I got from grepping my notes.

Anyway, minor rant on effective use of brain and the gift of literacy aside, I've also done a reasonably detailed specification. It's been a long time since I've done a spec this technical & detailed, but I hope it works out. If you have any comments or questions, ask here or on the spec itself.

How dependency guessing works

2011-08-18T13:18:00.000+01:00

Although in my last post I talked about our proof of concept tool, I didn't actually explain how to use it. That's mostly because it's not quite ready to be used by others. There's a good reason.

The most interesting thing that pkgme-binary does is to guess the dependencies of an application given only its tarball. The way it does this is by finding all of the ELF objects (executables, shared libraries etc.), reading the symbols from them, and figuring out the packages based on those.

Canny readers are already thinking, "Yes, that is what dpkg-shlibdeps does" – which is true. As some background, Debian packages that export symbols for linking also provide explicit metadata about those symbols and what versions they appear in, in order to allow Debian packagers to figure out dependencies easily using dpkg-shlibdeps. Fascinating reading can be found in the Debian policy manual, a spec on improving dpkg-shlibdeps and the guide on using the new symbol files.

Unfortunately, dpkg-shlibdeps can only query packages that are installed on your system. If you have a binary with symbols that are not provided by any library on your system, you cannot use it to calculate dependencies. Debian (or the Debian flavour of your choosing) might have a perfectly good package to satisfy that dependency, but you won't be able to find it.

So, to do dependency guessing properly, you need to have a database mapping symbols back to packages. Debian already has something like this in its mole database. Ubuntu doesn't have anything like this that I know about.

Assembling and maintaining such a database is pretty much a simple matter of programming, but it's still work that I wanted to avoid for the proof-of-concept. Instead, I used the mole database in Debian for the calculations. That means we'll get wrong answers for Ubuntu, but it demonstrates that the concept works.

Since I have a copy of that mole database locally, and since it's about 1.5GB, I'm not distributing it with the branch. Which means that the automagic binary packaging branch won't actually work for you.

Automagic packaging of binary apps for Ubuntu

2011-08-18T12:52:00.001+01:00

For the last few weeks I've been working on a tool to automagically package binary applications for Ubuntu. The idea is that anyone who wants to distribute a binary app on Ubuntu should be able to do so without having to learn how to package it.

I've used pkgme to build a proof-of-concept: which you can look at here: lp:~jml/+junk/pkgme-binary.

Or, you can watch the demo:

Right now, the tool assumes that the tarball:

is an application
contains ELF objects that can be scanned for symbols, which determine the dependencies
has one main executable file
that its contents can be copied into /opt/$PACKAGE/ and can be run from there by an ordinary user
comes with a JSON file specifying extra metadata

Our hope is that 90% of the binary applications we get will meet these requirements.

The plan is to take this proof-of-concept and turn it into something that will run server-side behind the Ubuntu Developer Portal. Next steps are to spec it out, create a project, start filing bugs and fix the bugs I already know about.

Watch this space for more updates.

Thanks to James Westby and Adam Conrad for their help in doing the proof-of-concept and to the dozen or so people who helped me get the darn screencast out.

launchpadlib helper

2011-08-02T12:05:00.000+01:00

I often need to muck around in a Python interpreter to figure out what I need to do with Launchpad's API. As it is, I write out the same commands over and over.

Since repetition is a stupid boring job that we should force machines to do while they are still subservient, I wrote a harness that, when run, gives you a Python interpreter and a few useful objects for playing with the Launchpad API.

For example:

$ ./lpharness.py 
lp:     authenticated Launchpad object
me:     logged in user
anon:   anonymous Launchpad object
errors: launchpadlib.errors
uris:   launchpadlib.uris

pprint: pretty printer
>>> pprint(list(me.searchTasks(status='In Progress')))
[<bug_task at https://api.launchpad.net/1.0/launchpad/+bug/240067>,
 <bug_task at https://api.launchpad.net/1.0/launchpad/+bug/418932>,
 <bug_task at https://api.launchpad.net/1.0/hydrazine/+bug/535414>,
 <bug_task at https://api.launchpad.net/1.0/hydrazine/+bug/574981>,
 <bug_task at https://api.launchpad.net/1.0/hydrazine/+bug/612641>,
 <bug_task at https://api.launchpad.net/1.0/tarmac/+bug/683351>,
 <bug_task at https://api.launchpad.net/1.0/wikkid/+bug/695232>,
 <bug_task at https://api.launchpad.net/1.0/launchpad/+bug/721166>,
 <bug_task at https://api.launchpad.net/1.0/ensemble/+bug/728320>,
 <bug_task at https://api.launchpad.net/1.0/bughugger/+bug/731075>,
 <bug_task at https://api.launchpad.net/1.0/tarmac/+bug/807785>,
 <bug_task at https://api.launchpad.net/1.0/pkgme/+bug/809447>,
 <bug_task at https://api.launchpad.net/1.0/ubuntu-archive-tools/+bug/805634>]

Script: http://paste.ubuntu.com/657088/

You are free to do whatever you like with it. I hope that someone puts it into some useful, maintained, centralized place for doing stuff with Launchpad. Perhaps launchpadlib itself.

Ubuntu on my iMac

2011-07-10T14:52:00.000+01:00

Long time readers will know of my attempts to get Ubuntu running on my iMac. Now that I'm working within the Ubuntu Engineering team at Canonical, I figured it would be a good time to try again.

Installing natively fails on 11.04 in the same way that it failed on 10.10: the installer sends output to the Mini DisplayPort rather than the actual screen. I don't have an external monitor that I can hook up to the DisplayPort, so that's pretty much that.

I can still run a VM, right? VirtualBox is pretty good, and I got me a running install of Ubuntu with the Unity shell without too much fuss. Problem comes with keyboard configuration. The literal keypresses Cmd+H and Cmd+Q are not passed through to the guest OS. With a Dvorak layout these become Cmd+D and Cmd+", and if one maps Cmd to Meta then you cannot easily kill-word in Emacs. That means for me to have a useful environment, I'd have to make do with Super and Meta swapped around from the usual PC layout.

VM Fusion doesn't have this problem and has a nicer UI, but I can't run Unity or compiz under it. This makes Ubuntu feel really old and clunky, and I'd rather not do that.

Parallels, well, at this point I'm running out of the will.

Think I'll settle on VirtualBox for the time being.

Leaving Launchpad, going to work on Ubuntu

2011-06-20T12:10:00.000+01:00

After four and a half years of working on Launchpad, I'm moving on within Canonical, taking a position on the Ubuntu Engineering team, working to get more and better apps on Ubuntu.

I am very excited about the change, but also a little sad, since it will mean leaving what has been the best team I've worked on. They are a wonderful bunch of people who not only get a lot of great stuff done, but consistently surprise me with their constant drive to get better at what they do.

Over the last couple of years, we have changed the way we are organized so that we can focus on building a small number of features at a time, the features that we do churn out are much, much better, we are rolling out new versions of Launchpad multiple times a week and we are actually paying off technical debt.

And they've needed to: Launchpad is a massive, ambitious application. I've never worked on something so big that aims to do so much, and with so few people actually hacking on it.

I still care a lot about Launchpad, It's crammed with potential and has so much to offer the open source world. It's going to be hard for me to move on.

But, wow, what a place to move on to, and what a time to do it. Ubuntu is aiming to go from about 20 million users to about 200 million, and to do that is going to need way, way more apps than they have now. To do that, we'll need a spiffing developer programme, and that's where I come in. I'll be loading up on information, plans and more concrete goals in a couple of week's time in Dublin, and will share them as I can.

Oh, and if you want to guide the world's best open source development collaboration platform into the future, do drop me or Francis Lacoste a line.

testtools 0.9.11 released

2011-06-12T14:08:00.000+01:00

While I slept, Robert Collins released testtools 0.9.11. This release is mostly a bug fix release, but the fixes are very much worthwhile.

In particular, Martin [gz] got our Python 3 support going again, Gavin Panella fixed up a dodgy Matcher and fixed a bug in how we feed information from fixtures into test results.

Also in this release, Tim Cole and Martin Pool made their first ever patches, for which they have my hearty thanks and congratulations. (The congratulations are also hearty.)

As always, it's just so darn pleasant to see so many fine people working together to make an open source project work.

testtools 0.9.10 released

2011-04-11T13:44:00.002+01:00

There was a bug in testtools 0.9.9 that prevented it from being easy_installed. Tres Seaver has fixed this bug, and I've rolled out a new release: testtools 0.9.10. Sorry for the inconvenience folks.

testtools 0.9.9 released

2011-04-08T13:00:00.000+01:00

testtools 0.9.9 has been released today. For me, the twin pillars of this release have been our vast documentation improvements and the new matchers, which make it very, very easy to make meaningful assertions about complex objects. Well worth checking out.

Thanks to Christian Kampka, Robert Collins, Aaron Bentley, Jelmer Vernooij and Michael Hudson-Doyle their contributions.

mdz on listening to users

2011-03-08T09:02:00.000Z

Matt Zimmerman writes about whether we should listen to users. It's a great post, and you should read it, but the summary is:

If you want inspiration for a new product, don't listen to users, watch them
To test whether a product is a good fit, ask users for feedback and listen to it
If you want to incrementally improve an existing offering, don't listen, gather data

I'm over-simplifying, you should read the original post. I also wonder whether it should be "when is it safe to not act on user feedback", rather than "not listening" per se.

Music is too hard

2011-02-02T12:04:00.000Z

It's way too hard to keep all of my music stored on one machine in a lossless format, have it backed up to another machine, synced to my iPod in MP3 and have it pleasingly playable on my OS X computer. Way too hard. Really.
Especially since fixes to track listings and so forth seem to vanish like smoke in the breeze. Banshee and Rhythmbox both pretend to help, but that's only so they can mess with my life more.

Expressing agreement and disagreement numerically

2011-01-25T18:02:00.000Z

There's a habit within Canonical on expressing agreement and disagreement numerically. If we agree with something someone says in email or IRC, we'll often say "+1", which means "I agree!" or "if we were to vote about this, you would have my vote". I sometimes hear people actually say the words "plus one" in conversation.

Some have extrapolated from this to say "-1" to mean "I disagree", which is a pretty natural thing to do. However, it confuses me a lot.

You see, the "+1" thing is a little bit like the Apache voting system, which I met in my early days of open source, back when I lurked on the Subversion development mailing list. The voting rules there were burned into my mind, and I foolishly assume that they are equally fundamental to everyone else.

In the Apache system, "-1" means "veto", which is a very strong way of disagreeing. When people on the Launchpad say "-1", I never really know what they mean. I don't blame them, "-1" is a bit of a silly way of vetoing a proposal. I bet if keyboards had a key for ∞, there'd be a much more sensible way.

I guess the moral of the story is, "ambiguous shorthand is ambiguous".

Incidentally, how does the Apache voting system work out in practice these days?

Larval prototype for Launchpad dashboards

2010-12-23T16:09:00.000Z

I mentioned a while ago that I really want to see something like a dashboard in Launchpad, some kind of view that shows you everything that you must do, everything that you are waiting on from others and all of your current work-in-progress. Launchpad could do this really well, since it has rich, inter-linked data about what's going on and since it can show you this information for all of your projects.

Today, I knocked up a very quick-and-dirty prototype for this. It shows all of the work-in-progress for a person across all of Launchpad, grouped by project.

The code lives at lp:~jml/+junk/whip and you can see examples of my work-in-progress and jelmer's work-in-progress online. You should be able to make your own with './bin/whip $LP-NAME > wip.html'. Note that there'll be some PYTHONPATH shenanigans.

Hackers, I'd love to see if you could turn this prototype into a web-app, or even a page on Launchpad. There's a NOTES file in there with whatever ideas I've had.

Designers, there's got to be a better way of showing this data than what I've picked. Take a look at the examples and see what you can turn them into.

testtools 0.9.8 released

2010-12-22T19:19:00.000Z

The announcement is a few days late, but I thought that you'd like to know that testtools 0.9.8 has been released.

This is one of our biggest releases, we have fixed a lot of bugs, added experimental support for running tests inside Twisted's reactor and added a stack of new matchers and convenience methods. It's well worth upgrading.

We've also got some good stuff in the pipeline, including a full re-working of our documentation, better error messages and still more matchers.

The "more matchers" thing is significant. More and more people are starting to use testtools because of the way our matchers let them build domain-specific assertions with rich, useful error messages. We continue to get contributions for basic matchers and for new ways of combining matchers. Also, projects like James Westby's soupmatchers show just how useful matchers can be. It makes me think that eventually matchers will become part of the normal way that people write tests in Python.

Thanks to Robert Collins, Martin [gz], Jelmer Vernooij, Michael Hudson-Doyle and James Westby for making this our best release ever.

testtools bug update

2010-12-10T23:03:00.000Z

Hello testtools fans.

If you are wondering what all the recent bug mail was about, wonder no more, for I shall explain. Thus.

We're using only three different levels of importance for testtools bugs: Critical, Medium and Wishlist. Critical is reserved for release blockers: regressions, test failures and other disasters. Medium is for genuine defects and other things that we think are important. Wishlist is for everything else. I think of them as Critical, Important and Someday.

All of this is in preparation for the 0.9.8 release, which promises to be a doozy. Stay tuned.