はてなエンジニアブロガー祭りに登壇しました

去る12月14日に開催された「はてなエンジニアブロガー祭り」で第二部のパネルディスカッションに登壇しました。当日の様子は Togetter のまとめやはてなブログのトピック「エンジニアブロガー祭り」のエントリ等をどうぞ。

人生初のパネルディスカッションでうまくやれるかドキドキでしたが、はてなスタッフの方々やモデレータの高橋さんと事前打ち合わせでしっかり認識合わせができたり、非モテ時代の話やらはてな愛やらで暴走しがちな僕をパネラーの皆さんが上手にフォローしてくださったおかげで、つつながく終えることができました。ありがとうございました。

「はてなエンジニアブロガー祭り」に登壇しますを書きながら「これはぜひ言いたい」と思っていたことはだいたい当日言えたので自分としても充実したイベントでした。充実しすぎてブログに書く感想が思いつかないほどです。はてなのイベントに出していただいて、はてな民冥利に尽きます。

他のパネラーの方々のお話もとても興味深かったです。吉岡さんがおっしゃった「未来のいつか」の意味を知ったときは、自分もそういう風に思っていた（けどうまく言語化できなかった）のだ、とはっとさせられましたし、 t-wada さんが指摘された「過去を時系列で振り返られる」という点もまったく同意でした。堤さんのブログとの向き合い方は自分とずいぶん違っていて、ブログの懐の深さを再認識しました。

ブログを書く理由やモチベーションは人それぞれで、同じ人であってもその時々で移り変わっていきます。僕自身、誰かに何かで認められたいという自己顕示欲や承認欲求もありますし、未来の自分を含めた誰かの役に立ちたいというささやかな貢献の気持ちもありますし、書きながら考える・思考するツールとして利用するという極めて私的な目的もあります。そういう多面的な、混沌としたものを受け止めてくれるから、僕はいまだにブログを書いているのでしょう。

photo by Maria Reyes-McDavis

MongoDB Tokyo 2013

I attended MongoDB Tokyo 2013. I heard three sessions at noon.

