title 要素で「スパムフォローをまとめてブロック」と謳っているくせに、せいぜいブロック出来るだけで、アプリ上からのスパム報告に対応していなかった TwitMgr に、ようやくスパム報告機能を実装しました。
ぶっちゃけこの機能が無いせいで、作者自身いちいち公式サイトに飛んでからスパム報告してたので、今回とても便利になって嬉しいです。
1時間足らずで実装出来るならさっさとやってれば良かったです…。
あとはあれですね、リスト登録機能が欲しいですよね。
当たり前ですが、投げっぱなしで終わりのスパム報告よりもリスト周りの API の方が複雑なので、こっちはちょっと時間がかかると思います。
Twitter API の仕様変更により動作しなくなっていた TwitMgr をフルスクラッチで書き直して Ver.2.0.0 としてリリースしました。
Ver.2 を名乗る割に、機能的には Ver.1 を踏襲しただけというのが残念ではありますが、適宜先読みを行ったり、取得したデータをキャッシュする事で、従来版よりキビキビと動くようになっています。
その分、メモリの消費は増えているのですが、昨今のトレンドに沿った修正ですし問題ないと思っています。
デザインに関しては、HTML5 / CSS3 の構成で作っています。最近、個人でサイトを作る時は全力で IE を無視するので、HTML5 / CSS3 の機能を存分に使えて気持ちいいです。
今回、webkit に限ってですが、transition を初めて使ってみました。これ、これまで食わず嫌いで使ってなかったのを後悔しましたよ。「あっても無くても機能には支障ないけど、あるとちょっと嬉しいワンポイントアニメ」とかが、楽に表現出来ます。
散々言われていた事ですが、自分で使ってみて初めて本当に理解するっていう感じです。
それと、CSS3 を使い込んで頑張ってみたのがツールバー＆タブのデザイン。
これを画像無しに表現出来るようになるとは驚きです。
ツールバー部分だけを抜き出してみれば、マークアップもシンプルです。
<h3 class="tab selected">フォローしている</h3> <h3 class="tab ">フォローされている</h3> <div class="toolbar"></div>
最近の Web デザイン系の記事に触発されて 1px のラインを入れてみたりしてます。
この CSS だけ取り出しても面白いかと思うので、そこはまた別の記事におこします。
最後に、ソーシャル系のボタンとして、はてブ・Twitter・Facebook を付けてみました。
それぞれ公式のスクリプトを生成して貼り付けた感じですが、はてブと Facebook は URL とかページタイトルの指定が固定で入るような形だったので、そこは動的に取るようにしています。
その点、Twitter のボタンはどんなページでも共通のスクリプトを貼り付けるだけでよいので楽ですね。一方、「このサイトのボタンは、どんなページにあってもサイトのトップに対するボタンにしたい」ってのが Twitter だとできないです。
まあ、プロモーション上、サイトのトップにソーシャルのアクセスを集中させたい気持ちは分からないではないんですが、ユーザは「今見てるページ」をブクマしたかったり「いいね！」したかったりすると思うので、そういうのは避けたいです。
さて、せっかく TwitMgr 自体を綺麗に書き直したので、今後は少し機能拡張もやろうと思ってます。
初代 TwitMgr リリース時点では機能が存在していなかったリストへの対応とスパム報告への対応が当面の目標です。
この 2 つは、いま自分で TwitMgr を使うにあたって欲しいと思ってる機能なので、確実に実現させると思います。
その他にも何かフィードバックがあれば、是非教えて下さい。
JavaScript から気軽に Twitter API を利用するためのライブラリ、TwitAPI.js の Ver.0.2.0 をリリースしました。
TwitAPI.js はその仕組み上、プロキシサーバを経由して Twitter API にアクセスしているのですが、メソッドが GET で認証不要な API の場合、Twitter API を直接 JSONP で利用する事が出来るので、それを可能にするアップデートです。
また同時に、TwitAPI.js 用プロキシサーバである taj-proxy も、build 5 を公開しています。
これは、TwitAPI.js 本体の更新とは関係なくて、従来、Twitter API にアクセスする URL として固定で https://twitter.com/… となっていたのを、現在の正しいドメインである、https://api.twitter.com/… に変更したという対応です。
これをしないと最新の API が利用出来ずに困った事になっていました。
しばらく放置していたのですが、最近ちょっと時間が出来て TwitMgr のリライトを再開出来たので、それに合わせたアップデートになります。
というわけで次は TwitMgr の新バージョンを報告出来るといいのですが、それはまだ先の話。
Twitter をやっていると、色々なユーザをフォローするにあたって大きく 2 つの方針があるように思います。
まず 1 つ目は、フォロワの発言を基本的に全部読めるように厳選して TL を構築する方針です。Twitter を始めた当初はこういうパターンの使い方が多いのではないでしょうか？メッセンジャー的、あるいは SNS 的使い方と言えます。
これを厳選 TL と呼びましょう。
そして 2 つ目は、もっとフォロワの範囲を拡大して、未読の発言が流れていっても気にしない方針です。フォロワが増えていくにしたがって、全部の発言を追えなくなると、どこかのタイミングでこういうターニングポイントがやってくる人が多そうです。開き直って、どんどんフォロワーを増やし続けるパターンも見受けられます。これは、ストリーミング的な使い方で、雰囲気としては TV のザッピングに似ていますね。
こちらは、ストリーム TL と呼ぶことにします。
もちろん、厳選 TL とストリーム TL の境界は曖昧でその中間的な状態という場合も多いでしょう。
さて、「知らない人をフォローすること」と独創性 | WIRED VISION という記事とか、フォロワがいっぱいいて Twitter 充している人なんかを見ていると、Twitter の一番面白い使い方は、ストリーム TL ではないか、という気がしてきます。
だけど、せっかく構築した自分の厳選 TL に大量のフォロワを追加して、ストリーム化させてしまうのには躊躇する人も多いのではないでしょうか？
自分自身、すでにある程度ストリーム化した TL にはなっていますが、ざっくりと議論を追ったりは出来る厳選 TL 的な要素も残っています。ストリーム TL の面白さを追求してみたいとは思うのですが、これ以上フォロワを増やすと厳選 TL の要素が無くなって完全なストリーム TL になってしまうので、それは避けたいという気持ちもあります。
ではどうすればいいでしょう？
まず思いつくのは、もう1つのサブアカウントを取得して、目的別に使い分けるという事です。この方法は、厳選 TL とストリーム TL をそれぞれ綺麗に分離することが出来ます。マルチアカウントに対応したクライアントアプリを使えば、TL を見るには困らなさそうですが、ちょっとした問題があります。
ストリーム TL からザッピングして、ちょっと返信を付けたり、RT したりしたい時は、やはりメインのアカウントでやりたいのですが、その度にいちいちアカウントを切り替えるのは面倒です。あるいは、ストリーム TL で気に入ったユーザがいたから厳選 TL に組み込みたい時なども面倒ですね。
とかく、複数のアカウントを使い分けて何かするというのは面倒になりがちなので、この方法はボツです。
これが本命です。
今の Twitter には、「リスト」というユーザをグループ分けする機能があるのですが、このリストに追加するユーザについては、自分でフォローしている必要がありません。
そこで、フォローしないままリストにどんどんユーザを追加して、そのリストをストリーム TL として参照します。この場合、ホーム TL (＝厳選 TL) とストリーム TL が混在することなく存在し、また、自分のアカウントは 1 つなので、返信や RT を行ったり、厳選 TL に組み込んだりするのもスムーズですね。
さらに、リストの設定にはプライベートモード (自分以外に非公開) というものも存在するので、「フォローするまでもない」と判断したことを本人に知られたくない場合や、ストーｋ 恥ずかしがり屋なあなたも安心です。
ところで、確かに気になる発言はあるものの、Tweet の絶対数が少なくてあっさり見落としてしまうような人を、確実に補足するにはどうしたらいいのでしょうか？
この場合、流し読み前提のストリーム TL は適当ではありません。
そこで出てくるのが ユーザ RSS です。RSS とは何かについては、ここでは言及しませんが、Twitter では一人一人のユーザごとに、そのユーザの発言だけが含まれる RSS が生成されています。
具体的には、以下のような URL です。
http://twitter.com/statuses/user_timeline/{userId}.rss
{userId} の部分には、対象となるユーザのユーザ ID (数値) もしくはスクリーンネームが入ります。ユーザ ID はやや専門的になるので置いておいて、スクリーンネームは各ユーザのプロフィールページの URL などに含まれる、ユーザを個々に識別できる英数字の文字列のことです。
この RSS を任意の RSS リーダに登録して購読すれば、そのユーザの全ての発言を漏れなく拾うことが可能になります。(*1)
これまた本人には知られないないですし、しかも Google リーダーなどに登録してしまえば、過去の発言の検索性も上がるので、情報源として Twitter を利用したい場合は非常に助かります。ストーｋ 恥ずかしがり屋のあなたには、願ったり叶ったりな状況になりますね。
そんなわけで、新たなフォロワを増やすことなく、気になる人を補足する方法を 2 つほど紹介しました。Twitter の使い方に正解などは無いと思っていますが、自分好みの使い方をする上での一助となれば幸いです。
*1 厳密に言えば、RSS リーダーのクロール速度を、ユーザの発言速度が上回った場合に取りこぼしが発生する可能性があります。
※前置き長いです。本題はここから。
9/6 ごろから 9/9 にかけて、TwitMgr と Splitwit の OAuth 認証が正しく動作しなくなってしまっていました。
これらは、JavaScript で Twitter API を扱うライブラリとして、TwitAPI.js を使っており、それがうまく動作していなかったのです。で、原因を追ったところ、JavaScript 側ではなく、OAuth 認証を肩代わりするプロキシサーバである taj-proxy 側に問題があることがわかったので、今回はそれを直したときの話です。
そもそも、taj-proxy は、開発当初 GAE/j 上でうまく Twitter OAuth 認証を扱えるライブラリがなかった (と思っていた) ため、OAuth 認証部分をすべて独自実装してました。Twitter 側の何らかの実装の変更により、その独自実装がうまく動かなくなったようなのですが、ぱっと見では全然原因が分かりませんでした。(多分 Signature 周りだとは思う)
それで改めて、Twitter OAuth 認証を扱えるライブラリを探したところ、Twitter4J という超メジャーなライブラリが、GAE/j に対応していることがわかり、早速使用させてもらうことにした次第です。
Twitter4J では、Twitter API と一対一に対応した java のメソッドが用意されており、きわめて簡単に TwitterAPI を利用することができます。(設計思想としては、初代の TwitterAPI.js に似てますね。)
ところが、TwitAPI.js では、将来的な TwitterAPI の拡張もにらんで、任意のパスを渡して TwitterAPI を利用することができるようになっているため、そのままでは JavaScript 側から渡されたパスを Twitter4J のメソッドに翻訳する必要が出てしまい、単に適用するだけでは済みませんでした。
そこで、Twitter4J の便利メソッドは使用せず、Twitter4J として用意されている各種のクラスを使用して、OAuth 部分だけを利用させてもらったので、その方法についてまとめておきます。
Twitter API を OAuth で使用する際に、開発者側で必要な ConsumerKey と ConsumerSecret はすでに取得済みなことを前提とします。もしまだでしたら、ほかの情報を当たってください。
ここではまず、これから始める OAuth 認証のために必要なリクエストトークン (使い捨てパスワードのようなもの) を取得します。
下記の疑似コードでは捨ててますが、consumerKey と consumerSecret から、requestToken と requestTokenSecret を取得するまでがポイントです。この時点ではまだユーザには何も提示しておらず、ここで取得した requestToken を次に使います。また、requestTokenSecret も必ずペアで保持しておきます。
Configuration conf = ConfigurationContext.getInstance(); OAuthAuthorization oauth = new OAuthAuthorization(conf, consumerKey, consumerSecret); HttpClientWrapper http = new HttpClientWrapper(conf); try { HttpResponse res = http.post(conf.getOAuthRequestTokenURL(), oauth); String result = res.asString(); if (res.getStatusCode() != 200) { System.out.println(result); return false; } Map<String, String> results = OAuthUtil.parseResult(result); String requestToken = results.get("oauth_token"); String requestTokenSecret = results.get("oauth_token_secret"); } catch (TwitterException e) { e.printStackTrace(); return false; } return true;
public static Map<String, String> parseResult(String result) {
String[] results = result.split("&");
Map<String, String> map = new HashMap<String, String>();
for (String param : results) {
String[] kv = param.split("=");
String key = kv[0];
String value = kv[1];
map.put(key, value);
}
return map;
}
単に以下の URL をユーザに表示して (通常、ブラウザであればリダイレクト) ユーザからの認証許可を待ちます。
認証が許可されると、ConsumerKey を取得した際に登録したコールバック URL に結果が返ってきます。
https://twitter.com/oauth/authorize?oauth_token=requestToken https://twitter.com/oauth/authenticate?oauth_token=requestToken
ここで、authorize は、必ず毎回ユーザの手動による認証が必要になります。
authenticate の場合、初回のみ認証が必要なだけで、一回認証してしまえば次回からは自動的にコールバックが呼ばれるようになります。大半のウェブサービスではこちらを使ってますね。
ちなみに TwitAPI.js では、その性質上簡単に認証情報を横取りすることが可能なので、authorize のみ利用可能にしています。
ユーザから OAuth 認証が許可されると、コールバック URL に結果が返ってきます。その際、リクエストパラメータとして oauth_token が渡されるので、これを requestToken と見なし、ペアで保持しておいた requestTokenSecret を取り出します。
再度 Twitter サーバに問い合わせた結果得られる、oauth_token と oauth_token_secret が、真に重要なアクセストークンになります。これがいわば、OAuth 認証の結果得られた、対象アプリケーション専用のパスワードのようなものです。その際、各ユーザのユニークキーである user_id と表示上の名前である screen_name が得られるので、これらすべてをセットにして保持しておきます。
ただ、screen_name に関してはユーザ設定で変更も可能なので、もしアプリ側でユーザごとの情報を何か保存する場合、user_id に関連づけて保存しておく必要があります。
Configuration conf = ConfigurationContext.getInstance(); AccessToken accessToken = new AccessToken(requestToken, requestTokenSecret); OAuthAuthorization oauth = new OAuthAuthorization(conf, consumerKey, consumerSecret, accessToken); HttpClientWrapper http = new HttpClientWrapper(conf); try { HttpResponse res = http.post(conf.getOAuthAccessTokenURL(), oauth); String result = res.asString(); if (res.getStatusCode() != 200) { System.out.println(result); return false; } Map<String, String> results = OAuthUtil.parseResult(result); String accessToken = results.get("oauth_token"); String accessTokenSecret = results.get("oauth_token_secret"); String userId = results.get("user_id"); String screenName = results.get("screen_name"); } catch (TwitterException e) { e.printStackTrace(); return false; } return true;
accessToken と accessTokenSecret が得られれば、後はそれを使って任意の Twitter API が呼び出せるようになります。
Twitter API は使用する HTTP メソッドにより効果が異なるので GET/POST/DELETE に応じて、使用する Java のメソッドが異なります。
Configuration conf = ConfigurationContext.getInstance(); AccessToken accessToken = new AccessToken(accessToken, accessTokenSecret); OAuthAuthorization oauth = new OAuthAuthorization(conf, consumerKey, consumerSecret, accessToken); HttpClientWrapper http = new HttpClientWrapper(conf); String url = "https://twitter.com/some_api_path.json"; HttpParameter[] parameters = new HttpParameter[]{new HttpParameter(name1, value1), new HttpParameter(name2, value2)}; try { HttpResponse res = http.get(url, parameters, oauth); // HttpResponse res = http.post(url, parameters, oauth); // HttpResponse res = http.delete(url, parameters, oauth); String result = res.asString(); if (res.getStatusCode() != 200) { System.out.println(result); return false; } // Document document = res.asDocument(); // for xml // JSONObject jsonObj = res.asJSONObject(); // for json object // JSONArray jsonArr = res.asJSONArray(); // for json array } catch (TwitterException e) { e.printStackTrace(); return false; } return true;
Twitter4J を使用するほとんどの人は、最初から用意されている便利メソッドで十分事足りると思うので、OAuth 部分のみ使用するといった用途は限定的かと思います。例えば、Twitter4J 未対応の新 API を使いたい場合や、今回のケースのように独自のアプリで変わったことをしたい場合などでしょうか。
ただ、そういった用途を想定したかのように、Twitter4J のクラス郡は非常によくできていて、とても使いやすいので助かりました。
改めて、Twitter4J の作者様には謝辞を述べたいと思います。
Powered by WordPress | Aeros Theme | TheBuckmaker.com