netail.net

_ モジュール整理 ▲

パッケージの名前付けで悩み始める．システム内の「ある機能の GUI 部分」とするか「GUI のうち，ある機能を利用するための部分」のどちらにするべきだろう？

前者だと，こう． function1.actions, function1.gui, function2.actions, function2.gui

後者だとこうなる． actions.function1, actions.function2, gui.function1, gui.funciton2

やっぱり「どちらも actions である」ということと「どちらも function1 である」ということのどちらの意味が大きいかで決めるのだろうが，どうやって量るべきだろう？

_ 紅茶 ▲

記念品としていただいた W-N クリスマスティーを飲む．名前のとおり，クリスマスをテーマにしたキャラメル系の紅茶．

包装がとてもかわいらしい．写真

茶葉の外見的には，レピシエの "キャロル" などと違ってチップが入ったりしないので，控えめな印象．写真

しかし，何しろ一袋（５ｇくらい）しかない記念品．淹れるのに気を遣う．（後で気づいたが，２回に分けて淹れれば良かった）

茶葉が広がったほうがいいだろうという思い込みにしたがって，とりあえずティーバッグから出してしまう．お茶の葉の状態でもかなり香りが強いので，フレーバーティー苦手な人は駄目かも．お湯はカップ２杯分＋α．この＋αは実験用．写真

茶葉が開くまで３分くらい．わりと勘で．（写真は赤色ちょっと補正してみた）写真

愛用のティーセットを使って，ストレートティー，ミルクティーを淹れてみた．写真

ストレートティーは甘い香りの後に少しだけ渋味がくるので，悪くはないのだけど，２杯飲むには微妙かな？というところ．どっちかというとミルクティーのほうが後味がやわらかくてよい気がする．一緒にもらった "お勧め" レシピにはミルクを同量くらい入れると良い，と書いてあるけれど，今回は個人的な好みから，少しだけしか入れないことにした．

さて，あまった茶液で，さらに濃く出したミルクティーを作ってみた．濃く出したものは，ミルクを淹れないと，あまりの渋さ＋微妙な甘さで非常に不味いことが発覚．でも，ミルクを茶液と同量くらい入れてみると渋味が意外と落ち着いてけっこういける．server-img:tea5.jpg 濃さ分かる？

結果としては，ミルクティーが，ほふふーとため息をつきたくなるような幸せ感があってなんとも良い感じ．もともとの記念品効果＋クリスマスティーというコンセプトのおかげ？

_ tex2text ▲

Tex2Text.rb を地味に更新．Ruby 1.8 になって，文字列リテラル内のダブルクォートのエスケープあたりが微妙に変わって動かなくなっていたのを修正．tex2text 公開ページ

_ Windows でのマウスのホイール操作のフック ▲

Volume Deskbar 用に導入する気はないけど，いちおう調べてしまったので，まとめ．

フックを仕掛けるときは，SetWindowsHookEx 関数を使う．

// フック: ４番目のパラメータの値は，仕掛けたいスレッドによって適宜変更
// HInstance は，DLL への参照をあらわす変数
MouseHookHandle := SetWindowsHookEx(WH_MOUSE, 
                                    MouseHookProc, 
                                    HInstance, 0); 
// ここで，MouseHookProc の型は，次のとおり．
function MouseHookProc(code: Integer; wparam: 
                       WPARAM; lparam: LPARAM): LRESULT;

lparam の中身は，PMouseHookStruct（MOUSEHOOKSTRUCT へのポインタ）なのだが，ホイールマウス用の拡張メンバが付いたMouseHookStructEx へのポインタとして扱うと，後ろにある mouseData へのアクセスが可能になる．

// 構造体やらの定義
// Delphi 7 では， windows ユニットには定義が存在しないので
// 自前で定義が必要
PMouseHookStructEx = ^TMouseHookStructEx;
tagMOUSEHOOKSTRUCTEX = packed record
  MouseHookStruct: TMouseHookStruct;
  mouseData: DWord;
end;
TMouseHookStructEx = tagMOUSEHOOKSTRUCTEX;
// 参照方法の例
// メッセージが WM_MOUSEWHEEL のとき，
// mouseData の上位16ビットが，ホイールのスクロール量．
function MouseHookProc(code: Integer; 
                       wparam: WPARAM; lparam: LPARAM): LRESULT;
var
    mouse: PMouseHookStructEx;
    delta: Word;
begin
    if (code >= 0) and (wParam = WM_MOUSEWHEEL) then begin
        mouse := PMouseHookStructEx(lParam);
        delta := HiWord(mouse.mouseData);
        // delta の Word 型は符号なし16ビットなので，
        // 符号ありに変換してから使用する
         :

_ [論文]メソッドの呼び出し順序についての制約記述 ▲

Tran, N., Abramson, D. and Mingins, C.: Call-Ordering Constraints.

Proceedings of APSEC 2005, pp.291-298, Taipei, Taiwan, December 2005.

Design by Contract の一環として，特定クラスのメソッドの呼び出し順序，それらのメソッドが「必ず呼び出すメソッド」「呼び出すことはないメソッド」（プロトコル）を指定しよう，という提案．基本的には，メソッド呼び出しが状態遷移を表す非決定性オートマトンで定義される．

Behavioral Subtyping として，「親クラスで valid な呼び出し順序は，子でも valid である（子で失敗するなら親でも失敗する）」という条件を指定している．また，必ず呼び出すメソッド，呼び出すことはないメソッドについては，減らすことはできないが，増加することは許している．多重継承のときは，すべての親のプロトコルを満たす必要がある．

必ず呼び出すメソッド・禁止のメソッドについては，メソッド呼び出しごとにスタックに積み上げていき，新しいメソッド呼び出しが「呼び出すリスト」に該当しているなら，リストから（もう呼び出されたので）削除し，禁止メソッドに該当しているときは，違反としてプログラムを停止する．

実装は CLI 上で行なっている様子だが，手法としてはわりと素直な印象がある．

_ [論文] 起こりうるメソッド呼び出し列からの影響波及解析 ▲

L. Badri, M. Badri, and D. St-Yves: Supporting Predictive Change Impact Analysis: A Control Call Graphs Based Technique.

Proceedings of APSEC 2005.

単純なコールグラフで，呼び出し関係を追跡すると，順番の考慮がないのでほとんどのメソッドが「影響を受ける」判定になってしまうので，制御フローグラフ上で，メソッド呼び出し頂点だけを残した「Control Call Graph」を使うことを提案した論文．

記法として，繰り返し，選択，省略可能を {m1}, (m1/m2), [m1] と書くことでメソッドの呼び出し列を表現していた．あくまで静的アプローチだが，動的解析からこのような列を見つけられるなら動的な影響波及解析も可能だろう，と言っていた．

_ [論文] APIなどの発見 ▲

S. Sarkar, A. Kak, and N. Nagaraja: Metrics for Analyzing Module Interactions in Large Software Systems.

concept-driven modularization として，やたら外部から呼ばれてるメソッドなんかは API の候補だろう，といった当たりをつけるためのメトリクスの提案．

人間の分類とメトリクスの傾向とに類似性があった，ということで，自動的な分類に役立つかもしれない．

_ コメントスパム対策 ▲

CAPTCHAプラグインを導入してみました．それから，１年以上前の古い記事に対するツッコミもスパム認識するようにしてみました．古い記事についてのツッコミは，掲示板とかメールとか別方法を使ってやってください．