カテゴリ別表示

全体

最近の日記

仕事納め
12月らしく
年末
忘年会2
休み

最近のレス

なおき (12/9)
やす (12/9)
なおき (12/3)
しろへび (12/3)
なおき (11/25)

日記アーカイブ

2008年
1 2 3 4 5 6 9 10 11 12
2007年
1 2 3 4 5 6 7 8 9 10 11 12
2006年
1 2 3 4 5 6 7 8 9 10 11 12
2005年
1 2 3 4 5 6 7 8 9 10 11 12
2004年
1 2 3 4 5 6 7 8 9 10 11 12
2003年
1 2 3 4 5 6 7 8 9 10 11 12
2002年
1 2 3 4 5 6 7 8 9 10 11 12
2001年
1 2 3 4 5 6 7 8 9 10 11 12
2000年
4 5 6 7 8 9 10 11 12

管理人
naoki   [HP]
RSS FEED
149881
2002年7月の日記

2002/07/01(月)
無題
--- 朝礼 ---
今日は朝から朝礼のため9時出社。
間に合うように家出たのに、山手線が止まる・・・ついてないぜ。
で、15分くらいに着いたけど朝礼はまだ始まってなかった。
なんだ、急ぐ必要なかった・・・
いや、西武線を各駅で乗ってる時点で急いでないのがバレバレだな(笑)。

--- 帰還 ---
先週末からずっと休んでいた某設計者が今日は来ているようだ。
逃避行から無事帰還ってところか?いや、ホントに風邪だったのかもしれないけど。
今週はバリバリ仕事してほしいね。

--- W杯終了 ---
ブラジルvsドイツの決勝戦。やっぱりブラジルは強かったね。
勝負の分かれ目はブラジルの1点目。
ドイツDFが「取られてはいけない」場所でインターセプトをくらって
速攻でゴールへつなげられた。

DFを一人下げたドイツが2点目を取られたのは仕方が無い気がする。
それだけのリスクをおかして交代したんだからね。

--- 着メロ ---
ここの現場でも携帯の着メロが鳴り響いている。
ホント、耳障りだぜ。仕事場での使用禁止希望願申請中(嘘)。

--- Simple is best!? ---
初心者のプログラマに共通して言える事がある。
「プログラムが複雑」なのだ。

異なる人が全く同じことをやろうとした場合、
作ったプログラムが全く同じになることなど有り得ない。
いや、もし有り得たとしたらそれはカンニングしてるということだ(笑)

それだけじゃない。プログラムの大きさそのものすら
作る人によって大きく変わってくるのだ。
僕の経験上、初心者であればあるほどプログラムは冗長になりがちだ。

長年プログラムを組んでいくうちに良いプログラムが書けるようになる。
「良い」という基準は一概に言うことはできないが、
より読みやすく、シンプルになっていくのが理想だと思う。

冗長なコードはメンテナンスが困難になる。
高速化を図る上で多少の複雑さが出てくることは仕方のないことだけど
それ以前の問題があるプログラムが多い。

シンプル イズ ベスト。これが僕の考え方だ。

--- 大苦戦 ---
おなじみ「ピンチの人」、未だピンチが続いてます(笑)。
先週、SEの人と仕様理解を深めてたらしいから安心してたんだけど、
今日ソースを見てみたらどうもまだ間違ってるっぽい。
前項の話題通り、彼のソースはかなり読みにくいんで大変だった。

で聞いてみたら、やはり仕様を完全には理解していなかったらしい。
懇切丁寧に説明してるのに、なかなか理解してくれなくて困ったぜ。

--- 1週間遅れ ---
本当なら今週から結合テストに入ってるはずなのに、
いまだ単体テストすら終わってる人物が僕以外にいない。
どうやらスケジュールは1週間近く遅れそうだ。

2002/07/02(火)
無題
--- 新メンバー加入 ---
といっても別にマリナーズの話ではない(笑)。
うちのプロジェクトのことだ。

どうやら、ある作業が思った以上に時間が掛かるらしく
新メンバー2人を含めた計7人でそれに取り掛かることになった。
で、みてみたら確かに面倒。
こんなのを1人週間でスケジュール組んだ奴は誰だ?・・・そう、奴だ(笑)。

以前から「適当な工数計算」を得意分野にしていた彼がまたやってくれた。
そして今日割り当てられた作業にもまたまた無理がある。
今日入れて2日で完成するとかほざいて・・・コホン。おっしゃって(笑)いるが、
100%不可能だぞ。

そろそろ真のリーダーに話振っといたほうがいいかもしれない。
このままじゃ今月中に終わらすなんて非現実的だからね。

--- 遅っ!! ---
このパラグラフでも主役は再び彼です(笑)。
今日割り振られたプログラムを作成中、どうもDBアクセスが遅いのに気が付いた。
で、計ってみてびっくり。
カラム数20、レコード数400程度のテーブルから全件抽出しただけで
280秒も掛かることが判明した。
どう考えても遅すぎるぞ。

試しに自分で作ったモジュールでやってみると
0.25秒ほどで終わる。これくらいが普通だよね。
しかし、どうやったら1000倍も遅くできるのか不思議だ。
確かにソース見たとき「無駄なことたくさんしてるなぁ」とは思ってたけど
まさかここまで遅いとは。

で、メンバー全員にこのことをメールで報告。
その中でチラッと「モジュール改造した方がいい」と言っておいたにも関わらず彼からは
ノー・リアクション・・・困ったもんだ。
彼はおそらく今週で抜けるから、もう逃げに入ったと見た。
メンバー内には追い込み馬もいないし、このまま逃げ切り成功か(笑)!?


2002/07/03(水)
無題
--- 多忙 ---
ふぅ。今僕は超多忙な毎日を過ごしている。
・・・いや、嘘です(笑)。
ただ、今までよりは間違いなく忙しい日であることは確か。

そして「毎日」といっても実際にはたった2日だってことは内緒だ(言ってる)。
さらに言えばちゃんと定時に帰ってることなどは極秘情報だ(笑)。

--- テスト ---
どうやらサブリーダーの考えでは明日から結合テストを始めるようだ。
が、「ピンチの人」は未だ単体テストすら行っていないらしい。
そんな状況で「明日の午前中までには単体テストまで終わらせてね」
というリーダーの発言はあまりにも無謀、いや、無知というべきか。

普通、プログラムを組むときには少しずつ作りながら進めていく。
つまり、ある程度の機能を追加したらそれが動くかどうか確認してから先に進むのだ。
そうしないと、もし問題が起きたときに非常にまずいことになる。
それはもしかしたら、プログラムの作りを根本から見直す必要が
出てくるかもしれないからだ。

--- ほぼ完成!? ---
で、彼は「ほぼ完成」というところまでプログラムを組んでいるのに
まだ一度も動かしていないというのだ。
「とりあえずコンパイルは通りました」って・・・それくらい当然だろ。

「コンパイルが通った」ってレベルと「プログラムが動いた」ってレベルは
相当の格差があるってことを知らないみたいね。
もちろん、ちゃんとした構想を立ててプログラム組んでれば
その差もかなり縮まってはくるけど。

サブリーダーが「コンパイル通れば80%完成とみていいから」
とか相変わらず適当な発言をするから、彼もそれを鵜呑みにしたのかも。
とりあえず、まあまあ出来る人がサポートに付くらしいから
明日中には単体テストまで終わるのかな?・・・終わるといいなぁ(笑)。

--- ちょっと一休み ---
昨日今日と一生懸命仕事してきたから、
明日はちょっとゆっくりする計画を立ててみた。
僕の担当してる部分は今日で8割方できたんだけど、それを5割程度ということにして
明日いっぱいで完成させればいいことになった。

おそらく明日はテストの準備やらで上の方は大忙しだろうから
僕はまた「ドタバタコメディー」見て楽しむとしよう(笑)。

2002/07/04(木)
無題
--- 予想通り・・・ ---
今日からテストが始まるとか言ってたのに
現場では何の音沙汰もない。
まぁ現実的に無理なスケジュールだってことは解ってたけど。
全く動いてる気配さえ無いのは感心するな(笑)。

僕のほうは、暇になるはずだった予定が少し狂う。
単体テストしてみたところ、他の人が作ったクラスを呼び出してる部分でエラー。
仕方がないのでそっちのデバック作業までする羽目に。

おまけに昨日まで作ってきた部分の仕様が大幅に変わったらしく
かなりの部分を作り直さなきゃいけないことも判明。
こんなんじゃ今週中に結合テストすら始められない・・・
よく考えたら今日はもう木曜。あと1日じゃどう頑張っても不可能だな。

--- 新メンバーその後 ---
一昨日から入った新メンバーも、手伝ってくれるのは今週いっぱいらしい。
そんなんだったら初めから入れない方が良かったんじゃ・・・
今週中に作業が終わらなければ、来週以降は残りのメンバーで
プログラム引き継がないといけないんだから。

人数使えばいいってもんじゃないのはどの専門職でも一緒だと思う。
人が増えることで全体としての効率が落ちる可能性は充分にあるってことだ。

--- 暑。 ---
今日は猛烈に暑かったね。
スーツ着ないでワイシャツで通勤して正解だったよ。
これから毎日こんな気候が続くのか?シャレにならんぜ・・・

2002/07/08(月)
無題
--- 再び帰郷 ---
先週末はまた地元に帰ってました。
相変わらずやったことと言えば友達と飲んでただけだけど。
一応、友達の就職内定祝いってことで。
それにしても僕の友達には優秀な人が多いなぁ。
S社にS社・・・これだけじゃわからんか(笑)。

--- 朝から ---
今日は久々に朝から日記書いてます。
先週末でサブリーダーとプログラマが1人ずつ抜けて、
いよいよこのプロジェクトも危うくなってきたわけです(笑)。

延びに延びていた結合テストも今日から始まる予定なのだが、
まだ何の音沙汰も無し。
しょうがないので日記でも・・・という流れだ。

--- 今週は? ---
果たして忙しいのだろうか・・・
むか?しに出たスケジュール上では、今週で結合テスト終了。
来週から相手先のところで外部テストをやる予定らしいが、
もはやそれは夢物語。

大体まだコーディングだってロクに完了してない事実を
真リーダーは知っているんだろうか。
その分のしわ寄せが残った僕らに降りかかることは必至。
困ったもんだぜ。

