タグ別アーカイブ: perl

「モダンmod_perl入門」のこれまでとこれから #yapcasia

こんにちは、先日YAPCトークデビューした おがた (@xtetsuji) です。

YAPC::Asia Tokyo 2012 に行ってきた感想については以前のエントリでたっぷり書いたので、ここでは、YAPCで初トークした「モダンmod_perl入門」の詳細や、これにいたる経緯、そしてこれからの計画について書いてみようと思います。

トークのフォロー

まずはトークを聴講しにきてくださった方々、ありがとうございます

話したい事がいっぱいあって、20分の枠に収めるのにトーク直前まで四苦八苦していたのですが、時間超過などのカッコ悪いことにならず、何とかうまく話せたかなと自分では思っています。

トーク内容の一部フォロー

SlideShareにアップロードする段階でトークのスライドを見返していて、ちょっと説明不足だったかなというところがあったので、ここで補足させていただきます。

mod_rewriteのPerlTransHandlerでのリファクタリングの話で、「Directory Contextに書かれたmod_rewriteの場合、別途ケアが必要になる場合がある」といった内容に触れました。Directory Context の例として <Location> と .htaccess をスライドで例示していますが、まさに Directory Context の代表と言える <Directory> に触れていないのは、単に忘れていただけです。

実際、mod_rewriteは「URLを書き換える」処理を行っているわけですが、PerlTransHandlerに対応するApacheフェーズでは、まだURLから実ディレクトリへのマッピング処理が完了していません。Apache設定のルートや<VirtualHost>直下に書かれたmod_rewriteの場合は、まだURLから実ディレクトリへのマッピング処理が行われない段階、つまりPerlTransHandlerと同じフェーズで処理されるので問題がないのですが、Directory Contextでは既にURLから実ディレクトリの解決が済んでいるわけです。mod_rewriteは、この部分をうまく解決するために内部的に多少面倒な事を行っています。このようなこともあり、mod_rewrite では $r (Apacheモジュールでいえば request_rec 構造体 r) が持っている uri 情報を実際は書き換えず、書き換えて穏当に実ディレクトリを解決したように見せかける処理を PerlFixupHandler と同等の場所(リクエスト処理フェーズの直前)で行っています。通常は問題にならないと思いますが、レスポンスフェーズで動作するプログラム(CGI, PHP, mod_perl Registryスクリプト等)がURLをつぶさに見る場合に状況によっては mod_rewrite → mod_perl PerlTransHandler の単純な書き換えで同等の動作が保証されない場合もあります。この辺りは mod_rewrite が見事とも言える複雑な処理をしている部分が大きいです。皮肉ですが、mod_rewrite 設定がすぐに魔窟になる所以でもあるでしょう。

PHPとの連携については、PHP以外の言語でもレスポンスフェーズで入出力を処理するものについては同様の事ができるはずですが、自信がなかったので私が経験したPHPとの連携に限ったお話とさせていただきました。PHPがレスポンスフェーズ以外でほとんど仕事をしないポリシーであることはPHPのコア開発者が述べていることでもあります(これはApache以外へのPHPの移植性を考えてのことでしょう)。その明瞭さゆえ、レスポンスフェーズでPHPが動作する場合、他のフェーズでmod_perlを投入することで干渉が起こらないと言っていいのです。

最近はdisられ役になったり、PHPプログラマ自身がそれを自嘲気味にネタにする時代ですが、私はPHPが得意な人・Perlが得意な人で協力しながら開発をする姿も良いと思っていますし、mod_perlがPHPとPerlを繋ぐ糊(glue)となって欲しいという思いもあります。誤解は無いとは思っていますが、少なくとも私のトークではPHPをdisったりする意図はありません。だからといって、多種多彩なプログラム言語で書かれたプログラムが乱立している状況だと保守性もへったくれもないので、必要性に応じて仕事では社内のプログラム言語はある程度統一しておいたほうがいいかなとは思います。

ただ…、過去にPHPで絡ませて頂いた仕事の半分くらいは痛い目に会っているんですよね。これは私が、スキルの低いPHP開発者とたまたま一緒に仕事をせざるを得なかっただけの話かもしれませんが…。しかしそのおかげで、PHPの勉強をサボろうという猛烈な熱意がmod_perl力をさらに向上させたとも言えるでしょう。もちろん、気持よく一緒に仕事をさせていただいたPHPプログラマの方も多くいらっしゃって、勉強させていただいたことも多くありました。その節は本当に助かったと同時に、良質なコードからPHPの勉強も自然とさせていただきました。

認証・許可処理は名前通り PerlAuthenHnadler・PerlAuthzHandler に書くべきでしたが、例示したコンセプト(スケルトン)ハンドラは PerlAccessHandler での設定でした。これには言い訳があって、Authen/Authzは癖があってApacheコアのRequireディレクティブなどと組み合わせないといけないのが面倒だっただけです。本来、PerlAccessHandlerはアクセス制御処理(IPアドレスでのアクセス制限等)を入れるフェーズですが、認証・許可処理を手軽にやるときはPerlAccessHandlerに書いてしまえというのは単なる私の怠け癖です。実際、アクセス制御処理を行う場合、単純なIPアドレス処理のようにヘッダを見ないのであれば、遥か前 PerlHeaderParserHandler のさらに以前である PerlPostReadRequestHandler でやってしまったほうが効率的なのです(多くの処理フェーズを省けるわけですから)。

Perlのスレッド(ithreads)をApacheのworker MPMと合わせて使うことでprefork MPMでは実現できない変数共有といったお話もしました。ただ、スライドでworker MPMはスレッドとプロセスのハイブリッドであると言っているのに変数共有できるのはなぜ?という疑問が湧いた方もいらっしゃったかと思います。これは完全に設定の説明を失念していて、worker MPMで生成されるプロセスを1つにするという設定が必要です(1プロセス・マルチスレッドの状態にする)。詳しい説明はここでは割愛しますが、ざっくりと StartServers、ServerLimit、PerlInterpStart、PerlInterpMax の各ディレクティブの設定値を 1 にしておけば良いはずです。スレッド設定については、MinSpareThreads、MaxSpareThreads、ThreadsPerChild の各種設定値を用途と環境によって適宜調整下さい。

ただ、トークでも何度も繰り返していましたが、現状Perlのスレッド(ithreads)は決して使用をすすめられるものではありません。諸事情あって私はこれを商用環境に投入することになりましたが、原則的に勧められることでは無いと思います。ただ、prefork MPM 以外、worker MPMがあまり陽の目を見ないことと、mod_perlの一つの可能性を知っていただきたかったので、今回トークのネタにしました。

他のmod_{lang}との比較をしようとは以前から考えていたのですが、検索すればあらゆるプログラム言語のmod_{lang}が出てくる状態はカオスでした。もちろん「コンセプトで実装してみました」で後は放置されて実用段階に無いものがほとんどなのですが、mod_ruby や mod_python についてはその名前から今も現役(現在のmod_perlと同等の実用性を持ち、保守がなされている)と誤解している方がまだいるのではないかと思ったので、念押しで解説させていただきました。

mod_ruby は、まだRails以前のRubyのエコシステムがそれほど整備されていなかった当時、Perlに追いつけと主にRegistryスクリプトに対応するものができるようにと mod_perl (mod_perl1) と対応したものを作ったものと私は理解しています。mod_ruby は Apache2 には少なくとも正式には対応されていないはずです。Rails以後は、Lighttpd + FastCGI が定石になって、その後 Rack 方面へと進んだと私は理解しています。

Apacheを拡張するものとしての mod_perl (mod_perl2) に対応するものは、現時点では mod_mruby でしょう。組み込み用途の mruby が今年2012年4月に登場してすぐに登場した mod_mruby ですが、現在も作者の @matsumotory さん (まつもとりょうすけさん) によって精力的に開発が進められています。「ApacheをC以外の他の言語で拡張する」という用途がmod_mrubyで見直され、それがmod_perlの「再発見」にもつながってほしいという期待を持っています。

ベンチマーク関係も不得意な私なのですが、今回は @matsumotory さんの結果を許可を得たうえでスライドに転載してご紹介させていただきました。mod_perlでの追加ベンチマークの補足情報もいただけて、本当に助かりました。会場にはRubyistの方もいらっしゃると思ったので「RubyでApacheやるならmod_mrubyもいいよ」とも伝えたかったのです。相当な機能と歴史を誇るmod_perlですが、現在進行形で開発されているmod_mrubyもmod_perlに追いつけ追い越せで開発されています。mod_perlの開発は今も現在進行形で行われていますが、mod_mrubyのような存在がmod_perl開発への良い刺激になれば良いなと願ってやみません。

20分で膨大なmod_perlのノウハウを語るには足りないと思ったので、アフターストーリーとして今後の展望を述べました。Twitter アカウント @mod_perl_info では時々mod_perlで困っている人をウォッチしてその解決策をご紹介したりしていますが、ウェブサイト modperl.info のほうは私がなかなか取り掛かれずに未完成となっています。作り途中でもいいので、今年中に何とか成果を小出しにでもしていきたいと考えています。ご声援、よろしくお願いします。

mod_perl関連の情報は他のmod_{lang}に比べて豊富ではあるのですが、日本語使用者にとって、やはり英語の情報が大多数なのがネックで、その辺りを解消していきたいと考えています。mod_perl関連のCPANモジュールの翻訳についてはmodperl.infoに閉じ込めずに、perldoc.jpへ積極的にコントリビュートしていきたいと考えてはいますが、まだ計画段階です。私の英語力の足りなさも目下の課題です。

