カテゴリ別表示

全体

最近の日記

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

2004/09/01(水)
新学期
今日から9月。
どうりで会社行く途中ガキ…いや、お子様が多かったわけだ。
でも電車の混み具合はいつもと変わってなかった。
大江戸線は学生利用がほとんど無いからその点は助かるね。

--- 遅刻王から欠勤王へ ---
やれやれ、例の遅刻王がとうとう本性を表したらしい。
昨日から仕事来てない様子。っていうか俺も昨日休んでるから偉そうな事は言えんが。
まぁ僕としてはもう来てくれなくて良いのだが。
会社的にはそうも行かないだろうからね。まだやり残してる仕事山ほどあったんだから。

とはいいつつ、いよいよ現場も最近では「次」の人を探していたようだ。
ってか遅いっての。もっと早く気付いてくれ。
こんな事態になってからじゃ手遅れだぜ。

--- もう言うことが無いです ---
もう凄ぇです。
イチローが月間56安打。本人も「もう言うことが無いです」って位に驚いているらしい。
ただ本当に残念なのが、彼をプレーオフの舞台で見ることが出来ないという事。
レギュラーシーズンだけなんて勿体無いよ。

アメリカじゃ、以前イチローを非難した記事を書いた筆者が
謝罪のコメントを発表したらしい。
これって凄いことだよね。

--- 暑 ---
なんでしょう。この暑さ。また真夏に逆戻りですか?
昨日汗をかいたのは僕の体調が悪いだけじゃなかったって事か。
台風一過ってヤツ?
明日からはもっと涼しい日々を与えておくれ。

2004/09/02(木)
五輪騒動
アヌシュ金メダル返せ。

という訳で、一瞬でも奴のことをスゲーと思ってしまった自分を悔やむぜ。
お前とは比べものにならない位の努力をしてきた室伏に金メダルを返還しておくれ。

--- まず行動せよ ---
あ?あ、ここの奴らの口ぐせはいつもこうだ。
「どうしましょうか…」
あのな、ゴチャゴチャ考える前にまず行動することから始めろよ。
そうやってたって物事は決して良い方向には進まないぜ。

--- 携帯 ---
自分で持っていて言うのも何だが、僕は携帯が嫌いだ。
いや、正確に言えば携帯を持ってる人間が、ね。
もちろん全ての人に当てはまるわけじゃないけど。

以前は外に出て迷惑なものといえばタバコくらいだった。
最近じゃタバコは減ってきたけどね。
携帯打ちながら歩いてる人間の約9割は歩くスピードが落ちる。
そして約8割は周囲不注意だ。
タバコの時と同様、こいつらの周りを歩くのは出来るだけ避けるようにしている。
特に通勤時だね。こいつらを邪魔に感じるのは。

そして音。携帯を打つときのカチカチした音が僕は嫌いだ。
それ以上に最悪なのが、折りたたみ式携帯を閉じるときのあの音。
世界で一番嫌いな(いやマジで)音だ。
自分のじゃ大して気にならないんだけどね。
乱暴に閉めれば閉める程、その不快感度合は増していく。

こういう風に感じてる人って少ないの?俺が神経質すぎるだけなのか。
とにかく、あの音は是非改善してほしい。

--- 眠… ---
やべ、今日は相当眠いのだ。
何たって5時に起きちゃったからね(←早すぎ)。

--- 3日目 ---
例の遅刻王(改め欠勤王)が来なくなってから3日が過ぎた。
失踪しているらしい。
この前の奴は入院、今度は失踪かよ。すげーな、この現場は。

使えんPMがとりあえず奴の仕事を引き受ける事になったようだ。
もちろん一人じゃ何も出来ないから社員を引き連れてね。

--- 疲 ---
はぁ、疲れます。
設計書書けば自動的にプログラムが完成すると思ってる奴。
なんでこんなのを相手にしなきゃならないんだ。
そのつたない文章で書かれた紙っぴらから
どれだけの情報がプログラマに伝わってると思ってるんだ。

で、不明な部分を問い合わせても判らないまま。
依頼主に正解を問い合わせようともしない。
設計書書いてハイ終わり、じゃないんだぜ。
正直、君が設計の仕事やるなんて10年早いよ…

--- 久びさに。 ---
なんか今日は毒全開モードですな(笑)。
眠すぎなんで少々刺激がないと起きてらんないのかも。
こんだけ眠かったら今日は飲まなくても寝られそうだなぁ。

2004/09/03(金)
なんか最近、現場のネットワークが相当遅くなっている。
何でもプロジェクトで使ってる外部からのデータ受信が原因らしい。
そのせいでインターネットアクセスも遅いので不便なのだ。
こんなところにまで被害を及ぼすとは…恐るべきダメプロジェクトだな。

--- つかの間の休息 ---
ふぅ、今日はメンバーが定例会とやらに行ってるので
ちょっとのんびりしてます。
たまには休息も必要だね。

そうじゃなくてもしょっちゅう本当の休息(休み)とってるくせに!
とかいう突っ込みは当然のごとく却下です(笑)。

--- あれ? ---
今日、何げなく家でIEを使って自分のサイトを見てみた。
普段僕はMozillaのFirefoxというブラウザを使ってるので、家でIEを使うことはほとんど無い。
で、とんでもない事に気付いてしまった。
ほとんどのページが文字化けしてる。

一体どうしたことか。
でも会社から見るときはいつもIEだけど、文字化けしてた記憶は無い。
なんでいきなりこんな事態になったのか知らんが、
おそらくこの前作成した日記サイトが原因のような気がする。

というのも、この新日記サイトは全て文字コードがShift_JISなのだ。
以前は避けてきたこの文字エンコーディングだが、
携帯(特にi-mode)は仕様上Shift_JISにしか対応していない。
日記サイトは携帯からも見れる必要があったので、仕方なくShift_JISで統一することにした。

--- とんでもない奴 ---
で、今回の文字化け。
おそらく、この日記サイトがShift_JISを使ってたので
他のページでもShift_JISを使ってるんだろうというIEの「勝手な判断」が下されたとしか思えない。
他のページはほとんどEUC-JPなので、混在した文字コードにIEが混乱したのだろうか。

