YAPC::Asia2009 09/10のメモ

perl カンファレンス YAPC
  • 前夜祭に引き続き初YAPC参加。セッション間の移動大変だった。
  • 記念にAcme大全2009とPythons&PerlMongersの2つとも買った
    • Acmeの下に何があるか知りたかったからちょうどいいタイミングだった！
    • P&Pはパラパラ見てたらダンザマッチョの心得編があってそこだけじっくり読んでしまった
  • AnyEventの意味がよくわからないまま使ってたのでmiyagawaさんの話聞けて良かった。やっとmy $w; $w = AnyEvent->timerの中でundefやってる理由がわかった（ような）
    • ただ、$cv->cb(sub{ $cv->recv });で複数同時に立ち上げるパターンってのを実際にやってみたけど上手く動かなかった。。もうちょい勉強しないとわからん。

Welcome - id:lestrrat

  • 今年からJPAが主催
  • 2年連続世界最大のYAPC。登録数539人/確認済み459人
  • テーマ：3つのC
    • Community:Perlはコミュニュティの文化と言っても過言ではない
    • Corporate:コーポレートトラック。企業でどのように使われているか
    • Connect:上の2つのCをつなげたい

基調講演 Perlの未来、その行程 - Perl Foundation: Richard Dice

FLOSSの技術進化のためのモデルとは？
  • 時間とともにソフトウェアは進化する
  • 初めに誰かが開発し、機能を加え、誰かがそれに加える
開発が安定した状態になる
  • 死んだ状態
    • 問題分野をやり尽くした(Text::Template)
    • 開発者の興味がすでに他に移ってしまった
    • 次のステップにコストがかかりすぎる
問題分野はすべてやり尽くした？
  • 時間とともに分野自体が変化する場合もある
    • Netscape2は良いブラウザだったよ
    • 怖いのは変化があるのにそこに加われないこと
CPANの開発プロセス
  • 誰かが必要に迫られる
    • その人が開発、他の誰かが恩恵にあずかる
  • 必要に迫られない場合は解決されない
    • 「いつか解決する」では遅い
      • 初めに解決した人が勝つ
誰も興味ない？
  • 本当に？
    • 実際は興味がある人と、解決する人が一致しないだけでは？
      • お金がある人はお金で解決できる
オープンソースプロジェクト
  • Perl:TPF,EPO,JPA
  • PerlとTPFはこれからどうなる？
    • 直接的な収益モデルがない
    • 直接サポートする企業がない
      • 収益が見込めない？
      • 戦略的な価値がない？
      • Perlには上の2つがないのか？
ケーススタディ：Mozilla
  • googleから多大な出資
    • googleはFirefoxと組むことに戦略的な価値を見いだした
  • 大きな企業と提携するベストな例
ケーススタディ：eclipse
  • 元はIBMの"Visual Age Studio for Java"
  • 企業に議決権付き会員券を販売
企業への売り込み
  • IBM&IntelはマルチコアCPUの時代
    • Perl6はマルチコアで動かすことに長けている
      • 戦略的提携ができそう
  • Microsoft
    • CLI上でのPerl6ビルドで協力
TPFで起こっていること
  • 内部での議論。何ができる？何をするするべき？
    • 「最小限」モデル
      • 今のまま
    • 「意欲的」モデル
      • 能動的に組織作りをし、Perlとともに戦う準備
Perlの未来
  • Perlエンタープライズ版
    • 2002年にp5eeがあったが盛り上がらなかった
  • コアにCPANを載せて上手くパッケージ化できないか？
JavaとPerl
  • Java
    • ほとんどの企業でインストールされている
    • Apache Foundationと共に成長
  • Perlは企業であまり使われていない
    • TPFやJPAがこことを繋ぐ役割を担う

Webエンジニアのためのmixiアプリ開発ガイド - mixi 田中洋一郎

自己紹介
  • Google API Expertやってる
  • Perlの話はほとんど出てこない
mixiアプリとは
公開アプリについて
  • アプリ数:231
  • 今の1位：能力大学-漢字テスト（ドリコム）
    • ユーザ数：395,598
バイラルの仕掛け
  • invite
    • マイミクにアプリを紹介する機能
  • アクティビティフィード
    • マイミクの更新情報
mixiアプリとOpenSocial
  • OpenSocialにmixiの独自のAPIを加えた物がmixiアプリ
  • mixiアプリ（PC版）
    • XML + HTML + JavaScript + Flash
    • DB用意しなくてもkey valueの簡単なPersistence APIが提供されている
    • 自分のサーバにアップロードし、そのURLをmixiアプリに登録
  • mixiアプリ（モバイル版）
    • 日本の携帯はJavaScriptに対応してないので、HTML + XML + RESTFulAPI
    • mixiがプロキシになっていて、リクエストが自分のサーバに渡されるイメージ
  • Gadget XMLファイル
    • 一つのファイルでPC版とモバイル版の両方に対応可能な記述ができる
