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

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.

Firefox 3 is awesome!

I have just returned from the shops with a Snickers bar. The packet says that one out of every six Snickers bars will instantly win me a free Snickers bar.

So, statistically speaking, how many Snickers bars do I have? Show working.

Ben Sussman-Collins writes about programmer insecurity and how a lot of programmers dread having others see their code.

Some of the best programmers I’ve worked with are in love with code reviews, and all great writers have editors. (The “linked list” is in no way exhaustive.) Personally, I see reviews as being a great opportunity to learn.

Sussman-Collins also writes about how distributed version control can exacerbate the “isolated genius” problem by shielding ones code from the public eye. This is definitely a big potential drawback of DVCS, but one that’s largely mitigated by a culture of short-lived branches and an easy-to-use public registry of all branches for a project.

I’m currently hacking away on Launchpad’s support for “stacked branches“, something that will really make Launchpad’s codehosting a joy to use.

At the moment, I’m writing some tests that require a user to login. This was becoming a bit cumbersome, until I remembered something: Tim has recently landed some code to make this easy. But how do I get these changes without messing up all of the work I’m doing now? bzr shelve to the rescue!

’shelve’ interactively goes through each change you’ve made to your current working tree and allows you to decide whether to keep a change or shelve it. It comes with a twin command ‘unshelve’, which lets you interactively restore your changes.

In this case, I don’t even care about the interactivity, so here’s what I did:

# Shelve my changes
bzr shelve --all
# Fetch the latest trunk
cd ../trunk
bzr pull
# Merge it into my branch
cd ../stacking
bzr merge ../trunk
bzr ci -m "Merge in changes from trunk to get login testing improvements."
# Restore my changes
bzr unshelve --all

The ’shelve’ command comes with the bzrtools plugin, and I am basically in love with it.

As a parting shot, I should mention that things like bzrtools aren’t accidents. They are natural and inevitable when you have good APIs in a high-level language and a very nice plugin system.

And now I’m off to keep working on this branch.

Inspired by Mikey, I’ve set up my own real-life blog.

I’ve done this one using Blogger’s “upload to remote server” feature. It looks nice, has the features I need and means less WordPress & PHP. I’m hoping to migrate this sucker to the same technology.

Ever find yourself working away on a branch, enjoying yourself and getting just a little carried away? Maybe you’re working on a feature and you notice and fix a bug that’s not strictly related to that feature.

If you catch yourself in time, there’s a nice little feature in Bazaar that can help with this: bzr merge --uncommitted. It will merge in the changes that you’ve made to your working tree but haven’t committed yet.

e.g.

$ cd some-feature-branch

... hack hack hack ... oops!

$ cd ..

$ bzr branch trunk bug-fix-2357

$ cd bug-fix-2357

$ bzr merge --uncommitted ../some-feature-branch

$ bzr ci -m "Fix up bug 2357. Found this while working on some-feature."

$ bzr send

Don’t know what bzr send does? Trust me, you want to find out.

z3p recently blogged about a comment I made in a code review. In the review, I linked to:

That’s a negative and grumpy way of phrasing an idea that I’ve come to value a lot: good code expresses its intent clearly.

When looking at a patch, the reviewer needs to understand two things: the intent of the code and the intent of each change to the code. To be clear on the former, you need:

• intent-revealing names.
• good abstractions / interfaces.
• good, small tests.
• simple implementations where possible.[1]
• docstrings where appropriate
• comments where appropriate.

That’s not exhaustive, but it’s in a rough order.

To be clear on the intent of your change to code, you need:

• Small patches.
• A good bug / spec with a good, short summary.
• A review request letter, summarizing your implementation strategy, any compromises you made, gaps in testing, future work etc.

That’s not exhaustive either. In #2037, I didn’t understand the motivation for lots of the code, nor for some of the changes to the code.

I’m indebted to Andrew Bennetts for teaching me that the first duty of a reviewer is to ensure that the code is clear and to Tom Berger for reminding me that compromises are worth noting.

—-

[1] Actually, this reminds me of something I heard a preacher say, “before I give a sermon, I go through it, find everything clever, and take it out” (I paraphrase, not having a reference on hand).

In as much as sermons and code should both be ego-free communications of ideas, I think this is sound advice for hackers.

The plugin I talked about in a previous post is now at https://launchpad.net/bzr-removable. Please file bugs.

Thanks to Michael Hudson and Daniel Watkins for submitting patches.

You can get the plugin by typing ‘bzr branch lp:bzr-removable’ on the command line.