今年も無事始まりました。

年末は恒例、忘年会→ゲーム大会→初日の出という流れ。
今年はよく晴れてて綺麗な日の出が見れました。
で、そのまま朝の電車で自宅へ直行（笑）。
結局実家にも帰らず、年越しそばも食べず。
もう少しのんびり実家で過ごしても良かったかなぁ、とか思ってみたり。

--- いきなり受難 ---
どうもWindowsマシンのハードディスクの調子がおかしい。
前々からあんまり良くなかったんだけど。
壊れる前に新調してデータを移行しとくことにする。

という訳で、こんな新年から出掛けたくはないが仕方が無い。
幸い、さくらやのポイントがかなり溜まってるのでこれを使えば安く済む。
では、行ってきます（笑）

昨日は小6のクラス会がありました。
14年ぶりだってのに皆あまり変わってないね、特に男性陣は。
女性ではぱっと見わかんない人もいたけど。え？まじ？みたいな（笑）

そんなわけで今日はお休みです。
スーツ出勤だから、実家から直接現場に行けないんだよね。
まぁそうであっても行く気はさらさら無いですが（笑）

現場の電話番号がわからずに、あやうくまた無断欠勤になるところでした。
とりあえず営業の人に電話して事なきを得る。
明日からまた暇な日が続くと思うと少々うんざり。
また暇つぶしのネタ見つける事からスタートです・・・こんなんでいいのか？

久しぶりの現場です。
昨日はほとんど寝れなかった。実家で昼過ぎまで寝てたからなぁ。
そのせいで相当眠いのだ。

--- 「全体」を見渡せ ---
プロジェクトリーダー(以下PM)というのは、
プロジェクト全体を見渡す重要なポジションだ。
しかし、ここのPMはその意味を取り違えている。

全体を表面(うわべ)だけ見渡し、その細部を全く理解していない。
いわゆる「広く浅く」ってやつだ。そんな中途半端な仕事じゃPMは勤まらない。

このプロジェクトは以前から言っているように相当遅れている。
こうなる前に手を打つのが本来ならPMの役割だ。
しかし、それが全く出来ていない。
楽観的すぎるのか、それとも単に進行状況を把握してないだけか。

--- ブレイク中？ ---
最近やけに「日本ブレイク工業」の歌を耳にする。
確か初めに聞いたのはタモリ倶楽部だったような気がするが、
いつの間にかブレイクしてたらしい。

何やらまた使えん設計書が渡されてきた。
とりあえず渡された設計書を元にプログラムを組み始めるが、
案の定不足している情報が多すぎる。
こんな設計書、いっそ無い方がマシだね、マジで。

通常、基本設計を作ったらそれを詳細に落とすための工程が必要だ。
それは会議であったり、レビューであったり。
それがこの現場には無い。
ここの連中は、基本設計からいきなりアプリケーションが完成すると思ってるらしい。
こういう現実を見てないゴミSEはさっさとクビにして欲しいね。

--- 新年だから ---
ふぅ、今年になってからは結構やることが多い。
暇じゃないのはいいんだけど、動いてるのが僕一人だけだから
どうもやりがいが無い。

結局、僕が頑張って作ってもそれを動かせる環境が出来上がるのは相当先の話。
そして恐らくその頃には多数の仕様変更が入るだろうから
二度手間、三度手間になることもほぼ間違い無い。
あ?あ、やる気も失せるぜ。こんなんじゃぁ。

--- 乾燥中？ ---
なんか今日はすげー喉が渇く。
乾燥してるのか、それとも俺が風邪でもひいたか。
結構きついぜ。

--- 大移動中 ---
おっ、現場が突然席替えを始めたぞ。
新年早々ご苦労さまです。
とりあえず僕は移動させられなくて済みそうだ。

なんでも、以前登場したダメダメ君が原因のようだ。
リーダーの隣に置いてバシバシしごく目的だって。
当の本人は全く気付いていないようですが(笑)

Javaパフォーマンスチューニング・ニュース(日本語)の最新版が発行された。
他のどんな言語よりも、Javaという言語はチューニングが必要だ。

これは高級言語の宿命だろう。
複雑な処理を簡単な命令で済ませられるのは一見便利だが、
何も考えずに使っているといずれパフォーマンスの問題が出てくる。