通常、文字コードを指定する方法は2種類ある。
まず一般的なのが、HTMLファイルの中身にmetaタグを記述する方法。
しかし、これは本来良いやり方とはされていない。
それよりも良い方法とは、HTTPサーバのレスポンスヘッダに文字コードを付加することだ。
ApacheやTomcatを使っていれば、この辺は簡単に指定できる。

僕が今まで作ってきたページは、HTMLファイル内にmetaタグを使用していなかった。
HTTPサーバが文字コードを返してるので、わざわざHTMLに再び記述する必要は無いと考えたからだ。
しかし、今回の例でわかるようにIEはHTTPレスポンスを見ていない。
そしてHTML内にmetaタグの指定が無いと、そのページの文字コードを
「勝手に推測」する(かどうかは判らないが、少なくとも本来の動きはしていない)。

仕方ないので、HTMLにmetaタグを埋め込むことで問題は無事解決したんだけどさ。

--- 協調性 ---
RFCというものがある。
これは、HTTPなどの仕様を明確に定めたものだ。
各アプリケーションは、この仕様を元に作られなければいけない。
そうしないと、アプリケーション毎に動きがバラバラになってしまうからだ。

しかし、Microsoftはそうじゃない。
自分達の作ったアプリケーションが世界標準だと思っている。
自分こそが「正」であり、その他は全て「誤」という腐った精神だ。
こんな奴らに、世の中を占領されてはいけない。

2004/09/04(土)
久々のゲームネタ
ファルコムが新作を出すらしい。
その名も「幻想三国志」。
通常のRPGってことだから、イースよりは英雄伝説っぽいシステムなのかな。

というか、いつの間に英雄の6が出てたのね。
まぁ今からこれ買うのも何なんで、幻想の方買ってみるかな…
初回特典のマウスパッドが欲しい。

--- 豪雨 ---
いや?、今日は参ったね。
ちょっとスーパーに出掛けたスキに、帰ろうとしたら超が付くほどのどしゃ降り。
とりあえず傘は持ってたから助かったけど。

2004/09/06(月)
日本人
大和魂をナメるなよ。
…と、いきなり訳わからん始まりで失礼。
いま全国いや全米の話題をかっさらっているのが、ご存知イチロー。
年間257安打という途方も無い記録が塗り替えられるかもしれないのだ。

こないだも書いたけど、アメリカではその事に対する批判記事が出てきている。

--- 大きな誤解 ---
僕は以前(イチローがメジャーに行く前)、メジャーリーグの事を
「ホームランが打てない選手はスターになれない」と考えていた事があった。
でも、実際にゲームを見てその考えはすぐに間違いだと気付いた。

アメリカの国民はそんな偏見を持っていない。
ただ単純に「良いものは良い」という素晴らしい精神がある。
どうやったら自分達が楽しくゲームを観戦できるのか。
その答えを彼らは知っている。

--- 外国人 ---
「ヒットを多く打ったからって大したことは無い」なんて考えを持っているのは
批判記事を書いた記者を含め、
アメリカ人の中でももはやごく一部に過ぎないだろう。
それは「外国人」に対する差別でしかない。

ホームランが打てなくても英雄になれた選手だって過去にいくらでもいる。
むしろ、「最近現れた素晴らしい選手達が(たまたま)ホームランバッターだった」
という解釈の方が正しいだろう。

日本野球界でも同じ。ローズにホームラン記録を破ってほしくないという奴がいる。
そんな奴がいるから、プロ野球は存続自体が危うくなってしまうんだ。
破られたら破り返せばいいじゃないか。
日本人にその期待を持てる選手がいないのだったら、
ホームラン王という称号そのものを辞めてしまったらどうだ。
替わりに「犠打王」でも作ればいいさ。

--- 尊敬される対象 ---
イチローの特集をやっていると、必ず語られる事がある。
それは、彼が「他の選手達から尊敬されている」ということ。
彼は結果だけじゃなく、全ての面で一流だからこそ
同じ野球人から尊敬されるのだと思う。

松井秀喜が所属するヤンキースには、
現役最高のプレーヤーとの呼び声が高いA・ロッドがいる。
「彼の何が一番凄いですか?」と聞かれた1年目の松井はこう答えた。

「彼の野球に対する姿勢です」
誰よりも素晴らしいプレーは、誰にも負けない練習量によって生まれている。
それを感じたと言う。スーパースターだから
練習なんかしなくたって良い結果を残せるなんてとんでもない。

世界最高レベルの選手達が集まるメジャーリーグ。
その中で最高のプレーを保つ為には、決して才能だけではやっていけない。
シーズンオフに休んでてもそれなりの結果が出てるようなリーグ(日本のプロ野球)は
所詮その程度のレベルだってことさ。

--- そろそろ… ---
終わりにしないと苦情が来そうなのでここまで(笑)。

今日は珍しく遅くまで仕事をしてたのだ。
とはいっても後半はほとんど隣の人とダベってただけだけど。
たまにはこういう日もあるさ。

2004/09/07(火)
ケリ付けてよ
あ?あ、まったく。
予想通り、この現場を辞めるという話が難航しているらしい。
俺はもう行く気さらさら無いんだぜ。この前も話したじゃないか。
ホントこういうの相手にしてると疲れる。

こいつら頼っててもしょうがないので、
今週末までに決着付かなかったら僕が直接話をすると言っておいた。
少しでも仕事にプライド持ってるんだったら、そんな事にならないようにしてくれよ。
なんで技術者が営業同士のやりとりに口挟まなきゃいけないんだ。

--- そうは言っても… ---
現場では今日も面接らしい。
ここで決まってくれれば僕も抜けやすくなるというものだ。
是非頑張って欲しいね。

--- 決めました ---
なんかこんな事いつまでも考えてても意味ないので
もっと建設的な考えをすることにしよう。
プロジェクトの仕事は言われた事だけをして、後は全て趣味に費す。
そうでもしないとやってられん。実際もう帰りたい。

--- 大雨 ---
昼、ご飯を食べていると突然、豪雨。
おいおい、またですか。幸いすぐに止んだから良かったけど。

--- 性? ---
ちなみに「さが」と読んで下さい。「せい」じゃありません(笑)。
趣味に費やすとか言いつつ、結局プロジェクトに関係する作業をする俺。

