husk.org. a website by Paul Mison.

I'm a bit late to this (it's a whole week and a half old), but a recent Stephen Fry Dork Talk column covered the Canon/Nikon camera rivalry, and more specifically, the Canon EOS 1000D. I've not really talked about it, but unlike a lot of the earlier commentators, I wanted to wait until it had found a street price, which it has: about £375.

So, what's the 1000D? Well, it's a new category (four digits, as opposed to the three-digit 350/400/450D, or the two-digit 30/40/50, or the single-digit (and expensive) 5D and the various 1Ds) of entry-level SLR. It comes with the same improved 18-55IS kit lens as the 450D (usually) does, and loses a few features compared to the model up (spot metering, for example) while saving about £100 off the price.

I'm sure it'll do very well, since the things that make me happy I've got a 450D (a replacement for a stolen 350D, although I'd have been tempted to upgrade anyway) rather than a 1000D won't occur to many people. (For example, the viewfinder's a lot better on the 450D, but no new SLR purchaser will even notice.) I'd also recommend it over Nikon's entry-level cameras, because it's compatible with all of Canon's EF lenses.

(Technically Nikon's backwards compatibility is better, since they never had the same sharp break for electronic kit as Canon, but the D40, D40x and D60 don't support autofocus on some lenses, and unfortunately the cheap-but-useful 50mm f/1.8 is one of them. Since I recommend this as something you want to buy either with your SLR or within a couple of months, this is a big deal.)

