Sun基地プログラマの繰り言

Windows 7 のタスクマネージャは幅を広げると表示がおかしくなる

2012-01-07T22:53:00.007+09:00

タスクマネージャで「パフォーマンス」タブを選択すると、CPU利用率とメモリ使用量が表示される。

このとき、タスクマネージャのウインドウ幅を広げると、あるところでCPU利用率のグラフが急に幅が狭く表示されるタイミングがある。具体的には2195ピクセルを超えたところで現象が発生する。

幅が2194ピクセルの場合

1ピクセル広げて、2195ピクセルにした場合

判りやすくするため、一定間隔毎にCPUを無駄に消費するプロセスを実行させた状態で、画面をキャプチャしている。

幅が2194ピクセルの状態ではCPU利用率の変動幅が広く表示されているが、この状態から1ピクセルだけ広げると、なぜかグラフの幅が細くなった状態で表示される。

しかも、グラフの背景の罫線は幅が変わらないから、ウインドウ幅を2195ピクセル以上にした状態を続けていると、グラフが左に流れるよりも後ろの罫線が左に流れる方が早くなってしまう。つまり、罫線がグラフの波を追い越していってしまうという訳だ。

上記の比較ではCPU利用率を用いたが、同じ現象はメモリ使用量のグラフでも発生している。さらに、ネットワークの利用率も同様である。おそらく、黒字に緑のグラフを表示するプログラムがバグっているのだろう。というか、高解像度のディスプレイでテストを行っていないことは明らかである。

じゃぁと言うことで、同じようなグラフが表示されるリソースモニタを確認しようと思ったら、こっちはグラフの幅を一定以上に広げられないようになっていた。

まぁ、別に困らないんだが。

なお、同じ問題がWindows NT 4.0とWindows XPでも発生することを確認した。

Windows NT 4.0があった

2011-12-30T20:40:00.003+09:00

昔買ったVisual Studio 6.0 Enterprise Edition。さすがにもういらないから捨てようかと思い、箱の中身をばらしてみた。中に、一度も使ったことのないBackOfficeServer Developer Editionとか、それの説明書きの本とかが入っていた。

その本をぱらぱらとめくってみると、中にWindows NT 4.0 Serverが同梱されているという記述が目にとまった。しかしながら、ディスクの表面を見ても、中身を見てもそんなものが入っている風はない。ものの試しに7枚あるすべてのCDからPCの起動を試みてみたが、ブートディスクになっているものはなさそうだった。

だが、中のReadMeみたいなファイルをよく読んでみると、どうやらWinNT4.0のインストーラ自体は入っているらしい。だが、起動ディスク（それもFDだ）は、コマンドを実行して自分で作れとある。

ならばやってみようと言うことで。

まぁ、別に何に使おうというのでもない。

だがしかし、自分の作ったソフトがいったいどの環境で動作し、どの環境では動かないのかをはっきりさせるためにも、各種OSを用意できるのはいいことであると考える。NT4.0で動作確認を行うか否かは別問題だが。

実績は努力に比例しない

2011-12-25T22:12:00.005+09:00

今日一日かけて片付けてみた。

下の方がこれ。

上の方に目を移すとこうなっている。

一日の労働が報われた気がしない。

隙間に体をねじ込んで、無理な姿勢でケーブルを固定する作業を続けていたせいで体の至る所が痛いし、あり得ないところが筋肉痛っぽくなっている。それなのに昨日とさして変わっているように見えない。

というか、LANケーブルが多すぎる。何でこんなになったのか？

一応、理由がある。まず、論理的なLANの配線を書くと、こうなっている。

一台のPCでWindows MultiPoint Serverを動かし、その上の仮想環境で2008 Serverを動かしている。そいつらにそれぞれIPv4とIPv6用のLANポートを設けてLANに接続する。これだけで1台のPCにLANケーブルが4本接続されることになる。同時に、無線LANの端末をIPv4のLANに接続するため、ブリッジ接続を行うためのLANポートを設ける。これで合計5本。

もう一台、Windows 7を動かしているPCも同様にIPv6用とIPv4用のLANポートを用意するので、これにはLANケーブルが2本刺さる。

図には書いていないが、未だに残っているSun Fire v250やBlurayDiscレコーダ、テレビ、プリンタと言ったIPv4のホストがいくつか存在し、また、ブロードバンドルータとHUBを接続するためのLANケーブルなども必要になる。

結果として、上の写真のような情景が描き出されることとなる。

配線を片付ける最も確実な方法は線そのものをなくすこと、すなわち無線にするか、諦めるかのいずれかである。だが、俺としてはそのどちらも受け入れがたい。

線をなくすこともできず、片付けようもないならば、甘んじてこの状況を受け入れるほかないのだろうか。

配線が汚い

2011-12-24T23:05:00.006+09:00

PC裏の配線が汚い。

前から汚かったのだが、多少の設備投資を行い、N/W環境を変更したら、ますます汚くなった。もはや、ちっとやそっとの工夫でどうにかなるレベルではなくなってきている。

これが、2009年7月時点の状態。

これが現時点の状態。

ほぼ同じ位置から、同じ方向を向いて撮っているはずである。画面奥にPCがあり、その裏側、白い壁との間にとぐろを巻いているのがケーブル類である。

UPSは設置位置を変えたから、上の写真ではその姿をあまり確認できないが、2009年次点から個数は増減していない。

画面奥に接近するとこうなる。まずは床に設置されたPCの裏側。

もはやケーブル、というかほとんどLANケーブルのせいで、すでに床が見えなくなっている。

というか、5ポートある安物のブロードバンドルータが1つと、8ポートと5ポートあるL2スイッチが1つずつ存在するわけだが、そいつらのポートをほとんど使い切ったのだから、これは必然なのかもしれない。

棚の上に置かれたPCからもケーブルが滝のように流れ落ちている。

特に黄色い線が目立っている。

デザインとか見た目とかは何も考えず、取りあえずカテゴリ6のLANケーブルを全部黄色で統一したら、こういう事になってしまった。

しかしながら、これはどうやったら綺麗に片付けられるのだろうか？　検索するとケーブル収納ボックスに入れたとか、何かに巻き付けられるようにしたとか、そんな話は出てくるが、その程度の工夫でどうにかできる気がしないのだが。

まぁ、明日気力があったら多少の努力はしてみることにしよう。

技術士の筆記が通った

2011-10-29T17:24:00.001+09:00

技術士（情報工学部門）二次試験の筆記が通った。三回目にしてようやくだ。

今度は技術体験論文とか言うものを出さなければならない。あまり受かっている気がしなかったからちゃんとしたものが手元にない。全くないわけでもないのだが、完成していない。

11月7日までに出さなければならないと思うと、余裕も考えればおそらく3日の休日にを狙って書留を出すのが無難だろう。
そう思うと、blogを更新している暇などなく、この土日で仕上げなければならないという計算になる。

しかし、書くとは言っても、何が良くて何が悪いのかという判断基準がないと、書きようがないし、まして推敲もできない。仕方がないから、なんか指南書の一つも探してこようと思って本屋に行ってみた。

とりあえず八重洲ブックセンターに行ってみたが、技術士の参考書が並んでいるコーナーには、ハゲ親父が二・三人へばりついて本を漁っていたから、そこはあきらめた。

次に、普段はいかないoazoの丸善に行ってみた。そうしたら意外と沢山技術士関連の本があっていい感じだった。まぁ、近くにホモくさい男二人がいて、ずーっとしゃべり散らしていたのが気にくわなかったが。

まぁ、そこで一冊だけそれっぽい奴を買って、後は何とかでっち上げることにしよう。

Multipoint Server

2011-09-27T20:22:00.002+09:00

Sigmarion IIIがあった頃は寝ながら枕元でPC（?）がいじれたわけだが、それもついに動かなくなりこの間捨ててしまった。

中古で3万円もしたのだが、何の生産性もないまま退役なされてしまった。全くもったいないことだ。まぁ、それはいいか。

代用品として、タブレットPCでも買おうかと思っていたが、どうにもお気に召すものがない。MSIの64bit版Windows 7を搭載した奴が良さそうに思ったのだが、品薄で手に入らないと言われたし、値段が高いこともあって、結局あきらめた。

試行錯誤した末に、Windows MultiPoint Server 2011というものを試してみることにした。これは、一台のPCに複数のキーボード・マウス・ディスプレイを接続すると、複数のユーザで同時にログインして使うことができるようになるという代物である。

俺の部屋には、今現在PCが2台ある。その状態で、枕元でPCをいじれるようにするためには、選択肢としては下記の3つしかない。
（１）小さいPCをもう一台買う
（２）一台を枕元に持ってくる。
（３）一台のPCにディスプレイを2つつないで、そのうち1つを枕元に持ってくる。

（１）の案については価格とブツの入手可能性の観点からやめた。（２）案が一番現実的だが、そうすると今現在机上で2台操作できる環境をあきらめる必要が生じる。ということで、（３）案を試みることにした。

（３）案だが、ただディスプレイを複数つないだのでは、ノーマルなマルチディスプレイとなり著しく都合が悪い。特に、どっちかのディスプレイを排他的にしか使用しないという状況では、マルチディスプレイになるとはなはだ困ったことになる。何かというと、ウインドウが消している方のディスプレイにも普通に表示されてしまうのだ。これでは操作に困る。

そういうことでMultipoint Serverという発想に至ったのである。しかもこれはMSDNで手に入るため、すでにダウンロード済みである。いつでも入れれば使うことができる状態にある。というか、使わなければもったいない。

だから入れてみた。

入れてどうなったかは、今度気が向いたら書いて見ようと思う。

HYPER-Vのマウスのアイコンが水着に見える

2011-08-19T11:00:00.002+09:00

タイトルの通り。

HYPER-Vの、ゲストOSの画面を表示するウインドウの右下に、おそらくマウスを表したと思われるアイコンがあるのだが、俺にはこれが、白いスクール水着にしか見えない。

少し検索したが、似たような書き込みが見あたらなかったところから判断すると、こんなことを思う奴は多分少数派なのだろう。

Multi Point Srever

2011-08-16T21:31:00.002+09:00

技術士の筆記試験が終わった。情報処理技術者試験のプロジェクトマネージャが合格していた。そう考えると、多少は金を使っても罰は当たるまい。

ということで、寝ながらPCをいじれるように、最近巷に増殖しつつあるタブレットPCなるものを買ってみようかと考えてみた。いろいろと比較検討すると、MSIのWindPad 110W 110W-017JPがいいようにも思われるのが多、しかしまだ供給量が少なく、手に入れるのは難しい要だ。それに6万近くするのはいくら何でも高すぎる。

仕方がないから、小さいディスプレイとキーボードとマウスを一式買って、今使っているPCに接続することにしておいた。すなわち、1台のマシンにディスプレイ・キーボード・マウスがそれぞれ2つずつ接続されると言うことになる。

そうした場合、それぞれのデバイスを別々に使って、複数のユーザが同時にログインできるようにしたいと思われる。単なるマルチディスプレイではどうにも使い勝手が悪いからだ。

そういう場合、MultiPoint Serverとかいうやつを使ってやると、どうもいい感じにできそうな気がする。しかしながら、それをやるためにはOSの再インストールを環境の再構築が必須になる。

これはちょっとばかりリスクが大きい。まぁ、せっかくの休みなのだから、ちょっとやってみることにしよう。

仮想ディスクイメージは穴だらけだった

2011-07-14T21:53:00.005+09:00

仮想OSのディスクイメージなどの大きなファイルをスパースファイルに変換して、0が連続している部分をスパースにしてやると実際に使用するディスク領域を節約することができる。前回はコマンドで実行するようなかきすてのコードだったのだが、それをもうちょっとまともなツールに仕立て上げてみた。まぁ、余り深い意味はない。

コマンドで実行するよりもはずっと使いやすい。ただそれだけである。

一応、ファイルのスパースがどういう状態で存在するのか、グラフを表示する機能もつけてみた。もっとも、それを見たところで、どうにもならないのだが。

赤いところがスパースのある部分である。

こうやってみると、使用されている領域というのは、結構不均等に存在するものらしい。一応、この処理をやる前には、仮想OS内で最適化を実行してはいるのだが。

スパースファイルにしてディスクイメージを縮めてみろ

2011-06-19T15:06:00.005+09:00

Oracle Virtual Boxの仮想ディスクイメージは、他の仮想化ソフトと同じように可変サイズのディスクイメージというのをサポートしている。つまり、仮想OSに対して、例えば50GBのディスク領域を割り当てたとしても、実際に使用する分しかディスクイメージのファイルは割り当てられないというやつだ。これを使うと、物理ディスクの領域を節約することができて、何かといいことがある。

しかしながら、仮想ディスクイメージはサイズが大きくなる一方で、小さくなることはないという性質がある。例えば、50GBのうちある時40GB使っていたとすると、仮想ディスクイメージは少なくとも40GBのサイズになる。その後、仮想OSでのディスク使用量が少なくなって10GBまで減ったとしても、40GBまで膨れあがった仮想ディスクイメージが縮むことはない。

まぁ、仕方がないといえば仕方がないのだろう。だが、その領域は完全に無駄であり節約したくなってくる。ましてディスクが足りなくなる可能性があるときには尚更だ。

そういうことで、ちょっと安直な対応方法を思いついたのでやってみることにした。

まず、仮想OSを立ち上げて最適化する。次に、ディスクフルを引き起こすまで空き領域を0で塗りつぶす。具体的には下記のようなプログラムを実行する。

int _tmain(int argc, _TCHAR* argv[])
{
char buf[4096] = { 0 };
DWORD WroteSize = 0;
HANDLE h = CreateFile(
argv[1], GENERIC_WRITE, 0, NULL,
CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL
);
while ( ::WriteFile( h, buf, sizeof( buf ), &WroteSize, NULL ) );
CloseHandle( h );
DeleteFile( argv[1] );
return 0;
}

次に仮想OSを落として、ディスクイメージのファイルを直接スパースファイルにして0の部分をスキップするようにしてしまう。

そうすることで、「かつて使われていた部分」も含めて空き領域を全て排除することが可能になる。

実例を挙げるとこうなる。

まずは変換前の状態。

全部で152GBある。また、これらは通常のファイルであり、見た目のサイズと実際のサイズは同じである。

これらのファイルに対して、上記のような操作を加えてファイルの圧縮を図る。

するとこうなる。

論理的には何も変わっていないにもかかわらず、40GBぐらいディスク領域を捻出することができた。まぁ、とりあえず良かったと言うことで。

ディスプレイが大きい

2011-06-07T21:41:00.004+09:00

ディスプレイを新調した。DellのU3011である。前から欲しいと思っていたが、ついに買ってしまった。

とりあえずでかい。2560×1600である。

右上にある草原の壁紙を設定しているのが、1920×1080のWindows XP 32bitである。左上にあるのが1024×768のWindows XP 64bitである。

フルHDが小さく見えて笑えてくる。

すでにして暑い

2011-05-30T21:52:00.001+09:00

大きな声では言えないが、例年、俺がいる職場では夏場は寒いぐらいにエアコンをつけて、非常に快適な環境を維持している。客の親会社では、夏場は冷房はもとより照明も消して耐えているというのに、システム屋のベンダーはその努力を無にする不届き千万な行いをしてきていた。だが、さすがに今年はそうもいかないようだ。

すでにして室内は暗く、日中は蒸し暑い。不景気なせいで仕事が無いから人間は少ないが、それでもPCは置いてあるし、風通しは悪いし、不快なことこの上ない。

今の季節からすでにこれでは、夏場が思いやられる。どれほど暑くてもスーツの上着は脱がない主義の俺でも、今年ばかりは挫折するしかないようだ。

とりあえず、早いうちに扇風機だけは持ち込んでおくことにしよう。

Blogのデザインを変更して集客力向上

2011-05-22T12:47:00.002+09:00

内容はさして変わっていないが、デザインだけ変えてみた。

世の中一般では、Blogは1ページに1エントリが普通らしい。複数表示しているところは存外少ないようだ。そういうことで、俺もそれに習ってみた。

広告は、右側に縦に表示していたやつを上に持ってきた。目立って良くないと思っていたが、世の中的には内容が1割で広告が9割とか言うのも普通にあるわけだし、まぁ、多少は目立たせても問題あるまいという方向に考えを変えることにした。

そうすると、全体に内容が減って広告が増えることになるので、ちょっと見栄えが良くなくなる。仕方がないから、ちょっとした賑やかしとして、右側にIPAが出しているセキュリティ情報を表示しておくことにした。

元ネタはRSSなのだが、意外なことにRSSを編集してWebページの一部として表示するのは、それほど簡単ではないらしい。検索すれば、コピペで終わらせられるようなJavaScriptぐらい転がっているだろうと思っていたのだが、どうやらセキュリティ上の理由とか何とかで、サーバ側の処理がいるらしい。まぁ、仕方がないか。

これで多少なりとも良くなっただろうか？　俺的には全く変わった気はしていないが。

Windows Home Serverを使う価値はあるか？

2011-05-15T18:47:00.004+09:00

一応気になるので、Windows Home Server 2011について考えてみる。

現時点で、サーバ用にWindows Server 2008 R2 Standerdを（評価用に）使用しているが、この環境を壊してWindows Home Server 2011にする価値があるのか無いのか。検索しても余りまともな評価もみられなかったので、とりあえずVirtual Boxに入れることにしてみた。

まぁ、ライセンス認証をしなければ失うものは何もあるまい。

まず、何が必要かと言えば、下記の機能がサポートされていなければならない。
(1)Active Directory
(2)DNSサーバ
(3)ASP.NET
(4)SQL Server

SQL Serverはいずれにせよ後から入れなければならないので、まぁ問題ない。気になるのはActiv DirectoryやDNS・ASP.NETが使えるか否かである。

旧バージョンのWindows Home Serverを確認する限りでは使えそうだったのだが、2011になってからどうなったのか。

■ハードウェア要件
・CPU　　: 1.4Ghz以上（x64のみ　最大1CPU）
・メモリ　：最小2GB 最大8GB
・HDD　　：最小160GB

不思議なことに、MicrosoftのWebページにはHDDは80GB以上と書かれており、製品カタログのPDFファイルには64GB以上と記載されている。だが、実際にインストールしてみると160GB以上無いとインストールできないといって怒られる。

■インストール
インストール直後の画面

旧バージョンの時は警告画面はWebページだったが、今回は壁紙になっている。
なお、デフォルトを選択可能な壁紙は、上記のものと以下のもののみである。

Windows Server 2008 R2であることを隠そうともしていない。
せめて壁紙のロゴぐらい設定しろよ。

あと、とりあえずシステム情報。

なぜか知らないが、いきなりService Pack 1である。

■サーバマネージャ
Windows Server 2008で導入されたサーバマネージャという機能があるが、これがHome Server 2011でも使えるようだ。というか、2008のものと全く同じにしか見えない。

■役割の追加
ここまで同じなら、ActiveDirectoryも使えるのではないか？
ということで早速「役割の追加」を開いてみる。

だが、ActiveDirectoryドメインサービスが見あたらない。IISもDNSもあるのに、ActiveDirectoryだけが機能に制約があるように見える。

Home Server 2011はドメインコントローラにはなれないのだろうか？　検索してみると、どうやらドメインコントローラどころか、クライアントとしてドメインに参加することすらできないらしい。（本当なのか？）

だとすると、今のサーバー機をWindows Home server 2011にリプレースするのはやめた方がいいようだ。

MS製品を落とせるうちに落としまくっておけ

2011-05-07T12:45:00.003+09:00

MSDNサブスクリプションを購入して、インストーラのイメージディスクとライセンスキーが取得できるようになるのは1年間に限定される。また、MSDNのライセンスについての注意書きをよく読むと、それ以外の制約条件は下記のようになるようだ。

１．インストーラなどがダウンロードできるのは1年間のみ。
２．新規にライセンスキーを取得できるのは1年間のみ。
３．期間内にインストーラとキーを取得しておけば、期間が過ぎた後でもソフトウェアを使うことができる。これはアクティベーションが必要なソフトウェアも含まれる。
４．アクティベーションが必要なソフトウェアのライセンスキーは最大で10個取得できる。また、1つのライセンスキーで少なくとも10回はアクティベーションが許可される。

