カテゴリ別表示

全体

最近の日記

仕事納め
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
2003年5月の日記

2003/05/01(木)
間の3日
なんか連休に挟まれた平日は
いつも以上にやる気が出ないのだ。
当然のごとく4/29に休んだのは…まぁ言うまでも無いでしょう(笑)

今週も大してやる事は無さそうなので暇だ。
で、何とか見つけ出した暇潰しが…

--- 恐るべきフレームワーク ---
前にも言ったけど、このプロジェクトは
N研のオブジェクトワークスというフレームワークを使っている。
帳票なんかを作るソフトも付いてるのだが、
これがまた最悪にひどい代物らしいのだ。

何でも、今回帳票レイアウトの修正作業が入ったらしいんだけど
その修正にえらい手間が掛かるらしい。
なぜ最悪かっていうのは、その理由を聞けば判る。

--- 史上最悪? ---
「微調整の為の座標修正が思うようにいかない」
例えば「この欄を少し左に動かしたい」と思ったとしよう。
普通だったら、そういう時はズームアップするか
確実なのは直接座標を数値で指定する方法だよね。
それが出来ないのだ。マウスでオブジェクトをドラッグするという方法しか取れない。

が、これだけではまだこのソフトを史上最悪と認める訳にはいかない(笑)。
すごいのはコレ。

「オブジェクトの座標が表示されない」
そんな馬鹿な話があるだろうか。
これじゃ、複数の帳票レイアウトを統一することなど不可能だ。
ユーザはただ手探り状態でオブジェクトを動かし、
「だいたいこの位かな」という勘でオブジェクトの位置を決定する。

--- 事実上不可能 ---
そして、用意されているズームモードは最大で200%しかない。
その大きさにしても、座標の最小単位である0.1ポイントは
画面上でわずか1ドットの大きさにしかならない。
ドット絵経験のある人なら判るだろうが、
数値表記無しで画面の1ドット単位をマウスで正確に動かすことなど到底不可能だ。

ここまで話せば解ると思うが、このソフトは最初から
そこまで細かい帳票を作成できるような作りにはなっていないのだ。
それなのに頑固なまでにこのソフトを使い続けるのは
もはや気が触れてるとしか言いようが無いね。

--- 本気? ---
で、既にそのレイアウト修正を経験した事のあるメンバーはこう言う。
「すごい紙いっぱい消費しますよ」
初め何のことか判らなかったが、少し詳しく話を聞いて驚いた。

つまり、画面で修正しただけでは
微調整がうまく行っているか判断できないので
印刷して確かめているというのだ。
微調整→印刷→確認、微調整→印刷→確認、………

なおもメンバーは続ける。「1帳票仕上げるのに1日は掛かりますよ」
本気でそう話す彼はまだ入社1年目。何も知らないから仕方無いとはいえ、
こんな超非効率な開発をやらされているのを気の毒に思ってしまった。

--- 最良の方法 ---
思いっきり話が横にそれたが、最初の段落からの続き。
そう、やっと見つけた暇潰しとはずばり「データ解析」だ。
当然、この帳票ソフトでは独自のデータ形式でデータを保存してるので
普通に考えればレイアウト修正をするにはこのソフトを使うしか無い。

が、そんなのは素人の考え。
そこに帳票のファイルがある限り、このデータを編集する方法などいくらでもある。
という訳で、今週は仕事も無いのでこのデータを解析することに決めた。

細かい部分は放っておいて、あくまで座標修正という観点からのみ解析を進めたので
昨日から始めた解析作業も今日でほぼ終わった。
これでいつレイアウト修正の作業を振られても大丈夫だ。
あんなゴミソフトを使い丸一日費やして1枚の帳票を仕上げるなんて事、
根性の無い俺には到底不可能だ。
プログラマやSEは、常に最良の方法をチョイスする事が可能なのだ。

--- いよいよヤバい? ---
このプロジェクトは、公社→N社→E社という繋がりになってる事は前にも話したっけ。
そのときの僕の予想では、E社がN社に切られるのも時間の問題だって書いたけど
どうやら現実は、N社が公社に切られる寸前まで来ているらしい。
元々は別のところが開発してたのだが、公社が諦めてN社に回したという話だ。

何だ、これじゃ昔のC社のときと一緒じゃないか。
当然、N社が切られればE社もお払い箱。
僕も晴れてこの現場から抜け出せるという寸法だ(笑)。