--- 仕方なく・・・ ---
テストはいつまで経っても始まりそうにないので
仕方なく他の人のプログラムを見ることにする。
これで全部だ。結局は僕が全部の人のプログラムを見てあげなくちゃいけない。
そうしないとテストで詰まることは目に見えているからだ。

さっき「とある」プログラマの日記を読んでいたせいか
思考が「毒々モード」に突入気味だ(笑)。この先読む人は要注意。
では、GO!

--- 唖然 ---
・・・あまりにも汚い。読みにくい。
こんなプログラムをよく平気で書けるもんだ。
そして無意味なコードの羅列。

なぜimport文を指定していながら、クラスの完全限定名を記述する!?
某狂言師のダブルブッキング問題と同様、
こういうのは一つだけ記述(ブッキング)したら
もう片方は使わない(キャンセルする)のが常識なんだ。わかってくれ。

定数クラスを定義するのはいいが、
なぜそれをnewしている!?何のために定数をstaticにしてるんだ。

ひどい・・・ひとすぎる。
この入力処理は以前のプロジェクトで使っていたものを改良して作ったらしいが
こんなもの、とても流用できる代物じゃないよ。

それよりも、一からプログラムを出来ない奴を
外注プロジェクトのメンバーの一員に入れないでほしい。
こういうのはもう少し社内研修してからでないと実践では使えないよ。
というか、彼は派遣なんだっけ・・・為す術無し。

--- ようやく・・・ ---
真リーダーに「テストまだですかぁ?」とメールで(柔かく)突っついたところ
ようやくテストの準備を始めたようだ・・・
これじゃ実際に始まるのは明日以降だね。

それよりも問題なのは、前々から言っているがDBモジュールだ。
このままじゃテストするのに膨大な無駄時間が掛かってしまう。
しかも今見てみたところ、レコードInsertの度にコミットしてるという愚かさ。
なんのためにコミットフラグ設定したのかわからんね、これじゃ。

・・・と、今ごろになって(現在15:35)SEの一人が
テスト用モジュールのリリースをしろとか言ってきやがった。
しかも16:00までに全作業を完了させろとは強引だぜ。
そういうことは早めに連絡しろっての。

--- 本音と建前 ---
真リーダーから返事が返ってきた。
やはり、現実のスケジュールは「今月いっぱい」で
社内テスト完了という事になっている様子。
まぁとりあえず、真リーダーは現状をある程度は把握してるみたいで一安心。

な?んだ、あと3週間以上も社内テストに時間割けるのかぁ。
いや、違うな。
その「今月いっぱい」の中で社外テストも行わないといけないのは前と一緒。
おそらく、社外テストなんてすぐ終わると思ってるんだろうね。

--- 社内と社外 ---
甘い。甘すぎるぜ。そんなの
アイスクリームに蜂蜜と練乳かけてチョコレートコーティングする
くらいに甘いぜ・・・なんじゃそりゃ(笑)。

今回一番重要なのが配賦と呼ばれているメイン処理。
その次に大事なのがインポート処理だ。
相手先からどんなデータが渡ってくるかもわからないまま
社内テストをいくら繰り返したところで
社外で試せば確実といっていいほど上手くいかないなんてのはもはや常識。

まぁ、社外テストすらも今月で完了させるっていうのも
完全な建前に過ぎないとは思うけどね。
そうでないとこっちが困る。休日出勤なんかは御免だぜ。

--- Eclipse ---
Eclipseというソフトを使ってみる。
これはフリーで提供されているJavaの総合環境で、なかなか好評らしい。
で、使ってみたところ。良いね。

今の現場ではIBMのVisual Ageを使ってるんだけど、
これと比べても雲泥の差。それなのに金払ってこういうソフト使ってる奴の気が知れんぜ。
今は亡きサブリーダー曰く、「せっかくあるんだから使わないと」。
お前は道端に落ちてる飴を拾い食いする小学生か!

まったく・・・あれば使うってもんじゃないぜ、こういうのは。
有能なソフトだからこそ、導入する価値があるのだ。
自動Import文作成、CVS連動、VisualCのようなメソッドヒント、
リファクタリング支援、ネイティブで高速な開発環境・・・
これら全てが揃っているEclipseと、全く揃っていないVisualAge。
あなたなら使うのは、どっち?(どっちの料理ショー風)

--- アウチの人 ---
なんてこったい・・・
サブリーダーが抜けたので、今日から進捗は真リーダーが進めるようだ。
別にそれは構わないんだが、そこで「アウチの人」(笑)が新たに出現。
これで今いるプログラマは僕、ピンチの人、アウチの人・・・猛烈に駄目じゃん。

そのアウチの人、何がアウチかというと。
今日完成させるはずのプログラムがまだ出来上がっていないらしく
僕が真リーダーからヘルプを要請される。
で、「だいたい完成した」プログラムを読んでみると・・・完全にアウチだ。

単体テストをやってないのはともかくとして、プログラムの設計がまるで間違っている。
リーダーには「今日中には単体テストまで終わらせて欲しい」と言われたので
僕が全部書き直した方が早い。
そんなこんなで、結局作業が終わったのが9時過ぎ。
こんな遅くまで残る羽目になるとは・・・ふぅ、疲れたぜ。

--- 終わり ---
はい、長かった今日の日記も無事終了です(笑)。
ここまで読んでくれた皆、ありがとう。
では、アディオス!

2002/07/09(火)
無題
--- 手詰まり!? ---
昨日の夕方ごろからテストが始まっている。
が、未だに最初のステップすら動かない様子。
どうもOracleドライバーの読み込みがうまくいっていないという話。

ったく、慣れてない総合環境使うからこうなるんだぜ。
とはいっても当然VisualAgeだってクラスパスの設定くらいはできる。
その方法がいつまでたってもわからないって・・・マニュアル読めば?

とか思っていたら、画面側もDB接続がどうのこうの・・・
おいおい、テスト以前の問題だろ?それ。泣けてくるぜ。

--- SYO?SHO? ---
このプロジェクトでも当然、データベースは使っている。
で、困ったことが起きている。
カラム名の付け方が適当なのだ。

例えば、商品名という項目があったとしよう。
あるテーブルでは、そのカラム名は「SHOHINMEI」。
別のテーブルでは、そのカラム名は「SYOHINMEI」。

どっちかに統一しろ!

まったく、こんな初歩的なこと、30過ぎのおっさんに言いたくないっての。
ローマ字変換方法表を作るとか、英語で書くだとか、
いくらでも方法はあるだろうに。
僕だったら最後に簡単なスクリプト作って統一チェックしたら完了だね。

こんな些細なことでも、プログラム作る側には当然影響する。
そのせいで無駄な時間を費やしたくないのに。
そのためにわざわざ設計者がいるんでしょ?

--- タイム・ロス ---
う?む、どうやら今日中にテストが進行することは望めないようだ。
いつまでたっても進んでる気配が無い。
昨日は残業、今日は暇。
これじゃ何のために昨日頑張ったのかわからんぜ。
今日やれば全然間に合ったのに・・・あほらし。

--- 今更ながら・・・ ---
Javaを仕事で使ってみて初めて気づいた。
Javaって「メイク」作業がいらないのね。
プログラムをコンパイルすればあとは実行するだけ。

しかも総合環境使ってると
ファイル保存すれば自動的にコンパイルされるから
コンパイルすらも意識しないで作業ができる。
「プログラムを書く→すぐ実行できる」っていうのは
今更ながら便利だなぁ、ということに気づいた僕でした。

で、昨日紹介したEclipseはさらに上を行ってる。
プログラムを1箇所修正しただけでコンパイルエラーを感知してくれるのだ。
これはもう超快適。
今までVisualC++の総合環境はかなり使えるなぁと思っていたけど
Eclipseはこれのいいとこだけを受け継ぎつつ様々な新機能を搭載してる。
これが世界標準になる日も近いかもね。軽いし。

--- 夏、暑 ---
近頃の暑さは異常だ。まだ梅雨も明けてないってのに。
それでも、外に出るのは家から駅までのわずか数分なので助かってる。
ホント、現場が駅ビルの中にあって良かったぁ。

--- タイム・リミット ---
おいおい・・・いつまで実行環境の構築に手間取ってるんだよ。
SE1人とプログラマ1人、それにテスター1人。
3人ががりで朝からず?っとやってるのにこれでいいの?

もうすぐ進捗の時間なのだが、始まる様子もない。
早くしてくれないと定時で帰る壮大な計画が崩れちまう。
急げぇ??。

・・・と思ったが、定時になったのでもう帰ります(笑)。
今日はたぶん進捗はないのさっ!と勝手に決め付けてみた。
じゃ。

2002/07/10(水)
無題
--- ずぶ濡れ ---
朝からずぶ濡れの奴がいる。
なぜ、こんな大雨なのに彼は傘を持っていないのだろうか?
出かけるとき降ってなかったのか・・・
いや、それは無いだろう。昨日の夜からず?っと降ってるんだから。

--- 面接 ---
現場では今日、面接をやっているらしい。
こうやってまた、素人同然の新人が社内に増えていくわけだ。
僕みたいに営業の人が付いているプログラマーならともかく、
学生である彼らの能力判断をすることなどほぼ不可能だ。

・・・いや、営業が嘘八百並び立てれば僕らも一緒だな。
実際そういうプログラマーも多いらしい。
「Java+EJB使えます!」という紹介で入っておきながら
本当にできることといったら「Hello World!!」表示することくらい(笑)。
ここまでくると裏口入学より悪質だぜ。

--- 理解不能 ---
いつまで経ってもテストが進まない。
一体彼らは何をしているのだろうか?理解に苦しむ。
さっさと僕の担当してるところまで回してくれ。すぐ終わらすから。

・・・などと思ってたらまたもやばい会話が聞こえてくる。
jarファイルにまとめるとか言い出したぞ。
そんなものテスト通ってからにしろよ。
本当に彼らのやってることは意味不明だ。

わざと無駄に時間を費やしたいのか?
それとも無駄ということすら解らないくらいダメなのか?
もはやアドバイスの送りようも無し。
何か聞かれるまで放置しとくのが一番だ・・・

--- 単体⇔結合 ---
結合テストが全く進まない理由がわかった。
単体テストでつまづくような場面でことごとく止まってるのだ。
ったく、「単体テストは終わりました」って言ってなかったぁ?
間違いなく都合のいい単体テストしかやってないね、これは。

