A few weeks into April? It must be time for the March film fight…

Watchmen is a film that I was generally quite excited about, given that it’s based on a stunningly brilliant graphic novel whose every panel oozes detail and links together so well that it warrants many, many reads. By all accounts, this was to be a (mostly) faithful adaptation; and that’s the problem. It starts off well, going over the death of the Comedian and his funeral, re-enacting what he meant to the other characters, but it takes its time about it. Having covered maybe two issues of the comic, there was no way that the remaining ten could fit intact. That, by itself, is fine. I’m all for properly adapting material, but this was not a proper adaptation. It would seem the writers picked out all the “must-have” scenes from the novel, the stuff fans would want to see, and cut lots between them. When the path through to those scenes has been so heavily cut-back, it starts to not make much sense and feel rather rushed. I’d have rather have seen far more cut out and for the film to be coherent and solid, rather than a quick bout of fan-pleasing moments flung together. I could go on at some length about how some of the characters were badly neutered (Laurie), some of the visuals were cheap and plasticky, and the story was left a pretty flimsy mess (and let’s not go into the crappy ending), but it’s not worth it. Wait to see how the extended version comes out (fingers crossed it has the extra material the film so badly needs) or, better yet, just read the graphic novel. (See my Watchmen Twitter review).

Next is the lovable but largely forgettable Marley & Me. It’s ostensibly about a journalist (played by Owen Wilson) who buys a badly trained dog for his girlfriend, but is really more about the relationship and hardships they endure, with the dog as a lens into that. It doesn’t have a huge amount to say, and is basically light Hollywood fun. That’s not a criticism, but don’t go in expecting anything more meaty. Enjoyable, yet flimsy. (See my Marley & Me Twitter review).

You’d expect Bronson, the story of Britain’s most violent inmate, to be a straight forward if unusually brutal biopic. It’s not. Instead we get a nightmarish, carnival atmosphere, with the title character himself as our ring leader, taking us on a bizarre and twisted journey through his life in an attempt to get fame for the only thing he knows he’s good at: brutality. Tom Hardy puts in the performance of a lifetime, as the film evokes an atmosphere of slightly-off darkness that hasn’t been seen since A Clockwork Orange. It’s brutal, ugly, a little funny, and very entertaining. A fantastic movie. (See my Bronson Twitter Review).

Finally, Gran Torino is a lazy and largely dull story about an old man coming to terms with changes in his neighbourhood, and finally befriending the immigrants who he has despised for so long. Clint Eastwood is the only person who puts in a half-way decent performance, and even that is stifled by the over the top racism he shows. Subtly, you see, is something this film lacks. Rather than tell you a story and let you judge the characters, everyone seems intent on telling you exactly what they’re feeling so that they don’t have to act it or buy too much into their ridiculously one-dimensional characterisations. About as subtle as a pink brick to the face in every aspect. Even if you can somehow swallow being spoon fed, there’s very little here to make it worth while. Avoid.

That makes Bronson the deserved winner for March.

A few months ago, I came across the term Technical Debt to describe a situation that I’ve long been familiar with: you have some code to write and you can either do it the messy but fast way, or the neat but laboured way. One usually means just hacking in a quick solution, and the other usually means careful refactoring to set-up the abstractions you’re writing to their fullest. If you decide to do it the fast way then it’s likely, even if it’s not obvious today, that you will have to maintain it a later date (no code is an island, the real cost is in maintenance etc). Thus you have a technical debt that you will have to repay at some point; whether in the form of rewriting the code to the proper way, or hacking further around it. You pay back technical debt by paying time on the principal (fixing the original issue) and paying time on the interest (having to work around something that isn’t as neat as it could be).

You can take this metaphor quite far (continued hacking eventually causes bankruptcy, for example) but I’ll leave it at that for the moment.

In the past, I’ve worked on projects where technical debt was carefully managed. On those projects, code was easy to write and maintain, and performance tended to be very high; largely because everyone understood the entirety of the code base and always knew how their decisions affected the system as a whole. This was pleasant, but required stringent regulation.

I’ve also worked on a project where massive technical debt was accrued and project management insisted on every fix being the fastest one possible, regardless of the long term consequences (I hasten to add I was largely opposed to this, but at some point you just have to get on with things). By the end, doing anything took far longer than it should have and performance began to tank. Working around the debt and managing time began to be the only thing possible, and paying off the principal never happened because there wasn’t any time left. That’s a bad situation to be in.

All of that said, if you know what you are building is a one-off or infrequently used piece of code that is needed sooner rather than later, taking on some technical debt can be the most frugal thing you can do. Rather than work on figuring out the neatest abstraction, or the nicest algorithms, just get the code working quickly and move on.

Now, I’m not saying that this is how you justify doing things the wrong way. There are rules you must adhere to in order to manage your debt.

