netail.net

_ ビザ審査を通過 ▲

カナダ大使館の人ががんばってくれたのか，ぎりぎり間に合うように（２週間ほどで）ビザ申請の審査が終わったから出国していいよという連絡が来た．で，９月にASE／AO-ASIA参加のために一度戻ってくる予定．そのためにポジションペーパーか何かは確実に書かないといけなくなったけど．

ウィークリーマンションに結局ネット環境はなかったので，OUCC部室のネットワークを借りつつ作業の予定．ウィークリーマンションは７日までで移動日は８日なので，空港に近いホテルを取ってのうのうと過ごすかな，というところ．

問題は，バンクーバーでの住居（大学の寮のようなもの）の申請の返事が来てないこと．とりあえず問い合わせ．

_ [ゲーム] スペランカーの岩の飛び越え ▲

１コンと２コンの両方でキャラクターが動かせることを利用して，片方で左を押して左に動き出してる間にもう一方のコントローラで右＋Ａを押すと右ジャンプできて，岩にあたっての跳ね返りは（左移動中のジャンプなので）右側になって岩を飛び越える（と理解している）技があるけど，知らない人もいるようなので書いておく．

_ ウィークリーマンションに移動 ▲

下宿引き払いに向けて，ウィークリーマンションに移動して，人に手伝ってもらって本棚など引き取ってもらった．

_ [hyCalendar] PCMode ６月号に掲載されてます ▲

「オンラインソフト鑑定団」という，ソフトウェアの価値を勝手に評価するという記事で取り上げられてます．

_ 梱包用エアキャップ ▲

とかもコーナンで扱ってたので見てみたら，10mで680円．安いんだけど，１人分の荷物だと，もうちょっと量は少ないほうがうれしいような……．

_ [論文] cflow 内部での context exposure の束縛の提案 ▲

SPLAT 2006 の論文のメモの残り．

Remi Douence: Relational Aspects for Context Passing Beyond Stack Inspection. Proceedings of SPLAT 2006.

cflow の中で，target や this などの値を保存しておけるようにしようという提案．「p.doSomething() を実行している間に呼ばれた q.getData() 」に対してアドバイスを動かして，p や q への参照を獲得できるようにする．

有用性については，たぶん便利だろうな，と感じるのだけど，オーバーヘッドが大変なことになりそう．cflowのマッチしかたにもよるだろうけど，「p → q → x」のような呼び出しで (p, x) のペアと (q, x) のペアの両方がポイントカットにマッチしたらどうするんだ，とか気になる．

_ [論文] アスペクト間の相互作用の自動合成 ▲

Anis Charfi, Michel Riveill, Mireille Blay-Fornarino, Anne-Marie Pinna-Dery: Transparent Dynamic Aspect Composition. Proceedings of SPLAT 2006.

アスペクトの定義である「Pointcut → Advice」が複数与えられたとき，

それらが一緒に動くときの動作順序を自動合成するという手法の提案

（説明を聞くまで自動合成だと気づかなかった）．

１つのポイントカットに複数のアドバイスが同時に動くとき，

「pointcut → advice 」ルールをすべて満たすような動作順序を出力するらしい．

考えていた出力と違ってたら declare precedence とか変更すればいいのか，と

質問してみたが，

ポイントカット定義が正しければちゃんと適切な出力が出るはずだ，というような

微妙な答えが返ってきただけだった．あまり考えてなかったのかもしれない．

_ [論文] MATLAB で AOP ▲

Joao M.P. Cardoso, Joao M. Fernandes, Miguel P. Monteiro: Adding Aspect-Oriented Features to MATLAB. Proceedings of SPLAT 2006.

SPLAT の中ではちょっと変り種．MATLABで，数値計算をするときの変数の型をデフォルトの数値型ではなく，別途記述するアスペクトによって固定小数点とかに変更できるようにしたという話（それ以外も計算途中のモニタリングとかも分離しているが）．

この「型を外部から変える」という発想が珍しくて，それでプログラムを壊してしまうのではないか，というような否定的な意見もあったけれど，この手法の場合は数値型のインタフェース（使える演算の種類）は変わらず内部的な表現が変わっているだけだからいいのではないか，という意見もあった．

_ [hyCalendar] 参照ファイルのバグというか仕様の穴 ▲

個別にテスト可能なモジュールを切り出すためのリファクタリング作業を続けているのですが，参照ファイル（他のファイルの内容を一緒に表示する）機能で，同じファイルを何個でも参照リストに追加できてしまうことが判明しました．

ファイルオブジェクトを検索するためのIDがファイル名で決まらないのはうれしくないので，参照リストには１つのファイルは１回だけしか登場できないように変更します．

_ 引越しに向けた本の処分 ▲

書籍のうち，要らないものを人に渡して回っただけともいう．

