2006-04-22

近況

ビール仲間を求めて大学時代の友達に電話をしたら, もうすぐ退職して自営業者になると聞き驚く. 会う度にやめるやめると言っていたのを, 私は典型的なサラリーマンの愚痴と聞き流していた. 本気だったとは. 自営業は営業活動が大変と伝え聞くが, 彼はもともと外交的な体質なのでうまくやる気がする.

自営業者の友達がふえると, しめしめ, クビになったら雇ってもらおう ... などと考えてしまう自分に気付く. なさけない. Gurus, Hired Guns and Warm Bodies を読んで以来, 私は自分が正社員社会からドロップアウトするうわついた恐怖を捨て切れずにいる. なぜかはわからない.

気がつくと夜は深く, ビールも飲み損ねた.

最近読んだ本 : Essential COM

最近 C++ を使うことがあった. コードを書いてみると C++ 能力の低さに我ながらがっくりくる. なんというか, 自動的に書けない. 自動的というのは いちいち細かいことを気にせず体が覚えたイディオムに従ってコードを書く あの感じ. 私は Java ならそこそこ自動的に書ける. C++ だとそうはいかない. 自由度が高すぎて悩むことが多い. もう少しルールを縛って書きたい. しかし従うべき良いルールが見当たらない.

世間の職業 C++ プログラマはおそらく自分/会社なりの ルールや枠組みを作っているのだろう. たとえばスマートポインタをどのくらい積極的に使うか, 何を POD にするか, 参照カウントは使うか, QI 相当の仕組みをどう用意するか, 何を仮想関数に, 何をテンプレートにするか, 例外をどのタイミングで投げるか, 何をメンバ関数に, 何を free floating 関数にするか, など... 特定のフレームワークに乗るならその流儀に従えばいい. ただ私の場合フレームワークはいらない. ルールとイディオムがあればいい. とはいえ Effective C++ に類する教科書のルールはプリミティブ過ぎる. もう少し高位のルールと, それを支援するツールキットが欲しい.

で, ヒントを求めて読みなおした. COM は素晴しいね. 私が最初にこれを読んだのはだいぶ前のことだ. その時はほとんど何も理解していなかったことがわかった. (そして今回もアパートメントのあたりはよくわからなかった.) 当時色々わかっていなかったことはあるが, あの頃は特にコンポーネントやコンテナについてわかってなかった気がする. だからコンテナが何をしてくれるかという視点を欠いていた. スレッドまわりの保護やマーシャリングなど, かなり色々やってくれるんだね.

たぶん COM プログラマはかなり自動的にコードを書けるのだと思う. COM のモデルに従った "良い" スタイルは限られている. こんな風に確立したルールやプロトコルでコードを束縛したい. ただ私は当面 Win32 で仕事をすることはないから COM は使えない. それに, COM はちょっと古い. (Microsoft のサイトにすら COM の仕様書は見当らない. obsolete すぎる... 誰か持ってたらください.) 言語中立やコンパイラ中立などがいくらかオーバースペックでもある. もう少し軽量モダンかつ堅牢な C++ のプログラミングモデルが欲しい.

最近の C++ は私が期待している方向への進歩はしていない気がする. プログラミングモデルを縛るという目的では boost も c++0x も役に立たない. boost や STL は主義主張をしないよう 注意深く generic に書かれている. (だから使いやすい.) しかしアプリケーションのコードを generic に書くのはコストが高過ぎる. genricity を利用して specific なコードを書く 平民アプリケーション・プログラマへの関心を C++ 界隈は欠いている気がする. 平民(私)は genericity にもメタプログラミングも大して興味はない. アプリケーションのドメインモデルを手早くコードに落として動かしたいだけ. その際に, スタイルが一貫し可読性が高く, 規模が大きくなっても破綻せず, バグが入らず, コンパイル時間が現実的で, 性能もそこそこ, そんな基盤の上で自動的にコードを書きたい.

だいぶ甘えたことを言っている気がしてまいりました... 修行が足りないだけかもしらん. Effective COM も読みたい. しかしかなり難解だと伝え聞き躊躇中.

最近読んだ本 : Inside C++ Object Model

C++ 繋がりで勢いあまって読む.

cfront の開発者が C++ のコードはコンパイルされるとどうなるのかを解説する. コンパイル結果はだいたいこんな C のコードと等価になりますという話が中心. 暗黙に生成/実行される関数群, 一時オブジェクト, クラスのバイナリレイアウト, コンストラクタの実行順序, vtbl ... 各種 C++ の教科書だとこうした話題は断片的に登場するだけだ. それを一望できるのはいい.

そして一望するとかなり気が滅入る. たとえば, 多重継承の話がかなり念入りに議論される. C++ の教科書を読む時は どうせ多重継承なんて使わないよね... と, 心がフィルタアウウトしていた話題だ. それと向かい合うことになる. かなりややこしい. 仮想継承なんて最悪だ. たとえば

class A { .. };
class B : virtual public A { ... };
class C : virtual public A { ... };
class D : public B, public C { ... };

とクラスを定義した時, B や C のコンストラクタは 自分の初期化だけをするバージョンと A のコンストラクタも呼び出すバージョンの 二種類が生成される. D のコンストラクタでは B, C のコンストラクタのうち 自分の初期化だけをするバージョンを使う. B を直接インスタンス化する場合は A のコンストラクタを呼ぶバージョンのコンストラクタが使われる. ...というような話. gcc -S して確認すると たしかに二種類のコンストラクタが生成されていた. うええ... C++ は主記憶の消費ならなんとか予想できるけど, コードサイズはさっぱり見当がつかない. これだけ色々やられては仕方ない.

