本を読む

読書やコンピュータなどに関するメモ

YAPC::Asia 2009に参加

 毎年恒例となった、世界的Perlイベント「YAPC::Asia」が今年も日本で9月に開催されました。今回はJPA(Japan Perl Association)主催です。

 毎度ながら、とてもわくわくしながら話を聴かせていただきました。ライブラリ作者のスピーチが多いせいか、参加するとなんらかのコードを書きたくなるイベントですね。特にスタッフやスピーカーの方々、ありがとうございました。

 そうそう、ダラク本こと「Acme大全」も買いました。無駄にパワーがかかっていて、すばらしい内容です。

 イベントから1か月弱たって、すでにレポートがWebに出尽してますし、状況が変わっている部分もあると思いますが、以下、自分のためにメモをまとめておきます。

前夜祭

 前夜祭は、Yokohama.pm出張版として開かれました。前夜祭といいつつ、旬のネタを押さえているところがニクいですね。ロビーではシュウマイパーティも開かれました。

AnyEvent的ななにか(acotie)

 女性プログラマーのacotieさんが、イベントドリブンを実現するためのフレームワークAnyEventを紹介しました。

 AnyEventは、I/Oイベントをはじめさまざまなイベントに対応していること、拡張性が高いことが特徴だそうです。リアルタイムでなにかやりたいときに、なにかあったときだけコールバックが呼ばれるようになっていて、新着feedがあったときとか、twitterの更新があったときとかに使えるとのことで、twitterの「髪を切った」という発言を拾うサンプルを紹介していました。

Shenker(spiritloose)

 spiritlooseさんが開発しているSinatraインスパイヤのWebアプリケーションフレームワーク、Shenkerを紹介しました。途中、画面に表示されたサンプルには「Michael Shenker」という文字列があったので、つまりそういう由来のようです。

 HTTP::EngineとHTTP::Engine::Middlewareの上で動いて、サーバー側としてはCGI、FCGI、mod_perl、AnyEvent、POEなどに対応しているそうです。

 ルーティングはSinatraふうに、get '/' => sub { ... }みたいにして簡単に定義。パラメータはparams->{foo}で取ったり、get '/user/:user'と指定して取ったりするそうです。RailsのようなNested Parameterも対応しているとのことでした。

 処理の段については、Beforeフィルターを定義できるとか、セッション(ただしデフォルトでは無効)とか、define_errorで例外処理を定義とかいった機能が紹介されました。デフォルトでUTF-8エンコードでテキストを扱い、パスパラメータもエンコードされるそうです。ファイルの内容をブラウザに返すsend_fileや、コントローラの途中で処理を止めるhaltなどの工夫も紹介されました。

 Viewのサポートとしては、TTとText::MicroTemplateに対応。tt_options WRAPPERでレイアウト要素を指定したり、__END__以降に@@indexでテンプレートを入れたりする例も紹介されました。

 今後、Plack/PSGIの様子を見てリリース版を出したいという話でした。ちなみに、セッション中に会場から「いまPlackで動くようにしました」という声が聞こえました(miyagawaさん?)。仕事はえー。

YAPC::Europa 2009参加報告(kawa.net)

 リクルートメディアテクノロジーラボの川崎さんが、YAPC::Europaに参加した様子を報告しました。今年は8月にポルトガルのリスボンで開催されたそうです。規模は300人ぐらいで、ヨーロッパの多くの国から集まるとのことです。

 YAPC::Asiaなどと違うのが、交流がメインなところだそうです。30分単位の長いコーヒーブレークで飲みものやスナックが提供されるし、BOFが多くてロビーでたむろして論議していたりするとのこと。パートナープログラムと称して同行してきた奥さんたちが集まって観光とかしてたりもするそうです。

 あと、プレゼン中に客席からのツッコミが盛んとか、ヨーロッパ中から集まるので若者の旅費を支援する「send-a-newbie」プログラムを実施してたりするとかいう話もありました。ちなみに、女性が(いくらか)多いとか。

 反対に日本が進んでる部分としては、ビデオ中継や同時チャットなどが挙げられるそうです。

 そのほか、コペンハーゲンで開かれたYAPC::Europa 2008がおしゃれだったとか、台湾ではYAPCにPHPやRubyが合流してOSDC TW 2009が開かれたといったのも紹介されました。

 ちなみに、川崎さんのプレゼン自体も、カメラで撮った自分をリアルタイムでプレゼンに合成する「LiveSlides」という大技が使われていました。ActionScriptを使ってブルースクリーンなしでできるとのこと。DAISOで買った指サックを認識させてコントロールしてみせ、「Wiiリモコンより安い」と笑いをとってました。

PerlのWAF今昔(k-z-h)

 PerlにおけるWeb Application Framework(WAF)の歴史を振り返り、今回のYAPC::AsiaでアツいPSGI/Plackの紹介につなげる発表でした。

 k-z-h(kuzuha)さんによると、暗黒時代(cgi-lib.pl)、領主の時代(CGI.pm)を経て、元祖WAFとして登場したのがCGI::Application(城主の時代)だそうです。

 やがてCatalystが登場して帝王の時代になります。Catalystはしばらく仕様がよく変わっていましたが、Mooseでだいたい仕様が落ちついたそうです。仕様が落ちついた頃には、plugin禁止令などもありました。なお、Sledge、mojoなども同じ時代とのことです。

 Catalystがらみで、CatalystからEngineを抜きだしたHTTP::Engineや、DIコンテナのBread::Board、Bread::BoardをMoose化したMooseX::BreadBoardも紹介されました。

 そして最後は、YAPC::Asia 2009前の1週間ぐらいで登場して急速に開発されたPSGI/Plackが紹介され、HTTP::Engine+Plack最強という結論になりました。

みんなHTML5やろうよ(amachang)

 JavaScriptや人柄などで知られるamachangさんが、HTML5をセクションツリーを中心に紹介しました。技術力はもちろんのこと、使えそうな機能に着目して、使いたくなるように紹介するセンスが抜群ですね。

 HTML5はいろいろポイントがあるけど、ドキュメントの要素とAPIをセットで定義しているのが新しいという話でした。例として、canvasを使って3Dを表示したり、既存のページをcontentEditableでいじるということでYahoo!にGoogleやCPANのロゴを入れてみせたりしました。

 中でもいちばん力を入れて紹介していたのが、DOMツリーとは別の「もうひとつの木構造」であるセクションツリーでした。見出し要素とそれに続くテキストを組にして、見出し階層をツリー構造でとれる、ということみたいです。「既存のHTMLもけっこうきれいにセクションツリーになる」ということで、普通のブログにJavaScriptで目次を追加してみせたり、LDRizeふうに目次を移動してみせたりして会場をうならせました。

 最後に、「プログラマにはネタの宝庫」ということで、みんなHTML5を使ってみようと薦めました。

