--- 大雨 ---
う?む、今日は朝から雨だ。
帰りには止んでくれることを祈るぜ。

--- 調査開始 ---
昨日の出張で発覚したプログラムの遅さ。
昨日リーダーに出したメールから返信が来ている。
「どこかロジック的に問題となりそうな箇所はありますか？」

はい、全部です。
…というわけで調査開始。
一番の問題点は発行してるSQL文の多さだね。
これを減らせば相当の時間削減は出来るはず。

--- 土日返上 ---
ちくしょ?、今週末はのんびり過ごすはずだったのに
このプログラム修正のせいで全てが台無しだぁ。
別に土日にやる必要は無いんだけどね。
やれることは今すぐにやらなきゃ気が済まない僕なのだ。

とはいっても、家のマシンで開発環境を構築できるかどうかが不安。
DBにOracle使うわけにはいかないからMySQLでやろうと思ってるんだけど
果たしてうまくいくのだろうか・・・
まっ、こんなものさっさと終わらせてのんびりするぜいっ！

--- 松井の決意 ---
メジャー行きを宣言した松井。
各局で取り上げてるから今更知らない人も少ないとは思うけど。
僕が一番心配してるのが、ヤンキースという球団だ。

いくら今まで彼が日本の中心的な存在である巨人で4番を務めていたとはいえ、
王者ヤンキースに集まる世界的な注目度はそれの比では無い。
スーパースター達に囲まれる状況の中で
活躍をするのは皆が思ってる以上に大変なことだと思う。

だけどやっぱり期待しちゃうよね。
松井にニューヨークという都市は似合わないけど（笑）

--- ひとまず終了 ---
金曜の夜から少しずつ進めていた田町用プログラムの修正が
とりあえず完了する。
あとはこれが向こうの環境で動かしてどの位の時間掛かるかだ。
あんまり根詰めてやると疲れるので
明日はゆっくりと羽を伸ばそう・・・

--- 速度への挑戦 ---
昨日の段階で一先ず完成したプログラムだが、
それでも相当に遅いことが判明したのでまたも改良することに。
今までは2つあるモジュールのうち1つだけを修正してたんだけど
どうもそれだけじゃ改善されないみたいで
もう1つの方にも手を加えることにした。

とはいっても修正なんて生易しい事してたら埒あかないので
1から作り直す羽目になったんだけどね。
色々な試行錯誤の結果、何とか納得できるスピードまで到達する。

初めは6時間以上掛かっていた処理が、昨日の修正で2時間弱に。
今日の修正1回目で30分程に。そして最後の修正をした結果
2分ほどで終わらせることに成功した。

--- 単純な発想 ---
今回施した修正方法は別に特別なものじゃない。
要するに、今までDBから毎回取っていた値を
処理の初めに全てメモリ（Javaオブジェクト）に格納しただけ。

今までは、実際にどれくらいの量のデータが来るか判らなかったから
この方法は避けてきた。
が、とりあえずこの前の出張でもらったデータが
かなり実践に近いものだということで、大体の目安はわかった。
そこで今回の修正に踏み切ったって訳。

--- 最適化 ---
今回、最終的なスピードが格段に速くなった理由は
TreeMapを有効に使ったことにある。
このクラスはHashMapとは違いキーに順序付けがされていて
使い方によっては相当のスピードアップが可能だということが
今回の修正でわかったことは収穫だったと思う。
そのせいで連休は見事につぶれたけどね・・・

--- 横道 ---
これを「おうどう」と読んだ人、かなりの横道坊主ファンと見受けるが
・・・実際、いないだろうな（笑）

家のマシンでメールサーバでも立ち上げようと思って
色々調べていると、なぜかWebDavの記事を発見してしまい
「まずはWebDavでも入れてみるかぁ」などと軽い気持ちで始める事に。

実は以前にもWebDavは導入しようとしたんだけど
どうもうまくいかないので諦めていたのだ。
Windows2000は標準でWebDavに対応しているはずなのに
何度試しても失敗してしまう。他のWebDavクライアントなら上手くいくのに。

--- 横道の横道 ---
Apacheのログを調べてみると、その原因が判明する。
詳しい説明は省くが、とりあえずmod_rewriteというモジュールを
入れないと問題は解決しないようだ。
そこで今度はmod_rewriteについて調べ始める。

・・・難しい。色々試してみるが、一向にうまく行かない。
散々粘った結果、1時間くらい経ってようやく成功。

ここから先はすんなりと進む。
日本語化に対応させたいのでmod_encodingモジュールも入れてほぼ完璧に。
ふぅ、疲れた。メールサーバはまた今度にするか（笑）

--- 週3日 ---
昨日の日記を読んで鋭い人は気づいたであろう。
なぜ僕がメールサーバなんかを導入しようと思ったか。
会社休んで暇だったから
ということは皆の心の中にしまっておいて下さい(笑)

というわけで、今日はもう水曜日。週3日出勤だ。
結局こうなるなぁ。仕事がある内はいいんだけどね。
無くなると途端に行かなくなるから、僕の場合。
たっぷり仕事用意してくれればいくらでもやりますよぉ(誰に言ってる)

--- ア然 ---
久しぶりに会社に来たので
らいおん君の進捗状況をチェックする。
僕は一応(前プロジェクトの)修正があるから
新プロジェクトの作業はしなくていいことになってるんだけど。
ちょっと心配なので見てみることにする。

まだ1つ目の画面作ってる・・・素晴らしいな、おい。
いったい何日後倒しすれば気が済むのかなぁ。
遅れてるの判ってたら休日中にやるとか方法はいくらでもあると思うんだけど
そんな形跡も全く無し。
まぁいい、しばらく放っておくか・・・

--- 環境の違い ---
現在、田町にきてテストデータを流している。
週末に作り上げたプログラムは午前中に茗荷谷で調整。
ここではすんなり行くはずだったのに・・・一向に処理が終わらない。

