« 2013年2月 | メイン | 2013年4月 »

2013年3月23日

「仕事に対する愛と情熱とプライド」若しくは新卒に向けたスピリチュアルな話

そろそろ新卒研修とかどうしようかとかで、エンジニア陣でわたわたしたりしています。「Songmu先生にはスピリチュアルな話をしてもらわないといけませんね」みたいなことを言われてなんかスピリチュアルキャラとして定着しているのもどうかと思います。

去年も「『仕事に対する愛と情熱とプライド』ってお題でソーシャルゲームチームの新卒向けに話してください」とか研修担当の人に言われて、なんでそんな熱いキャラとして認知されてるか謎だったんだけど、それで30分くらい話しました。

それが結構評判良かったみたいで、直接はあまり言われなかったんだけど「研修の時の先輩の話の中で一番印象に残っている」って言ってくれている人が多いって話を2年目の人から又聞きで知って嬉しく思っていました。

とか思っていたら、hisaichi5518の人は「なんかすごくいい話してた覚えはあるんですけど内容全く覚えてません」とかsoh335の人は「話したことすら覚えていない」とか言っていて、まあそんなもんですよね、っていう。

とはいえ、今年何か話すにしてもあまり去年と同じ事は話したくないなってのがあって、幸い去年の発表資料が残っていたのでそれを元にどんなことを話していたかを思い出しながら差し支えない範囲で書き起こしてみることにしました。

ちなみに以下の内容は僕個人が一年前に感じていたことであって、所属している会社の見解とは一切関係ないということを念のため申し上げておきます。


Songmuです。現在とある野球ゲームのリードエンジニアと最近出たばかりのゲームのインフラ周りのチューニングとかをやっています。

リードエンジニアって何をしているかというと、開発だけじゃなくて、スケジュール管理とか、ディレクションとかプロジェクトの動き全体を取り仕切るようなことをしています。

今のプロジェクトチームは売り上げ的に成果を上げているだけじゃなくて、社内のソーシャルゲームの中で、一番バグ発生率が少ないし、CS関連のチケットを0に保つことにプライドをかけています。ソースも一番モダンで綺麗だと自負しています。

現在、中途に入って2年目になったくらいです。Perlに関してはゲーム事業部では一番詳しいと思います。Perlが好きで今の会社に入ったようなもんです。

ただ、Perlに詳しいってのは決して技術力が一番あるってわけではないです。この辺りは非エンジニアにはわかりづらいかもしれません。他の事業部にはもっとPerlに詳しい人もいます。更に言うとPerlに関してだったら、そこにいる新卒のsoh335さんとかhisaichi5518くんの方が詳しかったりしますね。

野球が好きで、中国語が話せます。ロードレーサー2台とボウリングのマイボールを2個持ってます。これはどうでも良いですね。


愛と情熱とプライドっていうお題だけど、自分のことはたいしたことないと思っているからあんまプライドとかは無いかも知れないです。エンジニアとしては底辺だと思っています。

仕事に対してはドライなつもりです。土日とか働くことを薦めたくないし、そうなってしまっているのは、仕組みとしてイケてないからであってそういう働き方をしていることにたいして自己満足に陥ってはいけない。

個人の馬力で何とかしてしまうのはイケてないし、長く働いている人は無能だと思っています。僕自身も。

非日常に高揚感を感じるのはオナニーでしか無いし、成功体験としてしまうのは危険。徹夜してやりきったみたいなのに満足するんじゃなくて恥じるべき。

とは言え、僕自身は夜遅くまでコード書いたりするのは楽しかったりするけど、そういう状況を俯瞰的に捉えられた方が良い。

行列のできるラーメン屋に何十分も並ぶことは馬鹿馬鹿しいけど楽しくもあったりするみたいなようなこと。

「今年もきっと戦後最大の危機です」って社長が言ってたことがあって、これはすごく面白い言葉だなーと。決して揶揄の文脈じゃなくて、それはもうそういうもんで、そう捉えてそれに乗っかっちゃったほうが面白いんじゃないかって話。

そういうことを自覚しながらバランスをとることが大事だと思う。

仕事ってのは試合のようなものだけど、試合だけじゃ強くなれないと僕はスポーツとかやってきた経験から思ってるから、長時間仕事するのはやっぱ良くないと思っています。