必要となる実装
  • Social Data API
    • /people, /activities, /appdata, JS(opensocial.*)
  • Gadget APIの実装
    • /gadgets/makeRequest, JS(gadget.*)
  • Gadget Rendering
    • /gadgets/ifr
  • これらを実装するのは大変
Apache Shindig
  • （ここで次のセッション聞くために移動）

PSGI/Plack - id:tokuhirom,　id:miyagawa

  • 今日はAsync/DBIの話はしません。Plackの話は11時からはじまるらしいです。ウコンの力をのんだので、二日酔いの影響はありません。デモもやります。
最初に重要なこと
  • PSGIは仕様
    • Perl Server Gateway Interface
  • Plackは実装
  • この2つのことはとても重要です。覚えておいて。
プロトコルはシンプル
  • リクエストはHASHREFにシリアライズして渡す
  • レスポンスはARRAYREFにシリアライズして渡す
  • 独自変数
  • なんで必要か？
    • 自分でWebアプリケーションフレームワークを作ると、webサーバごとの実装を再度自分で作らないといけない。apahceとかmod_perlとかfast cgiとか
      • pythonのWSGIやrubyのrackとかと同じ。Perl5でiteratorなどができないのでもう少しlow levelだけど
  • response
    • 配列の形にした
      • ハッシュじゃないのは同じキーを使う時に困るので
    • 配列は嫌だってのは考えなくていい。考えるのはフレームワーク作る人だけ。その人ががんばればいいだけ
  • specはgithubに置いてあるので見て
  • HTTP::Engineは実装と仕様とAPIが全てごっちゃになってる
  • Plack::Adapter::HTTP::Engineも用意してある
    • HTTP::Engineから乗り換えやすいように。ただ、これをそのまま出すかはわからない
  • HTTP::Engineはメンテナンスのモチベーションが落ちてるのでこの先バグフィックスだけかも
Plack
  • Request class/Response classを持ってる
  • アプリを実行できるplackupコマンドがある
  • plackup
    • application loader
    • 「plackup MyApp」を実行すればサーバが立ち上がる
      • plackup foo.cgiと打てばCGIが立ち上がる
    • PLACK_IMPL=Mojoとか打てばMojoを使って立ち上げられる
    • アダプタを差し替えるのは-a Catalystとか
      • アダプタはWebアプリケーションの差異を吸収するもの
      • フレームワーク側で用意してもいいけど、Plack側にも入れてある
TODO
デモ
  • test
    • catalystのtestをパクって来て動かせる
      • まだ全部通らないのでどっかにバグがある
      • これはいいこと。フレームワークを作るたびに同じようなテストを書く必要がない
  • CGI.pmにもPSGIを入れることはメンテナの了承済み
  • AnyEventのデモ
    • （セッション始まる前からtimeを出力するデモ作ってたけど、なぜかinteravalで出力されず上手く動かない）
      • miyagawa:「バッファされてるから出力されないんじゃない？改行付けたら出ないかな？」
      • tokuhirom:コードのwrite部分に改行そのまま入れる
      • miyagawa:「いやいや笑」
      • miyagawa:「new line」
      • tokuhirom:考える
      • miyagawa:「\n」
      • tokuhirom:考え込む
      • miyagawa:「（ノートPCの前に行って書こうとするけど）viだと書けねぇな」
      • tokuhirom:意味がわかって"\n"を追加
      • 出力できた。会場「おぉ」と盛り上がる
質問
  • HTTP::Engine使ってる人はバージョンアップしないと動かなくなる？
    • 何もする必要なく動くから大丈夫。あとバージョンアップは多分もうしない。
  • PlackのHTTP::Engineや他とのパーフォマンス比較は？
    • Plackのベンチマークはまだ取ってない
    • 遅かった場合はPSGIの他の実装を使えばいい
    • Plackを使ってれば、今後新しいPSGIの実装が出て来た時にアプリ側は何も変える必要なくそれを取り入れて速くできる
  • PSGIの今後は？
    • CPANにあげるつもりだし、perl.orgをもらおうと思ってる。
    • Perl6のコアモジュールにして欲しい
      • Perl6をまだ勉強してないけどPerl6になればPerl5で実現できない部分が解決できるかもだし
  • Catalyst自体がPSGIを実装するべきでは？
    • Catalyst::Engineを変えて動かなくなったら困るからCatalyst::Engineの中身をPSGIで動かすようなものを書いた
    • 今あるフレームワークをPSGI対応するのはすごく簡単。CGI作るだけなので。
  • HTTP::Engineはいろんなところごちゃまぜになってるから他のフレームワークから移らないといけなくなっちゃう。なので、必要部分を分けた。

