2008/12/28

たな

技術士の試験も受かったことだし、新しいテレビを買おうかと画策してはいるのだが、しかし、今の状態で何も考えずに買ったら間違いなく置く場所がない。仕方がないから、部屋の模様替えに精を出している。

模様替えといっても、単に配置を変えただけでは、テレビを設置するに足りる広大な場所を捻出することなどできない。根本的に面積を増やさなければ到底追いつかない。

そういうことで、収納を大量増加するために、それなりの額の金をつぎ込んでいくつかの棚を購入した。お陰でかなりの空間を確保することができ、どうにかテレビ用の空き地を作り出すことに成功した。

しかしそのせいでテレビ購入用の予算が減少してしまった。ここは余り高望みはしないで、費用対効果を最大化する方向で購入する機種を選定した方が良さそうだ。

2008/12/27

騰落

9月23日にここのblogに書いた下らないソフトを公開しておいてみた

まぁ、自分で使うために作っただけの代物だから大した物ではないし、そもそも、世の中一般で需要があるとも思えないのだが、とりあえずWebサイトをいつまでも更新しないでおくわけにも行かないから、ページの賑やかしぐらいの気分で公開することにした。

しかし、いくらページの賑やかしに過ぎないとはいっても、ソフトを一つ公開するのであれば、それなりのヘルプファイルも必要になるので、それはそれで労力がかかってはいるのだが。


話は全く変わるが、この間受験した技術士の一次試験の合格発表が行われた。とりあえず俺は合格していたようだ。

一次試験を通ったということは、次は二次試験である。問題集を立ち読みした限りでは、二次試験は非常に難しいもののように感じられる。というか、おそらく尋常でなく難易度が高いのではないだろうか。まぁ、やると決めたからにはやるしかない。

否定しようのない事実として、俺には学歴オプションがない。だからこそ、直接的に学歴を更新してやろうと努力してはいるのだが、しかしそれだけでは不足だ。是非とも技術士はものにしておきたいところだ。

この間受けた情報処理技術者試験のアプリケーションエンジニアは不合格であったから、これ以上は落とすわけにはいかない。試験自体はまだ先のことだが、できるだけ早いうちに対策を立てておくことにしよう。

2008/12/20

破壊

酒が入った状態でSolarisのパッチを当てるという愚行を犯し、何かを間違えて環境を壊してしまったようだ。「主筆」の開発に使用しているマシンが起動しなくなってしまった。しかも、このところバックアップを取るのをさぼっていたため、事と次第によると今までの作業結果が失われてしまうかも知れない。うまい具合に再インストールして、ホームディレクトリのデータが失われないようにしなければなるまい。

Solarisを再インストールするにしても、手元にあるメディアは8/07という奴でいくらかバージョンが古い。ここは多少面倒でも、最新の奴を落としてきてからインストールした方が良い。8/07と10/08の違いは、基本的にはデフォルトで適用されているパッチが違うというだけのはずなのだが、そもそもパッチの適用でしくった(多分)のだから、あえてリスクは犯さないようにした方が良い。

この不測の事態によりしばらくマシンが使えなくなった上に、このところやる気が萎えていたから、少しの間「主筆」の開発作業は休憩することにしよう(もっとも、このところずっと休憩しっぱなしだが)。

そういえば、Webサイトの方を6月から一度も更新していなかったから、たまにはそっちの方も気にかけてやらねばなるまい。

2008/12/15

受注

俺が今担当している仕事のトラブルが未だに収まっていないというにもかかわらず、別のお客からRFIとか言う物をもらってきたから提案書を書けといわれてしまった。これは変な特殊機器は使用しないことから、ハードウェアのバグに悩まされるという可能性は低いのだろうが、しかし、これと同じような種類のシステムをやってプロジェクトが破綻したことがあるということを考えると、身の毛もよだつ思いがする。また性懲りもなく、みんなで仲良く地獄巡りでもしようというのだろうか。

RFIとか言う奴は、受注活動の前半部分である。まず客がRFIという、どんなことをやりたいのかというようなことを書いた紙を作成して、それをベンダーに送りつける。そうするとベンダーは簡単な形の提案書のようなものを作って客に提示する。客はそれを読んで、システムのイメージを固めた上でRFPという紙を作成する。RFPにはRFIよりかは詳細な要求仕様が記述されなければならない。でもって、再びベンダーにその紙を送りつける。このとき、RFIを送るベンダーとRFPを送るベンダーとは、同じである場合もあるし異なる場合もある。RFPを受け取ったベンダーは正式な形で提案書を作成する。この提案書には詳細なシステム構成や具体的な金額が記述される。客はそれを読んでベンダーを決定するか、あるいはさらに競争入札を行い、最終的に発注するベンダーを決定する。

他にも詳細なやりとりがあるのかも知れないが、とりあえずベンダー側の末端の担当者からすると、上記のようなやりとりが行われているように見える。

当然だが提案書を作るというのは大変な作業である。提案書は提案書であって設計書ではないとはいえ、それでもRFIなりRFPなりに記述されている範囲内で、分かる限り詳細にシステムやプログラムの設計を行わなければならない。気分や感覚、抽象概念的な方向性みたいな話も書かれるのだが、それ以外に、具体的にはどうなのかということを書かなければならない。RFPに対する提案書の場合は、プログラムの1ステップ、ネジやケーブルの1本に至るまで詳細に見積もりを行い、最終的に何十億円という見積もりを作らなければならない。しかも、その為に使用できる期間は客の都合で勝手に決められてしまうため、やたらと忙しいことになる。

しかも何が哀しいかって、それだけ努力したって受注できなければ全く元も子もないし、例え受注したとしても、結局そこから詳細な設計作業をおこなうのだから、提案時に作った見積もりや設計は意味をなさないことになる。ただ、受注するためだけの無駄な作業。しかも、やたらと時間がない。辛いことこの上ない。

正直言って、俺には今の仕事は向いていないのではないかと思う。

2008/12/13

記録

COBOLでは、ファイルは常にレコードの形式になっていることを想定している。すなわち、それぞれ形式の違う複数の項目、例えば顧客番号とか名前とか、そういった項目が複数個集まってレコードという固定長のデータ形式を作り、それが複数個集まって一つのファイルになるという考え方をする。また、汎用機ではOSのレベルでそういう考え方をしているらしい。

その考え方はリレーショナル型データベースの関係表でも同じで、あらかじめ決められた複数の項目が集まってタプルを作り、そのタプルが複数個集まって関係表を形成するという考え方をする。ただし、DBの場合は数学的バックグラウンドがあることから、COBOLのファイルやExcelの表とは根本的に異なるものと見なされる。

こういった表形式は、人間にとって直感的に理解しやすい。それに、実務で使用される帳票は、多少複雑な部分があるとはいえ、基本的には全て表形式である。こういった形式の帳票が作られるようになったのがいつの頃からなのか、実務における情報のやりとりは全て帳票に依るというルールが制定されたのがいつの頃なのか、俺は詳しいことは知らない。しかし、よほど特殊な業界を除いては、世の中のほとんど全ての企業で表形式の帳票を作って商売を行っている事を考えると、おそらくこれは人間の、世界に対する根本的な認識の仕方に基づくものなのだろう。

だからだと思うが、コンピュータでは大抵のデータは固定長のレコード形式をしていることが多い。少なくとも、「お金になる」業務データはことごとくそういう形式になっていると言っていい。(なお、固定長のレコード形式がコンピュータにとって扱いやすいからそういう形式になっているというのは、多分間違いだろう。固定長のレコード形式を扱いやすいようにコンピュータが作られていると考えるべきである。)

大抵の業務データが固定長のレコード形式をしていると言うことは、トラブル時には大抵、固定長レコード形式のデータを解析してトラブルシュートを行うということを意味している。プログラムが直接ファイルをいじるような場合であれ、DBから抜いてきたデータを解析するような場合であれ、大抵SEが目にするのは固定長レコード形式のファイルである。だから、このファイルのフォーマットを間違えると、トラブル対応時に酷い目に遭うことがある。

ということで、前置きが長くなったが、プログラムで取り扱うファイルを設計する上で考慮するべき事項について、俺なりにまとめておいてみようと思う。

1.固定長のレコード形式にする。

そもそも、可変長はありえない。可変長にしてしまったら、一体どうやってデータを分析しろと言うのか。もちろん、ビューアを作れば見て見れないことも無いはずである。しかし、トラブル時にブチ切れてるお客や動かないマシン、役に立たない上司を前にして解析用のプログラムを作れと言うのか。そもそも、いつ何時でも開発用ソフトが使える状態にあるとは限らない。そうなると、メモ帳(一本指打法を墨守するお客のマシンには、当然の事ながらまともなテキストエディタなんて入っているはずもない)でファイルを開いて、指折り数えて改行を入れていくと言うことをしなければならなくなる。

そんなまどろっこしい事をしている間にも騒ぎは大きくなり、じきに灰皿の灰やコップの水が宙を飛び交うようになる。というか、頭の上に降り注ぐようになる。そんな状況に陥ってしまったら、物理的にクビが切られる前にトンズラするしかない。まぁ、そういう背中にナイフを突きつけられるような状況に陥ることはなかなか無いが、それでも未然に防止できるならそれに越したことはない。

また、各項目が可変長のみならず、ファイル中のレコード形式が一定で無かったりすると、おかしなデータを見つけるのに時間がかかったり、あるいは見つけられなかったりすることがある。おかしなデータというものは、周囲のデータと比べて明らかに入っている値が違うとか、英数字しか入らないところに漢字があるとか、データのあるべき位置が空白になってるとか、連番になっているものが途中で乱れているとか、そういったことがきっかけで見つかることが多い。だから、そういう見分け方をするためには是非ともファイル中のレコード形式は一定でなければならないのだ。そうでなければ見つかるものも見つからなくなる。

2.テキスト形式にする

裸のWindows XPにMS-Officeと大量のセキュリティソフトを入れただけの、インターネットに接続できないPCを思い浮かべてもらいたい。でもって時刻は深夜2時。深夜3時までにマシンから抜いてきた大量のデータを解析して、報告書をまとめてお客に報告しなければならないとする。

そういった状況下で、もし与えられたデータが全部バイナリだったとしたらどうだろうか。

こういう会話がなされることが推定される。

俺 「このデータを私のPCにコピーしてよろしいでしょうか? 私が普段使っているPCであれば、このデータを解析するのに必要なソフトが入っていますので・・・」
客 「はぁ? 本番のデータを開発用のPCに持って行っていい訳がないだろうが。馬鹿野郎。ここでやれ。それとも何か、まさか逃げる訳じゃないだろうな? あぁ?」
俺 「いえ、そういうわけでは無いのですが・・・その・・・このPCには、このデータを見るのに必要なソフトが無いので・・・。では、データを持って行けないのなら、私のPCから必要なソフトを持ってきてもよろしいでしょうか? それであれば・・・」
客 「はぁ? 馬鹿かテメェは? 勝手に変なソフトを入れて良いいいわけねぇだろうが。とにかく、ガタガタ言わずに今すぐ仕事しろ。アホが」

