今月の読み物晒し

先週手元に届きました。

Ruby 関連の洋書って赤い本が多い気がする・・・

仕事で Ruby を使う機会がないんで、両著の Ruby そのものに関する部分は仕事で生かせないけど、書かれている内容を一歩昇華させてメタなスキルとして自分に染み込ませることが狙い、ということで注文しました。まだどちらも半分くらいしか読んでないので雑感しか書けませんが

Ruby Under a Microscope

半年前に呼んだ電子書籍のハードコピー版になります。電子書籍購入者には半額のクーポンがついてたのでそれなら、ということで迷わず買いました。電子書籍で読んだとき内容もよかったですし。ハードコピー版は電子書籍版のチャプター数の2倍になっており、電子書籍にあったチャプターはより細かくチャプター分けしたうえで例と図を増やして分かりやすくしています。ソースコードにもろにダイブはしないものの、Ruby プログラムがいかに内部で処理されているかをスライドショーのように丁寧に追っていくところに非常に好感が持てます。この本から得たいメタスキルは、内部構造を把握していない人達に本質だけをいかにわかりやすく伝えるか。万人に分かり易くとなれば A picture is worth a thousand words というわけで図の出番なのです。コードを見せすぎず、図を中心にして説明していく筆者の腕はぜひとも今の自分の仕事に欲しい。あとはこういう本を書けるとこんないいことがあるってとこでしょうか。

Writing a book on Ruby internals: 18 months of hard work - giving a copy to @yukihiro_matz - priceless! #rubyconf :) pic.twitter.com/0bZf1ATbSL
— Pat Shaughnessy (@pat_shaughnessy) November 9, 2013

ところでこの著者の Pat さん、同じ州にいる方だったんですね。しかもボストンで定期的に開かれているボストン Ruby グループにも顔を出しているとか。

Practical Object-Oriented Design in Ruby

こちらは Amazon のレビューの良さとサンプルチャプターに目を通したときにピンときた直感を頼りに購入。著者の Sandi さんも Pat さんと同様、テーマに合う例をよく考えて選んでいる。あと Ruby だと他の言語にありがちな煩わしい syntax がなくてオブジェクト指向の部分だけに意識して読める。ふだんオブジェクト指向の決まりごとを頭に入れてるようでも、仕事だと Law of Demeter （遠くのヤツと話すな、直近のヤツとだけ話せ）や Dependency Injection （お前が勝手に取りに行くな、オレがくれてやる）を無視したコードをカタカタと書いていることがあるので、そういう自分のゆるい部分にストップをかける意味でもこういう具体例とともに、ベストプラクティスを無視するとどういう痛い目にあうかを分かりやすく書いてある本があるといい戒めになる。ちなみに良書を書く人同士はやはり巡り会うようです。

What an honor meeting @sandimetz in person yesterday! #rubyconf pic.twitter.com/dM5M1I07nA
— Pat Shaughnessy (@pat_shaughnessy) November 10, 2013

両著とも今月には読み終わるかな。最悪、年末に帰国する際の飛行機の中で読む時間たくさんあるし無問題。

Paint Ball 初体験、その後いろいろ感じたこと

平日ではありましたが、チームで半休をとり会社から程遠くない Ashland にある Paint Ball 場でチームアウティングをしてきました。

View Larger Map

日本にいた頃は一度も体験したことのないスポーツでしたが（そうスポーツなんです）今日の Paint Ball 場でプレイした限り、ルールはプレイフィールドに設置された障害物に身を隠しつつ、色の入ったシェルを銃で打ち出しそれを敵チームのプレーヤーにあてていけば勝ち、逆に被弾すれば自分は退場、といったもの。ルールはシンプルながら実際やってみると色々と難しい。何が難しいのかって、1) 狙いが定まらない、2) 空圧で銃から打ち出されるシェルが高速（被弾すると地味に痛い、素手にあたって血が出ました）、3) 戦略が全く思いつかない。
本格的なトーナメントもあるらしいですし、カタカナで「ペイントボール」と検索してみたところ日本でも幅広く行われているスポーツとなってるようです。Paint Ball を一回やってみて、戦場での兵士がいかに想像を絶する状況下で死と隣り合わせになっているかが、ほん～の少しだけ分かる気がしました。あとは、戦略論の大切さとか。

と、そんな感じでチームアウティングを終え、その後はまた会社に戻りコードを書いてたのですが、Paint Ball で同僚と銃撃戦を交えた非日常感からか、ふと人間関係についてオフィスで考えていました。