Inline::x86 JIT Assembler - Yoshinori TAKESAKO(id:TAKESAKO)

  • Mooseが遅い
  • ということで今日はuse Inline::x86;
x86の歴史
  • MS-DOS 16bit
    • .comバブル時代
  • Win32APIが出て来た
No Binary
  • やっぱりuse Perlだよね
    • use Win32::API;
      • messageBoxに渡す値を引数で渡していて、わかりやすい笑
  • use Win32::APIをしなくてもDynaLoaderでdl_install_xsubを使ってもできる
  • use Inline::X86
    • 動くんだけど、セキュリティの問題でWindowsのDEPの設定をいじる必要がある
  • （ここまで聞いて、後はメモ取らずに話聞いてました）
    • わからなすぎて、まるで大学の授業を聞いてるかのような感覚に戻りました

API Design - Shawn Moore (Sartak)

  • GoogleのテックトークでもAPI設計の話が出た
  • Moose,Path::Dispatcher,HTTP::Engine,Dist::Zilla,IM::EngineのクールなAPIの話
  • 秘訣はテストを書くこと
Moose
  • MooseはClass::MOPのラッパ
    • Mooseのクラスのパーツは全てオブジェクト
      • hasはMoose::Meta::Accessor
      • isはMoose::Meta::Method::Accessor
    • Mooseのクラスを拡張すれば独自機能も作れる
  • ほとんどのMooseXはMOPを利用している
  • MooseはSugar Layer(シュガー層)が分離してるのも特徴
    • hasはメソッドではないのでメソッド呼び出しで書くべき物ではないし、関数で書くのもおかしい
Path::Dispatcher
  • jifty::Dispatcherをprophetで使うために作られた
    • 元々はSub::Exporterを使っていた
      • 拡張性がなかった
  • Robert Krimen(grink)が拡張したがってPath::Dispatcher::Builderができた
    • サブクラス化してロジック変更できるようにした
HTTP::Engine
  • HTTP::Engineを使うと好きなサーバを選べる
    • ServerSimple,ModPerl,FCGI
      • mod_perlは使ってるマゾな人もいるし
    • 新しいサーバが追加されても1行変えればOK
Dist::Zilla
  • 色々なプラグインが使える
    • プラグインの役割を書くとその役割をもつプラグインが選ばれる
  • Request Tracker
  • 選択肢を増やせる
    • ModuleBuild or MakeMaker
    • MetaYAML or MetaJSON
  • Dist::Zilla::Pluginに拡張も可能
    • ロールに必要な条件を満たせばいい
IM::Engine
  • JapperなどのIMに対応
  • 今取り組んでるプロジェクト
  • 気に入ってるのはplugin_collect
    • method=>'traits'でtraitsメソッドが呼び出せる
      • 結果はメソッドの結果を配列にまとめたもの
  • new_with_plugins,nwe_with_traitsも気に入ってる
    • new_with_traitsはMooseX::Traitsを利用している
  • MooseではRoleとTraitはほぼ同意語
まとめ
  • Mooseは拡張性やシュガーの分離を教えてくれた
  • Path::Dispatcherのようにooシュガー層という考えが広がって欲しい
  • HTTP::Engineの必要な機能だけ考えれば柔軟で簡潔になる
  • Dist::Zillaのように追加したい機能を明示的に指定できたっていい
  • IM::Engineのやり方をすればDRYにできる
  • テスト書くのを忘れないように

modern Catalyst - DeNA Hideo Kimura(id:hide-k)

  • Catalystの拡張の話
  • Catalyst5.8
    • Deprecation
      • Catalystを使う上で非推奨のことがいくつかあるのでそれについて
    • Catamoose
Deprecation
  • ::[MV C]::style
    • もう使ってる人いないと思うけどこの1文字の使い方はもうしないで
  • NEXTやめて
    • use MRO::Compat
  • __PACKAGE__->mk_accessors()もMoose使ってるのでナシで
    • use Moose attribute 'has'
Extend Application
  • pluginはもうダメ。怖い人に怒られる
    • Application namespaceならギリギリセーフ
  • Helper Method
  • Role
    • use Moose::Roleでsetupに入れれば使える
      • あんまやらないけど
  • base Controller
    • BEGINでextendsする
Extend Controller
  • Moose::Role
    • MooseX::MethodAttributes
  • ActionClass
  • ActionRole
    • Catalyst::Controller::ActionRole
      • Moose::Roleを使ってできる
    • いけてるところはDoesが使える所
Dispatcher
  • default:Privateが使えなくなる
    • default:Pathを使うようにしてください
    • 極端な話catchall::Pathでもかまわない
    • index:Privateも同様にダメ
  • $c->go、$c->vistiが追加された
    • 使い道がよくわからないけど。
