perl」カテゴリーアーカイブ

cutコマンドが分からないからxsvcolコマンドを作った

cutコマンド、いつもよく分からなくて使い方をmanするんですが、よく分からなくて結局 perl のワンライナーを使ってしまうので、perl で cut コマンドのような事をする xsvcol コマンドを書きました。大したものではないですが。

使い方は

xsvcol 正規表現文字列 0始まりの区切り番号

で、具体的には

ps ux | grep foo | xsvcol '\s+' 1 | xargs kill -HUP

といった感じで使います。上の説明は、foo が入ったプロセスの2番目のPIDを取り出して、xargs で kill に渡して HUP を投げるという感じ。名前の由来は何か(x)で区切られた値(separated value)の列(column)を取ってくるというもの。

仕様は気分で変える可能性があります。GitHub から clone するか pull するときに、perldoc をチェックしてみてください。

使っている外部モジュールはないので、通常Perl5が入っているシステムであればどこでも使えると思います。

その他にも、GitHub の xtetsuji/varios-commands には掘り出し物系コマンドがあるかも。面白いコマンドが出来たらまた紹介記事書きます。興味があれば git clone して bin/ ディレクトリにパスを通してみて下さい。

Hokkaido.pm#10 に参加してきました #hokkaidopm

こんにちは、おがたです。

8月31日に行われた Hokkaido.pm#10 に参加してきました。

詳細は上記の開催報告が詳しいです。参加者のブログ記事もまとめられています。

場所はいつものところ

いつもよりかなり遅めにホテルを出たのですが、現地に向かう途中で @ytnobody さんにあったり、@akiym さんにあったりしました。13時開場を13時開始と勘違いしていてみんな焦っていたという…。

あと、開始直前に LOCALの @koiwa さんが颯爽と現れて、学生支援の(?)クオカードを置いて行きました。「せっかくだから少し見ていきませんか」って言ったのですが、用事があるらしく、一瞬だけ来て颯爽と去って行きました。

今回も前回同様Ustream生放送はありませんでしたが、@onagatani さんが一部を録画していたようです。後日公開されてるかもしれません。期待。

