YAPC::Asia2009に行ってきました

去年はチケットを購入しながらも仕事で行けなかったのですが、ついにリベンジ! 前夜祭となる出張Yokohama.pmから3daysフル参加してきました。LLTV 〜 PHPcon 〜 YAPCとイベントが続きすぎて、体力の回復が全く追い付かんとです…

個別のセッションを全てエントリに起こす余力は無いので、人気のありそうなところはあえてスルーして、セッション単位でなくトピック単位で個人的なまとめ。

■P5EE

基調講演の中で軽く紹介された、2002年頃のプロジェクト。Perl本体とたくさんのCPANモジュールを合わせてパッケージ化して、Enterprise向けに提供しようという内容だったようです。

「開発者の興味が続かなかった」とのことですが、アップデートの追従とか何を入れるべきかとか、難しい課題は山のようにあったことでしょう。コアモジュールと、P5EEで採用されるモジュールとの線引きも難しそう。

今回紹介されて初めて知っただけで、具体的な当時の流れは全く分からない訳ですが、聞いた限りではすごくもったいない事のように思われました。当時の日本の状況で考えれば、企業が開発で使うというより、レンタルサーバに導入するソリューションとして有用だったんじゃないでしょうか。まとまったパッケージがあれば、レンタルサーバへの導入も進んだだろうし、サーバを移転しても同じモジュールが入っていることが期待できればアプリケーションを書く側にとっても安心感があったはずです。

僕自身、当時は安価な共用サーバで、モジュールもろくにインストールされていない環境でPerlを使っていました。その後、PHPが普及し始めて「標準でこんなことが出来るなんて便利だ」ということでPHPを使い始めたという経緯があります。あの時、サーバにP5EEのようなまとまったパッケージがインストールされていたら、また違った道を歩んだかも知れません。

ググってもあまり情報が出てこなかったので、わりと初期段階で頓挫した計画だったのでしょうか。戦略としては面白いと思うのですが。

PSGI/Plack

あちこちで書かれてるし、最低限のメモだけ残す。

  • PSGIは仕様」「Plackはリファレンス実装」
  • requestはHashRef、responseはArrayRef
  • アプリはHashRefを受け取って、ArrayRefを返すCodeRefを返す

■Catalyst5.8とMoose

未だに5.7しか使ってなくて、依存関係でうっかり5.8が入ってしまわないようにビクビクしてるわけですが、やっぱりいろいろ変わってるんだなと改めて思った。

今の仕事で使ってるサーバはスペックが貧弱なので、僕にとってCataMooseは実用的な選択では無いのです。確かに内容は良くなっているように見受けられるけど、だからといってそのためにサーバのスペックを上げる、つまりは固定費を増やすことは出来ないのが現状です。

また、Catalystに限らずMooseを使うということは、実質的にCGIとの決別を意味します。それも一つの流れとして理解は出来るし、よほどの小規模案件でもない限りCGIで運用するケースは少ないのかも知れません。でも実際にそういうスクリプトを書く機会は、少なくとも僕にとっては日常のよくある風景です。

もちろん全てがMoose化することはないだろうし、MouseやArkやDBIx::Skinnyといった、より軽量なアプローチもどんどん出てきてはいます。とは言っても、Perlのメインストリームとも言える大きなモジュール群がどんどんMooseに流れていくと、いろんなモジュールが気軽に使えなくなる懸念もあります。

Perlをより広めるとか、もっとカジュアルに使われるようにとかいったことを考えると、この方向性には一抹の不安を覚えるのも正直なところです。もちろん、Mooseの有用性は踏まえた上で。

■Ark

CGIでスタートして、アクセスが増えたらFastCGIとかに切り替えられる」のがウリだと思ってたら、「人気が無くなったサービスをCGIに出来る」って紹介されてて吹いた。

最近はCatalystからこっちに移行しようと、ちょこちょこ触ってました。いろいろ話が聞けて、知らないこともいっぱいあってよかった。

Ark::FormとかArk::Modelsあたりの最近になって追加された機能は、ドキュメントが全く無い上にサンプルも無いのでどうしたもんかと思ってたけど、そのへんも解説があったのでとっかかりが出来ました。

ていうか、実プロダクトのソースコードが公開されてるなんて知らなかったよ! ちょっと覗いただけでも、ものすごい参考になることばっかりで失神しそうになった。

