さて、今日から現場が変わりました。
今回のは入る前から大体現場の雰囲気が掴めてたので
特にグチる事もありません(笑)。

ただ、予想してた以上にショボいプロジェクトだったね。
まぁ素人達に作らせる訳だから仕方無い事なのか。
彼らに全部作らせていたら到底終わりそうにも無いので、
共通部分が僕が提供する形にしようとは思ってるんだけど。

--- 片手間 ---
今回、作成に携わるPGは全部で3人。
ただその内2人は、他のプロジェクト(テスト担当)も受け持ってるので
半分位の工数で計算してくれとの事。

その中途半端な考え方が腐ってるね。
今回は、彼らにプログラムを勉強させようという目的があるらしいのだが
だったらそれに集中する環境を与えてやれよ。
片手間で作ってロクなもんが出来る訳ねーっての。
プロジェクト掛け持ちするのはもっと能力が付いてから。

--- 電子マネー ---
現場のあるビルは、全ての施設で電子マネーが使える。
中には電子マネーしか使えない場所もあったりする。
例えばとあるメーカー直営店のゲーセンとか。

っていうか何で仕事中にゲーセン行ってるんだ、俺は(笑)。
というのも、現場の人と昼食べた後に
ちょっと寄ってこうと言われて行ったんだからしょうがない。
ここの現場の人は結構行ってるらしいね。随分自由な現場だこと。

ただ、予想通りシューティングゲームが無い。
STGの無いゲーセンなんて俺に言わせりゃゲーセンとは呼べないぜ。

さーて、そろそろ現場にも慣れたんで日記でも書きますか。

まだ仮マシンでの作業なんで、なるべく開発作業は控えることにする。
っつーか出来ない。相当スペック低いノートPCなもんで。
一体いつになったら正式なマシンが来るのだろう。

おかげで、今までに経験が無いくらい
ドキュメントを作り込んでしまった。
こんな細かく書く位だったら自分で作った方がよっぽど早いのだが、
そうする訳にはいかないのだ。

--- 大丈夫？ ---
それにしても、作成担当PGのレベルが
かなり低いようなんでそこが問題。
でも、やる気はあって勉強もしているらしい。
今日もいくつか質問されたけど、質問内容から察するに正直厳しいだろうね。
彼らに全てを任せてたら2ヶ月で終わりそうにない。

本人がやる気あるのはいい事なんだけどね、
あんまり残業とかされてもこっちはつき合いたくないのだ。
ある程度自分の力量をわきまえた上で
僕の方に任せてくれた方がいいんだけど、そううまくいくかなぁ。

--- ドキュメント ---
よく、プログラマっていうと「ドキュメント書けますか？」
てな事を聞かれたりする訳だけど
ドキュメントも書けないようなプログラマはプログラマとは呼べんよ。
そんな奴らと一緒にしないでくれ。

自分の考えを文章にして相手に伝えるなんてのは出来て当然。
もちろん僕も、出来る限り必要の無い無駄ドキュメントは
書かないようにはしてるけど。
書くとなったら丁寧に書くよ。誰が見てもわかりやすいようにね。

--- 忘れてた… ---
しまった。今日は田臥のデビュー戦が朝11時からあったんだ。
録画してくるの忘れちまったぜ。
15人のロースターに残ったのはこの前書いたけど、
その後さらに12人の開幕メンバーに入ることが決定。

…うむ、ニュースで見たところ、やはり出番はあったようだ。
しかも結構活躍している。
たしか今日の深夜に民放で録画放送あったはずだから、チェックしておかねば。

やっと現場に僕のマシンが来ました。
予想してた通り、相当の貧スペックに少々やる気が失せる。
256しか積んでないでWebアプリの開発は相当厳しいよ。
まぁ僕は本来開発担当ではないからそんなに気にする必要も無いんだけど。

でもやっぱりマシンの性能が低いのは辛いね。
作業しててストレスが溜まるから。
Javaの開発した事がない人間というのは、こういう事が解らないみたいだ。
Javaアプリというのはとにかくメモリを食う。
EclipseもJavaベースだから軽く100MBを超えるメモリを消費してしまう。
もちろん、その分のメモリさえ確保すれば最高のパフォーマンスを得られるんだけどね。

