Web Site Expert巻頭レポート(英語)

Kevin Makice: Building Twitter Applications with the Twitter API

この記事を読むのに必要な時間:およそ 11 分

Speaking of changes, what do you think the API’s geotagging support?

I think that geotagging in Twitter is fundamentally different than with other services because you are not just letting friends know where you are, but the world at large?and potentially, at frequent intervals. Maybe that doesn⁠t matter to you, but I⁠m not sure what I⁠m going to do. I⁠ve jumped into things like the Foursquare service that lets you see friends⁠⁠ locations on your phone. But that works through check-ins, which means that I determine whether or not I want to report in from any particular place.

But Twitter is different because it is so much a part of my life. I often tweet several times a day at different locations, and I don⁠t know if I want every one of those to reveal where I am at that moment. Twitter has done the right thing by making geotagging opt-in: users have to specifically enable it. Twitter is also asking developers to make it very clear to users that their location is being attached to a given tweet. It helps that the API provides a Boolean flag that let⁠s developers know if a user has enabled geotagging or not.

I think other people have the same hesitations. Which means that as a developer, you should know that your dataset will initially be skewed toward people who are more inclined to share this information. Not everyone has a smart phone, to make the sharing of location easy. What⁠s not clear is whether these are early adopters, or whether they will forever remain a small subset of Twitter users. Maybe a year from now, with smart phones growing ever more popular, more people will be interested. But for the time being, I⁠m not sure what the value is. Here in Bloomington, Indiana, we have about 1300 people using Twitter right now, most coming on board over the past year. But my guess is that if I wrote an application for my community that relied on geotagging, only 100 or so would enable the service and show up. That⁠s not the kind of payoff I would want.

The Twitter API has been a bit confusing?because it has actually been two discrete APIs.

That⁠s true, and it⁠s important to know that. Originally, Twitter didn⁠t have its own search engine. So in July 2008, Twitter made its first and only purchase of a third-party developer, acquiring Summarize and its search tool. Summarize had its own API, as well, and that became Search API. If you look at the Twitter API documentation, there are two sets of methods: ⁠Search API⁠⁠ methods and ⁠REST API⁠⁠ methods. Twitter is working to fully integrate the two. I⁠m guessing it will happen sometime in early 2010. There has already been some movement to make the error codes behave the same.

Meanwhile, are there pitfalls for developers?

Potentially. For example, for a long time, if you deleted a tweet using the REST API, it could still be found in the search engine. I think Twitter has now fixed that. The larger problem is that you really are using two completely different APIs, which requires two different ways to parse the information, and the information you do get is a little different.

The API is also confusing because it hasn⁠t been stable. The ground keeps shifting under you. So keep checking the API changlelog, which gives a complete list of the changes made to date. If I were to do an update of my book, that⁠s where I⁠d start. I⁠d look at what changes have come up since the book left off, and that⁠s what I⁠d update first. For developers, the same thing is true. Your program might be done and tested and well used?but the Twitter API is still going to change. It⁠s a moving target.

You wrote in your book that you didn’t have to be a programming expert to create good Twitter applications.

Right. I wrote the book for people who have great ideas for Twitter applications, not necessarily full-time professional programmers. So I included some basics, like information about the API wiki and where to find the libraries. An experienced programmer would already know that.

I do assume you have some understanding of basic programming. The book is based on a suite of sample applications that you can download and install. For those, I use PHP, MySQL, HTML and CSS. Dusty Reagan is working on another book, Twitter Application Development for Dummies that despite its title is geared toward more advanced programmers. I think he⁠ll be giving more specifics about different types of languages, about writing for the desktop versus the Web, and about other ways besides XML to get data from Twitter. There⁠s also a book coming out by Mark Hawker on the APIs that might be worth a look in 2010.

Where is Twitter application development headed?

I think there are still lots of opportunities. More people are using Twitter?and in more places around the world. With that global focus, there are international issues?politics and economics?that Twitter is well suited to helping people connect. And there are new applications related to e-commerce and electronic banking?though personally, I⁠m not sure I⁠m ready to do that over Twitter.

Not every idea will work. There was a cool site called TipJoy that attempted to help people to contribute to good causes through micropayments. But the site went under?its co-founder now works for Facebook. Maybe this was an idea ahead of its time, and with more e-commerce now going through Twitter, someone else will try it. PayPal now has a robust API, and some developers are integrating that payment system with Twitter. But the lesson is that a successful application requires not just good use of the technology, but that people be comfortable with your idea. Sometimes, that cultural acceptance comes later.

I⁠m most interested in how Twitter helps local communities?and in that respect, I find geotagging an interesting development because it shows Twitter too is recognizing the importance of local communities. There are a lot of opportunities here. So I⁠d say to developers?don⁠t try to be everything to everybody. If you think at the community level, you have the opportunity to create applications that will make a difference to the people around you.


Bart Eisenberg

Bart Eisenberg's articles on the trends and technologies of the American computer industry have appeared in Gijutsu-Hyoron publications since the late 1980s. He has covered and consulted for both startups and the major corporations that make up the Silicon Valley. A native of Los Angeles and a self-confessed gadget freak, he lives with his wife Susan in Marin County, north of San Francisco. When not there, he can sometimes be found hiking with a GPS in the Sierra, traveling in India, driving his Toyota subcompact down the California coast, or on the streets of New York and Tokyo.


1980年代後半より,『Software Design』や『Web Site Expert』などの雑誌に,アメリカのコンピュータ業界のトレンドと技術に関するレポートを執筆しています。シリコンバレーで,スタートアップ企業から大企業まで幅広い分野でコンサルタントを務めました。

ロサンゼルス生まれで,自称ガジェットフリークです.現在,妻のSusanとともに,サンフランシスコ北部のMarin County在住。また,SierraのGPSを携えてハイキングしたり,インドを旅したり,カリフォルニア海岸をドライブしたり,NYや東京の街中を歩いたりしています。