探し物を見つける

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

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

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

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

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

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

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

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

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

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ファイルで減色変換。

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