OTCHY.NET

Splitwit Ver 1.0.0 をリリースしました。
TwitMgr のデザインをそのまま踏襲したので、思いつきからリリースまで約半日でのスピードリリースになりました。

さてこの Splitwit、何をするためのツールかというと、140 文字の制限がある Twitter の中で、その制限を超えて投稿するためのツールです。
もちろん、既存でも同様の目的を達するためのツールはあるのですが、別サービス上に長い文章を書いて、Twitter への投稿はその冒頭部分だけで、残りはリンクで別サービスに飛んで下さい。というのが普通だったりします。

そもそも、そこまでの長文を書くつもりは無いんだけど、ちょっと長すぎて 140 文字に収まらないような時、わざわざ他の場所に書くのって面倒じゃないですか？
Twitter クライアントで TL を見ている時に、わざわざ外部の URL を開いて投稿の内容を確認しないといけないのって、嫌じゃないですか？

そんなわけで、140文字を超える内容を適宜分割して、連続投稿出来るツールを作りました。

分割といっても、140 文字ぴったりにはこだわらず、なるべく読みやすい位置で分割をするようにしたり、連続投稿といっても、一定のバッファを設けることで、スパム判定されにくくしたり、といった工夫を凝らしています。
また、各投稿にはヘッダとフッタを指定出来るので、連続投稿の関連性を分かりやすくすることも出来ます。

そんなこんなです。ご意見ご感想など、是非お寄せ下さい。

TwitterAPI.js の Ver 0.9.4 をリリースしました。

