[随想]HT-01Aの画面保護フィルムはもう流石に売ってなかった

2009年9月に購入し、今年4月までメインで使っていたWindowsMobile端末HT-01A（2008年秋モデル）の、新しい画面保護フィルムを買いに札幌ヨドバシカメラに行ったのだが、もう流石にHT-01A向けのフィルムは置いていなかった。

（確か）昨年の時点で、他の大半の電器店が扱いをやめていた中、ヨドバシカメラには比較的長くHT-01A向けのフィルムが残っており、昨年9月にはHT-01Aのフィルムこそなかったものの、ソフトバンクの同型機であるX05HT向けのフィルムが残っていたんだけど。

てなわけで、初めて「自分で切って使う」タイプのフィルムにお世話になることになりました。

クラウド温泉3.0に行ってきました

@nakayoshix氏主催、クラウドを題して（と言ってもそればかりでないのですが）開催される、IT技術者向け合宿。
今回が3年目で、私は以前から存在は知っていたのですが、参加は初となった。
今回は「代数」と「Object Functional」（オブジェクト指向＆関数型言語）がテーマであった。

参加レポート：2012.8.18〜8.19 クラウド温泉3.0 - H.Hiroのチラシの裏の裏

TwitterのAPI仕様変更について自分の経験も踏まえて考えてみる

2013年3月をめどに、大幅なTwitterのAPIの仕様変更がなされるということがTwitterから告知された。これを読んでいると、開発者にとって技術的に考え方を変えないとならないことに加え、そもそも「Twitter APIを使ってサービスを作ること」についても考え方を変えないと感じられた。

以下の記事を見つつ、ポイントをまとめていくとともに、私の考えを述べていく。
●原文：Changes coming in Version 1.1 of the Twitter API | Twitter Developers（基本的にはこれを参照します）
●日本語での要約：Twitterブログ: Twitter API v1.1でのAPI利用ルールの変更について
●参考記事：Twitter、開発者向けガイドラインとAPI変更について説明　ユーザー数制限など厳しい内容 - ITmedia ニュース

【Authentication required】（認証が必須になります）

現行では、statuses/user_timeline（一人のユーザを指定して発言を取得）のような「Twitterにログインしていなくても見られる情報」に関するAPIは、認証情報を送らなくてもアクセスすることが可能であった。しかし仕様変更後は、どのAPIでも認証情報を送る必要が生じる。

現在、私がHHiro.net内で動かしているTwitter向けツールでは、TwiPieces以外すべて改修が必要になる。あと個人的に動かしているボットとかツールとかも。

でこの改修なのだが正直面倒である。OAuth対応は本当に面倒くさい。方針としては、私自作のTwitterボットライブラリ「twbot2.rb」からOAuth関連部分だけ切り出して対応しようと考えている。

【Per-endpoint rate limiting】（API呼び出し対象ごとの規制）

簡単に言えば、statuses/user_timeline と statuses/home_timeline はそれぞれ別枠でAPI呼び出し回数の規制をしますよ、という話。ユーザごとにAPIを使うサービスならあまり影響はないものの、ふぁぼったーのような「多数のユーザから取得する」サービスがつらい、という話も。
参考：F's Garage @fshin2000 ：Twitter api ver1.1、痛いところ、痛くないところ

ちなみにこれは、あくまでタイムライン取得系APIの規制の話で、発言数規制やふぁぼ規制は（現行のスキームが維持されるなら）別枠で計算される。

【Changes to the Developer Rules of the Road】（開発者が従うべきルール）

【Display Guidelines will be Display Requirements】（「表示ガイドライン」は「表示の必須要件」に）

Twitterでは、ツイートを表示する場合のガイドラインとしてDisplay Guidelines（英語）を用意していて、「アイコンは必ず表示する」「ユーザの名前とユーザのアカウント名はアイコンの隣に表示する」「ツイートを選択したりしたときは、返信・お気に入り・リツイートが必ず出来るようにする」などのガイドラインが存在している。これは現状では推奨される表示方法という位置づけであったが、これが必須になる。

ここで大きな問題があって、例えば「動作を軽くしたいからアイコンを読み込まない、というのは認められないのか」とか、「表示する情報量を増やしたいから、オプションとしてユーザの名前は表示しないようにする、というのは認められないのか」といったことが挙げられる。ちなみにDisplay Guidelinesで個人的に気に入らないのは、発言時刻の表示について「24時間以内の発言の場合は"●●時間前"などの表示を、それ以前のものは日にちのみを表示」と決められていること。個人的にはどんな場合でも、日時と時刻で見えていて欲しいので。

