2007-08-26

最近読んだ本

前回は 5 月.

C/C++ セキュアコーディング

中味はバッファオーバーランとその亜種で半分くらい, 残りは整数演算と競合条件の話. バッファオーバーランは C 標準のダメ API を使わなければだいたい防げるからいいとして, 整数演算と競合条件は怖い. 特に競合条件は OS の資源を使う各所で起こりそうだから, 防ぎ切るのは大変そう...

そのほか C/C++ コードに対するセキュリティ強化用のツールやライブラリが紹介されている.

デスマーチ

一冊くらいデマルコを読んでおこうと手にとった. ら, デマルコじゃなくてヨードンだった...



ヨードンは "プロジェクトのパラメータが正常値を50%以上超過したもの" 
とデスマーチを定義している. 
デスマーチというと非人道的なものを連想するけれど, そうとは限らない. 
たとえば一山あてようと熱心に働いている(失敗と隣り合わせの)ベンチャーも
デスマーチだにあたる でも当人に不満はないだろう. 
本の内容は, デスマーチの実体はどういうものかの説明が半分, 
どうやってその中を生き延びるかという話がもう半分. 


その中で労働時間と生産性の関係について記述があり, 
ヨードンはもっともアウトプットが多いのは週に 60-80 時間の労働だと主張している. 
たしかに身に覚えがある. XP が主張する週 40 時間労働でのアウトプットを私は疑問に思っていた. 
週 80 時間のハードワークが嫌なのは, 
生産性が下がるからではなくて人間的な暮らしがしたいからだ. 
生産性を理由にした短時間労働の主張はいまいち実感とあわずうさんくさい. 
その点でこの主張は信用できる. ヨードンは 80 時間働けと主張しているわけではない. 
生産性と人生は別の問題だという当たり前だが見落されがちな前提がある. 


Distributed Systems: Principles and Paradigms (2nd Edition)




ネットワークのミドルウェア屋さん勤務ということで読む. 
勉強にはなったがしんどかった. 
理論の話(様々な一貫性の定義, 失敗の種類など) と
アーキテクチャやアプリケーションの話(分散 FS がどうとか) の二本立て. 
序盤で概要やアーキテクチャの話をしてそのあとに理論の話, 
理論の上でアプリケーションの話と進む. 


アプリケーションやアーキテクチャの話は良くかけているし, 
知らないことも多く勉強になった. 
一方で理論やアルゴリズムの説明はわかりづらい. 
もともと複雑な問題な上に応用がわかりにくく, 気付くと寝ている読書の日々が続いた. 


アーキテクチャやアプリケーションの話は適当なサーベイを読んだり
実装のマニュアルを読んだりした方がよくわかる面がある. 
でも理論やアルゴリズムを実装から読み解くのは難しい. 
教科書にはそこをフォローして欲しいんだけどなあ... 


分散システムの理論的な核にあるのは
一貫性, 同期, 耐障害性のモデル化とアルゴリズムだということはわかったので, 
また気合が溜まったらアルゴリズムに焦点を合わせた教科書を読むことにしよう. 
だいぶ先になりそうだけど. あと参考文献は充実しているので, 
面白そうなのを端から読んでいくのは良いかもしれない. 
この二版が出たのは 2006 年なので, それなりに新しい話題も入っている. GFS とか. 


ところでこの本の Amazon の星 は 3 つ. 
レビューも全体に辛辣. 
以前 牛の本 のレビューが低いのを見て以来, 
教科書に対するスコアは信用せずレビュー数だけを見るようになっていた. 
今回もレビューの評価が低いのは知っていたれど, 
どうせ根性なしのやつらが不当に低い星をつけているんだろうと甘くみていた. 
ところが自分も根性なしだったという ... レビューを活かすのは難しい. 
洋書は読むのが大変だから, ハズレはひきたくないんだよなあ. 
分散システムの本は軒並み星が少くて困ります.  


デバッガの理論と実装




面白かった. 著者はまず OS や CPU に用意されたデバッグ支援機能を概観し, 
その上でデバッガの仕組みを順番に組み立てていく. 


OS 提供のデバッグ機能を見るとなんとなくもうデバッガくらい作れる気になるが, 
読みすすめるほど話が単純でないことを思いしる. 
各種ステップ実行を行うべくいかにコードを書き換え, 書き戻すか. 
(リリースビルドのライブラリから呼び戻される関数はどうトラップするの?)
限られた資源の上で競合がおきないデータ構造をどう組み立てるか. 
(式を評価するために関数を呼んじゃうけど, そのなかにブレークポイントがあったら?) 
最適化されたコードからいかに文脈を引き出すか. 


