Chapter 4. Pragmatic Paranoia【The Pragmatic Programmer】

Pragmatic Programmer の Chapter 4. Pragmatic Paranoia を読んだ。

内容は次の通り。

• 21 Design by Contract
• 22 Dead Programs Tell No Lies
• 23 Assertive Programming
• 24 When to Use Exceptions
• 25 How to Balance Resources

契約によるプログラミングとか、Assertion 使いましょうとか、全体的に時代を感じる章だった。まずはクラッシュさせよう！とか聞くと、うーん…、って感じになる。確かに理解はできるが…。

そういえば、最近はあまり assert とか使ってないなぁと思った。昔は結構単体テストとか assert とか書きたがるタイプだったけど。

単に今の仕事ではそこらへんをきちんとすることへの優先度が低いと感じているだけかな。自分には時間も能力も限られたものしかなくて、何が一番効果的かと考えた時、assert や単体テストを拡充することが今の業務にとって有効だと感じていない。

やりたいこと/やった方がいいことがあったとしたら、きっと、そのうち 80% のことは諦めなきゃいけなくて、決意を持ってそのうちの 20% を選ぶことが仕事なんだと思う。そして、うまく選べればその20%で80%くらいの結果は出せるはず。

最近は人生もそんな感じかな、と思うようになった。

話が完全に本と関係なくなってしまったな。。。

Chapter3. The Basic Tools【The Pragmatic Programmer】

Pragmatic Programmer の Chapter 3. The Basic Tools を読んだ。

内容は次の通り。

• 14 The Power of Plain Text
• 15 Shell Games
• 16 Power Editing
• 17 Source Code Control
• 18 Debugging
• 19 Text Manipulation
• 20 Code Generators

この章はツールの紹介とかが多くて、やや話が古い印象を受けた。現代においてソースコード管理システムを使わない開発はありえないだろう。

一方、デバッグの心構えみたいなのは古くなってないと感じた。

Tip 27 Don't Assume It - Prove It

という話はまさにその通り。

他にもデバッグの心構えはいくつか書かれていたけど、本当にこの一言に集約されると思いました。

おわり。

Chapter2. A Pragmatic Approach【The Pragmatic Programmer】

Pragmatic Programmer の Chapter 2. A Pragmatic Approach を読んだ。

内容は次の通り。

• 7 The Evils of Duplication
• 8 Orthogonality
• 9 Reversibility
• 10 Tracer Bullets
• 11 Prototypes and Post-it Notes
• 12 Domain Languages
• 13 Estimating

曳光弾開発とプロトタイプ開発の違いについての話は興味深かった。

Tracer Bullets と Prototypes

モジュールごとではなく、システムを貫通するように機能を中心に作ることを曳光弾開発という。この言葉は前から知っていた。プロトタイプ開発と曳光弾開発と何が違うのか？

プロトタイプ開発はあくまでプロトタイプ。製品リリースに向けてコード自体を１から書き直す前提。プロトタイプのコードをベースにして開発を進めてはいけない。

一方、曳光弾開発は製品レベルのコードで一部の機能を実装する。実装したコードは作り直すことがなくほぼそのまま製品として利用できる。この点が大きな違い。

プログラムとプログラム製品

『人月の神話』に『プログラム』と『プログラム製品』の違い、という話がある。

『プログラム』を作るのにはそれほどコストはかからない。それは単一の環境で、簡単なデータの組み合わせに関して動作すれば良いものだから。エースプログラマが徹夜して数日で『プログラム』を作り上げた、なんて話はよく聞くだろう。

でも、多様な環境で動作して、様々なデータに対応した『プログラム製品』にするには『プログラム』を作る3倍のコストがかかる。というのが『人月の神話』に書かれた話。加えて『プログラム』を、コンポーネントに分離された拡張可能な『プログラムシステム』（フレームワークとか OS に該当）にするには 3 倍のコストがかかり、もし『プログラム』を『プログラムシステム製品』にするなら 9 倍のコストがかかる。

プロトタイプの危険性

プロトタイプを作るということは『プログラム』を作ることであって、決して『プログラム製品』を作っているわけではない。プロトタイプができてもリリースまでにはさらに数倍のコストがかかる。