僕は好きな事やってるだけだからね。
それがたまたま仕事に関係する内容だっただけの話。
あぁ僕って何て仕事熱心なんでしょう(←嘘ばっか)。
他にネタが無かったんだもん。

--- 間一髪 ---
今日は台風が近づいてくるらしいので早めに帰る。
ちょうど駅に着いたところでまたも雨。
まだ強くなる前だったからギリギリセーフかな。

2004/09/08(水)
なんかまた今日は暑い。
しかも現場はいつも寒いくらいなのに、今日はなぜか暑い。
こんなんじゃ仕事やる気が失せる。
ただでさえ無いってのに(笑)。

--- またですか… ---
さぁ、こっから毒舌モード全開の恐れがあるので要注意(笑)。

またまた現場で仕様変更。
その原因は、処理速度にあった。
設計書の通りに実装してみたが、とてもじゃないが実用に耐えうる速度で動かない。
こんな事がこの現場では頻繁に起こる。

--- 「性能」の考慮 ---
なぜこんな事態が起こったか。
それは、設計の段階で性能に関する考慮が全くなされていなかったから。
このシステムの設計をしているのは、
発注元である会社とこちらの会社のSE達。
こいつらだけで話を進めるから、こういう事になってしまう。

以前、僕もこの設計会議に参加したことがあった。
予想通り、突っ込み所満載の会議内容。
こんな奴らが設計してる限りロクなものが出来上がるはず無いとその時思ったよ。

--- SEの限界 ---
今現在、僕はその設計会議に参加していない。
うちからその会議に参加しているのが、通称SE達。
もちろん僕が行った方が良いのだが、ずっと前にも言ったように
そうすると彼らの仕事が無くなってしまう。

「SE = 設計者」という見方は間違っている。
正しくは「SE = 設計しか出来ない奴」。こっちの方がよっぽど現状を表している。

設計だけでも、極めれば良い設計が書けるんじゃないかって?
甘い。その甘さが致命的。
要件定義ならまだしも、基本設計ですら
かなりの部分で「性能」を意識した作りが本来必要なのだ。
設計だけやっていたら、とてもじゃないが適切な性能判断など不可能だ。
「多分これで大丈夫」的な考えで通用する程、コンピュータは賢くない。

--- 結論 ---
こんな事にならないようにするにはどうするか。
答えは簡単。SEなどという無能な人種をプロジェクトメンバーに入れない事だ。
まぁ別に肩書きはSEでも何でもいいけど、
実装に関わる事まで理解できる人間でないと意味が無い。

ほら、こんな事書いてるから現場の人に見せられないんだ(笑)。

--- 現実逃避? ---
夕方過ぎから、ひたすらMySQLの関数をドキュメント化。
暇だから、という訳ではなく、単に仕事したくないから(笑)。

そろそろこの現場の最後(僕にとって)も近づいてきたので(多分)、
モチベーション下がってるのが手に取るようにわかる。
まぁその分色々な事に手出してみるいい機会かな。

2004/09/09(木)
嬉しい誤算?
わーい。
今日丸一日充ててた作業が午前中の段階で完了。

別に多めに見積りしてた訳じゃないんだけどね。
思ったより簡単な修正内容だった。
これで今日はあと適当に過ごしてればいいわけだ(ホントか?)。

本格的にMySQLのマニュアルを作り始めようかと思っている。
あれほど完璧な日本語マニュアルがあるのに無駄な気もするが。
マニュアルというよりはもっと実用的なものにしたい。
とはいえ、あまりに膨大なのでいつまで掛かるか判んないけど。
途中で飽きるかもしれないし。

--- 同類? ---
あ?やだやだ。
寝るんなら家帰ってからにしてくれよ。
そんなんじゃ周りから見たらこのグループ全体がだらしなく見られるんだぜ。

…と思ったら今度はお菓子タイム。
ボロボロこぼして、しかもそれを床に捨てるなっつーの。お前は子供か。

普段周りの事なんか気にしない僕でも、これには参ってる。
行動が目立ち過ぎなんだよ。嫌でも視界とか聴覚に入ってくる。
こんな事でストレス溜めたくない。

--- 連休? ---
今月はあと3日も休めるのだ。
第4週は祝日が2回もあるからその週は除けば毎週1日ずつ休める計算。
というわけで、明日は休もうかな。

2004/09/10(金)
あくまで偶然です
今日はお休み。
こういう日に限って雨が降るのは気のせいかなぁ。

で、結局プロ野球はスト回避ですか。
どうせまたこのままズルズル行くんじゃないの?

今週決着つけるって言ってた今の現場の話も何の連絡も無いしなぁ。
ホント使えん営業だぜ。
次の現場行ってる間に別の場所探すかな。
真剣に探せばもっとマシなところあると思うし。

2004/09/13(月)
朝から…
改札を抜けると、そこは人ゴミの嵐。
この田舎駅に何が起きたのかと思ったが、どうやら西武線が遅れているらしい。
おかげで遅刻だ。参ったぜ。

--- ライブ ---
昨日は久々、ライブに行ってきた。
うちの弟がやっているバンドで、その名も「ポチョムキンズ」。
名前からは想像も付かないかもしれないけど、バリバリのロックバンドです。

リンクページからHPにも行けるので、暇な方は是非。
アドレス見て判ると思うけど、うちのサイト内で運営してます。
ちなみに次回のライブは28(火)、下北沢の屋根裏です…なに宣伝してるんだ(笑)。
なんかしばらくライブ行ってなかったせいで
「ライブ行きたい病」が渦まいている。次も行くぜ。

--- まだまだ続く… ---
先日に引き続き、性能を全く無視した設計が問題となっているらしい。
今度はデータ配信。
とんでもない量のデータ配信を要するコンテンツがある。

このコンテンツを動かそうとするだけで、ネットワークへの負荷が高くなり過ぎる。
他にも山ほどコンテンツがあるってのにね。
将来、1000Mbpsくらいのネットワークが普及するまで
このシステムは凍結しとくのが吉だよ、本当に。

なぜこんな事になったかって?
それは、データの具体的なサイズを全く考慮しないまま設計を進めてしまったからだ。
プログラムにおいて抽象化というのは重要なキーワードだが、
それを設計でやってしまうと大変な事になる。
設計というのは出来る限り具体化していかないと、それを実現する際に
様々な弊害が発生する。

