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

WWW::PushoverをCPANで公開しました

おがた (@xtetsuji / PAUSE: OGATA) です。

WWW::Pushover というモジュールを CPAN で公開しました。2014年4月15日現在のバージョンは、初期バージョンの0.01です。Mac OS X のクリップボード監視モジュールAnyEvent::Mac::Pasteboard以降、久々にCPANにモジュールをアップロードしました。

これはPushoverという海外のスマートフォン向けプッシュ通知サービスへのインターフェースです。もともとWebService::Pushoverというモジュールがあったのですが、重量級のモジュールをいくつも使っていたのと、PushoverにあるAPIでサポートしていないAPIが一部あったので、Perl5.14以降のコアモジュールだけで事足りるようなものを作りたくて、ずいぶん以前に作ったものをアップロードした次第です。

今回は Minilla の minil コマンドでひな形を作って作業していたのですが、念のためと FAKE_RELEASE=1 minil release をした後からおかしな状況になってしまい、結局 minil build したものを PAUSE の管理画面からアップロードするなど、混乱してしまいました。そのせいか、2014年4月15日時点でsearch.cpan.org/~ogata/metacpan.org/author/OGATA の一覧に WWW::Pushover が出てこないとか色々あってどうしたものかなと思ってはいるのですが、ひとまず cpanm WWW::Pushover と打つことでインストールはできるようです。このあたりは、次にPerlの勉強会に行った時にでもCPAN Authorの方に質問してみようかと思っています。頼れる人がいるの大事。

CPANにアップロードしたいものの色々な理由で踏ん切りがつかずGitHub止まりになっているモジュールはいくつもあるのですが、今後多くの人に有用なものは少しずつCPANにアップロードしていきたいと考えています。まだまだCPANへのアップロードは不慣れな点が多いのは、場数を踏んで解消していきたいところです。

英語ですが、ドキュメントにも書いてある通りいくつかの注意点があります。

  • Pushoverのスマートフォンアプリは、買い切りの有料アプリ
  • WWW::Pushoverを使うためには現状ログインをして自分専用の「アプリ」を作ってAPIキーを発行する必要がある

後者に関しては利用者の利便性のためにAPIキーを同梱しようか結構悩んだのですが、現時点では同梱していません。そのあたりはドキュメントにも書いてある通りです。

「日本だとImKayacがあるだろう」という意見もあるのですが、さすが有料のPushoverは高機能で、例えば以下の点がImKayacより優れているポイントでしょう。

  • Pushoverは通知のサウンドを選べる
  • Pushoverは通知の優先度を選べる
  • PushoverにはiOS版だけでなくAndroid版もあるし、iPadにもユニバーサルアプリ対応している
  • …その他色々

ImKayacは無料です(有料版もあります)が、ちょっと通知ごとにサウンドを替えてみようかなとか、AndroidユーザでImKayacを使えなかったユーザへの、もう一つの選択肢になるのではないでしょうか。

ちなみにAndroidには他にもプッシュ通知系アプリもあってAPI公開されているものもあるので、そのAPIラッパーも暇があったら書いてみたいと思っています。

Foursquareの本質とは何なのか

Foursquare大好き、ロケーションベースサービス大好きな おがた (@xtetsuji) です。

ここ最近、私の周囲ではGoogleからリリースされたAndroidアプリ「Ingress」が少しずつブームになってきています。いわゆる位置情報が取れるようになってから定期的に出てきた「陣取りゲーム」のようなものなのですが、グラフィックの秀逸さなどから、一部に熱狂的なファンを生み出しつつあるようです。 そんな中、「IngressはFoursquareより面白い」といった声も聞かれるようになりました。ただ、なんだか違和感を感じます。「Ingressってゲームだよな。FoursquareってIngressと比較されるようなゲームだったっけ?」と。

Foursquareは今や世界でも有数の位置情報のビッグデータを持った企業でありサービスです。FoursquareユーザがFoursquareでチェックインし続ける目的はそれぞれあるでしょう。そんなことを考察していき、私が考えるFoursquareの本質と、今後の展望について文章の形で考えてみることにしました。

とりとめもない長文になってしまったので、最初に結論を書きます。あとは興味と時間のある人だけ読んでいただければ満足です。また、太字だけを流し読みしていただいても嬉しいです。

結論としては

長文を読むのが面倒(いわゆる tl;dr)という人向けに結論だけ書いておきます。

  • 私が考える上でFoursquareの本質はゲームではない。新規ユーザを取り込むためにバッジといった「ゲーミフィケーション」を設けているのは呼びこみの一つに過ぎない。バッジ目的でFoursquareをしても、早晩頭打ちになる。
  • Foursquareは位置情報のビックデータを持つ有数の企業になった。今後はこの情報を使って、O2Oを仕掛けてくる。また、位置情報を欲する企業や団体と連携して音頭をとって収益モデルを築いていく。
  • ユーザがFoursquareを使う大きなメリットの一つは、ライフログであり、それは個人のビッグデータである。また、Foursquareが仕掛けてきつつあるO2Oの情報を使うことで、いわゆる食べログよりももっと汎用的なべニューランキングツールとしてユーザにメリットをもたらす。
  • 実際に興味のある人は、熱心なFoursquareユーザ(4sqer)と顔を合わせて語ると良い。4月16日のFoursquareの日に、全世界で4sqDay Meetupが行われる。2014年も東京でも行われる予定。私も行く予定です。

Foursquareはゲームではない

Foursquare自体、仕組みとして「バッジ」などといったコレクション要素のあるゲーミフィケーションの仕掛けを用意していますが、Foursquareの本質はここにはないと思います。 バッジを集めるためにわざわざ外出するという動機付けのもとに頑張っている人もいることは確かですが、多くの人はそうではないでしょう。後述の「位置ゲー」企業の中の一部は、自治体などとタイアップして観光誘導などで成功している例もありますが、Foursquareはそういうことを直近では行わないと思います。不正チェックインは論外です。

そうなると普段の生活圏内でチェックインをしてどれだけバッジが収集できるかといった話になるわけですが、一通り数十種類のバッジが集まったら、あとはほとんど手に入らなくなってしまうでしょう。 またメイヤーについてもゲーミフィケーション的要素ですが、これは「ユーザの中でも最も常連である」的意味合いしかなく、奪い合うものではないと思います。これも普段の生活圏内でチェックインしている限りは、それほど増えるものではありません。

要するにバッジやメイヤーといったゲーミフィケーション要素は、Foursquareの本質ではないと私は考えています。 もちろん、Foursquareユーザの中には様々な場所に足げく通い、バッジやメイヤーの収集に楽しみを覚えている人もいます。当然ながら、楽しみ方や活用方法は人それぞれではありますが、それがFoursquareユーザの大多数かと言われると私は否定的な方です。

位置情報とその実用と遊びの前史

いわゆるガラケー、ドコモなどでは基地局によるキロ単位の位置情報が取れる機能がありました(オープンiエリアなど)。その頃から、地図などを表示するという実用アプリが徐々に出てき始めました。まだ、精度的にもゲームに利用するには早い時期でした。 その後、多くのガラケーがGPS機能を搭載して、地図アプリなどが高機能化します。ガラケーにもGoogleマップといったPCでお馴染みの「実用アプリ」がガラケー向けにブラッシュアップして登場します。 そのなかでGPSの位置情報が、「実用」と対比される「遊び」(=非実用)に利用される事例が現れ始めました。スマートフォンの前の時代は、世界的には日本のケータイ(ガラケー)が性能的にも最高峰の携帯電話でした。この点でも日本が先行していたと言えるでしょう。特に「位置ゲー」という登録商標をひっさげて市場に切りこんできたコロプラはよく知られた企業です。このころ、コロプラという企業の前身である「コロニーな生活」が作られた頃から、企業や個人が多くの位置情報を活用したゲームを公開します。 しばらくは日本のガラケーによる位置情報を活用したゲームが先進していました。

その状況を塗り替えることになるのがスマートフォン、特にiPhoneの登場です。このころから、Foursquareのような位置情報サービス・ロケーションベースサービスと呼ばれる毛色の違うものが登場するのですが、その詳細は後述します。

Foursquareに至るまでのロケーションベースサービスの歴史、そしてGoogleの戦略

