読者です 読者をやめる 読者になる 読者になる

北海道苫小牧市出身の初老PGが書くブログ

永遠のプログラマを夢見る、苫小牧市出身のおじさんのちらしの裏

YAPC::ASIA Tokyo 2009 1日目 実況メモ

レポート perl yapcasia2009

今日から本番です。

またgihyo.jpさん側にも書いたりしますので、合わせてご利用下さい。

会場で、Shibuya.pmでお会いしたid:makotoworldさんにまたお会いできました!!

lestrratさん「開催のあいさつ」

  • 2日前から、39度の熱を出して倒れていた
  • 今年からYAPCJPAが主催する
    • 他、様々なスポンサー++
  • 2年連続で、世界最大のYAPC
    • 459/539名
  • 今回のテーマ: 3つのC
    • Community
    • Corporate
    • Connect(CommunitとCorporateが手を組む)
  • 連絡
    • Tシャツ、手ぬぐい買ってね
    • ランチは無料で配布します!(サンドイッチ)
    • 懇親会(有料)
  • CM: 特別研修出て下さい!
    • お昼の間に、目立つ外人さんに声をかけて下さいとのこと!

Richard Diceさん「Where Perl can go and how to get it there」

英語のセッションなんで、毎度のことながらヒアリングしきれてません、すみません。

  • はじめに
  • 進化的モデル
    • 時間とともに、ソフトウェアの機能は増えていく
    • だんだんと安定していく
  • 安定した状態(生物学的には死んでいる状態)
    • 問題が全て解決している(ttなど)
    • 開発者の興味が移った
    • コストの問題
    • これらが複合している
  • 問題は全て解決している??
    • 時間が経てば、分野自体が変わる
    • 分野が変化したのに、プロダクトが変わらないのは危険
  • CPANの開発パラダイム
    • 必要に迫られた人が作り、他の人が使う(Adam Kennedyさんは除く)
    • 必要に迫られない場合、コストがかかり過ぎる場合は、解決されない
  • いつか、では遅い
    • Perlを使って XXX をするには?
    • XXX を最初に実装した人が勝つ
  • 興味がある人が居ない
    • 実際は、興味がある人と開発者が同一でない
    • お金で解決できるが、お金がない人の興味は解決できない
  • コストについて
    • 適材適所で配置を行う
  • さまざまなOSS関連団体と、TPFの違い
    • 収益モデルがない
    • 直接サポートする企業がいない
      • Perlは企業にとって有用じゃないの?
  • 例: Mozilla
    • MozillaはTPFの一部になろうとした
    • 100名で、半分がプログラマ。他は別の技術者
    • 口座には80万ドル、収益は50万ドル
    • 最終的には、Googleとの連携
    • 汎用プロトコルの上に質の高いソフトを作る(MSはその逆)
  • 例: eclipse
    • 元々は、"Visual Age Studio for Java"(IBM)
    • 501(c)(6)団体
      • 非営利団体。企業に会員権を販売
      • 年間収益6万ドル、従業員15人、弁護士5人
      • 企業の強力事業
  • YAS/TPFは、501(c)(3)
    • 会員権を売れない
    • コミュニティへの命令はできない(命令は意味がない?)
  • 企業への売り込み
    • IBM & Intel: マルチコア→Perl6は並列処理が得意→Perl6の普及の協力を要請
    • Microsoft: CLI上でのPerl6ビルド
  • TPFで話し合われていること
    • 「最小限」モデル: 今のまま。コミュニティの要請があれば動く。
    • 「意欲的」モデル: 能動的な組織。
    • もっとディスカッションが必要
  • Perl 5.10.1の開発補助金
    • Perl 5.10.0は2007年に
    • #p5pにて、リリース耐性の議論
      • David Mitchellさんが担当
    • 400個以上のパッチを適用
  • 財源等について: Booking.com, Hague基金
  • Hague基金
    • p6の開発者へのサポート
  • 交付の例
    • SMOP
    • S19
    • Dispatcher and
    • Traits
    • Rakudo Perl and PCT improvements
  • ParrotはTPFから独立した(リソースの最適化)
  • TPFは、ボランティアのみでなっている
    • 事務作業を、スケールできるようにしたい → Hague基金
  • Perlの将来
  • ベース技術、効率化、種類が増えた、開発者の増加等
  • 2002年に、P5EE構想があった(エンタプライズ版)
    • コアPerlの上にCPANモジュールを追加して、パッケージング
    • Perl + CPANは、実はJ2EEなどと同じもの
  • ベンダーサポート
    • ノリが大事(新しいプラットフォームへ、すぐに対応する)
    • LSB 3.2の、Perl5.8.8の正式サポート(TPFの仲介)
    • OraclePerlを同梱
  • フィードバックについて
    • 今 : 企業 - 開発者 - コードアーティスト
    • 将来: 企業 - 戦略的パートナー - 開発者 - コードアーティスト - 教育者 - 起業家
  • 企業の言語の採用
    • 言語設計レベル: Cobol, Ada, Java
    • アクシデント的: Java, C
  • まとめ: JPAやTPFは、おおきな生態系を作るサポートをする

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