TRPG系ではMERPとLotR，バトルテック，それからRPG研で作ったものなど，小説はアン・マキャフリィ，ひかわ玲子，J.R.R.トールキンの作品の一部を残して放棄．

プログラミング関連では，意識的に残したのは，まつもとゆきひろさんのRuby本や結城浩さんの「プログラマの数学」．どちらも，オブジェクト指向とか数学とか，基本的な考え方を再確認するのに役立つ（と私が思っている）本．その他には，たびたびお世話になっているBertland Meyer の「オブジェクト指向入門」，Andrew Hunt と David Thomas の「達人プログラマー」あたり．

_ [論文] アスペクトの処理をベースコードと一緒に読むエディタの提案 ▲

やはり時間は経過したけれど，SPLAT 2006 の論文からいくつか面白かったものを整理．

Michael Desmond, Margaret-Anne Storey, Chris Exton: Fluid Source Code Views for Just In-Time Comprehension. Proceedings of SPLAT 2006.

あるソースコードを読んでいるとき，そこから呼び出しているメソッドの中身や，実行されるアドバイスの中身が気になることがあるので，最近の開発環境で使える「メソッドの折りたたみによる非表示化」の逆で，メソッドの中身やアドバイスの中身をその場（メソッドならその呼び出し文の直後とか，アドバイスが動く場所）に展開してソースをまとめて読めるようにしよう，というもの．多態性については，複数の候補のどれを見たいか選んだりする．

複数のエディタ，あるいは１ファイル内の複数の場所をあちこち移動しているうちに本筋の処理を見失ってしまうことがあるので，その手間を省こう，というのがコンセプトのようで，アイディアとしては面白い．

この手法の弱点（かもしれないもの）として指摘されていたのは，「あまり調子に乗ってコードを展開しすぎたり，展開先のコードが100行以上あったりしたら，本来の処理が何だったか分からなくなりそう」というもの．展開した状態を保存・再現したり，エイリアス解析を使って多態性の解決を自動化したりとか，実装上はかなり工夫の余地がありそう．発表してた人とも少し話してみたら，いくらかアイディアは持ってるみたい．個人的には，プログラムスライシングとかの適用結果の出力方法として使えそうなので，有望そうな情報表示方法の１つとして参考文献入りにしておく．

それから，別の人が「アスペクトはコードの挿入ではないので，そういう表示方法だと，誤解を招くことがあるのではないか」といった指摘をしていた．分かるような分からないような．

_ [論文] 小さな単位でポイントカットを定義したほうが再利用性がよくなる（かもしれない） ▲

Bert Lagaisse, Wouter Joosen: Decomposition into Elementary Pointcuts: A Design Principle for Improved Aspect Reusability. Proceedings of SPLAT 2006.

アスペクト内でポイントカットをいくつも定義するとき，ＡかつＢ，Ａ’かつＢ，Ａ”かつＢ，といったようによく似たポイントカットがたくさん登場するので，アスペクトを継承して子アスペクトでポイントカットを使いまわすときにはＡとＢは個別に名前付きポイントカットとして定義しておいたほうが実は再利用しやすく便利になる，という話．

「１つのイベントに１つの名前」というのは，「１つのメソッドは１つの仕事」という概念に近いのではないか，というような賛同意見が出ていた．個人的にも，構文ベースで選択されるジョインポイントに，早めに名前をつけて意味を与えたほうが変更の波及を防げる気がするし， 分割するよりは統合するほうが簡単なので（ＡかつＢというポイントカットに新しく名前をつければ良い），もしかしたら将来的には当たり前のデザインになっているかもしれない，と思ったりする．

_ [日記CGI] カテゴリ表示順序を変更 ▲

お知らせが新しいものを上に表示したかったので，category.rb の category_list_sections メソッドの HTML 生成部（118行目）にあるループ処理を逆順でまわすように修正した．

変更前: @categorized[c].keys.sort.each do |ymd|
変更後: @categorized[c].keys.sort.reverse_each do |ymd|

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

テスト環境が手元になかったのでリリースが遅れてしまいましたが，ホイールのクリックでのミュート切り替えができるようになりました．

_ LRU と Belady's Anomaly ▲

廃棄物処分屋さんによる見積もりがあるので，今日は自宅待機中．

以前レター論文で発表した，「実行履歴を機械的に分割する」ネタでキャッシュの中身入れ替えアルゴリズムを使っていたときに，Belady's anomaly（Belady's anomaly についての解説 ）が起きてたらどうしよう，という話になったと思うのだけど，実装時に LRU 選んだから問題は発生しないということに今さら気づいた．キャッシュのミスが連続するピーク位置は移動するかもしれないけど，ミスの回数は増えない．当時ちゃんと考えたのかもしれないけど，よく覚えてないので，いちおうこの辺にメモしておく．

