Mere Code

I Love Data

2008-07-07T17:00:00.003+10:00

At work, we recently started to graph the time it takes to access a branch in Launchpad via SSH, both on our staging and production servers.

I love this so much. Having this data is liberating. It's like turning on a light in a dark room: suddenly I can go from uncertain, careful, hesitant steps to bold, confident strides.

In fact, the metaphor stretches further. This new light has revealed objects of interest (that is, spikes in the time taken) that I wasn't aware of before. I need to know how long these spikes last, how they correlate with load on the system and so forth. Soon there'll be more graphs, and I'll be able to correlate them and analyze them and suck on their delicious, numerical marrow (the light metaphor long abandoned).

Regardless of whether it's liberating illumination or nourishing, savoury meat, this new graph makes me wonder why I don't chart other things I care about. Having such graphs would help me see the impact of my actions. I could chart things like my bank balance, my waistline or the number of Latin words I learned this week. Then I could answer questions like "do I spend more on Tuesdays?" or "can I afford this iPod/cake/gerund?". This is important, because when I am tempted with a sleek/delicious/perplexing iPod/cake/gerund, I fall back on my own judgment. I think it's time to confess, dear reader, that my own judgment isn't very good. And yet I continue to trust it.

The reason I don't have such graphs is that they are inconvenient to maintain. A graph of branch access times is easy. All you need to do is describe how to get the measurement, and then do a bit of once-off set up. If you want to graph your body weight, you need to get on the scales at a fixed time and then look at the dial and adjust for parallax and then write a number down somewhere and maybe note down whether this is before or after a meal and then take the number and then add it to a spreadsheet. Most online banking sites I've seen are even less convenient than this.

Getting data on life is hard, but for programming it's easy. What things do you care about on your project? Features, user experience, how fast bugs get fixed? Can you quantify these things? Can you make a pretty picture out of it? If so, do it now! Post your answers here, set up something like Cricket and then profit!

P.S. I can't believe I got to the end of this post without saying how awesome the Canonical sysadmins are. Let me correct that now. The Canonical sysadmins are heck of awesome. They could simply walk into Mortor.

Somebody Do This Please

2008-07-03T16:17:00.004+10:00

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

GMail feature request

2008-07-01T09:09:00.000+10:00

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.

2008

2008-06-23T20:12:00.000+10:00

Firefox 3 is awesome!

Really Satisfying

2008-06-13T15:23:00.000+10:00

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.

Aren't code reviews great?

2008-06-13T14:37:00.000+10:00

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.

Another Bazaar story

2008-06-13T11:29:00.000+10:00

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.

Real Life

2008-06-05T11:17:00.000+10:00

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.

Neat Bazaar feature

2008-06-02T13:28:00.001+10:00

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.

What I meant

2008-04-21T11:39:00.000+10:00

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.

bzr-removable

2008-04-21T11:04:00.000+10:00

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.

OK I lied

2008-03-18T14:36:00.000+11:00

The next post is actually about a Bazaar plugin that I've now got ready to share. To get it, 'bzr branch lp:~jml/+junk/merged-branches'.

Once you've got it, run 'bzr merged-branches' in the trunk of your project. It will then show you all branches in sibling directories that are safe to delete. That is,

They have no uncommitted changes.

