2005年8月アーカイブ

Google Talkが始まった。インターネットを利用した一般ユーザ向けサービスとしてはごつい市場を持っているIMだけに、Googleがそこに目をつけて参入してくるのはまぁ理解できる。IM市場じゃ(少なくとも日本では)MSNメッセンジャーが一番のシェアを持っているだけに、対Microsoftという構図の中でGoogleがIM市場で対抗ソフトを出したいという気持ちも十分に理解できる。実際にさわってみたところ、細かいところの詰めが甘いのはβ版であるということで大目に見よう、これまでになかった目新しいところとしては、新鮮な感じのするUIが目につくところ。ただ、Googleが新しくサービスをするからには、やはりこれまでになかった斬新なものを期待してしまうのは私だけなんでしょうかね。

私は何人かの身内のためだけのチャットに出入りしている。Webブラウザを使ってサーバにアクセスし、CGIで共有のチャットの場を提供しているという環境になっている。サーバで集中処理してるんで、チャットのログがすべて記録される。そのチャットのログをHTMLで保存し、NamazuとMySQLを使ってデータベース化し検索できるようにしている。かれこれ6年近くも続いているチャットサーバなだけに、過去6年間の身内周りの出来事がすべてこのチャットのログに記録している。このログを瞬時に検索できるサービスに仕上げ、自分の過去の出来事の日時やら曖昧な記憶の確認やらに重宝している。

ただ、チャットとしては今はWebブラウザとCGIを使ったタイプは主流ではない。IRCなんてのも、最近は使ってる人は限定されてきているんだろう。今は、手軽なチャットシステムの座はIMとなっている。たいていのIMでは、他のユーザと交わされた会話のログがテキストファイルとしてローカルに保存される。ここ、ここなんよ、私が不満を感じているのは。確かにローカルにログは保存される、だけど複数のマシンを使い分けている場合には、IMの会話ログが分散してしまう。これが不便で煩わしくて面倒で残念でならない。まぁ工夫すれば一カ所で集中管理できなくもないだろうけど、どんな工夫を入れるかねぇ、あんま面倒な仕組みは入れたくないんだけどねぇ。

聞くところによると、GoogleはGoogle File Systemなるものを持っているそうじゃないか。これは簡単に言うと、ごく普通のパソコンを複数(数百台)あわせてクラスタ化し、データを冗長化し冗長化が失われたら(=ノードが壊れたら)自動的に修復する(=壊れたノードの代わりを自動で用意する)機能を持ったOSをそのパソコンに乗せてしまっているものです。1台のパソコンが壊れたら、壊れたパソコンを引っこ抜いて(パソコンはブレードです)新しいのをさしてしまうだけでよい。大事なデータはOSが勝手にシステム全体で守ってくれる。信頼性の高いストレージを低いコストで構築しているのがGoogleの強みだそうな。

話がそれた、要するにGoogleはネット上の大容量ストレージな訳で、せっかくGoogleがIMサービスをするならIM上の会話をすべてGoogle側で保存してしまえばいいんでないの、と思うわけです。もちろん、保存するだけではなく高速に検索できるとうれしい、検索結果が的確ならなおよい。今更いわなくてもいいだろうけど、GoogleはWeb検索サービスでNo.1の企業、そんな企業ならIMログ検索においてもきっといいものを提案できるに違いない。

もちろん、会話ログがサーバ上に残ってしまうとセキュリティやプライバシーの面で不安に思う人もいるかもしれない。ただ、同様の懸念はWebメールサービス全般にもいえることなので、ことIMに限って騒ぎ立てるのもどうかと思う。私としては、そういうよくありがちな話はおいといて、とりあえずGoogleに任せてみたい・Googleに新しいものを期待したい、そんなふうに思う。

実に10ヶ月以上も悩ませ続けたBF1942のフリーズの原因がたぶんつかめた。UX16(USB-MIDIインターフェース)が悪さをしているようだ。これを抜くと症状が治まった。

UX16を指していると、BF1942のリロード時のBlackScreen.exeの画面の時にそのまま半フリーズ状態となってOSレベルでまともに機能しなくなる。たちが悪いのが、100%再現できるわけでなく10回に1回くらいフリーズするくらい。つまり長い間BF1942をプレイしているとこの症状に出会ってしまい、そのままリセットスイッチを押すしかなくなる。

UX16のドライバのバージョンアップ履歴から察するに、HT(HyperThreading)も関係しているのかも。よくわからないが、いずれにしても、UX16をはずしてからこの悩ましい症状に出くわしていないので、たぶんこいつが犯人でしょう。

関連「3GC型とVFX」

MIDlet-OCL → MIDxlet-API
MIDlet-Application-Range → MIDxlet-ScreenSize
MIDlet-Network → MIDxlet-Network
他いくつか「MIDlet-hoge → MIDxlet-hoge」なものがあるので要注意

Canvasのキーイベントで現れるkeycodeは、以前はgetGameActionを介さなくても判定できたが、3GCではkeycodeとGameActionを区別して識別すること。面倒なことを考えたくないなら、