このセッションに関しては、gihyo.jpさんで参加レポートを書かせていただきました。gihyo.jpさんの特集記事もあわせてご利用下さい。

  • 階段で転びそうになって足を痛めたとのこと
  • 注意: Perlの話はほとんどでてきません(「Perlのイベントだったんですね?」)
  • mixiアプリについて
    • mixiプラットホーム構想の、一部分
    • 日本でも有数のソーシャルグラフを、一般に公開
      • マイミクなど、人間関係の蓄積
    • 8月にリリース済。(なぜか緑・・・mixiっぽくない。)
  • mixi Open ID
  • mixi Connect
    • mixiの情報を、外部に利用してもらう
    • 一部法人のみ、契約ベース
    • マイモード: mixi版のtwitter
    • みんなの農園: 草刈りとか水やり
    • ハグミィ: ヨシオリさんにカンチョーする、など
  • さまざまなAPIで、新鮮なユーザ体験
    • Community
    • Persistence
      • データを保存
    • Invite
      • 招待
    • Albums
      • フォトアルバムへのアクセス
    • Activities
    • Gadget
    • Person & Friends
  • 公開アプリ数231、一番人気のアプリは395,598
  • アプリを広めるための仕掛け
    • Invite(招待機能)
    • アクティビティフィード(アプリがマイミクへ送るフィード)
  • OpenSocial v0.8.1相当
    • orkut、Linkedin、force.com 等でも動く(はず)
      • 現実には、独自APIの違いで動かないことが多い
    • さらに、mixi独自APIを追加
    • OpenSocial JavaScript API: PC向け
    • OpenSocial RESTful Protocol: ケータイ向け
  • XMLに、アプリを記述
    • 各種APIを利用
    • 自分でWEBサーバを用意し、mixiに登録
  • バイル版では
    • mixiがプロキシとなり、元リクエストを含むリクエストがサーバにくるイメージ
    • RESTful Protocol + OAuthに準拠し、mixiサーバにXMLを返す
  • mixiアプリの特徴
    • PC版とモバイル版を一緒に書ける
    • バイルではview属性にmobileを指定
  • mixiOpenSocial実装
  • APIサーバ
  • リリース後のダウンについて
    • mixiアプリ起動しない
      • Shindigがダウンした
      • 504エラー:Shindigの不具合(socketのclose漏れ)
      • パッチして、安定
    • APIレスポンスの低下
      • Shindigが動き出したせいで負荷が戻った
      • 情報へのパーミッション処理が、重い(インストール済かどうかで、各APIについて決まる)
      • サーバ台数を増加(ピーク時は4倍にしたが、CPU利用率100%)
      • Devel::NYTProf にて、分析、チューニング
      • キャッシュ率高、DBアクセス削減、処理順序修正(仕様変更はなし)
      • 7倍の速度になった
    • 今度は、mixiアプリが負荷に耐えられなくなった
  • mixiアプリにもエコが必要
    • ライブラリの挙動を知るべき
    • 開発者へ、フィードバックするとよい
    • 人気が出るほど、リクエストは増える → スケールを考えること(mod_perl, memchached)
  • まとめ
    • mixiデベロッパセンターを見て下さい
    • アプリ開発者が増えてこそ成功。ぜひ作って下さい。

Tokuhiro Matsunoさん「Plack/PSGI