全裸でワンライナー(すぎゃーん)

 LLTVに続いて登場。「全裸で形態素解析」「YAPC::Asia全裸祭」などのマクラをふりつつ、Perlスクリプトをワンライナー化するAcme::OneLinerを紹介して笑いをとってました。スクリプトをDeparseした結果を1行にするそうです。

 1行にするだけではなくて、空白などを削るshortオプションとか、すべて記号だけにする(アルファベット等は使わない)symbolオプションなども紹介されました。

 ちなみに、全裸botもワンライナーにしてcronにしたけど動かなくて、cronのコマンドは1000バイトまでらしいとわかった、という役に立つんだか立たないんだかわからないトリビアも紹介されました。

Smoker - pluggable framework(nekokak)

 WAFだけじゃなくてCLIでも使えるのを目指した、プラガブルなフレームワークだそうです。HTTP::EngineとHTTPxx::Dispatcherがベースで、CLIはまだ未実装とのこと。ちなみに、名前の由来は灰皿に吸い殻が詰まった状態のイメージだそうです。

 プラガブルということで、細かい機能をComponentにして、いっぱい作るようになっているそうです。GitHubで公開中とのことでした。

PHPとのつきあいかた(bto×junichiro)

 PHP vs. Perlというネタの、ゆるめの公開討論というか、PHPプログラマが見たPerlの話だったと思います。ちょっと面白かった発言をメモ。

  • PHPは初級者の割り合いが多く、Perlは上級者の割り合いが多い
    • JPAはPerlによるWeb案件の裾野を広げてPerlの仕事を増やそうという試み
  • どの言語を選ぶかは最初にやった仕事に左右される
  • PHPは女子率が高い(笑)
  • プログラムを好きじゃなくて仕事でやってる人はPHPを選ぶ?
  • Perlのキラーフレームワークって?
    • PHPのかわりにはNanoA?
    • キラーはCatalyst?
    • ArkはCatalystから乗りかえやすい?
  • WordPressのコーディングのポリシーが…

エロサイト管理者の憂鬱II(yusukebe)

 yusukebeさんが、身をもって体験して工夫している、比較的小規模なWebサービスのノウハウを紹介しました。

  • 作って、運用して、マネタイズして、チューニング
    • プロモーションも自分でできる
    • ジョブキューやWAFも自分でやれるのが楽しい
  • Catalyst 5.7系、Mouse、DBIx::Class、TT
  • Catalystのディレクトリは牧さん方式を参考に
    • Webディレクトリの下にMVC、など
  • ./db/update_schema.plスクリプトを、DBスキーマが変わったときに走らせて更新
  • 実はHTMLテンプレートを買っている
  • 静的ファイルはS3に。Expiresを設定できる
  • アフィリエイト収入は自分で広告をとるより楽
  • サーバーの台数を減らしてコストを削減するためにチューニング
    • AnyEvent → Q4M → LWPの構成で負荷を下げる
  • HTTP::EngineをベースにWAFもどき
  • ec2はメモリ制限があるのでmemcachedじゃなくてCache::FileCache

1日目

 1日目は、朝から参加しました。基調講演の方向性か、自分がメイン講堂を中心に聴いていたせいか、いままでのYAPCよりビジネスや組織の色(JPA色?)の強い方向に振っていたように感じました。

Welcome(牧大輔)

 今回の実行委員長であり、JPA会長でもある牧大輔さんによる開会の言葉です。「Community」(コミュニティ)、「Corporate」(企業)、「Connect」(両者をつなげる)、という「3つのC」をテーマに掲げました。そして「Perlまみれになって楽しんでください」という言葉で開会を宣言しました。

