netail.net

_ [hyCalendar] 1.3.3 リリース ▲

再起動時にオプションを破棄していたバグが一番の修正点で，あとはハイパーリンクが全角文字対応になったり，日付メモのインポートができるようになったり．

Kt関数アドインが昭和の日に対応してくれていたので，配布アーカイブ内の休日情報（holidays.txt）も新しいものに更新した．

_ お土産を買う ▲

香月堂のお店でおみやげを１つ買うついでに，ばら売りのもみじ饅頭を１個だけ買ったら，売店の人がおまけしてくれた．ちょっと嬉しい．

_ [ツール] Volume Deskbar 1.0.4 リリース ▲

全体音量とWAVE音量との同時制御を可能にしてみた．

全体音量とWAVE音量の積で効果が表れると，音量バーの変更量に対して実際の音量変化が線形ではなくなるという問題があるかと思っていたのだけれど，実際やってみると，そう気になるほど極端な変化は起きないようなので，そのままリリースすることにした．

_ 本棚の整理 ▲

一部RPG研に寄付することにして，本棚から除去．E.A.ポオの小説全集と詩集（文庫版）は，MLで聞いてみたらすぐに引き取り手が名乗り出てくれたので，古本屋に持っていく手間が省けてありがたいところ．

_ [AspectJ] 単体テストでは動的アスペクトのほうが楽？ ▲

アスペクトをテストしようとすると，AspectJの場合，テスト用クラスと一緒にアスペクトをコンパイルして実行，という作業が発生して，構成ファイルをいちいち用意したり，けっこう手間だったりする．普通にEclipse＋AJDT でコンパイルしてると，標準ではすべてのアスペクトが同時にコンパイルされるので，単体テストにならない．

Dynamic Deployment を持った処理系（CaesarJとか）だと，JUnit でいうところの setup メソッドでアスペクトをテスト用オブジェクトに deploy して実行するというコードが書けるので，テスト容易性という観点では有利だといえそう．コンパイルあたりを ant で自動化した場合でも，実行コストの差だけでなく，テストケース側に「どのアスペクトがdeployされた場合のテストか」が明示されている点は有利だと考えられる．

動的なほうが，どのアスペクトがバインドされているかコンパイル時には分からないので問題が起きたときの調査は難しそうという印象があるのだが，コンポーネントの接続などに限定したアスペクトなら，動的に適用したほうが問題が簡単になったりするのかもしれない．

ということで，CaesarJとかに少し心惹かれているこの頃．

_ 黒豆コーヒー ▲

というものをお土産にもらったので飲んでみた．コーヒー＋黒豆なので，きな粉を入れたのに近いと言えそう．黒豆とおぼしき香りのぶん，コーヒーっぽさはあまりない．

ちょっと甘みがあるので，ココアみたいに牛乳に溶かすと美味しく飲めるみたい．

_ [VolumeDeskbar] 1.0.4 の設定ダイアログ ▲

コマンドボタンが Windows XP スタイルじゃなくなったのか，と報告をいただいたので，少し調べてみたら，ＰＣによって微妙に「設定」グループボックスが表示されなかったり，XP スタイルじゃなくなったりするらしい．開発環境のPCでは分からなかったのだけど．

愉快な問題なので，もしかしたら設定ダイアログのウィンドウリソースが破損しているのかな，と思ってクリーンビルド（Delphiの「再構築」）したらいちおう直った．

テスト用プロジェクト（ボリューム調節のバーをタスクバー上ではなく，普通のウィンドウ上に出す）側の中間コンパイル結果ファイルが悪さをしていた可能性が考えられる．

_ [論文] クラスの使い方の実行時情報からの抽出 ▲

Salah, M., Denton, T., Mancoridis, S., Shokoufandeh, A. and Vokolos, F. I.: Scenariographer: A Tool for Reverse Engineering Class Usage Scenarios from Method Invocation Sequences.

Proceedings of the 21st International Conference on Software Maintenance (ICSM 2005), pp.155-164, Budapest, Hungary, September 2005.