こういう不毛な問答をしている間にも時間は刻一刻と経過していき、一方、俺はどうすることもできずに、ただただ針のムシロに座り続けるしかない。これでは、換えの胃袋が何枚あったっても足りないし、いかに鋼鉄の神経でもたちどころにすり切れてしまう。

だから、とにかくデータはテキスト形式とするべきである。それも、できればShift-JISにしておくべきである。そうすれば、少なくとも全く手も足も出ないという状況は避けられるはずである。固定長のテキストデータであれば、Excelで開いてカラムごとに分割することができ、そうすれば少なくともなにがしかの結果をまとめることができる。しかし、中にバイナリのデータが含まれているとそういうことができなくなる。

しかし、時にはシステム的にバイナリのデータを取り扱わざるを得ない場合もあるだろう。そういった場合は、バイナリの部分だけを別の場所(ファイルを分けるか、別のテーブルに入れるか)した方が良い。DBから抜いてくるのであれば、バイナリの部分は避けてテキストの部分だけを抽出するようにした方が良い。そうでないと酷い目に遭うから。

あと、データ中にはできれば日本語は含まれていない方が良い。どうしても日本語のデータが入らざるを得ないのであれば、Shift-JISにするべきである。EUCは最悪である。言うまでもないことだが、いつ何時でもエンコードを自在に変換できるとは限らないからだ。

また、日本語が含まれている場合「レコードを固定長にする」というのが多義的となり、事態が複雑化する。すなわち、固定長というのを文字数で見て固定とするのか、バイト数で見て固定とするのかが異なってしまうのだ。Excelで固定長のデータをカラムに分ける場合、常にデータはShift-JISと見なされ、かつ、バイト単位で固定であるものとしてデータが区切られることになる。また、メモ帳などのエディタで開く場合も、バイト単位で固定長としておけばカラムがそろって見やすくなる。だから、データは必ずバイト単位で固定長として処理した方が良い。

もっとも、この文字数で固定長とするかバイト数で固定長とするのかはシステム全体の設計に関わる問題であるため、なかなか自由に選べるものではないのだが。例えばシステム内部で文字をUTF-16か何かで取り扱う場合は、当然の事ながら文字数で固定とすることとなり、それ以外に選択肢はなくなる。だからその場合は、メモ帳とExcelだけで戦う道は閉ざされる事となる。

3.レコードの末尾には改行コードを入れておく

今までの議論からも明らかなとおり、レコードの末尾に改行コードが入っていないと見づらい。レコード長がバイト単位で固定になっている場合は、エディタで開いて決まったところで改行を入れればいいのでそれ程大変ではないのだが、それでもデータ量が多い場合にはどうしようもなくなる。あらかじめ出力するデータに改行が入っていれば、いざというときに助かる。

挿入する改行コードはCR+LFにしておくと良い。どうせWindowsのPC上でファイルを開いて見るのだから。

なお、時にUNIXオタクの奴がデータをWindows上で解析することに対してケチを付ける事があるが、それはナンセンスである。大学の研究室での常識とやらをビジネスの現場に持ち込まれても困る。一般に、企業で使用されているコンピュータは、サーバはLinuxや商用UNIXであることが多いが、クライアントPCはことごとくWindowsである。業種によってはMacという可能性もあるが、少なくともクライアントPCがUnix系のOSである可能性は非常に低い。でもって、サーバマシンにはディスプレイやキーボードは接続されておらず、それどころか物理的に遠く離れたところに存在し、まともなディスプレイやキーボードが接続されているマシンは、クライアントのWindowsPCのみである。

そういう状況下で、データをシェルスクリプトで分析するだの、viで編集するだの言わないでもらいたい。よしんば、その方が作業時間が短くて済むのならそれでもいいが、しかし、最終的に分析した結果は体裁の整った表なりグラフなりにまとめて、報告書を書いて、それを印刷してお客の所に持って行かなければならないのだ。最後は結局ワープロソフト(一太郎でも何でも良いが少なくともTexではない)で清書するのだから、最初からPC上で仕事をしろ。というか、大概「Excelなんてwww」と言っている奴に限って、Excelの使い方を知らないものだ。

4.データ中にカンマやダブルクォーテーションを入れない

時に、データを固定長のレコード形式ではなくCSV形式で出力することもある。そうすると、文字数で固定だのバイト数で固定だのといった問題や、改行の問題などを回避できる可能性がある。また、Excel等の表計算ソフトに取り込む際に、桁数をいちいち指定する必要が無くなり、作業効率がよくなる。

だがその時、たまに罠に嵌められる事がある。それは、データ中にカンマやダブルクォーテーションといった、CSVファイルで使用される制御用の文字がデータに含まれている場合だ。そういう値が入っていると、CSVファイルを正しく開くことができなくなる。

システムの仕様上、そういった値も持たなければならないというのなら致し方がないのだが、しかし、あえて深い理由もなくカンマなどの文字を使うというのであれば、少し考え直すべきである。余り痛みを伴わずに別の文字で代替できるのなら、替えてみるという選択肢もあるのではないかと思う。

なお、CSVファイルを普通に表計算ソフトで開くと、数字や日付などの値を勝手に解釈してそれぞれの形式に変換して取り込んでしまうという、非常にお節介きわまりない機能が動いてしまう。一般に、桁がずれてるとか変な文字が入っているとか、そういった問題はExcelに変な加工をされると分からなくなってしまうため、データに余計な解釈を加えずに文字列のまま取り込むようにした方が良い。だから、CSVファイルであっても明示的にデータのインポートを行わなければならない。それを知らないと、トラブルがいつまでも解決しないという罠に嵌められる可能性がある。

5.同種の項目であれば桁数を揃える

たまに、金額を表す項目であるにもかかわらず、ある場所では6桁、別の場所では8桁、消費税は5けたなどと、桁数がバラバラになっている事がある。だが、そういう細かい違いはトラブルの元である。システムそのものを開発するときにもバグの温床となるし、トラブル対応時のテンパッているときなら尚のことである。似たような項目は同じ編集方法とするべきである。

同様に、データの桁数が足りない時に、余ったところに入れるパディングの値も、システム全体で統一するべきである。ある項目ではNULLで埋めて、別の項目では全角空白で埋めるなどということをやっていると、いつかは足下をすくわれることになる。できれば、数字/半角文字列/全角文字列で変えるのもやめた方が良い。左詰で余ったところには半角空白をいれる、ということで統一した方が良い。当然のことながら、バイト数を持たせて可変長にする、等というのは絶対にあり得ない。



以上の対策は、今具体的に俺が困っていることを羅列したものであって、全てを網羅しているなどと主張するものではないし、また、必ずしも正しいとも限らないと思う。だが、変な実装のシステムの保守をやらされて苦しんだ上で理解したことだから、それなりの価値はあるのではないかと思う。とりあえず、今度新規にシステムを構築する場合には、以上のような対策を取り込むようにしてみたいと思う。

2008/11/29

開通

引っ越してからようやくインターネットへの接続が開通した。俺が構築している室内のネットワークは、ネットワークアドレスとして192.168.0.0を使用していたのだが、プロバイダからDHCPで割り当てられるIPアドレスも192.168.0.0だったために、全ての機器のIPアドレスを変更しなければならなくなってしまった。面倒だった。

というか、本当であればグローバルなIPアドレスが欲しいのだが、社員寮である都合上そういうわがままは通りそうにない。まぁ、今しばらくはグローバルIPアドレスをもらったところでやりたいことがあるわけでもなし。まぁよしとしよう。

この一ヶ月インターネットにつながっていなかったお陰で、いろいろと更新しなければならないものがたまっていた。このblogそうだが、それ以外にもWindowsやSolarisのパッチ・ウイルス対策ソフトのパターンファイル(特にこれが一番うるさい)、その他ソフトのアップデートなどだ。とりあえずこの土日は、各種の更新処理を片付けることにしよう。

資格取得試験の嵐は10月に収まり、インターネットにもつながらなかった11月の間は、とりあえず「主筆」の開発作業を進めていた。6月の開発を中断する前ぐらいから、セキュリティを強化するような対応(シンボリックリンクファイルを不用意に書き換えないようにする、等)に取り組んでいたが、それも一通り片付け、現在は内部ロジックの見直しを行っている。

具体的には、文字列の更新時における処理効率の向上や、ファイル名等の一部の文字列をマルチバイト文字列で処理している箇所を、ワイドバイト文字列に変更する等と言ったことを行っている。別に、こんな事をやったからと言って直接的にユーザ(俺の事だ)にとってメリットがあるというわけではないのだが、しかし、プログラムの寿命を延ばすという意味においては、必ずしも無意味なことではないと考えている。

また、純粋な意味での機能向上としては、構文強調表示処理のMakefileとINIファイルへの対応を実装した。今までずっとMakefileとINIファイルを処理するロジックを作ったまま「主筆」の本体に取り込まないで放置してあったのだが、今回ようやく取り込んだというわけだ。俺としては、あとはリソースファイルを頻繁に編集することがあるので、せめてそれぐらいは対応できるようにしておきたいと考えている。まぁ、亜文それは大分先の話になるのだろうが。

行折り返しの機能は未だに手を付けられていない。これを実現するのは明らかに大変なので、先延ばしにしているのである。まぁ、今やっている内部ロジックの見直しが終わったら考える事にしよう。

2008/10/18

進路

引っ越しだの試験だので忙しいのにもかかわらず、このところ本業の方が忙しくなってきて辛い。今までやってきた開発案件が、紆余曲折の末にようやく納品までこぎ着けたと思ったら、今度は客のエロい人にケチを付けられ、またしても振り出しに戻りそうな予感である。もうやだ。

情報処理技術者試験を受けると前々から言ってあるはずなのだが、一体どうするつもりなのだろうか。別に、なにがしかのサポートをしてくれと言っているわけでもないし、受験料だってもとより自腹で出しているのではあるが、それでもせめて試験日に試験を受けに行かせてくれる位の配慮があったっていいのではないかと思う。俺は何か間違ったことを言っているだろうか。

所詮、人身売買で利益を獲得する会社なのだから、商品自身が商品価値を向上する取り組みぐらい認めてもらいたいものだ。


大学の方は卒業が確定したから、次は大学院である。しかし、どこに行くのが良いだろうか。

基本的に、修士だからといって何か意味があるかといえば、何もないように思われる。つまり、最低ラインで博士まではやらなければならないと考えている。であれば、博士課程のある所に行かなければならない。