However, beyond the low end I'm increasingly minded to recommend Nikon. They have a much smoother progression in their range, whereas Canon have a vast chasm between the roughly £1000 50D and the well-over-£2000 5DmkII. (I'm assuming the 5D will vanish quickly; possibly not.) On the other side, the D90, D700, D300 and D3 are each much closer to each other in price (although it starts to get a bit rarefied towards the end). I have no idea what Canon's thinking is here, and of course there's more to an SLR system than bodies (there's lenses too), but even so, it's a bit strange.

Still, SLRs are more affordable than ever (especially if you look outside the big-two duopoly: Sony's entry-level Alphas are under £300 now, I believe), and so it's as good a time as ever to consider one.

Having finally got snaptrip out there, I'm hoping you'll allow me a little (pretentious?) waffle about why I wrote it, where it fits, how I made some of my decisions, and what's next.

I'm a big fan of Flickr's machine tags. Most of my images have at least ten - mostly generated automatically, like my EXIF machine tags - and I tend to add geographic metadata as well. As such, it's probably not a surprise that I'd write an application that made Dopplr trip IDs available. The big surprise is that I bothered to make it accessible to most people, by building it as a website not a script.

Why a website? Well, I thought I'd like a nice interface as much as anyone, and I also know that to make a machine tag truly useful you need as many people as possible using it. Asking folk to download a script, get a key, and use a command-line interface - or no interface at all - isn't going to work.

Speaking of Dopplr, I don't think I've seen a talk by anyone there since it started, but I do think I've picked up their philosphy from slides and abstracts online. The phrase that tends to crop up is a "coral reef", the idea being there's a web of data that's available on the internet and that by doing one thing, and doing it well - the old Unix philosophy, really - that you can live in a happy niche. Well, snaptrip lives on part of the coral built by the two companies whose API it consumes.

I'm not under any illusions: it's likely that most users won't care about their past trips, or matching their Flickr photos. Those who do will probably only visit the site once, tag a few trips, and then leave. That's fine.

In my previous post I alluded to some decisions I made about the geotagging features in snaptrip. To be honest, it wasn't something I'd considered at first, but seeing Richard Crowley's Dopplroadr hack - which does some of the same things as snaptrip, but when they're uploaded rather than by looking for existing Flickr photos - made me consider the possibility. However, because I am looking at things that have probably accumulated metadata already, snaptrip is careful not to overwrite any information that's already there.

snaptrip adds fewer tags than Dopploadr. It won't add human-readable tags at all, and it adds the geographical data at a relatively low level of accuracy. I didn't want snaptrip to assert with precision that all these photos were taken dead in the centre of Copenhagen, since they probably weren't. My US trips show exactly the sort of thing I'm talking about: most of my pictures are actually taken anything from ten to two hundred miles from where Dopplr thinks I was staying. Similarly, it doesn't set a woe:id machine tag, instead preferring to use the dopplr:woeid namespace/predicate pair.

It's quite possible I'm overdoing the paranoia here, and so I'll probably add the option to set more tags later, but for now, I'm happy to tread lightly. (In that vein, snaptrip doesn't set a visible "snaptrip" tag, like many apps (Shozu and AirMe spring to mind; Picnic also suggests adding its tag). However, it does set a dopplr:tagged=snaptrip machine tag, and I should probably make that optional also. For now, you can use Flickr's tag tools to delete it.)

So, what's next? Well, the basic functionality I wanted seems to be there and stable, so I'm now considering two further avenues. I'm trying to develop tools to give you some views on the aggregated data from your past trips, but perhaps I should instead be looking at tools to increase the amount of stuff in that Dopplr history. I've got a couple of ideas...

I'd hoped to do a lot to snaptrip over the weekend, and I pretty much managed to do what I hoped for. There's a lot of changes which went live today; a lot of them are kind of invisible, but hopefully they're all useful.

Firstly, there's some user interface changes that incorporate suggestions from people within Dopplr. You now have to authenticate with both Dopplr and Flickr before logging in; it was possible to use snaptrip with just the one, but it didn't really make a lot of sense. When you tag photos, they get a border in the city's colour (as they do if they've already been tagged). I've also removed the requirement to load all the photos before tagging them; you now get to do so in batches of 24.

Secondly, the behind the scenes changes. Google App Engine makes it really easy to use memcache to avoid loading data more than once, so I now use that, making reloading pages really quick. There's much better error detection, especially for when a network call to either of the services it relies on fails. I've also fixed the sort ordering in the statistics panel on the trip list page.

show-dopplr-link

Thirdly, I've added a lot more functionality to make use of the location information on both sides. Your map now shows Flickr photos*, and it's a "slippy map", so you can zoom in and out and recenter it. (It also shows the departure point.) It's also possible to use the Dopplr information about trips to add photos to Flickr's map. I should probably make it clear here that snaptrip will never overwrite location data (or trip data) that you've added yourself.

Finally, I had a comment on a previous post asking why you couldn't see trip tags on Flickr. Assuming that snaptrip worked, then the machine tags it's added aren't even shown by default- you have to open the disclosure triangle in the right hand pane. However, if you're using Firefox and Greasemonkey, you can install the show-dopplr-links user script, which will display a badge and link - like those for Upcoming - on each photo page.

Hopefully this isn't the end- there are still features I want to add, and the usage of the app when DopplrHQ first publicised it was a pleasant surprise. I hope these fixes and additions make it useful for you, though.

* Usually. There's a philosophical point I hope to expand on in another post.

Just a quick note to say thanks to all of you who've been using snaptrip today, since it was mentioned on DopplrHQ's Twitter stream. As it says in the questions and answers on the front page, I'm still poking at lots of bits of functionality, and you may see the odd error when I haven't properly caught one of the web services I use failing to send back some text. Despite all that, I can see that the app's been fairly popular, and hopefully it's been useful.

However, I've just spent an evening tightening up some of the text, and also working on how to show that an image already has either Dopplr trip tags or location data. (You've probably noticed there's a link that doesn't work- I didn't expect to be releasing quite so soon- but it might give you a clue as to what's coming next.) I'll try and keep posting fairly regularly, but for now, thanks again.

I've finally got to the point where I'm happy to really start posting about snaptrip.

snaptrip is a little web project that lets you use Dopplr and Flickr together. Initially, it allows you to put machine tags - specially formatted bits of data - on your Flickr photos. Why bother? Well, Dopplr itself uses this data, if available, to show you photos on its site.

