• "Tux dresses up sinatra in a shell. Use it to interact with your helpers, view rendering and your app’s response objects. Tux also gives you commands to view your app’s routes and settings." Handy – will definitely be using that in future.
  • "…let's not kid ourselves. If you sell a game that's a first-person shooter, then no matter how many RPG elements you shoe-horn into the game, the shadow that hangs over every character interaction that you have, no matter who they are, is the question in the player's mind of "What happens if I shoot this person?" And that's our own fault! We've sold the player that; we've made a contract with the player that says it's okay to kill people. Why would we then chastise them for exploring that?" Patrick Redding is brilliant. This interview, with Chris Remo on Gamasutra, is great – Remo asks some smart questions, and Redding gives some really smart answers.
  • "The game insists that I focus, even for mundane activities like carrying groceries, on carefully following directions delivered to me visually on-screen. The simple act of carrying groceries is subsumed by the mechanical procedure of executing a series of prompts _for no apparent reason_. This, for me, is the primary disconnect in Heavy Rain. My mechanical game-directed actions don't amplify or add meaning to the in-game behaviors they execute. They don't pull me in; they keep me out. " Hmn. I've been thinking about something similar recently. Time to fire up the blogpostmatron…
  • Lovely, lovely article explaining just how the PeepCode Blog works. The blog itself features unique layouts for every post. There's no CMS, no database, but what's going on under the hood is at least as clever – and the flexibility makes the beautiful and clear pages much easier to build.
  • "…for reasons that baffle me, my TV can only receive the four terrestrial channels, plus a grainy feed from the building’s security cameras. Easy choice."

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.