地雷力のある人がいる. 簡単に直りそうなバグ, 一日で追加できそうな機能に手をつけたはずなのに, と当人はいう. バグがバグをよび, パッチがパッチをよび, 議論が議論をよんで, 目のまえに次々と刈るべき毛深いヤックが増えていく. そんな人がたまにいる. しかも話の流れでみつけてしまったバグをぜんぶ割り振られていたりする. 気の毒に...私が遠目にうかがうなかそのひとは毛を刈りだして, 刈るそばからバグや作業が次々と湧きだすけれど, しばらく経ってふと目をやるとあらかた片付いている. そして最後には歓声を耳にする: "おわった!" おめでとうと私は応じる. そのひとは次の仕事にとりかかかる, ああ, そのバグはやめておいた方が... けれどそのひとは動じない. いや一旦は動じるけれど, やれやれと仕事を再開する. そんな人には地雷力があるとおもう. 地雷体質, 羊毛フェチなど揶揄をこめるこ

2009-12-31 近況 プログラマとしての成長が感じられない一年だった. 目先の仕事に気をとられ, 問題についてよく考える時間をとらなかった. 過労を言い訳に勉強もしなかった. 情けない. 一方で仕事のチームでは成長を感じることができた. せっかくだから, "チームがよくなる" 感じについて書いてみたいとおもう. 最近, 私のいるチームはコードレビューをするようになった. 私はこれまで仕事の中でコードレビューを実施しょうと試行錯誤してきたけれど, チームに定着することは少なかった. コードレビューはそれなりに面倒な作業なので, 特に組織的な外圧がないところではさぼられがちだと思う. けれど今のチームは外圧なしでやっている. およそ一年間のプロジェクトを通じ, このチームがコードレビューをするに至った道程を振り返ると, チームが成長する様子をうまく捉えることができるかもしれない. フェー

ある Mac プログラマから "WebKit ってドキュメントがすくないよね" という話を聞いた. WebKit の挙動が気に入らないので直せないかと調べたところ, Mozilla と比較した文書の少なさに呆れたという. 私としては連載枠が貰えたのもひとえに文書がないおかげだから, そこに不満はない. (むしろめでたい.) けれどコードを直したい人が不便なのは困ったことだ. WebKit に比べ, Mozilla の内部は網羅的ではないにしろそれなりに文書化されている. この違いはどこから来るのだろう. 私の印象は, Mozilla が "書き直し" プロジェクトだからというものだった. Netscape は Netscape Natigator 4.x のコードベースを捨て, ほぼスクラッチから Gecko を書いたとされている. 私の仄暗い経験によれば, 書き直しのプロジェクトは最初に

PC は忙しい時ほど壊れる. 先週は職場の PC にこの経験則が降りかかった. 頻繁にフリーズしはじめる VisualStudio 2008. VS 単体での修復では問題が直らず困り果て, 結局 OS から入れ直す羽目に. まあディスクが故障しなかっただけ幸いだと思おう... OS の入れ直しは生活習慣を見直し悪習を捨てる機会でもある. 私の Windows 生活で最大の悪習は cygwin だ. ホスト OS への敬意を欠く cygwin には以前から後ろめたさを感じていたが, 惰性でずるずると使い続けていた. 今回のトラブルは良き市民たれという神(シアトル在住)の思し召しかもしれない. 啓示に耳を傾け, しばらく cygwin なしでがんばってみたい. PowerShell cygwin を捨てるということはシェルを乗り換えるということだ. いま Windows 民の間でホットなシェル

2008-12-20 近況 WEB+DB PRESS Vol.48 に記事を書かせてもらいました. デバッグをねたに, という話だったのだけれど, デバッグのような辛い記憶はすぐに忘れてしまうので無理です...とごねて その手前, エラー処理の話を書いてみました. 他の方はちゃんとデバッグの話を書いていてえらい... おまえはいつから Web とか DB をやるようになったんだという指摘は甘受いたします. なぜ RPC はいまいちか (今更編) WEB+DB Press には REST の連載があり, 今号は RPC の話だった. その記事を読んでいるうちに, 以前書いた 少し関係のある話 が途中だったのを思いだした. 元の記事は REST vs. RPC の議論だったけれど, REST はさておき RPC はどんな場合にいまいちか, すこし書いてみたい. 多くの RPC は, だいたい次