あとどうでもいいことですが、古いネタ「キモーイガールズ」を入れたのは、いつか私が大舞台でこのネタをやってみたかっただけです。私がmod_perlをdisるはずもなく、いわば自虐ネタですね。トークの数時間前にホールで座っていた見知らぬ隣の人が、私が隣にいるとも知らず、私のトークについて「mod_perlの追いやられ感は半端ない」「mod_perlは風前の灯火」と評論してくださった事への皮肉です。もちろん現在それは実際の事であって、怒ったりはしてませんよ。入れる予定は無かったのですが、その事もあって勢いで数時間前にはてなセリフで作って入れちゃいました。はてなラボのサービス、便利!

会場での質問へのフォロー

トーク後の質問タイムで幾つか質問があったのですが、満足に答えられなかったかなという思いがあるので、ここで質問に対する少し詳細なフォローをさせていただきます

まず消費メモリやコストの問題

消費メモリに関しては、初期にかかる量は十分把握できるわけですが、その後mod_perl/Apacheが「太っていく」問題に関して、会場では Apache::SizeLimit / Apache2::SizeLimit を使った解決策を紹介しました。それは、規定以上のメモリを使用した子プロセスが MaxRequestPerlChild の指定に関わらず自発的に終了するという、言わば消極的な解決策ですが、「太っていく」事への対策はこのような対症療法しかないと思います(問題のプロセスを取り出して何らかの操作で「痩せさせる」事ができるでしょうか)。なぜ太っていくのかといえば、mod_perlの処理の中で大きなファイルなどメモリを大きく使用する処理の後で思惑通りの量のメモリを開放してくれなかったり、使っているPerlのバージョン自身に未知および既知のメモリリークのバグがあったり等、様々です。このような問題はスクリプトのコンパイル結果を都度捨てているPHP(mod_php)自身にも見られる問題であり、Apache固有の子プロセス終了関数apache_child_terminateも用意されているくらいです。

また上述のような対症療法以外に、初期にかかる消費メモリを抑える事もご紹介しました。Apacheの親プロセスの起動時に PerlModule ディレクティブで Encode や DBI 等のよく使用するモジュールをプリロードしておくことで、Apacheの親プロセスを子としてforkするときにCopy on Write(CoW)効果が働くことを利用して初期のメモリコストを抑えることができます。この周辺については、Perlの永続プロセスをマルチプロセスで生成するものであれば同様に考えられる問題と解決のようで、FastCGI等でも似たような感じのようです(この辺りは、例えば書籍「Mobageを支える技術」でも軽く触れられていました)。

初期メモリを抑えるためにCoWを利用することのトレードオフは、サーバの初期起動時間が長くなる事でしょうか。あと、あまり素性も分からないモジュールを親でロードしないほうが安定性の面で良いかなとは思います。

また、mod_perlのテスト環境についても質問をいただきました。

実はテスト駆動開発は私の完全に不慣れな分野でして、回答では「mod_perl自身には触れていないのに、なぜかmod_perlのテストについては『モダンPerl入門』にしこたま書いてある」なんて答えて少し笑いをいただきましたが、私の知識はそれくらいです。

テスト駆動開発全盛の昨今、この部分については皆さんも興味があるだろうと思ってスライドを用意はしたのですが、時間の都合で割愛させていただきました。サービススライドに押しやっているので、もし良かったらそちらをご覧いただけると幸いです。

会場では Apache2::FakeRequest を使った $r のフェイクオブジェクトを使うという方法をお答えしましたが、(私の不慣れのせいかもしれませんがこれは)手間はかかります。後は Apache::Test による方法などがありますが、あまり私が語れる部分は少ないのが恐縮です。この部分については今後も勉強していきたいと思います。

書籍「Practical mod_perl」にも、mod_perl1時代の情報でかつ洋書ですが、各種テストやデバッガを交えた開発手法が乗っています。こちらも興味深いので、もっと知りたい方におすすめです。「Practical mod_perl」はCreative Commonsライセンスで公開されているので、書籍が無くてもサイトから読むことが可能です。

ここまでの経緯

個人的なお話で恐縮ですが、このトークに至るまでの私の紆余曲折です。

2003年にプログラムも分からない自分を入れてくれた現在の会社。当時は学生時代に得たサーバ管理の知識で食いつなごうと思ったのですが、見事に素人知識を見透かされてかサーバは任せてもらえず、まずはテキスト処理・ログ処理からPerlを勉強することになりました。

2004年からPerlでのウェブ開発を任されるようになりましたが、当時は右も左も分からず、大変でした。mod_perlの事も言葉だけ聞くだけで、当時は「Perl CGIを速くするものだけどクセがあるから要注意」程度の理解をしていました。柱コンテンツはmod_perl1で動作していましたが、今振り返って見ると、当時はPerl CGIの高速化 (Apache::Registry) を目的とした使い方しかしていませんでした。

2005年から一人プログラマとして企画やデザイナの方々と小中規模のサイトを運営していくのですが、mod_perlの正体がつかめなかったので、私はPure CGI(Apache mod_cgi)でのPerlウェブ開発をしていました。ただ、この時からパフォーマンスを気にするようになって、柱コンテンツに使われているmod_perlを横から研究するようになりました。このころから隠れて(?)mod_perlを勉強するようになり、mod_perlはPerl CGIの高速化だけでなく、Apacheの拡張すらできるものだということを徐々に理解していきました。

これ以降の数年間は仕事の幅も広がり、後輩や一緒に働く外部の方も増え、自分がメインで担当する開発案件以外にも、PHPコンテンツの納品保守や、遊軍として他のPerlウェブ開発プロジェクトのサポートなども担当しました。その中で、それまで勉強してきたmod_perlの知識が色々なところで役に立ったのが印象的です。

数年前から、一緒に働く開発者の人数やプロジェクトの数が整理され、社内の柱コンテンツに戻ってきました。それまで得たmod_perlの見識を投入して、パフォーマンスチューニングや、mod_perlハンドラによる諸々の拡張や新規開発、mod_perl1からmod_perl2へのマイグレーション等、Registryスクリプト利用による高速化のみを目的に当初導入されたmod_perlの可能性を広げていっています。

せっかくこれだけ培ったmod_perlのノウハウを社内に閉じ込めておくのも良くないと考え、2011年からはHokkaido.pmでのトークをメインに、社外にもmod_perl情報をアウトプットしはじめました。今年2012年のYAPC::Asia Tokyo 2012での本トークは、それの集大成としたものです。

これからの計画

私はmod_perlも古くて新しい現役技術と考えてはいるのですが、残念ながら今の世の中的にニーズは少ないのが現状でしょう。私としても会社としても新しい技術を取り入れていく事が将来的なメリットであることは確かで、今後は Plack/PSGI ベースの WAF を積極的に勉強して取り入れていこうと考えています。今のところ、なんとなくMojolicious かなという気分です。少しずつ勉強中。

それでもせっかく得た mod_perl の知識をこのまま自分一人で抱えて枯らしてしまうのはもったいないと思い、今後はその知識を体系化してまとめて外に出していく作業をしていこうとしています。それがトークでも触れたアフターストーリーであり、Twitterアカウントやウェブサイトの開設の野望でもあります。

今回のYAPCのLTソンでもミートアップがありましたが、地域pmが盛んになってきたことは嬉しい限りです。もし地域pm等のPerlの集まりで「mod_perlについて聞きたい」という要望があれば、声をかけてくだされば時間やお金をやりくりしてぜひ訪問したいです(経費をいただいて呼ばれる身分ではありませんので、費用は自分でなんとかします)。

繰り返しになりますが、今回のYAPCでの「モダンmod_perl入門」は、私の数年間のmod_perl開発の集大成的な位置付けでトークしました。今後はmod_perl以外のジャンルにも視野を広げて、求められればmod_perlの事を語れる準備は怠らないものの、今後自発的に発表するものは、多くの皆さんの興味を引く別の話題ができればなと考えています。

今後とも、mod_perl を含めた Perl の世界で、皆さんのお役に立てるアウトプットをしていきたいと考えていますので、どうかよろしくお願いします。ここまでの長文、読んでいただきありがとうございました。

YAPC::Asia Tokyo 2012 に参加して、mod_perlネタで発表もしてきました #yapcasia

こんにちは、Perl大好き おがた (@xtetsuji) です。

簡単にまとめようと思ったのですが長文執筆癖が発動して、また熱く長く書いてしまいましたので、時間のない方は太字部分を中心に遠慮無く読み飛ばしてください

今年も行ってきました、プログラミング言語Perlの祭典「YAPC::Asia Tokyo 2012」(以下YAPC)。なんと今年は「モダンmod_perl入門」というタイトルでYAPC初トークまでさせていただきました。最初はこんな古風なネタで発表枠なんて頂けないと思っていましたが、結果的に発表枠を頂けて本当に感謝です。トークした雑感は後述。トーク内容の突っ込んだ詳細については、別のブログ記事として書こうと思います。

YAPCは2007年から毎年参加していますが、YAPCは年を重ねるごとに面白さが増しているイベントだなと感じます。それは自分が昨年からHokkaido.pmやHachioji.pmといった地域pmに参加し始めて知人が結構増えたことや、YAPCや大きなイベントへ参加慣れしたこともありますが、やはり牧さん(@lestrrat)、櫛井さん(@941)を始めとした、運営に携わる方々の努力の賜物だと思います。この場を借りて御礼を申し上げます。