--- 初の舞台 ---
また新たな舞台へ日本人が立った。
世界最高峰のバスケットボールリーグ、NBA。
田臥勇太は、フェニックス・サンズの一員として開幕を迎えた。

大量リードを奪った最終クォーターに、ようやく出番が回ってきた。
そのときの会場の盛り上がり方に、彼が単なる一人の新人選手ではないことが伺える。
日本人初のNBAプレーヤーを、観客は皆歓迎していた。

そしてしっかり結果も残した。
これからの活躍次第で、もっといい場面で彼の出番もきっとあると思う。

--- NHK杯 ---
さて、今年もフィギュアスケートの季節がやって参りました。
今年から採点システムが変更され、点数差が付きやすくなったらしい。
以前にも増して、ミスの許されない演技が要求される。

そんな中、圧倒的な強さを見せた選手がいる。
昨シーズンの世界選手権を制した、荒川静香。
あのときもそうだったけど、今日の彼女の演技は完璧だった。
おそらく、以前までの採点システムだったら6点満点が出たんじゃないかと思う。

思わず解説者が言葉を失うくらい、非の打ち所が無かった。
2位に10ポイント以上の差を付けて、ショートプログラムを終わってトップに立つ。
まだ明日のフリー演技があるというのに、
「逆転するのは不可能ではないでしょうか」という実況が流れる程。

でも、それほどまでに今日の演技は見事としか言いようがないものだった。
明日も、よほどのミスをしない限り優勝は確実だと思う。
それよりも、今日よりもさらに難しい演技を予定してるらしいから
それが楽しみだね。

やべっ、久々に本格的な風邪。
昨日大量に飲んだのが原因か。
あ?あ、これでもう今月休めなくなりそうだ。
まだ月の始めなのになぁ。
明日までには治して会社行かないと…

@ITにこんな記事が載っていた。
http://www.atmarkit.co.jp/farc/rensai/heaven01/heaven01a.html

「優秀な技術者を集めることは、プロジェクト成功への確実な要素ではない」

そこには、「優秀」な技術者を集めたにも関わらず失敗してしまった
プロジェクトの例が挙げられていた。

確かにこの記事は一見正しいように思える。
が、僕に言わせれば根本的な間違いが一つある。
プロジェクトが失敗してしまったような技術者を何故「優秀」と呼べるのだろうか。

--- 優秀って？ ---
おそらく、彼らの意見は「技術スキルがある = 優秀」というものだろう。
いくら技術スキルがあっても、それを有効に活用してくれるマネージャ等がいなければ
彼らの力は発揮されないという。
そんなのが本当に「優秀」な技術者と言えるだろうか？

そういった輩は、常に優秀な人物の元で働いてきたのだろう。
自分がやるべき内容を指示され、それに従って忠実に動く。
しかし、それによってどのような結末が待っているかを判断する能力が無い。
その結果、彼らは月350時間という強制労働を強いられたらしい。

--- プロジェクトを成功に導くには ---
優秀だと言われている彼ら技術者に、最も欠けている部分がある。

プロジェクトを完成させるために必要な作業の全体像が見えていない。
それは全ての事項よりも優先して考えられるべきなのに
誰もその事を考えていない。もしくは、考えるだけの能力が無いと言った方が正しいか。

--- 技術者の役割 ---
そういった作業はプロジェクトマネージャ(以下PM)がする事だから
技術者は全く気にする必要が無いって？
甘いね。

PMは、ピラミッドの先端に位置する人物だ。
大まかなスケジュールを決めるのは彼だが、
それを実現できるかどうかは実際に作業する技術者でないと判断できない。

今回の例では、PMはそれを判断することが出来なかったようだ。
最初の3ヶ月間では「理想的」な設計書が作り上げられた。
しかし、その設計をコーディングするのにどの程度の工数が掛かるかという事を
誰一人として判っていなかった。
そしてこれは、「実装」を軽く見ている奴らがよく陥るトラブルだ。

