Just A Summary

The ‘gizzajob’ post

In the unlikely event that you’ve been wondering where I’ve been this last while, I’ve been busy with one of those long dark teatime of the soul affairs, all the while baking bread. 

Right now, I’m seriously considering giving up programming and becoming an artisan baker making really good crusty bread in a woodfired oven. Or maybe an ‘event’ photographer – weddings, parties, open source conferences etc. 

Which is all very well, but it doesn’t really bring home anything that looks remotely like bacon. So, once the electrician’s finished in my office, I’m going to be getting my nose back to the Typo grindstone and demonstrating to myself and anyone else who’s interested in hiring a programmer that I can do sustained maintainance work. Things are looking good for Typo right now, Scott has recently squashed a nasty memory leak, sped things up nicely and has added a friendly installation system, which means 4.0 is amost ready to roll.

So, I need to get back up to speed on what’s changed and start hanging out on the channel and doing some support work. All the while looking for work. So, if you are looking for a reasonably experienced ruby programmer with Rails experience, backed up by nearly 10 years experience with dynamic object oriented programming, get in touch, I could well be your man.

Martin Fowler has posted an overview of the ways in which different projects can handle Code Ownership on his blog. As usual with Martin, it’s a thoughtful piece coming down strongly in favour of an agile solution (Martin argues persuasively that strong code ownership makes it much harder to improve the code – or make it worse, but let’s assume that we know what we’re doing).

Typo is open source. In theory it has collective code ownership, but looking at the patches that come in, it’s apparent that a lot of people still think in terms of strong code ownership. A typical typo patch tends to contain all its changes in a single class, even if that means writing a bunch of structural code – code that treats objects as if they were data structures – which is a code smell if ever there was one. Still, I’d rather have the patches than not, even if it means that the usual process of accepting one is to apply it and then refactor before committing anything.

So, don’t be afraid to submit Typo patches that alter multiple classes; the aim is to keep Typo as well factored as possible. Structural code tends to introduce unnecessary dependencies, and unnecessary dependencies make code brittle.

Once upon a time, when the world was young, Apple announced their 17 inch G4 Powerbook with a huge screen and blisteringly quick 1GHz G4 PowerPC processor.

“It must be mine!” I thought, and so it came to pass.

Product placement? At a wedding reception? Nah.

It was lovely. It was built to my scale. It was the best computer I had ever owned.

Of course, Apple kept rejigging it with faster processors and graphics cards and other goodies, but I never felt the upgrade itch; so what if there’s faster stuff out there, most of the stuff I do is still blocked on network latency and typing speed.

Then, a couple of weeks ago, I typed rake on a colleagues new 15 inch Macbook Pro and watched a Rails test suite go from 0 to all tests passing in what seemed like the blink of an eye.

“Right!” I thought, “When the 17 inch version gets launched, I’m going to get one.”

And then my contract came to an end, so now I’m not getting one. Yet.

I wish I’d not seen how quick the tests ran on that other machine. Now, when I run the Typo tests and it goes away for the best part of 3 minutes, I get cross. Before I just used it as thinking time.

If you’ve been following typo development on the trac you’ll have seen that I’ve been niggling away at the Typo sidebar system and I haven’t finished with it yet. The changes waiting in my current SVK repository are rather substantial so I’m going to give you a preview of them here.

Why mess with sidebars?

Well, in the past, developing a sidebar required you to sling a bunch of boilerplate code in with the code that actually did stuff, which violates the DRY principle in all sorts of horrible ways. Also, the boilerplate code we were using breaks with IE6.

Sidebars have two ‘sides’ (a little like Apple’s Dashboard widgets, but without the cool/annoying graphic effects when you switch between the config and content views). Most of the ugliness for the developer being found on the configuration side.

Some time ago, around the time of the Typo themes contest, someone, I think it may have been Scott Laird, wrote a nifty little sparklines textfilter.

It’s a really cunning piece of code, the problem is that, to make it work, Scott had to make some dramatic changes to the way textfilters work which, in turn, meant we had to change the way we got at the htmlized versions of our content. Before sparklines, you could do content.body_html in your view and it would just work, generating the html as required. After the change you had to do content.html(controller, :body), which I'm sure you'll agree is rather gruesome. So we wrapped it up in a helper method, letting you do: @article_html(article, :body)@, which is only slightly less gruesome.

At a stroke, we managed to break almost all of the themes entered in the contest, the eventual winner included. Ho hum.

To be honest, screwing up the winning theme’s almost beside the point, I’ve disliked the new interface for getting at html content ever since we introduced it, but I’ve liked cunning textfilters more, so we’ve bitten the bullet and accepted the fact that Typo 4.0 will have a different theme API from the last release.

Well… I say accepted. I’ve been looking for a way out of it in a desultory fashion ever since we introduced it. And today I cracked it. I knew – despite a few howls of protest – that introducing a Blog class was the right thing to do even if we never take the step to full multiblog capabiliity. Today, it paid off…

Rails 1.1 got released on Sunday.

Lots of hosting services upgraded.