基調講演:Perlの未来、その行程(Richard Dice)

 初日の基調講演は、The Perl Foundation(TPF)元代表のRichard Diceさんの講演でした。TPFやJPAのような組織の役割がテーマで、一般開発者とコードアーティスト(ハッカー)、企業が協力しそれぞれ拡大するエコシステムを作っていきたい、という話だったと思います。

 Diceさんは、FLOSSは時間とともに機能が増えていき、「安定した状態」=「死」に近づいていく、という話から始めました。

 「安定した状態」になる原因として「問題分野をすでにやりつくした(と思っている)」「開発者が興味を失った」「次のステップにコストがかかりすぎる」の3つが挙げられました。「問題分野をすでにやりつくした」については、時間とともに分野じたいが変化する、変化があったときに(初期段階から)加われないほうが怖い、というのを例とともに説明。Perl(CPAN)は基本としては必要にせまられた人が開発するのだが、必要にせまられなかったらどうするか、という問題を提起しました。それにあわせて、「開発者が興味を失った」「次のステップにコストがかかりすぎる」についても、人とテーマをマッチさせたり、場合によってはお金で解決したりするのが有効ではないかと語りました。

 TPFについては、直接的な収益モデルがなく、直接サポートする企業もないそうです。といっても収益がいらないわけではないと思う、と言った上で、Googleから収益を得ているMozilla Foundationや、業界団体的な性格のEclipseの例を紹介しました。ちなみに、Mozilla Foundationは、かつてTPFの一部になろうとしたこともあったそうです。そして、TPFの取り組みとして、Perl 6の並列プログラミングでIBM & Intelと提携したり、CLI上でのPerl 6ビルドでMicrosoftと協力したりする話が紹介されました。

 また、dijkmat.nlによるPerl 5.10.1開発補助金や、Booking.comによるTPJへの寄付と開発者の雇用、Perl6開発者を支援するHague基金などの事例が紹介されました。

 一方、TPFについて、ボランティアのみなので時間的制限がきつい、事務作業はスケールしづらいといった問題が挙げられました。TPF自身が力をつけるため、Hague寄付金でTPF自体を活性化する、たとえば追加雇用も視野に入れたい、との考えが語られました。

 最後に、エンタープライズに食い込むにはスポンサーシップが重要と説き、教育者、起業家、戦略的パートナーをPerlのエコシステムに組み込んでいきたいと語りました。こうしたエコシステム作りは開発者には動機づけが薄いものなので、TPFやJPAの役割であるとまとめました。

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

 「Perlの話はほとんど出てきません」と前置きして、mixiアプリの開発と、サーバー側の構成について解説しました。

 mixiアプリは蓄積されているソーシャルグラフを一般の開発者に解放する、というのが目的だそうです。mixiアプリと言った場合、一般に、mixi OpenIDのアプリを指します。ほかに、外部のサービスからアクセスできるmixi Connectもあって、こちらは個人情報にアクセスできるので契約ベースで進めているそうです。

 YAPCの時点で、231アプリ。マイミクの招待機能や、個人ページにマイミクの更新情報が表示される機能など、バイラルな機能で利用者が増えているそうです。

 mixiアプリは、OpenSocial 0.8.1+独自APIで動きます。OpenSocialに対応していれば対応SNSでみんな動く、というのがOpenSocialの理想ですが、実際にはSNSごとに独自API、デザイン、サポート範囲があるので、それぞれ独自APIが必要になるとのことでした。

 OpenSocialは2つあります。主にPC向けのJavaScript APIと、主に携帯(JS非対応機器)向けのRESTful Protocolです。いずれも、自分のWebサーバーでアプリを動かして、Gadget XMLにアプリを記述し、mixiに登録する形だそうです。mixiの場合、1つのGadget XMLにPC/モバイルを一度に記述できるようになっているそうです。

 SNS側の実装も紹介されました。SNS側では、Social Data API、Gadget API、Gadget Renderingを実装する必要があります。これらAPIの実装にはApache Sindigがよく使われているそうです。Sindigは、もともとiGoogleのサーバーソフトをApacheからOSSとして公開したものだそうです。

 mixiの場合は、Shindig(Java版)をifrとmakeRequestの2つでのみ使っていて、それにPerlのAPIサーバーを組み合わせる構成となっているそうです。

 さて、mixiアプリをリリースしたところ、mixiのサーバーのダウンやレスポンス低下に見舞われたそうです。これは、前例があまりなくて見積もれなかったのが原因だとか。

 まず、Shindigがダウンして、調べているとソケットをcloseしてなくて504エラーが頻発していたそうです。それを直したら、今度はPerlのAPIサーバーがダウンして、これは情報ごとに公開範囲の複雑なパーミッションモデルが設定されている構造により情報のアクセスごとに重いクエリーが走っていたのだそうです。そこでサーバー台数を追加していったけど、負荷が下がらない、ということで、Devel::NYTProfなどでプロファイリングして地道にチューニングして、効率が向上したそうです。具体的には、memcachedのキャッシュのヒット率の向上や、DBアクセス削減、処理順序の見直しなどだそうです。

 で、その結果、アプリ側で、負荷に耐えられないアプリが続出した(←今ここ)、と。通常のWebアプリよりアクセスが増える傾向もあって、アプリの安定稼働のためのTipsが紹介されました。たとえば、まず全マイミクをとってくるというような富豪的なプログラミングが流行っているが、パーミッションチェックが入るため応答時間が重くなるので、必要なだけアクセスしたほうがいい、と紹介されました。これは、ライブラリがそういうプログラミングをしていることもあるので、ライブラリの中を確認しよう、という注意もありました。また、画像がたくさんあると、そのままリクエストが自分のサーバーに集中するので注意、人気が出るアプリならGAEやEC2を使うのもいい、というのも紹介されまいた。

Plack/PSGI(tokuhirom/miyagawa)

 発表の前週の金曜あたりから開始して、今回のYAPCでホットトピックになっていたPlackとPSGIについて、急遽、tokuhiromさんとmiyagawaさんが共同で発表しました。始まる直前までコードをいじってたりして、ライブ感のあるセッションでした。

 PlackとPSGIは、いろいろなサーバー実装とWAFのはしわたしをするもので、PSGIが仕様でPlackが実装だそうです。ちなみに、PSGI(Perl Server Gateway Interface)はPythonのWSGI相当、PlackはRubyのRack相当とのことでした。ちょうどIRCなどで活発に開発されているところだそうです。今あるWAFのPlack対応は簡単で、10~20行ぐらい書けばいいとか、いやさすがにそこまではとか。

 Webサーバーの抽象化は、たとえばCatalystのHTTPエンジンはCatalystだけのもので、ほかのWAFで使えないので無駄、移植しても高速化したらほかの実装で実装しなおしになる、そこで共通のインターフェイスを作ろう、ということみたいです。HTTP::Engineもあったけど、HTTP::Engineは実装、仕様、APIがごちゃごちゃになっているので、それとは違う、と。HTTP::Engine::Intterfacce::PSGIを作ったので移行できて、HTTP::Engine自体はメンテナンスフェーズにするという話も出ていました。

 PSGIでは、リクエストはHASHREFで、レスポンスはARREYREF(同じヘッダーエントリーを複数入れられる)にして受け渡して、CGI感覚+αで使えるという話でした。で、PlackではそれぞれRequestクラスとResponseクラスにして扱うそうです。たとえばいままでリクエストクラスをインターフェイスごとに作り直していたけど、それが不要になるので、高速化されるはず、という話もありました。パフォーマンスについては会場の質問もあり、WAFが直接PSGIをサポートすると速くなるだろうとか、PSGIに対応していれば速いサーバーに簡単に移れるとかいうメリットを挙げて、ベンチマークも取る予定だと答えていました。

 アプリケーションローダーはplackupコマンドがあって、サーバーとのインターフェイスを切り替えてアプリを起動できるそうです。ただし、発表時点ではFCGIには対応してなくて、それはあたりまえすぎて書いてなかったからだとか。WAFのAPIの違い(new->run()のものとそうでないものとか)を吸収するフレームワークアダプタを、plackup -aで指定できるそうで、Plack::Adapter::Catalystを作ったという話もありました。

 予定としては、twitterのstreamingとかCometとかみたいなものに対応したAsyncとか、GAEでPerlを動かすプロジェクトにPSGI対応を相談中とか、Perl 6にも入れてもらうかとかいう話も紹介されました。あと、PerlだといろいろなインターフェイスでISPに受け入れられにくいし、mod_perlを入れたくないISPも多いけど、PSGIだったらPCGI::Liteもあるし安心だね、と。

 あと、会場との間で、Catalystが直接PSGIに対応すべきか、しかし既存のスクリプトが動かなくなると困るし実装を切り離すのがPSGI、でも本来からすると直接対応したほうがいいのではないか、といった議論も交わされていました。