スマートフォンが登場する前後に、アメリカで「Dodgeball」というサービスが生まれました。これは実は今のFoursquareを作った人達によって作られた位置情報サービス・ロケーションベースサービスなのですが、ほどなくしてGoogleに買収されてしまい、そしてサービスが終了してしまいます。

Googleはというと、買収したDodgeballを無駄にしたというよりも、そのノウハウなどを利用して新しいものを作ったと想像しています。それが記憶にある人もいるだろう「Google Latitude」です。これはスマートフォンの位置情報を送信し続け、仲間達の間で位置情報を共有しあうというサービスだったのですが、セキュリティ上の懸念が優先してしまい、いまいち流行らず、そして数年ののち終了してしまいました。

Dodgeballを作った人達は、GoogleにDodgeballを売却した後、新しいロケーションベースサービスを作ります。それが今のFoursquareです。ちょうど高機能なスマートフォンが出てきた時代であったり、Gooogleにサービスを売却した人達が再度類似サービスを作ったという状況などが話題となり、Foursquareは一気に有名になっていきます。

当初は、日本も世界もスマートフォンをゲームに活用しようという機運が非常に高く、その括りでFoursquareも位置情報ゲームとし捉えられることが多かったように思います。ちょうど日本でのガラケー時代からのコロプラ勢などの影響もあるでしょう。ただ、当時のFoursquareの経営陣はゲーミフィケーション的要素はユーザ獲得の入口に過ぎないとしていたのだと思います。当時のFoursquareは収益モデルも確立しておらず、多くの人が先行きを不安視したりしましたが、現在は位置情報のビッグデータを持つ有数の企業として、対企業向けにそれを元に商売をしていることは知る人ぞ知るFoursquareの顔です。

ここで話を戻して、Googleはせっかく買収したDodgeballを閉鎖し、その後のLatitudeもサービス終了して、位置情報サービスの負け組となったのかというと、そうでもないようです。ユーザ数ではTwitterやFacebookに大きく水を開けられているGoogle+ではGoogleマップと連携したチェックインの概念を持ち込み、最新のAndroid端末のウリとなっている「Google Now」でLatitudeのような機能を持ち込み、そこそこの好評を得ています。また、冒頭に出てきた「Ingress」などにも経験が生きているのかもしれません。

Googleくらいの大きな企業ともなると、位置情報への投資と失敗は些細な出費なのでしょう。Googleがここまで失敗を繰り返してもロケーションベースサービスに興味をもったのは、一つはソーシャルメディアへの強いあこがれと、もう一つは自社のメインサービスとなったGoogleマップやGoogle Earthの進化といった理由があるのではないかと私は見ています。

FoursquareとGoogleは仲が良いかと言われると、そうでは無いように見えるところが面白いです。Googleマップの企業向けの利用料が格段に上がったときにいち早くGoogleマップの使用をやめた企業の一つがFoursquareです。FoursquareはOpenStreetMapを使う選択をしました。Foursquare自身も自分たちが作ったサービスを潰されて、しかもFoursquareの対抗サービスを定期的に出してくるGoogleに、あまり良い気分をしなかったことは大いに想像できるところです。

またFoursquareはGoogleのライバルとも言えるAppleとの接触を何度か図っています。記憶に新しいところでは、新しいiOSで採用されて大不評となったAppleマップのデータ改善にFoursquareが情報提供をしたという報道。これが事実であるかは不明ではありますが、FoursquareはどちらかというとGoogleよりもAppleに寄っているという見方は正しいのではないかと思います。

GoogleとFoursquareという軸で話をしてきましたが、私の想像なども入っているので、全て事実であるという保証は無いところはご注意ください。また、日本語のWikipediaの以下の記事を参考にさせていただきました。

今もFoursquareに熱心なユーザは何を目的に使っているのか

どの無料サービスにも言えることですが、サービスを何年も継続していると、登録はしたものの使わなくなったユーザと熱心に使い続けるユーザの二通りに分かれるのは常といえます。

では今もFoursquareをしているユーザのモチベーションとはなんなんでしょうか。

少なくともゲーミフィケーション要素は、何年もFoursquareを続けていくと薄れてきます。バッジも取れなくなるし、メイヤーも取れなくなる。

ユーザの目的の一つは「同報通信」的目的があるでしょう。Twitterの「○○なう」の代わりにFoursquareを使う人です。私もそれを実践して、カフェにいたら私に会いたい後輩がやってきたという出会いがありました。位置情報を公開する事のリスクばかりが取り沙汰されますが、一定のプライバシールールを意識することで、有用な出会いのツールになるのではないかと思います。

もう一つ、これが重要なのですが、ライフログ的使い方があります。FoursquareはiCalなどのフィードもしていて、いつどこに行ったのかという情報を後から振り返る機能をいくつも提供しています。GoogleカレンダーにiCalファイルを登録すると、何年も前のチェックイン情報を振り返ることができます。これが数年分たまると、とても興味深い自分のライフログ・個人版ビッグデータとなるのです。

今後のFoursquareはどこに向かうのか

Foursquareの本質が、少なくとも多くの人にとってゲームではないことは前述した通りです。

ではFoursquareの本質は何なんでしょうか。いったいFoursquareは今後どういった方向に向かうのでしょうか。

一つは位置情報のビッグデータを使って対企業に商売をするという方向性があります。これは純粋に位置情報が欲しい企業への情報提供というものでしょう。あまり一般ユーザには関係ない話かもしれませんが、AppleマップやOpenStreetMapが改善するかもしれないことを考えると、我々に無関係な話でもなさそうです。

また、日本でいうところの「食べログ」的な情報発信源になろうという目論見も垣間見えます。つまり、いまどきの言葉で説明すればO2O事業への参入です。既にFoursquareは、飲食店などのビジネスパートナー向けのアプリケーションをリリースしています。今後、日本での活動が活発化した際には、この分野での攻めもあることでしょう。以前からアメリカでは「Yelp」と競合すると言われてきました。2014年春、ついに日本にもYelpが遅れて上陸したわけで、Foursquareの動向には注目が集まります。Foursquareの経営陣は「世界で一番多いチェックインは新宿駅」などといった、日本を注目しているといった発言もたびたびしており、日本でのFoursquareの本格的な活動が楽しみであるというのが、Foursquareの一ファンである私の意見です。

飲食店に限らず、全世界の全ての場所「ベニュー」を包括的にレーティングし、それを一時発信元として発信できるのは、Foursquareなど一部の限られた企業だけでしょう。また、一連のステマ騒動や星3つ収斂問題を抱えている食べログの牙城が誰によって切り崩されるのかといった興味もあります。それはYelpかもしれないし、Foursquareかもしれません。外来のO2Oプレイヤーの活動から今後も目が離せません。

Foursquareのユーザと交流することでFoursquareの色々な面が見えてくる

既に周囲でFoursquareをやっているユーザがいないけど、なんとなく好きだからやっているというユーザは、FoursquareのMeetupなどに参加してみるとよいでしょう。

4月16日は4の2乗(square)が16であることから「Foursquareの日」とされており、その日に全世界でMeetupイベントが行われます。今年2014年も東京でイベントが行われます。

私も2012年に参加して、様々な目的でFoursquareをプレイする人達の様々な意見を聴き、非常に興味の持てる、幅の広いサービスだという印象を持ち、さらにFoursquareが好きになりました。

もしFoursquareに漠然とした興味はあるけど、その本質が何か分からないという人は、FoursquareのMeetupに顔を出すなどして、実際にFoursquareのコアユーザと話をしてみることで新たな視点が得られることは間違いないでしょう。初心者から開発者まで、様々な人達が集まった過去の4sqDay Meetupでしたが、みなさん非常に楽しんでいました。

上述の、2014年東京のFoursquare Meetupには私も参加します。後日レポートを書く予定ではいますので、もし興味があるけど出られないという方は、楽しみに待っていてくださると嬉しいです。

過去の4sqDay Meetupのまとめなどを引用して、この文章を締めくくりたいと思います。

皆さんのFoursquareライフが充実したものになることを願っています。

MacBook Air でハズレのLG製ディスプレイを引いた場合の対処方法

おがた (@xtetsuji) です。

