Mere Code

New GPG key

2009-07-13T11:53:00.001+10:00

I've published a new GPG key: 2048R/2A727997

Details available here: http://static.mumak.net/jml-key-transition-2009-07-13.txt

Angle on code review

2009-07-07T17:03:00.003+10:00

You're a core contributor to a Free Software project. Maybe you get paid to do it, maybe you don't. You get a patch from the outside: someone whose name you don't recognize has contributed a patch.

You could ignore this patch, since you've got a lot of work to do already. Better, you could review the patch and give the newbie some much needed feedback.

Alternatively, you could champion the change by making sure it gets the treatment that one of your own patches would. Review it or get it reviewed, help the newbie make the changes the reviewer wants, make sure it's managed using the best systems for managing patches in your project, keep track of its progress like you would one of your own patches, be eager to see it landed, pimp it in the changelog and the release announcement, get the newbie's name in lights.

In practical terms: if you use a DVCS, get the patch out of whatever email attachment its in and put it in a branch; if you use a code review system like Launchpad, get it out of the bug tracker and into the code review tool; if you have a test suite, empower the newbie to write tests (normally that means knowing where to put them and how to run them).

It's a matter of perspective: am I here to maintain the quality of the code base and prevent bugs from being introduced, or am I here to help others in my community. Am I just a reviewer or am I a champion?

Twisted huh?

2009-07-01T01:18:00.002+10:00

One of the hallway conversations I've had a few times so far at EuroPython goes like this:

A: Twisted's got some good stuff going for it, but I don't like the way it forces me to use Zope interfaces. It's too heavyweight?
B: Huh? What do you mean? It doesn't make you do that.
C: Yeah, there's lots of deep inheritance, which just feels really wrong.
A: Right, I have to write too much code to get something simple working.
B: Sorry, I have no idea what you mean. Can you give a concrete example?
A, C: I can't think of one right now.

To me, this is a very intriguing beginning to a real conversation. Do you know what A and C might mean here? I'd love to understand their points so that I can form an opinion.

Argh!

2009-06-25T16:47:00.001+10:00