--- 結局一緒 ---
現実は大抵こうだ。恐らくN社が切られて別のところが担当したとしても
同じような状況は続くのだ。
どこの開発会社のレベルもこんなに低すぎるっていう現状は
同じ業界にいる人間として情けないね。

まっ、でもこれでますます俺が活躍できるチャンスが増えたって事だ。
一刻も早く、自社で一括の仕事を受けたいもんだね。
いつまでもこんな所で油売ってるのは時間の無駄でしか無い。

だからと言って僕はまだフリーになる程の自立性も持ってないから
会社を辞めるつもりは無いけどね。
しばらくはこうやってぬるま湯に浸かりながら、家でスキルを磨く生活を続けましょうか…

2003/05/02(金)
まずは前フリ
ここの現場でも、他の現場と同じように
サーバマシンは「開発用」とか「総合機」とか複数存在している。

ソース管理はCVSで行ってるので便利。
そして、毎日2回くらいのタイミングで開発用マシンにCVSから更新をかけて
全コンパイルしているようだ。
当然手作業だと思うけど、そんなに労力の掛かる作業じゃないし
まぁ許せる気がする。

--- 何故? ---
が、その環境を総合機に上げるのを何故か全て手作業で行なっているらしい。
総合機と開発機にあるファイルの修正時刻を調べて、
総合機の方が古いファイルだけを手作業で開発機→総合機にコピー。
なんでこんな面倒な事をするのかがさっぱり理解できん。

しかもそのせいで、当然「漏れ」が出てくる可能性も高くなる。
今日も、数日前にとっくに修正したバグが総合機で発生するという現象が起きて
調べてみたら結局ファイルの上げ忘れだった。
そんなつまらん事に時間割かせるなっつーの。
いや、時間つぶしの材料を与えてくれたのだから感謝すべきか(笑)。

--- 自動化 ---
毎日毎日こんな無駄作業繰り返してたら、普通もうちょっと
効率良くやろうとか思うだろうよ。
ちゃちゃっとスクリプト書くだけで完全自動化できるのに。
Meadowと組み合わせれば完璧だぜ。

--- 日課 ---
最近天気が良いので、5時過ぎくらいに恒例の散策コース(笑)に出かける。
前の現場で身に付けた暇潰し作戦だ。
約15分くらい、グルッと周るように歩くだけで気分はリフレッシュだぜ(笑)

2003/05/04(日)
うちもかよ
昨日は地元に帰って恒例の飲み。
今日は夕方頃まで実家でのんびりしてからまた帰ってきました。
で、実家であるものを発見。発泡酒のダースだ。

ご存知の通り今月から発泡酒が値上りしたので買い溜めしたんだろう。
昨日の飲みで友達がそんな話をしてたんだけど、まさかうちもとは。
「ブルータス、お前もか!」って感じですな(謎)

--- 困るんですけど… ---
通販で掃除機を紹介している。
「ほらほら、何でも吸いこんじゃうんですよ?」
ガラスの破片なんかはいいとして、硬貨まで吸いこんじゃうのはどうか。
逆に困ると思うんですけど…

--- 芸術の左 ---
レッジーナvsローマを観る。
試合は敗れたものの、最後の最後で中村がフリーキックを決めた。
ホントすっげ?な、あれは。
ゴール右上隅ギリギリ。あれじゃ誰も取れねーぜ。

もし将来、動画の絵画なんてものが開発されたら
ぜひ家の壁に飾っときたい一品だな(またも謎)

2003/05/10(土)
今月か来月
今の現場は一応6月までというのが最初の予定だったんだけど
あまりにも酷い現場なのでなるべく早く辞められるように
営業の方に前々から言っていた。

そのかいあって、もしかしたら5月末で辞められる可能性も出てきた。
来週中にはちゃんとした回答が出るとのこと。
さて、どうなりますか…

--- 続・Struts ---
また最近になってStrutsをやり始めてる。
Tomcatの管理アプリケーションもStrutsで作られてたり、
そろそろTomcatパッケージに正式に含まれる日も近い感じなので
今後の為に、という事で。

始めた当初はその動きに四苦八苦していた訳ですが、
最近はようやく流れも見えてきた。
ただ、自作JavaScriptとの連携がちゃんと取れないのは残念。
完全にIE専用の作りになってしまうのだ。
いい加減、NNもdocument.allを装備してくれ…