--- 現実を見る力 ---
こんな初歩的なミスをおかすPMが、果たして優秀と言えるのだろうか？
僕から言わせれば、彼はとんでもない無能PMだ。

理論や過程なんかどうでもいい。
ただ単に、彼は「結果」を残せなかった。
それだけの理由だ。仕事とは、そういうものだと思う。

だから、僕がPMに一番必要だと思う条件はたった一つ。
それは「現実を見る力」だ。
緻密な設計書大いに結構。しかしそれも、プロジェクトが成功してはじめて意味をなす。

現実が見えていれば、そのプロジェクトを成功に導くための道がきっと見えてくる。
「何とかなるだろう」。PMが決して口にしてはいけない最悪の言葉だ。

PMが発する言葉はこうであるべきだ。
「何とかする」。その為にPMがいるのだ。全力を尽くし、プロジェクトを成功に導くために。

--- 先生 ---
この現場は、もともとハード系テストの作業をする人たちが多いので
そもそもプログラマが少ない。
周りから「先生」と呼ばれている人ですら、相当レベルの低いことが判明。
笑っちゃいかんが、その程度の実力で先生と呼ばれてて恥ずかしくないのかねぇ。

ここのPCは昼頃になると急に処理が重くなる。
なぜかというと、ウイルスチェッカーのタスクが強制的に始まるからだ。
クライアント側から解除できないらしく、12:00?13:00くらいまでは処理がメチャクチャ重い。

ちょうど昼飯どきだからいいじゃん、と思うかもしれないが
ここの現場は皆11:30くらいから飯に行くのだ。12:00だと混むからね。
だから、昼から帰ってきてもまだ12:00過ぎだったりする。
そうすると、後の1時間くらいの作業に支障が生じるという訳。

だいたいウイルスチェッカーなんて事後策に過ぎないよ。
それ以前にウイルス持ち込ませない努力をしてほしい。
全く関係ない僕まで被害受けてるんだからね。

--- やはり無理が… ---
現場メンバーの作業が全く捗っていない。
まず、3人いるメンバーのうち2人は他の作業に追われてて
今だに作業を始めてさえいない。
既に作業を始めてる人物も、一番初歩的とも言えるDBアクセスの課題を与えたのに
まだ一つも完成していない有様。

こんなんじゃ前途多難だ。
僕としては早く、彼らを切り捨てて僕が開発をするという方向に進めたい。
でも今の段階でいきなりそれを実行するわけにもいかないので
とりあえず僕は僕で自分のモジュールを作成していって
頃合いを見計らったところで彼らのモジュールと入れ替えるのが妥当かな。

面接のときには「最悪のシナリオ」としてこの考え方もあることを説明されたのだけど、
現実問題からすればこれが「最良のシナリオ」かもしれないね。
間違い無く僕が作った方が良いモノが出来るんだから。
新人の教育は、また今度にした方がいいよ。
…というか一生無理だろうね。ここの会社の形態じゃ。

--- プロの世界 ---
NBAの開幕メンバーに選ばれたばかりの田臥に、早速プロの洗礼が与えられた。
わずか3試合を消化した段階で、チームがメンバー補強に乗り出したのだ。
フォワードで実績のある選手と契約、その結果田臥はメンバーから外れることになる。

田臥のパフォーマンスが悪かったわけではない。
チームの調子が悪かったわけでもない。チームは開幕から3連勝と絶好調。
しかし、その際に挙がった課題を克服するために
ビッグマン(背の高い選手)がどうしても必要だった。

田臥のポジションはポイントガード(以下PG)。彼はチームで3番手のPGだった。
残る2選手のパフォーマンスは高く、田臥が登場する(=必要な)場面はほとんど無かったのが現状だ。
そう考えると、今回の選手起用は納得のいくものと言えるだろう。