public int getMyGameAction(int keycode){
 switch( keycode){
　case  KEY_NUM0 :
　case  KEY_NUM1 :
　case  KEY_NUM2 :
　case  KEY_NUM3 :
　case  KEY_NUM4 :
　case  KEY_NUM5 :
　case  KEY_NUM6 :
　case  KEY_NUM7 :
　case  KEY_NUM8 :
　case  KEY_NUM9 :
　case  KEY_POUND :
　case  KEY_STAR :
　　return  keycode ;
　default:
　　return  getGameAction(keycode) ;
 }
}

で、keyPressed(int keycode)などのメソッドの最初で、kecode=getMyGameAction(kecode)としておけば既存の場合と同様にいける。もちろん既存の機種でも問題なく動く。

Canvasの画面などのバッファは随所で使い回されているため、Canvasのpaintの最初でfillRect( 0, 0, width, height)としておく必要がある。こうしないと、前のDisplayableのゴミが残ることがある。

drawStringなどでは、必ずGraphics.HCENTER|Graphics.TOPのように縦横とも位置指定を入れないといけない。Graphics.TOPだけだったりGraphics.HCENTERだけだったりすると、そもそも文字が表示されない。

デフォルトのTimeZoneがJSTではなくGMTになってる・・・

月日の流れは速いもので、私が自動車免許を取得してから早5年半がすぎてしまいました。ああ、もはやおっさんといわれる年齢も近いかも・・・

という前置きはさておき、5年半ということで2回目の自動車免許更新がやってきました。1回目の更新は初回ということで強制的に長い教習を受けさせられしかも有効期間は+3年ですが、2回目以降は優良ドライバ(無事故無違反)ならば教習も1時間で有効期間が+5年となります。

この免許更新に関する規則も最近変えられたばっかりで、昔は優良ドライバでも有効期間が3年だったんですよね。また、昔は免許更新期間は誕生日の1ヶ月前から誕生日までだったんですが、今は誕生日を挟んで前後1ヶ月ずつになってます(免許の有効期間も誕生日の1ヶ月後まで)

そんな具合に、道路交通法もちょくちょく改正がなされてます。たとえば、今回の教習で聞かされた近々改正予定項目でおもしろいものに、自動自動車免許の新設なんてのがあります。これって、大型持ってなくても乗れるくらいのトラックを運転する人には大きく関係ありそうですね。ちなみに、既存の区分で免許を持っている人には影響がないようで、今後免許を取る人に影響があるということです。

ちょっと前に初めてTOEICを受けてみて、そしてその結果にorzしてましたが、今回某機会にTOEICを受けさせられるということがあり、その結果がちょっと前に返ってきました。

Listening: 280, Reading: 345ということで、前回(L: 265, R: 250)と比較して大幅アップ。全く試験勉強もやらずにこんなけあがってええんやろか、とか個人的に思いながらも、ひとまず600を超えたんでそこそこ浮かれ気味。この分だと、特にListeningを重点的に鍛えれば700台も夢でないかも!?

・・・浮かれすぎ？(お)

動機はともあれ、なにかしら急に思い立って、stViewerの動作速度改善作業をやってみた。

ソースの修正ってっても、動作時にクリティカルになってる部分、つまり動作に時間がかかっているところの修正を行いました。もっと具体的にいうなら、ファイルからの読み込み時と検索時ですけどね。もともと、これまでよりも速度を改善するためのロジックをぼんやりイメージしていたので、それを実際にソースに落としてみたというところです。

そしてその結果、検索速度はこれまでの20倍以上(当社比)となり大成功。しかし、ファイル読み込みは逆に遅く(当社比)なってしまいました。ううーーーん、これは意外。プログラマ的直感で絶対に早くなると思ってたのに。。

具体的には以下のような感じです。IOから読み込んだのがbyte[] bufに入っているとして、String[] bodyへ1行ごとにぶった切った文字列を入れていくとします。従来が

String tmp = new String(buf);
for(int i=0; i<100; i++){
　body[i] = tmp.substring( i*20, (i+1)*20);
}

for(int i=0; i<100; i++){
　body[i] = new String( buf, i*20, 20);
}

これまではsubstringを実行しまくっているせいで無駄なStringのインスタンスを作っていた、その分が省けて実行速度も改善するだろう、と思いこんでいたわけです。ところが、JavaVMのString周りのインスタンス生成におけるメモリ管理がうまいんだろうか、逆に遅くなってしまいました。動作状況から察するに、どうもnew Stringを呼ぶ回数が増えた分ネックになってしまったという感じです。参考までに、公開しているstViewerのソースコードのアーカイブには、「view.java.bak」としてその改変したやつを添付しておきます。

まぁそんなわけで、思い立って行動した時間のうち、ファイル読み込み関連のソース修正(+そのパフォーマンス測定)にかかった時間3時間ちょいが無駄になりました。誰か利子つけて返してください。おながいしまつ。