例えばC言語の時代なら、同じ処理をするのに2つのプログラムがあった場合に
それらの実行速度の比は、まぁ大きくても10倍程度だろう。
しかし、Javaの場合はそれが100倍、1000倍になる可能性も現実としてある。
CPUやメモリの豊富な昨今、パフォーマンスを全く考慮しない人間が増えたのも原因か。

--- 最終到達点 ---
しかし僕はここで面白い記事を発見した。
「サーバは、CPU がボトルネックとして残るまでチューニングされるべきです。」

DBやネットワークというCPUより遥かに遅い媒体が存在するにも関わらず、
最終的にはやはりCPUがボトルネックとなる。
もちろんこれは(かなり高い)理想だが。
おそらくこの場合、そのシステムは全ての機器を能力の限界まで使っている。
もしネットワークにボトルネックが残っているならば、このときCPUはおそらく暇なはずだ。

--- 実行時の最適化 ---
同じ記事にあった
「コンパイラや VM をアップグレードしたら、
　6ヶ月前にやった最適化は今日はボトルネックになってしまうかもしれない。」
というのはJavaの特異性を表す。

Java仮想マシンの行う最適化が、
以前のプログラムで行っていた最適化を邪魔してしまう可能性があるという。
よく言われるのが「オブジェクト・プーリング」。
JavaのHotSpot(実行時最適化プログラム)は
プログラマが考えるより遥かに賢く働くというのがSunの主張だ。

この真偽を確かめるには、実際にシステムを動かすより他に方法は無いだろう。

新年始まったと思ったら3連休。
別に大したこともせずに終わってしまいました。

新宿に行ったら駅前でバンドが演奏してるのでしばらく聴く。
なかなか良い歌だとは思うんだけど、自分達のバンド名すら言わないのはどうかと。
まだ誰も知らないような無名バンドなんだから、
言葉に出さないと誰も覚えてくれないでしょ。
結局バンド名は判らないまま、駅前を後にしたのでした。

--- 女性プログラマー ---
先週の金曜日、営業の人に誘われて会社近くのカフェまで遊びにいった。
うちの会社に新しい(っていうか初)女性の技術者が入ったらしい。
とにかく女性の少ない業界なのでこういう事は大歓迎です。

よく、女性プログラマーには変わった人が多いって聞くけど
少なくとも僕が知ってる人はそうでも無い。
今度入った人も別に普通の感じの人だったし。

--- 今週は何とかなる？ ---
先週は、長期休暇後だけあってそれなりに仕事があった。
とりあえずこれを続けていけば今週もまぁ何とか暇では無さそうな予感。
…いや、予感というよりはあくまで希望だけど(笑)。

現在、次の暇つぶしネタを模索中。
以前にも少し手を出したMidlet(携帯用Javaアプリ)が最有力候補かな。
これなら仕事での需要も少なからずありそうだし。

--- 選択ミス？ ---
…と思ったら、何と僕がこの前買った携帯ではJavaアプリは使えないらしい。
そういう事は買うときに教えてくれよな?、一応Vodafoneショップで買ったんだし。
お目あての機種が無かったから一つ前の機種を買ったんだけど、
その違いについて聞いたときには「ほとんど同じですよ?」と適当な答え。

嘘付け、画素数だって全然違うじゃねーか。
QVGA(240x320)液晶の事聞いてもあまり知らない様子なのでそれ以上の詮索はしなかったけど。
という訳で、Vodafoneショップ高田馬場店の店員様方。
僕が次に携帯買うまでにはもう少し勉強しといて下さい(泣)。

またですか…
今回のプロジェクトで使用するWindowsサービス。
某H社が作ったらしいが、サービス停止→起動すらうまくいかない。
マシン再起動しろ？全く腐ってるぜ。そのマシンはクライアントマシンじゃ無いんだぜ。

--- じゃ消しといて ---
H社の作った酷いソースの解読を進める。
どうもこのソースはJavaのように見えるがC#で作られたものらしい。
そのせいか知らんが、メチャクチャな作りになってるのは困る。

複数のクラスを一つのファイルにまとめてるのは見にくいし、
publicやprivateの識別子がほとんど使われていない。
全てデフォルトのパッケージprivateで済まそうとしている。
これは非常に良くない事なのだ。
変数名にも平気で大文字が使われてるし、とにかくグチャグチャだ。

さらに、コメントに「★これ使われてませんよ？」とか入ってる。
じゃお前が消しとけよ。っていうか、★とか使うな(笑)。