また、俺個人の希望として、できれば理系の、欲を言えば情報系の学科にしたいと考えている。もしそれが不可能なら、経営か会計である。いずれにせよ、学際的な奴、平たく言えば何の専門なのかが理解できないような奴は避けたいと思う。そうすると、進むべき道はかなり限られてくる。

その上、生きて行くためには仕事を続けなければならない都合上、いけるところは極端に限られてくる。できれば通信制が良いのだが、どうしても選択肢がないのなら、土日や夜間に開講しているとか言うものでも良いのではないかと考えている。

どこに行くべきか、というのは非常に重大な問題である。いけるか否かについては後で考えればいいものとして、とにかく進学先を決定しなければ話にならない。いろいろと条件を勘案して、後悔の無いようにしなければなるまい。

2008/10/15

経過

13日の月曜日に技術士の一次試験を受けてきた。受かったか落ちたか何とも判断がつかないが、とりあえず受かったものと仮定して二次試験に向けて行動を開始しようと思う。

今日、通信制の大学の方から、卒業手続きに関する書類が来ていた。とりあえず、諸々の書類を書いて明日ぐらいに出してしまおうと思う。

大学はこれで確実に卒業が決定したのだから、大学院への進学に向けた手続きを進めなければならなくなってきた。今までさぼってきていたが、そろそろ行動を開始しようと思う。

聞いた話によれば、大学院の場合は必ずしも常に入学できるとも限らないらしい。書類選考その他諸々の評価が行われる様だが、その場合、何らかの資格などがあると有利に評価されるらしい。

そういった意味でも、技術士には是非合格しておきたいのだが、しかしこれは日程的に間に合わないだろう。間に合うのは来週受ける情報処理技術者試験の方だ。アプリケーションエンジニアを受ける予定だ。これがそれだけの効果を持つのかよく分からないが、それでもなにがしかの効果がありそうなんだったら、確実にモノにしておきたいところだ。

いずれにせよ今月はイベントが多い。半ばを過ぎた時点ではあるが、すでにして疲れてきた。

2008/10/04

期間

この10月は個人的なイベントが多い。勢いで申し込んでしまった技術士の試験は13日に試験が行われる。19日には情報処理技術者試験が行われる。これも金を払ってしまっているから、今回はやる気がないとはいえ、無視するわけにはいかない。月末には引っ越さなければならないし、ほぼ同時期に、今やっている開発作業が一区切りついて本番リリースされることになる。

本業の方は、もはやなるようにしかならないから、もうどうでもいのだが、しかし、2つの検定試験は自力で努力しなければどうにもならない。

引っ越しに向けて、いろいろと不要物を捨て当面使いそうにないものを段ボールの中にしまったり、調達してきた緩衝剤で包んだりと、これはこれで何かと忙しい。しかし、引っ越しまでにはいくらか時間があることを考えると、実は受験勉強するのが嫌で、それを先延ばしにするための口実として引っ越しの片づけを使っているだけであると言える。それに気がつきつつも、やはり勉強などと言うものはやりたくてやる物ではないので、なかなか手が着かなかったりする。やらなければならないことは判っているのだが。

通常、やりたくないことをやるためには、やらざるを得ない状況に自分を追い込む必要がある。例えば、本当であれば仕事なんてやりたくはないのだが、しかし、会社に出社してしまえば仕事をせざるを得なくなるから、必然的に働くこととなる。勉強もそれと同じで、やるしかない状況となればやるのだが、それ以外にすることがあり、かつ、そちらの方が心理的に楽なのであれば、勉強など一生やることはない。

例えば、電車に乗っているときは暇で他にすることがないから、興味のない物理学の本であったとしても読むことができる。しかし、自宅に帰ってくれば自由に使えるPCがあり、いろいろとやりたいことが他にあり、かつ、自分を監視する面倒な人間がいないとなれば、誰が勉強などするだろうか。当然、つまらない本など読む気にはなれないし、公式を丸暗記する作業など、到底やる気にはなれない。

そういう状況下で、俺は一体どうやって勉強すればいいのだろうか。技術士の試験まで後一週間しかない。少なくとも、ネコの写真をアップロードしている暇はないはずである。

2008/09/24

ネコ

実家で猫を飼っている。とりあえず、猫の写真なら権利関係やプライバシーなど気にすることなくアップロードできそうだから、公開しておいてみる。



胴体をひねった状態で寝ている。



半分ぐらいひねっている。



ひねらずに寝ている。

この猫の名前は「トラ」という。名前を決めるとき、俺は「ゴールデンたま」が良いのではないかと強く主張したのだが、誰にも聞き入れられなかった。今でも「ゴールデンたま」にするべきだったと本気で考えている。

ついでに言うと、この写真を撮ったとき、この猫は必ずしもリラックスして寝ているわけでは無かったようだ。写真では判らないが、微妙に薄目を開け俺の様子を窺っていた。おそらく、いじられて気分を害していたのだろうと思われる。

三番目の写真が比較的判りやすいと思うのだが、この猫は下腹部の皮が余ってたるんでいる。模式図で書くとこんな感じである。



別にとりわけ太っているというわけではないようなのだが、皮だけが余っている。以前飼っていた猫はそんなことは無かったから、おそらく、この猫特有の事象なのだろう。なお、本人というか本猫には、皮の弛みを気にするだけの知能は無いようだ。

2008/09/23

更新

技術士の一次試験まであと一ヶ月を切ったところで、お勉強をしなければならないとは思いつつも、どうにもやる気が出ない。気がつけば、全然関係ない下らないソフトの開発に熱を上げていたりもする。

http://www.syuhitu.orgのwebページは、ほとんど手作業で作成している。HTMLエディタとしてVisual Studioを買ったときについてきた評価版のFrontPageを使ってはいるが、本格的にWebサイト全体の管理を行う為には使用してはいない。その都合上、多くのページで共通して使っている記述、例えば、画面の上部や左側に表示しているリンクの固まりなどを更新するのが面倒くさい。

FrontPageをもっとちゃんと使うか、あるいは何らかのWebサイト作成ソフトを買ってくるかすればいいのだろうが、そえは何か負けたような気がしてむかつく。そもそも、そういったソフトが生成するHTMLのコードは、基本的に信用ならない。ソフトが勝手に変な著作権表示を入れてみたり、表示されない無用なコードを大量に生成したり、特定のブラウザに強く依存するようなコードを吐いたり、最悪なのがJavaScriptが無ければまともに表示することすらできないとか、そういった諸々が死ぬほど気に入らない。

WebサイトのHTML文の美しさなど、別にさして気にしているわけではないのだが、それでも勝手に変な自己主張されたり、無駄な記述が多かったりJavaScriptが必要だったりするのだけは避けたい。ということで、基本的には手作業で作成するという現在の運用スタイルで落ち着いている。

しかしそうすると、困ったことが起きる。

現在のレイアウトでは、画面の左側に各ページへのインデックスを表示している。そのため、ページの追加・削除を行うたびに、このインデックスも更新しなければならない。しかし、インデックスは全てのページに付けられている。すなわち、インデックスを持っている全てのページを更新しなければならないと言うことになる。

技術は何であれ、とにかくWebサーバ側に何らかのスクリプトを埋め込むことができるのであれば、こういった共通部分の自動生成程度であればすぐにでもできる。難しいことは何もない。しかし、借りているサーバの仕様上それはできない。また、それができるサーバに移るという手もあるが、それも何か面倒だ。

ならば、クライアント側で共通部分の自動生成、ないしCOBOLのCOPY句かCのinclude文の様なことをやろうとした場合、できる方策は二つしかない。すなわち、JavaScriptを使うか、フレームを使うか、である。

以前(結構昔)はフレームを使っていた時期もある。だが、やはり何かと不都合が多い。今更フレームに対応していないブラウザがあるとか言うつもりもないが、しかし、それ以外にもユーザの操作によってはフレームのネストがどんどん深くなってしまったり、フレーム内のページを「新しいウインドウで開く」で開かれたり、あるいは検索エンジンからフレーム内のページに直接飛び込まれてきたりという問題がある。今更あげつらうまでもない、フレームを使うことにまつわる無数の問題に対して、俺はいちいち対処できる自信はない。

仕方がないので最近は、一部のページにおいてはJavaScriptでインデックスを生成するようにしていた。だがやはり、嫌いなものは嫌いなのだ。なぜ嫌いかと言われても、答えられないが、とにかく嫌いなのだ。

そういうことで、Webページの共通部分を自動的に更新するツールを開発することにした。原理は単純で、事前に埋め込んでおいたコメントを頼りに、文字列を書き換えるだけである。難しいことは何もない。

やることは簡単なので、一日二日あればできるだろうと思って、気分転換に作り始めたのは良いのだが、それが意外と工数が懸かり、結局数日分の休日を使い切ってしまった。

確かに、テキストを更新する部分の処理は極僅かなのだが、それ以外のUIを処理する部分の開発工数がかなり嵩んでしまった。UIなど別にこだわらなければそれで済むのだが、やはり今後まともに使っていることを考えた場合、それなりの機能は必要だろうと思い、そこそこ作り込んだら、結構大変な事になってしまった。

画面のイメージを示すと、こんな感じである。



まぁ、大した物ではない。

もっとも、こんな物を自分で作り込むのは明らかに間違いで、本来であればまともなWebサイト作成ソフトを落としてくるか、あるいは買ってくるかするべきである。しかし、俺は変態だから、自分で作り込むことにした。はっきり言って、素人にはお勧めできない。

何はともあれ物は作ったのだから、早速それを使ってWebページを更新しておいた。更新するべき位置を示すコメントは、事前に自力で埋め込まなければならないのだが、そればかりは仕方がない。そこは自動化できなかったのだから、力業で片付けた。でもって、全てのHTMLファイルを更新して、昨夜アップロードしておいた。

それにより、いままでJavaScriptを無効化していると、インデックスが表示されない部分があったのだが、それがちゃんと表示されるようになった。当然だが。また、ページの更新が自動化されたので、今後の更新作業はかなり楽になるはずである。多分。

しかし、こんな物を開発するために、貴重な時間を無駄に多く使ってしまった。このままでは確実に試験に落ちるような気がしてならない。どうにかならないものだろうか。

2008/08/21

車輪

自転車のタイヤがパンクした。このイベントは、確率的に時折発生するのだが、その原因はいまいちよくわからない。明らかに、画鋲や釘などの鋭利なものを踏みつけたのであれば仕方ないような気もするのだが、そういう覚えもないのに、気がつくと空気が抜けていたりする。なぜなのだろうか?