--- ダメダメです… ---
なんじゃこりゃ。
何げなくDBのテーブル一覧を眺めてみる。その数の多さに閉口。
コンテンツ毎に固有のテーブル使ってる部分が多い。
こんなん汎用のテーブル1個用意すりゃ済む問題じゃないかよ。

このプロジェクト(に限らず最近のシステム開発全般)では
テーブル毎にJavaのクラスを作成するというスタイルを取っている。
例えば MASTER というテーブルを追加したら、
MasterDAO / MasterRec という2つのクラスを生成しなければいけない。
前者はデータベースアクセスオブジェクト、
後者はレコード保存用のBeanオブジェクトだ。

つまり、テーブル数が増えるという事はそれだけ保守が大変になる。
なるべくなら汎用のものを用意した方が良い。
もちろん、パフォーマンスやディスク容量の関係で
テーブルを分ける必要も時にはあるとは思うけどね。

プログラムソースと同じように、DBも管理が必要なんだ。
設計書の管理なんかよりよっぽど重要な事だよ。

--- 親切?それとも… ---
最近は携帯コンテンツの開発にも手を出している。
今のところまだ掲示板と日記システムだけだけど。
で、どうもauではコンテンツをキャッシュする機能が働き「過ぎ」ているらしい。

一度読み込んだコンテンツは、サーバ側で更新されたとしても
それを「確認しに」すら行かないようなのだ。
そんな酷い仕様があるかよ。
コンテンツがいつ更新されるかなんてクライアント側で予知できるはずもないのに。

これをパケット代節約のための親切とみるか。
しかし、今やパケット通信定額の時代。そのコース使ってる人にとっては逆に迷惑だろう。
通信量、つまりそれによって会社に掛かるコストを出来るだけ減らそうという
auの戦略かもしれない。

auのサイトを見て、metaタグやレスポンスヘッダのCache-Controlを指定すれば
キャッシュは働かないと書いてあったのに、
その通りにしてもどうやらキャッシュされている様子。
どうなっとんじゃい。実装してない仕様なら載せないでくれ。

--- 結局… ---
先週営業から何の連絡も無かったので、
仕方無く直接現場のPMにメール。
とりあえず返信が来て、僕が今月末で辞められる手配は取ってくれるようだ。
ふぅ。これで一安心かな。やっぱ自分でやった方が早いわ。
営業に任せてても埒あかんよ。

にしてもビックリしたのが、僕の契約がいつの間にか「2005年6月」になっていたという話。
なるほど。あの仲介人は勝手にこんな長期契約結んだから
辞めるな辞めるなってうるさかったのか。
途中で辞めちゃったら契約違反だからね。

それにしても、こんなん違法行為じゃねーの?
まぁうちの方に被害が来ることは無いけどね。
こっちは3ヶ月毎の契約書結んでるんだから。
そして恐らく仲介人の方にも被害は行かないのさ。
ここのPMと仲良しみたいだからね。
ったく。こんな腐った横流し会社潰れちまえ。

--- どっちでもいいよ ---
なんか遠くでごちゃごちゃ言ってる奴がいる。
なんでも名刺の肩書きがどうのこうの。
そんなんどっちでもいいだろうよ。

名刺に立派な肩書き書けばそいつの能力がアップすんのか?
意味ないこと止めようよ。
名刺に必要な情報なんか名前とメールアドレスだけで充分だぜ。

--- むむむ… ---
さっき日記に書いといたばっかで何だが。
もう少し契約が延びるかもしれない。
僕が以前から言ってたように仲介人無しで直接うちの会社と契約してくれる事を考えているらしい。
っていうか、そういう事は早く言ってくれよ。
もう次の仕事も決まり掛かってるんだから。

2004/09/14(火)
もう無ぇよ
あぁ、また始まりました。
ヨーグルトの底をガリガリx2…いつまでやってんの。
そうかと思ったら、今度は紙パックジュースをストローでズーズーx3。
そういうのは家に一人でいるときにやってくれよ。
第一そんな吸ったってもう残っちゃいねーぜ。

--- 完璧ならね… ---
どうしてこの業界には中途半端な完璧主義者気取りが多いんだろう。
こいつらのセリフは決まってこんな感じだ。

「どうして動かないんだろう。絶対動くはずなのに」

はっ、不思議だね。
どこからその「絶対」とか「はず」とかいう発想が出てくるのかね。
あんたの想定してる超好都合の状況なんて、
実際の状況に当てはまる事なんかあり得ないんだぜ。

--- Oracle、おまえもか ---
はぁ。結局君も同じですか。
SQL ServerでPreparedStatementを使うと遅くなる件は前に話したけど、
今日はついにOracleまでもが遅くなるという事実が判明してしまった。

具体的には、バインド変数にTimestampを使ったとき。
普段はそれほど気にならないけど、レコードが数百万件を超えるようなテーブルだと
処理時間がメチャクチャ遅くなる。
原因として考えられるのは、うまくインデックスが使われていないか
キャッシュが効かないとか。

とにかく、Statementを使って通常のSQL文を発行する方が明らかに速い。
一体どうなってんのさ。こんなんじゃ全く使えねーじゃねーか。
EJBとか使ってるプロジェクトはどうなんだろうね。
例えばjbossだと全てPreparedStatementを使ってるはずだから。
大量のレコードを持つ開発にEJB & Oracleは使えんって事になるぞ。

--- 明日決定? ---
ようやく明日、うちの営業と現場のPMが「仲介人を通さずに」話をするらしい。
これで事がうまくいくと一番楽なんだけどね。
まっ、契約内容次第かな。来月以降も続けるかどうかは。

2004/09/15(水)
呪われたプロジェクト
またプロジェクトで使ってるハードディスクがイカれたらしい。
もう何回かこういう事起きてるぞ。
こうも多いと何か不吉な力が働いてるんじゃないかと勘ぐってしまう。

--- 中休み ---
さーて、昨日は頑張って仕事したし
今日は時間を趣味に費そうかな。

Javaで書かれたDBビューアの数が少ない理由がわかったよ。
各社のJDBCドライバ性能があまりに悪いせいだ。
結局、Cなどで書かざるを得ない。

