おがた (@xtetsuji) です。
2015年4月3日（金曜日）、1社目で最後まで一緒に働いていた後輩と二人で久々に飲み会をしました。そこで考えて語ったレガシー開発論など、公開しても良さそうなところを書いてみます。私は2014年1月に退職していますが、後輩は今も在職しています。
飲み会 (@ 居酒屋 だいぶつ in Shibuya, 東京都) https://t.co/Xl4yJEqZRK pic.twitter.com/yA7ekhowXX
— OGATA Tetsuji (@xtetsuji) April 3, 2015
書きたいことはざっと書いたのですが、推敲がうまくできなくて長文になってしまいました。暇な時に流し読みしていただくのがちょうどよいかもしれません。長いブログ記事、Kindleで電子出版したほうがいいかもしれませんね…。
執筆依頼やモジュール類のドキュメント化依頼は随時受け付けていますので、この勢いで文章を書いて欲しいという方がいらっしゃいましたら、ぜひご依頼ください。
おがた (@xtetsuji) です。
以前からこのブログにも書いていますが、2011年からコミュニティ活動を始めて、各地のPerlの勉強会や、2012年と2013年のYAPC::Asia Tokyoでmod_perlのトークを頻繁にしてきたからか、今も「mod_perlといえば@xtetsuji」とか「モドパール神」とかたまに言われます。恐れ多い。
新年度になって振り返りの余裕もできたので、最近の私とmod_perlとの関わりを書いてみたいと思っています。
1月末に退職して2月初めに転職したことをご報告したのですが、現在の職場はPerlの会社ではあるものの、mod_perlは使っていません。それなのに、よく採用していただけたなと、ありがたい限りです。
前職でも案件が入れば必要に応じて書くという感じだったので、年がら年中mod_perlのコードを書いていたというわけではありませんでしたが、今の会社では入社から今まで2ヶ月の間、mod_perlとの接点は当然ながら全くありません。
以前のエントリにも書きましたが、数社面接を受けて、mod_perlを使っている会社から不採用で、mod_perlを使っていない会社から内定をもらうという事実が人生のネタみたいなものでした。
今の職場で配属された部署では、以前からの案件ではCGI(SpeedyCGI)上に乗った独自フレームワーク(OSSにもなっているけど、ほぼほぼ自社フレームワーク)。新しい案件ではモダンにNginxをリバースプロキシ役として前面に立たせて、Plack+Starletに載せたAmon2改造フレームワークを使って開発しています。
エンジニアの上司や偉い人もしばしば「mod_perlは使う予定もないからねー」と言っています。適材適所なので、使わせてくれと言ったことはないし、現状うまくいっているので良い感じなんですが、なんか私がmod_perlの人と思われているようで、mod_perlの話が出るとそんなことを言われます。
個人ではというと、借りているVPS(さくらのVPS)では、ウェブサーバはApache2.2+mod_perl2という構成で動かしていて、何か込み入ったことをやりたいと思ったときには、時々mod_perlハンドラを書いたりしています。
OAuthを使ったサービスを作るためのスクラッチはmod_perlハンドラだと面倒だったので、Mojolicious::Liteを使ったりしています(面倒だったのでApacheのmod_proxyでリバースプロキシさせました)。会社がAmon2寄りとはいえ、Mojoliciousも使ったりしているのは、Mojoliciousの可搬性を個人的に気に入っているからです。
自宅サーバでは今もApache1.3が動作しています。過去の環境を意図的に残す意味で、わざとやっている部分もあるんですが、そこでmod_perl1のハンドラを書いたりすることもあります。
実際に個人的に作りたいサービスもあるのですが、MojoliciousとAmon2を作る対象物に応じて分けて使って、小さいものはmod_perl (PlackのPlack::Handler::Apache2) で動かしたいと考えています。なぜって、ログを見るのが簡単だから。
先日業務で、NginxからPlack+Starletへリバースプロキシして、plackupはSupervisorで起動するっていうのをやったんですが、もうデバッグ時にログを見るのが大変でした。何かあったときに、Nginxのログ、Plackのログ、Supervisorのログがあって、どれを見ていいものかとか、なかなか戸惑いました。慣れの問題だったり、あとアプリケーション仕様のURL設計が難儀だった(これは私が設計したものではないです)ってのもあるんですが、ミドルウェアが増えるとログも増えて大変だなーと思った次第です。個人レベルで小さなウェブサービスを作るのであれば、ミドルウェアを不必要に・扱いきれないほど多くする必要はないかなと感じています。Apacheなら堅牢だし。
前職でmod_perlを劇推ししていたのは、自分がmod_perlが好きという他にも、インフラ部署がほとんどのミドルウェアの使用を許可しないという理由があったからでした。それは退職エントリにも書いたのですが、彼らの言い分は「ミドルウェアが多くなればなるほど監視対象が増えて自分らの仕事が増える」ということらしい。まぁごもっともではあるのですが、memcachedとか既に市民権を得ているようなミドルウェアまで危険視されて入れさせてくれなかったのは、自分のキャリア的に多様な経験を積む機会を奪われたとしか言いようがありません。結局memcachedのようなものもmod_perlで書きました。それならOK!
先日PerlBeginners#12に参加したときに、「会社でインフラを担当している」という方からmod_perlの質問を受けました。やはりmod_perlにもまだ一定の需要はあるんだと感じました。
私だって転職活動時にmod_perlを使っている会社を聞きつけたりもしたくらいですから、好きか嫌いかは別として、使っている会社や使おうとしている会社があるというのはわかります。
前述の通り「ミドルウェアが集約されて簡潔な構成になる」「監視対象のデーモンや永続プロセスの類が減る」といったことをメリットとして捉えてApache+mod_perl構成を取る会社もあるだろうし、そういう選択もあるんじゃないかなーと思います。静的ファイルはフロントエンドに立たせたNginxが出力して、動的な画面はバックエンドのPlackが…といった構成は、中小規模の開発(漠然としていますが)であれば、それほど求められないと思います。古いもの＝悪、新しいもの＝善、の構図は全ての文脈で当てはまるとは言えないでしょう。
幸か不幸か、mod_perlの活きた知識だけは頭の中にたまっているので、そういったmod_perlをこれから使っていく人のために情報を出していったりコンサルタントをしていったりしたいと考えています。
Twitterアカウント @mod_perl_info がありますが、あまり活動をしていません…。とりあえずその辺りから活動を初めて、mod_perl関連の文章の翻訳などをしていければと思っています。英語が得意なわけではないのですが、mod_perl自体の知識があるので、翻訳兼監訳的な立ち位置で翻訳作業ができるかなと考えています。とはいえ今は時間がない。
前職で10年間Perlをやっていた半分以上はApacheのmod_perlを突き詰めて研究して、それ以外のサーバやミドルウェアはほとんど(少なくとも)業務では触りませんでした。というか最後のほうは触らせてすらくれませんでした。
なので「Perl歴10年くらいです」といっても、mod_perl以外の知識が全然無いというある種面白いPerlプログラマーなのですが、そういった私を重宝してくれるPerlの勉強会や職場があることに本当に感謝しています。
今の環境で学んでいる「新しいこと」も伸ばしていきつつ、それもまたブログやトークの形などでフィードバックしていければと思っています。それと同時に、mod_perlの知識も「生き証人」として、後世の人に分かりやすい形で残していければいいなと、強く願って実行に移そうとしています。
こんな私に要望などがありましたら、遠慮無くどんどんリクエストしてくださると嬉しいです。
こんにちは、おがた (@xtetsuji) です。
2013年9月19日〜21日まで慶応大学日吉キャンパスで行われる YAPC::Asia Tokyo 2013 でトーク「mod_perlの展望とApacheの超絶技巧」をさせていただけることになりました。
Apache httpd server (以下Apache) 上で動作して、長らくPerlのウェブサーバ高速化環境として欠かせなかったmod_perl。今では新たな技術が出てきてその役割が少しずつ減っているように感じる昨今ですが、そのmod_perlのこれからの展望について話す予定です。
昨年のYAPC::Asia Tokyo 2012では「モダンmod_perl入門」というトークをさせていただきましたが、そちらがmod_perlの本質のご紹介とその実践であれば、今年はより思想的かつ哲学的な話、具体的に言えばmod_perlの未来といった話をしようと考えています。もちろん、コードや動くものが出てこないのは楽しくないので、後半半分くらいは「超絶技巧」と題して「そんなことまでApache+mod_perlでやるのか！」と人を驚かせるような事を披露する予定です(が、2013年8月7日現在構想段階です)。
チケット発売は8月11日(日曜日)までです。私は2007年から毎年参加していますが、Perlをメイン言語にしないプログラマの方も絶対に楽しめる3日間です。この規模のイベントにしては5000円は安い！しかも学生は無料(申し込みは8月11日までに必要です)。ぜひ会場で会いましょう！
質問など有りましたら、Twitter @xtetsujiなどへお気軽にどうぞ。
こんにちは、北海道生まれ北海道育ちで北海道大好きな おがた (@xtetsuji) です。
ブログを書いている3月末から少し時間が経過してしまいましたが、3月9日に行われた Hokkaido.pm#9 に行ってきました。
今回はまとめもUstreamも無いですが、上記リンクからスライドをたどることができます。
前回(#8)は2012年12月末で、フィギュアスケートとSMAPコンサートが重なって、札幌近郊に宿が取れなかったり大変な事になりましたが、今回は穏やかに開催することができました。ただ、全国的に大荒れの天気で吹雪が大変でしたが、それもまた良い思い出。
今回の感想は短めに。スライドについては前述のリンクから御覧ください。
@aloelight さんによるトーク。
Ruby Gemfileの移植であり、依存モジュールの厳密なバージョン定義ファイルであるcpanfileについてのトーク。cpanm や Carton で利用可能とのこと。
cpanfile がどういったものかといったことや、なぜそれが必要なのかといったことは、cpanm や Carton の作者でもある Tatsuhiko Miyagawa さんも書かれています (それの翻訳)。英語ですが、こちらも通読しておくとよいかもしれません。私も勉強します。
@shinotra さんによるトーク。
Hokkaido.pm Casual ではトーク経験があるとのことですが、今回 Hokkaido.pm では初のトークとのこと。それでもかなり好評なトークでした。
実際に作ってみたウェブサービスの話。最近はミドルウェアよりもそれらを使って実際にウェブサービスを作ってみるといった事に興味が集まる傾向にあるのですが、今回も多くの人の興味をひいていました。私も聴いていて楽しかったですし、ウェブで何か作りたいなぁって思わされました。
私 @xtetsuji のトーク。
主にペンシルパズルをPerlで解くためにCPANモジュールを使ったり、またゲームとは何かといった哲学的トークを後半に入れた構成でした。
今回は反省材料が多かったです。誤解を与えるような表現があったり、リスペクトのつもりがdis(ディスリスペクト)になっていたり、ネタやギャグがことごとく滑ったり…;。一応記録として、トークを除いてスライドだけ見ると誤解を受けたりする部分を修正した版のスライドをアップしました。
個人的な反省項目については下の方に書きます。
JPA招待ゲスト @xaicron さんのトーク。
最前線で活躍している人がいったいどういう環境やモジュールを使っているのかというのは、意外に興味深いところです。「CPANソムリエになる方法」。
上記リンクから、完成版スライドが閲覧できるので、Perlを勉強中の方々はぜひとも目を通して、今の流行りどころはどのあたりなのかといった部分を感じ取ってみると良いと思います。私も最前線を追っかけるのが苦手な人間なので、非常に勉強になりました。
17:30開始が好評となったので、今回も17:30開始となりました。
二次会の場所としては、前回 Hokkaido.pm#8 のときと同じ。活イカ好きの @onagatani さんオススメの場所。
しかも個人的に前日札幌入りした夜に行った二次会もここでした。活イカ三昧ですけど、美味しいから満足。
折りしもの吹雪で人々が散ってしまって、一部の人だけで少し遠方のラーメン屋まで歩いてラーメン食べました。今回はいつも恒例の「すみれ」では無かった。気づかないうちに @onagatani さんがいなくなっていたからかもしれない。
開始が17:30と早いので、三次会まで行っても終電には余裕があるという優しい時間設計。今回の私は、いつものすすきのの宿が取れたのでJRに乗って恵庭まで行くとかいう前回のようなことは無かったです。
上記に書いた通り、結構滑った感じの今回のトークでした。テーマ決めるまで時間がかかったり準備不足だったり調子に乗っていたり(スライド半分くらいしかできていないのに前日札幌入りして夜中まで飲んでいた)、色々要因はあると思いますが Hokkaido.pm#5 から5回も登壇すれば、一度は失敗(?)することはあるかー、と思う他ありません。失敗も含めて場数を踏んで、トーク力や開発力をアップしていければいいなと思っています。
Games::* の話は、2006年くらいに一度盛り上がったとのこと。mod_perlでも6年くらい前の流行を追いかけている自分なので、まぁ6年前の流行を再復興できてよかったかなとポジティブに考えています。そうでなければmod_perl芸人やっていけない。
折しも、このトークの後で数学や数独の界隈が盛り上がったりしていて、まだペンシルパズル系のネタはいけるかなと考えています。スライドにも書かれている通り、全く対価を求めずに個人的興味だけでスリザーリンクの研究も進めていたり解法モジュールを書いたりしているので、その成果も随時公開していければと考えています。
今回はcpanfileの話からウェブサービスを作る話、そしてCPANソムリエになるためのトークなど、前回がスピリチュアルや設計トーク中心だったことを考えると、実践的なトークが多かったように思えます。今回も非常にモチベーションを高めることができたので、次回 #10 もぜひ参加したいです。#5 からの連続参加記録はまだ途切れていない。
次回 #10 は7月予定とのこと。今回は(今回も？)様々なイベントと重なってしまい、参加者数的にはそれほど多くは無かったですが、次回は告知などで私も協力できる部分は協力したりして、多くの参加者の方々に来場していただき、Hokkaido.pm と北海道を体験していただきたいと考えています。記念すべき10回目が盛り上がると良いなと、色々な意味で故郷である Hokkaido.pm には強い思い入れを感じます。
毎回トークする人が固定化するのは良くないと考えているので、新しくトークしたい人がいればぜひとも枠を譲りたいところですが、もしトーク枠があれば、原点回帰してApache mod_perlの話でもしたいですね。Apache 2.4でも、もうそろそろmod_perlが安定版で動作しそうだったり、手元でもまだ「秘密のネタ」を仕込み中だったり、Hokkaido.pm とは切り離してmod_perl活動を進めていきます。
今まで #5 から何回かトークしたmod_perlネタは、面白い(自画自賛というより「こんな変態的なことやる奴いるのか！」的に)割に聴衆にスキルとして持ち帰ってもらえない、という欠点があったように思えます。その場が盛り上がればよいとは思うのですが、何かネタ以外で持ち帰ってもらえるようなネタがあればいいなと思って今回は全く別のテーマにしたのですが、ちょっとアテが外れてしまいました。トークの世界はなかなか難しい。でも、だからこそ面白い。
次回キリの良い10回目、いつにもまして盛り上がれればいいなと思います。北海道の夏は空気も綺麗で涼しくて最高ですよ。2ヶ月前くらいに航空券と宿泊先を抑えればかなり安くなりますし、関東圏在住の方々も、旅行やリフレッシュを兼ねて Hokkaido.pm に行ってみてはいかがでしょうか？
自称mod_perlエバンジェリストの おがた (@xtetsuji) です。
2012年のYAPCで「mod_perl王にオレはなる！」とか言っておいて、mod_perl業がおろそかになってしまって非常に恐縮です。最近は別の事に熱中していて…;という言い訳は置いといて、そろそろ本腰を入れてmod_perlしていきます。
Twitterを見ていたらこんなツイートがありました。
[tweet https://twitter.com/_sugarsan/status/301911501659320320]これに対して @mod_perl_info は
[tweet https://twitter.com/mod_perl_info/status/302079473338175488]…;と返しましたが、mod_perlだけでこういう問題を解決するにはどうすればよいでしょう。
まずは system($cmd.’&’) 作戦から。
mod_perl の Perl CGI エミューレート環境 (Apache::Registry, ModPerl::Registry ファミリー) では、コードはある種のコンパイルをされ、特殊な内部パッケージ名の handler という名前のサブルーチンの中のコードとなります。mod_perl は一度メモリ上に作った特殊な内部パッケージの handler というサブルーチンを繰り返し呼び出すことでコストを抑えています。
mod_perlのPerl CGIエミュレート環境ということで、CGI.pm か CGI::Simple を使っていると仮定すると、system($cmd.’&’) されるのは print $cgi->header(); を行って、必要なHTMLなりテキストなりのアウトプットが完了した時点だと思います。そうでなければユーザに完全なレスポンスを返さずに長時間作業に入ることになってしまい、ユーザはブラウザの前でイライラすることでしょう。
これで問題解決…;と言えるかもしれませんが、いくつかの問題もはらんでいます。
これをmod_perlだけで解決するにはどうすればよいでしょうか。
ネタ元ツイートの方は exec が CORE::exit と同等 (Apacheの子プロセス自体を終了させる) と言及していますが、実際の exec の挙動は一般的に「現在のプロセスを他のプロセスで置き換える」事です。execはexitと違い、mod_perl側が *CORE::GLOBAL::exec をいじるなどのサポートは行っていないので、元のexecそのものの挙動になります。preforkされた該当の子httpdは $cmd で定義されたコマンドに置き換わり、親から見たら子は突然消えたことと同じことになり、子が設定値的に足りなくなれば親が充足してくれます。ただ、以下の問題があります。
前者は少々乱暴でも良いとは思いますが、ログが書かれない事を望むウェブ開発者はいないでしょう。
これら全てをmod_perlだけで穏当に解決するにはどうすればよいか。
まずmod_perlというかApacheは、レスポンスを返すフェーズの後続が以下であることを復習しましょう。
長時間かかる仕事 $cmd を実行するのであれば、レスポンスフェーズをきちんと終わらせた後、ログ処理フェーズでログを書いてもらい、$cmd の実行はクリーンナップフェーズで行うのが良いでしょう。大量に来るのであればクリーンナップフェーズで exec して子httpd を $cmd にして、親に「子が親離れした」と思わせてもよい。クリーンナップフェーズであれば既にログも書いているので、exec で子が「いなくなっても」問題は無いでしょう。
それは以下のようなコードで実現できると思います。mod_perl の Registry ファミリーを使った Perl CGI エミュレーションスクリプト中を想定。
my $r = $cgi->r # $cgi is instance of CGI.pm or CGI::Simple
or warn "non mod_perl environment";
if ( !$r ) { # Pure CGI
system($cmd.'&'); # Pure CGI の場合は諦めてここで実行
} elsif ( $r->can('register_cleanup') ) { # mod_perl1
$r->register_cleanup(sub { system($cmd.'&'); }); # exec($cmd) でも OK
} elsif ( $r->can('pool') { # mod_perl2
$r->pool->cleanup_register(sub { system($cmd.'&'); }); # exec($cmd) でも OK
}
else { die "unknown"; }
もしくはmod_perl環境でもわざとレスポンスフェーズの末尾でsystem()をして、それに掛かった時間をログに載せるという手もあります。
my $r = $cgi->r; my $start_time = time(); system($cmd.'&'); my $end_time = time(); $r->notes->set( cmd_proctime => $end_time - $start_time ) if $r;
Apche の LogFormat ディレクティブで %{cmd_proctime}n を使って参照できます。
$r->notes->set( cmd_proctime => $value ); でなく $ENV{cmd_proctime} = $value; として LogFormat ディレクティブで %{cmd_proctime}e として参照することもできますが、これはmod_perlではバッドノウハウ。この子プロセスが次に受けたリクエストがこのsystem()処理を行なわいスクリプトでも比較的永続的なプロセスである子は環境変数を持ち越してしまうので、前回の値がかかれてしまう。Pure CGIはそもそもApacheノートや環境変数でmod_log_configに値を渡すことはできない(これについて以前FastCGIでどうすべきかを論じた記事がありますが、それがPure CGIでも参考になると思います)。
mod_perlでも、Apacheの処理フェーズなどを駆使してここまで曲芸ができるという例でした。
上記コードは全て知識を元にした推測で書いています。実証実験はしていません。何か問題があればTwitter等でリプライください。
もっと汎用的にこの問題に取り組みたいということであれば、ジョブキューを使いましょう。例えば「第10回 ジョブキューで後回し大作戦―TheSchwartz，Qudo，Q4M（3）：Perl Hackers Hub｜gihyo.jp …; 技術評論社」や、書籍「モダンPerl入門」を参照すると良いと思います。
こんにちは、北海道生まれ北海道育ちの おがた (@xtetsuji) です。
2012年12月23日に行われた Hokkaido.pm#8 に行ってきました。
その他、2012/12/30 現在でアップされている参加者の皆さんのレポート。
私のレポートよりも参考になると思います。
今回のHokkaido.pm#8は
などの理由により参加者が少なかった・参加者が参加に苦労した回でした。かくいう私も、普段は普通に(懇親会の会場となる)すすきのに宿をとるのですが、すすきのどころか札幌駅近郊のホテルがのきなみ満室で、僻地恵庭に宿をとることになりました。
以下、発表、LT、懇親会レポートなどをつらつらと書いていきます。
@jamadamさんによる発表。
前回(#7)の発表から特段新ネタは無いとのこと。スライドは早々に終了して、以後はライブコーディングというかライブメンテナンス作業を見せるという斬新な光景になりました。会場提供のWi-FiではGitHubにアクセスできない等トラブルもありましたが、面白かったです。
JPAからいらっしゃった@typesterさんによる発表。
この「XSにまつわる話」はスライドがSpeakerDeckにアップされており、@akiyamさんによる詳細なレポートがあるので、そちらをご覧になると良いと思います。
XSとは何かという話から、実際に@typesterさんがXSを始めることになった話から、XSの初歩まで、盛りだくさんんで非常に参考になりました。「あぁ、XSってこういう時に使うべきなんだ」って、改めて実感がわきました。「高速化」というのはあくまで黒魔術師がやることであって、本来はCで書かれたライブラリを低コストで呼ぶものだということなど。
Hokkaido.pmのボス(?)@onagataniさんによる発表。
次回は3月初旬開催予定、というか確定。
@onagataniさんだけでは負担。運営やりたい人いる？→@aloelightさんにお願い。
次回はJPAから@xaicronさんが来てくれることになった。
引き続き@typesterさんによる発表。
こちらは先ほどのXSのトークとは違ってスピリチュアルトーク。勇気づけられました。
@zigorouさんによるトーク。
非常に詳しいトークでしたがテンポも早く、手元のメモそっちのけで聴いていました。こちらはUstreamによる録画があるので、そちらをご覧頂くのがよいかと思います。@zigorouさん自身も、スライドが完成したら公開するとおっしゃっていたので、それを期待しましょう。
@ 鶏屋とことん
前回好評だった、本会終了から時間を待たず17時30分から飲み始めるパターン。
今回はすすきの移動ではなく、東札幌駅近くの居酒屋での開催となりました。料理が美味しかった。
本会は参加人数は少なかったですが、そのほとんどの人が懇親会にいらっしゃっていて、非常に密に盛り上がれたと思います。これはこれで楽しかったー。
外はすっかり吹雪いていましたが、タクシーですすきのに移動して @onagatani さん推薦の活イカの店でイカや日本酒を堪能。これまた美味しかった。
お決まりのコース、すみれでラーメン。
23時30分ごろには解散。
今回はすすきのに宿が取れなかったので、地下鉄とJRを乗り継いで恵庭のホテルに帰ることになりました。ただ、JRで2駅寝過ごしてしまって恵庭で降りられなくて、タクシーで戻ることに。1800円くらいの痛い出費をしてしまいました…;。SMAPとフィギュアスケート…;。
写真は外部リンク(Twilogや4sqなど)から参照してください。現在写真整理中…;。「顔出しNGの人いますかー？」って聞かなかったなぁ、そういえば。今回は下手ながらコンデジで頑張って写真を撮ってみたのですが、無難に限定公開できる場所に公開できればします。
今回はガチ技術論というよりもスピリチュアルなトークや概論的な話が多かったような気がしましたが、聴いて奮い立たされる話が多くて面白かったです。
いつも来る人が来れなかったり、参加者が少なくもあったのですが、これに関しては時期的にもアレ的にも仕方がなかったです。3月開催予定のHokkaido.pm#9に期待です。よほど避けられない予定がなければきっと行きます。
こんにちは、先日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 の世界で、皆さんのお役に立てるアウトプットをしていきたいと考えていますので、どうかよろしくお願いします。ここまでの長文、読んでいただきありがとうございました。
こんにちは、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年の発売当初から本当にお世話になっているので、改訂版への淡い期待など、積もる想いで一杯です。
先ほども書きましたが今回、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や他の中小規模の勉強会で会った人達やネット上で交友がある同士の「同窓会」としては非常に面白い場です。
噂通りの美味しい食事にお洒落な飲み物が揃っていて、昨年の前夜祭との違いにビックリしました。
聴講したトーク(敬称略)
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やりつづけてもいいんじゃないと思うくらい。
前夜祭の人数の比ではないくらいの人が集まって、食事も行列状態。すごかった。大群衆に揉まれるのが苦手な人間なので苦労はしましたが、前夜祭同様、いつも会わない方やTwitterやブログでのみ面識のある方との交流がメインでした。食事は早々になくなっちゃったし。
スカイアークの小林社長が会場入りして、乾杯の音頭を取ったのは印象的でした。やはり力強い方だなと。実はスカイアークの小林社長とは昨年の5月の初対面ぶりの再会。久々にお会いして道民トーク・十勝帯広トークで盛り上がりまくりました。楽しかった。その場の勢いで北海道つながりの飲み会を東京でやろうという話が実現してしまったくらい。
2007年からYAPCに参加していますが、今まで引っ込み思案で、Larry Wall氏が来日していても近寄れないでいたのですが、今年は大胆に行こうと、一緒に写真撮影をお願いして快諾していただけました。嬉しかった。
飲み物は潤沢にあったので飲みまくったし、疲れたし(もともと疲れやすい)、明日自分のトークあるしで、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を使おうとしているので、そこでも良い資料になりそうです。
1日目のLT、2日目のLT、そして併設の会場でのLTthon。5分間の枠でどれだけ聴衆を楽しませるか。世間でもLTのノウハウがたまってきてはいますが、本当にみなさんLTがうまい。今回も @hiratara さんによる「Perlでおねえさんを救ったお話」や、女性による半ば下ネタかと思わせるような人生ネタ、スカイアークスポンサーセッションによる @onagatani さんコスプレ付きの北の国からネタ「帯広から、愛」等々、本当に笑わせていただきました。
今回は特に流行が無くて寂しいとか今後の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がありさえすれば絶対に参加します。繰り返しになりますが、本当にありがとうございました！
こんにちは、東京在住なので東京の勉強会にも顔を出し始めた おがた (@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 mod_perl が大好物の おがた (@xtetsuji) です。
そういえば、2012年に開催されるYAPC::Asia Tokyo 2012にトーク「モダンmod_perl入門」を応募しました。この記事が気に入りましたら、ぜひとも「イイね！」お願いします。
mod_perlに偏執的なのも良くないなと思って、最近はFastCGIやPSGI/Plack以降のWAFも勉強しています。Perlから外に出られていないのがまだまだといったところですが…;。
それでも好きが講じて、Twitterを使って日々mod_perlの情報を収集しているのですが、今日こんな会話を見つけました。
この会話、要約するに
FastCGIの仕様書や、FastCGIを使ったプログラムを書いたり読んだりしたことはありますが、私はそれほどFastCGIの仕様はわかっていません。ただ、当初これはFastCGIでは無理ではないかと思いました。
環境変数ならと考えてはみたものの、perldoc FCGI を読んでみても実際に試してみても、use FCGI; して得られた my $request = FCGI::Request(); を試行錯誤していじってみても、環境変数をApacheリクエスト処理の後続に位置しているログ処理フェーズに伝えることはできませんでした。…;というかそんなのは当たり前ですね。詳しく説明できない程度の知識しかないのがもどかしいですが、FastCGIはApache本体とは独立したコンテナのようなデーモン(サーバ)を作るわけですから。気の利いたソケット(詳しくないけど言ってみたかっただけ)で両者が繋がっていれば話は変わってくるかもしれませんが、最初から勝算はありませんでしたし、うまくもいきませんでした。
perldoc FCGI をさらに読んでも、環境変数はまだしも、Apacheノートに関する記述は完全にありませんでした。敗北が見えはじめました。
基本に戻ってLogFormatのカスタムログ書式を復習してみました。ApacheのサイトにあるLogFormatのカスタムログ書式のマニュアルを読んでみると、任意データを受け取れそうな “%{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ノートにデータを読み書きする方法は、ざっくり以下です。
実際にmod_perlハンドラを生で書く場合には幾つかの注意点があったりしますが、今回は割愛(需要あるかな？)。CGI.pmではその部分をなんとなく吸収してくれています。ただひとつ注意点は、CGI.pmのドキュメント perldoc CGI では r というメソッドには一切触れていない、つまり非公開メソッドであること。とても歴史の古いモジュールですので、突然次の日に使えなくなる可能性は限りなく低いとは思いますが、使う場合はその点ご留意ください。
そんな部分も含め、mod_perlの興味深い世界に興味を持っていただいた方は、しつこいですがトーク「モダンmod_perl入門」にぜひ「イイね！」よろしくお願いします！YAPC::Asia Tokyo 2012 会場でのトークや(トーク動画とともに後日公開もされる)資料で、もっと興味深い世界をご紹介します。