プログラムの実行履歴（各オブジェクトへのメソッド呼び出しの履歴９から，そのクラスの使い方を探してこようというもの．インタフェース記述でメソッドの呼び出し順序の解説なんかを書こうという動きもあるし，この手の研究が最近流行っている気がする．

「メソッド呼び出し列」の集合から，その中のメソッド列群を代表するような "canonical set" を選び出し，他のメソッド列は canonical set の各要素のどれに属するかを分類する（canonical set の１要素に代表されるメソッド列の集合を canonical group と呼ぶ）．で，１つのcanonical group に属するメソッド列たちに対して，それらを簡潔に表現するような正規表現を見つけてくる．ユーザには，あるクラスに対する典型的なメソッド呼び出し列を表現した正規表現の集合が出力として与えられることになる．

canonical set を計算するところは，各メソッド列を頂点として，他のメソッド列との類似度を重みとした完全グラフを作ったとき，その中から頂点集合 V を，「V に含まれる頂点同士の辺の重みの総和ができるだけ小さく，V と V の外部にある頂点をつなぐ辺の重みの総和ができるだけ大きくなるように」選び出すという最適化問題になる．これに対して，類似度には edit-distance を使って，既存の近似アルゴリズムを適用している．

canonical set が決まると，他のメソッド呼び出し列は，一番類似度の高い（同じ類似度が複数あればそれらすべての）canonical group に分類され，あとはそこに正規表現での近似処理が適用される．

適用実験では，正規表現クラスとソケットクラスに対して適用しており，正規表現のほうは，match してから isMatch を何回か呼び出す，というそれっぽい出力が得られている．ソケットのほうはある部分列（getLocalAddress/getLocalPort/getPort/getInetAddress）が繰り返し登場するパターンが出力されていたが，実はソケットへの入出力を行うストリームクラスが，これらのパターンを作り出していたらしい．このような特定クラスからの関与が，自動的に判別されてから情報が出力されるなら，そこそこ便利な手法かもしれない．

_ [論文] 相互依存したプログラム要素の発見方法 ▲

Binkley, D. and Harman, M.: Lcoating Dependence Clusters and Dependence Pollution.

Proceedings of the 21th International Conference on Software Maintenance (ICSM 2005), pp.177-186, Budapest, Hungary, September 2005.

プログラムの中に，相互依存するような要素群があると，保守が難しくなる．

依存関係はプログラムスライスによって調べることができるが，相互依存関係を持った要素の数が多いかどうか（問題かどうか）を判断するのは難しい．

そこで，相互依存した頂点から計算したスライスはまったく等しくなり，従ってスライスのサイズも等しくなるという性質を使う．

各頂点から計算したプログラムスライスを，横軸にサイズ順に並べて，縦軸にサイズをとると，突然サイズが大きくなり，しかもサイズが等しいようなスライスの固まりが可視化できる．そのような形が現れたら，そこはまったく同じスライス（相互依存関係を持った頂点群）が並んでいるのではないか，と開発者は判断できる．必ずしもサイズが同じ＝スライスが等しいとは限らないが，ほぼ一致することを実験的に確認している．

このような相互依存したコードの固まりを Dependence Pollution と呼び，それをリファクタリングすることで，スライスサイズを減らせる（影響の量を減らし，回帰テストなどのコストを下げられる）と主張しており，ケーススタディとして様々なプログラムに対して適用し，実際に問題のありそうな部分を調べてリファクタリングすることでスライスサイズの平均値を大きく減らせる例などを示している．

グラフの中で，ループした要素を見つけたいというときに，そこからたどり着けるノードの数でソートすれば楽，という発想は，何か他でも使えるかもしれない．

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

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％程度余分に時間がかかる程度）．数百ミリ秒で終わる処理だから微妙ではあるが．

_ Call for Paper を見てたら ▲

First International Conference on Software Engineering Approaches For Offshore and Outsourced Development (SEAFOOD) というのが開催されるらしい．Conference Site.