2003/05/12(月)
たまには…
この現場に入ってからは珍しくちゃんと月曜に行ってたので
たまにはこういうのもいいかな。
今日は家でのんびりすることにする。

--- ログ解析 ---
やっぱり何かやってないと気が済まないので、こんな事をしてみる。
通常のログ解析はanalog等を使えば充分なんだけど
唯一気にいらないのが検索単語レポート。
どれも日本語対応が今いちで英単語しかまともに解析してくれないのだ。

という訳で、検索単語の解析に絞ったプログラムを自分で書いてみる。
大まかな部分はすぐ出来たんだけど、面倒なのが文字コードの特定。
クエリー文字列(URIの?以降部分)で明記してあれば簡単なんだけど
省略してあるものが多い。

サイト毎にデフォルトの文字コードをハードコードするのは格好悪いが
他に良い方法が見当たらない。自動判別するのはあまり好きじゃないし。
しかも同サイトでも条件によって文字コードが変わったりと相当ややこしい。

悪戦苦闘の末、99%程度の命中率には仕上がった。
でも、また新しい検索サイトが登場すればプログラムも修正する必要があるな。
というわけで、結果はこれ

2003/05/13(火)
大量投入
現場に新人が4人も入ったようだ。
昨日休んでたから知らなかったぜ(笑)

僕の両端にも1人ずつ入った。
左隣はどの現場にでもいる(?)せっかち君。
開発の工程方法やフレームワークの事なんかを必死で尋ねている。

ふふふ、やる気あるねぇ。
でも大抵この類の人種は1ヶ月もすればボロが出てくるんだよね。
いわゆる口だけ君ってやつだ。
まぁ彼がそうだと断定する訳じゃないけど。

--- マジ? ---
そして僕の右隣はというと…
昨日から来ているはずなのに、まだマシンのセットアップをしている様子。
どうも、昨日セットアップをしたんだけどWindowsが立ち上がらなかったらしい。

で再チャレンジをしてるものの、まだうまくいかない模様。
どうせHDでもイカレてんだろ。
結局、僕が帰るまでにセットアップは完了しなかったようだ。
明日になってもまだやってたら笑えるな。

--- 新たな光 ---
夕方頃、営業の人から連絡があった。
なんでも次(=この現場が終った後)のプロジェクト候補が見つかったらしい。
しかも6月から新規で始まるプロジェクトらしく、なかなか内容は良さそうだ。

前にD社の現場で一緒だった人も面接を受けるらしい。
という訳で、もしまた一緒になったらよろしくお願いします(笑)。

--- swing ---
ただ、swing使おうとしてるっていうのが気掛り。
swingっていうのはJavaに標準装備されているグラフィックライブラリなんだけど、
とにかく遅いのだ。到底実用で使えるレベルには達していないというのが僕の感想。

今だったら勢いを伸ばしつつあるSWTがお薦めだね。
これはEclipseで使用されているネイティブ・グラフィックライブラリで相当速い。
しかもswingとほぼ同様の作りになってるらしいので
互換性もバッチリのはず。swingで出来てSWTで出来ない事があったら困るんだけどね。

--- 大切なのは役割 ---
僕が次からの現場を選ぶ基準にしたいのは
言語や環境なんかでは無く、自分に与えられた役割だ。

今の現場にしても、素人同然の上層部が作った仕様に沿って
俺はただ作業してるだけ。
プログラムを整理しようにも、それをやるには全てのプログラムを作り替える必要がある。
その為に人員や時間をスケジューリングできるような権限が
僕には与えられていないから、そんな事は結局無理なのだ。

--- 新規プロジェクト ---
でも、新規のプロジェクトならそれが少なからず可能だ。
プログラムはまだ存在していなく、これから作る段階にあるって事は
共通化等によってプログラム構成を変える事は比較的簡単なはず。
上の人に直接言える環境にあれば、の話だけど。

今日聞いた案件は6月からって事だから、
今月いっぱいでこの現場を辞められれば丁度都合がいい。

営業の人もなるべくその方向で行かせてくれるって話なので
後はその流れがうまく進むようにチョコチョコ仕込んでいけばOKだろう。
月曜日休むとかね(笑)。

僕がやる気無いのは現場も判ってるらしいので、
そんなに辞めるのは難しくないとは思うんだけど。
まぁ、精一杯頑張ります…辞められるように(笑)。