まぁそんな事俺には関係無いけどね。
家で使ってるMySQLならJDBC経由でも全然速いから。
一応本家が提供してるDBビューアもあるにはあるんだけど、
僕にとって使いやすいものってのは結局自分で作るしかない。
欲しいと思う機能が揃ってるものってなかなか無いからね。

--- 北国 ---
…現場で凍え死にそうです(笑)。
こんなときはじっと耐えて何もしないのが一番。
昼過ぎればもうちょっとマシになるはず。

--- 誤解の原因 ---
JavaパフォーマンスチューニングNewsの日本語最新版が出たので読んでみる。
よく目にするのが「SingleThreadModelは使うな」の文字。
別にいいんだけど、一言「WebSphere等、一部のサーバに限る」という注釈を入れてほしい。

以前記事にも書いたけど。Tomcatの実装ではSingleThreadModelを使うことによる
パフォーマンス低下はほぼあり得ない。
Tomcatは他のWebアプリケーションサーバとは異なり、
一つのインスタンスを使い回して同期化を取るような作りではない。

複数のインスタンスを使うことで、同時に発生した複数のリクエストに対応する。
もちろん同期化など一切行われない。
大体、その名称が勘違いの元だね。
「SingleThreadModel」ではなく「MultiInstanceModel」と呼んだ方がいい。

2004/09/18(土)
4連休
はい、すっかり金曜は定休日になっている僕です(笑)。
まぁこんな事になったのも、おかしい契約結んだ向こうが悪いんだからね。
基準時間が160?200なんて初めて聞いたぜ。
そんな契約で誰が160時間超えてまで働くかよ。

--- スト突入 ---
いよいよプロ野球もストに突入。
各局報道してるけど、これで影響を受ける人なんて
今の日本には数%しかいないのが現状だろうね。

僕にはメジャーリーグもNFLもある。
日本のスポーツで言ったって、大相撲やJリーグの方がよっぽど面白いよ。
根本的に何かを変えていかないと、今後もプロ野球は衰退する一方だろう。

--- Eclipseプラグイン ---
またまたこんな事を始めている俺。
Eclipse3もリリースされたし、そろそろまた再開しようと思ってね。
はっきり言うが、Eclipseは従来の総合環境とは一線を画するほどの
超革命的アプリケーションだ。

これを導入するとしないとでは、開発の効率が約50%は変わってくる。
こんなアプリケーションがフリー、しかもオープンソースという事は
開発業界にとってとてつもない出来事だ。

--- 競争から共存へ ---
使いやすいプログラムを使う。こんな事は開発者にとって当たり前の事だ。
しかし、事務などでは今だに「使いにくいけど仕方なく使っている」アプリケーションが
多々存在するのが現実。AccessやEcxelなどのMicrosoft製品が主だけど。

ブラウザ競争は、最近ではかなりIEが押されているという。
従来の99%IEが占めていた時代ではない。
僕が使っているMozillaのFirefoxは、IEと比べて何の遜色も無いくらいの機能を備えている
オープンソースのブラウザだ。

もう、Microsoftの独占時代は終わったのだ。
.NETを使う意味も大して無い。
訳もわからずWindowsを使っているような時代も、そろそろ終わりを告げるだろう。
そんなとき、Windowsに頼った開発をしていた人達は音を立てて崩れ去るに違いない。

--- その先へ ---
マルチプラットフォーム。
PCでも、携帯でも、はたまた別の端末でも。
どんな環境でも動くプログラムを作る。
それが、Javaの目指す道。それは、全ての開発者が望む道。

時代は進んでいる。
でも、日本は遅れている。プログラマを軽視する企業が多いからだ。
僕は昔から一からプログラムを作ってきた。
企画、設計、開発、テスト。
何が一番重要かって、そんなの開発に決まっている。
何が一番難しいかって、それも開発に決まっている。

自分では解らないからといって開発を外の人間に頼ってきた奴は、
これからも一生まっとうなシステムを作ることなんて出来ない。
現実から目を背けてるような奴に、幸福な未来は訪れない。

--- そろそろ… ---
何やら今日は訳わからんテンションですが。
決して身体中にワインが浸透してるからじゃありません(笑)。
それにしても昨日の由佳さんは可愛かったなぁ…
金曜休んだかいがあったってもんだぜ(違う)。いや、別に休まなくても見れる時間帯だけどさ。

まだあと2日も休みだなぁ。
明日からは何しようか。
…別になんもしないんだろうなぁ(笑)。

2004/09/20(月)
swf
もう連休も終わりだってのに、僕は一体何をやってるんでしょう。
暇だったのでネタを探してたら、こんなものにたどり着いてしまった。
ちなみにswfっていうのはFlashで使われてるファイル形式のこと。

swf作成ソフトは、ほとんどが有料なので
今まではあまり手を出していなかった。
以前、mingというフリーライブラリを使ったことはあったけど
これはJavaから使えない。

今回Javaからswfを作成したいって事で、情報を探してみる。
Macromedia にswfファイル形式の資料が置いてあったので、
これを見ながらやれば出来るはず。
バイナリ形式(しかも一部ビット単位)なんで相当骨折れる作業になるけどね。

2004/09/21(火)
2 + 2
なんか今週は休みが2日もあるらしい。
だから本来なら週3出勤なんだけど、
なぜか今週は現場全体が土曜出勤なので週4日出勤。

まぁ、土曜は私服出勤でいいらしいから気楽なもんだね。
最近は現場で暇つぶす良いネタが見つかったので、時間が過ぎるのも早い早い。
今日も延々とswf生成プログラムを作る。
さ?て、明日はちょっと仕事しようかな。

2004/09/22(水)
当然の関心
Firefoxのバージョン1.0が公開された。
5日間で100万ダウンロードを超えたらしい。

さらに、Thunderbirdというメーラーも開発が進んでいる。
こちらはまだ使ったことが無いんだけど、
おそらくFirefoxの普及と共に使われ始めていくはず。
Firefoxには標準でIEからブックマークをインポートする機能が付いてるから
おそらくThunderbirdにもOutlookからのインポート機能が付加されると思う。