もちろん、これで彼の今シーズンが終わったわけじゃない。
必ず復帰するチャンスはある。
可能性として一番高いのが、現存する2人のPGが故障したとき。
このとき、間違い無く彼はスタメンに復帰する。
他人の不幸を喜ぶわけにはいかないが、田臥が今後羽ばたくにはこういった条件も必要だ。
そしてそれが、よりチームを強くすることだって良くある事なのだ。

--- JDK5 ---
Eclipseも3.1からJDK5に対応してるので、家ではもっぱらJDK5を使っている。
やっぱり、これは便利だね。
Genericsとenhanced for loopだけでも充分使う価値がある。
これ使うとプログラムが綺麗になるからね。

最新のEclipse3.1M3ではstatic importやenum、可変引数にも対応してるらしい。
あとは拡張Annotationに対応してくれれば完璧だね。

またまた記事から。
http://www.itmedia.co.jp/anchordesk/articles/0411/09/news088.html

最近勢いを増してきたブラウザ、Firefoxの批判記事。
要約すると、今だに90％以上の人がIEを使っているのだから
FirefoxはIEの独自機能を少しはサポートするべきだ、というものだ。

IEに限らず、今までの全てのブラウザは専用機能をクローズアップしてきた。
例えば、大昔のNetscapeはレイヤーという概念を導入していたり。

--- W3C ---
今一番必要なものはこれらの専用機能ではない。
かなり前から、HTMLの仕様を決めたW3Cという規格が存在している。
これに従って皆さんブラウザを作って下さい、という事だ。

しかし、当時市場は完全にIE一本だった。
そのため、他のブラウザを作ろうなどと考える開発者は現れなかった。
それを最初に打破したのがおそらくOperaだろう。
僕も、発表当初Operaを使ってみたが
そのあまりの使いにくさに使用を断念した思い出がある。

--- 標準化 ---
Mozillaグループが開発したFirefoxは、W3C仕様に完全準拠しているだけでなく
ユーザにとって非常に使いやすいブラウザとなっている。
さらに、開発者が独自のプラグインを開発することも容易だ。

Firefoxが良いというのは正しいが、それが全てだという考えは間違っている。
現在、W3Cを忠実に再現するブラウザで最も優れているのがFirefoxなだけで
今後より良いブラウザが登場する可能性はある。
おそらく、携帯端末用にはもっとコンパクトなブラウザが必要となるだろう。

--- 未来の為に ---
話を戻すが、記事で言っている「FirefoxもIEの独自機能をサポートするべきだ」
という意見は完全に的を外している。
それは確かに既存のWebサイトを守るうえで重要かもしれないが、
未来の事を何も考えていない。

これらのサイトは近い将来「IEでしか」見れないサイトとして
ユーザから拒絶されてしまうだろう。
だとしたら、今やることは既存サイトを守ることではなく
積極的に標準化の仕様にのっとった作りに修正する事であるはずだ。

流行り廃りではない。これは時代の流れなのだ。
IEの使用率が(わずかずつではあるが)急速に下降しているのは紛れもない事実なのだから。
大きな流れに逆らう者は、この世界で生きていけない。

Javaでは標準で同期化の機能が導入されている。
同期化とは、ある変数が複数のプログラム(正確にはスレッド)から同時に
更新・参照された場合に不整合が起こらないようにすること。
Java では synchlonized 構文を使うことによって簡単に実現できる。

ただし、同期化を使うとプログラムが遅くなる。
この事は誰もが知っている事実であると思うが、
最近それを否定するような意見がよく出てくる。

つまり、JavaVMは日々進化しているので
同期化による処理速度の低下はもはや無くなっているという説だ。

--- どちらが迷信？ ---
これと似たような話が他にもいくつかある。
有名なのが、ガーベッジ・コレクションの話。
確かにJavaVMは進化し続けているが、間違い無くガーベッジ・コレクションの処理は
「無視できるほど」軽くはなっていない。

そして同期化の件。
同期化処理がまだ無視できるほど軽くなっていない決定的な証拠が一つある。
JDK5.0で追加された StringBuilder というクラスがある。
これは、StringBuffer とほぼ同じだが同期化処理を施していないクラスだ。