一部、不具合の修正もありますが、メインは Firefox 3.6 に対する対応です。
元々 Firefox のブラウザ判定にワンライナー (/a/[-1]==’a') を使っていたのですが、それが 3.6 から無効になり、Fx 3.6 で正常動作していませんでした。
こういうイレギュラーなのはあんまり使うもんじゃ無いですね…。

一方、UTF-8 以外の文字コードで使用した場合に、Chrome で文字化けする問題の解決も試みましたがダメでした。
document.createElement(’iframe’) した iframe は、元のページのエンコードにかかわらず UTF-8 で生成されるのが Chrome 以外のブラウザの実装なのですが、Chrome だけは律儀に元のページのエンコードを引き継ぐため、文字化けが発生してしまっています。

meta タグで Content-Type を指定してみたり、document.open で、Content-Type を指定してみたりしたのですが上手くいかず挫折です。
誰か Chrome 上で元のページのエンコードにかかわらず、UTF-8 の iframe を生成するいい方法を知っていたら教えて下さい。

TwitterAPI.js の Ver 0.9.3 をリリースしました。

バージョンとしてはマイナーバージョンアップとしていますが、全面的に書き直して、大幅な機能追加を行っています。

JavaScript だけで Shift_JIS/EUC-JP のページから UTF-8 に変換して POST する方法 や、JavaScript だけでクロスドメインで POST メソッドを送る方法 の POST 完了時にコールバック関数を呼び出す技の成果などを取り込んだり、従来不可能と思っていた BASIC 認証における再ログインを実装したりと、意欲的なバージョンアップです。

全面的なリファクタリングに際して記述を洗練させたため、機能が増えても、容量や実行速度は減っています。
最初、Ver 1.0.0 を付けて華々しく…と思ったものの、全面書き換えでバグがあったりすると切ないので、やめました。「バグフィックス版の Ver 1.0.2 がスタンダードになる」みたいのって、格好悪いじゃないですか。

それと、本家の Twitter API も以前と比べ色々と追加されていたので、それらにも追随しました。report_spam とか、search とか出来るようになったので使い道も増えたんじゃないでしょうか？
近々、リスト系の API が追加されれば、それも取り込んでいきたいと思います。

さしあたって、スパム報告機能については、TwitMgr と相性が良さそうなので、そこで使っていきたいですね。

今日 (2009-10-28) の朝、とほほの WWW 入門 で有名なとほほ(杜甫々)さんが亡くなったのでは？というニュースが Twitter を駆けめぐりました。
発端になったのはこの投稿です。

この投稿にはてブが付き始めたり、「とほほ」がばずり始めたりすると、訃報が一気に広まったのです。
また個人のブログで、広島在住、Perl 使いという特徴から「とほほ(杜甫々)さん＝平志朗氏」説を述べているページが以前からあった事も、ニュースを補強します。

とほほの WWW 入門にお世話になった世代と、日本で Twitter を使っている世代が重なった事もあって、Twitter 上のあちこちで訃報を悲しむ声が上がりました。

そんな中、冷静にとほほ（杜甫々）さんと同一人物とはまったく思えないといった指摘があがります。

ここで指摘されているサイトはどうやら亡くなった平志朗氏のサイトなのですが、確かに「とほほの WWW 入門」からは想像出来ないサイトの作りです。

しかもソースを見る限り、ホームページビルダーで少なくとも 2004 年以降に作成されています。
このあたりから、徐々に、とほほ(杜甫々)さんと平志朗氏は別人ではないかという見方が広がり始めます。

ただ、Twitter の特徴として各人の TL で情報伝播速度に違いがあるため、この段階では真偽入り乱れる非常に混乱した状態になってきていました。
訃報に悲しみ続けている人、さらなるソースを求めて真偽を見定めようとする人、結論を保留して様子見を決める人もいます。

そしてついに、ソースが発見(追記：初出はこちらとの事です)されます。

平志朗氏のサイトで、平志朗氏自身がとほほ(杜甫々)さんとは別人であると書き込む内容です。

すると、TL の内容も徐々に誤報を伝えるコメントが増え、訃報が広まったのと同じ速度で誤報であるという情報も広まっていきました。
今回の騒動を機に、とほほ(杜甫々)さんの影響の大きさを感じた人も多かったようです。

こうして今回の騒動は収束し始めていったのですが、この間、時間にしたらおよそ 1 時間程度でしょうか？
Twitter 検索でずっと情報を追っていたのですが、あまりのスピードに驚きました。

次の Web のトレンドはリアルタイムだと言われて久しいですが、今回まさにそれを体験した思いです。
こういった事象をもっと早い段階で何度も見せられた米国のネット関係者は、Twitter のすごさをもっと早くに理解していたんですね。
Google や MS が自前の開発ではなく、Twitter との提携に踏み切った理由もよく分かります。

これからの Web はますます面白くなりそうです。

また、今回の騒動はとほほ(杜甫々)さん≠平志朗氏で決着が付きましたが、それでも誰かが亡くなった事実には変わりません。ご冥福をお祈りします。

追記(2009-10-29)

その後、とほほ(杜甫々)さんご本人より、平志朗氏の訃報を悼むコメントが とほほの WWW 入門に掲載されました。

JavaScript のみを使って、クロスドメインを実現しつつ POST メソッドでリクエストを送信する方法について解説します。
ここで解説する方法にはこんな特徴があります。
(2009-10-30 追記) iframe の unload のタイミングについて、重大な不具合がある可能性に気づきました。Chrome/Firefox において、2度イベントが発生している可能性が高いです。unload イベントを使わない場合は無関係です。結論が分かったら修正版をこのページで公開します。
(2010-01-29 追記) Chrome は大丈夫そうです。Firefox もカウンタ or フラグを使ってイベントを記録すれば大丈夫ぽいです。ちゃんと直せて無くてすいません。

• XMLHttpRequest では不可能な、クロスドメインによるポストを実現している。
• 元になるページの文字エンコードの種類にかかわらず、必ず UTF-8 でポストできる。
• ポストが終わったタイミングをイベントで捕捉できる。
• JavaScript だけで実現するので、サーバサイドに何らかのスクリプトを用意する必要がない。
• 必要な HTML は DOM で後から埋め込むので、元になっているページの HTML は修正する必要がない。

さて、話の発端は、はてブ with Twitter になります。
このスクリプトは、元々 Greasemonkey に搭載されている GM_xmlhttpRequest 関数を使って実装されていました。
GM_xmlhttpRequest は通常の XMLHttpRequest に存在するクロスドメインの制限がないので (その分危ないとも言えますが)、 「はてブを追加する前に Twitter につぶやいて、その処理が終わってからはてブを追加する」という事がいとも簡単に実現していました。
ところがこのスクリプトを Google Chrome に対応させるにあたって、Google Chrome では、GM_* 系の関数が存在しないので、それを代替する手段を模索する必要があったのです。

通常、JavaScript によるクロスドメインというと、API 側が、JSONP 対応している前提で、script タグを埋め込んで対応するのが一般的です。
ただ、この方法には制限があり、script タグによるリクエストは必ず GET メソッドになってしまいます。
Twitter の API は大半が GET でアクセスできるのですが、つぶやきを送信する API については、POST でのアクセスが必須となっていて、Twitter でつぶやくために JSONP を使う事は出来ません。

単につぶやいてそれっきり、という動きでよければ、以前 閲覧中のページについてそこから遷移せずTwitterでつぶやくためのブックマークレットでやったのと同じ方法でいいのですが、はてブへの追加をするにあたっては、Twitter API へのアクセス完了を待たないといけないので、そのあたりを解決したのが、Google Chrome 版スクリプトになります。

以下では、はてブ with Twitter (for Google Chrome) のソースから一部を抜粋して、どうやってその動作を実現したかを解説してきます。

var d = document;
var f = /* なんかのフォーム Element */;
var b = /* なんかのサブミットボタン Element */;

// サブミットボタンにイベント登録
b.addEventListener('click', function (e) {
    // クロスドメインポスト用隠し iframe
    var i = d.createElement('iframe');
    i.style.display = 'none';
    d.body.appendChild(i);

    // レスポンスイベント取得用隠し iframe
    var i2 = d.createElement('iframe');
    i2.name = 'postresult';
    i2.style.display = 'none';
    d.body.appendChild(i2);

    // レスポンス時イベント登録
    i2.contentWindow.addEventListener('unload', function(e) {
        f.submit();
    }, false);

    // クロスドメインへの POST メソッド送信
    var iDoc = i.contentWindow.document;
    iDoc.open();
    iDoc.write('<form method="POST" action="http://twitter.com/statuses/update.xml" target="postresult">');
    iDoc.write('<input type="hidden" name="status" value="ポストしたい内容" />');
    iDoc.write('</form>');
    iDoc.write('<script>window.onload = function(){document.forms[0].submit();}</script>');
    iDoc.close();

    // サブミットボタン本来の動作をキャンセル
    e.preventDefault();
}, false);

このソースは、元々ページに存在するフォームに対して、そのサブミットボタンの動作をフックし、サブミットが行われる前に Twitter へのつぶやき (クロスドメインでの POST メソッド送信) をして、それが完了したから本来のサブミットをする、という動作を意図しています。
ソース中の f が元々のフォーム、b が元々のサブミットボタンです。

まず、サブミットボタンの click イベントを追加し、イベントの中で、e.preventDefault() する事で、本来のサブミット動作をキャンセルします。
そしてそのイベントの中で、i と i2 という 2 つの不可視 iframe を追加しています。

i は、POST メソッド送信用の iframe です。
window.write メソッドを使って iframe 内に form を組み立てつつ、window.onload で、読み込みと同時に form.submit() が走るようにしておきます。
ここで、form タグの method に POST を指定し、target に i2 の name を指定するのがポイントです。

i2 はあらかじめ name を指定してある iframe です。
i2 については、中身は空のままでいいですが、unload イベントを登録しておくのがポイントです。
これにより、i の中の POST 処理結果が i2 に送られたタイミングで i2 の unload イベントが発生するので、POST の完了を捕捉する事が出来ます。
ここで f.submit() と本来のサブミット動作を指定する事により、サブミットボタンのクリック動作をフックして別の動作を組み込む事が実現します。

(備考) 後かたづけの必要性

この例では、i2 の unload イベントの中で、親画面を遷移させてしまっているのでそれっきりでいいですが、親画面をそのままにする場合は、i と i2 を削除するなど後かたづけをしておく必要があるでしょう。
JSONP を使う場合もそうですが、テンポラリに生成したエレメントを放置していると、動的な HTML がどんどん汚くなって非常にマナーが悪いので後かたづけもちゃんと考えたいですね。

(備考) なぜ iframe で POST するのか

実は、単に POST メソッドを送信するだけでよければ、1つ目の iframe は不要です。document に直接 form を追加する事でも POST メソッドを送信する事が出来ます。
あえて、iframe を追加し、window.write で form を作っているのは、文字コードの都合になります。
iframe を空っぽの状態から作ると、内部的にその iframe の文字コードが UTF-8 になる事を利用して、POST の内容を UTF-8 にしています。
Web 用に POST メソッドの API を公開しているような最近のサービスは、要求される文字コードが大抵 UTF-8 かと思うので、元のページが Shift_JIS とか、EUC-JP であっても、iframe を利用すればスムーズに API を使えます。

(備考) なぜ iframe が 2 つ必要なのか

iframe を 1 つにして、それ自身の unload イベントを捕捉すればいいじゃないか、と思ったアナタ。その通りです。正しい思考です。
こればっかりは、実際にやって上手くいかなかったから、としか言えません。どうも、POST 後に unload イベントが発生していなかったようなので、2 つめの iframe を用意してやる必要がありました。

Twitter API が返すのが xml だからなのか、クロスドメインの制約によるものか、Firefox だったらそれでも上手くいくのか、理由はよく分かりません。
まあ、このあたりも含めて一種のノウハウなのでそのまま公開します。

(備考) IE の場合

IE の場合は未検証ですが、イベント周りの扱いが標準とかけ離れているので、上記のソースがそのまま動く事はないです。
具体的には、addEventListener のあたりと、preventDefault のあたりは確実に違います。
もし IE も視野に入れてどうにかしたいなら、イベントモデルの差異を吸収してくれているラッパ (jQuery やら prototype.js やら) を使うのが賢明かと思います。