とりあえず、原因の心当たりを探っていたところで、今そこにある危機への対応にはならないため、修理することを考える。だが、まともに自転車に持って行くと1000円取られる上に、多少時間がかかる。そもそも持って行くのが面倒だ。そういうことで、100円ショップで売っていたパンク修理キットを使って自分で修理することにした。

パンク修理キットのパッケージの裏には、懇切丁寧に修理の仕方が記載されている。だからそれを見ながら、書かれている通りに赤いプラスチック製のヘラでタイヤの周囲を突き回すと、タイヤのゴムがはずれる。

ゴムがはずれたら、中から柔らかいゴムでできたチューブを引っ張り出し、水を張った洗面器に浸しながら穴が開いている箇所がないか探してみる。だが、この時点では漏出箇所を発見することができなかった。

とりあえず、穴が開いている箇所が無さそうであることと、明らかに空気を入れる口金のところに埋め込まれているバルブについている虫ゴム(と言うらしい)が痛んでいることから、多分これが原因なんだろうと当たりをつけて、適当にバルブを交換してみる。これも100円ショップで売っていた。

バルブ交換後に空気を入れ得しばらく放置しておき、改めて確認してみると、再び空気が抜けていた。どうやら、他に原因があるか、さもなくば交換したバルブが間違っていたらしい。

ということで仕方がない。今一度タイヤをばらして、再び漏出箇所を探してみる。先ほどは、あまりチューブに空気をたくさん入れないで水に浸してみていたが、もしかしたらそれが悪かったのかもしれない。だから今度は、明らかにチューブが太るぐらいに空気を入れた状態で穴探しを行ってみた。

すると今度は見つかった。明らかに空気が漏れ出てきている。よく見れば、小さな穴が開いている。何で突如こんな変な穴が開くのだろうか? 原因がわからない。

理由はどうあれ、穴が開いていて空気が漏れているのだから、その穴を塞いでみる。パンク修理キットのパッケージの裏には、ちゃんと穴の塞ぎ方が書いてあるので、それを見ながら接着剤で丸いゴムを穴にある位置に貼り付ける。

こんな接着剤なんかで大丈夫なんだろうかと思いつつも、とりあえず穴が塞がって空気が漏れなくなったので、多分これでいいのだろう。念のため、他にも空気が漏れていると箇所がないか、口金のところから空気が漏れていないか確認してみる。

問題が無さそうなので、はらわたを押し込んでタイヤをそれっぽい形に戻して、空気を入れてみる。これで直ったかどうかは、しばらく様子を見てみなければわからない。

結果はどうあれ、とりあえずこれで修理のやり方は判ったわけだから、今後はタイヤがパンクしても、その都度自転車屋に持って行く必要はなくなるだろう。だが、相変わらず真の原因がなんなのかは判らないままである。

どうにも忌々しいこの事象。どうにかならないものだろうか。

2008/08/16

低脳

いろいろあって、技術士とかいうやつを受けることになったのだが、どうにも難しい様だ。とりあえず、受験料1万1千円は払ってしまったのだから、何とかして受かりたいとは思ってはいるのだが、ここままでは確実に落ちるだろう。

しかし、そうはいってもただ落ちるに任せていても仕方がないので、とりあえずいろいろと本を買ってきて勉強してはいる。数学や物理など、俺みたいな低脳には余りにも壁が厚いのだが、にもかかわらず無駄な努力を続けている。

しかしそのお陰で、大学の試験に落ちた。二科目ほど、何の準備も心構えもなく受験したら、ものの見事に落ちた。しかも、そのうち一つは4単位の科目だった。

このせいで9月の卒業が大分怪しくなってきた。まだ必ずしも不可能と言うところまで入っていないが、しかし、全く余裕が無くなった。8月に行われた試験(3科目)が全て合格しており、かつ、8月後半にあるスクーリングの授業を受けにいくかもしくは9月の商業簿記の試験に受からなければ、半年間の留年が確定する。

高校の頃簿記の授業は死ぬほどやらされたから、多分余裕だろうと思って取ったのだが、これがスバラシク頭の中に残っておらず、全く手が出ない。試験を受けて合格するのは、それ相当の難行苦行を強いられることになるのが予測されるため、できれば8月末の授業を受けに行く方で単位を取るようにしたいものだ。これであれば、例え何も判っていなかったとしても単位だけは取ることができるのだから。

その為に、万策を尽くして夏休みの日程を調整、どうにか授業を受けに行ける目処が立った。あとは休みの間に大きなトラブルが起きて呼び出しを喰らわなければ、かつ、俺の単位数の計算に間違いがなければ、9月には卒業できるようになるはずだ。

大学を片付けたら大学院を始末したいと考えているのだが、現在のスケジュールで行くと、例え最速の場合であったとしても、10月からの大学院への進学は無理そうだ。となると、どうあっても来年の4月からということになり、半年ほど時間が空いてしまうことになる。著しく時間がもったいないが、まぁ致し方ないだろう。その間、技術士の一次試験と情報処理技術者試験のアプリケーションエンジニア試験の受験勉強にでも、せいぜい精を出すことにでもしよう。

2008/07/19

書類

実のところをいうと俺は、今年の一月ぐらいに酷い目に遭わされたような、ある程度の規模がある「まともな」システムの開発に携わることは余りない。

俺がやっている仕事の大部分は、ExcelやVBScriptやバッチファイルなどでつくられる下らないツールの開発ばかりである。

別に、大規模プロジェクトの地獄が気持ちいいとか、昔はよかったと懐かしむ年寄りの感慨ではないのだが、しかし、こういった細かいものを作り続けていると気分が萎えてくる。まぁ、気分が萎えようがやる気がなかろうが、生きて行くためには仕事をしなければならないのだから、文句を言うつもりはないのだが。

しかし時には文句の一つも言ってやりたくなることがある。それは、無意味に仕様書や設計書の内容が細かく問われるということだ。

これは俺のいる所だけの事かも知れないのだが、不思議なことに、開発規模が大きくなるに従い設計書の品質が低下するという傾向がある。逆に、開発規模が小さくなるにつれて、設計書やマニュアル・手順書の類の品質、というか物量を求められるようになる。

つまり、高々数ステップで済むようなものの場合、ステップ当たりの書き物の量は信じられないほどの規模に達するということだ。前にあった例では、20行のバッチファイルに対して、70ページ以上のドキュメントを書かせられたことがある。

こうなってくると、完全にドキュメントを書く意味というものが無くなってくるはずである。ドキュメントは、将来自分以外の誰かがプログラムを使ったり、あるいは変更したりする場合に備えて、その誰かが目的を達することができるようにプログラムについて説明するためのもののはずである。だが、プログラムに対してドキュメントの量が多すぎると、逆にドキュメントの解読や維持保守に時間がかかるようになり、ドキュメントがドキュメントとしての役を果たさなくなる。

つまり、俺が書いたものは完全に意味がない、ただのゴミに過ぎないということだ。その上、あのお客は設計書をちゃんと取っておかないという悪い癖を持っている。後から必要になったから設計書を払い出してくれといっても、まともに出てきた試しはほとんど無い。細かいツール類のものに至っては、まず間違いなく消失している。すなわち、俺の仕事は、それこそ全く無意味だということになる。

何でこんな事になるのだろうか? どうして、一回動かされたきりで、その後二度と動くことのない書き捨てのツールに対して、膨大な量のゴミ資料をねつ造しなければならないのだろうか?

俺なりに少し、理由を考えてみた。

まず第一の理由は、設計書の使われ方に由来するものだ。実をいえば、設計書やマニュアル・取扱説明書などといった物が一番役に立つのは、将来プログラムを保守する時などではない。トラブルが発生したときに、開発元に責任をなすりつける時の口実として利用されるのだ。設計書とは、そもそもその為に作成されるものであると言っていい。

つまり、「設計書にこう書いてあるのに、その通りになっていないじゃないか。だからおまえが悪い。おまえの金で今すぐ直せ」と主張するために使われるのだ。

だから、お客の担当者の立場に立って考えると、設計書には思いつく限り何でもできますと書かせた方が、自己保身につながるのだ。どんなに汚いデータを投入しても行間を読んで正しく補正します、超能力でユーザの操作ミスを検知しトラブルを未然に防止します、大統領を暗殺することができます、死者蘇生ができます、魔王を降臨させることができます、等といったことを、とにかく手当たり次第に書かせるのである。そうすれば、トラブルが発生したときにも、「俺は悪くない。悪いのはあいつだ」と、言うことができるようになるのだ。

つまり、ドキュメントの量が増えるのは担当者の自己保身という圧力があるためであると言える。

また、開発規模が小さいほどドキュメントの量が増えるのは、関わる担当者の数が少なくなるからであると思われる。つまり、規模が大きいと担当者の数が増えるために、なにかトラブルが発生しても、「俺は悪くない」と主張しやすくなるためであると思われる。また、大規模な奴が障害を起こした場合は、設計書の中身が問われることなく、問答無用で開発元が全面的に悪いと言われる傾向がある。その意味からしても、開発規模が大きくなるにつれて、設計書にむやみやたらに何でもできますと書かせる圧力が少なくなるものと思われる。

次に第二の理由だが、これはお客の情報システム部門が、いわゆるコストセンターでありプロフィットセンターでは無いという事に由来すると思われる。

プロフィットセンター、つまり、実際に企業外部から利益を稼ぎ出している部門であれば、自分たちの成果というものを判りやすく外に示すことができる。つまり、「今期はいくら使っていくら稼ぎました。だから俺たちはとても頑張っているんです」ということを経営者に対して、容易に説明することができる。

それに対してコストセンター、つまり業務の内容が直接的には収益に結びついていない部門では、そういった成果を示すことができない。

通常では、システムの利用に対して課金する、などといった方法で情報システム部門の仕事を評価するということが行われる様だが、それだって完全ではない。情報システム部門以外の、システムを利用する側からしてみれば、システムは使わなければならないから使っているというだけであって、必ずしも使いたくて使っているわけではない。それに、システムを利用したからといって、それが結局いくらの利益をもたらしたのかということは、誰にも判らない。

経理や総務・人事といった部署の仕事は、情報システム部門と同様、直接的に利益をもたらすような仕事ではない。だが、それらの部門でやっていることの内容は明らかであり、その必要性についても今更とやかく言われることもない(まぁ、近年ではアウトソースされるという危険性があるようだが、それでも必要性が問われることはない)。それに、こういった部門が使用する経費は、毎年ほぼ一定しており、極端に大きく変動することはない。

それに対して、情報システム部門のやっている仕事は経営者からしてみれば胡散臭いことこの上ない。