もし、同期化処理が無視できる位に軽かったら
わざわざこんなクラスを追加する必要があるだろうか。
つまりこの事は、今だに同期化は処理速度を低下させるという裏付けになる。
もちろん、どれほど低下するのかは実際に計測する必要があるけどね。

--- スワップ全開 ---
あ?あ、こんなマシンでWebアプリ開発はきついぜ。
256しか積んでないのに、メモリ使用量は軽く330MBは超えてる。
Eclipse2を使えばもう少し減らせるんだけどね。
今さら2には戻れないというのが正直な意見。

おかげでマシンはいつもスワップ処理がフル稼働状態だ。
こんなんじゃハードディスクにも悪いしロクなことが無い。

--- とりあえず前進 ---
ふぅ、ようやくメンバーの一人が与えてた課題を終えたようだ。
来週からは残り二人のメンバーも加わって本格的に作業してもらうことになりそう。

当初聞いてたよりもかなりの機能追加をしようって話なので
少しは暇な度合も減るのかな。と期待してみたりする。
向こうが要求したものを作るだけじゃつまんないからね。
色々と隠し機能でも付けてやろうか(笑)。

朝から雨で電車が遅れる。
と思ったら、今度は人身事故があったらしく停車。
まったく、今日はついてないね。

--- 時代遅れ ---
あ?あ、何で日本のスポーツ界ってのはこんなに時代遅れなんだ。
バレーボール女子日本代表、栗原恵。
彼女が今シーズンVリーグでプレーできないというニュース。

もともと彼女はNECに所属していた。
で、昨シーズンを最後にこのチームを辞めて移籍先を探していた。
海外リーグへの参戦という話もあったんだけど、結局はVリーグのパイオニアに移籍することが決定。

さて、ここからが問題。
まもなく始まるVリーグ。その開幕1ヶ月前までに登録していない選手はリーグ戦に出ることが出来ないというのだ。
つまり、彼女はパイオニアの一員として試合に参加できない。それも今シーズンを通して。

--- 皆のために ---
一体何のためにそんな下らない規定を作るんだ。
海外のスポーツを見てみろよ。
昨日までハンバーガーショップで働いてた人間だって、翌日からプレーオフの試合に出れるんだぜ。

日本のエースである彼女を試合に出さないということが
どれほどの損害を与えると思ってるんだ。そんな規定を作る理由がわからない。
ほんと、Vリーグのスタッフっていうのは腐りきってるね。
以前、加藤陽一が海外のリーグに出るときもそうだったし。

日本のバレーを強くしようって気持ちのカケラも見えない。
何のためにVリーグを開催してるのか、その意義が全く見えない。
いっそのこと選手達にはストライキでも起こしてほしいよ。
そうでもしないと奴らの心は変わらないだろう。

うむむ…メンバーの作業が全く捗ってないぞ。
能力無い以前にまずやる気がないってのが一番の問題。
一人は完全にやる気無し、もう一人はまあまあ、最後の一人はそれなりに頑張っている。
というわけで、メンバー3人の「スキルを考慮しない」実質人数は1.5人とみた。

これにスキルを考慮すると…恐しいから考えないことにしよう(笑)。
そんな事を知ってか知らずか、今日もまた機能追加の話。
僕からすれば、もっとじゃんじゃん持ってきてくれって感じだけど。
そろそろ現存のシステムは大体作り終えてしまったので
どうしようかと思ってたところなのだ。

とりあえず現場のメンバーの作業も少しずつ進んできたようだ。
この調子なら予定してた今週中に終わるかもしれない。
とはいっても、来週から本格的にWebアプリの作業してもらうから
そこで脱落してくれなきゃいいけど。

それにしても、彼らはプログラマには向いてないね。
ひたすらコードを書く以外に、プログラム上達への道などあり得ないのだ。

--- 社内システム ---
今回僕らが作るシステムは社内で使われるものなので、
頻繁にユーザの声が僕のところに届く。これは非常に良い事だ。

その橋渡し役をしてる通称「SE」がいる。
SEっていうのは腰が低い方が成功するらしいね。
その点では僕も接しやすいので楽だ。

