netail.net

_ [近況] セーターをまだ着たり着なかったり ▲

この学部では，必要なソフト一式（マイクロソフトのOfficeや開発環境，SQLサーバとかAdobe AcrobatとかSSHクライアントとか）が用意されたサーバにリモートデスクトップで接続して使うということができるようで，けっこう面白い．使う側としてはインストールの手間がないし，管理側もメディア類を貸し出したりとかの管理をしなくていいので楽なのかもしれない．また，人の出入りが多いせいか，ドキュメント類とサポートデスクがちゃんと用意されている．

研究室の特定の部屋に入るための非接触型の鍵（fob）をなくして$20のデポジットを失ったので，少し反省して大学の本屋でちゃんとしたキーホルダー（key chain）を$10で購入してきた．UBCと大学名が入ってるだけで値段がけっこう上がるみたいで，コーヒー用マグカップなんかはUBCロゴ入りだと，$20したりする（スーパーで，同じタイプの「Vancouver」マークのものを$7で見つけた）．さすが記念品．

_ [VolumeDeskbar][お知らせ] VolumeDeskbar 1.0.9 リリース ▲

タスクバーを縦方向にしても，ツールバーは水平方向で表示したい人向けのオプションと，ただの左クリックだけでは音量を変更しないオプションが増えました．

現在の機能で既に満足されている場合，あまりアップデートする意味はないかもしれません．

さすがに水平方向表示は，ちょっと無理していて，横幅は可変ではありません．「ツールバーの最小幅」オプションで設定された値をそのまま水平方向の幅として採用しています．

VARIABLEHEIGHTを使えば良いと思われるかもしれませんが，描画時，透過色がうまく使えず，音量バーの外側の領域が灰色（通常のツールバーの背景色）で染まってしまうのでやめました．

操作体系まわりの改造は，まだかなり悩んでいますので，今回はとりあえずオプション１個だけの対応にとどめてあります．アイディアをお持ちの方は，ぜひお聞かせください．

_ [論文] "Feature-Oriented" リファクタリング ▲

Jia Liu, Don Batory and Christian Lengauer: Feature Oriented Refactoring of Legacy Applications.

Proceedings of ICSE 2006, pp.112-121, Shanghai, China, May 2006.

Feature-Oriented Refactoring (FOR) は，色々なfeatureを持ったソフトウェアを，featureごとにモジュール分割する作業のことを指す．この作業を補助する手法を提案している論文．

各featureは，それぞれ固有のメンバー定義（AspectJでいうインタータイプ宣言）である基本のモジュール(base)と，基本モジュールに対する変更操作（アドバイス）である派生モジュール(derivative)によって構成される．派生モジュールの中には，依存する他の派生モジュールを改変するもの（他の特定のfeatureの存在を仮定した処理）が含まれる．この定式化が論文の前半を占めている．

プログラムをfeatureごとに分割する作業では，最初に，開発者が「featureがどう合成されているか」をモデルとして（マニュアルやソースから割り出して）定義する．たとえばロギング機能とバックアップ機能が付いたバッファクラスなら [LOGGING] [BACKUP] BUFFER といった具合．ケーススタディでは GenVoca という文法をこのモデル記述のために使っていて，もしあるfeatureが他のfeatureに依存しているなら「LOGGING implies BACKUP」のように制約を記述できるようにしている．

モデルができたら，元のプログラムの各メンバーがどのfeatureに属するかをラベル付けし，base 部分と derivative 部分を先に切り離してから（先の例なら BUFFER だけを先に取り出してから），派生モジュールのほうをさらに細かく分割していく．

featureごとのモジュールさえできたら（形式的にはAspectJのアスペクトやAHEADのrefineクラスで），あとは組み合わせたいfeatureの組み合わせ（モデルの文法で生成可能な文）を選ぶだけで，プログラムを自動的に再合成することができる．

feature間の相互作用がすべて派生モジュールとして登場するので，featureの数 n に対して，組み合わせ数である2のn乗の派生モジュールが生じてしまうが，実際には相互作用というのはほとんどないので，実際には 3*n 個くらいのモジュール数に収まるようだ，とケーススタディに基づいて述べられている．

この論文の偉いところは，feature間の相互作用を必ず考えろと定式化段階で言ってるところかもしれない．また，featureのモデルを作るのが，必須の機能と付加的な機能を列挙して，その間の依存関係を定義するだけなので，開発者にとっての負荷もそれほど高くなさそうなところもいいかもしれない（コードをそのモデルに基づいて分割するのはけっこうなコストだとは思うけど）．

_ [論文] Dominance Tree アルゴリズム系を探すのこと ▲