勤務先でも昨年からYAPCの協賛スポンサーをさせていただくことになったのですが、櫛井さんには今年も遠路はるばる説明のために来社して頂いてありがたい限りです。前夜祭(もしかしたら懇親会かも)の時にも声をかけてくださって、その時にも色々お話をしたかったのですが、なにぶん忙しい方なので軽く話した程度。牧さんは「モダンPerl入門」という書籍を執筆された方で、今回勝手にこの名前をパクった「モダンmod_perl入門」なんてトークを応募した手前、前夜祭で真っ先に探してトーク採用のお礼と勝手にタイトルをパクったお詫び(?)をしました。運営等で忙しそうだったので、こちらも軽く挨拶をした程度でした。書籍「モダンPerl入門」には2009年の発売当初から本当にお世話になっているので、改訂版への淡い期待など、積もる想いで一杯です。

YAPCで初トークした

先ほども書きましたが今回、2007年から参加しているYAPC::Asiaで初めてトークしました。題名は「モダンmod_perl入門」。

2011年5月にスカイアーク勤務で Hokkaido.pm の主催である @onagatani さんと運命的な出会いをしたことがきっかけで、2011年7月に初めて踏み入れたHokkaido.pm#5(参加レポート)。初の地域pm参加と同時に、公での初の20分トークと、色々無茶をした第一歩でしたが、これがキッカケでこの後から勉強会への参加とトークを積極的に行っていくことが出来ました。2011年10月のYAPC::Asia Tokyo 2011」では Hokkaido.pm 組が多数YAPCの大舞台でトークしているのを見て「来年こそは」と心に秘めていた夢が、今年実現した格好です。

「やっぱりYAPCの大舞台だと緊張するかな」と思っていたのですが、1年半各所でトークの場数を踏んできただけあって、意外にもさほど緊張しませんでした。ただ、余裕を持って準備したスライドがいじってもいじっても20分枠に収まらないことで、当日までリハーサルをしたりスライドを削ったりサービススライド枠に押しやるセクションを選定したりといった作業が結構大変でした。とはいえ「ネタが出ない」に比べたら贅沢な悩みです。

「モダンmod_perl入門」の詳細については長くなりそうなので、後日別のブログ記事で書く予定です。

前夜祭

YAPCには2007年から行っているのですが、前夜祭に行ったのが昨年2011年が初めてで、それがとても面白かったので今年も行くことにしました。今年は上司と今年3月に入社した後輩も一緒です。

地下2階の一番広いホールに200人くらい集まったでしょうか。昨年同様トークは聴かず、久々に再会した元先輩や元後輩、Hokkaido.pmやHachioji.pmの方々とご挨拶をしたりしました。

YAPCクラスの大きな場所で初対面して深く知り合いに…;というのはなかなか難しいですが、どなたかのブログにも書いてあった通り、地域pmや他の中小規模の勉強会で会った人達やネット上で交友がある同士の「同窓会」としては非常に面白い場です。

噂通りの美味しい食事にお洒落な飲み物が揃っていて、昨年の前夜祭との違いにビックリしました。

1日目に聴講したトーク

聴講したトーク(敬称略)

15:35の枠は3本並行しているトーク全てが本当に聴講したくて、身体が3つに分裂すればいいのにとか混乱した挙句、午前中で疲れてしまったのと考えすぎて疲れてしまって、結局決められずLTthonを覗いたらとても笑わせてもらえて気分転換になりました。ちょうど、札幌 Hokkaido.pm からいらっしゃった @techno_neko さんが Hokkaido.pm Casual の宣伝と見せかけてスープカレーLTで大爆笑を取っていたとき。このトークは最終日に「初代ベストエルティニスト」に選ばれることになったLTでした。詳細はtechno_nekoさんのブログ記事が詳しいです。

聴講したトークの詳細は、上記リンクからスライドと動画を見ることができます。

遅刻してきたので、Perlの父Larry Wall氏のトークは途中からホールに入ったのですが、既に客席はいっぱい。後ろのほうの席からライブコーディング(もしくはコーディングの録画)を眺めていました。「あぁ、Perlの父も我々と同じようにシェルを使いエディタを使ってPerlを書くんだー」って親近感が湧いたり。Perl6の事は良く分かりませんでしたが、便利そうな構文が結構出てきたりして、「早くPerl6パブリックリリースしないかな」とか「Perl5.xxで構文導入してくれないかな」とか思って聴いていました。

ウェブ上での画像処理とかにも関わったりした経験から、pixivの裏側はどうなっているんだろうと興味を持って聴いていたのですが、mod_small_lightというApacheモジュールとは面白い。Apacheモジュールの積極活用事例は聴いていて興味深いです。nginxへの置き換えなんてことも触れられていて、ngx_small_lightを移植したとか、個人・会社ともに、そのパワフルさに脱帽です。

mixiの新入社員Masaaki Goshimaさんが新しいPerl5の実装系を作ったという話は当初から興味深くて聴講に行きました。まだ数値のみで文字列、特に正規表現周りの処理が未実装(に近い?)状態らしいので、今後の展開に期待。mod_gperlなんてApacheモジュールができたらいいですね。

りーお@DeNAさん(@riywo)のトークも聴講しました。日本人による英語のトークでしたが、いつか私も英語でトークしたい欲に駆られました。ヒアリングまわりで英語のトークについていくのが大変でしたが、スライドのデザインも群を抜いてカッコイイ。Hokkaido.pmでもお話をうかがっていたToryoの公開が待たれます。

Kenichi Ishigaki(@charsbar)さんのDBD::SQLiteのトークは、普段利用しているDBD::SQLiteにはこんなにも沢山の機能があって、こんなにも苦労があるのかといったことを知れた良いトークでした。Tim Bunce氏、Adam Kennedy氏といった神々も集結して石垣さんと英語で議論しているさまは、まさに遠巻きに「すごいなぁ」と思わされました。

その後、Tatsuro HisamoriさんのFreakOut!の裏側、Shunichiro Fujiwaraのベンチマークとプロファイリングといった話が続き、今年のYAPCはパフォーマンスをテーマにした年だなぁということを実感。FreakOut!での合言葉「古典的でも地道にやる」は響く言葉でした。またFujiswaraさんはISUCONでも優勝したほどのパフォーマンスまわりの著名な専門家。両者のトークを聴講してパフォーマンスへのさらなる意識を高めました。

その他、聴いていて印象深かったトークは全部。ハズレ無し。1日目も2日目もできれば全部のトークを聴きたいと思っていたくらいですから。個人的にはトークの並列数を減らして1週間くらいYAPCやりつづけてもいいんじゃないと思うくらい

1日目の懇親会

前夜祭の人数の比ではないくらいの人が集まって、食事も行列状態。すごかった。大群衆に揉まれるのが苦手な人間なので苦労はしましたが、前夜祭同様、いつも会わない方やTwitterやブログでのみ面識のある方との交流がメインでした。食事は早々になくなっちゃったし。

スカイアークの小林社長が会場入りして、乾杯の音頭を取ったのは印象的でした。やはり力強い方だなと。実はスカイアークの小林社長とは昨年の5月の初対面ぶりの再会。久々にお会いして道民トーク・十勝帯広トークで盛り上がりまくりました。楽しかった。その場の勢いで北海道つながりの飲み会を東京でやろうという話が実現してしまったくらい。

2007年からYAPCに参加していますが、今まで引っ込み思案で、Larry Wall氏が来日していても近寄れないでいたのですが、今年は大胆に行こうと、一緒に写真撮影をお願いして快諾していただけました。嬉しかった。

飲み物は潤沢にあったので飲みまくったし、疲れたし(もともと疲れやすい)、明日自分のトークあるしで、2次会等には参加せずに懇親会終了後はそのまま帰宅しました。

2日目に聴講したトーク

聴講したトーク(敬称略)

並行トークがなかった「Perl 今昔物語」は、豪華メンバーゆえ聴くべきか悩んだのですが、その時間にLTthonで「地域pm、勉強会、交流会 ミートアップ」をやっていて、悩んだ挙句「地域pm、勉強会、交流会 ミートアップ」のほうを聴きにいきました。自分が対外的な活動の起点となったのも地域pm(Hokkaido.pm)だったので、昨年くらいからアツい地域pmの現状を知っておきたいと思ったからです。結果的に北はHokkaido.pmから、南はOkinawa.pm(まだ開設準備中?)まで、各地域pm主催者が一堂に会してトークを交わす貴重な場となりました。LTthonの司会を務めていた@uzullaさんの引っ張り方も本当に上手い。会場は笑いが絶えませんでした。

2日目に @ytnobody さんと @typester さんの、CPANを主題とした話が連続でありました。聴いていると、「CPAN Authorになってみたいな」といった野望がふつふつと湧いてくるではありませんか。恩返ししたい!息をするようにモジュール書いてドキュメントで熱い想いをぶつけたい!両トーク、それぞれの側面で話が被っていなくて、両方聴講して熱意2倍。この熱が冷めないうちにPAUSE IDを取って、コンセプトで書いたmod_perlモジュールを成長させてどんどんコミットしていきたいと思ったのでした。

日本が誇る世界的ハッカー @miyagaawa さんのトークは、先日の LL Decade の基調講演で聴いた内容に近いものでした。「PythonやRubyから学ぶ事は多い」というのは、PSGIやPlackの誕生からも分かる通りです。LL Decade で miyagawa さんのトークを聴いた後、私も言語へのこだわりを減らして、他の言語から学べるものは学ぶという姿勢を持つようにしています。それは私のトークにも、mod_mrubyをmod_perlへ新たな刺激を与える良い存在と紹介したりといった部分に影響を与えています。