このセッションに関しては、gihyo.jpさんで参加レポートを書かせていただきました。gihyo.jpさんの特集記事もあわせてご利用下さい。

  • miyagawaさんが友情(?)出演
  • PSGIは仕様の名前、Plackは実装
  • PSGI(Perl Webserve Gateway Interface)
  • WEBサーバとアプリの間の中間プロトコル
    • リクエストをハッシュリファレンスに
      • $env SERVER_NAME、PATH_INFOなど
      • 独自変数: psgi.input、psgi.version、psgi.url_shceme
      • psgi.multi_process などの機能が、昨日miyagawaさんに追加された
    • レスポンスは配列リファレンスに
      • ステータスコード、HTTPヘッダの配列、最後に(?)コンテンツ
      • この配列リファレンスを使うのは、WAF側。WAFがこれを吐けばいい
  • なぜPSGIがいるの??
    • CatalystのエンジンはCatalystでしか使えない
    • 各WEBフレームワークで書き直すのは、無駄
    • どの組み合わせでも動くようにするもので、WSGIやRackのようなもの
    • 仕様はまだ流動的。意見募集中。
  • specも公開中(英語)
  • HTTP::Engineとの違いは?
    • HTTP::Engineは、実装。
    • リクエストやレスポンスが、オブジェクトになっている
    • PSGIは、実装と仕様をわけたもの
    • HTTP::Engine::Interface::PSGI はまもなくリリース
    • Plack::Adapter::HTTP::Engineもある
    • メンテナがやる気を失いつつある(笑)
    • 開発者同士で、今後requestをどうするか
  • Plackとは
    • リクエスト、レスポンス、plackupコマンド
    • 種々の実装(Apachefastcgiに関しては簡単過ぎてまだ。実装者募集)
  • Plack::Request (Catalyst::RequestのぱくりのHTTP::Engine::Requestのぱくり)
    • Responseは、あまり使わなくてよい
  • plackup
    • アプリケーションを立ち上げる
    • モジュールの指定、*.cgiの指定が可能
    • 実装を変更可能(MojoやらAnyEventやら)
    • 今後は、plackupがfastcgi経由で来ると、fastcgiで動くようにしたい
    • PSGIの仕様を満たすコードリファレンスを起動させる
  • アダプタ
    • WAFのAPIの違いを吸収: MyApp->new->run とか MyApp->run_api とかの違い
    • PSGIにおけるアプリケーションは、コードリファレンス(ハッシュをうけて、配列を返す)
  • TODO
    • 非同期(Async)の仕様が未確定
    • IRCチャネルで意見を募集中(特にWAF、WEBサーバを書いてる方)
    • 実装: Impl::ModPerl、Impl::FCGIPlack::Requestのインタフェース
  • デモ
    • Catalystでアプリを作り、plackupで動かす(CatalystMojo、AnyEvent)
    • Catalyst::Testのテストは、Plackで走らせることができる
    • CGIの例: plackupで動かす(バッファするタイプのHTTPサーバだと、多少効率が悪い)
    • asyncの例は、不具合があってデモ中止・・・?
      • commetなども、吸収できるような仕様になっている
      • miyagawaさんが直したら動いた(さすが)
  • CGI.pm に、PSGIのサポートを入れる予定もある
  • Google APIエンジンのPerl仕様でPSGIを使えないか、打診しているとのこと
  • 質疑応答
    • Q. HTTP::Engineのアプリは、今後動く?
    • A. HTTP::Engine に機能追加も、壊れることもない。安心。
    • A. remedieでも使ってるので、大丈夫
    • Q. Plackのパフォーマンスはどうなのか?
    • A. PSGIは仕様なので、Plackを使う必要はない。C実装もできる。遅ければ、別の方法はある。
    • A. ただし、現時点では早い(オブジェクトがないから)
    • Q. この仕様はRFCになったりする?
    • A. CPANにはあげる。perl.orgで名前をもらう。Perl6の開発陣にコアにしてもらいたい
    • Q. PSGIの実装はどうする。例えばMojoでは?
    • A. MojoからのリクエストをPSGI準拠するように書き換え、アプリへ。逆にアプリからの配列をMojoへ。
    • Q. Catalystの他の実装をやめさせたりしないのか?
    • A. 古いアプリを考えると、それは難しい。PSGIのうまみは、仕様と実装が分かれること。将来的にはそうなるかもしれない。
    • A. PSGIへの乗り換えは楽。2-3行・・・いや、10行程度で大丈夫
    • Q. HTTP::Engine::Interfaceがインタフェースだったが、今後のインターフェースは?
    • A. Interface::PSGI となる
    • A. HTTP::Engineは、余計なことをやりすぎている。仕様、API、サーバ実装。これを分ける。
  • IRCgithubを参照して下さい #http-engine@irc.perl.org

Yoshinori TAKESAKOさん「Inline::x86 JIT Assembler」

うーん、相変わらず難しい。内容は不正確かもしれません。

  • Mooseの速度が遅いと言う議論
    • Mouse? Perl OOをやめる? XSにする?
    • use Inine::x86; !!
  • 簡単なデモ: x86をインラインで記述する例
  • x86の歴史
    • MS-DOSの16bit (昔よく書かれた(!?))
      • hello16.comのデモ
      • .comバブル!
    • Win32API時代
      • hello32x.exeのデモ
      • ファイルサイズが大きくなる(windowsのpヘッダ)
      • ヘッダにコードを入れたりすると短くできる(GOLF的には97byteになる!)
  • バイナリは難しいので、Perlを使う
    • use Win32::API
      • hello1.plのデモ
    • DynaLoaderでも、実現できる
    • hello2.plのデモ: Inline::X86 で組むと、Perlでコメントしつつマシン語が書けてきれい
  • セキュリティの問題
  • デモ: CPUIDをとる例
  • Perlから64bitモード化を調べる方法の紹介
    • myはポインタが変わるので使えない。user varsする。
    • デクリメントが走るか走らないかで分けれる(64bitだと該当処理が消される)
  • トラップを拾い、書き換える
  • mprotectにより、書き込み可能にする
  • x86_sub 関数で、関数を定義する