--- どこが？ ---
で、彼が「ちょっと無理っぽいな?」と言いながらやってきた。
先程行われた発表会で、ユーザからの希望としていくつか挙げられたようだ。
無理かどうかは僕が判断することなのだが、聞いてみてびっくり。
とんでもなく簡単な処理の追加じゃないか。
これのどこが無理っぽいのか俺にはよくわからんぜ。

ほんと、以前にもいたがこういう事をSEの分際で勝手に判断しないでほしい。
よっぽど無茶な注文じゃなけりゃ、僕が無理なんて言う訳ないのにさ。
だって、それを可能にするのが僕の仕事だからね。

無理って言う事は敗北宣言にも等しい。
僕は今までそんなセリフ、一度として言ったことは無いよ。
こっちが出来るって言ってんのに「そこまでやらなくていいか」と言われて
モチベーション下がった事は過去に何回もあるけど。

はぁ、またまたOracleでトラブル発生だ。

もともと、このプロジェクトはMySQLとPHPを使ったシンプルなものだった。
それを今回、OracleとJSPを使って書換えることになった訳だが。
奴らはなぜOracleを使おうとするのか。

--- サポート無 ---
以前僕は、Oracleにはサポートがあるから
これに逃げようという魂胆があるのかと思っていた。
しかし今回の現場の場合、まともに人数分ライセンスを買ってないようで
そのサポートすら受けられないという有り様。

しかもバージョンは8iとかなり古い。
この頃のOracleは、JDBCの対応も2.0まで。
もっと正確に言えば、その対応すら全く不十分だ。

こんな数年前のデータベースを選択する理由が、僕には全く理解できない。

--- バグだらけ ---
OracleのJDBCドライバはバグだらけな事は前にも話したが、
今回またバグを発見した。
結果セットをスクロール可能にすると、日本語が化ける。

一応、Oracleのサイトから最新のJDBCドライバを落としたら
このバグは直っていたが。
仮にもCDリリースをしてる製品にこんな致命的かつ単純なバグが残っているなんて
信じられない。
これはつまり、Oracle社の人間はJavaからデータベースにアクセスする事など
辞めろと言ってるのと同じだ。

そう、結論はこうだ。
「JavaのプロジェクトでOracleを使うな」

--- 間違った認識 ---
なぜOracleを使うのかと聞いてみた。
「将来扱うデータが大きくなったときのためらしいよ」
こういう事を言う奴らは何も彼らだけじゃない。

どっからそんな嘘情報を仕入れたのか知らんが、
Oracle以外のDBが大容量レコードに耐えられないとでも思っているのか。
それ以前に、大容量レコードを扱うんだったらまず
Windows上にサーバ立てるのを止めてくれよ。

とにかく、今回はOracleでいくことは外部の都合で決定してしまったらしいので
これで頑張るしかない。
8iのドライバにはCLOBにアクセスする簡単なインターフェイスもない。
他に山ほど便利なものがあるのに、それを使えないもどかしさ。あぁ嫌だ。

--- 今回の形態 ---
今回の契約はやや面倒なのだ。
僕はとあるA社のフロア内で働いている。
そこには、B社のメンバーが十数名ほど働いている。
僕は本来その他のC社なのだが、一応B社の「協力会社の社員」という形で働いている。
だから名札もB社のものだし、A社の人間は僕のことをB社の人間だと思っているのだろう。

まぁそんな事は置いといて、今日の夕方頃。
そのB社の営業が現場に来ていたらしく少し話をした。
僕の契約は12月末までなのだが、来年以降もB社経由で働く気は無いか、というもの。

--- 読めました ---
案件があるというので聞いてみる。
最近は大抵、話を聞けばその現場がどんな感じだか解るようになってきた。
ここら辺はやっぱり、経験があってこそだよね。

一言で言えば、ずばり「却下」の案件だったんだけど。
今度面接に行ってほしいと言ってきたのだが、ここは丁重に(やや嘘)断わっておいた。
彼は営業にしては意外と物わかりが良いので助かる。僕の意見も聞いて理解してくれるし。
確か技術の経験もあるとか言ってたっけ。

