2008-01-11
近況.
とっくに明けてますがおめでとうございます. 親元には WiiFit がありました. また負けた. 悔しいので世の中にはニコニコ動画というのがあって... とまだまだ若いところがあるのを見せようとしたらアカウントがなくて, 仕方ないので金を払ってプレミアム会員になり, 猫鍋やらアホな料理を見ていたら年が明けていました.
最近読んだ本
前回は 8 月. 全然最近じゃない...
オブジェクト志向設計入門 第2版 原則, コンセプト
古典ということで読んでおく. 厚い. 辛かった. 古さは感じるが, しっかりとした内容でそこそこ満足. 継承の話以外は.
1/3 くらいは継承の話で, そこは辛い. もう多重継承とかやめてよ... 継承付近のつじつまあわせで Effiel の言語仕様は やたらと面倒になっている気がする. 使うことはないからいいけれど.
基準, 規則, 原則の議論はよく引用されるだけあって力強い. DbC はもちろん, そのほか抽象データ型や共変など理論的な話も案外詳しくて勉強になった.
継承への殺意はさておき, どのへんに古さを感じるのか考えてみる. おそらく "変更" に対する扱いが軽いからだろう. ソフトウェアの仕様は変わるし, 自分の最初の設計はまずい. だから現実問題としてソフトウェアは "閉じて" ばかりもいられない. Meyer の方法論は, ソフトウェアの成長シナリオとして "拡張"(追加) に主眼を置いている気がする. でも実際には既存のコードを開いて書き直したり, 部分を差し替えたりしたい. (継承など)結合の密になりがちなアプローチだとそういう組替えがきついんだけど, 拡張が主体だと目立たないんだろうな.
一方で近代的なソフトウェア開発では成長に伴う変化を一級市民として扱う. リファクタリングや TDD がそれを象徴している. 皮肉なことに, 今となっては暫定/抽象クラスを用いるアプローチが Meyer の挙げる "単一責任選択の原則" に合致するとはとても思えない. 原則は変わらず, 解決方法は変化していく.
Optimizing Linux Performance
プロファイラの話を書いたついでになんとなく読む. カーネル・パラメータをチューニングする話かと思ったら, Linux 上で動くプログララムを様々な計測に基いて高速化するための話だった. 予想は裏切られたがとても面白かった.
一章は高速化の概要. 自分のしたことがわかるよう, とにかく全て記録に残せ. 面倒な計測作業を自動化しろ. オーバーヘッドの低いツールを選べ. 複数ツールで問題を理解しろ. 他人の経験を(慎重に)頼れ, などガイドラインが並ぶ. アルゴリズムが重要, みたいなわかりきった話をしないあたりがわかってる.
2-8 章が各種集計/計測ツールの紹介. CPU 負荷をはかるツールだけでなく, メモリ, ディスク, ネットワークの状態を 監視する様々なコマンドを紹介する. 知らないツールも多かった. slabtop なんてあるんだ... そのほか名前は知っていても(私が)使いかたを知らないツールもサンプルつきで紹介されており, そういう風に使うのかと勉強になった. xxstat 類とか.
9 章は問題分析のためのフローチャート. 遅いアプリがあったとき, 何を調べて問題を絞りこんでいくかという表がある. こんな機械的に高速化できたらかっこいいよなあ.
10, 11, 12 が一番の読みどころ. 実際のアプリケーション (GIMP, nautilus, prelink) を 高速化したケーススタディを紹介している. 読み物としてめちゃめちゃ面白い. スーパーハカーの実況中継というかんじ. 高速化について自分がいかに素人かを思い知る.
厚さは 350 ページ. 半分以上はコマンドと出力のダンプなので, 体感は 100 ページくらい. さっくり読める.
Agile Web Developmen with Rails 2nd edition
初版は読んでいるので, 差分をぱらぱらめくる. migration とか. 色々と便利になっていて驚く. みんな熱心に追いかけるわけだ.
買った半月後に 日本語版 が出でがっくり...
Beautiful Code
"Beautiful Code" というお題で 33 人の著者が思い思いの話を書いたエッセイ集. 夏ごろに出た本で, 翻訳がでるかなーと思って待っていたけど諦めて読んだ. 役には立たないが面白かった. 基本的にプログラマによるお気に入りコード自慢. こいつはビューティホーだと思うのもあれば, ひどいコードだなアホめと思うものもある. そういうツッコミも含めて楽しい. プログラマで良かったなーと思う. こればかりはプログラマにしか判らない楽しみだからね.
話題はサーバからゲノム解析, ホーキング博士用の入力デバイスまで, 言語は C++ から Perl, Lisp, FORTRAN, Matlab まで. 幅広い. 私は 1/3 くらいわからず読み飛ばした. つかみとまとめを読み, 面白そうなら残りも読むといい. 割とどうでもいい話もそこそこ混じってるし. 一方でコードとしての楽しさだけでなく, 書き手の個性や信条が伝わってくるものもある. ときに深く共感し, わかりあった喜びが残る.
個別の紹介は面倒なので割愛. 目次 を参照のこと.
プロフェッショナル撮影技法
仕事でウォークスルーっぽいアプリケーションのカメラ位置を決める必要があり泥縄的に読む.
あまりわかりやすい本ではない. 文章の筋立てが弱く, 展開についていけないことが多い. ただページ数自体は編集やカメラワークの話題に多く割いており, 映画の世界にある色々なカメラやその取り方の定石がいくらかわかった. 普段はあまり気にして見てないから新鮮. あとは映画の人々が CG に夢を見た理由がよくわかった. 映画は物理的な制約がとても多い. だから最初のころ, 自由にカメラを操り録り直しもできる CG に夢を見たんだね.
逆にゲームのように CG 前提の世界だと物理的な制約なんてのはないから カメラは映画とはまったく別の常識で動く. (描画負荷を減らすとか.) そんなわけで物理的な映画の話が直接私の役に立つことはなさそうだった. イベントなんかで映画的な演出をしたい時は別なんだろうけれど.
後半 1/3 は光画部寄りの話題が多く興味から外れたため読まず. CEDEC光画部 に入りたくなったら読みます...
パターンによるソフトウェア構成管理
だいたい実践している話だった. だからパターンとしては悪くないと言える. ...だいたい実践しているといのはややブラフ. やらなきゃなーと思いつつやっていないものもある. というかやってない. 数えてみたら 16 個パターンがあって, 実施してるのが 5, 実施してるけど不完全なのが 2, 実施してないのが 3, プロジェクトの規模のおかげで不要と思われるものが 6, という分配だった. 勝率 (5+0.5*2)/10 で 6 割か...
パターンの記述はややわかり辛い. ちゃんと読めば問題の文脈と解決が書いてあるとわかるけれど, ぱらぱらページをめくりながらピックアップできる感じではない.
Mercurial ユーザとしては, 分散 SCM を使うことでブランチを使うパターンがぐっと楽になる点を強調したい. Private Versions, Task Branch あたりは 分散 SCM にとっては標準の動作だからね.
アジャイル レトロスペクティブズ
"ふりかえり" の方法論. 定量的な観測や問題解決よりも チーム内の不和や感情的なしこりを取り除くことに注力している. それがなんというか, 興味深い.
そういえば少し前にプロジェクトのふりかえり (社内ではポストモーテムと呼ぶ.) があった. 初体験. 不満や問題点を書き出し, 議論するのはなかなか面白かった. ただそれを具体的な改善に結びつけるのは難しいとも感じた. そのポストモーテムも問題点のリストや改善アクションの候補を出すところまでは進めたけれど, 実行の割り振りや追跡が出来ないまま放置されている. 言いたいことを言って憂さ晴らしができると自分の中の不満レベルが下がって 面倒を後回しにしてしまうのかもしれない. 割り当てを決め, 次フェーズのタスクに紛れこませることがきればいいんだけれどなあ. 相談してみよう...
感情的な面では, 私は不満を持った瞬間にブチブチ文句を言ってしまうので 口に出せずに溜めるものは多くない. どちらかというと, 感情的になってしまったり感謝を表明しそこねたりして 溜まっていく後ろめたさの方が多い. だから "ふりかえり" という形式を借りて, ごめん, ありがとうと言えることの方が嬉しい.
話がそれた.
この本で紹介されている方法はけっこうヘビーウェイトなので, "ふりかえり" 入門としてはオブジェクト倶楽部の プロジェクトファシリテーション実践編：ふりかえりガイド の方がコンパクトで良いとおもう.
実務で役立つプロジェクトファシリテーション
こんなのばっかり読んでるな. 会社でやったポストモーテムの予習用. すげー付け焼刃ですが...
ミーティングにはシナリオ(アジェンダより細かい時間割)を作って望むというのと, ホワイトボード(のかわりに同僚の趣味で模造紙)を区切って 議論のフレームを見えやすくするというのを試した.
いまパラパラとページをめくるとかなり内容を忘れているなあ. もともと人間関係や感情に興味が薄いので覚えが悪い. 会社に置いといた方がいいかも.
プロジェクト・マネジャーの人間術
また似たようなやつ. 私は別にマネジャーでもなくマネジャーになる予定もない. マネジャーな人に迷惑をかけないポイントを知りたくて読む.
この本はとてもうまく整理されており, マネジャーが対処すべき人間がらみの問題についてよく理解できた. 私だったら面倒がって放置したりなす術もなく振り回される問題を, マネジャーな人々はなんとか片付けているのだなーと溜息.
動機付けに関する章の末尾にある "討議用課題" の示す困難は象徴的. ちょっと引用してみる:
アンジェリカは, ソフトウェア開発プロジェクトのプロジェクト・マネージャです. ...(略)...社内では人員削減が実施されるとの噂も流れています...(略)... メンバーの一人は内向的なベテラン社員で14ヶ月後には退職します. また, 他国で学位を取得して帰国したばかりの新入社員もいます. また, 二人の技術契約社員は期限未定でプロジェクトに出向してきています. さらに, 自分がプロジェクト・マネジャーに選ばれるはずだったと不満げな通研技術者がいます. あとの二人は, 若いエリート技術者で革新的な技術を持っていますが, 仕事のツメは 甘いとみられています. ...(略)... 1. あなただったら個別にどのような動機付けを行いますか 2. まずは手始めに何を行えばよいでしょうか. 3. 効果測定はどのように行いますか。
いやはや. 手始めに逃げるね. 自分だったら...
プロジェクトマネジメント知識体系ガイド第3版
プロジェクト管理の公式教科書. PMBOK ってやつですね. 日頃の暮しで特段役に立つ感じはないけれど, 語彙の獲得にはなる. こういう基盤の上で stakeholder が議論を勧められたら話は楽だろうね. 一方で形式だけ整っていて実の無い運用をしているプロジェクトもある. それならぐだぐだの方がマシかもしれず, 難しい.
教科書の冒頭にはこれをフルセットで使うことはまずないと書いてある. せっかくなら色々なバリエーションを見てみたい. もっともそれは他の教科書の仕事とも言える. McConnell の 新約 ソフトウェアプロジェクトサバイバルガイド も PMBOK に合わせて訳されなおしている. このように開発方法論の教科書が PMBOK の語彙に合わせていくのは名案な気がする. 比べやすくなる.
完全独習統計学入門
著者の小島寛之は他の書籍 ( 確率的発想法 ) が結構面白かった. なので読んでみた. (数学苦手コンプレクスを突かれると弱いというのもある.)
この本も内容はかなり易しいが, ちょろまかして誤魔化そうとするところはない. 著者のこういう姿勢が好き. このヌルさで学部レベルの統計を網羅してくれたら 全十巻でも読むんだけどなー.
そしてページをめくり, 内容を半分以上覚えてない自分に驚く. 確実に脳が劣化している...
ワインバーグの文章教室
どうやって書くねたを集めるか, どんなねたを集めるか. 集めたねたをどう整理して示すかに焦点を置いている. ねたを "石" と呼び, 石の壁 を積みあげるメタファーで話を進める.
私はねたを集める必要性に追われていないから, 作家は大変だなーと思いながら読んだ. ただ文章にかぎらず面白いねたを集めておくのは その人の interestingness という観点からは意味があることかもしれない.
後半は少し文章構成の話が入っている. このへんはよくある話ではあるが面白い. またワークショップの題材として使うことを意図した話題が多い. 一人で読んでもつまらないけれど, 文章を書きたい人が集まって ワークショップをするのは面白そう. ワインバーグ勉強会みたいなの. やるなら行く.
そのほか
"サブプライム問題とは何か" は lucille の人 が勧めていたのを見て. 税制の歪みは昔からありそうな話だけれど, 証券化されて危険が隠されてしまうというのは現代的だ.
もちおファンとして "ウェブ時代をゆく". 私のように薄情なひきこもりには厳しい時代になったなと, けものみちで野垂れ死ぬ予感に怯えた. いや, いろんな人に会ったりもしたんだけれど, 対話能力って使わないと指数的に劣化してくんだよね...
"若者はなぜ「会社選び」に失敗するのか" は インタビュー集とあったのでエスノグラフィーを期待したけれど, だいぶ違った. 各種大企業を色々なカラーの軸にプロットし, 社風のほんとのところというのを炙りだそうとしている. 野次馬としては面白い. 信憑性はどうなんだろう. 私の知り合いのいる会社もいくつかけなされていたけれど, 彼らは楽しそうにやってるからなあ. もっとも数千, 数万人の集団がそう一様なはずはないか.
イアン・スチュアートなので著者買いした "若き数学者への手紙". 著者が仮想の姪である "メグ" に送った手紙という設定で書かれた数学(者)エッセイ. 高校生のメグに送る手紙からはじまり, 章を追うごとにキャリアを勧めていく. イアン・スチュアートの描く数学者コミュニティがどこか庭園的な平穏を含んでいるのは, イギリス人だからかなあ.
梨木香歩 "ぐるりのこと" も著者買い. "春になったら苺を摘みに" にあった 幻想的な語りはいくらか影を潜め, 日常におちる不穏な翳とどう折り合いをつけるか, そんな話が多くなっている. 雑誌の連載だったからかもしれない.
けれど僕たちはしなかった. 月の光を浴びながらも, 君のアパートの裏庭で燐光性のカンテラみたいに光るホタルたちに照らされながらも, 僕らには見えない, ましてや解読しようのない星座の下でも, もはや僕たちから盗まれてしまった夜の真の闇にとって代わった暗い薄光のなかでも, 僕たちはしなかった. 街がじわじわと朽ちていくにつれてビルの谷が僕らの背後で次第にのぼってくるさなかにも, 冷戦が荒れ狂う夏の暑さのさなかにも, 僕たちはしなかった. 若さゆえの自由にもかかわらず, 初恋ゆえの気ままさにもかかわらず, 運命のせいで, 業のせいで, 運の悪さのせいで --- 何だって同じことじゃないか? --- 僕たちは, しない, ということをひとつの驚異に仕立て上げたのだった. そしてなお, 僕たちはしなかった. 僕たちはしなかった. ただの一度もしなかった.