Goro Fujiさん「XS書きのためのPerl MAGIC 入門」

  • XSをみなさんよく書きますが、XSはMAGICを使うのが大事
    • MAGICを使うにはコードを読むしかない
    • 解説します!
  • MAGICとは?
    • Perlの構造体に、特殊な機能などを持たせるもの
    • 各種フック関数
    • mg_obj → SVを持たせられる
    • get, set, free
  • MAGICの利用目的
    • tie
    • 特殊変数($^H: PL_hintsにバインド, $!: errnoにバインド)
    • Weak reference、Defer elements(存在しないハッシュキーへのアクセス)、UTF8ヘルパ
    • 変な挙動をするものは、MAGIC → tieでもなんとかなる
  • Devel::Peek
    • MAGICを調査できる
    • DBIステートメントハンドルは、Dumperしても空っぽ
    • Devel::PeekでDumpするとよい
  • CPANでMAGICしてるもの
    • B::Hooks::EndOfScope (フック)
    • WeakRef::Auto (フック)
    • Sub::Name (マネージデータ)
    • Class::MOP / Moose (マネージデータ)
  • XSレベルでは、MAGICを全て意識する
    • MAGICを使わなくても意識が必要(APIが勝手に使ったりする)
  • MAGICを起動するAPI
    • ドキュメントに書いてることが多いが
    • SvIV、SvNV、SvPVなど (GetMAGIC)
    • sv_setsv_mgなど (SetMAGIC)
    • sv_isobject (perlapiに載ってない。ソースを読むこと)
  • MAGICを起動しないAPI
    • 速度を稼ぐために存在する
    • SvIVX/SvOK 直接参照
    • sv_setx系(_mgなし)
    • デフォルトtypemap
    • tie変数を渡したときの挙動が要注意。知ってなければいけない。
  • typemapのMAGICの状況
    • char*, int ハンドルする
    • HV*, AV*, CV* ハンドルしない
    • ほとんどバグに思える
    • Magic::Exampleを参照(githubにある)
    • Scalar::Utilのtypemapも参考になる
  • av_store の戻り値 → 失敗時はnullだが
    • tieされたものも、nullを返す → storeしたSVの解放が必要
  • メタスタック(PERL_SI)の役割
    • ドキュメントがない部分もある
  • PERL_MAGIC_ext : ユーザレベルで使っていい
    • sv_magicextのあと、SvREFCNT_decしないとリークする
    • Perlコアでも間違えていたことがあった。注意
  • XS code template
    • クロージャのXS版
    • XSUB + パラメータ
    • Class::XSAdapterClass::XSAccessor など *1
  • 動的コードの生成
    • eval, closure
    • 速度だと、XS code templates
    • Inline::x86JITはメンテナンスがむずい
  • 質疑応答
    • Q. XS templateの速度は?
    • A. 生成はやや速い。実行は圧倒的に速い。
    • Q. XS template はメモリを食う?
    • A. かなりメモリは少ない。

Masanori Wadaさん「Yet Another BPM Framework "Kailas"」

このセッションに関しては、gihyo.jpさんで参加レポートを書かせていただくことになっています。実況メモもgihyo.jpさんのサイトへ掲載しておりますので、gihyo.jpさんの特集記事を参照して下さい。

  • YAPCとしては、少し変わったセッションになる予定
    • チャレンジなので聞いて欲しい
  • wadit
    • 従業員2名の会社
    • お父さんは60歳、最年長では?
    • 鎌倉だがKAYACではない。
    • オフィスの紹介(真上を湘南モノレールが走ってる・・・)
    • コミュニケーションはGTalk
    • 受託開発、業務システム
  • Kailas
  • 名前は、チベット未踏峰カイラス山」
    • BPM(Business Process Management)
    • プラットフォーム、かつ、システム構築技法であり
  • Kailasの狙い
    • 人間が主体のものにする
      • 現在はITが主役
    • ビジネスの言葉
    • 要求が決まれば、そのまま動かす
    • WEB技術は、いいものがたくさんある → 融合
  • Kailasが産まれた背景
    • 20年間変わらない業務システムを変えたい
    • 業務プロセスをそのまま実装できない
    • 上流から下流において、一貫性がない
    • 人間にからむ業務をIT化できない
  • 既存の業務プロセスを書いてみると
    • 手作業7、システム2の割合
    • 業務システムを作ったことにならない
    • 要求定義において、手作業のものを捨てているのが原因
    • "人間がITシステムに使われている"
  • Kailasによる業務プロセス分解のアプローチ
    • プロセスレベルを1〜5に分ける
  • コンポーネントの粒度
    • 論理的、適度な大きさ、均一
    • プロセスレベル4「アクティビティ」 でコンポーネント化するといい
    • 依頼に対し、答える(意思決定する)
    • 単位意思決定: データを確定すること
  • H.A.サイモンの意思決定プロセス
    • 情報、設計、選択、検討、の各活動
    • このIT化をする → WEB技術が活用できる
  • フローを、2段にする
    • マクロとミクロ (ミクロがサイモンの意思決定)
  • 適用できる業務: 顧客接点サービスプロセスが狙い
    • ERPとかが手を伸ばしてない分野
    • 引合・見積、資機材調達、修理サービス、サービスデスク、オーダー受領
  • Kailasの構成モデル
    • 依頼→データ確定→作業・報告
    • 各Activityにフォームがあり、それぞれに承認のプロセスがある
    • Processのデザインから、WEBまで落とし込む
  • デモ: 店舗の修理サービス
    • デザイナ画面(WEB)
      • プロセスをテンプレート化できる(コピーすると楽)
      • ドラッグ&ドロップで作れる(さくさく動いてる)
      • アクティビティを並べる(案件→担当者→修理日→修理内容→作業→報告)
    • WEB側
      • デザイナで設定した各アクティビティに対して、承認プロセスが自動作成される
      • 後は、アクティビティを順番に終わらせていくだけ
  • まとめ
    • ビジネス用語でそのまま作成
    • ワンクリックデプロイ
    • プロセス一覧、そのまま回せる
  • Kailasの技術
    • jQuery UIが特徴
    • プロセスは、ハッシュで表現可能 → JSON/YAML
      • 別のデザイナを作っても良い
    • HTML::FormFu の利用
      • validationとかの機能を理由
    • Catalystで(View::JSON)
  • なんでwaditはPerlなのか?
    • 無料、抽象度がちょうどいい、CPANがある
    • Perlコミュニティがうらやましい
    • エンタープライズの問題を解決できるかもしれない
  • システムは使われてなんぼのもの
    • 役に立たない、正しいシステムの量産
    • 1/3は使えないもの
  • みんなの知恵がシステムの質を高める
    • 「とりあえず動けばいい。力仕事だ。」
    • OSSの利点は、コストフリーではなく高品質
  • いいものを利用させてもらう
  • Perl魂を、エンタープライズに注入したい