MSDNの期間内であれば、上記のような些末な条件は余り考慮する必要はない。Windows 7やWindows XP等は最大で100回しかアクティベーションできない。しかし、1年間で100回アクティベーションするためには3日に1回はインストールすると言うことを意味しており、それだったらそもそもアクティベーションしないで使えばいいので（しなくても30日は使えるから）、回数制限に意味がないのである。

だが、期間を経過してしまったらどうなるのか。

MSDNサブスクリプションを継続して購入すれば問題はないのだろうが、そういう予算がつかなかった場合は、そこで契約が切れることになる。その場合、新規にソフトウェアをダウンロードできなくなる。また、ライセンスキーも取得できなくなる。

ということはだ、MSDNを購入したら使うか使わないかに関わりなく、とりあえずダウンロードできるものは全部落としておき、ライセンスキーも手当たり次第に全部取得しておくべきだと言うことになる。

ここで気になるのは、ある一つのキーについて、アクティベーション可能な回数を全部使い切っていない状態で他のキーを取得してとして、元のキーは無効になったりすることはないのかと言うことである。つまり、あるキーKEY1を取得し、それをまだ1回しか使っていない状態で、追加のキーKEY2・KEY3・KEY4を取得してもいいのか、KEY1はKEY2を取得したときに無効化されたりしないのか、ということである。

これはちょっと不安だから、余り必要でなさそうなVirtual Server 2005を使って試してみた。

取得できるキーを10個分全部取得してしまってから、取得したいろいろなキーを入れて認証を試みてみた。すると、どのキーでも正常にチェックをパスした。ということは、やはり当初の予想通りキーは全部先に取っておいてしまった方がいいと言うことになる。だから面倒だったが、休みのうちにライセンスキーの取得をやっておいた。

また、期間が過ぎるとライセンスキーを表示するMSDNのWebページが参照できなくなるらしいから、XMLファイルでライセンスキーをエクスポートしておいた。でもって、そのXMLファイルをCSVに変換するツールを自作して、表計算ソフトに取り込んで印刷しておいた。

ここまでしておけば、使った金を余すことなく有効活用できるだろう。

個人情報漏洩にみる不祥事隠蔽についての一考察

2011-05-04T08:16:00.002+09:00

くだらないことを考えてみる。

一般的に、ある程度の事業規模がある企業では不祥事の隠蔽を図る専門部署を設けている。当然、部署名はCSRだのコンプライアンスだの、あるいは広報部だのと言うもっともらしい名前を名乗っていて、不祥事の隠蔽などと言うことはおくびにも出さないが。

俺が今勤めている会社でも、社会一般ではほとんど知られてはいないが年に一度は営業停止処分をくらうような悪事をちょびちょびとやらかしている。まぁ、談合とか贈賄とか、そういったやつだ。それでも世間様から非難を浴びないのは、上記の組織が暗躍しているからに他ならない。

例えば下記のような例を考えてみる。

・4月6日（水）　児童３１６人の個人情報紛失
・4月7日（木）　障害者施設長が個人情報を紛失（70人分）
・4月13日（水）　阪急交通社、ツアー利用客の個人情報３７人分を紛失
・4月18日（月）　卒業生２４人の個人情報紛失
・4月19日（火）　児童調査書ひったくり（34人分）
・4月20日（水）　タニタ　個人情報５５２人分紛失
・4月22日（金）　愛媛日産、７万３０００人分の顧客情報流出
・4月26日（火）　SCE、PSN/Qriocityで個人情報流出の可能性

26日のソニーの事件は扱いが大きく、さすがに飽きられてきた原発や地震関連のニュースを圧倒して、27日以降はソニーバッシングが隆盛を極めている。

その後、次のような発表が行われている。
・5月2日（月）　東京海上日動、２５１６人分の顧客情報紛失
・5月2日（月）　郵政３社、顧客情報３２万件を紛失…誤廃棄か

どちらも2日、すなわち、26日以降の最初の月曜日である。また、東京海上日動は4月7日には判明していた紛失をこのタイミングで発表している。郵政グループに至っては2010年11月に判明していたものである。

どちらもタイミングを図っていたのは明らかである。

個人情報漏洩のような不祥事が社内で起きたとき、その対応にはいくつかの鉄則がある。その一つに、必ず公表するということがある。もし組織で隠蔽しようとすると、後でそのことがばれると大変なことになる。たとえそれが小さなことであったとしても、隠蔽しようとしたという事実そのものがバッシングの対象になる。だから、不祥事はゲロしてしまわなくてはならない。

だがここにもう一つ圧力がある。それは不祥事によるイメージダウンを避けるという要求である。当然だ。営利企業である限りイメージダウンは避けなければならないし、そうでなくてもバッシングは受けたくないものだ。

だから、上記二つの要求を満たす方法を考えなくてはならない。それが「目立たないように発表する」という作戦だ。

要は隠蔽しないで公表しさえすればいいのであって、必ずしも目立つ必要はないのである。だから、不祥事は他企業における類似する不祥事の陰に隠れて発表するのである。具体的にはソニーがバッシングを受けている隙に、うちもやりましたと言ってゲロするのである。そうすれば、公表したという事実は残るが注目は浴びなくて済むのである。

また、細かいテクニックはいろいろあるのだろうが、不祥事はあえて月曜日に発表するという話を聞いたことがある。これは月曜日には土日に生じたニュースがまとめて報じられるから、月曜日に発表すればほかのニュースに薄められて目立たないという理屈らしい。

俺のいる会社でも、談合や贈賄を同じ手口で隠蔽しているようだ。無論、営業停止処分を受けているぐらいだから公表はしているし、官公庁から会社名も公表されてはいる。だが、世間の注目を浴びないように、大手ゼネコンでの談合や贈収賄事件に紛れて表沙汰にしている。

こう言っては何だが、公式に与えられる罰則である数日間の営業停止処分や、数百万円の罰金などは、企業会計からみれば痛くも痒くも何ともないのである。罰金なんて、それこそ小数点以下四捨五入、誤差の範囲でしかない。不祥事をやらかして一番困るのは世間様からのバッシングを受けることであるが、これさえ逃れることができてしまえばなんと言うこともないのである。

そういう意味では、今は個人情報流出と食中毒事件が世間を賑わわせていることから、この関連の不祥事であれば、発表するのは今だと言うことになる。

だから、休み明けの6日や9日には、多分何件かこの手の発表があるのではないだろうか？

松井証券のテクニカルチャートって動かなくね？

2011-05-02T09:33:00.007+09:00

松井証券のFXで、JavaAppletを使用したテクニカルチャートというツールがある。しかし、俺の環境ではブラウザごとフリーズしてまともに動作しない。DSP版ではあるが、ちゃんと金を出して買ったx64版Windows 7 Professionalで、IE8で、Javaのランタイムも最新版を適用して実行しても、状況が改善されない。

しかしまぁ、余り一般的でないと思われる物も含めて様々なソフトが同居しているから、その中の何かが悪さをしているのかもしれない。

ということで、環境を変えてやってみた。

まずはWindows2000（IE6.0/JRE1.6.0_25）

エラーがある？

証明書の期限が切れている！

これは恥ずかしい。　内部の管理体制をが大いに疑われる。

いや待て、Windows2000でIE6.0なのがいけないのかもしれない。ということで、Windows XP SP3（IE8.0/JRE1.6.0_25）でやってみることにした。

フリーズした。Windows 7の場合と同じである。こうなるとJava VMとIEのプロセスを殺すしかなくなるため始末に悪い。

XPと7とで症状が同じと言うことは、ブラウザの問題だろうか？　IE6で表示されたセキュリティ警告の件もあるし、ちょっとブラウザの設定を変更してセキュリティを緩めてやってみたが、状況が変わらない。何がいけないのだろうか？

動作環境をよく確認してみると、これはIE6.0と7.0しかサポートしていないらしい。昨今、IE9.0が公開されたというにも関わらずである。

仕方がないから、IE8.0を抜いてIE7.0を入れた状態でやってみた。だが、状況は全く変わらない。

（わかりにくいが、上記はIE7.0である）

しかも、Javaのランタイムがものすごい勢いで暴走している。

セキュリティにせよバグにせよ、いずれにせよかなり恥ずかしい状態であることには違いがあるまい。もっとも俺は、FXはほとんどやらないからたいした問題じゃないんだがな。

三度目の技術士

2011-04-24T17:53:00.002+09:00

技術士の二次試験の申込用紙を出してきた。これで三度目である。

去年まではWebで申し込むことができたのだが、今年からは全ての手続きが旧態依然としたアナログに変わっていた。まぁ、どっちにしろ会社の公印を押した紙を提出しなければならない以上、大して手間に違いないと言えばそれまでだが。

情報処理技術者試験の場合、受付期間中であればWebで全ての手続きができるから、受験の手続きはかなり簡単である。それに対して技術士の場合は、書かなければいけない書類の内容も難しいし、業務経歴に対して、勤務先の代表者権限による公印による証明とやらが必要だし、金の振り込みも郵便局にいってやらなければならないし、非常に面倒である。

しかも高いし。

除湿しすぎた除湿剤の末路に関する観察

2011-04-16T15:23:00.005+09:00

西友だったか100円ショップだったか忘れたが、どこかで買ったドライペットである。

仕掛けてから数年、捨てようと思い蓋を開けたが、中から廃液が出てこない。不審に思い中を覗くと何か固まりが詰まっていた。

逆さにしても出てこないので、ドライバーで突き崩して取り出してみた。

見た目は氷に酷似している。だが冷たくはない。

水で洗ってみたら、溶けてどんどん小さくなっていった。

なんだかよく分からないが、いずれにせよロクでもない代物だと思われるので、そのままゴミ箱に捨てておいた。

せっかくだから

2011-02-27T18:13:00.003+09:00

中古のデジカメを買ったのだが、PCのパーツを写す以外に使い道がないのももったいないので、とりあえず適当にその辺の写真を撮ってきてみた。

ちょっと位置を変えてもう一枚。

川よりも空を撮った方が良かったかもしれない。

仮想OS

2011-02-13T15:32:00.003+09:00

MSDNを買って様々なバージョンのWindowsを使えるようになったのだが、ちょっといろいろとやってみようかと思い仮想化した環境でインストールしてみている。だが、ディスク容量が不足して困ったことになった。

メモリとディスクは常に一杯になるという法則があるが、腐るほど使えるようになったとはいえこの法則は未だ健在なようだ。

デフラグ画面の経年劣化が深刻化している

2011-02-11T22:08:00.007+09:00

Windowsには昔からディスクの最適化を行う機能が搭載されているのだが、この画面はバージョンが上がるに従って簡略化されてきている。

■Windows 98

Windows 95や98では、本当だかどうだかは知らないが、クラスタ単位で状況がグラフィカルに表示され、デフラグの進捗をみているだけでも楽しかったものだ。

■Windows 2000

だいぶ手を抜いている気がするが、それでも状況がグラフィカルに表示されている。

■Windows Home Server

Windows 2000と同じである。この画面はVistaが現れるまで使われるためかなり寿命が長かったようだ。

■Windows Vista

最悪である。

断片化やデフラグの状況が分からないどころではない。進捗すら表示されない。そもそも「数分から数時間かかります」って一体何なのか？　何の質問にも答えていない。やる気がないにも程がある。さすがに悪名高いVistaなだけあって、デフラグ画面ですらクソである。

■Windows 7

フォントが汚いことや状況が分からないといった著しい劣化はVistaの頃から変わっていない。しかしながら、進捗だけは表示されるようにはなった。進捗だけは。その意味では少しだけ改善がみられるということができる。

昔を懐かしむということでもないが、なぜに変更する必要のない部分をいじって劣化させていくのだろうか？　俺には理解できない。

特定用途で用いる画像を格納・閲覧するWebシステムの構築について

2011-02-09T20:29:00.007+09:00

最近リプレースしたSolaris8のマシンには、ある「特定用途」で使用する画像を格納・閲覧するための自作ソフトが入っていた。しかし、そのマシンをリプレースしてしまったため、代替となるソフトを作らなくてはならなくなった。

もっとも、そのソフトは全てJavaで作ってあったため、理論的にはWindowsにそのまま移植することはできた。だが、作りが余り良くないことなどを考え、ASP.NETで作り直すことにしたのだ。

それで、できたのがこんなやつ。

（１）格納してある画像を一覧表示することができる。

（２）当然だが、原寸大の絵を表示することもできる。

なお、当然だが、上記サンプルでは当たり障りない絵を使用している。実際には、インターネットでかき集めてきた「特定用途」の画像が格納・表示されることになる。

上記（２）の画面では、キーボードの操作により次の絵や前の絵を表示させることができる。これは、使用中には右手が塞がっており、マウスを操作することが困難だからという事情による。それ以外にも画像の分類分けや表示する順番など、使用用途に適応したいくつかの機能が実装されている。

本来であれば、せっかく作ったソフトなので公開したいところではあるのだが、なにぶんASP.NETで作ってありIISやSQL Serverが必須なため、気軽に配布できるようにはできていない。まぁ、こればかりは自分一人で使い続けるしかないだろう。

HDD

2011-02-01T23:25:00.002+09:00

メインマインのHDDがまたしても壊れた。しかも、前回壊れたやつと同じところに刺さっていたやつだ。ついでにいうと、サーバ用高耐久モデルとかいう、普通のやつよりも2倍ぐらいする高級品だ。それが認識すらされなくなった。

1番のポートは呪われているのか、悪霊が取り憑いているのか、さもなくば上から二番目のシャドウベイだけ特別に悪い電波を受けやすいのか。理由はしらんが出費がかさんで痛い。

しかし、これだけ頻繁に壊れるとなると、さすがに全体的な品質を疑わざるを得ない。この会社の背品は、今後買わないことにしよう。

廃棄

2011-01-15T16:16:00.007+09:00

ところで、IntelのSSDを買ってきたら、Kingstonの4GBのUSBメモリが1つづつついてきた。RAID0+1にする都合上4つ買っているため、USBメモリも4つある。

しかし、LANですべてのマシンをつないでいる以上、USBメモリは全く使い道がない。バックアップの媒体に使うにも信頼性がないし、いったいどうしろというのか。

古いマシンが引退するということは、そのマシンを廃棄しなければならないということを意味する。しかし、PC（ではないのだが）を処分するのは金がかかるし、何より手間がかかる。ということで、ばらして、小さくして、少しずつ不燃ゴミとして処分することにした。

まず、元々はこんなやつ。

これを素手とドライバーとゴムハンマーで解体する。

中央左寄りに見えているのはCPUのヒートシンクである。Blade100のCPUはファンレスであり、TDPの割にはちょっと大きめのヒートシンクがついている。

CPU本体は記念に残しておく。無論、全く何の役にも立たない。

破壊工作をの後は証拠隠滅を図る必要がある。

後は毎月第二・第四月曜日に、目立たないように排出していけばいいだけだ。

買った

2011-01-10T23:08:00.009+09:00

とうとうSunのBlade 100が退役して、新人を投入する時期が来た。

とりあえず、下記のような構成にしてみた。
M/B : ZOTAC M880G-ITX
CPU : AMD Turion II Neo K625（オンボード）
メモリ：8GB
ディスク：120GB SSD × 4　（RAID0+1）
CPUファンなど：600rpm 14cmファン1つのみ

ZOTAC M880G-ITXは、説明のWebページにもマニュアルにも説明書にも、RAID0・1・0+1・5に対応していると書かれている。しかし、実際にやってみたところ、RAID0・1・0+1・JOBDにか対応していない。RAID5はできなかった。

何かの間違いかと思っていろいろと調べてみたが、BIOSのバージョンは当然最新の状態になっているし、ほかにアップデートするべきものもなさそうだし、何かをすればRAID5が有効になるとも思えなかったので、諦めることにした。

使用しているチップセットは「AMD M880G + SB820M chipset」と書かれている。この記載が正しいのかどうかまでは確認していないが、もし正しいのだとしたら、おそらくRAID5は仕様上サポートできないはずである。AMDのSB820Mのドキュメントを確認する限りでは、RAID5という記載はない。まぁ、マニュアルと広告の間違いということなのだろう。

とりあえず、物を組んでいるときの写真を晒す。

マザーボードと14cmファンである。ついでにいうと、M880G-ITXはmini-ITXなので、基盤のサイズは一辺17cmである。

AC電源と14cmファンである。M/Bのマニュアルには、最小でも300Wの電源を用意しろと書かれていた。

Intel製の120GBのSSDである。

余談だが、以前とあるシステムでIntelのチップを使った高級品のCFカードを大量に仕入れて使ったことがあるのだが、それの故障率が異常に高くてひどい目に遭わされたという経験がある。（数千枚のCFカードが一日あたり5%程度ずつ壊れていくのだ。客になんと言って土下座すればいいのか、俺には思いつかなかった）。

それを考えると、IntelのSSDがまともに動くかどうかはかなり疑わしいと言わざるを得ない。だが、いろいろ考えてとりあえずこれにしておいてみた。もしすぐに壊れたら、今後二度とIntelの製品は買わないことしよう。

ケースにマザーボードをつけてみた。この時点ではすでにM/Bに付属する6cmファンは取り外してある。

ゴミの山。

すべての配線を終えて、ファンも取り付けた状態。

ファンはファンステイでM/Bの真上に来るようにして固定している。元々は、ケースの上に14cmファンを取り付ける穴があったからそこにつけていたのだが、そうするとNorthbridgeが異常に加熱するという問題が生じたから、仕方なくこうなった。

当初の構成案を下図に示す。これだと、なんだかよく分からないチップのヒートシンクに阻まれて、Northbridgeが冷やされない。

だから、急遽ファンステイとか言うやつを買ってきて、上記の写真にあるようにM/Bに覆い被さるような形にした。これなら、いくら何でも冷えるというものだ。

ケースのふたを閉めて、斜め上から撮ってみた。

中に見えている銀色のやつがCPUのヒートシンクである。

元々ついている6cmのヒートシンクは、当然だがそれなりに騒音があり、24時間起動しっぱなしにしておくのには難があるわけだが、低速で回る14cmファンなら問題はない。なめらか秒針が回る無音のアナログ時計のモーター音よりもは静かである。

後はこれを使って、ソフトウェア方面の環境を整えてやる作業が残っている。

買えなかった

2011-01-02T15:06:00.000+09:00

たまには金を浪費したところで罰は当たるまいと覚悟を決めて、二日続けて秋葉原に行っては見たものの、年末年始で金をおろすことができなかったから、結局何も買わずに帰ってきてしまった。交通費だけが無駄になった。

いったん仕切り直して、ケースとUPSについても慎重に品定めを進めた上で、今一度機会を伺って買いに行くことにしよう。その頃には「ZOTAC M880G-ITX」への人柱も十分に沈められ、情報があがってくることだろう。

俺としては、Active DirectoryやDNSサーバ・WSUSを使いたいから、作ったPCにはWindows Server 2008を入れたいと考えている。x86である以上、CPUやメモリが何であったとしても動かないということはないはずではある。だが、俺の経験則からいって変なOSを入れようとした場合、グラフィックとネットワークのドライバが正常に認識されずに頓挫することが多い。それ以外のデバイスはどうにかすれば使えるようになるか、あるいは諦められるのだが、この二つばかりはどうにもならない。

まぁ、純粋にサーバとして使うのだから、グラフィックはたとえVGA表示になってしまったとしても、OSのインストールさえできればそれでいい。だが、ネットワークが使えないとなったら目も当てられない。そう考えると、そのあたりの正否についてもう少し情報が出てくるのを待った方が利口かも知れない。

いずれにせよ、金がなければ買うことはできないんだがな。

リプレース

2011-01-01T16:39:00.001+09:00

昔買ったSunのBlade100をエロ画像サーバとして使っているが、さすがに老朽化してきたこともあり、リプレースを考えている。

買い換えるのでれば常時通電しておけるような静音マシンにしたいのだが、それがどうにも難しいようだ。いろいろ調べてはいるのだが、やはり、完全ファンレスは敷居が高いらしい。そういうことで、低消費電力型のCPUか何かを使って、最小限の冷却ファンでまかなうことを考えている。とりあえず、マザーボードとCPUとしては「ZOTAC M880G-ITX」のあたりを候補に挙げている。情報があまりないが、大丈夫だろうか？