上司とか先輩とか
今のチームメンバーにはもちろんそれぞれ肩書きがあるのですが、それは各々の仕事の中身を明確にし効率よく処理するだけのただの窓口にすぎない。ディスカッションが始まってしまえば、上司、先輩など関係なく、自分を出していける。相手もそれを全身で受け止めてくれる。精神的に負担になるような階層はどこにも存在していない。今日の Paint Ball だって、自分のボスや社歴 20 年の先輩にたいしてガチで銃口を向けてぶっ放してるんだから、礼儀はどこへ行ったんだって話です。

そして上記を皮切りにアメリカに5年以上滞在してきて、他にも色々な境界線がなくなってきてたことを職場からの帰途でうっすらと感じていました。

なにじんとか
周りにいる人の国籍がバラバラで、自分の接している方がどこの国の人なのか、そういうことを問いかける脳の部分が麻痺してしまっている。のび太のように「人の幸せを願い、人の不幸を悲しむことのできる人」であれば、なにじんだっていいじゃない。

言葉とか
そういう多国籍の人とは英語で話すため、最近は自分の中で日本語と英語の区別がもうなくなっている。ふたつひっくるめて「自分の意思を伝える言葉」です。

学術分野とか
最近は世界史の本とかを読んだりするけど、芸術や宗教、政治や経済、戦争論と色々な分野の土台になっていることにいまさらながら痛感する。学生だったころは文系科目だからとかいう理由で避けて通ってきたことにただただ後悔ばかり。学びに境界線なんてないことにこの年になって気づく。

様々な境界線を感じなくなっていく一方で、日本語には人に劣等感や不幸を与える線引きワードが、まだまだ日常で普通に交わされているなぁとも常々思うわけで。

　高学歴・低学歴、現役・浪人、文系・理系、正社員・非正社員、新卒・既卒

高学歴・低学歴
真にクレジットを受けるべきは確固たる教育理念を掲げ機関を設立した創設者であって、その創設者らのビジョンに高いも低いもない。その理想の元、レールの上を通っただけの人間がそれに妙な付加価値をつけて何かを高いとか低いとか言っていることがおかしい。先生や学友らを含めた愛校心から、卒業した学校を載せてるのであればそれは納得がいくが、大の大人が「学歴」とやらのためだけに卒業校を列挙してるとしたら、それは大学生がこの幼稚園卒業しましたって言ってるのと変わらないレベルかと。
カリキュラムだけならもうオンラインで好きに学べる時代だし、わざわざ学校に通うなら、尊敬する先生がいるもしくはクレイジーなやつらがたくさんいるっていう理由で選ぶべきでは。

現役・浪人
長い人生のたかだか一年くらい、気にしなくていいのではないでしょうか。

文系・理系
個人的には、自分は文系（理系）のこの科目には興味がないから理系（文系）にいるんだ、っていう否定的な枠組みに聞こえることが多いです。経済学にだって数学は必要だし、工学にだって人類史は必要。

正社員・非正社員
会社に貢献してる人の労働そのものに差があるんだろうか。

新卒・既卒
別にその人をあなた色に染め上げるわけじゃないんだし、卒業から時間が空いてたって何の問題が？ほかの人が持ち合わせていない特殊なスキルが”既卒”の人にあるかもしれない。

自分が生まれた、世界で一番好きな国。だからこそ、本質的には何の違いもない上記のような言葉が飛び交って、誰かの気持ちを暗くさせていると思うと無性に悲しくなるわけです。

C++コード書きの3つのゴール

先月同様の手抜き更新です。チームで C++ Seasoning というタイトルのトークを見たので、他にも興味ある人がいるかなと思いつつトークのビデオをここに貼っておきます。

 
トークの中で Sean 氏は、3つのゴールとは、むき出しのループはやめよう、むき出しの同期プリミティブはやめよう、むき出しのポインタはやめよう、であると説明しています。詳しくはトークを見てもらって、以下は僕がビデオを見た（すっごく適当な）雑感を。

最初のゴールのむき出しのループはやめようの Chrome OS のサンプルコードのループの連続、これ結構ヒドいですね（笑）Google は candidate をスクリーニングしてるはずでは？？
でもインタビュー質問を突破したとしても、次から次へと舞い込む日々の作業の量ゆえ、こういうコードを書いてしまう気持ちも分からなくはないです。が、極力避けるべきことだと思います。

最後のゴールのむき出しのポインタで shared_ptr とグローバル変数は同じメモリ領域を複数人で叩いてるんだから、つまるところ一緒じゃん言われてギクっしました。あとポインタ経由の継承を避けてトーク内では type erasure を使ってる？のかな。でも自分は現場ではそれはやってないですね。どうしても安易にポインタ経由の継承に走っているので、このトークの観点からすると自分のあまりほめられたことはやってないんだなと。 

また別のトークを見たらここでまた適当に紹介します。

