YAPC::Asia Tokyo 2010 2日目

gihyo.jpさん(http://gihyo.jp/news/report/01/yapcasia2010/0002)さんでのレポートの下書きをおいておきます。

gfxさん「How Xslate Works - The next generation's template engine」

資料：http://d.hatena.ne.jp/gfx/20101016/1287214638

gfxさんによるXslateの内部構造を中心としたトークでした。電車遅延を考慮して10分遅れてのスタートとなりました。

  • What is Xslate
    • A template engine for Perl5
    • XSで書かれている
    • 高速かつ安全
    • 複数の文法をサポート。TT likeな文法をサポートしている
    • エラーメッセージが優しい
  • なぜ今更テンプレートエンジンなのか？
    • おもいつくだけでも10数個のテンプレートエンジンがある。Template-Toolkitが有名。HTML::Templateも広くから使われている。最近開発されたText::MicroTemplateも人気がある。Text::MicroTemplate::Extendedとして拡張されている。Template::AlloyなどTT2互換なものもある。
    • ただしどれも一長一短
  • Template::Toolkit2
    • 長所：機能が豊富。使うのも簡単。拡張も容易
    • 短所：動作がとても遅い。仕様がとても大きくて、複雑。XSSを生みやすい
  • HTML::Template::Pro
    • 長所：実用上問題ないレベルの高速さ。機能も制限されている（何でも出来すぎない）
    • 欠点：使いづらい。機能が少なすぎる。XSSを生みやすい
  • Text::MicroTemplate
    • 長所：Pure Perlだが十分に速い。インストールも簡単。最初からXSS対策が施されている
    • 欠点：テンプレート言語としてperl言語を採用しているため、何でも出来すぎる。デザイナー等にはつかいづらい
  • Xslateとの比較
    • TT2と比べると格段に速い（100倍以上）
    • Text::MicroTemplateと比べても早く、適度に構文を制限しているので危険なことはできない
  • Text::ClearSilver
    • いいライブラリだが、もっといいものが作れそうと思った。
  • 既存のものより良いものを創りたい
  • Tutorial
    • Text::Xslate->new()->render()
    • newにはオプションをいろいろ渡せる。cacheの指定など
    • render()メソッドは文字列を返すだけ。出力先の指定などはできない（オプションが増えると遅くなるので）
    • render_string()は遅いのでプロダクションでは使わない方がよい
    • forループはperl6っぽい。フィールドの参照も->ではなく.(ドット)で
    • cpanm Text::Xslateでインストール（依存がちょっと多いのは欠点）
    • exampleディレクトリに例をたくさん置いている
  • Perfomance
    • TT2の158倍速い。via http://xslate.org/
    • Sam Graham'sレポート
    • テンプレートエンジンのインスタンスを再利用し、かつキャッシュが効いている状況だと一番速いとレポートされている
    • PSGIアプリケーションを念頭においているため、この前提は問題ない
  • Safe
    • 従来のテンプレートエンジンでは、htmlエスケープを明示する必要があった。Xslateでは自動的にHTML-escapeされる
    • Text::MicroTemplateでまず採用。値がエスケープされたかどうかを保持している。それをそのまま取り入れた。
    • 'raw'を使うとエスケープしないこともできるが、極力避けるべき
  • Multi-syntaxex
    • Kolon - デフォルトはPerl6風の構文。Xslateの全ての機能が使える。チューニングも進んでいるのでお勧め。
    • TTerse - TT2互換。完全ではない。プラグインや例外はサポートしていない。パフォーマンスの劣化は殆ど無い。ただエスケープのコンセプトが真逆のため単純に置き換えるのは難しい。
    • Clevery - Smartyのサポートもしている。こちらは不完全。今はあまり頑張っていない。
  • 拡張
    • TT2風のメソッドを追加する拡張モジュール Text::Xslate::Bridge::TT2Like
  • Template cascading
    • Text::MicroTemplate::Extendedのテンプレート継承機能を拡張したもの。もともとはPythonのDjangoが起源。この構文はKolonでしか使えない。
  • Execution Process
    • テンプレートエンジンにバーチャルマシンを搭載している。
    • テンプレートをいったんプログラミング言語風に変換。それをパースして構文木を作成、実行しやすくするためにコンパイルしてバーチャルマシンに処理させる
  • Preprocessing
    • メンテナ募集のため解説してます
    • T::X::Parser::preprocess
  • Parsing
    • 教科書通りにパースする。
    • Parserは手書きでやっている。Beautiful CodeのTopdown Operator Precedenceを参考にした「9章 下向き演算子順位解析（ダグラス・クロックフォード）」
    • Kolonの一部をオーバーライドして、一見全然ことなるTTerse構文を実現している
    • テンプレートをTokenに分割。それをSymbolに食わせると構文木（Node）ができる
  • Symbols
  • Complining 時間がないのでこのあたりは省略
  • Saving/Loading Bytecode
    • 保存は高速化のためにData::MessagePackを使っている
  • なぜ速いのか
    • 最適化を頑張っている
    • <: 1 + 2 :>などはリテラルの3に
    • <: if 0 :>などは削除
    • 仮想マシンがはやい。register machine
  • HTML Escaping
    • これの処理負荷が意外と高い
    • Text::MicroTemplateのエスケープ部分だけxs化したらフルXSのHTML::Template::Proより速くなった
  • Preallocation
    • 出力サイズのバッファを予想して予め拡張しておくと20％くらい早くなった。
  • Information
    • http://xslate.org
    • Web + DB Press Vol.59 今回の話とは被らないように使い方中心で

質疑応答

  • Q. VMを実装したところの主眼はなにか？Perlのコード化して実行する手法もあったと思うが
  • A. 実際にPerlコード化するエンジンは結構ある。XslateのPurePerl実装もそうなっている。Perlインタプリタ自体はテンプレートの出力に特化しているわけではない。xslateはテンプレート処理に特化しているので、速い。文字列の連結は全て手書きしている。余計なバッファを作らずにエスケープ処理をしている
  • Q. 独自のVMをもっているということであれば、もうちょっと頑張ってPerl6を実装できない？
  • A. テンプレート処理に特化しているので、例外処理や変数スコープなどがないので、普通の言語を実行するのは難しい感じ
  • Q. perl以外のバインディングを作ることはできるか？
  • A. perlの内部構造に依存しているので、移植する形にするか、perlライブラリにバインディングするなどの方法ではないと難しそう。移植の予定はいまのところない。

overlastさん「Perl で自然言語処理」

発表資料：http://www.slideshare.net/overlast/perl-5460697

  • 自然言語処理って何？
  • 必須な要素
    • プログラミングスキル
    • 確率統計と言語に関する知識がすこしあればよい
  • 関連する知識・技術
  • 自然言語処理の勉強のはじめ方
    • 日本語の教科書を読む。薄くて新しめで網羅的な本が良い
    • 生駒日記を半年ぐらいウォッチすれば業界通になれる
    • FSNLP
  • 勉強会
  • その他
  • 三つの心構え
    • 最初は簡単に、あとから洗練する。やってみるとユーザの動きがかわるから、効果をみて凝るのがよい
    • 機械はミスをする。誤り箇所を探すとかは難しい。日本語の口語文テキストは難しい
    • データは自前で集めて自前で持つ。早く計算するために
  • Webサービスと自然言語処理
    • 最初はWeb APIやライブラリを利用すればOK。
    • 課題を見つけてチャレンジする。独自でデータを収集して、自分でライブラリを書くのがお勧め
  • Webサービスにありがちな悩み
    • ユーザ回遊性を高めたい
    • データはあるけど検索できない
    • 単語Aと単語Bって一緒にならないの？
    • ユーザが全アイテムをみてくれｒない
  • Web APIを使って問題解決
    • もうみんな飽きてますよね
  • ユーザ回遊性を高めたい
  • 単語Aと単語Bって一緒にならないの？
    • 正規化、データクレンジング、名寄せなどで検索
    • 例:電話番号っぽい数字 CPANならNumber::Phone::JPなど
  • ユーザが全アイテムをみてくれない
    • ランダム表示してログを観察
  • 出力結果の順番が気に入らない
    • ソート方法を変える。日付、頻度、確率（このページにきた人のうち、お気に入れた人は何人かなど）
    • ソート順の機械学習 CPANモジュールのAlgorhithm::SVMLight
  • 文書分類
    • 欲しいカテゴリごとに分類した文書集合を準備
    • 機械学習記に学習させる
  • 文書クラスタリング
    • 事前に文書集合をなんこにわけるかを考えておく
    • 分類された素性を分析してラベルつける
    • CPANモジュール Text::Bayon

cho45さん「映画にでてくるハッカーになりたい」

発表資料：http://subtech.g.hatena.ne.jp/cho45/20101016/1287204627

  • 映画に出てくるハッカーの例
    • なにかわからないが文字が流れている
    • ものすごい可視化
    • よくわからない方法で暗号をとく
    • かっこよく仕事で使いたい
    • コーディングしてモテたい
  • 使えそうで使えない、でもちょっと使えるツール群
    • 実用的かつ映画的なハッカー
    • なにか文字が流れるもの
    • tail -f
    • 人間がえられるもの。動体視力
    • ハッカー的なこと・・・・凄い可視化
  • realtimeresponsegraph.pl
    • tail -f からレスポンスタイムを即座にグラフ化する
    • 全解析は一日かかるので、本番でのチューニング結果がすぐわからない
    • デモ　「かっこいいとおもいません？どや？」
    • 実装面
    • use OpenGL;
    • select();
    • vec();
    • fileno();
    • AnyEventも検討したが、難しかった
    • いろいろな機能
    • グルーピング パス毎に別のグラフにできる。
    • Apacheのログフォーマットパーサジェネレータ
  • だいぶ良くなったが、まだ何かが足りない
  • realtimeaccesstracker.pl
    • 直近のアクセスログ。ユーザごとのアクセスが見れる
    • 実装
    • まだまだたりない
    • 原点に変える - 画面に何か流れる
  • Devel::KYTProf
    • id:onishiさん作
    • DBIとかmemcachedとか、IOに関わる処理を処理時間とともにターミナルに出力
    • どこから吐かれたかわかる
    • 処理にかかった時間がわかる
  • demo
  • まとめ
    • realtimeresponsegraph.pl 実用性まあまあだけどカッコよさはイマイチ
    • realtimeaccesstracker.pl 実用性はないけどまあまあカッコいい
    • Devel::KYTProf 実用性もかっこよさもMax!

kazuhoさん「perl-casual特別企画 Unix Programming with Perl」

発表資料：http://developer.cybozu.co.jp/kazuho/2010/10/my-slides-at-ya.html

  • 正しいコードを書くためにすること
    • テストが通るからかならずしもただしくない
    • 実際に正しいコードを書くには、perlの知識やOSの知識が必要
    • OSの話は少ないので今回はその話題
  • errno

if ( ! -d $dir ) {
# ディレクトリの存在を確認してから、mkdirするまでの間に他のプロセスが作ってしまったら？
mkdir $dir or die $!
}

    • mkdirを読んで、そのエラーの結果で判断すべき
    • でも$! =~ /File exists/で判定はだめ。OSのロケールによって異なる
    • use Errno (); $! == Errno::EEXIST
    • $!はdualvar - 数値として評価した場合は数字で返ってくる。文字列として評価した場合は文字列として返って来る
    • errnoの探し方。perldoc -f しても書いてない
    • man 2 mkdirで確認できる。manのsection2はsystem callの一覧。section3はCのライブラリ関数の一覧
  • forkとファイルハンドル
    • forkしてもファイルハンドルは共有される
    • 共有させたくない場合はファイルを開きなおしてやればよい
    • ファイル共有しているとSQLiteのファイルが壊れるケースがある
    • ファイルの場合はどちらかがファイルをクローズすればよい
    • DBIの場合はunef $dbhではだめ
    • $dbh->{InactiveDestroy} = 1; してからundefすると、ソケットだけクローズしてくれる
    • *CORE::GLOBAL::forkを書き換えて強引に閉じる
    • POSIX::AtForkを使えば同様のことができる
    • execする前にファイルディスクリプタを閉じるべき
  • Unix Signals
    • SIGPIPE - ファイルハンドルにデータを書こうとしたときに書き込めなかった場合に飛んでくるシグナル。デフォルトの動作はプロセスの終了
    • $SIG{PIPE} = 'IGNORE'で防げるけど、print文の失敗を都度チェックしないとけない
    • $SIG{ALRM}をつかってタイムアウト処理を書く
    • ALRMタイムアウトの利点。多くのシステムコールが使える
    • ALRMタイムアウトの欠点。globalなので構造化プログラミングと相性が悪い。そういう場合はselectやIO::Selectで
    • キャンセル可能なコードの例。
    • Gearman::Workerなどでやっている
    • waitはシグナルが来ても無視する。そういうときProc::Wait3を使う。
  • WEB+DB PRESSにgfxさんの次に掲載予定

http://developer.cybozu.co.jp/kazuho/2010/10/my-slides-at-ya.html

perl-casual特別企画 PMグループディスカッション

地方PMトークセッション。日本全国6箇所のPMグループのディスカッションとなりました。

各pm紹介タイム
  • Hokkaido.pm - onagataniさん。
    • 北海道帯広市在住。Perl歴5年。Movable Typeで仕事している
    • 設立:2010/4
    • Hokkaido.pmって広すぎじゃね？ でも市町村単位だと人数が集まらない
    • JPAへのお願い。講師派遣や初心者向け資料の提供
  • Yokohama.pm - clouderさん
    • 世田谷在住（設立時に横浜に住んでいた)
    • 日本で7つめのpm
    • 横浜を中心に活動しているPerl Mongersがゆっくり参加できるPMが欲しい。
    • Shibuya.pmよりも初心者がトークで参加しやすいPMが欲しい
    • すべて開催後に交流会がある。参加率が90%以上と高い。
    • 勉強会以外（忘年会など）も開催したい
  • 名古屋でperlをゆるく語る会 - issmさん
    • 名古屋からこられている方3名程度
    • 名古屋では他の言語の勉強会はあるが、perlがない。
    • 名古屋と近辺の融資で食事しながらPerlについてかたる・・・という名目の飲み会
    • 毎回10名前後のあつまり
    • @yuruperl
    • Nagoya.pmとして申請中
  • Kansai.pm - lapis25さん
    • 兵庫県在住。普段perlはやってない。
    • 設立:2000年3月
    • リーダーがいない。メンバ融資による運営
    • 年１〜２回のペースでミーティング。広域なのでほぼ土日開催
    • 勉強会だけではなく、新年会、忘年会、ぼたん鍋ツアーなど
  • Fukuoka.pm - debilityさん
    • 2007/11設立
    • 頻繁に定例会のように開催している
    • 技術的なプレゼン、飲み会#1〜#4。ビール瓶で乾杯
    • 設立者の杉山さんありがとうございます
  • 岡山.pm/都会.pm - canadieさん
    • 2009/11から
    • しばらく一人だった。参加人数は8名
    • 問題点。人が集まらない。人が集まらないので問題点がでない
    • 人を増やすいいアイデアを募集しています
