タグ別アーカイブ: perl

穏やかな速度でファイルを削除するプログラム gentle_unlink を書いた

おがた (@xtetsuji) です。

Linux サーバ上で作業をしていると、様々な一時ファイルがディスクを圧迫していて、ディスク容量を増やすために削除を行うことがあります。通常であれば rm コマンド一発で終わる単純なファイル操作ですが、ファイルが何百万やそれ以上といったオーダーで大量にあると、削除自体のコストが無視できなくなります。

Linux サーバ管理者の間ではたびたび問題になる大量ファイルの削除操作、各人コマンドを組み合わせて工夫しているようですが、より微調整をしたかった私は Perl を使ってコマンドを書くことにしました。その名も gentle_unlink。

最近はITエンジニアリングネタは Qiita に書くことが多いのですが、自分が書いたまとまったプログラムの紹介ということで、メインブログに書いてみることにしました。

初出の社内勉強会での紹介トーク、そしてスクリプトファイルは以下のリンクからどうぞ。

続きを読む

mod_perlプログラマーが飲み会で語るレガシー開発論

おがた (@xtetsuji) です。

2015年4月3日(金曜日)、1社目で最後まで一緒に働いていた後輩と二人で久々に飲み会をしました。そこで考えて語ったレガシー開発論など、公開しても良さそうなところを書いてみます。私は2014年1月に退職していますが、後輩は今も在職しています。

書きたいことはざっと書いたのですが、推敲がうまくできなくて長文になってしまいました。暇な時に流し読みしていただくのがちょうどよいかもしれません。長いブログ記事、Kindleで電子出版したほうがいいかもしれませんね…。

執筆依頼やモジュール類のドキュメント化依頼は随時受け付けていますので、この勢いで文章を書いて欲しいという方がいらっしゃいましたら、ぜひご依頼ください。

続きを読む

福岡のPerlコミュニティに参加してきました

おがた (@xtetsuji) です。

3月21日(土曜日)から3月26日(木曜日)まで福岡に行っていました。

今回福岡に行った大きな目的が、福岡のPerlコミュニティとの交流でした。滞在6日間の間にいくつか参加できたので、私視点でその周辺をご紹介します。

続きを読む

MacBookやLinuxノートパソコンのバッテリー残量をウォッチしてImKayacでiPhoneに通知を送るPerlプログラムを作ったら地味に便利だった

仕事と個人で合計MacBook Air 3台に囲まれている おがた (@xtetsuji) です。

最近は複数のMacBook Airに囲まれている生活をしているのですが、現状バッテリーは自宅も会社も一つしかコンセントに繋いでいないという状況でなんとかなっています。ひとえにMacBook Airのバッテリーが持つから。一方の充電が完了したら、もう一方に充電ケーブルをつなぎ替えるだけで良いんです。当然ながら製品購入時に付いてくるものや予備で買ったものも含めて、ACアダプタは複数持ってはいますが、電源を挿す口が近くに足りていなかったり、会社に予備を置くのが面倒とか、そんな背景があります。

とはいえズボラな性格なので、こっちのバッテリーに充電してそのまま放置していたら、あっちのバッテリー残量がピンチということも結構あります。そこでMacBook Airのバッテリー残量を定期的に監視して、必要に応じて手元のiPhoneにプッシュ通知してくれるプログラムが欲しいと思って、思うままにサッと書いてみました。それが思いのほか便利だったので、せっかくなのでブログでご紹介してみようと思って記事を書いてみた次第です。

必要なのはPerlです。できればシステムPerlではなくユーザPerlが良いでしょう。モジュールはコアモジュール以外ではAnyEvent、Cocoa::Growl (存在する場合) 、WebService::ImKayac::Simple に依存します。Cocoa::GrowlはMacにしか対応していないし、WebService::ImKayac::Simple は最近登場したモジュールなので、Debian/Ubuntu のパッケージにもなっていません。そういうことを考えるとやはりユーザPerlを作る必要がありますが、そのあたりはPerlbrewやplenvの記事に譲りたいと思います。

やっていること自体は単純なので、最近のPerlのコアのみでも、もしくはシェルスクリプトでも頑張れば書くことはできると思います。

デーモン化とかは全然考えていないプログラムで、”&” でバックグラウンドに回して使う系のコマンドです。個人ユースのプログラムは面倒なので無闇にデーモン化しないというのが個人的な趣味なだけです。デーモン化が好きな方はApp::Daemonなどを使って改造していただくか、nohup や disown などを使ってください。詳細はプログラム内のPODを見てみてください。

標準ではホームディレクトリに WebService::ImKayac::Simple の設定ファイルが “.imkayac.yml” という名前で存在する必要があります。当然ながらiPhoneでImKayacのアプリをダウンロードして登録している必要があります。設定ファイルの書式は WebService::ImKayac::Simple のドキュメントを参考にして下さい。

上記のようなお膳立てでバックグランドジョブとして起動すると、バッテリー残量を10分おきにウォッチして、20% 50% 80% を上回ったり下回ったりした場合にImKayacで通知を送信します。また現在のバージョンでは、Cocoa::GrowlがインストールされていればGrowlでの通知も行い、要らないかもしれませんがお節介にも標準出力にも出してくれます。また充電が100%になったときに満充電になったこともお知らせしてくれます。監視のインターバルやバッテリー残量のしきい値の数々は、コマンドライン引数で変更可能です。詳細はプログラム内ドキュメントを参照してください。

こんな感じで通知が来ます。便利。

battery-watchdの通知の様子