北海道が誇る高校生Perlハッカー @akiym さんは Skype API を使ったボット作成といった独自性のあるトークを披露。若いのに本当にすごい。この文章書いているオッサンがトークしはじめたのは30歳過ぎてからだよ…;。Hokkaido.pmでも毎回彼のトークは楽しみです。

正直自分の発表直前は、Room 2で給電しながら最後のスライド調整にまわろうとしていたのですが、ついついRoom 2 の話が面白いので聴き入ってしまいました。

Nozomi Mikamiさんのトークはタイトルが初心者枠で正直最初は期待していなかった(非常に失礼)のですが、中学生の頃からのプログラミングに対する強い熱意、そしてインターネットサービス企業(paperboy&co : ペパボ)にカスタマーサポート職で入った後にもその熱意が冷めず、業務外で社内の技術者に質問をしてPerl CGIで小さなブログサイトを完成させていくといった内容。どうしても男性中心になってしまう技術者界隈ですが、プログラミング初心者の女性が果敢に突き進むそのお話、その内に秘めた情熱に心打たれました。初心忘れるべからず。

Masahiro ChibaさんのTengのお話は、Tengのとても分かりやすい導入として参考になりました。といっても、この時間は私の発表の直前だったので、頭に入ってきた内容が少ないのですが、後でスライドを見返して良い資料だなと振り返り。会場にはTengの作者である @nekokak さんもいらっしゃって、発表者のChibaさんは緊張したかと思いますが、時々交わされる作者と発表者とのやりとりにライブ感を感じました。社内でも私に影響されて後輩が社内ツールでTengを使おうとしているので、そこでも良い資料になりそうです。

みんなLTがうまい

1日目のLT、2日目のLT、そして併設の会場でのLTthon。5分間の枠でどれだけ聴衆を楽しませるか。世間でもLTのノウハウがたまってきてはいますが、本当にみなさんLTがうまい。今回も @hiratara さんによる「Perlでおねえさんを救ったお話」や、女性による半ば下ネタかと思わせるような人生ネタ、スカイアークスポンサーセッションによる @onagatani さんコスプレ付きの北の国からネタ「帯広から、愛」等々、本当に笑わせていただきました。

聴講したトークと今年のYAPCのまとめ

今回は特に流行が無くて寂しいとか今後のPerlへの不安といったものも見聞きしたりしましたが、それだけPerl5やそのエコシステムが成熟してきた現れではないかと思います。それは他のLLも同様ではないでしょうか。@charsbar さんが、CPANコミット数がgemコミット数に抜かれつつあるといったLTをしましたが(カウント方法には異議もあるようですが)、今後の推移を見守りたいところです。仮にもPerlの先が暗いのであれば、今年のYAPCはこれだけ多数の協賛スポンサーも聴衆もスピーカーも集まる大規模カンファレンスにはならないでしょう。

逆に過去を振り返ると、Catalyst/DBIC/TT一色の年や、Moose一色の年などもありました。ただ私は各会場で「Moooooooooooooose!!」と叫んでいる光景を見て「ちょっと行き過ぎ、その流行を追っかけている人じゃないとついていけないよこれは…;」と若干辟易としていた側だったので、今年のような、ある種成熟してトーク内容も良い意味で様々なジャンルがあった今年のYAPCは、心の底から楽しめました。

今年の特徴としては、例年以上にPerlに関わらない話が多かったように思えます。特に、Tim Bunce氏の来日にあわせてか、プロファイラやチューニング等、パフォーマンスに関わる話が多かったように思えました。50ms or die! の FreakOut! さんが目立っていたのも印象的です。「平均レスポンスタイム50msをPerlで捌く中規模サービスの実装/運用」等でも繰り返された「古典的でも地道にやる」は今年のYAPCを代表する名言の一つではないでしょうか。結局、パフォーマンスを追求するとどのLLでも手法は同様になってくるわけで、そういう意味でも今年のYAPCはPerlを書いたことがない人にも楽しめるイベントだったと思います。当然ながら、運営の方々の多大な努力や、LTthonといった画期的なイベントの存在が、今年のYAPCを例年以上に盛り上げた事に異論は無いでしょう。

その後に勝手に極貧飲み会

80人規模で有志による後夜祭が予定されていたのですが「参加したとして、自分のトークが失敗して恥さらしの場になったらどうしよう」とか「1日目の懇親会が人だらけで、人混みに疲れたから2日目は遠慮しようかな」といった考えが働いて申し込みしませんでした。

そのかわり、@onagatani さんを中心とした Hokkaido.pm メンバーが #極貧飲み会 をやろうとしていたので、そちらに合流。最初は4人での飲み会でしたが、途中で @hiratara さんが合流してくれて、こじんまりと盛り上がれました。私の趣向でもありますが、数人規模での飲み会は個々人とゆっくりお話もできて、好きです。 #極貧飲み会 万歳!

これから

とりあえずPAUSE IDを取得してCPAN Authorへの道を一歩踏み出そうと思いました。

また、後輩とは「今年のYAPCで得られたことは何か?」といった話を何度かしていて、我々がこれからすべきことを再認識させられた次第です。

あと、今年のトークがそこそこ好評だったので、来年もトークしたくなりました。mod_perlネタはもういいとしても、今のところnginxのHttpPerlModuleやFastCGIなどmod_perlと似たレイヤーにいる他の興味深い事柄の最新事情を追いかけてそれを発表してみたいですね。来年のYAPCに向けて、勉強と実践、そしてトークの場数をさらに踏む活動の始まりになりそうです。

私と交流してくださったみなさん、トークを聴講しにきてくださったみなさん、楽しいトークを提供してくれたみなさん、そして運営のみなさん。みなさん本当にありがとうございました。来年もYAPCがありさえすれば絶対に参加します。繰り返しになりますが、本当にありがとうございました!

Hachioji.pm#20 に参加してきました #hachiojipm

こんにちは、東京在住なので東京の勉強会にも顔を出し始めた おがた (@xtetsuji) です。

今回、平日開催となった Hachioji.pm#20 に参加してきました。Hachioji.pm は今住んでいるところから比較的近い地方PMなので、頻繁に通ってPerl Mongerの皆さんと交流したいと思っていたのですが、特に春先から眠れないやら激しく腹を壊したりやらすこぶる病気がちだったもので、Hachioji.pm#15 以来の久々の参加となりました。

今回は平日開催ということもあって、参加者は9名と普段より少なめ(当初は定員と同じ10人)。

今回もHachioji.pm公式ページのレポートがアップされていますので、そちらをご覧になると雰囲気が分かると思います。

ちょうど帯広から東京に出張にきていた @masiuchi さんがいらっしゃっていて、Hokkaido.pm 以来の久々の再会が嬉しかったです。

会場は吉祥寺のevinoという名前通りのエビ料理の店。北海道生まれ北海道育ちにも関わらず、エビの皮むきが苦手で服に汁を飛ばしたりしたハプニングもありましたが、料理はどれも美味しいものばかりでした。エビのハンバーグが特に印象的でした。ビールもワインも美味しかった。ちょうど私が座った席の周辺が、自分を含めて北海道出身という状態で、@masiuchiさんと@ytnobodyさんの函館ディープトークやら、ここはHokkaido.pmかと錯覚するような光景も繰り広げられました。

自分も含め、今回の参加者の9人のうち約半数が、9月末の YAPC::Asia Tokyo 2012 のスピーカーだったこともあって「トーク採択おめでとうございます」「期待しています」といった会話が飛び交いました。

今回の Hachioji.pm がなぜ急遽平日開催になったかというと、YAPC::Asia Tokyo 2012 の会場の一角で LTthon (エルティーソン) という LT (Lightning Talk) のマラソンのようなものを行おうというイベントの予定を立てるためとのことでした。トークどころか5分間LTすらしたことのない人にも YAPC::Asia Tokyo 2012 という大舞台の一角で話す機会を与えたい、といった趣旨だったかな。「どんなことを話してもらうんですか?」と質問したら、「家で飼っているメダカの話とかでもいいよ」とのことでした。要するに公序良俗に反しなければ何でもありのLTのようです。気楽ですね。YAPC::Asia Tokyo 2012 に来る人で心当たりのある方に、ぜひともLTthonでのトークデビューを勧めてみたいと思いました。企画の骨格がさらに固まっていくことを待ち望んでいます。

Hachioji.pm恒例の「1枚LT」。今回もお酒を飲みながらパソコンを持ち出してPerlなどを熱く語るという光景が繰り広げられました。今回こそはと、私もLTスライドを準備して念願のHachioji.pm「1枚LT」デビュー。場の反応はそこそこだったこともあって安心しました。

他の「1枚LT」は、@uzullaさんによるLTthonの話、@ytnobodyさんによる新しいWAF「Nephia」を作ってみた話(詳しくは@ytnobodyさんのブログエントリをどうぞ)、合計で3LTでした。最近学習のためにMojoliciousの中身を見て、その巨大さと複雑さに「中身を見て理解するのは相当な根気と努力が要るわー」と挫折しかかっていたところだったので、生まれたての小さなWAFがどのように育っていくのか、「Nephia」をウォッチすることでWAFの成長というものも含めて勉強させてもらおうと思った次第です。

私の「1枚LT」である「すごいmod_perl」は、当初の発表資料に多少の修正を加えた上でSlideshareにアップしました。半分はネタトークです。当初はこんなに YAPC のトーク採択が早いとは思っていなかったので、ここで宣伝して「いいね!」してもらおうと思って準備していたものでしたが、期せずして YAPC で採択されたトーク「モダンmod_perl入門」の宣伝になって良かったです。「すごいmod_perl」はネタトークでしたが、本番の「モダンmod_perl入門」はどこまでネタや笑いどころを入れるかはまだ考えていません。20分はやはり語るに短い。それでも興味深い内容を話して皆さんに興味を持ってもらえるよう、入念に準備したいと考えています。

