AAMALIAA

Last month I received a frantic text message from my roommate. “I have an awesome idea but no one to do it with! :(”

His idea involved taking a swing voter in the upcoming presidential election and putting their vote up to a vote on Twitter. Each public tweet containing either one of our two hashtags would count as a vote in either direction and at the end of the project span, our swing voter would vote for whichever side had the most “twitter-votes”. A seemingly simple concept, somewhat controversial (if you’re passionate about that sort of thing, though I saw it as more of a fun/weird experiment than a serious statement), but it was definitely going to be a team effort.

As he had only seen the few hackathon projects I had done (and left unfinished and in “prototype”, un-hosted form, as most hackathon projects usually are), and most all of my other work is on internal company tools and apps, he was originally going to look elsewhere for a developer. I took that as a challenge—we were launching this thing within 2 weeks and I was going to code it.

The guidelines I listed were the following:

• We needed some way of continuously searching for tweets containing our hashtags and storing them into a database without going over API limits.
• Once tweets were collected, we needed some way of showing them on our main site.
• We also needed to be able to show the percentage of voters voting each way, and also update those numbers frequently.

So I took to Google…

The first thing I discovered was Twitter’s awesome Streaming API—it allows you to hook into their ridiculous firehose (though they make you limit your search, only a few huge data companies have access to the full firehose offering) stream of real-time tweets and apply your own filters.

The next thing I discovered was 140dev’s awesome open source PHP/MySQL solution for getting and parsing tweets from the Streaming API, called Phirehose—I was able to use their code as a base and filter our tweet votes (while also easily limiting the number of votes per user_id that we count into our database) with only 2 PHP scripts that run on the server at all times. The vote percentages shown in the middle of the two feeds are populated from a simple json file that is updated every 5 minutes from a simple query to our “votes” database table.

I knew that, in the event that the site was a huge hit, storing the full tweet data in our own DB and then constantly querying it to show the tweets in two separate feeds on our homepage might be a bad idea (I’m pretty sure I don’t have the backend chops to scale a database for that kind of activity)—not to mention it might violate Twitter’s new API rules. Referring to the Twitter API again, I found that two Embedded Timelines would do the job for free (and legally).

As for the back-end, I have been especially into AWS lately so it was all done on a basic micro EC2 instance and a MySQL DB on RDS.

Things I particularly liked about working on this project (I like lists):

• working with designers—this was actually the first time I’ve worked together with a designer on a site and I liked not having to fire up Adobe Photoshop/Illustrator myself to get things done, not to mention the logos and photos look awesome.
• it was quick—we started and launched this thing in ~2.5 weeks!
• it’s finished—saying you’re going to do a project and actually finishing said project are 2 very different things

Things I want to explore for future projects:

• I really really want to explore using node.js to provide real-time updates. PHP is fun and really easy to use, but I love the idea of an event-driven environment (i.e. showing updates to your database on your site or webapp as soon as they happen).
• All of my projects thus far have used MySQL but am curious about NoSQL (think MongoDB)… we’ll see.

Thanks for reading! If you have any questions or just want to discuss nerdy things like this, hit me up on twitter… and PLEASE VOTE FOR JORDAN!