2003/05/14(水)
暇すぎ
つらい…今日俺が現場でした事といったら何だろう。
Javaのドキュメント読んでたくらいじゃないか?
ホント苦痛だ。とにかく5月いっぱいでこんな現場終わりにしたい。

が、初期の契約が6月末って事で、簡単に辞められる状況でも無いらしい。
でももう俺には6月以降も続ける気力がございませんぜ…

--- 今できる事 ---
そんな訳で、今俺にできる事は現場で大量に与えられた暇な時間で
数々のドキュメントを読み漁る事くらいだ。
とはいってもネットに繋がってないので
家で資料集めていかないとどうしようも無いんだけどね。
とにかく、少しでも無駄な時間を減らしたいという気持ちで一杯だ。
明日はどんな資料持っていきましょうか…

2003/05/15(木)
暇でしたが…
今日も暇なのでひたすら資料読みモード。
昨日用意しておいたSWTとJDK1.4が役に立ったぜ。
とか思っていたら、6時半になって会議。
そこで驚くべき展開が待っていたのだ…次号に続く(嘘)

--- 先週の出来事 ---
先週の水曜あたりにスケジュールが発表された。
内容はなんとドキュメント作成だ。
もう総合テストまでやっている段階になってからこんな事やり出すとは
いつもの事ながら理解不能。

1画面に3日*4。各画面の最終日にはレビューが行なわれる事になっていた。
が、当然の如くいつまで経ってもレビューをやる気配が無い。
まぁそんな事を気にしてたらやってられないので、放っておいて作業を進めていた。

--- こんな展開 ---
そして今日の会議だ。
レビューをしなかった事などには触れもせず、
新たなスケジュール表を配るメガネ君(初登場)。

今週から入った新人もスケジュールに入っているのだが、
問題はその配分。
1画面を3人で手分けしてやると抜かし出したと思えば、今度は
「2画面を1日」という割り振りでスケジュールが組まれている。

単純に前回の倍の作業になってたという訳。
そんなの無理に決まってるじゃねーか。しかも来たばっかりの新人に対して。
俺が調子こいて4画面を3日程度で終わらせてしまったのがいけなかったらしい(笑)

--- ペース ---
別に俺は構わんが、後から入ってきた彼らがかわいそうだ。
正直言って、彼らに僕のペースと同じペースでやれというのは無理だと思う。
別に己惚れてる訳では無く、今までの経験からいって多分これは当たってる。

他にも突っこみ所満載のスケジュール表。
なんで夜の7時に配るスケジュール表に今日の予定が入ってるんだ。
こんなの遅れるに決まってるだろ。それとも何か?残業してやれってか?

そして、根本的に1日2画面というペースで進行する事などまず不可能だ。
前回のこともあったので、メガネ君に確認を取る。
これは「本当にやるつもりのスケジュール」なのか
「あくまで上層部を安心(騙すとも言う)させる為の偽スケジュール」なのか、ということ。

--- 崖っぷち ---
一応本人曰くやるつもりはあると言うので信用する事にする。
が、おそらく本心では彼も可能だとは思ってないだろうね。
もし本気でそんな事を思ってるとしたら、よっぽどの無謀な自信家か
自分の正しい力すら評価できないダメダメ君のどっちかだ。

今まで散々後倒しにしてきたスケジュールも、これ以上伸ばせないという事で
無理矢理に線を引いたんだろう。まっ、少しは同情してやるか。

--- 僕はあくまで… ---
というわけで。
会議ではメガネ君の余りの無謀さに呆れて散々突っついてやったんだが。
よく考えれば別にそんなに目くじら立てる事でも無いかな。

僕に負担が掛かる訳では無いし。
また明日からいつものペースでやるだけだ。
ただこれで、ますます今月いっぱいで辞めたいと思う気持ちが
強くなったのだけは確かだね。こんなのに付きあってたら疲れ過ぎるぜ。

--- Javaの進化 ---
いきなり話飛んですまん(笑)
今日JDK1.4のドキュメントを読んでて思った事。
1.4では、かなりパフォーマンス(実行速度)を上げる為の機能が増やされている。

ioパッケージの拡張機能であるNew I/O APIと呼ばれるnioパッケージや
コレクションクラスの拡張など、かなり興味深いものが多い。
そのうちまたドキュメントにでも起こすかな。

2003/05/18(日)
あと2週?
さて、5月もあと2週間。
事がうまく運べば、それで今の現場とはおさらば。
まだ正式決定の連絡が来てないので何とも言えないが、
このままじゃまた週3程度の出勤が限界になってしまいそうだ。

