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

Yokohama.pm#10 に参加してきました #yokohamapm

コメントを残す

おがた (@xtetsuji) です。

2014年2月21日に行われた Yokohama.pm#10 に参加してきました。

Yokohama.pm#10 の看板

参加といっても、今回は完全に聴講する側で、しかも少し遅れて会場入りしたのですが、なかなか楽しめるイベントでした。

 

PRONTOでのYokohama.pm#10の風景

ビール片手に立食パーティーなYokohama.pm#10

というわけで結局、終始メモを取ることができなかったのですが、実際に発表が行われている場所で雰囲気を感じ取ったり、来ていた知り合いの方々と懇親したり、飲んだり食べたりができたり、色々と有意義な勉強会となりました。

私の2013年12月の入院の心配をしてくれる人がいたりと、色々と挨拶してくださる方も結構いて、本当ありがたい限りです。

本トークも色々と参考になりましたが、LTのトークの内容も良かったです。後日の資料公開が期待されます。

本来であれば自分のメモをまとめたものをブログ記事に載せているのですが、今回はメモが無いので、雰囲気だけ伝える感じ。その代わり、Togetterに参加者の関連ツイートをまとめました。

都心から来ている人も結構多くて「横浜遠い」という話も結構聞こえたのですが、Yokohama.pmですからまぁ横浜ですよね。それでも昔に比べれば副都心線でかなりアクセスが良くなったので、また開催されるならぜひ行きたいです。今回は1年ぶりくらいの開催だったようですが、今後は数カ月おきに開催していくという話なので、期待したいです。

日本語のperldocを検索する便利なショートカット

1件のフィードバック

おがた (@xtetsuji) です。

Perlの良い点は、コンソールで perldoc コマンドを使うことで、オフラインでも迅速に組み込み関数やモジュールのドキュメントを見ることができることです。そしてそこに書いてあるSYNOPSISを真似ればとりあえずモジュールが使えるという点。この仕組みはPerlの長い歴史の中でずっと続いている良い点だと思います。

でも出てくるドキュメントはたいてい英語なんですよね。Perlを10年書いてきてPerlのドキュメントの英語に慣れたとはいえ、時々は日本語で読みたいもの。PHPやRubyはどうなんだろうと調べてみると、だいたいはウェブ上に日本語ドキュメントがあって、それを閲覧する形のようです。

Perlにもperldoc.jpという日本語perldocが読めるサイトがあります。

このサイト、パスの最初に組み込み関数やプラグマやモジュール名を入れると、それが存在すれば適切なパスにリダイレクトをしてくれるという嬉しい機能があります。

FirefoxやGoogle Chromeなどのアドレスバーや検索ボックス(オムニボックス)でURLにキーワードを渡して検索ができる機能があるブラウザの場合、これを利用してperldoc.jpのドキュメントを素早く検索することができます。

Google Chromeの場合はアドレスバー(オムニボックス)に chrome://settings/search と入力して設定画面を開き「検索エンジンの管理」というボタンを押します。右上の設定検索を利用すると楽でしょう。

この次に一番下にある「新しい検索エンジンを追加」で

  • 新しい検索エンジンを追加: perldoc.jp
  • キーワード: perldocjp (ここはお好きなキーワードで)
  • 検索キーワードの代わりに…: http://perldoc.jp/%s

と設定して追加をします。%s 部分に検索キーワードが入るという感じです。これはFirefoxでも同様です。

こうすることで、検索エンジンとして設定したキーワードをアドレスバー(オムニボックス)に入れた後にスペースかタブを押すと、検索キーワードの入力を促されます。例えば「LWP::UserAgent」と入力してLWP::UserAgentの日本語ドキュメントが表示されたら成功です。

perldoc.jpが単純な仕組みで検索結果を表示してくれるので、コマンドラインアプリケーションからURLを構築して、CUIやGUIのブラウザで検索結果を表示するということも簡単にできるでしょう。色々と応用が可能です。

これで便利な日本語perldocライフが過ごせますね。

DebianでPerlのDB_Fileモジュールのインストールに失敗した時の対処法

コメントを残す

おがた (@xtetsuji) です。

cpanmでLiBotを入れようとしたらDB_Fileモジュールが入らないとエラーが出たので、~/.cpanm/build.log をみたら「db.hがない」といったエラーが出ていました。

サーバはDebianだったので、UbuntuなどのDebian系OSであれば同じ方法でいけると思いますが、以下の方法でdb.hを配置することができるようです。

$ sudo apt-get install libdb-dev

このapt-getが無事終わったら、cpanm で DB_File モジュールが入ります。

検索したら、他のサイトでは「手作業でtarボールを落としてきて…」とか書かれていて「Debian系ではそこまでする必要はないんじゃ」と思ったので手元で試行錯誤したら上述の方法でうまくいったというメモでした。apt-cache search berkeleydb して出てきたパッケージの中からもっとも有力そうなものを入れたらたまたまうまくいったというだけですが。

よく確認していませんが、perlbrewやplenvではない「システムPerl」を使う場合であれば、Debian の libmldbm-perl パッケージで DB_File モジュールが入るようです。ただ、LiBotのような新しめのモジュールはパッケージとして提供されていないので、ユーザPerl環境を作るか、cpan2deb (dh-make-perl) コマンドを使うなりして自分だけのCPAN配布パッケージのDebianパッケージを作る必要があるでしょう…が、この作業はPerlモジュールの依存関係が深くなればなるほどしんどい…。個人用途で縛りのない環境であれば、ユーザPerl環境を作るほうが楽な時代でしょう。

さて、本題のLingrで遊ぶ作業の続きでもしようかな。

参考:

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

コメントを残す

おがた (@xtetsuji) です。

2013年12月28日に行われた Hokkaido.pm#11 に参加してきました。

※参加ブログ記事やスライドURLなどについては、公開されたりしたら都度追加していきます

いつも参加ブログ記事を書くのが遅いので今回はすぐに年内に…。本当は他にも出席したものの、まだ参加ブログ記事を書いていないイベントが結構あるのですが、それは年末年始休暇にまとめて書こうと思います。

参加者の方々によるブログ記事 。

場所は、今回は東札幌駅近くの産業振興センターではなく、札幌駅の北の札幌エルプラザというところでした。ここはHokkaido.pm Casualを毎月催しているところ。

今回も13時30分開始でした。勝手が分かっていて、一度Hokkaido.pm Casualに出席して札幌エルプラザに行ったこともあるので、比較的迷わず行けました。吹雪結構大変だったけど。

自分主導でUstreamをやってみた

自宅で役割のなくなったiPhone 4sがあったので、前回のPerlBeginnersのときにそれにUstreamアプリを入れてUstreamをしてみました。一人でも見てくれれば御の字と思っていたら、数人から反響があって、やってよかったなと思ったので、今回のHokkaido.pmでは、私が名乗り出て、この形式のUstreamをやってみることにしました。幸いHokkaido.pmのUstreamアカウントは随分前から存在していたので、それを利用しました。録画もあります。

前回のPerlBeginnersは短時間イベントなので気付かなかったのですが、iPhoneのUstreamアプリの最大連続録画時間は3時間(180分)ということを知らず、途中でぶった切られています。ちょうど自分が発表する前後でした。

Ustreamは3時間まで

 

ちょうど3時間(180分)寸前でいったん録画が切れているのが分かりますが、そういう事情です。録画が残されていたことが幸いでした。しばらく気づかず、タイミングが悪かった。皆さんもiPhoneのUstreamアプリで長時間ライブ配信をするときには気をつけてください。

いちおう休憩中はオフレコの雑談もあるだろうということで、画像はブルースクリーンを移しつつ、マイクはオフにするという対応をしました、これはこれで良かったかなと思います。3時間以内に収めつつ、収録時間を少し細切れにするとよいんだなというのが今回の教訓でした。

録画は3時間超(13時30分〜17時頃まで)の長丁場ですが、ダラダラ閲覧すると雰囲気が分かっていいかなーと思います。@yusukebeさんの40分トークなど、見所も多かったので、自分の見たいところだけを見るのも良いと思います。

今回はUstream業や会場入りが遅かったことや体調不良などもあり、バタバタしていてメモが疎かです。他のスピーカーの方がスライドを公開したりしたら、随時情報を更新していこうと思います。

13:40~14:00 「今年書いたPerlコードの振り返り」 by @akiym さん

akictfの話から。

特にMac関連のCocoaモジュールが豊富な @akiym さん。私も結構お世話になっています。

  • AnyEvent::SKKServ
  • Cocoa::NetworkChange
  • Regex::VerbalExpression

Cocoaモジュールの作り方について。なぜ「Cocoaのモジュールを書くのか」という問いについては、CocoaのAPIに触りたいからとのこと(高速化ではない)。Perlを使って、Macアプリを使わずにMacの機能にアクセスしたいだけだし、単体モジュールにして言ったほうがみんなが幸せだとtypesterさんがいっていた、とのこと。

最近では「XSUBで書けるようになったので超絶便利」であり、革命とのこと。Cocoa::GrowlやCocoa::Skypeは面倒なことをしているそう。xsubppが…。

MinillaでXSモジュールを作成する場合には minil new -p XS Module して、builder_MyBuilder.pm を作成してminil.tomlを編集。あとは *.xs にゴリゴリと書いていって、makeすると.mが生成される。

Cocoaモジュールは、普通のXSと同じように書けるそうです。Cocoa→Perl、Perl→Cocoaのデータ変換に気をつければいいだけ。それ以外はただのXS。どうやればいいんだ…というときには@typesterさんや@soh335さんを参考にすればよいとのこと。

Mac::Keyboard::LED というモジュールを作った話。Caps Lockを光らせることが出来るやつ。通知に良いかもしれません。

後半はベータバージョンであるPerl5.19の話。hash slice sytaxやpostfix dereferencingなどの便利記法を紹介したあとに、CGI.pmが正式にdeprecatedされた話や、削除されたモジュールの一蘭などを紹介。ようやくCPANPLUSが無くなった。時代ですね。

最後に、ウェブアプリケーションの設計についての、聴衆への質問の投げかけ。

Amon2を使っている理由は単なるコンテキストマシーンであるというところから、Bootstrap3.0対応、Kolon対応が良いという話、Rooter::BoomやTengを使っているという話の後で、Modelというものは何なのかという問いかけでトークが終わりました。質疑応答が盛り上がったものの、MVCにとらわれすぎてはいけないという結論に至ったような気がします。

14:00~14:20 「Hokkaido.pm #11」 @__papix__ さん

自称「どこにでもいる大学生」、@__papix__ さんが大阪から遠路はるばるやってきました。今回はフェリーらしい。

今回のHokkaido.pmのテーマである「今年作ったもの」というのにふさわしく、いくつかの業務・私的に作った作品を紹介していました。

  • Facebook API 変更自動確認ツール Kaopan (これはインターン先の会社で作ったそう)
  • シンフォギア (今のところ自分用スライド公開ツール)

Kaopanは結構便利そうなので、会場からも公開を期待する声が多く聞かれました。

シンフォギアは「Amon2+Teng+SQLite+Text::Markdown::Hoedown」という構成で2日で作ったとのこと。今までの積み重ねと先人の苦労があって2日という短期間で作成できたというのは本人の弁。

先の @akiym さんの話に続いて、MVCについての話も触れられましたが、やはり「とらわれすぎてはいけない」という話。DBはModelとして扱うというよりもDB名前空間で別物として扱うスタイルだということが語られました (このあたりちょっとメモが怪しいかも)。

14:30~14:50 「Hokkaido.pm寿司x11」 @moznionさん

今年の流行語は「DevOps」という話からはじまり、協調を提案する話へ。

その後、TestとDocumentの関わりについて触れ、「DocumentからTestを生成する」アプローチと「TestからDocumentを生成する」アプローチの二種類を比較。 「SYNOPSIS重要」としつつも、「DocumentとTestを同居させる」という結論に。

後半は「TestからDocumentを生成する」というアプローチにフォーカスしてJSON APIのテストを書くとそれのドキュメントを自動生成してくれるautodocの紹介や、Test::JsonAPI::Autodocモジュールの紹介などをされました。

多岐に渡る活躍の中でもとりわけテストや品質管理に造詣が深い @moznion さんのトークでした。トークやスライドのテンポも面白く、Ustream録画やスライドは要必見です。

14:50~15:10 「」 @charsbarさん

翻訳家の@charsbarさんが余っている20分枠に急遽登壇。

最初はCPANTSなどの品質管理系の話から始まりました。

