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

Kevin Makice: Building Twitter Applications with the Twitter API

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

In your book, you list several categories of Twitter applications, including publishing, search, and aggregation statistics. Where are the opportunities?

I⁠m surprised that there hasn⁠t been more done with Avatar pictures for profiles. The API now shows you changes in profile information, including the profile picture. So I thought for sure there would be a whole suite of applications around managing your picture. But that didn⁠t happen. Last spring, I worked with a local business on an idea of allowing you to change your picture based on kind of tweet you were posting, or on your mood, or even on the time of day?so you could have a different picture depending on whether you were at work or home. Since then, a new application, Moody Tweets, has surfaced that does some of that. I haven⁠t seen any other application that comes as close.

Another gap is in having a tool directory for developers. For example, there are a number of libraries to help you integrate your chosen programming language with the API. But programmers can⁠t always find them?even though there⁠s a list on the API⁠s wiki site. Developers need something friendlier. There⁠s also a need to create mentoring relationships, so that people with a lot of experience with the API can help newer programmers. I⁠m encouraged by the initiative Twitter announced at LeWeb last December to put the ecosystem front and center in their organization plans. Ryan Sarver announced a number of plans, including an official developers conference in March and an online site devoted to this very problem. That doesn⁠t mean third party developers can⁠t help support that effort through their own projects.

There⁠s also a need for better analysis. The Twitter API supports a number of methods that show basic statistics: the number of followers, the number of updates, and the number of people you follow. These were the stats most applications focused on early in the ecosystem growth, but they only give part of the picture, especially in terms of determining value. You can⁠t really say that somebody with a large network is more important, or is even getting a better experience, than someone with a smaller network. The smaller network may be more focused and more meaningful. I⁠d like to see more variety in the way tools interpret Twitter data to better reflect the actual value people are receiving. A lot of this may come from focusing on local groups or some other subset of the entire network.

So there’s a need for a “second generation” of statistics with more sophisticated analysis.

Right?people are looking for information that is less obvious. The traditional way of evaluating what one site calls ⁠your global significance⁠⁠ is to value things like retweeting. Even before Twitter institutionalized it, a lot of people had concluded that the ultimate goal of Twitter is influence: which means to get your tweets retweeted. Retweeting is nice because you are sharing information with large networks of people, but that⁠s not going to be appropriate for everyone. You may be valuable in a narrower sphere of interest, such as your local community. That counts, too.

So I think developers should look at other ways to go about assessing value. One good example is MrTweet, which calls itself a ⁠personal networking assistant.⁠⁠ The site tries to show you people you should follow, people you can point to, and ways to get discovered?based on your own activity and the information people feed into the site. Some people now focus on the lists compiled by influential members of the community, like the ones Robert Scoble curates. You could do this at the local level, as well. In using the API, developers may find other ways of combining the list methods to create something of value. It⁠s an area worth looking into.

What technologies are useful for Twitter application development?

One of the most important is OAuth, a protocol for users to share contact lists, photos, and other personal information. OAuth is a better alternative to basic authentication, which requires disclosing your user name and password. But if you change your password for one application, that breaks the relationship for all of them. OAuth uses tokens instead, which means you aren⁠t handing out private account information?and you control the relationship of your account for each particular application. OAuth is now recommended by Twitter for performing authentication with the API. By mid 2010, it will be required.

What programming “best practices” would you suggest?

There are a few of these. For example, it⁠s really good practice for your app not post things without your knowing about it. You give an application authorization to access your information, and the next thing you know, it⁠s tweeting in your stream without your permission. That may be a good thing from the standpoint of the application developer?a way to spread the word?but I don⁠t like it when I⁠m not asked. Personally, I won⁠t use any application that does that.

Also, be aware of new updates to the Twitter API. If you aren⁠t, your application may start breaking or become inefficient. For example, there⁠s a tool called Qwitter that notifies you when somebody stops following you?something Twitter itself doesn⁠t do. I profiled Qwitter in my book, but since then, people started complaining that Qwitter⁠s reporting wasn⁠t working. Into that gap came TwitDiff. They took advantage of new API methods that weren⁠t there when Qwitter got started. The API updates meant you could do the job with just two calls, rather than having to loop through several different requests.

You should also be aware of third-party Twitter-related APIs. A good example doing this is Topify, which replaces the standard Twitter notification you get when you have a new follower. A Topify notification may include the follower⁠s profile information and most recent tweets. Topify also mixes in data from MrTweet, if the new follower has an account there. That⁠s possible because MrTweet has its own API. These third-party APIs are both an opportunity and a service. As a developer, they⁠re an opportunity to access a broader set of data. And if you create your own API, that⁠s a great way to give back to the community. Having your own API also allows you to make connections that may lead to future development partnerships, co-marketing, and other good things for your business.

What about data security for Twitter applications?

That⁠s definitely a part of best practices on Twitter. You build it in and test for it. If security is not your strength, then make sure you get a security expert to review your code before you launch it.

The other important thing is to participate in the community. For English-language developers, there is a Google group worth following, which is also available as a daily summary. You may find that people are discussing issues that are tripping you up too. I fully expect Twitter⁠s emphasis on developer support in 2010 will bring better resources to all levels of developers and to different languages.

著者プロフィール

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や東京の街中を歩いたりしています。