毎年毎年莫大な額の金を喰らっているくせして、1円の利益ももたらさないし、そもそも、毎年の予算を一体何に使っているのかが全く判らない。どうしてこんなパソコンを1台買うのに、毎年何十億・何百億もの金を使わなければならないのか。近所の電気屋に行けば10万円も出せば良いのが買えるというのに。おそらく奴らは、仕事をしているふりをしながら、予算を使って遊んでいるに違いない。そうだ、そうに違いない。

まさか、今時まともな企業の経営者であれば、こんな事を本気で考えている奴もいないだろう。だが、それでも専門外の人間からしてみれば、情報システム部門の仕事は不透明なことこの上ない。よくワカランが必要そうだから、社員や株主からの要請があるから、最近の流行だから、とりあえず投資し続けてはいるものの、腹の中では常に必要性には疑いを抱いている。

そうすると情報システム部門の人間としては、自分たちの仕事を護るために、来期の予算を獲得するために、経営者に対して自分たちの頑張っている姿を示さなければならなくなる。

だが、建物のようにその成果が明らかに目に見えるものであればいいのだが、システムの場合はそうはいかない。ハードウェアはそれでもまだ判りやすいのだが、ソフトウェアの場合は、それを作るのにどれだけ苦労したのか、どれだけの人員を投入しなければならなかったのか、それを年寄りに判らせることは間違いなく不可能である。

だから、できることはただ一つ。何でも良いから、「大量に作りました!」と主張できるような何かを用意することである。そして、その何かとはプログラムとドキュメントの事である。

そして、この関係は経営者から情報システム部門のエラい人、ちょっとだけエラい人、あまりエラくない中間管理職、末端の担当者へと続いていく。つまり、来期の予算を獲得するために体育会系的努力の姿勢を上司に対してみせるという関係は、経営者から末端まで続くことになる。

そうすることで、お客の担当者にはドキュメントの量を増やすという圧力が生じることになる。

開発規模が大きければ、必然的に書き物の量も増えるし、それに頑張っているというのが素人にも判るようになる。だが、高々数ステップのツールみたいな奴だと、努力している風に見えない。それどころか、手を抜いているとさえ言われかねない。だから、規模が小さい奴では、何とかしてまとまった量の「何か」を作り出さなければならないのだ。だから、無駄なドキュメントを大量に作る羽目になる。

正直言って、俺はこんな仕事は嫌だ。

一度作られたきり二度と読まれることもなく、ただ印刷して枚数を稼ぐためだけの資料、よくてディスクの肥やし、悪ければ削除されるだけの、何の意味ももたないWordとExcelの資料を作り続けるだけの仕事。それがスケジュール的に余裕があるのならまだしも、大概は無意味に期間が短く、必要もないのに深夜や休日に出勤させられるこんな仕事が辛くてたまらない。

生きて行くためとはいえ、どうにかならないものだろうか。

2008/06/29

行折り返し

例によって例のごとく、「主筆」の新バージョンを公開したから、今後やりたい事リストを書き連ねてみることにしようか。

最近、俺の中で気になっているのは、「主筆」は行を折り返して表示することができないということだ。ウインドウの右端で折り返して表示することができないのはもとより、一定文字数の単位で折り返して表示することもできない。それどころか、一行の長さはは最大10239文字までで、この制限はロジック中に定数値で書かれていて変更することもできない。

この制約は元々、「主筆」開発当初、すなわち2004年10月頃における決定事項に由来する。すなわち、最初から余り高度な機能を実現しようとすると、途中でモチベーションが維持できなくなるから、ある程度機能を絞って多少所しょぼい代物であっても構わないから、とりあえず動く物を作って公開することにしよう、という事だ。

この決定事項に基づき、俺は一行は最大10239文字(つまり10K文字)までと決めてしまい、かつ、行折り返しの機能は完全に諦めたのである。行を折り返して表示できるようにするとなると、明らかにテキストを描画するロジックが複雑になる。しかし、絶対に行を折り返して表示することはしないとすると、一行が極端に長いテキストを読み込まれたときに、甚だ困ったことが起きるものと予測される。つまり、ウインドウの表示に極端に時間がかかってしまったり、あるいは何らかの内部的な制約に引っかかったりするのではないかと、心配になったのだ。だから俺は、(1)面倒だから行折り返し機能は実装しない、(2)予測されうる問題を回避するために、一行の長さを制限する、という決定を下したのだ。

だが、ここに来てそろそろその決定を覆そうと考えている。すなわち、行の長さの制約を取り除き、行を折り返して表示する機能を実装するということだ。

行を折り返して表示すると言っても、いくつかのパターンが考えられる。まず第一に、一行がある程度以上の長さになったら、そこで強制的に折り返して表示するというものだ。テキストを描画する上で、やはり極端に横に長いといろいろと不都合が生じる危険性がある。だから、ある程度長くなったら自分自身を護るためにも、そこで強制的に折り返して表示するようにしてしまう必要があると考えられる。また、ユーザによってはある一定のところで折り返したいという欲求もあるかも知れない。それと二点目は、ウインドウの右端に来たら折り返して表示するという奴だ。これがいわゆる一般にに言うところの、行折り返し機能と言える奴だろう。

実装上及び機能上、この二つには共通部分もあるが共通しない部分もある。共通する部分としては、結局いかなるところで折り返そうとも一行が複数行として表示されるようになると言うことだ。現在の「主筆」は、一行のテキスト(つまり改行コードから次の改行コードまで)は、必ず一行で表示されることを前提として作成されている。その前提が崩れるのだから、内部的なロジックにはかなり甚大な影響が出るものと予測される。

共通しない部分としては、行を折り返して表示するタイミングの問題がある。まず、ある一定文字数以上になったら折り返すというのであれば、どこで折り返すのかを求めるのは存外容易である。つまり、テキスト中に含まれる文字数だけで、何行になって表示されるのかとか、どこの文字で折り返されるのかが容易に計算できる。更に、選択された文字がどの行に含まれるのかを計算するのも、比較的容易である。それに対して、ウインドウの右端で折り返すとなると、事態は一変する。つまり、どこで折り返すのかとか、結果として何行になるのかといったことは、各文字が描画されるときの幅を取得して、一行がウインドウの幅を超えるか超えないかという判断を行わなければならないのだ。これが固定ピッチフォントであれば、それもそれ程難しいことではないのだが、プロポーショナルフォントを表示する場合には、純粋に各文字の表示位置を計算してウインドウ幅と比較するという処理を行わなければならない。

ウインドウ幅で折り返す機能を実装するためには、各文字の幅を取得して、文字が表示される位置を計算しなければならない。そうしなければ、全体としての行数も判らないため、スクロールバーを表示することもできない。すなわち、テキストファイルを読み込んだタイミングで、一旦全てのテキストの表示幅を算出してやらねばならないということを意味している。そしてそれには時間がかかることが予測される。

そういった諸々を考えると、行折り返し機能は何かと大変なのではないかと思われる。

とりあえず、今現在特に対応したいと思っているのはそれぐらいだろうか。手元に転がっているMafefileやIniファイルの構文強調表示機能は、適当に時間を見繕って組み込めば良さそうだし、印刷機能の拡張(例えばカラー表示やプリンタ依存の拡張機能の利用など)は、今のところ余り必要性を感じていない。ツールバーはもとより実装する気はないし、ログを出力させる機能も個人的には欲しいところだが使う側としてはありがたみがない。プラグインやコマンド周辺の機能拡張もいくつか欲しいところだが、これはおそらく適当に気分が乗ってきたときにやることになるだろう。

そういうことで、第21版に搭載されるかどうかは判らない、というか今までの例からするとおそらくもっと後になるのだろうが、とりあえず行折り返し機能を実装する方法について、いろいろと考えを巡らしてみることにしよう。

2008/06/28

20

とりあえず、「主筆」の第20版を公開しておいた。本当なら、まだまだ細かいところを調整したかったのだが、きりがないから現時点で一旦打ち切ることにしておいた。

第19版からの変更点で、最も大きいものはエンコードの自動認識機能を搭載したことだろう。長年必要だろうと思いつつも実装できていなかった機能だが、これでようやく対応することができた。また、世の中一般ではごく当たり前に存在するMRUリストを管理・表示する機能も搭載しておいた。俺的には余り必要だとは思わないのだが、あると見てくれが派手になるから、一応入れておいた。

また、検索・置換ダイアログも少しだけ機能を拡張した。今までは、検索・置換ダイアログが表示されたとき、フォーカスが「OK」ボタンに来ていたのだが、それだと使いにくい。やはり、検索はキーボードだけで操作できるようにしたいものだ。ということで、検索・置換ダイアログが表示されたときには、検索文字列を入力するテキストボックスにフォーカスを合わせるよう変更した。また、テキストが選択された状態で検索・置換ダイアログが表示された場合には、選択されたテキストを検索対象の文字列としてデフォルトで設定するようにもした。後は、検索・置換対称の文字列の履歴を保持・表示する機能や、正規表現の入力を補助するような機能があれば、より便利になるのではないかと考えている。

これは俺だけかも知れないのだが、Windowsではフォーカスをどのコントロールに設定するのか、というのを制御するのはそれ程難しいことではない。だが、なぜだか知らないがMotifだとそれが以外と難しい。難しいと言うよりも、なんだか判らないが直感的にできない。思った通りに行かないのだ。検索・置換ダイアログのフォーカスの問題も、「初めからそうしておけばよかったじゃないか」という突っ込みが入りそうなのだが、実を言うと、「しなかった」でのはなく「できなかった」だけなのだ。だが、それもとうとう第20版で解決した。体育会系的方法論で。

全く役に立たないし、おそらく俺自身も動作確認をするとき以外は絶対に触らないであろう、バージョン情報を表示する機能も追加しておいた。世の中一般のソフトウェアでは、大概「ヘルプ」メニューがあり、その中には何の役に立つのか知らないが、バージョン情報を表示する機能がある。だから、「主筆」でもそれに倣ってこの機能を追加しておいた。まぁ、さしたる手間がかかるわけでもないし。もっとも、本当であれば「ヘルプ」メニューにはヘルプを表示する機能を搭載するべきなのだろうが、それはまだ実装できていない。

「主筆」のマニュアルはすべてPDFである。その都合上、プログラムから表示できるようにするのは何かと面倒だ。まぁ、不可能ではないし、表示するようにしても良いのだが、ユーザがPDFファイルのビューアとして何を使っているのか判らないとか、Solaris 8ではデフォルトではAcrobat Readerが入ってないとかいう問題があるから、やりたくないのだ。

CDEの場合(というべきかMotifの場合と言うべきかは知らないが)、古いWindowsのヘルプのようなヘルプを表示する機能が無くはないようなのだが、正直言って、あれは使いにくいような気がする。もし、「主筆」にまともなヘルプ機能を実装するのであれば、WindowsのHTMLヘルプのようなものを提供できるようにしたいものだ。そうすると、それはそれでかなりの作り込みになってしまうだろうが。

