前夜祭レポート［随時更新］

明日、明後日（9月10日、11日）に、YAPC::Asia 2009が開催されます。それに先立ち、本日「Yokohama.pm 出張版 - YAPC::Asia 前夜祭」が開かれます（スピーカーはこちらのページを参照⁠）⁠。

本ページでは、このYAPC::Asia 2009 前夜祭をレポートしていきます！

イベント前の受付

イベント前の受付準備中の風景です。

前夜祭開催！

前夜祭の開催にあたり、yokohama.pmの栗原さんより挨拶がありました。

acotieさん「AnyEvent的ななにか(仮)⁠」⁠

AnyEventについてacotieさんが発表しました。AnyEventはイベント・ドリブンを実現するフレームワークです。例えばTwitterのフィードから特定の発言を抜き出したり、新着のフィードがあったときだけ何か処理行なったりすることが可能です。

デモではTwitterの発言の中から「髪を切った」というコメントだけを抜きだし、それを集計するアプリケーションについて説明がありました。実装は簡単ですが、とても奥の深いフレームワークで、継続的あるいはリアルタイムに何かしたいときに使えます。興味のある方はAnyEvent::Introを参照してください。

spiritlooseさん「Schenker - DSL for quickly creating web applications in Perl」

spiritlooseさんが紹介するのは、Sinatraにインスパイアを受けた、DSLによるWEBフレームワークであるSchenkerです。SinatraとはRubyのWEBフレームワークで、DSL的にWEBアプリケーションを記述できるのが特徴です。また、DancerやMojolicious::Liteなど、他にも似たフレームワークはあるとのことです。

実装には、HTTP::Engineを使っているそうです。これは、RubyでいうRack、PythonでいうWSGIであり、WEBサーバとWEBアプリケーションフレームワークの中間に位置する、様々な処理の規格を決めてくれる物です。

Schenkerでは、WEBアプリケーションはDSL的な記述をします。例えば、ルーティングは get '/' => sub {} のように書いたり、入力パラメータを取得するには直接 params->{hoge} と記述したりできます。これは、直感的で非常に便利と思いました。

今後はPSGIやPlack等の動向を見て、対応ができたらリリースを行いたいとのことでした。また、最後の質疑応答でmiyagawaさんが「セッション中にPlackで動作するようにした」と発言し、会場を多いに沸かせました。

kawanetさん「YAPC::Europe 2009（ポルトガル）参加報告」

ポルトガルのリスボンで開催されたYAPC::Europe 2009に参加した感想についてkawanetさんから報告がありました。 YAPC::Europeはヨーロッパ全土から参加者が集まる「最も国際的なYAPC」ということでした。今回のYAPC::Europeの参加者は328人で、その特徴として

コーヒーブレイクの時間が多く食べ物も沢山用意してあるので空腹の心配が無い。
プレゼン中のとっこみが多い。
BoFが多い。
女性がいくらか多い。ということが挙げられました。また、日本との比較として、
日本とヨーロッパではカンファレンスに求めている価値が違う。
運営面は日本の方が優れていることが多い。などが挙げられました。そして
日本人も海外のカンファレンスへ参加しよう。
日本のYAPCでも海外からの参加者を暖かく迎えよう。という呼び掛けもありました。

k-z-hさん「PerlのWAF今昔」

k-z-hさんのセッションは、PerlのWEBアプリケーションフレームワークの歴史について、振り返るものでした。「⁠暗黒時代」から「帝王の時代⁠」⁠、そして現在までを一気に振り返りました。

暗黒時代と言われていたのは、cgi-lib.pl。その後、CGI.pm、CGI::Applicationと時代は続きます。古くからPerlを使っている筆者としては、非常に懐かしい限りでした。jcode.pl、なんて時代もありましたね。

そして、帝王の時代はCatalyst。ただ、Contextが頑張り過ぎているのが好きではない、とk-z-hさんは主張されていました。そこで、HTTP::EngineとBread::Boardを合わせて使うのが、これからのおすすめではないか、といった内容がセッションの結論でした。

PerlのDIコンテナであるBread::Boardに関しては、さらに依存性の解決力を高めるため、MooseX::Bread::Boardが開発されているという紹介もあり、こちらも大変楽しみです。