(Since I forgot to get any novelties so there are no photos in this post :(

Indexing & Query Optimization

David talked about indexing and query optimization on mongodb. He tried to explain not only what index is, but how it works by diving into B-Tree index explanation. It was quite good to understand why some queries can't get benefit of poor-designed indexes. I have an experience of MySQL so I often noticed these are very similar on indexing. Since his presentation material has a lot of sample codes, I really want to see it again on the web.

Data Processing and Aggregation Options

Stephen introduced about useful tools for data processing on mongo. He explained Aggregation Framework at first. It sounds very powerful. Moreover it looks not so complex. He talked about MapReduce and integration to external services like Hadoop too. In conclusion he suggested Aggregation Framework as might be a best solution. I'm not sure whether I really want to do heavy server-side data processing, but if the time is coming I will try Aggregation Framework at first.

Data Modelling Examples from the Real World

In Matias's talk, he explained the difference of thinking about schema design between RDBMS and mongo. He also showed us two "real world" examples to solve common problem of application development. Actually this session is main purpose why I went to that event. He explained "message inbox" and "history" data model patterns. I think it was a presentation about designing application architecture. That's very good. He concluded that the important point is to make sure the use case of your application. There are many solutions and cases.

Thoughts

There were many business person wearing suit. Usually I'm scared of "suit" guy, but I also impressed that those business person really interests about MongoDB. I guess MongoDB is definitely used in serious business world and many people pay proper money to MongoDB business. It's quite good. I hope the MongoDB company (formerly 10gen) to keep growing in future.

All of English sessions had one-by-one translation. Translation itself was good, but truth be told I was not satisfied with quality of translation. It can't be helped though, translators didn't seem to have enough technical knowledge, so they sometimes said strange translation. For example, when speaker explained about querying with regular expression, he said the pattern starts with caret character (/^foo/) will use index. But translator called this symbol "carrot" (speaker jokingly performed to bite carrot, lol) In that case, we might not need translation about "caret" because it was very clear for most of audiences (I assumed attendees were engineers..)

But I want to say thank you to translators again, because due to one-by-one translation, speaker talked slowly and intermittently so I could hear and concentrate their speech relaxed. I think it was good for not only people who can't listen English at all but also people who can listen English somehow.

I got back to office without attending networking party, but when MongoDB Tokyo 2014 is held I want to attend after party to meet some MongoDB guys too. Thank you all of speakers, organisers, translators and MongoDB staffs.

Book: 諦める力

諦める力?勝てないのは努力が足りないからじゃない

元陸上選手の為末さんの「諦める力」を読んだ。「勝てる見込みのない場所で努力を続けるよりも、自分の能力で勝てるフィールドを見つけて少ない努力で勝つ、それが戦略であり、勝ち目のない勝負を避けるために諦めることは決して後ろ向きな決断ではない」みたいなことがいろいろ表現を変えながら繰り返し語られていて、自分も似たようなことをよく考えるので印象に残った。

ここ二、三年で自分のキャリアについて考えることが増えた。ソフトウェアエンジニアの仕事に年齢は関係ないのであまりそれを基準にしたくはないが、二十代半ばくらいの頃は「自分はおそらくこの分野で一番の人物にはなれないだろう、しかしあくまでそこを目指して努力するべきだ」と考えていた。今思えば、不可能なことに挑戦する自分（と若干の悲壮感）に酔っていたのだと思う。

しかし三十代に入り、「自分の能力やできる努力の量、費やせる時間等々では一番になるのは到底無理だから、一番になれなくてもこの仕事で食べていける方法を探そう」と考えるようになった。ソフトウェア開発の仕事は好きだし他のことに比べて得意だという自負もある。その仕事で安定してそこそこ稼ぐのが自分の目的で、一番になることは単なる願望に過ぎなかった、そんな感じだろうか。

理屈ではわかっていても感情的に折り合いをつけるのは難しい。自分は見栄っ張りなところがある。注目を浴びるのが好きだから、ソフトウェア開発者のコミュニティで一目置かれたいという野心も手伝っていろいろ発表をしたりもしてきたし、ブログを書くのも一番の理由は自分自身のためと言いながら、はてなブックマークでの反響を人一倍気にしてきた。でも残念ながら、一番になれるほどの人気も反響も得られなかった。

為末さんは著書の中で、「陸上の花形競技である100メートルは競技人口も飛び抜けて多く、才能ある人が多数しのぎを削っている。自分がそこで勝つのは無理だと悟って、マイナー競技だが勝てる確率の高い400メートルハードルに移った」と言っていたが、叶わない願望を前に自分がとった行動はこれと真逆だった。「勝てるかもしれない」という夢を見れないくらい広いステージに行こう、と思ったのだ。

一番になりたいという競争心がどこからうまれるのかを自分なりに分析してみた結果、「東京で一般消費者向けのウェブサービス開発をしている職業ソフトウェアエンジニアのうち、コミュニティ内で目立っている人たち」という層を過剰に意識しすぎている、という結論に達した。この条件に当てはまる人たちは、自分の感覚だと二百人から三百人くらいだ。三百人と競争したら、頑張ればベストテンくらいには入れるような気になってくる。しかしその中には世界でもトップクラスの人たちもいて、この小さい集団のランキングで上位に入るのは想像よりずっと難しい。

それならいっそ、ランキングの順位を意識するのなんてばかばかしいくらい広大な集団のなかに身を置いたらどうだろう。三百人中で十位下がったらショックだが、三百万人中で十万位下がっても気に病むことはないような気がする。それはもうランキングと呼べる性質のものではない。他者を意識して競うことへの執着心を断ち切れるのではないか、と考えた。

先日登壇したイベントで、質疑応答の際に「前職では Heroku の競合にあたるサービスを作っていたのに Heroku のヘビーユーザー企業へ転職したのはなぜか」という質問を受けた。その場にふさわしい質問だったかどうかはさておき、「英語でソフトウェア開発をする仕事に就きたかったから」と答えた。そのときはキャリアアップ的な側面を押し出して回答したが、改めて考えると「勝ち目のないランキングでのし上がることを諦める」という動機も大きかったと思う。

最近、仕事でロンドンの開発者とやり取りすることが増えた。イギリス人の小難しい英語に首を傾げながらモジュールの設計方針について議論したり、どの国から来たのかもわからない人のコードレビューをしたりしているが、不思議と彼らに対して競争心を感じることはない。こちらが日本のどこかのランキングで上位にいたとしても彼らはどうとも思わないだろうし、そういう価値観が通用しない相手だからこちらも変に意識することもなく肩の力を抜いて接することができている。

自分が固執していたものは多様な価値観に基づく「良し」のうちの一つにすぎず、その世界の外で暮らしている人たちのほうがずっと多い。そういう風にものごとを相対化してとらえられるようになった。最初からそれを狙って環境を変えたわけではないが、自分にとって望ましい変化が得られたことは大きな成功だったと思う。

特に結論めいたものはないが、毎日暮らしているなかでふとした隙間時間—歩いているときとか、湯船に浸かっているときとか—にこういうことを考えていて、そういう断片的な思考の積み重ねが自分自身の価値観を築いていくのだと思う。たまにこうして文章化することで、もやもやとしてつかみ所のなかった思考にくっきりとした輪郭を与えられる。こういう作業には、やっぱりブログが一番向いているな、と思う。

Book: Working With Ruby Threads

I am a fan of "Working With ~" series wirtten by Jesse Storimer. I read Working With Ruby Threads. This book describes concurrency in Ruby world.

Semantically, this book has three parts.

In the first part, author defines difference of concurrency and parallelism. I'm not sure whether this definition is general or not, but clear definition for ambiguous words makes this book easy to understand.

Second part is tour of low-level thread APIs such as Thread, Mutex and Condition Variable. One of the most important thing I learned from this book is "Don't use low-level thread APIs by myself". It's too difficult to use properly.

Last part is example of Ruby's concurrency in read world. Author introduces Celluloid, an actor-style concurrent framework. Even though there is not so many codes, it's enough to give a basic knowledge of it. He also explains Puma's thread pool implementation. This is more complex than Ceclluloid basis.

After reading this book, I'm interesting more about concurrency in Ruby. I read a few lines of code of Ceclluloid and changed default ruby interepreter of my machine to Rubinius. My first contribution for Rubinius was fizzled out, but I wish to keep in touch.

Tech Compass #6 Love Heroku? の発表資料を公開しました

Tech Compass #6 Love Heroku? の発表資料を公開しました。ご参加いただいた皆さん、マイナビ様、ありがとうございました。

Heroku を利用した Quipper の開発事例紹介

Quipper におけるサービス開発・運用において、 Heroku をどのように利用しているかを具体的なユースケースを交えて紹介しました。全体的に褒めるトーンなのは Heroku のイベントだから、というわけでもなく、実際に仕事で使ってみて便利さを実感した上での意見です。

ただ、資料にもあるようにあえてアドオンを使わないという選択も十分ありえると思っていて、資料では省きましたが例えば SendGrid もアプリ個別のアドオンではなく直接一つアカウントを契約してしまって共有したほうが、 SPF レコードの設定漏れを防げるなど、手間を省けそうだなと思っています。

ちなみにその SendGrid ですが、構造計画研究所さんが日本での代理店業務を開始したそうで、12/10に無料セミナーを開催するそうです。 Quipper でもメール配信まわりは「SendGrid が定番でしょ」という感じで利用しています。日本語サポートがあるのは日本でサービスを展開する際は心強いですね。

---

イベント自体の感想としては、 Wantedly の川崎さんの言葉がいくつか印象に残りました。

デプロイ職人を作らない、デプロイを属人的な仕事にしない

僕もまったく同意見で、以前ブログにも書いたことがあります。 Heroku は git push でデプロイできるので、独自の作法を覚える必要もなく、自然と作業の属人性を排除できるようになっているのがいいですね。

優秀なインフラエンジニアとしての Heroku

これも同意見で、優秀なインフラエンジニアがいればいいのですが、ただでさえエンジニアの採用が難しい昨今、さらにインフラのエキスパートともなるとそう簡単には採用できません。また、サービスの規模が小さいうちはそもそもインフラの整備に人手をかけるフェーズではないので、たとえエキスパートを採用できたとしてもその能力をフル活用できません。ならば PaaS のような手厚いホスティングサービスを利用することで、運用のプロ集団に丸ごとお任せしてしまおう、というのは理にかなった選択と言えます。

心配しなくていいことは、心配しない。 エンジニアなら、なんでもやりたくなってしまう。でも、サービスの成長のほうが優先度が高い。それに集中するために Heroku を使う。

Quipper 技術チーフの @masatomon もよく同じことを言っていて、 Quipper と Wantedly は実はエンジニアリング的な価値観がすごく似ているのかな？とちょっと驚きました。 Quipper でもたまに Amazon Web Service のちょっと込み入った機能を試してみようか、なんて話が挙ったりするのですが、みんな本音では新しい技術を実戦で試してみたい、せめてリサーチだけでもいろいろ手を出したいと思いつつも、モノになるまでにかかる時間や、使い始めてからの運用コストなどを鑑みて、割と現実的な選択をしています。

---

楽屋裏ねたをひとつ。発表の際に、世界地図に Quipper の拠点のピンがドロップしてあるスライドでピンの位置がずれてしまい、ロンドンオフィスが西アフリカのサハラ砂漠にあることになっていたりして失笑を買ってしまうミスがありました。実はイベント開始直前まで会場でスライドの手直しをしていて、その際に地図を上に移動させたのですが、ピンを移動し忘れていたんです。

プロジェクタへの接続確認などのため一時間ほどはやく会場入りしたのですが、スクリーンに投影した資料を実際に会場中ほどの座席に座って見てみたところ、文字や画像がスライド中央に配置してあるとけっこう下寄りに見えたんです。本番では前の席に人が座ることを考えると、おそらくスライドの下半分はもっと見づらくなるだろうな、と思い、文字色を濃くするのとあわせて全てのスライドを全体的に上方に配置しなおしました。

果たしてどのくらい効果があったかはわかりませんし（懇親会で聞くのを忘れてしまった）おかげで恥ずかしいミスをしてしまったわけですが、発表前に観客席からの見た目をチェックした上でスライドを修正する余裕があったのは今回が初めてで、なかなか良い体験になりました。ちなみに、公開した資料のほうは中央のほうが見やすいと思ったので、もう一度もとの位置にもどしてからアップロードしています。

それと、イベントの二週間ほど前から風邪をひいてしまい、しばしば咳き込むことがあってちゃんと喋れるか不安がありました。病院で咳止めやら風邪薬やらいろいろもらって服用していたのですが当日になってもなかなか良くならず、咳止めシロップを飲んでも咳が止まらなくてけっこう焦りました。本番の緊張感のおかげでなんとか切り抜けられましたが、あまり声が出てなくて聞き取りづらかったかもしれません。今年の RubyKaigi のときも同じように喉をやられていて、つくづく体調管理をちゃんとしないとな、と反省点が残りました。