You can now find out what Schulze – or anyone else, for that matter – is listening to (as described in this post) on the web; just head on over to http://wotlisten.heroku.com.

The utility of the original command-line script is now diluted even farther – mainly because you now have to go to the website to scrape the web – but that wasn’t really the point of putting wotlisten online; the point was to see just how easy deploying to Heroku really was.

The answer is: remarkably so. I wrapped the original script into a little Sinatra application, with two views, and a tiny bit of error handling for convenience. Sinatra’s something I’ve been playing with for a while now: it’s really excellent for wrapping small scripts into little webapps with the bare minimum of extra code, and when combined with lightweight tools like DataMapper, and sqlite, just powerful enough for the lightweight tinkering I seem to do so much of. If you’re a Ruby developer and you haven’t played around with Sinatra, you owe it to yourself to check it out – it’s a lovely library to have in the toolbox.

With the webapp written, I installed the heroku gem, which helped me create a new remote git branch pointing at my Heroku account. Deployment is trivial – far simpler than using something like Capistrano; all that is necessary is to push my master branch to the heroku remote, and upon a successful push, Heroku notices that I’ve pushed out a Rack application – and it directs requests to it automatically.

It took about ten minutes to write the Sinatra app, and another ten to get it up and running on Heroku; the single snag I ran into was the same as Tom did – the need to unpack haml into a vendor directory.

I’m very, very impressed. It’s all very well being able to build small, trivial toys like wotlisten, but it’s often a hassle to deploy or configure them. Heroku really takes most of that pain away, and makes setting a tiny Sinatra app live a trivial task. It’s definitely going into my toolbox – or, perhaps, that should be toybox – for the near future.

So we listen to music on speakers – not headphones – quite a bit in the studio. Or at least Jack does, because they’re in his batcave.

And sometimes, I’m not sure what’s playing from next door, but I know I like it – and it’d be good to know what it is. Fortunately, Jack mainly listens to last.fm radio (and even if it’s not radio, his iTunes would still be scrobbled).

So I wrote wotlisten.rb. You can see it (and get it) as a gist on github. It doesn’t use audio recognition, or the last.fm API, or RSS; it uses plain-old screen-scraping.

(Somewhere near the top of my list of coding tools is Hpricot, because it’s a lovely HTML parser that you can scrape with as fast as you can think. Or, at least, as fast as you can write selectors. That was the case here.)

So: you throw in a username, and wotlisten.rb tells you what they’re listening to. Or what they were last listening to. It doesn’t distinguish between the two – and why should it? This is Situated Software at its most useful: I assume you can hear the music that’s playing, and that you know the last.fm tag for the user playing it (and: until very recently, I assumed that person was Jack Schulze; this updated 2.0 release lets you pass in any username).

It’s unremarkable code in the extreme, but notable for the fact it took ten minutes to bang it out; it came out as fast as I could think it. I’m getting to the point where, especially with Hpricot and similar, this kind of tools is second-nature to write. It’s taken a long while to get there, though.

The script proved useful upon several occasions that day. More to the point, it paid for itself handsomely a few hours later, when we discovered that Schulze was playing Bonnie Tyler’s Holding Out For A Hero.