今回は開催に当たって大きなイベントを避けたつもりが、どうやらバレーボールの世界大会にぶつかってしまったようで、2ヶ月前にも関わらず宿泊先をおさえるのに相当大変な思いをしました。最初は「どうしてこんなに予約埋まっているの?」って感じでした。以前(#8)のSMAPとフィギュアスケートがぶつかったときのような、恵庭まで遠くに宿をとるのは避けたいと思ったので、結構お高いホテルでしたが空室があったすすきのの宿に宿泊しました。

以下、私の手元のメモより。メモを取りきれなかった部分もありますので情報としては不完全、ダイジェスト版だと思ってください。詳細は、上記まとめエントリから各スライド資料を参考にするなどしていただければと思います。

フォームバリデーションを自動化してみた

Mojoliciousのスペシャリストで、雑誌「月刊I/O」2013年8月号にMojoliciousの記事を寄稿したり、mojo-legacy などでも有名な @jamadam さんによる発表。

  • バリデーションルールを書くのは大変。DBフィールドを全部網羅しても不足。1000くらいある。
  • 書いた → Mojolicious::Plugin::FormValidatorLazy
  • ミドルうウェア的な位置づけでバリデーションをする。
  • 署名をつける
  • 問題点
    • JavaScriptバリバリのアプリでは役に立たない
    • スキーマの生成が高負荷
    • あくまでセーフティネット
    • ブラウザの差異を吸収するJSが必要
  • Web Application Firewallという分野で既出?

Perl meets ■■■ → Perl meets Leap Motion

Hokkaido.pm が誇る若手のホープ @akiym さんによるトーク。

大学生。「Herokuで学ぶ、初めてのPerl」という話を YAPC::Asia Tokyo 2013 でする。

  • akictf / CTF: セキュリティ競技大会

Perl meets Leap Motion? → なにそれ?

  • 次世代デバイス
  • 手のひら、指を細かく認識
  • WebSocketでデータを取ってくることができる

#1. air pointer

  • マウス操作
  • OS X でマウスをコントロールする方法
  • WindowsならWin32::GuiTest
  • Cocoa::GuiTest みんな大好きCocoaモジュール
  • マウスを動かす
  • ただし不安定

まとめ

  • PerlからLeap Motionを扱ってみました→夢広がっています
  • Cocoaモジュールが足りない

時間が余ったので「GitHub止まりモジュール」5選

  • #1. Text::PicoTemplate
    • ユーザーにテンプレートを書いてもらう
    • – Text::MicroTemplateはPerlのコードが実行出来るようになっている
    • – 変数のみサポート
    • – s/// でやれば
    • – もう少し柔軟に対応したい
  • #2. Text::ChineseNummeral::JA
    • 漢数字→数字
    • 正規表現でゴリゴリ → ワイルド
  • #3. Cocoa::NetworkChange
    • ネットワークが変更されたときに何かをする (OS X専用)
    • 例えば特定のWi-Fiにアクセスしたときにログイン処理をするとか → 大変捗っている
    • is_network_connected()
  • #4. Iroh
    • もうひとつのTeng
    • ネーミングがおかしい
    • T*nga – a  = Teng
    • no inflate, deflate, iterator
    • というかTeng使っています
  • #5. WWW::Fc2Video::Download
    • WWW::なんとか::Downloadシリーズ
    • FC2動画が足りない!
    • 単純にスクレイピングだけでは不可能
    • 良モジュール!

https://github.com/akiym をどうぞ。

イベント駆動とノンブロッキング

私 (@xtetsuji) のトークです。

詳細は Slideshare にアップしたスライド からどうぞ。

以前から @aloelight さんに「YAPC (mod_perlの展望とApacheの超絶技巧) の前哨戦みたいなトークどうですか?」と言われていたのですが、そういえばイベント駆動ウェブサーバのことをよく分かっていないなー、ということで、その勉強の記録をまとめてトーク素材にしてみました。むしろ、ブロッキングだとかそういう事を何となく理解したつもりになって、イベント駆動自体の理解を深めずにAnyEvent周辺を使っていたこともあるし、Apache 2.4 で正式リリースされた event MPM の理解にもつながるだろうということもありました。さらに社内の部内勉強会でそのあたりを突っ込むきっかけもあったので、さらにちょうどよいきっかけとなりました。

ウェブサーバを自分自身で書いてしまう凄腕のプログラマーとか、分かっている人は分かっているのでしょうが、StarmanやStarletやTwiggyやHypnotoadなどのイベント駆動ウェブサーバの使用者側の多くの人の中で「なんとなくググって出てきた方法で起動させたら動いたので、なんとなく使っている」という人もいるのではないかとは感じていました。数カ月に一回のHokkaido.pmだからといって肩筋を張って自分ができうる限りの難しい話をするよりも、恥を忍んでこのような初歩的なトークをしてみるのも悪くないかなと思って、今回のトーク資料を作った感じです。

普段のmod_perlネタはあまり反響がない(?)のですが、今回はSlideshare上でもそこそこ資料に対する反響もあったようで、やはり興味を持ってくれる人は持ってくれるんだなということはわかりました。

懇親会で @tokuhirom さんから、epoll や IO::Select を中心に調べてみるとよいといった話を聞くことができました。epoll については勉強会や独自勉強の過程でも出てきたキーワードで、自分自身Linuxの基礎の勉強が足りないなと痛感していたところでした。雑事が落ち着いたところで、持ち運ぶのも重量級な1600ページを越える書籍「Linuxプログラミングインタフェース」を買って重要箇所から拾い読みして勉強する予定です。さすがに書籍の体積と重量が凄まじいので、先日発表されたKindle Paperwhiteの最新版を予約しました。PDFの電子書籍版を購入する予定です。時代は電子書籍なんでしょうね。紙の書籍の質感は大好きなのですが、自宅の本棚が満杯なのを見てそう痛感する次第です。

ここ最近の取り組み

TengやQudoなど多数のPerl CPANモジュールの開発者として有名な @nekokak さんによるトーク。以前 JPA 派遣講師として来てくださいましたが、今回は自費で参加してくれました。

現在は DeNA に在籍しており、普段はあまりコードを書かないマネージメントをされているようです。

  • Gmailとスプレッドシートが友達。
  • 海外とのコミュニケーションのため、英語のスラングの勉強ばかり
  • commit log に fuck fuck 書くようになりました

共通技術基盤という組織について。

  • 自分たちで解決した問題を宣伝
  • いろんな所に首突っ込んで宣伝
  • 一緖にやってくれそうな別部署捕まえて進めていく
  • 社内tech talkとかやってどういう取り組みやってるか宣伝

BaranというPerlモジュールの名前空間を作ったら社内でウケた。

  • 名前の元々の由来は弁当に入っている仕切り「バラン」→そういう影を支えるモジュール
  • Baran::DBI
  • DBIx::Handler のラッパー
  • Baran::Memcached
  • Cache::Memcached::FastのDeNAラッパー
  • Baran::PushNotification
  • DeNAのInfraに特化した内部共通モジュールとして成長
  • DeNAに依存しない物はCPANモジュールにしたい
  • Baran::PushNotificationとか普通にCPANモジュールとしてアップしたい

プッシュ通知はバッドノウハウ。CPANモジュールをそのまま使うと結構ハマる。

新しい取り組みについて。

  • 新規プロジェクトを始めるときは必ず何か今までにやったこと無いことを取り入れるようにしてる
  • 例えばNginxは他部署に黙って採用して既成事実化したりした
  • JSON-RPC

SOA化の推進。

  • 細かく分割しよう
  • JSON-RPCのmethod単位でplackup
  • methodによってrequestの数とかが異なるので用途ごとにスケール出来るように

マネージャーになるときに思ったことや聞かれたこと。

  • よくコード書きたくならないですか?
    • 自分が書いたほうが速いこともある
    • 書きたいこともある
    • でも本気で書いたら負け
    • 一人で挙げられる成果なんてたかが知れてる
    • チームで高いアウトプットを出せるようにするのがマネージャー

「GitHub止まりモジュール」

  • Komainu
    • Fluentdに置き換えられていってます
  • Class::Anon
  • Data::Koyomi

「Pager Duty」というサービスを多く使っている。アラート用のサービス。メールを投げると誰も反応しないと電話がかかってくる。お金がかかる。SMSはカネがかかる。

CPANと私

JPA派遣講師としていらっしゃった @tokuhirom さんによるトーク。

Thanks to JPA++

自己紹介

  • Web Application Engineer
  • サーバサイド
  • 自社サービス
  • 書いている言語は色々ある:Perl5, Perl6, Ruby…
  • 最近はHTMLよりもJSONを出力するAPIを書いている

CPANモジュールの話をしようと思ったら @xaicron とかぶる

立場が変われば技術もかわる

  • 受託とか
  • 納期とか

アジェンダ

  • CPANモジュールの選び方
  • おすすめのCPANモジュール
  • CPANモジュールを取り扱うためのモジュール
  • 将来への展望とYAPC

CPANモジュールの判別

僕が重要視すること

  • 他人のコードのせいで動かないことはキライ
    • Cratalystみたいにコードがぐっちゃぐちゃなもの

客観的な選別手段

  • 最終更新日
  • CPAN Testersの結果
  • t/が寂しいモジュールは使わない
  • バグトラッカーへの登録数をみる

作者による選別

  • 個性に溢れすぎているCPAN Authors
  • 人ごとの癖がわかると、わりとなんとかなる
  • gfxだから高速
  • ○○さんはテストを動かさないでリリースする
  • ○○さんはインターフェースが重厚
  • ○○さんのモジュールは実際にはつかってない
  • ○○だから非互換の変更をする
  • ○○さんは自分で書くけど使っていない
  • ○○は非互換な変更をする

信頼おけるパールハッカーの例

  • dgolden
  • rjbs
  • miyagawa
  • gfuji
  • mschwern
  • makamaka

速度

  • 当たり前ですね
  • メモリ消費量

Moose依存はダメ。「0.7秒」は困る。

後方互換性に対する姿勢

  • 最重要
  • 動いていたコードが動かなくなるのはすごく嫌

結局は他人に聞くのが一番いい

  • Twitter
  • Lingr
  • etc.

Fukuoka.pmはFacebookページがあるらしい。

Hokkaido.pmにはFacebookページがあるらしいんですけど…

最終的に自分でメンテしてもいいな、というものだけを選ぶ。

流行り廃り

  • アーリーアダプターの穴掘り
  • つきあう必要なし

流行りは廃りでもある。ある程度落ち着いてからでいい。

CPANモジュールの選び方の実例。「@xaicronとかぶっていないのをえらんでみました。」

アプリケーションサーバ → Plack+PSGI

  • ◎ Starlet
  • ◎ Twiggy
  • ○ Starman
  • × FCGI
  • – CGI
  • – mod_perl

Starman vs Starlet

  • Starletはかずほさんが一から書いたもの
  • Starman は Catalyst の何かからポートした物

Starlet は中身が追える。@kazeburo さんも読んでいる。良い。

FastCGIは一番無い選択肢。中途半端。ApacheのFastCGIの実装には癖がある。FastCGIの仕様を忠実に守った実装がない。

オブジェクト関連

  • ◎ Class:Accessor::Lite
  • ○ Class::Accessor::Fast
  • × And others
  • ◎Moo
  • ◎Mouse
  • ○Moose
  • ×Any::Moose
  • ×And others

Mooはほとんど問題無いけど、一部モジュールを呼ぶとMooseにアップグレードするというのが問題。

MooはCPANモジュールを作るときに使う。

MouseはMoose陣営から嫌われている。

オブジェクト関連の今後の展開。

  • p5-mop-redux
  • たぶんコアへ
  • たぶん5.20には間に合わない

CPANインストーラー

  • ◎ cpanm
  • × The CPAN Shell
  • × CPANPLUS

O/R Mapper

  • ◎ Teng
  • ○ DBIx::Skinny
  • ○ DBIx::Class (DBIC)
  • × Class::DBI (CDBI)

DBICは海外ではそれなりに使われている。

日付関連

  • ◎Time::Piece
  • ○DateTime

月末問題やタイムゾーン問題というものがある。

JSON

  • ◎ JSON::PP
  • ◎ JSON::XS
  • ○ JSON
  • × Cpanel::JSON
  • × JSON::Any

JSON::Anyは絶対に使ってはいけない。PPとXSを自動で切り替えるモジュールはあまり使わないほうがいい。

JSON::PPは標準添付になっている安心感。速度気にしない場合はJSON::PPで問題無い。

CPANモジュールの使い方

実際、どういうふうに使っていくか

  • plenv
  • cpanm
  • carton

plenv

  • plenv = Perlバイナリの管理
  • perlbrewみたいなもの
  • 複数バージョンのPerl5をきりかえて使う
  • 最新のPerl5をつかう
  • 通常は普通にシステムPerl使えばいい
    • Macだとsystem Perlが腐っているので必須。
    • Linuxならsystem perlをつかってもいい。
      • ただし、system perl は -Dusethreads → 速度劣化
  • アプリケーション単位でperlのバージョンを変えられる
  • 環境変数でバージョン切り替え

plenv global と plenv local の話

plenv local では、古いPerlがこのプロジェクトでは有効に…といったことができる。

$ cat ./.perl-version
5.8.1

環境変数でも指定可能

$ PLENV_VERSION=5.19.0 perl -v

仕組みは、シェルスクリプトを ~/.plenv/shims/perl に置いている。

どうやってバージョンを指定するか

  • PLENV_VERSION
  • .perl-version (plenv local) → ほぼこれ使っていない
  • ~/.plenv/version (plenv global)
  • システムPerl

以上簡単なplenvの使い方。

cpanmの話

  • CPANモジュールのインストールにはcpanmを使います
  • plenv install-cpanm
  • perlbrew の install-cpnam は壊れていた!
  • cpanmはインストールしなくても使える!
  • cpan とか perl -MCPAN -eshell やめておいたほうがいい (とくにperl -MCAPn -eshell の CPAN Shell は)
    • 古のやり方
  • cpanm -n Carton

簡単でしょ

carton

cpanfile というファイルに依存関係を書いておくと

$ carton install

local/ 以下にモジュールがインストールできる。インストールしたバージョンを cpanfile.spapshot に記録。cpanfile.snapshot を元に local/ を復元できる

GitHub止まりモジュール

  • Perl5 is DSL for CPAN
  • Another DSL?
  • Perl6!
    • YAPCでは詳しく話す。
  • Perl6 to Perl5 transpiler
    • like Coffee script
    • With XS hacks
  • Passed 3% in test suites
  • Seis 面白い

LT: Asset Pipeline

Hokkaido.pm の主催者の一人で色々とお世話になっている @aloelight さんによるLT。

  • 複数のJavaScriptやCSSを結合してminifyしてくれる機能
  • Plack::Middleware::Assets::RailsLike というのを作った

主な機能

  • JavaScript、CSSの結合と最小化
  • LESS, Sass/Scssの展開
  • Cache
  • Pre-compile

LT: PDLを使ってみよう

Perl meets beats でおなじみの @techno_neko さんによるLT。

  • http://pdl.perl.org/ で数値計算。行列計算とか。

後半、音がならないとつまらないよね!ということで、PDLで音楽を鳴らしていました。

LT: 気象のお話とか

東京から来た北海道生まれでPerl Beginners主宰の @ytnobody さんによるLT。今回Hokkaido.pm初参加?

  • MetXML という気象情報XML
  • XML::XPath::Diver 書いた
  • Nephia という WAF を書いている
    • JSON API

LT: Riji さわってみた

Hokkaido.pmの常連の一人である @koji_magi さんによるLT。

  • Rijiは @songmu さんが作成したブログ作るツール

懇親会

今回も最近のHokkaido.pm恒例の、17時あがりの17時30分懇親会スタートスタイル。諸事情で少し開始が遅れて18時頃の開催となってしまいましたが、それでも余裕たっぷりです。この余裕が懇親会での気楽さとなっている、そんな気がします。

一次会

でした。もしかしたら「南4条店」のほうだったかも。このあたり、この店のチェーン店が密集していてよく分からなかった。

普段、私は東京にいるにも関わらず、札幌にいたほうが東京の有名人の方々と密にコミュニケーションが出来るといういつもながらの不思議を味わっていました。

@tokuhirom さんとは最初私のほうがたどたどしく会話していましたが、徐々に慣れてきた感じでした。この場で私のトークに対して epoll であったりというアドバイスを頂いて「なんか発表中に指摘しづらかった」とのこと。私のトーク、なんか割り込みづらい雰囲気でもあったのかな…。Dan the Question がしやすいトーク作りを目指そう。

十数人の参加で、結構盛り上がりました。Facebook には Hokkaido.pm のボスである @onagatani さんがアップした写真もあるので、アカウントがあるかたはそちらも御覧ください。

二次会は、活イカがいれば「酒肴酒菜 掌-てのひら-」になるところでしたが最近は活イカが不漁とのことで

となりました。こちらでも盛り上がりました。活イカ食べたかったけど、ここも美味しかった。

三次会は、普段は @onagatani さんが先導してみんなでラーメン屋に行くコースなのですが、@onagatani さんが次の日に社員旅行があるらしく帰ってしまったので、ここで一旦解散となりました。ごく一部の人達で、ノリのよい @itrysd さんに連れられて行ったが以下のお店。

いわゆるすすきのによくあるパブです。ただ、パブの相場にしては安かった。@ytnobody さんと@itrysd さんがひたすら弾けまくっていました。

この後、四次会らしきものもあったようですが、私はホテルへ戻りました。午前3時前。

起床したら午前10時を過ぎていて、午前11時チェックアウトのホテルでひたすら焦りました。お高いホテルを取ったのに、室内を全然堪能できないという残念状態。

この後、札幌から地元とかち帯広へ帰省することになるのですが、それはまた別の機会に書きます。

前日の話

話は逆戻りしてしまいますが。Hokkaido.pm#10 はいつもの Hokkaido.pm のように前日入りしていました。前日8月30日に集まれた一部で、ジンギスカンの食べ放題の店に行ってきました

すすきの駅のすぐ近くにあるビルのテナントでしたが、かなり美味しかった。食べ放題であの美味しさ、その割にはコストパフォーマンスが良かった。ただ、しばらく肉は食べなくていいなー、って感じになりました。年を取った証拠ですね。しばらくは野菜や魚の食生活をしたいです。

前日で、特に私はスライドが出来ていないにも関わらず二次会にも行ってしまいました。

活イカの店ですが、前述の通り不漁で活イカはいませんでした。しんみり日本のお酒を飲んでいました。

この後、ホテルに戻ってスライドの残りを作っていたものだから、一日目も起きたのが遅くなって結構焦りました。

まとめ

今回は @akiym さんが出した「GitHub止まりモジュール」という言葉が一番流行った感じでしたね。その後の発表の人達もみんな自分のGitHub止まりモジュールの事に言及していました。なぜGitHub止まりなのかは色々事情はあると思いますが、CPANに上げるべきタイミングはいつなのか、色々悩むところ多いですからね。私は主にテストが書けないモジュールのアップは躊躇している感じです。

今回も楽しい Hokkaido.pm をありがとうございました。前回 #9 の 3月から半年近い期間が空いてしまいましたが、3ヶ月に1度くらいのタイミングでの開催を期待しています。Hokkaido.pm Casualがあるから補完されているという雰囲気もああるようですが、私に取ってついでに帰省するきっかけにもなるし、どんどん開催して欲しいです!

YAPC::Asia Tokyo 2013 で「mod_perlの展望とApacheの超絶技巧」をトークします #yapcasia

こんにちは、おがた (@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などへお気軽にどうぞ。

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

こんにちは、北海道生まれ北海道育ちで北海道大好きな おがた (@xtetsuji) です。

ブログを書いている3月末から少し時間が経過してしまいましたが、3月9日に行われた Hokkaido.pm#9 に行ってきました。

今回はまとめもUstreamも無いですが、上記リンクからスライドをたどることができます。

前回(#8)は2012年12月末で、フィギュアスケートとSMAPコンサートが重なって、札幌近郊に宿が取れなかったり大変な事になりましたが、今回は穏やかに開催することができました。ただ、全国的に大荒れの天気で吹雪が大変でしたが、それもまた良い思い出。

今回の感想は短めに。スライドについては前述のリンクから御覧ください。

cpanfile

@aloelight さんによるトーク。

Ruby Gemfileの移植であり、依存モジュールの厳密なバージョン定義ファイルであるcpanfileについてのトーク。cpanm や Carton で利用可能とのこと。

cpanfile がどういったものかといったことや、なぜそれが必要なのかといったことは、cpanm や Carton の作者でもある Tatsuhiko Miyagawa さんも書かれています (それの翻訳)。英語ですが、こちらも通読しておくとよいかもしれません。私も勉強します。

私は如何にして心配するのを止めて自分でコードを書くようになったか

@shinotra さんによるトーク。

Hokkaido.pm Casual ではトーク経験があるとのことですが、今回 Hokkaido.pm では初のトークとのこと。それでもかなり好評なトークでした。

実際に作ってみたウェブサービスの話。最近はミドルウェアよりもそれらを使って実際にウェブサービスを作ってみるといった事に興味が集まる傾向にあるのですが、今回も多くの人の興味をひいていました。私も聴いていて楽しかったですし、ウェブで何か作りたいなぁって思わされました。

Games::* – Perlで「ゲーム」しよう

私 @xtetsuji のトーク。

主にペンシルパズルをPerlで解くためにCPANモジュールを使ったり、またゲームとは何かといった哲学的トークを後半に入れた構成でした。

今回は反省材料が多かったです。誤解を与えるような表現があったり、リスペクトのつもりがdis(ディスリスペクト)になっていたり、ネタやギャグがことごとく滑ったり…;。一応記録として、トークを除いてスライドだけ見ると誤解を受けたりする部分を修正した版のスライドをアップしました

個人的な反省項目については下の方に書きます。

最近使っているモジュールの話

JPA招待ゲスト @xaicron さんのトーク。

最前線で活躍している人がいったいどういう環境やモジュールを使っているのかというのは、意外に興味深いところです。「CPANソムリエになる方法」。

上記リンクから、完成版スライドが閲覧できるので、Perlを勉強中の方々はぜひとも目を通して、今の流行りどころはどのあたりなのかといった部分を感じ取ってみると良いと思います。私も最前線を追っかけるのが苦手な人間なので、非常に勉強になりました。

LT

  • @hiratara さん「CurryとHokkaido.pm」
  • @techno_neko さん「PureDataをPerlで鳴らしてみる」
    • YAPCやWEB+DB PRESSでPerlの音職人として名を轟かせている@techno_nekoさんによる新作。今回はTerm::ReadKeyを使ってキーボードをピアノのように打つことで音を出したり、さらなる進化を遂げていました。
  • @xaicron さん「BigShip」
    • Cinammonのクローン「BigShip」のトーク。スライドは無し。違うところはパラレルで動いたり、複数のサーバへばらまけたり…;。
  • @charsbar さん「Quality Assurance Hackathon」
    • QA Hackathon に行って CPANTS のメンテナンスをしてくるといった話。
    • 検索機能に関連してGroongaの話も出てきました。

懇親会

春花秋灯 南四条通り店

17:30開始が好評となったので、今回も17:30開始となりました。

二次会

酒肴酒菜 掌-てのひら-

二次会の場所としては、前回 Hokkaido.pm#8 のときと同じ。活イカ好きの @onagatani さんオススメの場所。

しかも個人的に前日札幌入りした夜に行った二次会もここでした。活イカ三昧ですけど、美味しいから満足。

三次会

らーめん 信玄 南6条店

折りしもの吹雪で人々が散ってしまって、一部の人だけで少し遠方のラーメン屋まで歩いてラーメン食べました。今回はいつも恒例の「すみれ」では無かった。気づかないうちに @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だけで重い処理を行うにはどうすればよいか

自称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なりテキストなりのアウトプットが完了した時点だと思います。そうでなければユーザに完全なレスポンスを返さずに長時間作業に入ることになってしまい、ユーザはブラウザの前でイライラすることでしょう。

これで問題解決…;と言えるかもしれませんが、いくつかの問題もはらんでいます。

  • この system($cmd.’&’); が呼び出されるアクセスが大量にやってきた場合、全ての子の数(たとえばprefork MPMの場合、MaxClientsの数)以上のアクセスが $cmd の長時間処理にかかりっきりになったら、それ以上のHTTP応答ができなくなる。
  • ユーザに返したいレスポンスを全て返した(HTMLであれば”</html>”までとか)としても、ブラウザはそのHTTPリクエストのレスポンスをたぶん待ち続けるはず。ブラウザがHTMLドキュメントの終了を推測できてDOM解析を完了できたり、KeepAlive等のタイムアウト設定で接続が切れることで、表向きは問題無いように見えるけど、処理としてはエレガントではない。

これをmod_perlだけで解決するにはどうすればよいでしょうか。

ネタ元ツイートの方は exec が CORE::exit と同等 (Apacheの子プロセス自体を終了させる) と言及していますが、実際の exec の挙動は一般的に「現在のプロセスを他のプロセスで置き換える」事です。execはexitと違い、mod_perl側が *CORE::GLOBAL::exec をいじるなどのサポートは行っていないので、元のexecそのものの挙動になります。preforkされた該当の子httpdは $cmd で定義されたコマンドに置き換わり、親から見たら子は突然消えたことと同じことになり、子が設定値的に足りなくなれば親が充足してくれます。ただ、以下の問題があります。

  • mod_perlハンドラhandler中で正規の処理を終わらせていないので、クライアントから見たら接続先のHTTPサーバが突然見えなくなるという乱暴な事になる (大きな問題ではないと思いますが)
  • ログ処理フェーズへ子プロセスが進めないので、当然ながらログが書かれない

前者は少々乱暴でも良いとは思いますが、ログが書かれない事を望むウェブ開発者はいないでしょう。

これら全てを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入門」を参照すると良いと思います。

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

こんにちは、北海道生まれ北海道育ちの おがた (@xtetsuji) です。

2012年12月23日に行われた Hokkaido.pm#8 に行ってきました。

その他、2012/12/30 現在でアップされている参加者の皆さんのレポート。

私のレポートよりも参考になると思います。

今回のHokkaido.pm#8は

  • 2012年も年の瀬
  • SMAPのコンサートと時期が重なった
  • フィギュアスケートと時期が重なった

などの理由により参加者が少なかった・参加者が参加に苦労した回でした。かくいう私も、普段は普通に(懇親会の会場となる)すすきのに宿をとるのですが、すすきのどころか札幌駅近郊のホテルがのきなみ満室で、僻地恵庭に宿をとることになりました。

以下、発表、LT、懇親会レポートなどをつらつらと書いていきます。

MojoliciousをPerl5.8で使えるようにする

@jamadamさんによる発表。

前回(#7)の発表から特段新ネタは無いとのこと。スライドは早々に終了して、以後はライブコーディングというかライブメンテナンス作業を見せるという斬新な光景になりました。会場提供のWi-FiではGitHubにアクセスできない等トラブルもありましたが、面白かったです。

プログラマーと仕事 → XSにまつわる話

JPAからいらっしゃった@typesterさんによる発表。

この「XSにまつわる話」はスライドがSpeakerDeckにアップされており、@akiyamさんによる詳細なレポートがあるので、そちらをご覧になると良いと思います。

XSとは何かという話から、実際に@typesterさんがXSを始めることになった話から、XSの初歩まで、盛りだくさんんで非常に参考になりました。「あぁ、XSってこういう時に使うべきなんだ」って、改めて実感がわきました。「高速化」というのはあくまで黒魔術師がやることであって、本来はCで書かれたライブラリを低コストで呼ぶものだということなど。

  • XSに手を出すまで→XS食わず嫌い期
  • lestrattさんとかgfxとか会話意味不明だし難しそう…;
  • iOSアプリのためにCでAMF/RTMPパーサーライブラリを書いた
    →これをXS化したい
  • * Data::AMF::XS
  • XSとは
    • Perlと外の世界をつなぐ物
    • XSで高速なPerlプログラミング!っていうのは異端 (e.g. Mouse, Text::Xslate)
  • 普通の人は、まずライブラリを普通に書いて、それをXSでバインディングを作れば良い
  • 普通の人はXSで書いても高速化しない。
  • XS書くのに必要なもの
    • ターゲットライブラリの使い方(C/C++とかの知識も含む)
    • *XSの知識その1、XSのマクロたちの使い方
    • *XSの知識その2、Perl<=>Cのデータ変換
    • ターゲットライブラリの使い方(@typesterさんの場合) *iOSアプリケーションの開発が大きい
  • Cocoa APIは慣れた物
  • libmsgpack, libev, libuv とかもアプリからよく使う
  • XSの知識その1
    • XSマクロの使い方(.xs内の構文)
    • ST(N)とかXSRETURN(N)とかのマクロ
    • perldoc perlguts
  • XSの知識その2
    • Perl<->C
  • XSモジュールの作り方
    • Module::Insta::XSUtil or Module::Build::Pluggable::XSUtil を使うと非常に簡単
    • 後者は使ったこと無いけど次のモジュールで使おうと思います
    • M::I::XSUtil
    • gfx作 2010年のAdvent Calendarに載っている
  • DEMO: DISCOUNT Cで書かれたMarkdown変換ライブラリ
    • 型変換を自動でやってくれる仕組みがあるのでそれを使うとコード量が減る。
  • XSでObjective-C
  • 二つ方法がある
    • *.xsをかかずにxsubppで生成されたcファイルと同じ形式のファイルを.mで書く
    • *.xsでObjective-Cを書き、xsubppで変換された.cファイルを.mにリネーム
  • *Hacking Mac Cocoa API from Perl (YAPC::Asia 2011)
  • MacRuby的なの?
    • PerlでMacアプリが書きたいわけじゃなく、PerlでMacの機能にアクセスしたいだけ
    • PerlでObjective-Cの構文を表現したりとかするとカオスになるのは目に見えているし
    • 単機能をPerlの流儀で使える単体モジュールにしていったほうが良い
    • Objective-C自体もLLっぽいし、メモリ周りはPerlといっしょ(refcount方式)だし…;
  • まとめ
    • XSはPerlを外の世界とつなぐもの
    • Perlの世界と対象の世界、両方の知識が必要(両方の知識がある人には夢のツール)
    • Perlしかしらないけどあのライブラリ使いたい!ってときは、そのライブラリ使える人に頼む
    • 自分でそのライブラリを勉強しつつかく
    • XSからCを勉強してもいいんじゃない?
    • 牧(dmaki)さん、0mqさんのXSコードは綺麗で参考になる
    • 基本、一回書いたらコピペが多い

PM運営について

Hokkaido.pmのボス(?)@onagataniさんによる発表。

次回は3月初旬開催予定、というか確定。

@onagataniさんだけでは負担。運営やりたい人いる?→@aloelightさんにお願い。

次回はJPAから@xaicronさんが来てくれることになった。

未来をつくるプログラム

引き続き@typesterさんによる発表。

こちらは先ほどのXSのトークとは違ってスピリチュアルトーク。勇気づけられました。

  • 未来をつくるのは技術者
  • せっかくプログラマーになるなら”未来をつくるプログラム”を書こう!
  • 仕事と趣味の話 (収入を得る得ない、人生を賭ける賭けない)
  • シェアタイム
  • アイデアは常に考え続ける →習慣になっていないとできないこと
  • 技術は常に磨く →今できるのか、それとも少し勉強すればできるのか
  • ハックの精神 →ちょっと自分の周りを便利にするの大事
  • ロールモデルをもつ →一人だと難しい
  • ライバルをもつ →こいつには負けたくない
  • 仲間を持つ →一緒に何かをやってくれる人
  • 下に行くほど難しい
  • ロールモデルの人物
    • Tatsuhiko Miyagawa
      • 日本のPerl界のカリスマ
      • つくるもののセンスがいい
      • 速い
      • ログ記事からハック精神に溢れている
    • Brad Fitzpatrick
      • Livejournal
      • Memcached, Gearman, TheSchwartz
      • 自分のサービスのために自分でミドルウェアを作る。
      • Androidガレージ開け、双子の名前アナグラム提案など。
    • Mat S Trout
      • DBIx::Class
    • Marc Lehmann
      • AnyEvent, libev, libeio
  • ライバルの人物
    • Masakazu Ohtsuka
      • こえ部, ナカマップ, Wonderfl, jsdo.it, 写真袋
  • 仲間の人物
    • Shunichiro Fujiwara
      • 信頼のインフラエンジニア
      • ISUCON二連覇
      • チャレンジングだけど不安な事にダメ出しをしてくれる。だけど保守的ではない。
  • プログラマという仕事に誇りを持って!

サルでもわかるOAuth2

@zigorouさんによるトーク。

非常に詳しいトークでしたがテンポも早く、手元のメモそっちのけで聴いていました。こちらはUstreamによる録画があるので、そちらをご覧頂くのがよいかと思います。@zigorouさん自身も、スライドが完成したら公開するとおっしゃっていたので、それを期待しましょう。

LT

  • @__papix__ さん
    • 25歳
    • モジュール作ってみた
    • Module::Setup
    • テストも書く
    • PODを書く
    • Makefile.PLを修正する
  • @moznion さん →スライド
    • 2年前まで道民
    • 学生
    • 数値計算
    • テスト大事
    • テストの書きやすさマジ重要
    • (トーク非常に素早かったです)
  • @techno_neko さん → スライド
    • 名前付き引数のお話
      • 順番で渡す
      • ハッシュで渡す
      • ハッシュリファレンスで渡す
    • Hokkaido.pm Casual
    • ベストエルティニスト
  • @koji_magi さん →スライド
    • Kokusaitenjijoumae.pm
    • リア充爆発しろ
  • @akiym さん →スライド
    • Perl5.18予想
    • state sub, my sub, our sub
    • Perl5.17時点での予想なのでPerl5.18では変わるかも
  • @xtetsuji →スライド
    • スピリチュアルトーク
    • Hokkaido.pmのおかげでYAPCでトークできた
    • ありがとうHokkaido.pm!

懇親会

鶏屋とことん

前回好評だった、本会終了から時間を待たず17時30分から飲み始めるパターン。

今回はすすきの移動ではなく、東札幌駅近くの居酒屋での開催となりました。料理が美味しかった。

本会は参加人数は少なかったですが、そのほとんどの人が懇親会にいらっしゃっていて、非常に密に盛り上がれたと思います。これはこれで楽しかったー。

二次会

酒肴酒菜 掌-てのひら-

外はすっかり吹雪いていましたが、タクシーですすきのに移動して @onagatani さん推薦の活イカの店でイカや日本酒を堪能。これまた美味しかった。

三次会

すみれ 札幌すすきの店

お決まりのコース、すみれでラーメン。

23時30分ごろには解散。

その後

今回はすすきのに宿が取れなかったので、地下鉄とJRを乗り継いで恵庭のホテルに帰ることになりました。ただ、JRで2駅寝過ごしてしまって恵庭で降りられなくて、タクシーで戻ることに。1800円くらいの痛い出費をしてしまいました…;。SMAPとフィギュアスケート…;。

写真は外部リンク(Twilogや4sqなど)から参照してください。現在写真整理中…;。「顔出しNGの人いますかー?」って聞かなかったなぁ、そういえば。今回は下手ながらコンデジで頑張って写真を撮ってみたのですが、無難に限定公開できる場所に公開できればします。

まとめ

今回はガチ技術論というよりもスピリチュアルなトークや概論的な話が多かったような気がしましたが、聴いて奮い立たされる話が多くて面白かったです。

いつも来る人が来れなかったり、参加者が少なくもあったのですが、これに関しては時期的にもアレ的にも仕方がなかったです。3月開催予定のHokkaido.pm#9に期待です。よほど避けられない予定がなければきっと行きます。

「モダン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日(金)を予定しているとのことです。隔月開催なのかな。非常に有意義な勉強会でしたので、次回もぜひ参加させていただこうと思います。

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

こんにちは、最近は積極的に勉強会の類に参加してみようとしている おがた (@xtetsuji)です。

いつもブログが遅筆ですみません。記事を書いている段階では一週間前の2012年3月24日に行われた「Hachioji.pm#15」に参加させていただきました。私は中野区在住で八王子駅まで片道1時間弱。移動の負担は首都圏的感覚だとそれほどでもなかったです。

東京在住なのに、地元が北海道という縁でHokkaido.pmには2回参加+トーク発表をしたものの、今回初めて関東圏の地方.pmに参加させていただきました。まぁ、YAPC::Asia Tokyoは2007年から行っていますが、地方.pmのような大規模でないイベントのほうが各人の交流がしやすくていいなとは、Hokkaido.pmの参加のときから思っていました。その思いを膨らませて、今回Hachioji.pmに思い切って初参加した次第です。

このイベントの前の朝から夕方までに行われていた「Like a ハッカソン」は参加してみたかったものの、あまり体調が良くなくて長く作業すると疲れが出て後日に響いてしまうコンディションだったため、興味はあったのですが今回の参加は遠慮させていただきました。

参加前に参加要件を見ていたのですが、「一枚LT」とか聞いたこともないものが要件にあったりして、検索してみたら「模造紙でプレゼン」とか出てきたりして、文房具店に行く時間も無いし一枚に自己紹介と課題である「スマートフォン」の話をどう書けばいいんだろうとか、いろいろ考えてしまって結局準備をせずに向かったのですが、模造紙云々はどなたかのネタらしく、みなさん普通にプレゼンテーションアプリケーションを使った数枚のスライドのプレゼンテーションをされていました。

「Like a ハッカソン」とは違い、本イベントである「Hachioji.pm#15」自体は、どちらかというと飲食店に集まって飲み食いしながら技術のお話をするというのがメインのようで、お酒が入った状態でざっくばらんに最近の技術動向について情報交換ができる、気軽な場所でした。

「Like a ハッカソン」を含めた「Hachioji.pm#15」の詳細は、Hachioji.pmのブログ記事やそこからリンクされたページを参照していただけると、私の記事より良いものがあります。

個人的にざっくばらんな会話で感じたのは、一人でネット上の情報を見ていても「流行り」はたくさん流れてくるけど、「廃り」といったことは実際に対面でお話をして動向のお話をしないと見えてこないということでした。確かにネットで「廃り」を宣言したりすると、その作者やそれの愛用者の目にとまったときにdisられたとか反感を買うので書きづらい部分はあるんだと思います。今回も「jQuery UIはダメだね」とか、それぞれの方々の思う「廃り」の印象のお話が聞けて面白かったです。

初参加で一人八王子までやってきて、会場のペルー料理店MISKYに「こんばんは〜」と入ってきたのですが、ネット上で存じていた方や、YAPC::Asia Tokyoでお会いした方(@ytnobodyさんとか)もいらっしゃって、向こうはこちらの顔なんて覚えていないだろうなと思いつつも、空気を読まず「いやー、お久しぶりです」とか言って場に馴染もうとしてみました。

初参加なのに30分くらい遅刻をしでかした私でしたが、その後に遅れて@maka2_donzoko さんがやってきて、課題の「スマートフォン」に引っ掛けて「すあま」と「本」を持ってきました (参考: ご自身によるブログ記事)。すあま、あまり馴染みのないお菓子でしたが、かなり美味しかったです。自分好み。

すあま

いただいた すあま の写真。美味。

「まかまかさん」こと@maka2_donzoko さんは、PerlのAcmeモジュール同人誌「Acme大全」やPerlモジュールを題材にしたカードゲーム「Parumon」の作者でもあります。YAPC::Asia Tokyo 2011で「Acme大全」は購入できたのですが、売り切れで入手できなかった「Parumon」を、なんとこの場で売ってくださいました!ありがとうございます、まかまかさん!

Parumon

「Parumon」は、Hokkaido.pmの何名かが購入をして、プレイ風景をリアルやネットで見たりしていたのを指をくわえて羨ましがっていた状態だったので、非常に嬉しかったです。会社でもちょうど3月に開発者が一名入社してPerlの勉強をしてもらっているところなので、教材としても使っていきたいです。

飲み食いが一段落したところで、皆さんの「1枚LT」が開始されることになりました。詳しくは上述のリンクに譲りますが、みなさんタイトルの「1枚」とかお題の「スマートフォン」に縛られないLTを繰り広げられて、これでいいんだって感じました。皆さんのお話はどれも興味深いものばかりでした。

Hachioji.pm#15の開催者である@uzullaさんがとても精力的な方で、そこから繰り広げられる話の数々を拾うだけで、とても有意義でした。PHPerを何度も自称しながら、それなのにPerlイベントを主催しているとか、ジョークも数々。楽しかったです。

本当にいろいろな話題が出て、すべてを拾いきるのも、ここで思い出して書くのもなかなか大変なのですが、スマートフォン向けのjQuery互換軽量JavaScriptモジュールzepto.jsは本当に名前も知らなかったので、jQueryで作ったスマートフォン向けサイトをzepto.jsで置き換えできないか、考えてはじめています。また、スマートフォン開発に詳しい方が数名いて、Androidアプリ内課金の大変さを説いていたのも印象的でした。私も最近Android アプリ内課金案件を抱えていたので、もっと詳細を聞いておけばよかった、とも後で思ったのでした。

その他は、上述のHachioji.pm自身による記事からたどっていただけると、興味深い話題が多かったことがわかると思います。

「Like a ハッカソン」もそうですが、予定や体調が許す範囲で、次回以降の「Hachioji.pm」にもぜひ参加してみたいと考えています。まだまだ新参者感が抜けない私ですが、Hachioji.pmの皆さん、今後ともよろしくお願いします。

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

2011年12月10日に行われた Hokkaido.pm#6 に行ってきました!

書こう書こうと思いつつ、うっかりこれを書いている日(2011年12月28日)から2週間以上経ってしまっていることに気づいて、「今年やり残したこと」にならないように慌てて書き始めた次第です。本当に遅くてすみません。

前回の Hokkaido.pm#5 に参加したときと同様、今回も東京から札幌へ遠征しました。前回の #5 では「mod_perl温故知新」と銘打った発表を行いましたが、手持ちのモダンPerlな面白い話が特に無かった自分は、今回もmod_perlネタを持って行きました。

YAPC::Asia Tokyo 2011 の gihyo.jp レポートでも、とてつもない速度でレポートを投稿していった @hirataraさんによる「今日は Hokkaido.pm#6 の日です」が前回同様、非常に良いまとめとなっています。本当に迅速にまとめが出来る方には頭が上がりません。また、Hokkaido.pm の Ustream チャンネルには、当日の録画もあります。

以下、各トークへの私なりの感想です。内容については上述のリンクをご覧いただくといいと思います。

@aloelightさん「Carton使ってみた」

モダンPerlの技術を常に追っていらっしゃる、@aloelightさんのCarton話です。→スライド

YAPC::Asia Tokyo 2011 でも、作者である@miyagawaさんが発表されていたCartonでしたが、一日目の午前中だったため、なんだかあの時は会場入るまでバタバタしていて、午前中のトークがあまり頭に入って来なかったんですよね。一日目の午前中は重鎮ぞろいだったってのもあるけど。なので、今回のトークはとても参考になりました。

本人は「簡単すぎて話す事がない」とおっしゃっていましたが、本当に簡単なのかも。まだいじっていませんが、年末年始の休暇中にでも perlbrew の箱庭環境で試してみることにします。パッケージのアンインストールにも対応しているということも改めて知りました。さすが、cpanmより進化しているんだなぁ。

個人的には@aloelightさんと同じ(今の日本でははてブにおされ気味の)Deliciousユーザの私は、@aloelightさんが開発したTweet::ToDeliciousをCartonで動作させるデモが興味深かったです。手元ではpfswatch等も使わせていただいていて、個人的には前回(#5)から色々声をかけていただいたりしてお世話になった(と勝手に思っている)@aloelightさんからは目が離せませんし、その活動をぜひ見習いたいと思って仕方がありません。

▼@akiymさん「botのつくりかた」

Hokkaido.pmが誇る高校生ホープ、@akiymさんのbotのお話です。→スライド

「高校生はIRCを使わない」「高校生はSkypeを使う」という出だし。確かに、IRCは会社とかにいる古い大人が先導して使う道具のようでもあるし、大人数になってワイワイしたいときにこそ真価を発揮するものだよなぁ、と思ったり。そういうわけで、Skypeボットの作り方を…という話の流れでした。

Windows と Linux にはそれぞれモジュールがあって、Skype API を叩くことができるのですが、モジュールがバラバラなので Skype::Any というモジュールを作ったという話。

Mac には同様の Skype API を叩くモジュールは無いようで、Cocoa と対峙しないといけないなぁ、といった話が繰り広げられていました。でも、@akiymさんなら近いうちに何とかしてくれそう、という期待も持っています。

@akiymさんのトークを聴講するたびに、2011年の高校生は本当にすごいなと思わされます。いや、@akiymさんが特に優秀だということは分かっているのですが。自分が2011年に高校生だったらどうなっていただろう…、と思わざるを得ません。

@nekokakさん「Clutch – distributed job system」

既に Perl Job Queue の先鋒として Qudo や Jonk など数々のプロダクトを世の中に出している@nekokakさんによる Job Queue の話。→スライド

Job Queue と Message Queue の違いの話は、今まで多少は気になっていたもののよく分からなくて放置していたのですが、実際に学術的な違い以上のことは考えなくてイイということが知れてよかったです。

Job Queue や Message Queue 等、要所要所で「使っている人いますかー?」というアンケートをされていましたが、手を挙げられずすみません…。会社でも Job Queue や軽量ORMを推進していこうとしているのですが、なかなかうまくいかず。まぁ、会社の主力製品も大規模で、おいそれと新しいものを入れるわけにいかないという言い訳もあるのですが…。来年2012年は個人プロジェクトを立ち上げる等して、そこで@nekokakさんプロダクトを入れていきたいなぁ、と思っています。

@xtetsuji「mod_perl hacks PHP」

はい、私の発表です。感想というか反省点やフォローなど。→スライド

スライドにも書いてありますが「モダンPerlに乗れていない」という通り、あまり手持ちのモダンPerlネタで話せるものもなく(POEの置き換えとしてAnyEventを最近いじり始めたり等してはいますが)、@aloelightさんのツイートにも後押しされて今回もmod_perlネタにしてみました。

まずはタイトルを決めて内容を考えていったのですが、正直タイトルを申請したところで「ちょっと大それてやいないか?」「PHPerに発見されて怒られたら嫌だなぁ」という思惑が頭の中をよぎって、トークの最初は言い訳みたいなものが続くことになってしまいました。

PHPも良いし日々お世話になっている。けど、世間で発注して納品されるPHP製品は残念ながら決して品質の高いものばかりでは無く、既に誰も保守していないPHPに手を加えて機能追加をしないといけない悲劇、また製品保守をしてもらったとしても契約などの縛りで手を加えることができない大人の世界のジレンマもあったりする、といった背景を打ち出してみました。

内容は「PHPに前処理をはさむ」「PHPに後処理をはさむ」の二部構成にしてみました。前処理も後処理も色々な、それこそApacheモジュールでできるあらゆることができるのですが、興味を持ってもらえるテーマは何だろうと考えて、前処理は認証周り、そして後処理は出力フィルタ周り、といった部分を話すことにしました。

「前処理」の認証周りについては「Cookieを読み書きできるからPHPの認証を捨て去ってPerlの認証を入れたり、既存サイトとSSOできるよ!」といったコンセプトを言うだけで、デモを作る時間がありませんでした。本当ならCPANモジュールのApache2::AuthCookie等を使ったデモを見せられれば良かったのですが、持ち時間の20分だとコンセプトの発表にとどめておいて正解でした。前処理といえば、PHPer御用達(今もそうなのかはわかりませんが)のmod_rewriteをPerlTransHandlerで置き換えるといったお話も興味を引くかと考えましたが、それは前回発表したし、トークという場では無い、ブログなどでまとめてお話が出来ればいいなと思って、完全に割愛しました。

認証周りをやると、画面に「〇〇さん、こんにちは」みたいなモノを出したくなるのでは?といった疑問にこたえるべく、Apacheノートについてお話しようと思ったのですが、時間がなく盛り込めずでした。そもそもデモすらしませんでしたからね。AuthenやAuthzのフェーズで認証をしてDBからユーザ名 $username を引けた場合、$r->notes->set( username => $username ) などとして、Apacheノートに記録することができます。これによって、フェーズ間で情報のやり取りができます。少なくともApacheモジュールで動作するPHP(mod_php)にはapache_note()という関数があり、mod_perlから渡したApacheノートを取り出すことができます。これによって、PHP側で認証をするほどの労力を使うことなく、「〇〇さん、こんにちは」を実現することができます。PHPソースコードの改変が必要にはなりますが、最低限で良いというのがメリットです。文字コード等はよしなにお願いします。

「後処理」は、出力フィルタ、ログ、クリーンナップ、と数えるほどしか無いのですが、Apache2から導入されたネイティブの出力フィルタをmod_perlから使う話は面白いのではないかと思って、今回取り上げさせていただきました。本当は出力フィルタの話は結構複雑なのですが、Bucket BrigadeとかそういったApache専門用語は使わず、ソケットから丸呑みして書き換えてやれ、といった20分トーク仕様にしてあります。後処理は簡単でもいいからデモをしてみようと、初デモをしてみました。Pukiwikiの出力を書き換えるというデモでした。本当なら、ドコモ端末から絵文字入り投稿をしたページをソフトバンクで見たらEncode::JP::Mobile等を使ったmod_perl出力フィルタが絵文字変換をしている、といった嬉しいデモを見せたかったのですが、Pukiwikiにドコモ端末から絵文字を投稿したら丸々文字化けしてしまって愕然となり、発表直前に諦めざるを得ませんでした。結局、出力に特定のキーワードがあったらそれを大文字にするとか、簡単なデモで済ませてしまいました。

「時間がかかる処理はまずユーザに画面を出して、実際の処理はJob Queueに任せる」といったものがモダンPerlの鉄則ですが、prefork MPM Apache + mod_perl を使った安上がりな解決方法として、クリーンナップフェーズで処理をする方法があります。そうすれば、ユーザに画面も出してログも書いた後、数十秒かかる処理でも気にすること無くApacheが処理をすることができます。ただ、かかる時間やそのような処理の発生頻度が高い場合には、クリーンナップフェーズで処理をしているApacheが溜まってリクエスト受付処理ができない場合があります。その場合はクリーンナップフェーズで必要な処理をする別プログラムを用意してexec()して処理を移譲してしまえば、そのApacheは消えていなくなってしまい、Apacheの設定に伴って必要があれば親から新しい子プロセスが供給されます。ただ、この場合はexec()のコストも考えないといけないので、これも良し悪しかな。

懇親会までの間に複数の方から「mod_perlを使うとApacheが太りませんか?その対策はどうすれば?」といった質問を受けましたが、こればっかりはどうしようもありませんね。ハードウェアにメモリを潤沢に乗せるか、Apacheの設定MaxRequestPerChildを小さめに設定する、Apache::SizeLimit (mod_perl1)、Apache2::SizeLimit (mod_perl2) を使って太り過ぎて支障が出るほどのApacheに退役してもらう作戦くらいしか回答できませんでした。

関係ない話で熱く語って長くなってしまいましたが、この熱意をトークでも出した「日本mod_perl改造計画」につなげていきたいと考えています。

mod_perlバカと思われている私ですが、まだまだ使ったことのないmod_perlの機能は沢山あります。Plack/PSGIの登場で使いやすいWAFが登場して、特定のウェブサーバに依存せず簡単にウェブアプリケーションを作ることができる嬉しい時代ですが、こういったPHP等の他言語との連携をする場合に、最もシェアの高いApache上で動くmod_perlの「魔法」を使って助かったという人が、私の活動をきっかけに一人でも出てきてくだされば本望です。

@hirataraさん「循環参照のはなし」

冒頭でも触れた、最速でHokkaido.pm#6をレポートしてくださった@hirataraさんによる、循環参照のお話です。→スライド

出だしで、私の冒頭の言葉を拾ってくださって「私もモダンPerlに乗れていない…」と@hirataraさんがおっしゃったときには「いえいえそんなことはー!」って言いそうになってしまいました。Ustreamされているので、さすがにその場では言いませんでしたけど、懇親会で「恐れ多いです」とはお伝えしました(笑)。

循環参照。結構Perlを書いていれば誰しもが知ることになる言葉ですが、普通にコードを書いていればあまり出会わないものと思っていました。ただ、昨今は非同期・イベント駆動フレームワークでサブルーチンリファレンス・コールバックが多用され、そうった状況下で循環参照が発生しやすいといったお話は、非常に参考になりました。さすが AnyEvent 等を極めている@hirataraさんだけあるなぁ、と非常に感心してしまいました。

Perlユーザであれば、昔からの標準モジュールScalar::Utilにあるweaken()でどうにかなるんじゃないの?といった部分についても、そう単純にはいかないよといった話があって、循環参照って古くて新しい、結構難しい問題なんだなと思った次第です。

@onagataniさん「YAPC::Asia Hokkaido 実現に向けて」

以前から開催が計画されていた YAPC::Asia Hokaido 実現に向けての計画を、Hokkaido.pm 代表の @onagataniさんがお話されました。→スライド

当初はLTでのトークの予定でしたが、時間が余ったのでこの枠に移りました。結果15分ほどのトークとなったので、ちょうど良かったのだと思います。

「Hokkaido Perl Workshop」などいくつか名前が提案されていましたが、このトークで「YAPC::Asia Hokkaido」という言葉が正式に打ち立てられたと思います。北海道出身者として、YAPC が北海道で催されるのであれば、これほど嬉しいことはありません。

ただ、トーク後の質問等でも出ましたが、どの時期に開催するとしても何らかのイベントと大抵ぶつかる事や、初の東京以外でのYAPC開催への不安、様々な見積もり、会場をどうするか等、これから解決していかなくてはならない問題は多そうです。

私は東京在住の身であり、実働部隊のスタッフとしてお手伝いし難い部分もありますが、早速 Google Group に加わらさせていただきました。可能な支援は積極的にしていこうと考えています。

LT

  • @sugyanさん「たのしい記号Perlプログラミング」
    拡張正規表現を使えば7つの記号だけでプログラミングができる!→排他的論理和を活用→Acme::HeptaSymbolize→画像からHello! World.が作れるよ。→かわいいアイコンと北海道でデモ
  • @koji_magiさん「困ったときのAcme::*」
    最近お祝いする人ができた→Acme::Omedetou→ひたすら画面におめでとう→「Hokkaido.pmに参加すると嫁ができる」
  • @techno_nekoさん「GUIアプリに必要な3つのこと」
    「人見知りの人こそ、スピーカーになって話しかけてもらう」→GUIは痒いところに手が届くことが大切
  •  @nekokakさん「Object::Container::Exporter」
    飛び入りLT参加(すごいです)→Object::Containerはシングルトンにオブジェクト管理用モジュール→Object::Container::Exporterはimportやnew等、さらに色々なことを行ってくれる
  • @charsbarさん「YAPC::Asia Hokkaido 実現に向けてへの補足」
    飛び入りLT参加→直前の@onagataniさんの YAPC::Asia Hokkaido 実現に向けてのトークについて、 このスケジュールだと海外のコレとかぶるよ、といったアドバイス。

雪駄で関東からいらっしゃった@sugyanさんのLTは、Yokohama.pmのUstreamで以前拝見したもののパワーアップバージョンでした。面白い。@koji_magiさんのAcme::Omedetouといい、Acme::*は本当に楽しいPerlの文化です。

@techno_nekoさんが主張する「人見知りの人こそ、スピーカーになって話しかけてもらう」は、私自身が今年実感したことです。枠とネタがあるのなら是非しゃべるべき。そうすれば、人見知りで人に声をかける勇気が必要な方でも、話しかけてもらえます。

飛び入りでLTをするという@nekokakさんと@charsbarさん。さすが熟練者だなぁと思わずにはいられませんでした。また、様々な国内・海外の動向を把握している@charsbarさんはスゴイなぁと感じました。

その後

余剰時間を使うことなく完璧に時間通りに終了し、結構余った時間をロビーで過ごしつつ、懇親会の時間が近づいてきたら数人でタクシーをつかまえて、懇親会の会場へ移動しました。その間、外に積もった雪にはしゃぐ@sugyanさんや@nekokakさんを見て皆さんで楽しんでいました。

懇親会

関数型都市忘年会との合同忘年会でした。テーブルはHokkaido.pmと関数型都市で分かれていて、向こう側のお話は難しくてついて行けなかったので、私は主にHokkaido.pm側の席でいろいろな方とお話をしていました。

今回、取材でいらっしゃった@ya_k0さんから、著名な某ハッカーの素性を拝聴したり、YAPC::Asia Tokyo 2011 でお会いできなかった@hirataraさんと初めておしゃべりをして「モダンPerlに乗り遅れているのは私だけですよー」などと話しかけたり、同じ数学科出身という共通項で勝手に盛り上がってお話をさせていただきました。

その他にも、YAPC::Asia Tokyo 2011以来の再会となったスカイアークシステムの方々を初めとした北海道勢の方々と改めてお話をしたり、気がついたらParumonで盛り上がっている@aloelightさん達を見て羨ましく思ったり、美味しい料理を食べたり、本当に楽しい懇親会となりました。

ここまでお話、特に懇親会の雰囲気については、以下の @ya_k0 さんのブログのまとめが秀逸です。写真が上手い!

私も乾杯のシーンで笑顔を写真に出しています。また、酔って口から出た発言も拾われちゃっていますね。あはは。

二次会

懇親会終了で関数型都市とは分かれて二次会へ。Hokkaido.pmは@onagataniさんが先導して、見つけたお店に入ってみたものの、最初のうちは混雑していてぎゅーぎゅー詰めにされて大変でしたが、後半は客が引いて余裕が出来たスペースを勝手にHokkaido.pm勢が占拠して、事なきを得ました。

初参加という@jamadamさんに、今回の私のトークを褒めていただいたのは嬉しかったですね。レガシーPerlもまだまだ健在だし、一から自分達の自由に作れる会社よりも、ボロボロの製品の保守を引き受けたりコンテンツ移管をしたりといった事のほうが世間では多いんじゃないかとか、そんな話。私の会社もそんな時期があったからこその今回の私のトークだったので、今も一人開発者として奮闘している@jamadamさんと意気投合して、途中から@onagataniさんも入って一緒に楽しく語らいました。

あ、一人開発者って、自分の今の会社での立ち位置も似たようなものじゃん!会社では開発者の求人も募集しているので、そちらもよろしくお願いしますね。2012年はみんなでワイワイ開発したいなー。

まとめ

今年は5月の@onagataniさんとの出会いから、トントン拍子に7月の Hokkaido.pm#5 に初参加+人生初トークとなり、12月の今イベント Hokkaido.pm#6 も参加+トークという、非常に充実した一年となりました。GitHubやCPANに動く有用なものをアップするまでにはまだ到達していませんが、トーク活動共々、実際に動く有用なものを世の中に出していくことも来年2012年の目標にしたいと、Hokkaido.pmに意欲と情熱を貰った一年でした。

今回も長文となってしまいましたが、ここまで読んでいただいた方、ありがとうございます。

「YAPC::Asia Tokyo 2011」 #yapcasia に行ってきました

タイトルの通りですが、2011年10月13日(は前夜祭)、14日(1日目)、15日(2日目)に行われたプログラム言語Perlのカンファレンス「YAPC::Asia Tokyo 2011」に行ってきました。

このブログ記事を見る方は「オマエ誰?」という方がほぼ大半だと思うので、私とPerl/YAPC周りの関わりを3段落で書いてみます。

  • 30代男性。aka @xtetsuji。地元北海道で18年、大学で上京、東京で今の会社に就職して8年、今に至る。
  • YAPCは2007年から毎年参加。毎年聴講のみの一般参加だったけど、ついに今年念願の自社がYAPC協賛スポンサーに!今年はそのスポンサー枠で参加。fonfunという赤いウネウネした何かがロゴの、ウェブメールをやっている会社です。
  • 就職してひょんなことからPerlを書き始める。元々はインフラ志望、Linux歴十数年、Perl歴8年。だけどブランク時期もあってスキルは…でもPerl大好き!モダンPerlの先端は追いかけきれていない今もヒヨッコだけど、VMやperlbrewで手軽になって手元では試しやすくはなった。社内は昔から濃ゆいmod_perlのシステム、それで今もなおmod_perlエキスパート(?)の道を邁進中(Nginxとかも試食中だしオワコン野郎って言わないで><!)。社内の内向きのアウトプットはしていたけど、長年(社会人になってしばらくしてから)ブログ等の外向きのアウトプットをしていなかったが、その大切さを最近痛感。今年2011年、地元北海道の縁もありHokkaido.pmでmod_perlを題材に初トークさせていただいたり、今ブログを書いたりし始めています。

よろしくお願いします。

毎年、懇親会等の交流の場では、一緒に来た会社の仲間数人と集団を作るだけで、シャイな性格ゆえかなかなかボッチ感が拭えなかったのですが、今年はHokkaido.pmの仲間との再会や、そこからの繋がり等もあって、ボッチ感が少し和らいで、より楽しかったです。ただ、特に有名な方に名前を覚えて頂くまでには至っていません(お前アウトプットしていないんだから当然!って言って下さい)。今年YAPCで頂いたモチベーションを利用して精力的にアウトプット、さらに精力的に交流する!これは次回への課題です。

各トークについては、技評さんのまとめを初めとした優秀なまとめが数多くあるので、個々に聴講したトークの内容は逐一書かず、印象に残ったトークの感想や場面をざっくり書いてみようと思います。

前夜祭 10月13日(木曜日)

YAPC::Asia Tokyo は今まで何度も参加していますが、前夜祭に来たのは今回が初めてでした。当初来る予定は無かったので会社で仕事をしていましたが、#yapcasia タグの中継を見ていて、居ても立ってもいられなくて「事前登録だけできればいいか」という気持ちで18時過ぎに会場に向かいました。

結局、会場に着いた時間が遅くてRejectConfは聴講できませんでしたが、事前登録を済ませ、会場ホールで私の大切な師匠の一人である@shakujiさん(今回は運営を担当されていました)にお会いし軽く談笑。ビールを頂き、その後の宴会に参加して北海道勢との再会を中心に親睦を深めることができました。

ホールから撤収した後についていった宴会の開場は狭く圧迫されて疲れたことも確かですが、酒場でもPerlやシステム用語が飛び交う光景、近くに来てくれたtokuhiromさんの熱いお話を聞くこととができたり、楽しく貴重な体験でした。

1日目 10月14日(金曜日)

遅れ気味に到着。@941さんのOpeningの途中から講堂に入りました。

その後、午前中は講堂で聴講をしていたのですが、Jesse Vincentさん、Tatsuhiko Miyagawaさん、Naoya Itoさんと、重鎮のトークが続きます。最初から疾走感と重厚感が半端なかった。Perl5の明るい未来を実感し、Cartonスゲーと驚き、スマホ開発のイマドキを生で聴くことができました。

午後はMarc Lehmannさん(非同期)、Kang-min Liuさん(perlbrew)などを講堂で聴きました。何年経っても英語は苦手。スライドから雰囲気を察する力だけは向上中。ダメですね、英語の勉強もヒアリングから始めてスピーキングも勉強しないと!と毎度思います。今年こそは実行に移す!

北海道(Hokkaido.pm)から来た@techno_nekoさんの「perl meets beats」を聴講。Hokkaido.pm#5でもこれの一つ前のバージョンのトークを聴講しましたが、機知に富んで面白いトークでした。こちらは2日目ですが@hrkさんの「OtoPerl」も聴講して「Perlで音楽、アツい!」と思いました。

Plack以前のWAFで盛り上がったりMooseに湧いたりといった例年と違い、特定のプロダクトや動向に多くの注目が注がれない年だったとは思いますが、ゲームとサウンドが個人的にアツい(ネタ的にも笑えますし)と思いました。

今年特定のプロダクトがことさらフォーカスされなかったのは、良い意味で現状が成熟していて過去からの新陳代謝が起こっているからなのではと思います。もちろん進化や新しいものを生み出す原動力は必要ですし、JavaScriptの話が多いのは時節柄としても、一時期過大に持ち上げられたORMも今回はORM-dis風潮に飲まれたり…。SQLチューニング等、温故知新は悪い事ではないかなと。周囲に話を聴いても「いくらOOPを楽にしたいといえパフォーマンス等を犠牲にしてまでMooseしなくても自分でblessすりゃいい」といった話も聴きます。私もそう思います、というかblessって構文の名前、オシャレじゃないですか。私は好きですよ。

LT1日目。20個近いLTに大盛り上がり。でも iSteve for perl が全て持っていったくらいの威力でしたね。単純に高い技術を発表すれば盛り上がるわけじゃない、LTの面白さと難しさを再確認しました。

懇親会は、再会した北海道勢と盛り上がったりできて、今までのYAPCの懇親会に無い活発な交流ができましたが、それでも有名人に中々声を掛けられなかったり、ボッチ感が完全に拭えた感じではありませんでした。これも次回への課題でしょうね。でも、あの大勢の空間の中ではなかなか難しい部分もあります。私はスポンサー枠を示す緑色のストラップを下げていましたが、特に収穫や恩恵はありませんでした。

2日目 10月15日(土曜日)

1日目もそうですが、2日目は本当に悩みました。1日目以上に聴きたいトークの時間が重なりまくっているのですから…。どうしたものか…。現地のアツい空気は感じているし、聴けないトークは後日の動画やスライドの公開に期待しようと心に言い聞かせつつ、毎回苦渋の選択をしました。

午前中は前日同様講堂に入って「続 Unix Programming with Perl」「運用しやすいWebアプリケーションの構築方法」を聴講。実践的な内容に満足。

午後は「私は@nekokakさんのファン」とか言いつつ、「watch your log」ではなく、蔵前会館へ移動して「DISられないCPANizeを目指して」を聴講しに行きました。これからCPAN Authorを目指したい自分にとって、この聴講は大きな糧となりました。

数学科出身で圏論などを操り、今回の技評レポートでもその超速レポートぶりを発揮していた@hirataraさんの「Monads in Perl」を聴講。私も実は数学科出身ですが、専攻が違ったので圏論は全くの専門外。でも、分かりやすく解説されたトークからの数学の香りはとても心地良いものでした。最近数学自体を勉強していないなぁ…、Haskellも興味あるなぁ…、等と聴講中も聴講後も思いを巡らせました。

「SKYARC system presents 招待 LT」。地方の力、若い力を存分に感じました。スカイアークシステム++。若い方々頑張って、地方頑張って。私は個人的にHokkaido.pmを応援していますよ。

15:20は究極の選択。北海道勢の究極のダブルブッキング。私が個人的にお世話になった(と勝手に思っている)@aloelightさんの「少人数でのWebアプリ開発 – CGIからPSGIまでの変遷」と、高校生ホープの@akiymさんの「なぜ、高校生がPerlを使うのか?」。苦渋の決断の末、前者を聴講しにいきました。mod_perl止まりの私にとって、少人数でも進化を続けておられる@aloelightさんが羨ましかった。トークも面白かったです。

移動が多い2日目。また移動して、「OtoPerl」「Perl Hobby Programming – Games::BeLike::EightBIT ターミナルで8ビット風ゲームを作ろう」を聴講。OtoPerlについては前述。8ビット風ゲームはHokkaido.pm#5や1日目LTでも聴講したものの長時間バージョンですが、ある意味破壊力抜群。OtoPerlとともに、面白すぎて笑いが絶えない2トークでした。

その後は講堂に戻り、LT2日目、基調講演、Closing、と進行。

基調講演「Managing A Band Of Hackers」はギークのマネージメントといったお話。私はまだマネージメントをする側ではありませんが、マネージメントも含めて色々体験してみたい、その時にはこの基調講演の内容を活かしたいと思った次第です。

Closingは@lestrratさんが登壇。スライドの企業スポンサーの中に自社ロゴがあったのは感無量でした。そこで示された数字を見るだけでも、YAPC::Asia Tokyo って本当に大規模な祭典!今回は時勢柄ゆえかJavaScriptの話も多く、Perlをメインで書かない人も是非来てみる価値があるイベントだと断言できます。だって、懇親会でも「Perl歴本当に少ないんですよ」「業務ではPerl以外を使っています」っていう方にチラホラお会いしたくらいですからね。

例年通り、トークの投票の抽選などClosingの中で行われて喝采や笑いで盛り上がる中、YAPC::Asia Tokyo 2011は閉幕。

毎年ですが、今年は特に語り尽くせないほど本当に面白かったです!来年があるかどうか?という不安な発言もClosingで飛び出しましたが、来年・次回があれば、次回はさらに楽しめるよう、それまでアウトプットをしたり自己研鑽を楽しんで、万全の体制?で望みたいなって思いました。

トークをした皆さん、本当に楽しかったです。イベントスタッフの方々、本当にお疲れさまでした。私とお話をしてくださった方々、また機会を見つけてお会いお話できれば本当に幸いです。

長文になってしまいましたが、これを以て YAPC::Asia Tokyo 2011 のまとめとさせていただきます。ありがとうございました。