意を決して、今日、買う気で秋葉原までいってみた。だが、例年のごとく初日はやっていない店が多い。結局、何も買わずに帰ってきた。

そもそも、ケースを何にするのかがまだ決まっていない。どれがいいのだろうか？　そもそも、予算をケチるべきか、思い切って出しておくべきか、その方向性すら決まらない。　悩ましいものだ。

Windows 98

2010-12-12T18:15:00.007+09:00

意味はないがWindows 98を買ってきてみた。

現在ではMSDNでもWindows XP以降しかダウンロードできず、9x系のOSを手に入れることはできない。しかし、秋葉原のジャンク屋でWindows 98を売っていたから半ば衝動買いしてみた。

セットアップ中の画面である。

なお、セットアップ直後にWindows Updateを試みたが、IE4.0がフリーズしてパッチを落とすことができなかった。嘘ばっかり書くんじゃない。

もう一枚セットアップ中の画面。

2000年対応も万全だそうだ。だが、今は2010年である。

起動時の画面。

ここまで来る間に、数回再インストールをやり直している。ついでにいうと、この画面をキャプチャした後にも、何回かやり直している。さすがに無印98はじゃじゃ馬である。

起動した。

画面の色が16色表示な上に解像度が640x480で作業しづらい。だが、Virtual BoxにはWindows 98用のディスプレイドライバは添付されておらず、これ以上、どうしようもないらしい。

と思ったが、検索したら同じようなことをやっている人間が結構いるらしい。こんな情報が出てきた。

とりあえず、書いてあるとおりにディスプレイのドライバを落としてきて入れてみると、まともに表示されるようになった。

なお、この時点ではまだIE4.0である。

IE4.0ではMicrosoftのWebページを表示することができず、IEのバージョンアップすらできない。仕方がないから、ホストOSのWindows Server 2008でIE6.0を落としてきて、それを使って98のIEを6.0にした。

まぁそう書くだけなら簡単なのだが、実際にはこの作業だけでも結構苦労している。

不思議なことに、マインスイーパーやソリティアなどのゲームはデフォルトではインストールされず、Windows Updateで配られていた。深い意味はないが、とりあえず入れてみた。

ディスプレイドライバの設定なのかコマンドプロンプトの設定なのか、原因は分からないがMS-DOSプロンプトを起動しようとすると、画面の表示が乱れる。

無論、このままでは操作できないから、再起動するほか無くなる。

まぁ、Win98を入れて何に使うかと問われても微妙に困るのだが。とりあえず、「鋼鉄のガールフレンド」を入れてみた。

昔は動画の表示は辛かったのだが、今は何の苦もなく動作する。しかも、音もちゃんと再生される。仮想環境の上なのに。

いれてみた

2010-08-22T23:34:00.003+09:00

ホストOSとしてWindows Server 2008 R2 Standerdを、ゲストOSとして今まで使っていたWindows 2000 Professional(32bit)、新しく落としてきたWindows XP Professional(32bit)とWindows Vista Ultimate(64bit)を入れて起動してみた。

ついでにFedraをいれて、こんな感じになった。

しかし、間違ってVistaに割り当てるメモリを512MBで起動してしまった上にアップデートをやってしまったから、いつまでたっても終わらない。ホストOSにはまだ十分にメモリが余っているのに、一人でスラッシングを発生させて、一人で勝手に大変な騒ぎを演じている。

そろそろ、VMを殺してしまおうかどうか悩み始めている。

VS2010

2010-08-15T13:19:00.003+09:00

ついにVisual Studio 2010 Professional with MSDNを手に入れた。当初の予定では6月ぐらいには購入する予定だったのだが、本業が忙しくてそれどころではなかったため延期していた。しかし、技術士2次試験（筆記）も終わり、少しだけ余裕ができたから思い切って買ってしまった。

買ったはいいが、悩ましいのはOSをどうするのかという問題である。せっかくのMSDNである。様々なバージョンのWindowsをインストールできるという権利である。これをを使わないのではMSDN付きで買った意味がない。そもそも送られてきたメディアに、すでにしてWindows Server 2008 StanderdとWindows 7 Ultimateが付属しているのだ。どう考えても、使わないわけにはいかないだろう。

現状、使用しているOSはWindows 7 Professionalである。電源BOXと一緒に買ったDSP版だ。これをWindows Server 2008 R2 Standerdに変えるか、Windows 7 Ultimateに変えるか、それとも変えないか、悩ましいところである。

7のProとUltimateにはたいして違いがなさそうである。持ち歩く気の更々ないデスクトップPCでBitLockerとかいうものを使う気はしないし、そう考えると、わざわざ労力をかけて入れ替える気力はわいてこない。してみると、Windows Server 2008にするのが妥当だろうか？　その上で、Hyper-Vとかいうもので各種バージョンのWindowsを動作させれば、多少はおもしろいことになるのではないか。

せっかく作った環境を作り直すのも辛いといえば辛いが、まぁ、ゆっくりと考えることにしよう。

話題

2010-05-08T19:58:00.001+09:00

近年、インメモリデータベースとかいうものが出てきて、話題になっているらしい。俺が今やっているシステムでも、このインメモリDBを使うとか、使わないとかいう検討をやっている。

いろいろな事情があり、Oracleの人が来て「性能要件が厳しいからTimesTenを使うといいです」というようなアピールをしていった。しかし、こういっては何だが、実を言うとそれほど大変な性能を求められるということでもないようだ。

更新するレコードは秒あたり数件ぐらいだし、参照だって1日に一度バッチ処理で参照する以外は、更新のために見るというだけである。

ネットの記事を見る限りでは、普通のOracleでも数万件／秒の更新ができると書いてる。話を100倍ぐらいに膨らませて書いてあるとみたって、数百件／秒はできるだろう。そう考えると、強いて目新しいものに手を出す必要はないような気がしてくる。

ぶっちゃけていえば何を使ったってできるはずである。それなのに、製品選定の比較検討で丸二ヶ月忙殺されていて、正直言って疲れた。他にもやらなければならないことは山ほどあるはずなのだが、なぜにDBだけでこれほど振り回されなければならないのだろうか。

組織とは不思議なもので、一度やり玉に挙げられると徹底的に叩かれるという性質がある。今回のDBがいい例だ。比較検討を行うのならOSやCPUだって検討しなければならないはずなのに、一度も何の議論も行われることもなくx86のLinuxだと決定してしまった。他のソフトにしても同様だ。それなのに、DBMSだけはいつまでも揉めている。

他にも例はある。俺が勤めている会社はベンダーである都合上、社内では常にいくつかのプロジェクトが平行して走っている。そして、その中で目立つ案件についてはエラい人に目をつけられて、いろいろと締め上げられるという悪しき慣例がある。

ではどういう条件で絞めるプロジェクトが決定されるのかというと、その判断基準は非常に曖昧である。ある程度は規模に比例するらしいのだが、必ずしもそうとは限らない。納期が厳しいとか、金がないとか、そういった基準でもないらしい。どうやら「話題に上った」プロジェクトが絞め殺される対象になるらしいのである。

ということは、世の中をうまく渡っていくためには、言葉を変えるのならプロジェクトを滞りなく進めて安定して利益を得るためには、とにかく目をつけられないこと、話題に上らせないことが重要であるといえる。誰にも何も気づかれないうちに全てを片付けてしまうこと。これに尽きる。そうすれば、全く報われることのない、無用な苦しみから逃れることが可能となるはずである。

タスクバーの色

2010-04-21T23:27:00.006+09:00

Windows 7の見てくれを派手にしたときのタスクバーの色は何によって決定されるのか。

たとえば、「マイコンピューター」は青である。

また、ペイントは薄い青であり、

古いMSDNは黄色だ。

まぁ、明らかにアイコンの色を使っているのだろうが、この色はどうやって決定しているのだろうか。とりあえず、いろいろと試してみた。

まず、こんなアイコン。すなわち、全部背景色の場合。

薄い青になった。

ちょっと複雑なパターン。周囲が赤で中が緑、わかりにくいが、四隅に青・黒・水色・黄色を設定してある。

緑になった。

紫ではない。1ドットづつ赤と青を交互に並べてある。

青くなった。

ならば、上記と同じパターンで青を黒に、赤を黄色に変えてみた。つまり、青と黒は同じ位置に存在し、かつ、赤と黄色は同じ位置に存在している。これでもし黄色が採用されたのであれば、ある特定の位置にあるドットを採用しているのではないと断言することができる。

予想通り黄色になった。

ここまでやると、だいたいどういうアルゴリズムを使っているのかが解ってくる。おそらく、アイコン中でもっとも彩度が高い色を採用しているのだろうと推定される。

ということで、今度は黒く塗りつぶした中で、1ドットだけ赤紫を入れたアイコンを作ってみた。

やはり赤紫である。

だったら、全部黒くしてしまったらどうなるのか。

薄い青になった。

どうやら、アイコン中に彩度の高い色がなかった場合には、この薄い青を使うようだ。

たとえば、下記のような白・灰・黒からなるアイコンだと、

薄い青になる。

まぁ、こんなことを調べてもどうしようもないのだが。

とりあえず、パッケージソフトウェアを作るのでれば、タスクバーの色がコーポレートカラーにるよう意識してもいいのかもしれない。

冷却

2010-04-17T11:32:00.004+09:00

RAIDカードが熱いという問題があり増設を延期していたのだが、調べてみると、やはり同じような問題に悩む人は多いらしい。拡張スロットに取り付けるブロアファンなるものがいくつか発売されていた。その中でも、ちょうど良さそうだったから、PC AIRCONなる製品を買ってきて、付けておくことにした。

とりあえず、写真を曝すとこんな感じになった。

中程にある大きなファンはCPUクーラーである。その下に拡張ボードが並んでいる。RAIDカードと冷却ファンは一番下に存在する。

RAIDカード周辺である。

画面中央に写っている、黄色と黒の金具（？）がRAIDカードのヒートシンクである。明らかに能力不足な、心許ない代物である。しかも、しっかりとくっついていて、取り外すことができないようになっている。VGA用のクーラーでも付けることができれば、それと交換してもよかったのだが、なにぶん3万円もする新品のRAIDカードを破壊する度胸はないから、その方法はあきらめることにした。

RAIDカードの下にあるプラスチックの箱が冷却ファンである。右側から風を吹き付け左側からケース外部に排気するようになっている。

温度を正確に調べたわけではないのだが、とりあえず指で触ってみる限りでは、まぁ、大丈夫だと思うぐらいには冷えるようになった。しばらくはこの状態で様子を見てみることにしよう。

RAID

2010-03-28T20:02:00.003+09:00

PCのHDDが単体ではやはり不安だから、前々からRAIDにしようとは思ってはいたのだが、ついにそのときが来たようだ。

買ってきたのはAdaptec RAID 2405という奴である。でもって、上に見えている銀色のものが、320GBのHDDが3つだ。

一応、マザーボードにRAIDの機能があるのだが、所詮はソフトウェアRAIDであり、何となく疑わしいこととSolarisではおそらく対応していないであろうことから、まともなハードウェアRAIDの拡張カードを買ってきてみた。

しかしこのカード、検索して調べてみると、どうやら非常に高温になるらしい。AdaptecのWebページにも、一定以上の通風があることを前提としていると記載されている。

しかしまぁよくわからないから、とりあえずつなぐだけつないで、電源を入れて状況を確認してみたのだが、やはり噂に違わずべらぼうにあつくなるようだ。火傷しそうなほどだという書き込みもあるが、確かにそれぐらいあつくなる。

PCの内部を模式図で表すと、こんな感じである。

右下から冷たい空気を吸い込み、HDDを冷やしつつ、CPUクーラーを通り抜け、右上の電源ないしケースファンから熱い空気を吐き出す。おおよそはこれでいいと思うのだが、しかしこの形だと明らかに拡張ボードを冷やすことができない。

拡張スロットに付けるファンもあるようだが、それらはたいてい排気用である。それでいいのだろうか。もっと、風をしょぼくれたヒートシンクに直撃させてやった方がいいのではないだろうか。

まぁいずれにせよ、このままでは使用には耐えないので熱対策ができるまではRAID化は延期することにしよう。

職務

2010-03-03T22:13:00.003+09:00

最近、どうにも体に疲れがたまってきているようだ。体のいろいろなところが痛くてたまらない。

客から引き合いがあると、提案書を作成する。その成果があって受注すると、今度は設計作業が始まる。客の社内では企画と呼ばれる作業があるはずなのだが、それはベンダーが提案書を作成している時点ですでに終わっている。そのため、俺のような外注業者は要件定義と呼ばれる作業工程からプロジェクトに参画することとなる。

プロジェクトが立ち上がると、関連する他システムでの開発案件や契約条件にも大きく影響を受けるのだが、一般的には開発環境を用意しなければならない。すなわち、設計・開発作業に使用するPCを用意して、LANを引いて、開発用のソフトを用意して、そいつらを使えるようにする作業である。すでに使える状態でそいつらが存在するのであれば、ことは早いのであるが、全く新規のプロジェクトである場合などでは、一から全部用意しなければならない。

PCや開発用ソフトを用意すると言っても、別に電気屋に行って買ってくるわけではない。それなら困ることは何もないのだが、そうではなく、社内の然るべき部署に言って用意してもらわなければならないのである。それも、かなり多くの部署と連絡を取り合い、いろいろと調整しながら作業を進めなければならないため、俺のような引きこもりには身を切るようにつらい仕事である。

しかも、調整だの連絡だの申請だのと言ういやな仕事を一方的に俺に押しつけ、なおかつ都合が悪くなると俺を攻撃することで自分の身を守ろうとするような輩が多く、それこそ無駄に神経を消耗させられるからたまらない。その上、客との打ち合わせでも俺が矢面に立って話をしなければならない。そう言う立場に追い込まれてしまった。

俺はガキの頃から人付き合いが苦手で、だから少しでも人間関係に煩わされなくても良さそうな技術系の仕事を志し、結果としてSEという今の仕事に就いたのだが、それが大きな間違いだったようだ。どうにも人間関係の問題から逃れることはできないようだ。それどころか、俺の仕事のほとんど全ては、人間との調整につきるようだ。

明らかに俺の性に合わない。これ以上、今の仕事を続けるのは無理だ。

設備投資

2010-02-11T12:54:00.006+09:00

2チャンネル同時に録画できるBlu-rayディスクレコーダーがあるから、とりあえずテレビの録画については困ることはないだろうと考えていた。しかし、人の欲望というものはとどまるところを知らず、設備を増強すればするだけそれを上回る欲求が生じるようだ。前々から恐れていたことではあるが、とうとう、録画したい番組が3つ重なるという事故が起きてしまった。

単純安直な対処法としては、それか一つをあきらめるということになるのだが、それが許されるほど俺の強欲は甘くない。ということで仕方がない。もう一つ録画できる仕掛けを用意することになった。

今まで、オーディオ関係とPCとは完全に切り離すという方針で設備増強を進めていたため、今回も独立したHDDレコーダーか何かを買おうかと考えたのだが、そうするとかなり高くつくことに気がついた。中古のDVD+HDDレコーダーでも、HDで録画できるものとなるとそれ相当の値段になる。

ということで仕方がない。今までの方針を覆してPC用の地上波デジタルチューナーを買うことにした。これなら、新品で買ったとしても安く押さえることができる。

まぁ、これも中古で買うという選択肢も考えられたのだが、なにぶんPCが64bitのWindows7である。周辺機器の互換性は想像以上に低い。いくら安くても動かなかったら元も子もないから、64bitのWindows7対応を明示的に謳っている製品を買っておくことにした。

ということで、幾分高かったがIO-DATAのGV-MVP/VSという奴を買ってみた。

アンテナ線を接続する機器が複数あり配線には多少苦労した。模式図にすると下記の通りである。

テレビにつながるBSデジタルがなくなってしまったが、まぁ、テレビのチューナーはもとより使っていないから問題はない。

多少の試行錯誤はあったがどうにか無事に使えるようになった。なお、画面を曝そうかとも思ったが、mAgicマネージャDigitalという奴が起動していると画面のキャプチャがブロックされる（おそらく、PrintScreenキーがつぶされるのだろう）から、やめておくことにした。まぁ、著作権の問題もあるし。

しかし、このチューナーをインストールするとデフォルトでログイン時に自動的にmAgicマネージャDigitalという奴が起動するようになるのだが、そうした場合、設定を自分で変えるおつむのない奴は金輪際画面のキャプチャができなくなるのだが、いいのだろうか。まぁ、自動的に起動しないように設定ことも、明示的に終了させることもできるのだし、そもそも、自分でヘルプを読んだり設定を変更する知的能力のない人間が画面をキャプチャする必要があるとも思えないから、たぶん問題はないのだろう。

とりあえず、相性およびその他の問題は生じていないようだ。参考までに主要な環境を公開しておこう。

・OS : Microsoft windows 7 Professional
・CPU : Intel Core i7 920
・メモリ : 12GB
・M/B : ASUS P6T
・G/B : ELSA QUADRO FX 580

全く関係ないが、PC本体を裏側から見るとこんな感じになっている。

DVIの下にある二つ並んだ丸いコネクタがアンテナ線をつなぐF端子である。ついでにいうと、その上下に4つあるD-Sub9ピンのコネクタはRS-232Cである。マザーボードにはUSBは6個もついている癖してRS-232Cポートが1つもないため、あえてわざわざAREA SD-PCI9845-4Sという拡張ボードを装着している。sunのマシンが2台ある都合上、どうしたってRS-232Cが必要になるのである。

ハードウェアはだいたい上記の通りである。機能面に関しては、また今度気が向いたら書くことにしよう。

耐震

2010-02-06T18:21:00.004+09:00

いろいろな理由がありロハで手に入れた、日立製のDT19BPというディスプレイ。

不思議なことにこれは、前後には動くのだが、左右には回転しない。仕方がないから、100円均一で回転テレビ台を買ってきてみた。

ついでに、耐震用の粘着ゲルも買ってきて、それで動かないように固定してみることにした。しかし、どうにも粘着力が弱いような気がする。

それに、回転台そのものが二枚に割れて壊れそうな気がする。

まぁ、地震が来たらそのときまでだという考え方もなきにしもあらずだが、しかし、俺はまだ死にたくない。安いコストで万一の事態に備えることができるのなら、その支出は無駄ではないと考えている。

だとしても効果がないのでは意味がない。今までの経験からすると、粘着ゲルの粘着力は価格に比例するようだ。買うのであれば、あまりケチらずちゃんとした奴を買った方がいいらしい。

編隊

2010-01-02T13:31:00.005+09:00

振り返ってみれば、2009年の5月頃から「主筆」の大規模なリファクタリングに手をつけ始めている訳なのだが、年が明けてもその作業が終わりそうにない。

とりあえず、文字列を保持・管理するモジュールについては大部分作成し終えた。だが、これの動作確認を行うためのテストドライバを作成しなければならないのだが、それが面倒でやる気が出ない。

上の簡単な絵で言うと、いじらなければならない部分のうち、下3分の1について終わりが見えてきたという状態だ。

でもって、微妙な青緑色で塗りつぶされたモジュールをテストするためのテストドライバの作成が残っている。

正確には、文字が描画される幅を求めてインデックスを更新する機能を除いては、テストドライバも作成されており、すでに動作確認も終わっている状態となっている。だが、この作成されたドライバに文字幅の情報が正しく設定されているか否かチェックする機能を実装するのが面倒でやる気が出ないのだ。

そもそも、いくら頑張って作ったところで結局のところ使うのは自分だけで、しかもこの努力が人から理解されることも評価されることも絶対にないと分かっているからこそ、なおのことやる気が出ない。では、なぜこんな作業をしているのかと問われると、それこそ答えに窮する。まぁたぶんそれは俺が変態だからなのだろう。

とりあえず、今作っている部分が満足に動くようになれば、後は比較的簡単な作業のはずだから何とかなるだろう。そうすれば第21版の公開も可能となるはずである。

分析

2009-12-31T12:21:00.003+09:00

欲しいものはあるが軍資金は有限の資源である。ならば何にどれだけ予算をつぎ込むのか、十分に検討しなければならない。しかし検討するとはいっても、そもそも軍資金としてどこまで使用していいものなのかをはっきりさせなければならない。