露骨な名前だなーと思ったら，開催場所は ETH Zurich，Switzerland．何か名産でもあった？単に語呂合わせ？

それにしても，seafood で web 検索したとき，ちゃんと当たるんだろうか．ドメイン名にseafoodが入ってるから大丈夫なのかな…．

_ 書籍をRPG研に寄付 ▲

ソードワールドSFC/PCシナリオ100本集と，クトゥルー関連の書籍色々を寄付してきた．まだたくさん本が転がってるので，順次処分していく必要あり．

_ [論文] Micro Patterns＝クラス単位の実装コードのパターン ▲

Gil, J. and Marman, I.: Micro Patterns in Java Code. [ACM site]

Proceedings of the 20th annual ACM SIGPLAN Conference on Object Oriented Programming Systems Languages and Applications (OOPSLA2005), pp.97-116, San Diego, CA, USA., October 2005.

デザインパターンよりも実装に近いレベルでのパターンについて，ソースコードを分析してカタログを作ってみたという論文．設計の良し悪しの判断は難しいので，まず設計の違いについて調べてみる，といったことを言っている．

デザインパターンでは自動的なパターンの適用・認識が困難であることを踏まえて，Micro Pattern の特徴は，機械的に判定できるように定義してあること．たとえば「メンバーを持たないインタフェース」のように，属性，型名，メソッドのシグネチャなどから決定する．また，１つのモジュール単位で，パターンにマッチするかどうかを判定できるようになっている．

Micro Pattern を共通の語彙として使うといった使い方はデザインパターンと同じだが，Micro Pattern はそれぞれ，特定の設計問題に対する解法というわけではなく，もっと一般的な道具のようだ，とも述べている．

どんなパターンがあるか，なんかいずれ使うかもしれないのでいちおう日本語版っぽいものを作ってみた．

統計調査では，JDKやTomcat，Antなどを集めてきて，それらの中から各クラスがどの micro pattern に該当するかを調べている．統計によって，言語による制約ではなくちゃんと設計から生じたものであることを確認し，また，１つの仕様に対して，違う実装でも同じパターンを使っている傾向があることを確認している．

結果として，約75％のモジュールは少なくとも１つのmicro patternに該当する．登場回数では，Sink，Stateless，Implementor，Overrider，Pure Type の５つで約58％を占めた．

一方で，パターンごとの条件は排他的ではないので，２個以上のパターンに属するものも数多く，最大では６個のパターンに該当していたらしい．同じパターン群に属したクラスは互いに構造的に類似していたようで，Canopy/Restricted Creation/Overrider/Sink/Functional Object/Data Manager の６個セットに該当した１２個のクラスとか，Joiner/Pure Type/Stateless/Sinkにマッチした30個のクラスの例が挙げられていた．ある意味では，これらのパターンの組で，１つのパターンを定義しているといえる．

その他の調査としては，パターン群への分類の偏りを調べて，そこから得られる情報量を計算しており，定義したパターンによる分類には意味があることを確認していたり，複数の JRE ライブラリを比較して，パターンの出現率が同じ傾向であることを確認していたりする．

_ [日記CGI] 「リンク元」設定の変更 ▲

いわゆる検索エンジンからこのページへ来る→「リンク元」としてキーワードが載る→そのキーワード自体を検索で見つけてさらにこのページへ来るという動きが気になったので，「リンク元」として表示しない正規表現として検索エンジン系のを一通りを入れてみた．

_ [ゲーム] "鉄人" Mangband ▲

Ironman MAngband という企画の結果が出ていた．要は１ヶ月で得点・フロア数を競うというものだったらしい．ランキングで名前を選ぶと，そのキャラクターの dump 結果（"C" で表示される情報）が見られる．他人のアイテムやら銘の刻み方が分かって面白い．

_ [論文] コード変換を使用してのアスペクト抽出リファクタリング ▲

Binkley, D., Ceccato, M., Harman, M., Ricca, F. and Tonella, P.: Automated Refactoring of Object Oriented Code into Aspects.

