netail.net

_ ワイン ▲

デパート地下でワインの試飲だけしてきた．

アルビオン・カベルネとルブラート・アリアニコ．どっちもフルボディの赤ワインで，3000〜5000円の妥当な価格帯．美味しかったので，そのうちボトルで買ってみよう．

普段は置いてないらしいが，しばらくは取り扱うと試飲コーナーの店員さんが言っていたので，即時購入は保留．

_ 紅茶 ▲

レピシエでアッサム・ディコムを補充しようとしたら売ってなかった．仕方がないので，アッサムのディクサム・フルリーフを100g購入．ついでにウヴァ・ハイランズを50g補充．

そこでもらった「レピシエだより」に，「電子レンジで作るチャイ」というのが載っていた．

作り方はとてもシンプル．1. ティーバッグ＋50cc程度の水を電子レンジで加熱．沸騰させる．2. 沸騰後，５分ほど蒸らしてからティーバッグを引き揚げる3. ミルク150ccと，砂糖を加えて，電子レンジで沸騰しない程度に加熱．

しかしティーバッグのお茶なんて持ってないので試そうにも試せない :-)

_ 論文 ▲

Katharina Mehner:JaVis: A UML-Based Visualization and Debugging Environment for Concurrent Java Programs.Software Visualization, LNCS 2269, pp.163-175, 2002.

実行トレースから UML のシーケンス図を生成して，その上にデッドロック情報を乗せる．デッドロック検出アルゴリズムは既存だし，シーケンス図を作ること自体は今のところ力技のようなので，新規というわけではないが，あると便利そう，というところ．

シーケンス図を作る，というところで，Visualizing the Execution of Java Programs の筆者らが「スケーラビリティがないので実際には使いにくい」という主張をするのは仕方がないところかも．

_ 論文 ▲

Wim De Pauw, Erik Jensen, Nick Mitchell, Gary Sevitsky,John Vlissides, and Jeaha Yang:Visualizing the Execution of Java Programs.Software Visualization, LNCS 2269, pp.151-162, 2002.

Java のプログラム実行時情報を可視化するJinsight というツールを紹介した論文．

オブジェクトのインスタンス数・呼び出し数・消費メモリ量・実行時間を見る Histogram View，呼び出し・参照関係をツリー状に表現して，枝にその参照が何回ずつ起こっているかを表す Reference Pattern View，オブジェクトを「世代」にグループ化することで行うメモリリーク分析（「捨てられるべき」オブジェクトグループへの参照を誰かがこっそり保持していないか調べる），プロファイラ結果を図示する Execution View，呼び出し回数の比率を示す Call Tree View がある．

Execution View は，全部のメソッド呼び出し関係を図示するようで，かなり見づらいが，150万行程度の実行履歴でもちゃんと表示できているあたりは，かなりがんばっている．

主にメモリおよび実行性能上の問題に対処することが目的らしいので，このあたりで十分なのだろう．なんとなくだが，Eclipse の Java プロファイラツールで使われているビューに似ている気がする．IBM の人たちだし．

関連研究としては，・情報をいかに減らすか（適当な単位で分割するなど）・いかに探すか（クエリーベースの探索ツールなど）があげられる．UML で並列性の問題を可視化するツールなどもあるようだがスケーラビリティの問題が大きい，とも述べている．また，一般的な情報表示よりは，特定のタスクに絞って便利な情報を提供するツールのほうが良い，とも述べている．

_ 紅茶 ▲

レピシエでもらったバニラティー１杯ぶんを淹れて飲む．濃いめに淹れてミルクティーにする，という方針で間違いなし．最近，ミルクを多めに入れるタイプのミルクティーがメインになってきた感がある．

単に濃く出すのに慣れてきただけ？適当に出しても十分飲めるし．

_ [work]資料作り ▲

来週の出張は２つくっつけてしまったので，持っていく必要がある地図やら書類やらが微妙に多いことが判明．

地図やら印刷しつつミーティングの資料も仕上げる．今回は，M1 の人の未発表の研究内容が題材なので材料のスライドがなくて，細かいところ詰めるのに約１人日かかってしまった．ミーティング資料は，学会発表と違って時間の幅なんかをそれほど考えなくていいのでお気楽に作れる．発表練習もいらないし．

_ [論文] イディオムのアスペクトでの置き換え ▲

Bruntink, M., van Deursen, A. and Tourwe, T.: Isolating Idiomatic Crosscutting Concerns.

Proceedings of ICSM 2005, pp.37-46.

Cプログラムでのパラメータチェックをしていたイディオムを，アスペクトとして分離したよーという話．

イディオムを使っているとき，どうしてもイディオムから逸脱した要素（たとえばパラメータチェックが必要ない状況）も出てくるが，アスペクトとして必要な場合と必要でない場合とが両方とも明記されるので，理解容易性は向上すると述べている．保守性については，関数のシグネチャが変わったときにアスペクト側にも更新が必要という潜在的なリスクを背負うので，たとえば存在しないシグネチャをアスペクトが指定している場合は警告を出すとかいったチェックで対応している．

_ [論文] 分散システムのロギングのAOP実装 ▲

Briand, L. C., Labiche, Y. and Leduc, J.: Tracing Distributed Systems Executions Using AspectJ.

Proceedings of ICSM 2005, pp.81-90.

RMI を使った分散システムで，通信時には特定のコーディング規約に従っているという前提で，AspectJを使って分散システムの実行時情報を集めました，という論文．ロギングサーバを１つ作って，そこへデータを集めるような実装になっている．

実装のやり方，アスペクトのソースなんかが論文の大きな割合を占めている．ケーススタディでは実行時間の評価を行っており，分散システムだと，ネットワーク越しの処理なんかが遅くなるのでログ取りが重くなるのかと思えば，そうでもない（20％程度余分に時間がかかる程度）．数百ミリ秒で終わる処理だから微妙ではあるが．

_ [VolumeDeskbar] ホットキー機能の追加中 ▲

なんとか手元では動くものができたので，もう少ししたらリリースします．あまり極端に遅れないようにはするつもりですが，ドキュメント更新する時間に依存して時期は後ろにずれます．

THotkey.Hotkey の値が Num 8 と Up キーを区別しない（HKM_GETHOTKEY で獲得した情報が TShortcut 型に変換される段階で情報が落ちる）という仕様のおかげで，カーソルキーが Num 2 4 6 8 で表示されてしまいますが，実用上問題ないので放っておくことにしました．

フルスクリーンな環境については，ピンボールのフルスクリーンモードでいちおう実験してみました．音量のポップアップの表示が解像度と色数の都合で普段より汚く見えますが，ちゃんとキーは有効で，変更後の音量も分かるみたいです．