Tweetrics - Don't do what I did post

I recently put together tweetrics. It's a site dedicated to tracking public twitter accounts, graphing daily and cumulative activity. I had a lot of fun putting the site together, unfortunately it wasn't without its problems. Before I get into that, lets get into how the site is setup. Backend Setup For the backend setup, I used Passenger and Merb. I know Merb is going to merge with Rails, but I found building tweetrics as an opportunity to get more familiar with the nuancies of Merb. I wanted to use the run_later method in merb to offload the processing of tweets because it's a very processor intensive task, but I decided against it. The main reason being run_later creates a queue per merb process on the server and not a global queue. The global queue was important to me because I did not want multiple instances of the method that builds the twitter activity because my server does not have very much memory. Also, from what I've read on the web, I couldn't use run_later even if I wanted to because it does work behind Passenger. Instead of run_later, I used beanstalk. I found instructions that met my needs at Nuby on Rails. The instructions were pretty clear and the setup of the software to get beanstalk up and running was pretty painless. Like the Nuby on Rails article, I also had a database that recorded the state of jobs in the queue should the beanstalk instance crash. Frontend Setup To get the front end working, I used a combination of JQuery, the Google Visualization API and a little bit of Ajax. Working with the Google Visualization API was a complete breeze. All you need is a couple of lines of javascript in your page and POW! The visualization shows up. I was even suprised the charts could be rendered after issuing some JQuery UI effects. Don't Make These Mistakes After writing this app, I learned a few things. Hopefully by posting this, you won't have the same problems that I did.
  1. When using Beanstalk and the Ruby gem beanstalk-client, make sure that you use the yput method and not put.

    yput will serialize the object before putting it into the message queue and then your worker can pull it out and deserialize it. I tried to get around the serialization step by using the put method but for me, I kept getting errors and the job would not get inserted into the queue. I struggled with this for a while before giving up and using yput.

  2. When using Google Visualization API, make sure the user's url and the hostname in Json Requests actually match.

    This was quite frankly a stupid mistake on my part. The charts page actually pulls in a static JSON file that has the chart data unfortunately the hostname of the url to request the JSON file was hardcoded as http://tweetrics.info/. If a user accessed the site using http://www.tweetrics.info/ instead, the Google Visualization would not pull the data into the charts.

  3. If you're using the Google Visualization API, load JQuery from Google instead of hosting it on your own site.

    Pulling JQuery from Google can save you oodles of bandwidth. Just do it like so.....


0 comments


Leave a Comment