地方だからできること、できないこと
  • Fukuokaでは勉強会が大量にあって、奪い合いになるので、PHP-in Fukuokaと合同でやっていたりする。地域性が大きい
  • Yokohamaは都会に近いので、Shibuya.pmから来る方が多い。人数的には潤っている。スピーカーもShibuya.pmと結構かぶっている
  • Hokkaidoだと、札幌市だと会場が沢山あるが、帯広市には殆ど無くて会場探しに２週間ぐらいかかった
私、実は今悩んでいます 〜地方PMからのホンネ〜
  • Nagoyaだとperlを扱っている企業が少ない
  • Okayama人がいない。車移動が常識のため、飲み会ができない。FUKUOKAのビール瓶乾杯がうらやましい
  • Fukuokaのビール瓶乾杯は例外です
  • Kansai miyagawaさんが発表されたとか、hatenaで開催されたときとかは人が集まったが、定着しない。新しい人が入りづらくなってきている
  • Nagoya Shibuya.pmのようなハッカーの集まりはハードルの高さを感じる
  • Tokyo.pmの前田さん、最近は昔話担当。最初のPM。設立の目的は、月１回程度飲み会することだった。今Nagoyaさんがやっているような活動はもうすでにPMとしての資格を満たしていると思う。海外でも飲み会ばかりのところや、勉強会ばかりのところなど、地方ごとに個性がある。まずは人と人とのつながりを定期的に行うのがいいと思う。
ちょっと教えて！気になる他PMへ質問
  • Q.開催する会場の探し方。有料無料、選定基準、開催曜日
  • Hokkaido 札幌市だと100名4000円とかで借りられるので苦労しないが、帯広では会場自体がないので苦労する。開催日は広い北海道では平日にやることはほぼ不可能
  • Kansai 企業さんに借りる。会場を借りる場合は実費。学生さんん向けには学割を用意して参加しやすくしている
  • Yokohama 平日が多い。金曜日に行って、次の日休みなので飲める
  • Okayama メンバーが来れる日がたまたま平日が多いだけ
  • Fukuoka メンバーの会社の会議室。IT向けに借りられる場所がある。土曜日の昼ぐらいからやって3時にはビールが空いてる
  • miyagawaさん、会場をきめると人数が制限されるので、制約になることもあるかもしれない。
  • Q.他コミュニティとの面白い試みなどはありますか？
  • Hokkaido 活動をサポートする社団法人がある。
  • Fukuoka PHPグループとお互いのフレームワークの話とか、Acmeの話をした。毎回Perl界隈は怖いと言われる
  • Kansai またあなたのところの弾さんがPHPをdisっていると言われる(会場笑い)
  • Q.メンバーの平均年齢と男女比
  • Hokkaido 30歳前後、女性の方は見たことがない
  • Yokohama 30代中盤とおもう。98%男
  • Nagoya 男性8割女性2割。20代後半ぐらい
  • Kansai 若い学生から大学の先生まで幅広い。中心は30代。男女比は女性の常連さんがいるので0になることはない程度
  • Okayama 25から35程度。いつも参加されているのは女性は１名
  • Fukuoka 30前半。いままで見た女性は二人。いつも参加されているのは１名
  • Q.上級者・初級者がいる中でのトークのレベルなど、運営の仕方について工夫していますか？
  • Yokohama 初級者がトークする場も提供したい。
  • Hokkaido あまり意識せずに運営している。メンバーも増えたのでこれから考えていきたい
今後の豊富
  • Hokkaido スタッフのかたが増えてこないと運営が回らないことがわかった。今後は初診者にやさしい勉強会を拓いていきたい
  • Yokohama トーク以外のことも実施していきたい。最近開催数がへってきているので活発化したい
  • Nagoya 力まずにゆるく進めたいと思います。
  • Kansai いままでどおりゆっくり進めたい。初心者にむけては、Rubyとかでロールモデルがあるので、検討していきたい
  • Okayama 10人目指したい。フリーディスカッションや、初心者と上級者が教えあうという場をつくっていきたい
  • Fukuoka 周りとの交流をもっとやっていきたい。

横山 彰子さん「perl-casual特別企画 Perlをするとこんないいことあったよスペシャル」

Topics

  • 更に自己紹介
  • Perlコミュニティに触れて
  • プチ独立までの経緯
  • フリーになり心がけている事
  • 今後の課題
  • 黒歴史、語ります
  • Perlコミュニティに触れて
  • プチ独立までの経緯
    • 今は会社を作るためにとりあえずフリーランスとして活動しました
    • 現在は某コンシューマ向けサービスを開発。AnyEventやCoroを使ってクローラを開発したりする
  • 重視していること
    • 自分の市場価値を知る
    • 市場の動向を知る。エンジニアとして何が流行っているのか。
    • 人気プログラミングランキング、Go、Objective-Cが急上昇。今はperlだけじゃなくて、Objective-CやAndroid開発のためにjavaができるなどが大事だと思う
    • 自分の強み弱みを知る
    • ロールモデルとなる人を見つける。エンジニアとしてどういうふうに進んでいきたいか
  • 独立前にしたこと
    • 最低限の生活費を計算する
    • 利益の目標額を決める
    • 時間的なコストを考える
    • 営業活動
    • 見積書や請求書や契約書作り
  • フリーになってから心がけていること
    • なるべく自分を褒めてあげる。必要以上に責めない
    • いろんな人の意見を聞くこと。悪い意見も含めて
    • 手帳、マインドマップを駆使し、必ず目標と現在のステップを見直す
    • 戦略的に行動する。今の仕事がなくなったとしてもちゃんと生きて行けるように。
    • 最初はなんでもいいので、とりあえずブログ書いてみる
    • コードとか晒してみる
    • イベントで発表してみる（主催してみる）
    • アウトプットを続けているといろいろ相談してもらえる
    • Perl最高。ありがとう
  • 今後の課題
    • 孤独と向き合う
    • 自分でただしいことを選択する。お金儲けのためにモラルに反することはしたくない
    • CPANモジュールを書くこと
    • とりあえず法人化したい
  • Perlによって得られた物
    • 尊敬できる人たちと関われる
    • 他の言語もわかるようになる。個人的にpythonとかも触れ始めている
    • 大きく年収アップ
    • Perlでお仕事できる