Proceedings of ICSM 2005, pp.27-36.

アスペクトマイニングなどで，アスペクトにするとよさそうな範囲がαとωというマークで括られているとき，そこに適用可能なリファクタリングの種類を選び出し，そこから開発者が実際にどれを適用するかを選択し，機械的な変換によってアスペクトを生成しよう，という手法．

リファクタリングの種類としては，メソッドの先頭あるいは終端のコードを取り出す Extract Beginning/End，あるメソッドの前後に登場するメソッドを取り出す Extract Before/After Call，条件文を取り出す Extract Conditional，Return文の前に実行されるコードを取り出す Pre Return，ラッパーオブジェクトを追加する操作を取り出す Extract Wrapper の５種類．

リファクタリングを適用可能かどうかは，TXLという言語を使ってルール記述を行なっている．たとえば Extract Before Call なら，「α; 文; ω; メソッド呼び出し;」という列に対して「α(BC適用可能); 文; ω; メソッド呼び出し;」といったようにアスペクト適用可能マークを追加するプログラム変換として記述している．そして，適用可能なリファクタリングのマーキングが複数付いていたら，開発者が最大で１つ選ぶ（適用しないという選択肢もあり）．

実験では，JHotDraw をこれでリファクタリングをどんどん適用したら，Extract Begin/End，Extract Before/After Call，Extract Wrapper がほとんどを占めていたらしい．また，お互いに関連しない（DEF-REF 順序に関係ない）文を入れ替えることが必要なケースは２割程度．

リファクタリングの適用は，それぞれのコード片に対して個別に作用しているようなので，その後でうまく一般的なポイントカット定義を作ってアスペクトをまとめないと，小さなアスペクトが大量に生成されるだけのようにも見えた．

_ [VolumeDeskbar] 全体音量とWAVEの連動＋他のツールとの相互作用 ▲

掲示板で報告いただいた内容を調べてみた．