プロトタイプをマネージャーや経営陣に見せる時は注意が必要だ、と Pragmatic Programmer には書かれている。

動くものがあると、リリースはすぐそこだと勘違いしてしまいやすい。『プログラム』を『プログラム製品』にするには3倍のコストがかかるという事実を忘れてしまう。

それを防ぐため、正しい情報を伝えるのもエンジニアの役目なのだろう。

第 218 回 TOEIC の結果

そういえばもう一ヶ月くらい前になるけど、第 218 回 TOEIC の結果が返ってきた。

Listening	Reading	Total
430	415	845

結果として前回から100点くらい伸びた。Listening も Reading も前回の TOEIC よりはきちんと理解して解けたところが多かった。理解できてない問題はきちんと分かるようになった。

「ああ、これは間違いなくこの答えだな」と「うわ、今の会話は全然聞き取れなかった…」が、ちゃんと分かるようになった。 まだまだ前者の割合が低く、後者の割合が高い。前回に引き続いて予想以上の結果がでてるなぁと思った。

やったこと

去年の TOEIC から何をやっていたかというと、ひたすらこの本をやってた。毎日30分くらいこれをやり続けた。

どんどん話すための瞬間英作文トレーニング (CD BOOK)

結果を出すためには日々の継続が大事なんだなぁと改めて感じた。特に語学はね。

先週くらいから、これに加えて iknow を始めて少し英語に費やす時間を増やすことができている。なかなか時間の取れない中で、習慣として少しでも英語に費やす時間が増やせたのはだいぶよい。あとは英会話を始めたいけど、どうやって時間を捻出するか…やはり休日の朝か…。

『基礎からしっかり学ぶ C++ の教科書』を読んで

『基礎からしっかり学ぶ C+の教科書』という本を読んだ。

基礎からしっかり学ぶC++の教科書 C++14対応

著者の方に贈っていただいたもので、こういう経験は初めてだ。 記念に読んだ感想を書いておこうと思う。

よくよく考えてみると、自分はこういうちゃんとした入門書を使ってプログラミング言語を学習した経験がほとんどない。 いつもなんとなくその言語を触れるようになって、発展的な書籍を読む、というパターンがほとんど。 だから、友達に「プログラミングができるようになりたいんだけど、オススメの教科書ある？」と聞かれるとけっこう困ってしまう。

そういうわけもあって、入門者にとってこの教科書が分かりやすいのか、という点は評価できない。 その代わり、少なくとも昔 C++ を触ったことがあるエンジニアとしてどう思ったか、という視点で少し書いてみる。

"macOS"

本の冒頭にこんな一文があった。

... Windows だけでなく、macOS やLinux でも本書の内容は試せます。

macOS の表記が正しく "macOS" になっている。 こういう記述があると「この本は信頼できるな〜」と安心して読み進められる。 それに最新の情報が書かれていることも期待できる。

macOS の話はあくまで象徴的な話で、肝心の C++ についてもきちんと書かれてる。 C++14 に対応したコードが掲載されているのはとても助かる。 仕様、コンパイラごとの実装の違いについてもケアされてる。 入門者向けだからといって、妥協された知識を提供されている感じはしない。

細かなことも書かれている一方、きちんと現場で使える話題も載ってる。 ポインタを使ってリンクリストを実装しましょう、なんて現場で使われないような課題はない（最近だと面接で使われること多いので有用な側面もあるけど）。 特にページが割かれているのはライブラリの使い方（コンテナ、文字列、入出力、スレッド）やメモリ管理（スマートポインタ、コピー、参照、ムーブ）など実践的なところ。 バージョン管理やライセンスについて触れられているのもポイントが高い。最近の教科書では普通なのかもしれないけど。

一方、「プログラミングの経験がそれほどなく、C++ も初めて」という読者を想定した場合に説明が細かすぎるかも、と感じるところがある。 自分のようにコンピュータの一般的な知識があり、数年の開発経験に加えて C++ もある程度分かる、という人間だからこそ「ふむふむ」と読めるのでは？と思う箇所もところどころ。