They have no "unknown" files. (Files outside of version control that haven't been explicitly ignored.)

They have no shelved changes. The plugin will only check for this if it can find bzrtools.

The branch is now at the point where it works for me, but it still belongs in '+junk' — here's why:

It assumes that you have a trunk branch in the same directory as all of your other branches.

It assumes that branches and working trees are the same thing.

It's called 'merged-branches' when it really means 'safe-to-delete'.

It doesn't make it easy to see why a branch is not safe to delete.

It doesn't let you customize the conditions of the search. Maybe you want to see all branches with uncommitted changes.

Still, if you are like me and make a lot of branches, it's quite useful. I'll tolerate bugs, accept patches and welcome encouragement.

User Experience — When Reality Attacks

2008-03-13T10:24:00.000+11:00

I've just got back from a hectic week in London, where members of the Bazaar community got together and thrashed out a bunch of important topics.

We talked about "user experience" and how we all want Bazaar to be a joy to use. More than one person said that we have been focusing too much on features and performance instead of user experience. The term was never really pinned down, but it's fair to say that there are things other than convenience and speed that affect how users feel while using Bazaar and that we need to work on those things, once we figure out what they are.

I think I might know the name of one of them: errors. Next post: "Notes on error".

Three-ways on Pidgin?

2008-02-18T10:04:00.000+11:00

Dear Lazyweb,

How do I initiate a three-way chat with Pidgin 2.2.1?

jml

What I do all day

2008-02-15T16:57:00.000+11:00

Kick-arse summary here: The great source code supermarket.

The Economist Index

2008-02-11T15:10:00.000+11:00

The Economist occasionally publishes a "Big Mac Index" — how much the world's favorite "burger" costs in each country, translated into a common currency.

Why they don't publish an index of how much an issue of the Economist costs? All of my issues have the price of the newspaper in lots of Asia-Pacific currencies. A small sample:

Australia, 9.39855 USD

Cambodia, 6.00 USD

China, 10.43655 USD

Hong Kong, 7.6917 USD

India, 5.0522 USD

Japan, 10.70535 USD

New Zealand, 8.6669 USD

Can anyone tell me why the price varies so much?

WoW account temporarily suspended

2007-12-10T12:43:00.000+11:00

Howdy Partners,

My World of Warcraft account is temporarily suspended for silly administrative reasons. I'm not in any rush to clear those up, so don't expect to see me on Khaz'goroth or Frostmourne any time soon.

Regards,

jml

Obligatory

2007-11-15T02:02:00.000+11:00

Not using Facebook anymore.

Have fun kids.

Fake Plastic Tests

2007-10-23T12:40:00.000+10:00

Ever wondered what's the difference between a FakeReactor, a StubReactor and a MockReactor? Find out in this brief article on test doubles.

The most retentive thing I've done

2007-10-16T18:15:00.000+10:00

Cracked Mac

2007-10-16T18:09:00.000+10:00

OK, I've started with this whole photography thing, I might as well run with it.

My Mac cracked:

Around like Grover

2007-10-16T18:06:00.000+10:00

What's up hep-cats?

I've been travelling around the world, weaving in and out of timezones like Jason Bourne navigates facial expressions. Last week's adventure took me to tropical Dunedin — the southiest outpost of Canonical Ltd. (I'm trying to get a mention on Language Log.)

Those few Hobartians who keep reading will notice that Dunedin, well, umm... here's a photo:

Pay careful attention to the hills in the background.

Five Years

2007-09-17T13:35:00.000+10:00

That's not quite how long it took Glyph to write a post explaining what he meant when he told me that xUnit should use the visitor pattern instead of the composite pattern.

I'm going to write a more detailed response later, God willing. I just wanted to flag the post and say thanks to Glyph for finally posting it — the hassling must have worked.

It's a Gibbon

2007-09-10T10:07:00.000+10:00

Over the weekend I upgraded my laptop to Ubuntu 7.10 aka "The Gutsy Gibbon".

Obvious improvements include having Pidgin installed and a much superior version of Deskbar. There's also a swanky new panel to actually control display settings (dual monitor and all that jazz). Unfortunately, I can't quite get it to work just yet. My 22" 1680x1058 LCD will just have to sit there, gathering dust :(

In another weirdness, all of my fonts are suddenly much, much bigger. I had to resize everything down to 8 or 9 to make them sane.

My pretty Emacs has also stopped working, but that's to be expected. It's a third-party package that hasn't yet been built for Gutsy.

Other than that, seems to be a fairly routine upgrade. Is there anything exciting that I've missed?

Merging New trunk Features to a Development Branch (redux)

2007-09-05T09:37:00.000+10:00

Oubiwann has recently posted about the joys of using Combinator to do branch-based development using Subversion. I thought it'd be fun to do the same post, except this time with Bazaar.

Background

You're working on a project called "Project", you have a copy of the mainline branch (i.e. 'trunk') in your src directory.


~$ cd ~/src/Project
~/src/Project$ ls
trunk

You want to implement a new feature, so you branch trunk to work on it:


~/src/Project$ bzr branch trunk viking-feature-836

Bazaar is a version control system, not a PYTHONPATH-managing system, so it doesn't maintain a global list of projects and the branches that are currently active for each project.

Perhaps your company focuses on historical invasions of Britain. You decide to start work on another feature:
lass objects.


~/src/Project$ bzr branch trunk norman-feature-1066

You multi-task for a bit, until you finish 'viking-feature'. You decide to merge 'viking-feature-836' into trunk.


~/src/Project$ cd trunk
~/src/Project/trunk$ bzr merge ../viking-feature-836
~/src/Project/trunk$ bzr ci

At this point, you begin to suspect that Bazaar treats branches as first-class objects. However, at this point, a developer on the obverse side of your continent calls you,

"Where's your viking feature? I need it to invade Britain!"

"I've just put it into trunk. Have you got the latest copy?"

"Yeah, I do, I just pulled from trunk."

"It's in trunk, you fool! ... Oh, wait, gimme a sec."


~/src/Project/trunk$ bzr push
Pushing to bzr+ssh://bzr.example.com/Project/trunk...
~/src/Project/trunk$

"Try now."

Merging

OK, enough background, let's merge.

Say you need some of the changes in trunk in order to finish work on your norman feature. No problems.


~/src/Project$ bzr merge trunk norman-feature-1066
~/src/Project$ bzr ci -m "Merge from trunk."

It's hard not to feel smug at this point.

Wait a second, you also want to look at the experimental branch that a friend is working on:


~/src/Project/norman-feature-1066$ bzr merge bzr+ssh://yourfriend.example.com/branches/sealion-1946
~/src/Project/norman-feature-1066$ bzr diff | less # better double check this one
~/src/Project/norman-feature-1066$ bzr revert # nope, doesn't seem like a good idea

Summary

Bazaar treats branches as first-class objects and treats trunk just like any other branch. Although Combinator is great for branch-based development in Subversion, it is more complex and less flexible than doing branch-based development in Bazaar.

With Combinator, you lose history when you merge in changes from trunk, with Bazaar you don't.

With Combinator, you can only merge in changes from trunk, with Bazaar you can merge from any branch.

With Combinator, merging from trunk leaves a bunch of changed files in the trunk checkout on your system (this has tripped me up more than once). With Bazaar, this doesn't happen.