つまり、ある一つの例しか試していない。
あるいはさらにひどいと「ただ正常に終了しただけ」とか。
彼なら有り得るな。なんたって「アウチの人」だし(笑)。
ここはインポート(入力)処理だから、
全ての場合を試さないと意味が無い。
全部といっても20ファイル程度なんだから、大した手間じゃないはずなのに。

そして、ピンチな彼はいつまでたってもコーディング中だ。
もう結合テストが始まったことなどお構いなし。
まっ、実際はじめの部分でつまづいてるから
彼のところへ行くまでにはしばらく時間が掛かるとは思うけどね。

そう、結合テストなんてもっと早くから始めるべきだったんだ。
結局はまた単体テストレベルまで戻って
プログラム組まなきゃいけないんだから。
「単体テスト→結合テスト」なんていう矢印は
もはやこの現場では通用しない。

・・・今になって「mainがない」とか言うのはやめてくれ??

--- Oracle ---
それにしてもOracle付属のアプリケーションってのは使いにくい。
OracleMasterとやらは、こういうソフトを使って作業してるんだろうか?
それとももっと使えるソフトを別に用意してるんだろうか。

もし前者の人間がいたとしたら、
彼らは会社から高い金で雇われていながら
こういった駄目アプリを使いつづけることで無駄な時間浪費をしている
金食い虫だ。そういうのは早めに斬ったほうがいい。
使えるアプリの習得を勧める方法もあるが、
プライドの高い彼らはそれを許さないだろう。

・・・偏見ありすぎか(笑)?もしかして。
もちろん全てのOracleMasterに向けた台詞ではないので。
そういう輩も絶対にいる、ってことを言いたかっただけ。

どの現場でも承知していることだが、
Oracleは世界的に普及しているが果たしてそれが使いやすいのかというと
「?」な製品だ。
バージョンアップする度に動かなくなったり動作が変わったり。

偉い設計者はそんなこと気にしないかもしれないけど、
そのたびに開発者は修正をしていかなきゃいけない。
まったくもって使いづらいDBなんだ。

相当凝ったことをやろうとしない限り
もっと使いやすいDBがいくらでも(しかもフリーで)ある世の中だ。
プロジェクトに合ったDBを選ぶのが本当に良い設計者なのに、
彼らの頭の中では既に「DBイコールOracle」という図式が出来上がっている。

他のDBのことを何一つ知らないからだ。
「井の中の蛙」とは正にこのことだぜ。
なんでもかんでもJavaでやろうとする奴もこれに当てはまるな。

--- ルーズ ---
17:30から始まるって報告あった進捗がいつまでたっても始まらんぜ。
どの業界でも、時間にルーズな奴はいるな。
ようやく18:00から始まる。

・・・しかも今日も残業だ。外は台風だってのに。
さらに言えば、やることも何もない。
もう天災だと思って諦めるか。日記でも書きながら(笑)。
明日から内職でも始めることにしよう。

が、これで帰ってからMLBオールスターの録画を観るという
スケジュールは台無し。
まぁ日本人選手の活躍は無かったみたいだからいいか。

--- 謎の作業 ---
共同でテストすることになったSEの人からメールが届く。
テスト用のデータ作成するための資料らしいが、
はっきりいって意味不明だ。
同じ文がずらずら並んだSQL文。この人は一体何がしたいんだろう?
とりあえず・・・これは見なかったことにしよう(笑)。

--- 駆け引き? ---
ここのリーダーもクズだ。
客とのやりとりには必要なものが、嘘?駆け引き?
てめぇは詐欺師かよ。
そんな考えじゃいつかこの会社も潰れるぜ。
それとも、相手が馬鹿ばっかだから嘘ついてても問題ないってか?

俺はそんな考えじゃないね。
最後に残るのは、騙し騙しやっている企業なんかじゃない。
これを聞いて、俺の考えを「社会のわかってない人間」と思う奴は思え。
俺はいつだって俺の信念を貫くぜ。
どっちが正しいか、いずれ解るときが来るはずだ。

--- PM23:00 ---
初めてだ。PM23:00まで残業してしまった。
この分がちゃんと給料に反映されるってわかってたら
もう少しモチベーションも上がるのだが、実際のところはどうだか怪しい。

ようやく真リーダーが事のやばさに気づいたらしく
しばらくは残業が続くかもしれない。
コーディング終わって暢気にしてた俺もテスト部隊に回されてしまった。

まっ、こんなテストちゃちゃっとやって担当者に振ればおしまいだ。
が、その担当者も当然あてにならないので注意は必要だ。
まだまだやることは山ほど残ってる。
後半部分は仕様すらまともに決まってないのでさらに大変なはず。

その大半のコーディングが俺に回ってくることはもはや必至なので
なるべくならテストなんかで無駄な頭を使いたくないというが本音だ。

そんなこんなで、今日は終了。
忙しそうにしてた割には日記よく書いたな(笑)。
まぁ11時まで残業してりゃそれくらいの暇は出来るでしょ、普通。
じゃ、また明日。

2002/07/11(木)
無題
--- 夢?幻想? ---
昨日からここの現場のお偉いが会社の在り方について話している。
ほんと聞けば聞くほど夢物語みたいな話でうんざりする。

全員定時であがるようにしたいだとか、
フレックス制を辞めて朝9時からにするだとか、
昼12時から1時間は完全に仕事しない時間にしたいだとか・・・
聞いてて呆れてくるね。

まっ、所詮はそんなもの空想の世界にすぎない。
それをやっていたらあんた達のモットーである
「客騙して金取る」ことができなくなるもんね。

そういう客は社員がみんな定時で帰ってるのを知ったら
「もっと仕事してほしい」だとか「本当は暇なんじゃないの?」とか言って
報酬を出すのを渋るに決まってる。

それ以前に、全員が残業しないで作業してたら
作業効率が半分くらいになっちゃうんじゃないだろうか?
皆残るのを前提で作業してるんだからね。
リーダーが一番初めに言ってた「基本的に残業は無しでお願いします」
なんてのも完全な建前にすぎなかったってことがそれを物語ってる。
もちろん僕は頼まれない限りは定時で帰るようにしてるけど。

--- 猛暑続く ---
最近やばいくらいに暑い日が続いてる。
このままじゃ溶けて無くなりそうだ(笑)。
昨日台風が来てたのは幻か?

--- マイナス ---
VisualAge。本格的に使えないということが解ってきた。
が、現場ではソース管理のため「だけ」に使っている。
おかげで、バグ発生→ソース修正→リリースの手間が果てしなく面倒だ。

一応は総合環境なのだが、全ての機能があまりにもしょぼすぎる。
不自然かつ解りにくいインターフェイスが最大の欠点だ。
だいたいIBMにこういう総合環境のノウハウなんて有るはずないんだから
普通の人間だったらその時点で導入を断念するはずなのに。

必至こいてリリース管理しようとしてる某SE。無駄時間使うなよ。
アプリを導入して、効率が落ちる。
何のためのアプリなのかわからんぜ。

--- 今日も・・・ ---
昨日に引き続き残業。
だんだん進捗する時間が遅くなってるのは
もはや奴らの策略としか思えない。
今日も進捗終わったのが8時過ぎだ。それくらい定時前に終わらせろ?。

結局、やることもないまま俺はこうして日記を書いている。
この人たちには「仕事を早く終わらせるために頑張る」という考えが無いようだ。
だらだら時間使ってるから、いつまで経っても仕事が終わらないんだ。
少しはそんなのに付き合わされてる俺の身にもなってくれ。

そんなわけで。
今日もグチ満載で後味の悪いまま終了です(笑)。
さらば!

2002/07/12(金)
無題
--- びっくり。 ---
以前に何回かこの日記で紹介したEclipse。
それが、今まで酷評してきた(笑)VisualAgeの開発元である
IBMの製品だということが発覚した。

とても同じ会社が作った製品とは思えない。
というか、IBMがフリーの製品(しかも高性能)を出してるとは。

見てみると、VisualAge(3.5)のライセンスを見ると「1991-2000」年。
Eclipseの方は「2000-2002」年。
明らかに開発グループは別物と見たね。
とにかく、Eclipseは最高ランクの総合環境を備えている。
CVSにも対応してるので、ソース管理まで全てこれ一つでOKだ。

惜しむらくは、マウス中心の操作になってしまうことだ。
キーコンフィグが出来ないっていうのは痛いね。
次バージョンでの対応求む。

ただ、Linux環境ではEmacsに勝る開発環境って無いんだろうなぁ。
一応Linux版Eclipseもあるんだけど。
まだまだLinuxでのグラフィック表示は相当遅いので
テキストベースのEmacsが一番使いやすいのだ。

--- テスト中。 ---
テスト部隊はず?っとテストをしている(ということになってる)。
しかも、こんなに時間が経ってるのに
バグ報告が全然無いってことは、大して進んでないってことだ。
実際には山ほどバグが潜んでるんだからね。

--- 社内?社外? ---
ここの現場にはもちろん社員もいるんだけど、
パートナーと呼ばれる社外からの人間も多数存在する。

で、この会社の重要なポジションにいる人すら社外の人間だったりする。
しかもうちの会社(正確に言えば僕が元いた会社)の人間だ。
彼はもう社内の人とほとんど変わりない気がする。
いずれは正式に社員になるんだろ?なぁ、とか予想してるんだけど。

当然だが僕はここの社員になるつもりなんて全く無い。
もうしばらくは続けるけどね。
今のプロジェクトは今月いっぱいで終わりだけど
来月以降もここの会社の下で働くことになるらしいので。

--- 休日返上 ---
なんてこったい。明日仕事出る羽目になってしまった。
とりあえず午後から行って5時くらいには終了予定。
僕の立てていた「週末大掃除プラン」はとりあえず延期だ。
じゃ。

2002/07/15(月)
無題
--- 週末結果報告 ---
日記に書いたように、土曜日は現場に行ってました。
が、1時過ぎに着いたのにまだ来ている人間が2人のみ。
午前中から来るって言ってた奴も来てないとは・・・どうしようもないな。

で3時過ぎになって到着。
「寝過ごしちゃって・・・」
ったく、小学生の言い訳レベルだぜ。
どうせ前日遅くまで起きてたんだろ?こいつは確信犯だ。

さらにもう一人遅れてきた奴も
「マックで30分待たされて・・・」
2時間以上遅刻してる人間のいう言い訳じゃねぇだろ。
どいつもこいつも言い訳だらけ。
嘘言ってまで自分の潔白を表明しようとする様は余りに見苦しい。