おかしいと思い調べてみると、JDBCにアクセスする所で止まっている。
いつまで経ってもメソッド呼び出しから帰って来ないのだ。
どうも35000件程度抽出した段階で止まってるらしい。

これが果たしてOracleの設定が問題なのかは解らんが
とりあえずこのままじゃ先に進めない。
それにしても、こんな所で止まるなよなぁ。せめて例外返すとかにしてくれ。
これじゃ対処のしようが無い。

--- 使えないもの ---
ホント、Oracleっていうのは大した製品じゃない。
高度なSQL文が使えるのは認めるよ。
でもそれ以上にプログラマにとって重要な「安定性」がまるで無い。
バージョン変えたら動かなくなるなんて話もよく聞く。
そしてOracleMasterなんていう称号を自ら作り、信者を増やそうとしている。

--- 性能差 ---
今回、自宅でテストした際に使ったのはフリーのMySQLだ。
そのときにこんな不具合は起きなかったし、
別にこのDBを使って処理をしても何の問題も無かった。
今回のプログラムは月次処理なので、トランザクションについて
神経質になる必要も無い。
このプログラムを実行するのは1ユーザーのみだからね。

それなのに、こいつらは訳も判らずOracleを使おうとする。
それで自分の首を絞めることも知らずに。
いや、正確に言えば一番被害を受けてるのは僕らプログラマなんだけど。

--- 寒 ---
おいおい、なんだよこの寒さは…
まだ11月も始まったばかりだっていうのに。

--- 硬直 ---
らいおん君がさっきから画面を見つめたまま硬直している。
ヘビにでも睨まれたか(笑)？

--- 久々に… ---
朝からプログラミングをしている。
この前修正した部分とは別の箇所の処理がどうにも遅いので
チューニングをしてもいいかとリーダーに聞いたところ
OKが出たので、ひたすら最適化に励む。

どんどん速くなっていく実感。
やっぱりこれがプログラマが幸せを覚える瞬間だよね。
唯一上の奴らを納得させられる手段でもある。
いくらプログラムを綺麗に書こうと誰も褒めちゃくれないもんなぁ。

今回の箇所はほとんど自分で作った部分なので
最適化はスイスイ進む。
今回もTreeMapを使うことでかなりのスピードアップに成功。
うむ、これは初めから使うべきだったな。

--- 自分は？ ---
らいおん君が後輩に偉そうにしてるぞ。
自分のことは棚に挙げて
「それはやっといた方が今後の為になるよ」だって…
自分で出来ないことを人に押しつけようとするのは
こういう人種の特色か。

--- そして今度は ---
そのらいおん君の上司であるダメゴンが登場だ。
余りにもらいおん君の進みが遅いので
見かねて処理のフロー図なんかを作ってあげたらしい。

それだけ聞くと聞こえはいいが、
おそらくそのフロー図もロクでも無い代物なんだろうね。
プログラマにとって一番厄介なのは、上が作った使えない設計書なのだ。

--- 続・メールサーバ ---
ただいまメールサーバの勉強中です。
現在の主流であり各Linuxディストリビューションにも
デフォルトで採用されているsendmailと、
それに真っ向から対抗するqmail。
両者の違いは何か。qmail.jpを読めばその概要が見えてくる。

ご存じの通り、sendmailには今まで数々のセキュリティホールが
発見されてきた。
一方、qmailは「セキュリティホールを発見した人に賞金を出す」
という姿勢を取っている。
自分達が作ったソフトウェアに絶対の自信を持っているからだ。

--- セキュリティホール ---
qmailの設計方針には7つの基本原則があるらしい。
その一つが「単純にしろ」だ。

セキュリティホールというのはつまりバグである。
僕は、バグを失くす最大の近道はプログラムをシンプルにする
ことだと思っていた。そしてそれは正しかった。
メールサーバという最もバグの混入しやすいソフトにおいて
この理念の正当性は見事に証明された。

「存在しない機能にはセキュリティホールはありえない」
これが彼らの主張だ。
sendmailはたくさんの機能を追加した結果
プログラムが複雑化し、ホールを作る危険性を生んだのだ。

--- qmailから学ぶこと ---
qmailの作者は言う。
「sendmailの作り方では今後もホールが発見されると確信している」
そう、sendmailのソースを見て
バグが混入することは目に見えていたというのだ。

これは、僕らが作っている小規模なプログラムでも成り立つ。
ソースを読めば、そのプログラムの信頼性が大体は見えてくる。

qmailの設計には哲学がある。作者は言う。
「安全確実を絶対的要求事項にするために私はqmailを作り始めた」
いかに便利か、では無い。
それ(便利さ)を満たしつつ安全確実なソフトを作ることは
もはや不可能に近いことを皆知っている。

それでいて、qmailの設定ファイルはsendmailのそれより
ずっと簡単だと言う。それを理由にqmailを使い始める初心者も多いらしい。
しかし当然のように、そんな安易な考えで使いこなせるほど
qmailは初心者寄りなソフトウェアでは無い。

僕はもうしばらくメールサーバの導入は控えるつもりだ。

--- 暑 ---
なんだか部屋が急に暑くなってきたぞ。
いかん、このままじゃ寝てしまう…
でもこの室温じゃ寝てくれって言ってるようなもんだ。
俺を落としめる為の罠か？(違う)

--- ようやく ---
メールサーバを動かすことに成功する。
散々悩んだあげく、結論はルータのバーチャルホスト設定が
されてなかったというもの・・・あ?あ、こんなんじゃ先が思いやられるぜ。

--- 毎週恒例？ ---
また今日もお休みだ。
どうやら僕の身体は数ヶ月前に戻ってしまったらしい。
つまり、日曜の夜に寝れない。今日も寝たのは朝8時過ぎ。
さ?て、何しようかなぁ・・・

--- 挫折 ---
メールサーバの導入には成功した。
ちなみにメールアドレスはnaoki@limy.minidns.netです。
今ならご希望のメールアドレスを差し上げます（笑）