Yusuke Wadaさん「perl-casual特別企画 NoSQLで作るTwitter解析サービス」

  • NoSQLな話はあまりしません
  • クロール＆表示型サービス
    • Plaggerブーム時代から個人で作成
    • CrawlerでDBに入れて、加工してWebAPPで表示
  • 基本システム構成
  • リソースとしてのTwitterの登場
    • 圧倒的な情報量(4000万tweet/日)
  • Twib
    • Twitterホットエントリー
    • つぶやかれているURLを収集
    • 人気順に並べる
  • Version 0.01
    • 2009/8/4リリース
    • 3万Tweet / 1day
  • Version0.02
    • 2010/7/5
    • 80万 tweets / 1day
    • 携帯アプリtwittieとの連携
  • Version0.03
    • mongodb採用しかけた
  • Version0.04
    • 急遽やめた
  • 運用環境
    • 自宅サーバ
    • App/DBx2/Worker - これらを各アプリで共有している
  • アプリケーション構成
  • Twitter解析のポイント
    • 更新が速いのでデータ量が多くなりがち。
    • とにかく早くどこかへ格納して、解析する際に非同期で処理をする
    • 情報のプライオリティを決める
  • tweetの取得
    • Search APIとStreaming APIの併用。リンクを含むツイートはhttpで検索するというシンプルなロジック
    • 解析を非同期で行う。URLの情報（タイトル／ようやく）を取得する必要がある。tweetごとに処理していては間に合わない
  • ジョブキューによる非同期処理
    • Job 仕事 = 仕事の名前とパラメタ
    • Client - 仕事を依頼する人
    • Worker - 仕事を受ける人
  • gearmand Cの実装を使っている。
    • workerは60プロセス。URL情報の取得をWorkerにやらせる。WorkerがDBに登録する
  • Webページ情報の取得
    • 短縮URL - リダイレクト先をみて「展開」させる。tweetされたURLと展開されたURLのペアをキャッシュ
    • 要約HTMLの取得。HTML::LDRFullFeed。だめだったらHTML::ExtractContentを使う
    • 特徴画像の抽出。Content-TypeとContent-Lengthを見て判断。画像サイズが一定サイズ以上なら特徴的なデータと判断
  • 情報のプライオリティを決める
    • Twibの場合は「直近のランキング情報」に価値がある。
  • バックエンドの評価
    • 信頼性をすてて速度重視なら間違いなくgearman
  • MongoDBをやめた理由
    • Shardingは嬉しいがリソース予測がしにくいのでやめた
  • 特化した機能はAPI化させる
  • ポイントのまとめ
    • tweetを速く集める
    • プライオリティを決めてデータを扱う
    • ボトルネックはDBとジョブキュー

sugyanさん「perl-casual特別企画 とある自社サービスの運用事例」

発表資料：http://d.hatena.ne.jp/sugyan/20101017/1287249719

  • wonderfl.net
    • 2008/12〜
    • オンラインでActionScript3.0のコードが書ける
    • ユーザのFollow、コードのFavorite、Forkして他の人のコードを改造できる
    • ライブコーディング機能
  • jsdo.it
    • 2010/06〜
    • wonderflと同じようなしくみ
    • JavaScript, HTML5, CSS3をブラウザ上で書ける
    • 今回の発表資料もjsdo.itで作っている
  • wonderfl.netの構成
  • jsdo.itの構成
  • Catalyst
    • DBIx::Class、Object::Containerベース
    • ViewはTT
    • 設定はひたすらYAMLで
  • daemon
    • memcached - セッション情報。閲覧頻度の高いコンテンツ
    • gearmand - 重い処理はバックグランドで
  • wonderfl.netコンパイラサーバ
  • Webサーバの変遷
    • lightpd + fcgi時代 〜2010/03。再起動時は予備プロセスつくったりで面倒
    • 2010/03からPlack & Server::Starterへ
    • 今はnginx + Starletで。設定変更してもダウンタイムなしで何でも変更できる
  • 認証の話
    • OpenIDでログイン、Google, Yahoo. mixi, livedoor, はてななど
    • 認証IDとユーザプロフィールを紐付ける。
    • 2010/07〜OAuthでもログイン可能になった
    • ユーザと認証IDを１対多に。GoogleでもYahooでもTwitterでも１つのユーザとしてログインさせたい
    • UserとUserAuthテーブルをhas_manyで実現
    • ついでに導入してみた。Authorization::Roles。UserとRoleを紐付け、チェックできる
  • 今後の展望
    • TTからXslateへ
    • コードの共通化(似通ったサービスだけどコードが別になっている)
    • 検索システムの改良(Solrなど検討している)
    • jsdo.itでもライブコーディングとか
  • 個人的雑感
    • Catalyst, DBIx::Classようやく少しずつわかってきた。慣れれば使いやすいし情報も多い点で、スタンダードなものはよい。何にしてもまだまだ経験不足、もっといろいろ触れてみよう。

Tatsuhiko Miyagawaさん 「Keynote - The Tale of Plack」

  • PSGI/Plack。仕様がPSGI、実装がPlack
  • アプリケーションは単純なコードリファレンス。
  • Plackは１年前に始まった。この１年で急速に広がり、導入が進んだ。他のYAPCでも取り上げられている。
  • なぜPlackは成功したのか？
  • 1) Good artists borrow, Great artists steal. 借りるよりも盗んでしまったほうが偉大。
    • HTTP::Engine WSGI/Rackにインスパイアしていたけど、既存のものにひきずられていた。borrowしたがstealまでいかなかった。
    • Plack - Stolen from Rack & WebOb.py 名前空間も含めてほとんどRackをコピーしている
  • 2) We were coming in late.
    • WSGI: Dec 2003, Rack: Aug 2009 (0.9) Ruby on Rails
    • 遅く来るといろんな物が残っている。始めるタイミングが遅かった分、何がうまくいって、何がうまくいかなかったかがわかる。
  • 3) JFDI
    • 誰かの許可を得なくてもコードは書ける。IRCで２時間ぐらいしゃべった後、最初にリポジトリをつくったのはtokuhiromさんだった。やれる人がやればいい。
  • 4) Shut the fuck up and write some code.
    • うだうだ言ってないでコードを書こう。
  • 5) TIMTOWTDI - Tim Toady ( Larryさんのニックネーム)
    • BSCINABTE- But sometimes Consistency Is No A Bad Thing Either。Mooseのようにオブジェクトシステムを共通にするのも悪くない。
    • PSGI - ひとつの統一インタフェースを介することによって、サーバとフレームワークの組み合わせに自由が生まれた。
  • 6) Keep It Simple and Stupid
    • PSGIの仕様は、バカみたいな仕様で、Perlのネイティブなコードリファレンスと、Arrayリファレンス、ハッシュリファレンスにした。それが最もシンプルだから。
  • 7) Perl a glue language
  • 8) コンピュータサイエンスで難しいこと cache invalidation and name things
    • Too may ::'s !
    • タイプするのがめんどくさい。話すときもめんどくさい。省略して書くようになる。読めないし新しい人はわからない
    • Again, steal from Ruby できるだけ名前をトップレベルに。Starman、Twiggy、Starlet
    • 名前をつけるのは大変な仕事。でも名前をつけることで愛着もわくし、意思疎通もとりやすい。名前をつけるのは重要
  • 9) 一番だいじなのはやっぱり人

Perl glues people together.

YAPC::Asia Tokyo 2010 1日目