"集合知プログラミング" という本が出たらしい. 私の積読には元本の "Programming Collective Intelligence" があって, 途中まで読んだまま放置していたら日本語訳が出てしまった. (オライリーのアンチパターンと命名.) 悔しいので本は処分. そのうち日本語版で続きを読もう.... 興味を持っていたのは推薦エンジン(協調フィルタ)だった. 私の中では検索エンジンに匹敵するウェブのハイテクという位置付けなんだけど, 草の根には普及しておらず悲しい. 検索エンジンでの Hyper Estraier や senna に相当する協調フィルタの立ち位置は デッドヒートが予想される...とだいぶ前から思ってるんだけど, いまのところ閑古鳥気味. まったく, 出し抜くだけの実力があればなあ. 先の皇帝ペンギン本では, 一章にさっそく協調フィルタが登場する. 読んでみると

先週, 会社をさぼって システム性能評価と待ち行列理論 という講義を受けてきた. 待ち行列理論の入門講義で, 大学の学部でやるレベルの話らしい. 私は学部でも学部以外でも勉強したことがない話題だったので, とても興味深く聞いた. 受講後はすっかり盛り上り, 待ち行列で性能評価するぜ! という気分になったのだが, 実際は難しい. 性能評価一般の難しさはさておくとして, 待ち行列理論そのものがけっこう複雑. 数学が苦手な身には辛い. 理論の常として, 待ち行列の理論もまず解析対象の特性に様々な制限や前提を設けた上でモデルをたてる. そのモデルがうまく解析できたら, 少しずつ制限をとりはずしていく. 現実を扱えるモデルに至る道程は険しそうだ. 高価なツールを使えばそんな洗練されたモデルも扱えるのかもしれないけれど, もうちょっと庶民に優しい路線であってほしい. 解析に挫ける一方, 理論の成果が明

いただきました. ありがとうございます. ネットワークの構成から冗長化, サーバのチューニング, デプロイの自動化まで, インフラや運用の話題を集めた本. 私は運用やインフラに素人なので, 内容の技術的正当性について特に意見はない. ただ動いてる実システムの解説という点で信憑性は担保してる気がする. ひたすらすげーなあ大変そうなだなあと読んだ. 特に TCP/IP より下, LAN カード (という表記が我ながら素人っぽい. 玄人ぶるには NIC と呼ぼうか...) より向こうは つい所与のものと考えてしまう. たまに仕事で必要になっても同僚に押しつけてるし. 実は色々やってるんだろうなと, なんとなく思っていた中身を垣間みた気分になる. NIC より手前の話もあるけれど, 個人的には ハブ(...というと素人っぽい. スイッチ.) や ルータやロードバランサの出てくる話が, 未知の世界で

Protocol Buffer の話題は一部で熱く語られた...というより炎上していた. ようやく炎がおさまってきたから, 野次馬として現場にかけつけてみたい. 火事と喧嘩はウェブの華. 火元から見ていこう. 熱心な Google ウォッチャーである MS の Dare Obasanjo が, protobuf 公開に合わせ すかさず "The Revenge of RPC: Google Protocol Buffers and Facebook Thrift" という記事を書いた. 記事の主張自体は穏当なもの. 「最近一部で バイナリエンコードな RPC が流行ってるみたいだけど, 時代は XML と REST で疎結合じゃなかったの？」と修辞的な疑問を示しつつ, "いや基本的に Web は XML で REST な時代なんだけど, Web に出ない会社の内部ならバージョンやらツールを

HTTP の神 Roy Fielding による Apache 3.0 の 講演をストリーミングで拝聴した. (スライド PDF.) スライドの副題にもあるとおり, Apache 3.0 の計画は大風呂敷 (tall tale) で しばらく実現の見込は薄そう. ただ, コミュニティが大きな書き直しに至るまでの話は面白かった. http-dev メーリングリストの流量を時系列にプロットした Fielding は, 書き直し(メジャーバージョンアップ)開始の手前では ML の流量が減衰していると指摘する. 開発者コミュニティが活力を失っているのだと. そんな時に "がばっと書き直して刷新しようぜ" と言い出すとコミュニティは活気づく. そんな話だった. 2.0 もそうだったし, 3.0 も似た状況にあるという. 実際には言いだすだけでなく, コードが伴う必要もある. 調べてみると, 2.0

