こんにちは、「最近の主戦場はどこ？」と聞かれたら「Twitter」と答えるでしょう、 おがた (@xtetsuji) です。
先日、3月21日になりますが、「第5回 Twitter API勉強会」に行ってきました。前回「第4回」から二度目の参加になります。
公式サイトは無いようですが、情報をTogetterにまとめてくださった方がいらっしゃいましたので、タイムテーブルやスライド資料などはコチラからご参照ください。
前回の私の感想ブログの締めくくりで「機会があればPerlのTwitterライブラリについて発表してみようかなと思いました。」と書いたのですが、今回のタイムテーブルの10分LTに自分のアカウント名が登録されているではありませんか。「いつか発表したい」→「次回発表する」の流れにちょっとビックリ。
[tweet https://twitter.com/xtetsuji/statuses/172637481408282625]そういえば前回「第4回」で、こんなやり取りがあったのでした。まさか本当に「第5回」で発表になるとは…。
「Twitter API勉強会」は月1回の活発な勉強会で、準備期間は1ヶ月もありません。まぁ、結局スライドは前日の深夜に徹夜気味に作ったのですが…。当日いらっしゃった方々、内容もさることながら、発表がグダってしまって本当に申し訳ありません。練習不足でした。スライドの内容の補足等については後述します。
前回の会場は御茶ノ水のデジタルハリウッドさんでしたが、今回は渋谷の「ハロー会議室」というところでした。
広々とした会議室でしたが、私はちょっと遅刻してしまったので、最初は後ろのほうに座って聴講していました。その後、トークの隙を狙って前の方に進出していきましたが…。
Twitterの日本語検索、ハッシュタグについて
最初のトークは、急遽タイムテーブルが変更になって、Twitterの国際化等に携わっている@keita_fさんによる「Twitterの日本語検索、ハッシュタグについて」。
資料も公開されていない半分オフレコっぽいトークだったので、どこまで感想を述べていいかちょっと分からないのですが、浅い範囲で手元のメモに書かれている興味深かった項目としては
- Lucenceを使っている
- Twitterは50もの言語をサポート
- ツイートの言語判定はJavaで実装。UTF-8文字列を各種ローカル文字コードにエンコードしてみて失敗するかどうかでチェック(結構コストがかかりそうなトライアンドエラーで検出するとは意外でした)。西欧の文字列はn-gramでチェック。
- 2つ以上の言語が混じっている場合の苦労
- 絵文字(emoticon)の取り扱い
- Unicode Alphabetの取り扱い
- 形態素解析にはGomoku、西欧の文字列は独自実装。
- テキスト処理のオープンソース化を https://github.com/twitter/commons/ 以下にしていっている
といったところでした。
@keita_fさんは、あのティコリンク(t.co短縮URL)の実装にも関わっている人らしく、どちらかというとそちらの方で色々と質問したかったのですが、時間が無かったのと懇親会にいらっしゃらなかったので、そちらについてはほとんど話を聞けませんでした。
声をかけて一つお話をしたのは「ティコリンクの識別子(スラッシュの後の文字数)は8文字ですが、Twitterには日々膨大なURLが投稿されているので、あれが9文字になる日は来るんですか？」というつまらない(?)質問をしてしまった(とっさに思いついたのがそれだった)のですが「じきにそうなる日も来るでしょう」という回答でした。実際、Twitter APIからはティコリンクを展開したURLの情報も乗ってくるので、そちらを見れば各種実装が8文字を想定する必要すらないので、他愛も無い質問だったなぁと思います。
交流タイム
最初のトークが終わった後は、恒例の交流タイム。今回は学生さんの参加が少なかったようですが、周囲の社会人の方とどんなお仕事をされているのかとか、どういった興味でここに来たのかといった話で盛り上がりました。ここで後ろの席から前の席へ移動。
ランチタイム共有サービス「昼会」のご紹介
次のトークは@setomitsさんによる「昼会」のご紹介。デジタルガレージの中の方です。
なぜTwitterかという話から。最初は(デジタルガレージが業務提携を結んでいた)LinkedInのOAuthを使ったログインを検討していたらしいです。ビジネスランチ的な何か？そこは普及度を考えてTwitter OAuthに変更したとのこと。
開発は、Google App Engine(GAE)上でTweepyというAPIを使って開発しているとのこと。Pythonですね。
ユーザへの通知に自分へのDMを使用しているとのことですが、ユーザから「自分から自分にDMが来るのは気持ち悪い」「スパムかと思った」「アカウントを乗っ取られたかと思った」といった意見があったとのこと。でも開発者に話をすれば実装上「まぁこうするだろうね」といった感じで折り合いが着いた(?)ような感じです。Zusaarでも登録ユーザへの連絡はユーザ自身へのDM(ひとりごとみたいな感じ)で実現していますし、同種の考えのサービスは多いようです。
既存のサイトのOAuthの利用について、いちいち新しくユーザー登録をしなくて良いのは良いとのこと。
トラブルもあって、ログイン出来ないということはサービス開始前やサービス開始直後に頻発していた模様。原因追及できず、一切のAPIコールができない状態が続いたようです。
昼会の開発から8ヶ月、色々な発見があったようです。昼会というサービス自体で新しい出会いがあったこともあるようですが、昼会の敷居が意外に高いこともあったとか。確かにサイトを見ても中々昼会の予定が入っていない。質疑応答で「夜会もやったほうが…」というジョーク質問がありましたが「ドメインhirukai.jp取ってしまいましたし…」とのことでした。
昼会の開発体制は最初3人。開発1人、デザイナ1人、企画交渉1人。最小編成ですね。
質問はGAEコストにも波及して、改定前は数千円/月だったのが改定後に数万円/月になってヤバいと思い、APIのコール周り等のコストを見なおして、改定前くらいの価格まで押さえ込めたとのこと。GAEのコスト改定はニュースにもなっていましたが、桁が違ってくるほどの値上げだったんだなと思いました。
この後はLT。
Twitter 4 contact
@inda_re さんの「Twitter 4 contact」。問い合わせフォームをTwitterで作ってしまおうという発想は面白かったです。資料もPHPで作られたプログラムも公開されているので、導入しようと思えばすぐにでも導入できそうです。発想の面白さと、LTならではのウケ狙いの上手さに感服です。
PerlのTwitterモジュールについて
これは私 @xtetsuji によるトーク。5分や20分の経験はあったのですが、10分LTというのは初めてで、どれくらいの分量でトークしていいか分からないまま、練習不足というかほとんど練習をせずにのぞんでしまったために、非常にグダってしまい申し訳ありませんでした。
前回、学生さんが多かった事を念頭に置いて「半分くらいはPerl自体の環境導入をやったほうがいいのでは」と思って資料を作ったのですが、今回はほとんど学生さんがいない(居たとしても既にスキルある方ばかりな)状況だったので、ちょっと構成に失敗したかなぁ、といったところです。
結局のところ、PerlにもStreaming APIをいじれるAnyEvent::Twitter::Streamというモジュールがあって、手軽にプログラムが書けるんだよといったところが伝わればよかったかなと思います。
以下、資料です。
デモプログラムで登場した twitter-stream-search.pl は、自分自身がテレビ番組(アニメとか)の実況をコンソールで tail -f のように流し見しつつ、あとで録画したものを観るときにそのストリームの詳細がログの様になっていて欲しい、と思い立って30分くらいで書いたプログラムです。今も便利に普段使いしています。仕事のプログラムは書くのに何時間も掛かるのに、人は私利私欲があればものすごい速度でプログラムが書けるんだと思った瞬間でした。AnyEvent::Twitter::Streamの導入さえ成功してしまえば、後は比較的簡単に使い始められるのも特長としています。
ここからは発表から蛇足になりますが、AnyEvent::Twitter::Streamも万能ではないようで、まだできないこともあります。最近Streaming APIで開始されたgzip圧縮にも対応していないようです。あと、上流でHTTPストリームが切られた場合の再接続アルゴリズムも実装されていないようです(Squid経由で接続してSquidを再起動させれば簡単に再現できる)。前回の勉強会の時にJava Hackerに囲まれて話をしたときに「TwitterのStreaming APIを正確に実装しているのはTwitter4Jしかない」という話がありましたが、まさにそういうことなのかもしれません。Twitter4Jの作者であり、このTwitter API勉強会の主催者である@yusukeyさんに、懇親会でその辺のお話をうかがってみると、再接続アルゴリズムは実装も確認も大変とのこと。Perlに貢献するべく、AnyEvent::Twitter::Streamにパッチでも当ててみようかとも思ったのですが、作者がPerl界の大御所過ぎて、どうしていいかちょっと悩みますね。でしゃばり過ぎとか言われそう。
twitter-stream-search.pl は Date::Format と Date::Parse に依存していますが、Perl-5.10以上を最初から要求しているのだから、Perl-5.10からコアモジュール入りしたTime::Pieceを使えば不要な依存関係を減らせると後で思ったのでした。これは気が向いたら直します。Date::Format も Date::Parse も cpanm で簡単に導入できるので、それほど深刻な問題ではないと思いますけどね。
KotlinでもTwitter4J
@ngsw_taro さんによるトーク。KotlinというJavaベース(?)のプログラム言語があるようですね。そのKotlinからTwitter4Jを使おうというトーク。結局デモは失敗してしまいましたが、後日Kotlinから投稿したツイートがあったので、それでデモが成功(?)ということになった感じでしょうか。
LT中に紹介された、お手軽開発環境 http://kotlin-demo.jetbrains.com/
Java界隈にはGroovyとかJRubyとか、その上に乗る言語がたくさんあって面白いですよね。Twitterの勉強会なのに、Javaを見直すきっかけが多い勉強会でもあります。
懇親会
渋谷の外を移動して、今回も貸しスペースでのオシャレな場所で懇親会がありました。
(写真撮ってくるの忘れた…)
今回初めて出席された方と色々な話で盛り上がったり、前回トークをした方へ質問をしてみたり、有意義な時間が過ごせました。勉強会中だとなかなか質問したり交流したりといったことが苦手な日本人でも、酒が入るとその辺結構いけるものなんですね。酒が入った後にコードを書いたりできるかどうかは別として、初顔合わせや顔見知りの人と雑談する上で、お酒と貸切の静かな(勉強会関係者以外がいない)場所はうってつけの場所でした。
今回は発表者側に立ったこともあって、声をかけて下さる方もいて、発表者効果さまさまだなと思った次第です。用意は大変ですが、発表者として壇上に立つと、私のような知らない人に声をかけるのが苦手な人も話しに花が咲いて、非常に良い経験でした。
月1回の勉強会に、資料の用意がなかなか大変なこともあって、しばらくは発表者側にはまわらないとは思いますが、次回発表する際には低層の話ではなく、PerlとそのTwitterモジュールを使って書いた何らかのウェブサービスを紹介できればと思いました。体調が許せば、次回も聴講者として懇親会も含めて参加したいです。