gihyo.jpさん(http://gihyo.jp/news/report/01/yapcasia2010/0001)さんでのレポートの下書きをおいておきます。

Kazutake Hiramatsuさん「Modern Perl Web Development on Amazon EC2」

  • Plackを使ったPSGIなWebアプリの作り方
    • PSGIって何？ Perl Web Server Gateway Interface。
    • PSGIアプリケーションとは？PSGIの使用に従ったWebアプリケーション。本体は単なるPerlのCode Reference。CGIの環境変数ライクなハッシュを受け取って、Array refを返すという仕様。
  • Plackについて
  • plackupの使い方
    • app.psgiを指定してkidou
    • -sでサーバとして使うモジュールを指定。これでサーバ実装を変更できる。-s Starmanと指定するとPlack::Handler::Starman
    • -Lでpsgiアイルをロードする方法を指定
    • plackup -s Starman -L Delay app.psgi
    • 本番運用するならStarmanかStarlet
  • StarmanとStarletの違い
    • Starman Graceful restart with HUP (No hutdown with QUIT yet)
  • Startlet
    • Graceful restart, Graceful Shutdown
    • miyagawaさんのwiki
  • -LでPlack::Loaderの指定
  • DelayedとShotgunの番
    • -L Delayed 最初のリクエスト時に子プロセスでpsgiをロード
    • -L Shutgun Copy on Writeが有効になって効率的？。でも実際にはかるとDelayedのほうが速かった
  • Server::Starter
    • SIGHUPによるGracefu restartをサポートするサーバプログラム
    • plackupをstart_serveｒで起動するとgraceful restartがサポートされる
    • start_serverのintervalオプション。SIGHUPを受け取った後respawnするまでに要する時間（秒）。shutdownに1秒以上かかるサーバの場合この値の調整が必要
  • PSGIアプリの書き方
    • おすすめは、自分で簡単なフレームワークを作ること
    • CPANモジュールを使えば容易。そのほうが挙動を把握できる
  • おすすめモジュール Plack::Request
    • リクエストパラメータの取得に仕様
    • そのまま使うのではなく、継承して拡張
    • Object::Applyというモジュールを使って、flagged utf8へdecodeする
  • DBIx::Skinny
    • 軽くて速い
    • SKINNY_TRACE=1でSQLを出力してくれる
    • connect_options => [ mysql_enable_utf8 => 1 ]でDBから取得した値をflagged utf8へ
  • Router::Simple
    • URLからコントローラへのディスパッチ
    • WEB APIつくるときとか
  • JSON::XS
    • JSON出力で使う
  • daemontoolsを使ったwebサーバの運用
    • デーモンを制御するためのツール
    • /service配下にサービス用のディレクトリを作成し、直下にrunファイルを置くと、runファイルに書かれたサービスをデーモン化してくれる
    • start_serverをdaemontools経由で使用
    • コンパイルエラーになるので、src/error.hの書き換えが必要
    • svcコマンドがわかれば十分。-u:でサービス起動、-d:サービスの終了 -h:サービスへのSIGHUP送信
    • runスクリプトは普通のシェルスクリプト。execでプログラムを起動するのがポイント
  • cpanmを使ったCPANモジュールのインストール
    • CPANモジュールは全てcpanm管理
    • root権限いらずで、ホームディレクトリにインストールしやすい
    • -lオプションでディレクトリを指定してモジュールをインストールできる
    • 環境変数PERL5LIBを追加
  • Amazon EC2上でのWebアプリ構築、運用
    • Amazon EC2といっても、アプリケーションレベルの構築方法に大きな違いはない
  • AmazonEC2のサーバ環境
    • Small Instance メモリ1.7G
    • CentOS 5.4(32bit)
  • DBサーバ
    • Large Instance メモリ7G
  • 構築に関しての疑問
    • サーバのIPアドレス変わるって本当？
    • DISK内容が保持されないって本当？
    • 負荷分散は？
    • アプリケーションのデプロイは？
  • サーバのIPアドレス変わるって本当？
    • インスタンスをTerminateしたときなど、IPだけでなく、DNS名も変わる（可能性がある）
    • WEBアプリケーションで、DBサーバだと致命的
  • Elastic IPを使って、DNS,Global IPを固定化できる
    • 内部からのDNS問い合わせはPrivate IPを返す
    • Webサーバに関しては使っていない（オートスケールを使いたいので）
  • DISK内容が保持されないって本当？
    • インスタンそのTerminateで、破棄される
    • EBSかS3を使う
    • DBサーバはEBSブートを使ってインスタンスを起動
  • 負荷分散は？
  • アプリケーションのデプロイは？
    • オートスケールを利用していなければ特に困らない
    • オートスケールを利用している場合、インスタンスがイメージから起動されるので、元となるイメージを最新化しておく必要がある
  • デプロイ方法
    • Elastic IPを余分にひとつとっておく
    • テスト用のFQDNを登録し、Elastic IPで取得したDNS名に向けてCNAME登録する
    • テスト用インスタンスを起動し、そこへファイルをアップ
    • Elasticで取得したDNS名をテスト用インスタンスに結びつける
    • テスト用のURLでテスト
    • 問題なければイメージ化して、順次差し替える
    • ソースをNASやNFSに置く方法をとっているところもある
  • その他の注意点
    • amazon EC2でオートスケールを使う場合、IPアドレスが固定化されないので、任意のIPでlisten出来る必要がある
  • Amazon EC２の感想
    • 本質的な開発作業に大きな差はない
    • daemontools + Server::Starter + Starmanで問題なく動いている
    • Elastic IPを利用
    • オートスケールは便利
  • まとめ
    • Plackを使うとPSGIなアプリを簡単につくれる
    • StarmanやServer::Starterは本番サービスに投入できる品質
    • CPANモジュールの管理はcpanmを使おう
    • サービスの管理にはdaemontoolsを使おう
    • amaozon EC2上で運用する際は、amazon特有の環境に注意
  • 質疑応答
    • Q. daemontoolsのログの保存はどうする？
    • A. EBSなりに持っていかないとだめ。

Tokuhiro Matsunoさん 「モダンな Perl5 開発環境について - Modern Perl5 Development Environment - 2010年代を生きのびる Perl5 活用術」

  • Perl5をつかったウェブアプリの開発についてがメイン
  • Perl5のバージョン
    • いままではperl5.8系がメインだった。今は5.12まで出ている。それらの使い分けは？
    • system perl sucks。OS標準のperlを使うのは良くないと思っている。コンパイルオプションが一般的すぎる。threadが有効になっているとか。
    • ithreads sucks. no "-Dusethreads"。Webアプリケーションを書くときはthreadをoffにしておくほうがよい。これによりインタプリタの速度が15%程度高速化される
    • perl 5.10.0は良くない。正規表現使ったときにmemory leakするなどbugがある
    • perl 5.x.0は全体的に良くない。
    • perl 5.12.2が一番いいと思う
    • 安定志向ならperl5.8.9でもよい
    • 5.10以降の方がgiven/when, say, smart match, defined or (//), naped captureなど便利な機能が使える。smart matchは速度がでないなど良くない面もあるけど便利。//は地味だけど便利。0とか空文字列に起因するバグが減る。
  • perlbrew - 好きなバージョンのperlを使うために
    • perlbrew install perl-5.12.2
    • perlbrew switch perl-5.12.2 でバージョンを変更できる
    • 簡単にインストールできて、なにも考えなくてもいい。お手軽
    • ./Configure -des --Dprefix=/path/to/perl-5.12.2/ && make && make installでもそんなに変わらない
    • CPANモジュールはperl-5.12.2/lib/site_perl以下に入る。local::libを使う必要がない
    • こうやって作ったperl5をrsyncでばらまくだけ
    • gitで管理するのもあり
  • cpanm
    • From cpan to cpanm
    • 同期はCPANはメモリ使用料が多いのでvpsで動かなかった。
    • 今は使わない理由がない。no configuration, no relad
    • cpanm Acme::Damn
    • 依存モジュールをインストール cpanm --installdeps .
    • cpanm -l extlib/ Acme::Damn
    • cpanm -l extlib/ --installdeps .
  • cpan-outdated
    • インストールしたモジュールが古くなってしまう
    • cpanm App::Cpanoutdated
    • cpan-outdated で古いモジュールがリストされる
    • cpan-outdated | cpanm で一括最新化
    • cpan-outdated -l extlib/ | cpanm -l extlib/でローカルモジュールの更新もできる
    • cronで自動更新、自動テストもできる
  • cpanf
    • CPANモジュール、なおしてもらったけど、ミラーに反映されてないことがある
    • cpanm App::CPAN::Fresh 最新のミラーから取得できる。
    • cpanf -m Acme::Damnでcpanm経由でインストールされる
  • pm-uninstall
    • pm-uninstall Acme::Damn でモジュールをアンインストールできる
    • pm-uninstall -l extlib/ Acme::Damn でローカルモジュールにも対応
  • deployment
    • Perl5のディレクトリをrsyncするのがオススメ
    • アプリケーション特有のやつは、extlib/にいれておいてrsyncしよう
    • no rpm; no deb;
  • CPANモジュールの選び方
    • 8万モジュール以上ある。
    • 日付の処理をしよう。'Date'で検索 -> 3000package以上
    • 答え「みんながつかってるモジュールをつかう」
    • #perl-casual@irc.freenode.org で聞いたら教えてくれる
    • Twitterボット @perlism by @lestrrat
    • 答え「有名なPerl Hackerがつかってるモジュールを使う」
    • Task::BeLike::XXを使う。Task::BeLike::Tokuhirom githubにあります。
    • 自分で選ばないといけないとき。http://d.hatena.ne.jp/tokuhirom/20080520/1211292598
    • 2004年より前とかはかなり危険なかおり（枯れているものも中にはある）
    • Testがこけたまま放置されているのはメンテナンスされていない可能性が高い
    • t/以下を見て、テストの充実度を見る
    • Dependencies 依存モジュールがみれる。"D"を選ぶと依存しているモジュールも見れるので、どの程度使われているかもわかる
    • 有名な作者が作っているモジュールは安心
  • まとめ
    • みんなで使いやすくしているのでどんどん使いましょう
    • Perl is undead!
  • 質疑応答
    • Q. CPANモジュールをアップデートする際にunstableを見分ける方法は？
    • A. 基本的にはCPANには安定版しか上がらない。開発中はどんどんアップロードしてしまう。リリース後は気になったものだけアップデートしている。
    • Q. perlbrewを使っているときに、システムのperlとバージョン不整合になる時があるが、どうしたらよいか？
    • A. そういったケースに出会ったことはない。おそらくPATHなど環境系の問題ではないか。

Hiroki DaichiさんInside Mixi - ソーシャルネットワークを支える技術

  • mixiについて
    • 多様なデバイスに多様なユーザを
    • 2000万ユーザ。300億/PV
  • mixi development
    • 歴史の長いコード
    • 機能間連携多い
  • テーマ：二つのスケーラビリティ
    • Performance : アクセス数の増加や変動に耐える
    • Development : 機能追加や他人数開発に耐える
  • memcached
    • 揮発性KVS
    • 汎用キャッシュ機構
    • LRU
    • 願い事 - memcachedが落ちませんように
  • Cacheとは
    • 更新に対して、参照が多いデータの参照を高速に
    • いつ入れるか、いつ更新されるか
    • なにを入れるか
    • データ参照のホットスポットを発見して適応
  • 通常データ
    • keyからketamaで一意のノードから読み書き
  • 参照料の多いデータ
    • 同時に複数ノードに書き込み。読み込みを分散
  • Cache方式 リードスルー
    • 読み込み時にキャッシュに追加。実装が簡単。Aspect, Moose::Role、Class::Method::Modifierなどで透過的に実装できる
  • Cache方式 ライトスルー
    • 書き込み時にデータソースとキャッシュに書き込む。
    • memcachedは揮発するのでリードスルーと併用が必要。
    • 書き込み粒度と読み込み粒度を一致させる必要がある
  • Cache方式 変速的なライトスロー
    • DBに書き込んでから、マスターを読み出す
    • 読み込み時は、リードスルーと同様の実装
    • incrをうまく使い数を管理する
  • Cache対象レイヤ - カラム単位キャッシュ
    • 個別に参照頻度が高いデータ
    • get_multiなどで必要なカラムを収集して柔軟に使いたいケース
    • set_by_keyなど使えると局所性もコントロールできて高速にできるかもしれないが、利用はしていない
    • 削除タイミング。該当カラムが更新。データソース系モジュールで更新
  • Cache対象レイヤ - 行単位キャッシュ
    • レコード単位でキャッシュ
    • 該当レコード更新、データソース系モジュールで更新
    • 行単位キャッシュなら、handle socket pluginなどで置き換えたほうがよいかもしれない
  • Cache対象レイヤ - ドメイン単位のキャッシュ
    • サービス上のモデル分析の妥当性が重要
    • 大きすぎる粒度に注意
    • その範囲では仕様変更につよい
  • Cache対象レイヤ - サービス単位
    • 参照データ頻度が大きく、キャッシュやDBを複数個経由して出来上がるデータ。日記サービス、通知履歴など
    • 削除タイミングが難しい
    • Expireのみを期待する。ドメインごとの更新タイミングにフックポイントを仕込む
  • 粒度と抽象化
    • アクセス数や更新頻度に応じて適切に選択が重要
  • memcachedをキャシュ以外に仕様
  • memcached以外のキャッシュ
    • デーモン
    • プロセス間
    • プロセス内
    • リクエスト - mod_perl pnote
    • スコープ内 - sesshon
  • コードの複雑さを防ぐ
    • MVCの重要性。さまざまなデバイスに展開するとき。Controllerが肥大化していると苦しい
    • 複雑に各コンポーネントが依存しあうサービス要件
    • 広告やカスタマーサポートなど、色々なところに使われるサービスがある
    • 凝集度を高く結合度を低く
  • コンポーネント間の連携を定義する原則
    • 基礎ライブラリ、フレームワーク、サービス、アプリケーションを定義。レイヤ間の依存関係を決定。レイヤごとに品質規準を定める
  • システムコンポーネント
  • JobQueueサーバを利用してユーザの行動をフック
    • シェーピング - 突発的な負荷を緩衝して、スパイクを避ける
    • Joinの代替 論理／物理 - 複数ソースにまたがっている関連情報を一貫させる
    • 副次的な要件の処理 - 異なる責務領域で必要になる処理
  • JobQueueでPublisher-Subscriber
    • add_daily日記作成時に、 イベントを作成。関連するモジュールがそれぞれ非同期に処理。
  • ModelのCRUDにフック
    • 個別コードの事情や構成に詳しくなくても利用できる
  • CRUDを補足したサービス
    • 日記コメント、日記イイネ！
  • まとめ
    • 二つのスケーラビリティ
    • 両方共最終的には似てくる
    • 責務の分散構成と負荷の分散構成は似てくる

Lyo Katoさん「DataPortability and SocialWeb Protocols」

  • DataPortability - http://dataportability.org
  • SocialWeb界隈
  • Others
    • Atompub - RSSのように記事を決まった形で表示するだけではなく、RESTfulにデータ交換ができる
    • Salmon - Aggregateされた先で付けられたコメントでデータ提供元にもどってくる
    • oEmbed - URLが画像だとその場に展開
    • Pubsubhubbeb - Web Hook。HTTPでリアルタイムのプッシュを実現
    • SAML - エンタープライズ領域での認証技術基盤。OpenIDやOAuthより機能豊富。その分複雑
  • OpenID/OAuth
    • Service Ecosystem。IdPとSPにわけて考えることができる。IdPを持たないサービスは、OpenIDを利用できる
    • smartfmがたくさんのOpenIDプロバイダに対応している
    • OpenIDのクライアントはIDを取得できる。拡張を使えばプロフィール情報などの属性も取得できる
    • 他のサービスの機能を、認証情報をわたさずに使うのがOAuth
  • Access Token
    • 誰がどのサービスに何のデータをいつまで使わせるかという委任状のようなもの
    • OAuth::Lite - mixi, DeNA, モバゲーでも使われている
  • SGP(Social Graph Provider)が出てきた
    • Social Graphの部分をかりてサービスを作る > OpenSocial
  • OpenSocial
    • 大きく分けて、Gadget APIとRestful APIがある
    • opensocial公式ページでPerlライブラリがない
    • Net::OpenSocial::Clientを作った。RESTful APIに対応しているところが少ないため、使いどころが少ない。
  • OpenIDとOAuthの相違点
    • OpenID - 認証をOPに移譲
    • OAuth - OPに認証を移譲しているといえなくもない
    • IDの取得、OpenIDでは仕様で定義されているが、OAuthでは定義されていない。だがOAuthでは認可後にプロフィールとして提供は可能
  • 認可
    • OpenID - AX, SREGなどの拡張でユーザ属性の取得は可能
    • OAuth - トークンの認証方法は仕様で定義。ユーザデータのフォーマットは未定義
  • Fedaration
  • OAuth2.0
    • SSL必須（署名がなくなった？)
    • session, scopeの標準化
    • Request Tokenがなくなった
    • Web以外での利用も？
  • Profiles
    • WebServer Profile - Webを使った３者間の認証
    • UserAgent Profile - デスクトップアプリケーションなど
    • Username and Password Profile - XAuth
  • OAuth::Lite2
    • OAuth2.0対応(draft10)
    • Plack対応(Server側)
    • クライアント側は署名がなくなればライブラリいらないかも
    • サーバ側はOAtuth::Lite2::Server::Handlerを継承して実装する。プロトコルを熟知していないとかけない
  • OAuth on Native App
    • HTML5, CSS3
    • Bluetooth, GPS, APNS, C2DM
    • カメラ、マイク
    • AppStore, android market
    • デバイスとサーバ間の連携にOAuthが要求されるシーンが増えてくる
  • tips and traps
  • Twitter OAuth事例
    • secret埋め込み問題 - OAuth for OpenSource
    • サービス間連携 - OAuth Echo
    • その他 - XAuth
  • OAuth for OpenSocial
    • 最初にKeyを与えると、keyとsecretなどが帰ってくる。最初にkeyはsecretがないので詐称される可能性はある
  • xAuth
    • usernameとpasswordを直接わたして、Access Tokenを返してもらう
  • tips
    • カスタムURIを使う
    • application:handleOpenURL
  • Tokenのセキュアな保存
    • ローカルマシンへの保存を気をつける
    • 暗号化
    • アクセスコントロール
  • Adobe AIR
    • SharedObjectは使わない
  • android
    • Shared Preference
    • Account Manager - OSがアカウント情報を統合管理する仕組みを持っている
    • new Contacts API
  • まとめ
    • OAuthはそろそろ必須技術
    • nativeアプリを作るときはいろいろ注意が必要

Jiro Nishiguchiさん「Write Good Parser in Perl」

  • パーサとは
    • なんらかの意味をもったテキストを、その後の処理に適した形にする
    • 「正しく」「動作」して「あたりまえ」という期待
    • 重要なのに、空気なような存在
    • ベンチはとられまくりでかわいそうな子
  • Kind of parser
  • Perlでよく使われているパーサ
    • HTML::Parser
    • XML::LibXML
    • JSON, JSON::XS
    • HTTP::Parser::XS
    • Template-Toolkit
    • Cache::Memcached - getリクエストのあとにもどってくるレスポンスのパーサ
  • HTML::Parser
    • Since 1996
    • Depended on by 408 modules (HTML::FillInFormなど)
    • Written in XS
    • 手書き（自前で１バイトずつ進めている
  • XML::LibXML
    • Perl binding for libxml2
    • XMLの代表的なパーサ
    • Depended on by 267 modules (Plaggerなど)
  • JSON(::PP)
    • Standard JSON module
    • Wrapper of JOSN::PP and JSON::XS
    • Pure Perlで手書き
  • JSON::XS
    • 高速なJSONパーサ
    • 手書き
  • HTTP::Paraser::XXS
    • Plackで使われている
    • Writtern in XS
    • 手書き
  • Template-Toolkit
    • Pure Perl
    • Based on Parser::Yapp
  • Cache::Memcached
    • getコマンドのパーサ (::GetParser, ::GetParserXSもある）
    • 手書き
  • Why XS?
    • Perlのテキスト処理は遅い（Cに比べて）。とはいえ正規表現など非常に高速なので普段は問題ないことが多い
    • 1バイトずつ読み進める処理はCが高速。perlだとsubstrなどでオーバーヘッドが大きいため
  • How to write - 手書き？
    • 自由度は最も高い
    • プログラムの腕によっては最高速になることも
    • 怠惰なプログラマには向かない
  • How to write - 既存モジュールを使う
    • 可能な限り新しいフォーマットを作らないのが重要
    • 既知のフォーマットを自作するといいことはない。バグを生みやすい
  • How to write - 正規表現ベース
    • 書き捨てに、小規模に便利
    • 十分に速い
    • 規模が大きくなってくるとメンテナンスが大変
    • Regexp::Assembleを使えばかなり頑張れる
  • Parser generatorとは
    • 文法などの定義情報からパーサを生成する
    • 怠惰なプログラマにうってつけ
    • yacc(bison)
    • Parser::Yapp, Perse::Eyapp( Exteded yapp), Parse::RecDecent, Pege, Ragel
  • Ragel
  • Ragel + XS
    • ステートマシンの定義を書く
    • パースする関数をCセクションに書く
    • 分かりやすく宣言的に書ける
  • XSいやなんですけど・・・
    • データ構造を作って返すだけ
    • 文字列結合や配列、ハッシュが触れればOK
  • (例)ログ解析
    • Benchmark 5倍ぐらい速くなった
  • まとめ
    • ログ解析などあまり変更しなさそうなものは、パーサジェネレータとXSで高速するといいかも
    • 保守性と速度のトレードオフ

Seiji Haradaさん「mixi チェックインの裏側」

  • mixiチェックインについて
    • 「mixiチェックイン」は、携帯電話のGPS機能を利用して、今いる場所やお店（スポット）を簡単に友人・知人に共有できる『mixi』の新しいコミュニケーション機能です。
  • スポットの絞り込み方法
    • geohashの前方一致。geohashとは緯度経度の範囲を文字列で表す仕組み。
    • geohash表現をbase32して、2進化。奇数番目が経度、偶数番目が緯度となる
    • geohashが短いと範囲が広がる
    • 落とし穴。矩形の端っこの場合。桁数を削って範囲を広げると無駄になるので、周りの部分を矩形をとってきて処理する。
  • 高速化
    • geohash - 計算処理が多いので早くしたい
    • mysqlで無駄なクエリを減らしたい
  • 高速化 - Geo::Hash::XS
    • Geo::Hash -> Geo::Hash::XS ベンチマークとったら140倍〜200倍速かった
    • 隣接するgeoashを求めるadjacentメソッドもある。
  • 高速化 - mysql
    • キャッシュ化- スポット情報が頻繁に変わらない
    • 検索は６文字のgeohash -> 6文字のgeohashをキーにしてMemcachedに積んでいる
    • スポットの多い関東と関西をキャッシュ
  • まとめ
    • 6文字のgeohashによる前方一致で絞り込み
    • GPSの精度があがれば７文字もあり
    • 最小で１つ、最大で４つのキーで検索
    • 検索範囲は半径250mでキーの平均値は2.66個 ( 実機で実際はかったときの最大ズレ幅 )
    • 位置情報を楽しもう！

keroyonnさん「非同期タスクの通知処理 with Tatsumaki」

  • 月々7000円の小遣いでコツコツと旅費をためてきた
  • Web越しにガンガン登録される重いタスクを
    • リアルタイムに
    • 待ち時間を感じさせずに
    • リソースを食いつぶさずに処理したい
  • 解決策 - みんな大好きCGI
    • ブロッキング、ストリーミング
    • Ajaxとか使わないのでUIがブロックされる
    • コード的には$=1を指定してprintでちょっとずつ出力
    • ブラウザがずっとローディングになる
  • クライアント側を非同期化してみる
    • multipart/mixed, boundary = "ABC"
    • CGI側でboundaryを出力しながらコンテンツを出力する
    • クライアントDUI.jsで処理
    • １プロセス１処理なのでC10K問題をもろに受ける
    • ストリーミングはC10K問題の影響を受けすぎる
  • PSGI/Plackストリーミング
  • PPSGI/Plackストリーミングの弱点
    • 同期IO処理ができない
    • CPU使う処理ができない
    • multipart/mixedとか面倒
  • 解決策その１ Tastumakiを使う
  • 解決策その２ Gearmanを使う
    • 重いCPU処理が苦手という欠点を補うジョブキューサーバ
    • クライアントからはAnyEvent::Gearman::Clientでブロックしないように
  • 解決策その３ WebService::Async
    • keroyonnさん作のモジュール
    • 非同期処理が簡単に書ける
  • まとめ Tatsumaki, Gearman, WebService::Asyncを使えば非同期処理も恐れることはない

吉見 圭司(walf443)さん「Webサービスのページング処理について」

  • RDBMSからデータを取得して、それを出す際の話
  • ページングとは、１ページに収まらない結果をわけること
  • 典型的なやりかた
    • 典型的なページング方法 limit 50 offset 10;
    • トータル件数はcount文で
  • 利点
    • たいていの場合に使える
  • 欠点
    • Group byでうまくいかない
  • 時間がかかるクエリの場合の対策
    • インデックス効くように
    • memcachedでキャッシュ - 結構面倒なことが多い
  • 別のやり方
    • MySQLのCALC_FOUND_ROWSを使うと、その直後にselect FoundRows()を実行するとトータル件数が取れる
    • 二度計算しないので、Countよりはマシ
    • limitによるmysqlの処理打ち切りが動作しなくなる
  • 次のページがあるかどうかだけを調べる方法
    • １件余分にとれば判断できる。
  • perlでページング処理するのはData::Pageが一般的
  • 一般的な一番コストがかかるのは、「トータルな件数」を求める処理
  • DBIx::Skinny::Pager
  • ページング周りの小技
    • データのないページにアクセスしてくるユーザ対策
  • あまり軽くできないSQL
    • 全文検索ページとかどうしても速度がでないところでは、10000件とか多めに取得しておいて、cacheに突っ込む
  • 質疑応答
    • Q. ページング処理中にデータが増えた場合表示がずれる可能性があるがどう対処するか
    • A. タイムスタンプなどを保持しておいてページングすれば解決できるのでは

Shibuya Perl Mongersテクニカルトーク#14に行ってきた

多分5年ぶりぐらいにShibuya.pmに参加してきた*1
個人的に気になったところをメモ。

詳細な解説はid:hirataraさんのメモを参照されるのがいいと思います。

http://d.hatena.ne.jp/hiratara/20100930/1285815873

Perl6 Language Update by 小飼弾さん [twitter:@dankogai]

Perl6新機能の紹介。FizzBuzプログラムをとして機能を紹介するという内容だった。
ローカルスコープな名前付き関数が書ける話や、例外処理構文、遅延評価リスト、マルチディスパッチ
（Javaでいうオーバーロード）、OOの話などがあった。
Perl6式OOはPerl5でもほぼMooseやMouseで実現できるけど、ドットでのメソッド呼び出しはPerl6じゃないとできないとのこと。
またPerl6では例外処理のCATCH文はtryの内側に書くということで、聞いたときは変な構文だとおもったけどgfxさんのツイートを見て良さを納得。

ぼくのかんがえたさいきょうのYAPC::Asia – 櫛井さん [twitter:@941]

YAPCの凄いところの紹介。特に気になったのは景品。MBPのMemory8Gは欲しいなぁ。発表しないので無理だけど。。。

JPA活動報告 – 牧さん [twitter:@lestrrat]

941さんの発表とは違い笑うところはない真面目な活動報告。
Web+DBプレスのリレー連載はJPAが監修していて、今のところ2月までは継続確定らしい。

memcached injection – 佐名木智貴さん

プロトコルは簡単なテキスト形式で、キー名に関してはエスケープ方法が規定されていない。
PerlのCache::Memcachedなどはキーをエスケープしていないのでアプリケーション開発者が意識する必要がある。
JavaライブラリはURLエンコードしてくれるものがあるとのこと。

memcachedの運用監視ノウハウ – 長野雅広（ライブドア）さん [twitter:@kazeburo]

memcachedの監視方法について。twitter:kazuhoさん作成によるcronlogを使った監視方法や、Nagios Pluginの方法が紹介されていた。
個人的にはdaemontoolsなどを使った場合、勝手に再起動してしまうのでどうするのか気になっていたが、uptimeで監視するという方法が紹介されていて参考にしたいと思った。

監視で大事なのはPDCAサイクル、自動化、可視化とのこと

パネルディスカッション - 身につけておきたい、今そこにあるシステムの救命措置

脆弱性を報告してもなかなか対処してもらえない。1000日以上も放置されているものがある。この現状を打破するにはどうしたらよいかということのディスカッション。

  • 治してもらえない場合だけ公開する？1000日ルールとか。
  • サンプルが少ないと対応してもえない。IPAがスキャンして一定数以上のサイトを報告して、全体的にどれぐらいのサイトが脆弱性があるのかを公表しみんなで直していくのはどうか
  • セキュリティ規準を満たしたら、保険がかけられるとか。リスクが担保できるとなると頑張るのでは

などの提案があった。

とはいえ現場からしてみるとずっと可動しているレガシーコードを対応するのは厳しいよなぁという意見も。同感ですｗ

http://togetter.com/li/55216

Perl 1,2,3,4 の歴史 – 前田薫さん [twitter:@mad_p]

Perlの歴史の話。

などで調べられるとのこと。

Android + Perl – 伊藤直也さん (グリー株式会社) [twitter:@naoya_ito]

Scripting Layer for Android (SL4A)を使うと、perlでアンドロイドアプリが作れるらしい。
アンドロイド上でコードも書けるそうだが、かなりきついので、Emacsで書いてadbコマンドでインストールするとのこと。
結構さっくり動くらしい。
perlでWebViewを起動して、JavaScriptのcallbackをキックとかも出来るそうで、個人的にはiPhoneアプリ作成でUIはWebView, 画面制御系はObjective+Cで作成しようか検討していて、そうするとAndroid展開も楽かもと思っていたけど、同じような手法がしかもperlできるとなるとかなり楽できそうなので、そのうち試してみよう

Data::MessagePack – [twitter:@tokuhirom]さん

JSON::XSより高速、ストリーミングデシリアライザといった特徴をもつシリアライズモジュール。
C++, Ruby, Java, Haskell他様々な言語で実装されていて、異なる言語間でデータ交換する場合に効率的かつ容易に利用できる。

Storableと比較
利点
・速い！(gfx++)
・他の言語ともつかえる
・データサイズがちいさい
欠点
・blessとかは使えない

JSON::XSと比較（かわった外人が作ったモジュール。コンパイラとか書いてるひとで非常に速い）
利点
・速い（ちょっとだけ）
・データサイズがちいさい
欠点
・バイナリなので人間がよみづらい

String::Filter 構造化テキストの正しいエスケープについて – 奥一穂さん [twitter:@kazuho]

最近あったTwitterのXSSの事例を元に、正しいXSS対策の紹介。
バグがあるプログラムのほうがXSSがあるプログラムよりも遥かにマシということで、セキュリティホールを生み出さない様な設計が重要という話だった。
具体的には、

にわけて設計し、後者さえ正しく行えば前者にバグがあったとしても安全ということで、あらためてエンコーディングはできるだけ最後にという基本を再認識させられる内容だった。

Perl Parser Hacks vol.2 – 藤吾郎さん[twitter:@__gfx__]

前回はperlのParser定義ファイルであるperly.yの紹介をしたが、これをいじるとPerlのソースコード全体を再コンパイルする必要があり大変なので、今回はPerlの新機能を使った手法の紹介。
plugable keywordと、parse fullstmtが紹介された。

pluggable keywordはperl 5.12から導入された機能で、任意のキーワードを追加できるものだが、パーサなどは自分で書かなければならず使いにくい人のこと。
pars fullstmtはperl 5.14に向けた新機能だが、単位がステートメント単位であるため粒度が荒く、使いどころが難しいかもとのこと

*1:その間興味がなかったわけではなくいつも気づいたら埋まっていたという。。。。最近はatndで気づけるので感謝 > twitter:@atnder

第2回自然言語処理勉強会＠東京に参加してきた

http://atnd.org/events/8140

「あずにゃんに関連する検索キーワード」→「あずにゃん　ペロペロ」を実現するクエリ推薦技術について [twitter:@y_benjo]さん

発表資料：http://d.hatena.ne.jp/repose/20100925/1285399983

ユーザが入力したクエリに「近い」クエリを推奨する技術に関する二つの論文の紹介。
ここでいう「近い」とは、「意味的に近い」ということ。

今回の紹介論文で用いるデータは以下のとおり

  • ユーザが入力したクエリ
  • 検索結果からどのページに遷移したかという情報
論文1: Query suggestion using hitting time

論文PDFリンク：http://research.microsoft.com/en-us/um/people/denzho/papers/sugg.pdf

手法

  • ユーザが入力したクエリと、アクセスしたページから二部グラフを作成する
  • そのグラフ上をランダムウォークし、クエリを推奨する

利点

  • 意味的に似ているクエリが推奨される
  • 共起していないクエリも推奨される
  • ロングテールに対応しやすい
  • パーソナライズしやすい

クエリ推奨の課題

この論文によると

  • いかにパーソナライズするか・・・MSRという略語をとっても、工学の人なら多分「Microsoft Research」、金融の人なら「Montage Service Rights」でしょう
  • ロングテールに相当するクエリにどう対応するか・・・広告分野において大きな期待が生まれる

実際は、本当にマイナー過ぎるなキーワードは推奨されずらそうだけど、単純な共起モデルよりは良い結果が出そうとのこと

論文2: Generalized syntactic and semantic models of query reformulation.

論文PDFリンク：http://www.google.com/research/pubs/archive/36337.pdf

  • 文字列の類似度と意味の類似度をあわせて一般化したクエリ推奨手法を提案
  • 生成モデルを使ってクエリを推奨してみた
  • 教師あり学習も適用

クリックログは用いない手法

  • PMI(Pointwise Mutual Information)というのがよくわからず、ついていけない感じ。。。。
  • 同じユーザが連続して入力したクエリを用いる
  • 評価指標にはスピアマンの順位相関というものを使うらしい。

FSNLP６章読みながら「nグラム入門」的なこと [twitter:@naoya_t]さん

発表資料：http://blog.livedoor.jp/naoya_t/archives/51478756.html

連続したn単語（ないしn文字）をひとつの塊としたもの。

n-gramには大きくわけて２種類ある

  • 単語nグラム
  • 文字nグラム
1) 文章の素性値としてのnグラム
  • 語彙リストが与えられているとして、ある文章における各語彙の出現情報をベクトルで表現したものをその文章の素性として扱う
    • 出現頻度を表現 -> 頻度ベクトル
    • 出現の有無を表現 -> 二値ベクトル
  • 単語の代わりにn-gramを用いることで語順も素性として扱える
2)n-gramで次に来る単語を予測
  • ある単語Wnの出現確率を、直前のn-1語の出現を前提とした条件付き確率で表す
  • n-1次のマルコフモデル