amachangさん「Web的ななにか」

HTML5についてamachangから発表がありました。自己紹介の後、HTML5の概要について以下の要点が挙げられました。

独自仕様の再定義
新しい要素、属性
API(これが重要)

独自仕様の再定義

document.write、canvas、contentEditableなどこれまで独自に仕様が定義されていたものが再定義されます。

新しい要素、属性

nav、 aside、 article、 section、 canvas、 dateなどが追加されます。

API

HTML5まではドキュメントの仕様だったものが、HTML5では「ドキュメントの仕様+APIの仕様」のようになっています。

もう１つの木構造

HTML5には既存のDOMツリーとは無関係なセクション・ツリーが存在します。そして全ての要素は必ず単一のセクションに関連付けられ、セクションツリーを生成するための明確なアルゴリズムが存在します。

仕様を読もう

HTML5の仕様書はプログラマにとってネタの宝庫です。

最後にamachangから「HTML5って楽しいですよ。皆さんも試してみてはいかがでしょうか?」という呼び掛けがありました。

sugyanさん「全裸でワンライナー(仮)」

まず、LLTVにて発表されたという、「⁠全裸で形態素解析」という話を紹介して下さいました。これは、文章を形態素解析し、動詞の前に「全裸で」という言葉を入れると、色々な文章が面白くなるといった内容のものです。sugyanさんは、さらにtwitterのつぶやきに勝手に「全裸で」を入れる、全裸botを開発しているとのことです。

次に、ワンライナーについての話がありました。通常のワンライナーは、特殊文字や記法を駆使していかに短く書くかということに力を入れますが、sugyanさんが今回考えたのは、どんなスクリプトでも1行に変換すればそれはワンライナーだ、ということでした。

それを元に作ったモジュールが、Acme::Oneliner。どんなスクリプトでもワンライナーにしてくれる便利（？）なもので、--shortや--symbolといったオプションで出力されるワンライナーの調整もできるそうです。ただし、crontabに張り付けると長過ぎて起動しないようだと、ワンライナーの限界について嘆いていました。

nekokakさん「SmokerっていうぷらっがぶるWAFをつくってみたよ！」

SmokerはHTTP::Engineベースで、WAFだけでなくCLIで使うことも想定したフレームワークです。特徴としては、いろいろなComponentを作って、それを組み合わせてContextを作ります。Smokerはgithubで公開中です。

junichiro x btoさん「PHP的な何か(仮)」

普段はPHPを使っているというお二人のセッションで、Perlの未来について考えるといったものでした。junichiroさんは昨年のYAPC::Asiaのセッション「Perl Is unDead」を聞いて感銘を受けたそうです。一方でbtoさんはPerlを使ったことがないそうで、では、なぜbtoさんはPerlを使ったことがないのだろうかという辺りから掘り下げていきました。

まず一番初めに取り上げられたのは、PHPにはユーザが非常に多いということ。しかし、これには、PHPには初心者層が多く、Perlには楽しんでいるプログラマが多いので、質が違うのだという意見が。その上で、PerlではJPAが法人活動も行っており、今後一般企業にPerlが採用されることも増えてくるのではないかとJPAの取り組みを歓迎していました。

その一方で、やはりPHPのユーザが非常に多いというのは利点であるということで、Perlを使う人数を増やすのにはどうすればいいのかという話に。PHPの利点として、デザイナでも使える便利さが大きいので、この点を真似してはどうか、という提案がなされました。その中で、やはりPHPでは$_GETや$_POSTが使えたり、HTTPヘッダが自動で出力されるのは、初心者には魅力的だろうという話が出ました。

また、参考としてWordPressの徹底した初心者向けのポリシーを紹介。その中にはクラスを使ってはいけないなど、プログラマーにはありがたくないものが多く入っていますが、実際の普及にはこのようなことも考えなければならないのではないかと、問題提起をしていました。

最後には、PHPの$_GETや$_POSTなどの機能を初心者が迷わず使えるように、キラーフレームワークとなるようなフレームワークの登場が、Perlの普及につながるのではないかとまとめていました。そのフレームワークとして、NanoaやArkなどが挙げられており、今後もこれらのフレームワークの動向からは目が離せないと感じました。