僕は事前の予定通り5時で仕事を終わらせて帰る。
もちろん周りの連中は帰る気配などまるで無し。
たまには時間通りに終わらせて帰ったら?

--- 熱風 ---
今日はすさまじく暑い。そして風も強い。
もう梅雨は明けたのかな?
あ、でも台風が来てるんだっけ・・・

--- 遅すぎ ---
信じられん。定時過ぎたのにまだ進捗始まってすらいないぞ。
とりあえず進捗くらい定時前に終わらせてくれ。
これ終わらないと帰れないんだから。

本来僕はテスト部隊じゃないんだけど、人手が足りないってことで
SEの一人が担当してる部分の半分を受け持つことになった。

--- 丸一日かけて・・・ ---
で、僕は今日で終わったんだけど
このSEが進捗で言った一言。
「テスト1件やろうとしたんですが、そこで落ちまして・・・全く進んでません」
おいおい・・・マジ!?
じゃあ今日一日掛けて君は一体何をやっていたの?と聞きたくなる。

だいたい落ちるなんてこと有り得ないぞ。
僕も同じモジュール使ってるけどそんなこと一度も無かった。
今回のテストは下準備が少し面倒。適切なテストデータをDBに登録しておく必要がある。

つまり、アレだ。
必要なテストデータの準備が出来ないのを誤魔化すための言い逃れだ。
それにしても丸一日かけて1件も終わってないっていうのは・・・
追い討ちは、リーダーの「いつ頃終わりますか?」の問いに「今週いっぱいは掛かります」。

--- 結局・・・ ---
で、僕がもう終わったっていったら
遠回しに「僕の分もやってほしい」みたいな逃げ腰。
それやったら君の存在価値無いじゃん?
「上の人間の手伝いはしない」僕のポリシーにも反するしね。

わかんないんだったら聞きに来ればいい。いくらでも教えてあげるから。
それを自分で頑張って出来ず終いで結局人に頼むっていうのは
余りに問題解決能力が無さすぎるぞ。
人が叩いたDBのSQL履歴見てニヤニヤしてる暇はあるくせに。

--- ソース管理 ---
前にも言ったが、このプロジェクトではソース管理にVisualAgeを使ってる。
で、そのプロジェクト管理をSEの一人がやってるんだけど
奴の効率の悪さにはホント閉口する。

たかだか1回のプロジェクトリリースに1時間も掛けてるらしい。
そんなんで一日の大半を費やしてることを愚かだと思わないのか。
確かにこのアプリのソース管理機能は使い物にならない。
だったら他にいくらでも手はあるだろうに。

結局は与えられたアプリケーションをやみくもに使い続けることしか出来ない。
そんなんじゃ開発者として一向に成長しないぜ。

--- 未だ先は見えず ---
このままじゃテストは終わりそうに無い。
リーダーはこのやばい状況に気づいているのだろうか。
結局はまた休日出勤?進歩無いね。

そんなわけで、かなり精神的に参ってる今日この頃。
明日は台風来るから休みだなっ(嘘)。

2002/07/16(火)
無題
--- 台風 ---
世間では台風で学校も休校になっているというのに、
僕は朝から西武線の急行で通勤。
「きゅうこう」つながり・・・朝からすべりました(笑)。

今日は営業の人と昼飯を一緒に食べに行く予定。
一食分浮いたぜっ!

--- DB設計 ---
テストが全然進んでない人、通称「終わってる人」は
今日もまだ来ていない。
いつも遅くまで残業してるのかは知らないが、
それで結局午後から来るんなら意味ないじゃん。
リーダーが昨日の進捗で注意してた「勤務時間の見直し」も
全く耳に入っていない様子だ。

で、彼はDB設計も任されているわけだが
この設計がまたひどい。
カラム名が統一されてないって話は前にしたけど
それ以外にも「DB設計」をしたとはとても思えない作りには呆然。

NULL値の扱いが全く決まってなかったり
インデックスの付け方も超適当だったりと
全く使えないDBに仕上がっている。
これで「DB設計者」という肩書きを持てるんだから
この会社もロクなもんじゃないね。まぁ彼も派遣らしいが。

--- ウイルス ---
何でも会社の上の人間がウイルスにかかったらしく
社内のいたるところにウイルスメールが流れているらしい。
っていうか、メールサーバでウイルスチェックくらい掛けろって感じだが。

どうせ何も考えずに添付ファイル開いたんだろうが。
基本的に信用できない人間からきた添付ファイルを開くなど愚の骨頂。
普通の開発者ならHTMLメールすら嫌うっていうのに。
いい加減「対策をしてないと間違いなくウイルスにかかる時代」
だってことを認識したほうがいいなじゃない?

--- くず ---
といっても別に山口&宮迫のユニットのことではない(笑)。
この現場に一人、どうしようもないクズがいる。
ああいうのは現場の士気を下げる。早めに斬るべきだ。

会社としてはピラニア飼ってるような感じか。
相手先に噛み付く人間が必要で、仕方なく雇っているのだろう。

--- 現場 ---
結局「終わってる人」は来ない。
もう先月と合わせると5日は休んでるぞ。
そんなんでクビ切られない現場もどうかしてる。
・・・前の現場での俺も似たようなもんか(笑)。

が、明らかに違う点がある。
彼はSEであり、仕様を確認するときに必要とされる人間なんだ。
前の僕のように「いてもいなくても大差ない存在」じゃないんだから
無断欠勤されると困る。

僕が担当してる作業で仕様が固まっていない部分があるから
そこを彼に聞いてプログラム完成させたかったのに、
とりあえず明日以降に回すしかなさそうだ。

だいたい、テストが全く進んでいないのに
休んでて大丈夫なのか?
それとも今日休むことを考慮に入れての
「今週いっぱいは掛かります」という発言だったのか?
いっぱい食わされたぜ・・・

--- 来月以降 ---
昼に営業の人と飯食べながら打ち合わせ。
とりあえず来月以降もこの現場で働く方向でいるようだ。
が、具体的にどのプロジェクトにつくのかはまだ決まっていないらしい。

次のプロジェクトでリーダー関連の仕事やってみる?とか聞かれる。
う?ん・・・別にいいんだけど、早く帰れなくなるなぁ(笑)。
リーダーといっても、プロジェクトリーダーではなくて
チームリーダー程度だろうとは思うけどね。

しかし、キャリアの無い僕の下に付けられるプログラマーなんて
おそらく新人レベルに違いない。まとめるのが大変そうだぜ。

というわけで、今のところは全て未定です。
なるべく早めに決めてほし?な?。

--- 巻き添え ---
眠い・・・もう定時だぜ。
相変わらず進捗は始まらない。
あんたらが仕事終わらないからって
その被害をこっちにまで回すのは止めてくれ。

そして「ピンチの人」は、なぜか進捗が異常に長い。
20分ぐらいかかることもある。
モノをまとめて説明するということが出来ないのだ。
自分がやったことを1から100まで全て話しつづける。困ったもんだ。

僕は自分の話す部分は1分以内で終わらせる。
それについて周りから質問が出ることも多いから
実質もう少しかかるけどね。
何にせよ、さっさと終わらせないとどんどん長引いていくからね。

・・・結局終わったのが19:30。一時間の残業だ。
じゃ、もう帰ります。

2002/07/17(水)
無題
--- 予想通り ---
営業の人からメールが来ている。
やはり、今のプロジェクトは8月までずれ込むらしい。
とりあえずは良かった。
今のままじゃ7月中に終わらないのは明白だからね。

終了後は別プロジェクトに組み込まれることが
決まっているらしいので一安心。
それと今後のためにEJBを勉強しておいてほしいとか。

--- EJB ---
確かによくEJBという言葉は聞く。
しかし雑誌の特集などを呼んでも今いちピンとこない。
そこでWebで調べたところ、何となくだけど解ってきた。

要するにEJBというのはJava開発環境で使う
業務用モジュールが色々詰まったパッケージのことだ。
つまりEJBの規格なんてのもパッケージによって様々で
「EJBが使える」ということは
例えばパッケージの一つである「WebLogicが使える」ということに過ぎないのだ。

「EJBができる技術者が少ない」らしい。
当然だ、業務用で高価なEJBパッケージを個人で買う人間などいやしない。
結局はWebLogicを採用しているどこかの企業や現場で働かない限り
マスターすることなどできないのだ。

まぁとりあえずは無料の評価版が公開されてるので
ただいまDL中・・・会社で100MBに近いアプリを落としていて
怒られないだろうかと少し不安。
幸い今は暇だし、しばらくはこれで時間をつぶすとするか。

--- 終わってる人、現る ---
今日はいるみたいだ。
手が空いている人が彼のヘルプに入ったらしい。
これで少しは進むかな。
おそらく彼女のほうが解ってるはずだから。

--- ピンチの人、再び ---
ほぼ完成したはずのモジュールをいじり
エラーが起きている。
ちゃんと動いてるんだから変更すること無いのに。
素人がロジックを追加すると必ず起きるのがデグレだ。
今まで通っていた部分が通らなくなる。修正して逆に悪くなってるわけだ。

しかも自分でよく理解していない技術を使おうとしてるらしく
まだ直らないらしい。この先不安だ・・・

--- ドタバタ ---
ドタバタコメディー、復活。
SE2名とテスター1名がDBがどうとか言って騒いでる。
今日中に解決できるといいねぇ。進捗が怖いぜ。
・・・さらに発展。プログラマ2名を巻き込んだ新喜劇に突入だ(笑)。

話は飛ぶが、今日は進捗5時から始まるようだ。
よかったよかった。

--- 俺もかよ・・・ ---
しまった。ピンチの人の巻き添えくらってしまった。
彼のヘルプに回されたんだけど、
プログラム見るともうグチャグチャで大変。
仕方がないので、以前動いてたバージョンに戻してもらうことにした。

これが一番安全かつ簡単な方法かな。
とりあえず前のがちゃんと動いていることは確認したから、
それにさえ戻してくれれば後はこっちでなんとかすることにしよう。
あ?、今日も残業かよ・・・参ったぜ。

2002/07/18(木)
無題
--- 引き続き ---
今日もWebLogic ServerでEJBの勉強だ。
それにしても眠い。眠すぎる。十万石・・・いや、なんでもない(笑)。

