「perl」タグアーカイブ

YAPC::Tokyo 2019 に参加してきました #yapcjapan

コメントを残す

2019年1月26日、YAPC::Tokyo 2019 に参加しました。

YAPC::Tokyo 2019 で登壇した LT の発表内容については、以前書いたブログ記事「YAPC::Tokyo 2019 に参加して LT をしてきました #yapcjapan」を参照下さい。

続きを読む →

YAPC::Tokyo 2019 に参加して LT をしてきました #yapcjapan

コメントを残す

2019年1月26日、YAPC::Tokyo 2019 に参加しました。

このブログ記事では登壇した本編 LT の内容にフォーカスします。全体を通しての感想は、また後日ブログに書く予定です。

続きを読む →

Perl を書き続ける理由と大事にしたいこと

コメントを残す

私がプログラミングをするときの第一言語は Perl です。周囲には「私は Perl 以外のプログラミング言語はよくわかりません」と念を押すくらいには Perl ばかり書いています。

しかし、2018年の今日 Perl は一定の役割を終えた古い言語とみなされ、メインストリームからは退いたと多くの人が考えています。10年前の2008年を思い返しても、複数の対抗言語の登場で Perl に陰りがあった事は事実ですし、今日のメインストリームに Perl が居ないことを改めて言う必要も無いでしょう。

それでもなぜ私は Perl を書き続けるのか、少し考えてみました。

続きを読む →

#Perl入学式 の運営のご紹介

コメントを残す

2012年から開始されたPerl入学式ですが、最初の数年間の模索期間を経て、ここ1〜2年は運営フローもだいぶスムーズになりました。今回は「普段どんな感じで運営作業をしているの？」というお話です。

続きを読む →

企業出張版 #Perl入学式 のお話

コメントを残す

2017年も 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 のご紹介

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

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などへお気軽にどうぞ。