その後、本業である翻訳業の中で手間だったラテン語の辞書を引くためにMojoliciousアプリケーションを書いた話などが印象的でした。

最近編集(?)を手がけた「世界の名酒事典 2014年版」の紹介などもありました。興味深い。手広いです。

最後に、WindowsのiTunesで英語の勉強などで歌詞をブラウザでリアルタイム表示させたいといった要望を手軽にかなえるために書いたというウェブアプリケーションをご紹介。これはMojolicious Advent Calendar 2013でも紹介されていた記事のデモでした。MojoliciousとWebSocketの組み合わせ。これもまた興味深かったです。

15:20~16:00 「今年見たPerlコミュニティそしてこれから」 @yusukebe さん

講師派遣は無かったのですが、今回メインとなった40分トークを飾ったのが、最近JPAの理事に就任された@yusukebeさんのトークでした。

技術的なことよりも、それを支える方法であるとか、盛り上げるアイデアだったりといった展望について熱く語られたトークでした。スライド公開後のネットでの反響もかなりあったようです。スライドも公開されていますし、Ustreamにも録画がありますので、ITエンジニアコミュニティに興味のある人であれば、元気がもらえるスライド・トークでしょう。私が書いたメモを公開するより、このスライドをテンポよくめくっていったほうがよく雰囲気が分かると思います。興味があればUstream録画も見るとよいといった感じです。

今回の名言「PerlMongerよ、旅に出よ！」は、Perlプログラマだけでなく、全てのOSSに携わるITエンジニアに言えることではないでしょうか。数学などの頑張れば一人で出来る学問でさえ、ネットを使ってみんなで協力するだけでなく、学会発表や研究交流のために各地に旅費を払って行くわけです。場所が変わって、そこで得られる知見といったものは何にも代えがたいものがあるでしょう。私も関東圏と北海道のみが活動圏だったので、今後は西や南のほうや海外へ、出来る限りもっと積極的に足を運びたいと感じました。

16:10~16:30 LT

今回のLT、最初は応募が少なかったのですが、結果的に飛び入りが多くて活況となりました。

まずトップバッターは飛び入り参加の @itrysd さん。ギターの音を奏でられる本格的なウェブサイトを作ったそのデモは、なかなか興味が惹かれるものがありました。本公開が待ち遠しいです。

@techno_neko さんの「本当にあったGrepが遅い話」は、耐久テストのような問題が出されて、なかなか面白い感じでした。非常に疎な配列の作成が新しいPerlであれば実行可能であるという結論は、なかなか興味深かったです。

次は私のトークでしたが、その話は後ほど。

再び登場 @__papix__ さんによる「Hokkaido.pm#11 Lightning Talk」。今年書いたモジュールを色々列挙。@moznionさんが「成果を横取りされた」と言っていたのが面白かったです。Acme::SuddenlyDeathが今年2013年とは…。随分前のことだと思っていたので、意外に2013年は長かったのかなぁとも思いました。貴重な感覚です。

@onagatani さんによるAWSの紹介。スカイアークがAWSを主導していること、とても興味深かったです。

@aloelight さんの「今年書いたPerlのコード」は本格的なモジュールがいくつも出てきて驚愕しました。Tamanegiは興味深いですね。公開を楽しみにしています。

※LTのメモが疎かだったので、順番などが狂っている可能性があります。

私のLTについて

「今年作ったもの2013」と題して発表させてもらいました。スライドも公開済みです。

実際2013年は色々あってあまりPerlのプログラムを書かなかったのですが、APIラッパーの類や、書き捨てスクリプトであったり、そのあたりを含めて紹介させていただきました。他の人が発表している本格的なものに比べて見劣りするなぁとは思いましたが…。

特に今年は、12月11日から12月24日まで胃潰瘍で入院をしていて、今回の Hokkaido.pm#11 にも出られるかどうかというギリギリの感じでした。Twitterに同報通信的に状況を報告していったのですが、同情をもらおうとかそういう意図は全く無かった(詳しくは「入院中、そして伝えたいこと少し」を参照)ものの、意図せず色々なITエンジニアの方から心配をしていただき、2011年7月のHokkaido.pm#5から開始したコミュニティ活動によって「作った」というよりも「豊穣された」温かいコミュニティにトークの中で感謝をしたかったということがあります。

とはいえ、ディスプレイトラブルであったり、ちょうど180分のUstreamトラブルであったり、久々にハマった発表だったので、なんかそのあたりを落ち着いて話すことが出来なかったのが心残りでした。

ご心配くださった方、お見舞いに来て下った方、本当にありがとうございました。

懇親会

今回もすすきのへ移動しての開催でした。札幌駅近くだったので、今回は30分ほど歩いて移動することに。入院していたこともあって、久々に長時間歩いたので結構疲れましたというか汗をかきました。

鍋料理、お腹に優しくてとても助かりました。移動できない狭さだったので多くの方との交流はなかなか難しかったのですが、それでも近くの席の人達と盛り上がれました。

二次会

@onagatani さんが大好きな活イカのいる、いつものあの場所でした…がシケで活イカはいませんでした。

少し人数が減って、多くの方との交流がより弾みました。@onagatani さんともようやく二次会でゆっくり話すことができて満足。

その後

大体Hokkaido.pmの三次会は@onagataniさんが大好きなラーメンで締めるのが通例なのですが、病み上がりでラーメンのような脂っこいものが食べれないことなどもあって、行きませんでした。噂では、@onagatani さんと @jamadam さんの二人でラーメンに行ったようです。

まとめ

久々のHokkaido.pmだったなーという気がします。Casualが毎月開催されているのでそちらに比重が置かれてしまう感じもありますが、北海道外からの参加者も集めて大々的に出来るHokkaido.pm本会というのも趣がありますし、私も大好きな北海道に行く口実ができてとても良いです。噂では、また3ヶ月に一度くらいのペースで次回が開催されるらしいとのことで、大いに期待したいところです。

先日の #Perl入学式 での演習問題「calc_string.pl」の一風変わった解法

コメントを残す

おがた (@xtetsuji) です。これを書いている2013年12月22日、まだ入院中です (詳細)。ベッドでブログ書くの、結構腰が疲れます…。

最近では「Perl入学式in東京」のサポーターを常連でやらせてもらっています。

先日の #5 での演習の中に「calc_string」という問題がありました。スライドの内容から引用します。

  • 引数として与えられた文字列が, 数値A 演算子 数値Bという文字列であれば, その値を計算して, 結果を返すような関数calc_stringを書いてみましょう
    • ｢数値A｣は任意の桁の正･負の整数とします. また, 演算子は+-*/%が使えるものとします.
    • 但し, 引数が与えられなかった場合(空の文字列の場合)は, undefを返します
    • また, 数値A 演算子 数値Bというフォーマットと一致しない場合もundefを返します
  • 関数calc_stringとwhile文を使って, Ctrlキーとdキーを押すまでの間標準入力から文字列を受け取り, 文字列に書かれた式を計算するようなコードを書いてみましょう

これについての回答は、他の生徒さんもブログにアップしたりしていて、その試行錯誤を見て初心に戻ったりしました。

私も生徒さん達が問題に取り組んでいるときに問題をといてみたのですが、マッチさせた演算子文字列で延々と条件節を書かないといけないのであれば、最初から計算式が文字列として組み立てられていることを前提に「文字列eval」したほうが、この場合はパフォーマンスを気にすることもないし簡潔になるかなと思って、Perl入学式の中では教えられなかった s/// の e オプション (eval) を使って解決してみました。しかも結果的に一風変わった形式で。

#!/usr/bin/env perl
# https://github.com/perl-entrance-org/workshop-2013-05/blob/master/slide.md#%E7%B7%B4%E7%BF%92%E5%95%8F%E9%A1%8C-1

use strict;
use warnings;

while(my $str = <STDIN>) {
    chomp $str;
    my $res = calc_strings($str);
    if ( defined $res ) {
        print "$res\n";
    } else {
        print "Input Error: $str\n";
    }
}

