netail.net

_ Calendar ▲

ウィンドウズROM とかいう雑誌にhyCalendar 0.5.1 が収録されてるので見本が届いた．

中をちゃんと見たのは初めてだったんだけど，微妙な雑誌だ．

_ 結婚式 ▲

参列する予定の結婚式準備．というてもスーツ＆シャツ出したり，ご祝儀袋用意したりするだけだけど．

筆ペンで書くの難しい．墨でないだけマシだが．

_ ファミコン ▲

レーサーミニ四駆ジャパンカップ攻略用セッティングのページにこっそり（でもないが）アクセスカウンタとアクセス解析を設置．

……昨日から９人来てるみたい（自分で実験用に踏んだの除く）．そんなに需要あるのだろうか :-)

_ Calendar ▲

hyCalendar 0.6.4 アーカイブ版作って公開．ini ファイルを zip から取り除いて，それに伴って README, CHM ファイルも更新．間違って設定ファイルを上書きしてしまうーと文句言われたので，それに対応．

_ ファンタジー職業適性診断 ▲

さっきの紹介されてたサイトでたまたま載ってたので見つけた．http://trpg.gasuki.com/trpg/csi.php

私は「剣闘士」と出ました．攻撃力は最高……って言われても．

_ AspectJ ▲

たまたま読んでたら，このサイトのことも載ってた．ほめられてるので，わりとうれしい．＃批判されても，話題に上るぶん嬉しいんだけど．http://melodyflag.sytes.net/mt/

_ Cygterm ▲

Cygterm を Guevara からつついてみた． http://www.dd.iij4u.or.jp/~nsym/cygwin/cygterm/cygterm.cc を適当に置き換えてみた．怒られそうな変更してるけど．ポートはデフォルトの値１個だけを使うようにしてる． cygterm.cc cygterm.cfg Guevara 側の設定例．（cygterm.cfg で設定したポート番号をつつくようにする） cygterm.cfg

_ Calendar ▲

HTML Help が開けない問題への対処を実装して0.6.4 実行ファイルだけ作ってリリース．

0.6.4 リリース用アーカイブ作るのが面倒になってきた．というか，ドキュメント更新する手間が大きい．

HTML Help 内に更新履歴持つのをやめれば多少は楽になるだろうか．

_ Calendar ▲

hyCalendar で，ヘルプファイルを開こうとしたときになぜか 7zip file manager が立ち上がってしまうという微妙な問題が発生．やっぱり単純なファイルを開くシェル依存な処理ではなくまじめに実装しろということか．

この辺が参考になりそう．http://www.stbbs.net/~junichi/adelieworks/hhwd/knowledge/contexthelp/delphi/modifyatdelphi.htm

_ Article ▲

predictability について調べていたらヒットした原稿．要は「予測できること」なのだが．どんなものを作るのか，どんな構成になるのか，とかいうのでインタフェースによるモジュールの分割などが重要で，何もない状態では大変なことになるというお話．

http://www.onlamp.com/pub/a/python/2001/04/04/se4e.html

_ 論文 ▲

Katharina Mehner:JaVis: A UML-Based Visualization and Debugging Environment for Concurrent Java Programs.Software Visualization, LNCS 2269, pp.163-175, 2002.

実行トレースから UML のシーケンス図を生成して，その上にデッドロック情報を乗せる．デッドロック検出アルゴリズムは既存だし，シーケンス図を作ること自体は今のところ力技のようなので，新規というわけではないが，あると便利そう，というところ．

シーケンス図を作る，というところで，Visualizing the Execution of Java Programs の筆者らが「スケーラビリティがないので実際には使いにくい」という主張をするのは仕方がないところかも．

_ 論文 ▲

Wim De Pauw, Erik Jensen, Nick Mitchell, Gary Sevitsky,John Vlissides, and Jeaha Yang:Visualizing the Execution of Java Programs.Software Visualization, LNCS 2269, pp.151-162, 2002.

Java のプログラム実行時情報を可視化するJinsight というツールを紹介した論文．

オブジェクトのインスタンス数・呼び出し数・消費メモリ量・実行時間を見る Histogram View，呼び出し・参照関係をツリー状に表現して，枝にその参照が何回ずつ起こっているかを表す Reference Pattern View，オブジェクトを「世代」にグループ化することで行うメモリリーク分析（「捨てられるべき」オブジェクトグループへの参照を誰かがこっそり保持していないか調べる），プロファイラ結果を図示する Execution View，呼び出し回数の比率を示す Call Tree View がある．

Execution View は，全部のメソッド呼び出し関係を図示するようで，かなり見づらいが，150万行程度の実行履歴でもちゃんと表示できているあたりは，かなりがんばっている．

主にメモリおよび実行性能上の問題に対処することが目的らしいので，このあたりで十分なのだろう．なんとなくだが，Eclipse の Java プロファイラツールで使われているビューに似ている気がする．IBM の人たちだし．

関連研究としては，・情報をいかに減らすか（適当な単位で分割するなど）・いかに探すか（クエリーベースの探索ツールなど）があげられる．UML で並列性の問題を可視化するツールなどもあるようだがスケーラビリティの問題が大きい，とも述べている．また，一般的な情報表示よりは，特定のタスクに絞って便利な情報を提供するツールのほうが良い，とも述べている．

