netail.net
自作フリーソフトや,ゲームに関する雑記を公開してます.
日記はソフトウェア工学の論文ネタが中心です.
最近のお知らせ (古いものはこちら)
2006-04-05 [長年日記] ▲
_ [Delphi] 今日のはまり ▲
Delphi Studio での条件コンパイルで "logging, test" のようにコンパイル条件を "," で区切って書いたら,無関係なエラーメッセージ(リソースファイルに変なマクロがある,云々)が出力された.空白で区切るのが正しいらしい.
そういえば,hyCalendar も Volume Deskbar も Delphi で書いてるので,Borland 側のサポート関連のニュースはけっこう気になってます.hyCalendar はそこそこの(実験対象として手頃な)規模になってきたので,データのモデルの再検討ついでに, Java (+ あわよくばAspectJ)に逃げたいなーと思うこの頃.問題は UI のウィンドウメッセージずぶずぶな(ウィンドウプロシージャとして実装している)部分をちゃんと移行できるかどうかです.とにかく実験してみないと…….
2006-04-03 [長年日記] ▲
_ [ツール] XTMemo ▲
TODOというほどでもないメモを管理するのにいいツールはないかなと思って,XTMemoというツールを試してみた.
ファイル作る→ファイルの中にメモを作るという形で,メールボックスとメールにも似たインタフェースで,けっこう面白い.保存は単なるテキストファイルなので,加工しやすいのも利点.
とりあえずwikiに書いてたメモをいくらか移行してみた.作ったメモの保存順序が更新日時ではなく作成時の日付順序である(しかもソート機能を持たない)というのが少し気にかかるが,検索したキーをそのままタブとして保存してくれたり,タイトルの横に本文の内容の先頭部分を少しだけ出してくれるのは親切で,満足度はそこそこ.
研究関連のメモを整理しておくには,何か足りないような気もするのだけど,何が足りないか,使ってたらそのうちわかってくるかもしれない.
インストール時,データ保存フォルダを指定するときに,何も考えずに普通にテキストファイルが入ってるフォルダを選んだら,勝手に手元のテキストファイル群を加工されてしまった.なぜ保存先のフォルダを先に選ばされるのかなと思ったら,基本的には指定フォルダ内にあるデータは全部既定の形式のテキストファイルだとみなして扱うということらしい.
2006-04-01 [長年日記] ▲
_ [hyCalendar][VolumeDeskbar] 変更要求リスト ▲
hyCalendarの変更要求リストとVolume Deskbarの変更要求リストをそれぞれまとめてみました.
ようやく新環境には適応しつつあるものの,ちょっと別仕事を抱えているので,今しばらく,対応まではお待ちください.
2006-03-29 [長年日記] ▲
_ [ツール] JUnitとFIT ▲
JUnitでは,データの値と結果のペアをひたすら assertEquals で並べるので疲れると思っていたら,そういうテストに適したFITというツールがあるらしい.
developerWorksの記事によると,どうやらHTMLテーブルを書いておくと,列名が変数名なら入力データとみなし,メソッド名ならそこに書いてある値がそのメソッドのあるべき出力値とみなして,自動的にテストしてくれるというものらしい.
あと,鷲崎先生も記事を書いていた.ぱっと見た限り,けっこう便利そうなので,次の開発から使ってみたいところ.
ダウンロードページを見てたら,現段階ではJavaやC++など色々なバージョンが既にリリースされている様子.Delphi 版はさすがに(開発しようとした人はいるようだけれど)なし.こういうのを見ると,hyCalendar とかもそろそろサポートが充実した別の言語に移行すべきかなとちょっと悩んでしまう.
2006-03-28 [長年日記] ▲
_ AOSD まとめメモ/ポスターセッション ▲
ポイントカットを提案していたものでは,path expression pointcut と,block pointcut というのがあった.
path expression は,フィールドに格納されている参照を使って,obj.field1.field2 のようにたどれる範囲のオブジェクトを宣言できるようにしようというもの.target(p) && path(obj -> p)
のように記述することで,オブジェクト p を保有する obj なんかを変数に束縛できる.これは,DemeterJ とかで使っているtraversalの記法でもあり,強力な仕組みになる可能性はある
ただ,実現のアイディアについて聞いてみたら,ガベージコレクタなんかがオブジェクトの参照を見つけるような方法,といっていたので,かなりの力技になりそうな点が不安.成果が出てみないと何ともいえない.
一方の block pointcut は,東工大の人々による提案.エラーから回復するために,エラーを検出する特定の try ブロックを2つのポイントカット pcd-begin
と pcd-end
を使って block(pcd-begin, pcd-end)
という形式で指定し,それに対して回復用のアドバイスをくっつけることを提案している.pcd-begin
とpcd-end
が同じブロック内にならないといけないという制約を付けていても,beginとendの対応が正しく取れているかどうか,コンパイル時にしっかり判定する必要があり,実装はけっこう難しそう.
そのかわり,ポイントカットの抽象度を向上させる可能性はありそう.たとえばファイル処理に関するブロックを pointcut FileProcess(): block(call(File.open), call(File.close))
のような記述で記述すると,今までのようにbefore(): open
と after(): close
と書くかわりに,before(): FileProcess
と after(): FileProcess
と書いたりできる.これは,実装の詳細のメソッド名などを見せずにポイントカットだけを公開するために使えたりするかも?とちょっと期待.