23時ごろお開き。中野区在住にとって、中央線で中野に近づいてくれるとより足を運びやすいので、今回の吉祥寺開催はとても行きやすかったです。平日開催でしたが、会社が杉並区だったので、荻窪まで行って少し西に行くだけで会社帰りでも簡単に行けました。今後も名前通り八王子での開催が中心となるでしょうが、たまにはもうちょっと中央線の東寄りで開催していただけるといいなぁと贅沢な事を思った夜でした。

Apache上のPerl FastCGIはCustomLogにデータを書くことができるか?ついでにmod_perlでのお話

こんにちは、Apache mod_perl が大好物の おがた (@xtetsuji) です。

そういえば、2012年に開催されるYAPC::Asia Tokyo 2012にトーク「モダンmod_perl入門」を応募しました。この記事が気に入りましたら、ぜひとも「イイね!」お願いします。

mod_perlに偏執的なのも良くないなと思って、最近はFastCGIやPSGI/Plack以降のWAFも勉強しています。Perlから外に出られていないのがまだまだといったところですが…;。

それでも好きが講じて、Twitterを使って日々mod_perlの情報を収集しているのですが、今日こんな会話を見つけました。

この会話、要約するに

  • ApacheのFastCGI(mod_fastcgi)を使ってPerlスクリプトを動作させている
  • PHPのapache_note()関数のようにApacheでデータをログに乗せたい → たぶん LogFormat ディレクティブで “%{Foobar}n” 書式を使って CustomLog ディレクティブに指定したログにデータを書きたい
  • mod_perlは使いたくない → 嫌わないで(´Д⊂ヽ

FastCGIの仕様書や、FastCGIを使ったプログラムを書いたり読んだりしたことはありますが、私はそれほどFastCGIの仕様はわかっていません。ただ、当初これはFastCGIでは無理ではないかと思いました。

  • FastCGIは永続環境であるもののCGIの思想を踏襲しているわけで、Apacheとは独立した仕様であり(Nginxやlighttpdでも動きますし)、Apache HTTPリクエストフェーズでの情報交換を目的としたApache独自の「Apacheノート」にアクセスすることは出来ないだろう
  • FastCGI、今回はApacheのmod_fastcgi自体がこの要望を叶えられないのであれば、各種CGIとなるプログラム言語のライブラリレベルで努力しても、少なくとも普通の実装では無理だろう

環境変数ならと考えてはみたものの、perldoc FCGI を読んでみても実際に試してみても、use FCGI; して得られた my $request = FCGI::Request(); を試行錯誤していじってみても、環境変数をApacheリクエスト処理の後続に位置しているログ処理フェーズに伝えることはできませんでした。…;というかそんなのは当たり前ですね。詳しく説明できない程度の知識しかないのがもどかしいですが、FastCGIはApache本体とは独立したコンテナのようなデーモン(サーバ)を作るわけですから。気の利いたソケット(詳しくないけど言ってみたかっただけ)で両者が繋がっていれば話は変わってくるかもしれませんが、最初から勝算はありませんでしたし、うまくもいきませんでした。

perldoc FCGI をさらに読んでも、環境変数はまだしも、Apacheノートに関する記述は完全にありませんでした。敗北が見えはじめました。

基本に戻ってLogFormatのカスタムログ書式を復習してみました。ApacheのサイトにあるLogFormatのカスタムログ書式のマニュアルを読んでみると、任意データを受け取れそうな “%{Foobar}?” といった書式はこれだけありました。

  • %{Foobar}i:入力ヘッダ “Foobar” の内容
  • %{Foobar}n:Apacheノート “Foobar” の内容 (公式サイト上では「メモ」と書いていますが、この記事では「Apacheノート」で統一します)
  • %{Foobar}o:出力ヘッダ “Foobar” の内容

入力ヘッダはいじりようがない(FastCGIが動作するリクエストフェーズのずっと前の、Apacheのヘッダ解釈フェーズで既に処理されている)ので除外。Apacheノートも、上記考察から除外。

最後に残ったのは出力ヘッダ。「あ、出力ヘッダはFastCGIからApacheを通るし、もしかしたらいけるんじゃね?」と思って試してみました。

custom-output-header.fcgi

#!/usr/bin/perl
# ogata 2012/08/03

use strict;
use warnings;

use FCGI;

my $request = FCGI::Request();

while ( $request->Accept() >= 0 ) {
    print "Content-type: text/plainrn";
    print "X-Tetsuji: Hello! World.rn";
    print "rn";
    print "It is fine.rn";
}

LogFormatの設定

LogFormat "%h %l %u %t "%r" %>s %O "%{Referer}i" "%{User-Agent}i" "%{X-Tetsuji}o"" combined_xtetsuji

手元のApache2+mod_fastcgiにVirtualHostを作って、この combined_xtetsuji を CustomLog で使うようにして、custom-output-header.fcgi を叩いてみました。

以下がそのアクセスログ(IPアドレスは何となく伏せました)

xxx.xxx.xxx.xxx - - [03/Aug/2012:00:08:28 +0900] "GET /custom-output-header.fcgi HTTP/1.0" 200 245 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_4) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/21.0.1180.57 Safari/537.1" "Hello! World."

お、最後に “Hello! World.” 出てる!

結果的に、出力ヘッダ “%{Foobar}o” を LogConfig ディレクティブに使えば、記録したいデータを出力ヘッダに含めることで、FastCGI でも Apache CustomLog ディレクティブに指定したログにデータが記録できることがわかりました。

…;が、この方法は、わざわざヘッダを見るユーザには記録したいデータが丸見えという明らかな欠点がありますね。これはちょっと…;

Apache FastCGIを使う限り、会話に登場した方が本当に満足する方法があるのか。もしくは上記で良いのか、ちょっとわかりません。私にはこれが限界でした。

あと一つ!mod_perlはPerl CGIの高速化環境として見ても、それほど悪いものではないですよ。FastCGIもmod_perlも永続環境という意味では同じような魅力と問題を合わせ持っていると思います。インフラエンジニアの専門家の方には「Apache自体はスリムであれ」等、鋭いご指摘等があるかもしれませんが。そういったご意見もぜひご教示いただきたいです。

ちなみに、Perl CGIの高速化環境 (PerlHandler Apache::Registry (mod_perl1) / PerlResponseHandler ModPerl::RegistryPrefork (mod_perl2)) のmod_perlでAapcheノートにデータを読み書きする方法は、ざっくり以下です。

  • use CGI; # CGI.pm は Perl CGIの高速化環境下のmod_perl{1,2}をサポートしている
  • my $cgi = CGI->new(); # 普通にインスタンス作成
  • $cgi->r というメソッドが用意されていて、これでmod_perlリクエストオブジェクト(Apache::Request (mod_perl1) / Apache2::RequestRec (mod_perl2)) を取得することができる
  • $cgi->r->notes->get(“BuzzMemo”); # Apacheノート “BuzzMemo” の値を取得
  • $cgi->r->notes->set(“BuzzMemo” => “This is fine”); #  Apacheノート “BuzzMemo” の値を設定

実際にmod_perlハンドラを生で書く場合には幾つかの注意点があったりしますが、今回は割愛(需要あるかな?)。CGI.pmではその部分をなんとなく吸収してくれています。ただひとつ注意点は、CGI.pmのドキュメント perldoc CGI では r というメソッドには一切触れていない、つまり非公開メソッドであること。とても歴史の古いモジュールですので、突然次の日に使えなくなる可能性は限りなく低いとは思いますが、使う場合はその点ご留意ください。

そんな部分も含め、mod_perlの興味深い世界に興味を持っていただいた方は、しつこいですがトーク「モダンmod_perl入門」にぜひ「イイね!」よろしくお願いします!YAPC::Asia Tokyo 2012 会場でのトークや(トーク動画とともに後日公開もされる)資料で、もっと興味深い世界をご紹介します。

Hokkaido.pm#7 に行ってきました

こんにちは、遅筆癖を直したい おがた (@xtetsuji) です。

2012年5月13日に行われた Hokkaido.pm#7 に行ってきました。

…;と、このブログを投稿している7月末になって「何をゴールデンウィーク明2ヶ月前の話をしているんだ!」とお叱りを受けるかもしれません。ごめんなさい。遅筆な上に、ついつい文章を書き始めると長文になってしまって時間がかかるので、書き始めるまでの心理的障壁が大きいんです。

あとブログ記事が遅れた要因として

  • 会社が「おまえよく発表後に体調崩すから発表しちゃダメ」と言われたのに飛び入りLTした事を会社に律儀に報告して許しを乞う(5月中旬)
  • 発表に使ったMyApache2::Sinatraticに大バグ発見。Apache上の複数のVirtualHostで使っただけで崩壊なのには自分ながらガッカリした。修正開始。(5月下旬)
  • 体調を崩す。元々弱い腹に胃腸炎が襲来。(6月上旬から中旬)
  • 胃腸炎の後遺症で戻りかけていた睡眠リズムが崩壊して体調が中々戻らない(6月下旬)
  • MyApache2::Sinatraticさらに修正(7月上旬)
  • 忙しかったり体調不良が続いたり(7月中旬)

といった事情もあります。言い訳。MyApache2::Sinatraticはなんとか「動くように見える」レベルまで修正しました。後述。

今回は簡潔に行きます!要約大切!(いまのところの意気込み) → …;と思って書き始めましたが、結構な長文になってしまいました…;とばし読み流し読み大歓迎!もしくは「あとで読む」に放りこんで、時間のあるときにどうぞ!

