«前の日記(2014-05-28) 最新 次の日記(2014-05-31)» 編集

ポケットを空にして。

1985|10|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|04|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|04|05|06|07|08|09|10|11|12|
2012|01|02|03|04|05|06|07|08|09|10|11|12|
2013|01|02|03|04|05|06|07|08|09|10|11|12|
2014|01|02|03|04|05|06|07|08|09|10|11|12|
2100|01|

「人の心に残るというのが大事」と言う話。

何か連絡がある場合はメールでどうぞ(過去の日記へのツッコミは基本的にみていません)
プレゼントは随時受け付けております :-) ここ最近のツッコミ/トラックバックリスト。


2014-05-29 [長年日記]

「コード・シンプリシティ――ソフトウェアの簡潔性を保つ事実、法則、真理」

先日、オライリーの電子書籍「コード・シンプリシティ――ソフトウェアの簡潔性を保つ事実、法則、真理」を買った。半額セールにつられて、という奴だ。
Bugzillaの人の話なのだけど、書いてあることは正直「まぁそうだよね」という妥当で普通な話が多い。

で、ざっと他の人の感想を見て回って、自分が一番腑に落ちたことが取り上げられてなかったのでメモとして。

「ユーザーがいる、という価値」という項目で以下のように述べられている。

つまり、多くの場合、価値が高まるようにソフトウェアをリリースしていかなければならない、ということだ。時間がかかりすぎる変更は、結果として価値がゼロになることもある。効果的な助けとなるリリースのタイミングを逃してしまうからだ。変更の欲求度を考慮する際には、リリースのスケジュールを検討することも大切だ。

例えば今更フロッピーディスクを100倍の効率で扱うためのプログラムが提供されたとしても正直意味がない。物事にはそのバリューを発揮するためのタイミングというものがあり、そのタイムフレームから遅れてプロダクトを提供してもダメ。(逆に、早すぎてもいけないけど。インターネットが提供されてない世界でウェブブラウザがあっても今ほどの価値は発揮されないし)。

このタイミングというのは実は非常に難しい。タイミングを逃さないためには、絡み合った物事をプライオリティを付けてスコープを限定して処理する必要がある。これを行わないと、物事の依存関係によりブロッキングが起こり、結果としてレイテンシの遅延が大きく生じ、結果としてウィンドウが開いている間に意図した機能を提供できないことになる。朝寝坊して電車に乗れないで目の前で発車される、みたいな。

無限のリソースを持っていると仮定していればすべてパラレルで実施すればいいじゃん、となるが当然現実は違うわけでリソースの把握とスコープの過程と順序付けを考えつつ作業を行わないと、プロダクトは出来上がらないし、できたとしてもold fashionedなものにならざるを得ない。

そういう意味で、Debianでstableが「古い」と揶揄されるのを、言葉通りに受け取ってはいけない。コードは現実世界の物理的なものとは違って、決して錆びついたりはしないからだ。古いのが問題なのではなく、環境の変化に合わせて利用したい機能について、タイミングを外して提供できていないことが問題なのだから。逆に言えば、この問題点を改善できれば価値を大きく上げることができる。