ファイルシステムやJSPについては
それほど通常のJavaアプリと違いが無いので楽だった。
が、問題はメインとなるEJB関連。

JSPによるセッション管理はそれだけでも相当優れた一品だ。
しかし、致命的ともいえる欠点がある。
それは「安全でない」ということだ。

--- 安全性 ---
では何が安全でないのか?
例えば、あるユーザーが通販のオンラインページで
なにか品物を買おうとしてボタンを押したとしよう。
このとき、もし途中で「回線が切れる」「サーバーが落ちる」
など不慮の事故があった場合を考えてみる。

通常のJSPでは、このときの動作は「予測不可能」である。
ユーザーはお金だけ払って品物が届かないという事が起こるかもしれない。
これでは明らかに安全ではない。

--- EJBコンテナ ---
そこでEJB(Enterprise Java Beans)の登場だ。
EJBではこういった場面に対応するために
トランザクション機能を有している。
これは現在のDBに必ずあるといってもいい機能の一つだ。

EJBを使えば、開発者は複雑なコードを書かずに
DBのデータとJavaアプリ内でのデータを完全に同期化できる。
これこそが、業務用アプリにEJBが必要とされる
最大の理由だ・・・と、今の僕は思っている。

これらの処理を全てやってくれる存在が「EJBコンテナ」と呼ばれる代物だ。
つまりはEJBコンテナの使い方さえわかれば
それほど習得に時間は掛からない・・・はずなのだが
このEJBコンテナの仕組みが実にとっつきにくい。

とりあえずはサンプルが豊富にあるので
これを見ながら少しずつやっていこう。

--- Ant ---
最近Javaで使われているビルド方法のことだ。
C言語ではmakeが一般的だよね。
Antも基本的にはmakeと似ているんだけど、大きく違う点がある。
それは「XMLで記述されている」ことだ。

XML記述は手書きだとやや面倒だし冗長になりがちなので
今まで僕はあまり好きじゃなかった。
でもmake最大の問題点だった「文法が複雑かつシビア」を解決する
一つの答えがXMLであることは確かだ。

XMLの記述は実にシンプルだから間違えようが無い。
makeでは「タブではなくスペースだから」という理由だけで
通らなかったりする。パッと見ただけではタブとスペースは区別できないから
非常に厄介だった。

そしてJavaプロジェクトのビルドはAntに統一されつつあるので
総合環境などでのコンパイルも非常に簡単だ。
EclipseでもAntを採用しているので
WebLogic Serverのプロジェクトを「何の設定もなく」
一発でコンパイルすることができた。

Javaで一番面倒なのがクラスパスの設定だ。
これらも全てantファイル(build.xml)に入っているので
便利便利。なるほど、antとはこんなに使えるコマンドだったのか。
今更ながら感心した。

--- ほぼ確実に ---
今週中にテスト完了させなきゃいけないのにEJBなんかの勉強してる余裕あるのか?
と思われるかもしれないが
あいにく今テスト部隊はテストデータ作りの真最中だ。
テストが始まるまで僕は何もすることがない。
やれやれ、彼らのせいで休日出勤はほぼ確実となったようだぜ。

--- 新人初仕事 ---
ここの現場では今、社内で使うWeb勤怠システムを
新人が作っているらしい。
やっぱり初めはこうやって社内アプリ作るのが無難でしょ。
失敗しても回りに迷惑掛けないもんね。

--- 休憩 ---
ここの奴らは休憩してるんだか知らんがよく居なくなる。
そんなに休んでる暇あったらその時間働いて
仕事早く終わらせれば?と思うのは僕だけだろうか。
どう見ても無駄に思えてしょうがない。

現在16:30。今日は相当やることがない。
どうせ進捗後にまたやることが決まるという
どうしようもない循環の悪さだ。
今日こそは定時で帰ろうと思ってるんだが・・・結果はいかに!

--- ようやく・・・ ---
テストが始まったらしい。
予想していたことだが、出るわ出るわバグの嵐(笑)。
単体テストすらやっていなかったのが幸いしたか。

幸い?災いの間違いじゃないかって?
否、「幸い」なのだ。
自分でテストまで済ませちゃうと、その後恐ろしく暇になるのが
目に見えてたからこういう方法をとってみた。
それに、こういう現場だとバグの数は多いほうがいいらしいから(笑)。
う?ん、俺も大人になったもんだぜ(違う?)。

それにしても、テスト部隊が今やっているテストって
結合テストって言ってるけど完全な単体テストレベルじゃん。
なにをもって結合テストと言ってるのか教えて欲しいね。

--- 若干の遅れ ---
今日はなんとか定時少し過ぎに帰る。
やはり進捗が早く始まるようになったのが一番大きい要因だね。
じゃ。

2002/07/19(金)
無題
--- 大慌て ---
現場は今大変なことになっている。
テスト始めてみて出るわ出るわ仕様漏れの嵐。
僕も仕様が決まっている部分しか作ってないから、
確かにあれじゃ動くはずないとは思っていたけど。

今回の失敗原因。
それは明らかにSEの認識不足によるものだ。
客先から提示される仕様なんて所詮
向こうの都合のいいように記述されたものに過ぎない。

それをSEが見て「この仕様でアプリケーションがちゃんと動くか」
ということを判断しないといけない。
全然なっちゃいないね。とりあえず完成したプログラムは
期待通りの動きを全くしていない。

--- 2人のSE ---
一人はおなじみ「終わってる人」。
彼は仕事の効率が信じられないくらい悪いことで有名だ。
そしてよく休む。次の日の進捗でそのことについて一言も触れないのは
もはや常識外れの行動だぞ。

もう一人は「ちょ(は)っかい君」(?)。
メインの仕事はリリース管理だ。
プロジェクトの最新ソースを1時間近くかけて
サーバにアップロード、そしてソース管理を行っている。
暇な時間はテスターの横に座ってテストを支援(するフリ)。

猪八戒(ちょはっかい)に顔が似ている。
そして暇を見つけてはテスター等にちょっかいを出す。
というわけで彼はちょっかい君(もしくはちょはっかい君)に命名だ。

こんな二人だから仕様漏れが山ほど出てくるのも頷ける。
いや、本当は頷いてちゃいかんが(笑)。

--- これからのプログラム ---
そうなんだ。
これからはプラットフォーム依存しない開発が必要なんだ。

唐突に始まって失礼。
PCの世界はインターネットにより世界の壁が取り払われた。
しかしプログラムの世界では、大昔から抱える一つの問題がある。
それが「OSやアプリケーションによる互換性」だ。

世界には様々な人種がいる。
それと同じように、世界には様々なOSがある。
・・・といいたいところだが、実際はそうではない。
一般大衆の使うWindows、そしてMac、開発の人間が主に使うUnix。
この3つだ。

--- 依存性 ---
Windowsには2000やXP、Meなどいくつかのバージョンがある。
Unixではもっと多様で、個人用に発展したLinuxだけとってみても
10種類くらいのバリエーションがある。

いま発売されている多種多様なアプリケーションのうち、
これら全てのOSの元で実行できるものがあるだろうか。
おそらく無いだろう。
それどころか、「Win2000では動きますがXPでの動作は保証しません」
というものすら有る。

これは開発者にとってもユーザーにとっても
望ましい状況ではない。
開発者は複数のOSに対応するプログラムを書く必要があるし
ユーザーは自分のOSに対応していない商品があったら
それを使うことが出来ない。

--- 2つの解決策 ---
これを解決するには2つの方法がある。
第一の方法。それは全世界でOSを統一することだ。
これを実践しているのがMicrosoftであり、Windowsである。

Windowsは独自の方法を思う存分使い、
「わが社のOSはこんなに便利ですよ?」とアピールしている。
しかし以前にも話した通り、その便利さはウイルスの標的となる。
開発する人間にとっては必要ない環境なのだ。

この方法には欠点がいくつもある。
これが実現した場合、Microsoftは全世界を牛耳る独占企業になってしまう。
そして全世界の人々は今以上にウイルスの危険にさらされることにもなる。
もしかしたら、ウイルスを作っているのはMicrosoftの参謀かもしれないのに。
これはとても危険だ。

第二の方法。それは「どのOSでも動くようなアプリケーションを開発する」ことだ。
これを実践したのが言わずと知れたJavaプロジェクトだ。
現在ではJavaはSun社がかなりの勢力を占めているが、
所詮は開発ツール、それが全世界に広まったからといって
Sun社が独占状態になるということは考えにくい。

そしてMicrosoftと大きく違うところ。
Sunに限らずJavaは基本的にオープンソース。
完全に閉じた世界で開発をしているMicrosoftとは違うのだ。

--- 唯一であり、多様であること ---
今までJavaの話ばかりしてきたが、
別にこれはJavaである必要はない。
要は世界で一つの「依存性の無い」開発言語が唯一つ必要なのだ。

そしてその言語に対応したOSを作るのは誰でもいい。
Windowsでも、Unixでも、これから新しいOSが誕生したっていい。
言語は一つ、OSは多数。
ウイルスの危険を常に抱えながら生活するしかない初心者はWindowsを、
Windowsの持つ利便性を特に必要としない人間は別のOSを使う。

--- OSの自由 ---
そして、ここが一番重要。
「一つの会社(チーム)内に複数のOSが混入できるシステム」
そう。これが僕の考える理想形。

結局今のところ、会社側がWindowsを採用していた場合
そこに所属する人間もまたWindowsを使わざるを得ない。
ネットワークなど、様々な問題があるためにOS選択の余地など無いのが実情だ。
個人が自由に好きなOSを使えたら、これほど便利なことはない。

--- 実現性 ---
僕が今まで話したこと。
それはまだ実現できる段階になっていない。
様々な理由が挙げられるが、やはり速度の課題が大きい。
特に組み込みシステムなどでは
速度だけでなく搭載するチップサイズの問題まで出てくる。

これらを全て解消するには、極端な話
アセンブリレベルでJavaに対応する他ないかもしれない。
いずれにせよこれから先、さらに生産性をあげるためには
これを実現する必要がありそうだ。
製品毎に違う言語を使ういうことは生産性を著しく低下させる、
ということは誰が見ても明白なのだから。

--- 初仕事 ---
ただいま14:15。ようやく仕事が来ました。
よ?し、頑張るぞぉ!

・・・いきなり意気消沈。
テストする前には必ずテストデータ確認しれくれって
言ってるのに。全然できてないじゃん。ダメすぎ。
ホント、これだったら一から自分でやった方が早いよ。
中途半端な作業は好きじゃないからね。

