今日から本番です。
またgihyo.jpさん側にも書いたりしますので、合わせてご利用下さい。
会場で、Shibuya.pmでお会いしたid:makotoworldさんにまたお会いできました!!
lestrratさん「開催のあいさつ」
Richard Diceさん「Where Perl can go and how to get it there」
英語のセッションなんで、毎度のことながらヒアリングしきれてません、すみません。
- はじめに
- 進化的モデル
- 時間とともに、ソフトウェアの機能は増えていく
- だんだんと安定していく
- 安定した状態(生物学的には死んでいる状態)
- 問題が全て解決している(ttなど)
- 開発者の興味が移った
- コストの問題
- これらが複合している
- 問題は全て解決している？？
- CPANの開発パラダイム
- 必要に迫られた人が作り、他の人が使う(Adam Kennedyさんは除く)
- 必要に迫られない場合、コストがかかり過ぎる場合は、解決されない
- いつか、では遅い
- Perlを使って XXX をするには？
- XXX を最初に実装した人が勝つ
- 興味がある人が居ない
- 実際は、興味がある人と開発者が同一でない
- お金で解決できるが、お金がない人の興味は解決できない
- コストについて
- 適材適所で配置を行う
- さまざまなOSS関連団体と、TPFの違い
- 収益モデルがない
- 直接サポートする企業がいない
- Perlは企業にとって有用じゃないの？
- 例: Mozilla
- 例: eclipse
- YAS/TPFは、501(c)(3)
- 会員権を売れない
- コミュニティへの命令はできない(命令は意味がない？)
- 企業への売り込み
- 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の将来
- p5/p6のエンタープライズ版、ベンダーサポート等
- ベース技術、効率化、種類が増えた、開発者の増加等
- 2002年に、P5EE構想があった（エンタプライズ版)
- ベンダーサポート
- フィードバックについて
- 今 : 企業 - 開発者 - コードアーティスト
- 将来: 企業 - 戦略的パートナー - 開発者 - コードアーティスト - 教育者 - 起業家
- 企業の言語の採用
- まとめ: JPAやTPFは、おおきな生態系を作るサポートをする
田中洋一郎さん「Webエンジニアのためのmixiアプリ開発ガイド」
このセッションに関しては、gihyo.jpさんで参加レポートを書かせていただきました。gihyo.jpさんの特集記事もあわせてご利用下さい。
- 階段で転びそうになって足を痛めたとのこと
- 注意: Perlの話はほとんどでてきません(「Perlのイベントだったんですね？」)
- mixiアプリについて
- mixi Open ID
- mixi Connect
- mixiの情報を、外部に利用してもらう
- 一部法人のみ、契約ベース
- 例
- さまざまな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: ケータイ向け
- orkut、Linkedin、force.com 等でも動く（はず）
- XMLに、アプリを記述
- モバイル版では
- mixiアプリの特徴
- mixiのOpenSocial実装
- APIサーバ
- リリース後のダウンについて
- mixiアプリにもエコが必要
- ライブラリの挙動を知るべき
- 開発者へ、フィードバックするとよい
- 人気が出るほど、リクエストは増える → スケールを考えること(mod_perl, memchached)
- まとめ
Tokuhiro Matsunoさん「Plack/PSGI」
このセッションに関しては、gihyo.jpさんで参加レポートを書かせていただきました。gihyo.jpさんの特集記事もあわせてご利用下さい。
- miyagawaさんが友情(?)出演
- PSGIは仕様の名前、Plackは実装
- PSGI(Perl Webserve Gateway Interface)
- WEBサーバとアプリの間の中間プロトコル
- なぜPSGIがいるの？？
- specも公開中(英語)
- HTTP::Engineとの違いは？
- HTTP::Engineは、実装。
- リクエストやレスポンスが、オブジェクトになっている
- PSGIは、実装と仕様をわけたもの
- HTTP::Engine::Interface::PSGI はまもなくリリース
- Plack::Adapter::HTTP::Engineもある
- メンテナがやる気を失いつつある(笑)
- 開発者同士で、今後requestをどうするか
- Plackとは
- Plack::Request (Catalyst::RequestのぱくりのHTTP::Engine::Requestのぱくり）
- Responseは、あまり使わなくてよい
- plackup
- アダプタ
- TODO
- デモ
- 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、サーバ実装。これを分ける。
- IRCやgithubを参照して下さい #http-engine@irc.perl.org
Yoshinori TAKESAKOさん「Inline::x86 JIT Assembler」
うーん、相変わらず難しい。内容は不正確かもしれません。
Goro Fujiさん「XS書きのためのPerl MAGIC 入門」
- XSをみなさんよく書きますが、XSはMAGICを使うのが大事
- MAGICを使うにはコードを読むしかない
- 解説します！
- MAGICとは？
- Perlの構造体に、特殊な機能などを持たせるもの
- 各種フック関数
- mg_obj → SVを持たせられる
- get, set, free
- MAGICの利用目的
- Devel::Peek
- 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
- 動的コードの生成
- 質疑応答
- Q. XS templateの速度は？
- A. 生成はやや速い。実行は圧倒的に速い。
- Q. XS template はメモリを食う？
- A. かなりメモリは少ない。
Masanori Wadaさん「Yet Another BPM Framework "Kailas"」
このセッションに関しては、gihyo.jpさんで参加レポートを書かせていただくことになっています。実況メモもgihyo.jpさんのサイトへ掲載しておりますので、gihyo.jpさんの特集記事を参照して下さい。
- YAPCとしては、少し変わったセッションになる予定
- チャレンジなので聞いて欲しい
- wadit
- Kailas
- 親子アジャイル開発
- "Subversionを使う60歳"
- Daily Iteration: 朝10時のミーティング
- 名前は、チベットの未踏峰「カイラス山」
- BPM(Business Process Management)
- プラットフォーム、かつ、システム構築技法であり
- Kailasの狙い
- 人間が主体のものにする
- 現在はITが主役
- ビジネスの言葉
- 要求が決まれば、そのまま動かす
- WEB技術は、いいものがたくさんある → 融合
- 人間が主体のものにする
- Kailasが産まれた背景
- 20年間変わらない業務システムを変えたい
- 業務プロセスをそのまま実装できない
- 上流から下流において、一貫性がない
- 人間にからむ業務をIT化できない
- 既存の業務プロセスを書いてみると
- 手作業7、システム2の割合
- 業務システムを作ったことにならない
- 要求定義において、手作業のものを捨てているのが原因
- "人間がITシステムに使われている"
- Kailasによる業務プロセス分解のアプローチ
- プロセスレベルを1〜5に分ける
- コンポーネントの粒度
- 論理的、適度な大きさ、均一
- プロセスレベル4「アクティビティ」 でコンポーネント化するといい
- 依頼に対し、答える(意思決定する)
- 単位意思決定: データを確定すること
- H.A.サイモンの意思決定プロセス
- フローを、2段にする
- マクロとミクロ (ミクロがサイモンの意思決定)
- 適用できる業務: 顧客接点サービスプロセスが狙い
- ERPとかが手を伸ばしてない分野
- 引合・見積、資機材調達、修理サービス、サービスデスク、オーダー受領
- Kailasの構成モデル
- 依頼→データ確定→作業・報告
- 各Activityにフォームがあり、それぞれに承認のプロセスがある
- Processのデザインから、WEBまで落とし込む
- デモ: 店舗の修理サービス
- デザイナ画面(WEB)
- プロセスをテンプレート化できる(コピーすると楽)
- ドラッグ＆ドロップで作れる(さくさく動いてる)
- アクティビティを並べる(案件→担当者→修理日→修理内容→作業→報告)
- WEB側
- デザイナで設定した各アクティビティに対して、承認プロセスが自動作成される
- 後は、アクティビティを順番に終わらせていくだけ
- デザイナ画面(WEB)
- まとめ
- ビジネス用語でそのまま作成
- ワンクリックデプロイ
- プロセス一覧、そのまま回せる
- Kailasの技術
- なんでwaditはPerlなのか？
- システムは使われてなんぼのもの
- 役に立たない、正しいシステムの量産
- 1/3は使えないもの
- みんなの知恵がシステムの質を高める
- いいものを利用させてもらう
- Perl魂を、エンタープライズに注入したい
Hideo Kimuraさん「modern Catalyst」
移動の都合で少しおくれて会場に入りました。
なお、このセッションに関しては、gihyo.jpさんで参加レポートを書かせていただきました。gihyo.jpさんの特集記事もあわせてご利用下さい。
Tatsuhiko Miyagawaさん「Event programming fun with AnyEvent and Coro」
このセッションに関しては、gihyo.jpさんで参加レポートを書かせていただきました。gihyo.jpさんの特集記事もあわせてご利用下さい。
- 自分以外のモジュールを喋るのは久しぶり
- AnyEventの作者はすばらしい
- でも、miyagawaさんが作者にメールを出すと、罵倒メールが返ってくるらしいｗ
- 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 : ヘッダは自分で処理
- AnyEvent::Handle
- 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を使いましょう
- 質問
Naoya Itoさん「Perl で圧縮」
移動等の関連で、終了5分前に入りました。ので、最後の方だけ。
- 圧縮率には数学的限界がある
- しかも実行時間とのトレードオフ
- 限界を求めても、得られるものは少ない
- Compress::*系
- Algorithm::Huffman
- ハフマン符号の実装
- Range Coder実装を作成 → github参照
- まとめ
- 汎用テキスト圧縮: zlib、LZMA
- 整数列の圧縮はpack、δ符号、ゴロム符号を自分で
- Pathtraqの事例 → 特性にあわせて、自前処理
- WEB+DB Pressの圧縮話も見てね
Gosuke Miyashitaさん「ペパボでの Perl のつかいかた」
- お二人でのセッション
- 伊藤さんはnaoyaさんの弟らしい
- はてなからのスパイか！？
- 面接では、ドクタペッパーチェリーを飲みたい、と言うこと
- paperboy&co.
- 例: 30days Album
- ここでトーク中なのになぜか差し入れのドクターペッパーが到着！！！
- MogileFS
- ストレージAPI(by catalyst)
- Perlbalとの連携・・・は省略
- ジョブサーバ
- 写真のリサイズ、回転
- 裏はGermanとTheSchwartz
- これもWEBでAPIを張ってる
- Gearman
- リアル性の高い処理用
- Proc::Background + daemontoolsと組み合わせ
- TheSchwartz
- リアルタイム性の低い処理
- 写真のリサイズは、遅れてやっている
- ジョブサーバを横に伸ばしてスケーリング
- 画像処理 → Image::Imlib2
- yusukebeさんのベンチマーク参照
- ホスティングサービス
- CGI環境の提供
- SuEXEC + mod_cgid
- CGIリクエスト → 1プロセス
- 行儀悪いプロセス(メモリ、CPU)
- hetepro プロセス管理デーモン
- たくさんのサーバを扱うノウハウ
- 同じ処理をさせたい
- Archer → id:tokuhiromさん
- RubyのCapistranoと同等
- システム管理にも使える
- ssh越しで、同じコマンドを送れる
- ロリポップリニューアルの内部
- 内部APIを変更。JSONRPCでやりとり
- HTTP::Engine、Any::Moose、Data::ObjectDriver、Kwalify
- Func(Python)と連携
- APIと各サーバはFuncで通信
- web開発者から、内部実装や利用サーバを隠す(WEB開発とサーバ開発の分離)
- アカウントの管理
- Func
- qpsmtpd
- その他のPerl
- 開発者募集中！！
- 質疑応答
- 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サーバ
- 提案したシステム
- 例: エイビーロード、ケイコとマナブ (JSONP)
- 利点
- コミュニケーションパスが短い
- APIリファレンスを見てもらえば済む(ER図を渡さなくていい)
- 性能面で優位な場合もある
- 外部の人が、とりあえず試してみる、ことができる
- 集めたデータから、開発者から逆提案 → 楽しい
- コミュニケーションパスが短い
- 構成
- Perl系
- ModPerl::RegistryPrefork
- 自作フレームワーク
- アジャイル開発
- ペアプロを徹底
- テストを必ず書く
- subversion、Backlog
- チーム構成で、役割は明確にしない
- 経営陣にも好評
- 今度は、大規模化を要請されている
- なかなか難しい
- 例: iPhone版のサイトを開発中
- 絵文字について
- Google絵文字は4バイトで、MySQLには格納できないのが問題
- OpenSocial
- Shindigのコードを、Perlへ移植
- Apache + FastCGI + HTTP::Engine
- osapi 「社内の相性はオサピー」
- 従来より短い記述ができる
- ガジェットはShindig、Mixiアプリ互換、osapiで開発も快適
- Mashup Awards 5
- 最優秀賞は100万円。本日より募集開始。
- 協賛は50社以上。
- 去年の優勝作品は、ChaMap
- まとめ
- リクルートはPerlを昔から使っている
- mod_perlやFastCGI + HTTP::Engineで動作
- OpenSocial、コンテストもぜひチャレンジして下さい。
- 液晶拭きも使って下さい！！(ちょっと強めに拭くこと)
- 質疑応答
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
- Util側はシンタックスシュガー。
- Moose::Meta::TypeCoercion
- 型変換。通常はTypeConstraints経由
- Tips: NYTProfを使えば、呼び出しツリーがわかる
- ポリモーフィックなものでも、実際の呼び出しを追える
- ゴーン！！(時間切れ)
Shunichiro Fujiwaraさん「Perl で Salesforce」
- Salesforceとは？
- Perlからの利用
- WWW::Salesforce 以外はメンテされてないので注意
- login、create、retrieve、update、deleteとか
- キーバリューではなく、SOQL
- ほぼSQLの文法
- Tips
- ユーザ定義型は、型指定しないと文字化け
- APIは5000回まで。200-300msの速度
- 接続を使い回すが、接続確認はステートレスなので無駄
- upsetやcacheなど、メソッドをうまく使う
- 安定性: アメリカのサーバなので、つながらないことも
- ジョブキューを使う
- 計画メンテナンスもあるので、注意(月1回)
- まとめ
Tokuhiro Matsunoさん「Test::TCP」
Daisuke Muraseさん「通知マニアのための im.kayac.com」
Yusuke Wadaさん「miyagawanize」
kamipoさん「nginxやlighttpdでMogileFSしてみた」
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 {}; を使う
- ゴーン！！(時間切れ)
*1:thanks to gfxさん