懲りずにまた何か案件があったら紹介してくれるらしい。
まぁ僕としても、現場にいながら次の面接の手配をしてくれるので
楽っちゃあ楽だしね。

--- 時間不足 ---
来週は火曜が休み。
本来だったら月曜も休んで4連休といきたいところだが、
月の始めに休んでしまったので今月はもう休むわけにはいかない。
祝日が2回もあるからね。

今までだったら少し残業してもっと休みを取ってるところなんだけど、
ここにいてもやること無いしね。それにマシンは超貧弱だし。
その辺も今日来た営業の人に言っといたんだけどね。
改善されるかどうか。

やっぱり今日は休日に挟まれた平日ってことで人が少なかった。
僕がいる部屋なんか4人しかいなかったから気楽にやれてよかった。
…まぁいつも気楽にやってるけどさ(笑)

--- 久々のライブ ---
なんか最近、全然ライブ行ってないぞ。
というわけで、YASSさんのライブが12/23にあるらしい。これは行かねば。
ただ、場所が四谷天窓っていうトコで結構狭いらしい。定員55名とか。
さっきチケット予約のメール入れたんだけど、間に合ったかなぁ。

日記で相撲の話をするのは初めてかもしれない。
最近、夜にまとめてハイライトを流す25分番組が毎日やってるので結構観てたりする。
生で観るのは無理だから(だって6時前だよ？)、こういう番組は非常に嬉しいね。

で、白鵬って力士が今強ぇ。
まだ幕内上がって3場所目くらいなのに、ここまで9勝1敗。
今日なんかあの強かった横綱の朝青龍にまで土を付けて、この強さはまさに本物。
今後も楽しみだ。

最近よくこんな記事を目にする。
「LinuxよりWindowsの方が低価格運用を実現できる」
何当たり前のこと言ってんのさ。
一体誰がLinuxをクライアントとして使おうなんて事言い出したのだろう。

Linuxは確かに最近X-windowsを搭載しているが
クライアントマシンとして使うにはまだまだ弱点が多過ぎる。
というより、Windowsマシンと比べてメリットがこれといって無いのに
どうしてわざわざLinuxを使いたがるのだろう。

--- サーバとしての地位 ---
Linuxはサーバとしての地位を確立した。
unixを使うまでもなく、Linuxサーバの安定性もかなり信頼できるものとなった。

当然のように、Windowsはクライアントマシンとして唯一とも言える存在だ。
これらを使い分けることが重要なのだ。
Linuxだから安全だとか、Windowsだから危険だとかそういう問題ではない。

--- 危険なのは何だ ---
Windowsが危険なのではなく、Microsoftの作るアプリケーションが危険なのだ。
筆頭が、IEとOutlook。この両者を使わずにWindows Updateを行っていれば
ほぼウイルスの混入する危険は無くなる。
もちろん、ユーザがそれ相応の注意を払って使用することが前提だが。

Mozillaの開発したFirefoxとThunderBirdが、これらの代役として現在最も有力だ。
ポート監視ソフトである ZoneAlarm を使えば、さらに危険は減るだろう。
もちろん、全てフリーで使うことが出来る。

--- 限界 ---
IEのシェアが遂に9割を割ったそうだ。
これから先、シェアはある程度のところまで割り込むだろうが
一定以上には決して減らないことを忘れてはならない。

なぜなら、Windowsには標準でIEがインストールされているからだ。
先にも言ったように、ほぼ全てのPCにWindowsが入っている現状を考えれば
IEのシェアは確実に一定以下に落ち込むことは有り得ない。

だから、今も未来も結論は同じだ。
「自身がセキュリティに気を付ける事こそ、ウイルスから身を守る唯一の方法」
そう。こんな簡単なこと、誰でも判ってるよね。

--- 逆転 ---
さて、ここで現地メンバーの近況報告。
3人のうち一番劣っていると思われた彼が、今一番作業が進んでいる。