Model
  • Contollerを小さくして、Modelを賢くしなさい
Test
  • Catalyst::Test
    • 使うとMyAppが自動的に起動してテストができる
    • $c->stashの中身とかも見れて便利
    • formをまたぐようなCookieの中身が見れない
      • Test::WWW::Mechanize::Catalystでやる
PSGI
  • Catalyst::Engine::PSGIを実装してくれれば::impl::Coroや::impl::Mojoが使えて便利
資料

Asynchronous Event programming with AnyEvnt - id:miyagawa

  • 自分の書いたモジュール以外の話をするのは4年ぶりくらいなのでベーシックな話になるかも
  • AnyEventの作者の人は面白い人
    • miyagawaさんのことが嫌いらしい。メールすると怒濤の勢いで怒ってくる
      • でも何かそれが面白くなって来た
  • イベントループのモジュールはたくさんあり、APIもそれぞ違う
    • これは問題
      • POE::Componentsの数が250もあるから人気のように見えるけど、IO::Asyncの対応してるようなものばかり
  • AnyEventで書いたコードはどのイベントループが入ったモジュールでも使える
    • POEが使われている既存のコードにも追加できる
      • もうPOE::Componentsは増やさなくていいよ。ホント。
AnyEventの基本
  • TimerWatcher
    • timer
      • after秒後にinterval秒ずつ実行
  • condvarで待ち受けのイベントを作って、実行されたらコールバック関数の実行結果をrecvに渡す
    • $cv->recvがメインループ
    • $cv->recvの戻り値にsendで渡した引数が入る
I/O
  • AnyEvent::Handle
    • push_readのline,chunk(ある行数分),json(jsonを読み込み終わったら)
  • AnyEvent::Sokect
  • AnyEvnt::HTTP
    • プリミティブなのでHeaderなどは自分でがんばって書かないといけない
モジュールの紹介
  • AnyEvent::Twitter::Stream
    • TwitterのStreamingAPIに対応したモジュール
    • filterで何のデータを取るか決める
    • track => '#yapc,#yapcasia2009'とすればyapcとyapcasia2009のハッシュタグをtrackできる
    • コールバックのon_tweet中でAnyEventを使ってIRCに渡せたりする
  • AnyEvent::ReverseHTTP
    • デスクトップでクライアント作ると通信できないけど、サーバとクライアントを逆転させることで上手くやってる
AnyEventのTips
  • Transactions(multi signals)
    • parallelにdownloadしたい場合は一時変数使って書きたくなるけど、そうじゃなくてsendを使わない書き方をする
      • beginとendを使う
  • watcherのスコープについて
    • forの中で$wというwatcherを作り、forの外でrecvしようとするときに、何もしないとforが実行されたタイミングで$wが消えるため上手くいかない
    • クロージャの循環参照の性質を使って、callbackの中で$wを参照すればいい。
      • 中で参照すれば何でもいいんだけど、イディオムとしてはundefがいい
      • my $w; $w = AnyEvent->timerと書いて、cb => sub { undef $w; }
      • こうすると循環参照が起きて消えない
      • my $w; $wとわざわざ2つに分けている理由は、my $w = AnyEvent->timerを定義している中で$wを参照することができないから
  • 複数同時に立ち上げたい場合のやり方
    • 複数の$cvを->recvでは受けられない
    • $cv->cb(sub{ my $v = $cv->recv })
    • or use Coro::AnyEvent
      • malaさんが明日話すだろうから割愛
CPANにあげたい場合
  • AnyEventを使ったモジュールはnewするのはイマイチ
    • 単純な関数で書いた方がいい
      • AnyEvent::mDNSを参考に
  • 循環参照使うとメモりリークするから気を付ける
    • Scalar::Util::weakenを使って確認する
  • 最近できたAEという名前空間は引数の個数とか見てくれるのでコンパイル時にエラーが出てくれていい
質問
  • CPANモジュールにするとき名前空間はどうしたらいい？
    • AnyEventの下に置いてるけど、自分もどうしたらいいかちょっと考え中。POEとかでも使えるからAnyEventって入れなくても良いかも
資料

優しいモダンなWAFの作り方 (How to develop modern web application framework) - id:dann

モダンなWAFとは
  • 拡張性が高い
    • Plaggerのようにプラガブル
  • テスタビリティ
    • WSGIのようにサーバ抽象化
  • ユーザビリティ
WAFの基本構成要素
  • Engine
    • requestを受けて、responseを返す（Plackでのサーバ抽象化）
  • Dispatcher
    • URLをController名へマッピング
  • Component Manager
    • コントローラなどのロード
