netail.net

_ [hyCalendar] RFC2445を読んでみた結果 ▲

時刻とタイムゾーンのサポートや，カテゴリへの対応など，色々考えています．

最終的には Google のアレと相互運用できるようにしたいんですが，そこに至るまでにはデータ構造の拡張と，それに伴うUIの大幅な変更が必要で，下手するとほとんど別アプリケーションになりそうです．

_ [論文] アスペクトの情報だけを使って干渉の検出 ▲

Guenter Kniesel, Uwe Bardey: An Analysis of the Correctness and Completeness of Aspect Weaving.

Proceedings of WCRE 2006, pp.324-333. [IEEE site]

アスペクトが使うポイントカットに相当し，動作条件を指定する "predicate" と，実行されるアドバイスによって起こるプログラムの変化 "effect" をそれぞれ論理式で記述としたとき，「あるアスペクト effect の述語が，別のアスペクトの predicate に登場したら，アスペクト間に依存関係がある」とする手法の提案論文です．

アスペクトさえ揃えばどんなベースコードに結合するかに関係なく依存関係を検査でき，依存関係で作ったグラフをトポロジカルソートすればアスペクトのウィービング順序を決定したりできるので，かなり性格の良さそうな手法です．

実際にソースコードから述語を取り出すまではけっこう大変そうな気がしますが，アスペクトの干渉を論理式の関係に落とし込んでる点は読んでいて感心しました．AOASIA 2006 のときに「モジュラーな解析方法を用意するのが大事だ」とか当人が言ってた（気がする）のは，この辺のことだったのかなと思います．

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

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

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

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

_ [AspectJ] 誰が処理を行うかを隠蔽するアスペクト ▲

最近，Java で大規模なデータ構造を操作していて，呼び出したいメソッドを持ったオブジェクトへの参照をデータ構造のメンバー全員に行き渡らせるにはどうしたらいいか，などと悩んでいるうちの思いつきです．

メソッド呼び出しには，いつ処理を実行するか（その文をどこに置くか），誰が処理を実行するか（対象となるオブジェクト），どう処理を実行するか（その処理内容）という情報があります．このうち，「どう処理を行うか」については，インタフェースを使って隠蔽することができますが，「いつ，誰が」処理を実行するかというのはそのまま明記されています．

しかし，AspectJ のポイントカット＋アドバイスを使うと，元のコードからメソッド呼び出しを取り除くことができます．こうすると，「いつ，誰が」という情報が丸ごと隠蔽されます．AspectJ のポイントカットだと，主に「いつ」実行するかという情報を一箇所にまとめるのが主な役割としているんですが，一方の「誰が」という情報を隠す（呼び出し先への参照の管理をオブジェクトから取り除く）ことも大きな役割ではないのかなーという感覚がしています．

「誰が」だけを隠蔽するアプローチとしては，ASE 2006 のポスター発表で教えてもらった Zhi＃の人々の方法があります．この人たちは，あるオブジェクトから employee という関連を逆方向にたどって見つかるオブジェクト（company.employee == this が成り立つ company オブジェクト）を「this.^employee」というような形で参照できるようにしていました（データモデルの情報や，関連の名前についての ontology が与えられているという仮定はありますが）．

AspectJ でこれと似たような記述を少ない手間でやろうとするなら，空のオブジェクト参照フィールドを用意しておいて，before(): get アドバイスを使ってそのフィールドを実行コンテキストの値に応じた適切なオブジェクトで埋める，とかいう形になりそうです．これは，Dependency Injection でやってるようなことを，実行時の情報を使って動的にやろうとしている，という気もします．

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

ダウンロードは Volume Deskbar 公開ページからどうぞ．

今回の新機能はホットキー対応のみです．例によってデフォルトでは無効なので，設定ダイアログに新たに加わった「ホットキー」タブから有効にしてやってください．ホットキーなんか別に要らないという人は，即座にアップデートする必要はありません．

ホットキー自体を何にするかは趣味の問題ですが，標準はCTRL+ALT+カーソル上下となっています．テキストエディタなんかで CTRL+ALT のキーバインドを頻繁に使う人は，誤操作を避けるために設定を変えたほうがいいでしょう．

ノートPCユーザの人は，Intel のノートPCディスプレイ管理ツール(Intel(R) Graphics Media Accelerator Driver for Mobile) にご注意ください．このツールには，CTRL+ALT+カーソル上下左右で画面の表示向きを変えるというホットキー機能があり，それが有効になっていると，押した瞬間に画面表示が切り替わって驚くことになります．

このホットキー機能には「Volume Deskbar 自身がタスクバーから分離した状態だと働かない」という制限があります．これは仕様ということにさせてください．複数のウィンドウは同じホットキーを登録できないという制約と，デスクバーの「新しいインスタンスを作りつつ古いほうを破壊する」という処理との兼ね合いで，分離・合体時の切り替えにうまく対応できていません．

