TwitterAPI.js の後継にあたる、OAuth 認証対応版、Twitter API 用 JS ライブラリ、TwitAPI.js を公開しました。
まだまだ荒削りなバージョンですが、とりあえず基本的な動作は可能になったので Ver 0.1.0 として公開です。
当面は完成度の向上を行って、いずれは TwitMgr と Splitwit を OAuth 化させていきたいですね。
TwitAPI.js はインターフェースを一から設計し直したので、旧版にあたる、TwitterAPI.js と互換がありません。
そのあたりは専用のラッパを書く予定なので、そこがすんなりと実装できれば、TwitMgr と Splitwit もあっさりと対応完了するはずなんですけどね。
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 はますます面白くなりそうです。
また、今回の騒動はとほほ(杜甫々)さん≠平志朗氏で決着が付きましたが、それでも誰かが亡くなった事実には変わりません。ご冥福をお祈りします。
その後、とほほ(杜甫々)さんご本人より、平志朗氏の訃報を悼むコメントが とほほの WWW 入門に掲載されました。
Powered by WordPress | Aeros Theme | TheBuckmaker.com