今の会社の文化と仕事に関して去年強く感じたのは

  • 何をするかより誰とするか
  • のっかる文化

の2点。

入社式の時に代表の一人がわけわかんない英語か何かを発話してたけど実は良いこと言ってて、あれは岡本太郎の言葉で

情熱があって何かを始める人なんて少なくて、普通は何気なく始めたことに無意識のうちにのめり込んで、そこから情熱が生まれる

ということです。これは本当にそうだなーと思って、僕自身一年間働いてきて、周りは本当に良いやつらばかりで一緒に働くのがすごく楽しかった。入社した時はソーシャルゲームとか好きでも嫌いでもなかったけど、今は情熱を持って取り組んでいます。

入社してしばらくしてから野球ゲームの新規プロジェクトチームにジョインできたのがすごく運が良くて、それによって僕自身がすごく野球が好きだったってことを思い出すことができて、開発しているゲームに対して思い入れを持てたし世界観に入り込むことができました

あと、プロフェッショナルなエンジニアとか、凄腕のデザイナーとかがいるすごくいいチームで開発ができた。

前の会社までは僕はデザイナーと近くで仕事をしてなかったけど、今の職場は美大出身とかの本気のデザイナと机を合わせて仕事できる。これはエンジニアにとって、モノつくりをする上でとてもよい環境だと感じています。

そのチーム中で僕自身も必要とされたから、自分のプロダクトに誇りと責任を持たざるをえないし、その期待に応えることがモチベーションにもなっています。

そのプロジェクトが結果として成果を上げることができていることもあって、すごく良い成功体験をさせてもらえたと思っています。

今年から引き継いでリードエンジニアをやってるけど、その位置に居るのは僕自身の意識が高いとかじゃなくて、いろいろな意味で運が良かった。運が良かったけど、それは状況に素直に乗っかっていったから掴み取れたものではあるかなとは思っています。

今運営している野球ゲームは、ユーザー同士でチームを組んで試合が行われたりするんだけど、こちら側が思いもよらないようなドラマチックな展開が生まれたりします。強いのになかなか優勝できない悲劇のチームとかが、念願かなって優勝したりすると運営側も盛り上がったりします。普通に野球の試合を見ている感覚ですね。

ユーザーと一緒にゲームの世界を創り上げている感覚があって、それは経営理念の「つくる人を増やす」にもつながっていると手応えを感じています。


今ソーシャルゲームに対しては色々ネガティブなことが言われていて、僕自身も抵抗が全くなかったといえば嘘になります。ただそこに何故飛び込んで来ることができたかと言うとこれまでの経歴が無縁ではありません。

僕はかなりダメな人生を送ってきてて、大学はSFCだったけどコンピュータとかあまりやらずに中国語ばっかやってました。一応機械翻訳の研究とかもやってる体でしたが基本適当でしたね。卒論も書かないで卒業しました。

僕が就職活動してた時期は、俗に言う就職氷河期だったんだけど、SFCの学生ならSEには比較的なりやすかったようです。実際に受けてないからわからないんですけど。

でも大学でコンピュータをあまりやってなかったし、周りが(僕よりもコンピュータを扱えない人でさえも)どんどんSEになる中、僕は尚更安易にSEとかになりたくないみたいな屈折が生まれてしまって、出版社志望を気取ってたんだけど、結局どこも内定取れずに就活に失敗しました。大分厨二ですね。

それで、大学卒業後に中国に行ってそこでITベンチャーの立ち上げ手伝ったりとかしてました。結局ITかよって話です。で色々あって、給与未払いみたいなことが起こりそうになって、お金が底を尽きて日本に帰ってこざるを得なくなった。突き詰めると僕自身の実力不足です。

それでお金がないからどうしよう、でももうITの仕事はコリゴリだとか思って、結果として見つけたのが語学学校。駅前留学とかそういうやつです。

中国語のスクールマネージャの営業職に応募したんだけど、連絡が来ないのでダメ元でこっちから電話したら英語と中国語のオンライン/電話レッスンの営業担当兼システム担当全般みたいなポジションで雇ってもらえることになった。結局ITから別れられません。

後から聞いたら応募フォームの情報チラ見で落とされてたみたいなんだけど、電話した時に担当の人が再度情報を見なおしたら以前IT系の仕事をしていたことが目に止まって、そういうポジションの人がちょうど足りなかったから採用してもらえたようです。