■FormValidator::LazyWay

Data::FormValidatorを源流とするValidatorモジュール。フォームに対して条件を定義するのではなく、項目に対して条件を定義していって、フォームは条件の集合体であるという考え方は新鮮に感じました。

バリデーションって難しいですよね。Modelでやるのか、Controllerでやるのかとか、いかに効率よく信頼性の高いものを書くかとか、かなりの迷いどころ。

個人的にはControllerでのバリデーションは「ユーザーの入力に対する検証」で、Modelでのそれは「アプリケーションが保持するデータに対する検証」として、どちらでやるかといったものではなく、別々の物としてどちらも必要ではないかと考えています。

ただ、それをそのままコードに落とすと、同じようなバリデーションのコードをあちこちに書くことになって効率が悪いし、保守性も低下してしまう。そのへんが目下の悩みの種です。

mixi

「PCよりもケータイから使う方が一般的」ってイメージだけど、PVの75%がモバイルと聞くと改めて多いなと感じる。ケータイの方がページを頻繁に切り替えるから、PVが増加傾向になるとは言え、やっぱり多い。

あと、長野さん = kazeburoさんだと認識していなかった。WEB+DBの連載で見てたはずなんだけど、脳内で情報として整理されていなかったらしい。

■kazuhoさんのMySQLトーク

PacificはDB分割とかするような大規模プロジェクトはもちろん、ふつうにレプリケーションを使うだけの環境でも管理ツールとして有用そうに感じた。そして、なんしかプレゼンが全編に渡ってかっこいい。惚れる。

先日のPHPconでも紹介されてQ4Mが非常によさげなので、そのためにMySQL5.1入れようか。

■「ライブラリに頼る、フレームワークに頼らない」

最後の基調講演でのこのポリシーは非常にPerlらしいと思ったし、これには全面的に賛同したい。フルスタックのフレームワークって、どうしてもあまり好きになれない。

フレームワークに全面的に頼ってしまうと、その言語ではなくフレームワークに支配されることになるので、言語の可能性を狭めかねないのが気にかかります。

■英語

英語セッションの基本的な流れは、スライドは翻訳付きで(charsbar++)トークは英語。それも日本人向けにゆっくり話すとかじゃなくて、ふつうに英語。一部、Emersonさんがいる部屋は質疑応答での翻訳サポートはあったりしたけど、本編は一切の翻訳無し。日本人のプレゼンでもスライドは英語のみとか、英語+日本語の物も多かった。

そんな英語セッションがだいたいいつもどこかで行われているような状態で、かなりストロングスタイルな印象を受けました。事前に分かってはいたけど、やっぱり実際に体感すると改めて「日本語だけではやっていけない」と思い知らされます。

英語のセッションは何を話しているのかほとんど聞き取れなかったんだけど、他の人は皆あれぐらい平気なんだろうか。正直、もう少しゆっくり話して欲しいと思った。

先日のPHPconでは、Symfony開発者のFabienが英語で発表してたけど、あちらはゆっくり話す(彼自身がフランス人だからかも知れないけど)+全編翻訳入りだったのと全く対照的なスタンスだったことが印象的です。どちらがいいとか悪いとかではなく、それぞれの姿勢の違いは興味深い。個人的には両者の中間ぐらいがちょうどいいかな。

Perlコミュニティと自分

そこかしこで声かけてもらったり、名前呼ばれたりして、すごく嬉しかったです。あとは思った以上に「ブログ読んでます」とか「Twitterで、Wassrで見てます」とか言われることが多くて、見てくれてるんだなーと感慨にふけったり。

まだ結構おっかなびっくりなところがあるんで、そのへんはもっと何とかしていきたいですね。こういう場でどれだけ堂々としていられるかというのは、やっぱりそれまでに自分が書いてきたコードが一番の土台だと思うので、その積み重ねをやっていきたい。会場で「この中でCPANにモジュールをアップしている人どれぐらいいますか?」という問いかけに対して挙がった手の多さは衝撃的でした。

実際に業務でモダンなPerlを書ける環境がどれぐらいあるか? ということは若干の疑問や不安を覚える面もあるのですが、Perlの面白さを全身に刻み込んだ3日間となりました。来年は更に満喫できるようにしたい。

そして、あの講堂の階段はどう考えても設計ミス。ケガ人出るぞ、本当に。