GMail feature request
July 1st, 2008First, 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
June 23rd, 2008Really Satisfying
June 13th, 2008I 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.
Aren’t code reviews great?
June 13th, 2008Ben 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.
Another Bazaar story
June 13th, 2008I’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.
Real Life
June 5th, 2008Inspired 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.
Neat Bazaar feature
June 2nd, 2008Ever 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.
What I meant
April 21st, 2008z3p 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.
bzr-removable
April 21st, 2008The 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.