いやー大変だわ, デバッガ. いつも遅くて不便で腹をたてることが多いけれど, 
動いているだけで感謝しないといけないのかも知れない. 


ふつうの Haskell プログラミング




なんとなく読んだ. よく書けていて, サクサク読めた. 
Haskell は周辺の話題が硬派すぎていまいち近付きがたかったけれど, 
さわってみるとけっこう良いなあ. 文法もミタメとは裏腹に案外書きやすいし, 
emacs の mode はよくできているし, 
コンパイルエラーのメッセージも C++ よりは親切. 
scheme, SML とさわった中では Haskell がいちばん馴染みやすいかもしらん. 
Monad はよくわからないけれど, わからなくても当面は困らなそうだしね. 


でもいまいち使いみちがなく読後の学習はすすまず. 
"Real World Haskell" がでたら
読んでみようかな. 


ソフトウェア見積り


マコネルなので読んだ. いろいろ正しい主張をしている. 
読んだのは二ヶ月くらい前だけれど, 全然活かしてない... 
という話を友達にしたら, 
"見積は普段からやってないとクリティカルな場面で使えないよ" と諭された. 
わかってる. わかってるけど ... これまで何度もひどい目に遭っているのに, 
我ながらキリギリス体質. 泣ける. 


神は妄想である




ドーキンスがひたすら神と宗教を糾弾する本. 
日本はそれほど宗教(一神教)の影響は強くないし私自身も無宗教だから, 
さほどページを割くまでもなく神様がいないだろうという主張に異論はない. 
それにこの本を読んでも既に信仰をもっている人の気持ちは揺るがないだろうなとは思う. 
(ぐぐってみるとわかる.) 
ドーキンスも宗教を信じることができず苦しんでいる人を対象読者としている. 


それでも読んでいて面白かったのは, 神がいるかどうかはわからない 
"不可知論" の立場の内訳を細かく議論しているところ. 
teapot 信仰 を例に挙げながら, 
"わからない" といってもどちらかと言えばいると思うかいないと思うか, 
本質的にわからないものなのか, 人類が進歩すれいずれわかるのか. 
そうした点も含めて立場をはっきりしろと迫り, 議論を掘り進める. 


こうした議論とは別に, なぜ人は (存在するわけでもない) 神を信じるのかも議論する. 
個人的にはこの議論の方がドーキンス的で面白かった. 
一つのアイデアは, 宗教の求める一連のプラクティスや倫理が
人間が生きていく上で有効なものだというもの. 嘘をつくなとか. 
こうしたプラクティスを動機づける上で神様を想定すると都合がよかったというわけ. 
ドーキンスは社会のメカニズムを紐解きながら, 
宗教にたよらなくても人は倫理的でいることができると主張する. 


もうひとつ, より興味深い(ドーキンスらしい)アイデアが示される. 
それは宗教をウイルスばりの感染力をもつミームとみなすものだ. 
人間の特徴を逆手にとって勢力を伸ばすミーム. 
もう少し穏当な類似の考えとして, 何か他の遺伝的特性の副作用と見ることもできる. 


<悪い方がよい>原則 では, UNIX と C を "究極のコンピュータウィルス" と呼んでいる. 
UNIX は必ずしも最善な解ではないけれど, 計算機や利用者の特性にうまくマッチしたという話だった. そして感染後も支配は続いたと. 
宗教が持つなんらかの戦略は, 感染力という点で UNIX みたいなものだったのかもしれない. 
ドーキンスはその戦略の候補として, 子供が大人の言うことに従うよう躾ることを考えている. 
この戦略は未開の社会では有効だったが, 強力すぎて悪用されがちだと主張する. 
Richard Gabriel は, 
UNIX の戦略をインターフェイスの単純さより実装の単純さを選ぶことだと考えた. 
その時からは大して時が流れていないから, これはまだ優れたアイデアであり続けている(と思う). 


ドーキンスは, 人間がどれだけ宗教のウィルスに弱いかを示す例として 
積荷信仰 を挙げている. 思わずドキリとする. 
プログラマだってカルトに弱い 
からね...


影響力の武器




人間は状況判断のリアルタイム性を実現するために色々なヒューリスティクスをつかう. 
それを逆手にとって悪さをするやつがいるから気をつけろ, という話. 
著者はヒューリスティクスの枠組みとして次のようなものを挙げている: 
"返報性" (おかえしをしたい), 
"コミットメントと一貫性" (言うことはコロコロ変えたくない), 
"社会的証明" (他の人がやっているから自分も), 
"好意" (好かれた相手を好きになる), 
"権威" (医者がいうから間違いない). 
20 年前の本なので, 紹介されている実例は素朴に感じる. 
ただヒューリスティクスを欺こうとする商業的な手口自体はなくならないだろうし, 
より洗練されているのだろうと思う. 