今まではそれほど厳重な金の管理をしなくてもやってこられたが、やはり将来を見据えて計画的に消費した方がいいものと思われる。ということで、現状の収入と支出のバランスを調査してみることにした。

とは言っても、ちまちまとレシートを集めて帳簿につける気力はない。そもそも今から情報収集を開始していたのでは遅すぎる。何とかして既存のデータを元に傾向を把握するようにしたい。

利用可能なデータは限られている。履歴として残っており参照可能なのは銀行の入出金明細と給与明細だけである。無論、給与明細をいくら眺めてみたところで収入の構成が分かるだけで支出の構成は分からない。そうなると銀行の入出金明細だけが頼りとなる。

入出金明細には、口座引き落としのものはそのものズバリで記録が残されるが、現金で引き出したものやカードで払ったものは使途が記録されない。だからそれらについては記憶だけが頼りとなる。だが、いつにいくら引き出したのかが分かると存外内容を覚えていたりもするので、まぁ、実用上は問題ない。

そう言うことで、とりあえず分析してみた。

まず、元データを月別・項目別に一覧表にまとめ、そこから当面無視するデータを除外する。一つに賞与は別管理とするため除外する。次に非定常的な支出は除外する。そもそも、分析の目的は非定常な支出にいくらつぎ込むことができるのかを求める為だからである。さらに、株式投資などの資産配分の変更に伴う入出金は除外し、なおかつ、交通費は会社から支給されるため相殺する。

そうすると、だいたい次のような結果が得られる。
A.収入：約20万
B.定常的な支出：約5.2万
C.思いやり予算：3万
D.通話料：0.4万
E.クリーニング代：0.6万
F.検定受験料：0.2万

恣意的にいくつかの外乱要因を除外しているため安全とは言い難いが、だいたいの傾向としては間違っていないはずである。

上記のうち、定常的な支出に分類したものは食費や書籍代などであり、多分に削減の余地があるものである。しかし、とりあえずここは将来にわたって減少することはないものと考えた場合、余剰金として利用可能なのは約10万ということになる。つまり、未来があることを想定せず享楽的に生きるのであれば、毎月10万ずつ使っても問題ないという計算になる。

しかしそれはあまりにもリスキーである。そもそも、賞与とそれを当てにした非定常な支出のバランスが考慮されていない。すなわち、この10万という数字を下記の項目に割り当てなければならない。

X.貯蓄
Y.非定常支出準備金（主に大型設備投資）
Z.非定常小口支出（月々出て行く生活費ではない支出）

Yについてはデータが少ないとはいえ分析すれば概算値が出るはずである。となると問題はXとZの配分ということになる。これについては、もう少し考えてみることにしよう。

職業

2009-11-21T19:21:00.000+09:00

おそらく、世の中に存在するほとんど全ての職業について言いうることなのだろうが、俺がどんな仕事をしているのかと言うことを人に理解させるのは容易ではない。特にそれが、コンピュータに詳しくない、インフルエンザウイルスとコンピュータウイルスの区別もつかないような人にとっては、ほぼ不可能なことなのだろう。

俺の仕事はいわゆるSEである。雑用係という方が実態を正確に表してはいるのだが、横文字で言った方がかっこいいからSEと言っている。まぁ、名前はともかくとして、とりあえずSEと言っておけばコンピュータ関係のいろいろやっている人間だという程度には理解してもらえるものと考えている。何せ、コンピュータ業界は建築業界に次いで二番目に就業人口が多い業種だと言われているのだ。十分、世の中に浸透した職業だと言っていいはずである。

それなのに俺の母親は、つい最近まで俺の仕事を「鶴嘴を持って地下深くに潜り何かをする仕事」だと思っていたらしい。むろん彼女はそのように理解していたわけではない。ただ何となくそのような心象を抱いていたに過ぎない。いったいどこの地下に潜って、鶴嘴で何をどうすると思っていたのだろうか？　無考えにもほどがある。

最近いろいろあって、俺が何をしているのかを説明してやったのだが、結局最後には「要はパソコンを直す仕事をしているのね」と言われて終わってしまった。

まぁツルハシに比べればだいぶ近づいたのには違いない。だがそれでも大きく外れている。確かに仕事でPCは使うが、それはあくまで文房具に過ぎず目的はそこではない。そもそも、PCを使うのはSEに限らず、事務職をはじめとして世の中の多くの職業でPCの使用は必須となっている。それに俺は一度も「修理」する等とは言っていない。それでどうして「パソコンを修理する」になるのだろうか？

また、俺は一応現時点では正社員として雇用されており、とりあえずは安定した生活を送っている。サブプライムローン問題やリーマンショックの際にもクビを切られることなく無事にやり過ごすことができた。生活に苦しんでいる人から見れば、俺は間違いなく羨ましがられる立場にいると言っていい。にもかかわらず、彼女は俺が日雇いの労働者であると信じている。何度となくそうではないと言い続けているにもかかわらず理解しようとしない。

どうやら彼女の中では、俺は是非とも肉体労働に就いていなければならないらしい。というか、いわゆる差別的な思想に基づくところの被差別階級に属していなければならないらしい。

思えば彼女は俺がガキの頃から俺のことをけなして馬鹿にしておとしめるという習慣があったが、それが未だに抜け切れていないらしい。本当かどうかは知らないが己が腹を痛めて産んだはずの子供に対して、どうしてそういうことができるのか俺には理解できない。まぁ、大方「放蕩息子を持つ不幸でかわいそうなアタシ」を演じていたいのだろう。とりあえず、日々の食事に毒を盛られることなく独立することができたのだから、それでよしとするべきか。

環境

2009-11-03T22:58:00.003+09:00

PCを買い換えた。

もし技術史の試験に合格していたのなら、CPUはXEONのW5580にしようと心に決めていたのだが、残念ながら落ちていたからCore-i7 920で妥協しておいた。

それでも、当然だが以前のマシンと比べれば比較にならないほど高速である。当たり前だが。

現在は新PCで今まで通り開発作業を行えるようにするために環境を整えている最中である。しかし、やることが多すぎていくら時間があっても足りない。とりあえず、画面のデザイン等はおおよそ自分のいいように調整することができ（それでも不満は多いが）。

とりあえず、画面を曝しておく。

Firefoxの後ろに見えているのは、VirtualBoxにより動作させているWindows2000である。XPモードではない。

本来であればこんなものは使う予定になかったのだが、なにぶんVisual Studio 6.0はバージョンが古すぎてWindows 7では動作しないのだから仕方がない。

だったらXPモードにしておけばいいのではないかという考えもあるのだが、いろいろと思うところがあって完全に環境を切り離しておくことにした。

感慨

2009-10-31T23:40:00.001+09:00

PCをリプレースすることになり、今日秋葉原で各種のPCパーツを買いそろえてきた。
今は、今夜で最期になる現行PCからこのblogを書いている。データを移し終わったら、後はバラして捨てるだけだ。

さすがに10年使ってきたPCだから、入れ替えるとなるとやはり感慨深いものがある。

ファジング

2009-10-26T22:08:00.001+09:00

久しぶりに、新しいコンテンツを一つ追加しておいた。ブルートフォース法によるファイルのファジングを行うツールである。

別に、どうしても急遽このツールが必要だったという訳ではない。ただ何となく、「主筆」で使用しているモジュールの動作を確認してみたくなって自作したに過ぎない。

「主筆」では設定ファイルとしてWindowsでよく使用されるini形式のファイルを使用している。しかし当然だが、Unixではini形式のファイルを読み込む標準のライブラリなどは存在しない。その為「主筆」では自前でini形式のファイルを読み込むモジュールを作成している。いや、正確に言えば「主筆」で使うために作ったのではなく、俺がそれよりも前に作成していたモジュールを流用したのである。

そういう経緯があるため、ini形式のファイルを読み込むモジュールは「主筆」を構成するモジュールの中でも群を抜いて古い。おそらく、俺が作ったプログラムの中で現存している最古のものではないかと思われる。

一般的に言って、古いプログラムというものはバグも少なく安定していると考えられている。つまり、技術的に枯れていると考えられる。だがこの場合は、何分俺が作って俺が使っているだけであるため、到底枯れているなどと言える状態にあるとは思えない。

そもそも、これを作った当時はセキュリティ性なんて微塵も考えておらず、単に動けばいいという程度にしか考えていなかった。だから攻撃を受けた場合に大丈夫なのかどうか全く自信がない。

だったら、自信がないのなら、十分なテストを行い品質を確保すればいい。そういうことで実際に攻撃をやってみようと言うことで作ったのがこのツールである。

まぁ、無論、このツールで生成できる攻撃用のファイルには制限も大きく、大して実用的とは言えないものかも知れない。だが、今後機会があれば拡張してゆく予定である。

PC

2009-10-22T23:06:00.001+09:00

長年使ってきた今のPCだが、ついに入れ替えようと思う。

OSやアプリケーションが変化しない限り、PCの性能が低くても問題はないものと考えていたのだが、やはり、必ずしもそういうわけにはいかないようだ。ウイルス対策ソフトにしろ、周辺機器にしろ、ブラウザで見るWebページにしろ、どうしても求められるPCのスペックは年々向上して行き、ついに俺も耐えきれなくなってきた。まぁ、CPUがK6-IIIの450MHzであることを考えれば、よくがんばった方だといってもいいだろう。

そうすると問題は、次はどんな奴にするのかという事だ。

SPECの値を俺なりに分析すると、以下の傾向があることが判った。
　・純粋な1スレッドあたりの処理速度という観点からすれば、Core2Duoが一番早い。
　・複数スレッドによる処理を考慮に入れた、CPU単体の処理速度という観点でいくと、XEONのW3580やCore-i7 965がほぼ拮抗していて最高速。XEONの5500番台は必ずしも一番早いと言うわけではないが、その差はわずかである。
　・性能の値を価格で除したコストパフォーマンスで分析すると、Phenom II x4が群を抜いて一番いい。Core-i7 920は二番手集団に位置している。XEON、特に5500番台のコストパフォーマンスは著しく悪い。

また、これはSPEC intやSPEC floatのベンチマークの性質によるのだろうが、HTはほとんど性能向上に寄与していないらしい。それどころか、むしろスレッド数を増やした方が性能が劣化しているという結果が多数散見され、向上しているデータは少ないように見える。まぁ、Intelの誇大広告ですらHTによる性能向上は25%だというのだから、実際にはどれだけ早くなるのか、推して知るべしということなのだろう。

CPUの選定に関わる重要な要素は二つあるものと考えている。一つは性能である。これには、コストパフォーマンスの概念も含まれる。そしてもう一つは、男の沽券である。Core-i7やPhenom等といった民生用の軟弱なCPUでいいのか、それとも、男らしくXeonやOpteronにするのかという問題である。

OpteronはなぜかCPUそのものが売っていない。マザーボードも手に入りにくいようだ。そうすると、Opteronで自作という線は消える。そういう意味でのスキルは俺にはない。そうすると、男の沽券を守る方向でいくとなると、Xeinがもっとも可能性が高くなる。しかしこれではあまりにも価格が高くなりすぎる。俺の試算が正しければ、Xeonのマルチプロセッサ構成にした場合、55万から75万は必要になる。

では、安い方向でいくとした場合は、やはりコストパフォーマンスが重視されるから、Core-i7の920かPhenomである。Core-i5やCore-i7の800番台はベンチマークの結果になかったから評価していないが、価格によっては考慮の対象になる可能性もある。いずれにせよ、この方向で進んだ場合は、安ければ10万を下回る価格で手にはいる可能性がある。多少こだわっても、20万がいいところだ。

男の沽券を取るか、金を取るか。

どうにも決められないから、考え方を変えてみる。すなわち、俺の男の沽券の価格が55万円(75万-20万)と解釈してみる。そして、買うべきか否か悩むときには、悩んでいるものを人にその値段で売り払う事ができるか否かで考えるといいという。そのアルゴリズムに従って考えてみると、すなわち、俺の男の沽券を人にくれてやる(あるいは捨てる)代わりに55万円入ってくるという事になる。俺の沽券に55万もの価値があるのだろうか。

だがしかし、男の沽券とはそもそもなんなのだろうか？

困難

2009-08-29T20:31:00.002+09:00

三ヶ月ぶりに着信メールを確認したら、ジャンクメールが多数きていたから全部消してしまった。最も、メールボックスの容量はなぜか知らないが120MBまで利用できるため、あふれると言うことはないのだが。

今現在、「主筆」の文字列データを保持するロジックを開発しているのだが、最近になってようやく文字列をまともに追加／削除できるようになってきた。後は、構文に従って色を設定するロジックと、文字幅から行がされる位置を決定するロジックを作り込むのみである。

しかし、この処理は複数スレッドを回して並列に処理させるつもりである。すなわち、今まで作り込んできた処理の難易度はほんの序の口で、これからが本番だと言える。それぐらい困難な作業になることが予想される。

一応、基本的な考え方やアルゴリズムについては、頭の中ではできてはいるのだが、しかし、それをコードに落とすのがそう簡単にできることとは思われない。とりあえず、スレッドの生成やウェイトを行うための部品を作るところから手を付け始めたが、すでにして難しい雰囲気が十分に漂ってきている。

まぁ、誰に急かされている訳でもないのだから、ゆっくりと進めていくまでの話だが。

UPS

2009-07-26T20:06:00.004+09:00

気がついたら、オーディオ機器に接続するUPSが著しく増殖していた。

別にだからなんだということでもないが。

ついでに言うと、左に見えている黒い板はPioneerのKUROの背面である。でもって、這い回っているケーブルの大部分は電源とLANである。

出火しなければいいのだが。

同期

2009-07-20T07:10:00.001+09:00

「主筆」の、テキストデータを保持し、編集する部分の実装を進めてはいるのだが、やはり難しい。とりあえず、文字列の追加と削除を行う処理だけを先に作って、その部分だけでもとりあえず動くようにしようと考えているのだが、それだけでも難しい。

今現時点では、追加・削除の処理を行う部分のコーディングが終わり、少しずつ動かし始めてはいるのだが、どうにも思うように動いてくれない。一つ課題が解決すれば、また次の問題が生じるという状態で、苦しいことこの上ない。いかんせん、アルゴリズムそのものが複雑なのだから仕方がない。

ところで、今頑張って作っているロジックは、ウインドウ幅での行折り返しを実現するということと共に、複数の処理を並列で走らせて、処理効率を向上するという目的もある。とすると、何らかの方法で、スレッド間の排他制御を行い、矛盾が生じないようにしてやらなければならないはずである。しかも、処理効率向上を目的としているのだから、ごく単純に、あるスレッドがデータ構造にアクセスしようとする都度、データ全体に対して排他ロックを掛けると言うような方式を採用するわけには行かない。複数スレッドが矛盾が生じない限り、複数のスレッドが同時にアクセスできるような方式を考えなければならない。

しかしこれはこれで非常に難しい問題である。

直感的に言って、ツリー構造全体にロックをかけてしまうのが野蛮だというのであれば、ツリーの個々のノードに対してロックをかけるようにすればいいような気がし無くもない。そうすれば、少なくとも矛盾が生じることなく、かつ、複数スレッドで同時にデータ構造にアクセスすることができるようになるはずである。

しかし、その方式には大きな問題点がある。まず、各ノード間には複雑なデータの依存性があるという事だ。つまり、親ノードは子ノードに対するインデックスであるため、子ノードの情報を変更した場合はその変更が親ノードに反映されなければならない場合がある。そのため、単純に一つのノードをロックすると言っても、実際に排他をかけなければいけない範囲は、単一のノードよりもはもう少し広いということになる。そのため、ロックをかける範囲がはっきりせず、実装が困難だと思われる。

さらに、個々のスレッドがどのような順番でノードにアクセスするかが決められないため、場合によってはデッドロックに陥る危険性があるという問題がある。各スレッドの処理をACID特性に従ったトランザクションとして実装するのであれば、デッドロックが生じた場合には、それを検出して一方をロールバックするという方法も考えられる。だが、そこまでやるのは明らかに大仰過ぎる上に、処理速度的にも不利になる。だから、処理が途中で失敗したら元に戻せるような実装にすることはできない。すなわち、デッドロックから回復する術がないということであるため、そもそも、デッドロックが発生しないような、何らかの方法を考えなければならない。

デッドロックを防ぐためには、各リソースに対して、ロックをかける順番をあらかじめ決めておいてしまえばいい。そうすれば、理論上デッドロックは発生し得なくなる。しかし、今回はその方式を採用することはできない。

ツリー構造である都合上、同一の高さのノードを左右に移動するようなアクセスはあまり起こらないと考えられる。そうすると、ロックをかける順番を「上から」と「下から」のどちらかに限定しさえすれば、デッドロックを防ぐことができるような気がする。しかし、必ず上(ルート側)から順番にロックをかけるようにする、というルールを決めた場合、それは、アクセスする都度必ずツリー全体にロックをかけるという方式と同じになってしまう。なぜならば、ツリー構造である都合上、アクセスそのものが必ずルートから行われることになるためである。また、下(葉)から順番にロックをかけるというのも、同じ理由で成立し得ない。いきなり葉からアクセスすることはできないからだ。

また、この考えを延長して行くと、二層ロックを採用することも不可能という事になる。ツリー構造にアクセスするためには、まずルートにアクセスする必要があり、そのためにルートのノードに対してロックをかけることになる。その後、自分が一通りの処理を終えるまでずっとルートのノードを押さえ続けていたら、その間ずっと他のスレッドはツリー構造にアクセスすることができなくなってしまう。だから、どうしても処理途中であっても使わなくなったノードは解放してやるようにしてあげなければならない。

そう考えていくと、どうにも八方塞がりの様な気がしてくる。しかし、あまり汎用性のない、アプリケーション依存な方法を使うのであれば、全くやりようがないという事でもないようだ。まず、データ構造にアクセスするスレッドの種類・数・アクセスパターンは、あらかじめはっきりと判っている(何せ自分で作るのだから)。そこから、起こりうる競合を全て洗い出して、各競合に対してどのように対処すればいいかを一つずつ決めていけばいい。そうすれば、高い効率を維持したまま、矛盾やデッドロックを生じさせないようにすることが可能である。

とりあえず、考えた結果については、また今度気が向いたら書くことにしよう。

時間

2009-07-10T21:12:00.001+09:00

「主筆」の文字列を保持するデータ構造の実装を始めてからかなり時間が経つが、まだコーディングも終わっていない。そもそも、テキストファイルの読み込み／文字コードの変換／マルチバイト-ワイドバイトの変換／データ構造への格納／構文強調表示処理／文字の描画位置の確定／画面への文字列の描画という7種類の処理を全て並列に処理させようと言う野心的な目標なのだから、そう簡単に終わるものとは考えていない。その上、ウインドウ幅での行折り返しに対応させるために、いくつかの余分なデータも保持させなければならないのだから、ますます事態は複雑化し混迷を極めている。

しかし、「主筆」の開発を進める一方で技術士の受験勉強もしなければならない。気がついてみれば、試験日まであと一ヶ月を切っている。論文を書く練習なども、このところ少しさぼり気味だったから、また復活させなければならない。時間は限りなく無いと言える。

どうやらこれは、エロ画像の収集に精を出している場合ではなさそうだ。

共連れ

2009-06-12T18:58:00.002+09:00

ビューとドキュメントの分割に手を付けたのは良いのだが、それをやるためにはどうしてもドキュメント部分の内部構造に大幅に手を入れなければならないようだ。

当面の所は既存ロジックを極力残したまま分割だけを先にやってしまおうと考えていたのだが、やはりどうにも構造がクソで流用するのも難しいと判断したのだ。

そういうことで、ここ数日は文字列操作の要となるデータ構造をどうするかということについて死ぬほど考えていた。

データとして保持しなければならないのは、文字そのものと文字の色、文字の幅である。色は構文強調表示で必要となり、文字の幅はプロポーショナルフォントを取り扱う上で必要となる。でもって、下記の操作に対して最悪でもlog(n)の計算量で処理を完了するようにしなければならない。
　・文字列の追加
　・文字列の削除
　・文字の検索