そのほかにも仮想クラスへアクセスする際の offset を vtbl に保存する話, 多重継承をした仮想関数の呼び出しに使われる thunk のアイデアなど, C++ マニア垂涎, 良心的なプログラマは逃げだしたくなる話題ばかり. JavaScript 仕様を馬鹿にした自分を心から反省.

古い本なので例外や RTTI の扱いは軽い. RTTI はともかく, 例外は生成されるコード全般に影響があるはず. 詳しく説明してほしかった. 著者によると cfront は例外をサポートしきれず頓挫したという. 要するに C のソースコード生成ではまともに扱えない機能というわけか. 想像を越えて厄介そうだ.

薄くて字が大きいのは良いが, 英語はわかりにくい. たぶん文章が下手なんだと思う. また製本はひどい. 字の歪んでる部分が多い. (私が外れをひいただけかもしれない.) 値段も高いのであまりお勧めできる本ではない. 暇なので読みたいという方はメールもらえればお貸しします.

最近読んだ本 : JavaScript 第三版

Shibuya.js の帰りに購入.

良い本だった. かなり詳しく細かい話まで書いてある. これを読めば仕様書は読まなくても良さそう. 仕様書は細かい API を調べるに便利だけれど, 通読するのは面倒だ. 良い本があるならそれに越したことはない. また仕様書と違い利用者向けに書かれていてわかりやすい. 私は Call オブジェクトのあたりをよくわかっていなかったが, これを読んでようやくわかった.

ECMAScript 仕様だけでなく Netscape 拡張も載っているのは面白い. Closure オブジェクトなんてものがあるとは知らなかった. まだあるんだろうか. (...なかった.)

前半は JavaScript の解説, 後半は DOM の解説になっている. DOM の部分は概要を知るにはよい. 私は HTML DOM (!= XML DOM) をよく知らなかったので読みではあった. ただ実用性は低いかもしれない. 参照している実装が古い. 今更 NN4 の問題がどうこう言われても興味がわかない.

その実用性の低さも歴史的な資料としては面白い. たとえば DOM の イベントモデル. IE は bubbring を, NN は capturing を実装していて互換性はないとある. 私は DOM Event 仕様を見たとき, なぜ bubbring と capturing の二種類の伝播モデルがあるのか さっぱりわからなかった. 実装の和だったのか. 謎がとけた. ほかにもあるバージョンではバグがあって他のバージョンでは直っている, という類の話は多い. 進歩の過程が見えて楽しい.

"Writing Solid JavaScript" には足りないけれど, "プログラミング言語 JavaScript" としての役割は果たせる本だと思う. 勧める人が多いのも納得できた.

最近読んだ本 : Getting Real

Backpack や RoR で知られる 37signals が 自社の開発プロセスや技法について書いた本. なかなかミーハー心をくすぐる.

大企業を目指さない謙虚さと優秀なスタッフによって実現できる 超アジャイルなソフトウェア開発とはこういうものだ, という内容. なかなか刺激的. 一方で, これを実現できる暗黙の前提は厳しい. 特に開発や運営のプロセスについてはそれが顕著. 大半の読者にとってはとても真似できそうにない. 書評を見ても, "いい方法だと思うけどうちじゃムリだよねー" という反応が多い. exMSFT のプロジェクト・マネージャ Scott Berkun は レビューの中で, この非現実さは彼らの経験不足からくる限界だと指摘する. 要するに恵まれない現場を知らないのだと. 説得力がある. きっと 37signals はタレント揃いなんだろうね.

とはいえ, そういう政治的な部分をさて置くと学ぶべき話題は多い. "Interface Design" と "Wording" の章 (どちらも UI の話) は 37signals 製アプリケーションの小粋さがうまくまとまっており, とても面白かった. (個人的には機能選定と UI を掘り下げて本を書いて欲しい. ディフェンシブ・ウェブデザインの技術 も面白かったけれど, 逆に話題を絞りすぎ.)

プロセスの部分については, 趣味プログラミングの方法論だと思って読むといいかもしれない. たとえば機能追加について "まず NO という" 姿勢を, 無茶な野心で自滅しがちな趣味プログラマは見習っていいだろう. メジャーソフトと競合しようと思わずニッチをつけという話も同様. 地味でも便利なソフトウェアを小さなコストで楽しく作ろうという 意思が通底している. それで金を稼げるかには議論があるのだろうけれど, 基本理念そのものには同意できると思う.

とても薄いくて字も少い. 新書みたいなかんじ. PDF のみ.

最近読んだ本 : グーグル—既存のビジネスを破壊する

ファンブックとして購入.

なかなか面白い. NHK スペシャルを見ている気分. よく取材している.

ただ世間の "アルゴリズム = 中立公正" という感覚はなんとか訂正したい. "コンピュータ = 間違えない" の亜種なのだろうけれど, この誤解は早めに解いておかないと色々不都合がありそう. ( 誰か:"グーグルはこっちが正しいっていってるよ!" 私:"うるせー, それは仕様がバグってるんだ!" とか. ) 今までも似たような議論はあったのけれど, これまではやれやれと肩をすくめていればよかった. しかしこのイメージを恣意的に利用するアルゴリズム原理主義者が現れると話は別. 部外者(私)がとばっちりを受けかねない.

一方で, けっこう根深い問題のような気もする. 数式を目にした時の思考停止と同根なら厄介だ. 少し考える必要がありそう.