プログラマのまわりを見ても, 認知のヒューリスティクス/ある種の心理的傾向を
逆手にとることは日常的に行なわれていると感じる. 
古いものでは "銀の弾丸" を信じたくなる気持ち. 
新しいもの, 複雑で洗練されたものへの偏愛. 無闇なアナーキズム. 
情報産業の buzz にはこうした戦略が溢れている. 製品だけが相手ではない. 
たとえばアジャイルな開発プラクティスの中には, 
生産性向上の役には立たないけれど
プログラマ(やマネージャ)を吸い寄せる "影響力の武器" がまざっているかもしれない. 


自分の心理的傾向を自覚するのは免疫になる. 
たとえば "俺ってばスゲー感" という言い回しは
自嘲をほのめかす軽やかなワクチンなのだと思う. 


(もうすぐ 2 版がでるらしい. 初版平積み紀伊国屋のアホーー!!)


オッペンハイマー




ピューリツァー賞を受賞したオッペンハイマーの伝記にして原子力読み物. 
原題は "American Prometheus". 
内容が重くて読むのは疲れたけれど, 面白かった. 読み応えはたしか. 
前半は普通の伝記だけれど, 原爆投下後の後半は圧巻. 
政治の波に飲まれたオッペンハイマーが
物理学のメインストリームから姿を消し, 更に冷戦の風潮の中で政敵にやられるまでを描く. 
途中からオッペンハイマーが窮地に陥っていく話が続き, 辛くてなかなかページが進まなかった. 
打ちのめされた読後感がのこる. 
(このごろ割とハッピーエンドの話ばかり読んでいたせいもあるけども.)


"原子爆弾の誕生" を読み直したくなったけど絶版か...


そのほか


いちおう所属元を明かしている手前,  
会社の話を書くにも気を使わなきゃいかんかもなーと読んだのが 
ブログスフィア. 
著者の示しているラインは妥当な気がするけれど, 
考えてみるとプログラマのふだんの仕事は別に秘密ってほどのものでもないよね. 
ましてミドルウェアだし. 
コードそのもの, 顧客, 金周りの話を避ければあとは特に隠しだてすることもない気がする. 
コード書き周辺以外には話して面白いこともそんなに多くないし. 


その流れで 
会社コンプライアンス 
も読んだ. この文脈で得るものはなかったけれど, 
情報産業がなぜコンプライアンスで儲けようとしているのかはわかった. 
色々文書化して蓄積しろと法律で決まったのか. 納得. 


たまには自己啓発本を読むかと 
リバレッジ・シンキング 
を読む. 
でも自己啓発な気分じゃなかったことに気付く. 
人生そのものをプロジェクトっぽく目的指向で
運用するというメンタリティに共感できない. 私生活くらいグダグダさせてほしい. 
読書ノートはいいかもなーと思ってつけてみたけれど, 
ノートを書くのに本を読むのと同じくらい時間がかかってしまう. 
速くノートをつける技術があるのかもしれない. あるなら知りたい. 


ヤバい経済学 増補改訂版 は arai さん推薦. 
読みそこねていたら増補されたので読んだ. おもしろかった. 


女は見た目が10割 は 
夢と欲望のコスメ戦争 に類する化粧本. 
たいして洞察はないが, 細かいウンチクや本音っぽいグチが面白い. 
同じ著者の ラブホテルの力 も
けっこうアホらしくて面白かった気がする. 


最近はエッセー集ばかりで喰いたりない斎藤美奈子が去年 
冠婚葬祭のひみつ 
なんてのを
書いていたのに気付き, 読む. やっぱりこの人は調べて書くのが向いてるひとだよなあ. 
結婚式や葬式のマナーを知らない自分は世間知らずだと恥じていたが, 
そうしたマナーは日本の伝統なのではなく, 
冠婚葬祭業界とマニュアル本によって作られたものだと説く. 
つまりマニュアルを読んでおけばいいんだな, と妙に安心. 
著者はそんな祭事を揶揄しているわけだけれど... 


職場にいるオープンソース指数の高い同僚をみて, 
比べると自分はそんなにオープンソース寄りでもないかもしれないなどと思いながら 
オープンソースの成功 
を読んだ. 
なにか色々考えた気がするけれどいまいち覚えていない. 本の内容はよく書けている.