なぜn-gramで言語をモデル化するのか
  • n-gramは非常に単純な割に、驚くほどうまく行く（3-gramに勝つのは意外に難しい）
n-gramの残念なところ
  • 語彙数のn乗にほぼ比例して、メモリ空間やらCPU時間やらを消費
  • 賢くするには超巨大なコーパスが必要
n-gram残念解消法
  • n-gramのnを減らす ・・・ 実用的な範囲で、2とか3がよく用いられる
  • 語彙数を減らす ・・・ stemming, lemmatization (見出し語化)

Latent Dirichlet Allocation入門 [twitter:@tsubosaka]さん

発表資料：http://d.hatena.ne.jp/tsubosaka/20100925/1285424360

機械学習ライブラリmalletを使う。

単語は独立に出現しているのではなく、潜在的なトピックを持ち、同じトピックを持つ単語は同じ文章に出現しやすい

何の役に立つのか？
文章生成モデル
  • 各トピックごとに単語出現確率をディリクレ分布から生成
  • 文章ごとにトピック確率をディリクレ分布から生成
推論アルゴリズム
  • Gibbs samplerを使ったパラメータ推定ほうがよく用いられる
Mallet

Javaベースの統計的自然言語処理、文章分類、トピックモデリングなどのパッケージ

  • CsvIterator - 行志向のデータを読み込むのに便利