適切なGitHubのリポジトリがあれば入れようかと思ったんですが、どこに入れてよいかわからない書き捨てプログラムとなってしまったので、とりあえず現状のものを $VERSION = “0.01” としてGistに貼りました。

Linuxラップトップでも acpi コマンドでバッテリー残量を取得することが可能なので、それにも対応してみたつもりですが、現状Linuxラップトップが手元になかったので、この部分のコードはテストしていません。レポートお待ちしています。

まだ作りたてなので、色々と不具合のようなものがあるでしょう。レポートお待ちしています。

適切なリポジトリやパッケージ化の続報があれば、随時追記しています。要望ありましたら、Twitter @xtetsuji などにお気軽にお知らせください。

#!/usr/bin/env perl
# xtetsuji by 2014/04/19

our $VERSION = "0.01";

use strict;
use warnings;
use utf8;

use AnyEvent;
use Config;
#use Cocoa::Growl ':all';
use File::Basename qw(basename);
use Getopt::Long ();
use WebService::ImKayac::Simple;

use constant HAVE_COCOA_GROWL => eval {
    require Cocoa::Growl;
    import  Cocoa::Growl ':all';
    1;
};

if ( !HAVE_COCOA_GROWL ) {
    # Cocoa::Growl の無い環境ではとりあえず何もしないコマンドとして定義しておく
    *growl_register = sub {};
    *growl_notify   = sub {};
}

use constant APPLICATION_NAME => basename($0);
use constant GRAPH_DOWN       => -1;
use constant GRAPH_UP         =>  1;
use constant GRAPH_RELAX      =>  0;
use constant OSNAME           => $Config{osname};

my $p = Getopt::Long::Parser->new(
    config => [qw(posix_default no_ignore_case auto_help)]
);
$p->getoptions(
    'watch-percents=s'        => \my $watch_percents,
    'imkayac-config=s'        => \my $imkayac_config,
    'interval=i'              => \my $interval,
);

our $DEFAULT_INTERVAL = 600;

growl_register(
    app => APPLICATION_NAME,
    #icon => '',
    notifications => [qw/info/],
);

my $IMKAYAC_CONFIG_FILE = $imkayac_config || "$ENV{HOME}/.imkayac.yml";

if ( !-f $IMKAYAC_CONFIG_FILE ) {
    die qq(ImKayac config file "$IMKAYAC_CONFIG_FILE" is not found\n);
}

binmode STDOUT, ':utf8';

my @watch_percents = (20, 50, 80);

if ( $watch_percents ) {
    @watch_percents = split /,/, $watch_percents;
    if ( grep { !/^\d+$/ } @watch_percents ) {
        die "watch-percent option specify comma separated digits.\n";
    }
}

#chomp(my $hostname = `hostname`);
my $hostname = $Config{myhostname};

my $previous_percent = get_remaining(); # initialize

my $cv = AnyEvent->condvar;

my $im = WebService::ImKayac::Simple->new($IMKAYAC_CONFIG_FILE);

my $notify_callback = sub {
    my $response = shift;
    print $response . "\n"; # DEBUG?
    growl_notify(
        name => 'info',
        title => APPLICATION_NAME,
        description => $response,
    );
    $im->send(APPLICATION_NAME . ": " . $response . " ($hostname)"); # ok either flagged utf-8 or not.
};

my $timer = AnyEvent->timer(
    after    => 10,
    interval => $interval || $DEFAULT_INTERVAL,
    cb       => sub {
        my $current_percent = get_remaining();
        my $response = '';
        # process...
        for my $key (@watch_percents) {
            if ( my $res = graph_direction( $previous_percent => $current_percent, $key ) ) {
                if ( $res == GRAPH_UP ) {
                    $response = "${key}% を上回りました。現在${current_percent}%です。";
                }
                elsif ( $res == GRAPH_DOWN ) {
                    $response = "${key}% を下回りました。現在${current_percent}%です。";
                }
            }
        }
        if ( $previous_percent != 100 && $current_percent == 100 ) {
            $response = "満充電されました。";
        }

        if ( $response ) {
            $notify_callback->($response);
        }

        # reinitialize
        $previous_percent = $current_percent;
    },
);

$cv->recv();

sub get_remaining {
    if ( OSNAME eq 'darwin' ) {
        return get_remaining_mac()
    } elsif ( OSNAME eq 'linux' ) {
        return get_remaining_linux();
    } else {
        die "Unsupported your architecture yet\nPlease contact to \@xtetsuji by Twitter if you want to use this program!\n";
    }
}

sub get_remaining_mac {
    my $pmset = `pmset -g ps`;
    my ($percent) = $pmset =~ /(\d+)%; /;
    return $percent;
}

# 追加してみたけどまだ試していない
sub get_remaining_linux {
    my $acpi = `acpi -b`;
    my ($percent) = $acpi =~ /(\d+)%, /;
    return $percent;
}
# see: http://polamjag.hatenablog.jp/entry/2013/10/23/125843

sub graph_direction {
    my ($prev, $cur, $thr) = @_;
    if ( grep { !/^\d+$/ } ($prev, $cur, $thr)  ) {
        require Carp;
        Carp::croak "graph_direction error. ($prev, $cur, $thr)";
    }
    if ( $cur < $thr && $thr < $prev ) {
        return GRAPH_DOWN;
    }
    elsif ( $prev < $thr && $thr < $cur ) {
        return GRAPH_UP;
    }
    else {
        return GRAPH_RELAX;
    }
}

=pod

=head1 NAME

battery-watchd - battery watcher and observer for Mac and Linux laptop

=head1 SYNOPSIS

 battery-watchd &

=head1 OPTIONS