そんな感じで、わらにもすがる気持ちで入った語学学校業界なんだけど、入った当初は業界を馬鹿にしていた部分がありました。馬鹿なOLとかリーマンを喰いものにする業界だろ?的な。

ところが実際は教務の人とかは圧倒されるくらい情熱を持っていて「日本人が英語・中国語を話せるようにするにはどうすればいいか」という命題に真剣に取り組んでいる。営業の人も本気でお客様の事を考えられる人が結果を残すことが多かったです。

「ネイティブ講師つけておけば大丈夫だろ」的な適当なことをやっている学校もありますが、僕が勤めていたところはそうではありませんでした。

口先ばかり上手い営業の人は新規契約率は高めだったとしても、更新率が低くなる。ちゃんと契約後にお客様の事を考えてケアできる人は更新率が高くなります。実際、新規契約率は水物だけど、更新率は努力次第で大きく上げられるから、そっちのほうが成果につながるんですよ。

入る前は全然未知で偏見すら持ってた業界だったけど、入ってみるとそういう風に実は得るものが大きかった。その時の体験があるから、何かと言われてるけどソーシャルゲーム業界に入っても得るものはきっとあるだろうなと思うことができました。

ちょうどその頃は、とある語学学校が色々消費者問題とかを起こして経営破綻したとかそういう問題で騒がれた時期でもあって、世間の語学学校業界に対するネガティブな印象がすごく強かった。なので今のソーシャルゲーム業界に似ているなーってのも感じたので逆にソーシャルゲーム面白そうだなと思った部分もあります。

その事件もあったのでお客様を搾取するモデルは結局長続きしないなってのを確信しました。誠実に運営することが最終的に成果につながるっていう僕自身のポリシーを、単なるキレイ事以上のレベルでこの頃から信じられるようになった。僕自身嘘をつくことが苦手なのでそう信じて動けたほうが気分が良いってのもあります。今もそう思いながらゲームを運営しています。


それでなんで今エンジニアやってるんだ?って話になります。これまでの話の通り、避けていたつもりのITが何故かずっと付いて回ってきてたんだけど、それでも「ITはあくまで仕事の手段でしかない」とか厨二臭いことを思っていたわけです。ただ、それが段々楽しくなってきて「あ、僕Web好きだ」って認めた瞬間に僕の中でブレークスルーがありました。すごく視界がひらけて自分のやりたいこととかが明確になった。

それで転職してSIer勤務を経て今の会社にいます。後から思えば、ツンデレじゃなくて素直にさっさと「好きだ」って認めちゃったほうが良かったなと思います。


仕事に対する愛の話なんですけど、僕は最後は「愛」だと思っています。

これは人それぞれスタイルがあると思うけど、僕はこれまであんま先のことは考えずに、妻に対する愛だとか自転車に対する愛だとかプログラムに対する愛だとかPerlに対する愛だとかプロジェクトに対する愛だとか、そういうものに突き動かされて生きてきたので、それが一番パフォーマンスを発揮する方法だと感じています。

ただ「仕事を愛しましょう」とかアホくさいことを言うつもりはないです。「愛国心を持て」という言葉みたいに滑稽ですからね。ちなみに僕は日本好きですよ。

束縛しようとしたって束縛できないし、束縛しようとするのは自分に自信が無い証でしかない。愛せる人になるのが大事だと思います。自分から愛するものにコミットするってだけで、愛させるとか愛してもらうとかどうでも良いのです。

その愛が単なる身勝手に終わらないためには「好きな事しかしない覚悟」を持つことが大事かなーと思っています。

よく「自分事化」とか「全部自分の責任」とかそういう言葉が社内では出るんですけど、間違ってはいないんだけどちょっと息苦しい感じがして嫌だなーと思う部分があって、僕としては「好きな事しかしない覚悟を持つ」と思っていた方が気分が良いなーと思っています。

よっぽどまともな判断力を奪われた悲惨な状態とかじゃない限り、自分の人生の選択に対して最終的に判断を下しているのは自分なんだから、それは結局アナタが選んだアナタが好きなことでしょってことです。

今僕はエンジニアとして働けていて、自分の好きなコトやっているのですごく充実しています。


