マーフィーの法則

20世紀末に大流行したので記憶に新しいが、マーフィーの法則はプログラミングに関しては極めて役に立つ法則だと言える。
読み直してつくづくそう思う。
ソフトウェアは人間の思考を置き換えたものであるから、人間と同じ失敗をする訳だ。
曰く、

・失敗する可能性のあるものは失敗する

「ソフトウェアは必ず失敗するもの」と言い換えても良い。

・２つの出来事が予想される場合、望ましくない方が生じる
・おかしくなり始めると、次から次へとおかしくなる
・連続した何かがおかしくなる時は、最悪の過程をたどりながらおかしくなる

こでは、「何か条件に合わない時はプログラムは停止しなくてはならない」という基本を怠った、
あるいはミスのために、停止しなくてはならないはずのプログラムの誤動作が連鎖的に広がり、
最終的にシステムがダウンするなどの障害が発生する。
テストでも最後の最後にしかしない異常系のテストの工数が少ないか、あるいはしなかったために、
しばらく運用して初めて問題が発覚することを示唆している。

やはりアジャイル開発の反復型で、運用込みで開発して行くのが望ましいということか。

・危機に臨むと人は最悪の選択をする

これは客先でバグが見つかったので、そこだけ急いで修正したらデグレしたということである。
「バグはそこだけ直してはならない」と思わなくてはいけない。

・隠れた欠陥はかならず表面化する

そうですね。どんなバグも隠してはいけません(笑)

リラックス

プログラムのバグ予防に、ペアプロやアジャイルプログラミングなど色々な対策手法があるが、それ以上に大きな効果が「リラックス」にあると思う。

つまり、

• オフィスは静かである(電話機はない。休憩室や談話室がある)
• オフィスは清潔で、グリーンなどの観葉植物もある
• オフィスの自分や周りの机もきれいに整理整頓されている
• スタッフとのコミュニケーションも充分取れていて気心が知れている。
• 締め切りや客先などからのバグ対策に追われていない。
• 仕事のスケジュールは、ゆるくなくきつくなく適度な緊張が保たれている

などなど、気分的にリラックスしてプログラミングすると、当たり前のことかも知れないが、「間違わない」
しかし、この「リラックス」の状態は、上に説明しにくいし、何とも獲得しにくいものである。
恵まれた職場環境は、「なんだあいつらだけ」なんて陰口を叩かれることも少なくない。
しかし、納品後にバグがみつかり、客先に頭を下げて誤りまくって、深夜作業が続けなくてはならない労力があるならば、「リラックス」環境作成に使うほうが断然マシだと思うのだが。

アイディアとインスピレーション

アイディアを出すのは難しいと考えている人がいるが、アイディアを作りだすのは極めて簡単だ。
アイディアは、知識を組み合わせて、新しい知識を作り出す作業に他ならない。
だから、自分の知っていることをありったけ思い出して、組み合わせていけば、20や50のアイディアは簡単に作り出すことができる。
これをホワイトボードなどを使って、複数の他人と一緒にするのが、ブレインストーム会議である。
これは結構楽しい。
もし楽しくないのなら、やり方が間違っている。アイディアを出すのは、知的好奇心を高める楽しい作業である。

　ところで、アイディアとインスピレーションは、どこが違うのだろうか。
アイディアは知識の組合わせといったが、インスピレーションとて全く同じである。唯一違うのは、そのスピードである。
インスピレーションは、瞬時に産み出されたアイディアで、人間の潜在能力の一種で無意識を利用している。
しかも、ゆっくりと考え出されたアイディアよりも断然面白い。
インスピレーションは、まるで自分でないものが答えを与えてくれたので、神の啓示とか言ったりする。
神が人間を創って、この能力を与えてくれたのだから、合っているけど。考え出したのはあくまでも本人である。
この潜在能力は、誰にでもある。
例えば、料理屋を一瞥しただけで、美味しそうな料理が出てくるかを見極めたり、
初めて会った人の第一印象で、その人の性格や能力などを判断することが普通にできる
(しかも結構合っていたりする)。