=head2 --watch-percents

 battery-watchd --watch-percents=5,10,15,20

Specify watch percents separated by comma.

=head2 --imkayac-config

 battery-watchd --imkayac-config=/path/to/config.yml

Specify your ImKayac config file path.

Default path is "$ENV{HOME}/.imkayac.yml".

This file format is YAML format. See below CONFIG FILE SYNTAX section.

=head2 --interval

 battery-watchd --interval=600

Specify watching interval seconds.

Default may be 600 seconds. You confirm it by following command.

 grep DEFAULT_INTERAVAL `which battery-watched`

=head1 CONFIG FILE SYNTAX

You can give a battery state by ImKayac.
So you have to tell this program ImKayac setting.
This program gives ImKayac setting file of YAML file.
It syntax is same as L<WebService::ImKayac::Simle>'s format.

Setting file's path is below "--imkayac-config" section.

=head1 DEPENDENCIES

L<AnyEvent>,
L<Cocoa::Growl>,
L<WebService::ImKayac::Simple>,
and some Perl5 core modules.

=head1 COPYRIGHT AND LICENSE

Copyright (C) 2014 by OGATA Tetsuji

This library is free software; you can redistribute it and/or modify
it under the same terms as Perl itself.

=cut

転職活動の振り返りと、人生の「もしも」

おがた (@xtetsuji) です。

2月始めに転職をして2週間経過。12月と1月は入院生活と病気生活で横になっていたのでまだ病み上がりで体力が戻りきったとは言えないのですが、だいぶ気分的に落ち着いたので、転職活動のことを文字で振り返ってみようと思います。

要所要所に、これからPerlで転職活動をする人への参考となることを書いてみたつもりです。

詳細は退職エントリ入社エントリを参照下さい。長文ですが、忙しい人は見出しと太字だけ読めば何となく流し読み出来ると思います。

2013年転職活動の成果

2013年10月から12月初旬まで転職活動をしました。結果的に4社面接を受けて、2社不採用、2社内定という内訳。

入社した「株式会社Wano」以外に面接した社名については、昨今色々と敏感に反応する方もいらっしゃるので伏せることにします。

「1社目」は、勉強会でよく交流している方から以前より声をかけてもらっていた会社。今や誰もが使っている超有名プロダクトを出している大企業で、誰もが知っている会社。10月に転職活動を開始することになる前から水面下で話をしていたけれど、10月にいよいよ就職活動開始となったときに繋いでもらいました。結果的に一時面接で不採用になるのですが、面接前事前テストから面接決定そして一時面接を受けて不採用になるまでが1ヶ月以上(5週間くらい)かかって、大いに焦りました。「この調子じゃ、いつまでたっても次が決まらない」と。

1社目の不採用で、焦って次を当たりました。水面下で就職活動をしているとコッソリ伝えていた人づてに2社目3社目と面接を受けさせていただきます。

「2社目」は、社名自体の知名度はそれほど高くないものの、業績も良くて今元気な会社。主にモバイルでソーシャルゲームを開発運用している会社。私の経験を買われて、中の現場の人から熱烈歓迎を受けてオフィス見学までさせてもらって、すごい良いオフィスだと感動しました。ただ、マネージャークラスの方と面接したときの受け答えで何か良くない部分があったのか、まさかの不採用となってしまいました。中の現場の方も残念がっていたので、本当に残念です。分析は後述。

「3社目」は、親会社の名前は誰もが知っている歴史のある会社の子会社。社員数数百人で、親会社なら万の単位の人数がいるらしいです。話を繋いでもらった中の現場の方に呼ばれて、上級職の方とざっくばらんに話をするという内容だったのですが、結果的にこれが一時面接のようなもので、次の「二次面接」で話をした方とも感触が合って、嬉しいことに内定をいただくことになりました。

「4社目」は、入社エントリでも書いた「株式会社Wano」。ここは今までの3社と違って、YAPC::Asia Tokyo 2013 のハガキを送ったのがキッカケで、中の人で知っている人が全くいない、だから興味があった会社でした。詳細は入社エントリを参照下さい。

所有スキルが一致する事が第一ではないらしい

私は2011年からPerlを中心としたエンジニアコミュニティでオープンに活動をしはじめて、そのなかでも「Apache mod_perl」と呼ばれるPerlを組み込んだウェブサーバを専業として各地でトークをしたりしていました。何しろ前職の業務のミドルウェアの縛りが相当きつくて、Apache mod_perl以外のウェブサーバを使わせてくれなかったという事情があって、それは今では良い部分も悪い部分もあったと思っています。

1社目と2社目は、社内にmod_perlの資産をまだ結構抱えていると聞いていました。なので1社目と2社目は結構自信があったのですが、結果は不採用となってしまいました。中の現場の人も意外がっていた部分です。

逆に、3社目はPerlの古い資産も抱えているもののJavaやPHPもあって、これからMojoliciousで新しいサービスをPerl部隊が作っていこうとしている会社。4社目(Wano)はAmon2をベースとしたフレームワークで結構長くサーバサイド開発をしている会社。この2つの会社はmod_perlとほとんど縁がなかったこともあって、面接を受ける段階で自分の強みが伝わらないから内定確度は低いと思っていたら、非常に好意的に迎えていただいて内定をいただけたました。

結果的に「Perl」という主軸となるスキルはすべての会社で訴求して一定の効果はあったのですが、その中でも自分が突き詰めた「mod_perl」というスキルは結果としてあまり活きなかったというのは興味深かったです。

