ぶっちゃけこの機能が無いせいで、作者自身いちいち公式サイトに飛んでからスパム報告してたので、今回とても便利になって嬉しいです。
1時間足らずで実装出来るならさっさとやってれば良かったです…。

あとはあれですね、リスト登録機能が欲しいですよね。
当たり前ですが、投げっぱなしで終わりのスパム報告よりもリスト周りの API の方が複雑なので、こっちはちょっと時間がかかると思います。

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 を使うにあたって欲しいと思ってる機能なので、確実に実現させると思います。
その他にも何かフィードバックがあれば、是非教えて下さい。

また同時に、TwitAPI.js 用プロキシサーバである taj-proxy も、build 5 を公開しています。
これは、TwitAPI.js 本体の更新とは関係なくて、従来、Twitter API にアクセスする URL として固定で https://twitter.com/… となっていたのを、現在の正しいドメインである、https://api.twitter.com/… に変更したという対応です。
これをしないと最新の API が利用出来ずに困った事になっていました。

しばらく放置していたのですが、最近ちょっと時間が出来て TwitMgr のリライトを再開出来たので、それに合わせたアップデートになります。

というわけで次は TwitMgr の新バージョンを報告出来るといいのですが、それはまだ先の話。

まず 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 です。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;
}

Twitter4J の役者たち

Configuration クラス

Twitter4J の設定情報を保持しています。シングルトンなので、こうしてインスタンスを取得して様々に使用します。

OAuthAuthorization クラス

Twitter4J で OAuth の認証情報を扱うクラスです。この時点ではまだ consumerKey と consumerSecret しか持ちません。

HttpClientWrapper クラス

GAE/j では外部サイトに対してソケットを開くことができず、Apache Commons Http Client などの普通の HttpClient は軒並み全滅という状況の中、HttpClientWrapper は、GAE/j でも利用可能な HttpURLConnection も状況に応じて使用して GAE/j 上でもスムーズな動作を可能とした、超ナイスなクラスです。

独自メソッド

OAuthUtil.parseResult メソッド

HttpResponse#asString() メソッドでは、単にサーバからのリプライを文字列で返してきます。Twitter API の仕様上、OAuth 認証段階では、名前=値&名前=値&名前=値… という文字列が返ってくるので、それを Map にパースするだけです。

OAuth 認証の要求

単に以下の 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;

Twitter4J の役者たち

AccessToken クラス

Twitter4J で OAuth のトークン情報を扱うクラスです。この時点では一時パスワードに相当する、requestToken を保持します。

OAuthAuthorization クラス

前と違って、取得済みのリクエストトークン情報も渡します。こうすることで、先ほどユーザが OAuth 認証した結果を結びつけて Twitter 側に伝えることができます。

Twitter API の呼び出し

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 の役者たち

AccessToken クラス

前と違って、一時パスワードに当たる requestToken ではなく、認証済みの accessToken を保持します。

OAuthAuthorization クラス

認証済みのアクセストークン情報も渡すことで、任意の API を呼び出し可能になります。

url

任意の Twitter API の URL が指定可能です。Twitter API の仕様として「拡張子」に当たる部分を、json とか xml に変えると、Twitter が返す結果のフォーマットを制御できます。詳しくは、Twitter API のドキュメントを参照してください。

HttpParameter クラス

HttpClientWrapper クラスに、任意のパラメータを渡すために使います。どういったパラメータが有効に機能するかは、Twitter API のドキュメントを参照してください。

あとがき

Twitter4J を使用するほとんどの人は、最初から用意されている便利メソッドで十分事足りると思うので、OAuth 部分のみ使用するといった用途は限定的かと思います。例えば、Twitter4J 未対応の新 API を使いたい場合や、今回のケースのように独自のアプリで変わったことをしたい場合などでしょうか。
ただ、そういった用途を想定したかのように、Twitter4J のクラス郡は非常によくできていて、とても使いやすいので助かりました。
改めて、Twitter4J の作者様には謝辞を述べたいと思います。

まず、TwitMgr に引き続き、OAuth 対応を果たしました。何とか、BASIC 認証の期限に間に合って良かったです。
また、要望の多かった逆順投稿について対応しました。

逆順投稿については、投稿者自身のプロフィールページで見たり、普通のフォロワーの TL 上では、上から順に読めるので読みやすくなる一方、TL の流量が多い人から見ると、途中で分断されてかえって読みにくくなる事がある諸刃の剣かとは思います。
まあ、Splitwit の連続投稿に割り込まれるレベルで TL の流量が多いユーザは、そんなに多くないとは思うので、実用上問題になるケースは稀少でしょう。

それと、ヒントの表示の仕方を今風の味付けにしました。
今後、機能追加をしていくと、ヒントの行数がかさんでくるかも？という考えがあって、事前にスペースを確保したというところです。