inline::x86 JIT Assembler(TAKESAKO)

 Shibuya.pmリーダーの竹迫さんが、Perl上でx86バイナリを動かす話を、いつものように軽快な調子で紹介しました。つかみはまず、「Moose or No Moose」から入り、Mooseは遅い→Mouse?→OOやめる?→Perlやめる?→そこでInline::x86、という展開で笑いをとりました。

 まず、MS-DOSの.COMファイル(いわく「.comバブル時代」)やWin32のPE形式.EXEファイルでメッセージを表示する例を紹介しました。そして、「No binary, use Perl」ということで、PerlからWin32::APIモジュールでWindowsのメッセージボックスを表示する例や、DynaLoaderモジュールで機械語バイナリを実行してWindowsのメッセージボックスを表示する例を紹介しました。

 そのほか、CPUIDをとってくる例や、Linux/x86_64で64bit long modeを判別する例も紹介。"コード文字列 x 3" でループアンローリング(笑)とか、use varsで変数のアドレスを固定とかいったTips(?)も紹介されました。

 さらに、「正規表現でx86 JITコンパイラ」ということで、$SIG{TRAP}に、文字列に入った機械語コードをs///でnopをretに書き変えるコードを入れて、実行時に書き換える例をデモしました。

 最後に、Inline/x86.pmを紹介。ちょっとDSLっぽく機械語でPerlの関数を書けるようでした。

XS書きのためのPerl MAGIC入門(gfx)

 XSで最近活躍されているgfx(藤吾郎)さんが、PerlのMAGIC変数を解説しました。

 MAGIC変数というのは、SV構造体に機能を付け加えたもので、フックメソッドをテーブルに登録したり、malloc()したメモリを登録してキャッシュに使ったりするものだそうです。つまり、値を設定したときになにか動作をさせたりする変数でしょうか。特殊変数はほとんどMAGIC変数だそうで、ほかにTieとかweakレファレンス、UTF8 helper、Defer elementsなどもMAGIC変数を使っているとの話でした。MAGIC変数かどうかは、Devel::Peekでわかるそうです。

 ただしこのMAGIC、ドキュメントがアテにならなくて、Perlのソースを読むはめになるそうです。CPANモジュールにもMAGICを使ったものがいくつかあるとのことで、B::Hooks::EndOfScope、WeakRef::Auto、Sub::Name、Class::MOP/Mooseといった名前が挙がりました。

 MAGICはPerlレベルでは意識しなくていいようになっているのですが、XSを書くときにはMAGICを扱うAPIと扱わないAPIが区別されているので意識しなくてはならない(MAGICを使わない場合でも)のが罠だそうです。MAGICを起動するAPIとMAGICを起動しないAPIがあって区別しなくちゃならないのだけど、型変換をするxsetbppのtypemapは型によって起動するものとしないものがあって、これはバグじゃないか、という話でした。

 そのほか、av_storeとhv_storeの戻り値の問題、スタック操作をともなうケースの問題、PERL_MAGIC_extの問題などが紹介されましたが、私にはすでに内容が思い出せないので省略します。

 最後に、XS code templateが紹介されました。XSUBを自動的に生成するメカニズムだそうで、動的にコードを生成する、クロージャのXS版ともいえるものとのことでした。XS code templateについては、会場からメモリ消費について質問があって、Perl関数よりは少なくなるはず、との答えでした。

Yet Another BPM Framework "Kailas"(Masanori Wada, Yuusuke Wada)

 Web系で活躍するyusukebeこと和田祐介さんが、業務システムコンサルティングをしているお父さん(和田正則さん)といっしょに、株式会社ワディット名義で開発しているBPM(Business Process Management)フレームワーク「Kailas」を紹介しました。チベットの未踏峰カイラス山からとった名前だそうです。家では、親子アジャイル開発ということで、SubversionとTracを使い、毎朝ミーティングをやって、Daily Iterationを回しているという話でした。

 「YAPCとしては異質な内容」という前置きで、前半は正則さんがコンセプトを熱く語りました。コンセプトは、「システムではなく人間が主役のプロセスを志向する」「ITではなくビジネスの言葉でシステムを作る」「要求が決まればすのまますぐに動く」とのことで、それをWeb技術と融合することで実現するものだそうです。

 いままでの業務システムは、ビジネスや業務プロセスをそのまま実装できていなくて、システムの都合に合わせて人間が手作業して入力している、単なる伝票システム・帳票システムだと正則さんは語ります。これは、「決まった時間にデータをもってこい」とシステムに人間が命令されているようなものだ、と。

 Kailasのアプローチは、業務プロセスを分解して階層化する、つまりプロセスレベルと粒度を設定してコンポーネント(アクティビティ)化し、コンポーンントの連なりを定義する、と。アクティビティは受注確認などの単位意志決定で、原則1つのデータを確定するそうです。ここで、H.A.サイモンの意志決定プロセスが引き合いに出されました。

 適用業務としては、ERPや市販パッケージが手をのばしていない、引合・見積もり、調達、ユーザーサポートなどの顧客接点サービスプロセスを想定しているとのことでした。たとえば、依頼受付、データ確定、作業、報告というフェーズごとにアクティビティを割り当て、その状態遷移を定義するそうです。

 ユーザーインターフェイスについては、Web技術を活用し、情報へのアクセスのスピードを向上させることを狙います。集合知の活用(コミュニケーション、アドバイス、マッシュアップ)、履歴データの分析(レコメンデーション)などです。このあたりを、Process Designer、Configuration、Core API、Web Application、Web Interfaceとして構成しているそうです。

 会場では、祐介さんの操作で、修理サービス店の業務管理をデモしました。デザイナー画面では、キャンパスにコンポーネントを貼り付けてプロセスを設計します。これをワンクリックでデプロイして、Webにインストールします。個別のプロセスの画面で情報を設定し、たとえば受付情報や故障箇所の写真、担当者、要因などを各プロセスで入力します。そして、プロセスの進捗をバーで表示したり、進行中のプロセスと完了したプロセスを一覧したりといった様子を見せました。

 ちなみに、司会さん(k.daibaさん?)のコメントによると、BPSとしては承認フローが必要なのではないかという話もありました。

 最後に祐介さんが技術構成要素を紹介。UIにはjQuery UIを、データのシリアライズと保存にはJSON/YAMLを、JSONデータを元にしたフォームの動的生成とValidationにはHTML::FormFuを、WAFにはCatalystを使っているとの解説でした。

 最後に正則さんが、Perlのコミュニティの力が、「使われているのは1/3」「動けばいいとうことで質を問われない」というエンタープライズシステムの抱える問題を解決してくれるかもしれない、という言葉でセッションを締めくくりました。

