Chapter 5. Bend, or Break【The Pragmatic Programmer】

The Pragmatic Programmer の Chapter 5. Bend, or Break を読んだ。

内容は次の通り。

  • 26 Decoupling and the Law of Demeter
  • 27 Metaprogramming
  • 28 Temporal Coupling
  • 29 It’s Just a View
  • 30 Blackboards

一通り読んだけど、あまり印象に残る話題がなかった。たぶん、どこかで一度は目にしたような話が多かったからだろう。30 の Blackboards は、「確かに、そうだね」って感じだったけど、イマイチ具体的な話が伝わってこず、消化しきれない感じ。


6割くらい読んできた感じとしては、技術的な話のところは大して面白くなく、精神論みたいな話の方が楽しい。

ただ、精神論を読みながら、「うんうん、ほんとそうだよねー」って自己完結しても大して身にならないので、気をつけないとね。

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

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

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

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

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

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

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

でも、多様な環境で動作して、様々なデータに対応した『プログラム製品』にするには『プログラム』を作る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)

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

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

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

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

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

基礎からしっかり学ぶC++の教科書 C++14対応 (マイクロソフト関連書)

基礎からしっかり学ぶC++の教科書 C++14対応 (マイクロソフト関連書)

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

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

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

macOS

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

Windows だけでなく、macOSLinux でも本書の内容は試せます。

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

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

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

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

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

C++Java

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

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

(『はじめに』から)

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

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

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

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

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

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

またいつか

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

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

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

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

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

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

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

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

rebuild.fm

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

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

hjm333.hatenablog.com

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

calnewport.com