Announcing Tweet Fighter
Firstly: allow me to bash the bible for a few lines. Over the past year or so I’ve become enamoured with Sinatra, the Ruby microframework. I’ve toyed with it, pushed it around, made it do things it didn’t want to do, locked it out in the cold and like a terminally happy pet, it still keeps coming back for more. Sinatra’s versatility is a product of its simplicity – it does its job well and the rest is up to you. Anyway, enough proselytising… on to Tweet Fighter.
Concept
You submit two Twitter users, who are then queried a handful of times through the Twitter API and a “fight” of sorts is created between the two users. They are attributed points based on various “fight”-worthy criteria: bad language; negative language (words like “kill” or “hate”, for instance); previous Tweet Fighter fight record; and – this being Twitter – number of followers and number of tweets to date. The (fuzzy) thinking behind this is that, along with the fighting talk, the mouthiest users with the most backup from their group would have an advantage in a fight situation.
It’s pretty silly, I know. I considered hacking away at some kind of worthy cause, but I’m a big kid. Maybe I’ll get around to creating a parking metre/carbon emissions cross-referencing Google Maps mashup one day when I’m older and crabbier. Hopefully nobody reading this will assume that I’m advocating random violence by making a fight-based application, but we’ll see.
I lifted the visuals from Street Fighter II, which was one of my favourite games as a kid (please don’t cease-and-desist me, Capcom. It’s a tribute). I seem to remember playing as Vega a lot, despite him not being very good.
Inside
As mentioned before, Tweet Fighter is written in Ruby, on Sinatra. My ORM buddy of choice right now is Sequel. I like the intuitive, chainable query syntax. As such, I was happy to see the recent announcement regarding plans to make Active Record more, well… Sequel-esque.
I’m also using httparty to allow users to tweet directly from their fight pages – basic authorisation is easy with httparty and it felt like a much better fit than overkilling the project with OAuth.
Issues
Overall, the Twitter API is easy to work with. It’s a little weird having the search API split away from the remainder of it, but it’s no big deal. One major limitation of the Twitter API – the unsearchable nature of any status updates over a certain age – actually turned out to be a blessing. It means that fights involving the same Twitter users will be different from week to week (or even day to day), depending on how sweary/misanthropic the users have been feeling recently. Sure, follower counts will remain roughly the same for weeks on end, but a couple of good old blue-tinted rants about your local transport provider will have you beating opponents in no time.
Future
A leaderboard is in order. Anything else I think of might just get done too. Any suggestions/bugs/breakages, please let me know.
Update, 12 Feb 2010
I’ve just read that Twitter is phasing out basic authentication much sooner than I’d anticipated. Will have to get cracking on OAuth!
Update, 18 June 2010
I stripped out the basic auth tweet form and replaced it with a TweetBox from Twitter’s @Anywhere platform. Pro: Trading a controller action and two gems for a few lines of JavaScript isn’t bad at all; Con: non-JS users miss out again.