Hideo Kimuraさん「modern Catalyst

移動の都合で少しおくれて会場に入りました。

なお、このセッションに関しては、gihyo.jpさんで参加レポートを書かせていただきました。gihyo.jpさんの特集記事もあわせてご利用下さい。

  • Moose対応
  • 拡張
    • Pluginは使ってはいけない
    • ヘルパメソッド
    • Role
    • Controllerのベースに
  • コントローラのMoose対応について
  • コントローラの拡張
    • Moose::Role (MooseX::MethodAttributes
      • -traitsの指定
    • ActionClass: 昔からある
      • Catalyst::Actionの継承
      • 再利用が出来る。ただし、複数は使えない
    • Catalyst::Controller::ActionRole: 最近
      • Moose::Role をアクションとできる
      • Does属性で呼べる。複数指定可能
  • default :Privateは将来使えなくなる
    • :Pathを使う
  • index :Private も使えなくなる
  • :Chainedの階層
  • $c->go: 行き先のauto等を実行, $c->visit: 行き先のauto等を実行、そのまま
  • Contorollerは薄く、Modelを賢くする
  • Catalyst::Test
    • ctx_request が便利
    • Cookieなどのテストは、Test::WWW::Mechanize::Catalystを使う
  • 様々なドキュメントに出ている
    • Catalyst::Manual::ExtendingCatalyst, Catalyst::Manual::CatalystAndMooseなど
    • charsbarさんの連載
    • Definitive Guide to Catalyst
      • コードは間違ってるので注意、とのこと
  • PSGIについて
    • Catalyst::Engine::*の代わりに、Catalyst::Engine::PSGIとなる
    • 統一されるとすばらしい

Tatsuhiko Miyagawaさん「Event programming fun with AnyEvent and Coro」

このセッションに関しては、gihyo.jpさんで参加レポートを書かせていただきました。gihyo.jpさんの特集記事もあわせてご利用下さい。

  • 自分以外のモジュールを喋るのは久しぶり
  • AnyEventの作者はすばらしい
    • でも、miyagawaさんが作者にメールを出すと、罵倒メールが返ってくるらしいw
  • 250 → POE::Componentsの数
    • POEとIO::Asyncと同時に使えない
    • POEのコンポーネントは、時間の無駄だから書くべきでない
  • 例: POEとAnyEventを一緒に使う例
  • 35 → AnyEventのモジュールの数
    • これ以上増やす必要もない
  • PoCoを書くのはやめて、AnyEventを!
  • Timer: 一定時間後にコールバックの実行。recvでループが走る
  • I/O: poll, cb にて指定
    • AnyEvent::Handle
      • lineやchunk、jsonなど、読み込みを指定できる
    • AnyEvent::Socket
    • AnyEvent::HTTP : ヘッダは自分で処理
  • condvar,subprocess, modules
  • 例: AnyEvent::Twitter::Stream
    • Twitterが流れてくるタイミングで、コールバックを呼ぶ
    • POEでは面倒
  • 例: AnyEvent::ReversHTTP → クライアントがロングポールしてHTTPを待ち、そこに投げてもらう
  • POEを全てAnyEventにしたくなる
  • CondvarのTips
    • 複数プロセスのcondvarの扱い
    • 例: 並列のHTTPダウンロード
      • condvarに対し、beginとendを使う
  • AnyEventが、スコープ外になると消滅する問題
    • my $w; $w = ... し、内部で undef $w; する(クロージャ、循環参照で残る)
  • 全てのプロセスが、1秒後にうごくようにするには?
    • cbメソッドないで、recvする
  • Coro::AnyEventについては、省略
  • AnyEventの流儀としては、APIはシンプルなコールバックで
    • 単純であれば、newとかをするよりは関数そのままで
  • guard
  • 循環参照なので、当然メモりリークする
    • weak refference 使ったりする
  • AE::*
    • 名前が登録されてる。プロトタイプ宣言されてる
    • 使いやすいし、作者からもおすすめ
  • まとめ
    • AnyEventを使いましょう
  • 質問
    • Q. POEはPoCoだが、AnyEventの名前空間は?
    • A. 気になっている。AnyEventの直下では心配。「Twitter::Stream::AnyEvent」とかいう名前もあるかも。考え中。

Naoya Itoさん「Perl で圧縮」

移動等の関連で、終了5分前に入りました。ので、最後の方だけ。

  • 圧縮率には数学的限界がある
    • しかも実行時間とのトレードオフ
    • 限界を求めても、得られるものは少ない
  • Compress::*系
    • Zlib: deflate法。バランスがいい(zlibやgzip
      • 過去のデータを使う。テキストが短いとだめ
    • Bzip2: 圧縮率は高いが、ちょっと遅い
      • 短いテキストにはだめ
    • LZMA::Simple
      • liblzma、圧縮率が高く、復号は速い。静的アーカイブの配布に優れる
    • LZO
      • 圧縮率は高くないが、非常に高速(memcpyの数倍程度の実行時間)
    • PPMd
      • PPmdライブラリ
  • Algorithm::Huffman
    • ハフマン符号の実装
  • Range Coder実装を作成 → github参照
  • まとめ
    • 汎用テキスト圧縮: zlib、LZMA
    • 整数列の圧縮はpack、δ符号、ゴロム符号を自分で
    • Pathtraqの事例 → 特性にあわせて、自前処理
    • WEB+DB Pressの圧縮話も見てね

Gosuke Miyashitaさん「ペパボでの Perl のつかいかた」

  • お二人でのセッション
  • 伊藤さんはnaoyaさんの弟らしい
  • 面接では、ドクタペッパーチェリーを飲みたい、と言うこと
  • paperboy&co.
  • 例: 30days Album
  • ここでトーク中なのになぜか差し入れのドクターペッパーが到着!!!
  • MogileFS
    • 適切なノードへのリクエスト振り分け
    • 同類のOSSを知らない、Perlbalとの相性
  • ストレージAPI(by catalyst)
  • Perlbalとの連携・・・は省略
  • ジョブサーバ
    • 写真のリサイズ、回転
    • 裏はGermanとTheSchwartz
    • これもWEBでAPIを張ってる
  • Gearman
    • リアル性の高い処理用
    • Proc::Background + daemontoolsと組み合わせ
  • TheSchwartz
    • リアルタイム性の低い処理
    • 写真のリサイズは、遅れてやっている
  • ジョブサーバを横に伸ばしてスケーリング
  • 画像処理 → Image::Imlib2
  • ホスティングサービス
  • CGI環境の提供
    • SuEXEC + mod_cgid
    • CGIリクエスト → 1プロセス
    • 行儀悪いプロセス(メモリ、CPU)
  • hetepro プロセス管理デーモン
    • プロセス情報でフィルタリング。マッチしたプロセスにアクション
    • kill -9 して、ロギング
    • 設定はyamlで行える
    • Sys::Statistics::LinuxLinux専用
  • たくさんのサーバを扱うノウハウ
    • 同じ処理をさせたい
    • Archer → id:tokuhiromさん
    • RubyCapistranoと同等
    • システム管理にも使える
    • ssh越しで、同じコマンドを送れる
  • ロリポップリニューアルの内部
    • 内部APIを変更。JSONRPCでやりとり
    • HTTP::Engine、Any::Moose、Data::ObjectDriver、Kwalify
    • Func(Python)と連携
    • APIと各サーバはFuncで通信
    • web開発者から、内部実装や利用サーバを隠す(WEB開発とサーバ開発の分離)
  • アカウントの管理
    • MySQLで管理
    • Data::ObjectDriverでハンドリング (各アカウント)
    • ユーザさんを収容したファイルの管理(ホームディレクトリやVirtualホストなど)
  • Func
    • Python
    • func-transmit にYAMLを食わせるperlコマンド経由で使える
  • qpsmtpd
    • PerlSMTPデーモン。通称:メールのmod_perl
    • Perlでいじりやすい。プラグイン + フック。qmailのパッチより楽
    • フック: hook_connect、hook_helo、hook_rcpt、hook_queue など
    • プラグインの例: check_badsubject、check_relay_rcpt、check_size、max_rcpt_to
    • check_sizeは、pqsmtpd本体にもパッチを入れ、ESMTPのSIZEパラメータを使えるようにしている--欠点: ドキュメントがすくない。ソース嫁。
  • その他のPerl
    • JugemKey、JUGEMモブログ、システム管理、MySQLクライアントスレッドの管理
    • 勤怠管理、稟議管理
  • 開発者募集中!!
  • 質疑応答
    • Q. Image::Imlib2のベンチはちょっと適当です。キャッシュとかの関係。
    • A. でも、速いはずです。
    • Q. 開発環境で、複数台サーバを想定したテストはどうする?
    • A. 本番環境に、開発用に使えるものを用意したりする(ステージング)
    • Q. 勤怠、稟議のシステムを買わずに作ったのは要請から?エンジニアが勝手に?
    • A. 要請はあった。タイムカードが紙ベースだったが、システム化した。買うって発想自体があまりない。自分たちで作るノリ。
    • A. Perlで勤怠管理を作っておけば、あとで書き換えてなんとでもなる(by kdaibaさん)

Yusuke Kawasakiさん「Corporate Perl in Recruit, OpenSocial and Emoji」

このセッションに関しては、gihyo.jpさんで参加レポートを書かせていただきました。gihyo.jpさんの特集記事もあわせてご利用下さい。

  • 二人でのセッション
  • 様々なWEBサービス
  • 通常のサイト
    • WEBサーバ、DBサーバ
  • 提案したシステム
    • Webサーバとデータベースの間に、一覧検索API
    • データベースを最適化(かぶってる部分が多い)し、小さく
    • 疎結合で、メンテナンスが楽に
    • JSONPでブラウザから直接叩ける
  • 例: エイビーロード、ケイコとマナブ (JSONP)
  • 利点
    • コミュニケーションパスが短い
      • APIリファレンスを見てもらえば済む(ER図を渡さなくていい)
    • 性能面で優位な場合もある
    • 外部の人が、とりあえず試してみる、ことができる
    • 集めたデータから、開発者から逆提案 → 楽しい
  • 構成
  • Perl
  • アジャイル開発
    • ペアプロを徹底
    • テストを必ず書く
    • subversion、Backlog
    • チーム構成で、役割は明確にしない
  • 経営陣にも好評
    • 今度は、大規模化を要請されている
    • なかなか難しい
  • 例: iPhone版のサイトを開発中
  • 絵文字について
    • 同じハートでも、マッピングが E6EC、E595、E022 の3種類
    • Googleも独自のコードポイントを持っている : emoji4unicodeプロジェクト
    • Unicode::Emoji::E4U と Encode::JP::Emoji
      • 絵文字の相互変換、IMGタグへの変換、Googleのコードポイントへの対応
      • pure Perl (Encode::JP::Mobileはコンパイル必要)
      • CP932にdecodeしてから置換することで、tr//で置換
      • utfフラグが立つと、tr//が遅い(それは仕方がない by dankogaiさん)
  • Google絵文字は4バイトで、MySQLには格納できないのが問題
  • OpenSocial
  • osapi 「社内の相性はオサピー」
    • 従来より短い記述ができる
  • ガジェットはShindigMixiアプリ互換、osapiで開発も快適
  • Mashup Awards 5
    • 最優秀賞は100万円。本日より募集開始。
    • 協賛は50社以上。
    • 去年の優勝作品は、ChaMap
  • まとめ
  • 質疑応答
    • Q. Shindigをなぜ移植した?
    • A. 我々はPerlを使っているから。DBアクセスもPerlなので、PHPにDB関連のコードを移植する必要があったが、それは嫌だった。
    • Q. Perlに移植すると、速度はどうか?
    • A. 変わらない。数十ミリsecで返ってくる。
    • Q. WEB APIを作る時に、小さいDBに切り出した際、どうやって元と同期するのか
    • A. FTPダンプを置いてもらい、バッチで数週間に1度程度反映する。一番速いメディアでもデイリー。反映もフロントだけに反映し、1日に一回だけ表に反映する。

Lightning Talks (1)

このセッションに関しては、gihyo.jpさんで参加レポートを書かせていただきました。gihyo.jpさんの特集記事もあわせてご利用下さい。

Goro Fujiさん「Moose Hacking Guide」
  • Mooseが流行ってるからみんなソース読むよね?
    • 多い・・・
  • 58モジュール、47ドキュメント、Class::MOPは15モジュール
  • ジャンル分け
  • Moose::Meta::Instance
    • デフォルトではハッシュリファレンスの生成
  • Moose::Meta::Class
  • Moose::Meta::Attribute
    • 属性のふるまい
  • Moose::Meta::Method
    • Moose管理したのメソッドの生成
  • Moose::Meta::Role
    • Role::*以下はサブクラスではない
  • Moose::Meta::TypeConstraints
  • Moose::Meta::TypeCoercion
    • 型変換。通常はTypeConstraints経由
  • Tips: NYTProfを使えば、呼び出しツリーがわかる
  • ゴーン!!(時間切れ)
Shunichiro Fujiwaraさん「PerlSalesforce
  • Salesforceとは?
    • CRMクラウドで。
    • PAAS Platform as a Service (Custom Object、APEX code)
    • Force.com Sites エンドユーザ向け
    • 共用SSLなので、DISられないように注意
    • SOAP over HTTPS
  • Perlからの利用
    • WWW::Salesforce 以外はメンテされてないので注意
    • login、create、retrieve、update、deleteとか
  • キーバリューではなく、SOQL
    • ほぼSQLの文法
  • Tips
    • ユーザ定義型は、型指定しないと文字化け
    • APIは5000回まで。200-300msの速度
    • 接続を使い回すが、接続確認はステートレスなので無駄
    • upsetやcacheなど、メソッドをうまく使う
    • 安定性: アメリカのサーバなので、つながらないことも
      • ジョブキューを使う
      • 計画メンテナンスもあるので、注意(月1回)
  • まとめ
    • APIPerlからRDBMS風に使える
    • 面倒な部分は、工夫しよう
yuki kimotoさん「Webアプリケーションフレームワーク Mojoの紹介」
  • Mojoとは?
    • ポータブル(レンタルサーバでもそのまま動く)
      • Perl5.8.1以降があればOK
      • CGIFastCGIで動く
    • オールインワン(フルスタック)
      • 雛形の作成、テスト、自動試験、ディスパッチャ、テンプレ、リクエスト
    • 開発者(CatalystのSbastian Riedelさん)
  • Mojoの将来と利点
    • 軽いので気軽
    • Catalystと違い、依存性が低い
    • CGI::Apllicationはs
  • ゴーン!!(時間切れ)
Tokuhiro Matsunoさん「Test::TCP
  • テストがめんどうなケースの解決
  • 例えば、TCPサーバのテスト
    • Test::Moreをforkすると、順番がばらばらなので、TAP出力がだめ
      • Test::SharedFork を使う
    • 空のTCP port はどれ?
      • portの直書きは絶対駄目!
      • Test::TCP::empty_port を使う
Daisuke Muraseさん「通知マニアのための im.kayac.com」
  • im.kayac.com
    • HTTPポストをすると、Jabberのアカウントにメッセージが飛ぶサービス
    • アカウントを作って、ユーザネーム付きのURLにポストするだけ
  • 直接だと使いにくいので・・・
    • irssi、tiarra、hookhub : 各種イベントを、自分に通知する
  • iPhone対応をした
    • iPhoneにイベントを送れる
    • AnyEvent::APNS (Appleの許可が通れば、App公開)
  • iPhoneで実際にデモ
Yusuke Wadaさん「miyagawanize」
  • 紫のモノで、miyagawaさんに負けてる
  • 紫のモノの正体はよくわからない
  • OpenCVで顔認識し、紫のモノをあて、miyagawaさんに近づく
  • デモ: dankogaiさん、lestrratさん、オバマさん、モーニング娘。
    • Can you miyagawanize him? Yes, we can!!
    • 多人数の写真でも、ほぼ全員に紫のモノが(たまに認識できない人も)
kamipoさん「nginxやlighttpdMogileFSしてみた」
  • MogileFS
    • 分散ファイルストレージ
    • 複数のノードに分散保存
    • クライアントから保存、参照
  • clientがStorage nodeに参照させるのは遅い
  • 考えたこと
    • StorageNodeはperlbalでなくてもいいのでは
    • いまどきならfastcgi
  • nginxやlighttpdWebDAVの設定をすればいい
  • perlbal はX-REPROXY-URL
  • 最終的にはこれは失敗でした・・・が、デモ
    • nginxはキャッシュしない
    • lighttpdは画像すら返って来ない・・・
  • ゴーン!!(時間切れ)
Kazuho Okuさん「Server::Starter - a superdaemon to hot-deploy server programs」
  • ホットデプロイ : WEBサーバを止めずにデプロイ
    • 止めずに、リソースリークせずに、失敗しても落ちない
  • Server::Starter
    • 新しいサーバを立ち上げ、その後に古いサーバを落とす
    • 3つの問題が解決でき、安全
    • 新しいサーバ側でself-testをやるとよい
  • デモ: エラーがあるときは、killを送っても新しいサーバに切り替わらない
  • daemontoolsと組み合わせるのがおすすめ
  • Plack実装がある
  • FastCGIやinit.dスタイルには未対応
  • 明日のトークで、さらに詳しく話す
Yuval Kogmanさん「nothingmuch」
  • throwはdie、catchはeval + $@
  • evalはevil
    • DESTROYでevalすると、エラーハンドルできないことがある
    • localする → rethrowに問題がある。一度$@を保存しないと
    • if( $@ ) で、捉えきれないことがある(中間にevalがあったり)
  • evalを正確にするには、多くのコードが必要
    • try {} catch {}; を使う
  • ゴーン!!(時間切れ)

懇親会

喋り過ぎて声枯れたorz

スピーカーのid:sugyanさんやid:gfxさんに声かけてもらえてよかったです。

*1:thanks to gfxさん