で、今日はメーリングリストを導入しようと思ったのだが
これがうまくいかない。qmailと共に使うezelmというのを入れたんだけど。
とりあえずまた今度かな。

--- 置き忘れ ---
しまった。田町に日記置き忘れてきた・・・
というわけで二度書く気力も起きないので今日はこの辺で（笑）
久々に残業して疲れたのだぁ。

--- あやうく… ---
今日も田町に行かされそうになった。
あいにくバグが発覚したのでその調査。
この前作り直した配賦部分のデグレだ。
0から作り直してるからこう呼んでいいのかどうかは知らんが。
他には無いことを祈ろう。

--- 更新バッチ ---
JDBC2.0には、更新処理を繰り返し行うときに使える
バッチ処理というものがある。
要はまとめて更新処理をしようという実に単純なものなんだが
これが結構速くなる。

今回もまた遅さが気になったのでこれを導入してみたところ
かなり速度は改善された。
出来ればこれをインポート処理のところにも入れたいが
あの部分は手の施し様が無いほど「荒れ」ている。
よほどのデータ量が来ない限り放っておくのが妥当だろう。

…と褒めていたところでまたもOracle JDBCでバグらしき動作。
ホントにこんなの信用して使ってていいのかね？

--- サンプル無 ---
うむむ…バッチ更新でハマる。なぜうまくいかないのだぁ。
それにしても、どうしてOracleはロクなサンプルすら用意してないのかね。
Webを見ても、これに関連するサンプルはわずか一つ。
しかも超初歩的なメソッドの使用例しか載せちゃいないので全く使えん。

またバグ発見だ。更新処理で一意制約エラーが出る。
なんで俺がOracle JDBCのデバッグなんかせにゃあかんのだ。
とりあえず対処法を見つけさっさと片付ける。
もしかして、こういうバグに対処するのが嫌だから
わざとサンプル付けてないのか？そうすれば皆使わないと思って。

--- 抜け出せず ---
なんかいつまで経っても前プロジェクトから抜け出せない。
今週こそはそろそろ新プロジェクトに手を付けようと思ってたのに
色々と問題が発生して未だ未着手。
もちろん、らいおん君の進行状況も
1画面目から全く進んでいないのであるが。

どうやらダメゴンに言われて設計書を書くことに
専念しているらしい。確かにあんな設計書じゃ
これから増えるであろう人員も困るだろうからね。

--- また ---
田町にて問題発生だ。
今度はDBのインデックス表領域が足りないとかエラーが出やがった。
調べてみると、50MBしか割り当てていない。
こんなんじゃ足りないでしょ。

勝手にDBの設定いじるわけにはいかないので
本部（？）に確認を取る。
電話に出たのはご存知、自称DBマスターの彼。
さっそく、意味不明な専門用語を連発して
相手を戸惑わせる作戦を取ってきた（笑）

彼が言うには、表領域の容量を増やす前に
DBのバックアップを取る必要があるという。
確かにそれも一理あるが、そのためにDB落とさなきゃいけないとは
Oracleの開発者は一体何を考えているんだ？
それとも彼が勘違いしているだけか？真実は不明だが。

当然、よそのDBを落とす権限が僕らに与えられてる訳はなく
バックアップは取らないまま処理を続行することにした。
大体、容量増やすだけでDB壊れる可能性があるってどういうこと？
彼は以前に一度そういう経験があるらしい。
ホントに使えんDBだぜ。

--- 久々に ---
前述した問題は起きたものの、今日は比較的順調に作業が進む。
てなわけで、のんびり会議室で日記を書いている次第である。
では、そろそろ帰りま?す。

--- 休憩 ---
ふぅ、一段落ついたのでちょっと休憩。
今日は珍しく一日中作業に追われてたのだ。

旧プロジェクトはいよいよ向こうが本格的に動きだすらしく、
来月からはこの会社からも新メンバーが加わり
ちょっとは活発になってきそうだ。
開発グループにも一人入ることに。
その名も「アウチの人」…以前この日記に登場したこともある彼である。

とりあえずプログラムは僕が担当することになっているので
彼の仕事は向こう(田町)へ行ってデータを流すという
オペレータ的役割になっているようだ。
FTPとエディタとTeraTermが使えればOKなので
それくらいは出来るだろう。

--- 全改造 ---
今まで色々と高速化を施してきたが
いよいよ放っておいたインポートモジュールにも手を回すことになった。
他の部分が速くなったので、ここだけ遅いのは
どうにも気に食わなくなってきたのだ。

結果、250ステップ程で完成。
こんな簡単な処理を4?5個のクラスに分け
とてつもなく面倒な手順を踏んでいたのには今さらながら呆れる。

これで、このプロジェクトで使用する全モジュールは
僕が作成したものに置き変わった。
やっぱりこの方が落ちつくね(笑)
ただ、こうしちゃうと今後のバグは全て僕に振られることになる。
…今までもそうだから別に変化は無いか。

--- 静音化計画 ---
朝、会社でqmailとvpopmailの情報を調べ始めた。
はずなのに何故か、キーボードの記事に目が止まる。
「Happy Hacking Keybord」
かなり使いやすいらしいので欲しくなる。
この前買ったキーボードがキーが小さすぎて使いにくいのだ。

で、そのページにあった「自宅サーバ静音化」の方に興味は移る。
今までノートPCを自宅サーバとして使ってきたが、
デスクトップマシンでも改良すればかなりの静音化が可能だと知り
徹底的に情報を集め始めた…

--- ベアボーン復活？ ---
我が家には、買ったはいいものの
余りのうるささに参り、放置してあるベアボーンPCがある。
どうにかしてこれを復活させられないか。

色々調べたところ、やはりベアボーンの騒音には
かなりの人が参っているらしく、様々な静音化が試まれている。
具体的にはファンの交換が主な手段。
電源ファン、ケースファン、CPUファンを何とかする必要があるらしい。

