“2004/07”な記事

WWDC2004.の3link

 WebObjects屋さん的には予想通りコレと言った話題もなく、平穏無事と言った印象ですねぇ。もちろん個別のWebObjectsセッションで何か発表された(る)かも知れませんが、NDAでしょうから表に出てくる事もないでしょう。

 まぁ、私としてはそれでもOKなんですけどね、「別にここから進化しなくても保守だけしてくれればいいやぁ」みたいな。流石にソレも無しだとちょっと嫌だけど、Appleがそう決断しちゃったら仕方がないかなと。使える間使って後は他のに乗り換えるかなと。
 実際、私はWebObjectsが「使える」と思っているからやっている訳で、それよりも「使える」と思うものと出会えば普通に乗り換えるし、Appleが儲からないから止めると言ってもそれはそれで受け入れちゃう。

 と言いつつも、WebObjectsで仕事ができるだけで幸せを感じるんすよねー。がー

フェッチの回数をけちる。link

 WebObjectsの実行速度ってどうなんでしょう。やっている事を考えると「そこそこかな」と思うのですけど、決して速くはないと言われています。だからというわけではありませんが、私も一応最適化の真似事をしています(←実際はスピードというより、エレガントかどうかの方が重要だったりしますけど)。
 最適化の道はそれはもう奥が深く、突き詰めるとif文はコストがどうのこうのというところまで行くらしいのですが、もちろん私はそんな事知ったこっちゃない、と言うかよくわかりません。ですので、「単純に無駄な処理はさせなきゃいいじゃん」と心がけています。そしてもう一つ、フェッチの回数をできるだけ少なくする様に。

 WebObjectsで行える色々な処理のうち、重い(←つまり時間がかかる)のはデータベースからデータを引っぱり出したりするフェッチだと言われています。と言うのも、HDDへアクセスするからなのです。HDDは大容量である事、通電していなくても記録を残せる事と引換えにデータを出し入れするのが遅くなってしまう作りになっているのです。そしてほとんどのRDBMSはHDDにデータを格納する事が普通ですから、結果的にフェッチが重い処理となってしまいます。
 しかしフェッチをする事からは避けられません、ほとんどのWebObjectsアプリケーションはRDBMS内のデータにこそ用があります。逆にRDBMSとの連携を考えないならばWebObjectsを利用するメリットはかなり目減りしてしまうでしょう(←それほどWebObjectsのRDBMSと連携する仕組みは強力なのですから)。

 そんなわけで、フェッチの回数を減らす事はパフォーマンスの面からもかなり影響が大きいです。これはマシンスペックが貧弱であればあるほど顕著で、以前PowerBookG4/550MHz/DVD-ROM(←近年稀に見る負け組マシン)で考えなしに作ったアプリを最適化した時には、「うぉ、やってみるものだな」とめずらしく素直に感動しました。

 フェッチの回数を少なくするには色々な方法があると思うのですが、二つ例を上げてみます。
 ある一定間のデータを連続的ににフェッチをかける様な場合(←一ヶ月分のデータを日別に表示するとか)は、その一定間のデータをまとめて一発でフェッチし、それをオンメモリで絞り込む様にすると良いです。一度データをメモリに読み込むので、あまりに大量のデータの場合や、内蔵メモリが足りていないとswapが発生したりして元の木阿弥になる可能性もありますが、かなり効きます。

 もう一つ、WebObjectsはリレーションも簡単かつ柔軟に扱えたりしますが、たどるともれなくフェッチが付いてくるのでその扱いに注意が必要な場合もあります。関連するオブジェクトの存在が保証されていない場合(←うちの個別の記事の下の方にあったりなかったりする過去ログへのリンクがそうなのだけど)、ある時だけフェッチを行うと無駄がなさそう。でも、あるかないか確認するためにもフェッチしないといけないんですよね、コレが。
 あるかないかわからないからフェッチする。て事は予めわかっていればいいわけで、「だったらそれ用のフラグでも立てるか」と、元モデルの方にカラムを一つ追加して関連するオブジェクトの有無を持たせる事で対処しています。そこを参照してフェッチするかどうか判断するわけです(←あまり美しくないですけど、他には思いついてませんですから)。
 関連するオブジェクトを追加・削除する時に少し注意が必要ですけど(←ないのに有判定とかなると無意味になるので)、これで無駄なくフェッチをかける事ができる様になります。効果の程は状況に寄りまくりなので微妙かも知れません。

 これだけスペックが向上したら不要という意見もあるかも知れませんが、無駄なモノは無駄ですし、EOAdaptorDebugEnabled=true 等とした実行ログを見ても“精神衛生上非常によろしい”というのも大きいですわ、私にとっては。