_ [work] 論文の作成工数の見積もり ▲

卒論シーズンなのでというわけでもないんですが，論文の書き方について多少調べています．

論文の品質を向上するための一般的な方法として，書いた後に別の作業や睡眠を挿んで論文を読み直す，というのが言われてますが，それに関連して，卒論のスケジューリングについて書かれた文書を見つけました．論文の作成，添削に関する見積もりの式が示されています．

私の場合，論文を書く→ご飯を食べる→論文を読み直す，といった，もうちょっと早いサイクルで進めることが多いので，係数は違いそうですが，論文のセクション数で見積もるというのは面白いと思います．

卒論・修論を書く人にとっては，添削期間の式のほうが，余裕をもって原稿を添削する人に渡すべし，ということで大事かもしれません．

_ [work] 論文での用語定義 ▲

論文の書き方については，千葉先生の解説がわりと読む量が少なくて良いと思います．あとはこちらの解説文なんかも参考になると思います．

上記の解説では「論理の鎖を省略しないこと」という，ちょっと格好いい表現が使われていますが，論理の鎖で大事なものの１つが，論文中で使う用語の定義だと思います．

未定義な用語を発見するための個人的なチェック法は，論文の先頭から出てくる名詞に対して片っ端から「それって何？」とツッコミを入れていくというものです．その場所から論文を前のほうへ遡っていき，定義（あるいは informal な解説）が発見できればOKです．

この作業は，それなりに時間がかかりますが，アブストラクトや前書きあたりに適用すると，提案手法に読み進むまで何の説明もない用語をたまに発見できたりします．

ただ，未定義の用語を発見するより，その用語の定義・解説を省略しても大丈夫かどうかという判断のほうが難しい気がします．ソフトウェア関連の用語は増え続けているので，特に説明せずに使える用語はどのあたりまでか，という基準はいまいちうまく説明できません．論文での重要度とか，雑誌記事などで目にする頻度が影響していそうですが．良い判断基準があれば教えてください :)

_ [論文] プログラムの自己進化のためのアーキテクチャ ▲

個人的には，プログラムが自己進化する必要は今のところないと思いますが，いちおう夢がある(?)話なので取り上げてみます．

Ming-Yang Hou, Xi-Yang Liu, He-Hui Liu: Fifi: An Architecture to Realize Self-evolving of Java Program. [ACM site]

Proceedings of SEAMS 2006, p.93, Shanghai, China, May 2006.

１ページの Research Summary で，自己進化型プログラムのためのフレームワークを作ってます，というものです．

このフレームワークでは，JVMTI を使って相互通信する２つの JVM を同時実行し，１つをプログラム実行用，１つを監視システムとします．そして，監視システム側は，プログラム実行時のイベント列に応じてプログラム改変が必要かどうかを判定し，改変の指令をプログラム実行用JVMに送ります（改変されるのは実行プログラムのみで，監視用のコード部分は書き換えません）．

仕組みとしては，今の Java バイトコード書き換えツールを駆使すればそれなりに実現できそうですし，コードの最適化とか難読化にも使えそうです．実行中のプログラムにパッチを当てるという話に似ていますが，この研究の場合，監視プログラムが，機能改変用のパッチを自動生成するという違いがあります．

自己進化の「コードを書き換えるルールを書く」という観点だけを見ると，静的な操作，たとえばリファクタリング操作をスクリプト言語で書くとか，sed でコードをまとめて変更するいったものであれば，あまり変な気はしません．

プログラムの実行を監視して，随時，動的に書き換える必要がある機能変更ってどんなもの，といって何も思いつかないのが，怪しいと感じる要因かもしれません．原稿では「捕まえられない例外が投げられたらtry-catchブロックの自動追加（エラーを無視して実行を再開する）」というものだけが例として載っています．

_ [hyCalendar] 起動速度の計測結果 ▲

要望がけっこうたまってきたので，次のバージョンに向けて，ぼちぼち作業を開始しました．こまめにリリースにするか，まとめてからリリースするかはちょっと悩んでます．

そういう作業をしつつ，現在の性能はどんなものかと気になって，ProDelphiを使って計測してみました．Pentium M 1.73GHz のノートPC上で，開発中の版に80KBぐらいのファイル（私が使ってるスケジュールデータ）を読ませてみたところ，起動に使う時間はだいたい250msぐらいのようです．時間の内訳は，ファイル読み込み，iniファイル読み込み，ウィンドウ生成でほぼ三等分で，ボトルネックになるような関数は特に見当たりませんでした．なので，これ以上はあまり性能向上はしないと思います（タスクトレイ常駐という手段は別として）．

なお，上記の数値はわりと最速の構成で，「起動時にIMEを有効にする」オプションや，六曜表示，開くタブの枚数の増加などが加わると，起動時間は増加します．