すべての会社が面接時に私のオープンな活動に目を通していたはずです。1社目と2社目でも面接時にmod_perlの話やYAPCでのトークに触れたのですが内定を受け取ることはできませんでした。想像ですが、レガシー資産を抱えている会社はレガシー資産を捨てたい一心であって、今さらレガシー資産を専門に開発できる専門家なんて雇ったら捨てたいものも捨てられなくなるという思いがあったから不採用になったんじゃないかと思っています。あくまで想像でしかありませんが。

mod_perlがレガシーというくくりに入れられるかどうかは別ですが、多くの会社にとってPlackやそのエコシステムこそ新しく、CGIやmod_perlは旧世代のものだという認識でしょう。mod_perlが好きな私にとってはいささか寂しい話ではありますが、それが事実です。

ソーシャルゲーム業界はエンジニアが飽和していてハードルが高い

数年前に一世を風靡したソーシャルゲーム。プラットフォームとなる大企業、開発をしてプラットフォームにゲームを提供する中小企業、開発の受託を受ける零細企業、それぞれの規模で勝ち組と負け組がだいぶハッキリしてしまいました。また、ソーシャルゲーム自体の市場規模も以前ほどではありません。

何が言いたいかというと、ソーシャルゲームの開発運用経験が無いシニアクラスのエンジニアは今ソーシャルゲームの会社に入って開発運用の仕事を受けるのは難しいということです。2社目がまさにソーシャルゲームを作っている中規模の会社でしたが、私がソーシャルゲームについて中立的な立場であることや、ソーシャルゲームの開発運用経験が無いことを話したら場の空気が悪くなった(感じがした)ので、私の年齢になると中途無経験でソーシャルゲーム業界には入れないんだなと痛感しました。まぁソーシャルゲームが大好きだという熱意を押せばまた違った結果になったかもしれませんが。

今回は面接を受けませんでしたが、ソーシャルゲーム企業の代表格であるDeNAの募集要項を見ると「ソーシャルゲーム開発運用経験3年」がすべての職種において付いていて「こりゃ色々無理だな」と思った次第です。たとえ運良く入れたとしても、ソーシャルゲーム特有の知識を求められることは必死でしょう。他の落ち目になったソーシャルゲームの会社から人材は毎日のように流れてくるわけですし、私のような人材を雇う必要性は少ないわけです。新卒といった若い年齢でポテンシャル入社をするのはまた別の話ですが。

複数内定を選ぶ悩み

結果的に2社から内定を頂いたというありがたい状況ですが、同時に選択に悩むことにもなります。年収や福利厚生や職場環境といった部分は両社甲乙付けがたいという状況でした。

内定をもらったのは12月始めでしたが、悩んでいる最中に2013年12月11日の緊急入院となってしまいました。貧血と連日の胃カメラなどの検査の連続でグッタリしている最中に、3社目から返事を急かされるメールをiPhoneで確認したあと2時間ほど熟考したのですが、結果的にWanoを選ぶことにしました。Wanoが決め手になった部分については入社エントリに書いてありますが、選択は本当に僅差といった感じでした。同時に複数社受けても、内定をもらえてもせいぜい1つと思っていたので、これは本当に大変な選択でした。人生は選択の連続です

熟考の末にたどり着いた結論は「どんなにオフィス見学をしても面接で詳しい話を聴いても、実際に入社してみないと結局何も分からない」ということでした。分かれ道があっても、失敗を恐れずどちらかに歩いていかないと何も始まらない

実際に入社してみて

まだ2週間、緊張癖なので手探りです。1ヶ月とか半年とか1年経ったときに振り返りブログ記事を書こうと思っています。

前職が在職10年。客観的に見ても業界内ではかなり長いですが、10年ぶりに環境が一新したという事実にまだ慣れないというのが実際です。たぶん2ヶ月病気で病み上がり状態、かつ環境適用力が高いとは言えない自分の場合は、少なくとも慣れるまで1ヶ月くらいは掛かりそうです。

転職エージェントは絶対に使わないと決めた

今回の転職活動では、いわゆる「転職エージェント」というものは使いませんでした。退職エントリや入社エントリにも書いた通り、2010年に人生最悪の出会いをしたからです。

よく「転職エージェントは複数活用すべきだ」という意見を聞きます。あれの真相は、視野が広がるとかそういう意味ではなく、誤解を恐れずに言えば転職エージェント4人のうち3人は他人の人生なんて考えず、自分の目先の利益だけを考えて、人を会社に機械的に突っ込むだけの人売りに落ちぶれてしまっているからでしょう。数名に聞いたのですが、だいたいの人は転職エージェントの6割から7割5分は落ちぶれた人売りだと言うところ、自分と同じ感想を抱いているんだなと思いました。

私は2010年の最悪の体験以来、金輪際「転職エージェント」というものを使わない・関わらないと心に誓いました。

もしあなたが転職エージェントを使って転職活動をするならば、絶対に4人以上の転職エージェントを使うべきです。そしてそのうち胡散臭い下位3人は話半分で付き合う程度で良いでしょう。運悪く全員胡散臭い場合は全取り替えも躊躇なく行うべきです。それがあなたの人生とあなたのメンタルを守る大切な行動になります。

2010年転職活動の振り返り

2010年転職活動は、元同僚の「転職を考えていなくても自分の市場価値を測るためにも転職活動をしてみるべき」と言われ、2010年春に紹介された転職エージェントの出会いからになります。