インスピレーションを発揮するには、どうするかと言うと、難しく考えずに、自分に静かに聞くだけである。
後は、自分の潜在能力が答えを見つけ出してくれる。こういう能力をさえ否定しなければ良い。
難しく考えないことである。

最後に、デジタル全盛の時代になっても、本はアイディアの元である。本は、沢山読む方が良い。

仕事を速くする

　仕事を速くするには、できるだけ、仕事の内容を細かい単位に分割すると良い。
後10分しかないから、できないとか、明日やろうと考えるのではなく、
10分で終わる単位の仕事にしておけば、空いた時間も無駄にならない。
こうすれば自然と仕事が速くなる。
TOC理論というのがある。Total of Constraintsの略で、制約理論などとも言われている。
つまり、ボトルネックがあれば全体の動作がそれに制約されて遅くなるという意味である。

例えば、工場のラインで、１個生産するのに、A工程で1時間、B工程で2時間、C工程で30分かかるのなら、
普通なら、1個生産するのに3時間30分かかる訳だ。
もし、A工程、B工程、C工程を並列化したとしても、それでも2時間は必ずかかるということである。
当たり前。このB工程がボトルネックである。
もしB工程を細分化して45分時間でできるようにすると、今度はA工程の1時間がボトルネックとなる。

ボトルネックを解消するには、工程を可能な限り小さい単位にバラバラに分解して、
ボトルネックが小さくなるように工夫すれば生産性が向上するのである。
そして生産性があがれば、無駄な在庫が減り、生産性は上がり、工場はつぶれなくて済んだという話が、
「The Goal」(イスラエル人物理学者　エリヤフ・ゴールドラット博士著)という本に書いてある。

SE・プログラマの年齢限界

誰が言ったか、脳細胞は生まれてから減り続けて行く一方で、SEやプログラマは30歳が限界とか。
私が思うに30歳で限界なのではなく、30歳で勉強することを止めるから、限界が出現するのであって、
絶え間ぬ努力をすれば(才能なんかもあるだろうが)、年齢限界を突破するには難しくないだろうと思う。
そもそも、SEやプログラマがドロップアウトするタイミングは、年齢よりも、
新たな技術の波が来て、それを習得できない人が消えていっている感じである。
最初に触れた技術は、覚えることが出来ても、2つ目の新たな技術が習得できない人が多い。
それは何故か多くの人が、２つ目の新たな技術を、全く新たなものとして覚えようとしているために思える。
こうなると、記憶量は単純に2倍になる。
運よく、２つ目が習得できた、としても３つ目の時には脳がパンクして挫折するかも知れない。
これは、勉強や理解の仕方が間違っているように思う。
新たなことをそのまま覚えるのではなく、その技術のバックグラウンドをしっかり理解することが先である。
まずは、基礎技術を理解するのだ。
基礎技術は10年経ても、20年経ても変わらないものである。
応用技術は、基礎技術にプラスアルファして、作られるものである。
基礎技術を理解していると、応用技術の理解もできるようになる。
しかも、新たに覚えることは少ないので、習得が早くなるし、応用も利く。

それに、基礎技術といっても、難しい専門書を読み解く必要はない。
一番簡単な方法は、コンピュータの歴史を知ることである。

わずか数十年の革新的な技術変化も、元をたどれば１つの技術にまでさかのぼることができる。
それを理解して、もう一度歴史を読み進めていけば良い。

原因不明のバグの探し方

