Using Twitter as a commenting engine for Zoom around Town
So with the number of routes in http://zoomaroundtown.appspot.com/ increasing daily, the time has come for me to start considering implementing some kind of commenting functionality for the added cycle routes. I have not had the time to implement a user login system (I am still hoping to see more routes in the database first), let alone a commenting system. However one day, a simple idea came to me. What about getting people to comment on routes by creating tweets and then all I have to do is to display these tweets using Twitter Search. I was quite keen on exploring this idea, and I implemented the following in Zoom around Town:
For each route, I programmatically create a bit.ly link for its unique page url e.g. (http://bit.ly/39oF3z for http://zoomaroundtown.appspot.com/findRoutes?id=24001). On the page, I then display a message telling people to comment on the route by sending a tweet starting with @zoomaroundtown http://bit.ly/39oF3z (I'm even including a link that automatically populates the starting text for the user: http://twitter.com/home?status=%40zoomaroundtown%20http%3A%2F%2Fbit.ly%2F39oF3z%20).
To display comments, I use the Search API (http://apiwiki.twitter.com/Twitter-API-Documentation) to search for all tweets sent to zoomaroundtown containing the string http://bit.ly/39oF3z i.e. using the search string to:zoomaroundtown http://bit.ly/39oF3z.
Whether this is a viable way of enabling commenting Zoom around Town, only time can tell. However there are obvious pros and cons:
PROs:
Extremely easy to implement (especially when I don't have a user login system yet)
Increased site exposure on Twitter
CONs:
Twitter Search only seems to return tweets no more than 2 weeks old
I have no control over content (but since these are public tweets, do I really care?)
Last but not least, something unfortunately I only managed to discover after deployment to the live cloud environment - Twitter Search's rate limiter does not seem to like Google App Engine, and it is this point that will lead us to my next post, but for now it suffices to say that Twitter Search rate-limits requests per IP, so it is not surprising that in a cloud environment where one is sharing IPs with loads of other apps, some requests are bound to get rejected!
For each route, I programmatically create a bit.ly link for its unique page url e.g. (http://bit.ly/39oF3z for http://zoomaroundtown.appspot.com/findRoutes?id=24001). On the page, I then display a message telling people to comment on the route by sending a tweet starting with @zoomaroundtown http://bit.ly/39oF3z (I'm even including a link that automatically populates the starting text for the user: http://twitter.com/home?status=%40zoomaroundtown%20http%3A%2F%2Fbit.ly%2F39oF3z%20).
To display comments, I use the Search API (http://apiwiki.twitter.com/Twitter-API-Documentation) to search for all tweets sent to zoomaroundtown containing the string http://bit.ly/39oF3z i.e. using the search string to:zoomaroundtown http://bit.ly/39oF3z.
Whether this is a viable way of enabling commenting Zoom around Town, only time can tell. However there are obvious pros and cons:
PROs:
Extremely easy to implement (especially when I don't have a user login system yet)
Increased site exposure on Twitter
CONs:
Twitter Search only seems to return tweets no more than 2 weeks old
I have no control over content (but since these are public tweets, do I really care?)
Last but not least, something unfortunately I only managed to discover after deployment to the live cloud environment - Twitter Search's rate limiter does not seem to like Google App Engine, and it is this point that will lead us to my next post, but for now it suffices to say that Twitter Search rate-limits requests per IP, so it is not surprising that in a cloud environment where one is sharing IPs with loads of other apps, some requests are bound to get rejected!
Comments
pretty interesting. Have you tried to use this method in really BIG radians (e.g. 2500 KM) and a zoom level of 3? The circle behaves more like an onion an dthe center moves to the left.
I just added via Firebug a corresponding value to your drop down box and zoomed out. Looks horrible, I'll try to figure out a better code for getDestLatLng - we already use some geocoding code on some stored procedures, so it should be easy to manage :-)
I have never tried it with BIG radii. To be honest, I did not bother going through the maths, but I will definitely try to understand the geometry involved at some point!
In the mean time, if you have a better implementation, please do let me know!