僕が持っているベアボーンは「CF-7589」という型で
マザーボードはFV25が搭載されている。
これ自体の性能は中々いいらしいので
押し入れの中に放置しておくのも可愛そうだということに今更気付く。

--- FreeBSD ---
今まではRedHat Linuxを使ってきたが、
そろそろFreeBSDに乗り替えようかと思う。
RedHatは、Windowsから移行する際には楽かも知れないが
色々と付加機能が多いので純正のUnixとはかなり違うと考えたからだ。

開発者の方々のページを見ると、そのほとんどが
FreeBSDを使用しているという実績もある。
今後、業務でUnixを使う可能性があることも考慮に入れ
早めにRedHatからは手を切ろうという結論に達した。

というわけで、近々(いつになるか解らんが)自宅サーバを
「ノートPC + RedHat」から「デスクトップ + FreeBSD」に切り替えます。

--- もう一つの理由 ---
自宅サーバをデスクトップに移行する理由の一つに、
Tomcatを稼働させたいという欲求がある。
ノートPCは128MBなので、Tomcatを使うのは少々厳しい。

趣味でWebサーバやるにはeRubyで充分なんだけど、
eRubyを使う案件なんてどこにもありゃしないので(笑)
実益を兼ねたJSPにも手を出しておこうかな、と。

さらにはdjbdns稼働も復活させるつもり。
これ立ち上げとくと(正式にはdaemontoolsだが)
HDへのアクセスが頻繁に起きるので
ノートPCのカリカリしたHDアクセス音が我慢できずに
稼働を諦めてたのだ。

--- いつの間にか ---
今日はひたすらWebで情報を探し回っていただけなのに、
気がついたらもう定時だぞ(笑)
おかげで色々と勉強になったなぁ。

--- ハード関係 ---
昨日は家でマシンと格闘。
どうもハード関係には弱いので毎度のことながら苦戦する。
ベアボーンはやはり電源ファンが一番うるさいことが
判ったのだが、これが半田で固定されてて外れやしない。

気がつけば、そういった道具何一つ持ってない。
実家にいるときは家にあったから気にしなかったけど。
さすがにドライバーだけじゃ静音化に挑むのは無理っぽいので
今度買いにいく必要があるな。

--- ほんの10年前 ---
以前僕はこんな事を思ったときがあった。

「このままCPUのスピードが上がっていったら
アセンブラの必要無い時代が来るんじゃないか？」

当時(10年くらい前)、プログラムの主流はC言語だった。
が、スピードを要求する場面ではどうしても
アセンブラを使わざるを得ないという事態が多々存在した。
特にグラフィック関係は、まだVRAMに直接書くという手法が
一般的に行なわれていた為にアセンブラによる独自ロジックは必須だった。

--- アセンブラ ---
そして今、おそらくアセンブラでコードを書いている人は
ほとんどいないだろう。
理由は簡単。その必要性が無くなったからだ。
C言語でも充分な速さが得られるようになり、多種のCPUが氾濫する
この時代にもはやアセンブラは時代遅れなのだ。

では、あと10年経ったらC言語はJavaによって
その存在意義を無くしてしまうのだろうか？
僕の予想はNoだ。

--- 全ての原点 ---
アセンブラを知っている人なら判ると思うが、
C言語は限り無くアセンブラに近い言語である。

全ての原点は「機械語」にある。
これはCPUが唯一理解できるコード体系で、その実態はバイト列の羅列だ。
これを人間が書くことはほぼ不可能に近い。

そのために登場したのが、アセンブラ言語である。
人間が理解できるような文字を連ねることで機械語のコードを作り出す。
そう、実はアセンブラも立派な「コンパイラ」だったのだ。

C言語は、そのアセンブラをより判りやすく、使いやすく
したものだと僕は思っている。
精通したプログラマならば、C言語のソースを読めば
それが作り出した機械語をほぼ予測できるのだ。
ただし、C++ではその限りでは無い。
そういう意味では、C++はJavaの発展により消えて無くなるはずだ。

--- Javaの利点 ---
ではなぜ、JavaはC言語の後継者になれないのか？
それは、両者が全く異なる内部設計を持っているからだ。
前述したように、C言語はアセンブラに極めて似ている。
つまり、C言語→機械語という矢印がある程度成り立つ。

しかし、Java→機械語は成り立たない。
Javaはインタープリタだからだ。
その動きは、実行させるマシンのJava VMによって決定される。
速度は犠牲になるが、一つのClassファイルがあれば
それが全てのCPU上で動かせる。これがJavaの最大の利点だ。

--- 「速さ」の重要性 ---
僕はそのとき、こうも思った。
「速さを追求するプログラミングなんて必要無くなるのではないか？」
CPUの速度が飛躍的に伸びていく世の中で、最適化によるスピードアップは
必要なくなるものだと思っていた。
でもそれは間違っていた。

現在、プログラムは素晴らしく速くなった。
しかし、もしそのプログラムを100回連続で動かしたら
一体どれくらいの時間が掛かるのだろうか？
あるいは、それを100人が同時に動かしたら？

--- 「速さ」の重要性 ---
単純に言って、それらの実行には100倍の時間が掛かる。
そして巷ではWebの需要が確実に高まっている。
大勢の人が同時に利用するWebシステムにおいては、
「速さ」というのはもはや絶対条件として挙げられるくらい
重要な項目になっているのだ。

そして、扱うデータも過去とは比べものにならないくらい肥大化している。
100万人の顧客データがそれぞれ10KB程度の情報を持つだけで
その合計は実に10GBもの巨大なものになってしまうのだ。
そんな中、効率を考えずに作ったプログラムでは
もはや使いものにならないくらい遅くなってしまう。

--- 現実 ---
こうは言ってみたものの、現実はそう甘くはない。
速度なんか二の次で、正確性を求める声が現場では多いだろう。
そしてある時、速度の遅さに気になり出した上司が言う。
「もうちょっと速くならないかな?」
…そう、僕の体験談です(笑)