Belady's anomaly っていつ発表されたんだろう，と思って調べてみたら，Citeseer でそれらしき引用文を発見．L. Belady, R. Nelson, and G. Shedler. An anomaly in the space-time characteristics of certain programs running in paging machines. Communications of the ACM, 12(6):349--353, June 1969. だそうで，さすがに PDF も何もありません．

ページングのほうでは，Page Fault Frequency (PFF) 置き換えアルゴリズムなんていうものもあって，ページフォルト率が閾値 p より上がってくるとページ枠を増やし，q より低下するとページ枠を減らすというものらしい．授業でちゃんと教わった気がするんだけど記憶にあまり残ってなかったので，やっぱりメモしておく．

_ ポスドクの invitation letter PDF とカナダのビザ申請 ▲

質問を投げている間にオリジナルのほうが届いたので意味はなかったけど，メモ: 担当者のサインもちゃんと入った invitation letter の PDF ファイル版をメールで受け取ってたので（郵送が未到着の状態で），それを印刷したものでも査証の申請ができるのか聞いたところ，「PDFのプリントアウトで一度申請し，審査官のほうで原本を見る必要があると判断した場合には連絡するので，そのときに提出できればOK」という旨の返事があった．

_ [ツール] テストからの擬似クラス生成 ▲

Java World のニュース欄でちょっとだけ話が載ってたので，JaSST のほうの原稿などを読んでみた．

伊尾木 将之，河野 広伸，合田 英二: TDDを加速する擬似クラス生成方法 - Simulated-Class by Tests with KikainekoMocker -．ソフトウェアテストシンポジウム 2006.

"Simulated-Class by Tests" という，テストケースを入力としてテストを通過する最小限の実装を生成する手法の提案．

予稿集では，手法ではなく使うことでどううれしくなるか（試行錯誤の容易化，コミュニケーションの容易化，設計の確認）がメインで，手法についての形式的な記述は特になし．

手法の実装であるKikainekoMocker公開サイトにある設計概要によると， テスト用コードをインタプリタとして実行し，メソッド呼び出し列を "TargetClass" に送信し， assert 文が来たところで「このメソッド列に対して出力はこうなるはずだ」という判断を下す，らしい． 抽象実行とかの一種と考えるとしても， Java コンパイラや実行系がやっていることと似たようなことをやろうとしているので， たぶんすごく実装には手間がかかっていると思われる．

このアプローチで大変そうな点は，まず１つ目として， モック生成対象クラスが存在していない段階で JUnit テストケースを書く都合上， そのテストケースは未知のクラスを参照したコードとなり， Eclipse 上などではエラーが発生してその他の意味エラーを検出できないかもしれないこと， ２点目は，戻り値が何らかの型に代入されていたり instanceof とかで判定されていたりしない限り メソッド戻り値の型が推論できないこと．

テストコードを分析して必要なインタフェースを勝手に書いてくれる，と思えば プロトタイピングの支援としては便利そうだし， 対象オブジェクトの満たすべき状態遷移（っぽいもの）もついでに 出してくれると色々使い道はありそうな気がする．

発想はとても面白いのだけれど，あらゆる種類の JUnit テストケースに隙なく対応しようとすると，実装がすごく大きくなりそうというのが怖いところ． 最終的に落としどころがどうなるかは今後見てみないと分からない． 解析系なことをやってる人間としては，「不完全な（クラスが足りない）情報を解析」というのがどう実現されるかは興味深いところ．

公開されている KikainekoMocker プラグインを， 手元の Eclipse 3.1.1 + JRE 1.5.0.06 にインストールしてみたけど， NullPointerException とか色々エラーを言われて動かなかったので， また折を見て試してみることにする．

_ [論文] SPLAT 2006 パネルディスカッションのメモ ▲

今さらながら少しだけメモを整理．

パネルディスカッションのお題はスケーラビリティだった．

効率面では，当然オーバーヘッドが少ないほうがいいに決まっているので，あまり変な話は出なかった．大規模システムでも低レベル（一番実装よりというか，テクニカル）な横断的関心事がたくさんあって大変だった，とかいった苦労話のようなことは少し出ていた．

アスペクトの利用法については，たとえばあるクラス群Ｃ，Ｄ，Ｅに貼りついているアスペクトＡがあってパッケージを構成しているとき，新登場したクラスＦにはアスペクトＡは実は貼りつくべきではないのではないか，また，外部に新しいアスペクトＢが出てきたときにそれはＣ，Ｄ，Ｅに影響を与えるべきではないのではないか，という話が出ていた．アスペクトの影響範囲（スコープ）をサブシステム内部とかある程度限定しないと，予期しないところでアスペクトが影響を与えてしまうかもしれないので，アスペクトの影響をうまく管理できるようにしたいね，という話にはわりとみんな同意していた．Erik Ernst は "safe applicability" というような言葉を使っていた．