ちなみに、「この要件を守らないアプリケーションの許可を取り消す権利が我々にはある」（原語：If your application displays Tweets to users, and it doesn't adhere to our Display Requirements, we reserve the right to revoke your application key.）とあるので、サードパーティのクライアントもこのガイドラインを強制される、すなわち「自分の好きなUIでTwitterを楽しむ」ことが出来なくなってしまうんじゃないかという懸念がある。

【Requiring pre-installed client applications to be certified by Twitter】（Twitterを利用するプリインアプリは許可を受ける必要あり）

パソコンやスマフォなどのプリインアプリが対象。理由としては「プリインアプリが更新されるには時間がかかるから」とのこと。

【Requiring developers to work with us directly if you need a large amount of user tokens】（大量のトークンが必要な場合はTwitterと直接協業する必要あり）

ここでトークンというのは、OAuth認証における、ユーザとアプリの組に対して与えられる認証用文字列のことで、つまりは「大量のユーザを対象とする場合は」という話である。
1つのアプリが、Twitterに許可を得ずに受け入れられるアカウントの数は10万に制限される。ただしすでに10万を超えているアプリなら、その2倍までは拡大が認められる。

【API v1.1 migration period】（API v1.1への移行期間）

6か月待ちますよ、とのこと。

【Today's Twitter ecosystem】（現在のTwitter界の体系）

結論から言うと、Twitter社としては「Twitterクライアントはあまり作って欲しくない」とのこと。

現在のTwitter APIの使われ方を「ビジネス向けか一般利用者向けか」（Business/Consumer）「Twitterを利用するのか分析するのか」（Engagement/Analytics）という軸で分け、そのうち右上の項目 "Consumer+Engagement" についてはAPIをあまり使って欲しくない、とのことであった。（原語：limit certain use cases that occupy the upper-right quadrant）

で、このConsumer+Engagementに含まれるものとして、「traditional Twitter clients」（これまでのTwitterクライアント）や、「Syndication」（発言を見せたり広めるためのサービス、という意味と思われる。Favstarなど）が入っている。

確かに現在だと、ブラウザのインターフェイスが多機能化してブラウザだけでもかなり使いやすくなったし、モバイルアプリも公式で揃っているというのはあるけど、歴史的経緯からすれば「色々な人が知恵を出して＆技術を身につけて作った」から多数のクライアントアプリがあるわけで、そういう開発者にとってはもちろん面白くないし、「様々なクライアントがあるから自分にあったものを見つけられて、それによってTwitterを楽しめている」人にとっても面白くないと思う。

ただTwitter社の意向としては、どうも「どんなユーザエクスペリエンスを提供するかは、Twitter社がコントロールしたい」ようなのである。上記の表示ガイドライン然り。
（参考記事：Twitterの将来を握っているとされる"Twitter Cards"とは：InstagramへのAPIも閉鎖したTwitterの将来像 - the Public Returns - 続・広報の視点）

【Looking ahead】（前を見て）

Twitter Cardsの話。上記のリンクにも書いてあるのだが、ユーザ側で「Twitterで見ると画像などが表示される」ようなサービスを作るための仕様である。

ちなみにこの節の最初の一文を訳すると、「API v1.1以降では、Twitterにあるコンテンツを使って何かするだけではなく、Twitter Cardsへの対応も考えて欲しい」という内容。言い換えれば、Twitterから情報をもらうだけじゃなくて、Twitterへ情報を渡すこともして欲しい、とのことだろうか。

【結論】

結局のところ、「今までは外部サービスに支えられてきたけど、今後は徐々に、Twitterが主要な部分を握った上でAPIを使ってもらいますよ」という方向転換をしたというのが見て取れる。上記のthe Public Returnsの記事で言われている通りなのだが。

でこの構図、どこかで見たことあるなーと思ったのだが、考えてみたら「プラットフォームの主要な部分はユーザに使わせず、それによってユーザエクスペリエンスを向上させるiPhone」vs「ユーザに自由に使わせることで、使い方自体をどんどん広げてもらうAndroid」がそれだった。
なので、この舵の切り方がうまく行けば、Twitterという世界に統一感が生まれてユーザにとっても分かりやすくなるとは思う（それでも私は快く思わないけど）。ただ一方で、現行の開発者の離反を招くのは確かなので、そこでコケないのかという懸念も感じるのである。

【余談】

交流ツール、情報収集ツールとしてTwitterを使うのはしばらくやめそうにないけど、自分がTwitterに対して開発者魂が疼かなくなっていきそうなのは確かなので、自分は何か代わるサービスを探した方がいいかもしれない。