なんでこんな状況が頻発するかというと、
皆正確に動くプログラムさえも満足に作れないからだ。
当然、スピードと正確性どっちが重要かって言ったら後者に決まってる。
正確性は確保した上でスピードを追求するのが
開発者としての常識だと思うが、それも彼らには通用しない。

--- 静止 ---
またらいおん君が静止したまま動かない。
さっきのダメゴンとのやりとりを聞いてる限り
手詰まりといったところか。
新しいスケジュール決まったら僕も参加する予定なんだけど
この調子じゃまだまだ掛かりそうだなぁ。

--- トラブル ---
何やら隣(らいおん君ではない)ではまた
ゴタゴタがあったようだ。
「法律に関わるかもしれない問題なんだから！」
電話で怒鳴ってるのがいる。
おいおい、この会社は大丈夫か？

--- WebSphere ---
メールが来ている。
何でも、僕が属してる部署でWebSphere Studioを開発環境として
導入するらしい。
今までも一部のプロジェクトでは使用していたらしいが、
今回はそれを全チームに適用するとのこと。

「理由は、生産性向上と品質向上の為です。」
とある。考えが甘いね。
こういうツールを採用したところで、根本となる
コードスキルの上昇には全くつながらない。

逆に初心者がいきなり総合環境から始めてしまうと
それ無しではプログラムを作れなくなるという危険性もある。
確かに、ほんの少しの生産性向上は得られるとは思うが。
ツール使いを育てたがるのはどこの会社でも一緒だね。

--- とりあえず… ---
何はともあれ、タダでWebSphere Studioを入れていいって
いうんだからそれに乗らない手は無い。
使ってみて駄目だったら使わなけりゃ済む話だし。
前にも話したように、このソフトはEclipseをベースにして
作られてる訳だからそれなりの期待は持てる。

ただ、画面見たらVBみたいでちょっと不安になったけど。
初心者向けツールだったら必要ないもん。
あとは動作スピードが問題だな。

--- 感想 ---
さっき会議があった。WebSphere Studioの実演会(笑)
思った通りEclipseとほとんど同じだった。
ただ、やはり1ライセンス7万近くする製品だけあって
様々な付加機能が付いてるみたい。

特に高性能のプロファイル機能が備わってるのは素晴らしい。
メソッド単位だけでなくインスタンス単位での
呼び出し回数や消費時間が検出できるので
ボロなプログラム作ってるとすぐにバレちゃうって訳だ(笑)
そうなる前にソースレベルで検証しとけば済む話なんだけどね。

--- Tomcat再び ---
しばらくやっていなかったTomcatプログラムにまた手を出す。
そのうち自宅サーバにも導入する予定なのでその練習にもなるし
今後の仕事にも役立つしね。

Webプロジェクトは仕事始めてから手を付け始めた分野なので
まだまだスキルが足りないのだ。
通常のプログラムよりデバッグが大変、とか思っていたけど
Eclipseを導入したことでそれ程でも無くなった。
これだとJSPを変換したサーブレット(通常のJavaファイル)を使って
デバッグできるからね。変数参照やステップ実行なんかも簡単だ。

でも、個人用ホームページでJSP使うような暇人は少ないだろうなぁ。
セッション管理の必要とか無いもんね。

--- djbdns再び ---
djbdnsとはD. J. Bernsteinが作成したDNSサーバの名称だ。
インターネットを使って全世界とアクセスするには、
このDNSサーバの存在が不可欠となる。
これにより、クライアントはどこにいても
求めるべきURLを適切に探し出せるのだ。

現在、DNSサーバとして一般的に普及しているのはBINDである。
このBINDは今まで数々のセキュリティホールを作りだしては
混乱を巻き起こしている。
それに対し、djbdnsは今までに一度も
セキュリティホールを発見された事が無い。

この関係、どこかで見たことが無いだろうか？
以前話題にしたsendmailとqmailの関係に似ている。
それも当然だ。qmailとdjbdnsは同じ作者なのだから。

--- 「先手」の優位性 ---
セキュリティホールの宝庫であるBINDやsendmailが使われ続けている
ことには原因がある。
「最初に登場したソフトだから」である。
当然、当時のプロバイダ達に選択肢は無く皆これらのソフトを使うことになる。

そして時代は流れ、djbdnsやqmailが開発された。
しかし、これらを使おうとする人達は少なかった。
以前から住み慣れてきた環境を変えることが嫌だったからだ。
「とりあえず問題無く動いているから」「皆使っているから」
という考えは解らなくも無い。

しかし、それが大変な被害を捲き散らす原因になる。
BINDにバグが発見される度、世界中で問題が発生するだろう。
「Webページにアクセスしたら別のページに飛ばされた」
「メールの内容がWebに公開されてしまった」
これらはもはや個人あるいは企業レベルで済まされる問題では無いはずだ。

--- 自給自足か否か ---
djbdnsのコードステップ数は約7,000程らしい。
それに比べ、同じDNSサーバであるはずのBINDは100,000ステップを超えるそうだ。
何故これ程までの差が出たのだろうか。
BINDの方が高機能だから？確かにそれは間違ってはいない意見だ。
しかし、根本的な原因はもっと別のところにある。

BINDは、あらゆる機能を全て自分達で作ろうとした。
わかりやすい所で、セキュリティ関連のコードがある。
djbdnsは、ssh等の確かな実績のある外部ツールを使うことでセキュリティを確保した。
しかしBINDはこれすらも自前で用意した。
その結果、BINDはセキュリティホールの巣窟になってしまった…

--- 独占意欲 ---
BINDが全ての機能を自給自足しようとしたのは、
それによってDNSサーバの地位を独占しようと思ったからだ。
これはMicrosoftの戦略に似ている。
構成ファイルも独自の(非常に解りにくい)ものを使っている。
Excelファイルが独自のバイナリ形式を用いているのと同じ理由だ。