modern Catalyst(hide-k)

 いまどきの、Moose時代のCatalystのお作法を解説しました。以下、箇条書きで。

  • NEXTやめれ
    • MRO::Compat
  • Moose化
    • mk_accessors()やめれ
  • アプリケーションを拡張する方法
    • プラグインやめれ
      • 怒られる
      • Application namespaceならまあOK
    • Helper Method
    • Role
    • base Controller
  • Roleを作る
    • setupでロード
  • Controller
    • Moose化
    • extends 'Catalyst::Controller'をBEGINで
      • てっぺんでロードしたい
  • Controllerを拡張
    • Moose::Role
      • MooseX::MethodAttributesを使わないとうまくいかない
    • ActionClass
    • ActionRole
  • Catalyst::Actionを継承
    • execute()、match()
  • Action
    • 利点
      • 再利用がきく
    • 欠点
      • 2つをアトリビュートにできない
  • そこでActionRole
    • Catalyst::Controller::ActionRole
      • Moose::RoleをActionとして継承
      • Doesアトリビュート
      • 2つをアトリビュートにできる
  • Dispather
    • default :Privateは将来使えなくなる
      • default :Pathを使う
      • catchall :Path
    • index :Privateもなくなる
      • index::Path Action()
  • :Chained()
  • $c->forward()、$c->detach()
  • $c->go()
    • forwardににている
    • autoも実行する
  • $c->visit
    • detach
    • autoも実行する
  • Model
  • Controllerにロジックを入れるな
  • Test
    • Catalyst::Test
      • ctx_request()便利
      • Cookieとかテストできない
    • Test::WWW::Mechanize::Catayst
      • Cookieとかテストできる
  • 資料
    • Catalyst::Delta
    • Catalyst::Upgrading
    • Catalyst::Manual::*
    • gihyo.jpのモダンPerl連載
    • 書籍「The Definitive Guide to Catalyst」
      • いい本だけどコードはかなり間違っている
  • PSGI
    • Catalyst::Engine::PSGI

Asynchronous Event programming fun with AnyEvent(miyagawa)

 非同期イベントを扱うフレームワークとして最近注目のAnyEventを、宮川さんが解説しました。「自分の書いたのじゃないモジュールを紹介するのは4年ぶり」とのことでした。ちなみに、AnyEventの作者はちょっと癖のあるキャラの人だというエピソードも紹介されました。

 イベントループ型プログラミングとしては、POEが人気ですが、独特の流儀が必要なため、ほかのモジュールと混ぜられないという問題があります。つまり、Aを待ちながらBを待つ、という場合、Aの処理とBの処理の両方がPOEに対応している必要があるわけです。その結果、CPANモジュールにはPOE::*がたくさんあるそうで「サイトごとにモジュールを作るようなもので、時間の無駄」と。

 それに対して、AnyEventならどのコードでも動くのが特徴だそうです。自分がどのイベントループで動いているかを自動的に検出してくれるので、POE::Kernelでも動くそうです。なので、AnyEvent::*のモジュールは現在35ぐらいだけとの話でした。ちなみに、宮川さんの作ったモジュールとしては、TwitterのStream APIを取るAnyEvent::Twitter::Streamや、ReverseHTTPを実現するAnyEvent::ReverseHTTPなどが紹介されました。

 AnyEventの実際の使い方も解説されました。基本は、コールバックを指定するだけで動いて簡単、AnyEvent->condvarで生成したオブジェクで状態をやりとり、と。実際に、タイマーイベントやI/Oイベント、サブプロセスの例が見せられました。

 はまりどころのTipsも紹介されました。まず、複数のcondvarをrecvすることはできないこと。10個を受け取ったら次に、といった場合に問題になるそうで、$cv->beginメソッドと$cv->endメソッドが使えるよ、と。複数のcondvarから待つ方法としては、$cv->cb()でrecvするコールバックを設定する方法と、Coro::AnyEvent、と。

 次にwatcherのスコープの問題。my $w;をつけて、コールバックでundef $wする、という黒魔術のような方法が紹介されました。よく理解できてませんが。

 ほか、オブジェクトが破棄されるときのコールバックとしてguardというのがあるとか、循環参照でオブジェクトを消さないようにする技とかも紹介されました。

優しいモダンなWAFの作りかた(dann)

 dannさんが、「WAF(Web Application Framework)作りがかつてないほど簡単になっている」ということで、自身の作ったWAFのAngelosを題材に。WAFの構造を解説しました。「シンプルなWAFは2~3時間あれば作れる」のだそうです。

 まず、モダンなWAFの特徴として、プラガブルに拡張(拡張性)、サーバー抽象化(テスタビリティ)、フルスタック(ユーザビリティ)の3つが挙げられました。例としてはそれぞれ、Plagger、WSGI、Railsだそうです。

 WAFの構造としては、Engine、Dispatcher、Component Managerの3つを中心に解説しました。EngineはWebサーバーとのインターフェイス、DispatcherはURIルーティングの部分です。

 特に力を入れて解説していたのが、Component Managerとプラグインによる拡張機構でした。dannさんの考えとしては、「WAFのコアは小さくして拡張可能に」「拡張箇所は限定する。どこでもフックできるより、フックポイントを明示的に与えるほうがいい」だそうです。

 プラグインの実現方法としては、ライフサイクルへのHook系(MouseのRole + method modifierなど)と、メソッドを生やす系(MouseのRole)が紹介されました。Angelosの場合は、PluginをRoleにして、Hookポイントとしてのmodifierを使っているとか。Hookポイントは大文字にすることで明示する、スコープを限定してHookポイントを絞る、といった工夫も紹介されました。

CPAN::Packager(dann)

 CPANモジュールを簡単にRPMやdebのパッケージにしてくれるツールCPAN:Packagerの紹介でした。同様のツールはいままでもいくつかありましたが、依存関係を解決してくれないとか、依存関係を1段階しか解決してくれないとか、依存関係の記述が間違っているときに対応できないとかいう問題があったので、新しく作ったそうです。記述の間違いなどの修正をYAMLの設定で自動的にフィックスしたりもできるとのことでした。便利そうですね。

 質問では、実はCPAN::Packager自身の依存モジュールが多いというツッコミもありました。