Typo, both the ‘stable but old’ and the bleading edge versions, didn’t get on with Rails 1.1. For quite spectacular values of ‘not getting on’. So, we ran around like headless chickens for a bit, gradually refining the incantations needed to get your existing typo installation working again – rake freeze_edge VERSION=3303 does the trick if you’re still having problems – and then Scott, Kevin and I spent the best part of a day nailing down the issues.

It turns out that there was rather a lot of ‘cargo cult’ code in older versions of Typo. Cargo cult code is code that isn’t there because it works, but because it reassures the programmer into thinking it will work. Rails 1.0 was far more forgiving of our cargo cult (excessive use of require_dependency, an undocumented method that doesn’t quite do what we thought it did) than 1.1.

So, with that done, and a few more bugs squashed and we’re almost ready for a release (future distributions will come with rails baked into the tarball – but not if you get it from the repository), both of 2.6.0 with a frozen rails distribution and of the forthcoming 4.0.0. As I write their are two issues outstanding on the 4.0.0 milestone, the trickiest of which is Scott’s plan to make typo installation substantially less user hostile. However, if you’re happy to deal with the slightly tricksy installation, there’s never really been a better time to jump onto the Trunk. Grab a copy and start blogging. You know you want to.

I’ve been working on Typo this weekend, mostly going through open tickets and deciding whether to apply patches.

There’s plenty of potentially good patches in the queue, but too many of them give me The Fear.

They don’t have tests!

I’m the first to admit that I’ve added untested code to my projects (and I’ve been bitten by it too), but I’m more sanguine about that risk because, when it goes wrong, I can often rack my brains and pull back some memory of what my intent was. Knowing my intent helps me write meaningful tests and fix the issue. However, I can’t remember the intent of your code. The only thing I have to go on is what you wrote. If you’ve written tests, I can tell what you expect your code to do, which is far more important than being able to divine what your code actually does. Given a choice between code without tests and tests without code, I’ll take the tests every time.

So, if you’ve got a typo patch on the trac and you want it to get accepted, you must write tests for it. If you’re implementing something that’s supposed to be conforming to a standard, then please reference those standards in your tests.

Today has been humbling. I had made some changes to the Typo database schema with the goal of making the code easier to follow and because, dammit, it’s the Right Thing to do.

First, I updated the published flag, and everything went well.

Then, I decided to kill two birds with one stone, and update allow_pings and allow_comments at once. So, I copied the migration and simply called the method that I’d written to change a column type to boolean a couple of times in one migration. And it was fine.

On my, mysql based, setup.

But it was far from fine on Postgres based Typo installations.

S, I made some changes that involved ripping the body out of the method I wrote and sticking it inline in the body of the migration… There followed a comedy of errors of embarrassing proportions. I think I’m just about to apply the 4th or 5th patch to fix a problem caused by cutting and pasting code and then not making all the small changes required to make the code that worked in one place work in its new home.

I’ve done more damage thrashing around, trying to fix this issue than I did releasing the broken migration in the first place. At least the broken migration fell over in a recoverable way. Meanwhile, the version that I’m about to patch once Adam ‘My personal saviour’ Greenfield has tested it one more time and posted to the Typo trac simply and silently throws important data away.

Lesson learned: When you’ve done something stupid, it’s a very good idea to stop, think and test in case you do something even more stupid in an attempt to fix the first stupidity. Which I knew before. I just didn’t know it.

Have you ever bought hardware from Apple?

Lovely wasn’t it?

I don’t mean the kit was necessarily lovely — Apple have build their fair share of clunkers in the past. I’m talking about the experience of getting your iPod, PowerBook, PowerMac or whatever out of its box for the first time. It’s obvious that Apple have spent a good deal of time on making that out of box experience as satisfying as possible. A box that you will probably only use once seems to have had as much care lavished on it as the thing it contains.

Maybe Sony have got better at this sort of thing, but I remember when I bought a MiniDisc player a few years ago. Where my iPod came in a great looking box that opened in a satisfying way which made it easy to get at the goodies it contained, the MiniDisc came in just another box and was awkward to get at to boot.

I felt, and still feel, good about my iPod. I haven’t a clue where my MiniDisc Recorder has got to.

So, why is this post in the Typo category?

Well…

As I write, Typo Themes Contest is in that nervous interlude that comes between the last day for entries and the judges’ announcement of fabulous prizes (I haven’t totted up the value of the prize fund, but there’s a Powerbook and an iBook for first and second place) for the winners.

So, if you’re one of the entrants busily chewing your fingernails down to the quick as you anxiously await the news of your shiny new powerbook, I have a request:

Please take the time to write a post mortem of your experience of writing your theme. What was good? What wasn’t? What really pissed you off about Typo? What documentation did you wish was available?

When you’ve written it, post it somewhere and either comment or send a trackback ping to this message. I promise that I’ll read every such postmortem I hear about. Feedback on this stuff is important to making sure that Typo theme engine is easy to use and well documented in the future — I’m a coder not a designer; what’s intuitive to me isn’t necessarily intuitive to you and vice versa. And where interfaces are concerned, user expectation usually trumps developer expectation.