どこかでエラーが混入して、プログラムが正しく動かない、なんてことは良くある。
プログラムはかなりの量になるため、最初から順番に調べていくのは、かない骨が折れそうだ・・・。
がするしかない。という様な悲惨な状況になる場合もある。今日も徹夜か、ハァ～てな状態である。
この時には、最初から探してはいけない。
プログラムのモジュール単位に分けて、半分ずつテストをするのである。
そして、半分の内、動かない方のモジュールをさらに半分に分けてテスト。
この操作を繰り返して、特定のモジュールを探し出し、モジュール内のソースコードを半分ずつに分けてテストを繰り返す。
短時間で、原因のある場所にたどり着く。
この方法は、プログラミングではバイナリーツリー・サーチというごく一般的な方法である。
これを応用しない手はない。

もし、SubVersionなどでソースを管理していた場合には、もっと簡単。
元に戻したソースをビルドして、動くことを確認したのなら、WinMergeやDiffなどでフォルダ毎比較。
違っているソースを比較すれば、もっと早く原因が分かる。

経験上、原因不明のバグは、だいたい一晩で安易にで作ったコピペ・コードの書き直し間違えとかじゃないでしょうか(^^;)

変なプログラマーの作り方 #12に参加してみた

　WEBの世界は、知っているか、知らないかで、見えているものが違う世界。
より知っていることで、ハックの楽しみは倍増し、ゲームの世界感という箱庭ではなく、
一時として同じ姿をしていない現実仮想の庭で、怒濤のように情報が吐き出され、
流れて消えていく中に、人類の知性が<集結>される。
　自分の知性の拡張し、楽しさがフィードバックできれば、無限大の面白さがある。
なんて詩的に夢想しつつ、話を聞かせて頂きました。

若い聡明な皆さんと楽しく会話ができて楽しかったです。
「巨人の肩に乗っかる」金言。「マウスは膝の上で使う」確かに姿勢が楽(笑)

探し物を見つける

大切な書類が、見つからないなど、探し物をすることはある。
しかし、探せども探せども見つからない。時間だけが、ただただ失われていく。

こういう時には、１つの物だけを探しては行けない。大掃除を始めるのである。

片付けられていないものを、決まった位置に整理整頓していくと、たいていは、見つけることができる。
探し物は、予想していなかった様な物の下に埋まっていたり、そもそも勘違いで見つけられない場合もある。そういう場合でも、大掃除をしていると、捨てていない限りは必ず出てくる。
また、記憶が呼び覚まされて、突然思い出して、しまっている場所を思い出す場合もある。

いずれにせよ、１つだけの探し物をすることは、さらに散らかりかねない。

大掃除をすることは、探し物は見つかるし、整理整頓になるのだから一石二鳥である。

この方法は、探し物に限らず、プログラムのデバックなどにも応用できる。
つまり、やっかいなバグなどが見つかって、一生懸命探しても、その原因が見つからないということがある。同じことである。

１つのバグだけを探してはいけない。ソースコードを広くチェックしていくのである。
バグが発生している所と、全然関係ないところに原因があったりするのである。

プログラムの場合には、あえてエラーとなるコードを混ぜて、別の原因があった時の相互作用からバグの原因をあぶり出すということもする。

いずれにせよ、なんかハマリの状態になった時には、一段高いところに上がって全体を見渡すような作業をするのが良い。

UIについて考える

グラフィカル・ユーザ・インターフェイスは最早当たり前。
ボタンをクリックすれば、関数やらメソッドやらが呼び出されて処理が行われる。
しかし、これをきちんと実装しているアプリケーションはまだまだ少ない。特にWEBアプリはまだまだである。
何が言いたいかというと、ボタンというものは、クリックできる状態になってから、イネーブルになって欲しいのである。

つまり、ボタンが最初からイネーブルになっていて、クリックすると、何も反応がないか、エラーメッセージがダイアログで表示されたりする。
だったら、最初からクリックできない状態にしといてね、と思う。
電車賃を買う券売機と同じと考えれば良いのである。お金を入れれば、入れたお金の分だけ、ボタンに金額のランプがついていくのが常識だ。
もし、100円入れただけで、1000円の表示がついてしまって、1000円のボタンを押せば、「まだ100円しか入れていません」とエラーメッセージが出たら腹が立つはず。