2010年、時代はまさにソーシャルゲーム全盛時代、その転職エージェントはひたすらソーシャルゲームの会社を勧めてきます。当時ソーシャルゲームに何の関心も無かった私は「いいんですか?」と言うと「作れる力があれば良いし、そう言えばよい」という転職エージェント。面接に行って、作れる力があることを語って不採用になった理由が転職エージェントに伝わって、次の会談で転職エージェントから「何でそんなこと言ったんですか」と怒られるということを何度か繰り返しました。典型的なダブスタとしか言いようがありません。当時のソーシャルゲーム市場は年収も高騰しており、転職エージェントの実入りを考えれば、とりあえず多くのエンジニアを機械的にソーシャルゲーム会社に突っ込む事で食い扶持をつなぐという、人それぞれの人生プランを考えない、最悪の考えだったのでしょう。運が悪かったし、私自身も無知だったとしか言いようがありません。カルト宗教に勧誘されたりねずみ講に捕まって軟禁されるくらいの屈辱とストレスを味わいました

2010年の春から、転職エージェントと自然に縁を切った同年秋まで、人生最悪の半年間を過ごして疲弊しました。メールに返信できないくらい精神的に疲弊し、思い出したくもない最後にもらったメールが「メールに返信しないなんて大人として最低」だったと思います。「おまえのダブスタのほうが最低だよ」と返そうと思ったのですが、その余力もありませんでした。

今だから時効だと思うので2010年転職活動の一端をお話しますが、1社目はDeNAでした。転職エージェントのソーシャルゲーム至上主義に踊らされた序章でした。YAPC等の露出を通じてDeNAは良い会社だと認識していて(今も良い会社だと認識しています)、Perlという自分の強みも活きると思ったのですが、前述の通り不採用となってしまいました。

カレンダーに記録が残っている面接記録です。他にも面接を受けた会社があるかもしれないのですが、もうあの転職エージェントとのメールのやり取りを見たくないので、調べるのはやめました。また、DeNA以外は社名を伏せることにしました。

  • 2010年7月2日(金曜日) DeNA 0時面接 (転職エージェントを交えた雑談)
  • 2010年8月16日(月曜日) DeNA 一次面接
  • 2010年9月8日(水曜日) 某ECサイト運営会社 一時面接
  • 2010年9月24日(金曜日) 某ベンチャーキャピタル 一時面接
  • 2010年9月28日(火曜日) 某有名会社のソーシャルゲーム孫会社 一時面接
  • 2010年9月29日(水曜日) 某ECサイト運営会社 二次面接
  • 2010年10月4日(月曜日) 某有名会社のソーシャルゲーム孫会社 二次面接
  • 2010年10月25日(月曜日) 某ベンチャーキャピタル 二次面接

DeNAを除いて、二次面接までは進めました。ただDeNA以降、転職エージェントのダブスタに辟易として、なるべくソーシャルゲーム会社を避けようとしていた事が伝わります。この中で内定をもらえたのは「某ECサイト運営会社」からだけでした。ただ、業界で良い評判を聞かない「EC Cube」を採用しているというところと、社内がPHPとPythonで二分されているというところに自信がなく、「某ベンチャーキャピタル」の二次面接の結果を待ちたいという理由で内定を辞退することにしました。同じ問題解決の層であるLL言語が社内に多く乱立しているということは、何となく個人的に避けたかったという気分でした。Pythonオンリーであれば入社していたかもしれません。

この時期も就職氷河期で、新卒の圧迫面接などが問題とされていて、そういうのにさらされたら嫌だなぁと思っていたのですが、中途だからかそういうのにはほとんどあたりませんでした。あ、ただ「某有名会社のソーシャルゲーム孫会社」だけは、高圧的な面接態度にさすがに立腹した覚えがあります。2010年秋、Plackを使ったことがないということで相当罵られました。この親会社ももともと好きじゃなかったのですが、さらに嫌いになりました。ちなみに既にこの孫会社は業績不振で無くなってしまったようです。具体的な名前を知りたい方は口頭で教えます。ここではさすがに書けません。

人生の「もしも」

今考えると、だいたい自分の周りのサーバソフトウェアやミドルウェアは6年くらいの周期で変わっていったと思います。これは私基準ですが、1997年、2003年、2009年です。個々の事例は省きますが、2009年秋にはPlackが登場してPerlウェブ開発の世界に変革が起きました。だいたい世間的にもこの周期で影響力の高いソフトウェアが登場しているんじゃないかと感じます。なので昨今はソフトウェアの話よりも開発手法などといった話が多いという仮説。

退職エントリに書いてある通りですが、2009年に自分や後輩が作ったサービスを潰していく作業をすることで私は精神的に疲弊していきます。また、私の立ち位置が柱サービスへの所属へと変わること、またインフラ部門とのセクショナリズムが確固たるものとなったことにより、2009年以降サーバサイドの裁量がほぼ無くなってしまいました。

大企業や終身雇用制度の基であればセクショナリズムも良い方向に働くといえるのでしょうが、中小零細企業ではセクショナリズムなど良いことなど何も無いと私は断言できます。たとえ会社の経営層がそれで良いと感じても、エンジニアの仕事の幅は非常に狭まってしまい、スキルを伸ばす場としてはふさわしくなくなってしまうからです

2009年の退廃的な作業、それ以降のサーバサイドへの裁量の消失、そして2009年秋に起こったPlack等のPerlウェブ開発界隈での大変革を考えれば、2009年から2010年に前職を退職しておくことが自分のスキルを磨くことを含めて自分の人生プランとして良かったのではないかと思えます。ただ、それは元同僚がキッカケで転職エージェントを通じて実際に2010年に行ったものの、(まず転職エージェントが最悪だったとはいえ)上手くいかなかったのでした。

また私は業界で無名で、まずはスキルセットを増やすかセルフブランディングをする必要があったのだと思います。