う?む。そろそろテスターの彼にもあだ名を付けようか。
・・・特徴が見あたらん。というわけでまた今度(笑)。

--- 理解不能 ---
ふぅ、テスターの彼と話してると疲れます。
テストデータが足りないのを指摘したら
「上から回ってきたのがこれなので」って。
そんなの上から正確なものが来るの待ってたら一生終わらないよ。
そういうのは自分で作るもんだ。

そんなわけで、彼のテストは一向に進みそうにない。
全てを完全に終わらせ、そして次のテストへ。
そんな非効率なテストは要らない。
「できるところから確実にやっていく」ことが時間短縮への鍵だ。

--- 連打 ---
カチカチカチカチ・・・
時計の音ではないようだ。見ると、ある人がマウスのボタンを連打している。
一体彼は何をしているのだろう。シューティングゲームか(笑)?

--- 丁寧なタメ口? ---
溜めろ?いや、違う。「ためぐち」です(笑)。
通称「アウチの人」の僕に対する口調が妙におかしい。
タメ口聞いてくるくせに、やけに口調が丁寧なのだ。
先輩面したいのかもしれないが、だったらもうちょっと堂々と話してほしいね。
あまりに不自然すぎて変なのだ。

--- 明日も・・・ ---
どうせ今日頑張ってもテストが終わるはずもないので
さっさと帰って明日また行くことにした。
2週続けて休日出勤は嫌だけど、どこかで代休を貰えるらしいので
それを期待しつつ・・・
じゃ。

2002/07/20(土)
無題
--- 本だらけ ---
ここの現場の人間はやたらと本を持っている。
いや、別にそれがどうしたってわけじゃないが
本当にその本役に立ってる?と言いたくなる。

「SQLバイブル」を持ってる某SEなどはその典型だ。
どうせ単純なSQL文や関数を調べるのにくらいしか使ってないんでしょ?
あんないい加減なDB設計してるんだから。

で、彼が力説してた一言。
「読んでて寝る雑誌じゃないと意味が無い」
・・・もう訳わかりません。
やっぱり理解してないんだってことだけは解ったけど、

--- in現場 ---
昨日の予告通り(?)、今日は仕事だ。
テストはなかなか進まない様子。で、早速暇になったので日記。
「終わってる人」は、何やら仕事がはかどっているらしく浮かれている。

・・・終わったの9時だぜ。
まぁ今日はJavaのAntやらSwingアプリやらを色々調べてたから
有意義には過ごせたかな。
じゃ。

2002/07/22(月)
無題
--- 一日の休み ---
やっぱり休みが一日だけじゃ足りない。
あっと言う間に終わっちゃうもんね。
来週こそは連休を・・・と誓ってみる。

--- 改善した? ---
またもピンチの人に何やらしでかしてくれた。
僕が精魂込めて(嘘)作ったDBモジュールに変更を加えたらしい。
何の連絡もなく勝手に人のプログラムいじるとは頂けないが、
それ以上に頂けないのがその修正内容。

やろうとしていることは解るが、あまりにも冗長なコードが多すぎ。
せっかくの僕のプログラム構成が台無しだ。
あ?でも直すように指示するのも自分で直すのも面倒だ。放っておこう。
今後のDB関連のバグは彼に振ればいいんだから。

--- 結局の原因は・・・ ---
で、そのDBモジュール修正の原因となったのがMapオブジェクト。
MapのkeySetの戻り値にiteratorを使うと
この反復子はキーを適当な順番で返してくるのだ。

「特定の順序では返されません」とマニュアルには書いてあるけど
その通りだったんだね。
挿入した順に返してくれるものとばかり思っていた。

しかし、元はと言えばWhere句のデータをMap型で渡すなんていう
インターフェイスにしやがったあのアホSEが原因だ。
いなくなってからも俺達に世話を焼かせるとは・・・
「死して尚、人を不幸にする」その自縛霊根性には呆れるぜ(違う?)。

--- ビリビリッ ---
こういう現場での資料などは、一応極秘である必要があるので
要らなくなったらゴミ箱にポン!というわけにはいかない。
ここの現場ではこれを「紙を手で破ってから捨てる」という
極めて原始的な方法で対処している。

そのときの「ビリビリッ」って音がうるさいったらありゃしない。
大体シュレッダーくらい買えよって感じ。
変なところで金ケチるんだなぁ、とか思ってしまった。

--- 大忙し ---
おぉ、今日はピンチの人が大忙しのご様子。
とはいっても、いつものようにピンチで忙しいわけではなく
色々な人への質問に答えている。
なんだ、彼も人の役に立ってるんじゃん(笑)。

--- それ以前に。 ---
アウチの彼がEJBを勉強しようとしているらしい。
「3日でマスターする」とかほざい・・・ぬかし・・・言って(笑)いるが、
それ以前にJavaをマスターしてから始めろよ、って感じ。

物事には順序ってものがあるのだ。
なんでもいいから簡単なプログラムを覚えて、
まずどのようにプログラムが動いているのかってことを理解する。
そして次に、仕事で必要なJavaなどの言語を学ぶ。
それがある程度使いこなせて初めてEJBを学ぶ価値が出てくるのだ。

前にも言ったようにEJBはJavaのパッケージ集だ。
要するにJavaを使えないとお話にならないってわけ。
インターフェイスや例外処理、パッケージの扱い方。
どれも最近の言語には当たり前のように付いてる機能だが、
これをきちんと使えている人は少ない。

特に例外処理は、その仕様を把握していないと
ひどいプログラムが出来上がってしまう恐れがある。
全部Exceptionで受けてたり、throwとcatchの使い方がメチャクチャだったり。

そんなわけで、彼がEJBを覚えたとしても
結局は「サンプルが理解できた程度」に過ぎない。
ただ、これにしろたった3日でマスターできるとは到底思えないが。

--- 基礎 ---
どんなスキルにだって基礎がある。
基礎があるから、それをより良くするための応用論が生まれる。
もちろんそれらのやり方は便利でありスキルを高めるのだが、
だからといって基礎の重要性が少しも失われたわけではない。

NBAのスーパースターだって、
毎日試合前の練習ではゴール下のシュートから始めるという。
それが一番大事なことだと知っているからだ。

プログラムにおいても、基礎が大切だ。
基礎は初め覚えるのは簡単だが、実は一番奥が深いってこと、知ってた?
ゴール下のシュートを何千回、何万回と打つうちに
また新しい発見が生まれたりする。
それはとても高度なテクニックのヒントかもしれない。

基礎を笑うもの、基礎に泣く。

・・・そんな諺ありません(笑)。

--- 仕様漏れ ---
いつになったら終わるんだろう。この仕様漏れの嵐。
なんか一つ修正をするたびにまた別の問題点が浮上してくる
この仕様の駄目さ加減は一体誰の責任だろうか。

SEからすれば「相手先がちゃんとした仕様を言わない」とか言うだろうが
そういうのはこっちから聞かなきゃ、いつまで経っても解らないぜ。
なぜなら、相手先もよく解っていないからだ。

プログラムも「プ」の字も解ってない相手に
完璧な仕様を求めること自体が既に間違っている。
そういうのはこっちで詰めていくのが当然だろう。
わからないことがあったら相手に聞けば済む事なんだし。

--- XPスタイル ---
もし、コーディングに全く手を付けない段階で
(相手先との会議などで)完全な仕様を作ろうとしているとしたら、
そいつは大きな誤解をしている。そんなことなど不可能なのだから。

XPスタイルと呼ばれるコーディングスタイルでは、
一日ごとに完成品を相手先に見せて
その反応をダイレクトに受け取り仕様を固めていく。毎日だ。

さすがに普通の現場でそこまで出来ないとしても、
せめて1週間に1度くらいは相手と仕様の確認をしていかないと駄目だ。
1週間コーディングをしていて全く問題の上がらない仕様などまず存在しない。
仮に全く問題が上がらないとしたら、それは「全くプログラムが進んでいない」
という理由である可能性が高い。

--- 苦労のかいあって ---
今週の金曜は代休をもらえることになりました。
これで週末は3・連・休♪
ちょっと嬉しくなった僕でした。じゃ!

2002/07/23(火)
無題
--- 珍しく ---
今日はいつもより一本早く電車に乗ってみました。
が、やはりこの車両は混んでる。
疲れた・・・やっぱり明日からは通常通りに戻そう。

--- EJB考察 ---
今日も引き続きEJBのお勉強。
どうやら、EJBというのはあまり綺麗な作りでは無いようだ。

コンテナ管理というのを使えば
プログラムでDBアクセスを意識する必要が無いのだが、
結局はその情報をxmlに記述してコンパイルしてあげないといけない。
しかもその記述法が特殊で

?1]]>

みたいなやつなのだ。
結局これって、あまりプログラムを知らない人でも
簡単にDBアプリが作れるっていう利点しか無いんじゃないだろうか。
要するに、「まず出来る人がEJBコンテナのロジックを記述する」
→「初心者がそれを使って安全にアプリを作る」
っていう構図が出来上がっているように思える。

--- 初心者向け? ---
僕みたいに全部自分でやりたい人には
かえって面倒くさい気がするし、何よりデバッグが大変だぞ、これ。
やっぱり僕が初めに思ってた「初心者救済システム」のような
匂いがプンプンする作りだ。

確かに便利は便利だけど、これだったらJava使う意味あるの?
って気がする。Javaブームの便乗商品にしか見えません。
そしてこういうアプリの一番の問題点もある。そう、スピード低下だ。

特にEJBっていうのはDBアクセスがメインだから、
スピードの低下は即ちDBサーバの負荷にも大きく関わってくる。
おそらくパフォーマンスは半分くらいに落ちるだろうね。
大規模なアクセスのあるサイトでこれは死活問題だ。

とはいっても、それなりに普及してるらしいから
僕もいずれマスターする必要があるのかも。

--- サボリ? ---
なんだなんだ、今日はプロジェクトのメンバーがかなり少ないぞ。
こんなことなら僕も休んじゃってもよかったかも。
全然やることないし。
でもそうすると金曜に休みづらくなるからな?。

--- 東京の月 ---
会社帰り、駅から家までの間
天気が良ければ月が真正面に見える。もうそろそろ満月だ。
東京の空はもっと汚れてると思ってたけど、
少なくとも僕が住んでる街は緑も多いし空気も綺麗だ。