JavaScriptでもちゃんとボタンをイネーブル、ディスエーブルにできるのだから(ブラウザ依存はあるが)、
処理を書いておいて欲しいと思うのだ。

ところで、ボタンの振る舞いは、どう書くか。
私の場合には、UpdateUI()とかUpdateButton()とかのメソッドに、画面に表示されているボタンが
イネーブル、ディスエーブルになる条件のif文がずらずら並んでいる。
何かUIの状態が変わる時にそのメソッドを盲目的に呼び出すことにしている。
実際は、計算に無駄が多いし、格好悪いとも思う。
(フラグを作ってボタンの状態を記憶させるのも良いけど、この場合には、フラグとボタンと二種類の記憶領域が存在することになり無駄な気がする)

もし、オブジェクト指向で書くなら、ボタンのクラスに振る舞いのメソッドを書かなくてはならない。
しかも、順繰りに呼び出すために、オブザーバー・パターンなどを使って書く必要があり、
イベントのどっかにフックしなくてはならない。
(VCなんかの場合には、PreTranslateMessage()とか。懐かしい)

これは、制御するボタンが100個もあるなら、きちんと実装する。いや、しなくてはいけない。
けど、数個から10個程度のボタンに、デザイン・パターンを適用するには、プログラムが大げさになりすぎる。
だから、オブジェクト指向でも何でないが、UpdateUI()にまとめて書いておけば、とりあえずは良いと思う。

プログラムの書き方

プログラムの書き方も今と昔では随分違う。
昔々は、C言語だったので、UNIXのシステムコールなどは使っている内にほとんど暗記していた。
オンラインマニュアル(英語)だったけど、これを読んで書いていれば良かったのである。

ところがWindowsになってから、事情が変わった。
Windowsのアプリケーションを開発するには、砂浜(Windows)に落ちている仁丹(API)を探すような作業が必要になった。
Win32API、MFC、ATL、OLEやActiveX、COM・・・、そもそもこんなに複雑にする必要があるのだろうか。

Windowsに関しては、OSとアプリケーションについて、マイクロソフトは一番の地位を保ちたかった。
正直にAPIを公開しようもんなら、マイクロソフトを出し抜く会社が出てくる可能性がある。
しかし、公開しないとサードパーティは現れないし、Windowsが普及しない。
このジレンマを解消するために考え出されたのが、砂浜に仁丹の撹乱作戦だったのだと思う。
.NETFRAMEWORKが出てきて、C#になってから少しはましになった感じがするが。

インターネットが普及してからは、プログラムはネットに落ちている物になった。
車輪の発明をしないように、まず、ぐぐる。
サンプルを見つけたら、それをコピペして、まず実行。
動けばテストプログラムを書き、テスト。その後本番プログラムへ組み込む。
さすがにサンプルそのまま、まる写しということはない。

しかも、WEBのプログラムになると、オープンソースを使う。そのまま使う。書かなくても良いのだ。
あるいは足りない部分だけをコピペして書き足す。

知っているか知らないかが、プログラムの生産性を決定している感じがする。

書かないという発想

先日した仕事では、フルカラー画像に指定色による減色の処理が必要だった。
ちょっと前なら正直にプログラムを書いていただろう。
しかし、予算が厳しいので別の方法を使った。

ImageMagickを使ったのだ。

ただ、テストで問題が見つかった。減色した画像ファイル中のRGB値が微妙にずれてしまうのだ。

原因は、ImageMagickで減色処理をするために、PHPのGDでgifファイルを作っていたのだが、このgifファイルのパレットにセットしたRGB値が、gifファイルとして出力すると何故か微妙にずれてしまうのだ。

対処方法は、GDでは減色の指定色で矩形を描画したPNGファイルを出力。
そのPNGファイルをImageMagickでgifファイルに変換。さらにそのgifファイルで減色変換。

これで、見事に指定色の画像ファイルが出来た。