2014年4月、個人でも会社でも「MacBook Air 13インチ 2013年モデル」を使っています。中のSSDのサイズが違うくらいで、あとはほとんど同じスペック。2014年1月に会社で使いたい機種を選ばせてもらえることになったとき、個人で使っているものと違うのがいいかなぁと一瞬思ったけど、まぁ同じ方が色々と無難かなと思った結果です。個人で買ったのは2013年6月、発売すぐです。

とはいえ最近気づいたのですが、会社で2台並べてみると、ディスプレイの色合いがぜんぜん違う。最初は会社のMacBook Airは外部ディスプレイに接続しているからカラープロファイルが違うのかなとか適当なことを思っていたのですが、個人で使っているMacBook Airの色合いの悪さが日に日に気になっていたので検索してみたら、見事にそういう記事がありました。

この記事は2012年モデルについての解説ですが、2013年モデルでも同様です。

Macでディスプレイの製造メーカーを調べる方法

ターミナルで以下のコマンドを実行すると、ディスプレイの製造メーカーが分かります。

ioreg -lw0 | grep IODisplayEDID | sed "/[^<]*</s///" | xxd -p -r | strings -6

もし「stringsコマンドが無い」といったメッセージが出てXcodeを入れるのに抵抗のある方は、システムに標準で入っている perl が使えます (2014/04/09 追記)。

ioreg -lw0 | grep IODisplayEDID | sed "/[^<]*</s///" | xxd -p -r | perl -E '$str = do { local $/; <>; }; say for $str =~/([x20-x6f]{6,})/g'

stringsコマンドはXcode Command Line Toolsが必要なようです。

stringsにはXcodeが必要

出力される結果は以下のパターンがあります。

  • LPから始まる文字列 → LG製造 → ハズレ
  • LTH、LSNから始まる文字列 → Samsung製造
  • Bから始まる文字列 → AU Optronics製造

自分個人のMacBook Airで実行したら以下の結果になりました。

LP133WP1-TJA7
Color LCD

見事にハズレorz。

会社のディスプレイは以下の結果になりました。

LSN133BT01A02
Color LCD

Sumsung製。やはり発色が良いのはこの違いだったか…。

具体的に言うと、LG製のディスプレイは白も黒もしまりがない感じになります。Sumsung製のディスプレイを見慣れると、薄ぼけた感じになるというか…。

ありがたい事に、LG製のハズレのディスプレイの発色をマトモにする方法があるということで、早速やってみました。

ハズレのLGディスプレイで発色をマトモにする方法

以下の方法はLG製のハズレのディスプレイへの方法です。他のアタリのディスプレイに施す必要はありません。逆に色が濃くなりすぎて見づらくなるのでやめたほうがよいでしょう。

  1. 有志が補正したプロファイルをダウンロードします。
  2. Finder で “/Library/ColorSync/Profiles/Displays/” を開く。さっきターミナルを開いているなら、open /Library/ColorSync/Profiles/Displays/ というコマンドを打てばOK。
  3. ターミナルで開いた Displays フォルダに、先ほどダウンロードした CustomMacRumors.icc をコピー。ここで認証が求められますが、適切なものなので承認します。
  4. システム環境設定 → ディスプレイ、と進みます。
  5. 「カラー」タブを開き、「このディスプレイのプロファイルのみを表示」のチェックを外します。表示項目が増えますが、下にあるほうの「カラー LCD」を選択します。
  6. 選択した途端に色鮮やかになったら成功です。黒色のしまり具合を見てみると違いがよくわかります。

チェックボックスを外して増えたカラープロファイル群

認証ダイアログが出た場合には「認証」を押して、管理者パスワードを入れて進めましょう。

Displayには認証が必要

これでLGのハズレディスプレイでも色鮮やかなMacBook Air 13インチ 2013年モデルになりました。Sumsung製のディスプレイと並べても遜色の無い色合いになりました。

その他

AppleがSumsungと喧嘩をしていることは有名で、今後はSumsung製ディスプレイの供給は減っていくのかもしれませんが、そこのところどうなんだろう…。

LGといえばNexus 5を作ったところとして記憶に新しいです。ただ、Nexus 5 の液晶ディスプレイには特に不満を覚えないのですが、これはLGが製造していないということなんでしょうか。それとも比較対象が無いから分からないだけとか?

参考

その他にも、検索をしてみると世界中で話題になっているようです。

比較対象が無くて、特にLG製でもいいやと思っているMacBook Airユーザの方、面倒がらずにカラープロファイルを入れ替えてみたら、見違えるほどMacBook Airの向こうに広がる世界が良くなりますよ。

最近の私とmod_perlとの関わり

おがた (@xtetsuji) です。

以前からこのブログにも書いていますが、2011年からコミュニティ活動を始めて、各地のPerlの勉強会や、2012年と2013年のYAPC::Asia Tokyoでmod_perlのトークを頻繁にしてきたからか、今も「mod_perlといえば@xtetsuji」とか「モドパール神」とかたまに言われます。恐れ多い。

新年度になって振り返りの余裕もできたので、最近の私とmod_perlとの関わりを書いてみたいと思っています。

今の業務でmod_perlは全然使っていないし使う予定もない

1月末に退職して2月初めに転職したことをご報告したのですが、現在の職場はPerlの会社ではあるものの、mod_perlは使っていません。それなのに、よく採用していただけたなと、ありがたい限りです。

前職でも案件が入れば必要に応じて書くという感じだったので、年がら年中mod_perlのコードを書いていたというわけではありませんでしたが、今の会社では入社から今まで2ヶ月の間、mod_perlとの接点は当然ながら全くありません。

以前のエントリにも書きましたが、数社面接を受けて、mod_perlを使っている会社から不採用で、mod_perlを使っていない会社から内定をもらうという事実が人生のネタみたいなものでした。

今の職場で配属された部署では、以前からの案件ではCGI(SpeedyCGI)上に乗った独自フレームワーク(OSSにもなっているけど、ほぼほぼ自社フレームワーク)。新しい案件ではモダンにNginxをリバースプロキシ役として前面に立たせて、Plack+Starletに載せたAmon2改造フレームワークを使って開発しています。

エンジニアの上司や偉い人もしばしば「mod_perlは使う予定もないからねー」と言っています。適材適所なので、使わせてくれと言ったことはないし、現状うまくいっているので良い感じなんですが、なんか私がmod_perlの人と思われているようで、mod_perlの話が出るとそんなことを言われます。

個人的な開発環境ではApacheとmod_perlは現役

個人ではというと、借りているVPS(さくらのVPS)では、ウェブサーバはApache2.2+mod_perl2という構成で動かしていて、何か込み入ったことをやりたいと思ったときには、時々mod_perlハンドラを書いたりしています。

OAuthを使ったサービスを作るためのスクラッチはmod_perlハンドラだと面倒だったので、Mojolicious::Liteを使ったりしています(面倒だったのでApacheのmod_proxyでリバースプロキシさせました)。会社がAmon2寄りとはいえ、Mojoliciousも使ったりしているのは、Mojoliciousの可搬性を個人的に気に入っているからです。

自宅サーバでは今もApache1.3が動作しています。過去の環境を意図的に残す意味で、わざとやっている部分もあるんですが、そこでmod_perl1のハンドラを書いたりすることもあります。

実際に個人的に作りたいサービスもあるのですが、MojoliciousとAmon2を作る対象物に応じて分けて使って、小さいものはmod_perl (PlackのPlack::Handler::Apache2) で動かしたいと考えています。なぜって、ログを見るのが簡単だから。

先日業務で、NginxからPlack+Starletへリバースプロキシして、plackupはSupervisorで起動するっていうのをやったんですが、もうデバッグ時にログを見るのが大変でした。何かあったときに、Nginxのログ、Plackのログ、Supervisorのログがあって、どれを見ていいものかとか、なかなか戸惑いました。慣れの問題だったり、あとアプリケーション仕様のURL設計が難儀だった(これは私が設計したものではないです)ってのもあるんですが、ミドルウェアが増えるとログも増えて大変だなーと思った次第です。個人レベルで小さなウェブサービスを作るのであれば、ミドルウェアを不必要に・扱いきれないほど多くする必要はないかなと感じています。Apacheなら堅牢だし。

前職でmod_perlを突き詰めていた理由