スキルの足りない彼が唯一メンバーの中で勝っていたのが「意欲」だった。
開発人にとって一番大事なのは知識でも才能でも無い。
それが「向上心」。これさえ持っていれば必ず力は身に付いてくる。

そう、ウサギは最後に必ずカメに負けるのさ。

非常に寒いのです。
冬はあんまり好きじゃないのだ。
すぐ眠くなるしね。

--- なぜか… ---
今日の現場での稼働率、約95％。
朝と昼にちょろっとWebでニュース見ただけで後はずーっと仕事。

なんでこんなにやる事があるのかって、原因は一つしかない。
どこぞの腐ったDBと格闘してるからだ。

--- 現場の決定 ---
プログラマにとって、わざわざ使いにくいものを使うというのは非常に耐え難い事なんだけど
DBってのは色々な問題があって、他のものに替えるという選択肢を取りにくい。
だから、現場がOracleを使うという決定をした以上僕もそれに従わなくてはいけない。

さらに今回骨を折る原因となっているのが、Oracle8iという4年程前のDBを使っているという事。
今まであまり意識した事は無かったけど、8iと9では出来る事に相当の差がある。

・JDBCのドライバが古い（ただし9のドライバもバグ多数あり）
・NCLOBがJDBCでサポートされていない
・共通SQL構文(INNER JOINなど)が使えない
・INSTR関数がLOBに対応していない

他にもまだまだあるが、特に厄介だったのがLOB問題。
VARCHARは4000byteしか入らないので、通常の自由入力欄の項目としては使えない。
精魂込めて入力したものがバッサリ切り捨てられたら、
ユーザは二度とそのシステムを使う気にならないだろう。

--- 回り道 ---
で、仕方なくLOB型を使うことになる訳だが。
前述したようにLOB型ではINSTR関数が使えない。つまり全文検索が出来ないのだ。
全文検索用のパッケージが別売されているらしいが、当然のように
ここの現場にそれを購入するような金は無い。

そこで達した結論は、ストアド・プロシージャを使うこと。
これで無理やり全文検索をするしか無い。
おかしな事に、SP内ではLOBへのINSTR関数が使えるので実装は比較的簡単だった。

が、ここでさらなる問題。
JDBC経由でNCLOBをうまく扱えない。
マニュアルを見るとサポート外だ、こんちくしょう。
仕方無くBLOBに変更。JDBCからはRAW型経由でパラメータを渡し、何とか成功したのだ。ふぅ。

--- 時間の無駄 ---
たかが日本語の全文検索をするだけなのに、丸1日以上費やしてしまった。
あぁ、この無駄な時間を一体どうしてくれるんだ。

普段だったらこれらの情報をWebで公開するところなんだけど
何せ対象DBが相当古いので、公開したところで誰の為にもならないだろう。
という訳で却下。
もし同じような問題にぶち当たっている人がいたら、掲示板ででも質問して下さい。

ようやく(？)事件発生ですよ、奥さん。

今日は朝から会議の予定。
で、また機能追加があるというので聞いてみるとどうもおかしい。
機能追加どころか、根底の作りが大幅に変わってるじゃないか。

しかもこのSE、それを何事も無かったかのように話そうとする。
確かに、画面上の見た目はほとんど変わらんよ。
でもな、その裏で動いているプログラムの事を何でお前はわかっちゃいないのさ。
これだから開発の出来ない人間と話すのは疲れるんだ。
あぁ使えんぜ。

--- 口実 ---
まぁそんな事をいつまでも気にしててもしょうがないので、
決断を下すことにする。
その画面を僕が担当することにした。
以前までの担当者じゃ、おそらく期限内に完成しないと思ったからね。

上の人の了承も得られたので一安心。
もっとも、ほとんどの部分は先週までに大体作っちゃったから
僕の作業自体は大して無いんだけど。

--- 発作のように… ---
なぜかここ最近、数ヶ月の周期で転職したい衝動に駆られる。
アホみたいな出来事があった後だからか？そうかもしれない。
前回はいざ面接のときにはもう既に冷めてて、結局面接すらしなかったんだけど。
今回はどうなるかな。