Plackを枠にしたWAFの作り方にしました
  • Server Gatewayの作成
  • psgi handler
    • PSGIのenvを受け取って、処理し、PSGIのresponse形式にして返す
  • request handler
    • リクエストを受けたらDispatcherでディスパッチ
  • Dispatcher
    • HTTP::Routerでリクエストにマッチするrouteを取得
    • dispatchを生成
  • Dispatch
    • Component Managerからコントローラを検索し、actionに渡す
  • シンプルなWAFは2-3時間あれば作れる
拡張部分について（拡張性）
  • あるべき姿
    • コアは小さく
    • 拡張箇所を限定
      • Contoroller,View,Middleware,Request,Response
    • Hookポイントを明示的に
  • プラグインの種類は大きく分けて2つ
    • ライスサイクルのHook系
      • MouseのRole + method modifier
      • Class::Trigger
      • MouseX::Object::Pluggable
    • メソッド生やす系
      • MouseのRole
      • Exporter
      • 多重継承
  • プラグインの作り方
    • PluginをRoleに
      • RoleはControllerにwithすることで使う
    • HooKポイントを明示(規約)
      • 大文字でACTION
      • プラグインのコードはbefore 'ACTION'とafter 'ACTION'
    • 適切なデフォルトセットの提供をする
      • ないとutf8flagがどうのとかそういうの考えなくてはいけない
  • まとめ
    • WAF作りがかつてないほど簡単になってる
資料

CPAN::Packager - ひきつづき id:dann

  • CPANモジュールの依存関係を再起的に解決して自動でRPM/Debパッケージにしてくれるモジュール
  • モチベージョン
    • Catalyst,Plaggerのインストールで1日が終わる
    • cpanコマンドでインストールしていたら、サーバごとに違うバージョンのモジュール
    • 依存モジュールが多過ぎて手動でパッケージ作るのは大変
既存ツールの課題
  • 依存関係を解決してくれない
  • CPANPLUS::Dist::{Deb,RPM}
    • 依存関係の解決が1段階
ツールが満たすべき要件
  • 依存関係を再起的に解決
  • 手動で既存モジュールのFixが可能
    • 入れたくないモジュールは入れないように設定するなど
  • CPAN::Packagerは上記を満たしてる
CPAN::Packager使い方
  • オプション--builderでRPMなどの指定、confで設定
    • 設定ファイルで依存関係や手動での条件を書く
      • globalでモジュール共通の全体設定、とmodulesでモジュール毎の設定
質問
  • 古いバージョンのモジュールを残したい場合は？
    • cpanminiでmirrorしないようにするか、手動でskipしてビルドするか
  • local::libに比べてメリットは？
    • pure perlだといいけど、アーキテクチャ依存が関わってくるのでRPMで管理すればシンプルなんじゃないかなと思う
  • 使ってるのだけど、configが結構めんどくさい
    • configのサンプルがあるのでそれ見るとある程度わかりやすいかなと思う
  • buildする時にtestはしてない？
    • RPM版はそういうモードがあるが、テストしてインストールしてというのをくり返さないといけないので処理が大変
  • CPAN::Packager自体が依存関係でかい
    • 笑。CPANPLUSの依存関係が多い。パッチwelcome
    • CPANPLUSの依存関係はgithubにextlib置くのがいいんじゃないかな？
資料

Key Value Store with O/R Mapper - Kazuhiro Osawa (id:yappo)

  • KVSとORMを組み合わせ
Data::Modelって何？
  • ORM
  • Data::ObjectDriverのようなもの
  • webアプリケーション上ではORMはKVSだからそれ用に
スキーマ定義
  • use Data::Model:Scema;でDSLをインストール
  • install_model user => schema {} でuserテーブルが作れる
    • key 'user_id'でprimary keyを指定
    • column qw/ /でカラムを設定
使い方
  • さっき定義したスキーマをuseしてnewしてモデルのインスタンス作成
    • $model = UserSchema->new;
  • モデルのメソッドであるset_base_driverのDBI中でDBIをnewするとその後はlookupなどでデータを取って来れる
    • $model->set_base_driver();
基礎知識
  • データソースはDBI,Memcached Protocol, Perl Hash, Perl Code, Gearman(予定)
  • データソースをRDB以外も予定しているのでData::*という名前空間
  • Q4Mにネィティブ対応
  • mixin
  • 透過キャッシュ
  • ナウいイテレータ
    • model('User')->get('user')で受け取ったものを<>でイテレート
  • 1テーブル/1クラスではなくて1DB/1クラス or 1つのデータのまとまり/1クラス
    • install_model(テーブル定義)毎にDriverを変更できる