ただ、ブックマークと違ってOutlookはやや面倒な形式でメール管理をしてるから
現段階で搭載されてるかどうかは判らないけどね。

--- 移行 ---
どうやら、このプロジェクトも徐々に収束しつつある。
本格的に他会社へ保守作業を依頼することが決定したらしい。
来週あたりから、そのための資料作りをすることになるようだ。

--- Eclipse3.0.1 ---
何が変わったのが知らんけど、とりあえずダウンロードする。
それにしても、Eclipseのアップロードマネージャって遅すぎ。
結局いつも新規でダウンロードしてインストールする手法を取ってるのだ。
この問題は早いうちに何とかしてほしいね。
っていうかネットワーク速くなれば解決するのか…

--- 参りました ---
以前から問題になっている大量のデータ取得。
今日また別の問題が発覚した。
ディスク容量が一杯になっているせいで、データ受信がストップしている。
こんな状況になっているのにも関わらず何の警告も発しないこのシステムは
とてもじゃないが実用的とはいえないね。

--- お望み通りに ---
SunがJavaの認定資格を作ったらしい。
それは何か、俺にネタにしてくれという事か(違う)。
69問135分のテストで24000円とはおいしい商売だよなぁ。
いい加減皆この販売戦略に気付いて資格なんか取るの止めたらどうだろう。
資格マニアなら別としてさ。

2004/09/24(金)
思わぬ壁
順調に進んでいたswf生成。
思わぬところで壁にぶち当たってしまった。

それが、アクションスクリプト。
これを使うと、Flashの中に簡単なスクリプト文を埋め込める。
僕はてっきりスクリプト文を埋め込めばFlashがそれを解析してくれる
ものとばかり思っていたが、どうやらそうでは無いようだ。

Flashプレーヤーが認識するのは、予め用意されたコマンドの解釈だけ。
スクリプト文を解析してコマンドに展開する処理は
こちら側で作らなければならない。

--- パーサ ---
つまり、スクリプトのパーサ(解析)クラスを自作する必要があるという訳だ。
僕はまだこの分野に手を付けた事が無い。

一応、世界標準にもなっている yacc という解析システムがあって
それをJavaに移植した JavaCC というライブラリを使えば
パーサを作ることは可能だ。
ただ、それでも相当に厄介な代物であることに変わりは無い。

今後の事を考えたら、パーサを作れるという事は大きなアドバンテージとなるので
いずれは手を付けたいと思ってはいたんだけど、
これは新しいプログラム言語を一つ覚える程度の覚悟が必要なので
ちょっと躊躇しているのが正直なところだ。

--- またかよ… ---
相変わらず僕の営業は電話に出ない。
どうなってんだ?
やる気無いんだったら、とっととこの業界から足を洗ってくれ。

2004/09/25(土)
来たのはいいですが…
今日は現場が出社日なので、仕方無く仕事してます。
来たのはいいけど、なんか騒がしくて仕事できる雰囲気じゃない。
こんな事なら来なければよかったぜ。
もう帰りたい。

--- 速いのはどっちだ ---
今だにC++の方がJavaより明らかに速いと思っている奴が多いようだ。

僕はどちらの言語も使ってきたから判る。
Javaが遅かったのは、JDK1.2などの大昔の話。
とある記事によれば、MPEGデコードのような
明らかにインタープリタが不利な処理においても
C++はJavaより僅か15%しか速くならなかったという結果が出たそうだ。
通常のビジネスロジックにおいて、JavaとC++による処理速度の差は1%にも満たないだろう。

「ホントかよ」と思う人もいるかもしれない。
でも、これは真実だ。
ただしこの場合、処理速度を意識したコーディングをする必要がある。
何も考えずにプログラムを組んだとしたら、その差は100倍になる可能性だってある。

--- ピンからキリまで ---
Javaは柔軟性が高いのだ。
処理速度を重要としない部分なら簡単に記述して、
高速化が求められる部分はチューニングしてプログラムを組むことが出来る。

全てを丁寧に記述しなければいけないCとは違う。
手を抜くところは抜く。そして重要なところだけキッチリ作る。
これが、現代における効率的なプログラミングのやり方だ。
これはもちろん、コンピュータの処理速度が大幅に上がった事によるところが大きい。

--- そして逆転 ---
信じられないかもしれないが、JavaがC++より速くなるという事実がある。
HotSpotによる実行時最適化により、ループ(特に再帰)を多く含んだ処理は
C++より速くなる事が実際に起きている。

そんな事は、実際どうでもいい。
明らかに言えることは、どんな処理を書こうと思っても
Javaの方がC++より何倍も速く(処理時間ではなく、プログラミングをする時間)
書けるという事だ。

そして、出来上がったプログラムも読みやすく保守しやすい。
ただ、一部のグラフィカルクライアントプログラムを除いてね。
この分野においては、Javaで凝ったアプリケーションを書くことは
VCやVBを使うよりも相当な労力を要すると思う。

--- 予想通り苦戦 ---
今日はとりあえず決まった仕事も無いので、
ひたすらスクリプトパーサの生成を続ける。
といってもまだ始めたばかり。

やはり慣れない分野なので相当に苦戦してる。
正規表現はそれなりに理解してるつもりだったけど、
スクリプト言語を構成するといった複雑な正規表現を書くには
まだまだ訓練が必要となりそうだ。

2004/09/27(月)
今日は朝からひどい雨。
電車も遅れるし、ロクなこと無いね。
雨よ、頼むから俺が寝てる間にだけ降っててくれ(←無茶言うな)。

--- 休み続き ---
なんか最近中途半端な休日が続いてるな。
先週は木曜休み。金土と2日仕事して1日休み。
今日仕事して、また明日は1日休み。
やっぱ休みは2日くらい続いてないと休んだ気がしないよね。

なんで明日休みなのかは、全くの不明です。
幻想三国志の発売日前日と一緒なのは、もちろん全くの偶然です(笑)。
ライブにも行こうと思ってるので、ちょうどいいと思って。
今月は時間的にも足りてるしね。

--- 引き続き… ---
土曜日に引き続き、なんかうるさい奴が騒いでいる。
そういう話し合いはどっか別の会議室でしてくれよ。

--- 無意味 ---
昨日のマラソン、渋井陽子が日本最高記録をマークした。
多数のペースメーカーを引き連れて走る様は、それはもう虚しいもんだった。