Hokkaido.pmは #5 から連続3回目の参加です。今回も東京から札幌へ遠征をしました。

このブログの過去記事より過去のHokkaido.pm。

今回は公式サイトの開催報告が良くまとまっていて見やすいです。動画もスライドも開催概要もここからたどることができます。私もトゥギャッターで協力しました。今回のテーマは「Webアプリ「再」入門」。特にWAF(Web Application Framework)の話が多くをしめました。

今回も各トークの私なりの感想を簡潔に書いてみたいと思います。

「ゼロからはじめるAmon2」@akiymさん

Hokkaido.pmの高校生Perlハッカー@akiymさん。「WAF初心者」とのこと。

「WAFとは?」という問いかけから、Amon2の基本的な使い方を紹介。

「Perl WAF といえば Catalyst?」という時代もあったけど、「なるべく学ぶことは少なくしたい。再入門に時間なんてかけてられない」。確かにそうです。

Perlにおける軽量WAFとして、「Amon2」「Dancer」を例示。Amon2がjQueryやTwitter Bootstrapを同梱していたり、Text::Xslateを標準テンプレートに採用しているといったメリットを提示。

スケルトン生成からデモへ。

flavorとしてBasic(デフォルト)とLarge、Liteがある。Amon2::Lite # Mojolicious::Liteっぽい。

コード例から、コンテキストオブジェクト $c からの基本を解説してくださいました。RequestやResponseはPlackからのシンプルな継承。設定ファイル config/{development,deployment,test}.pl を紹介して、これを PLAC_ENV で切り替えられるというお話。

% plackup -E deployment app.psgi

dispatcherはRouter::Simple。

詳細はスライドを見ていただければよくわかりますが、基本的なスケルトンコードを例示。いわゆるSinatraライクですね。

プラグインも紹介。

  • Web::CSRFDeefender → CSRF対策(トークンを埋め込む)
  • Web::FillInFormLite → $c->fillin_form(); # HTML::FillInForm::Lite
  • Web::JSON → $c->render_json();
  • Amon2::Auth → Twitter, Github, Facebook, Loctouch をサポート
  • Amon2::DBI → $c->dbi

実際にウェブアプリを作ってみるというデモもありました。

まずは「オレオレGyazo」を 「% amon2-setup.pl Gyazo」 として生成。FillIn や CSRF は要らないので削除、dispatcher にべた書き(このあたりはスライドが詳しいです) → 短縮URLの実装もやる → SQLite

ネタ的なおまけとして「KENT WEB」をAmon2で書きなおそう!なんてのもあって会場は爆笑。

  • Amon2::DBI
  • Teng
  • Form::Validator::Lite

素材はこれら。「KENT WEB」が最先端の技術で蘇りました。スゴイ。

まとめ:

  • Amon2は非常にシンプルなWAFで、使い勝手がいいのでおすすめ。
  • WAFは好み e.g. Catalyst, Mojolicious
  • Amon2はコードも読みやすいし複雑なことをしていないのでオススメ

簡単なWAFと呼ばれたAmon2のことが概観できて楽しかったです。

「DancerでWebアプリ再入門」 @aloelightさん

こちらもHokkaido.pmの顔ともいえる@aloelightさんのお話。札幌の会社でPerlの開発やインフラまわりをお仕事にされている方です。

今回のHokkaido.pm#7のテーマ「Webアプリ「再」入門」ということでDancerを使ってみた話。

先行の発表者が宣言したWAFを除いて、残ったものがCatalyst、CGI::Application、Kossy あたり…; その中で一番簡単そうで世界で知名度が高かったのが Dancer だったとのこと。

早速ウェブアプリを作ってみたとのことです。文字通りの機能を持つ「AWS Health Info」

  • Twitterアカウントでログイン
  • AWS Service Health をチェック
  • 登録者にお知らせ

次の一声「間に合いませんでした!」惜しい!業務でAWS触り始めた私も「AWS Health Info」に興味津々だったのに…;。

次にDancer の紹介と特色を紹介。特徴としては以下のようです。

  • Sinatra系のPerl整WAF # 最初から
  • すっごくシンプル
  • 豊富なプラグイン
  • 意外と豊富なドキュメント

インストールは簡単「$ cpanm Dancer」。依存 CPAN モジュールも少ないのだそうです。

Sinatraライクな文法なのは前述で触れられましたが、まさかサブルーチンリファレンスで文字列を返却するだけでレスポンスが書けるとは…; → use Dancer; get ‘/’ => sub { return “Hello, world”; }; dance; # これだけのスクリプトで 5000 番ポートで待ち受けるdaemonの完成。

もう少し複雑なアプリケーションの場合は「$ dancer -a MyApp」とするとスケルトン雛形が作成されるのでMyApp/lib/MyApp.pm にアプリを書くとよいそう。シンプル。基本は use Dancer; するだけ。

豊富なプラグインもあります。現時点で Dancer::Plugin 系が 94件。

メジャーなPluginのご紹介。

  • Dancer::Plugin::Database
  • Dancer::Plugin::DBIC
  • Dancer::Plugin::Email
  • Dancer::Plugin::Thubnail
  • Dancer::Plugin::Facebook

もっと知りたい方は「Dancer plugins ecosystem」http://advent.perldancer.org/2011/17 へGo!、だそうです。

Pluginの作り方も簡単とのこと。

ドキュメントも豊富。

  • Dancer::Introduction
  • Dancer::Tutorial
  • Dancer::Cookbook
  • Dancer::Plugins
  • Dancer::Deployment

Dancerの基本文法をご紹介。ここらへんは上述のように簡単。詳しくはスライドや動画を御参照いただけると良いと思います。Config、Cookie、Session、Templateにもそれぞれ独特のDSL構文(所定のオブジェクトを返す0以上の引数サブルーチン)があって、簡潔さを目指しているなぁというところが伝わりました。

ちなみに標準のテンプレート Dancer::Template::Simple には IF,LOOPが無いので Dancer::Template::TemplateToolkit を代わりに使いましょう、とのことでした。

データベースもやっぱりシンプル。use Dancer::Plugin::Database; をすると database というDSL構文が使えるようになってシンプル。前述の Config 等についても、use Dancer::Config をすると config 構文が使えて同様、等々。

これも前述のようなDSL構文が徹底されたリダイレクトやロギングといった部分を解説し終えた後、AWS Health Info のソースコードを読みながら、その雰囲気を味わいました。

やはり前述のような構文が多様されているため「MojoliciousやAmon2と違って $ が少ない」のが特長とのこと。

Twitter連携についてアドバイス。

  • Net::Twitter は Moose 依存
  • Net::Twitter::Lite はそうじゃないのでそっちを使おう

テストには Dancer::Test というのが用意されているので、それを調べて使いましょう、とのことでした。

感想としては、インポートされるDSL構文(詳細を説明すればオブジェクトを返すサブルーチン型のシンボルようなもの)が多くなるものの、メモリ等のコストとしては大したこと無いでしょう。こういうコンセプトのWAFも興味深い。ただ、日本での使用者人口がまだそれほど居なさそうで、何か困ったときの拠り所や頼れる人が不足しているのではないかという一点のみが懸念点でした。それ以外については、これほどシンプルさを目指したことに感心しきりでした。

「Mojoliciousをウェブ制作現場で使ってみてる」@jamadamさん

前回の Hokkaido.pm#6 の二次会で「初対面」して熱いトークをしたのが @jamadam さんでした。その時は全然知らなかったのですが、氏は Mojolicious のヘビーユーザ。英語のMojolicious ML へのコミットや、GitHub に自作の Mojolicious アプリケーションを精力的にアップしている方でした。私も @jamadam さん作だと知らずに使っていた Mojolicious アプリケーションもあって驚いたくらいです。北海道、Hokkaido.pmは、知れば知るほど猛者の集まりです。北海道出身の私は当然北海道ひいきですが、東京の人は地方を見くびっちゃいけない!

Mojolicious は現在の Perl WAF の中でも情報がいっぱいあります。

  • Mojoliciousアプリを簡素に記述できるMojolicious::Lite
  • MojoliciousというWAF
  • Mojoというモジュール群

このあたりの話をまずざっくりと解説されました。モジュール群の継承関連図の美しさ(本人作)には会場も息を飲みました。

最小のMojoliciiousアプリの例示「use Mojolicious::Lite; app->start;」

話はMojoliciousのモジュールMojoの構造の話へ。このあたりは内部設計まで踏み込んで解説されました。そしてMojoやMojolicious関連クラス群の親クラスMojo::Baseの使い方へ。

Mojoliciousはバージョン2.0からPerl5.8サポートが切られ、Perl5.10以上を必要とするようになってしまい、困ったのでmojo-legacyを作ったとのこと。レガシーな環境へのデプロイの仕事を多く持つ @jamadam さんならではの作品ですが、その原動力には感心するばかりです。ただし、本家Mojoliciousのいくつかのテストが失敗するのが困っているとのこと。それでもmojo-legacyは実践投入されているようです。mojo-legacy の話は紹介で終わり。

本題は「ウェブ制作の現場ではデザイナー主導で組みあがったサイトに動的コンテンツを後付けすることが多い。」「それってPHPが最適解」「でもPerlでやる」という一連の流れ。やっぱりPerl!

実践コードをいくつかご紹介されました。紹介された処理をプラグインにまとめたりもしたそうです。詳細はスライドや動画を御参照ください。

