分散プロジェクトの誤謬 - steps to phantasien t(2008-02-26)
タネン本を始めとする分散システムの教科書で必ずとりあげられる話題に "分散コンピューティングの誤謬" がある. 以下 Wikipedia から引用. ネットワークは信頼できる. レイテンシはゼロである. 帯域幅は無限である. ネットワークはセキュアである. ネットワーク構成は変化せず一定である. 管理者は一人である. トランスポートコストはゼロである. ネットワークは均質である. ネットワークプログラミングをしたことがあれば, いずれも該当のバグに思いあたる節があると思う. これらはみな複数台の計算機が関わる際の問題であり, いわばコミュニケーションの問題. 同じ問題は計算機同士に限らず, 人と人の間, 組織の間でもおこる. 順番に例を並べてみる. <伝言や連絡は信頼できる> : できない(よね?) ミーティングには欠席者がいる. 後輩は話を聞いてない. メモもとらない. メールはスパムに
steps to phantasien t(2007-07-06)
昔の同僚が退社してベンチャー仕事をやるという. 門出を祝う宴会に, 昔のよしみで呼んでもらった. ついでに古巣の近況を聞く. ひとつ嬉しい知らせがあった. 以下その自慢話. ある夏, 私は社内ライブラリのチュートリアルを書いた. そのチュートリアルが, 今でも改訂されながら参照されているという. のみならず新人プログラマの研修教材として広くとりいれられつつあるそうだ. 私はとても嬉しくなった. もちろん手柄は改訂を続け, 様々な改善を続けた彼らのものだ. それでもなお私は喜びを隠せない. 自分が去った今も文章だけが生き続けている. 私は平凡なプログラマだから, 自分のコードが生き残れるとは思えない. 一方ボランティアで仕事の合間に書いた文章は読み継がれている. 価値のあるものが生き残るのなら, 私のなした価値は(コードではなく)文書にあったことにある. プログラマとしては悲しいけれど, 会
ChangeLog の作法 steps to phantasien t(2005-10-13)
ソースコードなどの変更履歴を ChangeLog と呼ぶ. オープンソースのソフトウェアで変更履歴を "ChangeLog" というファイルに書いたのが ChangeLog のおこりだと思う. 最近は Subversion などに登録された変更履歴も change log, あるいは commit log などと呼ぶ. 以下ではそれらを ChangeLog と総称する. 最近わけあってこの ChangeLog をどう書いたものかと考えている. コーディング規約には山ほど資料がある. コメントの書き方もよく議論される. しかし ChangeLog についての読み物は少い. GNU コーディング規約 は数少ないそうした文書である. この説明はよくかけている: ChangeLog は将来のメンテナがバグの原因を探るのに使うものだ. コメントに書くべきものはコメントに書け. 関数名を並べろ...
steps to phantasien t(2007-06-01) ChangeLog の作法 つづき
Subversion の開発者が ChangeLog について面白い記事を書いている. 記事の要旨はこうだ: ChangeLog (Subversion なので commit log) を書くのは面倒だよ, メーリングリストもあることだし書かなきゃダメ? ってよく訊かれる. 書きましょう. バグトラックもあるけど, 書きましょう.これらのツールは補完しあっている. メーリングリストはノイズが多いし, 変更を特定するには情報が足りない. バグトラックはバグの記録がメインだからコードの話を細々書くのは邪魔になる. 変更については ChangeLog に書くのがいい. プログラマは ChangeLog を読む. 記録を検索して, どの関数に何が起きたかを調べるものだ. この類の記録は ChangeLog を読まないとわからない. 逆に ChangeLog を書く時は, それを特定できるように省略
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