前職でmod_perlを劇推ししていたのは、自分がmod_perlが好きという他にも、インフラ部署がほとんどのミドルウェアの使用を許可しないという理由があったからでした。それは退職エントリにも書いたのですが、彼らの言い分は「ミドルウェアが多くなればなるほど監視対象が増えて自分らの仕事が増える」ということらしい。まぁごもっともではあるのですが、memcachedとか既に市民権を得ているようなミドルウェアまで危険視されて入れさせてくれなかったのは、自分のキャリア的に多様な経験を積む機会を奪われたとしか言いようがありません。結局memcachedのようなものもmod_perlで書きました。それならOK!

世間でmod_perlを必要としている人もいる

先日PerlBeginners#12に参加したときに、「会社でインフラを担当している」という方からmod_perlの質問を受けました。やはりmod_perlにもまだ一定の需要はあるんだと感じました。

私だって転職活動時にmod_perlを使っている会社を聞きつけたりもしたくらいですから、好きか嫌いかは別として、使っている会社や使おうとしている会社があるというのはわかります。

前述の通り「ミドルウェアが集約されて簡潔な構成になる」「監視対象のデーモンや永続プロセスの類が減る」といったことをメリットとして捉えてApache+mod_perl構成を取る会社もあるだろうし、そういう選択もあるんじゃないかなーと思います。静的ファイルはフロントエンドに立たせたNginxが出力して、動的な画面はバックエンドのPlackが…といった構成は、中小規模の開発(漠然としていますが)であれば、それほど求められないと思います。古いもの=悪、新しいもの=善、の構図は全ての文脈で当てはまるとは言えないでしょう。

私にできることはmod_perlの活きた知識を残すこと

幸か不幸か、mod_perlの活きた知識だけは頭の中にたまっているので、そういったmod_perlをこれから使っていく人のために情報を出していったりコンサルタントをしていったりしたいと考えています。

Twitterアカウント @mod_perl_info がありますが、あまり活動をしていません…。とりあえずその辺りから活動を初めて、mod_perl関連の文章の翻訳などをしていければと思っています。英語が得意なわけではないのですが、mod_perl自体の知識があるので、翻訳兼監訳的な立ち位置で翻訳作業ができるかなと考えています。とはいえ今は時間がない。

なんとなくまとめ

前職で10年間Perlをやっていた半分以上はApacheのmod_perlを突き詰めて研究して、それ以外のサーバやミドルウェアはほとんど(少なくとも)業務では触りませんでした。というか最後のほうは触らせてすらくれませんでした。

なので「Perl歴10年くらいです」といっても、mod_perl以外の知識が全然無いというある種面白いPerlプログラマーなのですが、そういった私を重宝してくれるPerlの勉強会や職場があることに本当に感謝しています。

今の環境で学んでいる「新しいこと」も伸ばしていきつつ、それもまたブログやトークの形などでフィードバックしていければと思っています。それと同時に、mod_perlの知識も「生き証人」として、後世の人に分かりやすい形で残していければいいなと、強く願って実行に移そうとしています。

こんな私に要望などがありましたら、遠慮無くどんどんリクエストしてくださると嬉しいです。

Qiitaとブログの使い分け

おがた (@xtetsuji) です。

Qiitaという「プログラミングに関する知識を記録、共有する最適なサービス」が最近活発です。見やすく使いやすいインターフェースや、ウェブ開発者に人気のMac向けに専用エディタKobitoを提供したり、アドベントカレンダーの提供インフラを提供したりと、様々な工夫があります。

実際Qiitaは便利で、そっちに書き始めると、今まで開発系の話題を提供していた自分のブログとの使い分けに悩んだりすることがあったのですが、今のところ私は以下のような基準で使い分けています。

Qiitaの「趣旨」に明らかにそぐわない記事は自分のブログへ

Qiitaは「プログラミングに関する知識を記録、共有する最適なサービス」なわけで、一見技術的な話題でも「プログラミングに関する知識」とはいえないコンピュータの記事は自分のブログに書くようにしています。例えばGoogleドライブのフォルダ名称変更とかは、操作自体はsqlite3を使ったり技術的な話題なのですが、プログラミングに関する…とは若干離れていたので、Qiitaに書きかけたものの、最終的には自分のブログで記事を公開しました。

コンピュータからかけ離れたエッセーとかをQiitaに書くのは明らかに違いますよね。

あとどこかで指摘があったのですが、「自分のプログラミング勉強日記」といったタイトルのような連載ものもQiitaに書くべきではないといった意見もありました。そういう体裁のものは、得てして他の人に役立たない、他の有用な記事を埋もれさせるという理由もあると思います。そういうのは個人のブログを使うのが正解なのでしょう。

コンピュータの話題がTwitterで展開された場合も、直接Qiitaを使わずTogetterで「プログラミング」カテゴリとしてまとめて、Qiitaを使う場合もそれを引用する形にしたほうが再利用性も上がって良さそうな気がします。

自分の作ったものの紹介は自分のブログに書く

「○○を作りました」「○○をリリースしました」系の話題は、Qiitaよりも個人のブログのほうが良い気がします。紹介は知識というよりアナウンスに近いような気がするからです。

アナウンスを自分のブログで行った後で、それを引用する形で実際の使用例をQiitaに書くのは良い流れかもしれません。

自分のブログを育てるか、QiitaのSEOの力を借りるか

「共有すべきプログラミングの知識」があったとして、それをブログに書くかQiitaに書くか、悩ましい部分もあると思います。

まず自分のブログを育てたい、自分のブログ記事を多くしたいという思い。この場合は自分のブログに書くべきでしょう。

ただ、QiitaはKobitoを提供したり、もしかしたらあなたのブログよりもプログラミングの知識を書くための良いインターフェースを提供していることも事実です。

また、Qiitaには自分のGoogleアナリティクスを設定できるので、それをして計測してみるとわかるのですが、外部からの流入が自分のブログの比ではない事が多いと思います。Qiitaは相当SEO(検索エンジン最適化)に気を使っていると言えましょう。そこそこ有名なブログでない限り、自分のブログに書くよりQiitaに書いたほうがアクセス数は断然多くなります。せっかく書いたプログラミングの知識、より多くの人に見てもらいたいと誰もが思うわけで、そういう場合にはQiitaを使うのが正解と言えそうです。

こちらは質問サイト寄りですが、海外のStack OverflowもSEOに相当力を入れていることが垣間見えて、日本語サイトを検索エンジンで検索してもStack Overflowが引っかかるくらいです。SEOの重要性をQiitaの中の人も意識しているのでしょう。

承認やコミュニケーションを求めている場合はQiitaを選ぶ

自分のブログを育てたいと思っても、プログラミングの知識を書くのもそうですが、多くのブログは他者とそれでコミュニケーションを取るインターフェースが不足していることが多いと思います。

Qiitaはコメント欄でもMarkdown、しかもGitHub Flavorに近いMarkdownが使えたり、他者からのフィードバックがもらいやすい環境となっています。

また「ストック」という仕組みがある種の承認欲求を満たしてくれるということを歓迎する人もいるでしょう。本来はサイト内ブックマークとしての役割の一つですが、それが可視化されているために、はてブ数やイイね数のような指標としても使われます。また、多く「ストック」されている記事が分かるので、そういう記事は多くの人の役に立っていたり興味をひいていたりといった指標にもなるので、使う側も嬉しい機能でしょう。

アフィリエイトを中心にしたい場合には自分のブログを使う

先ほど挙げた「プログラミング勉強日記」にも似ていますが、多くの書籍を読んだ勉強結果を書いた上で、それらの書籍のAmazonアフィリエイトリンクを貼って誘導させようという記事はQiitaより自分のブログのほうが良いです。

Qiitaでのアフィリエイトに関する規定はどうもグレーなのですが、サービス利用規約第8条第4項第2号を読むと「広告、宣伝および検索サイト最適化を目的としてユーザー登録、投稿する行為」は「行ってはなりません」と書かれています。常識的な文献の引用として補足的にアフィリエイトリンクを貼った書籍へのリンクは問題とはされないと思いますが、全面的にアフィリエイトを目的としたような記事はQiitaの禁止事項にひっかかりかねないと解釈できます。そういう小遣い稼ぎを狙った記事は自分のブログに書くのが安全でしょう。

Qiitaの将来性

せっかく書いた記事も、Qiitaというサービスが無くなってしまったら消えてしまいます。そういったサービス継続性の心配は、どんなサービスを使う上でも心得ておく必要があるでしょう。

私が見るに、Qiitaを作っているIncrements株式会社は、Qiita:Teamといった課金プランも用意していて、いわゆるGitHubなどに見られるようなフリーミアムモデルを採用しています。つまり広告収入以外の収益源があるということです。これはサービス継続性を見極める一つの基準となるでしょう。

またIncrements株式会社の人達のインタビューなどが多数ネット上で公開されていて、そのサービス継続性やサービス育成への期待感が感じられること。GitHubとの連携や、GitHubとの機能補完といった、今や開発者の素養となったGitHubとQiitaの関係を見極めているといった部分は大いに評価できると思います。

私は、そういった判断材料を総合して、Qiitaがすぐに無くなってしまったりはしないと判断しています (あくまで私個人の判断なので、責任は持てませんが)。

Qiitaとブログを緩く連携させる

最後になりますが、Qiitaとブログを「連携」させる方法は色々考えられるでしょう。

Qiita側からは、ユーザのURLを設定できるので、そこにブログのアドレスを書いておけばよいでしょう。

ブログ側からは、Qiitaが出力するフィードをブログパーツとして載せる手が考えられます。フィードをブログパーツにするサービスはFeedWindなどがあります。探してみるとよいでしょう。

この情報がQiitaとブログを効果的に使い分けしたい人の一助となれば幸いです。

PerlBeginners#12 に参加してきました #perlbeginners

おがた (@xtetsuji) です。

2014年3月21日に行われた「PerlBeginners#12」に参加してきました。

今回は2月に転職して最初のPerlBeginnersだったのですが、今の会社の同僚の方とインターンの方々と一緒に行くという感じでした。

毎回人が足りないといった理由でトークしたりしていているのですが、今回はトークする人も当初から多かったし、環境が変わってトークする資料作りする余裕もなかったということもあって、トークはしないで聴く側に回ることにしました。

場所は水天宮駅近くの「日本橋公会堂」

今回はUstream無し

とはいえ前回に引き続きUstream配信をしようと思っていたのですが、当日の会場が建物の内側にある会議室で全然電波が入らなかったこともあって、Ustreamは断念。

当日のタイムテーブル

当日のタイムテーブルは結果的にこんな感じになりました。

ビギナーズという名前に相応しい程度の難易度が維持できているのも特徴でしょう。

詳細は割愛しますが、少し撮影した写真から。今回は iPhone 5 をテザリング用に入口近くに置いておいたので、Nexus 5での撮影です。Nexus 5を撮影用に使ったのは初めてだったのですが、ちょっと iPhone 5 より画質が悪いなって感じました。

パールビジナーズ?

まさかの「パールビジナーズ」。

PBパールビジナーズ

予約の際に聞き間違えたとかでしょうか。

基調講演 by @dokechin

基調講演の冒頭より、@dokechin さん。この写真だと白バックで飛んでしまって見えないですが、スライドのキャラクターは娘に書いてもらったとのこと。資料公開に期待しましょう。

PB基調講演の様子

もともと、Mojoliciousを使って色々なサービスを作って公開している@dokechinさん。「テストではまったお話」は Test::More の is 関数の内部で悩んだという話など。

この辺りのブログ記事が発端でしょう。

このあとのビギナーズセッションでもNYTProfの読み方について質問したりといったやりとりが続きました。

ビギナーズセッションより

ビギナーズセッションの中で、仕事で主にインフラを担当されているという方からmod_perlについての質問が出て、なんか会場の雰囲気から私が回答する感じになって、少し語らせてもらいました。

最近のmod_perlはApacheやPerlの最新版に対応していない部分はあるのですが、Perlの後方互換性の高さから、特に理由がなければ最新版の一つ前を使うという方針でも問題無いのではないかといった話。また、RHEL7ではApache2.4採用の兼ね合いから、Apache2.4にまだ対応していないmod_perl2がコアモジュールから排除されてしまったことへの注意点などをお話させていただきました。ただ、mod_perlの開発は他の mod_{プログラミング言語} の開発と比べても昔も今も活発に行われているほうなので、心配ある方はmod_perlのSubversion http24開発ブランチをウォッチしたりしてみると良いかなと思います。

mod_perl で何か質問がありましたら、@xtetsuji にお気軽に質問ください。応えられる範囲でお答えします。

YAPCでやりますと言ったものの出来ていないmod_perl系の活動もそろそろやらんきゃなぁと思った次第です。あと、自分が自己満足でネットに書いた記事が実際に読まれて参考にされているということに少し驚きました。今は少し私生活に余裕が無い感じですが、これから少しずつ自分が持っている情報を出していければと思った次第です。

@maka2_donzoko さんがいらしていて、「Acme大全2013」の宣伝をしていました。あの書籍は良書なので、1500円のもとは取れると思います。

LT

LTは @__papix__ さん、@tsucchi さん、そして主宰の @ytnobody さん、最後に飛び入りで @magnolia_k_ さんがお話されました。コード無しの精神論(スピリチュアルトーク)から、コードを交えた解説まで、バランスが良かった印象でした。

@__papix__ さんが語っていた話は、コミュニティやオープンに活動しようと思いつつできない人が恐れていることが杞憂であることを突いた、良い指摘だったと思います。ネットの向こうにいるプロのプログラマの人達は、ほぼみんな業界を良くしていこうという優しい人達ばかりです。変なコードを公開しても優しく指摘してくれたり直してくれたりすることが多いので、それだけでも勉強になると言って良いでしょう。

@tsucchi さんのお話では、異常な努力のもとに成り立っているモジュールの紹介がありましたが、一時期誰もが使ったCGI.pmの中身の異常さは語り尽くせないものがありますね。また、SQLなどのパーサ系のバッドノウハウ満載モジュールも、中身を見てその異常な努力に驚愕することがあったり…。そういう異常な努力の上に出来たモジュールを使わせてもらうことは良いとしても、自分自身が異常な努力をすることは、時間的にも健康的にも良くないなと感じました。時には自分自身が率先して異常な努力をしないといけないことも人生の中にありますが、そういうときのために普段は体力を温存して普通の勉強をしてレベルアップしていったほうがいいと思います。

以下のまとめが的を射ているなと思いました。どうしても難しい処理にたいして難しいコードを書いてしまうときはきっとあるけど、簡単な処理を難しく書くことはやめてほいたほうがよい。

  • 難しい処理をしているときに難しいコードを書いてしまうのはしょうがない
  • 簡単な処理を難しく書いてしまっていないか

メールの仕様も深く立ち入っていくと尋常ならざる複雑さになっていくといった話の中で触れられたYAPC::Asia Tokyo 2011 での RJBS氏によるトークは以下です。

主宰でもある @ytnobody さんのお話では「べからず」のお話。氏が今まで指摘されてきた色々な「クールではない」点について一つずつ解説したお話でした。これも時代によって変わる価値観ではありますが、一頃に比べてだいぶ落ち着いたPerl界隈では、今もしばらくはこの価値観で行って問題はないと思います。

こういうプロ同士の実践の中から題材に上がる情報が生で聴けるのも、PerlBeginnersのような勉強会の魅力ですね。

飛び入りLTをした @magnolia_k_ さん、brewっぽいビルドツールをCPANで公開したりといったアクティブな方。今回も、自分が使ってバグを踏んだモジュールの作者に、英語で意見を送ったりパッチを送ったりということを臆することなくやっても意外と大丈夫なんだよといったことを語って私を含めた聴衆を勇気づけていました。良い話。

懇親会

木曜日とはいえ、次の日は春分の日で祭日だったため、期せずして「週末」となってしまい、ただでさえ居酒屋が少ない水天宮駅周辺で居酒屋難民になってしまいました。

とはいえ、多少さまよって店を見つけて入ることができました。3500円で2時間飲み食い放題はお得でした。

確か8人集まりました。懇親会でディープな話が聴けるのも、こういった勉強会の醍醐味。

各人の最近の業務やPerlとの関わりとか、次回に向けてどうするかとか、色々な話で盛り上がりました。

次回は5月あたりになりそうな予感。PerlBeginners#13も楽しみです。

Station TV i for Macから映像も音も出なかった意外な原因

おがた (@xtetsuji) です。