僕は以前にも言った。
「全ての処理を自分達の用意したツールで行いなさい」という彼らの要求は
非常に迷惑極まりない。
僕らは自分達でカスタマイズしてもっと便利に使いたいのに。

--- 利己的策略 ---


上の言葉は、djndnsの日本語サイトからの引用である。
BINDを作っている集団はこんな馬鹿げた事を考えているというのだ。
でもそう考えると納得いく部分が数多くある。Microsoftにも同様に。

結局、彼らは自分達の利益だけを考え
ユーザーの利便性など何一つ考慮に入れていない。
だから僕らはdjbdnsやqmailを使い、BINDやOutlookを拒絶する。

僕は別に何も困っていない。
大衆的なツールを使わなければいけない理由など何処にも無いからだ。
自分が使いやすいと思うツールを使う。
だけどもし今後、仕事でBINDを使わなければならなくなったらどうしよう。
少し悩むところだ…

--- 高品質？ ---
またここでも嫌な言葉を聞いてしまった。
「障害出しとかないと、品質問われるから」
…はぁ。どうしてこういうアホな顧客が多いんだ。

向こうの言い分はこうだろう。
「障害が出てそれを直した数が多い方が高品質に決まっている」
ならば僕はこう言い返す。

専門学生が100回手直しして作った自動車と
この道30年の職人が一つのミスもおかさずに作った自動車。
どちらが安全に乗れますか？

--- 傷跡 ---
プログラムだってこれと同じだ。
誰が何と言おうと、障害の数は品質の向上には全く結びつかない。
設計がまずいから多くの障害が出るのだ。
そして障害を直した後には必ず「傷跡」が残る。

傷跡はかさぶたとなり、もし今後この近くで障害が起こると
それは剥がれて中から血が吹き出す。
そして、それを治すためにより頑丈で複雑なパテで塗り固めるのだ。
古傷はある日突然再発することも知らずに…

--- 本来のテスト ---
品質を確認するために必要なことは何か？
それは恐らくどんな現場でも行われているであろう
テスト作業に他ならない。
しかしテストとは、その内容が重要なのだ。

物置きを作りました。
これの品質テストをしてみましょう。
まず一人が屋根に登りました。大丈夫そうです。
では何人乗るか試してみましょう…100人乗っても大丈夫でした。

これでテストは完璧です。
この物置きは100個(人)のテスト項目を見事クリアしました。
無事お客様に売り出すことができます。

あるお客様が物置きを買いました。
まずはドアを開けてみました…そしたらドアが外れました。
雨が降りました。そしたら塗装が剥がれました。
試しに100人乗ってみました。もちろん大丈夫でした(笑)

--- 保証鑑定人 ---
上のはあくまで例です(当たり前か)。

でも、これと似たような事が多くの現場で行なわれているのは事実だ。
しょうもないテスト項目をウン百と並べ立て、
おそらくわざと出したであろう障害表を山詰みにする。
そして客は満足する。「これなら安心だ」

一体何が安心なのだろうか？僕には理解できない。
彼らはプログラムの本質を全く理解していない。
テストをしたら、そのテストが本当に
「この商品の品質を保証できるテストなのか否か」を
見極める人物が必要になってくる。
しかし大抵の場合、そういった人材は皆無だ。

--- 結局… ---
そうさ、これはビジネスなんだ。
そんなことは僕だって判っている。
だけど、こんなビジネスは決して長くは続かない。
今は需要に供給が追い着いていないから
どんな駄目技術集団にも働き口はあるけど。

この業界はバブル期にあるんだってことを理解することが大事。
数年後にはこういう奴らの半数は路頭に迷うことになるだろう。

--- 新発見 ---
今日の朝、エレベーターに乗ったときの出来事。
一緒に乗った人が6階のボタンをしきりに押している。
が、そのボタンは既に押されていて点灯している。
一体何してるんだろうなぁ…と思っていたその時！

ボタンの点灯が止まったのだ。
要するに、間違えて6階のボタンを押してしまったので
それを取り消そうとしていたらしい。

今まで長いことエレベーター使ってきたけど、
こんな手法？があるとは知らなかった。
確かに、間違って押しちゃうことってあるもんねぇ。
皆も、そういう時はもう一回(数回？)ボタンを押してみよう。

--- これで最後？ ---
午後から田町へ。
僕のやってた作業を別の人が引き継ぐことが
正式に決まったので、今日は一緒に行って手順なんかを教える。
これでもう僕が行く必要は基本的に無くなったんだけど
プログラム担当は僕なので、現場で調査が必要なときなんかは
また行く可能性はあるかもね。

--- in会社 ---
おっそろしく暇である…
仕方無いのでEclipseの新版をダウンロード開始。
遅い…10時から始めたのに定時内にDL終わらない勢いだぞ(笑)
ダウンローダー入れてないから
途中で止めるわけにもいかないし参った。

…結果、終わりそうにないので諦めて中断しました(涙)
今どき2Kbyte/sしか出ないこの環境の悪さ何とかならんかね。
年内には光回線を導入するって噂も出てるらしいので
それを期待して待つとするか。

--- CVSnt ---
以前から現場のソース管理にはWinCVSを導入してたんだけど、
これだけだとEclipseから使うことが出来ない。
Eclipseはpserverとext(ssh)しか対応してないらしいので。

で、何とかならないかと調べた結果やっぱりあった。
それがCVSntだ。これを使えばWindowsでもpserver経由でアクセスできる。
初期設定のユーザー追加する所でつまづくが
直接passwdファイルを作ることで無理矢理(？)解決。
無事Eclipseのソース管理に対応させることが出来た。

--- 快調？ ---
昨日断念したEclipseのダウンロードを
また懲りずに朝からチャレンジ。
おっ、今日はなかなか快調だ。
10時から始めて12時半には終わりそうだ。7.5bytes/sも出てるぞ(笑)