--- 崩壊の前兆 ---
どうしてこいつらはこんなに学習能力が無いんだ。
今回、ある機能を入れるためにデータベースのテーブルを一つ追加することになった。
そのとき、彼らの取った行動は以下の通りだ。

1. SEがデータベースのテーブル定義書を作り、それをチームに通達する
2. 定義書を元に実際にテーブルを作成する
3. PGがレコードを入れてサンプルプログラムを作成して動作を確認する

--- 問題発生 ---
さぁ、ここで当然不具合が発生しました。
この仕様では、この機能を満たすことが出来ません。
いくつか解決策はありますが、一番良い方法はテーブル定義を修正することです。
しかし、面倒くさいのでこのSEはそれをやりたくありません。
たかだかテーブル定義書を作成だけですが、彼にはかなりの工数を要する仕事なのでしょう。

そして、次に彼の取る行動はどんなものでしょうか。
4. テーブル定義は修正せずに、強引にプログラム内で解決させようとする
ほとんどのSEがこの選択肢を選びます。
もちろん、PGが僕である以上そんな事はさせませんが。

今回はそうではありませんが、
もしSEとPGが別会社だったとしたらこの問題はさらに厄介になります。
この場合、一度決めたテーブル定義を修正する事が簡単には許されないからです。

--- 順番が逆 ---
なぜこんな事が起きたのでしょうか。
それは、取るべき行動の順序を間違えているからです。
上の例で言えば、手順3.の後に手順1.を持ってくれば
何も問題は起こらなかったはずです。

問題が発生した時点でテーブル定義を即座に修正し、
うまく動くことが確認できたら各メンバーにそれを通達すれば良いのです。

--- 理想形 ---
今回の場合、理想の行動はどんなものでしょうか。
僕が考えるのは以下のようなものです。

1. 依頼主から、機能追加の詳細を正確に聞き取る
2. その機能を果たす為に必要な各仕様(テーブル定義、プログラム構成)を考える
3. 必要ならば、この段階で依頼主に作業工数を報告する
4. この仕様を元にプログラムを作成し、正常に動くことを確認する
4a. 正常に動作しなければ、仕様を見直して仕様／プログラムを修正する
5. 正常に動作したら、依頼主に作業完了を報告する

この中で一番時間が掛かる部分は、当然4(4a).の部分です。
一般的に考えて、2.の三倍以上は時間が掛かるはずです。
その他の部分は工数に数えるほどの時間は発生しません。

作業分担としては、1.はプロジェクトリーダーもしくはチームリーダーの役目でしょう。
2?4は、プログラマの役目です。
しかし、ほとんどの現場では2.の部分をSEと呼ばれる人物がやろうとします。

さらに、1.が不完全なままその先に進みます。
つまり、正確な仕様を理解しないまま開発に取りかかってしまうのです。
そのため、4aの部分で必ずと言っていいほど正常に動作しません。
ここから、冗談ではなく本当に1.まで戻ってやり直すのです。

--- 続々と。 ---
ホントにこのプロジェクトは続々と新機能が追加される。
というより、こっちの人間が正確な仕様を把握してないからなんだけど。

そんな事だから、元々依頼されてた機能なのか
後から向こうが新機能を追加したのかさえ判らないというとんでも無い状況だ。
これじゃ向こうの言いなりだね。

僕はWindowsではMeadowというエディタを使っているんだけど、
これが何故かよく落ちる。
具体的には、他のアプリから外部呼び出しをするタイミングで。

これはとっても困るんだけど、これ以上に使いやすいエディタが見当たらないので
しょうがない。頻繁に起こることでは無いしね。

--- NFL週間 ---
先週からNFLのプレーオフが始まった。
今年は去年にも増してスゲー試合が多いぞ。
特に一昨日放送のパンサーズvsラムズ。
早くも「今年のベストゲーム」に決定しそうな勢いだ(笑)。
そのうちゲームレポのコーナーでも作ろうか。

--- 俺のセリフ ---
某SEがいつものように悩んでいる。
「それやりたくないな?」とか言ってるが、
お前がやる訳じゃないんだからそんなに気にしてどうする(笑)。
そういうのは作成者である俺のセリフだ。

--- 残念ですが… ---
このプロジェクトの営業担当責任者が何やら話している。
「ここ勝負なんだから頑張ってよ」
いよいよ来月の1日に初の仮リリースがあるらしい。