ここで文字の検索といっているのは、何らかの方法で指定された位置に存在する、とある一文字が格納されているメモリアドレスを求める事を言っている。でもって「何らかの方法」というのには下記のような方法が考えられる。
　・（行折り返しを考慮しない）行番号と、行頭からの文字数
　・（行折り返しを考慮した）行番号と、行頭からの文字数

先頭から数えた文字数を用いて、配列のようにアドレッシングを行う可能性は低そうである。どちらかといえば、「画面上のココ」という指定をされて、その文字がメモリ空間中のどこに存在するのかを求める事の方が重要であると思われる。

また、表示や編集の処理を考えた場合、アドレッシングを方法を相互変換する機能も必要になるのは明白である。すなわち、
　・文字を示すメモリアドレスから、行折り返しを考慮しない行番号と、行頭からの文字数を求める
　・文字を示すメモリアドレスから、行折り返しを考慮した行番号と、行頭からの文字数を求める
　・行折り返しを考慮しない行番号と行頭からの文字数から、行折り返しを考慮した行番号と行頭からの文字数を求める
　・行折り返しを考慮した行番号と行頭からの文字数から、行折り返しを考慮しない行番号と行頭からの文字数を求める
という処理である。

上記の処理はいずれも、一見すると難しいような気もするが、計算量を考慮しない限りそれ程難易度の高いものではない。例えば、文字列を単純に配列に格納して、必要な都度文字列の先頭から総ナメにして要求された値を算出するようにしてやれば、よほどの馬鹿でもない限り実装することは可能なはずである。

だが、問題はこれらの処理を、文字数に対してlog(n)の計算量で解かなければならない所に存在する。

現在で主筆で使用しているロジックは、与えられた文字列を改行コードで区切って部分文字列を構築し、それら部分文字列を指し示すポインタを、単純な配列に入れて管理している。

だから、それこそ何の考えもなしに単一の配列に押し込んでいるよりかは幾分マシだとは言え、本質的には計算量はnに比例する。だから、余り大きなファイルを開くと性能が著しく劣化する。更に、一行の長さがあまりに長くなると、それこそ応答が返ってこないという事態になりかねないため、一行の最大長を10KBにするという制約を設けている。よって、これらの問題をここで一気に解消したいと考えている。

では、どういうデータ構造にすればいいのか。というか、計算量がlog(n)などという、言ってみればデータ量が増えれば増えるほど一文字当たりの計算量が減少するなどという、ご都合主義的な方法が存在するのだろうか？

答えから言えば、方法は存在する。存在するからこそ、こうして俺はゴタクを並べてblogを書いている。

方法としては、B+木を用いればいいはずである。無論「一意に識別できる値を使ってレコードを識別する」という処理ではないため、アルゴリズムは多少変則的なものになるが、それでも不可能ではない。というか、以前、こういった問題について考えたことがあり、その結果をこのページに記述している。要は、これと同じ事をしてやればいいはずなのである。

とは言っても、やはりそれが難しい。

とりあえずは、具体的なデータ構造や値の検索・更新の方法について、ある程度の目処が立ったところではあるが、実装はまだ全く手が着いていない。このままでは第21版の公開は、かなり遠い未来のこととなるであろう。

偽物

2009-05-26T06:53:00.000+09:00

「主筆」のビューとドキュメントの分割に手を着ける前に、とりあえずフォルダ構成を見直しておくことにした。現時点でも、現在公開している第20版には存在しない共有ライブラリが増えているし、フォルダ名がいくつか気に入らない奴が有るため、今の内にきれいにしておくことにしたのだ。

また、生成された共有ライブラリと、その共有ライブラリを使用するために必要となるヘッダファイルが、その共有ライブラリを開発するためのフォルダ内に格納されたままだと何かと都合が悪いため、別途includeとlibというフォルダを用意して、コンパイル後にそのフォルダにシンボリックリンクを作成するようにしておいた。

つまり、たとえばTaEdit/FOOというフォルダを作って、その中でlibFOO.soというライブラリを構築するようにしたとする。そうすると、libFOO.soそのものと、それを使うためのヘッダファイル、たとえばfoo.hは、TaEdit/FOOフォルダの中に存在する事になる。となると、そのlibFOO.soを使うプログラムは、コンパイル時にヘッダファイルとライブラリの検索パスとして、TaEdit/FOOというフォルダのパス名を指定してあげなければならなくなる。

とりあえず、使用するライブラリが1つだけであれば、それは大した事ではない。だが、そういったライブラリがだんだん増えてくると、コンパイル時に指定しなければならなくなるパス名が増えてくることになる。まぁ、だとしても、指定すればいいだけの話だと言ってしまえばそれまでだが、やはりそれでは美しくないため、外部に公開する奴は「公開されるためのフォルダ」を作って、そこに格納するようにしたほうがいい。そうしておけば物事がわかりやすくなるから、コンパイルするときにヘッダファイルが見つからないだの、リンク時にシンボルが見つからないだのと言われる可能性を減らすことができるようになる。

フォルダ構成の整理は、基本的にはMakefileをいじるだけだからそう大した話ではない。もっとも、複数人で開発している場合は、逆にほとんど不可能に等しい荒技ということになるのだが。

今現在は、COMの偽物の仕様ついて考えている。WindowsのCOMの様なことをやりたいとはいっても、しかし、COMそのものを作るつもりはないし、COMと張り合おうというつもりもない。ただ、自分が作ったアプリケーションの範囲内だけでつかわれる、それっぽくモジュールを分割できるような仕掛けが有ればそれでいいのだ。

そうすると、もっともストイックな実装としては、ただ、純粋仮想クラスを継承したオブジェクトを生成して、そのインスタンスを返してよこすだけのライブラリというのが考えられる。すなわち、そのライブラリで提供される関数を一回呼び出してやれば、IDocumentとか何とか、そんな感じの純粋仮想クラスのポインタを返す、そういうライブラリにしておくということだ。

だが、それではちょっとありがたみが薄い。どうせなら、そのライブラリのインタフェース仕様(つまり関数の仕様)や、オブジェクトのインタフェースとなる純粋仮想クラスに一定の規約を当てはめ、その規約を強制するようなライブラリを一枚かぶせるようにした方がいい。そもそも、共有ライブラリの動的ロードや実行時に関数を検索する処理など、ライブラリや実装するオブジェクトによらずみんな同じになるのだから、どうせなら処理を統合した方がいい。

とすると、その規約なりライブラリなりで、どこまで何をサポートするのかが問題となる。とりあえず、純粋仮想クラスを継承したオブジェクトを生成するという機能と、ライブラリ自体がエクスポートする関数は完全にC言語の仕様に準拠していること等と言った物事は、そもそもの目的であることからして外すわけには行かない。

だが、IUnknown::AddRefやIUnknown::Releaseといったメソッドにより提供される、インスタンス管理の機能は必要なのだろうか?　難しいことをやりたいわけでもなし、とりあえずオブジェクトを使う側で間違えなければ、わざわざインスタンス管理の機能をここで実装してやる必要はないものと思われる。もし、参照カウンタなりガーベッジコレクタなりでメモリ管理を行う様にしたいので有れば、それは別の機能として実現すればいいまでの話だ。

また、オブジェクトが提供する別のインタフェースを取得する機能も必要ではない。そんなものは適用にやればいい。COMではGUIDによりインタフェースなどに一意な名前を採番するようにしているが、それも簡略化していいはずだ。どうで、1アプリケーションに閉じた世界の話なのだ。世界中で一意にに識別できなければならない必要性などない。

微妙なのは、インタフェースを実装するライブラリをどこかに登録しておいて、オブジェクト生成時に、自動的に目的となるライブラリを検索できるようにする仕掛けがいるかどうかだ。COMではインタフェースに割り当てられたGUIDとDLLのファイル名をレジストリに登録しておいて、オブジェクトを生成する際にはDLLのファイル名や物理的な場所については意識しなくてもいいようになっている。だが、今回俺が作ろうとしているものには、そのような機能は必要であろうか?

ビューの方から本物のライブラリ名を指定してオブジェクトを生成させるようにしたところで、あまり実害はなさそうな気がする。だが、ライブラリのファイル名とインタフェース名を事前に何かの設定ファイルに登録しておくようにすれば、アプリケーションでライブラリのファイルを保持する必要が無くなり、何か便利になるような気がする。

だが、それ以上の具体的な利点が見えない。必要だろうか?　不要だろうか?　どっちでも良さそうな気がするが、きめなきゃ物事が進まない。どうしようか。

一刀両断

2009-05-22T22:41:00.002+09:00

正規表現の最適化なんか考えている場合ではない。技術士の勉強をしなければならないはずである。とりあえず、ここ数日は毎日論文の問題を解くようにしてはいる。だが、そもそも正解というものがない論文は、勉強したところでできるようになるものなのだろうか？　それに、手元にある問題数が少ないため、もうやるべきものが無くなってしまった。　とりあえず、漢字の勉強でもしておいた方が良いのだろうか？

「主筆」のウインドウ幅で文字列を折り返して表示する対応に、そろそろ手を付けたいと考えている。だが、それをやるためには文字列の編集と表示という、最もコアな部分に手を入れなければならない。

大変残念なことに、文字列の編集に関わる処理や文字列の表示に関する部分は、「主筆」の中でも最も古いコードに類し、かなりいい加減な作りになっている。特に気に入らないのは、文字列の操作や編集を行うモジュールと、画面の表示を行うモジュールが強く結合していることだ。つまり、ビューがドキュメントの内部構造に立ち入った様な処理になっているということだ。

どう考えてもおかしいこの作りは、開発当初、モチベーションを維持することを目的に、とにかく動作するものをでっち上げようとしたことに起因する。過去の経験から、フリーソフトを作り上げるためにはモチベーションを持続させることが重要だと考え、その為に設計の基本ですら無視した開発を行ったのだ。

その甲斐あってか、とりあえずはテキストエディタとしての体をなしたモノを作り上げることができた。そういう意味ではその戦略は正解だったといえる。だが、今やその目的は消え、当初無視した設計上の不良がここに来てボディブローのように効いてきている。

コアな部分には手を入れずに、塩漬けにしたまま使い続けるのであれば、別に設計がどうであろうが問題はない。しかし、大規模に手を加えようとするとなると、このままではどうにも都合が悪い。だから、そろそろドキュメントとビューをスパッと切断するような大手術が必要になるものと思われる。

できれば、インタフェースを明確に定め、独立した共有ライブラリとして切り出すようにしたい。つまり、Windowsで言うところのCOMコンポーネントのようにしたいと考えている。まぁ、IDLがどうだとかGUIDがどうだのということをやるつもりはない。とりあえず、インタフェースとして純粋仮想クラスを定義し、その純粋仮想クラスを実装するオブジェクトを生成する、という程度のことはやりたい。そうすれば、主筆の本体部分がほぼ真っ二つに切断されることになり、かなり事態が単純化するはずである。

しかし、その為にはまたしてもかなりの作り込みが必要になる。それも相当に難しく、一度踏み出したら容易には後戻りできない危険な迷宮に足を踏み入れることになるものと予測される。それを、技術士の勉強をしなければならないと言っているような、今この時期に始めるべきか否か。

それが問題だ。

正規表現の最適化2

2009-05-09T00:06:00.002+09:00

答えから書いてしまうと、「α{a,b}{c,d}」という正規表現はc(b-a)>=a-1もしくはc=dが成立する場合に限り「α{a*c,b*d}」に変換することができる。

証明といえるような内容になっているかどうか判らないが、俺なりに考えた結果を書いてみる。

まず、そもそも論として、「α{a,b}{c,d}」を「α{a*c,b*d}」に変換できるとはどういう意味なのだろうか？

「α{a,b}{c,d}」というのは、昨日も書いたが「とある正規表現αがa回以上b回以下繰り返す」というものがc回以上d回以下繰り返す、という指定である。また「α{a*c,b*d}」とは、とある正規表現αがa*c回以上b*d回以下繰り返すという意味である。

でもって、「α{a,b}{c,d}」を「α{a*c,b*d}」に変換できるというのは、「α{a,b}{c,d}」が実質的に「α{a*c,b*d}」と同じ、すなわち、「α{a,b}{c,d}」という指定により繰り返されるαの個数が、a*c～b*dの範囲内に収まり、かつ、a*c～b*dの全ての値を取るということを意味している。

例えば、「α{2,3}{4,5}」という正規表現を考えてみる。

αの数が最も少ないパターンでは、内側の繰り返しが全部2回で、かつ、外側の繰り返しが4回の場合、合計で8回繰り返す場合である。つまり下記のようになる場合である。

　αα αα αα αα　（半角空白は判りやすくするために入れた）

次に少ないのは、内側の繰り返しが2回の奴が3つと3回の奴が1つ、でもって、外側の繰り返しが4回の場合である。つまり、下記のようなパターンである。

　ααα αα αα αα
　　　　あるいは
　αα ααα αα αα
　　　　あるいは
　αα αα ααα αα
　　　　あるいは
　αα αα αα ααα

同様に、最も多くなるのは内側の繰り返しが全部3回で、かつ、外側の繰り返しが5回になる場合である。すなわち、下記のようなパターンである。

　ααα ααα ααα ααα ααα

こうやって考えていくと、「α{a,b}{c,d}」と指定された場合、全体の繰り返し数の最小は必ずa*c回、最大の繰り返し数はb*d回になると言うことができる。

ということは、「α{a,b}{c,d}」による繰り返し回数が、a*c回～b*d回の全てのパターンを取りうるのであれば、「α{a*c,b*d}」に変換できると言うことになる。

ちなみに、「α{2,3}{4,5}」の取りうる繰り返し回数を列挙すると下記のようになる。

外側の繰り返し回数	内側の繰り返し回数	合計
4	2,2,2,2	8
4	2,2,2,3	9
4	2,2,3,2	9
4	2,2,3,3	10
4	2,3,2,2	9
4	2,3,2,3	10
4	2,3,3,2	10
4	2,3,3,3	11
4	3,2,2,2	9
4	3,2,2,3	10
4	3,2,3,2	10
4	3,2,3,3	11
4	3,3,2,2	10
4	3,3,2,3	11
4	3,3,3,2	11
4	3,3,3,3	12
5	2,2,2,2,2	10
5	2,2,2,2,3	11
5	2,2,2,3,2	11
5	2,2,2,3,3	12
5	2,2,3,2,2	11
5	2,2,3,2,3	12
5	2,2,3,3,2	12
5	2,2,3,3,3	13
5	2,3,2,2,2	11
5	2,3,2,2,3	12
5	2,3,2,3,2	12
5	2,3,2,3,3	13
5	2,3,3,2,2	12
5	2,3,3,2,3	13
5	2,3,3,3,2	13
5	2,3,3,3,3	14
5	3,2,2,2,2	11
5	3,2,2,2,3	12
5	3,2,2,3,2	12
5	3,2,2,3,3	13
5	3,2,3,2,2	12
5	3,2,3,2,3	13
5	3,2,3,3,2	13
5	3,2,3,3,3	14
5	3,3,2,2,2	12
5	3,3,2,2,3	13
5	3,3,2,3,2	13
5	3,3,2,3,3	14
5	3,3,3,2,2	13
5	3,3,3,2,3	14
5	3,3,3,3,2	14
5	3,3,3,3,3	15

重複はあるが、最小の8回（=2*4）から最大の15回（=3*5）の全ての値を取るため、「α{2,3}{4,5}」は「α{8,15}」と同じであると言うことができる。

では、いかなる条件が成立した場合に、「α{a,b}{c,d}」による繰り返し回数がa*c回～b*d回の全ての値を取るのだろうか？

それを明らかにするために、まずは外側の数量子の値が同じだった場合、すなわち「α{a,b}{x,x}」という指定だった場合について考えてみる。つまり、

　命題：{a,b}{x,x}が指定されたとき、任意のax～bxの繰り返し回数を取りうる

の、証明を試みる。

何か泥臭いが、帰納的に証明する。

まず、x=1の場合、すなわち{a,b}{1,1}の場合にa～bの任意の値を取りうるか否かについて考える。{a,b}の指定は、a～b回の任意回の繰り返しであることを示すのだから、{a,b}{1,1}がa～bの任意回の値を取れるのは明らかである。

次に、x=2の場合、すなわち{a,b}{2,2}の場合について考えてみる。

x=2つまり外側の繰り返し回数が2回なので、内側の（a～b回）を2回繰り返す、すなわち、

　（a～b回）+（a～b回）=（2a～2b回）

が成立することを考える。

ここでまた泥臭いが、1回目の内側の繰り返し回数が、a回からb回に変化するのを順番に追っていってみる。

　（a+0回）+（a～b回）=（(a+0)+a～(a+0)+b回）=（2a～a+b回）
　（a+1回）+（a～b回）=（(a+1)+a～(a+1)+b回）=（2a+1～a+b+1回）
　（a+2回）+（a～b回）=（(a+2)+a～(a+2)+b回）=（2a+2～a+b+2回）
　　・・・
　（b-2回）+（a～b回）=（(b-2)+a～(b-2)+b回）=（a+b-2～2b-2回）
　（b-1回）+（a～b回）=（(b-1)+a～(b-1)+b回）=（a+b-1～2b-1回）
　（b-0回）+（a～b回）=（(b-0)+a～(b-0)+b回）=（a+b～2b回）

1つめの式により、2a回からa+b回の任意の繰り返し回数が生成できることが判る。また、それ以降の式の最大繰り返し回数が、a+bから2bまで1つずつ順番に増加して行くことから、結果として、2a回～2b回の任意の繰り返し回数を取ることができることが判る。すなわち、（a～b回）+（a～b回）=（2a～2b回）は成立する。

次に、x=3の場合、すなわち{a,b}{3,3}の場合について考えてみる。

x=3つまり外側の繰り返し回数が3回なので、内側の（a～b回）を3回繰り返す、すなわち、

　（a～b回）+（a～b回）+（a～b回）=（3a～3b回）

が成立することを考える。

ここで、（a～b回）+（a～b回）=（2a～2b回）が成立することを利用して、上記の式を下記のように変形する。

　（a～b回）+（2a～2b回）=（3a～3b回）

ここでx=2の場合と同じように、1回目の内側の繰り返し回数が、a回からb回に変化するのを順番に追っていってみる。

　（a+0回）+（2a～2b回）=（(a+0)+2a～(a+0)+2b回）=（3a～a+2b回）
　（a+1回）+（2a～2b回）=（(a+1)+2a～(a+1)+2b回）=（3a+1～a+2b+1回）
　（a+2回）+（2a～2b回）=（(a+2)+2a～(a+2)+2b回）=（3a+2～a+2b+2回）
　　・・・
　（b-2回）+（2a～2b回）=（(b-2)+2a～(b-2)+2b回）=（2a+b-2～3b-2回）
　（b-1回）+（2a～2b回）=（(b-1)+2a～(b-1)+2b回）=（2a+b-1～3b-1回）
　（b-0回）+（2a～2b回）=（(b-0)+2a～(b-0)+2b回）=（2a+b～3b回）

x=2の場合と同様である。1つめの式により、3a回からa+2b回の任意の繰り返し回数が生成でき、また、それ以降の式の最大繰り返し回数が、a+2bから3bまで1つずつ順番に増加して行くことから、結果として、3a回～3b回の任意の繰り返し回数を取ることができることが判る。すなわち、（a～b回）+（a～b回）+（a～b回）=（3a～3b回）は成立する。

一般化してn回の場合も同様に、

　（a～b回）₁+・・・+（a～b回）_(n-1)=（(n-1)a～(n-1)b回）

が成立することから、

　（a～b回）₁+・・・+（a～b回）_n=（na～nb回）

は、

　（a～b回）+（(n-1)a～(n-1)b回）=（na～nb回）

となり、今までと同じように、