--- Tomcat ---
日本語による「素」のTomcat情報っていうのは本当少ない。
おそらく大抵の企業では
どこぞのWebアプリケーションサーバーを使って
「充分に環境が整った状態」で開発をしてるんだろう。

今日悩んでたのはJSPの文字コードの問題。
デフォルトだと、JSPから生成されるJavaプログラムが
UTF-8という文字コードで出力されてしまう。
が、あいにくEclipseではファイル毎に文字コードを変えることが出来ない。
通常のファイルは全てShiftJISで作ってるから
二つの文字コードが混合する構成になってしまう。

当然Tomcatもソースが公開されてるので
それを追って調べるとすぐに対象箇所は見つかった。
そこをShiftJISに修正してコンパイルし直すと…
ほ?ら、うまくいった。

--- フリーの使い易さ ---
IISやWebSphereなどの製品を使ってると、こう上手くはいかない。
ソースが一切公開されていないからだ。
何かカスタマイズしたいと思ったらメーカーに直接交渉して
対応策を練る必要がある。
ソースをたった1行いじれば解決する問題でも
おそらく1ヶ月程度は掛かるだろう。

だから僕はフリーの製品が好きだ。
確かに日本語の情報が少ないが、それさえ乗り越えれば
市販製品以上のパフォーマンスを出すことが出来る。
ほぼ例外無く市販パッケージは「高機能、低速度」なのだから。
もちろん一番重要な「初心者が導入しやすい」作りには余念が無い。

--- 保守的商品 ---
市販パッケージは「安全性」が第一だ。
それを確保するために、どうしても速度は犠牲になる。
もし速度を高めるために最適化をしてバグが出たら
ユーザーからクレームが入る。そして修正をしなければならない。
その手間と時間を惜しんでいるのだ。

こういう保守的な姿勢を取るメーカーの製品を使う気にはなれない。
ApacheとTomcatさえあれば何でも出来るのだから。
以前注目してはJBoss(を含めEJBサーバ全般)は
まだ運用に使える域には達していないようだ。
速度面で相当のハンデを負うことは必至なので導入は控えるつもり。
あと2年くらい待つ必要有りかな…

--- 調査 ---
ようやくEclipse2.1をダウンロードできた。
ということでまずはどこが変わったのか軽く調査。
リファクタ関連がかなりパワーアップしたみたい。
とは言っても、実際あんまり使わないんだけど…
そういう規模の開発してないからなぁ。

プラグイン開発にチャレンジするも、余りの難解さに挫折。
また今度にしよっと。

--- 月末 ---
ということで今日は勤務表の締め切り日だ。
なんか今月は相当暇だったなぁ・・・
とりあえずリーダーにこの空き空きスケジュールを
何とかしてもらえるようにメール。

前も言ったんだけど一向に状況は改善されないから
今回も期待はできないけどね。
契約が来年の3月までなんで、その時にスッパリ辞められるように
今から布石を打っとく必要があるのだ。
もちろん、もっといい仕事割り当ててくれるんなら
それに越したことは無いんだけどさっ。

--- 小さな変更 ---
Eclipse2.1は使ってみると色々な変更点があることに気付く。
そのどれもが小さなものなんだけど、これが有るか無いかで
便利さが全然違ってくる。

うまく言葉で説明できない程ささいな変更なので
伝えられないのが残念だけど、まぁ一度使ってみればすぐ判ります。
例えばインデント(タブ)の補間。
これ自体は普通のエディタにも備わっているんだけど
Eclipseのは一味違う。

別の箇所からテキストをコピー(張り付け)しただけで
コピーした部分のインデントが自動的に修正されるのだ。
これは非常に便利。なんで今までのエディタには無かったのかと思うほど。

ただ、前々から気にはなっていたけど
自動コードフォーマットの整型が今いち使いずらい。
やたら改行とインデントが入るので、かえって見にくいのだ。
この機能は自動的に働くわけではないので
コマンドを使わなければ済む話なんだけど、
もう少し自分なりのフォーマットを指定できれば便利なのになぁ、とか
たまに思ったりするのである。

--- Apache2.0 ---
今年中にはサーバマシンを入れ替える予定なので
その際にApache2.0の導入をしようかと思っている。
今までほとんど情報が無いので使うつもりは無かったんだけど。

調べてみると本家のページでかなりの情報が日本語化されている。
しかも、結構便利な機能が色々あるみたいで
無性に使いたくなってしまったという訳。

さぁ、そうと決まれば情報収集開始だ。
幸い時間は山のようにある。

--- と思ったら… ---
リーダーからメールが来る。
僕の要求をとりあえず聞いてくれた形になったんだろうか。
次の案件を拾ってきてくれるらしい。
が、その内容というのが「Accessによる見積書の作成・印刷するシステム」
というんだから参った。

確かに「どんな言語でもいい」とは言ったものの、
Accessって言語じゃなくて完全にアプリだからね。
まぁグズグズ言っててても始まらないので
とりあえず関連のWebページを漁り始めるとしよう。

--- ≠プログラマ ---
それにしても酷いね。このAccessっていう製品の作りは。
こんなの使ってるから作業効率が上がらないんだ。
発見したWebの内容も、おおよそプログラマとはかけ離れた人達のページばかり。
こういうのはExcel他と同様、事務の人間なんかに
やらせとくのが自然な流れだと思うんだけど。

こんなの覚えるために時間費やすのも馬鹿馬鹿しいが、
他にやることも無いし我慢して進めるとしよう。

--- ナイスタイミング ---
家に帰ると、たて続けに宅配が2件。
実は新マシンを注文してたのだ。
それにしても同じ日に来るとはタイミング良いね。

今回買ったのはEPIAというマザーボード。
CPUはVIAの553MHzを搭載していてファンレス仕様なのだ。
それに、同じく静音がウリのAC電源タイプのケース。

このケース、ベアボーンを平べったくしたような感じでかなり小さい。
マザーボードとHD入れたらもう一杯。
一応この他にもFDDとスリムタイプのCDドライブは入れられる構造には
なってるみたいだけど特に必要も無いのでこれだけ。