ちなみに、先週は3日出勤でした(いつの間に?)
さすがに4連休する訳にもいかないので明日は行かないとなぁ…

2003/05/19(月)
嬉しい報告
今日の昼過ぎに会社の人から電話が入った。
今の現場を今月いっぱいで辞められる事が正式に決定したらしい。

次の面接も明日に入るってことで
とりえあず事は順調に進みそうだ。
明日の面接は結構良い所らしいから気合い入れていかないとね。
これまではいつも適当にやってきたから(笑)

--- またまた ---
先週、現場に新人が4人も入ったって話はしたけど、
今日もまた新しい人物が2人ほど入ったようだ。

今までは、とてもリーダー格とは呼べないメガネ君が一人で仕切っていたが
やはりこれでは駄目だと上が判断したんだろう。
新しい2人がリーダーとして呼ばれた様子。

--- もう遅いって… ---
そして会議。新リーダーが熱弁をふるう。
やる気は解るが、それはこのメンバー達の実力を把握してから言ってくれ。
その割には、「今年中にはちゃんとしたものを…」とか言ってる。
5月の中旬からそんな事言わんでくれ。そんなのんきに開発してる余裕があるのかよ。

まっ、もはや俺には全く関係の無い事だ。
俺が今月やる事はしょうも無いドキュメント作成だけだからね。
そして、そのノルマも今日一日で完了してしまった俺はこれからどうすればいいんでしょ(笑)

2003/05/20(火)
面接
今日は早速面接。
現場を途中で抜け出して東銀座へ。

で、感想。なかなか内容の良さそうな仕事みたいだ。
Javaのswingを使ったフレームワークを使ってるっていうのが唯一気掛りだけど、
話を聞いた限りではそれほど悪い作りでも無さそうだ。

--- Agile ---
この現場で採用されている開発スタイルがこれ。
アジャイルって何ぞや?と思い、少し関連ページを調べてみた。

--- 今までの流れ ---
従来の開発工程というのは大まかに言って
「基本設計→詳細設計→プログラミング→テスト」という流れだった。

相手先の出した案件に対してSEが基本設計をする。
そして、この設計で果たして
客の希望するシステムが実現できるのかどうかを検証し
客からのGOサインが出ればその仕様を元に詳細設計が始まる。
そして、その詳細設計をプログラマに渡しコーディングを任せるという流れだ。

--- 理想と現実 ---
が、この流れはあくまで理想論に過ぎない。
実際に開発をしてみれば、コーディングをする段階になって
基本設計の不備が見つかる事が多い。

そしてこれをどう解決するかと言えば、
開発側はその為に必要な仕様を修正し相手先に「仕様変更」の資料を渡す。
これにより新たな時間、人材、賃金が追加され開発工程は大幅に遅れてゆく…

--- 柔軟な対応力 ---
プログラム開発は、こういった流れ作業では絶対にうまくいかない。
これは僕自身常々思ってきた。

なぜなら、コーディングもしていないのに仕様の全てを決定してしまう事など
絶対に不可能だからだ。
コーディングをしていく上で、今まで考えていた仕様を
修正しなければならない事態は必ず発生する。

従来の開発スタイルでは、
コーディングに入ってから基本設計を変更する事はまず無い。
しかしそんな事では、効率的な開発が行えない。
強引に仕様に従ってコーディングしてしまうと、その後の保守や改良に影響をきたす。
結果的に、これはアプリケーションの質を低下させてしまうのだ。

--- 当たり前の概念 ---
アジャイルの概念の中で僕が最も気に入った点がある。

実際にシステムを構築しない限り、自分たちのシステムでも理解することは絶対にできない

これだ。この、僕としては当たり前の事実を認識している人間は驚くほど少ない。
なぜなら、今までのやり方では
設計をする人間はコーディングを全くしないからだ。

自分達(SE)が立派な仕様書を作れば、それで
素晴らしいシステムが完成するという考えが彼らにはあるのだろう。
だが、現実を見てみろよ。そんな事が実現された現場がかつて存在したか?
最終的にはプログラマに全てを押しつけてきたSEの罪は果てしなく大きいのだ。

--- 現実を直視せよ ---
アジャイルのアプローチは極めて現実的だ。
仕様を初めから決定するような事はせず、まずはプログラムを「ちょっと作ってみる」。
これが大事なんだ。その「ちょっと作る」を繰り返すだけで、
大規模なシステムを完成させる事ができるのだから。