　（a+0回）+（(n-1)a～(n-1)b回）=（(a+0)+(n-1)a～(a+0)+(n-1)b回）=（na～a+(n-1)b回）
　（a+1回）+（(n-1)a～(n-1)b回）=（(a+1)+(n-1)a～(a+1)+(n-1)b回）=（na+1～a+(n-1)b+1回）
　（a+2回）+（(n-1)a～(n-1)b回）=（(a+2)+(n-1)a～(a+2)+(n-1)b回）=（na+2～a+(n-1)b+2回）
　　・・・
　（b-2回）+（(n-1)a～(n-1)b回）=（(b-2)+(n-1)a～(b-2)+(n-1)b回）=（(n-1)a+b-2～nb-2回）
　（b-1回）+（(n-1)a～(n-1)b回）=（(b-1)+(n-1)a～(b-1)+(n-1)b回）=（(n-1)a+b-1～nb-1回）
　（b-0回）+（(n-1)a～(n-1)b回）=（(b-0)+(n-1)a～(b-0)+(n-1)b回）=（(n-1)a+b～nb回）

となり、（a～b回）₁+・・・+（a～b回）_n=（na～nb回）が成立する。

以上のことから、「α{a,b}{x,x}」は、常に「α{a*x,b*x}」に変換できると言うことができる。

次に、外側の繰り返し回数に幅がある場合、すなわち「α{a,b}{c,d}」の場合に、ac～bd回の任意の繰り返し回数を生成できるか否かについて考えてみる。

ここで、以下のような複数の変換について考えてみる。

　「α{a,b}{c+0,c+0}」を「α{a(c+0),b(c+0)}」にする
　「α{a,b}{c+1,c+1}」を「α{a(c+1),b(c+1)}」にする
　「α{a,b}{c+2,c+2}」を「α{a(c+2),b(c+2)}」にする
　　・・・
　「α{a,b}{d-1,d-1}」を「α{a(d-1),b(d-1)}」にする
　「α{a,b}{d-0,d-1}」を「α{a(d-0),b(d-0)}」にする

つまり、外側の繰り返し回数を固定にして、一つずつ増やしていった場合について、それぞれの変換について考えてみる。上記の変換は、外側の繰り返し回数が同じであるため、今までの証明から全て成立するということができる。

ここで、変換後の「α{ac,bc}」「α{a(c+1),b(c+1)}」・・・「α{ad,bd}」の繰り返し回数の範囲が互いに重複しているのであれば、「α{a,b}{c,d}」の繰り返し回数が、ac～bd回の全ての繰り返し回数の値を取ることができると言うことができるはずである。

数直線で書くと、こんな感じになるだろうか。

式で書くと、b(c+0)+1>=a(c+1) かつ b(c+1)+1>=a(c+2) かつ・・・かつ b(d-1)+1>=a(d-0) という条件式になる。表現を変えれば、下記のようになる。

上記の式は、下記のように書き換えられる。

ここで、iは必ず正の値であり、かつ、単調増大であること、及び、aとbの値は変わらないことから、iがもっとも小さいとき、すなわちi=cの場合にi(b-a)>=a-1が成立すれば、iがcからdまで変化する場合の、全ての場合について成立すると言うことができる。

以上のことから、c(b-a)>=a-1が成立する、あるいは、c=dが成立するならば、「α{a,b}{c,d}」=「α{a*c,b*d}」が成立すると言うことができる。

と、こんなもんでどうだろうか？　あっているだろうか？

正規表現の最適化1

2009-05-07T23:14:00.001+09:00

下らないことを考えてみた。

正規表現で、繰り返しを表す記号（数量子とか言うらしい）には、*とか、?とか、+とか、{a,b}とか、いろいろある。また、その中にも最長一致とか最短一致とか強欲なマッチとかいろいろな種類がある。

とりあえず、最長・最短・強欲の種別は無視するとして、*・?・+・{a,b}の指定に関して、正規表現を最適化することについて考えてみた。

*は0回以上の繰り返しを表す。すなわち機械的に{0,}に置き換えることができる。同様に、+は{1,}に、?は{1,0}に置き換えることができる。また、{a,b}の形式でbが省略された場合は、bに十分大きな値（例えばINT_MAX）が指定されたと考えれば、全ての数量子は{a,b}の形に正規化することができる。

そこまではいい。問題はここから。

α{a,b}{c,d}と指定されたら何が起きるのか、ということについて考えてみる。この指定の直接的な意味としては、正規表現αが、最低a回・最大b回繰り返し、かつ、それが最低c回・最大d回繰り返すということになる。つまり二重の繰り返しになるということだ。

だが、素直に考えるとこれは無駄である。例えば、α{0,1}{0,INT_MAX}と指定された場合は、内側の{0,1}の指定は全く意味が無くただの無駄以外の何物でもない。すなわち、α{0,INT_MAX}と最適化してあげるのが妥当である。

同じように、α{2,3}{4,5}と指定された場合にはα{8,15}としてあげることができるはずである。そうすれば、マッチを行う際の処理効率が大幅に向上するはずだ。（まぁ、元よりこんなアホな指定をする人間が悪いという考え方もあるのだが）

そう考えると、一般的にα{a,b}{c,d}と指定された場合は、α{a*c,b*d}と変換してあげることができるような気がする。

しかし、よく考えるとこの変換には無理がある。例えば、α{20,21}{2,3}という指定について考えてみる。この場合、先の変換公式に従うとα{40,63}という形になるのだが、実はα{20,21}{2,3}とα{40,63}とは等しくないのである。

すなわち、α{40,63}とした場合は、正規表現αが最低40回・最大63回繰り返すと言うことを意味しているのだが、α{20,21}{2,3}とした場合は、αが40回・41回・42回・60回・61回・62回・63回のいずれかの繰り返しになると言うことを意味する。よって、この変換は成立しない。

よくよく考えると、ある特定の条件が成立した場合だけα{a,b}{c,d}をα{a*c,b*d}に変換できるということに気がついた。だが、その条件については、今日はもう疲れたからまた今度書くことにする。

あな

2009-05-01T13:18:00.001+09:00

スーツを新調した。

別に、この年になってから性に目覚めておしゃれに気を遣うようになったためでもなければ、季節の変わり目だからという訳でもない。単に、スーツのズボンに穴が空いたためである。

いつも人に笑われるが、俺は外出する際には常に鞄は肩から提げるようにしている。典型的なオタク臭の漂うあのスタイルである。それは通勤の際も同様であり、必ず鞄は肩にかけている。その都合上、鞄の生地とスーツの腿のところがこすれて、気を付けてないとズボンに穴が空いてしまうのだ。

俺的には穴が空こうがズボンをはいていなかろうが、別にどうでも良いとしか思っていないのだが、しかし、曲がりなりにも客商売である以上、最低限まともな格好をしている必要がある。例えよれていようが型が古かろうが、最低限、穴や破れの無いスーツっぽい布きれでチンコとすね毛を隠さねばならない。これはサラリーをもらう社会人として必須である。

そういうことで、手取りが少なくなり、ますます生活が苦しくなりつつあるこの状況下でありながらも、思い切ってスーツを買ってしまった。

だがそもそも、穴が空かなければ無駄な支出を削減することができるのだから、例の腐臭漂うスタイルをやめればいいのではないかとも思うのだが、しかしこれはそう簡単な問題ではない。あの格好はいろいろな条件を勘案するともっとも安全であるという結果が導き出されるスタイルのなである。

まず第一に楽である。わざわざ手で鞄を持つ必要がないため、疲れにくい。第二に、置き忘れる心配がない。手で持っているとついどこかに置きたくなるが、そうすると置き忘れる危険性がある。手放さなければ置き忘れる心配はない。第三に、痴漢に間違われるリスクを軽減することができる。電車内で、鞄で股間を護り、両手を上に上げていることで、あらぬ言いがかりを付けられるスキをなくすことができる。

というか、むしろ鞄を手に持って満員電車に乗っている奴らの方が不思議である。あれはわざとやっているのだろうか？　鞄を手に持ち下におろしていると、ちょうど手がケツの部分にあたる。それを判った上で、女のケツを触るべくしてわざとそうやっているのか、さもなくば著しく頭の働きが鈍く、現実が認識できていないのか、そのどちらかとしか思えない。そういった連中がいる限り、世の中から痴漢が無くなることはないだろうし、同時に、痴漢の冤罪が無くなることもないだろう。

いずれにせよ、いろいろな意味でのセキュリティ的観点から言って、鞄は手に持つものではなく肩に提げておくべきものであるという結論が導き出される。

だがこのスタイルにはいくつかの重大な欠点がある。まず、先にも書いたがスーツに穴があくという問題が挙げられる。ジーンズの生地ですらこすれて薄くなり、ついには貫通するぐらいなのだから、スーツのペラペラな布きれなどたちどころにやられてしまう。次に、このスタイルは自ら公衆に対してオタク・マニアの類、すなわち、被差別階級の所属であることを公言しているようなものだということである。大多数の人は、おそらくこのレッテルを背負うことを恐れ、忌み嫌うのだろうが、俺はもはやそのような問題は超越している。マニアは、他者からマニアであると蔑まれることは気にしない。

しかし、余分な出費が嵩む現実は残る。合理性を妥協するつもりはないが、穴が空く問題には何らかの対処が必要であろう。

経歴

2009-04-23T23:13:00.001+09:00

努力の甲斐あって、技術士の試験の受験申し込み手続きが完了したようだ。とりあえず、申し込みを受理したとか何とかそういった内容のメールが来た。これは、受験ができるという解釈で間違いないのだろうか？　いずれにせよ、受験票が来る頃になってみれば判るだろう。

提出した業務経歴だが、これは当然の事ながら素直には書いていない。何せ、入社してから今年の3月末でちょうど7年なのである。入社直後には当然の事ながら研修が行われ、その間はもちろん仕事なんかしていない。配属後だって、右も左も判らないような新人に何ができるわけでもないし、さらには、しばらくの間仕事を離れて研修漬けだった期間もあるわけで、それを単純素直に書いたら「技術士にふさわしい業務の経歴が7年以上」という制約条件を満たすことができない。

だから、入社直後の期間については、そのころやっていた開発プロジェクトの名前を適当に書いておいた。まぁ、全く何も知らないものを書いて、変な突っ込みを受けてボロを出すわけにも行かないから、ある程度話ができるような物を挙げておいたのだが。また、しばらく研修で仕事をしていなかった時期については「○○の研究」ということでごまかしておいた。まぁ、内容の程度は別として、嘘は言っていない。

最近のものにしたって、普段はノーマルな受注開発を行っているノーマルな雑用係に過ぎないのだから、それをそのまま実体通りに書いても制約条件を満たすことはできない。受験要項を見ると「科学技術に関する事項についての計画・研究・設計・分析・試験・評価」をやっていることとある。だから、なんとしても語尾を「計画」「研究」「設計」「分析」「試験」「評価」のいずれかにしなければならない。しかしこのうち、「計画」「分析」「試験」「評価」というのは、ちょっと余りにも実体とかけ離れた感がある。とりあえず「設計」であればあながち嘘ではないので、全部これにしておいた。

順序にしたって、当然の事ながらオーバーラップする部分はあるはずで、それをそのまま書くことはシステム上の制約からして不可能である。だから、多少は実体とずれている部分がある。いや、はっきり言おう。かなりずれている。だが、こればかりは仕方がない。何せ、入社してから7年でパッツンパッツンなのである。期間を短くすることはできない。明らかに怪しいが、みっちり「設計」と「研究」に明け暮れていました、という内容にしておいた。

内容が何であれ、それを証明する「公印」は取ってきたのだし、問題は無かろう。経歴を証明する手だてもなければ、それを確認する術もないのだ。後は、（筆記試験に受かったらの話だが）口頭試問でボロが出ないようにすれば良いまでの話だ。まぁ、それが難しいのだが。

公印

2009-04-17T19:01:00.001+09:00

技術士の2次試験の申し込みが終わった。

技術士の2次試験は実務経験を求めており、業務経歴書を出さなければならない。俺の場合、1次試験に受かったのがついこの間の事なので、「7年以上の実務経験」という奴についての業務経歴書が必要になる。

とりあえず、今年の3月末で入社してから丸7年になるため、何とか適当なことを書いて業務経歴書を書き上げることぐらいは不可能ではない。入社1日目から研修もなくいきなり実務に携わっていました、というかなり無謀な経歴書ではあるが、書くだけならなんとでもなる。

しかし問題は、その業務経歴書には「会社の公印」というのが必要になるということだ。

そもそも「公印」というのが何なのかが判らない。gooの国語辞典を調べても、「公の印」としか書かれていない。これでは何の説明にもなっていない。まぁ、受験申し込みの要項をみると「所属部課の責任者の印」とあるから、課長か部長ぐらいの印があればいいのだろうと勝手に考えていた。しかし、だとしてもどんなハンコをもらえばいいのか？　要項には「無職の場合や自分が会社の社長の場合には、本人の私印を押せ」と記載されていることを考えると、少なくとも認印ではないものと考えられる。では、一体何なのか？

締め切りは4月20日で、その前の日は土日で会社が休みであることを考えると、時間は限りなく無いに等しい。仕方がないから、ヤケクソで総務の人に電話して訊いてみたら、どうやら「公印」として使える事業部長名の印鑑があるという。とりあえず、それをもらってくれば間違いないようだ。

困った。

事業部長というのは、俺から見れば上司の上司の上司の上司の上司である。はっきり言うが、顔を見たこともなければ口をきいたこともない。名前を知っているかどうかというレベルの人だ。課長か部長であれば、多少内容がいい加減であったとしても、なぁなぁで承認してもらうこともできるだろうが、こんなエンもユカリもないおっさんを丸め込むことができるのだろうか？

できるもできないも無い。やるしかない。この時点ですでに申し込みも受験料の支払いも終わっているのだ。受験料1万4千円を無駄にしないためにも、なんとしても印を取ってこなければならない。それも、日程的にはその日の内にやらなければ間に合わない。

そして俺はやった。成し遂げた。かなり無理のある経歴書の内容も受験申込書も、一言一句直すことなく認めさせた。出してしまった後だからいうが、受験申込書に書いた会社の部署名が間違っていたが、それも含めて認めさせた。というか、気づかれる前に印を取ってきた。

まぁ、受験の申し込みだけで、そう大した書類ではないから、ほとんど何のチェックも入らなかっただけなのではあるが、それでも内向的な俺が即日で公印を取ってきたいうのは、大変なことである。俺的には、これを片づけただけですでにおなかいっぱいである。

だが、試験自体はこれからである。そもそも、まだ書類を提出したばっかりで、受験できるかどうかも判らない。とりあえず、受験が認められることを神に祈りつつ、筆記試験の勉強でもすることにしよう。

げんこうといっしょ

2009-03-22T18:40:00.002+09:00

2月半ばほどから微妙に忙しかったのだが、3月に入ってからは本格的に苦しいことになってしまった。「現行システムと同じことをするプログラム」なる物を作っていたのだが、その現行システムというやつが何をどうしてそういう結果になるのかが理解できない酷い代物であるため、開発に苦労したのだ。

たとえ既存部分のプログラムが見苦しい代物であったとしても、業務処理がはっきりとしていれば、「現行システムと同じ処理をするプログラム」と作ること自体は不可能ではない。なぜならば、既存部分を全く無視して業務用件から仕様を導き出せばいいのだから。しかし、そもそもの業務用件が複雑怪奇な場合はそうもいかなくなる。

なぜならば、業務処理内容が複雑だと、その仕様を理解している人間が存在しなくなってしまうのだ。つまり、客に「この処理はどうすればいいのか」と聞いても「よくわからないから、それは現行と同じようにしておくように」と言われるだけで、何をどうすればいいのかについて教えてもらえなくなるのだ。

いわゆるレガシーという奴である。

しかし、どうしてそういうことになるのだろうか？　そもそも、業務システムという奴は、元々人間が手でやっていた仕事を機械でやらせるようにしただけの代物のはずである。ということは、もとはそれほど複雑な物ではなかったはずなのである。それなのになぜ、奇っ怪な化け物になってしまうのだろうか？

いろいろ理由はあるのだろうが、俺が思うに、システムというのは使われ出すと、仕様の元となった業務自体に影響を与えるからなのだと思う。つまり、業務を元にシステムの仕様が決められたはずなのに、システムが逆に業務に影響を与えるのではないかと思うのだ。（というか、そういう話をどこかで聞いたことがある気がする）

システムを使う側はシステムの中身については一切知らない。ただ、入力と出力が見えるだけである。そして、とにかくそれを使って仕事をしなければならない。そうなると、システムにあわせて人間が業務処理を変えてしまう可能性が出てくる、というか確実にそうなる。

そして、そうなると今度は、人間が業務処理を変えたのにあわせてシステム側が改修される。改修されたらまたそれに合わせて人間が仕事のやり方を変える・・・。そういったことの繰り返しで、長年の間に誰にも仕様が把握できない怪物が育ってゆくのである。

そうなるとその怪物には誰にも手が出せなくなる。手が出せないからそのまま放置しておく。するとますます怪物が成長する・・・。悪循環の繰り返しである。

おまけに、その悪循環を断ち切るべくシステムを作り直したとしても、システムを作るときには決してビジネスフローが見直されることがないため、新規にできた物は結局現行と同じ複雑怪奇な怪物だったりするためたちが悪い。

おそらく、「できた物」が「元となった仕様」に影響を与えるという問題は、元の仕様が人間そのものである限り、決して根本的には解決できない問題なのだろう。しかし、だとしても設計書やその他の文書として「どんな処理を行っているのか」について、ちゃんと書いておけばこんな苦労はしなくて済むはずである。なぜ、そんな当たり前のことができ無いのだろうか？

不思議だ。

事例

2009-03-02T07:46:00.000+09:00

世に言われている通り、業務システムで作られるプログラムには、時に常軌を逸して酷いものがある。正直言って、どこの素人が書いたのかと言いたくなるほどいい加減なものもある。

例えば、メモリを解放し忘れてたり、エラーが発生するとメモリの二重解放が起きてプロセスが落ちたり、ハンドルを閉じ忘れていたりする。だがまぁ、それはまだ可愛い方だ。とりあえず、結果オーライで動いているのだし、それに、間違えやすいポイントであり、必ずしも理解できないわけではない。

だが、中には作った奴の正気を疑いたくなるような記述もある。例えば、次のようなプログラム。

/* ↑ファイル名を取得する */
r = GetPrivateProfileString( ・・・ );

今時GetPrivateProfileStringを使うなと言う突っ込みではない。また、「ファイル名を取得する」等という、明々白々ことをコメントに書くなと言う突っ込みでもない。俺が怒っているのは、明らかに矢印の向きが間違っているということなのだ。

一体これは何を意図した記述なのだろうか？　これを書いた奴は矢印の向きを間違って覚えているのだろうか？　それとも、正真正銘の気違いなのだろうか？


/***************************************************
*                 日付をする処理
***************************************************/
int ProcessDate( ・・・ )
{
　・・・
}

ユーザが入力した日付の入力チェックを行う関数の前についていたコメント。「日付をする」って日本語として成立してネェし。


/* ↑日付のニューメリックチェック */
int d = atoi( strDate );
if ( d < 101 || d > 1231 ) {
    /* ↑エラー */
    ・・・
}

atoiで文字列を数値に変換してもニューメリックチェックにはならないと思うのだが、気のせいだろうか？　値の範囲のチェックぐらいはできるだろうが、その間にある不正な値、例えば「0231」とかのチェックはできてないし。

ついでに言うと、この無意味な処理の後で、上記の「日付をする処理」を呼び出して、詳細な入力チェックを行っていた。


long wlong1[1000];
long wlong2[1000];
long wlong3[1000];
char *area;
char *area2;

データの並べ替えを行うための作業用の領域らしいのだが、変数名からはそういったことが読み取れない。変数名がwlongでは、long型の作業用領域だと言うことしか判らない。変数名で言うべき事は値の型ではなく、それが何のために使用されるのか、何の値が格納されるのかということを言うべきである。

当然、同じ事がareaにも言える。areaでは、何が入るのか全く想像もつかない。

また、long型配列に格納された整数値を並べ替える処理を自分で実装するな。それも、なにやら奇妙でトンチンカンなソート処理を作っているんじゃない。qsort関数ぐらい使え。というか、そんな暇があったのなら、コメントをちゃんと書け。


/***************************************************
*            ファイルを検索する処理
***************************************************/
int MakeEnv( ・・・ )
{

}

「MakeEnv」という関数では、不要になったファイルを削除する処理を行っている。にもかかわらず、コメントには「ファイルを検索する処理」。何も言うことはない。

