2005-10-19

近況

RTR の complement として OpenGL2.0 の仕様 を読み始めた. Direct3D と違い PDF なのがよい. API の設計は古臭い(実際古い)が, 仕様書自体は良く書けている. 少くとも素人目には. 思ったより読みやすい. 学生のころ赤い本とセットで読んでおけばよかった. (読み切れる自信はないけど. 昔も今も...)

これまでハードウェアによるアンチエイリアシングの方法に無関心だったのだけれど, "multisample buffer" なんてものがあるんだなあ. これは要するにサンプル数の数だけフレームバッファと同じようなのバッファを用意するということなのだろうか. そんで画面に描く時に合成すると. そんな富豪的なことをしているとは. 最近の高級ビデオカードは RAM が 256MB も載っているというのを見て何に使うのだろうと思っていたけれど, こんなノリで使っていたらたしかにすぐ足りなくなる気はする. ほんとにそんななのかは知りませんけれども. 誰か教えて.

仕様書を刷る

仕様書は Kinkos で印刷, 製本した. OpenGL 仕様はだいたい 350 ページくらいある. 一枚 10 円だとして, 両面刷りすれば \1800 くらい, まあいいかと思って刷ったらなんと片面 10 円. 製本代も含めたおよそ \4500 を請求され面喰らった. Kinkos が高いのか世間の本が安いのか. ボーンデジタル書籍の値段にケチをつけようにも気が引けてくる.

私は学生の頃から印刷フェチで, しかも質より量だった. 研究室のプリンタでよく読みもしない PDF や PostScript を印刷し, 連なる積分記号を眺めながら満足していた. たまに読むこともあった ... 積分記号の数と読破率は明確に反比例していた. (反比例のように素朴な相関しか頭にうかばないあたりで察してほしい.) 会社に入ってからはやや遠慮して (加えてプリンタの印刷品質がいまいちだったので) あまり印刷をしなくなったけれど, 少し前から Kinkos の印刷製本に味をしめ, また色々刷りだした. 印刷だけでなく製本して背中を閉じ表紙をつけると, ただの紙束がエラそうになる. なかなか良い. 散財.

ワンクリック製本を求む

Kinkos の印刷製本サービスは便利だが, 改善の余地もだいぶある. まず電子入稿が不便. CD-R や MO に保存して店舗まで持っていく必要がある. ふだん CD-R を使わない私にとってこれは面倒. メール添付なり Web からのアップロードなりで入稿できるようにしてほしい.

Kinkos には オンライン印刷注文 のサービスがある. ウェブからファイルをアップロードして印刷を頼むサービス. しかし使おうとして途中で挫折. とても不便だった. まず UI の出来が悪く各種設定 (片面/両面, カラー/モロクロ, etc) の入力が面倒. 明らかに冗長なあれこれを入力させる. 更にウェブで見積りができない. なんと実際の店舗にメールで連絡が行き, それを人間が見て見積り, 返信をくれるらしい. 面倒な入力をさせておきながら最後は人手かよ! 電話の方が楽じゃん. しかも(人手なので当然)レスポンスに時間がかかる. とても待っていられない. こういうのはすぐ欲しいのだ. (ある種の物欲だから.) 結局ごそごそと掘り起こした CD-R にデータを書き込み, 店頭で印刷, 製本した.

Adobe Reader のアドオンに "製本" ボタンがあって, これをクリックすると最寄りの Kinkos で印刷製本された資料が受け取れる, あるいは Amazon から届く. そういうのが欲しいなあ. Adobe がどこかのプリンタ会社と結託してそんな商売を始めたら, 私はグリーンピースに命を狙われる過激派極右プリンティングバインディストともなろうよ.

仕様書を読む

仕事を始めて印刷の量は減ったけれど, 刷ったものを読む割合はいくらか増えた. 特に仕様書を読むようになった. 顧客からの要求仕様のように読まざるを得ないものだけでなく, もう少し技術的なものもいくつか読んだ. (途中で挫けたものが多いけれど.) OpenGL 仕様もその一環.

あるテクノロジに関する仕様書, あるいは仕様書に限らない公式文書の類を読むのは, 面倒だが得るものも多く, 読めば割に合う. プログラミング言語の言語仕様, ライブラリやフレームワークのリファレンス・マニュアル, ネットワーク・プロトコル, データフォーマット, 各種ガイドライン, など. 入門書を読んで実際に手を動かしたら, あとは本やウェブを漁るより仕様書を読む方が無駄は少い. 本やウェブのハズレより仕様書のハズレの方がずっと少いからだ. (そもそも仕様書がハズレのテクノロジはそれ自身ハズレである公算が大きい.)

よく書けた仕様書やリファレンスはそのテクノロジの教科書でもある. ただ詳細を網羅しているだけでなく, テクノロジの意図や目的, アーキテクチャをはっきりと示している. そういう記述はだいたい前半に書いてあるので, 途中で挫けてもけっこう実入りはある.

心理的な影響も無視できない. 仕様書を読むとテクノロジの "底が見えた" と感じるようになる; すごいと思っていたものが案外地味だったり, 厳格だと思っていた標準が隙間だらけだったり, 最新だと思っていたら山のようなレガシーをかかえていたり, 単純だと思っていたら奥が深...複雑だったり, 古臭いと思っていたら洞察に溢れていたり. こうした驚きや発見によって, なんというか, 絆が深まる. 入門書やサンプルコードだけを頼りに仕事をしていた時の幻想や抑圧や不安がなくなる. テクノロジを embrace できるようになる.

そう考えるようになってからは, あるテクノロジに精通しようと思ったら本を読むだけでなく仕様も読もう...と心掛けるようになった. これはプログラマのベスト・プラクティスと言って良いだろう.

あ. ベスト・プラクティスは心掛ける(=製本する)ことではなく読むことですからね. 誤解なきよう...