Mozcソースコード徹底解説 [twitter:@nokuno]さん

発表資料：http://d.hatena.ne.jp/nokuno/20100925/1285429764

Mozcのアーキテクチャ
変換エンジンの設計
  • 疎結合な階層構造を採用
  • ipc > session > converter > storage
コンバータ層の設計

かな漢字変換としてはオーソドックスな設計

  • 言語モデル：クラスbigram
  • Viterbiアルゴリズム・Lattice構造
  • 品詞情報を使って文節にまとめ上げ
  • 文節内の候補にNベスト解探索
確率モデルによるかな漢字変換
  • 確率的言語モデル P(x)　出力ｘがどれだけ日本語としてただしそうか
  • 確率的仮名漢字モデル P(y|x)　xのよみがyである確率
言語モデル：クラスbigram
  • クラスの接続コストと単語の生起コストを合計
クラス定義
  • 品詞 - IPAdicの品詞体系
  • 単語クラスタリング - 同じ品詞の単語をいくつかのグループにクラスタリング
  • 語彙化 - 助詞や助動詞などの頻度の高い単語をクラスに昇格
ソースコード：辞書ファイル
  • 左ID、右ID - 複合語の場合異なる
ラティス構造
  • 全ての変換候補をコンパクトに表現
経路探索：Viterbiアルゴリズム - 線形時間で経路を探索
ストレージ層

