Have you ever wondered if it was worth following someone on Twitter?
Now you have another tool to help you make that decision: follow cost. Give follow cost a Twitter user name and it will calculate how often they tweet on average. As a yard stick, follow cost uses the milliscoble, defined as 1/1000th of the average daily Twitter output of Robert Scoble. As an example, here’s my follow cost (currently, 133 milliscobles).
There’s even a bookmarklet you can use when viewing a Twitter profile.
We’ve got some neat features planned for the future, but to do them, we need better hosting. So we’re looking for a sponsor. Contact me if you’re interested.
Building follow cost
I built follow cost with my friend (and Harvest developer) Barry Hess. The idea for a service “to tell you how annoying someone would be to follow on Twitter” was hatched on our road trip to Windy City Rails a few weeks ago. (Fourteen hours in a van with 6 programmers is a long, long time.)
Barry and I decided that we wanted to do something a little different than the traditional Rails project.
We chose to use Sinatra. Sinatra was perfect for this project. It has very few dependencies. The routing is explicit and an integral part of your app. The app itself has only a few pages and doesn’t use a database. Really, anything else would be overkill.
We also decided to use jQuery for JavaScript, since neither of us had tried it before. It worked well, I can see why people like it.
To actually power the application, we call the Twitter API (using REXML) and the Twitter Search API (using JSON).
To keep things snappy, we implemented a page caching system for Sinatra that works very similarly to Twistr’s, which I described earlier.
Deployment was handled with Passenger and Rack based on these instructions.
I tried searching for “joevandyk” and “fixie”, but it said there was no twitter user by those names.
It couldn’t find my username either: http://twitter.com/teabass
Hey guys,
Thanks for trying out the site. Sorry it’s not working 100% right now. Barry and I are going to try to fix it tonight. We’re not sure what the the issue is, but I blame Dreamhost out of reflex. ;-)
Love it – excellent idea and beautifully executed. Congratulations!
Were you guys able to come up with any tricks to keep the Dreamhost Passenger alive longer? I have a site on Dreamhost running under Passenger, and it will only stay alive for about 1-2 minutes. Then it is reclaimed by Passenger (this is the normal behavior of Passenger) Then you get the annoying 10-15 second load time when you hit the app (since Passenger has to launch the Spawner and an instance of the app).
Brandon,
We aren’t experiencing much trouble with that. It could be because Sinatra loads up relatively quickly. We’re also using page caching, which means the application is bypassed entirely for many requests.
Twistr (my other Twitter project hosted on Dreamhost) is written in Rails and does have an annoying slow start up time when Rails isn’t running, but it’s not 10-15 seconds. Maybe more like 5. Perhaps it’s because I’m not loading any gems.
I guess I’d play around with it on your local machine (in production mode) and do what you can to reduce the load time (lazy-load gems, reduce the number of dependencies, don’t load some of the frameworks if you don’t need to, etc.) and see if that makes a difference.
Also, check the load average on your Dreamhost server. Maybe it’s unacceptably high for running a Rails app.