iPod mini.link

 車でのお出かけのお供もiPodですが、雨、もしくは著しく気分がのらない日以外の日課でありますお散歩のお供もiPodでございます。私のiPodは旧世代モノでありまして、最初の20GBのモノであります。つまりですね、厚くて重いのでございます。

 一応デカい(←容量が)のも持っているのでお散歩用に軽くて小さいヤツがあってもいい。あって然るべき。むしろ何故ないのですか。ない事こそおかしい。

 などという免罪符がグイグイと背中を……。耐えるけど(←コレだっ。ていう色がないのも幸いしてるな)。

最近のたくぅさん。link

 小規模のオンラインショップなサイトを引き継いで修正したり保守したりみたいな仕事をしています。当初の要望を満たす修正や作業は終了いたしまして一段落。

 椅子をリプレース。あれこれセッティングを試してみましたが、矢張りしっくりこず肩とか背中とか痛いです。1万5000円くらいの椅子じゃ駄目ですか。リープとかアーロンとかいかないと駄目ですか。買えるか、あんなの。ふん ……欲しいよ〜、欲しいさ〜。

 そう言えば、iPod miniを買うとして(←買うとしてて)、今あるiPodと同時(もしくは交互)に接続なんかしちゃったりしても、ちゃんと個別のモノと認識していい感じにsyncしてくれたりなんかしちゃってくれるのだろうか。4GBなのでiPod mini用プレイリストとか拵えて、それとsyncしちゃいたいよねぇ、20GBの方は丸ごとsyncだけどさ。できるよね、流石に。

最近のたくぅさん。link

 某WebObjects本をやっと読了したので(←二ヶ月かかってんし)、このアプリの書き直し作業に入る予定。は未定。
 追加したい機能とか思い浮かばないので、純粋に内部的な変更になります。若干最適化されるかな。

 ドンキーコンガ2は、エキスパ金のDKマーク全付けまで後3曲。てやっていない人には何の事だかわからない。
 前作での修行が効いているのか今作は難易度が下がっているのか、ハードまではほぼ一発で金のDKマークが付きました。エキスパは……、励んでいます。

 なんとなく純正Apple Mouseを引っ張りだして使ってみてたりして。

 純正Apple Keyboard(JIS)の“return”キーは、真ん中辺りを叩かないと引っかかってしまって上手く押せない。そして私は適当に叩いているのでよく引っ掛ける。つぅ事で、何か良さげな(←主に価格的に)キーボードは無いモノかと。いっそUS配列にしたろうかと。
 ちなみに、私がコンピュータ始めた時には既にMacにもJISキーボード付属でしたけれど、同時に触り出していた各UNIXな機械の方がUS配列だったので「どっちでもいいかなぁ」とか思う人。当時は座る端末に合わせて普通に打ち分けができてたっけ。今はどっぷりJIS慣れしてまして、“英数”キーとか“かな”キーとか使いまくってますが。あら、じゃー、JIS配列じゃないとダメかも。

最近のたくぅさん。link

 何も梅雨が明けたからってそんなに急に暑くならなくても……。と毎年言っている様な気がする。

 どうしてWOComponentにvalueForBinding()はあるのにtakeValueForBinding()がないのだろう。setValueForBinding()があるので困りはしないけど、なんか気持ち悪い。
 つか、WOComponentでさえも“お初にお目にかかります”的メソッドがちらほらな自分に(略)。

 輸入盤のCDはお値段がアレでCCCD率も低いのでわりと簡単に買ってしまう。邦盤はお値段がアレな上にCCCD率も高いので事前に調べたり何だり面倒であーくそもー……。そういう事だぞ。

 コンガ2はエキスパ金DKマーク全付けまで後一曲。が、その一曲がっ。

 バリアブルでいいのでSTOKKEの椅子も欲しい(←欲しいモノばっかりやな)。バランス取ってみてー。