こちらで紹介されているDominance Treeを探索する反復アルゴリズムに相当するものをちゃんと論文にまとめている人を探してみたら，Keith D. Cooper, Timothy J. Harvey, Ken Kennedy: A Simple, Fast Dominance Algorithm. というのがどうやら同じようなものらしい．性能評価も付いている．

しかしこの論文，掲載先は SPE だと書いてあったにも関わらず，SPEの目次には載ってなかった．よく見たらVol.がなくてNo.だけあったり，pp.1-10って書いてあるのにPDFが28ページある．

あまりに怪しいので，関連を調べてみたたら，Finding Dominators in Practiceという論文が，K. D. Cooper, T. J. Harvey, and K. Kennedy. A simple, fast dominance algorithm. Available online at http://www.cs.rice.edu/~keith/EMBED/dom.pdf.と引用していた．こちらの論文は，２フェイズに分けたDominanceツリー処理なんかの性能評価もしているので，こちらを引用したほうが無難かもしれない．

L. Georgiadis, R. F. Werneck, R. E. Tarjan, S. Triantafyllis and D. I. August: Finding Dominators in Practice. In Proceedings of the 12th Annual European Symposium on Algorithms (ESA 2004), Lecture Notes in Computer Science, volume 3221, pages 677-688, Springer-Verlag, 2004.

_ [VolumeDeskbar][お知らせ] Volume Deskbar 1.0.10 リリース ▲

「ポップアップで音量を表示する」オプションが増えました．マウスカーソルでポイントされている間はずっとヒントで音量が表示されます．

また，ボリュームコントロールからの操作などで音量が変化した場合には，カーソルが乗ってなくても約３秒間だけポップアップ表示されるようにしてみました．いちおう，一般的なヒントの長さだとは思います．

また，ミュート時は，ヒント文字列の後ろに「(Mute)」を付けるようにしてみました．

ご意見，ご感想，お待ちしております．

(追記) リリース状態にしてから気づきましたが，画面右端に縦方向表示でツールバーを使っている場合，「Mute」で伸びたぶん，微妙にヒント文字列が音量バーに重なってしまうようです．ごめんなさい．次に改良ネタがたまったときに，一緒に直したいと思います．

_ [Java] dW のコード品質測定の記事 ▲

コード品質を追求する: ソフトウェア設計者にとってのコード品質というのが出ていた．

遠心性結合(Ce)と求心性結合(Ca)って，最初何のことか分からなかったが，そのパッケージが持つ依存関係の fan-out と fan-in の数らしい．fan-out が多いほど不安定になるから， Ce / (Ca + Ce) で不安定性を計測する．

一方で，パッケージ内の抽象クラスの割合が「抽象度」となる．パッケージの抽象度と不安定性のバランスは，抽象度＋不安定性 = 1 の直線からの距離で判断できるらしい．

本当にバランスが良いか悪いかは分からないが，一般的に，抽象クラスほど安定しているはずだし，直観にはわりと合致する基準な気がする．パッケージ単位の結合度は，計算しようと思えば import 文を grep するだけでもかなり近似値が出せると思うので，使いやすいメトリクスだといえそう．

誰からも使われないパッケージは不安定性１となるのが，ふと「別に依存パッケージが少ないんだから気にせずどんどん変更できる」という意味かなとも思ってしまった．本文の解説によると，依存するばかりだと変更の波及を受けやすいから不安定という普通の定義らしい．

_ [近況] 授業課題に付き合うのこと ▲

建築コスト管理の勉強をしてる人の課題で，コスト管理ソフトウェアのユースケースから分析データモデル（クラス図）を作って設計プロセスモデル（シーケンス図とか）を作る，というのが出たらしい．その相談に付き合ってみた．四方山話を含めて夜９時に開始して２時間くらい．

FORTLAN をちょっと知ってるぐらい（コードを書いたことはない）という人なので，クラス図の概念は分かるけど，そこから詳細設計に落とすところで止まってしまっていた．

ソフトウェアの振る舞いを決めていく作業というのは，何をどういう順番で行っているのか，うまく説明できなかったので，これはちょっと，勉強し直さないといけないかもしれない．

ちなみに，スケジュールをちらっと見せてもらったら，１ヶ月で，帳票ベースの要求仕様を分析してユースケース書いて設計して実装までやるみたい．コンピュータサイエンスを専攻してる人間でも，これはけっこう大変では？

_ [hyCalendar] 1.3.7 プレビュー ▲

久しぶりの更新となりますが，次期バージョン（1.3.7）バイナリのプレビュー版を用意してみました．