実を言うと、第20版を公開してしまった直後に、プラグイン開発ガイドの英訳に手を付けてしまった。現時点では第19版として公開していた分の英作文は終了し、後は20版に追加された分と、マニュアルとして整形する処理が残っているだけだ。あと一日ぐらい時間があれば、Plugin Development Guideとして公開できるようになるだろう。更に、手元にはMakefileとINIファイルの構文強調表示処理を行うモジュールも存在していたりもする。このタイミングなら、第20版として一緒に公開してしまいたかったのだが、それをやるとまたずるずると公開できなくなるから、それは諦めてしまった。マニュアルは適当な時期に独立してHPにアップロードすることにしよう。構文強調表示機能の拡張は、第21版からということになるだろう。

もっとも、第21版が公開されることになるのかどうかは、判らないが。

2008/06/08

旧居

主筆」のエンコードの自動認識機能・MRUリスト表示機能・プラグインへ提供するAPIの強化などが終わり、そろそろ第20版として公開しようかどうか考えている。もうちょっといくつか細かい機能を実装したい気もするが、そんなことを言っていたら、いつになってもキリがつかないから、そろそろ潮時ではないかと思う。

しかし、公開するとなると一つ問題がある。それは、Solarisの互換性の問題だ。Solarisの場合、新しいバージョンのOS上でコンパイルされたバイナリは、古いバージョンのOSの上では動作しない。たとえば、Solaris 10でコンパイルしたバイナリはSolaris 8では動かない。だから、実行バイナリを公開するのであれば、動作対象とするOSの内でもっとも古いものの上でコンパイルして、公開するバイナリを生成しなければならないということになる。

「主筆」は、以前からSolaris 8以上をターゲットとしてきた。そして、それはこれからも変えるつもりはない。たとえSunがどのような意思を持とうとも、俺はSolaris 8を見捨てるつもりはない。そのために俺は、今でもわざわざSolaris 8の環境を整えて維持し続けている(まぁ、要はSolaris 8を入れたマシンを転がしてあるだけなのだが)。

また、現在「主筆」はSun Studio 12で開発を行っている。強いてそれでなければならない理由はないのだが、とりあえずSun Studio 12に移行してしまったのだから仕方がない。Sun Studioは、特にX-Designerは、一度新しいバージョンのもので編集してしまったら、二度と古いバージョンには戻れないと言う、嫌がらせのような機能が実装されている。そのため、たとえ俺がどれほど心から後悔し、懺悔し、神に祈り許しを請うても、二度とsun Studio 11などの古いバージョンに戻ることは許されない。

ここで素直にSun Studio 12がSolaris 8の上で動作するならば、世は事も無しなのだが、しかしそうはいかない。Sun Studio 12はSolaris 9以上のOSで動作すると言うことになっている。Sun Studio 11はSolaris 8以上で動作するようになっていたのだが、ここにきてSunはとうとうSolaris 8を切り捨ててしまったようなのだ。

そうすると、俺はかなり困ったことになる。すなわち、「主筆」がsolaris 8をサポートし続けるのであれば、なんとしてもSolaris 8上でコンパイルしなくてはならない。しかし、肝心のコンパイラはSolaris 8では動作しない。

どうすればいいのか。

大きく分けて対応策は二つある。まず第一に、Solaris 8のサポートをやめてしまえばいいという方法が考えられる。要は、古いOSにいつまでの拘泥しているのがすべての原因なのだから、ここは世の流れに身を任して、思い切ってサポート対象をSolaris 10だけに限定してしまえばいいという発想。だが、これは俺が許さない。俺の個人的感情から、なにが何でも、当面はSolaris 8をサポート対象に含めたいと考えている。

そうすると、もう一つの方法としては、Sun Studio 11以前の古いコンパイラを用いて、Solaris 8上でバイナリを生成する方法がある。というか、ほとんどこれしかない。

だが、どうやってそれをやるのか。神に祈ろうが悪魔と契約しようが、Sun Studio 11には戻れないのではなかったのか。

実を言うと、いくつかの要点を押さえれば、C++のコード自体にバージョン依存の記述がない限りコンパイラのバージョンを落とすことは不可能ではない。その要点とは、X-Designerである。

結局、古いバージョンに戻れないのはX-Designerだけであり、かつ、それはX-Designerにより生成されたファイルを入力して、Cのソースコードを出力するまでの問題なのである。逆に言えば、C/C++のソースコードをコンパイルし終わってリンクする時点では、X-Designerに互換性がない問題は関係無いのである。

つまりこういうことだ。一旦Solaris 10上のSun Studio 12に含まれるX-Designerを用いてCのソースコードまでは出力しておく。そして、得られたソースコードをSolaris 8に持ってきて、sun Studio 11でコンパイルしてやればいい。そうすれば、目的のSolaris 8用バイナリを得ることが可能となる。

だが、ここで一点気をつけなければならないことがある。それは、Solaris 10とSolaris 8とで環境を同じようにしておくということだ。少なくとも、Sun Studio 12とSun Studio 11をインストールするパスは同一でなければならない。なぜならば、コンパイル時にX-Designerが生成するソース中には、Sun Studio 12のインストール先パスを含むパス名を固定的に保持しているのだ。そのため、ソースを生成するときと、それ以降のコンパイルの段階とで、参照先のパスが変わっていたりしたら、まともにコンパイルが通らなくなってしまうのだ。

とりあえず、その一点に気をつければ、Solaris 10で、かつ、X-Designerの新しいバージョンを用いてソースコードを生成を行わせた後も、Solaris 8に持ってきて古いコンパイラでコンパイルすることが可能となるはずだ。

一応、今もまさにSolaris 8/Sun Studio 11の環境で「主筆」をコンパイルしている最中である。もしこれでうまくいかなかったら、なんか別の手を考えよう。

2008/05/18

日程

今まで比較的本業の方が暇だったのだが、ここに来てまた忙しくなってきた。同時に、いろいろとプライベートな面でも時間を取られて、「主筆」の開発が一向に進んでいない。

まず、日程の都合がついた事から、大学のスクーリングに行くことにした。今年に入ってから全く進捗が無く、このままでは二年で卒業する予定だったのを延期せざるを得なくなってしまうので、可能な限り単位の取得を優先するようにしているのだ。その為、五月には五日ほど授業を受けに行き、貴重なスクーリングの単位を四つほど確保した。更に、六月と七月には、それぞれ一日ずつ年休を取得し、授業を受けに行く予定である。

単位修得試験は、四月に四科目分受けに行く予定だったのだが、これはごく単純に忘れていたためにすっぽかしてしまった。六月にはなんとしても受験しなくてはなるまい。スクーリング以外にも、全体的な単位の取得も、そろそろケツに火がついてきた感がある。

科目修得試験は最大でも月に四科目しか受験できない事から、十月で卒業できるか否かはスケジュール的に間に合うか否かに懸かっていると言える。だから、今後は決してすっぽかすことのない様、具体的な対応策を講じることにした。すなわち、カレンダーにこまめに予定を書き入れ、目につくところに吊しておくことにしたのだ。

原始的だが、俺にしてはまともな対応だと思われる。普段俺は、手帳などという小粋なものを持ち歩く習慣はなく、無論、その手帳を見ることもないので、スケジュール管理は事実上記憶力頼りとなっている。しかも、その記憶力とやらもかなり疑わしい代物なので、実際問題スケジュール管理などなされていないに等しい状態となっている。これでは、試験を受けに行くのを忘れたとしても仕方がない。だが、世間一般の主婦がやっているのと同じように、ちゃんとカレンダーに予定を書き入れておけば、忘れることもないだろう。

ところで、ここで使っているカレンダーというのは、年初に上司から余ったからという理由でもらった自社のカレンダーである。だが、本来であれば、例えカレンダーであっても自社の名前の書いてある物など使いたくもないし、ましてやそれを目につく位置に吊しておく等もってのほかである。ところが、もそろそろ梅雨に入ろうかというこの時期に、新規にカレンダーを買うのも癪だし恥ずかしいしもったいない気がしたから、我慢して使っておくことにした。来年は、もっと使いやすい、かつ、マニアックなカレンダーをちゃんと買うことにしよう。

大学以外にも、俺のプライベートの時間をそぐ要因がある。本業が忙しくて土曜日にも出勤しているし、結婚式が重なるし、いろいろと必需品を買いに行かなければならないし、意外と時間がなかったりする。

本業の忙しさが改善されることは金輪際ありえない事と思われるが、しかし、プライベートの忙しさはそう長くは続かない見込みなので、いずれ暇を見つけて「主筆」の開発を続けることにしよう。

今は、第20版として公開できるように、マニュアルの修正や配布イメージの構築を終わらせたところだ。また、そこまでやっておいて未だに公開していないのは、まだ部分的に改修を加えているためだ。

具体的に言うと、プラグインに公開する関数を強化しているのだ。今までは、プラグインから「ファイルを開く」ダイアログを表示させ、ファイル名を取得する事はできなかった。また、同じようにエンコード名を入力し結果を取得することもできなかった。だから、それが可能になるように作り込むのだ。
また、ファイルオープン時にエンコードの認識を行うようになったので、プラグインにもエンコード変換の過程に改修できるよう、パラメタを追加してやらなければならない。そのため、第20版が公開されるまでには、今しばらく時間がかかるだろう。まぁ、強いてわざわざせかす人もいないので、適用な頃合いを見計らって開発を進めていけば、それで十分だろう。

2008/03/23

狭隘

主筆」とは何の関係もないし、極めて無駄な作業であるということは承知しつつも、つい「メタボール」生成アルゴリズムについて考えてしまった。

前回は、ボールの中心から外に向かってポリゴンをちょうど良い位置まで移動していく、というような方法について考えてみた。だがそれでは、ボールの接合部分がどうしても汚くなり、綺麗な絵を作るためにはポリゴン数を増やすか、別の方法を採るかしなければならなかった。

ということで、もうちょっと綺麗な絵を作るための方法について考えてみた。まず、結論から言うと、ポリゴン数をそれ程増やさなくても、比較的綺麗な絵を生成することができるようになった。




やり方は至って単純である。まず、空間をいくつかの格子に分割し、各格子ごとにポリゴンを生成してやるだけである。つまり、格子の頂点(全部で8つある)が、それぞれ物体の中にあるのか、外にあるのかを求めてやり、そのパターンからあらかじめ決められた形のポリゴンを生成するようにしている。

だが、この方法の問題は、各格子ごとのポリゴンのパターンを機械的に求められないことだ。すなわち、8つある頂点の内いくつかの頂点が物体内に含まれていた賭した場合に、どのような形のポリゴンをいくつ出力すればいいのかが、プログラムでは求められないのだ。

