何かを書き留める何か

数学や読んだ本について書く何かです。最近は社会人として生き残りの術を学ぶ日々です。

職場の思い出話 第二話

youtu.be

職場の思い出話 第一話は 職場の思い出話 - 何かを書き留める何か にある。

今月末で退職した。タイミングの関係で長めの夏休みができたので適当に有効活用していきたい。

『Effective Debugging』の査読を担当しました

一年越しの夢がかなう

2017年6月24日にオライリージャパンから『Effective Debugging』の邦訳が発売される。

www.oreilly.co.jp

この度、邦訳の査読者として参加させていただいた。 オライリーの方から話があったのは2017年1月ごろ、査読を開始したのが3月中旬ごろである。

筆者のDiomidis Spinellisさんは『Code Reading』や『Code Quality』で有名なギリシャの計算機科学者である。 経歴を見る限り、GoogleのSREエンジニアとして1年間働くなど実務経験もあるすごい人である。

book.mynavi.jp book.mynavi.jp

私は原著を2016年6月頃に紀伊國屋経由で入手している。

『Effective Debugging』も『Effective Python』のように読み進めようとしていた。

xaro.hatenablog.jp

最初の4項目で断念していた。 どこかの出版社から邦訳が出ないかと思っていた。 英語ができない、デバッグに関するドメイン知識が足りないという要因もあるが、筆者が英語ネイティブではないという要因も少なからずあった。 査読をしつつ、楽しみながら読み続けた。

さて、内容としては効果的にデバッグを行う方法が書いてあるのだが、この手の技術では珍しく心理学の観点からデバッグの心構えを説いた項目がある。 「項目9:デバッグを成功させるために心の準備をする」がそれである。 本の帯にも採用されて、

最初に、問題を特定して解決できると固く信じることが必要だ。

から始まり、果ては睡眠時間の大切さまで話が進む。

こう書くと精神論めいたテクニックばかり書いてあるかのような印象を受けるが、1章、2章でデバッグ戦略の全体像、心構えを説明し、3章以降で各場面・ツールに着目してデバッグの手法を解説している。 特に面白いのはハードウェアに関するデバッグでデバイスをアルミホイルで包んで劣悪な通信環境を作ってバグの再現手順を確立したエピソード(「項目16:特別な監視およびテスト装置を使う」)である。

デバッグそのものは言語によらない技法であるが、中で登場するのはC/C++, Java, Python, Lua、各種Unix系のツール、そしてシェルスクリプトである。 使われている言語をよく知らなくても十分読むことができると思う。

ちょうど『Effective Debugging』の書影が公開された時期に業務中に作成したAPI群のデバッグに迫られていた。 そこで役に立ったのが5章の「プログラミング技法」、「項目3:前条件と後条件が満たされていることを確認する」、そして「項目9:デバッグを成功させるために心の準備をする」である。 様々な要因が重なってとてもつらい状況下でもデバッグであったが、『Effective Debugging』を読んで得たものを心の支えにして乗り切ることができた。 アルゴリズムデバッグのようにすぐには役には立たず、じわじわと役に立つと目論見を立てていたが、すぐに効果が出るとは思っていなかった。

原著を所有している方はお気づきであると思うが、邦訳版と表紙のデザインが異なる。 邦訳版は『Effective Python』のテイストに寄せている。 偶然ではあるが、表紙を決めるやり取りを垣間見ることができてとても面白かった。

読んでためになる本である。ぜひ職場、研究室、ご家庭、座右にと思う。

『Eric Sink on the Business of Software --革新的ソフトウェア企業の作り方』を読んだ

『Eric Sink on the Business of Software –革新的ソフトウェア企業の作り方』を読んだ。 きっかけはジュンク堂池袋店で行われていた「ラムダノート取扱い記念フェア「ラムダノートはじめました」」で並んでいたのが目に留まったからである。 ジャケ買いならぬPOP買いである。

www.shoeisha.co.jp

読んだ、と言っても一通り目を通したに過ぎない。 そして感じたのは今の段階でこの本のすべてを飲み込むのはきついぞということである。 一回読んで満足する、役に立つ本ではなく、折を見て、見返して少しずつ咀嚼していきたい。

一見消化不良を起こしているような記述になってしまったが、その中でも心に残ったものとして、第13章「キャリア計算」がある。 その中で、開発者のキャリアにおける基本的な方程式として、以下の式を紹介している。

{C = G + LT}

{C}は実力、{G}は素質、{T}は時間、そして{L}は学習である。 3つの変数の中で自分でコントロールできるのは{L}の学習のみであり、実力{C}に着目するのではなく、実力の時間による一次導関数{\frac{dC}{dT}=L}に集中するべきであると説く。 つまり、学び続けることが重要である、と。

私は学び続けることができているだろうか。 最近、技術書を読む頻度が下がっていないか? そろそろPython以外の言語を学ぶべきではないか? 数学を継続して学ぶべきではないか? 流行りの服は嫌いだと機械学習から遠ざかっていないか?

また折を見て読み返したい。