だけど中にはとんでもなく環境の悪いところもある。
僕の会社の本社がある南青山なんかは正にそう。
駅を出た途端、汚れきった空気が僕を襲う。
生まれつき喉が弱い僕は、本社に行くまでに咳が止まらずに困る。

ほんと、あれだけはどうにかしてほしいぜ。

2002/07/24(水)
無題
--- また。 ---
例の「終わってる人」改め「休んでる人」は今日もいない。
もうプロジェクトやめたんだろうか。
別にどっちでもいいんだが。

今月いっぱいでまた多くのメンバーが抜けるらしい。
というか元々今月末のプロジェクトだから当然と言えば当然か。
僕は終わりまで残らなきゃいけないので大変。
来月の5日?9日は相手先の会社行ってテストするらしい。
これが一番厄介だ。場所は田町らしい。うむむ、やや遠いな。

--- もう既に。 ---
今月末まで残る他のメンバーは、
既に次のプロジェクトのことで頭がいっぱいの様子。
なんか横では色々と話し合ってる。
良いものが出来るといいねぇ(他人事)。

--- 一体いつまで・・・ ---
今度はhideがコンサートを行うらしい。
確かにそういうことをすればファンが喜ぶのは解る。
解るが、はっきり言ってこれは主催者の金儲けの手段に過ぎないんだ。

尾崎豊にしてもそう。あれだけ多くの映像やら何やら見せられると
彼らは本当にこの世に存在しないのかと疑ってしまうことすらある。
おまえら、こんな事繰り返してるといつかバチ当たるぜ。

--- 設計者 ---
またこの話か、とクレームを受けそうだが。
なぜここの連中に限らず多くの人間は
設計者とプログラマを完全に分割して考えるのだろう。

「プログラム出来なくてもいいから設計者が何人か必要」
殺意すら覚えるね、こういう言葉を聞くと。
プログラムも出来ねぇのに設計書書けるわけ無ぇだろうが。
どうやったらこんな思考が出てくるのか奴らの脳を疑いたくなる。

ただし原因なら解る。
奴らが設計かプログラムのどらちか(あるいはどちらも)の事しか
知らないからだ。
両方を知っていれば、とてもこんな思考は浮かんでこないだろう。

いい加減、こういう腐った発想は捨ててくれ。

--- 今さら ---
現場では今になって文字コードがどうとかいう話で騒いでいる。
おいおい、そんなこと今さら言うなよぉ。

家建て終わった後で
「あれ?この物件って床暖房なんだっけ?」
って言ってるようなもんだぞ・・・違うか(笑)。
そんなんで一日潰す彼らの仕事の遅さにも閉口するけど。

おかげでこっちはず?っとswingアプリのお勉強だぜ。
グラフィカルDBアクセスツールで中々良いのが無いので
自分で作ってみようと頑張っているのだぁ。
まぁおそらく中途半端で終わると思うけど。
こういうのって意外と面倒なんだよね。

--- 昔の流れ ---
やばい、今日は進捗がまだ始まらないぞ。
上が仕事詰まってくるといつもこのパターンだ。
この流れはもう過去のものだと思ってたのに・・・
始まる気配すら無いもんな。

それにしても何であんなことで時間掛かってるんだろう・・・
ただいま18:30。もう眠くなってきた(早っ)。
30分遅れて無事終了。じゃ、帰ります。

2002/07/25(木)
無題
--- 不安な質問 ---
きょう一生懸命仕事してたら(嘘つけ)、
なんだか頭の悪そうな頼りなさそうな人に
「Javaって使ったことあります?」
とか聞かれる。

「あの?・・・今のプロジェクトもJavaなんですけど・・」
と答えると、
「あっ、使えるのね。わかった」
と言いどっかに去っていってしまった。

あれってもしかして次のプロジェクトに関連する
ことだったんだろうか?
でもあの聞き方だとまたJavaの初心者プログラマとして
使われる可能性が高い。

なんだかな?、もう少しやりがいのある仕事したいんだけど。
次のプロジェクトの内容次第では
この現場も「捨て」にしようかなぁ・・とか思ってしまった。

--- 回りくどい ---
某休んでるSEに仕様の不備を指摘。
ごちゃごちゃ言い訳はいいから、早く直してくれ。
まったく回りくどい人間だぜ。

・・・あれ?DBのデータが消えてるぞ?
まさか奴、たった一つDBのカラム追加しただけなのに
全データ取り込み直してるのか?シャレになってねぇぜ。
やっぱ「仕事遅い王」の栄冠に輝いた(俺の中で)だけのことはあるな。

--- 3連休 ---
ふっふっふ。先週頑張ったおかげで
俺は明日からの3連休を勝ち取ったぜ。
というわけで今日は早く帰りたいのに・・・
進捗よ、始まれー!

--- しょぼ。 ---
先週の土曜、仕事の合間に珍しく吉野家に行ってみた。
例の価格戦争後に行ったのは初めてだったんだけど
その値段の安さに納得。
こんだけしょぼい品物ならそりゃ280円でも出せるよ。

以前行ったのはもうだいぶ前だからよく覚えていないけど、
明らかにもうちょっとマシだった気がする。
僕は薄っぺらでスジだらけの牛肉が数枚乗った程度の丼を
金払って食べる気には到底なれないよ。

--- やはり ---
ちょはっかい君がダメダメで困る。
なんか仕様修正が入るらしく、今まで8桁だったものを
9桁にしてほしいという。
で、そのとき奴の言った言葉。

「これって簡単に出来ます?」

簡単に決まってるだろうが。たかが一桁増やすだけだろ。
それよりも、これが簡単かどうかも解らないことの方が問題。
今日も進捗が遅かったのでやること終わらせて速攻で帰宅。
明日から3連休!日記もしばらくおやすみ(笑)!?

2002/07/27(土)
無題
よ?し、休み中にも日記書くぞぉ!
・・・ネタが無い(笑)。

とりあえずJava+Swingアプリ勉強のためにDBアクセスアプリ作ってます。
結構使いやすいものが出来つつある。
JDK(JRE)の1.4使うとホイールマウスにも標準で対応してるので便利。

やはり休日は書くことがそれほど無いようだ(笑)。
そんなわけで。じゃ。

2002/07/29(月)
無題
--- 交通費込み? ---
先日、営業の人から給料明細をもらう。
結局、交通費が出るようになったといっても
手取りは前と一緒。これじゃ全く意味をなさないぜ。
今まで通り「給料は交通費込み」って言い切った方が
まだいいと思うんだけど。どうだろう?

--- RMI ---
前から細々と勉強しているEJB。
そのロジックの基盤となっているのが
Javaが標準で搭載しているRMIという概念だ。

RMIとは、一言で言えば「分散オブジェクト」を扱うパッケージのこと。
一般的にはHTTPを通じて外部のJVMとのやりとりを行う。
これに色々な機能を付けてパッケージングしたのがEJBだ。
つまり、RMIを理解していないとEJBの本質を理解することなど出来ない。

EJBの技術者が欲しいと言っている現場の面接で
「RMIは理解していますか?」と聞く面接官が一体どれほどいるのだろう?
ほとんどの上層部はEJBといういわば「ブランド名」だけに取り付かれて
その本質を理解していない。

--- パッケージ依存性 ---
僕ら開発者にとって大切なことは「柔軟性」だ。
EJBという「市販パッケージ」だけを信頼してプログラムを組んでいたら、
近い将来このパッケージ内容が大幅に変更になったときに
多大な損害を被ることになるのだ。

僕が前働いていた会社は完全にMicrosoft依存症だった。
Accessなどのメジャーツールに頼った開発をしている。

たかが一つの会社(以下A社)の決定に、自社(以下B社)が大きく左右される。
これでは完全に親会社と子会社の関係ではないか。
しかし、どこからどう見たってA社はB社の親会社ではない。他会社だ。

--- 絶対的技術 ---
幸い、周りに左右されない開発というのは比較的簡単に導入できる。
CやJavaなどのメジャー言語は世界共通。
そしてRMIの「分散オブジェクト」という技術は
これらの言語以外でもほとんどの言語で使われている。

つまり、「RMIとは何たるか」さえ知っていれば
周りに依存しない開発が行える。
これはその会社にとって、とても大きいメリットになる。
もちろん、それを学ぶために多少の下準備は必要になるが。

--- Hashtable.getの罠 ---
現場でJavaを使い始めるとやはり色々な事が解ってくる。
今回悩んだのが、Hashtableでキーから値を取得するgetメソッド。
キーにString型などを使っていると問題ないんだけど、
これに独自クラスを使っていると何故かそのキーから値を取得できない。

悩んだ結果。Hashtable.getの詳細が掴めた。
それは・・・
1. 独自クラスでObject.hashCodeメソッドをオーバーライドする。
2. 独自クラスでObject.equals(Object)メソッドをオーバーライドする。

同じ内容?
その1。Hashtableという名の由来を考えれば納得なんだけど。
2つのオブジェクト内容が等しい場合、
これらのhashCodeは同じ値を返さないといけないのだ。

デフォルトのObject.hashCodeはどうやら内部アドレスを返すらしく、
「2つのオブジェクトが同一」でない限り同じ値を返さない。
先ほどと何が違うって?「内容」という言葉が抜けてるのがミソ。
これだと、

MyObject a = new MyObject();
MyObject b = new MyObject();

という宣言があった場合にaとbが違うhashCodeを返してしまうのだ。
aとbは違うオブジェクトだけど、内容は同じだよね?

equals(Object)
これが結構悩んだところ。
普通、MyObjectというクラスにequalsメソッドを入れようと思ったら

public int equals(MyObject obj);

とやりたくなるよね?
でもこれじゃ駄目なのだ。

public int equals(Object obj);

が正解。
内部でobjをMyObjectにキャストして(面倒だ...)
比較する必要があるのだ。

最終的には。
Hashtable.getメソッドはまずキー同士をhashCodeで比較する。
そして「hashCodeが同一ならばequals(Object)で比較」する。
この2つの試練?を潜り抜けて、ようやくgetメソッドは期待通りの動きをする。
やれやれだぜ(ジョジョ風に)。こんな複雑な仕様はドキュメントに書いておいてくれ。

一つアドバイス。
hashCodeは、内容が異なるオブジェクトが異なる値を返す「必要は無い」。
しかしその逆は成り立たない。
内容が同じオブジェクトでは同じ値を返す「必要が有る」。