_ 紅茶 ▲

レピシエでもらったバニラティー１杯ぶんを淹れて飲む．濃いめに淹れてミルクティーにする，という方針で間違いなし．最近，ミルクを多めに入れるタイプのミルクティーがメインになってきた感がある．

単に濃く出すのに慣れてきただけ？適当に出しても十分飲めるし．

_ 論文 ▲

Suhaimi Ibrahim, Norbik Bashah Idris, Aziz Deraman:Case study: Reconnaissance techniques to support feature location using RECON2.Proceedings of APSEC 2003.

プログラムのあるフィーチャーを含むような，プログラム実行テストケースを "Y" テストケース，含まないようなテストケースを "N" テストケースとして，それらの実行経過の差分を取り出すことでフィーチャーがどこに実装されているかを調べようというものらしい．

ユーザは，テストケースを作り，それを Y/N に分類しておく必要がある．

ケーススタディの結果，そんなにテストケースの個数はいらないが注意深く選んである必要はあるらしい．この手法は，どんな機能があるか，ある程度知っている状態でならプログラムのどこに，その機能が実装しているかを示すのはやりやすい．

弱点は，テストケースが実行できなければならないので，テストケースとして表現しにくい機能ほど見つけにくい．

ちなみに，「部分的な理解だけでもそれなりに保守はできる」ということは既に以下の論文でいわれているらしい．Lakotia, A., "Understanding someone else's code: Analysis of experience", Journal of System and Software,1993, Vol.23, pp.269-275.

_ 論文 ▲

Hiralal Agrawal, Richard A. DeMillo and Eugene H. Spafford:Debugging with Dynamic Slicing and Backtracking.Software Practice and Experience, Vol. 23(6), pp.589-616, June 1993. 動的スライスを使えるような環境を GDB ベースで作って，それに加えてバックトラック（「一ステップ前に戻る」）を実装したような環境を作ってみた，という論文． ある地点でブレークして，値がおかしいから動的スライスで前のほうへ戻って原因を調べていく，というもの．いちおうデータのみ，制御のみ，それぞれに注目したスライスも取れるようにしたりとか工夫されていて，成功したテストケースと失敗したテストケースでのスライスの違いなどが役立つだろう，と言っている． プログラムスライスや実行バックトラッキングの限界として，次のようなものを挙げている．

• 複数回同じ行が実行されたことを，スライスは明示してくれない．　（せっかく動的スライスでも，見た目はソースコードだから）
• スライスは「何が影響しているか」は教えてくれるが，そこから「どの制御あるいはデータが間違ったか」という原因に立ち戻るにはやはりかなりの苦労が必要である．
• 実行のバックトラックは，システムに対する副作用があるとそこで戻れなくなってしまうので「部分的」バックトラッキングで我慢するか，再実行する仕組みのほうが良いかもしれない．

プログラムスライスも見せ方と使い方が重要，というところではこの論文を引用することになりそう．

_ 論文 ▲

Andreas Zeller: Yesterday, my program worked.Today, it does not. Why?, Proceedings of 7th ESEC/FSE 1999

ベースライン（既存プログラム）に対する変更の集合 C を考える．test(x) は テスト結果 PASS, Failure, Unresolved を返す．

ある日，プログラムが動かなくなる: (test(φ) = PASS) ∧ test(C) = FAIL )

変更集合 C を適当に組み替えて（バージョン管理ツールなどを使って），どの変更でプログラムが動かなくなったかを調べる．

このとき，変更は [単調] である．∀c ⊆ C (test (c) = FAIL --> ∀ c' ⊇ c ( test(C') != PASS ) )

この変形で，うまくいっている変更の部分集合だけを取り出しても，テストは失敗しない．∀c ⊆ C (test (c) = PASS --> ∀ c' ⊆ c ( test(C') != FAIL ) )（一時的に実行不能になっている場合もあるかもしれないが）

で，失敗してる構成同士を組み合わせても意味がなくて，∀c1, c2 ⊆ C ( test(c1) = FAIL ∧ test(c2) = FAIL --> test(c1∩c2) != PASS )

どんなテスト組み合わせでも未解決のテストが出ない状態を，[一貫した] 状態であるという．∀c ⊆ C ( test(c) != Unresolved )

…ということを利用すると，変更単位が自動で扱えるなら，自動で，どの変更がバグの原因かを示せる．

変更 8個あれば 4個ずつでテストを実行し，失敗したものについてはさらに２分してどちらが失敗しているか（あるいは両方失敗しているか），さらに失敗したものについて２分して……としていくことで，失敗するテストを判定する．成功したもの同士は今度はくっつけてテストを実行して，組み合わせることによって成功するものはどれか，というのを調べる．たとえば，1-4, 5-8 がそれぞれ成功したとして，3-8 がテスト失敗したなら 3 + 5-8 と 4+ 5-8 でテストして，……というように組み合わせを自動で探索する．

テストを効率よくグループ化するために，プログラムの変更に対してプログラムスライスをとって共有ノードがあるかどうか，といったことでその変更が相互に影響するかどうかを調べたらいいなぁ，なんてことを将来の課題として説明している．

_ バトルテック ▲

Technical Readout 3025 を注文した．