I upgraded karmic, and now Do & Banshee are broken. :(

pyflakes now warns about unused local variables

2009-06-04T07:58:00.003+10:00

I finally got around to finishing my fix for Divmod bug #2718 -- Warn about unused variables in methods in pyflakes. Last night, the magnificent Jean-Paul Calderone reviewed and landed my patch. This means that if you are using pyflakes trunk (either from Subversion trunk or from the Launchpad Bazaar import), pyflakes will spot code like:

def foo(bar):
baz = bar + 2
return 12

and generate a warning like:

example.py:2: local variable 'baz' is assigned to but never used

I use pyflakes hooked up to flymake, so it's always running all the time on every Python file I'm working on. Relying on it has become as second-nature as relying on syntax highlighting. There's a whole class of mistakes I don't make any more, simply because it's on.

However, the main way it helps me is when I'm refactoring code. When extracting a function or changing a variable name, pyflakes acts like a sort of todo list for me. Now that it shows unused local variables, it's getting dangerously close to perfect.

To get pyflakes quickly, bzr branch lp:pyflakes.

(Edit: Grammar fix)

Landscape on Code Review

2009-05-25T17:12:00.003+10:00

The Landscape guys mentioned three things that I've missed in Your Code Sucks and I Hate You.

The important thing about code reviews is that they are a conversation. Emphasise this in your team's code review culture.
Don't speak to the person, speak to the code. "Why does the code do this?" rather than "Why did you do this?".
Remember that the person who wrote the patch is an expert in that patch.

From the Hands

2009-05-25T16:55:00.002+10:00

Just starting at UDS after a week at Canonical's Allhands event. Allhands was great, but one of the highlights for me was the Landscape team's presentation on their development process:

We optimize for fun. If something works really well in theory but it makes things less fun, then we don't do it.

Stealth feature

2009-04-09T08:54:00.003+10:00

Last release, Tim added a stealth feature to Launchpad. Since it's incomplete we didn't announce it on the official blog, but it's useful enough to share here.

If you browse to https://code.launchpad.net/~$USERNAME/$PROJECT, you'll get a list of all the branches in $PROJECT owned by $USERNAME, e.g. Chris's Gnome Do branches or Graham's Gwibber branches. I use this mostly to track my own branches in a project so I can make sure I haven't let any slip through the cracks.

We want to make it possible to get to these pages without URL hacking, of course. But if you use both Bazaar and Launchpad quite heavily then this trick is worth knowing about even as it is.

Truth (again)

2009-04-07T16:29:00.002+10:00

I originally posted this on my other blog. I saw it while digging up another post and thought I'd take it's advice.

Originally found on Presentation Zen.

Time-based releases and love

2009-04-01T09:12:00.004+11:00

I believe in time-based releases. I believe in frequent releases. I believe in a trunk branch that is always ready to be a release candidate. Many Free Software developers share my beliefs. For a long time I haven't questioned it. It's obviously good to release regularly and often.

"It is hard to argue that bzr isn't in a state of flux when a new stable version is available once a month." - Jason Earl, Bazaar mailing list.

Now I think I have to begin asking questions.

Is it possible that time-based releases actually create negative impressions of software? Should regular releasers slow down their cadence? How should compatibility watersheds (format, API, whatever) affect a release cycle? What would Bazaar's format reputation be like if they released every six months instead of every month?

Team +junk branches

2009-03-26T09:23:00.005+11:00

Very, very recently, we changed Launchpad to support team +junk branches. So recently, in fact, I don't think the change has hit the servers yet. Anyway, after the 2.2.3 release on April 1, you'll be able to push up & create branches in lp:~your-team-here/+junk/some-branch.

I have to confess I'm not a huge fan of this feature. Almost all of the time, if you've got some code in a branch and you want others to collaborate on it you should create a new project. That way you can file bugs, do code reviews and get easy branch stacking support.

Still, the use case that Jordan mentions is a good one, and the fix fell out naturally from some of the work we've done for source package branches, so we decided to do it. You see, we actually do get a kick out of making our users happy. Really.

I guess the moral of the story, if there is one at all, is to file bug reports. We don't want to build a website with separate bubble domes and three horns that all play "La Cucaracha" so we aren't going to mindlessly say "yes" to everything. But we do want to make something that will help you rock the Free Software world even harder, and to do that, we need to know what you want.

Trips me every time

2009-03-25T17:57:00.002+11:00

etrepum commented on how hash functions need to be idempotent. I pretty much always interpret things about functions and idempotence incorrectly.

When used in computing, saying a function is idempotent generally means you can call it a hozillion times and the state of the system (& thus the return value of the function) will be the same as if you called it once.

When used in mathematics, a function f is idempotent if f(f(x)) = f(x) for all x. The computing quality of idempotence isn't useful since f(x) = f(x).

I would greatly appreciate it if we could all find a way to communicate that didn't involve language.

brisbane-core

2009-03-23T09:29:00.002+11:00

Up in Brisbane, while I was diligently working away on package branches in Launchpad, many of the Bazaar guys were working on their new "brisbane-core" format.

I overheard one of them say in this new format 'log -v' is up to twenty times faster.

Want more details? Well, perhaps someone else on Planet Bazaar can provide them.

Firefox Smart Bookmark for Branches

2009-03-09T16:38:00.003+11:00

You might not know about Firefox smart bookmarks. They let you type something into your URL bar like "twisted 2345" and have Firefox load the Twisted bug page for bug #2345. Lifehacker explains how to create them.

Here's one to add for Launchpad branches:

Once you've added this, you can type 'lp twisted' or 'lp python' into your Firefox location bar and get redirected to the branch page for Firefox. Anything that works as part of an lp: URL will work here. Right now, this only works on edge.

Update: Firefox escapes any slashes you put into the URL bar, which makes this much less useful.

Fourteen Monthses

2009-02-27T16:01:00.002+11:00

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

2009-02-27T08:32:00.002+11:00

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

2009-02-25T12:51:00.000+11:00

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

2009-02-25T11:06:00.003+11:00

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

2009-02-24T17:16:00.000+11:00

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

2009-02-21T18:48:00.002+11:00

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

One bird, two stones

2009-02-21T14:47:00.003+11:00

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

2009-02-21T14:02:00.001+11:00

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

Neat trick

2009-02-21T11:08:00.003+11:00

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

2009-02-20T17:30:00.002+11:00

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...

2009-02-19T19:09:00.002+11:00

... 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.