1. Only take on technical debt on one-off or seldomly accessed code.
2. As soon as indebted code becomes used or maintained more frequently, and it inevitably will, you must endeavour to pay off the debt as soon as possible; before moving onto new code.
3. If you’re not sure whether or not you can take on debt in a given situation, you can’t. Write it properly and forget about it.
4. Never, ever, sacrifice documentation. If anyone is to have any hope of understanding your code (even the really good stuff), they’re going to need documentation. You cannot put your documentation into debt and hope someone else can pick it up easily.

Remember: all debt needs to get paid, or the whole thing can come crashing down.

I’ve been wanting to redesign Solitude for quite some time now but I figured since my post rate has dropped to a few month in recent times that I should concentrate on getting the post rate back up first.

That said, I had always been picking apart other designs and storing away my favourite snippets; the odd comment layout, a neat footer section, some interesting navigation etc. From that, and a few things I had done in my previous job with grid layouts, I had a pretty good idea how I wanted the new design to look. I wanted it to be relatively minimalist, with clean lines and an orderly and obvious grid layout.

I noticed two different websites, about 2 months apart, that had a lot of the features that I wanted, and noticed that they were oddly similar. A little investigation turned up that they were both using variants on a pre-built WordPress theme called Tarski. It was then that I decided that I’d be better off taking that theme too, and tuning it over time to fully achieve the effect I wanted. It was already 90% of the way there.

I consider the design to be a work in progress, though it’s perfectly serviceable as-is and will only be worked on slowly. Let me know if you have any suggestions for it. The first thing to go will be the header, as I’ve long had a particular image in mind for this.

Fun facts:

• This is my first redesign (beyond seasonal variants) since September 2004 when I introduced the previous design, Hazy Morning.
• Hazy Morning had that big “flower” in the top right, as some people pointed out? It was actually a heavy processed and sharpened picture of the sun.
• The header image I have in mind for the new theme I created in 2006. I just didn’t come up with what I wanted for the rest of the design until now.

You’ll be seeing the finishing touches sooner or later.

It’s February and the film fight is already a few weeks late. This does not bode well, but let’s see how it goes anyway.

Revolutionary Road is a difficult to watch, and delightfully so. The film centers on a failing relationship between a couple whose dreams are further away than they can stomach to reach, causing resentment and tension. It’s that tension that brings this film to life; the arguing, and picking, and ugliness of a once beautiful marriage worn down to a tiredness. It’s well-acted and lovingly shot, forcing us to watch some uncomfortable situations. The only place it really falls down is in the ending, where a cut a few minutes earlier could have avoided some unnecessarily tying up of loose ends. A great film. (See my Revolutionary Road Twitter review).

It’s a shame to see a great idea hampered by a some pretty clunky writing, but that’s what Doubt happens in doubt. The plot revolves around a priest who is accused of being indecent with a young boy in his care, and the nun who condemns him without any great degree of evidence. The story isn’t so much about innocence and guilt, as much as it’s about a witch hunt; a feeling that something is wrong being enough to make them wrong. The leads, again, provide strong performances, but they’re let down by some pretty weak writing. The wind as a metaphor for change? I can’t think of anything more trite. This is a good film, but with some pretty noticeable flaws. (See my Doubt Twitter review).

I like a good yarn, and that’s exactly what we get with The Curious Case of Benjamin Button. Every facet of the story, a tale of a man being born old and growing backwards, is larger than life and simple; much like Tim Burton’s Big Fish, but a touch less magical (save the central conceit). Sure, it’s not very deep, and some of it doesn’t really make sense, but it’s a fun story and told well enough that it doesn’t really matter. It looks the part, and is worth seeing, even if just to gawk at the fact that the lead’s head is entirely digital. (See my Curious Case of Benjamin Button Twitter review).

You’d like to believe that Anvil: The Story of Anvil is a mockumentary in the style of Spinal Tap for certain parts, but it isn’t. The band featured here, Anvil, never made it big in their youth but, unlike most bands, have never given up their dream. That’s what this documentary is about: the reality of never giving up on something you want more than anything else. It’s painful at times (you know exactly what a record label A&R guy means by “we’ll call you”, but the band are oblivious) and sometimes very earnest, but it’s enjoyable nonetheless. (See my Anvil Twitter review).

Finally, Vicky Cristina Barcelona is, well, a mess of a film. While Penelope Cruz shines through in the role that won her best supporting actress this year, the rest of the cast either fail to sell themselves or are simply unable to. Almost every major scene is undermind by a cold, flat narration that, rather than allow the actresses to emote and for the camera to capture the atmosphre, tells us frankly and plainly what every one is thinking and feeling. This is the worst kind of tell-don’t-show storytelling, and much of the movie comes across as self-indulgent yet empty. Avoid. (See my Vicky Cristina Barcelona Twitter review).

There are a few contenders this month but the winner is… Revolutionary Road. Kate Winslet and Leonardo DiCaprio are reunited in a winning combination.

As an aside, I also saw Winslet’s The Reader this month, but not at the cinema. It’s a great film, if a little long-winded in places; she puts in a solid performance, but the real depth lies with the main character.