感想としては、WAF素人の私としては、今使うなら日本でも使用者人口が増えてきた Mojolicious かなぁ…;と考えていたので、非常に参考になるトークでした。@jamadam さんが内部設計に詳しくそこにフォーカスをあてたトークだったため、前2つのAmon2やDancerのトークよりも難解さを感じはしましたが、まずは Mojolicious::Lite からコツコツとためしてみようと思います。

「Ops Tools with Perl」@riywoさん

東京から招待されたDeNAの @riywo さんによる Ops (運用) 関連のトークです。

Ops に役立つ Perl 製ツールの紹介をしてくださいました。

まずは有名な @kazeburo さんによる作品 CloudForecast。中身のウェブインターフェースはWAFなのですが、Kossyの元祖であるShirahata.pmというものを使っているのだそうです。Shirahata.pm、名前すら聞いたことありませんでした。

次は GrowthForecast の紹介。こちらのウェブインターフェースは WAF Kossy とのこと。

話はウェブから離れつつ、「はかどる系」のお話へ。

Alien::RRDtool の紹介。名前の通り RRD のモジュール。

chase-tail というツールの紹介。@hirose31 さん作。tail をしながら、指定したものがあればお知らせしてくれる系(だったかな)。これはシンプルなツールゆえ、すぐに活用ができそうです。以下のようなコマンドラインですぐに使えるそうです。

$ tail -f error_log | chase-tail -l 10 -t various_error

そして App::Ikachan のお話。@yappo さん作。これは私も使っています。簡単なHTTPでしゃべらせることができるIRCボット。障害が起こった時等、curl 等のよくあるHTTPクライアントツールで ikachan を叩けば、ikachan が IRC 上ですぐに教えてくれるといった使い方。

@riywo さんは「Touryo」というツールを作っているそうです。コンフィグ管理ツール。ただ、まだソースコードを出すことができないそう。会社でコンフィグ管理の必要性が発生した際に、ChefやPappetでは収まらない要求があったために自作したとのこと。基本はCLIツールだが、ウェブ管理画面もあって、それはAmon2中心に作っているのだそうです。

コンフィグはサーバごとに微妙に違ってくるケースがあって、それが既存ツールでうまくできない部分なのだそう。Touryo、公開が待たれますね!

内部的にはサーバにSSHしているけど、Net::SSH は ~/.ssh/config を読まないので使わなかったとのこと。そういう制限があるんですね。IPC::Cmd で ssh を呼び出すというスタイルを取っているそうです。これなら ~/.ssh/config も反映される。

最後に「どんな言語を使えば良いか?」という問いかけ。色々なスタイルの言語がある。スクリプト型、コンパイル型といった分類。手続き型、オブジェクト指向、関数型言語といった分類。普及しているか否かといった分類。

やはり選ぶとしたら普及している言語を選ぶべきという話。ライブラリが充実していることと、みんなが読めることがその理由

そしてTouryo等でPerlを採用したのは「I love Perl」だから。早く書けるし、なにより自分の周りにPerl Mongerがたくさんいたこと、そしてCPANの存在。

感想としては、私の会社ではインフラや運用はプログラマや開発とは部署が完全に分かれていて、インフラや運用で専用ツールを作るといった発想が無かったです。インフラ部署に行くとプログラムからは離れてしまって寂しいのではという印象すら持っていた。もちろん、既存ツールを使うという選択肢はインフラ部署で取られてはいますが(Nagiosとか)。私も元々インフラ志望だったこともあり、プログラムで「はかどる系」を促進していく、@riywo さんのようなインフラ運用を担うプログラマに憧れを抱きました。

LT

ここはメモが欠落しているのですが、記憶では1枠のLTがあったのみで今回は枠が2つ余っていました。冒頭で書いた通り、会社から「発表すんな」と言われていたのですが、こっそり秘蔵ものを持っていたので、空いているLT枠の話を聞いた時に休憩時間の10分間で簡単なスライドを作って「飛び入りLT」をやってのけました

このLTには動画がありません。会社にバレたときに怒られる可能性があったので、Ustreamを切ってもらったのでした。その後、会社から「それくらいいいんじゃない」と言われたので安堵しましたが…;。また、当初のスライドは10分で作った15枚くらいのスライドで、実際は後半3分ほどは拡大したEmacsにコードを移してカーソルを動かしながら解説したのでした。

私は mod_perl Hacker (Baka) として Hokkaido.pm で前2回トークをしているので「今回もmod_perlで無茶しやがって…;」といった笑いを頂くことができて嬉しかったです。テーマに従って、素の mod_perl を WAF っぽくするという無茶ネタ。興味ある方はぜひスライドをご覧ください。

その後

それでも余ったLT枠の時間で @onagatani さんが Hokkaido.pm についてのお話をされて、さらにそれでも余った時間のため、いつも押し押しになるにも関わらず時間を余しての終了。

懇親会までの時間も必然的に余るわけで「もう懇親会の会場に行っちゃおうか」という声が自然と沸き起こり、普段は19時あたり開始の懇親会をが17時45分に始まることになりました。

懇親会

居酒屋の座敷部屋での懇親会でした。東京からいらっしゃった@riywoさんのために、北海道の海の幸が存分に振舞われました。「カニの刺身が食べられるのはHokkaido.pmだけ」。美味しいものが食べたい方はぜひHokkaido.pmへ行きましょう!トークの質も(私は置いといて)みんな濃い!今最も熱い地方.pmのひとつと断言して良いのではないでしょうか。

二次会

バーのようなところに入ったのですが、すし詰め部屋に押し込まれてトイレに行くだけで大混乱、しかも外野が騒々しい(ダーツやってた?)という中々の環境でしたが、懇親会で入ったアルコールで皆さん打ち解けて話ができました。

三次会

三次会恒例のラーメン。@onagatani さん自信のコースです。東京からいらっしゃった方々も札幌ラーメンに舌鼓を打っていました。

そして、開始が早かったことで、Hokkaido.pm にしては異例の23時解散となりました。結果的に開始が早かったことで解散も早く、身体への負担も減った感じです。次回も懇親会は17時45分開始くらいにしても良いのではないでしょうか。

まとめ

結局長文になってしまいましたね…;。ここまで熟読してくれた方、飛ばしながらも読んでくださった方、ありがとうございます

当日リアルタイムにEvernoteにメモを取っていたので、トークの概要の大方はコピペ修正で編集しています。それでも執筆時間は2時間ほど。遅筆…;(なのかな)。でもせっかくの熱いHokkaido.pmの活動、なるべく活字として残しておきたいという思いをどうか汲みとってやってください。

Hokkaido.pm#5 で初pm参加 + 初トークをしてPerl仲間が劇的に増えました(YAPC::Asia Tokyo は2007年から参加しているけどいつもぼっちでした)。東京在住ですが北海道出身の私にとって、Hokkaido.pmは文字通り私の故郷でありパワースポットであり、意欲や情熱などの大切なものを色々頂いている本当に素晴らしい場所です。主催の @onagatani さん、@aloelight さん、その他常連の皆さん、本当にいつもありがとうございます。次回も都合をつけて絶対に参加します!今から本当に楽しみです。

Perl Beginners#2 に参加してきました #perlbeginners

こんにちは、Perlビギナーの おがた (@xtetsuji) です。

2012年4月27日に、東京の文京シビックホールでPerl初心者向けのイベント「Perl Beginners #2」が行われ、参加してきました。

当日の実況等はTwitterでも #perlbeginners ハッシュタグで流されていて、私がそれを以下にトゥギャりました。Twitterに流されていない感想ブログについても、見つけたものは末尾に載せました。当日の雰囲気を把握する上では、こちらをザッと読んでみると良いかと思います。

以下は、私から見た Perl Beginners #2 です。

あまり皆さんとは関係ない事なのですが、2012年3月1日に当社の開発部署にも新人さんが入社。ようやく、開発部署が1〜2人というごく僅かな事態が改善されつつあります。ただ、新人さんは実は前職がIT業界ではないこともあって「ここにいる1〜2人の人間が開発者の象徴だと思われると困るな、もっと広い世界のたくさんの開発者像を知ってほしいな」という思いがあり、ビギナー向けと呼ばれるこのイベントに参加してみることにしました。強制参加にはしたくなかったので、最初は都合が良くて気が向けば…という感じで誘ってみたところ、好意的に参加してくれることになったのでとても良かったです。意欲が高いその姿勢は素晴らしい。その後、会社からも公式に勉強してきてね(交通費が出て勉強会の時間中は出勤扱いになる)ということになって、最近は会社の理解もあるなぁ、と色々ありがたく思ったのでした。

私もPerl歴というかPerlを本気で書き始めてから9年ほど経過しましたが、偏った知識ばかりが蓄積して一般的な知識という意味での成長が見られないので、このイベントでいろいろ勉強させてもらえればという気持ちで参加しました。

初参加のイベントだったので、緊張しつつも会場入り。

既に主催者である @ytnobody さんによって会場設営が完了していました。

PerlBeginners#2 会場の様子

JPAさんの補助により、会場代はタダ、すなわち参加費もタダ!JPA++。また、JPAからのゲストに @zigorou さんがいらっしゃっていました。

主催者の @ytnobody さんに「写真撮ってね!ブログでレポート書いてね!雰囲気伝えてね!」と発破をかけられていたのですが、あまりたくさんの写真を撮ることができませんでした。場慣れしていない初参加イベントだと、どうも動きが鈍る…。

以下、当日のタイムテーブルが書かれたホワイトボードです。

PerlBeginners#2 当日のタイムテーブル

ビギナーズセッション

この「ビギナーズセッション」というのは、発表者が自分が今取り組んでいることを発表しつつ、聴衆に向けて「もっと良いやり方がありますか?」と問いかけるというもの。主催者とゲストの知識人が答えてくれるという面白い試みです。

