netail.net

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

今回，枠線の太さ指定が可能になりました．「枠線を表示しない」オプションは，枠線の太さが０とみなして設定を引き継ぎます．また，ツールバー自身の太さの設定，グラデーション表示の設定もできますので，見た目を今までよりは少し柔軟に設定できます．

これに伴って，設定ダイアログの１枚目，今まで「表示」タブだったところが，「色とサイズ」タブとなりました．今回追加されたオプションは全部そのページに配置されています．

また，初回起動時，日本語か英語かを自動で（GetUserDefaultLCID = 1041 かどうかで）選ぶようにしたので，普通の人には少しやさしくなったと思います．

_ [近況] ようやく住居の準備中 ▲

カナダに行ったときに全部捨てていって，トランク１つしか荷物がない状態だったので，何から何まで買いまくりです．

寝具類の納品が１週間後だったりするので，しばらく待ち状態になりました．

_ [論文] 開発者はドキュメントは読んでない ▲

LaToza, T. D., Venolia, G. and DeLine, R.: Maintaining Mental Models: A Study of Developer Work Habits. Proceedings of the 28th International Conference on Software Engineering (ICSE 2006), pp.492-501, Shanghai, China, May 2006. [ACM site]

開発者の作業時間の割合を調査した論文で，納期が近づくにつれて新機能を書く時間よりバグフィクスにかかる時間のほうが増えているとか，作業に割り込みがかかると，元の作業に復帰するまでには時間がかかるといった知見を得ています．

プログラム理解に使っている時間とコードを書いてる時間には負の相関があり，開発者は，自分が書いたコードについては十分な知識を持っているからプログラム理解には時間を消費してはいないようだとしています．

設計ドキュメントはいちおう書くものの，書いたものを読み返すことはまれであり，実際には自分が相手にしているコードを読んで知識を再発見している（そしてドキュメントは陳腐化していく）としています．

D. Spinellis の Code Quality (Addison-Wesley)の 7.2 Analyzability でも「コメントはアップデートするべきだが，他人がそうしてることを期待してはいけない」と言及されていたりするのですが，ドキュメントをきちんと更新しないから読まないのか，読まれないからどうせ更新しないのか，因果関係は謎です．ただ，こういうのを読んでると，「ソースがドキュメントだ」という発言にはそれなりに説得力がある気がしてきます．

_ [ツール] 使っている Soot のバージョンを上げてみました ▲

この前リリースされた 2.2.4 に移行してみました．ラベルの付与や一時変数の代入文など，どうも生成される Jimple コードが前と少し変っているみたいです．

Vista 64ビット版の JDK 1.6 上で新しいバージョンの soot を使って，メモリをとりあえず 4GB 渡してみたら（今までは 2GB），Java スライシングツールは40分かかってた PDG 構築を15分で終了しました．CPU自体の性能には極端な変化があるとは思えないので，ガベージコレクションが減った分が大きいのかもしれません．

_ [Java][論文] コンストラクタは引数なしが使いやすい ▲

Jeffrey Stylos, Steven Clarke: Usability Implications of Requiring Parameters in Objects' Constructors. Proceedings of ICSE 2007, pp. 529-539 [IEEE site]

Brian Ellis, Jeffrey Stylos, Brad Myers: The Factory Pattern in API Design: A Usability Evaluation. Proceedings of ICSE 2007, pp.302-312 [IEEE site]

いわゆるクラスライブラリ，API の使いやすさを評価しようという人々による論文２本です．

前者のほうは，何らかの引数が必要なコンストラクタを使うコードと，そうでないコード（引数なしで new した後に setFoo などとしてパラメータを与えるもの）とでどちらが使いやすいのか（短時間で使えるか），という比較を行っていて，後者のほうは，Abstract Factory って本当に分かりやすいのか，というのを調べています．

開発者は，コードを書くときに，とりあえずデフォルトコンストラクタの存在を仮定して new しようとし，コンパイルエラーが起きたのを見てから色々調べ始める，というパターンが多かったようです．なので，パラメータが必須なコンストラクタしかないクラスを使うのには，デフォルトで動くクラスを使う場合よりも時間がかかっています．

パラメータが必須ではない（デフォルト値つき）コンストラクタの場合は，与えるべきパラメータの組み合わせを理解することができ，それなりに便利なようです．

インタビューの結果によれば，実験対象となった開発者たちは，new してから setter を呼び出すほうが初期化の柔軟性が高くてうれしい，また，プロパティの値をセットしていく途中で適切なエラーコードを返せる（コンストラクタだと例外を投げるしかない）ことも良い，と答えていたようです．

Abstract Factory の場合は，コンストラクタを呼ぼうとする → コンストラクタが protected だからエラー発生 → 「サブクラスのために protected で用意してるよ」という決まり文句のコメントを見てサブクラスを探索 → でも見つからない → ようやくファクトリメソッドの存在に気づく というようなパターンにはまって時間を消費する場合があるようです．普通のコンストラクタで対応できるときはそうすべきだ（意味なく Abstract Factory パターンを導入すべきではない），と指摘しています．