僕がこの現場に来たのが去年の9月。
5ヶ月も経って満を持してのリリースだと思われるかも知れませんが、
全50強コンテンツの内まだ4つしか出来てません(笑)。
しかもほとんどが未完成。
この調子だと全部完成するのは10年後ぐらいになりそうです。

残念ですが、この勝負は戦う前から勝敗が決していたことを
いつか彼に教えてあげる必要があるかもしれません。
開発のノウハウがまるで無いこんなメンバーに任せたのが間違いだったのです。

--- 何故か焦る奴ら ---
昨日あれほど忠告しといたのに、まだこいつらは物事の順序をわかっていない。
まぁ実際には日記に書いただけだから彼らは知る由も無いわけですが。

今回の機能を作成するにあたって、なぜ最初にDBを作る必要があるのか。
まずDBを使わずにプログラムを組んで、そこから最適なDB設計が完成する。
最初からDBを作成したってそれがベストな設計になることなど有り得ないのに、
こいつらはそれをわかっていない。
これだからプログラムを組めない人間と話をするのは嫌なのだ。

--- 予想と反して… ---
先週とうって変わって、今日はメチャメチャ暇なのです。
しかも後ろで会議やってるからMidlet開発もできない。
その割には日記書いてますが(笑)。
文章書いてるだけならほぼバレないけど、
Midlet開発は携帯エミュレータ画面を出さなくちゃいけないから厳しいのだ。

そうそう、もうすぐこのプロジェクトに新しい人材が入るらしい。
そんな事しても無駄なのにまぁ頑張るねぇ。金無いとか言ってる割に。
僕がこんなに暇してる事を上の人間は知らないようだ。
といっても、僕がそれを言ったところで何も変わらないのは百も承知なので
そんな意味の無いことはしないけど。

結局、そのプロジェクトの成果なんてものは
プロジェクトがスタートした段階で8割方決まってしまうんだ。
後でどう足掻こうと大して変わるもんじゃない。
プロジェクトを成功させる努力をするよりも、自分の趣味に時間を投じる方がよっぽど有益だよね。
まぁ僕の場合はそれが仕事にも直結するから一石二鳥って訳だ。

--- 真冬 ---
いよいよ来ましたな。凍えるような寒い日々。
週間予報見たら、最高気温が10℃切る日が続くらしい。
ちなみに僕は、チカちゃん派です(笑)。
時間がちょうどいいっていう理由だけかもしれないけど。

暇そうにしていると、隣のオッサンが作業の依頼をしてきた。
今やってるプロジェクトと並行で動いてる関連プロジェクトの話らしい。
ず?っと前に作ったSVGライブラリは、実はここで使うものだったようだ。

まぁ別にそれはいいのだが、依頼内容がとにかくアバウト過ぎる。
納期も言わなければ作成するコンテンツの全容も見えていない。
使用するデータベースがまだ作成されていないので、
開発を進めるにあたってこの問題もどうにかしないといけない。
テストデータを作るのか、一体それは誰の作業なのか。

ありとあらゆる所が何一つ決まっていない。
僕はこういう依頼では極力作業しないようにしている。
後々作業の大部分が無駄になってしまう事が多いからだ。

とりあえずそこら辺をきちっと提示するように頼む。
今回の件でもわかるように、こういう類の人間は明らかに自分でプログラムを組んだことが無い。
それなのに、ここの部長は「あのプロジェクトは彼が作ったから」などと言う。
違うぜ、こいつが果たした役割なんてほんの数パーセントしか無いんだ。
そんな人間を高く評価するような部長を、もちろん俺も信頼するつもりは無い。
例え高額で個人契約を求めてきたとしてもだ。

--- 完璧な動き ---
それにしても、僕が最近行き始めた弁当屋の対応は凄い。
アジア系の女の子が3人くらいでレジ周りをやってるんだけど、
息をも付かせぬ勢いで作業をこなしていく。

注文を聞く、レジを打つ、会計を済ます、弁当を渡す。
この動作中にも前後の客をバンバンと片付けていく。
それはそれは見事な光景なのだ。
おそらく、1人の客に対して30秒を軽く切る位の速さで売りさばいていく(マジです)。
これぞ職人技といったところか。

さて、今日から現場に一人増えました。
こんな時はもちろん彼の出番です。
親切にプロジェクトの説明などを延々としているぞ。

まぁそんな訳だから、今はMIDletの開発に精を出すことにする。
ようやく開発／デバッグの環境が整ったので、スムーズに開発を進めることが出来そうだ。
ただ、作りたいものは特に無いんだけど。

