Sam's World Of No

November In Manchester is a social media love story. It focuses on the lives of eight fictional mancunians over the course of November – their story is played out over the characters’ tweets and blog posts; all of which are disguised as real people. They even interact with real people; they attend real events and they take real photos of the city. The main November In Manchester site was to bring their story together in to a single timeline, and when Tom approached me to build it, I was happy to oblige.

For my own notes, I thought I’d jot down a few details of the implementation for future reference, or for anyone who was interested. November In Manchester is built in Rails using HAML and SASS.

Scheduling

This was a nice opportunity to use the whenever gem. If you’ve not used this before, check it out – it’s a cracking gem and its example Capistrano recipe works a treat. Although I’m happy enough with cron syntax I was pleasantly surprised to have it so smoothly taken out of my hands, and means that our various scheduled tasks are managed straight from a config file in our application.

Twitter

The Twitter implementation was the most difficult part. The initial version used dancroak’s twitter search gem and worked a treat with the code. I don’t particularly like the query syntax, but this is down to twitter, not the gem. Also down to twitter is the job of updating the search results. Unlike the main site, the search site (and API) is not always real-time and can lag heavily behind. It’s no good being 8 hours on a story that’s supposed to be happening in real time.

We therefore switched the search gem out and ended up using the main API and gem. Initially we were perplexed about how to best get the information about various users’ tweets. The API is designed for a piece of software acting as a twitter user, and so can tweet, follow, etc – but it can’t search. In the end we settled on using the ‘user_timeline’ method and passing the username (screen_name) of the user we wanted to get the tweets for. We run this search every five minutes, and as long as we’re not more than 20 tweets behind (the method’s limit – although you may be able to override), we’re golden. It’s not ideal (better suggestions received) but it got us back to real-time.

Thankfully our architecture allowed this switch to be made in 10 lines or so of code. Good job – I had a matter of minutes before BarCamp Manchester 2 started to switch it over!

RSS/Atom

Ruby has built-in support for RSS, and we initially used this for the integration. However, it doesn’t support Atom and I didn’t want to be caught by surprise if a new blog turned up that used this format (I didn’t know what new characters and data sources Tom would introduce as the plot twisted and turned!), so we switched over to the excellent Simple RSS gem. This gem also supports reading from the content of the posts – which at one point we were using – which the built-in Ruby stuff doesn’t.

Flickr

Photos are a big part of the project, and we wanted to have the most recent photos displaying on the site, pulled from the flickr feed.

We used the flickr-fu (not ‘flickr_fu’, confusingly) gem for our integration here, and took inspiration from this blog post. I don’t think that helpers are the right approach here, though, so we instead import our flickr photos every 3 hours through a scheduled process and stick them in a database – hotlinking the actual images straight from flickr.

Deployment

We use Capistrano for deployment and git for version control.

Overall the tech stuff on the site was just the work of a weekend or two and a few evenings. It was nice to have a small project that was live quickly – something I’ll definitely try to bear in mind for the future. Hope you’re enjoying the story!

Bookmark: