てことで、PerlのIdiomとそれを読みやすくしたものを幾つか。

ファイル一気読み

こんな感じで書いてしまうことが多いと思います。 use autodie; も併用することが多いので、or dieとかも書かない感じ。

my $content = do {local $/; open my $fh,'<:utf8',$file_name;<$fh>}

細かい解説はさておき、このコードをわかりやすく書きなおすと以下のようになります。

use Path::Class qw/file/;
my $content = file($filename)->slurp(iomode => '<:utf8');

ファイル一気読みは、Perl6::SlurpだったりFile::Slurpだったりもありますが、Path::Classを使っておいたほうが何かと捗るので、Path::Classの使い方を覚えるついでに一気読みのやり方も押さえておくと良いと思います。

Perlのファイル操作は何かと初学者にはハマりどころなので、素直にPath::Classを使ってもらった方が良いんじゃないかと感じています。OS等アーキテクチャの違いも吸収してくれますし。以下の様な感じでファイル操作ができるので良いですね。

my $fh = file($filename)->open('>:utf8');
$fh->print('hoge');
$fh->close;

間接オブジェクト記法とか使ってもらわずに済むので良いですね。

一秒以下のsleep

Perlの標準のsleepは秒数を指定するようになっていて、1秒以下のsleepには対応していないという若干残念な部分があります。そんな時には以下のようなコードを書くことがあるでしょう。

select undef, undef, undef, 0.5;

これはあんま良くない感じがしますね。undefいくつ書くのかよくわからなくなることもあるので、素直にTime::HiResを使うと良いと思います。

use Time::HiRes qw/sleep/;
sleep 0.5;

出力のバッファリングを抑止する

local $| = 1;

古のCGIやバッチ処理なんかに書かれているのを見かけます。というか書いています。これは、標準出力のバッファリングを抑止するためのものです。

$|とかよくわからないし、selectを組み合わせて標準出力以外のバッファリングを抑止することもできるのですが、さらに面倒くさくて覚えれられません。

そんな時はIO::Handleのautoflushメソッドを使うと良いでしょう。

use IO::Handle;
STDOUT->autoflush;
STDERR->autoflush;
$fh->autoflush;

可読性も上がって素晴らしいですね。また、use IO::Handleすると、$fh->print('hoge')とか書けるようにもなって間接オブジェクト記法を避けられるのも密かなメリットです。

エラー処理

$@を使うというのは結構知られているとは思いますが、実際ちゃんとやろうとすると、$@がグローバルだったりするのでlocalしておいたほうが安全とか色々あります。

my $err = do {local $@; eval {
    ...
}; $@};
if ($err) {
    ...
}

こんな感じでごちゃごちゃ書くのはめんどくさいので、多少ハマりどころはありますが、Try::Tinyを使うのが良いかと思います。

use Try::Tiny;
try {
    ...
}
catch {
    ...
};

ただ、Try::Tinyは中身の動作を理解して使わないと危険です。詳しくはとある言語の例外処理 またはTry::Tinyの落とし穴 辺りを読んでいただくとして、それも読むのがめんどくさいという場合は、tryやcatchのブロック(厳密にはブロックではない)の中でreturnは呼んじゃダメよ、絶対、ということだけは押さえておいてください。

ちなみにPerlは特殊変数が多くて大変とか言われますが、% perldoc perlvarすれば全部出てくるんで、簡単に調べられます。

その中で一応公開できそうなやつとかを以下に記す。

iOS5から絵文字がUnicode絵文字になってたりとかAndroid対応とかでUnicode絵文字対応がちょっと必要になって書いた。

昔はUnicode絵文字とか無かったのでEncode::JP::MobileはUnicode私用領域に絵文字をマッピングする仕様になってますが、Unicode絵文字領域の文字をそのEncode::JP::Mobileの私用領域にマッピングしてしまうという後ろ向きモジュール。

絵文字はEncode::JP::Mobileの私用領域のレンジでDBに保存しているとか言うことも多いので、そういうサービスでスマホにも対応させる場合、Unicode絵文字も同様の対応を取らざるを得ないこともあり、その変換をするためのモジュールです。

一応動きますが、実装は超適当です。ちゃんとしたマッピングを書いているわけではなく、Encode::JP::EmojiとEncode::JP::Mobileの合わせ技で無理やり実現しているという...。Fallbackとかもよく分からなかったんで指定していません！(ｷﾘｯ

なので、現状githubのみ。

HTTP::MobileAgent::Plugin::SmartPhone

HTTP::MobileAgentにis_iosとかis_smartphoneとかそういうメソッドを生やしたかったので書いた。

これも一応動きますが、正規表現直書き判定でメンテナンス性とかを考えてないので駄目な感じ。なので同様にgithubのみ。

Archer

これはpull req送って取り込んでもらった。

今年初めの方から、このパッチあてて使ってたんだけど、パッチ送ってなかったのは、File::Rsync のバージョンによって出る問題だかと思って深く追ってなかったからなんだけど、File::RsyncのChangelog見てみたら実はそんなこと無かったので、取り込んでもらった次第。
(File::Rsync::(?:err|out)が以前はString返していたのが、Arrayを返すようになったとか想像していたら、もともとArray(?:_ref)?を返していてそんなことはなかった。)

File::Rsync::(?:err|out)はコンテキストに応じてリストかarray_refかを返すようになっている。そうすると、スカラコンテキストだと常に真になってしまうという問題があって(空のarray_refは真)、if () = $rsync->out;とかやって無理やりリストコンテキストで返すようにしている。カッコ悪い。

Archerは超便利に使わせてもらってるんだけど、情報が少ないし、まだ使いきれてない感があるから、もうちょっと知見を貯めていきたい。

割と弊社では活用されていますが、バラバラに使っていて知見が共有できておりません。

Plugin::ConfirmがPerl5.14では上手く動かない問題なんかもあるから、ちょっと手を入れてみようかな。

ちなみに、ArcherのwatcherがAuthor除くと弊社社員だけで吹いた。

最近社内向けのドキュメント書いてたりもするので、かねがね思っていたことを書く。かなり与太話。

文書くときって使い慣れたローカルのエディタで編集したいじゃないですか。長いBlogを書くときって、結局ローカルで書いたのをテキストエリアに貼り付けて、みたいにやっている人は多いと思うんですよ。僕はそうしてます。

BlogにせよWikiにせよドキュメントにせよ、ローカルでテキストファイルを編集できて、バージョン管理して、リポジトリにコミットしたらサイト反映みたいになってると、楽だと思うんですよね。

複数人で編集するときにすごく効果を発揮するはず。Wikiとか編集が競合したらめんどくさいけど、今時のバージョン管理ツールなら上手いことマージしてくれたり、コンフリクトを検出できるし。

文書フォーマットをどうするかというと、LaTeXで書いてPDF出力してみたいな話もあると思うし、書籍を執筆するときなんかはそれで良いと思う。実際問題としてはHTMLに変換できる簡易マークアップ記法が良いんじゃないかと思っている。

HTML+CSSの表現力ってのはすごい

アウトラインを意識すれば文書を書くというレベルで不自由はない。アウトラインを意識せざるをえないってのがHTMLで文書を書く上で逆に良い点だと思う。print.css書けば印刷物としても十分耐えうる。レイアウトもかなり自由が効く。

実際、僕は職務経歴書はHTMLで管理している。「プログラマの職務経歴書なのに綺麗に整ってますね」とか良くわからない褒められ方をされたことがある。HTMLで書いたと言ったら非常に驚いていた。

書籍とかで目次や索引をつけてページ数との対応とかをやるとなると、ワープロソフトに軍配があがると思うけど、実際は逆にハイパーリンクを張れたほうが何かと便利。

ePubの議論も盛んになってきたので、HTMLを紙にした時の見え方やそれに関連するCSSプロパティの対応はだいぶ進んできている。例えば、少し前まで背景画像のサイズ指定ができない問題があったけどbackground-sizeに対応しているブラウザも増えてきた。

Wiki記法とか

ただ、HTMLを直で書くのはきついし、HTMLテキストは可読性も低い。HTMLで使う要素は限られているのだから簡易記法で書くのは理にかなっている。

Markdownはテキストファイルのままでも可読性が高いってのが優れている。

ただ、Wiki的記法に総じて言えることだが、簡易記法である分、HTML→記法の逆変換が難しいってのが問題点。あくまで簡易記法だからHTMLのすべてをまかなえるわけではない。

Markdownは直にタグを書けるようになっていて、Markdownでまかなえないことは自分でタグを書いて解決するという割り切った方針になっている。そして、Markdownが提供するシンタックスも最低限になっている。

その割り切りは好きなんだけど、シンタックスがちょっと最低限すぎるってのがある。ちょっと複雑なHTMLを書きたくなると、すぐにタグが入り交じって可読性が落ちる。やれることが最低限な分、独自拡張が乱立してるのも問題。

そして、タグを書けるようにしているってのは実装上かなり大変。Wikiパーサーはただでさえ処理の前後関係を整理するのが難しいのに、タグ直書きを実現するためにパーサーのコードはさらにカオスなことになっている。だから前後関係を崩さないように拡張するのも大変。

Markdownその他簡易マークアップ言語に不満な点

定義リストとテーブルは欲しい。

定義リストは議事録的なものをとるときに、質疑応答とか小テーマとそれに対する決定事項みたいなものを並べるときに使いたい。(議事録なんかをとるときに簡易マークアップ言語を使うのは、書式の統一がとれて良いと思う)

あと、ソフトウェアのドキュメンテーションとかやると、codeの他に出力やシェルプロンプトを出したいので、sampが書けるとうれしいよなぁと思う。

あと、そろそろHTML5対応した簡易マークアップ言語が欲しいと思うところ。

特にasideが欲しい。実際普通に文章を書いていて横道にそれた時とか、議事録なんかで本筋から外れた話を書くときに使いたいですね。

HTML5の目玉(？)である、セクショニングの頭でh1を使うみたいなのは、既存の基本でもバリバリやっちゃって良いと思う。

このへんの不満を解消すべく、KuaiWikiを書き始めた部分があるんだけど、色々コード的にイケてなさすぎるので、げんなりして開発が止まっている。それに結局こういうWiki記法ってのは使ってもらってなんぼですね。そういう意味ではてな記法は成功したと思う。

Sphinxは便利っぽいけどreSTがイマイチ

あくまで個人的な感想ですが、reSTはイマイチだと思う。

あと、SphinxはePub変換とかPDF変換とか謳ってるけど、ePubは所詮HTMLに辞書情報のXMLファイル付加してzipで固めただけだし、PDFもWkHtmlToPdfとか使えば、HTMLからPDF生成できるわけだからそんな特別な話では無い気がする。要は印刷を意識したprint.cssが書ければあとは自由自在。

HTMLとPDFとePubが出せれば他のフォーマットは特に必要ないだろうし、HTMLがあれば、PDFもePubも出せるのです。

リンクとかリソースとか

Wiki的なものを実現させようとするときに、ページ内リンクをどう実現するかってのは地味にめんどくさかったりする。(ページ名を変えたときのリンク張替えとか、マルチバイトのリソースをどう管理するかとか。ファイルとして保存する場合はファイル名を可搬性のある形でどう保存するかとか。)

数式とか

LaTeXで書けるようになってて、MathMLで出力される感じのシンタックスがあれば良いのかなぁ。MathMLどうなのかなぁ。今日のSugamoでも話題になってたけど。

図とか

blockdiagがすごすぎる。テキストファイルでUMLを記述して画像出力するという素晴らしさ。今後の継続開発に期待。

あとは、Cacooも素晴らしすぎる。前職で社内向にYapafiのドキュメント書いたときに使った。UMLの要素も揃っている。とかそういう話を今日のSugamoでも話が出た。

本当に運営の人はお疲れ様でした。毎年のことながら素晴らしいカンファレンスをありがとうございました。今年の運営はこれまでの経験が活かされていて、非常に洗練されていたと思います。

個人的にはブログやらTwitterやらISUCONやらで以前より名前や顔を覚えてもらえていることもあって、交流しやすかったというのもあります。勝手に後夜祭から帰途につくときに、「@lapis25 さんと話せなかったな」とか思っていたら、帰りの電車を待っているときに本人から声をかけていただけたのは感激でした。

まあ、そこまで有名になったわけでも無いのですが、実力に比べて若干名前先行の感があるのでもっと精進しないといけないな、と思います。

そして、Kamakura.pmで話した内容の焼き直しでも良いから、話しておけばよかったと少し後悔しています。年々トークのレベルが上がっているので、そろそろ話しておかないと置いていかれる一方だな、という感じがする。来年は話す。

印象に残ったトークとか

Perl 5.16 and beyond(Jesse Vincent)

Perlに対する誤解を解くだとかレガシーPerlがどうのみたいなことを言うフェーズは終わって、どんどんPerlを進化させていくというフェーズに入った。Perl自体をよりスリムに、ソースコードもリファクタリングしていく。

といった内容を話していたと思いますが、非常に力強いメッセージで、期待が持てました。

ORMに関する議論なんかで良く言われることですが、すわ関数呼び出しのコストが高いだとか、オブジェクト生成のコストが高いからといって、ハッシュばかり使うっていうのは、有効なのはわかりますが、バッドノウハウ以外の何者でもない。(DBICがオブジェクト作り過ぎなのは確かですが)

確かに、ハッシュはシリアライズもしやすいし、イチイチオブジェクトの流儀を覚えるよりも楽なことも多いのは確かですが、だからといって、ハッシュばかり使うのは他言語からしたらナンセンスに思えるのは確かだと思います。

そのあたりが、今後Perl自体のソースコードのリファクタリング次第で高速になっていくことを期待しますし、共通的なオブジェクトモデルがどうなっていくか気になるところです。

Mobage オープンプラットフォームの事件簿(Toru Yamaguchi)

モバゲーでサービスを作っていることもあって、Zigorouさんやriywoさんのトークも非常に自分にとって身近で興味が持てるネタでした。

特にZigorouさんのトークに関しては「ここまで話しちゃっていいんだ...」とかびっくりするような内容でした。

話していた障害の話は、自分が作っているサービスにもモロに影響がでたやつなんだけど、話を聞いてみると、規模は違えどこちらでも悩んでいるような話で、逆に親近感が湧くような話でした。

しかし、それらに対する解決策は目からウロコが落ちるような、でも真似したくないような驚くべき内容で、とはいえ発想の転換という点では非常に参考になりました。

初日の懇親会で、Zigorouさんとお話しましたが、「なんか欲しい機能とかありませんか」とか聞いてきてくださって、こちらが出した要望にも真剣に考えてくださって本当に嬉しかったです。

こういうエンジニアの横のつながりってのは、なかなか非エンジニアには理解しがたい部分でしょうね。

他者のエンジニアが弊社に遊びに来ることとかあるんですけど、「スパイかも知れないよ」とか冗談をいう人がいて、勿論冗談なんだけどそういう冗談が出てしまうのは非常に残念だなぁと思ったりすることもあるので。

あとは、riywoさんのトークでも、

• 運用側にイベントの開始を伝えてない
• 「リアルタイム」という言葉は特に危険

みたいなことを話していて「あるある」とか思いました。

Perlで構築された中規模サイトのDC引っ越し記録(FUJIWARA Shunichiro)

ベストスピーカー賞おめでとうございます。初日のほうが来場者が少ないし、投票を促されるのも二日目なので、二日目のトークが有利だと思われる中での勝利は見事としか言いようがありません。

弾座談会

トークじゃないけど、二日目の夕方にスウィーツエリアで日本と海外のハッカーたちによる座談会が行われていました。

そこではいつもは空気を読まない弾さんのファシリテート力に驚いた。それだけじゃなく、弾さんが途中で口を挟んでも、すかさずそれに口を挟み返す、みたいなことが頻繁に行われていて、「ああ、これが英語圏の会話なんだな」とか思いました。

スピーチとかはあるけど、英語の座談会的なものは初めて聞いたのは初めてだったので非常に面白かった。聞き取れた英語は3割くらい。

その他思ったこと。

ハッカー文化の啓蒙

こういうYAPCの雰囲気やハッカー文化的なものを、ビジネスサイドの人たちにも理解してもらうことは大事なのかなぁと思った。最後のhidekさんのトークを聞いてもDeNAなんかはそこにすごく成功しているんだと感じた。

自社のエンジニアの書いたコードが他社のサービスで動いているし、その逆もまた然り。そういう基本的なところからして、ビジネスサイドの人間はなかなか信じられなかったりする。

YAPCがビジネスビジネスしたイベントになるのはゴメンだけど、お金を出してもらうだけではなく、ビジネスサイドの人を引っ張ってくる努力もしたほうが良いんじゃないかと感じている。

今回はスポンサー枠みたいなのもあって、うちの管理部門の人もYAPCに来たりしたわけだけど、一人は「YAPCすごく楽しいですね！」と言っていた。そいつはなんでも本気で「楽しい」と言えるナイスな奴なので、逆に参考にはならないけど、そういうふうにYAPCの空気を非エンジニアに感じてもらうってのは重要なんじゃないかと思う。

キャリアとか家庭とか

Perl界隈は僕くらいの年代が多いと思うんだけど、家庭をどうするかに関して色々考えていている人が多いように感じました。JPA理事の牧さんも子供欲しいっておっしゃってますし。

刺身さん問題(僕しか言ってない)について刺身さんと話せたのも良かった。

一般的にWebエンジニアは家庭を大事にしますが、Webサービスは昼夜問わず対応しなければいけないことも多く、仕事との両立は頭の痛い問題です。

しかし、帰りの電車で、@lapis25さんも@kazeburoさんも「子供かわいいですよね」とかおっしゃっていて、非常に幸せな気持ちになりました。

てことで、Webエンジニアは結婚相手として非常におすすめですね。おすすめな理由はここでは語り切れないので、またの機会にあらためることにします。

最近はMTで書くのがたるくなってきて、自分で適当なBlogツール的なものを作ろうかとか考えて、markdownをgit管理する簡易CMS的なものを多少作ってもいたのですが、そんなことをしているうちに余計ブログを書かなくなったフシもあります。

最近(でもないけど)以下のようなツイートをよく見かけますね。

hogeはfuga日生きた。今日は有意義だったか

こんなのは以下のワンライナー一発です。11448日生きたようです。

perl -MDateTime -E 'say DateTime->today->delta_days(DateTime->new(year=>1980,month=>6,day=>5))->in_units("days")'

これを見て常々考えていたことを思い出したんだけど、一年の体感時間て何故かどんどん短くなるじゃないですか。それは、一年が自分の中で何度も繰り返された末に、その価値がどんどん陳腐化していくのが大きな理由だと思うんですね。

これの数式化を試みると、0歳から1歳までの1年てのはその人にとっては人生の全てなわけですよ。この1年の価値を1とすると、1歳から2歳までの1年は自分の人生の1/2を占めるわけで、1/2の価値になります。そして31歳から32歳の1年は自分の人生の1/32にしかなりません。つまり以下のようになります。

人生の体感時間 = 1 + 1/2 + 1/3 ...

この体感時間に基づいて、実際に自分がどれくらいの割合の人生を消化しているのかを1歳から100歳まで出力するワンライナーが以下です。人生が100歳と長めに仮定しています。

perl -e '$die=100;$r+=$_ for map{1/$_}1..$die;printf "| %3d | %5.3f |\n",$_,sub{$i+=1/$_;$i/$r}->()for 1..$die'

|   1 | 0.193 |
|   2 | 0.289 |
|   3 | 0.353 |
|   4 | 0.402 |
|   5 | 0.440 |
|   6 | 0.472 |
|   7 | 0.500 |
|   8 | 0.524 |
|   9 | 0.545 |
|  10 | 0.565 |
|  11 | 0.582 |
|  12 | 0.598 |
|  13 | 0.613 |
|  14 | 0.627 |
|  15 | 0.640 |
|  16 | 0.652 |
|  17 | 0.663 |
|  18 | 0.674 |
|  19 | 0.684 |
|  20 | 0.694 |
|  21 | 0.703 |
|  22 | 0.711 |
|  23 | 0.720 |
|  24 | 0.728 |
|  25 | 0.736 |
|  26 | 0.743 |
|  27 | 0.750 |
|  28 | 0.757 |
|  29 | 0.764 |
|  30 | 0.770 |
|  31 | 0.776 |
|  32 | 0.782 |
|  33 | 0.788 |
|  34 | 0.794 |
|  35 | 0.799 |
|  36 | 0.805 |
|  37 | 0.810 |
|  38 | 0.815 |
|  39 | 0.820 |
|  40 | 0.825 |
|  41 | 0.830 |
|  42 | 0.834 |
|  43 | 0.839 |
|  44 | 0.843 |
|  45 | 0.847 |
|  46 | 0.851 |
|  47 | 0.856 |
|  48 | 0.860 |
|  49 | 0.863 |
|  50 | 0.867 |
|  51 | 0.871 |
|  52 | 0.875 |
|  53 | 0.878 |
|  54 | 0.882 |
|  55 | 0.886 |
|  56 | 0.889 |
|  57 | 0.892 |
|  58 | 0.896 |
|  59 | 0.899 |
|  60 | 0.902 |
|  61 | 0.905 |
|  62 | 0.908 |
|  63 | 0.911 |
|  64 | 0.915 |
|  65 | 0.917 |
|  66 | 0.920 |
|  67 | 0.923 |
|  68 | 0.926 |
|  69 | 0.929 |
|  70 | 0.932 |
|  71 | 0.934 |
|  72 | 0.937 |
|  73 | 0.940 |
|  74 | 0.942 |
|  75 | 0.945 |
|  76 | 0.947 |
|  77 | 0.950 |
|  78 | 0.952 |
|  79 | 0.955 |
|  80 | 0.957 |
|  81 | 0.960 |
|  82 | 0.962 |
|  83 | 0.964 |
|  84 | 0.967 |
|  85 | 0.969 |
|  86 | 0.971 |
|  87 | 0.973 |
|  88 | 0.975 |
|  89 | 0.978 |
|  90 | 0.980 |
|  91 | 0.982 |
|  92 | 0.984 |
|  93 | 0.986 |
|  94 | 0.988 |
|  95 | 0.990 |
|  96 | 0.992 |
|  97 | 0.994 |
|  98 | 0.996 |
|  99 | 0.998 |
| 100 | 1.000 |

100年生きたとしても、7歳にして人生が折り返すことがわかります。

さて、上の式をみてピンと来た方もいらっしゃるかも知れません。1 + 1/2...の無限和を数式化すると以下のようになります。

はい。これは調和級数ですね。

上記リンクから引用。

名称の「調和」(harmonics) というのは音楽や和声学における倍音の概念に由来するもので、振動弦の倍音の波長というのが弦の基本波長の 1/2, 1/3, 1/4, ... となっていることによる。調和級数の各項は前後の項の調和平均になっており、また調和平均という用語もやはり音楽に由来するものである。

音楽においても非常に重要な数式でもあり、西洋音楽の美しさの要とも言える式だということがわかります。

さらに以下の記述を引用します。

調和級数は、その項の極限が 0 になるにもかかわらず発散するという意味で、初学者にとっては直観的ではない級数である。

はい。ほんと直観的ではないですね。

この級数が収束するのであれば、人生を無限に生きることに特に意味が無いと断言できるのですが(いくら生きたって頭打ちだから)、この級数が発散するということは、無限に生き続けることにはわずかながらに意味があるということです。

「いくら生きたって、一定の値に収束するんだから、無限に生きたって意味はないんだ」とか言いたかったんですが、見事に失敗に終わりました。ということで人生は美しくも業が深いものですねと改めて思ったのでした。

実際は周りの認識通り、@fujiwaraさんに優勝させてもらったようなもので、@sugyanと僕は手を動かしていただけです。まあ、空気にならずには済んだので、そこは安堵しています。

修正したisuconソースはフォークしてGithubに置きました。プログラムの修正部分のみで、my.cnfの修正なんかはここには反映されていません。

さて、@fujiwaraのコンテストでの動きや、帰宅後のBlogアップまであらゆる仕事が速くてビビるんですけど、詳しくは、#isucon で優勝してきましたを見てもらうとして、

• どういうドタバタがあったのか
• アプリの修正点とか
• @fujiwara的には当たり前ですっ飛ばしてるけど僕には勉強になったこと

みたいなことを書きたいと思います。結果としては圧勝みたいになっていますが、かなり危うい部分や、苦肉の策なんかがあります。

事前作戦会議とか

前日のランチで軽く雑談。

とはいえ話したのは、「リバースプロキシはnginxにするでしょう」「memcachedはどこかで活用するんでしょうね」くらいの話。あんま変なモノは使わず、使い慣れている環境を使いましょう。あとは出たとこ勝負という話。

当日の役割分担

当日の役割分担は自然と決まって、作戦決定とOS・ミドルウェアの設定周りを@fujiwaraが担当して、それに従って@sugyanと僕が手を動かすという感じになりました。

初期設定とか 11:30-

まずはSSH周りの設定。authorized_keysにそれぞれ自分の鍵書き込んだり、hostnameの設定したり。rev(リバースプロキシ)を踏み台にして、他のサーバーに入る方針。

あとは、revにもアプリが入っていたので、そこでgit init。by @sugyan。それをローカルに落としてきて開発ってつもりだったんだけど、最後はサーバー上で開発になってました。

デプロイに関しては、revからappサーバー2台に、rsync -> SSHリモートコマンドでsupervisord再起動 みたいな簡単なシェルを書いた。(簡単なとか言いつつ、結構調べちゃいましたけどね！) by 僕

@fujiwara 組長にhostname等の設定をしてもらっている間に、アプリをざっと眺める。シンプルで綺麗。生DBIでテンプレートもxslate。こりゃPerlモジュールレベルじゃ全然高速化の余地はないなと、自分が空気にならないか心配になる。

PerlはSystem Perl。置き換えても良いかもしれないけど、他にやることはあるでしょう。MySQLが5.5だったのはスゲー意外。4.0とか覚悟してたんだけどw

チャットは社内IRC。チャンネル作ることも考えたけど、普段使っているチャンネルに。そっちのほうが社内の他のエンジニアへの実況になって面白いかな、とも。

最初の計測 12:30-

各サーバーでtop回しながらベンチマークスクリプト走らせる。まずは何はともあれこれ。スコアは800/min程度。

MySQLがネックになっていることが判明したので、今度はクエリログ眺めながらベンチマーク。そこでサイドバーを作るために発行している以下のSQLがネックになっていることが判明。

SELECT a.id, a.title FROM comment c INNER JOIN article a ON c.article = a.id GROUP BY a.id ORDER BY MAX(c.created_at) DESC LIMIT 10

クエリキャッシュを有効にしても焼け石に水で、1200/minくらいに向上したのみ。ただ、クエリキャッシュを適切に有効にしたことは、後々スキーマ変更した後のクエリ効率には貢献したので、もちろん有効な施策ではありました。

アプリ修正開始 13:00-

とりあえず、サイドバーが曲者だなってことで、まだ具体的な方針は決定はしていないものの、サイドバーの生成で上記クエリが走らないように、POST時にサイドバーの配列情報をmemcachedに突っ込んでしまうように先行して@sugyanがプログラムを修正することに。

で、よくよく考えたら、articleにlast_commented_atカラム追加すればjoinの必要なくなるしindexも張れるからかなり速くなるんじゃないか、と @fujiwara が指摘し、そのアプリの修正を僕、DBのAlterやデータ修正を@fujiwaraが担当。

僕と@sugyanがアプリの修正をしている間に、どうせ使うよねってことで、revにnginxとmemcachedを@fujiwaraがさくっとインストール。nginxのmemcachedプラグインも導入。

apacheからnginxにリバースプロキシを差し替えて、ベンチをとったらまさかの500/min。これは@kazeburoの罠で、時々keep-aliveを送りつけるベンチマーククライアントがいて、そのTCP接続が残り続けるのが問題だった。これはkeep-aliveをoffにすることで解決。

静的ファイルもアプリが返していたので、それもnginxでサーブするように変更。

僕の修正部分とnginxの合わせ技でベンチを取ったら20,000/min程度まで改善。@sugyanは大掛かりなコード修正で苦戦中。

このへんで一旦お昼ごはん。

キャッシュ戦略 14:00-

この時点で、DBのボトルネックは解消。次はアプリがネックになっている。フロントでnginxのmemcachedプラグインを使うってのは既定路線でそれを如何に有効に使うか。

データがPOSTされた1秒後にGETされるので、そこで確実に高速にレスポンスを返すためにまずはPOSTされた時点でGETされるであろうコンテンツを生成してキャッシュに乗せてしまおうという戦略。@fujiwara立案。

「GETされるであろうコンテンツの生成」はちょっとめんどくさいから、素早く実装できる方法として、localhostをFurlで叩いて、そのレスポンスボディをキャシュに載せてしまおうという力業。これまた@fujiwara案。このへんの見切り判断の早さがやばい。

その辺の実装を僕が担当。nginx memcachedプラグイン設定を@fujiwara担当。

リバースプロキシのアドレスをHostヘッダに入れてやる必要があるんだけど、FurlのHostヘッダの扱いに難があって、Hostヘッダを二重につけてしまったりしてしまう。あとで@xaicronに確認したところ、やっぱFurlの罠だった。結局LWP::UserAgentを使うことに。

その辺の変更を適用してベンチをとったら30,000/min程度までスコアが改善。ここまではすこぶる順調(のように見えた)。

14:40 (fujiwara) 現在1位

15:21 (fujiwara) 少なくとも惨敗はないなw

迷走時間 15:30-

キャッシュ戦略が有効に働き、ボトルネックがフロントに徐々に移行。「後はフロントの最適化」に専念。...とおもいきや「サイドバーの罠」にかかりここから苦戦することになる。

この時点でデータのキャッシュは上記の通りPOST時だけ。それを、GET時もキャッシュしてしまおうという戦略を@fujiwaraが立案。それを僕が実装。サーバー起動時に全URLにアクセスに行き、事前にキャッシュを温めてしまうウォームアップスクリプトを@fujiwaraが作成。

実装したところスコアはかなり改善したがエラーが頻発！

このへんで@sugyanのサイドバーの配列情報をmemcachedに入れる修正ができたので、マージして当て込んだところ、少しスコアは向上したが誤差の範囲内か。しかし、memcachedにミスヒットするとフェールオーバーしない男らしい作りだったため動作が安定せず、rejectすることに。フェールオーバー周りを改良して当て込む手もあったんだろうけど、残り時間の関係と、他のエラーも出てたので、問題点を絞りたかったってのが大きな理由。

この時点のエラー原因は後から振り返ってみると以下の4本。これが同時に起こったから、原因究明に苦労した。

1. アプリ自体の単純なバグ
2. アクセス増に伴うip_conntrack溢れ
3. アクセス増に伴うnginx->memcachedでのローカルポート枯渇問題
4. サイドバーの罠

3までは割とすぐ解決。@fujiwara がログを見る所が的確すぎて、原因究明が早すぎてビビる。

これで、問題完全解決とおもってベンチを走らせるも、サイドバーエラーが頻発。キャッシュをPOSTのみにするとエラーは起こらない。GETでもキャッシュさせるとエラーでベンチが通らない。

「謎だー」「DBコミットのタイミングかー」「でもオートコミットだよなー」

完全に迷走状態に。

恐るべきはサイドバーの罠 16:30-

いや、謎ではありません。以下を完全に見落としていたのです。

データがPOSTされると他のページのサイドバーも書き換わる

データPOST後の1秒後のGETだけではなく、他のランダムGETの処理でもサイドバーの整合性チェックをしていたのでベンチがコケていたのです。

考えてみればごく当たり前です。

つまりこれまで大丈夫だと思っていた、POSTの時だけキャッシュする戦略でも、GETの取られ方によってはベンチがこける可能性がある。

そもそものキャッシュ戦略が完全ではなかった

この恐るべき事実を突きつけられ、チーム内に衝撃が走ります。もう時間もない。

しかしここで、@fujiwaraの起死回生の一言がチームを救います。

「cacheに秒数付けて調整するしかないな」

それだー！苦肉の策ではありながら、時間内に出来ることはもうそれしか無い、むしろそれだけだったら十分すぎるほど時間に余裕はあります。当たり前の対策を的確なタイミングで言えるその凄さ。

懇親会で@kazeburoさんが講評前に「トップのチームはもっとフロントで捌くようにしてくると思ったけど、@fujiwara組はアプリに結構アクセスがあったのが意外だった」って言ってたって話を聞いた。

結局、上記のようにキャッシュ戦略に穴があったので、定期的にアプリに回してキャッシュを更新させるようにせざるを得なかったってのが理由です。ここはかなり出題者に負けた感があります。

秒数調整 17:00-

とりあえず、POSTのインターバルは1秒だからキャッシュの生存を1秒にしておけばほぼ安全。しかし、それだとキャッシュする意味が少なくなってしまう。他のチームのスコアを考えるともう少し冒険をしないとつらいところ。しかし、本番審査のベンチ時間は1分ではなく3分なので、その分は安全策を取らないといけない。

てことで、キャッシュの寿命を5秒に設定。ここでのベンチスコアは86,000/min! しかし、この時点のトップスコアが88,000/min程度だったので、それは上回れず。

とりあえず、100,000/minの初突破チームの特別賞狙いで、スケベ心を出してキャッシュの寿命を10秒に設定、nginxでのgzip圧縮転送等を試みるも、大して効果は出ず、96,000止まり。計測誤差範囲内。(この辺りの時間帯は各チームがベンチマークを回しまくっていたので、ベンチマークサーバーの負荷の関係か、ベンチマークのばらつきが大きかった。)

10秒でも大して効果なかったので、安全のためキャッシュ秒数を5秒に戻し。ここで、修正は凍結。あとは審査準備。

しかし実はここで僕がgit resetで "--hard"してなかったのでローカルのソースは巻き戻ってなかったというポカミスをしていた...。

願いを込めて再起動 17:30-

OS再起動後の審査スタートだったので、再起動後もちゃんとベンチが通るかどうかの確認。

ここで@fujiwaraの何気ない神の一手が発動。

おもむろに以下のようなテーブルを追加。

CREATE TABLE article_bh (
...
) Engine=blackhole;
CREATE TABLE comment_bh (
...
) Engine=blackhole;

そして、以下のSQLがOS再起動後に実行されるように設定。

INSERT INTO article_bh FROM (SELECT * FROM artcile);
INSERT INTO comment_bh FROM (SELECT * FROM comment);

うおお、なんてお手軽ウォームアップ。これでDBの内容をOSのメモリキャシュに載せるわけですね。

「memoryストレージ」みたいなことも話には出てたんだけど、まずは正攻法という哲学。

何度かベンチ回してスコア出るので大丈夫そうかな、と一安心

17:53 (songmu) 1位奪還中。後は本番勝負。

しかし間際でまさかのベンチFail。

最後の修正 17:57-

やっぱ5秒でも厳しいか、ってことで3秒に変更しようとする。しかし実は先程の記述のとおり、git上は5秒に戻してたけど、ソース上は10秒のままだったというオチ。なので、5秒に変更。

ソースを一行というか一文字変更するだけなんだけど、めちゃくちゃ焦って緊張した。ここでsyntax errorとか出したら死刑ものなので。

審査中 18:00-

周りの中間スコアを見ると、完走さえ出来れば上位には入れそうな感じだったので、なんとかベンチを完走して欲しいと願っておりました。1分完走率が8割だと、3分完走率は5分5分になってしまう。もっと成功率は高かったけど100％ではなかったので、やはり心配でした。

あとはプチ反省会。

• "/"はPOSTされるタイミングで更新されるわけだからキャッシュに乗せておけばよかった
• @sugyanのサイドバーのキャッシュはフェールオーバーをやっていれば、使えたかも
• そもそも、サイドバーの更新タイミングの違いの罠に気付くのが遅すぎた。それに早く気づいていたら違う手も打てた

審査結果発表 18:30-

先に発表された準優勝のスコアが70,000万/3minとそこまで高くないスコアだったので、内心「これはうちは審査完走できなかったのかも...」とドキドキでした。

無事に完走を遂げたらしく、270,000 over/min のスコアで優勝できました。

振り返って

ホント素晴らしいイベントでした。@fujiwara組長の仕事ぶりを目の前で見られたのは本当に大きな経験になりました。

懇親会での会話もめちゃくちゃ盛り上がりました。トークイベントとはまた違って、全員が同じ事をやっているので、話が弾む弾む。

話を聞くと、言いだしっぺの @tagomorisさんが、やりたいなーみたいなことを言い出したら、どんどん話が進んで、トロフィーまで準備されるという。エンジニアドリブンであれだけのイベントをあれだけのリソースを使って開催できるのはマジすごいと思いました。見習いたい。

あと、@tagomorisさんと自転車の話ができてよかったです。今度走りに行きましょう。

色々なユーザーの声をやたらめったら取り込んでしまったせいで、日本の家電みたいに無駄かつ一貫性のない機能が満載で醜悪なことになっていますが、その辺は気にしないことにしましょう。

ただ、変に多方面の声を取り込んでしまったせいで、妙にお行儀よくなりたがっている部分も多く、使いづらくなっている部分も多々あったりして困りものですが。

まあ、つまりPHPにおいて「良い」ってのはありえないんですよ。とか言ってみたりして。

閑話休題。

エラーレベルは最大にしろ

色々コードが書きづらくなる部分もありますが、逆にお行儀がよくなり分かりやすくなる部分も出てきます。また、前方互換も考えると、最大限有効にしておくのが賢明でしょう。

PHP.iniに以下のように書くのが理想です。

error_reporting = E_ALL | E_STRICT

PHP.iniを触れない場合、スクリプト内に以下のように書くこともできます。

error_reporting( E_ALL | E_STRICT )

ただ、この場合、コンパイルレベルでのエラーを一部出力してくれなくなるので残念です。

.htaccessに書くこともできますが、その場合は定数を使えず、即値を使わないといけないので、一長一短ですね。

あと、PHP4と互換性のあるモジュール(MDB2とか)なんかを使うときにエラーがたくさん出て困ることになりますね。このあたりどうすれば良いんでしょうね。

エラーレベルを動的に変更できないところがPHPの辛いところ。

文字コードはUTF-8一択

理由は色々ありますが、大きな理由としてはマルチバイト文字を扱うときにUTF-8じゃないとpreg系の関数が正しく動かないことです。

mb_regex_encodingを適正に設定して、mb_ereg系を使うという手もありますが、mb_ereg系では、各種正規表現修飾子が使えないのが痛い。特にx修飾子が使えないのが致命的。

正規表現はpreg系を使い、x修飾子を積極的に使いましょう

x修飾子超便利。

変数名には「意味」を持たせる。型は持たせない

型は意味ではない。変数の型付けに拘るのは静的型付け言語の考え方であり、動的型付け言語は無意味。

例えば、my_ageだったらintegerに決まっている。それをiMyAgeなんて変数にするのはナンセンス。

それに、追加開発時にmy_ageはintegerではなくて、ageクラスのインスタンスに仕様変更されるかもしれない。そういう自由さを動的型付け言語は持っている。そうなったときに、変数名がiMyAgeのままだったら目も当てられない。

ただ、同じ変数の型がプログラムの中でコロコロ変わるなんてのは分かりづらいのでやってはいけません。これは、次の「真理値を返すのは真理値を返すメソッドのみにする」でも触れます。

それと、キャメルケースは案外読みづらい。変数名はアンスコ区切りが良いんじゃないかと思う。

真理値を返すのは真理値を返すメソッドのみにする

PHPは動的型付けなので、メソッドの途中で失敗したらfalseを返すみたいなこともやってしまいがち。

しかし、正しくはメソッドの戻り値の型は固定にして、メソッドの途中で失敗したら例外を投げるべき。falseを返すような実装にしてはいけない。呼び出し元でイチイチ戻り値をチェックしないといけなくなり、コードの見通しが悪くなります。

メソッドが真理値を返すのは、そもそも、is*とかcan*とかtrueかfalseを判定するメソッドに限るべきです。

var_dumpとかアドホックな出力に頼るな

たしかにvar_dumpは便利だ。ただ、デバッグ値を画面に出力するだなんてのはあまりにもダサい。そんなことだから、PHPerがバカにされるのだ。

var_dumpの内容はデバッグログに吐くべきだ。それには多少工夫が必要になる。以下のような感じだ。

function d(){
    ob_start();
    ob_implicit_flush(0);
    $args = func_get_args();
    call_user_func_array('var_dump', $args);
    $str = ob_get_clean();
    return $str;
}

出力ストリームをトラップして、戻り値として返すようになっている。var_dumpは可変長引数をとるのでそれも受け付けるようにしてある。

上記関数を以下のようにロガーに渡して、ログファイルをtail -f で見ろ。そうすれば変数の変化なんかも追うことができる。

$logger->debug(d($obj));

三項演算子はネストしない

三項演算子は便利だがPHPだと連結順がおかしいのでネストしない。括弧で囲んで頑張ってネストさせる手もあるが、そこまで頑張らなくてもよいでしょう。

switch文が便利なこともありますが、例によって「緩やかな比較」なので注意。

ちなみに、PHP5.3以降は?:演算子も使えるのでちょっと便利。

$_GETと$_POSTを使え

$_REQUESTを使うのはもちろん論外だが、$_GETと$_POSTをイチイチちょっとしたクラスでラップする必要性も感じない。ユーザーの入力値を使いやすい形で提供してくれているのだから使うべきだ。

もし、オブジェクト化したら、キーをなめるような処理が欲しくなった時にkeysみたいなメソッドを生やさなくてはいけなくなるような不自由さが発生するし、そもそもアプリケーションがWebからの入力を前提とした作りになってしまう。

上手くクラスを利用するとしたら、バリデーターオブジェクトをつくってそれに$_POSTを喰わせるとか、フォームオブジェクトを準備しておいてリクエストに対して自動で$_POSTの中身をバリデーションするとか、そんな時でしょう。その場合も、$_GET, $_POST自体をラップしておく必要はありません。

そして、ちょっとしたアプリケーションであれば、生の$_GET, $_POSTで困ることは少ないのです。

ただ、$_GET, $_POST, $_COOKIEあたりを事前にmb_check_encodingを通して、不正な入力値が与えられていないかはフレームワーク側で担保しておいたほうが良いでしょう。

設定ファイルはアプリケーション設定ファイルと環境設定ファイルの2種類持て

最近は、アプリケーションの設定をする設定ファイルと、環境情報を記載した設定ファイルの2種類を準備したほうが良いんじゃないかと思い始めている。

そして、環境情報ファイルは本番と開発用で分けておくが、アプリケーション設定ファイルは本番と開発用で共通して使えるものにしておく。

アプリケーション設定ファイルが肥大化してきたら、一部の設定値や定数群をモデルクラスにアサインした方がよくなってくるでしょう。もちろんモデルだからといって、ストレージはDBとは限りません。

short_open_tagを有効にし、テンプレート内では<? ?>を使え

最後に超独断の爆弾。

個人的にはコントローラやモデルは<?php で書き始め ?>で閉じないように書いていますが、テンプレートでは<? ?>を使うのが好きです。

short_open_tagをoffにして、テンプレート言語としてのメリットを捨ててまで、PHPみたいな(censored)な言語を使う理由を全く感じません。

よく言われるのが、XML宣言云々ですが、そこだけechoで書けばよいだけの話です。なんでそこでechoを使わないためだけに、他のところでechoを使わないといけないのか意味がわかりません。

あと「他の環境に持って行っても動くように」なんて話もありますが、それも.htaccessに書けば良いだけなんでないの、とか思ったり。

理想を言えば、最近のトレンドからして、<?= ?>で囲まれた部分はオートエスケープされるようにPHP側で良きに計らってくれるようになってくれれば良いな、と思う。もちろん後方互換を考えてPHP側でなんらかの環境設定フラグを準備してもらう必要はあるでしょう。またPHPにフラグが増えることになりますが。

業務としては現状、ソーシャルゲームのサーバーサイドの開発をしています。毎日Perlを書けるので非常にハッピーです。でももっとバリバリ新しいことも出来るようになりたいですね。

自分がマウスとGUIに頼りっきりのゆとりだったことを改めて思い知りましたが、なんとかシェルとvimでひと通り開発できています。vimとかzshはもっと使いこなしたいですけどね。gitを本格的にコマンドラインで使うのもブランチを切ったりするのも初めて(!)でしたが、今やgitが無いと生きていけませんね。

社員も増えていて、同じ時期に入った人たちが凄い人ばかりで、存在感を示していて、非常に刺激を受けています。

社員は皆真面目です。ネタと思われてしまうことも多いのですが、そこも含めて真剣に働いています。真面目に稼ごうとしているし、会社として生き抜こうとしているし、実際生き残っている。形だけの真面目さが無い分、それ以上の真剣さが求められます。

その辺り誤解されている部分があって、損している部分もあるかなと思うのですが、今のスタンスを貫きながら世の中に認知され理解されていくしかないんだろうなと思います。実際待遇も悪くないし、良い会社だと思います。忙しくしている人が多いのは事実ですが、多くの人は納得して仕事をしています。

あとは、CPAN Authorを増やしたいですね。社内でCPAN Authorを増やしていくのもありますし、CPAN Authorの人たちもWelcomeです。一緒に働きましょう！

ウチは幸い家族も実家も無事で、被害としては、皿が2割程度割れ、コンポが一部破損し、本が多少グシャグシャになったのと、パソコンが一台壊れたくらいです。

とはいえ、最後のほうで迷って、3kmくらい逆方向に進んでいて心が折れかけましたが、なんとか帰宅しました。嫁とは帰宅途中にmixiでなんとか連絡がついてかなり安心した。あと、iPhoneとGoogleマップが無かったら帰れなかったと思うので、ネットの力すごい(笑)

家は物が散乱していて大変だったみたいですが、先に帰宅した嫁とお隣さん(!)が片付けてくれたようで、帰宅したらだいぶ片付いておりました。近所付き合い大事。

阪神淡路大震災の時と違うのは、もちろんあの時以上の被害が大きく関東にも影響があることもありますが、あの頃の自分とは格段に交友関係が広がっているので、東北出身者が身の回りにたくさんいるということ。だから、どこか個人的には他人ごとだった阪神淡路の時に比べて、他人ごととは思えず、なかなか心の整理が難しい部分がありますね。

とはいえ、自分ができることや気が回せることの範囲はそう簡単に広がるものでもないので、ネガティブな影響を受けすぎず、いつもどおり出来ることをするということは変わりませんね。被災地に大して出来ることは寄付をすることくらいでしょうか。サクっと赤十字にネット送金をしておきました。

そういえば、ウチにはテレビがなかったのですが、ちょうど仕事の都合でガラケーを契約したばかりでワンセグがスゲー役立ちました。

凄惨な被災地の状況に心を痛める部分もありますが、逆に愛する人と過ごす週末の尊さをいつも以上に噛み締めることも出来ました。まあ、前向きに生きて行くしかありません。

yusukebeにスピリチュアルとかやたら言われましたが、割と反応をいただけたようでよかったです。モダンPerlの裏側で有名なkoba04さんも丁度いらしていて、僕も割とモダンPerlの裏側に居た人間なので、お話ができて良かったです。

Perlの地位を上げる方法

基本的には、Perlって必須スキルだよね、誤解されてるよね、どうすればユーザーを増やせるんだろうとか、前の会社での経験も踏まえて話した感じです。

そういやスライドにちょろっと書いているように、今年から面白法人カヤックで楽しく働いています。その辺の話はまたそのうち。

PerlがロードレーサーでPHPがクロスバイクって話は個人的にはナイス例えだったんだけど、一部にしか伝わらなくてやや残念。

エクササイズ目的で自転車買う人って、ロードバイクには抵抗があるから、まずクロスバイクからって人が多いんだけど、そこでロードバイクをゴリ押しで薦めてしまうと、自転車自体に乗ってもらえなかったし、しぶしぶロードを買ったとしても、あまりハマってもらえなかったりする。

逆にクロスバイク買ってしまった人がたくさん乗るようになると、物足りなくなってきて、結局ロードを買ってしまう人が多々いますというお話でした。

実際、プログラミングとロードレーサーって似てる部分があると思っていて、割と簡単に「俺スゲー感」を味わえるんだけど(40km/hを自力で簡単に捻り出せる快感！)、よくよく見てみるとその「俺スゲー感」のレベルって大したことなくて、上を見たらキリがない所とか。まだまだイケると思ってしまい終わりがないところとか。

二次会でも指摘されたんだけど、丁度、プログラミング言語の比較ってのがホッテントリ入りしていて、奇しくもタイムリーな話題でありました。まあ、あのエントリーは良エントリーですよね。公平に書いてあると思う。Perlはもう少し評価して欲しかったけど。

僕以外のTalkはTech Talkに相応しい内容で、yusukebeのBlog Hacks 2011は流石の内容で、nekokakuさんのTengの話を聞けたのは非常に良かったし、fujiwaraさんのSys::Vertの話はVM使っているのでかなり参考になりました。

二次会では、yusukebeと

• tokuhiromのコードは面白いし参考になる
• 海外のPerlモジュールはマッチョでなんか違うよね
• だから日本から発信していかないといけないね

みたいな話をした。

で結局就職活動に失敗して、その後なかなか安定収入が得られず苦労したので、職に困らず、食いっぱぐれないしっかりしたスキルを身に付けたいと思うようになった部分があります。

それで、紆余曲折を経ていざ念願の守ってもらえるような会社に雇用されると、不安で仕方がなかった(笑) 今の会社が潰れたとしても生きていけるかがわからないから。たとえ潰れる心配は無いにしても。

就活の失敗体験があるから食いっぱぐれる恐怖がどこかにあるわけですよ。会社とか関係ない確固たるスキルを身に付けたいってのがやっぱ強い。絶対に食いっぱぐれない武器が欲しいんですよね。

また、会社に過剰に期待していると、些細なことで裏切られたと感じやすくなるし、その結果愚痴っぽくなってしまう。これは人間関係も同じですね。

それに、前の転職のときも思ったんだけど「いつでも他の場所に行ける」くらいの余裕があったほうが、余裕をもってクオリティの高い仕事が出来るように思います。

だから終身雇用とかアテにせず、自分の力で生きていこうと。結局そんなあやふやなものに頼るよりかは自分を頼りにしたほうがよっぽど安心だな、と。すごく当たり前のことに行き着いたわけです。

てことで、会社に頼らない・しがみつかないのは大事ですよ。

絶対起業とかしないとか思ってたけど、まあ、なんだかんだでそのうち起業しちゃったりするかもしれませんね。だって、また転職するだなんて思ってなかったんだから。

ブログは全然更新してないのにね。

ところでAdventと言えばシュトーレンですが、Twitterで@neotagと絡んでいたら、今更急にシュトーレン作りたい欲求が高まっています。それだけ。

今の会社は安定しているし、恐らく一生勤めることも可能なので、周りの友人や前職の友人からは「勿体無い」とか「何で？」とか言われます。私としてもチャレンジだと言うことは分かっているのですが、年齢も30になってしまったので、今後そうそうチャレンジできる機会も少なくなってくるだろうと言うことで転職に踏み切ることにしました。

正直、ここ2年は技術的に学べる人が誰もおらず、逆に私が一番知識的にあるということになっていて非常にストレスでした。自分のエンジニアとしての価値を計るためにこの業界に入ったにも関わらず、結局その辺りが未だにはっきりしていないという。生産金額として残した数字的にはダントツでしたが、たいしたことはやっていないので、中身が伴わず空虚な感じです。それで技術の分からない上司に妙に評価されるのもストレスでした。

もっともっと自分よりも優秀な人達と一緒に刺激を受けながらレベルアップしていきたい、そういう中で自分の実力を把握したいという思いが強く、また、このまま中身の伴わないマネージメント職に回されていく未来にゾッとした部分もあります。

今の会社の中で自分一人で周りを巻き込みながら成長していったとしても、他の自社サービスをやっているようなエンジニアにどんどん差をつけられていくのがわかってすごく歯がゆいものを感じていました。

そこで、自分の選択肢としては、頑張って会社を変えてくように努力するか、転職するかだった訳ですが、そこに気づくのが遅かったと言うことと、年齢的な部分もあり、後者を選んだということです。

今回、転職活動をしたときはなかなか結果が出ず、泣きたくなるくらい非常に悔しい思いをしました。前回転職活動をしたときもそういう気持ちになったはずなのですが、それを忘れていました。結局ここ2年間まったく成長が出来ていないことに愕然としました。

自分は我儘なことはわかっている。でもハッカーになりたい。2年前の転職のときに思っていたその熱い気持ちを忘れていました。

Webで生きていこうと決めたのが2年前で、そう決めるまでに自分は非常に回り道をしたと思います。でも、回り道をしてきた事を間違っていたとは思いたくないし、回り道をしてきたからこそ僕は肥沃だと信じたい。そういう意地があります。ああ、すごく恥ずかしいこと書いてますね。

だからこそ自分が成長できるステージってことで、大企業病のSIerではなく、自社サービス系の企業でチャレンジしてみようと思い次の職場を決めました。

次の職場は、チャレンジできる機会も多そうで、何より目標と出来るエンジニアもいるので、しっかりやろうと思います。

かなりネガティブサイドの話をすると、今の会社は社員に手厚いので、しがみついている人が残りやすく、若くて出来る人が割りを食らい、そういう人から辞めていくという悪循環がありました。

僕は共産主義者で年功序列万歳なので(嘘)、能力が違えど給与がある程度横並びなのは別に構わないと思うんですよ。そういう会社は別にあっても良いと思うんですね。だって能力の差なんてある程度生まれつきなんだから、それで生きる生きられないくらいの給与の差をつけられちゃたまらないでしょう。最低限を保証して、かつ、上積みで差をつけるんなら構わないと思うけど。

でも、出来る人が死ぬほど残業して、出来ない人はむしろ居るのが邪魔だから定時であがってもらってみたいな状況が常態化しているのはいくらなんでもヒドイなと。しかも出来る人が残業しているのは、出来ない人が下手に動いてしまって、被害を出したときだったりするわけです。上のマネージメントの問題もあるわけですが。

あと、エンジニア業界は、スポーツ選手に近い部分があって、人によって効率が劇的に違うし、プライベートと仕事の差が付けにくい、日々のトレーニングで差がつくわけですよ。だからちょっと普通の給与体系が則さない部分てのはありますよね。色々難しいですね。

ということでまとまってませんが、待遇とかに関しても色々思う部分も有りました。

ただ、今の職場には給与面では全く不満は無く、転職したらむしろ下がることも覚悟していたのですが、結果的にはそこそこ上がることになり、身の引き締まる思いです。

だから実際ソーシャル系は今バブルなんだと思いますよ。だからこそ弾けたときに生き残れるかどうかってところは覚悟してないといけないと思うし、そういったところで戦って行こうという決心はしました。

今の会社を辞めるに当たっては、残せるものは残していきたいなぁということもあり、スキルトランスファーとか非公式社内勉強会とかをちょこちょこやりました。社内フレームワークを作ったのもその一環だったりします。非公式社内勉強会はもっとやっておけば良かったなぁとか思いました。

Yapafiの技術コラムが妙に充実してるのもそのせいです。

ところで、今年から本社グループの再編成があり、その関係で本社の人とも仕事をする機会が増えたのですが、本社出身の人はやはり優秀な人が多く、その辺は刺激を受けたんですが、退職を翻意させるまでには至りませんでした。

てことで、来年から心を新たに頑張ります。勝負できるステージで勝負してやろうと思います。

• http://www.songmu.jp/yapafi/
• http://www.github.com/Songmu/yapafi

「社内フレームワークとかダサッ」

とか言う声が聞こえてきそうなのですが、まあ、WAF作りはWebプログラマーのはしかの一つといわれるくらいですから。

実際のところ、社内でそこそこ実績のある社内フレームワークがいくつか有り、ただ、それらがいい加減古い設計になっていたり、今からするといけていない点があったりしつつ、なかなか移行が進まないと言う問題があったので、その辺りの刷新を狙って作りました。

まあ何で作ったかとかは、公開ページに書いてあります。

基本的にはワンファイルで動き、WAF自体が提供するのはディスパッチ機能くらいな感じの薄いフレームワークとなっています。コードジェネレータとか難しいこともやらない感じです。

あと、単独でFormValidator.phpってのを作ったのですが、これが結構いけてるんじゃないかと思っています。ただ、まだドキュメンテーションできていません...。

チュートリアルとサンプルを見れば大体どんな感じかは分かると思います。

• http://www.songmu.jp/yapafi/tutorial
• http://www.songmu.jp/yapafi/sample

モジュールなんかの作りはかなりCPANモジュールからパクらせてもらっています。以下のモジュールはそんな感じですね。

• Mail_Address_MobileJp
• Devel_BackTraceAsHTML
• DataValidator
• FormValidator

PHPはPEARがイマイチ使いづらいので、集合知の部分はPerlに劣るなぁとか思いました。PEAR2に期待。