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
  • std statement denotation ( for statements ) ifとかforとかを解析する
  • nud: null denotation ( リテラル、単項演算子など)
  • let: left denotation ( 二項演算子や後置演算子など）
• 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
• 勉強会
  • nokunoさん主催の自然言語処理勉強会@東京がお勧め
• その他
  • 集合知プログラミング
  • 大規模サービス技術入門
  • 入門自然言語処理＠オライリーがもうすぐでる
• 三つの心構え
  • 最初は簡単に、あとから洗練する。やってみるとユーザの動きがかわるから、効果をみて凝るのがよい
  • 機械はミスをする。誤り箇所を探すとかは難しい。日本語の口語文テキストは難しい
  • データは自前で集めて自前で持つ。早く計算するために
• Webサービスと自然言語処理
  • 最初はWeb APIやライブラリを利用すればOK。
  • 課題を見つけてチャレンジする。独自でデータを収集して、自分でライブラリを書くのがお勧め
• Webサービスにありがちな悩み
  • ユーザ回遊性を高めたい
  • データはあるけど検索できない
  • 単語Aと単語Bって一緒にならないの？
  • ユーザが全アイテムをみてくれｒない
• Web APIを使って問題解決
  • もうみんな飽きてますよね
• ユーザ回遊性を高めたい
  • レコメンド - 強調フィルタリングで似たユーザを探す。はてなブックマークの関連エントリーなど
  • CPANモジュールの例 Algorithm::NaiveBayesが簡単
  • アンカーテキストをつける。CPANならText::Darts
• 単語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コミュニティに触れて
• プチ独立までの経緯
• フリーになり心がけている事
• 今後の課題

• 黒歴史、語ります
  • PC98、ファミコン、美容、学校裏サイト、携帯、BarTUBE
  • ファミコン、スーファミ大好き
  • 携帯サイトで見事に炎上
  • 謎のメルマガを発行し、読者150人くらい
  • 元美容アシスタント
• Perlコミュニティに触れて
  • 発表デビュー Yokohama.pm#2
  • Micro blog con
  • Shibuya.pm#10
  • YAPC::Asia 2009前夜祭
  • Perl Casual#1, #2
  • Mashup Caravan Girls Talk
• プチ独立までの経緯
  • 今は会社を作るためにとりあえずフリーランスとして活動しました
  • 現在は某コンシューマ向けサービスを開発。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で表示
• 基本システム構成
  • リソース RSS、Search結果
  • クローラ
  • DB - MySQL
  • Webアプリ DBIx::Class/ Catlyst
• リソースとしての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 - これらを各アプリで共有している
• アプリケーション構成
  • cliとwebでスキーマを共有する
• 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の構成
  • Web&Appサーバ x 1 Amazon EC2
  • DBサーバ x 1 Amazon EC2 mysql
  • AS3のコンパイル x 2 Amazon Ec2
• jsdo.itの構成
  • Web&Appサーバ x 1 Amazon EC2
  • DBサーバ x 1 Amazon EC2 mysql
  • キャプチャサーバ x 1 Amazon Ec2
• Catalyst
  • DBIx::Class、Object::Containerベース
  • ViewはTT
  • 設定はひたすらYAMLで
• daemon
  • memcached - セッション情報。閲覧頻度の高いコンテンツ
  • gearmand - 重い処理はバックグランドで
• wonderfl.netコンパイラサーバ
  • AnyEvent::Socket tcp_server。AS3コードを受け取りコンパイル
• 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
  • PGSI: a glue interface
  • いろんなフレームワークが同意するAPIをつくるのはすごく大変
  • HTTP::Engineはリクエスト/レスポンスのAPIを持っていた。新しいフレームワークはいいが、既存のフレームワークはそのAPIにアダプタを書かないといけない。
• 8) コンピュータサイエンスで難しいこと cache invalidation and name things
  • Too may ::'s !
  • タイプするのがめんどくさい。話すときもめんどくさい。省略して書くようになる。読めないし新しい人はわからない
  • Again, steal from Ruby できるだけ名前をトップレベルに。Starman、Twiggy、Starlet
  • 名前をつけるのは大変な仕事。でも名前をつけることで愛着もわくし、意思疎通もとりやすい。名前をつけるのは重要
• 9) 一番だいじなのはやっぱり人

Perl glues people together.