In This Chapter
Gleaning advice from other Twitter developers
One of the best ways to learn is to do. However, the next best way to learn is to glean advice from other people's experience. You've heard a lot from me in this book about my experience with the Twitter API, now here are some tips from other Twitter developers.
"Develop defensively. For instance, when passing in scoping parameters like since_id
, assume that the Twitter API will break one day and disregard since_id
when building the result set."
–Barry Hess (@bjhess), co-creator of Follow Cost (http://followcost.com
)
"The Twitter API can and will go down. Applications should have some sort of monitoring, graceful degradation, and informative error messages for users in the event that this happens. Because if you don't, your app gets blamed, not Twitter."
–Damon Cortesi (@dacort), creator of TweetStats (http://tweetstats.com
) and TweepSearch (http://tweepsearch.com
)
"Always use user_id
to reference accounts instead of screen_name. screen_name
could change at anytime."
–Abraham Williams (@abraham)
"Be sure to use long integers (Int64 in the .NET world) for storing ID values. 32-bit integers aren't large enough for the ID values that Twitter is producing."
–Duane Roelands (@DWRoelands), creator of Quitter (http://getquitter.com
)
"Expect things to change. Twitter is a rapidly developing service, and what is true now may not be true in 12 months. Subscribe to the developer announcement list (http://groups.google.com/group/twitter-development-talk
) and read it religiously."
–David Fisher (@tibbon), Web Ecology Project (http://webecologyproject.org
)
"If you're building a Web app, do as much of your Twitter communication outside the request-response cycle as you can. API calls to Twitter will often have errors or take unpredictable amounts of time. When possible, move API calls to background processes or cron jobs, batch them and cache the results. This gives users a more consistent experience, allows you to more easily handle errors and helps with staying under rate limits since your API calls are less of a function of the number of requests your app gets."
–Hayes Davis (@hayesdavis), creator of CheapTweet (http://cheaptweet.com
) and TweetReach (http://tweetreach.com
)
"Get to know JSON. Even if you aren't writing javascript, there are JSON parsers in most every language. JSON is leaner and meaner than XML and super easy to understand once you take 5 minutes to learn it. Every Twitter API method can return JSON data, so use it!"
–Chad Etzel (@JazzyChad), creator of TweetGrid (http://tweetgrid.com
) and TweetHook (http://tweethook.com
)
"Learn everything you can about efficient caching and database queries. If your app gets popular, these two things will make or break your success."
–Noah Coffey (@noahwesley), creator of TweetFX (http://tweetfx.com
)
"Make sure your app supports more than just English characters, especially when updating a user's status. For OAuth, this can mean extra legwork, since the content of the status update is part of what is used to authenticate the request @@md so it's crucial it gets encoded properly. It seems some developers don't test international characters @@md but Twitter is part of an international community, and this detail shouldn't be overlooked."
–Andrew Perrin (@mageuzi), creator of Trowl (http://mageuzi.com/trowl/
)
"Twibes uses the powerful (and under-hyped) JASONP support in the Twitter API to get around usage quotas. By using Javascript to perform searches, a Web page can become more like a desktop app @@md connecting directly to Twitter and only sending the relevant new results up to a Web server. Distributing your application logic to many clients takes load off your server and distributes the Twitter API calls (thus using none of your app's API quota)."
–Adam Loving (@adamloving), creator of Twibes (http://twibes.com
)
3.147.66.128