なぜhashCode→equalsという2段階の比較方法を用いているかといえば、
高速化を促す為かと思われる。
要するにhashCodeが異なればequalsによる比較を行うまでもないという
前提があってこそ成り立つわけだ。

独自クラスで2段階の比較をする必要が無い場合、
hashCodeはとりあえず固定値を返しておけば問題ないと思う。
これならequalsによる比較だけでgetが行える。
もちろん「簡単な相違確認方法」があるのならば
それをhashCodeに記述するのが一番良いんだけどね。

--- 席替え希望 ---
・・・またうるせぇアホが近く来て騒いでるぜ。
まったくもってこの席は落ち着かない。
とりあえずはもう少しの辛抱だな。来週からは田町に出張の予定。

大掛かりな仕様修正が入ったらしい・・・気のせいだろう、きっと(笑)。
工数は2日。こんなんで来週から外部テストできるのか?

2002/07/30(火)
無題
--- 見事な逃走劇 ---
とうとう「休んでる人」が来なくなった。
今月いっぱいはプロジェクトに残るはずなのに
既に逃走体制に入ってるらしく姿が見えない。
こんな人材取る方も取る方だ。さっさと切っちゃえばいいのに。

--- ちょっとした変更 ---
昨日さらっと流した通り、プロジェクトに多少の仕様修正が入った。
とはいっても時間の猶予が無いので
やっつけ的なやり方で片付けようとはしてるみたいだ。
このやり方なら数時間くらいで終わりそうなので一安心。
最初聞いたときはどうなるかと思ったけど。

--- ちょっとした不具合 ---
今日テストをしていたら突然謎のエラーが出たらしい。
で、見てみるとOracleのエラーで止まっている。
これはまずいなぁ・・・と思い、今まで放っておいた
インポートモジュールを少し見てみる。

かなりアウチだ。
DBのコネクションを作りまくっている。
こんなんで今までよく動いてたなぁと感心(←してどうするっ)
とりあえず少し修正するが、まだエラーが出る。

どうしようかと悩んでるうちに、テスターから報告。
「もう一つのDBにつないだら出来ました」
まぁそりゃそうだろう。
そっちはあんまり多くの人が接続してないみたいだから。

--- 動けばいい? ---
動けばそれでいいのか?
まぁ市販パッケージではないから
特殊な環境でのみ動けばそれで済むことは事実だが。
あまりにも一般ユーザー的な発想には呆れる。

このモジュールって一応社内の資産として使ってるんだよ?
今後それを使おうとした開発者が困ることなどお構いなし。
それだったら初めから資産になどしなければいいのに。

中途半端な下準備は物事の効率を悪くするだけでなく
新しいものを作ることを妨害することにもなる。
尤も、新しいものを作る技術が無いから
こういった資産に頼ろうとしてるっていうのが本音なんだろうけど。

簡単な仕様書どころかJavadocのコメントすら無いこの資産を
僕はとても使う気にはなれない。

--- 入場許可証 ---
来週から客先のところに行くかもしれないので
許可証を作ることになった。
証明写真撮るのが面倒だな。僕は写真が大嫌いなのだ。

一つ重要なことを忘れていた。
来週の出張時の交通費は果たして誰が出してくれるんだろうか(笑)?
うちの会社からは出そうにないし、
かといってここの現場も社員にしか交通費は出ないみたいだし・・・
さて、結果はいかに!

2002/07/31(水)
無題
--- なめてる? ---
ちゃっかり休んでる人が来てるぞ。
う?ん、こいつは一回根性叩き直してやったほうが
いいんじゃないだろうか?
あんたのせいでリーダー大変な目に遭ってるんだぜ。

・・なるほど。
今日は上の人間と打ち合わせがあったから来たわけね。
「現在引継ぎ作業をやってまして」・・・なめとんのか、コラ。
昨日一昨日と休んでおいてよくそういう台詞が吐けるな。
こんなんでも次のプロジェクトでもまた使われることになったらしい。
早く切れ、こんな詐欺師は。

--- また延期 ---
どうやらここの大人は
「約束は破るためにある」と思っているらしい。
来週頭から行く予定だった出張もどうやら延期が決定。
アホ臭くてやってられんぜ、本当。

口では「前倒し」なんて言っておきながら、
現実に起こるのは必ずといっていいほど「後倒し」。
暗黙の了解?・・・腐ってるぜ。
そんなことだから平気で嘘がまかり通る世の中になっちまうんだ。

結局は形だけ、表面だけだ。こいつらが進化していく方向は。
周りを着飾れば着飾るほど、内部は確実に退化していく。
僕ら技術者っていう職業はモデルや芸能人とは違うんだ。

そんなのが時間を経て上位職に就く会社に、もはや未来は無い。
やっぱり日本はまだまだ年功序列社会だ。
こんなんじゃ外国からどんどん離されていく一方だぜ。
実力主義が通用するのは、観客という第三者が存在する
スポーツ界ぐらいだろう。

--- 修正終了 ---
昨日も話に出た仕様変更の案が固まったらしいので
早速作業開始。午前中で終了・・う?ん、意外と簡単だったね。
仕方ないので(?)しばらくはJavaのLook&Feelについて勉強。
夕方過ぎになってから正式にリリースしてみる。
どうせテストは進まないだろうから今日は早く帰れるだろう。

--- Look&Feel ---
プログラムにおいて最大の課題は、未だ画面関係にあるらしい。
プラットフォーム共通言語として開発されたJavaでは
その問題はさらに悪化している。

理想は、全てのプラットフォーム(OS)において同様の表示が出来ることだ。
しかしこれはやや無謀な考え。
そこで考え出されたのが、Look&Feelというインターフェイス。

「見ろ、そして感じろ」。
・・・いや、違うか(笑)。とにかく各プラットフォームにおいて
同等の操作が出来る程度の表示ができるように統一しようということ。

ご存知のように、これをいち早く実現したのがHTMLによるWeb環境だ。
管理人は、HTMLでさえ記述すれば
どんなクライアントに対しても同等のコンテンツを提供できる。
もちろん、IEやNNなどブラウザの変化によって多少のズレは生じるが
基本的な画面表示において
もはやそのズレはほとんど無くなってきている。

--- 大きな欠点 ---
JavaのLook&Feel機能にはHTMLと大きく異なる点がある。
ずばり、カスタマイズがとても面倒なのだ。
HTMLではCSSを使うことによって比較的簡単にレイアウトを変更できる。
これがLook&Feelではそうはいかない。

30個を超え、総計500KBにも及ぶJavaファイル。
これを自作する必要が有るのだ。
もちろんデフォルトのソースを見て修正を加えれば良いのだが、
システムプロパティなど様々な要素が絡まって
とてもとても個人でカスタマイズできる難易度ではない。

結局はsun社から提供された3種類ほどのLook&Feelオブジェクトを
使い分けるくらいしか手段が無い。
これではとても「カスタマイズ」とは呼べないレベルだよね。

とにかく、スクロールバーの色でさえ
メソッドもしくは実行時プロパティレベルで変更が出来ないのは
あまりにも貧弱だ。
たかだか色変更するだけのために
膨大な量の自作パッケージを作る気にはとてもなれない。

とりあえずカスタマイズは我慢して
デフォルトの構成で使うのが無難だね。
ただそれじゃとても市販アプリには使えないけど。
見栄えが大事だからね、売り物っていうのは。

--- 発つ鳥跡を濁さず ---
休んでる人からメールが届く。
今までお世話になりましたという例のアレ(?)だ。
そうさ、ああいう人間が仕事続けるには
こういう大人の配慮が必要不可欠なんだろうな。

俺からすれば「んなもん送ってくんじゃねぇ」ってトコロだが。
偽善者からの謝礼ほど貰って嫌なものは無ぇぜ。

--- 18:00 ---
一日の中で僕が最も眠くなる時間だ。
その時間に進捗でもやってればボーっと過ごせばいいので(ホントか?)
楽なんだけど、進捗が始まってすらいなかったりすると相当眠い。
ちなみに今日もその状況だ。

おっ、今日はリーダーが休みなので進捗がないみたいだ。
にしてもこっちから聞くまで何の連絡もないのには困ったもんだぜ。
じゃ、今日はこの辺で。

2002/08/01(木)
無題
--- 8月 ---
もう8月だ。
世間では夏休みのせいか朝の電車は少し空いてる気がする。
それにしても外の暑さと電車の中の寒さはまるで別世界だ。
20℃くらいは違うんじゃないの?

--- セキュリティ ---
時代は情報社会だ。
世の中が便利になればなるほど、それを利用してまた犯罪が生まれる。
結局はそのいたちごっこだ。
システムを作るのも人間、犯罪を犯すのも人間。
片方だけが進化することなど有り得ないのだ。

これらのシステムで最も重要なものがセキュリティだ。
社会は今、住基ネット問題で揺れている。
全国民をIDで管理しようとするシステムだ。

「全国どこからでも簡単に個人情報が閲覧できる」
このシステムのキャッチコピーだ。
言うまでもなく、これは明らかに犯罪者の入り込む隙があるシステム。
いずれ全国中の個人情報は一つの闇組織に操られるようになるだろう。

--- プアーProject ---
今日、この部署のボスから話し掛けられた。
「作業はいつ頃終わりそう?」
一応、来週に相手先に行くというところまでは決まっているのだが
それ以降どうなるかは解らないと伝えておいた。

やはりボスも「余りにもプアーなメンバーで組みすぎた」
ことは自覚しているようだ。プログラマが新人だらけだからね。
しかしそれよりも重要な
「SE陣はもっとプアーだった」ことを彼は知っているのだろうか。
尤も、最大の要因は「相手先からの報酬がプアーだった」ことなんだろうけど。

僕には早く次のプロジェクトに移ってほしいらしいんだけど
あいにく現プロジェクトの終わりがまだ見えない。
それに夏休みも取りたいんだけど・・・
次は「ノーマルProject」級であることを願うぜ。
もしも「プロジェクトX」級だったら・・・ちょっときついな(笑)。

--- 月の進捗 ---
しまった。今日は月に一度の全体進捗があったんだった。
いや、本当は知ってたんだけど(笑)。
先月行ったけど何も無くて行く必要ないなぁ、とか思ったんで休んでみた。
朝早いと電車も混んでるしね。
じゃ、また。



Limyweb