ここの現場では、およそ2週間の周期でプログラムの「部品」を完成させ
それを検証するという作業を繰り返すルールになっているらしい。
以前紹介したXPに似ているが、こちらの方がより現実的なアプローチだと僕は思うね。

--- 結果は… ---
さて、今日の面接の結果は明日か明後日にでも報告できそうです。
面接自体はかなり好感触だったから、あとは入るべき枠が余ってるかどうかだね。
どうなりますか…

--- 大雨 ---
面接をしているあたりから段々雨足が強くなってきたと思ってたら
帰る頃にはどしゃ降りだった。参ったね。
まだ梅雨入りもしてないのに最近は雨ばっかり。
明日も雨だったら休んじゃうぞ(笑)、ホントに。

2003/05/21(水)
どっちでもいいか…
ふぅ、なんか今日は身体がだるいなぁ。
ちなみに今日は(も?)会社は休み。

ここで言っておきたいのは、身体がだるいから会社を休んだのでは無く
会社休んでゴロゴロしてたから身体がだるいのだ(笑)。
いや、別にどっちでもいいんだけど…

--- 検討中… ---
今現在、導入しようかどうか迷ってるものがある。
デジタルTV放送だ。

うちのアパートはケーブルが引いてあるから、引越してきた時点で
デジタル放送を観ることも可能だった。
でも僕が持ってるテレビは通常タイプだし、
特に見たい番組も無さそうだったから契約はしなかった。BSは観れるしね。

--- 調査開始 ---
が、最近になって観たい番組がデジタル放送でやっている事が多くなった。
もちろんその筆頭はNHKのデジタルハイビジョン放送な訳ですが(笑)。
とりあえず色々と調べてみる事にした。

まずは契約料金。
月額1500円はいいとして、初期費用に合計35000円も掛かるのは痛い。
驚いたのがテレビだね。28型だと実売6万程度の商品がいくつかある。
掲示板とか見ても、それほど悪い評価でも無いみたいだし。

--- 唯一の問題 ---
それがビデオ。デジタル録画をするにはD-VHSを買えばいいらしいんだけど
そのときに使うi.Link端子、これが
ケーブルテレビ会社からレンタルされるチューナーに装備されていないようだ。
つまり、うちの環境だとデジタル録画は事実上不可能って事。

ちなみにこのi.Link、ソニーの登録商標だとか。
というわけでK君、もう少しi.Linkの使用料を安くして
我がシティテレビ中野からもレンタル可能になる事を推進して下さい(笑)。

--- 一番の問題? ---
実は、今まで放ったらかしにしておいた問題点がある。
それは、この6畳という狭い空間に28型のハイビジョンテレビを置いて
大丈夫(?)なのかどうかという事だ。

配置スペースは何とかなるにしても、テレビと見る位置との距離が
どう頑張っても3メートルくらいしか取れない。目に悪そうだな。

それよりも、電磁波の影響が気になるぜ(嘘つけ)。
そういう時は白い布を巻けば完璧………この話題古いな(笑)。

--- 結果は… ---
以上の事を踏まえると、大体10万円もあれば
デジタル放送の環境は整いそうだ。
来月からの仕事が正式に決まれば早々にでも契約しようかな。

2003/05/22(木)
休み明けですが…
おっそろしい程、暇である。
MySQLのマニュアルを読み散らし、swingの勉強、Emacsのマニュアル読み、
………
いい加減ネタも尽きてきたぜ。こんなときは散歩だ。

それでもまだ時間が余る。
マジで疲れてきた。こんなんじゃ明日も行く気が失せるな…

2003/05/23(金)
真の力
なんか凄い事になってきた。
卓球の世界選手権個人戦、ベスト8に残った日本人がいる。

福原愛、まぁご存じ愛ちゃんな訳ですが。
世界ランキング91位の彼女がベスト8っていうのは
やはり快挙と言うべき他に無いだろう。
これでアテネへの出場がぐっと近づいた事は間違い無いね。

2003/05/25(日)
ついに来たか…
どうも最近サイトの来客数が減ってると思ったら、
昨日くらいからますます様子がおかしい。
全くアクセスが無い状況なのだ。