--- 日記ページ仕様追加 ---
日記ページにカウンタを付けられるようにしました。
とりあえずデフォルトではOFFになってるから、表示させたい人は
カスタマイズ画面で行って下さい。

アジア女子バスケットボール準決勝。
日本vs韓国。勝った方がアテネへの切符を手にする、大事な一戦だ。

韓国はこの試合に全てを賭けていた。
前の試合でも主力を温存し、「お得意様」である日本戦で確実に勝てると考えていた。
対する日本は前日、台湾と延長戦の末に敗れている。
試合後談だが、選手達も「正直韓国に勝てるとは思っていなかった」と話した。
ここで負けても3位決定戦に勝てばアテネへの切符を手にすることが出来るからだ。

でも、今日の日本は強かった。
どちらも高いディフェンス力を持つチームで、点の入らない試合展開。
56-56のまま、試合は延長戦に突入した。

--- 守備の重要性 ---
これで日本は2日続けての延長戦。スタミナが心配だ。
しかし、守備の良いチームはこういう展開にも強い。
延長に入ってから全くといっていいほど韓国の攻撃が決まらなくなってきた。

そこで、韓国は「ディフェンスから攻めてくる」作戦を取ってきた。
日本の攻撃中に激しい守備でボールを奪い、そのまま速攻で点を稼ぐ。
これにやられた日本はリードする展開を追いつかれ、試合は再延長戦にもつれ込んだ。

--- 冷静な判断力 ---
日本はこの守備に冷静に対応する。
相手がディフェンスで攻めてくるのだから当然その事によるリスクもある。
確実にボールを回して、韓国のディフェンスを振り切っていく。
やはり相手は疲れてきた。その隙をついて日本が立て続けにシュートを決めた。

残り1分を切った。ここで、とどめとなる3ポイントを日本が決める。
これで9点差。この劣勢をはね退けるだけのスタミナと精神力は、もう韓国には残っていなかった…

--- 感動の激戦 ---
とにかく今日の試合は凄かった。
日本がアテネへの切符を手に入れた。
選手も皆、泣いている。ついでに解説の原田裕花さんも(笑)。

そして僕も感動した。先日のNFLプレーオフも感動したけど、
やっぱり日の丸が付いた試合はそれ以上に特別な思いが込み上げてくる。
明日は最強中国との決勝戦。
今日の試合を見ていたら、アジアチャンピオンになる可能性だって無いわけじゃない。

それに加えて明日はNFLプレーオフがノーカット(約3時間半)で2試合。
一番つらいのは、会社を休めないところです(笑)。

今日は、某協会(今作ってるシステムの依頼元)へ行ってきました。
基本設計の打ち合わせ、今までは他のメンバーだけで行ってたんだけど
いよいよ人手が足りなくなって僕らまで駆り出されたという訳。

まぁ予想してた事だけど、とにかく打ち合わせの進行が遅い。
こんなトロトロやってたらそりゃ何時まで経っても終らんぜ。
ちなみに今週は丸一週間、この会議が続くらしい。
一日中ではなく午後からだというのがまだ救いか。
今日は5時半終了の予定だったのに結局終わったのは7時過ぎ。
ふぅ、疲れました。

--- 笑っちゃいます ---
いやぁ、それにしても彼らは凄いスケジュールを組んだもんだね。
まだ8つのコンテンツも完成してしないのに、
6月1日までに30コンテンツを作って外部リリースを行うんだって。
これだけ現実を見えてない人達の頭はもうどうかしちゃってるんだろう。

まぁ僕はそこまでは居ないから判らないけど、
3月末にも15程のコンテンツを作って内部リリースがあるらしいから
その結果がどうなるかはお伝えできそうです。

さて、今日も行って参りました。
3時間半ほど打ち合わせして、決まった事はごくわずか。
こんな密度の薄い会議に何で4人も出向わなきゃあかんの。
また明後日から2連チャンであるらしいけど、もう行くのは止めよう。
時間の無駄です。

--- 今度は順調に？ ---
今の現場、僕の契約は3月末まで。
過去の例だと、大抵の場合は延長とかあってそれを振り切るのに面倒だったけど
今回はすんなりと辞められそうだ。

なぜなら今日プロジェクトリーダーが、後続を探してる雰囲気を俺はキャッチしたからだ(探偵風)。
僕に何を言っても留まらない事は向こうも承知しているのだろう。
何にせよ、最近すんなりと現場の移行ができない事が多いので(ほとんどは俺の責任だけど)
今回くらいは何事も起こさず去りたいものです…