その記録にどれだけの意味があるの?
アテネのマラソンを見てるだけに、余計にそう感じるね。
世界最高記録を持ってたラドクリフが棄権、
それより5分以上も持ちタイムの劣る野口みずきが優勝したのを見てなかったのか。

--- 今週の仕事 ---
今週は、引き継ぎのための資料整理。
共通クラスのJavadocと、僕が作ったコンテンツへのコメント付加。

結構巨大なコンテンツだったのと、製作当初時間的余裕が無かった事が重なって
相当に汚ない作りになってしまっている。
本当ならこれを機にもう少し綺麗な作りにしたいところだけど、
今になってリファクタリング(とテスト)をしてるだけの時間も無いので断念。

--- 初めが肝心 ---
やっぱり、質の高いソースというのは
製作初期段階からきちんとした構想を持って作らないと不可能だ。
時間に追われていたのでは、とてもじゃないが綺麗なプログラムは作れない。
そして、後になってそれを綺麗にしようと思っても無理。
一から作り直すしか方法は無いのだ。

プロジェクト全体を考えれば、多少の余裕を持って初期製作に望んだ方が
その後のテスト/デバッグ/保守の面から言っても
明らかに良いのだけれど、それを理解できるような依頼主はほぼ存在しない。

今回の場合も、突然製作が決まったと思ったら
与えられた期間はごく僅か。
こんな状況で綺麗なプログラムを書けったってそれは無茶な相談なのだ。
個人的に言っても、そういうプログラムを書こうとすると
通常の1.5倍程度の工数が必要になるからね。

--- リファクタリング基準 ---
ある程度プログラムを組んでいって、
それなりの規模になったら一度プログラムを見直してみる。

コメントの記述もそうだけど、それより重要なのがリファクタリング。
ここではソースのメトリクス測定を元に作業を進めます。
Eclipse Metrics Plugin というEclipseプラグインがお薦め。
ただ、Eclipse3用はまだうまく動かない感じなので
Eclipse2を使った方が無難かも。僕もリファクタリングのときはEclipse2を使ってます。

--- メトリクス測定 ---
いくつか測定基準はあるので順に紹介します。

メソッドのステートメント数
ステートメント数というのは行数と似ていますが、
空白行やコメントなどはカウントされません。
そして、一つの文で改行をいくつ入れようとステートメント数は変化しません。
そういう意味では正確な「ステップ数」と言えるでしょう。

一貫したコーディングスタイルを取っていれば、ほぼ行数と比例するはずです。
個人的には、これが50を超えるようなメソッドは分割した方がいいと思います。

メソッドのパラメータ数
まぁ、そのものずばりです。
個人的に、6を超えるメソッドはメソッド定義を変更する事をお薦めします。
簡単な手法としては、いくつかのパラメータを含んだクラスを生成して
それをメソッドに渡す方法があります。

メソッド中の入れ子(ネスト)の深さ
インデントが深くなると、プログラムは非常に読みにくくなります。
とはいっても、前述したメソッドのステートメント数の制限を守っていれば
ほとんどこれを意識する必要は無いのかもしれません。

外部パッケージへの依存度
クラス先頭で宣言されているimport文の総数に相当します。
が、これを低くするのは中々難しいかもしれません。
あまりこだわり過ぎる必要は無いと思います。

あるクラス中のメソッドの複雑さの総和
一つのクラス中にメソッドをたくさん置いているとこの値が高くなります。
こういうときは、いくつかのメソッドを他クラスに分散させます。

マッケーブの循環的複雑度
なんか難しい言葉ですが、簡単に言えばあるメソッドの複雑度を表したものです。
この値が高くなると、テストや保守が難しいとされています。

メソッド単位の値なので、
メソッドのステートメント数を制限していれば高い値にはなり得ません。

--- メトリクス総括 ---
以上のことを踏まえれば、リファクタリング内容はほぼ一点に絞られます。
それは「単一メソッドの行数を制限する」事です。
これを実現するためには、色々なリファクタリング手法が必要になることに気が付くはずです。

正直、これを行うと総クラス数はかなり増えます。
しかし、総合的に考えればクラス数が増加する事は決してデメリットとは言えないのです。
4000行のクラスを一つ管理するよりも、1000行のクラスを4つ管理する方が
長い目で見れば管理しやすいという事です。

--- コーナー違い ---
…こんな話はプログラムのコーナーでやれって声が聞こえてきそうですが(笑)。
つい書きたくなったので日記に書いてしまいました。
こうやって文章にするって事は自分の開発手法を確認するって意味でも
必要なことなのだ。

ってなわけで。
明日は休みだし、今日は飲むかぁ!
…あ、酒が切れてる。(笑)

2004/09/29(水)
吉か凶か
IEがWindows2000以前のOSへの対応を打ち切るらしい。
このOSを使っている人へのMicrosoftの対応は、
「OSを(有料で)XPへバージョンアップして下さい」。
とんでもねぇ奴らだ。

これを機に、別のブラウザへ乗り換える人も多いだろう。
金儲けの為に立てた策略が、結果的に普及本数を減らしてしまうという
事態を引き起こすかもしれない。
果たしてこの戦略、吉と出るか凶と出るか…

そのうちWindowsそのものも同じ対応になるだろうね。
そうなる前に、早く別のOSに乗り換える必要がある。
Javaの開発環境という意味では、Linuxでも全然問題は無いんだけど
通常業務においてはまだまだWindowsに頼っている所が大きい。

というか、今までWindowsしか使ったことのない人間がいきなり他のOSに移ることなど
到底不可能だろうね。
これでまたMicrosoftは莫大な資金を手にするわけだ。

--- 休日の過ごし方 ---
ずっとゲームしてたなんてそんな馬鹿な(笑)。
注文してた品が意外と早く着いたので、ライブ行くのも忘れてゲームしてしまった。
今までのファルコム作品とは一味違うね。
まぁ舞台が三国志っていうのもあるんだろうけど。
結構やりごたえはありそうなので、じっくり進めていこうっと。

2004/09/30(木)
いよいよ…
もう散々ニュースでやってるから
あえて話題にはしなかったけど、とうとう目前までやってきました。
イチロー、最多安打まであと「3」。
今日は11時からアスレチックス戦。もちろん皆録画の用意はできたよね(笑)?