Obviously that's a bit dull, and I do have further plans going forward, but because I've been stopping quite often to polish the app as I was building it, it's been a bit slower than I'd like. (I've also been using it to learn about both Python and Google App Engine - the appspot.com gives that bit away).

Anyway, once I've sorted out a couple of little niggles, I'll probably post more about this elsewhere, but for now, if you have a Dopplr account, feel free to try it.

As you can probably tell from my previous post, Apple's iPod event has meant this evening has devolved into kicking the tyres of the latest release of iTunes. As usual, there are shiny new features. Unfortunately, as usual, there's also a problem with me testing them.

Most of my music is on an external hard drive, and usually that's shared through the house from either a Linux box. I also tend to install things like iTunes on a machine where I use it less, in case I want to back out the upgrade (as I feared I might before I started grepping strings for defaults hacks). Combining these means I rarely get to look at features on a local library, but instead use the iTunes shared library facility. Tonight, that's worked out fine for some of the new features, like the bundling of Magnetosphere (which is lovely to see).

However, it's utterly failed me on three of the others. Genius playlists and store recommendations are completely disabled for shared libraries. I can see why playlists might have to be lost - should the recommendations be drawn from the local or the remote machine? - but the store stuff? Surely that's doable too? Even more annoyingly, Apple still don't allow you to use any album artwork features (grid view, or the reworked album view (check out View > Show Artwork Column) remotely except for the artwork of the currently playing track.

As Tom Insam notes, this is particularly galling because Apple's iPod touch / iPhone Remote does show album cover thumbnails, at least, showing that somewhere in the guts of one of Apple's remote music protocols (and I suspect there is actually only one) the ability to work with artwork is there. However, I'm not holding my breath. Apple don't seem to care about the fact that iTunes supports a genuinely useful method of sharing music, and so it'll quietly wither as the user experience for a shared library continues to pale next to that of locally stored music.

Another September, another iTunes release. This doesn't really feel like one that entirely requires a major version, but with the last release already up to point seven, I suppose it's not a big shock.

The preferences window has seen a bit of an overhaul, which is probably a good thing, as it was getting horribly unwieldy. (I'm hoping that Sven-S. Porst will provide his usual exhaustive review in a day or three.) However, it's also lost one of my pet choices, namely the ability to switch off the genre browser. (That's the thing that comes up when you hit Command B. Once upon a time, it even had a button in the toolbar, but that's years ago now.)

Thankfully, there's still a hidden preference. Just open a new Terminal window and type the following:

defaults write com.apple.itunes show-genre-when-browsing  -bool FALSE

Lo and behold, your browser window is usefully wide again, and those nonsense genres are banished from your sight.

Today was the annual dConstruct conference. Instead of being at the afterparty, I'm in Suffolk. Why?

Let's step back first. I attended Interesting earlier this year, and it was a wonderfully organised single-track conference - personally I enjoyed pretty much every talk of the day, so it wasn't a hardship at all to sit through them. However, because everyone was in their seats for much of the scheduled six and a half hours, there wasn't much room for a social aspect. Sure, there was lunch, and a post-event pub, but the former is only so long and the latter was so full that it inevitably splintered. (It's also easy to get sat with a group and not mingle when you're at a pub.)

In contrast, I wasn't able to make it to OpenTech, but I know it had multiple tracks, and this constant turnover makes it easier to meet other people, but it also makes it more acceptable to ignore the speakers altogether and instead socialise. (Indeed, if I understood Twitter right, there was a fair bit of that going on.) However, the presence of an event also makes it much more likely that you'll see a mix of folk, as they wander in and out of talks.

This is hardly a new observation - indeed, the phenomenon of the "corridor track" is commonplace enough to have a name - but the point when it comes to dConstruct is that I'd rather avoid single-track conferences, because they don't easily enable that socialising. I accept that partly this is due to me - I'm very much a developer, and found the 2007 programme of talks a bit too design-led (apparently 2006 was the year I should have attended) - yet I also think it's a handy rule of thumb, if you're lucky enough to have a choice in such matters, that the social side of such a conference will be lacking. Meanwhile, I accept that dConstruct's pre- and post-event parties do help, but for me, they're not enough - especially if you come down on the day and leave early in the evening. The upshot is that I'll try and attend events elsewhere.

(I was inspired to write up what's been a common real-life rant by a tweet from Phil Gyford, who asked "Are there any conferences that don't have talks?". I suppose one could mention the BarCamp format, but, informal as they are, they do still have talks.)

One of the reasons I bought an iPod touch in November, as opposed to a cheaper, vaster iPod classic that I could use to store all of my music, was that it held out the promise of being an interesting device to fit into Apple's slowly-expanding range of devices that hang off iTunes. I don't just mean in the obvious "iTunes organises your music" sense, either, but by using iTunes library sharing and the music streaming that the AirPort Express enables.

It took months, and the release of the App Store, but one of Apple's two apps - and the only one that's free - is Remote. As Apple put it,

With Remote, you can control the music on your computer or Apple TV from your iPod touch or iPhone. Play, pause, skip, shuffle. See your songs, playlists, and album art on your iPod touch or iPhone as if you were right in front of your computer.

Better writers than me have outlined some of the ways that Remote actually improves on the user interface of "Mobile iTunes", the native interface to the music stored on an iPod touch. (In short, it provides much more contextual information within the space provided.) However, I used it and saw three things that it could do, but doesn't, although I readily admit each might have issues that stand in the way of an implementation.

No Cover Flow

Mobile iTunes uses the iPod's orientation sensor to swap from a list view to the Cover Flow view, which lets you see lots of artwork and scroll through it. Remote doesn't do anything with the orientation sensor at all, and certainly doesn't use full-size artwork.

There are two explanations I can think of. The trivial is that Cover Flow might be getting out of favour in Cupertino, just like metal windows did before it. The more sensible is that the demands on a network - even a wireless network - of downloading all the images are too high. Heck, even when copying from the "disk", my iPod can't refresh the entire list at once. Nonetheless, a man can dream, and it would be nice if the app had some sort of horizontal mode.

No streaming

In an ideal world, I'd have speakers in every room, connected to an AirPort Express, and I'd be able to wander around the house with the same music playing out of every speaker. (Actually, ideally, something would know where I was and switch the speakers on and off as required, but let's stick with what we have, shall we?) However, I can't afford that many wireless routers, so instead I'd be quite happy to wear the iPod and listen to it instead. Apple don't let you do that, despite the fact that's how shared iTunes libraries work.

There is, once again, a possible technical reason for this. The iPod might not be up to decoding all the different formats in your iTunes library; in particular, Apple Lossless might be a problem. However, it can play local lossless files, and I can't see that shifting the data is that much harder. I'm hoping this shows up as an option in a new release.

Since I first thought about writing this, two things have happened. Firstly, the tech press noticed an Apple patent filing discussing the "Remote access of media items", which goes beyond the capabilities of shared libraries at present (as it mentions syncing metadata). Secondly, Simplify Media released their client for iPods with the 2.0 software. However, I'm unhappy about having to run a second application just to cater for the chance I'd like to stream. (Interestingly, a recent blog post notes issues with cover art and bandwidth, so there may be something to the technical issues after all.)

No shared libraries

This is the biggest problem for me personally, and it could be the easiest to fix. It's straightforward: there's no way to use Remote to connect to a shared library. There are reasons you'd want this: an office server that doesn't have music of its own, but instead which plays from lots of other people's machines, or perhaps a laptop which relies on an iMac as the source of a home's entire music. While you could argue that you should connect Remote to the server in the latter case, that's not going to work out if you're using mt-daapd, and it doesn't work in the first case either, since the music won't come out of the server's speakers.

This does of course raise a few issues with the user interface, but Steve Jobs employs some very smart people, and I'm sure there's a way to deal with it. So there's my wishlist for a future version. Shared libraries, streaming to the iPod, complete with a Cover Flow view. Sure, it's tricky, but then, don't fanboys always demand the near-impossible of Apple?

As every Londoner knows, all tube lines were not created equal. There's a definite ranking of the lines you'd like to have to use, and those you'd like to avoid. So here's my own, totally unscientific (yet, I hope, reasonable) list of lines in order of usefulness.

Victoria

This isn't just because it's my daily commute (although I must say, in the nine months since I've been using it regularly, it's been pretty much rock solid), but it's because it's reliable and frequent. It probably helps that it's a single line with no branches (the only exception being the slight thinning of trains north of Seven Sisters as they peel off to the depot). Other things that help are the fact it's a relatively new line - only forty years old - and that the stations are spaced relatively far apart, making end-to-end journeys remarkably quick. Let's hope the current engineering works and the new stock (in service from next year, and hopefully a bit more roomy inside) don't cause any problems.

Bakerloo

The Bakerloo feels remarkably like the Victoria's older sister, partly due to its similar rolling stock. (It's much older, as it happens - the line celebrated its centenary a couple of years ago). However, it's also a single line (avoiding all those pesky problems with points) and it's mainly sheltered underground, so it seems to me - and I'm an infrequent user - that it's near the top of the list.

Central

Another old line, the Central manages to be remarkably useful despite having a fork at one end and a rather complicated loop at the other. However, its stock is pretty cramped - the line has some of the smallest tubes n the network - and although I commuted on it happily for six months, it doesn't quite reach the heights of the previous two entrants.

Piccadilly

Another line with branches, the Piccadilly does especially well given its length, with long extensions to Heathrow and Uxbridge (although the latter is a bit unreliable, from what I've noticed). I'm one of those people who'll save a tenner by taking it rather than the Heathrow Express, for example, and when I lived in the western half of Islington it was a pretty safe way to get back from the West End. However, it is pretty slow through the centre, with stops that are arguably too close together (the classic being Covent Garden's proximity to Leicester Square, exacerbated by the former's reliance on slow lifts), which keep it down at the current ranking, as does its extensive overground sections - always a problem if there's sufficient heat, rain or snow.

Waterloo & City

On the grounds of reliability alone, I reckon the Waterloo and City would score highly. Unfortunately, it loses out rather severely on the utility front, since it connects just two stations, closes in the early evening and isn't open at all on Sundays. It's also got the most uneven flow of any line I can think of, being full northbound in the mornings, with the reverse in the evenings, as commuters from the south west head back to their mainline trains.

Jubilee

The Jubilee is the newest line, with older sections being younger than the Victoria. However, a botched attempt to move to sophisticated signalling during the construction of the extended section seems to have doomed it to unreliability, and it seems to have quite low train frequency. This all knocks it along way down the list, which is a shame, because I like the noise of the gate thyristors of the trains, and it really should be a showcase for the system.

East London Line

This is a rather special case, since it's closed for engineering works until 2010, when it vanishes - it'll become part of London Overground (which, in the interests of sanity, I've excluded from this list, along with the DLR). Certainly, the current replacement bus services would be bottom of the list, but before its closure, I found the line reliable and friendly. Its use of Metropolitan stock meant the trains were spacious, and while train frequency was a little low (there was only one every six minutes) I still think it comes in as a fairly useful line.

Metropolitan

A long subsurface line, and the oldest (incorporating the original 1863 route from Baker Street to Farringdon), the Metropolitan seems to do surprisingly well, given the amount of its track exposed to the elements and the complexity of its north-western end. However, it does have issues, both out in the suburbs and when it gets interleaved with the other lines, which mean that, despite the spacious interiors, the line ends up pretty low in the rankings.

District

Another long subsurface line, the District has its fair share of branches, but mainly it loses points not for junction delays or complexity, but because it's so slow. The stations it shares with the southern edge of the Circle line all feel far too close together, so it takes an age to get anywhere. However, as with the Metropolitan, large carriages help it out, so it's saved from bottom place.

Northern

Ah, the Misery Line. No wonder it's down here. But what's this? A look at TfL's performance data seem to show more trains in service than any other line, and not too many delays. So why does the Northern end up all the way down here? Well, its complex layout is mostly to blame, causing both low train frequency on either branch (especially if you need to pass one of the link points at Camden Town or Kennington), while also letting delays affect either branch, if they're bad enough. Coupled with that are the short rolling stock - only six carriages, compared with a more typical eight for tube stock - and somewhat cramped interiors. (One can only be thankful that London Underground abandoned their usual colour-coding inside the train: all-black handrails would have just been even more depressing.) It drops into the last place for the deep tubes.

Hammersmith & City, Circle

I'm going to list these as a single line, because they share rolling stock, and they also share some of the same problems. However, in case you were wondering, the Circle really is deliberately listed last. The problem with it is simply that, except for two points, the line doesn't really exist: it's shared with the Metropolitan and District lines, and, as the name makes clear, has no terminus. This also means that there's nowhere to go when the service gets disrupted, and the usual outcome is that these two get sacrificed for the others. TfL plan to unroll the line somewhat in the next few years, running from Hammersmith around the loop once and then back to Edgware Road, which should help, but even so, the low train frequency (you can wait ten minutes for a Circle line train) and relatively small carriages (for a subsurface line, anyway) put the line at the bottom of the list.

So, that's the list. I should note that, even though it's last, the Circle still manages a reliability of over 85% and the average customer delay is about 10 minutes. I'd certainly usually choose it over buses, taxis or (horrors) driving.

I'd love to hear from more regular users of any of these lines if they have any comments.