IMEは常駐するのでメモリ使用量を最小限に抑えるよう工夫

  • LOUDSによるコンパクトなTrieインデックス
  • ハフマンコーディングによるバリューの圧縮
  • 接続コスト格納のための疎行列の圧縮
  • NG語彙フィルタのためのBloom Filter
  • LRU(Least Resently Used)キャッシュ
データ構造：Trie
  • 文字をノードとする木構造インデックス
  • 豊富な検索操作
    • 完全一致検索
    • 前方一致検索
    • common prefix search - (teaを検索するときに、tとかteとかの途中の単語も高速にヒットする)
データ構造：LOUDS
  • ビット配列でえ木構造をコンパクトに表現
  • ノード数*2+1 で表現できる。
  • 実際には高速化のため補助インデックスも必要
  • rxというライブラリのコード。かなりキモいｗ
  • 岡野原さんのtx読んだほうがいいかも。
Rewriter候補の書き換え - 様々のヒューリスティックを実装
  • 学習機能（文節区切り、文節内の順序）
  • 共起コーパスの反映
  • 数字、単漢字、記号変換昨日
  • 日付変換昨日、顔文字変換昨日、電卓機能
  • 福笑い機能、おみくじ機能
予測変換のアルゴリズム
  • SVNにより生起コストや品詞を考慮した予測変換
Bloom Filter - 予測変換に出さない候補をフィルタリング
  • 仮名漢字変換と予測変換は辞書を共有している
  • 予測にだけ出したくない候補を動的にフィルタリング
  • 間違えてフィルターすることはあるけど、間違えてフィルターをすり抜けることはない
IMEは総合格闘技

クライアントアプリならではの難しさも
統計的な手法とヒューリスティックの使い分け

ナイーブベイズで言語判定 [twitter:@shuyo]

発表資料：http://d.hatena.ne.jp/n_shuyo/20100925/language_detection

言語判定
  • 言語の絞り込み付きで検索したい
  • 言語別のフィルタを適用したい（SPAMフィルタとか）
利用対象
  • Web検索エンジン - Apache Nutchではクローラに言語判定モジュールが付属（日本語は入ってない(><) )
  • 掲示板 - 多言語書き込み
世間にあるもの＞少ない
  • コーパス／モデルの構築が高コスト - 対象言語の知識がどうしてもかなり必要
  • アジア系のサポートなし
既存の言語判定サービス
既存のライブラリ
  • Lingua::LanguageGuesser
  • NGramJ

両方ともテキスト分類器の実装(TextCat)をベース - コサイン類似度

ナイーブベイズによる「言語判定」
  • 「言語」をカテゴリ
  • 特徴量には単語ではなく「文字n-gram」を使う
文字n-gramで言語判定ができる理由
  • 各言語には固有の文字や綴り字の規則がある
    • Zで始まる単語はドイツ語には多いが、英語にはほとんど無い
    • etc...
  • これら特徴に「確率」を設定し、文書全体に累積
    • tri-gramだとsparse過ぎる
    • uni-gramからtri-gramまで全部使う
言語判定の流れ
  • 学習：学習コーパスからp(Xi|Ck)を求める
  • 判定：対象テキストからp(Ck|X)を求める
「文字」について予習
  • 世界で使われる文字は大きく４つに分類される
言語系統と「文字」
  • 文字が同じで言語体系も似ていると判別しづらいというのがわかる
  • 文字が独特の奴は楽（日本語のかな）

漢字系 - 中国語と日本語のように書けば通じるというのは特殊。世界的には口頭は通じるが書くとわからないほうが多い。

日本語 - 現存する言語の中で、表意文字と表音文字が混在する唯一の言語

Rubyで検証
プロトタイプの問題点
言語判定ライブラリ for Java
当初まったく精度がでない
  • 精度低下の原因
文字の正規化 - これが本題
  • 基本 - stop characterの除外
  • 文字種全体を代表となる１文字にまとめる
  • etc
CJK漢字
  • K-meansによるクラスタ分類 - tf-idfを特徴量で50クラスに分類（アルファベットにあわせた）
  • 常用漢字による分類

感想

  • 各発表の時間が比較的長めだったので、濃い内容でよかった
  • 英文も論文も読み慣れていないので、こういった論文紹介は個人的にとても有り難かった
  • Query suggestion using hitting timeの方は自社の検索ログでも実装できそうと思ったけど、改めて見直すと理解できてないな。。。。orz...
  • でも面白そうなのでプロトタイプぐらいは作ってみたい
  • n-gramは自社検索で使っていて*2おなじみだったけど、全文検索エンジン以外での話で単語のつながりとかを確率的に扱う話は個人的に始めてだったので新鮮だった*3
  • LDAの話はLDAって何って状態*4だったのでイマイチ消化しきれず。Malletというライブラリは覚えておこう
  • Mozcの話はまとめにあった「IMEは総合格闘技」の言葉通り、幅広いなぁという印象を受けた。データ構造系のところはTrieとかBloom Filterとは単語はよく聞くけどよくわかっていないので特に復習したいと思った
  • id:nokunoさんの資料は「ぷるむる」復習レーンでもいつもよくまとまっていて個人的に非常に分かりやすい
  • 言語判定のはなしは事前のタイトルからは想像できない、実践的で非常に泥臭い内容。各国語の特徴とか調べるの凄い大変そうだと思ったけど、そういったノウハウを惜しげもなく公開されているという意味で貴重な発表だった。日本語は難しいなんて話はよくきけど、やっぱりかなり特殊な言語なんだな