いや、もしかしたら、うまい具合にプログラムで算出する方法があるのかも知れない。だが、少なくとも俺は知らないし、判らなかった。ということで、考えられ得る全てのパターンについて、事前に手作業で定義してやることにした。直方体に存在する頂点は8つ。でもって、それぞれが物体内に含まれるか否かの違いがあるため、組み合わせは全部で256通りになる。

人手でやってできない数ではないとはいえ、大変だった。Webサイトの趣旨からは幾分はずれるが、これについてももったいないから解説ページを作ることにしよう。

2008/03/16

有効

このところ忙しかったのが、今度はうって変わって暇になった。業務時間中も無為に時間を潰しているだけだ。しかも、会社のPCはインターネットに接続できないため、する事もなくてこれはこれで苦痛だったりもする。まぁ、忙しいよりかはましか。しかし、このムダ・ムリ・ムラのある仕事のやり方はどうにかならないものなのだろうか。まぁ、せいぜい私的なことでを充実させて、時間を有効活用させてもらうことにしよう。特にこのところ、通信制大学の進捗が完全に止まっていたから、その方面に力を入れることにしよう。

去年の年末ぐらいにレポート提出を頑張り、その勢いで、登校して授業に出席しなければならない奴を年初に片づけてしまおうと思っていた。しかし、本業でアホみたいにこき使われていたせいで、その計画が完全に破綻してしまった。登校する必要がある奴は少なくとも後四科目片づけなければならないのだが、これは授業が行われる日程などの都合で、なかなか簡単には済ませられない。その上、土日の休みすら得られないのでは、とうてい消化することなどできはしない。全く、クソ忌々しいことこの上ない。こうなったらスケジュールを立て直して、なんとしても今年の秋までには卒業できるようにしてやるしかない。

だが、残っている科目を考えると結構気が重くなる。あまりにも俺の得意分野(俺には専門だの専攻だのと言ったご大層なものはない)からかけ離れた奴を選ぶと苦労するのは目に見えている。だから、少しでも心得のある簿記系の科目を多めに取ってあるのだが、これがかなり負担が大きかったりもする。まぁ、内容はそう難しいものではなく、単にやればいいだけなのではあるが、なにぶん面倒くさくてやる気になれない。「主筆」の開発のやる気がなくなったときにでも、一気に片づけてしまうことにしよう。

「主筆」の開発は相変わらず少しずつしか進んでいない。この数日で、とりあえずファイルのエンコードが判断できなかったときに、ユーザに問い合わせるためのダイアログを作り終えたところだ。後は、ファイルを開くところに、エンコードの自動認識機能と、判らなかったときにユーザに選択させる機能を組み込むだけである。とは言っても、それはそう簡単なことではないのだが。やはり、独立したプロセスになっていたり、せめて共有ライブラリになってさえいれば、それでも改変の負担は小さかったのだろうが、これから弄らなければならないのは「主筆」本体の一番巨大なプログラムの部分であるため、それなりに気を付けて修正しなければならない。前々から、この大きな奴を複数のプロセスかライブラリに分割したいと考えているのだが、それにはかなりの時間がかかるし危険性も高いため、いまだに成しえずにいる。いつかどこかで、時間をみつけてやらなければならないだろう。

結局、いつも時間・時間・時間だ。何にしても時間がないからということで後回しにしてしまう。生きるための本業に裂かれる時間が長いというのは事実なのだろうが、必ずしもそれだけではないだろう。おそらく、こうやって役に立たないblogを書くのに費やしている時間や、そのほかの無意味な行為にとられている時間をかき集めれば、もっと効率よく生きられるのではないだろうか。それに、そもそもするべき事や、やりたいことが多すぎるのではないか。いろいろなことに手を出すから、結局、労力が分散されて最終的には何も得られないという事になっているのではないか。クラウゼビッツも言うとおり、やはり戦力は一点に集中して使わなければならないのではないか。少なくとも、あまり力を入れて取り組むつもりのないWindows CE用ソフトの開発に、多少なりとも時間を費やすのは、やめた方がいいのではないか。

いろいろな思惑もあって、今更「主筆」の開発をやめるつもりもないが、それでも取り組むべき事項について、優先順位を決め計画的に物事に当たらなければならないだろう。少なくとも、あまり頑張るつもりのないプログラムを作るのはやめることにしよう。限りある人生の無駄遣い以外の何者でもないのだから。

2008/03/08

収入

諸般の事象があり作り貯めたWindows CE用のソフトがいくつか手元にある。必要に迫られて作っただけの代物だが、もったいないから時期を見てこいつらも公開することにしよう。ただ、まさに自分が使うためだけに作った代物だから、余り創意工夫も無ければ新規性もないし、使いやすいものとも思われないものなのだが。まぁ、Webサイトの賑やかし程度にはなるだろう。

ところで、最近一つ気がついたことがある。それは、俺のプログラムデッチ上げる能力が確実に向上したと言うことだ。このところのトラブル対応で、何度と無く背中にナイフを突きつけられた状態で他人の書いたプログラムをデバッグして書き直すという状況に陥った。これでプログラムが作れるようにならなきゃ、それこそ人間としておかしいというものなのだろう。

しかし「これを30分以内に動かさなければ10億の赤字が出るから何とかしろ」等と言われてまともにデバッグなんかできるわけがない。それも、他人の書いた、仕様書もない、コメントが間違いだらけのプログラムを、貧弱なログだけを手がかりに解析して、修正なんかできるはずもない。それでも、多少の間違いはあったものの、何とかやりおおせた俺は、もうちょっとぐらい残業代をちゃんと払ってもらったって、良いのではないだろうか。いずれにせよ、人と比べて、それ程図太い神経を持っているとは言えない、俺の脆弱な胃袋は、このところのストレスで大分すり減ってしまったようだ。

まぁ、モノをヤケクソで書き上げる能力だけは身に付いたから、これを使って小遣い稼ぎでもさせてもらうことにするか。それぐらいはしたって、バチはあたるまい。もとより、時給が法定最低賃金に達していないのだから、会社からとやかく言われる筋合いはないしな。(しかしそう考えると、会社がいくら赤字を出そうが俺には何の関係もないのだから、何もストレスに感じる必要は無いんだよな。プログラムが動こうが動かなかろうが、どうでもいいのだから。まったく、俺のお人好しもここまでくると馬鹿以外の何物でもないよな。)

2008/03/02

転嫁

ここにいたって、ようやく仕事が一段落付いてきた。とは言っても、地獄の元凶となった問題は何一つとして解決はしていない。ただ単にSEやプログラマにできることがほとんどなくなってきたから、俺の仕事量が少なくなってきた、というに過ぎない。後は、エライ人や、経理・法務といった部署の連中がこの問題を引き継いで、後始末を付けることになるようだ。とりあえず、会社としては大損を出すことになったのだろうが、一担当に過ぎない俺には関係のないことであり、何らの興味も関心もない。後は勝手にやってくれ。

とりあえず、人並みとはいかずとも牛馬並の生活には戻れたから、空き時間を使って「主筆」の開発を進めることにした。しかし、しばらく開発作業を中断していたため、どこから何をやればいいのか、思い出すのに多少時間がかかった。仕事にしろ私生活にしろ、何にしてもやはりこのような中断や割り込みが入ると、モチベーションや作業効率に大きく影響する。忌々しいことこの上ない。自分の人生設計を考えれば、俺に残された時間はそれほど多くはないのだ。まともに脳ミソが活動してくれる時間など、あと数十年もあればいいところだというのに、このような下らない無意味なことに時間をとられるのは、本当に耐え難いことだ。(ならば、役に立たないフリーソフトの開発が、なにがしかの有意義な意味を問われれば、それもまた大いに疑問だがな)

「主筆」の開発で今まさに取りかかっているのは、エンコードの自動認識機能だ。一応「主筆」は、日本語だけではない多言語対応を目指すということになっているため、エンコードの自動認識機能においても、かなりの拡張性を考慮した構成としている。そのため、意外と開発工数が嵩んでいるが、それでもだいたい目鼻は付いてきた感じがする。とりあえず今のところは、ASCII・Shift-JIS・EUC-JP・UTF-8・UTF-16・UTF-32が認識できるようになった。また、そのほかのエンコードにおいても、対象となるエンコードを処理するためのモジュールを作り所定の設定を行えば、機能を拡張できるようになっている。

だがしかし、まだ完全ではない。どうもUTF-16に認識処理にはバグが含まれているような気がするし、そもそも、「主筆」の本体側から作り込んだ認識機能を呼び出す処理を実装していない。あまり本質的な処理では無い気がしないでもないが、この辺の開発工数というものが、いつも考えている以上に大きくなる。甘く見ない方がいいだろう。印刷機能の実相でも、ひどい目にあったのだし。

今のペースで開発が進むのなら、自動認識機能を追加しただけのバージョンでも、公開は夏期休暇以降になるのではないだろうか。予定では印刷機能の強化や、行折り返し機能を実相したかったのだが、そんなことを言っていたら、すでにして第20版の今年中の公開が危ぶまれる。あまり欲を出さずに、エンコードの自動認識機能の実装だけで、第20版を公開してしまうのがいいのかも知れない。だがそれも、すでにして火がついている感のある次のプロジェクトが今回のような地獄に陥らなければ、という前提での話だ。その前提が崩れるようなら、今年中の代20版の公開は困難となるであろう。

というか、あのような酷い状況がこれからも続くようなら、まじめに本業を変えることについて検討しなければならないだろう。そうでなければ、俺の身が持たない。生きるために、明日のメシを得るために仕事をしているのに、その仕事のせいで命を落ちしてしまったら基も子もないのだから。

2008/02/12

品質

俺の余り多くない経験によれば、バグはテストしにくい部分に多発するように思う。すなわち単純に言って、叩かれた回数の少ないロジックは品質が悪いと言うことだ。

では、テストしにくいとはどういう事だろうか。自分で作ったプログラムなのだから、自分で動かし方を判っていて当然だと、人は思うかも知れない。だが、現実はそうではないことが多い。

まず、既存システムとの絡みがある場合だ。新規に開発した部分でも、既存システム側である種の条件がそろわなければ実行されることがないロジックというものは存在しうる。例えば、株価を計算する既存システムに、「株価がある一定以下に下がったら警告を表示する機能」を付け加えることを考えてみる。この場合、既存システム側から受け渡される株価がある一定以下に下がらなければ、新たに作り込んだロジックは実行されないことになる。

そういったロジックのテストを行うためには、単純に考えれば、既存システム側で然るべき条件を発生させるようなテストデータを喰わせて、新規に作り込んだロジックを走らせればいいということになる。

だが、設計・開発する人間は必ずしも既存システムの方を理解しているとは限らない。そもそも、その既存システムなるものを完全に理解している人間がこの世の中に現存するとは限らない。