こんな記事を読む。
「携帯電話等に着信する迷惑メールに対する自衛策について」
まぁ内容は題名の通りなんですが。
総務省が出したというこの記事、いかにもお役所的な発想で笑ってしまう。

たとえこの記事を日本全国の人間が読んだとしても、
この自衛策を実行できるのはその中の1％にも満たないだろう。
理想論だけじゃ、何も状況は変わらない。
こういうのを発表しただけで満足してるような人達には何を言っても無駄でしょうが。

--- OFF ---
今日はチームメンバーが二人しかいません。
というわけで、現場には来ましたがOFFの日ということに決定(笑)。
Java News という日本語のJavaニュースサイトが出来たようだ。
今日はここでネタを探すとしよう。

fastutil というライブラリを使ってみる。
これはJavaのコレクションを改良したもので、
プリミティブ型(intなど)の格納等が行える。
fastutilというだけあって、速さはJava標準のものよりそれなりに速いようだ。

ただ、数万以上の要素を扱わない限りは必要ないかもしれない。
ライブラリのサイズも9Mb程とやや大きい。
Cのコンパイル環境も必要。一応Windows+Cygwinでもコンパイルできた。
おそらく使う機会は今のところ無いけどね。

--- Eclipse3 ---
まだ正式リリース版じゃないので何とも言えないけど、
Eclipse3は明らかに遅いような気がする。よく固まるしね。
以前はベータ版でもこんな事は無かったはず。ちょっと心配である…

--- 数字遊び ---
近くでプロジェクトの見積り作業をやっている。
コンテンツの数×比例係数だけで見積りを出しているらしい。
そんなんでマトモな数字出るわきゃねーだろ。

素人が見積りを出すと、もはやそれは単なる数字遊びに過ぎないという訳だ。
しかも、大抵の場合は予算ってものがあるから
それに合わせて無理矢理比例係数を決めてたりする。何という都合の良さ。
君らには「Superご都合主義者」の称号を与えてあげよう。
さらに上のHyper…になれるように精進して下さい。

--- 充実したOFF？ ---
なぜか今日はやる事が結構ある。
残念ながら仕事では無いですが(笑)。

自作のプラグインを修正中。
RDというドキュメントフォーマットを自分が使いやすいようにして
Javaで書いたものがメイン。あまりにしょぼいんで外部公開はしませんが。
昔から汎用的なものを趣味で作るのって苦手なのだ。
自分が使いやすいようにやってると、
とても一般に公開できるような仕様では無くなってしまう。
「これ使わないから作らなくていいや」とかね(笑)。

もちろん仕事だったらその辺はキッチリやるけど。
趣味と仕事でやる内容は一緒だけど、こだわりは全然違うのだ。

今までIBMが開発を支援していたEclipseプロジェクト。
これが遂に完全な非営利組織へ移行するらしい。
まぁそれで何が変わるという訳では無いと思うが、
Eclipseにとって企業→非営利組織という移行はマイナスにはならないはずだ。

--- 風邪 ---
どうも体調が悪い。
昨日も午前中だけ出て早退してきました。
午後から協会との打ち合わせがあったのは、当然まったくの偶然です(笑)。
今日中に治して週末は完調で過ごしたいなぁ。

オープンプロジェクト万歳！
って感じですな。
EJB Web Application Server のJBossとデータベースのMySQL。
両者が手を組むことが決まったようだ。

もともとEJBっていうのはデータベースに依存しないものなんだけど
パフォーマンスを上げる為にはデータベースベンダー側の対応が必須になってくる。
JBossで最大限の能力を発揮する為にMySQLはチューニングされるはずだ。

--- 暖房器具 ---
やっぱりこの部屋は寒い。
エアコンのみの暖房じゃ厳しいね。
という訳で、暖房器具の購入を検討中。

石油は使えないので、ガスファンヒーターかハロゲンヒーターが候補。
手軽さで言えば後者なんだけど、どれだけ暖まるのかが心配。
でも個人的に風が発生しないのは凄く嬉しいんだよね。

--- ウイルス ---
現場のおっちゃん(部長)がウイルスメールがどうのと騒いでいる。
Yahooで見たけど流行ってるらしいね。
こいつ確か技術上がりとか自分で言ってたけど、完全に「エセ技術者」だね。
「メール恐くて開けんよ」とか言ってる。
ホントに技術者だったらそれくらい恐くも何とも無いだろ。