他にも追加機能の要望を頂いているので、実装方法について検討してみようと思います。
まずは、OAuth 対応を間に合わせることが重要だったので、いったんリリースします。

BASIC 認証から、OAuth 認証へ変更するにあたっては、どうしても使い勝手が低下してしまうのは避けようがないところで、そこが残念ではあります。
どうせ OAuth 認証にするならいっそ、サーバサイドをしっかり作り込めばユーザビリティの低下を最小限に抑えられるはずなのですが、元々 JavaScript だけで作られていたものを移植するとなると、ほぼ作り直しになってしまうので、現状で出来る唯一の手段としてはこんなところです。

というのは前置きでして、JavaScript による OAuth 認証について突っ込んで考えたので、以下本論。

TwitterAPI2.js (というか実質は、TwitAPI.js) を使った OAuth 認証では、js ファイルを読み込むたびに、毎回必ず OAuth 認証の確認画面を表示する仕様としています。
プロキシサーバで OAuth 認証を行う構成なので、やろうと思えば、初回アクセス時のみ確認を取る、という事も可能なのですが、そのようにしていないのにはセキュリティ上の理由があります。

TwitAPI.js では、同ライブラリで公式のプロキシサーバを用意していて、公式プロキシサーバに対して許可した OAuth 認証については、その情報がプロキシサーバ側に残ります。
なので、毎回、認証画面を表示するようにしないと、あるアプリ A に対して許可したつもりの OAuth 認証が、他のアプリ B からも簡単に流用できてしまうのです。
毎回許可を得る形であれば、他のアプリ B から無言でいきなり OAuth 認証が悪用されることは避けられます。

クッキーに保存した情報を組み合わせて認証することで、あるアプリ A (ドメイン a) に対して許可した認証を別のアプリ B (ドメイン b) から利用させないようにする実装も検討しましたが、TwitAPI.js の立場から、任意のアプリ A が信用できない以上、アプリ A に XSS があれば同じ事になってしまうので、クッキーを使った実装も見送りました。

Twitter API を JavaScript から利用可能にするための実装は、TwitAPI.js 以外にも見かけますが、そういったセキュリティ上の対応はどうなっているんでしょうかね？調べたことはないですが興味はあります。

JavaScript の場合、そのソースが、設定情報も含めて全て公開されてしまうので、OAuth 認証において本来であれば秘匿すべき情報 (Consumer secret とか最たるもの) を隠すのは困難です。というか、原理的に不可能です。

TwitAPI.js では、プロキシサーバを経由することで、TwitAPI.js 専用のハッシュを発行して Consumer secret を秘匿していますが、専用ハッシュが漏れた場合に備え、前述の「毎回認証画面」でセキュリティを保っているという形です。(専用ハッシュが漏れなくても、TwitAPI.js では共通プロキシを使用している時点で必須です。)
JavaScript で簡単に OAuth を利用したいという要求と、セキュリティを担保するという要求は相反する点が多く、現状で考え得る落としどころはそこであろうという判断です。

JavaScript による OAuth 認証で、初回のみ認証画面が表示されるような実装のアプリがあった場合、原理的にその OAuth 認証は、他のアプリから悪用されうるのではないかと考えています。
この点、もっとスマートに解決するやり方があれば、是非、識者の意見を伺いたいです。

ぶっちゃけていうと、TwitterAPI2.js にいろいろとバグがあって使い物にならないケースがあったので慌ててアップしたという形です。
バグ以外にも、既存の TwitterAPI.js でサポートしていながら、TwitAPI.js でサポートできていなかった機能も追加して、結果的に互換性が向上しています。

これでようやく、TwitMgr の OAuth 対応が完了しそうな感じです。
こちらも近日公開予定。

初回認証時に、サーバからのレスポンスが遅いと無反応になってしまう問題に対応するため、レスポンスが返るまでの間、waiting の表示を入れるようにしました。
ローディング画像風の動くテキスト表示なんかも入れたので、ユーザビリティは向上したんじゃないかと思います。

そろそろ Twitter API の BASIC 認証も期限切れなので、このバージョンと TwitterAPI2.js を使って TwitMgr と Splitwit の OAuth 対応もちゃちゃっと済ませたいところですね。

そこで、TwitAPI.js を従来と同じインターフェースで利用可能にするラッパを TwitterAPI2.js として公開しました。

元々 TwitterAPI.js を使っているアプリケーションであれば、読み込むライブラリを差し替えるだけで、従来と同じように使う事が出来ます。
TwitMgr や Splitwit もこちらのライブラリに置き換え予定ですが、出来れば置き換え前に、TwitAPI.js に残った TODO を片づけたいですねー。

特に、認証用のポップアップの起動が遅いのはなんとかしたいです。