社会人になって最初に配属されたチームのコードはひどいもので, 私は同期の新入社員仲間 Y に "ひどいコードなんだ. あの先輩はろくでもない." と愚痴た. すると Y はぽつりとこう答えた. "<コードを憎んで人を憎まず> だよ." Y の言葉は私の座右の銘となった. コードと人格を切り離す. あたりまえの事に思えるけれど, いまより輪をかけて狭量だった私はひどいコードの書き手を見下していた. もちろん自分は棚にあげて. たかがコードで友情や信頼を失うのは愚かなことだ. Y はそう言うのだった. 件の先輩社員は寛大だった. 私は勢いと趣味に任せて彼のコードを書き換えていたが, 彼は文句もいわず, 雑用を押し付けてくることもなく, 他所からのメールやバグを黙々と片付けていた. 私が同じ立場なら, 間違いなく戦いの火蓋を切っていただろう. (実際, 翌年の私は毎日のように後輩と口論していた.

頭が痛いだけでなく, 寝ている時に頭の傷を庇うせいか首がいたい. 鞭打ちかもしらんけど... そして頭とセットで打った臀部もいたい. 満身創痍で出かける気力もなく, 家でうだうだしているところ. こんなに良い天気なのになあ. うだうだついでに貰った本の紹介. 最近貰った本: プログラミング Erlang いただきました. ありがとうございます > 著者およびオーム社の中の方. Erlang の親玉が書いた入門書の翻訳です. Erlang は言語として特に斬新なところはなく, 処理系の提供するサービスの出来がいい, というのを伝聞で聞いていた. 読んでみるとたしかにそうだった. 本の内容も言語仕様(文法)の話は前半だけ. 後半は分散だとか並列の話をしている. 面白いのは後半. 私はお仕事の関係もあって分散メッセージングの仕組みには少し興味があったから, これはとても勉強になった. actor

タネン本を始めとする分散システムの教科書で必ずとりあげられる話題に "分散コンピューティングの誤謬" がある. 以下 Wikipedia から引用. ネットワークは信頼できる. レイテンシはゼロである. 帯域幅は無限である. ネットワークはセキュアである. ネットワーク構成は変化せず一定である. 管理者は一人である. トランスポートコストはゼロである. ネットワークは均質である. ネットワークプログラミングをしたことがあれば, いずれも該当のバグに思いあたる節があると思う. これらはみな複数台の計算機が関わる際の問題であり, いわばコミュニケーションの問題. 同じ問題は計算機同士に限らず, 人と人の間, 組織の間でもおこる. 順番に例を並べてみる. <伝言や連絡は信頼できる> : できない(よね?) ミーティングには欠席者がいる. 後輩は話を聞いてない. メモもとらない. メールはスパムに

いただきました. ありがとうございます > 訳者のかたとオーム社の中のかた. 薄くまとまっているのは良いと思いました. あとはなにより訳が良いというのはアジャイル本では重要なのだと再認識しました. これは本を貰ったお世辞が二割くらいで八割本当. 私がこれまでに読んだアジャイルの本はなんというか lost in translation があり, アジャイル固有の良く言えば情熱的な, 悪くいえば宗教がかった迸りが失われていた. この本でも強調されているとおり, アジャイルの文脈では態度や感情の持ち方がそれなりの比率を占めている. それを伝える上で文体の果たす役割は大きい. 訳文はそうしたアジャイルのノリをうまくあらわしていると思う． 具体的な内容は, 私にとってはおおよそどこかで聞いた話だった. アジャイル関係の本はちょこちょこと読んでいるから当たり前かもしれない. 入門書として見た時の話題の

あまり早くもない朝, 布団の中で二日酔いに唸っていたら母から電話. 何かと思えばコードを書けという. 割り算の問題ジェネレータ. 小学校教諭である母が教材作りに使うのだ. よくわからんが以前作ったものだと機能が足りないので改良版をよこせとのこと. 以前といっても 2,3 年まえ. もう記憶もないしコードもない. 顔を洗って掃除洗濯, メールをみると仕様の補足が届いていた. ねぼけていたことにしてしらばっくれるつもりだったけれど, そうもいかないらしい. 遠い記憶を呼び戻しながら策を考える. 要件は三桁÷二桁の割り算の中から特別な条件を満たすものを選ぶという簡単な話. このくらいの割り算は総計で 80000 通りしか候補がないから 総当たりで条件をチェックすれば解ける. 前もそんな作りにした気がする. 別にロジックはむずかしくない. 面倒なのは母でも使えるというところ. 自分で使うなら ru

友人の話をしよう. 先達に敬意を表し, 仮に彼を K と呼ぶ. (イニシャルは便宜的なものだ; 向上心云々と罵ったこともないし, 恋人を寝取ってもいない.) ある時期, 私は K と一緒に働いていた. 今は違う会社にいるけれど, 互いに暇なのか, このごろもよく二人で管を巻いている. 1 K は優秀なプログラマだ. いつも敵わないと思う. 一緒に仕事をしていたこともあり, プログラマとしての私は K から強い影響をうけている. たとえば私が自動テストを始めた発端には K がいる. コードレビューもそう. この日記に出てくる話も K の影響は色濃い. 私は K のあとを追いかけるようにプログラマを続けている. K と働いてはじめて, ああ, 物事とはこう改善していくものなのかと知った. 何か問題を感じると K は試行錯誤を始める. 問題は私が諦めていたものもあるし, そもそも気付かないものも

昔の同僚が退社してベンチャー仕事をやるという. 門出を祝う宴会に, 昔のよしみで呼んでもらった. ついでに古巣の近況を聞く. ひとつ嬉しい知らせがあった. 以下その自慢話. ある夏, 私は社内ライブラリのチュートリアルを書いた. そのチュートリアルが, 今でも改訂されながら参照されているという. のみならず新人プログラマの研修教材として広くとりいれられつつあるそうだ. 私はとても嬉しくなった. もちろん手柄は改訂を続け, 様々な改善を続けた彼らのものだ. それでもなお私は喜びを隠せない. 自分が去った今も文章だけが生き続けている. 私は平凡なプログラマだから, 自分のコードが生き残れるとは思えない. 一方ボランティアで仕事の合間に書いた文章は読み継がれている. 価値のあるものが生き残るのなら, 私のなした価値は(コードではなく)文書にあったことにある. プログラマとしては悲しいけれど, 会

Subversion の開発者が ChangeLog について面白い記事を書いている. 記事の要旨はこうだ: ChangeLog (Subversion なので commit log) を書くのは面倒だよ, メーリングリストもあることだし書かなきゃダメ? ってよく訊かれる. 書きましょう. バグトラックもあるけど, 書きましょう.これらのツールは補完しあっている. メーリングリストはノイズが多いし, 変更を特定するには情報が足りない. バグトラックはバグの記録がメインだからコードの話を細々書くのは邪魔になる. 変更については ChangeLog に書くのがいい. プログラマは ChangeLog を読む. 記録を検索して, どの関数に何が起きたかを調べるものだ. この類の記録は ChangeLog を読まないとわからない. 逆に ChangeLog を書く時は, それを特定できるように省略

ソースコードなどの変更履歴を ChangeLog と呼ぶ. オープンソースのソフトウェアで変更履歴を "ChangeLog" というファイルに書いたのが ChangeLog のおこりだと思う. 最近は Subversion などに登録された変更履歴も change log, あるいは commit log などと呼ぶ. 以下ではそれらを ChangeLog と総称する. 最近わけあってこの ChangeLog をどう書いたものかと考えている. コーディング規約には山ほど資料がある. コメントの書き方もよく議論される. しかし ChangeLog についての読み物は少い. GNU コーディング規約 は数少ないそうした文書である. この説明はよくかけている: ChangeLog は将来のメンテナがバグの原因を探るのに使うものだ. コメントに書くべきものはコメントに書け. 関数名を並べろ...

なんとなく Jim Gray のページ を見ていたら, "To BLOB or Not To BLOB: Large Object Storage in a Database or a Filesystem?" という記事があった. データベース業界には "ちまいデータは BLOB に入れろ, でかいデータはファイルに置け" という口伝があるらしい. (業界ビトでない私はしらなかった...) でも "でかい" って具体的にどのくらいなんだろう. 実験/ベンチマークをして BLOB とファイルシステムを比較, 疑問に答えましたよというのがこの記事. このごろはビデオや写真をウェブに置くのもふつうになりつつある. そういうメディアなデータを保存する世相を知っておくのはいいかもしれない. 読んでみた. この実験では BLOB の実装に MS SQLServer, ファイルシステムに NTFS を