--- 謎の閲覧者？ ---
なんだか昨日から急激にトップのアクセス数が上がっている。
別に何もした覚えは無いんだけどな?って思っていたけど、その謎が解けた。

一昨日の夜に、Programページの移動をしたんだ。
で、検索とかで引っかかってきた人がアクセスしてくると
当然エラー画面になる。
そのページにトップへのリンクが張ってあるから、アクセス数が増えたという事らしい。

つまり、トップページには来ない隠れ閲覧者が数多くいるって事だ。
とはいっても、その大部分が検索で来る人達だから
リピーターにはなりにくいのも事実。
結局、長い目で見れば毎日来てくれる人の数だけがアクセス数に直結するのかな。

今週は何だか忙しい。
それというのも、僕が本格的に開発に参戦する事になったからだ。

今までは開発は全てベトナムに任せていた。
向こうから技術的な質問が来ればそれに答えるだけという、まぁよくあるパターンだ。
が、それだけでは開発が追い付かない事が判ってきた。

やはり国を跨いでの開発というのはどう足掻いても大幅なロスが発生する。
それでとうとう日本でも開発を進めようという話だ。
とはいっても今のところ僕一人だけですが(笑)。

--- 構成改革 ---
まずはアプリケーション構成を見直す。
もともとこのアプリは某H社(の下請けN)が作ったものでひどく質が悪い。
本来、分散可能なアプリケーションという目的があってEJBを使っているのだが
その使い方がまぁ酷い有様。
僕自身もまだEJB開発は初心者なんだけど、それにしても無駄な作りが多すぎる。

とりあえず、僕はどんな場面においても初めにやる事はただ一つだ。
それは開発(デバッグ)環境を整える事。
これを最初にやっておかないと、その後の作業の進み具合がまるで違ってくる。

--- 人数×レベル = 工数？ ---
そういう事をきちっとできる人間は少ないので
ほとんどの現場では必要以上に無駄な時間を費やしている。
だから工数なんてのはアテにならない。
そこにいる技術者のレベルを考慮しないと正確な工数は出ないからだ。

大抵の場合、工数を求めるのに技術者のレベルは考慮されない。
最も一般的な技術者のレベルに合わせて工数を出す。
そしてそれは多くの場合、働く技術者のレベルが低すぎて正確な工数にはならないのだ。

--- EJB苦難 ---
EJB開発を始めると、いつも同じところでつまづく。
それがJNDIだ。

JNDIでは、複数あるEJBコンポーネント(部品)を識別子により区別・判断する。
各々のEJBにはEJB名というのがあって、それに対応するJNDI名も定められている。
アプリ側では、JNDI名をパラメータとして渡せばそれに対応するEJBコンポーネントが得られるという仕組み。
一見簡単そうだが、外部参照・ローカル参照という区別があるのが厄介の素。
ローカル参照だとJNDI名のprefixに「java:comp/env/」が付いたりするらしいが
今いちそこら辺の構造が理解できない。

もう少し経験を積む必要があるね、これは。
でもここで苦労しておけば、EJBの基盤を理解できる。
そうなってしまえばもう後は楽になるはずだ。
そして、EJBが今後最も需要が高くなる規格であることは間違い無い。

--- 一息入れて… ---
自宅サーバを取り入れてから早1年半。
主な利用目的はやはりWebコンテンツだ。
昔は音楽主体のページだったけど、最近は専らプログラムの事が中心になってきたね。
まぁ一応仕事でもある訳だし、当然といえば当然か。

で、いきなりですが。
「第1回検索文字列検証」を始めたいと思います。
ええ、唐突ですいません(笑)。

--- 2002年 ---
検索文字列とは、google等の検索エンジンからどんな単語でこのページに飛んできたかを示すもの。
Webサーバならば「referer」というヘッダを見ればそれが判る。
まずは2002年。

トップは不動の「eclipse」。
次いで「cvs」「eruby」等。上の方がほとんどがプログラマ関係だね。
ちょっと下を見ると、「pli:z」「黒夢」「斎藤和義」等のミュージシャンが続く。
意外なのが「宮本英治」。僕自身、彼の歌は数曲しか聞いたことが無いんだけどね。
インパクトのある歌が多かった気がする。

--- 2003年 ---
相変らずEclipseがトップ。
そしてJava関連の言葉も多い。