外見上は何も変わっていませんが，期間予定・周期予定まわりの構造が大きく変わっており，順次テストしている状態です．まだ予期せぬバグが含まれている可能性がありますので，試される場合，データファイルのバックアップを必ず取っておいてください．

新機能として，今まで微妙な動作をしていた上下スクロール機能に対して，「自動に上下に拡張していく」オプションを追加しました（設定ダイアログの「キー操作」タブ）．具体的には，月の先頭（一番上の行）で上を押したり，終端で下を押したとき，タブを切り替えず，そのまま追加の１行が表示されます．タブを押した瞬間に，その伸びた分は破棄されます．このあたりの振る舞いについてご意見がありましたら，お聞かせください．

そのほか，いくつかの問題を修正しています．これらについては，正式リリース時にリストを作ります．

「一定日数ごとの予定」は，かなり変更作業が長引きそうだったので，ちょっと先送りを決定しました．

_ [近況] グラフを混同していたことに気づく ▲

電気系・コンピュータサイエンス系の人向けに，IEEE Xploreは当然のように利用できるようになっていました．年数も種類も，阪大に比べると範囲をかなり広めに取ってあるようで，かなり快適です．

そのおかげで(?)，今まで頭の中で Control Call Graph と Branch Reserving Call Graph を混同してたことに気づきました……．

前者は APSEC 2005 の論文で「制御フローグラフ，ただし頂点はメソッド呼び出しと分岐のみ」．後者は APSEC 2003 の論文で導入されているもので，「コールグラフ，ただし分岐頂点は残っている」です．

締め切り前に気づいてよかった :)

_ [近況] 論文書きは続くのこと ▲

AO-ASIA用の paper には Gail Murphy は入りませんでした．方針の相談に付き合ったり，論文についてコメント，英文を修正した程度では "intellectually contributed" したことにはならないそうで．まあ，次の paper には共著者できっと入るんだけど……．

_ [近況] 投稿完了 ▲

AOASIA用の論文（ポジションですが），こちらで22日夕方，日本時間では既に23日午後なので，それなりによく間に合いました．深夜まで及ばずに済んだのは Gail Murphy の英語サポートのおかげです．ポスドクになって，普通の先生や学生より時間的に余裕がある（何しろ雑用の類が一切ない）というのも大きいかもしれません．

時間があるうちに，将来に備えて program committee とか（どんなことしてるのかあまり知りませんが）手伝っていったほうがいいのかな，と思ったり思わなかったり．

(追記)提出して数時間したところで，２週間締め切り延びたから修正したかったらどうぞーという連絡が Elisa Baniassad から届いてた．うーむ．

_ [hyCalendar][お知らせ] hyCalendar 1.3.7 リリース ▲

約２ヶ月ぶりのリリースとなりました．プレビュー版から比べても追加のバグ修正がいくつも入ってます．

新機能は１つしかないわりに，修正したコード量，修正されたバグの数を考えると，1.0.0リリース以来の大改造となっています．いつもよりは回帰テストを多めに実施していますが，テストし忘れとかで問題が起きてたら，ごめんなさい．安全のため，ちゃんとバックアップ取ってからバージョンアップしてください．

別に機能的に変わったわけではないのですが，周期予定はマッチした結果を内部でキャッシュするようになりました．動作効率の悪いような周期予定の条件式が多数使われていた場合は，以前より少し描画が高速になっているかもしれません．

_ [hyCalendar] DUnit導入 ▲

ユーザの皆さんにとってはまったくどうでもいい話なので，分けておきます．

今回，hyCalendar内部の基本部品（URLの切り出し操作とか）については， DUnit による単体テストを適用するようになりました．現在ソースコードにして18,000行くらいですが，それに対してDUnitテストコードが1800行程度，ファイル数では58個に対して14個のテスト用ユニットを作っています．

Borland Delphi Studio 2006 では，「新規」-「テストケース」を選ぶと，既存のモジュール用の DUnit 用ソースの雛型を生成してくれるので，かなり快適に作業を進めることができました．

単体テストを書くと，モジュールの微妙な例外項目を発見できるので効果的ではあるのですが，怪しいモジュールを作ってた事実にちょっとへこみます……．テスト駆動型のほうが「こう動いたらいいなあ」と理想優先(?)で進むので，精神衛生的にいいのかもしれません :)

_ RSS生成を少しだけいじる ▲

MakeRSSで，サブタイトルが文の先頭にも入ってるのが気持ち悪かったので少しだけ修正．

desc = apply_plugin ( .. subtitle_to_html, ..) + apply_plugin( ..body_to_html, .. )となっていたのを，subtitleのほうを取り除いただけですが．