なぜ他のモジュールを選ばなかったの？
  • 結論から言うと満足する物を自分で作る方が速かった
  • 使おうとしたモジュールの選定基準
    • webアプリはindex張ってあるkeyを基準にひっぱってくる
    • JOINは考慮しない
      • テーブルを複数のDBサーバへ分散する時に面倒
    • Schema定義で楽したい
    • DB以外のデータソースも扱いたい
    • KVS風な物
  • 他モジュール
    • Class::DBIは実績はあるが古い
    • DBIx::CLassは昔使ったトラウマで選ばなかった
    • Roseは見る暇なくJifty::DBIはJiftyでないと旨味なさそう
      • DSL周りは参考にした
    • Fey::ORM
      • use Moose使ってるのは…
    • DBIx::MoCo
      • ドキュメント少ない
      • infrate周りは参考にした
    • Data::ObjectDriver
      • 本当はこれが使いたかった
      • ググっても全然日本語情報なくて辛い
      • SixApartが想定する使い方以外だとどうなるかわからない
    • DBIx::Skinny
      • 一年前はバグ多そうだった
      • 今はそうでもないらしいので次のセッションで聞いてみて
ORMを作るポイント
  • 大体以下の5コンポーネントがあればいい
    • Schema
      • schema定義
    • Iterator
      • selectした行列を扱う
    • Row
      • 行毎のオブジェクト ORMのOの部分
    • SQL
      • オブジェクトで作ったクエリをSQLに変換する処理を担当
    • DB
      • DB接続を取り扱う
使い方
  • lookup
    • memcacheのインタフェースに合わせてる
  • insert
    • kvsなのでsetにした
  • column sugar
    • ものぐさな人におすすめ
    • column_sugarを定義するとそれを利用できる
    • あんまないかもだけど、開発中にスキーマ変えまくった時とか便利
  • alias_colum
    • バイナリデータをDBに格納するカラムがある時に、カラムにエイリアスを張ることで文字列形式とバイナリ形式の両方の形を利用できる
  • CREATE TABLE
    • auto incrementの流儀の違いなどを吸収
  • 透過キャッシュ
    • キャッシュがなければDBにアクセス
  • mysql master slave
    • slaveを一つしか設定できないが、LBでわけるのでそれでいい
  • add methodでメソッドを生やせる
  • mixin
    • DBICのResultSet拡張的なこと
  • Q4M
    • queue_running
  • transaction
    • tx_scope, rollback, commit
圧縮
  • 言いたいことは大体ブログに書いてある
  • 圧縮が必要な理由
    • 扱うデータ料が多くなると、圧縮のCPUコストよりもioの負荷が多くなる
    • そもそもサイズ少なければキャッシュにたくさんのるからいい
  • どうやる？
  • messagepack
  • Data::Modelの戦略
    • カラム名は数値に変換
    • primary keyはvalueに含めない
    • テーブル名も短い名前に変換
      • memcacheに投げる時にteblename:keyという形で投げるので
利点
  • SQLよりkvsの方が速い
  • カラムの追加が自由。ALTER TABLEなんかいらない
資料

DBIx::Skinny -simple OR mapper - モバイルファクトリー id:nekokak

  • 今はバグっぽくない
  • SQLベースのSimple ORM
    • 基本DBIの薄めのラッパ
どうして作ったか
  • DBICは便利だけど、もっとLiteに、もっと柔軟に
    • パフォーマンスを考慮したSQLが発行されない
      • そもそもORMにパフォーマンスを考慮したSQLを求めるべきではないかも
    • 会社によってはSQLのプロがいるのではないかしら
    • ORMはデータとオブジェクトの架け橋であるだけでいい
DBICの問題点
  • 複雑なPerlのデータ構造をもとに複雑なSQLは組み立て可能
    • でも結局複雑なSQLは直接DBIを叩くことが多い
  • DBIを直接叩いた場合
    • inflateしてくれない
    • utf8flagなりそういう便利機能が使えなくなる
  • 設定をDBIC持たせているのでそれを上手く使えないかな？
  • 重い
    • 1つのオブジェクトが大量のオブジェクトで構成されている
      • オブジェクトの生成コストもでかい
    • オブジェクト生成に時間がかかるため、HotSpotではDBICを外すことも
  • デバッグしにくい
    • Dumpするとどこまで続くんだろうってくらいダラダラと出てくる
      • ほんとにありがとうございました
DBICの素晴らしい部分
  • 慣れれば簡単に色んなことができて開発効率あがる
    • resultsetを使ったメンタルなsearchがかなり便利
  • Pluginも豊富
  • 有名なPerlHackerがメンテナンスしてるので安心
結局のところなんでDBICにしなかったか？どうしてDBIx::Skinny作ったか？
  • 不満の部分をどうにかしたかった
    • 周りと話をすると同じことを思ってる人が多かった
  • 他にもモジュールあったけど、生のSQLをいい感じにしてくれるのがなかった