何も知らない学生がこの教科書を与えられたとしてすべてを理解できるのだろうかと、少し不安を覚える。 まあ、すべてを理解しなくてもいいのかもしれないし、学生は何より若いからどんどん吸収していくだろうけど。

C++ と Java

でも一つ書いておきたいのは、この不安の原因はこの教科書では無く、C++ という言語の大きさと複雑性によるところが多いのかもしれない、というところ。 読めば読むほど複雑で大きく冗長な言語だと思えてくる。

C++ の大きさは、後方互換性は守りながら、性能面での妥協をせずに言語の抽象度を上げてきた結果です。 後方互換性はなくてもいい、プログラムの性能は低くてもいい、言語の抽象度は低くてもいい、このいずれかに該当しない方とっては、C++は学ぶに値するすばらしい言語だと思います。

（『はじめに』から）

筆者がこのように述べるように、C++ はとても興味深く、後方互換性があり、（正しく書けば）性能の高い、素晴らしい言語だ。

でも、いつのまにか自分にとっては複雑で重たい言語になってしまった。

以前いた会社でアンケートをしたとき、好きな言語の１位が C++ だった。嫌いな言語の１位は Java だった。 詳細は覚えていないけれど、当時、自分は C++ を書いていたし、きっと C++ に投票したのだろう。

今の会社では、C++ をかけるプログラマは一部だけで、Java は全員書くことができる。 そもそも今の会社では C++ を書く機会がない。自分もいつの間にか Java ばかり書く日々だ。

以前は自分でメモリ管理ができる C++ が好きだった。今はもうそこまでやりたくない。 コピー、参照、ムーブを意識し、ローカルストアとフリーストアを使いこなすプログラミングが自分にできると思えない。

いつの間にか歳をとったんだろう。信頼できる他人に仕事を任せられるのならそうしたい。 GC と JVM がある程度のメモリ管理と効率性を提供してくれる Java の居心地は、そこを積極的に離れるほど悪いものじゃない。

またいつか

それでも、この業界にいれば C++ をやろう（or やらなければならない）という時がくるかもしれない。

それがいつになるか分からないけど、その時、きっとまたこの本を手に取ると思う。C++2x なんてものが出ていればきっと改訂されたこの本が出ていると思うし。

今、もしあなたがそういう状況なら、『基礎から学ぶ C++ の教科書』はとてもおすすめですよ。

2017/08 追記

電子書籍版がないのが唯一の欠点ですね、と書こうと思ってやめてしまったんだけど、どうやら Kindle 版も出たようです。

『ディープワーク』を読んで

ディープワークを読んだ（邦訳のタイトルは『大事なことに集中する』）。

大事なことに集中する―――気が散るものだらけの世界で生産性を最大化する科学的方法

内容は rebuild 175 を聞くと分かるのでそちらで…（あとはぐぐるとか…）

rebuild.fm

この本に影響されて Twitter やFacebook を見る回数をかなり減らした。iPhone にはアプリを入れず、ブラウザで見たときは毎回ログアウト。Facebook は特に見る回数が減ったので良い感じだ。

大事なことに集中する、価値があるものに注力する、というのは『ハイアウトプットマネジメント』のテコ作用の話と同じ話だなぁと感じた（最近、復刊されたので読み直している）。

hjm333.hatenablog.com

ちょっと邦訳の質が悪かったので読める人は原著を読んでもいいかもしれない…。あと、著者のブログもあるので気になる方はチェックしてみては。

calnewport.com

『ファスト＆スロー』を読んで

『ファスト＆スロー』を読んだ。

ファスト＆スロー　（上）

ファスト＆スロー　（下）

上下巻に別れた大作でかなり読み応えがあった。

いろいろなところで、同じ内容が重複して書かれていて冗長に感じたが、『読みたい箇所だけ読めるように』という配慮からくるものなのだろう。

内容が多岐にわたり、かつ、示唆に富んでいたので本当は書きたいことはいろいろある。 けど、全部書くとかなり長くなりそうだ。最も印象的な『経験する自己』と『記憶する自己』についてだけ忘れないように書いておく。

喉元過ぎれば暑さ忘れる

