netail.net

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

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

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

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

_ [hyCalendar] DUnit導入 ▲

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

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

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

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

_ [近況] 投稿完了 ▲

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

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

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

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

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

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

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

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

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

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

_ [hyCalendar] 1.3.7 プレビュー ▲

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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