最悪の事態だ。僕が使っているフリーのDNSサーバが止まっている。
minidns.net にアクセスすら出来なくなってしまった。
このまま放置していてもminidns.netが復帰するのは
いつになるかわからないので、ネームサーバを変えることにした。

--- 復旧はいつ? ---
zoneedit というサイトも無料のネームサーバを開放しているらしいので
とりあえずはここに登録。
ドメイン取得元であるGANDIの設定も変更。
これでしばらく経てばDNS参照ができるようになるはずだ。
さて、復旧はいつになる事やら………

と思ったら、夕方過ぎにminidns.netが復帰したようだ。
しょうが無い。また元に戻すか。

2003/05/30(金)
大騒動?
今日でこの現場ともお別れ。
…のはずなのに、現場から何の指示も無いのは変だとは思っていた。
普通だったら引き継ぎとか色々あるからね。

定時になり、上の人に挨拶。
「今日で最後ということで…」と話を切り出すも、どうも様子がおかしい。
で、判明した事態。「そういう話は聞いていない」と。

--- 食い違い ---
どういうこっちゃ?
こっちは現場入り初日から不満を訴え、本来6月末までのところを
5月末で辞められるとあってウキウキだったのに。

とにかく会社の人と連絡を取らないと先に進まないので電話。
が、出ない。いくら掛けても出ない。

--- 原因判明 ---
仕方が無いのでオフィスまで出向く。
場所は六本木。なんでこの街はこんなに外人指数が高いんだ。

ようやく会社の人と連絡が取れる。
どうやら、こっちの営業サイドでは今月限りという事で話は進んでたみたいだが
肝心な所で話が届いていなかったらしい。

つまり、
現場の僕→うちの会社の営業→相手の会社の営業→相手の会社の現場
という連鎖を考えた場合の一番最後の「→」がブッツリ切れていたという訳。

--- 遠回り ---
この場合、悪いのは誰か?
当然、相手の会社の営業ということになるよな。
伝えるべき事を現場サイドに伝えてないんだから。

本来、現場には僕と相手の会社の人が一緒にいる訳だから
僕から直接相手側に話をしておけばこんな事にはならなかったんだ。
だけど、それをやると色々と問題が起こる(僕がビシバシ言っちゃうから)。
それでわざわざ遠回り覚悟で
営業を通して話を進めてたっていうのに、こんなんじゃ話にならない。

--- 激闘の末… ---
で、その後。
当然の如く相手の営業は上からこっぴどく叩かれたようだ。
そして僕が抜けた穴は、うちのグループから人を出すことで解決。
無事今日限りでこの現場を辞めることが決定しました。

それにしても、後味悪いよなぁ。
結局ばたばたしてて現場の人に最後の挨拶もできなかったし。
僕は悪くないはずなのに…ホント、疲れました。

--- 来月は… ---
この前受けた面接。そこに来月から行くことが決まりました。
しかも、場所は前と同じ虎ノ門。う?む、これは運命のいたずらか(笑)?

朝が早いらしいのでそれが気掛り。
でも定時で帰れるという話なのでそれは嬉しい。
…いつも定時で帰ってるくせに(笑)。

今度の現場はかなり期待できる。
その期待を裏切らないで欲しいと思う今日この頃である。
というわけで、その結果は次号を待て!

2003/05/31(土)
ハイビジョン
ようやく我が家にハイビジョンがやってきました。
午前中、無事テレビとチューナーが到着。
週末は台風だし、のんびり家で過ごすかな。

それにしても、またリモコンが増えて大変だ。
テレビにビデオ、そしてチューナー。
それにエアコンやコンポまで混在して我が家はもう大混乱(やや大げさ)。

--- これから ---
ハイビジョン放送はさすがに綺麗だ。
ただ、まだ番組のラインナップは薄いよね。
民放の無料放送もあるにはあるけれど。
これから徐々に良くなっていくことは間違いないので期待して待つとするか…

--- データ放送 ---
NHKハイビジョンのデータ放送が凄い。巨人vs阪神を観る。
今まであまり興味の無かったプロ野球も、これなら楽しめそうな気がする。
打者毎の詳細なデータや投球内容が刻々と更新されていくので飽きないのだ。

これがもうちょっと進化すれば、もはやインターネットと同化していく時代だろうね。
パソコンにチューナー付けてテレビ見るよりも
テレビにインターネット機能付けた方が圧倒的に便利だ。

