Sunday, July 12, 2009 10:43 PM by Michael Paladino
Those of you that
follow me on Twitter have probably already heard, but my employer,
Rockfish Interactive, has released a new product called
TidyTweet that is designed to help website owners filter their embedded Twitter feeds and block Twitter spam. Check out an example of the filtered Twitter feed on the right side of this page. I'm posting about the project here because I am fortunate enough to currently be the primary developer on the project.
The Concept
The idea came about when we had a site using a Twitter feed that became popular enough to draw the attention of spammers. The experience made us realize that if we wanted to continue to integrate these types of elements from Twitter, we would have to provide some sort of moderation mechanism. We started looking around for products to handle this for us and found that there were none. Thus TidyTweet was born.
I'll let you check out the
TidyTweet.com website,
an interview with me on Jay Thornton's blog, and
the article on Mashable.com for more details about the product itself. With this being a mostly technical blog, I thought I'd share a bit about the technology behind the product as well as some of the obstacles and planned enhancements.
Technologies
We used
ASP.NET web forms for the front-end,
LINQ to SQL for data access, and
jQuery for any client-side work. So far all have worked out well, and I have no complaints. We're making extensive use of
HTTP Handlers to allow for custom URL extensions such as *.atom and *.widget. HTTP Handlers are relatively easy to implement, provide performance benefits over standard ASPX pages, and provide cleaner URLs vs. something like *.aspx?format=atom.
Twitter API
We're obviously making extensive use of the
Twitter API. I initially did those calls via HTTP requests but midway through the project found
TweetSharp. TweetSharp provides an clean wrapper around the API and is very convenient for getting up and running quickly with the Twitter API. Working with the Twitter API is tricky due to the latency involved in the HTTP requests, potential for downtime on Twitter's side, and the
rate limits. We've worked through all of these things, but performance is definitely a concern and will be a continual source of refactoring.
That's just a small taste of the project from the technology side of things. Feel free to ask questions in the comments if you would like me to go into any further details. Obviously, a large amount of the code is confidential, but I can certainly discuss some of the technologies in general terms.
