Fourteen Monthses

I've been waiting since November for this.

Now, if you submit a branch for review on Launchpad, Launchpad will automatically generate the diff for you. For example, take a look at the review page for one of lifeless's subunit branches.

To take advantage of the feature, go to the page of a branch you want to land (you can use bzr lp-open to do this), then click on "Propose for merging into another branch". Select the branch you want to land it on (normally trunk, which is the default branch), then type some stuff explaining what the patch does. Hit "Submit", wait a minute or so, then refresh. Voila.

We hope to tweak the page later so that it's obvious that a diff is being generated and so you don't have to refresh. Even so, I'm very pleased that we got this done. Thanks particularly to Aaron for getting this landed.

Why you should have a public location for your branch

I asked this self-same question on the Bazaar mailing list the other day. Here's the answer:

• Given that the place you push the branch to (its "push location") might be different from the place that others get the branch from, branch's have public locations.
• Any tool that shares your branch with others (e.g. bzr send, a commit notifier or even lp-open) needs to have a public location to share with the world.

Betterer Cloud

The Launchpad branch cloud has been tweaked. We got rid of the green (what does that mean anyway?) and added more variations in font size.

Enjoy!

Useful, unpolished Bazaar plugin

I've just pushed lp:~jml/+junk/bzr-difftodo to Launchpad. It's a Bazaar plugin that:

• Finds the diff between your current branch and the submit branch
• Looks in that diff for any Python comments that you've added or modified
• Shows all the TODO or XXX items in Emacs "compile" format.

So the output looks something like this:

$ bzr todo
Using submit branch /home/jml/repos/someproject/trunk
lib/somefile.py:167:
XXX: JonathanLange 2009-02-23: This matches the old search algorithm that used to live in foobar.py. It's not actually very good -- really it should match based on substrings of the unique name and sort based on relevance.

lib/otherfile.py:680:
XXX: This is using _cromulateSplonks -- a private method that no longer exists.

lib/anotherfile:779:
XXX: I think that this can be moved into IAmAwesome.

Things to do: 3

The branch comes with an Emacs module bzr-todo.el. If you load this module, you can just go "M-x branch-todo" in any file in a branch and have the todo list come up in a compile buffer. Then you can just click on any item to jump straight to it.

The core code is pretty well tested, but everything around is really, really rough. It works for me.

I'd love some patches for it.

100% Pure Doing

As you might know, Launchpad has a code review system. You might have even given it a try a few months ago when it first came out. We, the Launchpad team, started using it almost right away and to be completely honest with you, we didn't like it very much. On the whole we are curmudgeonly engineers who would rather fix bugs or build features than fiddle with a silly website. However, now the much-feted power of dogfood was working for us.

We've been improving the code review system for ages now. It's not perfect, but is getting better rather quickly. Over the last cycle, it has started to become really good. We've done a lot of things this cycle, I want to focus on one in particular, since it's dear to my heart.

On our cutting edge servers, and in the next release, the "active reviews" page for a project is tailored to you specifically. Instead of just showing you all the reviews, like it used to do, it shows you the following lists:

• The reviews you must do. That is, the reviews specifically requested of you that you haven't done.
• The reviews you can do. Reviews that have been requested of your team that no one else has done yet.
• The reviews you are waiting on. Reviews that you've requested that haven't been done yet.
  
• The reviews you have completed. Reviews you've done that haven't been replied to yet.
• Everything else.

It's the first list that makes me happiest. At last, I have a list of reviews that I can churn through, knowing that I'm doing the right thing, not having to figure what state it's in or make decisions about how important it is. I simply do.

The second list is pretty awesome too. If ever I'm between branches or have a few minutes to spare during a lengthy test run, I have an already-prepared list of ways to make other people happy. That's the kind of software I like.

And, well, actually, I like the third list too. It's great to be able to look at the things you are blocked on and see who you need to hassle. The "Waiting For" pattern comes from GTD, and is one of the best things about the system and deserves wider notoriety.


(Oh, and just wait for the release announcement!)

Server reinstalled

Now running a beautiful instance of Ubuntu 8.04 LTS. Different passwords, no PHP, no Wordpress.

One bird, two stones

