6/10(Sun)
/** 128MBのメモリ */ 2980円で売ってた... 価格破壊しすぎ...(T_T) そして、価格情報を見ると、1960円!? すご... kakaku.com AKIBA PC hotline! /** 光学式マウス */ 親マシンのマウスが調子悪いらしく、光学式マウスを買ってみた。 なんでも、調子いいらしい。 PS/2の割には、それなりにスムーズっぽいし。 USBマウスのスムーズ感は、それはそれで十分なので、 わざわざ光学式に移行する必要は無いと思うけどね。 /** 阪神弱すぎ(-_-; */ ただ弱いだけなら構わないんだけど、 セリーグの足を引っ張るようなこと(＝巨人に負けること)は、 やめて欲しいんだよねぇ。 せっかく広島が3連勝したのに、何にもならないじゃん(-_-; /** パワプロ2001 */ 攻略方法? 140km/h前後のストレートは、 「チャー・シュー・メン!」 で打つべし! (→ 何のマンガだったっけ?) これで、大分ホームランが出るようになりました(^^) ただ、いつまでもこれだと、 変化球には対応できそうにないけど。6/9(Sat)
/** ボー(=_=)な一日 */ 今日も光合成することなく、日陰でまったり。 昼寝なんかしちゃったりして、活動意欲ゼロで人間失格っぽい(^^; 明日こそは外出しようかなぁ。 (→多分しない(^^;) /** パワプロ2001 */ Yahooランキングで2位らしい。 やっぱり、スポーツのコナミだしねぇ。 [良いところ] ・ホームランの打球が、観客席で跳ね返る。 → 伝統的な野球ゲームでは、吸い込まれちゃってたしねぇ(^^; ・ボール球(高めが有効っぽい)に、COMが結構手を出すようになった。 → 逆に、これを有効に使わないと、押さえられないっぽい。 [悪いところ] ・ひっぱれない → ひっぱったつもりが、全部センター返しになる(T_T) ・打席画面での打球の方向と、守備(走塁)画面での打球の方向がいまいち合ってない(気がする) → 慣れの問題? とりあえず、まだまだ「よわい」で修行中。 /** Servlet JDBC-ODBC */ ServletからJDBC-ODBCブリッジドライバを使うと出るエラー 「データ ソース名および指定された規定のドライバが見つかりません」 に、二日もハマってるし(T_T) それもこれも、会社(客先)のWeb環境が激遅なのがイケないんだぁ(>_<; あれじゃあ、調べる気になれないよ... 原因は、ODBCのユーザDSNを使っていること。 NTでは、Servletの実行ユーザと、ODBCの設定ユーザが違うらしい。 なので、そのマシン全体に有効な、システムDSNというのを使わないといけないらしい。 まだ試してないけど、きっとこれで解決することでしょう... ちなみにWindows98 + JDK1.3 + Tomcat3.1で試したら、 ユーザDSNでもつなげてるし(T_T) 多分、ユーザの概念が希薄で、ODBC設定ユーザ ＝ Servlet実行者 だからだろうね。 しっかし、ODBCが原因とはなぁ。 まだまだまだまだ修行不足のようです(^^; /** XML Centric Software Development */ またまた「from DB Magazine」。 6/5に言っていた、 DB → DOM → XSLT → 画面 っていう形態での開発手法において、 DB → DOMの部分は、Oracle XDKを使用すればできる。 みたいなことを書いていましたが、ここをOracle以外にも対応できるツールがありました。 その名も「iConnector」。 (インフォテリア株式会社: iConnector) これを使えば、対応データベースなら、 DB → DOM が実現できるみたいです。 そこで気づいたこと。 XML Centricな開発は、所詮DOAかと思っていたけど、 それは、やっぱり違うな。と。 なぜなら、XMLが標準的なものだけに、 例えばiConnectorや、Xalanのような、 「使えるツール」が、色々あって、開発をサポートしてくれるところが、 単なるDOAとは違うと思えます。 (データベースの違いを吸収してくれるから、DBベンダ依存にならないとかね。) 特に、XSLTに関しては、 純粋なプログラミング言語とは違い、 メタプログラミング的な要素を持っているので、 可読性などにおいて、保守性が高いと思われます。 そんなわけで、 「標準的な開発手法になっていくだろう」 と書いた、DB Manazine記事の著者が言うことも、 意外とあたってるかもなぁ。6/8(Fri)
/** ナスボー */ 宣言どおり、パワプロ2001を購入♪ ま、別におろしたお金じゃなくて、カードで買ったんだけどね(^^; /** パワプロ2001 */ 操作系統が変わってんじゃん(T_T) なんか打球の方向が良く分かんなくなってんじゃん(T_T) 観客が妙にひらべったいねぇ(>_<; COMレベル「ふつう」でも、0-12の完敗。メチャ強いよ。これ(T_T) とりあえず、「よわい」にしたら、逆に26-2とかになっちゃうし(^^; なんか、ゲームバランスがいまいち? なんか、セカンドできわどいプレーになったら、 「ただいまケガの治療中です...」 とか出てきて、 「プレー続行可能なようです...」 みたいなのが出てきてるし(^^; なんかもう、コリコリだね(^^;; ま、なれるまではしばらく苦戦することでしょう。6/7(Thu)
/** ナスボー */ 買うぞ! → http://www.konami.co.jp/press/2001/06/075/r.13.06.05.html 安っ(^^; っていうか、相変わらずお金の使い道がない... でもあんまり溜まらないのは、やっぱりムダづかいしてるからなんだろうなぁ(>_<; /** この人いいこと言うなぁ。 */ http://www.oracle-master.org/talk/kiji/kiji_master08.html この記事の最後の方にある、 「大切なのは、会社に依存しすぎないこと。たとえ会社がつぶれたとしても、 すぐに引き合いのある技術者で居続けることだと思います。...」 という言葉。 これはまさに、僕がいつも思ってることだし、 ベンダー資格を取っている理由の一つでもあるよね。 確かに「経験」つーのも大事だとは思うんだけど、 それは視覚化するのが難しいものだからね。 /** わけわか(>_<; */ INTERSTAGE APWORKS付属の、EJBコンポーネントDeployツール。 クラスにある130程度のフィールドから、あるフィールドをコメントアウトすると、 ちゃんとDeployできるのに、そのフィールドをコメントインすると、途端に「ワトソン博士」の登場となる。 ところが、フィールド2コ + 問題のフィールドを定義した状態だと、ちゃんとDeployできたりする。 まったくもって、???な状態に疲れ気味(-_-; 問題は、フィールド数が多すぎるっていうのと、 データベースのフィールド名をそのまま持ってきているので、 クラスのフィールド名が全て日本語になっているということ。 前者はともかく、後者は問題が起こっても仕方がないかもねぇ。 ちなみに、問題のフィールドの名前を、アルファベット表記にしたら通りました。 でも、そのフィールドで使っている漢字って、 他のフィールドでも使っている漢字で、文字コードが問題とか、 そういうのじゃないと思うんだけどなぁ。 まあ、最悪「native2ascii」を使うべきなのかもね。 /** もう〜(>_<; */ ちょっと大雨になったぐらいで、止まんなよなぁ(>_<; ＞ 横須賀線 タクシー代は使うし、普段とは違う路線で帰ったがために、 無駄な交通費は使うし、遠回りしてる分時間はかかるし(-_-; まあ、i-modeで交通情報を調べる方法が分かったんで、 それでとりあえずヨシとしますか。 こいつもパケット料がかかってるんだけどね...6/6(Wed)
/** また風邪ひいちゃった(>_<; */ こほこほっ(-_-; もうちょいで治る可能性も否定できない(^^; ここで気を抜くと、ぶりかえすんだけどね。 /** Object → Relational Mapping */ DOAなシステム開発では、E-R図を書くような、データモデリングの段階では、 「これって、クラス図っぽくて、オブジェクト指向っぽいねぇ?」 と、DOA(データ指向アプローチ) ≒ OO(オブジェクト指向)と勘違いしそうです。 しかし、いざ実装段階に入ってみると、 「xxのデータ取ってくる機能(＝関数)が必要で、さらにそのデータを渡すための入れ物(＝構造体)がいるねぇ。」 つーことになって、なんかとってもC言語(＝手続き指向)。 そもそも、構造体にデータ入れてる時点で、データが丸裸(＝カプセル化には程遠い)じゃん(^^; 実は、これが、 「とりあえずJava使ってるんだけど、なんかオブジェクト指向っぽくないねぇ。」 っていう現象の原因なんじゃあないかと思ってたりします。 まあ、オブジェクト指向(理想) → データ指向(現実)ってとこでしょうか。 事実、データ指向の方がパフォーマンスよさそうだし。 ちなみに、僕が去年の今ごろ研修で作成した、 「なんでもアンケートシステム」 は、内部のデータを全て「org.w3c.dom.Document」で持ちまわっているので、 入れ物が構造体からDOMに変わっただけの、真性DOAシステムだったことに気づきました(-_-; 道理で、クラス図を書いてみても、 「is-a関係」や「part-of関係」が、無いわけだ。 --- ところが冷静に考えてみると、 一般的に現場で使われているデータベースは、RelationalなDBで、 こいつはまさに、DOAを実現するには最適であり、 OOとは、相容れない部分があったりします。 そこ(オブジェクトの永続化)をシームレスに行うのが、ODB(Object DataBase)であり、 中間点に位置するのが、EJBのEntity Beanであると考えられるでしょう。 ただ、Entity Beanには、表結合ができない(EJB2.0では可能らしい)という問題や、 そのレコード指向のために、GROUP BYなどのソートを伴うクエリーをEntity Beanに行わせると、 1レコード取得ごとにクエリーを投げて、それごとにソートを行うので、 パフォーマンス上の問題が生じたりします。 じゃあ、 「Entity Beanを使わないで、RDBを使って、オブジェクト指向を実現するには?」 と考えるわけです。 そこで、「Object → Relational Mapping(ORマッピング)」という考え方が出てきます。 出てくるのはいいんだけど、それが具体的にどういうものであるかは、 どこにも書いてなかったりするんだよね(>_<; 多分、書いてあるような本はあるんだろうけど。 ここで、私的な解釈をしなくちゃいけなくて、 今のところ、「Entity Beanの考え方を継承しつつ、Entity Beanの制限を解消する方法。」 を追ってたりします。 つまり、行指向じゃない、永続化クラスを作ること。 ただ、現実的には、テーブルの項目は100を超えるものもあるので、 APWORKSのような、「表定義 → クラス」を自動生成するようなツールが必要で、 それは、データベース製品の知識と、「データベース型 → JDBC型 → Java型」 の変換ルールを知ってれば、可能だったりするんですが。 Oracleなら、「SELECT column_name, data_type FROM dba_tab_columns WHERE table_name = 'table_name'」で出来ますね。 こんな感じで、「RDBを使いつつ、オブジェクト指向を追求」しているわけですが、 一番心配なのが、「パフォーマンス」なわけで、 とりあえず作ろうとしているプロトタイプが、それなりに動いてくれることを期待するばかりです。 というわけで、まだ研究中...6/5(Tue)
/** また風邪ひいちゃった(>_<; */ ゴホゴホッ(-_-; /** な、なんじゃこりゃ〜 */ っていうか、流行りすぎ(-_-; SCEI，プレステ2にJavaを搭載 /** XMLでWebシステム構築 */ DBマガジン7月号に、ビクターの携帯向けWebシステム構築事例が載ってました。 DBからデータを取り出して、画面に表示するまでのプロセスを表現すると、 [Oracle DB] → (Oracle XDK) → [DBデータのDOMツリー表現] → (XSLT) → [画面に表示] のような感じ。 XSLTの書き方次第で、どんなクライアントでもオッケーてなところがポイント。 まあ、入力データ(クエリー条件)はどうするの? っつーところは、よく見てないんですが。 上のパターンをもうちょい応用して、XSLTをかける回数を2回にすれば、 「データの計算、加工のためのTransform」と「画面に表示するためのTransform」で、 XSLT(各XSLファイル)の責任範囲が明確になって、保守性が向上する可能性はあるね。 その事例紹介記事を書いた人は、 「この方法が標準になっていくだろう。」 などと書いていたんですが、この手法って、思いっきり 「DOA(Data Oriented Approach)」 なんだよねぇ。 DOAっていうと、オブジェクト指向にはなりきれないし、 いまいち機能指向を引きずってるしで、中途半端さは否めないね。 とりあえず、XMLと心中するなら、アリかも(^^;6/4(Mon)
/** また風邪ひいちゃった(>_<; */ 治ってから3週間ぐらいしか経ってないのに〜(>_<; もうヤダ(T_T) /** 目指せ! Oracle Master Platinum!! */ 6/16(Sat)にエントリー! これでやる気復活!? 本当は、6/9にしようと思ってたんだけど、チーム事情的にやめときました。 僕は休日出勤しないと思うけど、 周りが一所懸命やってる時に、一人「オラクルマスター」とか言ってられないしね(^^; とりあえず、プラチナ3科目の内の最初の1科目。 気合入れていかないとね。 /** プリンタ購入♪ */ HP Deskjet 990Cxiばなし。 やっぱり、静粛性というのは重要ですね。 なんせ、夜とか印刷しようとしても、うるさいんじゃムリだけど、 990Cxiぐらい静かなら、十分実用に耐えます。 それから、MJ-910Cとの比較ですが、 電源ボタンONから、印刷Ready状態になるまでが、めちゃくちゃ速いです。 今のプリンタは、みんなそうなのかも知れないですけど、 990Cxiは、2〜3秒じゃないかなぁ。 これは意外な利点でした。 あとは、速さですね。 これも評判どおり速いです。 ダテに、カタログスペック「17枚/分」とか言ってないね(^^; まあ、そこまで言うんだったら、レーザー買えよ! っつー話も出てくるかとは思いますが、 そこは家庭用だけあって、年に一度の「年賀状」というイベントがある限り、 カラーは必要になってくるでしょう。 こいつもうわさ通り、ドットが荒いんだけどね(^^; 今のところは、かなぁりいい感じで使えてます(^^)6/2(Sat)
/** プリンタ購入♪ */ 掲示板に書いたとおり、HPのDeskJet 990Cxiを買いました! まあ、「文字印刷の速さ＆静か」ってので、 選択基準としては十分だったでしょう。 明日くるらしい。たのしみ〜♪ /** USBじゃワカランのだよ(T_T) */ 今まで机の上に置いていたプリンタを、やや離れた本棚の上に置くべく、 試しに距離を測ってみると、3m程度でオッケーらしいことが判明。 これなら、3mのUSBケーブルを調達すればつなげるだろうと、 早速近所のPCショップに買いに行くも、プリンタ側のコネクタの形状が分からず(T_T) (2種類あるからね。参考) 一所懸命、プリンタのパンフレットを見てみるも、 案外、プリンタの裏側が写っている写真が見当たらず、 かといって、この店で買ったわけでもないプリンタについてきくのも、 なんだか聞きづらい(^^; とりあえずは、明日の実物到着を待って、 再度買いに行くことにしました。 昔の僕だったら、見切り発車的に、 「多分、この形状だろう。」 と買ってきてしまい、実物を見てみて、(T_T)な結果になっていたのですが、 さすがに最近は成長したのかも(^^; /** 送料3000円 */ 某PCショップでは、送料に3000円を取るらしい。 しかも店員が、 「3000円取られるぐらいなら、ヤマトとか佐川さんに頼んで送ってもらった方が、安いですよ。」 と、意味深な発言。 それって、僕にコンビニとかに持っていって、 配送手続きをしろっつってんの!? なんつー、サービサビリティの低い店なんだっ! とか思いつつ、「考えてみます〜(^^;」とか言って脱出。 客をなめんなよ〜(-_-; その後、洗脳CM＆ソングで有名な、某大手電気店へ。 さすがは某大手電気店、なかなかの接客力。 値段も、標準的な価格よりも「300円安い」ところが気に入り購入。 買ってから気づいた、送料無料も嬉しすぎ(^^) 帰る時も、「さすが石丸電気だよなぁ。」と思いっぱなし。 案外、パソコン専門店なんて、接客みたいなところでダメなものですね(^^;6/1(Fri)
/** FD & 5インチベイ復活! */ 前々から気になってた、FD差すとWindowsハングアップ問題と、 5インチベイの代わりに、とりあえず4xSCSI CD-ROMドライブ差してる問題を解決しました(^^) FDなんて、980円ぐらいで売ってるかとおもいきゃ、 秋葉原の相場では、1980円ぐらいなようです。 まあ、探せばあるんだろうけどねえ。 とりあえず、「クレバリー」なるアヤシげな店で、 1680円(税抜き)で手を打っときました。 ここで買ったのは、 「シルバーボディ!」 の売り文句に負けたからですが、 家に帰って着けてみると、FDだけシルバーってのは、 やっぱヘンでした(T_T) ついでに、Tsukumo DOS/V館で買ってきた、 5インチベイってのも、微妙に奥にひっこんでしまい(T_T) なんかもう、「フロントパネルがたがた」って感じです(;_; ま。あんまり気にしたらいけないよね。きっと。 /** プリンタ物色中 */ LAOX ザコンピュータ館に行って、パンフレットをゲットしてきました。 とりあえずEPSONを買うつもりはまったくなかったのですが、 なぜか売り場には、EPSONの人っぽい人がうろうろしていたので、 わざと避けつつ、CanonとHPのパンフレットだけもらって去りました(^^; さて、どっちにしようかな。 /** 携帯電話ツール */ 秋葉原で、こんなんのパンフレット見つけた。 ソースネクストと違って、着メロ4和音までは対応しているところが、 ちょっとイケてるかも。(N503iの話です。) まあ、「16和音iメロディ」＆「iAppli」に対応してくんないと、 全然買う気しないんだけどね(^^; 特に、iAppli対応は、必死になってやってるところなんじゃないのかな?