そして9月。Eclipseを超えTomcatがトップに。server.xmlが第2位。
やはりWebアプリは時代の中心になってきたようだ。
Eclipseは大御所のサイトが出来たせいか減少の方向へ。

11月。5位にランクしたのは「ボボボボボーボボ」。何故？(笑)
確かキリ番の部屋に某N氏が書いた一言だけなのに、ここまで順位を上げるとは。
最近じゃテレビでもやってる有名なアニメらしいね。

最後は今月。まだ終わってないけど。
去年の終わりに作ったばかりのページから「携帯サイト」が第6位に。
やっぱり需要は高いのか。

--- 総括 ---
まぁこんなところです。
これを見る限り、検索サイトの力は大きいという事を改めて実感した。
あんまり面白い単語は無かったなぁ、期待してたのに。
というわけで、また来年にでもこういう企画やりますんで。お楽しみに。

またまた僕の中で初の快挙。
祝、「1週間(5日)全て残業」記念です。
「それくらい普通だよ」という突っ込みは当然のように却下です(笑)。
僕にとっては記念すべき事なんだから。

やっぱり僕は開発をしてる方が性に合っている。
あっという間に時間が過ぎて、一日が何の苦痛も無く終わるからね。
今週はとりあえず現存ソースの調査と、新しいファイル構成の模索を中心に。

--- 残業の内容 ---
前にも言ったように、このプロジェクトはコンテンツ量が半端じゃない。
最終的には60を超えるような大規模なものになる。
それなのに、以前までの構成はそれらを全てまとめた形でしか扱えない。
一応コンテンツ毎にjarファイルは分かれているのだが、
結局それらをearファイル(J2EE用のjarファイル)にまとめてdeploy(配置)する形を取らないといけなかった。

こんなんじゃ、今はまだいいけど今後つらくなるのは目に見えている。
僕がいる3月末までにも後20コンテンツ位増える予定だからね(マジです)。
というわけで、コンテンツ毎にdeployできる仕組みに修正。
これが完成したらベトナムに送らなきゃいけない。

--- 外部の原因 ---
それと並行してやっていたのが、現存のパフォーマンス調査。
以前から遅い遅いと評判だったので調べてみることにした。
簡単なテストコンテンツを作り表示させてみる。

結果、時間が掛かっているのは外部が要因だということが判明した。
いくつかのコンテンツでは、地図を表示するのに専用のサーバを使っている。
この地図サーバが遅い。これが外部が作ったものだから修正する事は難しい。
目標として1アクション3秒という方針があるのだが、この地図サーバに2.5秒も取られている。
これじゃ目標達成は不可能だ。Webサーバ側を0.5秒以内に終わらせなきゃいけないんだから。

--- 詰めの甘さ ---
こんな事は、外部のサーバを使うって決めた時点で判ってたはずなんだ。
それを今になってどうしろというのもおかしな話。
他にもこんな事が山ほどある。
設計者というのは、こういう部分をきちっと詰めていかないといけない筈なのに
それが全くといい程されていない。

だから僕は彼らSEを「使えない人物」だと言っているのだ。
本物のSEならそれ位やれて当然だろう。

--- ほぼ大丈夫？ ---
この前、この現場にいる部長から呼ばれる。
てっきり契約延長の話だと思って緊張してたんだけど、どうもそうでは無いらしい。
以前、僕の会社と現場の会社の間に入っている「コバンザメ人間」と
少しトラブルがあったのを心配していたようだ。

このコバンザメ君がいたから、僕も今の現場に紹介された訳だから
邪険に扱うことは良くないかもしれないんだけど、とにかくこいつが俺と合わない。
しかも直で俺の携帯に掛けてきたりするから困っていたのだ。
今はそういう事はなくなったけど。

部長はあと2ヶ月の間、僕が突然辞めるんじゃないかと心配していたようだ。
なかなか鋭いな、こいつ(笑)。まぁ別に僕はやる仕事さえあれば急に辞めるような事はない。
今後はスケジュールも詰まってるし、そんな心配はなさそうなので
とりあえず大丈夫ですと言っておいた。

逆に言えば、これで僕が3月末で辞められる事はほぼ確定したといってもいい。
4月からは、また今の会社で仕事を探してもらう事にしようと思う。
とりあえず今回の場所はまぁまぁ良かったからね。
一回でも酷い場所で働かされたら、その時また考えることにしよう。