Glyph thinks that interfaces are great, and he is right (although I haven't read the full post, I certainly agree with the title).

One of the natural things you can do with interfaces is this: make a new class Bar that delegates all of the properties of IFoo to an instance of class Foo. This is the Decorator pattern (not to be confused with Python's decorator syntax), and is also the Bird in this parable.

We use interfaces a lot in Launchpad, and we need to Decorate classes quite a bit. So, we wrote something to make it easy and open sourced it. It's called lazr.delegates. This is Stone One, if you like.

Stone Two was actually cast first, and is called twisted.python.components.proxyForInterface. It's distributed as a part of Twisted, and solves exactly the same problem. For those interested, here's the Twisted implementation (scroll to line 320ish) and here's the lazr implementation.

Both implementations are fairly simple, and yet it is perhaps a shame that there are two of them. If anyone is at fault, it's me, since I knew about proxyForInterface and watched lazr.delegate arrive in the Launchpad tree without even thinking that the two might actually be the same thing.

But I wonder, is there a process bug here? Is there something Launchpad, Twisted, Zope or Guido could have done to avoid this?

Scheduled Unreliability

This blog will be available on and off this weekend as I upgrade the server it's on.

Neat trick

In Argentina I hacked up a little command for the 'launchpad' Bazaar plugin. It's a command line tool to open the Launchpad page for your branch in your web browser.

  $ cd ~/src/testresources/expose-reset-bug-271619
 $ bzr lp-open
 Opening https://code.edge.launchpad.net/~jml/testresources/expose-reset-bug-271619 in web browser

... and it works!

Available in Bazaar 1.12. Due to an unfortunate oversight, the NEWS file doesn't mention it.

Things every project needs

I'm reviewing my checklists right now. I just came across one that I'd like some help with. It's called "Things every project needs", and it currently has this:

• TODO system (e.g. specs, trackers, text file, bzr difftodo)
• Version control
• List of dependencies
• One step build
• One step build-and-run-tests
• One step build-and-run
  
• One step build-docs (API, testdoc, general docs, sphinx)
  
• Version information
• License
  

I hope you see the sort of thing I mean. I mean things you have to do (or at least think about) when starting any software project.

Can you think of anything to add?

Everything I ever learned about programming...

... I learned from Twisted.[1]

Which reminds me, one of the Twisted guns is up for hire. His name is Itamar Shtull-Trauring and he is very smart, wrote some of the best bits in Twisted and loses gracefully at Munchkin.

If you want someone in to review your system, help you design out a network protocol or provide a thoughtful, independent perspective for your new application's architecture, you should hire him. Itamar's got bad RSI, so he can't type much, otherwise I'd be trying to poach him.

Note: Itamar still works for ITA Software, so it's only short-term contracting.


[1] Well, SICP gets a guernsey too.

Better Cloud

The Launchpad Code home page is now a little bit nicer and a little bit faster.

For a while now, the page has had a tag cloud showing some projects that host branches on Launchpad. The tag cloud is drawn based on the following rules:

• The more branches, the bigger the tag
• The more recent the last commit, the less faded the tag
  
• If Launchpad is the place to go for getting the project's code, colour it green. Otherwise, blue.
  

Up until recently, the home page only showed some projects starting with 'A' -- which is a bit silly. My recent patch changed the query to show the most branch-y projects on Launchpad. It looks a lot nicer, IMO.

Martin Albisetti has asked me to change the colours though. Expect an update soon.

Make your code testable

A lot of people struggle with writing unit tests. They sit down with the noblest of intentions, ready to turn themselves around and be good little engineers, but then somehow, suddenly, everything goes horribly wrong.

It turns out that it's really hard to write unit tests. When we first discover this, we generally consider two options:

1. Give up
2. Work hard to write the damn test

There is actually a third way: make the code easier to test. Many of the barriers to testing are built from the design of one's own code. Globals, hard-wired access to resources, poorly parametrized behaviour and badly encapsulated data can make it a nightmare to test things.

The cool thing is, if you do this, your code base will actually be more fun and more productive to work with. Your application will start to look like a set of libraries that build high-level concepts, rather than like a maze of twisty passages. This is actually why the Bazaar API is so amazingly good -- they've written their code to make it easy to test.

Thanks to Cory Dodt for the idea for this post.

Bazaar commands

While in Argentina, I got around to doing something that I've wanted to do for ages: refactor Bazaar's "serve" command. It's been bugging me for a while, since we actually duplicate some of that code in Launchpad, and we keep getting bitten by changes to cmd_serve. There's also another, deeper reason why I wanted to do it.

Bazaar isn't just a version control system, it's also a very good version control library. It's very easy to figure out, use and test. I'm almost tempted to say "beautiful". In any case, if you're writing a Python library, you should probably copy bzrlib.

Except for bzrlib/builtins.py, which is where all of the built-in commands like "serve" live. For one reason or another, it's full of massive run() methods. Many of these methods contain logic that plugin authors end up copying and pasting — blech. Hence, refactoring cmd_serve.

If you are keen to learn how a version control system works, you could do a lot worse than dive into bzrlib/builtins.py, figure out what a particular command is doing, then refactor that command so the code speaks for itself. There are 64 commands in core Bazaar: get cracking!

Having said that, let me say this...

Seth Godin recently blogged the second-most useful piece of advice that technical presenters need to hear.

Launchpad and Bazaar in South America

Just got back to Australia after a couple of weeks in Brazil and Argentina.

Three big things:

1. This year, we are going to rock hard on Bazaar.
2. We are finally looking seriously at improving Launchpad's performance across the site.
3. The Code team has a lot to do, and not much time to do it.

More later.