これを書いてる段階ではまだ試合が始まってないけど、
僕の予想としては記録達成は明日以降だと思うな。
もちろん1試合3安打っていうのはこれまでのイチローの実績からすれば
充分可能性のある数字なんだけど。

今日を含め2試合をアウェーで戦って、あとはホームで3連戦。
やっぱりホームの皆も地元で達成してくれることを願ってるだろうし。

--- 反省の色無し ---
この前会社に行ったとき、前々から問題になってるヒジョーさんの話が出た。
仕事中寝てるのはマジで病気らしく、「気付いたら寝てる」んだとか。
おいおい、それやばいんじゃないの?
さっさと病院行ったほうがいいよ。

それとは関係無く、メール打ってる件は
担当営業からも注意したらしいんだけど
あまり改善されてる様子は無い。
以前みたいに10分以上も打ち続けてるって事は無くなったみたいだけど。

--- 試合速報 ---
今日はイチロー1安打。あと「2」。
明日の試合は生で観たいけど、今週すでに一日休んでるからなぁ。
Webの速報を随時チェックするしかないな。

…と思っていたら。
神様は僕に救いの手を出してくれた。
明日はデーゲーム。日本時間の午前4時半から生中継だ。
こりゃもう観るしかないでしょ。

というわけで、今日は酒でも飲んで速攻寝ることにします(笑)。
歴史的瞬間を生で観るために。

2004/10/01(金)
観戦結果
今日は朝4:30からマリナーズ戦を観る。
結果、今日のヒットは1本。
記録は明日以降のホーム戦に持ち越される事になった。

相手は投手力の弱いレンジャースだから心配はしてないけどね。
あとはどこまで記録を伸ばせるかどうか。
おそらくその記録は、もう何十年先まで
イチロー以外に破れる選手なんていないんだろうけど。

--- 偉大な記録 ---
その理由は、記録を見れば一目瞭然だ。
年間安打の歴代ベスト10を見ると、10位に2001年のイチローが記録した
「242」というものがある。
その上を見てみるとどうだろう。1900年代前半の選手がズラリ。

一番最近の選手でも1930年。
ということは、イチローがデビューの年に出した安打数でさえ
ここ70年以上誰も破ったことのない数字だったのだ。
その事実が全くといっていい程クローズアップされなかった当時の状況にも驚くけど。
ヒット数というのはホームラン数と違って、それほど人々の心に残らないのだろう。

だけど、今回は違う。
イチローは100年以上ある歴史の頂上に到達し、そして超えようとしている。

--- 「新人」の付かない称号 ---
これまでのイチローの記録はどれも、「新人」の冠が付くものばかりだった。
・新人の年にMVP
・新人から4年連続200本安打
などなど。
僕を含め、それをはがゆく感じてた人も多いと思う。
イチローを新人という括りで扱って欲しくない。

しかし、誇り高きメジャーリーグは
外部のリーグから来た人間は誰であろうと新人という扱いにする。
これは決して悪いことだとは思わないし、それをどうこう言うつもりもない。

もうすぐ、イチローに「新人」が付かない称号が与えられる。
「メジャーリーグの歴史上、1シーズンに最も多くのヒットを打った選手」
なんか嬉しい。
明日かな。明後日かな。
記録達成の瞬間にはまた、僕の部屋に絶叫が響きわたるのだ(笑)。

--- 予定オーバー ---
しまった。先月は勤務時間を8時間も(?)オーバーしてしまった。
前半あと1日休めたな、この調子なら。
今月は邪魔な仲介人がいなくなるので真面目に働いてみようかな。

--- 基本 ---
開発者としてあるまじき発言をした奴がいる。
「調べるの面倒くさい」
なんてことだ。自分で調べる事が出来ないようじゃ終わってるぜ。

「このカラムに小数って入るんですかねぇ」
自分でやってみろよ。そこに答えはあるのだから。
自分で調べる事が嫌だったらこんな業界に入ってくるんじゃねーよ。
もしくは本でも買え。

--- よくある光景 ---
またかよ。
なんか隣でトラブル対応をしている。
ちょっと話を聞いてみると、DBのインポート・エクスポートで失敗したらしい。
原因は、CSV形式でエクスポートしたファイルをExcelで編集して
インポートをしてしまったというお粗末なもの。

一体何年この業界いるんだよ。
その行為は大いなるタブーだらけって事くらい学んどいてくれ。

--- 第1のタブー ---
まず、CSVファイルは決してExcelで編集してはいけない。
閲覧だけならまぁ許せるか。
理由は、ExcelはCVSファイルを保存するとき
「既存のデータ形式を無視」して勝手な解釈でデータを保存しようとする。

例えば今回のパターンのように、
「05000」のような文字列型のデータを勝手に数値として解釈する。
そして、保存するときには「5000」と先頭の0を取った形で勝手に保存してしまう。
よって、Excel以外で生成したCSVファイルは決してExcelで修正してはいけないのだ。

--- 第2のタブー ---
次。DBのインポート(入力)にCSVを使ってはいけない。
エクスポート(出力)だけならまだ許せる…って何様のつもりだ、俺は(笑)。

理由は、CSVファイルからのDBインポートは
使うDBの種類やインポート時のオプションによって
インポートされる内容が変化するから。

つまり、エクスポートした内容を正しくインポートできない可能性がある。
DBのインポートには、必ずSQLファイル(INSERT文の羅列)を使用する事。
これを面倒だと思うなら、他の人に任せた方がいい。
もしくは、これらのツールを自作する。

--- 長 ---
今日はいつもにも増してお隣さんが爆睡状態です。
もうかれこれ10分以上も寝たままだぞ。
突っついて起こしてやろうか(笑)。

で、起きたと思ったら何やらガサゴソ始め出した。
これだったらまだ寝てる方がマシだな。人に迷惑掛けない分だけ。

--- 丸一日 ---
今日は4時半起きだってのに、結局夜遅くまで起きてる。
もうすぐ丸一日経つぞ。
そろそろ寝よっかなぁ。明日は11時からマリナーズ戦だから
それまでには起きればいいかな。



Limyweb