引越し

と言っても職場のオフィスの、という意味です。今年の上半期にキャンパスに新しいビルディング４ができ、それに伴いオフィスの場所を移すグループがありました。自分もその一派だったのですが、僕の場合は新しいビルに移ることはなく、これまでのフロアでしかも窓なしの部屋に移動になりました。入社して３年、初めての窓なし生活で軽くショックです、太陽が時間の経過を教えてくれません。

個室なので集中はできます

Revo さん節にまたもや魅了され

今年の4月は友人の結婚式で日本に一時帰っていました。帰国時に僕が必ずすることは書店めぐり。大手の書店からデパート内の書店まで色々な本屋を一日かけて満喫します。今回、どの書店の漫画コーナーでも目に付いたのが「進撃の巨人」。理科室に置いてある人体モデルのような巨人が表紙にデカデカと載っていたのはインパクトがあり、数巻ほど読んでみたらたちまちハマってしまった。帯にはテレビアニメも放映中とあり、幸い二週間ほど日本に滞在していたので運よく地上波で見ることができた。放映されたのは原作ですでに読んだ箇所だったのでストーリーを問題なく追うことができ、声、美術、構成とどれをとっても文句なしに素晴らしかった。そして極めつけがOP。放映中にOPの作曲者の名前を見てそれが Revo さんだと分かったときは本当に jaw dropping でした。ブレイブリーデフォルトであれだけ素晴らしい曲が書けて、今度はこんなにも中毒性の高いアニメーションのOPも作曲できてしまうのかと。

そして先日公開された新しいOPも聞けば聞くほど深みにはまっていく Revo さん節満載の珠玉のトラック。その曲に合わせて目で追いきれないほど瞬時に切り替わる映像もまさに一級品。

冒頭のファンファーレはブレイブリーデフォルトでも流れそうな感じです

ブレイブリーデフォルトでもそうでしたが、楽曲対象となる作品に対する Revo さんの理解が非常に深いことと、作られた楽曲は何回聞いても全く飽きが来ることなくむしろ中毒性が増していくこと、この二点は本当に特筆すべきことです。特に後者は驚異的で、4月に帰国したときのNY⇒成田の便ではフライト時間の三分の一はブレイブリーデフォルトのサントラを聞いていたと思います。どの曲も素晴らしいのはもはや given なのですが、そのうえで Revo さんの感性は天才だと感じた一曲はラストダンジョンで流れる「闇のオーロラ」

曲の感情を全体的に抑えているように聞こえるのにこれだけ妖しくも美しい雰囲気と禍々しさを同居させられるのは、まさに並々ならぬ才能と懐の深さがなせる業。感情むき出しの曲ではメロディもすぐ拾えるし、大きな音をジャカジャカ鳴らせばそれなりに壮大に聞こえる。感情を抑えてここまで曲のテーマの深さを表現できるのは並大抵のことではないと僕は考えます。そして雰囲気こそ違えど感情を抑えつつそのテーマを見事に表現した天才的な感性をうかがえるもうひとつの曲として、すぎやま先生の「神秘なる塔」を挙げます。

音楽評論家の故黒田恭一さんもすぎやま先生の引き出しの多さについてよく言及しておられました

話が逸れましたが、Revo さんの素晴らしいOP曲と美麗な背景美術、多くの伏線を含んだ目が離せない今後のストーリー展開と三拍子そろった誘惑に抗えず進撃の巨人の Blu-ray を全巻予約してしまいました。Blu-ray だと日本とアメリカのリージョンコードが同じなので助かります。

全体像を把握する目を、己の論理に自信を

職場では年に一度のパフォーマンスレビューがあります。誰にレビューをしてもらうかは自分で指定することができ、僕の場合はその一年で一定以上のインタラクションがあった人に頼むようにしています。2012年を終えて同僚の目から見た僕の仕事における改善点は、

• バグ修正のときはエラーとしてあがってきたユースケース以外に、それに関連したユースケースにもバグがないかどうかチェック

• ロジックを自分の口で説明するときは、自信を持つ

不思議なものでこの二つ、僕が自分に向けて書いたセルフレビューでも実は全く同様のことを挙げていました。すなわち、自分から見た己の改善点と他人から見た僕の改善点は一致しているということ。己の視点と他者の視点が一致することは分からないこともなく、というのも「ここをこうするともっとよくなる」とか「この誤りはもう二度と起こさないようにしよう」とかチーム内では普段から直接相手に言うようにしているので、レビューが書かれる頃には自分は何を改善すればいいのかおのずと分かっているという寸法です。レビューで指摘されている己の改善点を読む際にも少なくとも一度は直接言われていることなのでキモを冷やさずに済むと。