ずいぶん以前に、iPhoneやiPadでフルセグが観られる「SoftBank SELECTION デジタルTVチューナー SB-TV02-WFPL」というものを買って、iPhoneやiPadでフルセグを観ていました。iOSでの視聴は問題無く、それだけでもそこそこ重宝するものでした。

私は普段はMacBook Airを使っているので、これがMacでも使えると聞いて、2000円の追加出費をしてソフトウェア「Station TV i for Mac」を買いました。iPhone/iPadアプリは無料だというのに…。

その時はAmazonダウンロード販売を利用して購入しましたが、結果的にソフトウェアを起動してもEPG番組情報を取れるところまで進むものの黒い画面のまま画面も映らないし音も出ないという状況が続いていました。

もともと Station TV i for Mac は、画面キャプチャ能力を持っているアプリが起動していると、起動すらできないという厳しすぎる制限があって、Evernoteすら終了させないと起動すらできないというソフトウェアです。Evernoteに画面キャプチャ能力があるのかすらよく知らないのですが、とりあえずStation TV i for Macが起動できるところまで、普段常駐しているソフトウェアを終了させても、黒い画面のままという状態は脱することができませんでした。

サポートに電話してもそういう症状は無いらしく、諦めてiPhone/iPadのみで使っていましたが、今日古いMacBook Airを出してきて、ふとStation TV i for Macを起動させたら、なんと長い時を経て動いたのです。もしやと問題の切り分けをしていたら意外なことが分かりました。

  • ローカルマシンの8080番ポートが開いていると、黒い画面のままという症状になる

私は自分のMacBook Airからは自宅サーバにSSHをして使っていて、自宅サーバで8080番ポートで待ち受けているのSquid HTTPプロキシサーバへ SSH の ~/.ssh/config で「LocalForward 8080:localhost:8080」という設定を入れていました。つまり手元の8080番のTCPポートが自宅サーバのSquidの8080番ポートに繋がっている状態、手元の8080番ポートがHTTPプロキシサーバに見える状態になっていたのです。

この設定をオフにして新しいMacBook AirでStation TV i for Macを起動させてみると、なんと画面が映るではありませんか。

「起動時に手元にHTTPプロキシサーバが起動しているかポートスキャンしているのか?」と新たな謎仕様を疑ったりしたのですが、ローカルの8080番ポートにLocalForwardしている設定を試しに1080番ポートにしてStation TV i for Macを起動して、sshとStation TV i for Macを再起動してみても映るではありませんか。よく分かりませんが、Station TV i for Macは、起動したマシンの8080番ポートを見て、開いている(もしくは開いていてそれがHTTPプロキシサーバのポートである)ことを確認すると、映像も音も出さないらしいということが分かりました。

自宅限定ではありますが、普段使いのMacBook Airでフルセグが観られるようになって、ようやく快適になりました。

録画対応のマシンも今ではだいぶ安くなりました。欲しい。

浄輪寺にある関孝和の墓に行ってきました

昔は数学をやっていた、おがた (@xtetsuji) です。

3月15日(土曜日)に関孝和の墓に行ってお参りしてきました。江戸時代の大数学者です。

行ってみたかった

よく「東京の人は東京タワーに行かない」とか言われますよね。いつでも行けると思って行けない効果。最近も、札幌にずっと住んでいる人が北大のポプラ並木を見たことがなかったとかそんな話があって、自分も東京に相当長く住んでいるけど、そういう場所あったかなぁと考え直しました。

確かに東京タワーにも東京スカイツリーにも行ったことがない。かろうじて、都庁は良く行っているし東京ディズニーランドには行ったことがある程度。

昔勉強していて、今も勉強しなおしたいと思っている数学。そうだ、前々から興味があった関孝和の墓に行ってみようと思ったのでした。江戸時代の大数学科のお墓参りをして、改めて数学を勉強するぞと気合いを入れようと

行ってみた

検索してみるとすぐ場所が分かります。

一番近い場所に至る方法は、都営バスの「白61」という新宿と練馬車庫を大回りして運行している系統に乗って「牛込弁天町」というバス停で降りること。降りたすぐ近くに関孝和の墓がある「浄輪寺」にたどり着けます。

浄輪寺への入口

浄輪寺への道路からの入口はこんな感じ。「都史跡 浄輪寺」という石碑があるのですぐ分かると思います。

浄輪寺の入口の石碑 関孝和の墓、浄輪寺の入口

特に入るのに何か必要なわけではないので、とりあえず気を使いつつ入ります。

境内は普通の寺で普段は静かな場所です。通常の墓地となっており、関孝和の墓はその奥まった部分にあります。道は狭いので、知らずに入っていくにはちょっと勇気が要りますが、入っていくとすぐ分かります。

関孝和の墓

境内はそれほど広くないし大体一本道なので、都によって立てられた看板が目に入って、すぐ関孝和の墓の場所は分かると思います。

関孝和の墓の正面

看板には生い立ちや、その偉業の数々が書かれています。とても簡潔に分かります。

関孝和ってどんな人

江戸時代の数学者(和算家)です。詳しくはWikipediaの解説を読むと良いと思います。

例えば、高校時代に習ったことがある人もいる、あの「行列式」を世界で最初に見出した人でもあります。江戸時代に中国からもたらされた算術が日本国内で高度に発展した「和算」の中でも、取り分け「算聖」と呼ばれるまでになった人。後になって数学史研究者によって、西洋数学よりも数々の事実を先に発見していた人として、今に知られるようになりました。

墓はパワースポット?

大学が池袋の近くにあったころは、ときどき雑司が谷霊園を通り道にしていたことがありますが、あの墓地にも文豪の墓があったりして、良い散歩スポットだったことを思い出しました。

関孝和の墓、今あるのは二代目の墓とのことですが、ここにもともと関孝和が埋葬されたのかと感じると、特に何かをお願いしたわけではないですが、何かパワーがもらえたように感じます。そんな清々しい気分を味わいました。

暗いイメージが先行する墓場ですが、今を切り開いてくれた偉大な先人に敬意を表すキッカケになることは良い事はないか、今回の「墓参り」を通じてそう思わせてもらいました。

最近は帰省時期が悪く、自分の先祖への墓参りがここ数年できていないことが思い出されます。良くないですね。今年は彼岸の時期に帰省して、先祖の墓参りができるようにしたいと思います。

おまけ画像

3月15日、今年は厳冬でまだまだ冷えている感じではありましたが、境内の入口近くの木には元気に花が咲いていました。桜はまだとして、梅とかかな。病気の連続、そして2月からの新生活で色々忙殺されている中、少し心が癒された感じがしました。

関孝和の墓の近くに咲いていた花

 

Twitterのお気に入りツイートを振り返ってみて気づいたこと

おがた (@xtetsuji) です。

今回の記事は、ちょっと「気がついたから考えてみた系」のただのエッセーです。

Twitterにはツイートの「お気に入り」という機能があります。よく「ふぁぼ」とか言われるものです。ここではRTのように、Favということにします。

「あとで読む」はもう読まない

Favは「あとで読む」的な意味合いもあるとは思うんですが、世の中「あとで読む」とタグ付けされたものは、大抵あとで読まれないという法則があります。

自分も大量のブックマークをDeliciousに投稿したりしていますが、「あとで読む」というタグ付けは使わないようにしています。逆に「何度も読みたい」というタグ付けにして、一度は必ず目を通す、目を通すまでブラウザのタブは閉じないようにするという流れにしています。そういうようなタグ付けの工夫をすることによって、Deliciousブックマークの内容をあとで活用できることが多くなってきました。Delicious側が過去ブックマークの表示機能を高速化したというのも大きいです。使いやすい。

TwitterのFavも、この「あとで読む」的意味合いが多少なりともあると思います。もちろん、Fav結果がツイート主などにも伝わるのでそのツイートへの同意を示す意味合いや承認的意味合いもあるでしょう。ただ、このFav、あとで見返すことができるようになっているのに、しないのはもったいないなと感じた次第です。Deliciousブックマークの振り返り運用が最近うまくいっているからこそ思ったことなのかもしれません。

サードパーティのTwitterクライアントでは既に全てのFavをたどれないかもしれません。その場合はTwitterの公式クライアントか公式ウェブを使えば、少なくとも1000ツイートFav程度ならたどることができます。この理由は後述。

Favより自分の手法でメモしておいたほうがあとで検索できる