Solved in Perl 6(jnthn)

 England出身で今はSlovakiaに住んでいる、lead Rakudo developerの一人であるjnthnさんが、よく使いそうなPerl 6の機能をRakudoベースで紹介しました。

 以下、箇条書き。

  • 出力
    • say "hello,World!"
  • 入力
    • $*IN.get
  • 範囲
    • 1 <= $number <= 10
  • リストの合計
    • [+] @nums
  • ソートされているか確認
    • [<=] @a
  • Data::Dumpeerふうに
    • say @a.perl
  • リストのイテレーション
    • for @cities->$city { ... }
  • ハッシュのイテレーション
    • for %distances.$kv -> $city, $distance { ... }
  • 合格が含まれることを確認
    • if any(@a) >= 60 { ... }
  • 合格が含まれないことを確認
    • if none(@a) > 60 { ... }
  • ジャンクション
    • if $xx == 1 | 2
  • リストからランダムに抽出
    • @drinks.pick
  • リストをシャッフル
    • @list.pick(*)
  • 引数
    • sub greet($name){ ... }
  • *でリスト
    • デフォルト値
  • 数値の引数
    • sub double(Num $n) { ... }
  • マルチプルディスパッチも
    • multi double(Num $n) { ... }
    • multi double(Str $s) { ... }
  • マルチプルディスパッチで再帰
    • multi fact($n) { $n * fact($n - 1) }
    • multi fact(0) { 1 }
  • メタ演算子
  • 階乗の演算子を定義
  • クラス
    • メソッドとインスタンス
    • インスタンス化、メソッドの呼び出し
  • リストのすべてのオブジェクトのメソッドを呼び出す
    • @products>>.name>.say
  • メソッドを探す
    • Product.^methods(:local)
    • メタオブジェクト
  • メソッドの結果を利用してオブジェクトの配列をソート
    • @products.sort(*.name)
    • { $_.name } のシンタックスシュガー
  • マルチディスパッチでじゃんけん
    • win(::T, T) capture→同じ値
      • Tはただの変数名
    • win(Any, Any) それ以外
  • 使ってみたくなったらRakudoをダウンロード

Company Perl in Recruit, OpenSocial and Emoji (リクルートMTラボ)

 リクルートMTラボの開発状況について、石橋さんと川崎さんが紹介しました。

 前半は、石橋さんが解説。MTラボでは、リクルートの持っているDBからデータをもってきて、(リクルートに向けて)Web APIを提供しているそうです。DBを直接叩く構成から、WebサーバーからWeb APIをたたく構成にすることで、再利用性を高めているそうです。なお、DBをもらってくるには、定期的なジョブとしてまとめて取得しているとのことで、このへんは元が定期出版物だからという特性が関係しているようです。

 社内事例としては、エイビーロードやじゃらんなどが紹介されました。API化することで、仕様として固まるのでリファレンスを見てもらえばよくコミュニケーションパスが短くなること、DB本体でできない検索などレスポンス速度や機能面で優位なケースがあることなどの利点があるそうです。

 また、社外事例として、地球の歩き方やNAVITIME携帯グルメ、Google MapグルメクーポンにAPIを提供している例が紹介されました。これもコミュニケーションパスが短いこと、低コストで「とりあえず試してみる」ことができることが利点だそうです。

 システムは、RHEL(開発はCentOS)、Apache 2.2+mod_perl+Regstry+俺々フレームワーク+DBD::mysql、MySQL 5.0 + Sennaという構成が紹介されました。アジャイルな開発を採用していて、ペアプログラミングやテスト書きなどをやっているとのこと。社内ではレアだけど手法を社内に広めたい、とのことでした。

 近日登場としては、ホットペッパーのiPhoneアプリを紹介していました。前にWebアプリでやったのを作り直して、10月登場だそうです。

 後半は、川崎(kawa.net)さんが、携帯の絵文字や、OpenSocialへの取り組みについて紹介しました。

 絵文字はキャリアで違うので変換表が必要になります。最近ではGoogleがこのへんに取り組んでいてemoji4unicodeプロジェクトをやっていたりします。

 川崎さんは、emoji4unicodeの変換表へアクセスするUnicode:Emoji::E4Uモジュールと、それを使って絵文字変換をするPure PerlなEncode::JP::Emojiモジュールを開発したことを紹介しました。YAPC::Europaでも発表してきたそうです。Encode::JP::Emojiモジュールは、Pure Perlだけど十分な速度があるそうです。内部ではCP932にしてtr//などで変換するという実装だそうで、なんでもUTF8フラグがついたtrは3倍ぐらい遅いとか。

 ここで、キャリアが持ってない絵文字の例として「うんこ記号」を紹介して、IRCの画面が湧き上がりました。Googleがうんこ記号を提案しているそうですが、MySQL 5ではDBに格納できない欠点もあるとか。

 OpenSocialへの取り組みとしては、OpenSocialコンテナ「CREYLE」を紹介しました。10月にデベロッパーリリースだそうです。Apache ShindigのAPIの部分をPerlに移植して、それ以外はPHPをそのまま使い、Apache+FastgCGI+HTTP::Engineで動かしているそうです。ShindigをPerlで書き直した理由は、DBアクセスにPerlを使っているので揃えたいというのが大きいそうです。

 あと、Mashup Award 5も紹介。「リクルートは昔も今もPerlを使っています」という言葉で締めました。

LT:Moose Hacking Guide(gfx)

 ここからLTで初日が終わりました。

 まず、XSで知られるgfxさんが、Moose自体のソースの読み方を紹介するということで登場しました。Mooseは58モジュールに分かれていて、しかもClass::MOPの上にあるので、かなり複雑だそうです。そこで、Moose内の重要なモジュールを、カテゴリに分けて紹介しました。

 Tipsとして、みんな大好きNYTProfをソースコードビューアーとして使うと呼び出し関係がわかって便利、というのも紹介しました。

LT:PerlでSalesforce(藤原俊一郎)

 SalesforceのCRMクラウドをPerlから呼び出す方法を紹介しました。インターフェイスにはSOAPが使われていて、そのためのCPANモジュールもいくつかあるのだけど、WWW::SalesForce以外は何年も更新されていないそうです。APIまわりでは、SQLににたクエリ言語のSOQLとか、型指定とかも紹介されました。

 苦労話として、API回数制限があって増やすと料金がかかるので接続を使い回す工夫とか、ときどきつながらなくなるので更新系はジョブキューでとか、計画停止もあるとかあって、運用でがんばってしのいでいるという話でした。

LT:WebアプリケーションフレームワークMojoの紹介(木本裕紀)

 ブログ「サンプルコードによるPerl入門」の人で、著書「かんたんプログラミングCGI/Perl」も出した木本さんが、コンパクトなWAFのMojoを紹介しました。

 Mojoはオールインワンになっていて、ポータブルなのが特徴だそうです。なにより、気軽に扱えるMVCフレームワークなのが利点という話でした。