ViC-3(http://www.forest.impress.co.jp/article/2004/02/26/vic3.html)というツールは，アプリケーションの音量を（おそらくウィンドウクラスごとに）覚えておいて，そのアプリケーションがアクティブになったら既定の音量に戻すということをするものらしい．

Volume Deskbarの「全体音量とWAVEの連動」機能を有効にした状態で，全体音量とWAVE音量を違った値に設定するようViC-3が働きかけると，たとえば ViC が全体音量として 10 をセットするので，Volume Deskbar がそれに連動してWAVE音量も 10 にセットする．ここまでは良いのだが，ここで ViC がWAVE音量をたとえば20にセットしようとすると，Volume Deskbar が全体音量も20にセット，ここでViCは再び全体音量を 10 にセットしようとし，Volume Deskbar がそれに反応してWAVEを10にしてしまう，といったように音量自動調整がループを起こしてしまう．しかも，一方のプログラムから見ると，音量の調整はいちおう成功しているのに，すぐに元に戻されているという程度のことしか分からないので，対処のしようがなかったりする（ViC側がセットしようとする音量が，全体音量＝WAVE音量だったら大丈夫かもしれないが）．

_ [論文] AOPで書き直した場合のメトリクス値の変化 ▲

Tsang, S. L., Clarke, S. and Baniassad, E.: Object Metrics for Aspect Systems: Limiting Empriical Inference Based on Modularity.

Trinity College Dublin technical report.

ある traffic simulator を改造して，非同期処理とかメモリ管理とかをアスペクトとして実装しなおしたとき，AOPでの実装はOOPでの実装に比べてどう変わってるのか，というのをCKメトリクスに基づいて調べた論文．CKメトリクスはそのままでは使えないので，クラスの数としてアスペクトの数も数える，といった簡単な拡張をしている．

アスペクトによって結合が弱まるけれど，登場人物数は増えるので，CBO (Coupling Between Objects) が大きく減少するかわり WMC (Weighted Methods per Class)，RFC (Response For a Class) は増えてしまう．その結果，保守性は大きく向上していたが，WMC と RFC が保守性と理解容易性の足を引っ張る部分がある，と述べている．再利用性は，RFC の影響は受けないと考えられるため向上しており，テスト容易性はほとんど変化がないようだと述べている．

一点，よく分からなかったところは，論文では表を作ってどのメトリクスが保守性・理解容易性・再利用性・テスト容易性のどれに影響を与えるかを示しているが，文章の書き方からして，具体的数値で（たとえば，CBOの減った値に対してRFCの上昇値がどう，とか）向上や悪化を判断しているわけではなさそうなところ．

(追記)An Evaluation of Aspect-Oriented Programming for Java-Based Real-Time Systems Development というタイトルで，ISORC 2004, pp.291-300 に採録されているものがたぶん同じ話だと思われる．

_ [論文] 依存関係を表明として記述 ▲

Jackson, D.: Abstract Analysis with Aspect. Proceedings of ISSTA 1993, pp.19-27, Cambridge, MA, USA.

アスペクトといっても，アスペクト指向のアスペクトではなく，筆者が提案している解析手法のこと．要は手続きごとに，出力変数 x は入力変数 y に依存している，といったデータフロー関係を記述することで，それがない場合にはエラーとみなす．これによって，大事な変数の中身を途中で上書きしてしまうといったエラーを検出することができる．

「少なくともなくてはならない」条件を書くだけなので，仕組みとしては単純だし，誤検出なんかは起きない（そのかわり完全な条件ではないので，素通りの可能性はある）．実現の方法とか，その辺はあんまり書いてなかったので適当だが．

_ [論文] Aspectual Caml の論文を再び読み直してみた ▲

Hidehiko Masuhara, Hideaki Tatsuzawa, Akinori Yonezawa: Aspectual Caml: an Aspect-Oriented Functional Language.

Proceedings of ICFP 2005, pp.320-330, Tallinn, Estonia, Sep 205.

関数呼び出しが join point なのはいいとして，関数自体が変数に束縛されて違う場所で使われたりするから within みたいな静的スコープのポイントカットの使用がちょっと怖い気がした．

関数型言語的に嬉しくなさそうな副作用を伴う処理を全部アスペクト側に追い出すと，プログラムが簡潔になったりするのかなぁ，と思ってみたり．いわゆる計算方法自体と，入出力系などはまったく違うものだから分けて記述しましょう，という考え方はよさそうな気がするけど…．誰かに試してみてほしいような，別にどうでもいいような．

_ [VolumeDeskbar] バグをごそごそ修正 ▲

タスクバーからドッキング解除した状態のデスクバー(IDeskband)を閉じると，CloseDW メソッドの処理後にウィンドウに WM_DESTROY が飛んできてしまうようで，無造作にクラッシュしていた問題が判明．フォームを解放するときは TCustomForm.Free ではなく TCustomForm.Release を使わないといけない（Releaseは，必要なメッセージ処理が終わるまで解放を遅らせる）というのを忘れていたのが原因らしく，修正した．

ドッキング中に「タスクバーを閉じる」が選ばれたときは，親ウィンドウの破棄が起きないので，問題は起きないらしい．

それにしても，ドッキング解除時は，なぜか縦方向に伸縮するタイプのウィンドウが用意されるらしい（サイズを返す構造体に x メンバに代入した値がウィンドウ高さ，y メンバに代入した値が横幅になる）．縦横の方向の指定というのは，やり方がまったく示されていないようなので，とりあえずこのままにしておく．

_ [VolumeDeskbar] 原因は，無効になるウィンドウハンドルだったらしい ▲

昨日修正した Form.Free → Form.Release だけでは問題は解決せず，結局，引き続きバグ修正作業．色々ログを取りながら調べた結果，実は現状の実装に色々問題があったことが判明した．

原因その１は，フローティング状態などの Deskband を閉じた後で，再び Deskband を表示したとき，新たに生成した TMixer が内部的に生成するコールバック用ウィンドウハンドルがなぜか無効になってしまい，処理に失敗していた．こちらの原因は不明だが，Deskband に表示しているウィンドウのハンドルを使うようにしたらエラーは起きなくなった．

また，TPopupMenu のコンストラクタでは，Application.Handle グローバル変数が参照されており，ドッキング解除後に Popup Menu の動作がうまくいってなかったのはこのためのようだった．Popup Menu オブジェクトを完全に除去してしまったら，ツールバー自身の QueryContextMenu 関数呼び出しがポップアップメニューの作成に使われるようになった．

それから，SetSite での古いSiteオブジェクトへのSite.Releaseメソッド呼び出しが，どうも問題を引き起こしていたらしい．呼び出しを書かないと，フローティングウィンドウを閉じたときにオブジェクトが破棄されないように見えるのだが，書くと，今度は実行時エラーで explorer がこける．何か実装を勘違いしているのかもしれない．とりあえず，エラーを起こさない方向で修正．（追記）SetSite(nil)のときに古いSiteへの参照さえ nil にすれば，Release 呼び出しは不要．

_ [ツール] サクラエディタで単語カウント ▲

マクロがあるのかなーと思って検索しても見つからなかったし，それらしいコマンドも見当たらなかったので，wcコマンドを呼び出す１行マクロを書いてみた．wordcount.ppaとして以下の内容を書いて，設定の[共通設定]で登録して，ついでにショートカットキーも割り当てると，まあ，それなりに使える．マクロ用に使っているらしい ppa.dll （本体とは別配布らしい）とか，存在を初めて知った．

S_ExecCommand( 
  S_ExpandParamete(
    'C:\cygwin\bin\wc.exe "$F"' ), 1 )

2006/2/4 追記: この定義を使った場合，ネットワーク上にファイルがある場合，うまく動かない（"\\"が認識できないため）．また，ファイルが保存されてない場合も，"(無題)" が wc.exe に渡されてしまうので，処理に失敗してしまう．

2006/3/26 追記: 新環境へ移動するついでに調べている途中に気づいたけれど，サクラエディタのマクロと正規表現としてワードカウントのWinShell使った実装が公開されている．

_ [VolumeDeskbar] さらに問題の修正 ▲

デスクバンド情報をウィンドウ側に通知するために IOleCommandTarget のポインタを取得していた（SetSite で渡ってくる引数を参照型変数に代入していた）のに，それを SetSite(nil) のときにきちんとその参照型変数を nil に戻してないのが，実はオブジェクトの解放がきちんとおきない原因だったらしい．

Microsoft が提供している Deskband.cpp のサンプルでは，こんな通知処理なんかはしてないので，気づかなかった．

たぶん，参照されている限り解放しない（カウントが０になった時点で自動解放）という賢いコードなのだろうけど，今回みたいな循環参照環境（バンドが，自身を格納するウィンドウへの参照を保持してしまう）では，どうしようもなかった．

結局，正解の手順は: CloseDWでウィンドウを解放（このときにTMixerのインスタンスも解放）しておく→SetSite(nil)呼び出しのときに，古いSiteオブジェクトへの参照をすべて捨てる→デスクバンドオブジェクトのデストラクタが呼ばれる．

CloseDWでウィンドウを解放し忘れると，TMixer のインスタンスが生き残ってしまい，ウィンドウ破棄後に音量変更のメッセージが無効なウィンドウハンドルに届いてしまいエラーになるし，SetSiteで古いSiteオブジェクトへの参照を解放しないと，オブジェクトのデストラクタが呼ばれないことになる．で，参照の解放というのは，Delphiの場合は単に参照変数に nil を代入するだけで良かったらしい．

_ [VolumeDeskbar] 1.0.5ベータ版公開 ▲

サーバトラブルから無事復旧してくれたようなので，対象デバイス変更の実験以外は（たぶん一通りは）テストしたものを，一度β版としてリリース．これでバグあったら恥ずかしいな……．