僕は苦行が嫌いで、そういう自分を傷つけて自己満足みたいなのは低レベルなオナニーでしかない。仕事も一緒だと思っています。

僕はほぼ毎年ハーフマラソンに出てるんですけど、ハーフマラソンは楽しく走れるから出てるだけで、苦しみたいから出てるわけではないんですね。何の努力もせずにマラソンを走って、苦しんだ自分を褒めてやりたいみたいな人はまあ低レベルです。

それでも練習不足の時はハーフマラソンが苦行になっちゃうこともあって、それは結果としては色々反省するわけですけど、やっぱ良いことじゃないなーと思います。つらい思いはしたくないんで。

フルマラソンは苦行だから出ないようにしてるんですけど、フルマラソンが苦行じゃなくなったら自分としてはステップアップかもしれません。


仕事に対するプライドなんですけど「自分にしかできないことを見つけてそこにプライドを持つこと」が大事なんじゃないかと思っています。

そうは言ったものの「自分にしかできないこと」なんてそうそう見つかるもんじゃないと思ってしまうかもしれません。

でもそんなに難しくない方法があります。それは「レッテルに乗っかる」ことです。

僕の場合は例えば、コードが綺麗とかバグが少ないとかそういう「レッテル」を貼られるとそれに対してプライドを持つようになるし、バグをすぐ潰すようになる。

あとは、僕は今教育が得意とか、ドキュメンテーションが得意とかそういう「レッテル」を貼られていて、ホントは全然そんなこと無いんですけど、それに乗っかって、社内フレームワークのドキュメントを整備しなおしたりしました。

ただ、結局自分の評価ってのは他者が決めるってのが世の中の常だし、そういう「レッテル」が貼られるってのはどこかしらそういう側面なり素養なりがあるんだろうから、それに乗っかっちゃって強化してしまうのは結構有効なんじゃないかと思います。


エンジニアじゃない人も多いのでエンジニアって人種に少し触れておこうと思うんですけど、エンジニアは技術そのものが好きで、目的と手段が入れ替わってる人が結構多いかなと思います。技術に理解のない人は信用しない職人気質な人も多いですね。

エンジニアに限らないかも知れないんですけど、仕事だけじゃスキルが向上しない部分があるので、エンジニアの人は仕事以外でちゃんと勉強するとか、社外の人と交流を持つことも大事です。

この会社はWebクリエーターの会社ということになってるので、エンジニアに限らずHTTPは喋れないといけないと思います。喋るって言うと難しそうに思えるかもしれないけど、単にメッセージのやり取りの方法なのでどういうことをやっているかって感覚は持っておいたほうが良いと思います。

僕個人としては、プログラミングは今後必須スキルになってくると思うし、学校とかでも教えたほうが良いと思ってます。英語よりも大事なんじゃないかな。

まあそんな感じで気難しい人も多いですが、よろしくお付き合いください。


最後に感謝することについて話したいんですけど、僕は基本的に「自分にできないことが出来る人はすごい人」だと思っていて尊敬と感謝をしています。

なので、チームのメンバーとかもそうなんですけど、CSとか管理分門とかインフラの人たちには本当に感謝しています。

特にCSとか管理分門とかインフラの人達とかは僕等のクリエイターとしてのパフォーマンスを上げる仕事をしてくれているわけで、感謝してもしきれないですね。

普段は目につかないものとか見えないものに対する想像力ってのはクリエイターにとってすごく大事だと思うんですけど、CSとか管理分門とかインフラとか普段あまり接点のない人達がどれだけのものを僕たちに与えてくれているのかよくよく想像してみると良いと思います。

ちゃんと感謝を伝えると良好な信頼関係を築くことができるし、信頼関係が築けていると建設的に意見をぶつけあって喧嘩することも可能になります。

ゲーム運営をしていると、CSチームと関わることが多くなるんですけど、僕はお問い合わせの最前面にいて対応してくださるCSの皆さんにはものすごく感謝しているし、CSの声はユーザーの声だと思っています。CSからくるチケットとかを丁寧に迅速に返すことがユーザーの満足度に繋がって、結果としてお金を使ってもらえる、ゲーム運営を長く続けられると僕は信じています。

もちろんCSの負担を減らすためにも、とにかく不具合は出さないことも重要です。