自分の場合、メモっておきたいツイートは自分専用のプログラムで自分用IRCチャンネルに投稿してIRCボットにログを取ってもらうようして (簡単なコンセプトは以前トークした「クリップボード監視と外部コマンド実行 #chibapm」のスライドを参照) います。ボタンひとつでログファイルに残るので、便利でガンガン使っています。ログファイルの検索も簡単なので、あとで「あのツイート、コピーしておいたけどなんだったけなー」といった時にも役立ちます。

TwitterのFavツイートは事実上あとで検索できないし、自分で書いたプログラムで回収しようとしてもTwitter API1.1のレートリミットの制限で指定時間内に数百ツイートしか回収できないようで、自分がFavするツイートは「これぞ」といったもののみに最近はしています。Tweetbot for iOSというクライアントでも2012年くらいのツイートまでしかたどれませんでした。これはTwitterクライアントが悪いわけではなく、Twitter社の提供するTwitter API1.1での制限です。

気になったツイートのロギング手法については、こんどいくつか解説してみたいと思います。

というわけで、私のFavには特別な思いがこもったものが多いのですが、それを振り返ってみようとして気づいたことを書いてみたいと思います。実際にツイートを列挙して振り返るのは今度にしようと思います。

Twitterを始めたきっかけ

Twitterは2006年頃からあるサービスですが、当時ブログや公での発言にあまり積極的でなかった私は「マイクロブログ」と称していたTwitterに対しては距離を置いていました。

ただ、2008年頃からジワジワとTwitterは日本でも影響力を増していきます。2009年9月のYAPC::Asia TokyoではTwitterを主要な連絡手段にするというアナウンスがあって、そこで半ば負けた気持ちでTwitterに登録したのが2009年9月9日でした。

最初のツイート。敗北を認めた感じが伝わってきます。当時は2008年くらいまで多忙を極めていて、ネットのトレンドなどが追えていなかったことがあって、Twitterは流行らず消えると考えていたり、とにかく勘が鈍っていたような気がします。

その後、試行錯誤しながらツイートしていきますが、Twitterの楽しさというか活用法も分かってきて、同報通信的用途や自分のライフログ的用途に活用していくようになります。特に2011年3月の東日本大震災前後でTwitterの活用が広がっていったり変化していったような気がします。

他のブログ記事でも書きましたが、2011年からは勉強会でトークするようになったり、ブログを開設したり、対外的な発言も積極的に行うようになって、Twitterとの連動も広がっていきました。

震災に対外的活動デビューにと、2011年は節目の年でした。

Favを振り返って分かったこと

2009年9月9日から2014年3月16日までの間に、私のFavツイートは1000ちょっとあるようです。https://twitter.com/xtetsuji/favorites にアクセスして、たどれる最初のFavまでたどって、Chromeのデベロッパーコンソールで document.getElementsByClassName(“tweet-text”).length を打った結果です。最初はよく分からずブックマーク代わり程度にFavを使っていたので、厳選してこの数というわけではないです。

とはいえ、Twitterのウェブインターフェースでは、たどれるFavの数に制限は無さそう(3200制限はあるかもしれない)なんですが、どうも2012年11月4日以前のツイートのFavの取り消しができないっぽい。もしかしたら私だけの現象かもしれませんが、Twitterは定期的に仕様を変えてきているので、何らかの要因はあるのかもしれません。特定の人にだけ起こる不具合というのもTwitterにはあって、それを踏んでいるのかもしれません。

当時はフィードリーダーの代わりにTwitterのURL付き投稿をブックマーク感覚でFavしていたのですが、あとで検索できないということもあって、このフィードリーダーのブックマークがわりとしてFavを使うのは、本当に大切なFavツイートを見返せないから良くないなと今になって追っている次第です。

次回は

実際に同感して付けたFavツイートを振り返って、当時または今の自分がどう考えるか、時間を見つけて少しずつ振り返ってみたいと思います。

Mac版Googleドライブのディレクトリを変更する方法

おがた (@xtetsuji) です。

Mac OS X 版の日本語「Googleドライブ」アプリを入れると、ホームディレクトリに「Google ドライブ」という名前のディレクトリが作られて、特にコマンドラインで扱いづらいので名前を変更したいんだけど…という話です。

はじめに

$ cd ~/Library/Application Support/Google/Drive/

ls をすると

$ ls 
CrashReports/                   snapshot.db-shm
FinderExt.bundle/               snapshot.db-wal
cacerts                         sync_config.db
cloud_graph/                    sync_config.db-shm
lockfile                        sync_config.db-wal
mach_inject_bundle_stub.bundle/ sync_log.log
snapshot.db

といった感じ。今回は設定が入った sync_config.db が主役です。

念のためバックアップ

$ cp sync_config.db sync_config.db.bak

情報書き換え

sqlite3コマンドを使って設定情報をUPDATEします。今回はホームディレクトリ直下に “Google Drive” というディレクトリとすることにしましょう。

Googleドライブアプリをいったん終了させて、以下のように

$ sqlite3 sync_config.db "UPDATE data SET data_value='$HOME/Google Drive' WHERE entry_key='local_sync_root_path'"

とコマンド入力をすれば良いです。date_value= 部分を適宜書き換えればOK。

実際のディレクトリ名の変更も忘れずに。Googleドライブアプリを終了したあと

$ cd
$ mv "Google ドライブ" "Google Drive"

を実行してリネーム(Finderでやってもいいです)。そしてアプリを再度起動するとよいでしょう。

エラー「Googleドライブ フォルダが見つからないため…」が出た場合は設定が間違っている可能性があるので、バックアップを戻してもう一度精査してください。

設定は自己責任でお願いいたします。

今回は「Google ドライブ」アプリ バージョン 1.8.4357.4863 で検証しました。

実際いまはどうしているの?

結局Googleドライブアプリはアンインストールしてしまいました。どうも馴染めなかった。どうせGoogleドライブ特有のファイルをダブルクリックしたらブラウザに飛ばされるのであれば、最初からGoogleドライブのトップ画面にブラウザで飛んだほうが便利だし、ブラウザ上ではドラッグアンドドロップでアップロードとかが出来るので、特にブラウザで不便を感じないというのもありました。

同期系のストレージであればDropboxが、WebDAV系ストレージであればBox.comがあるので、ひとまずGoogleドライブはそれらとは違う使い方をしているという感じです。

参考

Mac OS X で /var/folder の中身を削除したら画面からアイコン画像が消失した

おがた (@xtetsuji) です。

今回は完全に「やっちゃダメ」シリーズと、日頃からどうするべきか考えるシリーズ。

/var/folders 消してアイコンが消えていった事件

酔っていて電車に座れたので、MacBook Airを開いてファイル整理をしていたんですが、find / -size +250MB などとして無駄な大きなディレクトリを探そうとしていたら、”/var/folders” というのがあって、中を見ても明らかにキャッシュでしかなかったので躊躇なく rm -rf しました。

そうしたら、しばらくしたらドックや(Command-Tabで出てくる)タスクスイッチャーや、デスクトップ上のアイコン画像がどんどん消え始めました。名前だけ出てきてアイコンはないけど存在しないはずのアイコンの影はあるといった感じ。Finderから見えるファイルのアイコンも消えていきました。恐ろしい!

ドックから消えたアイコン画像

Windowsでも似たようなことがあったときに再移動したらアイコンキャッシュが戻ったので再起動してみたものの、全く直る様子なし。

あとで調べてみたら、やはり /var/folders はキャッシュディレクトリのようでした。例えば 新・OS X ハッキング! (56) 新世代のOS Xユーザへ(4):情報の宝庫「/var」 | マイナビニュース が詳しい。その他にも /var/folders で検索してみると出てくるのですが、これ関連でトラブルに陥って結局直せない人が多いという印象でした。前出の記事ではログアウトしたら消えるディレクトリのはずが、再起動しても戻らなかったりしました。

私も色々やってみた挙句、自分の症状も治らなかったので、結局6日前に取っていたTime Machineのバックアップを引き上げて復帰させたという感じ。ちょうど平日は仕事で忙しくてそれほど個人用MacBook Airにファイルを置いたりしていなかったので、まだ傷口が浅かったです。

ちなみにTime Machineからの復元方法は、いったんMacを終了させて、Time Machineディスクをつないでおいて電源投入時にCommand-R を押しっぱなしで起動させること。これで復元ウィザードが出るので、あとは画面に従って復帰していきます。この方法だとOSイメージごとまるまる復元されるので、たとえばMountain LionのTime MachineイメージをMavericksに復元させるとMountain Lionに戻るくらいまるまる書き換えてくれるものです。

とりあえず6日前に戻して、あとは取り戻す必要のあるファイルを、GitHubやBitbucketから取ってきたり、Dropboxを同期させたりして対応しました。

既にトラブルが起こっているときにTime Machineを接続して、その時の記録も取られているので、バージョン管理やオンラインストレージの管理下ではないディレクトリのファイルも部分的にTime Machineで取り戻せるとは思いますが、まぁ自分の場合は6日の変更内容がほとんどGitHub、BitBucket、Dropbox上のものだったので助かった感じ。

教訓

  • /var/folders はキャッシュディレクトリだけど、巨大だからといって軽く扱ってはダメ
  • Time Machineは日頃から励行したい
  • 何かあったときに面倒なので、Time MachineディスクはローカルUSB接続が面倒だけど速いしオススメ
  • ファイル類はなるべくバージョン管理して外に出すようにして、GitHubやBitbucketに日々pushする習慣をつけておくとよい。またDropboxなどのオンラインストレージを活用するのもよい
  • Google Chromeのオンライン同期は素晴らしい。ブックマークとかは直前のものがそのまま同期された
  • 酔ってパソコンを操作するときは、ファイル整理とか失敗すると危険な作業はしない

色々と教訓を得ることができました。

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

おがた (@xtetsuji) です。

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

Yokohama.pm#10 の看板

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

https://twitter.com/xtetsuji/status/436803755523448833

最初にいくつかの15分トークがあって、その後椅子を寄せて場所を作ってビールタイム(無料!カヤックさんありがとうございます!)となって、立って飲み食いしながらLTを聴くという形式でした。会場もPRONTOだけあってオシャレな雰囲気。

PRONTOでのYokohama.pm#10の風景

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

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

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

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

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

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

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

おがた (@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業界に入れる可能性は広がってくる。

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

Wano株式会社に入社しました

おがた (@xtetsuji) です。

題名の通りですが、2014年2月1日付けで「Wano株式会社」に入社しました。2月3日(月曜日)に初出社しました。

先日の退職エントリが長すぎと何度か指摘を受けたので、転職活動中の詳しいお話については別に書きます

Wanoを選んだきっかけ

転職活動の最初の一社目が、面接前事前テストから一時面接後の不採用まで一ヶ月以上という時間のかかりようで「このまま転職活動していたら何時まで経っても終わらない」と危機感を募らせていました。

ちょうど数社の中の人から声をかけてもらっていたので、ひとまず直近で声をかけてもらっていた2社の中の人に頼ることにしました。

ただ、最初の一社目の選考時間の掛かりすぎに焦ったこともあって、同時に前々から興味を持っていたWano社に以下のようなアクションをかけてみることにしたのでした。

YAPCのカード1

 

あれ、これはどこかで見たことがありますね…

YAPCのカード2

 

といった感じ。せっかく貼られた50円切手の有効活用。面白法人カヤックさん、ありがとうございます。

このハガキ、送っても返信は返ってこないだろうと思っていたら、しばらくしたらWanoの中の人からメールでアクションが返ってきました。あとで聞いたら、向こう側もこのハガキが送られてくるとは思っていなかったようです。

この後、一時面接は前述の2社とほぼ同時日に行われることになりました。

一時面接は無事通過し、社長と話すために少し日を置いて二次面接に来ることになりました。二次面接はざっくばらんに社長とお話をして「しばらく待ってもらえますか?」「はい」→約10分くらい経過→「じゃ内定で」という驚くべきスピーディな流れ。一社目もこれくらいのスピーディな流れで結果を出してくれれば(たとえ不採用でも)良かったのにと思わざるを得ません。

Wanoを選んだ理由

もともと数年前からYAPC::Asia Tokyoで露出はあった会社だったのですが、「音楽を事業としている会社」ということしかYAPCでもウェブサイトでも伝わってきませんでした。確かにこのソーシャルゲーム全盛時代に音楽事業とは興味深かったのですが、YAPCに大々的にスポンサーをしているにも関わらず、中でどんなPerlの技術が使われているのすら全く分からない。これは中に興味あるというわけで、オフィス見学くらいできればいいな程度の気分でハガキを出したのでした。面接を希望するにしてはこの手法はあまりにも不躾な気もします。

そんな気持ちでハガキを出したのですが、結果的にオフィス見学と同時に一時面接をさせてもらえました。面接などの中で聞いたPerlなどの技術の使われ方の洗練っぷりにも惚れたのですが、一連の流れのスピーディさに会社としての決断力があるなと思ったのも大きいです。

2008年創業の新しい会社だけあって、当然ながらレガシーの負の遺産はあまりなく、Plackなどの新しい技術が多く投入されているという印象でした。いま当たり前の技術を当たり前に使えるということがようやくできそうだという心踊る思いがありました。

二次面接で野田社長とお話させていただいて、エンジニアではないという説明を受けたのですが、話していてIT業界においてキャッチアップ力の高い方だなと感じました。何しろ若いし勢いがある。社会人として1社しか経験の無い自分でしたが、3人の社長を経験して、そのIT業界におけるキャッチアップ力には疑問を持つことも多くありました。今回「この社長となら気持よく働いていける!」と率直に思えたのは決め手でした。

面接で話を聞いていると、表には機密保持的に出しづらいものの、音楽事業以外にもいくつかの事業をしているようで、その堅い事業と自分との相性もよさそうだなと感じました

Wanoの社員数は30人ほどなのですが、社員に占めるデザイナーを含めたエンジニアの割合が半分くらいという多さにも惹かれました。15人が多いか少ないかは人それぞれの感覚ですが、社員比としても多いし、純粋な人数としても多いと思いました。だいたい二週間に一度の割合で社内勉強会も行われているようです。会社でこの規模のエンジニアコミュニティが形成できる点は魅力的でした。世の中、見回せば何百人もエンジニアを抱えている会社もありますが、多すぎても自分が埋もれるという部分もあるし、これくらいが今の自分にちょうどいいかなと思っています。

結果的に自宅から会社が近いという点も魅力的でした。大江戸線で4駅。電車が嫌いでも、これくらいであれば我慢できる範囲です。

ウォーターサーバーは無いものの、飲み物は常時ペットボトルで提供され続け、いくらでも飲むことが出来るのは魅力的でした。水と従業員福利厚生の相関を真面目に説くネットの記事もあるくらいですが、大げさではないと思います。ウォーターサーバーは自宅導入も考えたのですが、トータルコストの割には少人数ではメリットが少ないので、Wanoくらいの規模の会社だとペットボトル運用がピッタリだと思いました。

勤務時間は裁量労働制などではないものの、パソコン環境などの仕事環境を柔軟に選べるのも良かったです。個人的に裁量労働制には良い思い出がないし、自宅も近いので、定時出社・定時退社で良いと思っています。

その他にも色々と決め手がありました。

内定のその後

内定を頂いたのは12月3日でしたが、12月11日に胃潰瘍で入院してしまうのは以前のブログの通りです。その時も、Wanoの方々にお見舞いに来ていただき、正式採用の取り交わしをまだしていない身分にもかかわらず配慮していただいて、本当にありがたく思いました。

年をまたいで1月に一度出社して詳しい説明を聞くことになります。その後すぐ風邪→中耳炎→インフルエンザの流れになってしまうことを考えたら、タイミング良かったなと思わされます。インフルエンザが治った次の日から初出社という綱渡りのようなタイミングでした。

初出社した

今日2014年2月3日に初出社しました。

社内の空気も綺麗、水も飲める、うるさすぎない(音楽が流れていてちょうどよい)、といった良い第一印象を持つことができました。最近「行ってきた」で出てくるようなオシャレオフィスとまではいきませんが、必要十分な空間に満足できるものが手の届く範囲に揃っているという印象でした。

出社1日目は、パソコン環境の構築と、事務的なもろもろ、あと事業内容についての詳しい話を聴いたりしました。2日目以降、どんどん作業を進めて、早くプログラミングをしたり案件ハンドリングをしたり、バリバリ働いていきたいです。