上記の二点は言うは易しのようなところもありますが、一点目は2013年になってからは改善できていると自分でも感じます。特定のエリアに限ってユースケースとコードベースのマッピングが頭の中で出来てきたおかげです。逆に初見のコードベースでは、まだまだというところか。しかしそのような状況でもやれる人はやるんですよ。そういう人は、1) 過去の経験からくる類推がわりと効くのと、2) その未知のエリアに明るい人物を探す能力に長けているのと、3) 疑問解決のためにその人物に投げかける質問の内容が実にポイントを得ている。僕はまだ三つのうちどれも未完成で、未知のエリアではしばらく試行錯誤を繰り返す日々が続く。

二点目もまだまだ改善が必要なわけで。自分のロジックを自信を持って説明している人は論拠となっている土台にブラックボックスがほとんど存在していない。もしくはそのブラックボックスを使う上での前提をよく把握している。すなわちその前提から外れた状況下でブラックボックスを使用して己の論理を組み立てていくと、導き出された結果が undefined behavior になることを良く理解している。僕の改善すべき箇所は、まだ年配のエンジニアの説明を鵜呑みにしている部分が多いということ。論拠となる部分で「Aさんからこういう説明を受けたので自分としてはこういう理解のもとに話を進めます」では、説得力に欠けるんですわ。しかし大規模ソフトウェアでは、assumption の上に assumption が重なっていくのでどこかで線引きをしないと、ブラックボックスの中を覗いているだけで一週間が終わってしまう。時間との戦いなのでどこかで探求を打ち切り前進しないといけないのだけれど、そのあきらめ方を工夫しないと説得力のある説明はできないというのが現状。これも日々試行錯誤しないといけないよな。

にしてもレビューで、自分の改善点を指摘するために具体例として挙げる過去のエピソードをどうしてこんなに克明に覚えているのっていうくらい、年配のエンジニアは僕との作業を良く覚えてる。こういうところでもシニアの人はさすがだと思わされるわけです。

読み物まとめ: 4月-5月

• ちはやふる20巻  

全巻通して読んでいますが、各巻読み終えるたびに背筋が伸びる思いです。登場人物成長モノはジャンプ黄金期から数え切れないほど読んできてますが、これほど日常レベルで劇中の名言を自分に還元できる作品はちはやふるが初めてですよ。原作者の末次先生は過去に大変なこともあったようですが、そのときの経験が活きて、この素敵な作品を生み出す原動力になっているんだなと、各巻の表紙の折り返し原作者コメントを読んでそう思いました。アマゾンJPの海外発送料なんて全然苦じゃないわ、ってレベルで毎巻楽しみにしています。

21巻が待ち遠しい

• Ruby Under a Microsope

ハードカバーは今年の11月に出るようですが、僕は20$の電子書籍版を購入して読みました。これはホントいい買い物をした！人にわかりやすく説明する手本といっていい。青木さんの RHG や巷の Yarv ソースコードリーディングブログ に比べてしまうと処理系内部のコードの掘り下げは比較的浅いが、そのぶん具体的なユースケースが Ruby 1.9 にどのように口で噛み砕かれて、食道を通って、胃で消化されるのかが順を追って詳細な図とともに説明されている。そして、実際はもっと複雑なんだけれど今は伝えるべき重要な本質があるのでその複雑な部分の説明は省きます、とその削ぎ落とし具合も絶妙。Scott Meyers の C++11 の Universal Reference  のビデオで便宜上嘘を鵜呑みにしておくことは時として真実を知ろうとするよりも役に立つことがあると言っていましたが、まさにソレ。煩雑な部分は後回し、今は押さえるべき重要なポイントがあるんだ、筆者のそんなスタイルが功を奏しています。

熟知しているのに説明ができない、そういう場面では本当にがっかりします。理解ができているのに、人に説明するのが下手もしくは出来ないのは最大の罪ですよ（お前どの口が言ってんの、という反論は受け付けます）。だったら私には分からないと言ってくれたほうがこっちはよっぽどすっきりする。そうならぬよう、仕事で己の作業分を別の人物に噛み砕いて説明する際は、図をいかに有効活用するかという意味でこの本が非常にためになる。言語処理系という同じ分野なので、処理系内部で起こっていることを図にするときはどう描くと分かりやすいのか、という意味でも参考になりますしね。

うちのチームでもこれくらい分かりやすい図を描く時間があったらいいなと思うんですが、Ruby Under a Microsope の著者はマッキンゼーで仕事をフレキシブルにしてもらいつつこれを書いたと謝辞にあった。自分も頼んだらもしかしてやらしてくれるかなぁとか。無理かぁぁ・・・！