2011年からの転換

2010年秋に精神的に疲弊しきって、いったんすべての活動をやめてしまいます。転職エージェントとも縁を切りました。ただ、なぜ転職活動が上手くいかなかったのか、自分がこのまま閉じた場所でスキルを伸ばせなくて良いのか、等々といったことは何度も考えました。その結果として、2011年からオープンな活動を始めるのでした。

まずはYAPCのパンフレットで見た地元企業スカイアークにアプローチしてみることからでした。運良く繋いでくれる人がいて、2011年のゴールデンウィークの間の平日に帯広本社に行って、@onagatani さんと初対面、そして @onagatani さんの持ち味である強引な人心掌握術(?)で、2011年7月の Hokkaido.pm (#5) に初参加、そして20分初トークという事になりました。地域PMは初参加、そしてオープンな場所で人前で話すのは初めてといった状態でした。トーク自体はあまりうまくいかなかったのですが、これが記念すべきオープンなアウトプット活動の最初となりました。

それまで、Linux系のイベントやYAPCをはじめとした勉強会やカンファレンスに聞き手として参加していたことは何度もあります。また後輩育成のために社内で熱心に教育活動はしていました。とはいえ、聞き手として参加するだけでは勉強会やカンファレンスを真に満喫したとはいえず(ということは今になって痛感)、社内で熱心に教育した後輩はみんな別の大企業に行ってしまいました(結果的に「別の大企業」を育てただけと気づいたときは無力感に苛まれました)。社内教育は必要なことですが、人材が流動的な業界では社内教育一辺倒になってはいけないのだと思わされた次第です

2010年の転職活動の失敗は、転職エージェントが合わなかったという原因以外に、転職エージェントを頼らないと転職活動ができないという自分の弱さからだと分析しました。その後も他の地域PMなどに参加してトークを重ねることで、まずセルフブランディングをしていこう、そうしないと終身雇用制度が崩壊した昨今、今いる会社も安泰とは限らないし、将来的にエンジニアとして生きづらくなると考えました。

セルフブランディングという活動と実際のスキルを伸ばす活動

セルフブランディングといっても、トークだけでなく、オープンなプロダクトを出していくことも徐々に行っていきました。ただGitHubは2009年にアカウントを取得しただけで、本格的に使い出していくのはもうちょっと先になります。

会社で得たスキルは「Apache mod_perl」くらいしかありませんでした。もともと自分は、会社で得たスキルと自分で得たスキルを混ぜて両輪回していくタイプでした。2003年に新卒入社をして自宅サーバを作ったりする技術などをそうして回して言ったのですが、2009年以降は自分で得たスキルを会社に投入することができなくなり、会社のミドルウェア等の縛りがきつくなって、会社で得られるスキルが限定的になってしまうというジレンマに陥ってしまうのでした。愛社精神はあって、会社で使えるスキルを自宅でも勉強するというスタンスでいたのですが、結果的にこれは無為に時間を過ごす悪い考えとなってしまいました

そういうわけで、結果的にニッチで古いと認識される「Apache mod_perl」という話題を突き詰めて各地でトークをして、2012年と2013年のYAPC::Asiaでもそれでトークをすることとなります。

この活動で「mod_perlといえば@xtetsuji」「mod_perlの神」などと恐れ多い事を言われることも多々あったことはセルフブランディングの成功例だと思います。ただ、2013年就職活動を振り返ってみると「レガシーしか知らない人」という見られ方をたぶんされてしまったのは、このセルフブランディングの失敗例だったと言えるでしょう。セルフブランディング活動も、ブランディングの題材によっては良い方向にも悪い方向にも解釈されてしまうという一例なのだと思います。

実際にmod_perlの勉強は進めたりしたのですが、それ以外の活動は「どうせやっても会社で使えない」ということで勉強が気乗りしなかったことは事実です。会社の研究職ポジションでAnyEventやTwiggyを推したり、個人的に作りたい小さな書き捨てサーバをPlackで書いたりといったことはありましたが、手を伸ばしたジャンルの幅が広がらなかったのは、私の会社を中心とした考え方が悪い方向に働いたのだと今では反省しています。これは会社自体が自由に何でもやらせてくれるか、そうではないのかにもよると思います。2008年まではこの考えで色々なスキルが伸びていたことを考えると、会社や各種状況によってこの考え方が良いか悪いかは変わってくることなんじゃないかと思います。

そういう考えを薄々感じつつ、本格的に自分で作ったモジュールなどを公開していくのは2013年になってからになります。2009年に取得したGitHubアカウントがGist以外でようやく大々的に使われていくのでした。PAUSE IDも取得して、色々管理画面をいじっていたら、うっかりCPAN Authorになったりもしました。ようやく健全なセルフブランディングができつつある、そう感じたのは2013年になってからでした。

自力で転職活動をするメリットとデメリット

転職エージェントの話になると、自力で転職活動をする・転職エージェントを利用する、それぞれのメリットとデメリットが話題になります。

転職エージェントを利用すると、以下のような利点が挙げられるのではないでしょうか。

  • 会社を見つけてきてくれる
  • 予定を調整してくれる
  • 職務経歴書や面接結果を分析してくれる
  • 採用時の給与交渉をしてくれる

これは一例で、転職エージェント礼賛記事になるとあらゆる利点を挙げた上で「転職エージェントを使わない手はない」といった論調が繰り広げられますが、私はこれらに懐疑的です。

2010年に転職エージェントが「見つけてきた」会社は、どれも私にとって乗り気ではない会社ばかりでした。転職エージェントとの席では、転職エージェントが何に熱心になるかというと、私がこれらの会社を好きになり、これらの会社の面接に乗り気になる説得ばかりでした。果たしてこれが私の(あなたの)人生にとって良いことでしょうか。甚だ疑問です。

予定調整に関しては助かる部分もあるのですが、自力でも負担なくできることでした。

職務経歴書の分析はエンジニア経験がない転職エージェントは適当なことしか言わないという印象を受けました。もちろんすべての転職エージェントがそうではないのかもしれませんが、多くの転職エージェントはそうであるというのは前述と同じでしょう。全く職務経歴書を書いたことがないという人も、友人知人に相談したり、ウェブで参考例を検索すれば済むことです。むしろ、あまりにも長大で力作な職務経歴書よりも、あなたのオープンな活動のほうが評価されることでしょう。オープン系ITプログラマであれば、ブログを書いたり小さなことでも良いのでオープンな活動を絶対にすべきです。

給与交渉を転職エージェントのメリットとする人は多いと思いますが、私は疑問です。この部分は、転職エージェントは自分の利益が少しでも増えるためにやっているだけです。これから私が(あなたが)入る会社が転職エージェントの手数料で相当懐が痛むことを考えたら(会社は転職エージェントにあなたの年収の数ヶ月から半年分くらいの手数料を払います)、自力で面接に行って内定を勝ちとった後で、自分が納得しない額の年収を提示されたら内定を辞退するくらいの勢いで良いのだと思います。

それ以上に、私の(あなたの)働きがいは金だけなのか?金は大事だけどそれと同じくらいに大切なものがあるのではないか、目先の金に執心しすぎてそういうところを見誤ると、劣悪な仕事環境に陥ったり、プライベートの時間が持てなかったり、金以上に大切なものを失うことだってあると感じます。

一番怖いことは、転職エージェントの話に乗せられるままに転職活動をして「思考停止」してしまうことです。私も2010年に転職エージェントを精神的に拒絶しなければ「思考停止」したまま、転職エージェントの言いなりになって、入りたくも入りたくなくもない曖昧な考えで会社に入って、その後のキャリアプランを台なしにしていたかもしれません。

もし、あなたが転職エージェントを使うなら転職エージェントに「思考停止」させられることだけはあってはなりません。都度自分の頭を使い、何が自分のキャリアや人生にとってよいか自分自身で熟考して考えるべきです。

なぜ2013年就職活動は上述の4社だったのですか?

単純に声をかけてもらった順番と自分で考えて良いと思ったところだという理由です。

ただWanoに関しては別で、中がよく分からないからまずオフィス見学をさせてもらおうと思ったら面接が始まって、トントン拍子で内定をいただいてしまったという感じでした。結果的にその会社に入社するとは運命的という感じです。

私が水面下で転職活動をしているということが広まって、後になって声をかけてくださった会社は他にもありました。本当にありがたいことです。その時には既に2社内定を貰っていていて、そのことを伝えたのですが、それでも良いとオフィス見学をさせてくださったガイアックスさんのご好意にはこの場を借りて感謝します。

あの大きな企業は選定基準に入らなかったのですか?

在職していた会社が20人規模の小さな会社だったので、大企業には正直興味がありました。

ただ、2013年就職活動の1社目が大企業で、散々待たされて不採用という感じだったので、大企業を中心に攻める戦略は無理そうだなと感じ、戦略を改めました。また、YAPC等でも新卒を百人単位でエンジニアを採用しているよと発表している企業は、なんとなく近寄り難い感じがして避けました。優秀な若い人に(教わることには抵抗ないのですが)埋もれること、そもそも中途より新卒指向であると推測できることもありました。また、この規模の企業は私のような人間のスキルが吹き飛ぶような超絶な人が何人もいます。内定の見込みは当然低いでしょう。

「3社目」が親会社が大企業で、そこに結構興味を覚えたことは事実です。ただ、社内政治的なことがあったら嫌だなぁという思いもあったりして、相当色々考えた末に辞退させていただくことにしました。苦渋の決断でした。

スカイアークには入らないんですか?

私の人生を変えたとも言えるスカイアークですが、色々考えて、まだスカイアークに入る段階ではないと感じました。

家庭的な事情で、将来的に北海道の実家に帰りたいと考えています。その時の就職先の選択肢はたぶんスカイアーク帯広本社になるのではないかと勝手に思いますが、スカイアーク帯広本社のエンジニアは少数精鋭かつ相当手広い知識を持っています。今の私にはまだ雲の上と感じました。スカイアークが求めるような手広い知識を身につけることがまず先決かと今は感じています。

また私のような発展途上なエンジニアは、今は東京という情報が集まる場所にいて、スキルを磨き研鑽する時期なのだと感じています。スカイアークには東京営業所がありますが、今回は色々な思惑から採用申込みの優先順位をグッと下げた結果が今回です。

各人それぞれのスキルでPerlを武器に転職活動をするには

Perl入学式などに出ていると、Perlのビギナーの方々がPerlを使った仕事をしたいという話を聞くことが時折あります。

これについては、多くの人に聞いたのですが「頑張れ」としか言えないと感じています。私が在職している会社に紹介することはできますが、判断するのは経営層なわけで、私の一存で就職を斡旋することは当然できません。

参考になるのは私の前職の後輩かもしれません。彼の前職は職業プログラマではなく、Perlは趣味でCGIなどを書いていたという経歴でした。転職エージェントにも「30歳近くで業務経験もない人がIT系に転身出来るはずがない」と言われていたようです。転職エージェントらしいですね、アハハ。

ただ、彼は面接時に趣味で作ったPerl CGIの掲示板プログラムのデモを行ったのでした。組織的にウェブフレームワークを使った開発をしている企業であればまだしも、私の前職はmod_perl環境に *.cgi のようなものを並べる仕事だったので、小奇麗に作られたその外観もあって好感触を得て、結果採用となりました。

ここで言えることは以下のようなことだと思います。

  • とにかくPerlの基礎を勉強する。少なくとも何らかの入出力を伴うウェブアプリケーションが書けるくらいまで。
  • 有名な大企業は難しいが、まだレガシー開発をしている中小企業を地味に当たる。情報収集は転職エージェント任せにせず自分中心でやる。勉強会などの人のつながりを最大限に活用する。これは苦難の道かもしれない。
  • 面接時に自作アプリのデモをするといった一見奇抜な作戦に出る。オープンな活動をしているとさらに良い。
  • 意外に外観重要。MojoliciousやAmon2も良いけど、パッと見で評価されるアプリなのでTwitter BootstrapやCSSなどの力のほうが効いてくる
  • IT業界の職歴なしで30歳を過ぎていたらかなり厳しいと思われる。この場合はパイの大きいJavaやPHPに切り替えることも考える。IT業界への転身さえできれば、あとは職歴を詰んでPerl業界に入れる可能性は広がってくる。

とにかく人の人生に無責任な事を言えないので、上記については参考としてください。私が忙しくなければ個別にご相談に乗ることはできますので、興味のある方は声をかけてください。

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ヶ月に一度くらいのペースで次回が開催されるらしいとのことで、大いに期待したいところです。

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

おがた (@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との互換性が保てれば色々と都合が良いので、その方向で拡張をしていきます。良い結果が出たらまたブログでご紹介します。

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があるから補完されているという雰囲気もああるようですが、私に取ってついでに帰省するきっかけにもなるし、どんどん開催して欲しいです!

WordPressのWXR形式とPosterousからのインポート

2013年4月末に終了したPosterousというブログサービスから、借りているVPSに手作業でインストールしたWordPressに記事を移した際に行った事のメモ書きです。もうPosterousというものは世の中にはないけど、手法としては参考になるかもしれないし、自分への覚え書きとして残しておきます。

WordPressでは、インポートやエクスポートの形式として WXR形式 というものをサポートしています。RSS+αといった感じ。用途としてはMovableTypeのMT形式のようなものでしょう。

Posterousもさすがに終了時に記事をZIPでエクスポートできて、その中に wordpress_export_1.xml というファイルがあったので「あぁこれはWXR形式なんだな」と思っていたんだけど、3ヶ月放置してマズイマズイと思ってWordPress設置してWXR形式としてインポートしたら見事にエラーが出た。参った。これは妥当なWXR形式じゃない!

PosterousのエクスポートZIPには、中を見ると1ファイル1記事となったPosterous独自と思えるXML形式があったので、とりあえずメールのような「ヘッダ、空行区切り、ボディ」といった自分独自のテキストファイル変換した

XMLは見づらいし扱いづらいので、メールっぽいUTF-8テキストファイルになれば、後はWordPressが受け付けてくれるWXR形式を作ればいいだけになる。今回は WXR(WordPress eXtended RSS)から記事をインポートする方法 – (DxD)∞ というページを大いに参考にさせてもらった。記事中のWordPress(2013年8月現在バージョン3.6)もWXR形式もバージョンが古いけど、それでもうまく行った。XML文字列をテンプレートにして、渡した独自形式テキストファイルの数だけitem要素を反復するスクリプトを書いて動かした。

タグやカテゴリのインポートは面倒なので諦めることにした。たかだか40くらいの記事だし、元々がタグやカテゴリの設定に不満なこともあって、取り急ぎインポート出来ればいいやと思った次第。タグやカテゴリ、あと欠損した画像とかは手作業でやると割り切りました。

40記事くらいであれば本当に全部手作業でインポートしてもいいかなと思ったけど、WordPressの投稿インターフェースでは過去の投稿日で投稿することはできないことが分かったので、WXR形式を少し真面目に作ることにしました。これはパーマリンクを “/?p=数字” ではなくて “/年/月/ポスト名” などとしている場合に響いてくる話。MySQLのWordPressのデータ構造を読みといて…というのも、テーブル数が少ないWordPressであることもあって出来なくは無さそうかなと思ったけど、WXR形式を作るほうが安全だろうなと思います。

他のPosterous難民は、Posterous終了直前にWordpress.comやTumblrから救済措置としてPosterous APIを使ったインポートツールを提供したので、そっちに移行したか、コンテンツを失ってしまったかのどちらかなのかなと思います。私も一応 post-tumblr.tetsuji.jp というTumblrに一時避難させました。ただ、こちらはしばらくしたら閉鎖したい。あと、PosterousのパーマリンクがWordPressとは相容れない形式だったので、URLとしての一意性を失ってしまったというのは痛い。独自ドメインでやっていたので、そういうリンクを拾おうと思えば拾えるのだけが救い。これをApache+mod_perlで拾って適切なリンクに誘導する方法も考えているので、後々のブログネタにする予定です。

もし将来的にWordPressから別のブログサービスに移行したくなったときも、たぶんWXR形式が役に立つんじゃないかな。永続性の担保されないサービスへデータを預けると、後々大変になるかもという話でした。

4月末から3ヶ月以上アウトプットの場を失っていた感じでしたが、いよいよ復活。これからアウトプットもどんどんしていきます。以前にさかのぼって記事を書いたり、いろいろはかどりそうです。

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がありさえすれば絶対に参加します。繰り返しになりますが、本当にありがとうございました!