設計方針
  • 生SQLのRができて、inflate,utf8flag周りが処理できればいい
  • inseart,update,deleteについてはDBICみたいに
    • pre_hookは欲しい
  • 検索結果をルールベースでオブジェクトにマッピング
  • デバッグしやすいようにオブジェクトに分けまくらない
ルールベースって？
  • 取得したデータをオブジェクトにする際、特定のカラムについてはutf8,inflateの処理が必要
  • 設定したルールにマッチしたカラム全てに対して処理
    • 「このカラム名の場合はこうする」って決めで十分だと思ったので。
使い方
  • setupメソッドでdsn,usename,passwordの設定をし、それをpackage Your::Model;とする
  • install_tableメソッドでschema設定
  • install_utf8_columnsメソッドでutf8のカラム
  • install_inflate_urlメソッドでinflate,deflateの設定
  • search_by_sqlでSQLも使える
  • search_name
    • search_by_sqlの拡張版
    • バインドの順番を間違うとプレースホルダ部分でミスるので、
      • ハッシュで名前で渡す:idなら{id => なんとか}みたいな感じで渡せる
  • クラスベースorインスタンスベース
    • クラスから直接呼び出すことも、インスタンス生成しても良い
      • 繋ぎっぱなしは嫌だって時はnewしてインスタンス作成してとか
      • 「インスタンスを作ってコネクション管理するまでもないな」という場合はクラスから直接
  • DBIx::Skinny::Manual::*に日本語マニュアル
relationshipについて
  • テーブル間のリレーションは特に何もしてない
    • DBICのようなhas_many/belongs_toはない
  • あると便利だからあると使っちゃうけど、それが問題になる
    • 裏側ではたくさんクエリ発行されている可能性がある
ラッパー
  • Skinnyはなるべく小さく設計している
    • 拡張部分はラッパを書くことおすすめ
      • nekoyaさんがDBIx::Skinny::ARを作ってる
  • コア部分で対応する部分は対応するの意見募集
Skinnyの良さ
  • 生SQL扱いやすい
  • Skinnyが作るオブジェクトは小さいのでアプリ側でデバッグしやすい
  • DBICより速い
Skinnyの足りない所
まとめ
資料

Corporate Perl in Recruit, OpenSocial and Emoji - id:iandeth, id:kawanet

  • 2人でリクルートのことと、絵文字のことについて発表
（まずはいしばしさんからリクルートについて）
  • Recruit Web Service
    • 結構な量ある
  • コンテンツの再利用が難しいという問題点があった
    • システムが再利用目的ではない
    • コストが高い
改善に2年前に着手
  • 3-4人で分担して10サイト分、40個のAPIを開発
  • WebサーバとDBの間にAPIを置いた
    • DBが超でかかった
  • JSONPでデータを取得できる
社内の事例
  • エイビーロード、ケイコとマナブ
  • SEO的にいい
  • 社内での採用理由
    • コミュニケーションパスが短い
      • デザイナやコーダに「APIリファレンスを見てね」で済む
    • レスポンス速度や機能面で優位なケースがある
      • APIの検索軸の方でしかできない検索があったり
社外の事例
構成
  • ハードウェア
    • webサーバ4台、DB2台、バッチサーバ
  • ソフトウェア
Perlについて
  • ModPerl::RegistryPrefork
アジャイル開発
  • テストを書く
  • 役割分担をしないでみんなでやる
    • これが結構効果的
今後
  • 10月にiPhoneのホットペッパー（FooMoo）アプリが新しくなるよ
（次にかわさきさんの発表）
  • 前夜祭にやったLiveSliesは時間がないので封印
Emoji
  • 同じハートでもsjisもutfも文字コードが違う
    • googleも独自のを出して来た
      • emoji4unicodeでサポート
  • Unicode::Emoji::E4Um
    • googleのemoji4uicodeプロジェクトに対応
  • Encode::JP::Emoji
    • 各キャリアの絵文字のマップを持ってる
    • 絵文字が存在しない場合はテキストで返す
    • pure perl
内部処理
  • 内部的にはcp932に一回変換してtr//等で置換する仕組み
    • utf8flagが立ってるtrだと3倍くらい遅いけどid:dankogaiが仕方ないと言ってるので仕方ない
例
  • うんこの例
注意点
  • googleのutfは4バイトあるのでMySQL5に格納できない
（話変わって）CREYLEについて
今年もMA5やるよ
  • 今日から募集
質問
  • Shindigをphpのままでなくperlに書き直した理由は？
    • フロントはperlだったので、Shindigをperlにした
      • 別々の言語だと管理しにくいのでどっちかに合わせかった。合わせるとしたら慣れてるperl。

LT