CSチケットを後回しにしたりとか、CSに共有せずにイベント始めたりとかそういうことを続けていると、CSチームと関係性が悪くなってしまいます。元々CSは常にユーザーさんとやり取りをしているので、どうしてもユーザーさん側の熱量に押されて感情移入をしてしまいがちな部分があります。

なので、CSと信頼関係が築けていないと、CSにも開発チームが悪者扱いされて四面楚歌になってつらくなりますし、運営にも支障をきたします。

逆にCSチームと関係性が築けていると、些細なバクの兆候とかも早めに伝えてくれるようになったりします。またCSがユーザー側に感情移入しすぎている時でも、信頼関係さえあれば、開発側の熱量をぶつけても建設的な意見交換ができ、開発側の意見も汲み取ってもらいやすくなります。

なので、感謝は人のためならずな部分もありますし、ちゃんと周りに感謝を伝えながら仕事をしていきましょう。

23:13

2013年3月18日

carton execでTest::mysqldが起動できなくて泣いた

% carton exec -Ilib — prove -lv t/mysqld.t
*** mysqlinstalldb failed ***
Can’t locate lib/core/only.pm in @INC (…

結論から言うと、carton execしたperlと別バージョンのperlがどこかで使われて、 そのPerlにlocal::lib(lib::core::only)が入っていないと死ぬ。

Test::mysqldだと、mysql_install_dbっていうMySQLのコマンドをキックしている んだけど、それが実はperlスクリプトで、/usr/bin/perlってshebangに書かれていて System perl前提にしているのだけど、それにlocal::libが入っていないとコケる。

Carton:CLI#cmd_execの中でPERL5OPTを以下のようにセットしているんだけど、 それが配下のプロセスにグローバルに影響を与えてしまうのが原因。

local $ENV{PERL5OPT} = "-Mlib::core::only -Mlib=$lib";

とりあえず手元では sudo cpan local::lib して凌いだ。cpanコマンドとか何年ぶり だろうかw

perlで書かれてSystem perl前提にしているコマンドをキックしているような場合に 軒並み動かない可能性があるので場合によっては困りそう。

根本的な解決は難しそうだなーという気はしているんだけど、とりあえず、 issueあげておいた。

該当のperlにlocal::lib入れれば解決するので、同様の現象で悩んでいる人も いるかもしれないのでとりあえずblogった。

local::libがperl coreに入れば徐々に解決といえば解決ではある。

3/18 23:45 追記:

ということで、既知の問題で修正を考えているとのことです。なんかこうmiyagawaさんから反応あるとすごく嬉しいですね!

11:00

2013年3月12日

おもむろにbrew upgrade mysqlしたらTest::mysqldが起動しなくなって泣いた

*** mysql_install_db failed *** FATAL ERROR: Could not find my-default.cnf

If you compiled from source, you need to run ‘make install’ to copy the software into the correct location ready for operation.

If you are using a binary release, you must either be at the top level of the extracted archive, or pass the —basedir option pointing to that location.

5.5から5.6に上がったので、なんか壊れちゃったかなーと思ったけど、 mysql自体は起動するので、どうもhomebrewとTest::mysqldの相性の問題であった。

Test::mysqldではmysql_install_dbコマンドの場所からmysqlインストールパスを探しているようなの だけど、homebrewだとwhich mysql_install_dbで返ってくる /usr/local/bin/mysql_install_db は単なるシンボリックリンクなので、そのへんでうまくいっていない模様。

なんか、

% ls /usr/local/Cellar/mysql
5.5.28/ 5.6.10/

とかなっていて、5.5のプログラム自体残っていたので、それが影響しているのかなーと思いきや、 エイヤッとrm -rf 5.5.28してもコケたままなので、なんでそもそも動いていたのかが謎い。

とりあえず、実行ファイルがシンボリックリンクだったら、readlink呼んで実体パスの 解決を行うようにしたら動くようになったので、とりあえずpullreq送らせてもらった。

Test::mysqlのCPANTesters見たら 見事にオールグリーンで自分の環境が悪いのかと一瞬怯んだけどdarwinはなかったので安心(?)した。

ちなみにreadlinkとか初めて使ったというか知らなかった。

追記:ちょっと調整して取り込んでもらった!ありがとうございます!

15:24

2013年3月10日

App::Xaicron構想

タスクの定期実行としてcronが使われ続けていることに問題意識を抱えている人は数多く居れども、多くは惰性で使い続けている。何を隠そう私もその1人である。

そんな中、近年ではcronの代替としてjenkinsを使うという斜め上の発想が蔓延りつつあるが、 そんなことをすると「cronに500Mもメモリ使ってられるかー」と椅子が飛ぶこと請け合いなので非常に難儀するものである。

斯くの如く問題意識を抱えていたものの、やはり惰性でcronを使い続けていたのだが、 昨日、代替cronのネーミングとして “xaicron” という非常に格好良い名前を思いついてしまったので、 この際代替cronについて考えてみることにする。

懸念事項としては、将来RPMパッケージ化などされた時に、実行ユーザーとしてxaicronが作られてしまって、 万が一xaicronというユーザー名を使っている人がいた場合に困るというのがあげられる。 (世界中のjenkinsさんは困ってないんでしょうか)

または、そのネーミングだと午前中は仕事してくれなさそうだという意見も頂いております。

ネーミング駆動でまだ全然イメージ湧いてないのですが、とりあえず、cronのpros/consを思いつくままに書いてみます。

cronの良い点

  • 枯れている
  • crondが落ちて阿鼻叫喚みたいなことはあんま考えなくて良い
  • Unix系なら大体どこにでも入っていてすぐ使える
  • 記法は大体みんな知っている(謎記法だけど)
  • 一つのエントリが一行に収まっているので綺麗に書けば一覧性はある(かも知れない)
  • 実行権限がユーザーごと別れてたりとか最低限の環境変数しか設定されてないとかセキュリティに配慮されてる
  • unixという考え方に則りsetlockとかsoftlimitとかcronlogとかtimeoutとかそういう細かいツールを組み合わせれば色々できる

cronのイケてない点もしくはcronができないこと

  • 記法が謎で初学者にやさしくない。間違えて毎分設定にして泣く人続出
  • setlockとかcronlogとかtimeoutとかsoftlimitとか覚えないといけないので敷居が高い
  • $PATHがちゃんと設定されていなくて動かないとかでハマりがち
  • crontabで環境変数の展開とかしてくれないの大分ダルい
  • 設定の横幅が長くなりがちだったり、ちゃんとスペース調整しなかったりすると読めなくなる
  • ちゃんと実行されるかどうかの確認に3分くらい待たないといけない
  • 後続の処理とかこの処理が失敗したらこの処理は走らせたくないとかそういう処理の親子関係みたいなのが設定できない
  • 標準の通知先がメールなので、いちいち全部のエントリーに| loggerとか書くのがだいぶダルい。結果としてログを捨てる人続出
  • 時間単位でしか設定できないし秒単位の設定ができない
  • 通知を受けてジョブを走らせるみたいなことができない
  • 設定を動的に変更するとかそういうことがやりづらいしやらないほうが身のため
  • Webインターフェースがない
  • 並列/排他処理とかは自分で頑張るしかない
  • 複数サーバーをまたいだジョブ管理とかができない
  • リトライとかタイムアウトとかできない
  • VCSとの連携(チェックアウトして実行とか)
  • 可視化ツールとの連携
  • プラグイン機構が無い

上記を踏まえていまぼんやりと考えているのは以下のような感じ。

  • 分かりやすいジョブ設定・環境変数設定
  • ジョブ管理デーモンがいて、うまいことクライアントと連携する
  • トリガによるイベント駆動的なジョブ実行(定時実行もそのうちの一つに過ぎない)
  • プラグイン機構
    • ジョブ実行前・実行後のフック機構
    • ログや通知機構の充実
    • 可視化
  • Webインターフェースは敷居を下げるためには必要

クライアント側に関してはUkigumo::Clientがだいぶイケてるので、そのへんからパクってくればいいかなーと思っている。 Ukigumo::Clientをもうちょっと抽象化したやつを切り出して、Ukigumo::Clientはそっちに依存する形でも良いのかなーとか思っている。

デーモン側はno plan。

こういう時参考実装とかをサクッとかけたりすればカッコいいんですけどねー。

15:30

2013年3月 9日

もにかじでオレオレ監視ツールについて話してきました

オレ自身を監視するツールって話なんだけどな!発表資料は以下。

オレオレ監視ツール

自分が触っているアプリケーションでのタイプ数を可視化するツールです。

なんか手元のMacにGrowthforecastが簡単に入らなかったのでカッとなって VPS上に構築しました。これで僕の行動が世界中からまるわかりです!

3/11追記 手元にHRForecast立ててそれで代用したのでURL消しました

適当に設定したら偶然にも調度良く赤系(iTerm,Macvim)が仕事、緑系(Chrome, Limechat) がサボり系になりました。Limechatがちゃんとライム色になっているのが素晴らしいですね。

仕組みとしてはごく単純で以下のような感じ。

  • KeyRemap4MacBookをdebugをONにしてキーイベントをログ出力
  • Slateでアプリの切り替えを検知してそれをログ出力
  • それらのログをtailで読み込んでperlスクリプトでゴニョってfluentdに投げる
  • あとはfluentd-growthforecastにお任せ
  • ソースとか設定とかこのへん https://gist.github.com/Songmu/5109279

本当はUkigumoについて話す予定だったのですが、木曜日に思いついてしまって、 社内IRCの雑談チャンネルでアイデアについて話したらKeyRemap4MacBookを使う アイデアをtypesterからもらい、Slate使うアイデアをsugyanからもらって、 なんか簡単にできそうだなーと思って木曜の夜に夜なべして作った次第。

調べたら、edvakfさんがすでに同じようなことをされている ことに気がついたのですが気にしないで作りました。

あと、帰ってから嫁にこのことを話したら

  • 去年のYAPCの川崎さんのトークでそういう話があった
  • isuconみたいなやつで全員コレ使えば面白そう

などとFBをいただきました。そういえばoDeskがそういうアウトソース監視の仕組みを 入れているって話をしていましたね。

ということでだいぶガイシュツネタでしたが、アリ物使ったら簡単に実現できるよってことで一つ。

運用寄りの猛者が集う中で、アプリ寄りの僕としては場違い感があり、しかも 参加者全員発表というモヒカンルールがあるのですが、ネタに走って凌いだ感じです。

「そんな風にアプリ寄りとか言っているとなんとかモリスさんて人にDisられますよ」

とか言われるし、モヒカン怖いですね。

そういやUkigumo大分イケてる感じなので、その話はそのうちまとめます。

22:32

2013年3月 7日

DBIx::Schema::DSLがWeek's winnerになりました

tokuhiromに教えてもらったのですが、なんかここで取り上げられられていました。

だいぶ数字が低いので、どさくさで運が良かった感がありますがありがたい話です。フィードバックも頂きたいものです。

解説すると、metacpanにはfavの仕組みが合って、https://metacpan.org/module/DBIx::Schema::DSLを見るとわかると思うんですが、 ログインした状態で、モジュール名右側を押すとfav的なやつを付けられるようになっています。

実はそれはこのへんで集計されていてランキングが見られたりします。

数字が寂しい感じなので、みんなもっと使って盛り上がると面白そうですね!ログインはgithubの認証で簡単にできますよー。

10:53

2013年3月 3日

DBIx::TransactionManager::EndHookが便利だけどCPANに上がっていない件

後輩だか先輩だかわからないsoh335さんが作った DBIx::TransactionManager::EndHook が地味にかなり便利。

入れ子になったtransactionでcommitが走った時に走らせたい処理を登録できます。 RDBだけで完結しない処理(ログやKVS連携等)を書きたい時に有用です。

何が嬉しいかは、335さんのエントリにも書いてあるんです が、例えば、ひとつのトランザクションの中で、

  1. アイテム付与メソッド
  2. ボーナス付与メソッド

みたいなメソッドを呼び出されていて、それぞれのメソッドの中でログを投げていた りとかするとします。コードにすると以下のような感じ。 (Tengっぽく書いてますが、DBIx::TransactionManager直でも全然構いません)

my $txn = $teng->txn_scope;

$user->take_item($item);
$user->try_to_take_bonus; # ここで死ぬと困る

$txn->commit;

...
sub take_item {
    my ($self, $item) = @_;
    $self->items->add($item);
    log('take item!');
}

この場合、もしtry_to_take_bonusの中で例外が発生したりrollbakeが呼ばれたりすると、 take_itemの処理も正しくロールバックされるのですが、take_itemの中でログ書き込み 処理とかが行われているとそこまでは正しく巻き戻すことはできません。

それじゃ困るってことで、DBIx::TransactionManager::EndHookの出番。先ほどの take_itemを以下のように書き換えます。

use DBIx::TransactionManager::EndHook;
sub take_item {
    my ($self, $item) = @_;
    $self->items->add($item);
    $teng->transaction_manager->add_end_hook(sub {
        log('take item!');
    });
}

このようにすることで、commitが走った後にログ書き込みをすることができます。

ログなんかの他にもcommitが走ってから確実にRedisのランキングデータを更新したい みたいな場合にも有用です。

僕なんかは「Rollbackとかめったに起こらないし、そこで多少ログ間違えて吐いても良 くね?」くらいに思っていたのですが、soh335先生はそこが気になったみたいでこうい う痒いところに手が届くモジュールが出来上がりました。

DBIx::TransactionManagerのメソッドをRedifineしたりとかしてるので、CPANに上げる のをためらっているようなのですが、まあprivateメソッドを書き換えたりしているわ けじゃ無いので良いんじゃないでしょうか。不安だったら、#dbix-skinny@irc.perl.orgとかで相談したらいいんじゃないかみたいな話をしております。

soh335先生は結構細かいところが気になる人で、とにかく綺麗にテスト書かないと気がすまなかったり「わたし、気になります」ばりに質問力を発揮したりこういう痒いところに手が届く便利ツールを作ってたりするので一緒に仕事をしていて捗ります。

そんな中生まれた、Test::Cond::Deepも地味に便利です。 →Test::Cond::Deepに関するエントリ

なんか、二番煎じの宮崎あおいばかり注目を集めていて、 彼が作った有用なモジュールの情報があまり知られていないようだったので勝手に宣伝しました。

ということで、DBIx::TransactionManager::EndHookもCPANに上げてほしい。

23:39

CartonConference行ってきた

当日からCarton触りだしてon testとかproveとの連携がどうたらとかtwitter言ってたら、tokuhiromとかmiyagawaさんに補足されて、その辺の現状とこれからの話とか知れてだいぶ良かった。カンファレンス駆動で学び始めるのだいぶ良い。

CartonCon自体もBundlerとの比較の話とか、現状のユースケースとかの話が色々出ててだいぶ捗った。

終わった後の懇親会が大分ひどくて楽しかった。

23:10

Hachioji.pm#25に行ってきた

もう一週間前ですが、大分面子が揃っていて非常に楽しかったです。

  • ytnobodyさんがTengよりも先にIrohaっていうORM作っていてだいぶ時代を先取りしていた
  • perl5.17でハッシュオーダーがかわった影響でJSON.pmのテストコケててリリースブロッカーになってる話
  • DBIx::Schema::DSLのフィードバックをmakamakaさんから頂いた
  • yanchaのタグでメッセージを管理する機構がだいぶ面白い
  • TengにTeng::Iterator 差し替えられるpullreq送った
  • LTE早くてテザリングが捗った

Hachioji.pmはcharsbarさんやmakamakaさん、hideo55さんなど渋目の超一流Perl Hackerとお話できるのがすごくいいですね。

karupaneruraさんにTengのIterator差し替えるpullreq送った話をしたら「それ僕も欲しかったんですよねー」とか言ってもらえて良かったです。

ちょうど(今も)messagepackが紛糾している時期だったので、makamakaさんにJSONでは そういうこと無いのか聞いたら「JSONの仕様よりもLehmann先生(JSON::XSの作者)とコ ミュニケーションとる方が大変で面白い」とか言っていたのが大分面白かった。

makamakaさんはAcmeの人というイメージが強そうですが、Perlのコアモジュールであ る、JSON.pmのメンテナなのは普通に世界的にすごい人ですよね。

最近Amon2を使い始めていたので、hirobanexさんとお話できたのも良かったです。

なんか最近ORMにしてもWAFにしても、ヘビーすぎるか軽いかのどちらかしかなくて、 調度良い具合のを作るには自分で何とかしないといけない部分が多くて結構コストが かかるってことを感じていたんですけど、そういう風に感じている人はやっぱ少なく無 いんだなってこととかを色々話して感じられたので良かった。

また顔だそうと思います。

23:07