ファスト＆スローでは人間の性質を３つの側面から論じている。

• 速くて直感型の『システム１』と、遅くて熟考型の『システム２』
• 完全に合理的な存在『エコン』と、合理的ではない存在『ヒューマン』
• 日々の出来事を経験する『経験する自己』と、それを記憶し思い出して評価する『記憶する自己』

３つめの『経験する自己』と『記憶する自己』について簡単に説明しよう。

経験する自己は日々の生活を経験する自己である。毎日、朝起き、仕事に行き、帰宅し、ご飯を食べ、ベッドに横になる、という日常を経験する役割を担う。 一方、記憶する自己はそれらの出来事を取捨選択して記憶する。また、後から出来事を思い出し、それを評価する役割を担う。

「喉元過ぎれば暑さ忘れる」という言葉が示すように、私たちは経験する自己を軽視し、記憶する自己を重視している。これは意図的に行われているのではなく人間に備わった性質である。そのため、この性質は根本的に変えることはできない。

その結果、長期間の緩やかな苦しみよりも、短期的な激しい苦しみを避ける傾向にある。経験する痛みの総和は後者の方が少ないにも関わらず、私たちは短期的な激しい痛みをとても嫌がる。

幸福に関しても、毎日の穏やかな少量の幸せよりも、短期的な激しい幸せを追求する。経験する幸福の総和は前者の方が多いにもかかわらず、短期的な幸福を選択しがちである。

人間の人生は一般的に長期であるため、総和を無視し、短期的な絶対量のみを追求するのは合理的ではない。この「合理的ではない」という点は本書のテーマの１つでもある。そう、人間は合理的ではないのだ。

（ちなみに、不合理という言葉はネガティブな印象が強すぎるため使わない、というのが筆者の考えである。経済的な合理性を真として、それで説明できない人間を不合理とするのはあまりに乱暴である、と筆者は主張する）

２つの自己の矛盾

確かに人間は記憶する自己を重視している。私が大学時代に所属していたサークルは練習が厳しく、理不尽な規則があることで有名だった。練習は強制参加で、自分の出場しない試合も応援として参加しなければならない。大学生活という人生で一番自由な時間を辛い経験に消費してなんの意味があるのだろう、と悩んだ。

先輩達は「卒業した時、絶対やってきてよかったと思える」と声を揃えていっていた。確かに、自分も振り返るとそう思っている節がある。最後の大会でサークルが優勝した時の嬉しさは格別だったし、今でもその光景は覚えている。

この本を読んでいて、あれがまさに記憶する自己の重視なんだ、と気づいた。

一方、年収750万円以上では生活の幸福度が上昇しない、という研究結果がある。これは直感に反するように思える。年収７５０万円の人と年収１億円の人が同じ幸福度なのか、と。

この研究での幸福とは『経験する自己』の幸福だ。大富豪も中流家庭も日々の生活はそれほど変わらない。朝起き、ご飯を食べ、夜寝る。これらの点は年収が750万円より上だとしてもそこまで大きな変化はない。

この研究結果を引用し、年収の増加による幸福を否定するような言説を目にする。しかし、この２つの自己にまで言及されていることは少ない。先に書いたようにこれはあくまで『経験する自己』の幸福であり、『記憶する自己』の幸福は明確に異なる。

『記憶する自己』は年収の上昇に伴ってより幸福になる、という研究結果が出ている。年収が10億円あればリゾートで素晴らしい体験を送ることができる。世界的な富豪であれば宇宙にだって行けるだろう。よりよい体験ができ、それらの思い出にふける時、記憶する自己はより幸福になる。

年収の増加によるこのような幸福の否定は、『記憶する自己』の否定でもある。

幸福になるには

人間の性質上、『記憶する自己』を過大評価する傾向は取り消せない。やはり『記憶する自己』は重要であり、年収７５０万円よりも年収10億円の方が幸福であろう。

しかし、『経験する自己』を過小評価しすぎると、日々のクオリティオブライフを下げることになる。私たちは『記憶する自己』を過大評価してしまうのだから、『経験する自己』をもう少しだけ大事にしてもよいのかもしれない。