_ リリースの情報をベクターへ送信 ▲

２月以来，すっかり連絡を送るのを忘れてました．あんまりバージョン差が広がってしまうのも問題なので，ちゃんと情報送りました．だいたい一週間ぐらいで反映されるはずです（といって，ここを見てる人にはあまり関係ないと思いますが……）．

_ [ツール] pukiwiki 1.4.7 へ移行 ▲

日本時間で26日付けでアナウンスされてたのを見て移行してみた．

差分版のほうをダウンロードして，元 wiki を cp -R で丸ごとコピーしておいた場所で，上書きするとまずそうなcacheディレクトリの中身とFrontPageに相当するファイルとpukiwiki.ini.phpとpukiwiki.skin.php以外を上書きコピー，pukiwiki.ini.php はパスワード設定など手写しして，最後にパーミッションの統一取れてないところを直して，動作確認．

あっさり動作してくれたので，古いほうとディレクトリごと差し替えて終わり．古いほうはそのままバックアップとして保存．

それにしても，「最近の更新」リストの中身を壊さないように移行する方法が分からない……．

_ [hyCalendar] バグ告知 ▲

ごめんなさい．周期予定の条件で「他の予定から X 日"前後"」が，キャッシュ処理に誤りがあってうまく動いてません．「後」のほうは，動く場合がありますが「前」のほうはまったく動いてないと思います．テストが完全に抜けていました．

また，祝日ではないけど日付の名前にしている予定が，ポップアップ文字列から消えています．

最新版バイナリを作りましたので置いておきます．

まだ他にも問題がありそうなので，もうちょっとテスト項目を洗いなおしてから，正式リリース用のアーカイブを作ります．

_ [hyCalendar][お知らせ] hyCalendar 1.3.8 リリース ▲

目立つバグ入りのバージョンが各所で配られっぱなしというのも良くないので，とりあえず昨日発見した問題２件＋新たに見つけた２件の計４件の修正でリリースしました．ご迷惑をおかけして申し訳ありません．

_ [AspectJ][読書] AspectJ Cookbook オンライン版を読む ▲

ACM から，書籍の中身をオンラインで全文読めるサービスの案内が届いてたので，使ってみた．それなりに本の種類が多く，オライリーの一部の本なんかも無料で読める．当然ながら英語版しかないけど，PDFじゃなくて普通にHTMLとして供給される上，「よく似た文章が他の本にもあるよ」と通知が出たりするので，けっこう面白いサービスだと思う．

で，AspectJ Cookbook を見つけたので読んでみた．ほとんどのレシピは当たり前というか，各ポイントカット定義の使い方の例示みたいなものばかりだったのだけど，１つだけ面白いのを見つけた．プロパティの値管理にアスペクトを使おうというもの．

staticinitialization(Main)なんかを捕まえて設定値のロードを行っておく．そして，プロパティの値を使うオブジェクトが生成されたとき（execution(public MyClass.new(..))）オブジェクトに設定値をセットしにいく．これによって，利用者側がConfigFile.getInstance().getSomeProperty()といった形で設定を読みにいく必要がなくなり，設定を格納したオブジェクトへの依存関係を削ることができる．

設定値の変更にも，set(int Main.someProperty)のように代入を監視することで対応できるので，設定ファイルの読み書き処理と利用者側の各クラスとを完全に切り離すことができる．

この方法を使うと，プロパティの値に依存して動くクラス群のテストなんかが楽になりそう．普通なら，設定ファイルに値を読みに行く処理をモックで差し替えるとか，様々な設定値のファイルを用意しておくとかになってしまうところが，単にテスト用コードが「アスペクトが読んでセットしてくれるはずのプロパティ」の値を代理でセットしにいくだけで良くなる．

「誰がこのフィールドに値をセットするんだ？」とか混乱は起こりそうだけど，そこはちゃんとドキュメントするなり，Java ならアトリビュート使って「これはアスペクトにセットしてもらいますよ」と明示するなりして使えば何とかなりそう．

この設定値の管理アスペクトは，「システムのあちこちで共有のパッシブなオブジェクトを使う」というのを，「システムの動作中の適切な時点でアスペクトが勝手に動く」という形で置き換えている，ロギングとよく似たパターンであるという気がする．fan-in analysis によるアスペクトマイニングで出てくる候補というのが，実はこの種の処理だったりするのかもしれない．

この設定値の管理方法，既に山ほど設定項目の入った設定ファイルクラスを持ってる身としては，すごく便利そうだなーと思ってしまう．Delphi用のアスペクト指向環境があったら喜んで使っていそう．