sub calc_strings {
    my $str = shift;
    # 文字クラス [...] の中での - は文字コード範囲になるので端っこに置く
    $str =~ s|^(\d+)\s*([-+/*])\s*(\d+)$| "$1 $2 $3" |ee
        or return undef;
    return $str;
}

ここでは Perl の simple replace s/// を使っていますが、e オプションを2回重ねています。こうすることで、置き換え後文字列に二回文字列evalがかかるというPerlの挙動があります。eオプションを重ねれば重ねるほどevalが重複してかかります。最初この挙動はPerlのバグというか意図しない挙動であったのですが、いつしか正式な仕様となりました。

  • s|^(d+)s*([-+/*])s*(d+)$| “$1 $2 $3” |ee

区切り文字を / から | に変更しています。割り算演算子としての文字列 “/” をキャプチャする必要があるのでややこしいからです。あと文字クラス […] 中では、正規表現のメタキャラはその意味を失います(一部の記号、例えばバックスラッシュや “[” などは除く)。またハイフン “-” は文字コードの範囲演算子になるので、文字クラスの列挙の最初か最後に書かないと混乱を招くことに注意しましょう(バックスラッシュでエスケープしてもよいです)。

「数字 演算子 数字」をキャプチャして、最初の置き換え後の文字列eval (e) では、これを文字列連結したPerlの文字列として評価しています。そして二回目の文字列evalで、最初に文字列連結した「計算式の文字列」をさらにPerl自身で評価させて結果を最終的な置き換え文字列としています。

ユーザの任意の文字列を文字列evalすることはセキュリティホールにつながる危険な行為であり、文字列evalはパフォーマンスにも良い影響を与えないことには注意が必要ですが、今回の例では「数字 演算子 数字」の列を正規表現できちんと検査していること、また一人で使うコマンドラインツールなのでパフォーマンス上の問題点は特に無いことで、これも一つのトリッキーな回答になっているかなと思います。

s///ee といった複数回evalの「仕様」は以前から知ってはいたのですが、実際に有用な場面で使ったのが初めてだったので、改めてまとめて解説を書いてみることにしました。

WordPressで新規投稿ができなくなった原因がプラグインだった

コメントを残す

おがた (@xtetsuji) です。

このブログ、2013年の夏から自分で契約したVPSにWordPressを入れて運用しているのですが、2013年の11月頃から新規投稿ができなくなってしまいました。新規投稿URL wp-admin/post-new.php にアクセスすると画面真っ白。個々のブログの画面表示も重くなった感じ。複数の投稿をDBから引っ張ってくるだろうトップページもまた画面真っ白という状況。

何が悪いのか原因を調査してもよく分からず。閲覧は重いながらもできたので、しばらく放置していました。

最近コメントスパム爆撃を受けた

結果的にこれは直接の関係は無かったのですが、2013年11月に大規模にコメントスパム爆撃をくらって、サーバがたびたび無反応になるケースが増えてきました。VPSのバーチャルシリアルコンソールでもログインができず、OOM (Out of Memory) Killer によってApacheがkillされる光景だけが見えるというもの。

Apacheのprefork MPMとmod_phpでPHP運用するケースは多いと思いますが、prefork MPM のパラメータ調整をしておかないと、Apacheの子プロセスのメモリサイズが増え続けることがあるので注意したいところです。

<IfModule mpm_prefork_module>
    StartServers             5
    MinSpareServers          5
    #MaxSpareServers         10
    MaxSpareServers         15
    #MaxClients             150
    MaxClients              50
    MaxRequestsPerChild    500
</IfModule>

Debianのパッケージの素で入れたApache2とprefork MPM (libapache2-mpm-prefork) の場合、MaxRequestsPerChild が0になっています。これは「子プロセスはどんなにリクエストを受けても刷新されない」という意味。

PHPも大きなファイルを扱ったりやコメントスパムなどの大量爆撃を受けたりすると、解放されないメモリが出てきたりします。PHP、すなわちmod_phpとApacheは渾然一体なので、これはApacheの子プロセスのメモリサイズが肥大化していく事を意味します。

だいたい、サーバでApacheが使える合計メモリサイズを計算し、だいたい1プロセス辺りに期待する最大プロセスサイズを割った数くらいをMaxSpareServersに設定するとよいでしょう。

「Apacheの子プロセスが実際にこれだけのサイズになったら自動的に終了(child terminate)してほしい」という要求はPHPでも出来るとは思うのですが、私はあまりPHPに詳しくないPerlプログラマだったので、mod_perl2のApache2::SizeLimitというモジュールで行いました。Debianであればmod_perl2 (libapache2-mod-perl2) を入れておけば使えるようになるでしょう。

mod_perl2を有効にして (Debian であれば sudo a2enmod perl として Apache を再起動すれば良い) 以下の記述を Apache の設定ファイル (Debian であれば apache2.conf) に書いて再起動して反映すればよいです。

<Perl>
use Apache2::SizeLimit;
# sizes are in KB
$Apache2::SizeLimit::MAX_PROCESS_SIZE  = 12000; # 12MB
$Apache2::SizeLimit::MIN_SHARE_SIZE    = 6000;  # 6MB
$Apache2::SizeLimit::MAX_UNSHARED_SIZE = 5000;  # 5MB
</Perl>
PerlCleanupHandler Apache2::SizeLimit

使用できるメモリを確認する

ネットを検索すると、特にレンタルサーバでは使用できるメモリ容量に制限があることで画面真っ白現象に見舞われることがあるとのことでした。

対処法としては

  • wp-config.php に define(‘WP_MEMORY_LIMIT’, ’64M’); と書く
  • .htaccess か ApacheのVirtualHostの設定ファイルに php_value memory_limit 64M と書く
  • php.ini に memory_limit = 64M と書く

などといった解決方法が見つかりました。ただ、Debian wheezy の標準の PHP では既にphp.iniで64MBになっているようで、あまりこの部分は関係ないと思われます。

デバッグモードにする

手がかりを得るために、WordPressにあるデバッグモードをオンにしました。

具体的には wp-config.php にある以下の false を true にすること。PHPファイルは都度読み込まれるのでApacheの再起動などは必要ありません。

define('WP_DEBUG', false);

これでブラウザの画面やApacheのエラーログに情報が出力されるようになります。

ただ、これで得られたのは「GoogleアナリティクスのプラグインがWordPressの変数を再定義している」というNoticeくらい。Noticeなので大した影響もないわけで、途方にくれました。

チャット(Yancha)で聴いてみたら「プラグイン、テンプレート、これらが怪しい」ということで、最近入れたプラグインを無効化して一つ一つ試していくことにしました。

そうしたところ、数回のアクセスで以下のような出力を得ることができました。

PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted (tried to allocate 12565 bytes) in /var/www/sites/post.tetsuji.jp/wp-content/plugins/crayon-syntax-highlighter/crayon_wp.class.php on line 261

私の場合、Crayon Syntax Highlighterというプラグインがメモリをバカ食いしていたようです。何かのサイトでシンタックスハイライトの便利なプラグインとして紹介されていたので導入したのは10月頃だった気がするのですが、これを無効化したところ、wp-admin/post-new.php で新規投稿もできるようになり、トップページの表示も非常に早くなりました。

このプラグイン、もともと動作が遅いことで有名なようで、検索してみると色々な情報がひっかかりました。設定を改善することで多少は速くなるのかもしれません。

WordPressでトラブルにあったら

まずは落ち着いて WP_DEBUG を true にしてデバッグ出力を観察。

今まで出来ていたことが出来なくなった系は、大抵は最近入れたプラグインかテンプレートに起因すると見て良いので、デバッグ出力を観察しながら確認。

参考サイト

様々なサイトを参考にさせていただきましたが、一部を列挙します。

結論

自分でブログを運用するのは、安価で自由度が高い反面、トラブルに会うと自分で解決しなきゃならないので、面倒なことを経験したくない人は、多少課金してでも商用のブログサイトを使いましょう。

シンタックスハイライトについては、最近ではGistが標準となっているので、Gistに投稿したうえでそれを埋め込むというのが速度的には有利かもしれません。Gist埋め込みはEmbed GitHub Gistというプラグインを使っています。これに関しては特に問題は起こっていません。

Crayon Syntax Highlighterはとにかく重い。また、投稿画面の拡張も行うので、投稿画面 (post-new.php) にもその影響が波及することになります(これは正直わからなかった)。またサイト全体も目に見えて重くなります。コメントスパム等の絨毯爆撃を食らうとさらに深刻なことになるわけです。ただ設定で回避できるという話もあるので、試してみるのは悪くないかもしれません。

コミュニティは素晴らしい。実際に質問できる人がいる。これ以上に心強いものはありません。みなさんも私が通っている勉強会にいらっしゃいませんか？

Shibuya Plack/PSGI Conference (shibuya.pl) #1 に参加してきました #plackcon

コメントを残す

おがた (@xtetsuji) です。

2013年11月20日(水曜日) に「Shibuya Plack/PSGI Conference (shibuya.pl) #1」通称 #plackcon に行ってきました。

plackconの看板

私自身は、特に今回はトークする側ではなく、完全に聴衆側でした。

普段の勉強会では結構熱心にメモを取ったりしているのですが、今回は遅れて会場に入ったことや、スライドが見づらい席に座ったこともあって、あまり熱心にメモも取らずに、スライドに集中しつつTwitterで #plackcon ハッシュタグを付けてツイートすることに専念していた感じです。

詳細はATNDのページが詳しいです。

ダブル基調講演

まずは「ダブル基調講演」から。先日のISUCON3の出題者側の @fujiwara さんと、優勝者の @kazeburo さん。

色々な意味でISUCONの「出題者」と「優勝者」である2人。なかなか確信をついたトークが印象に残りました。両者、商用投入をしたときのパフォーマンスといった部分にフォーカスしていた印象ですが、@fujiwaraさんのほうはツールを組み合わせた多くの人にオススメな実直トーク、@kazeburoさんのほうが既存のPerl製ウェブサーバの魔改造トークといった色分けでした。普段多くの人は魔改造をあまりしないし、@kazeburoさん自身のトークでもアプリケーション層のほうがパフォーマンスでは目立つという話をしていたこともあって、すぐ応用とは行かないまでも、UNIXの根底理解は大切な局面もあるので、@kazeburoさんのトークも非常に参考になりました。というか、10年戦うための長く参考になるであろう話でした。

第二部

 「第二部」は10分トーク3つ。

@moznion さんのトークは、YAPC::Asia Tokyo 2013 の後日ハッカソンでPlackの作者の方々との議論の中で生まれた Plack::Request::WithEncoding の話と、それをMiddlwareにした話。確かにencode/decode処理は「職人が！心を込めて！書いている」状態なのを何とかしようとした話。マルチバイトを扱う日本人ならではの発想ですね。

ただ、PSGIの仕様としてはインプットやアウトプットはバイトストリームを期待すると書かれているそうで、うかつに全てを透過的にしてしまうと仕様との乖離や諸問題が起こるということも要注意。そもそも文字コードの判定は一般的に難しい。

@tokuhirom さんのトークは、理想を求めず実直に業務で使える考え方が満載でした。「application/jsonで来るHTTP Body」「vhostをけちっても意味が無い」「URLの v1 とかよりも X-API-Versionヘッダ」「結局頑張って内部仕様を作っても、iOS/Androidエンジニアに見てもらえなきゃかっこいいパンツを履いているだけ」等、小気味よい話が続きました。例えば 404 Not Foundは、APIが指し示すリソースが無かった場合は200 OKでカラBodyを返しておけばよくて、API自体が存在しない場合にのみ404 Not Foundを返せば良いなど。確かに、iOS/Androidエンジニアは404 Not Foundの解釈をするなら後者寄りなのかなと思いました。

@yusukebe さんのMojoliciousトークは、簡単ながらもRouterやBridgeを解説した実践的トーク。@yusukebe さんのやり方を含んだMojoliiousのカスタム的使い方も解説されていたりして、大規模商用サイトに投入されたMojoliciousがどのように使われているのかといった部分が分かる良いトークでした。また、ここでもJPA理事就任の話と「YAPC::Asia 2014」やるよ宣言。ここで大きな歓声と拍手。今後に期待です。

LT

その後、時間おしおしで休憩ナシで突入した「LT」でした。

@bayashi さんのトークは、plackup のワンライナーの解説が主でした。ただ、Middlewareの理解が甘い私みたいな人には、気軽にMiddlewareをワンライナーで試せるという事が分かって非常によかったです。確かに一度は plackup -e でワンライナーを書いたりするのですが、その後その存在を忘れてしまいがちなのは良くないなと思いました。

@azumakuniyuki さんのトークは、先日の YAPC::Asia Tokyo 2013 で発表した、Haineko のその後の話。jQueryからメールを送信したいという要望から生まれた、JSONをやり取りするplackベースのMUAの話でした。これは面白いプロダクトなので、一度どこかで使ってみたいと思いました。BounceHammerの導入事例も解説され、「あの会社もBounceHammerのユーザ」といったことがわかってよかったです。こういうPerlのキラーアプリが出てくることは良いことですね。

@songmu さんのトークは、.psgi ファイルからの卒業と題して、コマンドラインからplackupする際の *.psgi ファイルを最小限にするという提案。そのほうがテスタブルになるし、見通しも良くなるという話。あと、自作の Riji や Puncher の話など、Plackを応用した各種ツールについての解説も盛りだくさんでした。

トリ

最後は「グニャラくん」さんこと @tasukuchan さんによるトークだったのですが、引越作業が大変とのことで会場には来られず。代わりに「ビデオLT」となりました。生放送ではなく収録だったので、こちらの雰囲気(まいている)が分からず、まったりしたビデオLTとその独特の雰囲気に、周囲は和やかになりました。あのビデオと「Plack寄せ」という言葉の連発がとりわけ印象に残ったトークでした。

懇親会

最近のエンジニア飲み会の定番となった、リアル北海道にはない「居酒屋 北海道」での開催でした。

懇親会の風景

人の集まりは20人ほどでしたが、各テーブルで熱い話が繰り広げられたようです。自分は密度の低いほうのテーブルに座ったので、@uzullaさんのPHP話が特に印象に残っているという結論に。

ISUCONの勝者 @kazeburo さんと 出題者 @fujiwara さんが酒を飲み交わしながら熱く語っていたのが印象的でした。混ざりたかったけど、話の邪魔をする割には特に聴きたい具体的なこともなかったので、声はかけませんでした。あ、@uzullaさんに「ISUCONの賞金どうなったの？」って聞きに行けって言われたので聞きには行きました。みんな、本当お金には興味津々ですね。

23時過ぎには解散となりました。

今回、本会は遅く入ったこともあってバタバタしていてあまり写真が撮れず。とはいえ、それほど絵的に重要な部分も無かったし、ほとんどの人がスライドを公開しているので、あまり写真の重要性は無かったかな。地理的要因で行けなかった人からはUstreamが渇望されていましたが、スライドを見ればだいぶ雰囲気が分かるかと思います。

「Shibuya.pm」をやってしまうと100人以上の定員が即座に埋まってしまうのですが、今回は「Shibuya.pl」ということで80人定員が直前のキャンセルで定員割れするくらいの感じでした。これくらいの人数だとギリギリカジュアルに開催できるのかなと思いました。「秋の」と付いていることもありますし、四半期に一度くらいはPlack/PSGI祭を期待したいところです。

Postfixのログを行指向に変換するプログラム maillog-hashnize.pl のご紹介

2件の返信

おがた (@xtetsuji) です。

ずいぶん以前に公開したんですが、Postfixのメールログを行指向にする maillog-hashnize.pl というプログラムをご紹介します。

もともと社内で使っていたプログラムだったのですが、数年前の当時、上司等に掛けあってたぶん初めて会社発OSSとして世に出せたプログラムです。公開方法も当時は最善策が思いつかず、個人アカウントでGistに貼りつけて公開という感じ。その際、会社の製品ブログで会社の取り組みとしてこれの紹介をしたのですが、いつの間にかその製品ブログ自体が無くなってしまったので、これを紹介する日本語の文章は無くなってしまいました。

紹介記事も無くなり、私もこのプログラムの存在自体ずっと忘れていたのですが、つい先日、海外の方からこれを使っている旨書かれた英語のメールをいただきました。その方の要求にぴったりだったようです。あまり英語が読めない私にも、賞賛する英単語の数々に恐縮してしまうくらいでした。また「私はPerlプログラマーではなくて自力ではできないものの、こういった機能が欲しいのです」といった内容も書かれており、かつそれが私にとって妥当な機能拡張であると思えたので、それに関して対応する旨返信も行いました。

実際、Postfixのログをどうにかしてくれるプログラムがないか検索してみると、pflogsumm 等の「集計やサマリーを出してくれるプログラム」はあるのですが、Postfixのmaster配下の各デーモンが出力したログの行をキューIDで束ねて一通のメールがどうなったかを一行にしてくれるプログラムというのは珍しい存在でした。今現在探してもなかなか見つからないんじゃないでしょうか。

しかしながら私の業務では、こういう行指向に修正するプログラムの必要性がありました。一通一通のメールがどのような経緯でサーバに入ってきて、どのような最終処理がなされたか、開発者以外の人と詳細を議論するための見やすいデータを出力する必要があったのです。その時に活用されるアプリケーションは大体Excelになります。

以前は、MySQLやPostfixの業界で著名な「とみたまさひろ」さんという方が、この要望に合うRuby製のpflogというツールを公開していて、業務ではずっとこれを主に使っていたのですが、Postfixのバージョンが上がってPostfix2.3以降のログを入力すると謎のエラーが出るという現象に出会いました。原因を調査して納得したんですが何だったかな…。

そんなこんなで、Postfix2.3以降の対応を含めて、かつオリジナルのpflogにあったバークレーDB出力機能などの滅多に使わない機能を削ったPerlプログラム maillog-hashnize.pl を作成しました。pflog同様、キューIDで行指向に一行に束ねてCSVファイルとして出力します。pflogで時々ハマったExcelのデータ誤認対策も色々と入れました。

RubyのプログラムをPerlに書きなおしたのはいくつか理由があって

  • 各所でDebianを使っていた都合、システムPerlの存在はRuby以上に身近だった
  • 生粋のPerlの会社なので、各種作業サーバにRubyインタプリタ自体が入っていなかった
  • RubyよりもPerlのほうが行読み込みや正規表現のパースが若干速かった
  • 今後機能拡張をするときRubyの知識が足りない事がネックになるのを心配した

という理由でした。特にRubyが嫌いだったわけでもなく、自分のRubyの勉強の教材になればいいかなとも思ったのですが、その時と将来的な事を考えて、一気にPerlに移植することにしました。社内にいるプログラマーの数が片手で数えられるほど少ないことも、個人的趣味を越えて不必要に社内採用プログラム言語を増やせない理由でした。機能拡張の要望があったときに業務では迅速に対応する必要がありますので。

私が思うに、Rubyが行読み込みや正規表現パースのパフォーマンスでPerlに劣るのは仕方が無いことで、Rubyのオブジェクト生成のコストやPerlの狂ったほどの正規表現チューニングが要因としてあるでしょう。実際にベンチマークを取った結果はほとんど優位な差は無かったのですが、業務では数千万行から数億行のログを処理する必要があったので、軽微な差が及ぼす時間的コストの違いは無視できませんでした。

後輩に業務を引き継いだ後は、会社のリポジトリ内の maillog-hashnize.pl を触ることはなくなりましたが、業務でもときどきこのプログラムが使われているようです。

とりあえずライセンスはArtisticとGPLのデュアルライセンスなので、私のほうでforkして、外部で使ってくださる方向けに機能拡張をしていこうと考えています。基本機能としてpflogとの互換性が保てれば色々と都合が良いので、その方向で拡張をしていきます。良い結果が出たらまたブログでご紹介します。

とりあえず「ザ・インタビューズ」から記事をバックアップする雑なPerlプログラムを書いた

コメントを残す

おがた (@xtetsuji) です。

「ザ・インタビューズ」が終了するというニュースが先日ありました。

一時、大ブームになったサービスですが、最近はめっきり話を聞かなくなったので「あぁ〜」といった感じ。ウェブの時代の過ぎ去る速度は早いですね。

終了のお知らせには以下のように書かれていました。

平素より、みなさまにご愛顧いただいております「ザ・インタビューズ」でございますが、誠に勝手ながら【2014年1月6日(月)】をもって、終了させていただくこととなりました。

【2014年1月6日(月)】をすぎますと閲覧・投稿、管理ページへのログインも含め、全ての機能がご利用いただけなくなります。

お手数ではございますが、必要な情報はあらかじめお手元に保存していただきますようお願いいたします。

ザ・インタビューズ終了のお知らせ画面

よく分からないんですが「必要な情報はあらかじめお手元に保存していただきますよう」って、手作業でやるんですか？探してもエクスポートツールも無さそうだし、雰囲気的に提供される感じがしなかったし、ペパボにどう問い合わせればいいか分からなかったので、自分用にエクスポートプログラムを書きました。もう面倒だと思って2時間くらいで書いた感じ。

Perlで書かれています。Web::Queryというモジュールを使っています。

あと2ヵ月もしないうちに無くなるサービスだし、GitHubにプロジェクトつくらず、Gistにあげました。

どういう動作をするんですか？

上記Gistのページからti-export.plをダウンロードして、以下のように実行します。

perl ti-export.pl ユーザ名

そうすると、指定した「ユーザ名」のユーザの全投稿を現在のディレクトリにダウンロードします。UTF-8で「投稿ID.txt」というテキストファイルを作って、添付画像がある場合には「投稿ID.jpg」という画像ファイルを作成します(jpg以外の拡張子にも対応しています)。

どんな形式でアウトプットすればいいか分からなかったので、とりあえずメールっぽい形式で出しておこうといった感じです。

Perlのセットアップはどうすればいいんですか？

perlbrew か plenv を操作できる方は cpanm で Web::Query モジュールをセットアップすることで使えるようになります。

ビルドに必要なツールさえ整っていれば、perlberw や plenv のセットアップは簡単です。検索してみてください。

Perlとかプログラムとかわからないんですがエクスポートしたいです

親切なエクスポートツールが他にあればいいんですが、無ければ私の方で代行しますので @xtetsuji にmentionくださるなど、お気軽にご連絡ください。要望が多ければウェブで操作可能なツールにしようと思います。

MT形式やWXR形式でアウトプットしたほうがいいんじゃないですか？

ファイル形式についてよく知らないので、そういう要望があればアドバイスくださると嬉しいです。

YAPC::Asia Tokyo 2013 で「Apacheの展望とmod_perlの超絶技巧」というトークをしてきた話など #yapcasia

コメントを残す

おがた (@xtetsuji) です。

YAPC::Asia Tokyo 2013 トークなど編。その他の「YAPC::Asia Tokyo 2013」関連記事は目次ブログ記事からどうぞ。

いつもそうですが、今回もかなりの長文です(1万文字越え！)。mod_perlに特段の興味のない方は、流し読みでどうぞ！YAPC::Asia Tokyo 2013関連のブログ記事はこれが完結編の予定。

トーク「Apacheの展望とmod_perlの超絶技巧」について

昨年の初トークに続き、今年もYAPC::Asiaの壇上で2度目のトーク「Apacheの展望とmod_perlの超絶技巧」をさせていただきました。2年連続、今年も飽きずに得意の持ちネタであるmod_perlネタをぶつけましたが、今年も採用してくださって本当にありがたいです。世間では古い古いと邪険に扱われがちなmod_perlですが、こういうトークもソーシャルボタン等でそれなりの支持をいただいて嬉しい気持ちです。

最初はタイトルが「mod_perlの展望とApacheの超絶技巧」というタイトルだったのですが、スライドを作って発表が終わって一段落付くまで、Apacheとmod_perlというキーワードが入れ替わっていた事に気がつかないというボケをかましてしまいました。悩んだ挙句、トークページのタイトルをしれっと書き換えるという作戦に出ました。これくらいであれば許されますよね？

前のVimのトークはイベントホールが満席状態だったのに、自分が壇上に立ったら半分くらい人がいなくなったときは焦りました。ただ、イベントホールとメインホールは普段はそんな感じで、多目的教室が狭すぎたという意見も聞きますし、mod_perlというニッチな題材にしては、そこそこの入りだったかなと感じます。

実際、話したかった事は

  • Apache httpd serverは、Nginx等の他のウェブサーバ実装の台頭でこの先どのようになるのか展望を話す
  • mod_perl2 を使って任意のサーバが Apache2 と同等の堅牢性で書けるということのコンセプトを示す

というところだったので、タイトルとしては「Apacheの展望とmod_perlの超絶技巧」のほうが言いたかったことを表しているわけです。

前年は「mod_perlの本質とは何か」ということをmod_perl1とmod_perl2両方を例示して懇切丁寧に解説して大量のスライドが余った感じでしたが、今回はmod_perl1の説明は一切しませんでした。私自身が関わっている業務でもmod_perl1をmod_perl2にマイグレーションして、mod_perl1環境がほとんど残っていないですし(わざと自宅にmod_perl1化石環境を残しているだけ)、展望と超絶技巧を示すには当然mod_perl2だというのが背景にあります。

トークが採択されたのは「超絶技巧」という大げさな単語を入れたのも効果あったかなと感じています。「無駄にカッコイイ」などと褒め言葉もいくつか頂きましたし。日常生活では「超絶技巧」なんて言葉は使わないですよね。クラシック音楽ではフランツ・リストの「超絶技巧練習曲」という作品が有名で、そこから単語を採用させていただきました。

肝心のトーク内容については、無難にまとまったかなといった印象。前半の展望と後半の超絶技巧、両方そこそこだったかなと。もっとうまくできれば…という点はもちろん色々あるんですが、終わってから欲を言っても仕方が無いわけで。

中間部にあのトークを意識した「もう一つの本当にあったレガシーな話」というスライド群を入れたのですが、時間の関係で飛ばしてしまいました。内容はスライドままなので、興味のある方は読んでみてください。

mod_perl2でmemcachedサーバを実装するというコンセプトが当日までに完成しなかったのですが、完成したところで20分のトーク中に実演することもなかったので、これからに期待してくださると幸いです。特にこの事例は実用を目指しているというわけでなく、コンセプトとしてこんなことも出来るということを示したいという意図程度です。

mod_perl1はHTTPリクエスト処理しか書くことができませんでしたが、mod_perl2ではTCPコネクション層から処理を書くことができます。これはApache1.3とApache2.xのモジュールAPIと対応しています。Apache1.3では本体にパッチを当てないとSSL接続を直接受けられなかったのが、Apache2.0でmod_sslが生まれて単体で処理が可能となった事などが好例です。

世間は新しいものが受容される環境ばかりではありません。古式ゆかしい納品型受託案件などでAnyEventはまだ新しい実績の乏しいものと見られ敬遠されるケースがあるかもしれません。daemontoolsはdjbアレルギーで拒絶される場面もあるかもしれません。そんな時にApache2/mod_perl2で任意のTCPサーバが書けることがプロジェクトの突破口になることもありうるのでは、という情報を提供したかったということもあります。現にqpsmtpdはApacheをEngineとして動作するmod_perl2モジュールが存在しますし、mod_mrubyやmod_luaなど、新たなApache拡張系の登場も、このジャンルがまだ現役である事の証拠だと思います。先輩であるmod_perlがmod_mrubyやmod_luaへの実用例の開拓者になるって素晴らしいと思いませんか？

トークでお話した通りですが、展望面では、Apache2.6では大きな変更は無いとしても、Apache3.0が依然として謎のベールに包まれています。またApache2.4でのmod_perl2対応がWindows環境で難航していることで今後どうなるのか、見守りたいです。未成熟なevent MPMが今後成熟してNginx等と切磋琢磨していくのかなど、今後もApache/mod_perlから目が離せません。随時ウォッチして、ブログやトークなどでアウトプットしていきければと思います。

会場では @tokuhirom さんが聴講してくださって質問やアドバイスをいただけたのは嬉しかったです。「Apache2をAnyEventのエンジンにするのは？」は、実用とは別に興味深い課題。つい「そのアイデア、頂きました」と言ってしまいました。

後日 @tokuhirom さんが書いたmod_perlに関するブログ記事もリンクしておきます。

「本当にあったレガシーな話」を聴講して

いやはや、1日目に20分mod_perl推し(?)トークをした私でしたが、2日目の @lestrrat さんの「本当にあったレガシーな話」はまさに40分mod_perl dis吹き荒れる真逆のようなトークで、聴講していた私も内心ビクビクしつつ、楽しんで聴講しました。

[tweet https://twitter.com/xtetsuji/status/381289572115562497]

さて、会場で爆笑していた人の中で、あまりmod_perlに詳しくない方のために、私なりの解説をしてみようと思います。

その前に注意点として、私はこの内部コードの事を当然知らないわけで、憶測や推測で語っている立場だということ。また、私自身の無知や無理解による誤解や間違いが含まれている可能性があるということ。これらをご留意下さい。

前提として、@lestrrat さんの「脱mod_perl、PSGI化推進」という方向性は2013年の今の選択として正しいと私も考えています。一度PSGI化してしまえば、Plack::Handler::Apache1を使って「裏返し」にmod_perl1を据えることさえ可能だからです(はたしてそれをしたいかは別として)。Plack::Handler::* の数だけ裏側のウェブサーバの実装とPerlの永続化手法も選び放題です。このメリットは計り知れません。その他に得られるメリットも枚挙にいとまがない。

このトークの「mod_perlをPSGIに書き換える一大事業」は大きく分けて二部あって、前半が「mod_perl1ハンドラ(sub handler)で書かれたアプリケーション」、後半が「mod_perl1に密に依存したSledge」でしょう。mod_perl1の問題点は前半で大体語りつくされており、後半も色々な試行錯誤があるものの、前半の部分に話の比重が置かれてか、軽めな印象を覚えました。

前半のmod_perl1ハンドラで書かれたアプリケーションの話。Apache::Request->instance と言われて一瞬意味がわからなかったのですが、libapreq のことだったんですね。

mod_perl1で「リクエストオブジェクト ($r)」と呼ばれるものは主に2つあって、

  • Apache オブジェクト (ref $r eq ‘Apache’)
  • Apache::Request オブジェクト (ref $r eq ‘Apache::Request’) a.k.a. libapreq

というものがあります。今回 @lestrrat さんが語っていたのは後者の Apache::Request のほう。

「もともとmod_perlはApacheのモジュールをC言語ではなくPerlを使って書けるようにしたもの」というコンセプトに立ち返ってC言語でのApacheモジュールの開発に降りて考えると、mod_perl1でいうApache オブジェクトが、Apache1.3 での mod_*.c 内での原始的なリクエスト構造体 (request_rec 構造体) の対応です。ただ、この request_rec 構造体はHTTPリクエストを扱うにはあまりにも貧弱で、例えばファイルアップロード(multipart/form-data)のPOSTデータを受け取ってそれをほどくことすら自前ではできません。C言語を書くプログラマにとってこれはあまりに苦痛でしかないことは容易に推測できるわけで、これを補うために libapreq というライブラリが Apache側から提供されました。これを使えば大体のHTTPリクエスト処理ができるようになります。このlibapreqのPerlバインディング(XS)がApache::Requestと理解していただいて良いでしょう。

資料には Apache->uplaod() で Apache オブジェクト (request_rec 構造体) から upload オブジェクトを取得できるとされていましたが、upload オブジェクト (Apache::Uploadオブジェクト) を取得するためには確か libapreq / Apache::Request の力が必要なはずです。ここでは「Apacheオブジェクトは貧弱、Apache::Request (libapreq) オブジェクトは強力」ということを覚えておいてください。というか、libapreq はあまりにも強力なものです。良くも悪くも。

実は私は、ジョークやコンセプト以上の目的で libapreq / Apache::Request を使ったことがありませんでした。なので Apache::Request->instance という文字列が出てきて理解するまで10秒くらいかかったのはここだけの話。この呪文 Apache::Request->instance は、どこでも都合よく強力なApache::Requestリクエストオブジェクトを虚空から取り出せる呪文のようなもの。1つのリクエストサイクル中でリクエストオブジェクトは実質的にシングルトンであるとはいえ、このクラスメソッドを使ってしまうことで、コードの量が多くなればなるほど可読性は大いに下がると推測されます。

Perl CGIのRegistry高速化は別として、ハンドラとしてのmod_perl はあくまでも「複雑なことをさせない」「外部との密結合を避ける」ことが大事だというのが私のモットーだったので、libapreq / Apache::Request を使った時点でそのモットーが崩れるというのが私の意見。要するに libapreq / Apache::Request を使った時点で、複雑なウェブアプリケーションをmod_perlハンドラで書くという船出をしてしまったようなものと言えるかもしれません。

「単純なことをする」「疎結合である」という要件が満たされるのであれば、速度や可搬性を持った良いmod_perlハンドラアプリケーションが書けるでしょう。例えば簡潔なJSONを出力するAPIなどのようなもの。HTMLの画面を出力するサーバとは分離したApache/mod_perl世界があるときなど、こういう手法は悪くないと思います。将来の移植性に置いても心配はそれほど無いはず。

トークでは「$rは多機能過ぎる」という下りがありましたが、まさに$rはmod_perl1のオブジェクトという存在以上に「Apache1.3そのもの」であると言っても過言ではないでしょう。この「多機能」というキーワードには、モダンなフレームワークが持つコンテキストオブジェクトのような移譲による役割分担をせずに、$rだけであらゆることをやろうとするという雑然としたメソッドの世界観を含んでいると感じました。また「ブラウザからのHTTP接続の切断」といった状況すら検知できる(皆さんがお使いのHTTPサーバやフレームワークではできますか？)という意味での強力さに手を出してしまうと移植性が途端に低下してしまい、Apacheロックオンの危険性を感じる立場もあるでしょう。

mod_perl1ハンドラは、いわばC言語を使わずPerlを使って書かれたApache1モジュールそのもの。サイトexample.jpの画面とロジックを作るとき、mod_examplejp.cを作ろうと普通の人は考えないのと同じ理由で、mod_perlで画面とロジックを書く事は迷宮への入口を思わせます。HTMLの画面としてのレスポンス結果を作成するのは、mod_statusくらいのHTTP GET単発画面を出す程度の簡単さがギリギリラインかなと思います。そうでなければ移植性を考えてPerl CGIを書いた上でmod_perl高速化環境を使うか、この層を抽象化したフレームワークを使いたいところです。

後半のSledgeをPSGI化する話。実際にSledgeを使ったアプリケーションを書いたことは無かったのですが、私が当時mod_perlハンドラを学び始めた頃の活きた教材がSledgeでした。

標準のSledgeはPerlの永続プロセス手法としてmod_perl1(2ではない)以外のバックエンドを持っていない事がまず問題です(CGIは非永続プロセス手法なので考慮外)。SledgeをPSGI化する外部の試みのいくつかも、大規模サイトに投入するにはネックとなることがトークで語られていました。

余談ですが、SledgeのAPI自体も非常にmod_perl1の影響を受けているようで、コンテキストオブジェクト (という名前が正しいのかな) のメソッド名はmod_perl1のリクエストオブジェクトのメソッド名を築一参考したと容易に推測可能なものです。これは、当時よくHTTPリクエストを抽象化していたものがCGI.pm以上にmod_perlのリクエストオブジェクトだったから、それ以外の実装がなかったから、という理由なのでしょう。当時「HTTPリクエストの抽象化」を意識できる教材は、SledgeかJavaのTomcat、Strutsくらいしか無かったような気がします。このような先人の苦労が今のPlack::Requestに結実していくのです。

トークでも語られましたが、Sledgeのmod_perl1部分はApacheオブジェクトは当然として、なんとそれの進化系であるApache::Requestに完全に依存しています。まずフェイクオブジェクト(のようなもの)を作成するという @lestrrat さんの作戦は、問題解決への鋭いアプローチだと感じました。

$r->status(200) + return 404 のくだりは私も理解が足りない部分だったのですが、エラー時にmod_perl1がヘッダ類を出力するときの癖というのは結構あります。Apache1.3コアのErrroDocumentディレクティブもそうですが、エラー画面を出力するという処理には内部リダイレクトという処理が関わってきて、それがApache1.3/mod_perl1上でのヘッダ処理をややこしくしているのではないかと感じています。私の定石は「$r->status()は使わない」「$r->send_http_headerをしたあとでステータスコードをreturnする」です。確かに $r->status() を使うと変な事が起こりがちかも。

Plack化の最初でパフォーマンスが落ちたという話。Plack::Request中でクエリ引数処理が重かったとのこと。Plack::Requestのクエリ引数のパース処理はPure Perlだったと思いますが、mod_perl1は古ぼけていていもクエリ引数のパースはmod_perl1のネイティブAPIがやるので爆速なはずです(libapreqを使う使わないに関わらず、内部的にはC言語での実装です)。

トークで語られたような当時のPlack::Request中にあった重複処理などを改善していく話はエキサイティングでしたね。そもそも、Plackの目的がパフォーマンスよりもPSGIのリファレンス実装やPlack::Handler::*によるウェブサーバの差異の吸収といった部分を優先している(ように見える)ことからも、見逃されていた重複処理があっても仕方が無いかなという気はします。クエリ引数のパース処理が目に見えてパフォーマンスにおいて支配的になるのは大規模サイトだということも、今まで見逃されてきた(?)一因でしょう。こういう観点からも、Plackの大規模サイトへの投入は興味深い事例だと感じました。

ここまで長々と私の解説を書いてみましたが、誤解や間違いがありましたらご指摘下さい。

両方のトークを比較する

長文での説明でしたが、私のトークと @lestrrat さんのトーク、対立するものではなく、向いている方向が違うという感じなんですよね。

  • @xtetsuji のトークは最新のPerlとmod_perl2の先端を使い尽くす
  • @lestrrat さんのトークは太古のPerlとmod_perl1の呪縛から解放する

そういう意味では、両方のトークを聴講した方が、mod_perl というものをどう受け取ったのか、興味深い部分ではあります。

聴講中に

[tweet http://twitter.com/xtetsuji/status/381306340414476288]

なんてツイートをいただいてどうしようかと思いましたが、時間切れで質問タイムはナシ。でも聴講時の私の認識は今よりも甘く、結果的に質問しなくて良かったかなと感じています。

@lestrrat さんからは

[tweet http://twitter.com/xtetsuji/status/381297867916185600]

と返していただいて微笑ましい感じでした。トーク後に10秒ほど会話をさせていただきましたが、両者の考えが互いに良い意味で伝わったような気がします。対立関係じゃないですよ！(笑)

今もmod_perlを採用している人達からの声とそれへの返答

その後、後夜祭などで声をかけてくださった方で、今も業務でmod_perl1アプリケーションを動かし続けている方が結構いることに驚きました。「動くものは触らず」の原則はあるでしょう。それについては否定できません。ただ、古いものを使い続けることへのある種の漠然とした不安を持っているという印象を覚えました。今回のレガシーな話のトークの影響も少なからずありそうです。

私が業務でmod_perl1からmod_perl2へマイグレーション作業をすることになったのは、Ops側が最近掲げた「Debian stable付属パッケージを全ての拠り所にする」というポリシーが大きいです(他にも細かな理由はありました)。Debian stableは既にApache1.3/mod_perl1を外してしまったため、マイグレーションの必要性があったわけです。私はDebian原理主義者的な部分があるほどのDebian好きなので、このポリシーには歓迎をしていて、ブランチを切って一気にマイグレーション作業を完結させました。

ただ、mod_perl1/2の知見が少ない企業が、今も引き継がれ残るmod_perl1アプリケーションをmod_perl2にマイグレーションすることは現実的ではないと感じます。mod_perl1→mod_perl2はApacheのモジュールAPIに対応するように、ある種のAPIの断絶があります。作業としては楽なものではなく、Plack等の別の基盤に載せ替える作業と大して変わらない作業量かもしれません。そうであればPSGI化するほうが良いに決まっていることは前段で述べた通り。

私、ネタとして「mod_perl芸人」的な部分を狙っていると言われればそうなのですが、ビジネス上大事な場面や商用環境でまで何でもmod_perlという立場ではありません。何でも適材適所というのは上述でも繰り返していること。むしろ、最近は業務でも個人でも、ネタ以外でmod_perlプログラムあまり書かず、AnyEventやMojoliciousを使うことが多いんですよね。まぁ、デプロイは慣れたApache2とmod_perl2(Plack::Handler::Apache2)を使って…ということはありますが、MonocerosのコードリーディングをしたりNginxのHttpPerlModuleを調べたり、そういう方向への研鑽も続けています。

ただ、せっかく得たmod_perlの知識。mod_perlを何かにマイグレーションしたい方や、mod_perlアプリケーションを何らかの理由で保守したり新規開発したりといった方へのアドバイス等に活用していきたいと考えています。@xtetsuji や @mod_perl_info にお気軽にご相談ください。

これからどういう活動をするの？

嬉しいことに「mod_perl芸人」はそこそこウケがいいので、小さな場では時々ネタを披露しようと思います。あと前述のようにレガシーに悩んでいる方のために、Apache/mod_perlのウォッチ活動は続けていきたいと思っています。リクエストがあれば、トークやマイグレーション等のアドバイスなどの活動は積極的に行っていきます。ブログなどのネット上でも細々と活動していくつもりです。

私は「新しいもの=善、古いもの=悪」という図式には完全には賛同できない部分があります。初学者の「CGIでゴメンナサイ」発言だなんて「大規模になって立ち行かなくなったときに改めて考えればいいのであって、まず動くものが作れる事がまず大事ですよ」「フレームワークは余裕があれば」と声をかけることもしばしば。それとは同時に、Perlの歴史が長いことで、古い真の意味で廃れた情報が未だに現役の如くネット上に残り続ける負の側面も知っています。何が良くて何が悪いのか、何が正しくて何が正しくないのか、そういう部分も意識して、誤解がないように各スキル層へのアプローチをしていきたいと考えています。

[tweet https://twitter.com/xtetsuji/status/395061721900920832]

Mojolicious飲み会等、新しい試みもしています。私の新しい側面にもご期待いただければと思います。

「来年のYAPC」(期待)のような大きな場での発表は、特段リクエストがなければmod_perlトークはしないかなと思っています。さすがに3度目は無いかなぁと。MPMは別として、APIとしてのApache2は既に枯れており、2回のYAPC壇上で話した内容が大枠の説明を網羅していることでしょう。

今年の YAPC::Asia Tokyo 2013 でも様々なジャンルのトークが行われました。Perlというプログラム言語の可能性は広く、これからも広がり続けることでしょう。そのための力となるべく、様々な事に取り組んで、微力ながらPerlというプログラム言語でありコミュニティを盛り上げていきたいというのが、私の今後の活動だと認識しています。

これからも精力的に活動していきますので、どうぞよろしくお願いします！

YAPC::Asia Tokyo 2013 ハッカソンとその後 #yapcasia

コメントを残す

おがた (@xtetsuji) です。

YAPC::Asia Tokyo 2013 後日編。その他の「YAPC::Asia Tokyo 2013」関連記事は目次ブログ記事からどうぞ。

ハッカソンに行くまで

YAPC::Asia 2013 Hackathonのページに書いてある通り、「例年はスピーカーならびに、スピーカーの招待者を基本有参加資格者としております」と書かれたイベント。私もトークをしたスピーカーの一人であるので有参加資格者ではあったのですが、どんな場所か分からず、出ようかどうか前日からさんざん迷っていました。

当日は疲れて動けないということもなかったので、とりあえず外に出て別の場所に行っていましたが、行こうかどうか悩んでいたものの、@YappoさんからMentionをもらって、行こうと決めていざフリークアウトへ行きました。

ハッカソンに行ってみた

表参道駅までやってきて、フリークアウトのオフィスが入っているビルを探してやってきました。恐る恐る入り口を開けると、そこは広大かつ綺麗なオフィスと、名だたるPerlハッカーの皆さんが各所で静かに黙々と作業をしている光景。

Foursquareにもvenueがあったので当然チェックイン。

メイヤーは @hiratara さんでした。

[tweet https://twitter.com/xtetsuji/status/381657005502390272]

オフィスが広大で綺麗なところに感動しました。特に感動したのは無限水、そう、自由に無料で飲めるミネラルウォーター。よく「その会社の福利厚生はミネラルウォーターを提供するかで表れる」と言われることがありますが、ここにはその夢の無限水があったのです。すごい！それだけでなく、カップのジュースやスープの自動販売機があったので、何か飲もうとお金を投入しようとしたら何と無料。ボタンを押すだけでジュースやスープが出てくる！すごいすごすぎる！どこからどこまでも夢のオフィスでした。しかも飲み物だけでなく、自由に食べても良いお菓子まであるという！オフィスグリコとか目じゃないこの太っ腹さ。感涙ものです。

写真を撮っていいものか、みんな真剣に作業をしている感じで聞きづらかったし、何しろお邪魔している他社様のオフィスなので、写真はほとんど撮りませんでした。撮影OKだったら記念に撮っておけばよかったな。

しかも、冷蔵庫にはビールがあるから自由に飲んで下さいとのことで、もう気分は最高潮。

[tweet https://twitter.com/xtetsuji/status/381672497642364928]

皆さん一箇所に固まらず、バラバラに座っている感じではあったのですが、私が座った席のテーブルの右斜め向かいには@miyagawaさんがいらっしゃって、黙々と作業していました。なんという豪華な空間！

私がしていた作業は、とりあえずYAPC感想ブログ第一弾を書いて…といったところで、その後は未完成だったmod_perl2で動作するmemcachedサーバであるModPerl::Memcachedを作っていたのですが、ビールを飲んだところで疲れと眠気が出てきて、ここからは眠気との戦いになってしまいました。眠気覚ましに立って歩いていても、皆さんお疲れの模様でした。さすがに3日間ぶっ続けのYAPC::Asiaでしたから、疲れが出て当然ですね。

結局、私の手元では眠気が邪魔して単純なミスに気づかず、memcachedサーバの実装は全然進まなかったのですが、各所ではPlackの実装についての議論が交わされていたり、第一線のPerlハッカーが一箇所に集まって作業をした成果が出ているようでした。Plack::Request::WithEncodingも、この場で@miyagawaさんや@tokuhiromさんが@moznionさんと議論をしながら骨格が作られたものです。

ハッカソンというものに出ること自体が初めてで、こういう空間はもちろん初めてだったのですが、第一線のPerlハッカーに囲まれて作業するだけでも刺激的な数時間を過ごすことができました。少し悩んだけど、勇気を出して(?)出て良かった！

会場のフリークアウトさんの写真は全然撮れませんでしたが、@941 さんのブログの行ってきた記事を見てみると雰囲気がわかるかと思います。

会場を提供していただいたフリークアウトさん、本当にありがとうございました！終始感動しっぱなしでした。

タイムテーブルでは23時まで続くと書かれていたハッカソンでしたが、19時くらいには「そろそろ食事へ…」という雰囲気になって、お開きになりました。

ハッカソン懇親会

ハッカソンの懇親会は、フリークアウトさんのオフィス近くのもつ鍋屋に来ました。

昼間からビールを飲みながらコードを書いていたわけですが、ここでもビール。美味しい鍋を食べながら会話が弾みます。

私の席は、鍋をどうすればいいかアタフタしていたら、@charsbar さんに色々と面倒を見てもらうことになって、なんだか有り難いやら申し訳ないやら。豪華なメンバーしか集めていないハッカソンだけあって、どこの席も豪華なPerlハッカーです(私という平凡なPerlプログラマ目線)。ここでもPerlやプログラム言語全般についての話が盛り上がりました。刺激的な空間です。

YAPC::Asia 開催中にもすれ違っていたはずなのですが、初めて @__gfx__ さんとお話ができました。色々な優秀で著名な方の話を聞くと、見聞が広がっていいですね。

YAPC::Asia Tokyo 2013 その後

今回、挨拶や有名人見たさの野次馬以上に、実質的に初めて本格的な議論を交わしたPerlハッカーの方々も多く、出会いって大切だなと感じると同時に、今後とも情報交換など良好なお付き合いをしていきたいと感じました。そのためには自分自身もその目線まで上がらなければと感じた数日間。ギブアンドテイクの世界、私もPerlの世界に多少なりとも貢献出来るよう、これからも頑張っていくぞと、やる気をもらえたYAPC::Asiaとハッカソンでした。

「来年のYAPC問題」については、別記事でも何回か書いた気がしますが、特に心配しなくてもいいんじゃないかなと思います。もちろん、誰かが発起して協力を求めるのであれば、出来る限りの協力をしたいと考えています。みんなでPerlを盛り上げていきたいです。

私のその後は「YAPC燃え尽き期」か、しばらくは疲れた感じで惰性で(?)9月を過ごし、10月へ入っていくことになるのでした。10月に入ってから、この記念すべきYAPC::Asia Tokyo 2013を記録に残すべく、少しずつ振り返りブログ記事を書いているといった感じです。

あ、そういえば、1日目の懇親会で出会ったMojolicious仲間と一緖に、その後9月25日に「Mojoliciousやmod_perlを話題にした飲み会 #2」を開いたのでした。この会自体が @jamadam さんが東京にいるときに開こう的ノリなのですが、今後も継続して開催していきたいと感じました。Mojoliciousユーザ、結構たくさんいるという印象を今回のYAPCで持ったものの、横のつながりがなかなか出来ていなくて、情報交換の場がもっとあってもいいかなと。

10月も後半になって、YAPC::Asia Tokyo 2013から1ヶ月が経ち、個人でのプログラミング活動も徐々に盛り上がりつつあります。これからも何かあったら当時のアツい日々を思い出して、自分自身のプログラミング活動の活力としていきたいと感じました。

YAPC会期中やその前後で、色々な新しい企画への誘いもあったり、自分自身でもこんなイベントが欲しいというアイデアが色々出ました。疲れを取って落ち着いた後は、また面白い日々が過ごせそうです。

本当に良いイベントを前夜祭からハッカソンまで、通算4日間、存分に経験した2013年9月。これから「次のYAPC」まで、この体験を思い出して頑張っていけそうです。微力ながら、私も未来を切り開いていく一人として邁進していきたいと心に誓いました。

YAPC::Asia Tokyo 2013 2日目 #yapcasia

1件のフィードバック

おがた (@xtetsuji) です。

YAPC::Asia Tokyo 2013 2日目編。その他の「YAPC::Asia Tokyo 2013」関連記事は目次ブログ記事からどうぞ。

聴講したトークなど

列挙していきます。

トーク雑感

@yusukebe さんのMojoliciousトーク、相当期待していたのですが初心者向けで、多くは既に知っていることが多かったです。とはいえ振り返りができたり、自分が取っていた手法は間違いじゃないんだということを確認できて良かったトークでした。@yusukebe さんには日本有数のサイト開発運用経験を元にMojoliciousの書籍執筆を期待したいです。絶対買います。

@goccy54 さんの「これからのPerlプロダクトのかたち」は、昨年の氏のトーク同様、多くの注目が集まっていました。gperlの構文解析の成果を現状のPerl5にポートして、それによってiOS開発ができる(RubyでいうRubyMotionのような)PerlMotionを作成中という話も期待が持てます。すでに構文解析の成果をPerl5で実現したモジュールは各所で使われており、PPIより速いと好評のようです。さすがPerlを根底から理解しようとした強者ならではのトークでした。

@typester さんによるEmacsの話は、Emacsユーザとして初歩的ではあったものの、いまどきの流行を知ることが出来て良かったです。anything.el すら面倒で入れていなかったのですが、今はまた別のブームがあるようで、まだCarbon Emacsの環境をCocoa Emacsに作り替えるタイミングで、スライドを見ながら大いに参考にしようと思っています。

@lestrrat さんによるレガシー話。Apache1.3+mod_perl1+Sledgeという構成のlivedoorBlogをPSGI化したという話でしたが、40分まるまるmod_perl disで、前日にmod_perlトークをした私は終始ハラハラしながら聴講していました。とはいえ、どこに真意があるのかはmod_perlをかなり使っている私は分かっていて、同意することしきりではありました。

壇上でmod_perl disが繰り広げられているときに、こんなツイートをいただいて、どうしようかなって思ったり。結局質問タイムが無くて公開の場で質問する機会は無かったのですが、結果的にそれで良かったかなと思っています。

会場で爆笑していた人がたくさんいましたが、何がダメだったのか、本質を見抜いていた人はどれだけいたのかなぁ。これについても語ると長くなるので、別ブログ記事で解説したいと思っています。

@maka2_donzoko さんによるボードゲーム話、「サラダ枠」とのことで、毎年楽しみにしている枠でもあります。今年も本当に面白かった。JSON::PP などの重要モジュールのメンテナーでもあるまかまかさんですが、人を楽しませる心意気には感心することしきりです。このトークは動画もスライドも、見たら元気が出るトークです。

PhantomJSの話、以前から気になっていたJavaScriptプロダクトだったので、結構興味深かったです。Seleniumとどういう違いがあるのかな…未だに理解不足な部分が多いですが、とっかかりとしてPhantomJSをいじってみようというキッカケになったことは良かったです。

@myfinder さんの、フルテストも50msec話は面白かったですね。日々増えるテスト、さすがに50msecでは終わらないそうですが、それにしてもテストが根付いた文化というのはうらやましいというか私の境遇からは想像できないので、終始感心しっぱなしでした。テストがあるおかげで安心してデプロイが出来て、新しいものを躊躇すること無くリリースできる好循環。モダンな開発環境が整った時代から始まった会社とはいえ、さすがフリークアウト。

LT雑感

1日目に続き、2日目のLTも盛り上がりました。こちらも、5分弱の録画ビデオが公開されているので、1日目同様、笑いたい時、楽しみたい時に見返すとよいかもしれません。

印象に残ったLTから抜粋してご紹介。

  • 今年のPerl同人活動報告 と銘打った @maka2_donzoko さんの同人報告。今年も大舞台で同人活動宣言。これは期待。
  • @azumakuniyuki さんの、JSONでメールが送信できるHainekoの話。とある要請で作ったようですが、当面メールが無くなることがないわけで、Ajaxなどを使ってメールを送信したいという要求を満たすことができるのではないでしょうか。興味深いです。
  • @barimi さんの「初めてのPerl ～ つぶやいてないでコードかけ ～」。@yusukebe さんを味方につければ素人でも5日でTwitterボットが書ける！冗談っぽい話ではありますが、人に聞くというのは大切なことですね。
  • @__papix__ さんによる「Perl入学式2013年度中間報告」。これからも期待しています。
  • @cubicdaiya さんによる Nginx に mbruby を組み込む話。Pixivでは Nginx+mrubyを精力的に使っているのでしょうか。なかなか興味深い。こういうトークも自然と受け入れられるところがPerlの祭典であってエンジニアの祭典でもあるYAPC::Asiaの懐深さなのかもしれません。mruby期待しています。
  • @takesako さん、今年は○×クイズでLT。いやはや、全員起立の参加型LTなんて初めてでしたよ。そして難問をクリアしたのがラクダ本の和訳をした近藤先生というのだから、なんというチート。面白かったです。

Keynote

LINE社の池邉さんによるKeynote。例年、この最後の枠はスピリチュアルというか、エンジニアという立場を俯瞰した視点でのトークがなされますが、今年もじんわりと響くトークでした。

池邉さんはlivedoor時代(もっと前?)から長く会社の技術を支えてこられて今の位置にいたりするわけで、業界の人間として何か感慨深いものがありました。大昔のYAPCで池邉さんのトークを聴講したこともありましたが、その時から立場が変わって、たとえ人の上に立つ立場となっても技術者視点を忘れないということは大切だなーと思いました。

Closing

例年のYAPC::Asia同様、牧さんによるClosing。今年の入場者数が1000人越えといった発表の後、牧さんと櫛井さんが今年でYAPC::Asiaの運営から卒業するという突然の発表。そして来年のYAPCは誰かが名乗りでないと開催されないという、さらに衝撃の発表。

しかしながら、地方でYAPCするぞというLTもあったり、今年の規模を越えることはできないにしても、来年のYAPC::Asiaは何らかの形で行われるのではないか、私はそう期待していますし、何か協力できることがあれば出来る限り積極的に協力していきたいです。

昼食

ちょっと時間を巻き戻して正午の昼食ですが、1日目同様2日目も学食へ行きました。慶応大学の学食、本当に安くておいしい。生活圏内に欲しいくらいでした。

昨日は気付かなかったけど、4sqにvenueがあったのでチェックイン。冷麺うまかった。

勝手に後夜祭

Closingの後、勝手に後夜祭に参加。

狭い店の中に60人以上が入って、鉄板の暑さと人の暑さですごいことに。ぎゅうぎゅう詰めの中、著名なPerl Monger達が立ったり座ったり暑い暑い言いながら懇親を深めました。

初期フードメニューはこんな感じ。食べ飲み放題でしたが、コナモノなのですぐに満腹になりました。

勝手に後夜祭の初期メニュー

そしてこの人のひしめき合う狭さ！

勝手に後夜祭の狭さ

あまりの狭さに懇親よりも「暑い暑い」と言っている時間が長かった気もしますが、それでも様々な方と会話ができたりして楽しかったです。金銭的時間的に余裕があれば、こういう場には積極的に参加したいですね。それだけ実りのある会話ができて、実りのある時間が過ごせます。

23時頃に解散。前夜祭も含めて3日間の疲れが出ないうちに帰宅となりました。

噂によると、八王子近辺在住のHachioji.pm勢はこの後、朝まで八王子で飲んでいたとか。すごい。

今後に向けて

3日間のYAPC::Asia Tokyo 2013の最後が「牧さんと櫛井さんのYAPC::Asia運営卒業。来年のYAPC::Asiaは誰かがやらない限り行われない」というものでしたが、きっと誰かがやってくれると楽観できるのは、この3日間で実感したPerlコミュニティの熱い想いがあるからでしょう。地域.pmもたくさん増え、それに伴って全国各地に心強いPerl Mongerが増えている現実もあります。東北勢も来年のYAPC::Asiaを東北でやりたいと名乗り出ました。YAPC::Asiaという名前のイベントや今回のような規模ではないものの、きっと来年も「YAPC::Asia」は行われる、そう信じています。

ひとまず前夜祭を含めて3日間の心地良い疲れを持ち帰って帰宅しましたが、実はさらに次の日に行われたハッカソンにも参加してきました。

というわけで、その後のハッカソンの話と、私のトークにまつわる話へ続きます。

YAPC::Asia Tokyo 2013 1日目 #yapcasia

コメントを残す

おがた (@xtetsuji) です。

YAPC::Asia Tokyo 2013 1日目編。その他の「YAPC::Asia Tokyo 2013」関連記事は目次ブログ記事からどうぞ。

オープニング、そして基調講演

前夜祭で遅くに帰宅して1日目の自分のトークの準備をしていたので、朝起きられるか不安でしたが、夢と希望の力で起きてオープニングには余裕で間に合いました。人間は夢と希望で活動していると実感した瞬間。

恒例の櫛井さんのオープニング。その後の基調講演。今回の冒頭の基調講演も前年同様英語のプレゼンテーションではありましたが、スライドが分かりやすかったのと、発音した英語が多少追えたので、なんとか楽しむことができました。Perl5.18の今や、これからのPerl5といったものが垣間見えて、これからの楽しみが増えました。

聴講したトークなど

列挙していきます。

トーク雑感

@kazeburo さんのMonocerosのトークは期待していたので、絶対聴講するぞと以前から思っていました。Monocerosというウェブサーバ自体の魅力の他にも、UNIX/Linuxでサーバを書くための作法というようなものも学べたのが良かったです。straceの出力を出して「これ読めますよね」という@kazeburoさん、さすがです。Monocerosのコードリーディングは細々と続けています。

学術分野におけるPerl、普段Perl入学式や地域.pmなどでお会いしている@__papix__さんによるトークでした。GPGPUを使った部分など、なかなか高度な事にチャレンジしているんだなと感心しきりでした。

普段はEmacs使いの私ですがVimにも興味があったので、Vimのトークを聴講しました。なかなか練られたプレゼンテーション手法に感心。後日公開されるスライドを読み返しながらVimの設定をしてみようと思います。

私自身のトークの振り返りは長くなりそうなので別記事で…。

@hiratara さんによる型付きPerlの話は、部屋があふれるほどの盛況ぶり。後ろの床に座って聴講していましたが、本当に難解でよく分からなかったというのが正直な感想。このあたりも勉強しないとなという意識付けが出来たのは良かったです。

次に聴きたいトークまで間があるし、多目的教室はいつも盛況で入れない状況だったので、しばらくロビー内などをブラブラしていました。ロビーの隅っこでは床に座り込んでparumonをしているHokkaido.pmの人たちがいたり、なかなかバラエティにとんだ風景でした。

床でparumon

@tokuhirom さんによるFuture Perlのお話は、午前中の基調講演とはまた角度が違った面白いトークでした。Perl6の実装は色々あれど、どれも開発フェーズが混迷していたり遅かったり使うのはちょっと…という印象を持っていましたが、Seisはなかなかいいところまで来ているという印象。私を含め、今まであまりPerl6に興味がなかった人もPerl6を使いたくなったトークではないでしょうか。前年のYAPCまでとは違い、今年はそういう未来についてのトークが熱かった印象。

@toku_bass さんのライブコーディングも会場が盛況。入場すら厳しい部屋から人があふれるほどの状況で、チラッと拝見しました。ただ、壇上に @toku_bass さんがいなかったにも関わらず、画面は進み声は聞こえるという不思議な光景。あとで聞いたら、立ちながらのライブコーディングは厳しいということで、最前列に座って作業していたとのことでした。今年のYAPCもPerl初心者中級者といった人が結構いたと思うし、そういう人にPlackの内部を見せながらウェブアプリケーションを書いていくライブコーディングは有用だったことでしょう。

LT雑感

LT1日目も盛り上がりました。タイムテーブルは公式Twitterで告知されているので、それに従って印象深いものを抜粋して振り返ってみようと思います。公式にビデオが上がっているものは、LTの時間制限の性質上、4〜5分で見られるものなので、何か愉快な気持ちになりたい時に、人生落ち込んだ時、ちょっと何か見て笑いたい時にも使えそうです。

  • ギークな異性を落とす魔法の言葉はネタ枠として大成功でしたね。200 OK
  • How to inspect a RUNNING perl processは既存のPerlプロセスを外部から観察する方法という込み入ったシステム的な内容でしたが、デバッグ時に参考になる部分も多く、今後この手法を使ってdaemonを開発したりしていきたいなと感じました
  • YAPC::NA 2013に行ってきたは、昨年ベストスピーカー賞を獲得した@yusukebeさんがそれでYAPC::NA 2013に行ってきた記録ですが、一度は海外のカンファレンスに行ってみたいと思わされたトークでした。英語の壁などありますが、金と時間があって行く機会を作れば乗り越えられそうな気が十分します。
  • んだっちゃだれ Sendai.pmは、今元気なSendai.pmの話。YAPC::Tohoku(仮称)の話も出てきて非常に盛り上がりました。東北は青春18きっぷで途中下車した盛岡くらいしか経験がないので、今度じっくり東北観光をしたい。
  • オープンソースプロダクトに貢献することはSixApartの方のトーク。一度movabletype (MTOS) をforkして、とある改良を入れようとしたのですが、どうしても克服できない点があって諦めた経験あるんですよね。でも行動に起こしただけ数年前の自分自身より進歩あるかなって思いました。
  • 1日目LTのトリである2013年代のBlogツールRijiの紹介は、もう@songmuさんの突然の中国語トークに全てを持って行かれた感がありますね。「YAPC::Asia なんだし例年台湾等からも聴講者が来るわけで、日本語以外のLTがあってもいいじゃない」という考えには大いに同意であります。いやはや、これは一筋縄では真似できない偉業です。

会場の雰囲気

このあたりは櫛井さんのブログが非常に詳しく写真も綺麗なのでそちらを参照していただくことにして、私が撮った数少ない写真からいくつかピックアップ。 各トークについては原則的にYouTubeで動画が公開されているので、そちらを参照すると雰囲気が分かると思います。

個人スポンサーの提灯

個人スポンサーのちょうちん。私のものも飾られていて「お〜」ってなりました。その後、2日目の終盤に持ち帰りました。

昼食

2日目もそうだったのですが、1日目もHachioji.pmあたりの人と集まって、生協の学食に行って食べました。安いしうまい。 YAPC自体に慣れてきたからか、外がそれほど暑くなかったからか、トーク会場との移動にそれほど困難を伴わなかったのも良かったところ。

懇親会

2007年から2010年まではボッチで食事だけして帰ってくる懇親会でしたが、2011年夏のHokkaido.pmとの交流開始から3年弱、Hachioji.pmにもよく顔を出すことにしていたら知っている人が増えて、この場が色々な場から集まる人達が一堂に会する同窓会的場所になってきました。

個人的にも長年のボッチ体験を回想して、ポツンとしている人やグループを見かけたらなるべく話すようにしましたが、私自身へ声をかけてくれる人も結構いたりして、色々限界もありましたが、多少のボッチ対策には貢献できたでしょうか。Mojoliciousを使っている会社の方々のグループがあって、数人の方とはPerlBeginnersかPerl入学式で面識があったのですが「@jamadamさんに会ってみたい」と言われたので、探して引きあわせたりしました。それが後日のMojolicious飲み会につながったりもしたので、なかなか有意義だったと思います。

それだけでなく、今年は勇気を出して@miyagawaさんにも話しかけて、Plack::Handler::Apache2まわりの話の質問を投げかけてみました。勇気を出した割には意外に気さくに受け答えしてくれたので、自分が無意識に作ってしまっている「著名な成果を出した人への心理的障壁」を感じましたね。消極的なの良くない。拙作のModPerl::PSGIについても、名前の良し悪しといった評論をしてもらって、非常にありがたかったです。先日のHokkaido.pm#10の時にゲストで来た@tokuhiromさんと話した時もそう思ったのですが、そういう殻はどんどん打ち破って話しかけていくべき、そう感じました。 そういう意味では、英語コンプレックスから、海外より来日したゲストの方々と話せなかったのは数少ない心残りな点でした。

懇親会の食事1 懇親会の食事2

 大人のYAPC

こちらにも申し込みをしていましたが、これは「ヤバい、面白かった」としか書けないです。守秘義務があるので。でもこういう試みは絶対求められていると感じた次第です。この独立イベントを手配してくれた@lestrratさんと@yusukebeさんには感謝です。

時間的に懇親会とかぶっていたので、懇親会を途中で抜けて、途中から大人のYAPCに入った感じでした。もっと懇親会を楽しめればよかったなという気持ちと、大人のYAPCを最初から聴きたかった気持ちが両方。両方とも稀有なイベントゆえですね。

飲み会

その後、1日目の自分のトークが終わった開放感からも飲みに行こうと思い、会場の1階にあるHUBに行って飲みました。さすがというくらい、様々なPerl Mongerが集まっていて非常に刺激的な場所でした。これぞYAPCという光景が確かにここにありました。

この場では、Hachioji.pmの人々と歓談したり、Hokkaido.pmの人達もいたので話したりしました。有用なメール関連ツールを精力的に開発している京都の @azumakuniyuki さんとお会いできてお話できたのは大きな収穫でした。その後 @azumakuniyuki さんから「Hokkaido.pm の @aloelight さんいますか？」と言われて「あぁ見かけましたよ、こっちです」といった感じで新たな接点が生まれたり、適度にPerl Mongerが密集した良い場となりました。

その後、終電が近い人から徐々に解散していき、私も23時30分には電車に乗って帰路に付きました。

2日目に続きます。

YAPC::Asia Tokyo 2013 前夜祭 #yapcasia

コメントを残す

おがた (@xtetsuji) です。 YAPC::Asia Tokyo 2013 前夜祭編。その他の「YAPC::Asia Tokyo 2013」関連記事は目次ブログ記事からどうぞ。 写真があればいいんですが、写真を撮るのが下手なので、あまりありません。公式サイトから大量の公式撮影写真が見られると思うので、雰囲気を感じるのであればそちらを参照ください。特に前夜祭の場合はイベントホールの雰囲気と「LTソン::Tiny」ですね。

入場まで

会社を16時過ぎに出て会場には17時30分頃に到着できるようにして余裕を持たせました。ただ、開場の18時がズレこんでロビーで多少待たされることに。とはいえ、当日(1日目)の混雑を前日に分散させるという意味ではこの前夜祭受付の試みはいいですよね。 待ち時間は、各地の*.pm(ほぼHokkaido.pmとHachioji.pm)の方々などと懇親(雑談)していました。 受付を済ませて、会場の床に座って斬新なカードに自分の所属ジャンル？のシールを貼る作業。そしてイベントホールの場所を確認して移動しました。

無限(?)ビールでのおもてなし

例年の前夜祭は、半ダースの350ml生ビールがそこかしこにあって自由に飲んでもよいという状態だったのですが、今年は生ビールの缶がテーブルに綺麗に整列されていて、さらによい環境となっていました。そして、LTソン::Tinyの会場として、イベントホールは机が整列され、さらには前倒しで用意された(本来であれば1日目からの予定だった)Wi-Fiまで完備されているという絶好の環境。ツイートし放題！ カウンターで350mlのビールを一缶もらって席につきます。 前夜祭の缶ビール俯瞰 その後、LTソン::Tinyが始まります。 写真は @equinox79さんが撮影した写真がとても雰囲気を表しています。 また公式 @yacpasia でも前夜祭の写真がアップされています。

LTソン::Tiny

私のエントリでは、ざっくりと取ったメモを残しておきます。メモというよりは、誰が発表したかくらいしかメモっていなくて、内容はほとんどないので、gihyo.jpさんのレポートも合わせて読むと良いと思います。

  • 継続可能な勉強会を支える技術
  • ほっけみりんさんの千葉.pmと自己紹介
  • Apache::LogFormat::Compiler: @kazeburo さん (ベストエルティニストでした)
  • Seleniumで捗る話: @__papix__ さん
  • サンフランシスコのIT企業: @yusukebe さん
  • @tomcha_ さん
  • 猫と色々(BounceHammer / Haineko / Acme::Nyaa / Nekoproxy): @azumakuniyuki さん
  • Excel方眼紙撲滅委員会活動報告2013.9: @tk0miya さん
  • @dameningen さん
  • ふっふはっほ: @dokechin さん
  • 日吉とラーメン: @bayashi さん
  • Mojo::UserAgentかわいい: @turugina さん
  • Mooseとその周辺の今とp5-mop-redux: @tokuhirom さん
  • エンジニア業務と忍術: @tomita さん
  • @tagomoris さん
  • Perl for beginners: @coji さん
  • ギターの話: @itrysd さん
  • PeaTiXの長い一日: @aklaswad さん
  • Social AppのFlash事情: @karupanerura さん
  • Riji使ってみた: @koji_magi さん

 その後

21時までに撤収とのことだったので、LTソン::Tiny発表者が全員発表した後、即座に会場を出ることに。座った席がど真ん中だったので、結局ビールは一缶しか飲めませんでした。 その後、私はHokkaido.pmの人達と合流して、久々(といっても1ヶ月ぶり)ですねといった話をしながら、日吉の定食屋に入って食事をして(アルコールは明日もあるしもういいって感じになっていた)、その後明日に備えて解散しました。

前夜祭、昨年初めて出て、前日から感じるその熱気に魅力を感じて今年もやってきたのですが、いやはや今年もそれを裏切らない熱気でしたね。 今年の「LTソン::Tiny」は、昨年のカジュアルに離席が可能で会場の収容人数も少なかった「LTソン」と比較すると、規模もケタ違いの聴衆が集中して、昨年のLTソンの雰囲気を想定して準備してきた一部の人は面食らったようです。あれは1日目2日目の通常のイベントホールでのトークより人いるから、緊張は数倍だろうなーって思いました。

司会の @uzullaさんとLTソン::Tinyのスタッフとして準備していた皆さん、そして発表者の皆さん、お疲れさまでした。そして前夜祭から楽しい催しありがとうございました。 1日目に続きます。

YAPC::Asia Tokyo 2013 に参加してきました #yapcasia

コメントを残す

おがた (@xtetsuji) です。

とりあえず「ブログを書くまでがYAPC」ということで、開催中はバタバタし過ぎて書けなかったブログ記事を徐々に書いていきます。一つのエントリが長くなりすぎると読みづらいかなと思うので、いくつかの記事に分けて書きます。

この記事自体も後で多少加筆修正をしたりすると思います。

自分とYAPCの今まで

このエントリを読んでいる人は分からないかもしれないので、自分とYAPCの関わりを列挙しておきます。

  • YAPC::Asia Tokyo 2013 は 2007年から毎年参加
  • コミュニティへの参加は積極的では無かったけど、YAPC::Asia Tokyo だけは会社の後輩を連れて行くようにしていた
  • 2010年までぼっちが続く。今のような「ぼっち防止企画」とかも無かったし、今よりずっと内気だったので、懇親会も単に「後輩と一緖に食事して帰ってくるだけ」に近かった
  • 2010年に地元北海道帯広市のスカイアークがYAPCのスポンサーになっているのを発見してスカイアークに興味をもつ
  • 2010年のゴールデンウィークの帰省中にスカイアーク会社訪問。@onagatani さんに熱烈歓迎を受けて2011年7月の Hokkaido.pm#5 で地域.pm初デビュー & トーク初デビュー(20分)
  • 主に各地のPerlの勉強会(Hokkaido.pm、Hachioji.pm、PerlBeginnersなど)を中心にトーク経験を積む
  • 在籍している会社を説得して、2011年から協賛スポンサー企業デビュー。今年で3年目
  • 2011年はHokkaido.pm勢のYAPCトークデビューを見て「自分もいつかは」と思う
  • 2012年のYAPC::Asia Tokyo 2012で「モダンmod_perl入門」でYAPCトークデビュー
  • 今年2013年のYAPC::Asia Tokyo 2013で「Apacheの展望とmod_perlの超絶技巧」というトークを発表

 全体的な感想

もうとにかく楽しいといか言いようがないですね。日本のカンファレンスの中で一番面白いのではないかと言っても言い過ぎではないくらい。トーク本編だけでなく、屋台が出ていたりBOFやランチカンファレンスといった企画があったり、様々な工夫がある。

年々楽しくなっている要因は、自分の変化もあるし、そしてYAPCの変化もあるのだと思います。

前述のように2010年までは事実上ぼっち状態だったので、トークに刺激を受けつつも交流という部分ができずにいました。ただ2011年以降は地域.pmやPerlBeginnersやPerl入学式などといった小さな場所で交流を深めて、さらにTwitterなどを使って互いに知った仲間を増やしたりして、「YAPCを同窓会の会場にする」という事を実現していきました。

自分の4年ぼっち経験を回想して、なるべくぼっちの人を作らないように努力したつもりです。Perl入学式やPerl Beginnersで顔を知った数人と、Hokkaido.pmやHachioji.pmの人を対面させたりしたりといった感じ。もちろん、数人をフォローした程度ですし、自分自身の懇親もあったので気が回らなかった部分も多かったように思えます。

またYAPC自体も、ぼっち防止企画やBOFなどの交流企画を続々と投入して、みんなで楽しめるイベントに年々成長していっているなということも感じました。

交流の難しさ

前段で「ぼっち防止対策」の話をしましたが、自分はどうだったかというと、満足半分反省半分といった感じでした。

Twitterや他のブログを読んでいると「日本人は真面目にトーク聴き過ぎるので、Hallwayをもっとすべき」といった話もありました。特に痛感したのは、せっかく来日した海外からのスピーカーと話せなかったこと。自分が英語に対してコンプレックスを持っていることもあって、ここは例年の課題を今年も解決できなかった部分で、大いに反省したいところです。英語力強化というよりも英語を話すことに対しての抵抗感を無くしていかなければならないなと痛感。

自分の場合は、2011年から「地方.pm等の各地の小さいところで顔見知りを作り、YAPCは彼らが一同に集う同窓会的な場所にしよう」としていたのですが、YAPCでしか会えない人もいるわけで、これも正解とも不正解とも言えない難しいところ。今年は例年以上に多くの人と会話をして懇親をしたつもりですが、なかなか交流って難しいと痛感した次第です。

YAPC::Asia のこれから

今年のYAPC::Asia Tokyo 2013のクロージングでの突然の告知、牧さんと櫛井さんのYAPC運営からの卒業。そして「来年のYAPC::Asiaは無い」という話。驚きました。そして今までお疲れさまでした＆楽しいイベントを提供してくださってありがとうございます。

ショックではありましたが、Perl入学式やPerlBeginnersなどの初心者イベントの充実、それに地方.pmの増加など日本を取り巻くPerlコミュニティは全国的に盛り上がって来ている感じはします(他の言語でもそうなのかもしれませんが)。

以前だってShibuya.pmからJPAにYAPC::Asia Tokyoの主催が移管されたりといったことがありましたし、今年の壇上で東北の方が「来年は東北でYAPC::Asiaやる！」と言っていたり、今年ほどの規模ではないかもしれませんが、来年もYAPC::Asia *** といったイベントが開かれそうな気はします。1000人以上も参加した今年、きっと誰かが発起してくれるのではないでしょうか。

Perlのこれまでとこれから

だいたい季節の変わり目、3ヶ月に一度くらいはネットで「Perlは終わった言語」というFUDが吹き荒れます。最近では慣れっこになった感もありますが。でももしPerlが本当に終わった言語であれば、なぜYAPC::Asia Tokyoが他のLLカンファレンスを越える日本最大規模のカンファレンスとして年々成長していっているのか。まさにFUDな証拠。

とはいえPerl5には至らない点が諸々あることは事実です。しかし色々な方々によって改善が進んでいて、Perl5.xxのマイナーバージョンは成長していき、Perlコアの不便を補うPerlモジュールもたくさん開発されている。色々な理由でPerlは愛され続けています。

もちろん、後発のLLや他の言語がPerlを参考にして作り出され、当然のようにPerlより良い言語になっていることは確かです。私もRubyの構文で魅力的だなと思う部分は結構あります。私は、あれもこれもと手を広げすぎるとダメなパターンの人間なので、それなりの選別をしつつも、他のプログラム言語もほどよく取り入れていける人になれればいいなと思った次第です。

トークを応募してから採択され、準備をし、9月のYAPC::Asia Tokyo 2013まで色々と準備をしたりしました。8月は少し忙しかったし9月のYAPC直前までは体調不良で結構つらかった。でも3日間のYAPCは疲れを吹き飛ばすくらいの面白さだったし、終わってみると一瞬だったなって感じます。時が過ぎるのは早いです。今年もあと3ヶ月、色々な目標を立てて実現しこうと思います。そしてまだ幻の「YAPC::Asia *** 2014」に向けて…。

個別の日程の感想や自分のトークの総括といった内容は、上述の通り、別エントリで書こうと思います。