「前向き」に解釈すれば、作っているときにテンパッてこうなってしまったのだと、考えられなくもないが、しかし、余りにも酷いのではないだろうか？　常軌を逸したコメントを見ていると、本当に書いた奴の知能のレベルが低かったのだと思わざるを得ない。

錠前

2009-02-26T07:28:00.000+09:00

世の中には不思議なことをする人間がいる。

よく、扉の鍵を閉めた後に、ノブを回して扉を前後に動かしてみるという行為をする人がいるが、あれは一体何を目的とした行動なのだろうか？

当然の事ながら、鍵を閉めた後なのだから、扉には鍵がかかっている。その扉を無理に開けようとしても、当たり前だが扉が開くことはない。そんな当たり前なことを確認して、一体何が嬉しいのだろうか？

どうやら、本人としては「鍵を閉め忘れていないかどうか」を確認したいがための行動であるらしい。しかし、鍵を閉めた後に扉を開けてみるという行動では、決してその目的が達せられることはないはずである。

なぜならば、鍵を閉め忘れた時には、扉を無理に開けるという確認もし忘れるはずだからである。

すなわち、扉を無理に開けるという行動によって確認できるのは、錠前が期待通りに正しく動作しているか否かという事だけであり、自分が鍵をかけ忘れたか否かという意味では、全く何の確認にもなっていないのである。

それなのに、その行動を執拗に繰り返す人間がいるのが不思議でならない。俺の隣近所に住んでいる奴が、特に著しい。朝、鍵を閉めた後にガチャガチャと数分間に渡って扉をこじ開けようとし続けている。それもかなりの勢いでやるから、音が周囲に響いて著しく不快である。

錠前の動作を疑い、その確認をするのは本人の考え方の問題であり、ましてや、それを何回行おうが他人の知ったことではないはずである。しかし、それは他人に迷惑をかけていない場合の話であり、その行動により少なくとも一人以上、不快に感じている人間がいるのだから、控えるべきだと思う。特に、その行動に余りにも合理性が無い場合には、周囲の人間をいらだたせるばかりだから、なおさらである。

別に、錠前の動作確認をするなとはいわない。だが、せめて静かにやってくれ。うるさいから。

ログ

2009-02-21T23:17:00.002+09:00

「主筆」の文字列処理を変更する作業で、プログラムの全体に渡って手を加えた。そのため、今度はデバッグが大変なことになっている。

全く動かないというわけではないのだが、やはり、変更したからには動作を確認する必要がある。しかし、変更箇所が多く全てを確認するのは大変だ。

まぁ、業務用のアプリケーションなら一も二もなくテスト漬けにして品質を担保するのだろうが、所詮ロハで公開しているフリーソフトである。そこまでする気力はない。とは言っても、とは言っても、やはり品質は気になる。

そういうことで、横着しつつも品質を向上できるような方法をいくつか取り入れることにした。

ひとつはassertを大量に埋め込むことである。今までも使ってこなかったわけではないのだが、それでも使用方法は限定的だった。だがこれからは、もっと積極的に導入することにした。

次に、ログ出力機能の追加である。ログを出力させることで、内部の処理が正しく行われていることを確認しようと言う訳だ。ログを出したからとて、直接的に品質向上につながるわけではない。しかし、それでも内部の状態を確認することにより、プログラムの正しさが（一面的ではあるが）確認できるので、まぁ、ある程度の効果はあろうというものだ。

だが、ログ出力機能を付けると言うことは、またしてもプログラム中の至る所に手を加えると言うことになる訳で、逆に状況が悪くなるのではないかという気がしなくもない。

だがまぁ、いいか。

文字列処理の変更

2009-02-05T07:36:00.000+09:00

このところ、自分で使うためのソフトいくつか作っていたのだが、そろそろ「主筆」の開発に戻ることにした。

かなり前にもここに書いた覚えがあるが、今現在取り組んでいるのは、「主筆」内部で取り扱う文字列をワイドバイト文字列で統一する作業である。

「主筆」内部では、基本的には文字列はワイドバイト文字列（すなわちwchar_tの配列ないしstd::wstring）で取り扱うようにしているのだが、一部そうでない部分がある。正確に言えば、ファイル名は全てマルチバイト文字列（すなわちcharの配列ないしstd::string）で取り扱っている。

だが、移植性や互換性といったプログラムの品質といったものを考えた場合、文字列は全てワイドバイト文字列で取り扱うのが正しいように思われる。しかし、Solarisはシステムコールやライブラリ関数がワイドバイト文字列に対応していないことが多く、酷く厄介である。

Windowsの場合、ほとんど全ての関数に対して、マルチバイト文字列（実装上はShift-JIS）を取り扱うバージョンと、ワイドバイト文字列（実装上はUCS-2、すなわちサロゲートペアの無い16ビットのUnicode）をおり扱うバージョンとか用意されており、かつ、それらをコンパイル時に切り替えられるようにするたの関数とか用意されている。

つまり、Windows上でプログラムを作る場合は、文字列は全てCStringないしTCHAR型配列として実装すればよく、ライブラリの非互換性などの問題は時々気にしてやればいいだけである。しかしSolarisの場合、外部の関数を呼ぶ場合にはほとんど全ての場合において、文字列のエンコードをマルチバイト文字列に変換してやらなければならない。

例えば、ファイルを開くためにfopen関数を呼ぶにしても、ワイドバイト文字列のバージョンは用意されていないため、ファイル名をマルチバイト文字列に変換してからファイルを開くということをしてやらなければならない。

面倒なことこの上ない。しかも、処理が遅くなりそうで気に入らない。だから「主筆」では、ファイル名などの一部のデータはマルチバイト文字列のままで処理するようにしていた。しかし最近になって、ワイドバイト文字列とマルチバイト文字列の混在による複雑さが手に負えなくなってきたから、面倒さはあるとはいえ全てワイドバイト文字列で統一することにしたのだ。

プログラム内部の処理方式を変えたからといって、基本的には外部に影響を及ぼすことはない。元より、ユーザがマウスとキーボードで操作するだけのソフトである。文字列の形式など問題とはなり得ない。しかし、今回の対応を行うことにより、一部分どうしても影響を受けざるを得ないものがある。

それはプラグイン関数のインタフェースである。プラグイン関数では引数にファイル名を受け取るものがあるが、そのファイル名がマルチバイト文字列（すなわちconst char*）になっているのである。

互換性のためにはconst char*の引数を受け取る関数を変更するわけにはいかないが、逆に手つかずのままにしておくこともできない。だとすると、const wchar_t*を受け取るバージョンの関数を新たに作って提供しなければならないことになる。

どうにも面倒だが、まぁ、仕方あるまい。

蝋燭

2009-01-25T10:07:00.003+09:00

数日前にyahooのニュースで、電気を止められてロウソクで生活していた人が、火災を起こしたというニュースが流れていた。

電気をとめられた場合、電力会社によって違うかも知れないが、100W程度の電気までならただで使わせてくれる可能性がある。つまり、電流制限器という1Aのブレーカーを取り付けられた上でなら、電気を使わせてくれるサービスを提供している。これは、まさに今回のような事件を防止するために行われている事だ。この事件の場合、電気を止められる際に、このサービスについての説明は無かったのだろうか。

電気代を払わないでいると、当然の事ながら電気を止められることになる。しかし、止められるとは言ってもいきなり供給が絶たれるわけではない。止められるまでにはいくつかの段階がある。詳細は電力会社によって異なるが、俺が知っているある電力会社の場合を例にとって説明してみる。

まず、しばらく滞納していると督促の紙が来る。それを無視していると集金の人が自宅にやってくる。その場で払えば当然の事ながら事なきを得る。しかし、金がないなどの事情で支払いを断ると、いつまでに払えという脅し文句を言って帰っていく。また、集金人が自宅にきたときに相手が留守だったら、いつまでに払えと書いた紙を置いていく。

脅し文句や置いていった紙を無視して、さらに払わないで頑張っていると、またしても集金人がやってくる。そのときには、いつまでに払わないとマジで止めるぞｺﾞﾙｧと言うことが書いてる紙を置いていく。

滞納の前科などによっても扱いは変わるが、長ければその後二回ほど警告の紙を渡される可能性がある。ついでに言うと、その紙には上記の「ちょびっとだけロハで使わせてくれるサービス」についての記載がある。

何回か渡される「止めるぞｺﾞﾙｧ」と書いた紙の文章はその都度内容が異なり、だんだん脅しの程度が強くなってくる。そして、左上に「最終」と書かれた紙を受け取ったら、もう後が無くなる。つまり、この次に集金人が来るときには、具体的に電気を止める作業をしに来ると言うことだ。

電気を止められると、「電気を止めてやったぞ、ざまぁみやがれ。でも金は払いやがれ」と書かれた紙を置いて行く。その状態で金を払えば、また電気が供給されるようになる。

電気を止められてもなお支払いを拒み続けていると、またしても集金人がやってきて、金を払えと言ってくる。それでも払わないで頑張っていると、最後には電気契約を破棄されることになる。しかしそれでも債務が消えるわけではなく、その後も何回か集金人がやってくる。その後どうなるのか、ここから先は俺は詳しいことは知らない。

だが、一般論としてはこのような不良債権は、専門の取り立て屋に売却されるため、時効が成立するか夜逃げに成功するまではずっと取り立てが続くものと思われる。

契約上、三ヶ月ぐらい滞納すると電気を止められる危険が発生するわけだが、しかし、初犯の場合は結構待っていてくれたりもする。この辺りは交渉次第と言ったところだろうか。しかし、常習犯の場合は相手も強行にでてきて、場合によってはいきなり止められるということもあるらしい。だから、全体的に遅らせてキャッシュフローを改善しようなどと言うことはあまり考えない方がいいのではないだろうか。

そもそも、集金の人はその道のプロであり、素人が立ち向かえる相手ではない。サラ金の取り立てではないので、幾分は甘いかも知れないが、それでも取り立て屋である。相手がいると判れば、夜打ち朝駆けを厭わない。平穏無事な人生を送りたければ、払うべきものは払った方がいい。

対話

2009-01-04T17:43:00.001+09:00

「主筆」のWebサイトを少しずつ変更している。

この間新規に作ったソフトを公開した以外にも、いくつかのページで採用していた対話形式のページを書き改め、普通のモノローグ形式に変更している。

特に深い理由があるわけでもないのだが、やはり対話形式だと「そういう物」にそれ相当の免疫のある人でないと読むに耐えないのではないかと思ったからだ。端的に言ってしまえば痛いのではないかと。

「痛い」心配は当初からあったのだが、まぁ、どっちみち内容自体が痛いのだしどうでも良いか、それよりかはインパクトが強い方が良いのではないか、そう判断して導入した対話形式なのだが、しかし、やっぱり痛いのではないかという方に最近考えが変わってきた。

俺自身に何があったというわけでもないのだが、ある種、思想の経年劣化なのかも知れない。

とりあえずそういうことで、1ページずつ順番に修正している。現時点で残す所は「主筆プラグインの開発について」のみである。これも気が向いたら、すぐに修正するつもりである。

同時に、Sun Studio 11の解説ページも全部削った。これはまぁ当然か。Sun Studio 12が公開されて久しいのにいつまでも11の話を載せておくわけにもいくまい。ただ、いくつかのページはSun Studio 11には余り関係のない話もあるから、それは焼き直して後日公開する可能性もある。

マルチスレッドの話も少し削った。余り具体性のない俺の妄想を語っているだけのページは、さすがに実がないと判断したからだ。書くのなら、実際にやってみて確認できるような、具体的な内容にしたいと思う。

しかし、こう考えてみると俺のWebサイトの内容は、どうも専門性に欠けるというか、総じて何を言いたいのか判らないようなサイトになってしまっているような気がする。何か一つのことについて集中的に述べる方が良いのだろうが、どうもそうなっていない。

今更抜本的に作り直す勇気はないが、それでも「これだけは他のサイトには負けない」というものを作って行くようにしたいものだ。

黒箱

2009-01-02T23:45:00.000+09:00

長年の逡巡のあげくに、ついにテレビを買った。PioneerのKURO KRP-500A。50インチのプラズマテレビである。安い奴にしようかと思っていたのだが、やはりここは思い切ってよさげな奴を買っておくことにした。60万弱だった。本体はおよそ55万だったが、接続に必要なケーブル類を含めると、それだけでも多少金がかかり、結局60万にちょっと足りないぐらいの金額となった。

まぁ、良いか。

それにしても、なぜD端子ケーブルとHDMIケーブルはあんなに高いのだろうか。5メートルのD端子ケーブルが約4千円、1.5メートルのHDMIケーブルが2千円。この2本のケーブルだけで6千円である。UPSが5千5百円だったことを考えると、高すぎではないだろうか。たかだかケーブルである。ただの導線を束ねただけの代物なのに、なぜあんなに高いのだろうか。

KPR-500Aはメディアレシーバーとかいう黒い箱がついている。これにはチューナー等が入っているらしいのだが、すでにBlu-rayディスクのレコーダーやAVアンプ・スピーカーなどを持っているから、俺には必要ないと思っていた。だが、逆にテレビの本体にはまともなインタフェースはついておらず、メディアレシーバーに全ての入出力が集中しているという構成になっていたため、使わざるを得なかった。

そうすると、このメディアレシーバーという奴をどこに置くのかが問題になる。今現在、AV機器を置いてある棚は4段しかない。しかも、この棚はこれ以上増やすことができない様だ。これは自分で組み立てるタイプの金網の棚だから、サイズが合う棚だけ買ってくれば増やすことができるはずなのだが、いかんせんこれはLuminousやERECTAのような著名なものではなく、安価な無名な奴であるため、同じものがどこで売っているかが分からない。そのため、増やしようがないのだ。

金に余裕があるのなら棚ごと買い換えてしまう所だが、それはいくら何でももったいない。だから、とりあえず一番使用率の低いレコードのプレーヤーをどけて、そこに黒い箱を設置しておいた。

そうすると今度は、レコードのプレーヤをどこに置くのかが問題になる。最近ではレコード自体が余り手に入らないことを考えると、まぁ、押入かどこかにしまってしまっても良いのだが、それは何か負けたような気がして忌々しい。何かうまい方法はないだろうか。

たな

2008-12-28T18:47:00.000+09:00

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

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

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

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

騰落

2008-12-27T22:44:00.001+09:00

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

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

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

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

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

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

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

破壊

2008-12-20T21:46:00.000+09:00

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

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

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

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

受注

2008-12-15T07:21:00.000+09:00

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

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

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

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

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

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

記録

2008-12-13T22:37:00.001+09:00

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

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

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

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

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

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

１．固定長のレコード形式にする。

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

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

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

２．テキスト形式にする

裸の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だけで戦う道は閉ざされる事となる。

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

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

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

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

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

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

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

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

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

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

５．同種の項目であれば桁数を揃える

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

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

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

開通

2008-11-29T14:13:00.001+09:00

引っ越してからようやくインターネットへの接続が開通した。俺が構築している室内のネットワークは、ネットワークアドレスとして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-18T00:04:00.000+09:00

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

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

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

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

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

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

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

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

経過

2008-10-15T22:35:00.000+09:00

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

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

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

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

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

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

期間

2008-10-04T14:36:00.000+09:00

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

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

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

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

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

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

ネコ

2008-09-24T20:42:00.000+09:00

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

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

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

ひねらずに寝ている。

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

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

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

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

更新

2008-09-23T11:55:00.001+09:00

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

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-21T16:39:00.000+09:00

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

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

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

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

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

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

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

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

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

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

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

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

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

低脳

2008-08-16T14:36:00.000+09:00

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

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

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

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

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

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

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

書類

2008-07-19T14:50:00.000+09:00

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

行折り返し

2008-06-29T21:26:00.000+09:00

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

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

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

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

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

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

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

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

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

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

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

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

２０

2008-06-28T20:20:00.000+09:00

とりあえず、「主筆」の第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-08T20:56:00.001+09:00

「主筆」のエンコードの自動認識機能・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-18T22:28:00.002+09:00

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

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

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

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

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

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

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

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

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

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

狭隘

2008-03-23T23:11:00.000+09:00

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

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

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

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

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

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

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

有効

2008-03-16T11:56:00.000+09:00

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

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

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

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

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

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

収入

2008-03-08T10:04:00.000+09:00

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

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

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

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

転嫁

2008-03-02T11:42:00.000+09:00

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

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

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

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

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

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

品質

2008-02-12T07:22:00.000+09:00

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

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

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

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

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

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

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

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

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

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

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

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

反省

2008-02-10T20:09:00.000+09:00

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

投擲

2008-01-23T23:10:00.000+09:00

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

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

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

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

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

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

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

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

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

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

Unicode

2008-01-01T19:12:00.000+09:00

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

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

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

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

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

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

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

面倒なことこの上ない。

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

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

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

積極的にユーザに問い合わせるべきだと思う

2007-12-31T10:39:00.000+09:00

文字コードの自動認識についていろいろ調べてみると、少なくとも日本語では、完全な自動認識というのは不可能であるらしい。まぁ、当たり前と言えば当たり前だが。当然のことながら、Shift-JISとEUC-JPとASCIIとJISとでは、文字コードとして使用する値が部分的に重複している。もし、入力したテキストファイル中に、たまたま重複した領域の値しか含まれていなかったとしたら、機械には判断のしようがない。

極端なことを言うと、A～Zまでのアルファベットしか含まれていないテキストファイルを読み込んだとき、それをASCIIと判断するべきなのか、Shift-JISとするべきかEUC-JPとするべきか、あるいはJISなのかBIG5なのか、それはユーザにしか判らない問題だと思われる。

無論、そのほかの様々な情報を総合すれば、ある程度の推定を下すことも可能だ。例えば、ShifT-JISとEUC-JPとで重複している文字コードの領域というのは、Shift-JIS側では余り使用されることの無いであろう文字ばかりであるとか、言語や文字コードが違えば値の出現頻度が変わるとか（例えば英語ならスペースやeが多い）、使用しているロケールがjaならばEUC-JPである可能性が高くBIG5は余り使われないだろうとか、いろいろと考えることができる。

だが、そういった情報による判断は万能ではない。ユーザの中には変な文字ばっかり使いたがる奴だっているかも知れない。意味もなく旧字旧仮名を使う気色の悪い連中だって、世の中にはいるのだ。どんな奴がいるか、知れたものではない。

いずれにせよ、完全な認識ができない限りどんなに高い精度で予測しようとも、必ず文字コードをユーザに問い合わせる機能は必要になるということだ。ということであれば、認識精度はそこそこでも構わないから、判断がつかないのならつかないなりに、ちゃんと「判らない」という答えを返す方が重要なのではないかと思う。

つまり、間違った答えを本物と信じて、ユーザに何も問い合わせることなくそのまま処理を続行してしまうのは、よろしくないのではないかと思われる。それならば、積極的にユーザに問い合わせるべきなのではないだろうか。

文字コードの自動認識

2007-12-24T08:41:00.000+09:00

「主筆」第19版を公開して以降、少しばかり開発を中断している。前にも書いたが、物の開発に対する意欲にはいくらか波があり、今はその谷間に来ている為である。とはいっても全く手を休めているわけではなく、エンコードの自動認識を行う機能を少しずつ作りつつある。ゆっくりとではあるが。

エンコードの自動認識は、今更自分で作り込まなくとも、既存の物がいくらでもあるような気もするのだが、いろいろと思うところがあって、結局自分で作ることにした。要は、「主筆」は日本語に依存したくないから、エンコードの自動認識機能も様々なエンコードに容易に対応できるようにしておきたかったのだ。

理論上は、世の中で使われているありとあらゆるエンコードに対応できるような自動認識機能を、自力で実装してしまえばいい。だが俺は、スワヒリ語やタガログ語はもとよりドイツ語やフランス語すら理解し得ない都合上、世の中全てのエンコードを使ってテストを行うことができない。つまり、英語と日本語以外のエンコードに対応できる自動認識機能は、俺には実装することができないのである。

ではどうすればいいのか。仕方がないからここは、俺には対応し得ないエンコードに対応する為のモジュールを、容易に追加・削除できるようにしておくしかない。そして後は、将来の俺か、あるいは俺以外の誰かに期待するしかない。

とはいっても、俺以外の誰かが俺にはできないことをやってくれるとは、到底思えないのだが。