LT:Test::TCP(tokuhirom)

 TCPサーバーのテスト方法の紹介でした。

 テストが面倒なケースとして、TCPサーバーをテストするときがある、なぜならforkするとTest::Moreはおかしくなるから、と。TAPも使えない。そこで、Test::SharedForkで解決、という話でした。空いてるポートをさがしてそのポートでテストしてくれるそうです。

LT:Introducing im.kayac.com(typester)

 ポストするとJabberにメッセージが飛ぶサイトim.kayac.comを紹介しました。自分が呼ばれたらIMに通知、とかができるそうで、cURLでPOSTしてデモしていました。irssiやtiarra、HookHubに対応するスクリプトもあるそうです。最後に、新しくiPhoneに対応したことも紹介しました。

LT:miyagawanize(yusukebe)

 yusukebeさんが英語でLT。ネタは、宮川さんのプロフィール写真で使われている「紫色の何か」を合成する、「Geek Face Generator」相当のプログラムを作った話でした。名付けてmiyagawanize.pl。Image::ObjectDetectorを使って顔を判別して、そこに合成するというのがミソなようです。

 デモでは、小飼弾さん、牧大輔さん、Larry Wallさんなどで実験。モーニング娘。はなぜか1人だけ認識されなかったようです。そして、オバマ氏の写真を使って、"Can you miyagawaize him" "Yes We Can"とか盛り上がってました。

LT:nginxやlighttpdでMogileFSしてみた(kamipo)

 分散ストレージのMogileFSの話。動画とかだと重くなるので、perlbalをリバースプロキシにするのが定石だけど、perlbalはFastCGIを扱えないので、nginxやlighttpdでやってみよう、という話でした。が、nginxではキャッシュされない、lighttpdでは途中でエラーになって、どちらも失敗、というオチでした。

LT:Server::Starter - a super daemon to hot-depolyserver programs(Kazuho Oku)

 サーバーを(ほぼ)止めずにソフトを入れ替えるホットデプロイメントのソフトServer::Sterterを紹介しました。スーパーデーモンからサーバーソフトを動かすようになっていて、新しいサーバーの立ち上げに成功してから古いサーバーを落とすので、デプロイしても失敗しても落ちないそうです。新しいサーバーを起動するときにセルフテストする機能もある、plackupにも対応、daemontool併用おすすめ、という話でした。

LT:exception in Perl(nothingmuch)

 Mooseのコア開発者の一人であるnothingmuchさんが、Perlで例外処理を扱うモジュールを紹介しました。

 Perlの例外処理といえば、基本はdieとeval{}です。しかし、$@が""だとifで判定をミスるとか、rethrowの問題とか、DESTROYされたらとか、いろいろな場合に対応しているとコードが肥大化していくという例がいろいろ示されました。そこで、try とcatchを書けるモジュールを作ったよ、と。Try::Tinyってやつかな。

2日目

 2日目は私は用事があって、15時から参加しました。Coroのセッションとか聴きたかったんだけどな。

Building a desktop app with HTTP::Engine, SQLite & jQuery (miyagawa)

 宮川さんが、Perlによるメディアセンターアプリ「Remedie」を解説しました。会場でも、Remedieを使っている人がけっこうな数でいたようです。

 まず、デスクトップアプリを作りたいときにはいろいろな手段がありますが、いまどきですし、Webプログラマーなので、それ相応の手があるだろう話からスタート。PhoneGapやHTML5という技術もあるけどまだ早い。そこで2009年はmicro Web appだ、という話でした。RemedieもHTTP::Engineベースのmicro Web appです。

 ここでさっそくRemedieをデモ。Twib対応とか、順番を入れかえる機能とか、iPhoneからアクセスしてリモコンになるとか、Bonjour対応で同じLANのRemedieの一覧がとれるとかいった新機能を紹介しました。パフォーマンスについても、AnyEventとCoroでノンブロッキングにしたと説明していました。

 DBにはSQLiteを利用。ファイルベースで、型がきびしくない、トランザクションあるという理由だそうです。ファイルベースならユーザーが起動を意識しなくていいし、バックアップやマシン間同期もしやすい、と。ただし、JSONのテキストをカラムに入れて、Key-Valueストアみたいなシンプルな使い方をしているそうです。

 ORMには、Rose::DB::Objectを利用。これは「使ってみたかったら」だそうで、けっこうメモリを食うので変えたいという話でした。

 ユーザーインターフェイスは、空のdivを入れてjQueryで書き込む方法で、jQueryのプラグインをいろいろ利用しているそうです。Cometのメッセージと組み合わせて、リモートで渡されたメッセージをevalする(iPhoneリモコンとか)という手法も紹介されました。

 そのほか、CometをCoroで、とか、PubSubで新しいチャンネルを通知とか、もっとアプリみたくやりたいということで、FluidやPrismでアプリっぽく起動する話とか、パッケージング重要でCPANモジュールをたくさん入れなくちゃならないのは面倒なのでlocal::libとか、Platipathでパッケージ化とか、Snow Leopard対応とか、perl-app-builder作ったとかいう話もありました。

Kioku(nothingmuch)

 nothingmuchさんが、オブジェクトを永続化して保存するKiokuDBを紹介しました。日本語の「記憶」が由来だそうです。「プロダクションで使われている」ことを強調していました。

 KiokuDB->connect()とかやって、なんでもオブジェクトを作って保存できるそうです。オブジェクトにはユニークなIDがふられて、$k->lookup($id)とかしてfetchするとのことでした。

 オブジェクト単体だけではなくて、それらのリンクも保持されるそうです。リンクリストや循環リスト、グラフ、継承、Role、などが保持されると紹介されました。

 トランザクション機能もあって$k-gt;txn_doで使えて、常にを使おう、そのほうが速いし安全という話もありました。crontabやCLI、ユニットテストなどがら使う方法も紹介されました。ヘルパーメソッドKiokuX::Model、Catalyst::Model::KiokuDB、認証のKiokuX::Userなどもあるそうです。

 KiokuDBのバックエンドとしては、複数のドライバが簡単に実装できるようになっているそうです。会場からプロダクトで使っているときのバックエンドは何を使っているかと質問があり、DBIバックエンドを使っている、昔はBDBを使っていたがときどき問題が起きるのだやめた、との回答でした。

 性能については、最適化されていないけど、なかなかよい、との話でした。

 TODOとしては、バックエンドの種類をもっと、永続的なメタクラス、未来のDBICと共有、クラスのバージョニング、パーティショニングなどが語られました。