--- 静 ---
電源はほぼ無音。HD冷やすためにファンが付いてるので
これが少々うるさい。そのうち静音ファンでも買ってこよう。

HDは一応現在出回ってる中では一番静音の
SeagateのBarracuda ATA IVなので替える必要も無しかな。
でもやっぱりこれが一番の騒音の元なんだよね。

メモリ買うの忘れてたので、とりあえず余ってる256を差す。
サーバに使うのでいずれは512*2(MAX)まで積んでおこうかな。
今までノートの128でやってきたから色々苦労してたんだよね。

--- FreeBSD ---
うむむ…やっぱりいきなりFreeBSDに移行するのは無理があるみたい。
ファイアウォールの設定とかRedHatとかなり違う部分が多いので
ひとまずRedHatで立ち上げることにした。
そこまでしてFreeBSD使う理由も特に無いしね。

--- 忘れた頃に… ---
大昔にあった、前プロジェクトの仕様変更の話が
今さらになって出てきたらしい。
あのときは工数見積もっただけで手は付けてなかったんだけど。

ただ、確かあの修正って1人月くらい掛かるはずだから
そうなると来週から受けるであろう
Access新プロジェクトの方はどうなるんだ？
また先送りとなってしまうのか…いつの間にか
新(もはや旧だが)ASPプロジェクトからも外れてるしなぁ。

--- 適当？ ---
…仕変会議終了。
向こう(別部署)側は何も理解していないらしく
仕様書の内容説明だけでエラい手間取っている。
聞いてて眠くなってきたぞ。

しかもまだ完全決定ではないらしい。
何故そんな段階で見積もりせにゃあかんのかは知らんが
適当な仕様書からは適当な工数計算しかできないので適当に書いておく。

--- 久々のヒット ---
珍しく笑えるCMを発見。
明日のジョーとユン・ソナが共演(？)してるやつだ。
顔だけ実写っていうのがまたいい味出してる。

--- 立派なエコロジスト ---
よく思うのだが、Windowsのアプリはどうして
あんなにメモリを食うものが多いんだろう。
特に開発系のアプリだと平気で「500MBは無いと」みたいな声が聞こえてくる。
一体500MBがどれだけの容量なのか判ってるの？

これらのケースのほとんどは、明らかに資源の無駄使いをしている。
メモリ使用量がどんなに増えようが一切お構い無しだ。
そういう意味で、qmailやdjbdnsなどD. J. Bernstein氏が作り出すソフト群は凄い。
メモリやCPUの消費量を極限までスリムにした構成は
高速、省資源、安定性の全てを兼ね備えた逸品だ。
彼こそ究極のプログラマであり、究極のエコロジストなんだと僕は思う。

--- 環境構築 ---
相変わらずこんな事をやっている。
新サーバマシンはやっぱりFreeBSDでいくことに決定。
今日はメールサーバの導入と、それを読むためのemacsの設定。

今まではメール閲覧にはずっとPOP使ってきたんだけど
自宅サーバしてるんだから、わざわざそんな事する必要は無いんだよね。
ローカルから直で読み込むようにすればいいんだ。
が、そのためのmewの設定に大苦戦。
結果、Maildirパスの指定を絶対パスで書いたらすんなり行くという…

なんで相対パス(?)だと上手くいかないのさ。
しかもそのことに関するメッセージは全く出ないので
そこが原因だって気付くのに相当掛かってしまった。ふぅ。

メーラー乗り替えようかとも思ったけど、
他にいいのも見当たらないからなぁ。しばらくこれでいくか。

--- 乗り替え挫折 ---
早くもApache2.0運用が暗礁に乗り上げてしまった。
一番大事とも言えるmod_rubyモジュールの作成がうまくいかない。
最新バージョンではApache2.0に対応しているらしいが、
やはりまだ使っている人が少ないのだろう。
ノータッチ(=ソースの手修正無)で全ての環境で使えるわけでは無いようだ。

メーリングリストに投げればすぐ解決してくれそうな気もするが、
やっぱりプログラマとしては、もう少し自分で調べてから
質問するのが礼儀だと思うのでやらない。
今は自分で調べてる余裕が無いのだ。

とりあえずはApache1.3で立ち上げて、
徐々に2.0環境を使えるようにしていこうかな。
今度はTomcatのバージョンも決めないといけない。
5.0が出たみたいだけど、一番安定してるのは3系列なんだよなぁ…悩むところだ。

--- NHK杯フィギュア ---
日本最高のフィギュアスケート大会が始まった。
国際大会だが、地元開催ということもあって日本からは3人のエントリー。
ソルトレイクに出場した村主と恩田、それに
前々回長野オリンピック出場経験のある荒川。

それにしても恩田さんはショートカット過ぎて少年みたいだったぞ(笑)
なかなかドレス着てこういう髪型する人もいないと思うけど
似合ってからまぁいいか。
トリプルアクセルは残念ながら失敗。が、その後のジャンプは全て成功。

普通に考えると「だったらトリプルアクセル外したら？」っていう
声も聞こえてきそうだけど、そこを挑戦するのが
彼女のプライドなんだと思う。

--- 彼女の内容 ---
今日の村主さんの演技は…とても緊張していた。
ソルトレイクのような笑顔は無かった。
エースとしての自覚。繊細すぎる神経。
演技が終わった後結果を待つ間、彼女は涙を流していた。
そして一言。

「私、何やってるんだろう…」

彼女の気持ちが、僕の心に突き刺さる。
僕が滑っているわけでも無いのに、何故か涙が溢れてくる。
どうしてなんだろう？人の事で泣くことなんて無いこの僕が。

--- 強い意思 ---
村主さんは間違い無く、他の誰よりも強い意思を持っている。
だから失敗したら悔しいし、泣くこともある。
それが良い方向に出ないこともあるけど、
最後には彼女は絶対笑ってくれる。そう僕は信じている。