それに、例え知っている人間がいたとしても、やはりテストをする度にその人にお願いして、テストデータを用意してもらって、場合によってはシステムを操作してもらって、ということをやっていては、テストははかどらない。それが、自社の同じ受注案件に放り込まれた開発要員であればそうでもないのであろうが、お客や縁もゆかりもない他社の人間だった場合には、その周辺のロジックはほとんどまともに実行されることなくリリースされる運命にあると考えた方が良い。

他にも、テスト可能な環境の数が少ない場合にも、同様の問題が生じる。ライセンスやマシンの台数や、開発環境を用意する人間の怠慢などによって、テスト環境が一つしかないというのはよくある話である。特に、DBの環境が一つしか用意してくれていなかったりすると、自分がテストしている最中に、他の奴に勝手にDB内のデータを書き換えられて、長い長いテスト行程を初めからやり直すことになったりする。結果として、動作させにくい部分のロジックが一度しか実行されないままリリースされたり、場合によっては一度も動かされることなく本番を迎えたりと言うことも起こりうる。

そういうとき、当事者どうして話し合ってそういうことの起こらないようにとか、事前にスケジュールを立てて計画的にテストを実施するようにとか、管理者の人間ならなら言うだろう。子供じゃないんだから甘えるなと、そういうだろう。だが、それは責任者の甘えであり、怠慢である。

人と話し合うのには、それ相当な精神的エネルギーを使う。コミュニケーションこそは効率を低下させる最大の要因である。それは人も機械も同じである。

プログラムの品質を向上させるためには、純粋に実行される回数を増やす必要がある。同じ事を何度やっても意味がないというのは確かにそうなのだが、しかし、何度かやらなければバグに気がつかないこともあるし、たまにしか発生しないバグというものだってあるのだから、ある程度は回数をこなすことは重要である。

その為には、開発者が人とコミュニケーションを取らなくてもテストできるような環境を整えることが何よりも重要である。それ以外の部分をいくら充実させても、その分が改善されない限りはテスト効率が向上することはない。必然的に、プログラムの品質が低下することになる。

俺が思うには、プログラムの品質を規定する要因としては、開発者の能力よりもテスト環境の優劣の方が大きいのではないかと思う。

2008/02/10

反省

今日は久しぶりの休日となった。明日からはまた仕事だが。

この国には本当に労働基準法という法律は存在するのだろうか? 労働組合は労働者の立場を守るために存在するのではないのか? なぜに、このクソ忙しい時期に組合の仕事までしなければならないのだ。俺に死ねというのか。

現在火を噴いているこのプロジェクトは、簡単に言えば端末のリプレースである。今まで使ってきた端末の保守期限が切れるから、新しい奴と入れ替えようという、ただそれだけのプロジェクトである。ハードウェアの入れ替えと同時に業務アプリケーションの一部改変も行われたが、それを含めてもプロジェクトのリスクは経験の範囲を超えるものではなく、時間的余裕がないことを除けば、必ずしも失敗することが運命づけられたプロジェクトというわけではなかったはずだ。

ところがだ、一つだけ予測していなかったことがあった。それは、そのシステムではある特殊な機器が接続され利用されるということだ。そして、今回はその特殊機器のリプレースも同時行われたのだ。

確かに時間はなかった。提案活動がずるずると延びていつになっても発注してくれない癖して、不思議なことに時間の経過とともに納期はどんどん前倒しになり、当初は一つもないといっていた改修が次々と追加され、それなのに金が増えることはなく、人を増やすこともできない。どこにでも転がっている悲惨なプロジェクトの一つ、よくある物語だ。だがしかし、それもこれも全ては予測の範囲内であり、おおむね物事は予定通りに進んだはずだ。

だがそれなのに、それなのにだ。

本番を迎えると、時々端末が故障するという問題が発生した。しかも、単にハードが故障するだけならまだいい。最悪なことに、業務データとともに一蓮托生で天に召されるのだ。せめてデータさえ消えることがなければ、ここまで客がキレることはなかったであろう。ハードの交換には金はかかるが、しかしそれは金の問題にすぎない。モノを作った奴に責任をとらせれば、それで済む話だったのに。

業務のデータが消えるとなると、もはやいかなる言い訳も通らない。たとえどんな手段を用いようとも、データが消失することの無いよう、対処せざるを得ない。そこまではわかる。

わかるが、しかし、何でその対処法が業務アプリケーションの改修なんだ? なんでハードウェアの不具合をプログラムで補完してやらなければならないんだ? ある時突然、何の脈絡もなくファイルシステムが崩壊するとかいう意味不明な現象に対して、プログラムとしては一体何をしてやればいいというのだ?

しかもタチの悪いことに、ハードウェアの故障がプログラムの品質のせいにされているし。所詮OSの上で動くだけのノーマルな業務アプリケーションが、一体どうやってファイルシステムを破壊するというのだ。単にデータを破壊しているだけではないのだ。メディアがマウントできなくなるほどに完全にいかれてしまうのだ。

ひどい話もあったものだ。

後は客は言いたい放題で、どう考えてもおまえらの間違いとしかいいようのない問題まで、こちらの責任として直させられるし、どう見ても無意味としか思えない改修をやらされるし、明らかに何の関係もない新規機能を瑕疵担保責任の名の下に作らされるし。それに対してこちらは、何一つ言い返すことはできないし。

あのハードウェアの故障さえ無ければ、プロジェクトとしては失敗では無かったはずだ。カネ的にも利益は確保できていたし、アプリケーションも言われるほど品質は悪くなかった。全くバグがないとは言わないし、時には客に迷惑がかかることだって、あったかもしれない。だが、今までに出てきているアプリケーションの不具合は、件数的にも性質的にも、通常予想されうる範囲内にとどまっており、むしろプロジェクトの期間を考えればよくできている言っていいのではないかと思われる。

それなのに、それなのにだ。

教訓:1.ハードウェアの品質を過信しないこと。2.プログラマはハードの不具合は追求してくれないし、それどころか報告にも上げてくれない。しかし報告に無いからと言って、かならずしも問題がないというわけではない。

2008/01/23

投擲

このところ、本業の酷い激務に追われて、人としての生活の全てが犠牲になっている。一年近くかけて作ってきたシステムが本番稼働したと同時に無数の障害が発生して、その対応に追われているのだ。

しかも、ただ現れた障害に対応し続けているばかりではない。障害時に備えてデータを保護するための機能だとか、縮退運転時にユーザ操作を支援するための機能などを同時に作らされている。無論、その間にも障害は発生するから、その暫定対策及び原因追及も同時にやらなければならない。

それだけではない。どう考えたって障害とは何の関係もない新規機能を、障害対応という名の下にロハで作らされている。それも、到底考えられないような短納期で対応しろと抜かす。500stepの改修が一晩で終わるわけがないだろうが。馬鹿野郎。しかも、自分たちの日程が合わないからといって、勝手にどんどん納期を短くするんじゃねぇ。

テメェらのヒラめいたオナニー機能を実装しているせいで、肝心の原因追及は全く進まないし、それどころか暫定対策もままならず、おまけに無理矢理作り込まされた奇妙な機能のせいで、新たな障害が発生するし。

挙げ句の果てには、明らかにおかしい部位があるから修正させてくれと言っても、なんのかのと難癖を付け改修を許可しない。どう見てもこれは、只で開発をやらせるための口実を温存しようとしているとしか考えられない。

他にも、一度障害の起きた端末は使いたくないとか言い始めるし。ここまでくればもう、純粋な恐喝以外の何物でもない。なぜ、実行プロセスが異常終了したらPCを新しいものと交換しなければならないのだ。ただ単に、新品のPCが欲しいだけじゃネェか。

確かに、作られたシステムの品質は悪い。それについてはこちらに非があるのだろう。しかしだからといって、その弱みを握って金品を要求したり、ありもしない不具合について言いつのり、物品を脅し取ったりすることが許されるのだろうか。ただ個人の楽しみの為だけに無意味な無理難題を押しつけ、開発要員を無駄に疲弊させるようなマネが許されるのだろうか。

会社としては、お客のシステム担当のチンコをしごいておけば、訴訟リスクを軽減することができるかも知れないと考えているのだろう。確かにそうかもしれない。だが、そのズリネタにされる俺らは一体どうなるんだ。身も心も摩耗して、後に残るのは魂の抜け殻だけだ。俺は、そんなのはお断りだ。

結局、残業代なんてまともに出やしないこの会社では、働けば働くほど損をするのだ。そう思うと全くやる気など出やしない。ありもしない自分の責任を果たすつもりにもならない。客が困ろうが損をしようが、会社が賠償金を支払らおうが何しようが、俺には関係ない。

ヤクザ対応はヤクザ好きにやらせておけばいいのだ。俺はもう、この仕事はやりたくない。隣の奴は数日前から姿を消した。俺もそろそろ、それに倣うことにしよう。

2008/01/01

Unicode

とりあえず、Shift-JISとEUC-JPについては、それっぽい自動認識機能を実装することができた。認識対象とするエンコード名を優先順位と共に入力させ、はっきりとそうだといえる場合には然るべき結果を返し、複数の可能性が残る場合には優先順位に従って結果を返す。同じ優先順位のエンコードが複数残った場合には、判断がつかない旨のメッセージを表示する。

条件がややこしく作りにくかったが、結果として何とかなった。後は動作確認をどうするかという問題が残されてはいるのだが。

それはいいとして、とりあえずそれっぽく動くようになったから、今度はUnicodeの判定を行うロジックを作り始めた。だが、これがまた難しい。

今更な話ではあるのだが、やはりUnicodeは文字コードの規格としては非常に複雑で難しいものだと思う。はっきり言えば見苦しい。そもそも、何で同じUnicodeの中にあんなに沢山の種類のエンコード方式があるんだ? というかUTF-8って、ありゃ一体なんなんだ?

愚痴はいいとして、Unicodeらしきテキストを読み込んだときに、それが本当にUnicodeのテキストとして正しいか否か判断する方式について考えてみる。

まず、UTF-8ならUTF-8でエンコードされたデータを読み込み、それを元にUnicodeのコード値とかいう値を求める。この時点で入力データがおかしいと判断できる可能性がある。

次に、得られたコード値がUnicodeの文字として正しいか否かを判断するには、Unicodeの標準として公開されているコード値の一覧と付き合わせて、存在する値か否か判断する。

面倒なことこの上ない。

しかも、単純なビット演算により正誤を判断できないため、処理時間が長くなる恐れがある。特に、コード値の一覧とのマッチングには十分に注意しなければならない。

この辺りはまだ実装していないが、何らかの高速な処理方式を実装しなければならないだろう。

全く、面倒なことこの上ない。