LT:Top Tens Of 2008-2009(charsbar)

 ここから2日目のLTです。

 charsbarさんは、CPAN Authorの統計数字をいくつか紹介して、この1年で最もモジュールをリリースした日本人はtokuromさん(世界でも9位)、最もCPAN Authorが住んでいるのは日本、などの話を紹介しました。

LT:hacking ngnix(Yappo)

 Web(ほかいろいろの)サーバー「nginx」のモジュールを作ってみたという話でした。nginxはけっこうプラガブルで、イベントループにソケットを入れていろいろなプロトコルに対応できるそうです。あと、標準でエンベッドなPerlが入っているそうです。

 作ったnginxモジュールngx_http_yappo_moduleを紹介したあと、ベンチマークのデータを見せていました。そのほか、Plack::Impl::Nginxを作ったという話もありました。

LT:Mojo / Mojolicious hookout(ka2u)

 Mojo/Mojoliciousを使って、WebHookを使ったアプリを作った話でした。Reverse HTTP(PTTH)を実現するMojo::Server::Reversehttpを作り、WebHookと組み合わせて、誰かがはてブにアクセスすると、Gtk2::NotifyでNotify OSDからnotifyしてくれるというのをデモしました。

LT:Hoppyではじめよう リアルタイムweb(ダウンロードたけし)

 Flash XML-SocketのサーバーをPerlで実装した「Hoppy」の紹介でした。プッシュ型のWebアプリケーションが書けるそうです。POEベースで、JSとの連係も簡単、という話でした。

LT:perl hacks on emacs(typester)

 Vimのセッションがあったのに対抗して、ということで、同じカヤックのimakadoさんが作ったEmacs Lispプログラムを紹介しました。

 1つ目は、cperl-modeのインデント位置を変えるパッチ。jrockway版のcperl-modeにも採用されているそうです。

 2つ目は、perl-completion.el。useするモジュールやnewしたときの引数、メソッド名などを補完する機能があるそうです。

 3つ目は、anything-project.el。プロジェクトの中のファイルだけを検索できるanything系プログラムだそうです。

LT:args.pm - a brand new argument validator(tokuhirom)

 簡単に引数のバリデーションをするライブラリargs.pmを作ったという紹介でした。MooseX::Declareはハックすぎるのでもっと普通に、でもPadWalker::perl5を使ってる、という話でした。

LT:CPAN realtime feed(miyagawa)

 CPANの最新情報をリアルタイムに取るしくみの紹介でした。通常、CPANにモジュールをアップロードすると、アップロードの時間、PAUSEのインデックス時間、そのミラーリング時間、更新間隔、モジュールのミラーリング時間、CPANシェルのキャッシュ期限などで、最新情報を取るのに最大48時間かかるそうです。

 そこで、CPAN Realitime feedというのを使うと、1秒前にアプロードされたモジュールの情報が取れる、friendfeed botやAPIもいろいろあるよ、CPANシェルコンパチのcpanfコマンドもあるよ、というのを紹介しました。

 LTでは実際にその場でモジュールをアップロードして、LTの時間内に表示されるか、というのをデモしていました。

LT:IRC HTTP Stream(yusukebe)

 前日の晩に思いついて実装したIRC botを紹介しました。PlackとAnyEventを使っているそうで、twitterにもポストできるそうです。

 で、「それPla」(それPlackでできるよ)= "Yes, Plack can"、と、前日のLTに続きオバマねたで笑いを取っていました。

基調講演:私がPerlにこだわる理由(jrockway)

 jrockwayさんの基調講演は「なぜPerl」「なぜプログラミング」というスピリチュアルな言葉をまず提示しました。これについて、プログラミングするのはアイデアがあって実装するため、なにかをかたずけるためだと説明し、それにはよりライブラリが重要であり、Perlにはライブラリがあると語りました。

 ここでjrockwayさんは、Perlの歴史をひもときます。元のコンセプトは、Unixの、再利用可能なコマンドとシェルでプロセス間をつなげるというものでした。Perlも、しばらくはそれをより簡単にするものとして活躍しました。やがてWebなどほかの領域でも使われるようになるようになり、拡張していき、ライブラリが出始めて、CPANが誕生したわけです。新しく作ったソフトをほかの人も使えるようにするライブラリ文化の登場です。これにより、人助けの文化と、過去の膨大な蓄積が生まれました。

 こうしたPerlとライブラリモ、古いアイデアを少しずつ新しいものに変えてきました。jrockwayさんは、Perlのオブジェクト指向がISA→モジュール実装→Class::Accessor→Mooseと進化してきたことを例に、古いコードもまだ動くし、Rubyにしないで改善を試みていることを説明しました。

 こうして日々新しいアプリを書くのが簡単になっているというライブラリの力を、Remedieなどを例に挙げながら強調し、「コミュニティがサポートしているコードを使うのは正しい」と語りました。ライブラリの開発を支える原動力として、Catalyst、Moose、POE、HTTP::Engineなどのサブコミュニティが活発であると紹介し、「Coolなことはサブコミュニティで起こる」とも語りました。

 そのほか、「ライブラリは作者の得意なやり方で書かれる」と語り、CatalystやMooseを例に、「良いコードを書くのが悪いコードを書くより簡単になる」のをライブラリのひとつの方向性としました。

 これからについて、まずWebを例に、CGI.pm→CGI::Application→Catalystと進み、フレームワークがコードの共有を簡単にしてきた歴史を振り返りました。そして、「フレームワークはもういい」として、欲しいものはユーザーに選ばせる「ライブラリの復活」を語りました。たとえば、Catalystというフレームワークに対して、ライブラリとして切り出されて発展したHTTP::Engineが例に挙げられました。

  最後に、「私がPerlにこだわる理由」を改めて取り上げ、Perlを使うとやりたいことを簡単にできる、退屈なこともコミュニティの成果を生かせる、皆さんが助けてくれるから、と語り、「I love Perl」という言葉で締めくくりました。

Closing(牧大輔)

 スクリーンに映されたパロディ動画とともに登場。開会のときに掲げた「3つのC」を再び出し、CommunityとCompanyが産み出す生態系をJPAとして作っていきたい、という言葉で締めました。

コメント

コメントの投稿

管理者にだけ表示を許可する

トラックバック

http://emasaka.blog65.fc2.com/tb.php/667-facf8678

 | HOME | 

Categories

Recent Entries

Recent Comments

Recent Trackbacks

Appendix

emasaka

emasaka

フリーター。
連絡先はこのへん

Monthly


FC2Ad