Togetter

http://togetter.com/li/53740

*1:本当はダメだけど。後のプロダクションコードはちゃんと正規化した

*2:そしてノイズに悩んでいて・・・

*3:単に不勉強なだけですが。。。orz...

*4:ディリクレ分布とかPRMLで出てきたなぁ。。。

クックパッド主催-「開発コンテスト 24」参加体験記

http://info.cookpad.com/24contest

賞金というよりクックパッドに入りたかった（？）ので、参加してみた。

応募アプリ概要

作品名：おはようタスク

概要：朝の貴重な時間を有効活用するためのアプリです。出社時間までの限られた時間のなかで優先度の高いタスクを確実にこなせることをサポートします。音声通知もサポートする予定です。

（応募文書は保存してないので改めて書き起こしました。よって応募時点とは異なります。。。）

開発ログ

  • たぶん23日金曜日の夕方ぐらいにコンテストを見つけた。
  • その日はhbstudy10( http://heartbeats.jp/hbstudy/2010/04/hbstudy10.html )に参加予定があったので、ちょっと出遅れるなぁと思いつつ、なんか思いついたら参加したいとウォッチ。
  • 勉強会の終り頃にお台発表のツイート。気になって上の空になる。
  • その後懇親会に参加しつつ、コンテストのことが気になり半分ネタを考えている状態（ぉぃ
  • 24時前に帰宅。少し考えるもとくに良いアイデアも出ず寝る。
  • 9時頃に起きる。ネットサーフィンなどしつつアイデアを模索。
  • やっぱり出ないので少し外出。LABI渋谷でMacBookProを衝動予約。
  • 12時半頃飯をくって帰宅
  • ふと、大学同期のGiornoBrandoにネタ振りをしてみる
  • 1時間ぐらいメッセしたのち、このラフスケッチで行くことに http://f.hatena.ne.jp/usuihiro1978/20100427000519
  • Railsで開発る。
  • OpenID認証にしようとしてハマる。後で思えばこの時間が勿体無かった(><)
  • 認証は諦めて機能開発に取り組む。
  • 18時頃。あと最低あれとあれはリリースしないとなぁ。。。なかば諦めかける。
  • 「ダメでもあと3時間だ。走りきれ！」と自分を奮い立たせる
  • 19時頃。とりあえず最低限のとろ（全然足りてないけど）を作って見せる。
  • GiornoBrandoが「天気予報欲しい」と言い出すので、調べる。
  • 20時半頃なんとか天気予報実装を終える。
  • リリースに取り掛かる。

RAILS_ENV=production rake db:migrate

は問題なく通ったものの（やっつけで直してた部分があったのでちょっと怖かった・・・）最終確認でエラー！！再び諦めかける

  • なんとかクリアし、20時50分ごろ正常系動作確認
  • カウントダウンのFlash(だったかな？）が重くて初代MacBook Airは悲鳴を上げ気味の中（キータイプ遅延が発生。。。）、なんとか締め切り3分前ぐらいに投稿完了

反省点

アイデア出しでつまずいたため、開発に使えた時間は3分の1弱。間際まで開発にとられてしまったため、紹介文とか、アプリ説明とか十分にできず、痕になって後悔。。。。

感想

Rails力の不足もあって、思いのほかうまくいかない部分も多かった。

それでも開発を初めて締め切りまでの約8時間。ものすごく集中してできたし、自分の実力以上の成果は出せたんじゃないかと思う。デッドライン効果素晴らしいです。普段の仕事にも応用したいところです。

結果は当選にはならなかったけど、久々に開発の楽しさと、集中して取り組む快感を得られた有意義な時間でした。

P.S.

1) 同様の作品で応募されている方がいらっしゃいました。
コチラのほうが完成度が高い。。。。ｗ やりたっかった音声通知が実現されている！
http://d.hatena.ne.jp/suer/20100425/cookpad24contest

2) 作ったアプリは・・・・

そんなわけで応募後は完成度高めて公開しようとおもったけれど、
上記の通りより完成度の高い方がいらっしゃったので、スクリーンショットで自重します。。。ｗ

http://f.hatena.ne.jp/usuihiro1978/20100426235855

3) 雑感

GiornoBrando氏との共同開発が予想外に（？）楽しかったｗ

Special Thanks.
http://giornobrando.jimdo.com/

ReviewBoardでアジャイルにレビューしたい

Python

ReviewBoardはSCMにコミットする前のdiffをベースにしてレビューするためのツールです。

今の会社ではSVNにcommitしてTracのdiffとかでレビューしていましたが、ReviewBoardはコード行数に直接関連づけてコメントを残せるのがなかなか素敵です。
SCMにコミットしなくていいのでもっと早い段階でこまめにレビューができればいいなぁと思っているのですが、レビューの登録をブラウザから行うにはdiffをとってファイルに保存→アップロードという手順を踏まなければいけないため面倒だなぁと思っていました。
ただドキュメントを見ているとレビュー登録するためのスクリプトがあるらしく、これを使えばいい感じにできます。

1.インストール
simplejsonが必要なためあらかじめインストールしておきます。

svn checkout http://simplejson.googlecode.com/svn/trunk/ simplejson-read-only
cd simplejson-read-only
sudo python setup.py install

続いてスクリプトはダウンロードするだけです。適当にパスが通っているところに置いて実行権限をつけておきます。

http://reviewboard.googlecode.com/svn/trunk/reviewboard/contrib/tools/post-review

2.新規レビュー登録
とりあえず作業ディレクトリ上のソースを変更します。

コマンドを実行します。基本的にサーバを指定するだけです。
post-review --server http://your-review-board-server-url

うまくいけば新しく作成されたレビューリクエストのURLが表示されます。うまくいかないときは--debugを指定すると原因究明がしやすくなります。これで登録されればあとはブラウザ上でコメントとか入れていくだけです。

3.修正後ソースの更新

  • rオプションでレビューリクエストのIDを指定します。

4.はまったところ
svnクライアントの出力が日本語化されていると動きません。
post-reviewは複数のSCMに対応しているのですが、SCMの判定は自動になっています。しかしソースをみると

    def get_repository_info(self):
        data = execute('svn info', ignore_errors=True)

        m = re.search(r'^Repository Root: (.+)$', data, re.M)
        if not m:
            return None

とかやってるのでsvn infoの出力が日本語だと動きません。
とりあえず

LANG= post-review .....

とかやってごまかしましたらうまくいきました。

5.雑感
とりあえずは開発中の流れでこまめにオンラインレビューを標準化できるといいなぁ。概要を入れたり状態変更もスクリプトから操作できるので（結構機能をAPI公開しているみたい）、工夫すればかなり楽ができるかもしれない。

6.参考ページ
Review Board - コードレビューをオンラインで
VMWareの開発でも利用されているソースコードレビュー共有ソフトウェア·Review Board MOONGIFT

インストールは下記が詳しいです。
http://blog.monospace.jp/2008/03/24/reviewboard_installation/

Perl5.10.0ではクロージャをネストしたときのメモリリークが解消されているみたい

Perl

Perl5.8まではクロージャをネストした場合にメモリーリークが発生するという問題がありましたが、5.10.0では解消されているようです。

例えば以下のようなソースを実行すると

use strict;
use Devel::Leak::Object qw(GLOBAL_bless);
package Foo;
sub new {
        my $class = shift;
        return bless { id => shift }, $class;
}
sub DESTROY {
        my $self = shift;
        print "Destroy @{[$self->{id}]} $self\n";
}

package main;
sub main ($) {
        my $j = shift;
        print "# MAIN BLOCK START\n";
        my $foo = Foo->new( $j );
        sub {
                sub {
                        print "id = $foo->{id}\n"; # 二つ以上外のローカル変数を参照
                }->();
        }->();
        print "# MAIN BLOCK END\n";
}

print "Perl Version is $]\n";
main($_) for (1..3)

5.6だと$fooは解放されずにすべてリークしてしまいます。

実行結果

Perl Version is 5.006001
# MAIN BLOCK START
id = 1
# MAIN BLOCK END
# MAIN BLOCK START
id = 2
# MAIN BLOCK END
# MAIN BLOCK START
id = 3
# MAIN BLOCK END
After main
Tracked objects by class:
Foo                                      3
Destroy 2 Foo=HASH(0x8143074)
Destroy 3 Foo=HASH(0x8143158)
Destroy 1 Foo=HASH(0x80f5714)

l5.8だと一回目の$fooのみ解放されずに残ってしまいます。

Perl Version is 5.008008
# MAIN BLOCK START
id = 1
# MAIN BLOCK END
# MAIN BLOCK START
id = 2
# MAIN BLOCK END
Destroy 2 Foo=HASH(0x81c399c)
# MAIN BLOCK START
id = 3
# MAIN BLOCK END
Destroy 3 Foo=HASH(0x81c399c)
After main
Tracked objects by class:
Foo                                      1
Destroy 1 Foo=HASH(0x8152b44)

これが5.10.0で実行するとちゃんと期待通り動作するようになっていました。

Perl Version is 5.010000
# MAIN BLOCK START
id = 1
# MAIN BLOCK END
Destroy 1 Foo=HASH(0x8167f20)
# MAIN BLOCK START
id = 2
# MAIN BLOCK END
Destroy 2 Foo=HASH(0x8167f20)
# MAIN BLOCK START
id = 3
# MAIN BLOCK END
Destroy 3 Foo=HASH(0x8167f20)
After main
Tracked objects by class:

Errorモジュールのtry catchなどで暗黙にクロージャが生成される場合等注意が必要でしたが5.10.0だと安心して使用できそうです。