まずは @c_tyo さんによる質問。ajax.cgiというPerl CGIをjQueryの$.ajax()で叩いてFacebookのような(画面遷移の少ない)ページを作っているが、もっとよい方法があるか、というもの。

知識人からの回答としては、やはりCGIよりもPSGI/PlackベースのWAFを使ったほうがいいのではないか、JSONの扱いならJSON.pmでやったほうがいいのではないか、という回答でした。

次は @i4djunichi さんによる質問。開発環境で作ったものをどのように本番環境にデプロイすればよいか、という話だったと思います。ただ、開発環境と本番環境でOS環境やCPANモジュールのバージョンが違うと…という話から、話題はバージョンを保持するといった話へ。

知識人からの回答としては、DarkPANやOrePANの話が出てきました。私もOrePANは知っていましたが、DarkPANのことは良くわかっていなかったのですが「DarkPANの実装の一つがOrePAN」ということでいいのかな。DarkPAN⊃OrePANという包含関係。

local::libというキーワードも出てきましたが、cpanmの登場によりそういうこともあまり気にしなくなりましたよね。ちなみに私が勤める会社では主にDebianを商用環境に採用していて、自社開発モジュールに関しては、適当な場所にバージョン管理システムから落としてくる、または rsync で転送したモジュールのトップディレクトリを、perl -le ‘print for @INC;’ して出てきた include-path のうちのどこか、大抵は /usr/local/lib/site_perl/ 以下に symlink を作るという方法で解決しています。コアのPerlやCPANモジュールについては、基本的にDebianパッケージになっているものしか使えず、そうでないものはインフラ部署にお願いしてDebianパッケージを作ってもらう流れなので、local::lib や lib などといったプラグマのお世話になることは皆無ですね。ちなみに、商用環境でのcpanmの使用は現状は事実上できない状況です。このあたりは開発部署主導というよりもインフラ部署主導なので私には意見を出せる部分ではなくて…。このあたりは、世間の会社とはちょっと違うところかも。

そしてちょっと早い休憩。

LT

@ytnobody さんによるLT。「PSGIへの誘い」というようなお題で、無名サブルーチンと配列リファレンスがあるだけの、非常に簡単なPSGIアプリを書いて、PSGIが簡単でこれからウェブアプリケーションを書く人にPSGIがオススメであることを分かりやすく解説していました。ちょっとしたハプニング(?)からか「ライブコーディング」が見られたのは、結果的に面白かったと思います。

「PSGIは難しくない」というメッセージ。ただ環境には、トークの中で触れられていた「SSH等でシェルを実行出来る環境であること」「プロセスを常駐させても怒られないこと」「必須じゃないけどperlbrew+cpanmが使えること」の3条件を満たす必要があるのは要注意。そのために、VPS等の環境をご紹介されていました。自宅サーバは色々敷居が高いにしても、「さくらのVPS」の最小構成であれば月額980円でこれが手に入りますし、ちょっと癖があるにしてもdotCloudを使えるようになるとある程度の範囲までは無料で作れるようになるので、良い時代になったなと思います。むしろdotCloudはPerl CGIのデプロイは無理で、PSGI/Plackアプリしかデプロイできなかったんじゃなかったな(この前見たけど調査サボり)。

「Twitterでハッシュタグ #perl を付けて「教えてください」っていうと意外に偉い人が教えてくれる。」という心強い話も。あんまり教えて君になるとdisられそうなので、困ったときの奥の手として使いたいところです。

このプレゼンテーション資料は @ytnobody さんによるページにて公開されています。PSGI/Plackが良く分からっていない人(自分含む)にとってとても参考になる導入資料ですので、一度目を通してみるとよいと思います。

私の会社では、以前は半分くらいCatalystを模倣した自社WAFがあったことがありましたが、現在は世間で言われているようなWAFといったものでの開発がなされていない状況です。ただ、PSGI/Plackの基盤がだいぶ固まった今だからこそ、今後新規で立ち上げるプロジェクトでは、何らかのWAF(Mojoliciousあたりを検討中)でPSGI/Plackの恩恵にあずかりたいと考えています。

次は @pohtarou さんによるLT。WAF(Webアプリケーションフレームワーク)「Kossy」によるWebアプリケーション作成のトークでした。Kossyは@kazeburoさん作のWAFでSinatra(RubyのWAF)風、簡単にWebアプリケーションを作ることができるというものです。

トークの中で「ストーカー力」という言葉が出てきたのが興味深かったです。「とりあえず書く」「ネット上をくまなく探す」そしてその作者に質問をぶつけるという意味だったかな。

とにかく疑問・質問・賛辞は作者にどんどんぶつける。多くは返答が返ってこないかもしれないけど、その中からバグが発見できたり自分の疑問が解決できたり、作者が喜んだり、色々良い事があるのかなと改めて思わされたトークでした。

質問タイムに「Kossyで作った商用サービスはありますか?」という質問をしてみました。まだ、社内サービスでの投入の段階とのことでした。

次は @irmr_log さんによるLT。「Perl歴2年ちょいで、LTもパワポも初めて」だそうです。その割には場慣れしている感じでした。

トークの内容は、HTTPヘッダ、W3C、MIMEタイプなどを解説した後、Webスクレイピングをするという話に到達。LWP::UserAgentが基盤としているモジュール、HTTP::{Response,Headers,Message} 辺りを解説した後で、この中にある文字コード判定コード $res->decoded_content() に着目してひたすらそのコードを解説するというガチンコトークでした。

たぶん、プレゼン資料に細かい字で書かれたコードをここで読めというわけではなく、雰囲気としてスゴイ大変なことをしているんだということが分かること、あと実際に動いているCPANモジュールのコードの中には色々なエッセンスが入っていてソレを読むことは勉強になる、という理解でよいのかもしれません。

文字コード判定といえば、Perl5.8から登場したEncode::Guess、またスクレイピングモジュールとして有名なWeb::ScraperやWWW::Mechanize等については割愛とのこと。自前でWeb操作系クラスを書くときにはdecoded_content()のコードをうまく活用するとよいかも、とのことでした。また、LWP::UserAgentを用いたコードを使うとき「コンテンツ取得部のデコード処理が適切か」といったことを抑えておくと良いという話もありました。

JPAセッション

JPA(Japan Perl Association)からゲストで来られた @zigorou さんより、今後のJPAの活動まわりのお話がなされました。本人曰く「技術系以外のプレゼンは初めて」とのこと。内容も、JPAという組織の活動といったことが大部分で、Perlのコードは一行も出てきませんでした。

まずは組織と新しい理事のお話。

PerlBeginners#2 JPAのスライド

@shakuji さん、@nekokak さん、@ktat さんが新しい理事に迎えられたというご紹介。

その次は活動報告について。JPAは首都圏や地方のPerlコミュニティの勉強会やイベントを支援しているという内容。私もこの制度のお陰で、札幌のHokkaido.pmで著名な方にお会いできたりして、非常にありがたいです。

さらにperldoc.jpのお話。個人所有だったものをJPAが買ったとのこと。今はperldocの和訳が読めるというサイトだけど、今後は日本のPerl情報が集約されて読めるきちんとしたサイトにしていきたい、そのためにデザインもid:nagayamaさんにお願いすることが正式に決まったとのことです(このあたりの話は先日Ustreamで拝見したKyoto.pmでもid:nagayamaさんが直々にお話していた気がします)。

そしてみんな気になる「YAPC::Asia Tokyo 2012」の話。テーマは「Take Another Step Forward」。ゲストは以下の豪華メンバー。

  • Gosuke Miyashita (a.k.a. mizzy)
  • Tim Bunce
  • Adam Kennedy
  • Larry Wall

その他「IRC(freenode)に入ろう」「ボランティア募集中(Join #yapcasia-staff@irc.freenode.org)」といったお話で締めくくられました。

昨年2011年から私の会社もYAPC::Asiaのスポンサーになることができましたが、今年も会社と相談をして、スポンサーを継続できるように働きかけていきたいと思いました。また今までperldoc.jpの情報にお世話になった恩返しとして、新perldoc.jpサイトの和訳等のボランティアで協力できることがあればしていきたいと思った次第です。

撤収

みんなで片付け。

片付け最中に、懇親会には出られないという @zigorou さんと少しお話させて頂きました。Hokkaido.pmでちょくちょく発表している私を伝え聞いていたとのことで、著名な方に知っていただいているとは本当に嬉しい限りでした。

懇親会

懇親会の会場は水道橋駅の近く。文京シビックホールの春日駅近辺からしばらく歩きました。

懇親会への参加は12人。全員男性でしたが、本体のほうには女性の参加も数名いました。

個人的にIT業界で男性女性をことさら分ける意義は特に無いとは思うんですが、大学や専門学校等で最近は扱われる機会の少ないPerlを勉強していこうという方が男性女性問わず増えていくことは、とても好ましいことだと思います。

PerlBeignners#2 懇親会

懇親会では酒が入った熱い話が続きましたが、途中からついつい私の偏ったPerlの知識の総決算でもある mod_perl について熱く語ってしまいました。同席の方、申し訳ありませんでした。私がここまで mod_perl に傾倒することになった経緯については、どこかでまとめて紹介できればと思います。

各自色々な話で盛り上がった後、終電が迫っている方から順に解散していきました。

最後に

次の開催は2ヵ月後、6月29日(金)を予定しているとのことです。隔月開催なのかな。非常に有意義な勉強会でしたので、次回もぜひ参加させていただこうと思います。