出処進退

2007-12-08T21:24:00.000+09:00

第19版を公開し、Webページも更新したところで、Fire v250の方のOSを入れ替えることにした。どうにも環境の出来が悪く気に入らないためだ。ついでに、開発環境もSun Studio 11からSun Studio 12に更新することにした。

ところで、Sun Studio 12はSolaris 8には対応していない。ここでもし、開発用のソフトをSun Studio 12にしてしまったとしたら、Solaris 8は切り捨てなければならないことになるのだろうか？

確かに、今までの開発方式を踏襲するのであれば、そういうことになる。だが、残念ながら俺は、まだSolaris 8を見捨てるつもりはない。例えSunが捨てても俺は捨てない。

ではどうするのか？　Sun Studio 12に乗り換えたときにSolaris 8で実行できるバイナリが生成できなくなるのは、Sun Studio 12がSoaris 8上で動作しないためである。つまり、Solaris 8で動作するバイナリを生成するためには、Solaris 8上でコンパイルしなければならないため、使用しているコンパイラがSolaris 8で動作しないとなると、Solaris 8用のバイナリが生成できないと言うことになるのだ。（WindowsではAPIの互換性さえ保っておけば、Windows XP上でコンパイルしたバイナリもWindows NT 4.0上で動作させることができるし、うまくすれば9x系でも動作する。だが、残念ながらSolarisはそういうことはできないようになっているらしい。）

だがここで一つ疑問が生じる。なぜ、Sun Studio 12を使って作られたプログラムは、Sun Studio 12でコンパイルしなければならないのか。C++で書かれているのなら、C++に対応したコンパイラを使えばコンパイルできるはずではないか？

確かにその通りである。少なくとも、CやC++で記述された範囲であれば、何もわざわざSun Studio 12でコンパイルしなくともForte developper 6.0でだってコンパイルすることができる（はずだ）。だが、そうでない部分が一箇所ある。それは、X-Designerで生成されたファイルだ。

GUIのデザインを作成するツールであるX-Designerは、設計されたGUIを独自のファイル形式で保存する。そして、コンパイル時には保存された独自形式のファイルを読み込み、Cのソースコードを出力する。問題はこの独自形式のファイルで、こいつは古いバージョンの奴で作られたファイルを読むことはできるのだが、新しいバージョンのX-Designerで生成されたファイルを、古いバージョンのX-Designerで読み込むことができないのだ。Sun Studio 11と12の互換性についてはまだ調査していないが、少なくともForte Developper 6.0 Update 2とSun Studio 11の間ではそういう関係になっていた。だから、Sun Studio 11と12でも同様であると考えた方が良いだろう。

つまり、一度でもGUIのデザインをSun Studio 12で編集してしまったら、金輪際二度とSun Studio 11には戻れないと言うことだ。だから、Son Studio 12がSolaris 8に対応していないと、Solaris 8用のバイナリが生成できないという理論が導き出されることになる。

だがよく考えてみれば、というかよく考えなくとも、Solaris 8上でできないのはX-Designerの独自形式のファイルからCのソースコードを生成する部分なだけであって、生成されたCのコードがあればForte Developper 6.0やSun Studio 11でコンパイルすることが可能なはずである。現に、一筋縄ではいかなかったとはいえ、似たようなことであれば、やったことはなくはない。

だから、うまい具合にMakefileを書いて、X-Designerで生成したGUIを表示するためのCのソースも一緒に配布してやるようにすれば、Solaris 8上でコンパイルすることも可能になるはずなのである。とはいえ、リンクするライブラリを配布する問題とか、いろいろとパス名が違う問題とかがあり、そう簡単にできることでもないのだが。

いずれにせよ、多少工夫してやればSun Studio 12に乗り換えてもSolaris 8を切り捨てる必要はなさそうである。

だが、ここにいたって別種の問題が持ち上がってきた。それは、Solarisの将来のバージョンではCDEがサポートされなくなることだ。前々からそんな話はなくもなかったが、ここに来て、CDEでログインする際に「将来のバージョンではサポートされなくなるから早くJava Desktop Systemに切り替えろ」という意味のメッセージが表示されるようになった。

見てくれが悪いからなのか共産主義者が多いからなのか何なのかは知らないが、世の中一般ではCDEは嫌われる傾向になるらしい。だが、誰なんと言おうとも俺はCDEが好きだ。GNOME何か死んでも使いたくない。あんな腐った鈍重なデスクトップ環境など、到底使用には耐えない。とはいえ、OpenWindowsと同様にSolarisでCDEが使えなくなるのは、もはや時間の問題である。

こうなると、さすがにそろそろ「主筆」の出処進退について考えなくてはならなくなるようだ。主筆はSolaris上のCDEで快適に動作することを特徴としている。そのCDEが無くなるとなると、「主筆」の居場所も無くなってしまうのだ。

どうやら、俺と「主筆」に与えられた選択肢は三つあるようだ。一つはこのままSolarisのCDEと共に心中する道だ。未だにCP/Mを使い続ける人がいるのと同じように、Solaris/CDEもこの世の中から完全に消えて無くなるまでには、相当の時間がかかるものと思われる。だから、このままCDEに拘泥し続けて残存者利益を享受し、最後はCDEと共にひっそりと消えていくという道が考えられる。

二つ目はネイティブのデスクトップ環境をJava Desktop Systemに替えることだ。なんだかんだと言っても、やはり時代はGNOMEやKDEに傾きつつある。これは致し方のない事実だ。ということで、「主筆」をJDS上で快適に動作するよう作り直すという方法が考えられる。だがこれは、GPL臭いものは嫌いだという俺の宗教観に真っ向から対立する道であり、そう容易には採用できない。そもそも、GNOMEをメインのデスクトップ環境として使うようにするのであれば、そもそもがSolarisである必要はなくLinuxに乗り換えてしまった方がマシである。

三つ目は、未だにCDEで頑張り続けている他の商用UNIXすなわちAIXないしHP-UXに乗り換える道だ。今の俺の心情では、この方向性が一番魅力的である。だが、それにはAIXないしHP-UXが動作するマシンを用意する必要があるため、それなりに経済的負担を負わなければならないという問題がある。

最近仕事で、HP-UXに触れる機会があり、その痺れるようにカッコイイCDEのデザインに心引かれつつある。やはり、売れなくなってきて共産主義者に媚びを売る様になった軟弱者とは格が違う。ログイン画面もへたれならログイン後の画面もいい加減で、俺の心の琴線を刺激してやまない。アレぞまさしく男のロマンだ。俺の目指すべき理想の姿がそこにある。

だがそうは言っても、俺の手元にある実弾は心許ない。もう少し戦線が回復できたら、HP-UXかAIXへの移行について検討することとしよう。とりあえずそれまでは、Solaris依存の部分を共通的な方式に変更する仕事でもやることにしよう。

第19版の公開

2007-12-02T22:57:00.000+09:00

とうとう「主筆」の第19版を公開した。

第18版との最大の違いは印刷機能が実装されたことだけなのだが、それでも公開するまでに半年以上の時間を要してしまった。

意外と地道に書き続けているblogを読み返してみれば、実は相当以前から印刷機能の実装に取り組んできていたらしい。一番古い記述は2007年1月22日にまで遡る。この当時はまだ第18版を公開していなかったことを考えれば、印刷機能の実装には随分時間がかかったものだと、言わざるを得ない。

だが、時間がかかったのは手を抜いていたばかりではない。純粋に開発工数が嵩んだためでもある。俺にとっては未知の言語であるPostScriptを勉強しつつ、それを出力するために必要となる多数のパラメタを入力させるインタフェースを作り込み、最終的にプリンタまで送り出すための出力処理など、思えば長い道程だった。

中でも特に苦しんだのが、エンコードの違いによる差異だ。印刷するとき、PostScriptの中でフォントを指定する必要がある。だが、そのフォントはエンコードによってそれぞれ別のフォント名を指定する必要がある。つまり、フォントはエンコードを意識するのだ。その為、そのPostScriptを生成する主筆側でも、ロケールに合わせてフォントを替えてやるようにしてやる必要がある。

だが、ここに一つ大きな罠がある。PostScript チュートリアル&クックブックを見ると、日本語環境において利用可能なフォントは、JIS・SJIS・EUCのそれぞれの環境におけるゴシック体と明朝体であると記載されている。だが、Solarisでは使用されるエンコードがUnicodeになる可能性がある。

もし単純に、PostScript内でのエンコードをカレントのロケールに合わせて、同時にフォント名もロケールに合わせて入力させるようにした場合、Unicodeでは印刷できないということになってしまう。

俺個人としてはUnicodeのロケールで使うつもりは更々無いのだが、とは言ってもロケールへの非依存は主筆の特徴として高らかに謳っていることでもあり、無視するわけにはいかない。

ということで、こういう事にした。まず、少なくとも日本語環境ではフォント名はEUCのものに固定する。当然、PostScript内に出力される文字列もEUCにする。それでもって、日本語以外の環境に対応するために、"PostScript内で使用するエンコード"をリソースで設定できるようにする。

こうすれば、例えロケールがUnicodeのものであったとしても印刷することが可能になる。

だがその為には、印刷前にテキストをEUCに変換してやる処理を入れなければならない。しかも都合の悪いことに、エンコード変換処理は別プロセスに切り出してしまってある。その都合上、エンコード変換はそう容易には行かない。

だが、容易には行かないとは言っても、やるしかないのだから実装した。パイプやテンポラリのファイルを駆使し、入力されたヘッダやフッタの文字列も含め、然るべくエンコードを変換するよう作り込んだ。

お陰で、印刷処理を行っているモジュールが随分肥大してしまった。単純に行数で行けば、このファイルが一番長い。仕方がないとはいえ、見苦しいことこの上ない。

だがまぁいいだろう。いろいろあったが、これで、テキストエディタとして最低限必要な印刷機能が実装されたのだから。

第19版のコンパイル

2007-11-18T16:54:00.000+09:00

「主筆」第19版の配布用バイナリを作成するために、Solaris8でコンパイルしようとしているのだが、これがどうにもうまくいかない。時刻を取得するために使用しているlocaltime_rという関数が見つからないとか抜かし、コンパイルを完遂しないでいやがる。

原因はなんだか知らんが、どうやらSolarisとPOSIXの微妙な違いにあるらしい。とりあえず、ヘッダファイルとかマニュアルとかをみると、コンパイル時に「-D_REENTRANT」という指定を入れて、「_REENTRANT」というマクロがdefineされるようにしてやればいいらしい。

だが、この指定を入れるとスレッドやプロセスの扱いが微妙に変わるというようなことがマニュアルに書かれている。この微妙な変化が動作に悪い影響を与えなければいいのだが。

それにしても、今現在Solaris8はBlade 100のマシンにインストールしてあるのだが、これでコンパイルすると時間がかかってたまらない。64ビットで最適化を入れてコンパイルすると、すべての処理が終わるまでに25分掛かる。でもって、コンパイルの最後の方でリンクのエラーとかが出て、またやり直しになったりして、本当に疲れる。

しかも、そうこうしているうちにマシンの環境を破壊してしまい、起動しなくなってしまった。原因は分かっているので、うまくすれば復旧する事もできたのかもしれないが、面倒だから再インストールする事にした。

このところ立て続けに再インストールの作業を行っているから、さすがにそろそろ慣れてきた。Solaris8を入れた後に行う設定作業や、入れたり削除したりするパッケージ、あるいはその順番など、いくら物覚えの悪い俺でも体で覚えてきた。だから、インストールを始めてから1日ほどで元通りの環境を再現することができた。

今現在は、足止めを食らった分を取り戻すべく、Solaris8上でコンパイルを行っている。差具我にそろそろうまくいってくれても良さそうなものなのだが。

Sun Studio 12

2007-11-13T23:14:00.000+09:00

気がつくとSun Studio 12の日本語版が公開されていた。早速落としてみたが、まだ入れてはいない。

しかし、ダウンロードするファイルの容量がSun Studio 11の頃と比較して、大幅に増えている。1138.93MBもありやがる。しかも、bzip2で圧縮されている。

その上、Sun Studio 12はよく見るとSolaris 8には対応していない。ちょっとばかり、嫌なことになってきた。

古いバグ

2007-11-04T14:51:00.000+09:00

第19版を公開するために必要な作業はおよそ終了した。後はホームページの紹介の文章を多少いじくるだけでいい。だがその前に、二三気になる点を修正することにした。

そのうちの一つに、長い間原因不明のまま放置してきた、時々「主筆」が二つ起動することがあるという問題がある。これは、ファイルをダブルクリックしたり、あるいはコマンドで主筆を起動した際に、主筆が同時に二つ起動し、なおかつその双方ともが同じファイルを開いてしまうという現象である。

主筆では、同じファイルが同時に複数回開かれることの無いように制御を行っている。だがそれが時々うまくいかなくなるのだ。うまくいかなくなるだけならまだいいのだが（よくないが）、しかし、主筆サーバ内の制御ロジックは、同じファイルを開いた奴が複数個存在しないことを前提としている都合上、この問題が発生すると内部の状態が不正になる可能性がある。

しかも、このバグは滅多に発生しないという最悪な性質を持っている。そのため、いつかなる時にいかなる原因で発生するのか、追求に手間取った。というか、ほとんど対処できなかった。

当初は、この問題では起動する主筆は必ず二つであり、三つ以上になることが無いと言う事から、主筆サーバ内のロジックを疑っていた。主筆サーバでは、クライアントや主筆から受け付けた要求の処理に失敗したら、もう一度だけリトライするよう実装してある。つまり、俺はこのリトライ処理の周辺で何かおかしなことになっているのではないか、と考えたのだ。この周辺の処理、すなわち、主筆サーバが主筆を起動し、主筆サーバ内の管理リストを更新するまでの処理は、意外と複雑なことになっている。だから、この複雑なところが一番臭いと、そう踏んだのだ。

だが、事実はそうではなかった。よくよく調べてみると、結局原因はプロセスの起動処理にあることが判明した。

プロセスを起動する処理は、その処理結果として起動したプロセスのプロセスIDを返すようにしている。また、処理に失敗した場合には-1を返す。ここの処理に下らないバグがあり、生成したプロセスのpidによっては、起動に成功したにも関わらず-1が返されてしまうことがあったのだ。そのため、主筆サーバ内のリトライ制御によりもう一度起動処理が行われれ、結果として主筆が二つ起動してしまっていたのだ。

下らないバグというのの概要はこうだ。

プロセス起動では、親プロセスでforkして子プロセスを生成し、その子プロセスからさらにもう一度forkを行い孫プロセスを生成して、その孫プロセスがexecする。そして中間の子プロセスはそのまま_exitする。こうすることによって、起動された孫プロセスをinitの子として、ゾンビプロセスなどの諸々の問題を回避するようにしている。これは、ゾンビプロセスの発生を防ぐ古典的なんだそうだ。

主筆では、この処理の中で子プロセスはforkする以外にもう一つだけ仕事を行っている。それは、親プロセスに孫プロセスのpidを通知する処理である。すなわち、親プロセスは孫プロセスのpidを知り得ないから、子か孫に教えてもらわねばならないのである。

そして本問題の原因は、このpidの通知方法にあった。なんと恐ろしいことに、子プロセスはその終了ステータスとして孫プロセスのpidを通知しようとしていたのだ。でもって、親プロセスのその終了ステータスをもって、起動した孫プロセスのpidとして関数の戻り値としていた。

もうね、ほんとに俺はアホかバカかと。プロセスの終了ステータスは1バイトしか返せないのだから、pidを終了ステータスにして_exitしたら、その下位1バイトしか親プロセスに返されないに決まっているではないか。下位1バイトしか返されないのであれば、たまたまそのバイトが0xFFになることだってあるではないか。0xFFであれば、データの扱いによっては-1になることも十分にあり得るではないか。

結局、このバグがたまにしか発動しない理由もこれでわかった。下位1バイトがたまたま0xFFになるのが、たまにしか起こらないからなのだ。

原因がわかれば対処法も自ずと明らかになる。用はpidの伝達に終了ステータスは使えないのだから、おとなしくパイプで通知してあげるようにすればいいだけだ。ちょっと面倒だとはいえ、ほかに方法はない。

この対応を入れることにより、問題は解消されたはずだ。生成された孫プロセスのpidが確実に親プロセスに通知されることも確認できたし、孫プロセスの下位1バイトが0xFFになる場合においても、主筆が二つ起動されることがない事は確認した。

バグというのは、たとえどんなに不可解な現象で、原因が全く推定できないようなものであっても、わかってみればこんな下らない事だったのかと、思わずにはいられないものだ。こんな些末な、あるいはこんな明白なものであればもっと早くに気がついて然るべきだと、いつもそう思うのではあるが、それがなかなかそうもいかない。人間というのは不思議なものだ。

CD-R

2007-11-03T10:13:00.000+09:00

Solarisにパッチを当てる度、いつも二・三個失敗して余ってしまう物がある。どうやら8/07以降のSolarisに含まれているとか言うパッケージを入れねばならないらしい。ならば、それを落としてきてCD-Rに焼かねばならないのだが、しかし、俺の手元にあるCD-Rの残弾は心許ない。

普段CD-Rはバックアップ取得用に少しずつ消費しているのではあるが、LinuxやSolaris等、特にOSのディスクイメージを落としてきてインストールする場合などには、まとまって消費される事がある。

腐るものでも無し、まとめて買って備蓄しておけば、それでいいのかも知れんが、しかし普段の消費量が少ないことを考えると、つい買わずにいてしまう。そしていざという時に不足に泣く事となる。

最近では店に行ってもCD-Rがあまり売っていなかったりもする。ほとんどがDVD-Rであり、昔ながらのCD-Rは棚の片隅で埃を被っていたりする。ちょっと買うのが恥ずかしい。このままでは直に手に入らなくなるのではないだろうか。もはや100円ショップではCD-Rやフロッピーディスクが姿を消しつつあるように。

それを考えればそろそろDVDかあるいはBlu-rayディスクか何かにしたほうがいいのかも知れないが、しかしいかんせん、3年掛かりの超大作といえ圧縮すれば数MBにも満たないものをバックアップするのだけであり、640MBでも多すぎるのに、なぜにわざわざ金を出してまでまでして、いらんものを買わねばならないのか。

技術革新にはおおむね肯定的な俺とはいえ、やはり規格の乱立と製品寿命の短縮には賛成できない。「あなたの損は私の利益」という言葉は経済の本質を表したものではあるのだが、しかし、消費者の利益を害する企業に将来は無いというのもまた一面の真実である。

DVD-RがCD-Rの代用品として使えるのであれば、それでもいいと思うのだが、どうもそんなことができるようになっているとは思えないし、新しいドライブを買う気はさらさら無いし。かといって磁気テープもまた規格乱立と非互換の泥沼だし、何か良い方法はないのだろうか。

まぁ、新しいドライブが只で手に入れば全ては丸く収まるんだがな。

ドキュメント

2007-10-28T19:02:00.000+09:00

この土日は特にすることもなかったから、「主筆」のマニュアルの作成に費やした。おかげで日本語版マニュアルとプラグイン開発ガイドの第19版をあらかた準備し終えた。

内容の最新化は当然だが、それ以外にも一部デザインの変更や日本語の見直しを行った。また、今までは目次は手作業で作成していたのだが、ちゃんと書式を設定して自動で振られるようにした。今後の作業の軽減を考えてのことだ。

表紙のデザインは相変わらず右上に主筆のネェちゃんを配置したもののままだが、表題のフォントだけ変えておいた。何となく、プロポーショナルフォントの方がしまりがあって良さそうだったからだ。

残るは英語版のマニュアルだけである。書くべきことは日本語版のものにすべて記載されているのだから、それを英語に訳していけばいいだけなのだが、この作業が非常につらい。おまけに時間がかかる。

自由に英文の読み書きができればいいのだが、なかなかそうもいかず、毎回苦労している。それなのに、日本語版マニュアルの作成以上に全く持って報いられることはない。この正真正銘の無駄な作業は、やめるべきか続けるべきか。難しいところだ。

それと、全然関係ないことだが、さっきから文字を入力していると画面下部にある「今すぐ保存」がどんどん右に伸びていく。いったい何が起きているのだろうか。