--- RubyServlet? ---
うちのページは、基本的にはeRubyでコンテンツを組んでるんだけど
パフォーマンスアップも兼ねて日記ページはTomcat Servletを使用していた。
今後は全てServletで作っていこうと思っていたのだが…
色々試してみた結果、eRubyでも速度を出せる方法を発見した。

元々は、RubyでJavaServletのような真似が出来ないかという事で
まずはビュー(html)とモデル(ruby)を分離する事から始めてみた。
というわけで、RubyServlet作戦開始。

--- 意外な盲点? ---
mod_rubyを使えば、RubyプログラムをApache上で動かす事は簡単。
そこからeRubyのクラスを生成してrhtmlを解析。
その結果をHTMLとして表示させてみた。

するとどうだろう。Javaサーブレットに負けないくらいの速度が出るではないか。
rhtmlを直接ERubyRunに掛けて表示するんでは無く
一旦RubyRunを呼び出して、その内部でERuby::Compiler.compile_fileをコールする。
たったこれだけの事なんだけど、まさかそんな事で速度が上がるなんて思ってもいなかった。

--- お手本? ---
後はJavaServletの作りをパクって似せて作っていくだけ。
「究極の」オブジェクト指向言語Rubyにとって、
この程度のロジックを組み立てることなど簡単だ。

これで無事、RubyでもServletに負けない位のコンテンツを作る事が可能となった。
後はセッションの管理とコンテナ(アプリケーション)オブジェクト程度の機能を
追加すれば僕としては充分実用に耐えるものが完成しそうだ。

--- MySQLの実力 ---
僕が以前から何度も推薦しているフリーのDB、MySQL。
速い速いとは聞いていたけど、今回の実験で一番驚いたのが
MySQLの接続速度の速さだね。

Oracle等のDBは、接続に時間が掛かるというのはもはや常識。
その為に、Servlet上では接続プール等を用意して速度短縮を図っている。
が、MySQLにその必要は無さそうだ。

接続に掛かる時間を計測した結果、何と1msも掛からないのだ。
この速さは驚異的だ。というより、この程度の時間なら
全く無視しても問題無いレベルまで達している。

--- MySQLの行く末は… ---
ただ、ちょっと今不安な点がある。それがMySQLの今後だ。
現在のMySQLは、御世辞にも初心者に易しいとは言い難い作りになっている。
もちろん、速さと安全性を追求したからこそ今のMySQLがある訳だし
それを責める事はできない。

しかし今後、MySQLは商品化される可能性がある。
その際、スピードその他が失なわれるかもしれないという危険性があるというのだ。

--- 労力の割り振り ---
不思議に思う人もいるかもしれない。
商品化される事が、なぜこのような原因を引き起こすのか?

ビュー(View)やストアド(Stored procedure)、副問合せ(Sub Query)等
大手ベンダーのDBには当たり前のように存在する機能が
MySQLには入っていない。

商品化する際、これらの機能が入っていない事は
他のDBに対してかなりのディスアドバンテージとなってしまう。
そして、初心者にも易しいインターフェイスを多数用意する等
やるべき事は山ほどある。

そういった時、犠牲になるのは何か。そう、速度という訳なのだ。
DBの速度を維持、向上させる為には多大な労力が必要になってしまう。
MySQL商品化の為には、そういった労力は
前述したような内容に回すことが最優先になってくる。

--- 二者択一 ---
速度が遅いのはユーザに我慢してもらえばいい。
とはいっても、MySQLは他のDBが真似できない程の速さを持っている。
今より多少スピードが落ちたところで、一般の人には
それほど問題がある点ではないはずだ。

だが、コアなユーザはこれを納得しないだろう。
スピードが速いという事は、マシン(CPU)に対する負担も軽くなる。
「エレクトロニック・エコロジスト」(んな単語あるか?)である彼らは
MySQLの速さに魅力を感じてこの製品を使ってきたはずだ。

例えば、検索サイト大御所のgoogleはMySQLを使っている。
googleの魅力の一つには「高速な検索速度」があることは間違い無い。

--- MySQL5.0 ---
製品化して速度を落とす事は、彼らを見捨てる事にもなりかねない。
次期バージョンとされるMySQL5.0。
この製品が果たしてどちらの方向に進んでいくのか…
楽しみな反面ちょっと不安でもある。

一番良いのは、じっくり時間を掛けて
どちらも満足するような製品を作ってくれる事。
だけど、ビジネスとして考えるとそう簡単な話ではない訳だから難しいよね。



Limyweb