I’m sure most people will have heard of it already but Spotify is probably the most interesting music service I’ve seen since the Napster days (the first version of Napster that is, not the current one).

You find an invite for it (there are plenty freely available just now), sign-up for free and you can then access a massive back catalogue of music to stream whenever you like. The streaming seems very reliable, and the selection is pretty good: this isn’t just small artists, all the major labels are represented. The cost? You either take it for free and listen to the occassional advert (all seem pretty unobtrusive so far), or pay £10 a month to stop the adverts.

It’s different from something like last.fm‘s streaming service, because you queue up a list of songs that you want to hear, rather than just starting somewhere and having new music pushed at you (which is not a bad thing in and of itself).

If Spotify is successful, then it’ll be a game-changer. I won’t be surprised if, within a few years, Spotify is the way to get music, just as YouTube is the way to get video and Google is the way to find information. You won’t buy new music when you want to hear that one song you’ve not heard in a while, you’ll Spotify it.

It’s fair to say I like it and I think it works incredibly, having tried it on Windows, Mac and on Linux (via WINE). It looks pretty slick across the board. It does, however, have some odd behaviour in places, which I’d like to detail.

The playback functionality is built around the idea of a “play queue”: a list that holds all the songs you’ve selected to play. When they’ve played, they leave the queue and appear in your history. That’s pretty straightforward, but the manner in which you add songs to the queue is, on occassion, counter-intuitive. This is going to take a little explanation.

There are two broad routes for finding music to add to the queue. You can either use a playlist (which, neatly, are shareable over the web), or you can use the fairly comprehensive search options. Once you’ve found the music you want with either route, you then have two actions you can take: play (the default action) and queue. The difference between the two, and how they interact with the two find methods causes some issues.

Problem #1: There are two different types of queue item. This is lengthy but keep with me, it’ll help you understand the rest. Let’s say you search for and find an album. You double-click the first track and start listening. As it finishes, Spotify automatically plays the next track as it has added the whole album to the play queue. Satisfied that it’ll keep going you make another selection and queue it i.e. not “play” it straight away as you want to hear all the items from the first album which, after all, you can see in your play queue. When the next song starts you might be surprised to learn that the next track to play is not the next track from the first album, it’s the first track from your second selection.

What happened? Well, it turns out Spotify has active and passive queue items. On any search, a play will actively queue the item you selected and passively queue everything else. The play queue is sorted so that passively queued items are always after actively queued items. Using the play action creates one active item and potentially many passive items. Using the queue action creates an active item for every item you have selected.

When you made your first album selection (using the play action), the first item was actively queued and the rest were passively queued. When you made your second selection (using the queue action), it jumped in front of all those other tracks. That’s pretty counter-intuitive, and is Problem #1.

You might think, “Ok, I understand that and can avoid it”. Well, slow down, there’s more.

Problem #2: You can’t play an entire selection. If you thought that the solution to the above problem was to select the entire first album and use the play action, you’d be mistaken. Although Spotify will let you make a selection and use the play action while on that selection, it really only plays one of the tracks i.e. it ignores the fact you have made a selection. You can make a selection, use the queue action, and then delete everything before it already in your play queue, but that’s a bit of a roundabout way of doing things. Better behaviour? Enable the play action to operate over a selection, or disable it when a selection has been made. Or, model intents by adding a “Queue album” action.

Problem #3: Queing passive queue items makes copies of them. So maybe you thought the solution is to use the play action on the first item, thus passively queueing the rest, going to the play queue and selecting queue on the remaining items? Well, that works. You’ll have the entire thing actively queued. The problem is that actively queuing something like that doesn’t remove the passive copy. As soon as the entire album finishes, you’ll probably be surprised to hear the second track onwards again. The passive items weren’t removed, they were just copied to the active part of the queue. Better behaviour? Making a passive item an active item (using the queue action) should jusy promote it, and not copy it.

Problem #4: Passive queue items can’t be removed easily. Maybe you thought the solution to problem #3 is to just remove the passive items from the queue, thus leaving one active copy. I’m afraid not. You cannot remove passively queued items, without wiping out your entire play queue. This is a massive cause of irritation. Better behaviour? Activate the delete option for all items, thus allowing the removal of passive items.

Problem #5: Search and passive queuing can interact too broadly. You’ve learned to jump through the hoops above and now know how to queue things properly. Good. Let’s say you want to hear one song, and do a search for it. The search results return 10 similarly titled tracks and the one you wanted. You play the one you wanted. Can you guess what happens? Those completely unrelated tracks by unrelated artists in unrelated genres all got passively queued and you’re now listening to them. Best of all, because of problem #4 you can’t remove them without wiping out your queue entirely. Better behaviour? Restrict the passive queueing of items such that only items from the same artist/album get passively queued when searching by artist or track. A special case here is when the track is from a compilation, where you might want to queue the whole thing.

Now, I know that comes across as negative, but let me reiterate that I really like Spotify (I’ve been listening to genre:britpop on it whilst writing this), and would just like to see some basic usability improvements.

Here’s hoping the service makes it.