Moose Hacking Guide - id:gfx
  • Mooseのソースコードでも読んでみるか
    • モジュール多過ぎて読めない
  • カテゴリ分け
    • MooseとMoose::Role
    • Moose::Util
    • Moose::Error
    • Moose::Object
    • Moose::Exporter
      • すさまじくでかい
    • Moose::Meta::*
      • 実際のコアの動き
    • Moose::Meta::Instance
    • Moose::Meta::Class
      • クラスを管理するクラス
    • Moose::Meta::Attribute
      • hasなど
    • Moose::Meta::Method
      • コードリファレンスの扱いやすいラッパ
    • Moose::Meta::Role
      • ロールの為のクラス
    • Moose::Meta::TypeConstraints
      • TCオブジェクトを実装
  • ソースコードを読むにはNYTProf使えばいい
  • モジュールはたくさんあるけど10種類くらいに分けられる
Perlでsalefsforce - fujiwara 藤原 俊一郎
  • Salesforceとは
    • CRM
    • PAAS
    • 独自SSL
      • 高木先生にdisられないように
    • SOAPでやりとり
  • perlでどう使うか
  • kvsでなくSQLに似たSOQLという言語で問い合わせ
  • API回数制限と速度がある
    • なので接続確認はしない方がいい
    • upsertを使う
      • updateとinsertを両方一発でできる
  • アメリカにあるのでたまに繋がらない
    • 更新系はjob queueでやった方がいい
WebアプリケーションフレームワークMojoの紹介 - 木本裕紀(id:perlcodesample)
  • サンプルコードによるPerl入門のサイトの人
  • Mojoとは
  • ポータブルな
    • Perl5.8.1がインストールされていればOK
    • アップロードすれば動く
    • CGI,FastCGIで動く
  • オールインワン
    • Catalystとおんなじようなのを備えてる
  • Mojoの利点
    • 気軽で便利に扱えるWAFがなかった
Test::TCP - id:tokuhirom
  • Testはいいものだけどめんどうなものもある
    • TCPサーバのCPANモジュールのテストをどうする？
      • forkしてテスト→でもテストの順番がバラバラになってダメ
  • そこでTest::SharedFork
    • 親子プロセスが平行に動いていい感じ
  • TCPポートがハードコーディングしてあるCPANモジュールだとこける
    • Test::TCP::empty_port()使えばいい
im.kayac.comの紹介 - Daisuke Murase(id:typester)
  • http://im.kayac.com/
    • HTTP2jabber API
      • 自分のJabberアカウントにHTTPからメッセージを送れるAPI
  • scriptの例
    • irssi script
      • 自分が呼ばれた時にjabberで呼んでくれる
  • iphone対応した
    • 呼ばれるとpush通知がくる
    • AnyEvent::APNS使ってる
miyagawanize - ゆーすけべー(id:kamawada)
  • purple thingについて
    • CPANの紫色のアレ
  • purple thingを画像に付けるscriptを作成
    • OpenCVの顔認識で紫色のものを付ける
  • 実例
    • オバマもいける
      • （「yes, we can!」で大盛り上がり）
    • モー娘のような集合写真でもいける
      • ギークじゃないのかゴマキだけいけない
nginxやlighttpdでMogileFSしてみた - id:kamipo
  • MogileFSとは
    • 分散ファイルストレージ
    • 複数のノードに分散して保存
    • 保存／参照は専用のノード
      • 今回は参照の話
  • mod_perlで返すとでかい画像を返そうとすると一つのプロセスが重くなる
  • ただ今時はmod_perlじゃなくてFastCGI
  • perlbalはX-REPROXY-URLをもらうことで、そこにもう一度アクセスする
    • ngixの場合はX-Accel-Redirectを使うと上手いことリダイレクトしてくれる
    • lighttpdの場合はX-Rewrite-URI
  • ただ、やってみた結果は失敗でした
    • perlbalはちゃんとキャッシュしてくれるのに対して、
      • ngixはキャッシュしてくれない
      • lightはちゃんと返してもくれない
Server::Starter - kazuho oku(id:kazuhooku)
  • ホットデプロイの話
    • サーバをリスタートすることなくバージョンアップする
  • Server::Starter
    • SIGHUPすると新しいアプリをfork&execし、うまくいけば古いやつは消す
      • 新しいアプリのコンパイルが失敗しても古いプロセスが生きているので問題ない
  • deamontoolsと組み合わせるといい
Yuval Kogman(nothingmuch)
  • ironmanプロジェクトに参加
  • 今回はdieの話
  • dieのcatchはevalでやるがeval is EVIL
    • $@ = ""となってcatchできない時がある
      • local $@を使っても問題ある
  • 色々解決しようとしても問題が出て来て、解決法の解決法がどんどんでてくるので、
    • Try::Tinyがいいよ