netail.net

_ [hyCalendar] 六曜モジュールなんかも修正 ▲

参照ファイルを追加した瞬間と，ファイルを開いたタイミングで違うDLLがロードされる可能性があったので，久々に六曜モジュール側も更新．明日か明後日にはリリースします．

今さらながら，DLL 側に stdcall 指定が抜けていたこと発覚．今までは引数／戻り値のどちらかしか持たないような手続き・関数ばかりだったので(?)，偶然動いてたみたい．stdcall が抜けてると，スタックポインタがずれるのか何かで，関数から戻るまでは正常なのに戻ったら突然アクセス違反という厄介な動きをしてしまう．原因に気づくのに時間がかかってしまった．

_ [近況] 観光もぼちぼち． ▲

Granville Island Museum という，小さいながらも大量の Model Trains/Ships が飾ってあるところに行ってきました．

ここは５月１日〜１０月１日は毎日が営業日（他の期間は月曜が休業；微妙に勘違いしていた）．

どの場所も，基本的に，夏の間に行けと言う設定みたい．

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

ご指摘いただきました日付名のフォントの間違いを直しました．

それから，六曜モジュールのほうは，今までは六曜計算 DLL がカレントディレクトリにあっても読み込んだのですが，ちゃんと六曜モジュールのあるディレクトリに固定しました．また，発見できなかったときに何もメッセージ出してないことに気づいたので，ファイル参照のダイアログにメッセージを出すようにしました．

_ 少しだけサイドバーを変更 ▲

カレンダー部分がスペースを食ってる感があったので，順序を入れ替えてみました．

アクセス解析によると，アクセスされてるページの人気度合いとしてはアスペクト指向＞hyCalendar＞Volume Deskbar＞バラモス＞ミニ四駆＞MAngbandとなっているようです．ミニ四駆は相変わらず人気あるようです．

_ ASE の registration 開始 ▲

ASE 2006の registration がいよいよ始まったようです．early registration は8月18日まで．だいぶ余裕があります．

チュートリアルとワークショップが19日に全部重ねられているようで，今のプログラムだと18日は何もやることなし．これだと，成田到着後，１日休めるかな？

_ activemail が丸２日間もメンテナンスらしい ▲

日本時間で8日の0時〜10日の0時までだそうです．気づいてなくて影響をもろに食らってます．時差の都合で日本時間の金曜の夕方以降のメールは読めてないのもあるかもしれません（大学宛の奴はちゃんと読んでます）．

丸２日って何をするんだろう……．時々メールサーバがなぜか返事くれなかったりとかしたので，これを機に IIJmio の契約をしてみたりする．

_ [hyCalendar] 1.4.0 での新機能 ▲

周期予定の名前の中に「%d」があると，それを現在日（あるいは指定した日付）から何日目にあたるかという数字に置換する処理を実装してみました．「締め切りまであと%d日」とか，「今日から %d 日後」というのが書けるようになります．

数えられるのはただの日数だけです．営業日数とかは数えられません．この手の「特定の日だけを数える」というのをやろうとすると，基準日から目的となる日付まですべての日付を処理する必要があるためです．特定の日付だけを検索・カウントする機能は，用意するにしても別の機能とするつもりです．

_ [ツール] SootとPaddle ▲

プログラム解析ツールを作るべく色々実験中．ポインタ解析の実装であるPaddleを使おうとすると，paddleのnightly-build版は，sootのnightly-buildではなくpaddleのページにあるbuild版と一緒に動かさないとオプション処理に失敗するとか，微妙な関係があるみたい．また，内部で使っているJeddというツールも，Windows用の（たぶん高速な）DLL実装を使いたかったら自前でビルドしろとのこと．まだちゃんと使えるようになるまでは先は流そう．

_ [ツール] javadoc から HTMLHelp を作る ▲

javadoc をHTMLHelpにできないかなーと思って探していたら，世の中にはちゃんとあるようで．jd2chmと，Javadoc2Helpという２つのプロジェクトを発見．

jd2chm のほうは python で書かれているものの，実行ファイルも提供されていて，exe を適当な場所に置いて，コマンドプロンプトで javadoc のディレクトリに移動してから exe を実行するだけでOK．HTML Help のファイル名とかを対話的に聞かれるので，答えたら HTML Help が生成される．ちゃんとメソッド名などをキーワードとして抽出しておいてくれるのが嬉しい．ただ，poderosa 上で cygwin から動かすと対話インタフェースのメッセージが表示されなかったりしたので，その辺は使うときに注意が必要．

一方の javadoc2help は，Javaで作られているツール．パッケージを展開後，bin/javadoc2help.propertiesファイルにHTML Help のコンパイラのパスを指定すれば利用可能（Microsoft が提供しているヘルプコンパイラをインストールしておく必要はある）．引数には，javadocの置いてあるディレクトリと，それを出力する先のディレクトリ（javadoc のファイル群がコピーされたりプロジェクトファイルが生成されたりする）を指定する．

 java -jar lib/Javadoc2Help.jar -chm 
 -src ../soot/tools/soot-2.2.3/doc/ 
 -dest /tmp/soot-help/

こちらは，キーワード生成なんかはやってくれないので，けっこう簡素な HTML Help が出力される．そのかわり，プロジェクトファイルをちゃんと生成してくれるので，自前でキーワード生成したり，結果を改変したい場合には便利かもしれない．まあ，今回はjd2chmのほうを使わせてもらうことにした．

_ [ツール][Java] バイトコード解析ツール Soot ▲

Soot を使って Java プログラムを解析するとゆードキュメントを作り始めてます．

ソフトウェア工学系の人の論文で，たまに Soot を使って……という記述を見るものの，日本語で Soot について整理されたドキュメントというのが公開されていないようなので，ちびちびと書いていくことにしました．何も作らないよりは後々楽になるだろうと信じてます．

プログラムスライシングの実装に向けてどんな情報が soot から取り出せるのか少しずつ実験しているところなので，その辺のことも少しは追記するつもりです．

_ [近況] 講演＠UBC ▲

Bjorn Freeman-Benson と Ward Cunningham の２人の講演．せっかくなので聞いてきた．２人で交互に喋るという形で流れるように喋っていく見事なプレゼンテーションだった．

講演のテーマは，協力(collaboration)って大事だね，というもの．２人の経験によると，プログラミングは最初は「自分だけ(me)」からスタートして，us（グループ開発）→you（商用ソフトの開発）→we（顧客と一緒に仕事する）→all（コミュニティでの協力）と進んできている．他人を信頼して協力することで，より良い成果を得ることができるようになっている．

１つのアイディアというのは，技術（technology）と方法論（methodology），アイディアを支えるコミュニティの３つによって成り立つのではないかと考えられる．たとえばJUnitなら，技術的には小さなフレームワークで，背景にはテスト駆動型開発という方法論があり，１つの開発チームが協力してそれを実践することで，より安心してソフトウェアを変更できるようになる，とか．

で，彼らは今は Eclipse Monkey というのに注力しているらしい．サイトはhttp://eclipse.org/dash/．端的には，Eclipse用の「ちょっとした改善」をスクリプトにしちゃおう，というもの．たとえばディレクトリツリーは最初に全部開いてる状態がいい，とかいうのを短いスクリプトで制御できるようにEclipseの環境をオブジェクトモデルとして提供しようというもの．短いスクリプトをみんなで公開して共有すれば，徐々に改良されながら便利な環境になっていくはずだし，「ちょっとした改善」も積み重なってくれば，開発者にとって便利な機能が分かってきて，それがAPIの洗練なんかにも繋がると考えているみたい．技術／方法論／コミュニティには，スクリプティング／リファクタリング／ブログなど，が対応する．

Eclipse の API が複雑化していることについては，開発者が学習する機会を設けるしかない．これについては独習用の教材（experience guide）を提供することが大事なのではないか，と言っていた．Eclipse の API を使うプログラミングの教育を scalable-personal という軸で考えたときに，ペアプログラミングは一番 personal 寄りで密度は高いけれど同時には１人しか相手にできない．パターンは逆に一番 scalable で，書籍なんかにすれば広く伝えられるけど，それだけではプログラムは書けない．wiki での情報交換ならもう少しだけ personal 側に寄るけれど，やはりまだ足りなくて，良い教材をコミュニティ（coach network）が提供して開発者が自分で経験を蓄積できるようにすべきだと考えているらしい．

……といったような感じで講演は１時間ちょっとだった．話された内容はだいたい理解したつもりだけど，多少ニュアンス違ってたりして．講演は，論文と違って，後から内容の正しさを確認できないのが厳しい．

余談: Monkey のスクリプトが Ruby や Python ではなく Java Script ベースなのは，熱狂的信者も強い反感を持った人も特にいなくて無難でしょ，とのこと :)

_ ごそごそとドキュメント書き ▲

「Soot を使って Java プログラムを解析する」に Soot の基本的な構造についての情報を追加しておきました．制御フローグラフに辺を追加しようとしたら実は unmodifiable だったとか，実験してる途中ではまったことはだいたい書いてみたつもりです．

bddbddb のときもそうですが，ドキュメント書いたとたん google で上位に来てしまうのがちょっと怖いです．

_ オーストラリア辞書／年表のバグ修正 ▲

bun45 オーストラリア辞書でエラーが出てた問題を修正しました．なんだかんだと息の長い（学部生だった頃から関わっている）プロジェクトで，古いライブラリへの依存性を切り捨てるべく今年修正した部分がエラー吐いてました．

最近，どうも問題の見逃しが多い気がするので，ソフトウェアのテスト方法あたりを改めて勉強してみないとなーと反省．

_ [読書] オブジェクト指向設計の経験則？ ▲

ACM のサービスでタダで読める範囲で見つけた Arthur J. Riel: Object-Oriented Design Heuristics を読み始めてみた．

２〜３章を読んだ限りでは，「余計なインタフェースを付けると，それだけ複雑になり，利用しにくくなる」といった，「比較的良い」設計の指針が提示されている．

オブジェクト指向をやり始めの人向けなのか，オブジェクト指向の基本概念の解説や，従来の手続き型言語でのプログラミング（この人は Action-Oriented と呼んでいる）との比較にもかなり分量を割いている．挙げられているのはよく知られている指針ばかりだけど，それぞれ具体例を出しながら「こう直したらいいよ」と解説してるので，かなり親切で読みやすい．

設計の問題のいくらかは，悪い設計を選んでもあまり全体には影響がないが，クラス数の増加（proliferation）の問題だけは違う，といったことが書いてあったので，まだ少し読み進めてみることにする．

_ [読書] Heuristics 本の続き ▲

昨日の続きで Arthur J. Riel: Object-Oriented Design Heuristics を読む．１章読むのに２時間ぐらいのペース？

４章はオブジェクトの使用（Use）と所有（Containment）についての説明．所有しているオブジェクトはちゃんと自分で使う（その参照を外部に提供しない）とか，良く知られた指針が多い．

５章ではクラスの継承なんかについては丁寧に触れられていた．紹介されてる改善例の中に，今では Strategy パターンや Composite パターンと呼ばれているものを発見．デザインパターンというのが良く考えられて作られているものだというのがちょっと分かった．

オブジェクトの参照については，あんまりたくさんあると複雑になるから６個ぐらいまで，少ないほうが良いと言ってるのに対して，クラスの継承については，「継承しても継承元は複雑にならないから」別に気にしなくていいと述べていたりする．

クラスの継承階層について，「正しく継承を使っているのであれば，継承の階層は深ければ深いほど良い」という意見を見たのはたぶん初めて．ただ，10を超えたあたりからクラス継承階層が把握しきれなくなるので，GUIツールなんかを使ったサポートで把握できる範囲（何もなければ６段程度）で使うのが妥当，といったふうに書いていた．継承階層の幅（１つの基底に対する派生クラスの数）については，「多い＝基底クラスがうまく再利用されている」なので，こちらは普通に多くて良いらしい（ただ，クラスでないものまでクラスにしてしまうことがあるので気をつけるべし，というのは書いてあったが）．

深ければ深いほど良いというのは，多段階の継承によって，差分で細かくクラスが定義されているほうが，再利用しやすいと考えていたりするのかもしれない……．

知らなかったのでいちおうメモ: C++ で，superclass/subclass ではなく「基底クラス base class」「派生クラス derived class」という呼び方をするのは，スーパークラスが持つデータメンバーはサブクラスのデータメンバーの subset になっている，といった紛らわしさを避けるためらしい．

_ [hyCalendar] 1.4.0 バイナリだけ ▲

ヘルプファイルを書き直そうと思ってるわりにぐだぐだしてるので，1.4.0バイナリだけを置いてみます．

期間予定を土日祝日だけ非表示にしたい人，「５日おき」のように定間隔の予定を書きたい人，「〜〜まであとX日」とか書きたい人向けの機能拡張が入ってます．変更点のリスト参照のこと．

当然ながら，新たな情報がファイルに保存されるので，データのバックアップをしてから使ってみてください．

「１月１日から１日おき」という表現だと１月１日，３日，５日...とか容易に想像できるんですが，１月１日，１１日，２１日...の予定を「９日おき」と表現するのはいまいち分かりにくい気がしました．そのため，「１０日に１回」という表現を使ってみていますが，どうでしょうか？もっといい表現があるよ，という方がいらっしゃいましたら，お教えいただけると幸いです．

_ [読書] Heuristics 本の，さらに続き． ▲

Object-Oriented Design Heuristics ６章〜９章．このあたり，あんまり新規な内容はなかったので短くメモ．

６章は「多重継承は正しく使おうね」という話だけ．

７章は「association」の解説．use でも containment でも inehritance でもない関係のこと．たとえば，車とメーカーがあるとき，車とメーカーオブジェクトが互いにメソッドを呼び合うわけでもないし，互いに所有関係にあるわけでもないが，どのメーカーがどの車を生産したか，という関連を持っている．で，車が持つメーカー名のような属性はメーカーオブジェクトを発見するための参照用の属性（referential attribute）だとしている．referential attribute を使うと，クラスの外部で間接的な利用関係を定義できる．たとえば「特定のメーカーの車を回収する」recall クラスなんかは，メーカークラスの機能数の増加を抑えるために有効だと言及されている．ただし，containment に比べると，「こう使ってほしい」という情報を外部に公開する分，クラスを使う側が理解する必要のある情報が増えてしまうので，containment を選べるならそうしたほうが良いと述べている．

８章は，オブジェクトに固有のIDを割り付けるといった，オブジェクト単体では対処できない振る舞いをメタクラスでモデル化しましょう，という話．メタクラスといっても，実装としては C++ や Java での static 宣言とか C++ でのテンプレートとかになるけど．

９章は physical design として，論理的な設計をプラットフォームに落とし込むときにどうするか，という話．プラットフォーム依存な設計をするのは良くないが，設計案が複数あるときに，実装上コストがかからないとか，プラットフォームの情報を使った意思決定は別に良い，と言っていたりする．あとは，ラッパークラスを使って外部システムをオブジェクトに見せることで従来のシステムやデータを再利用できるので良い，という話とか．この辺の内容は，普通の設計関連の本ではあまり見たことがない気がする．

_ [読書] Heuristics 本ようやく読了 ▲

Arthur J. Riel: Object-Oriented Design Heuristics. Addison Wesley, April 1996.

９章までがヒューリスティクスの紹介だったのに対して，10章はデザインパターンとヒューリスティクスの違いについて検討されている．この本の発表の時期的には，パターンランゲージは既に知られているけど GoF のデザインパターンカタログなんかはまだ，というぐらい？

ヒューリスティクスとデザインパターンの関連性は明らかにあり，筆者の「ヒューリスティクス」というのは「悪い設計パターン」から「良い設計パターン」へ至る変換のパターンであるといえる．

デザインパターンは，それをいつ適用すべきかというのが分かりづらいことがある．それに対して，ヒューリスティクスは「悪い設計パターン」というのがどういうものかを短く表現していて，しかもCASEツールによって自動的に検出できるものが多い．

ただし，変換パターンとして適用できる変換というのは複数あって，たとえば柔軟性とかクラス数の最小化とか，どの属性に着目するかで適用する変換が変わってくる．ものによっては，性能面など，実装都合上のトレードオフなんかも影響する，と述べている．

10章ではいくつか今までのヒューリスティクスを変換パターンとして書き直して紹介していて，１つのパターンの出力が他のパターンの入力になりうる推移性と，specialize/generalize のような反射性（２つ適用すると元に戻る）を持つパターンが挙げられている．

今後の研究の方向性として，次のようなことが挙げられていた: (1) 変換パターンをどう分類するのが良いのか．推移性などでその関連性を整理できるか． (2) 機能拡張などでの設計変更は，変換パターンによってとらえることが可能か？もしそうなら，それらのパターンの入力とは何なのか？ (3) 変換パターンを多数持っていたとして，それによって設計の最適化を自動化することは可能か？つまり，悪いデザインから良いデザインへユーザを導くようなツールは作れるか？そんなツールを作るには，設計の良さを，柔軟性，移植性，効率性，ソフトウェアやハードウェアの制約，クラス数の最小化といった側面から判断できる必要がある．

最後の11章は銀行のATMと銀行のトランザクションを取り扱った設計の例．途中でどんな選択肢があり，どのヒューリスティクスに基づいて設計を選んでいくかというのが解説されている．あとは付録で，ヒューリスティクスのリストと，なぜか「C++で起きるメモリリーク」の例とかが付いていた．

読むのにけっこう時間はかかったものの，読んだ価値はあったといえそう．10章の内容は，悪い設計パターン＝「コードの不吉なにおい」と読み替えると，「リファクタリング」の話に近いことだと言ってよいかもしれない（リファクタリングはコード可読性レベルの話もあるので一緒くたにするとまずい？）．今後の研究の方向性については，けっこうどこかの学会で聞いたかな？というような話もあったりするし，かなり示唆に富んでいるように思う．

余談: ヒューリスティクスによる改善の効果は，リファクタリングの効果が評価しにくいというのと同じように，評価しにくい．この本で出ているヒューリスティクスは，局所的な依存関係の変換だけを提示しているので，クラス数の増減や実行効率の変化を除いては，システムのほかの部分に波及することがない（カプセル化がうまくされているなら）．だからこそ step-by-step な改善に適用できるんだけど，「その改善ってどのくらい効果があるの？」と聞かれると弱かったりする．

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

ヘルプまわりの修正が終わったのでリリースしました．先日出したバイナリだけ版からは，特に変わってません．ヘルプのほうは，ちょっとファイルを小分けにしたりとか，目次を増やしたりとかしています．それから，HTML構文的にまずかった部分をかなり修正しました．

ワークショップに出してる論文の査読結果がもうすぐ届いたりとかするので，またしばらく本業専念モードになる予定です．更新間隔が広くなると思います．

_ [近況] ワークショップの notification 待ち． ▲

まだ届いてないので，月曜には聞いてみる予定．

今回はスケジュールにも余裕がずいぶんあるので，あんまり緊急でもない．

_ [近況] 今日も講演を聞いてきた ▲

Thomas Zimmermann という人が，今度のASEで発表する内容とかを話してくれた．この人は，去年のFSEではCVS履歴から「Aを追加してる人は同時にBも追加している」という情報を集めてきて，パターン分析しようというのを発表してた．

今度の手法は，アスペクトマイニング．「どこでどのメソッドを呼び出しているか」の関係を呼び出し側を縦軸，呼び出し先を横軸にとってチェックをつけていく．concept anlaysis を使って縦長の長方形になる部分（２〜３個程度のメソッド集合が，たくさんの場所で呼び出されているケース）を発見すればそれはアスペクトの候補だろう，としている．fan-in analysis の拡張といえる（？）

この人のアプローチで面白いと思ったのは，ロギングのような横断的関心事は「同時に複数個所に配置される」，IteratorのhasNextとnextのようなメソッドペアは「一度に一箇所ずつ増えていく」という仮定．これらの違いをCVS履歴から区別しようとしている．「一度にたくさんの箇所に呼び出しが追加されているもののほうがアスペクトっぽい」というメトリクスを定義しているようで，それをランキングに使った結果，lock/unlock ペアとか，意味のありそうなものが上位に出てきているらしい．

この人は，「データ抽出タイミングと，出てきたパターンのランキング手法とのどちらで頑張るかという選択肢があるが，ランキング側に力を入れている」らしい．だから，メソッド呼び出し対象のエイリアス解析とか，その辺はコストかけず適当に，という感じらしい．

メトリクスのちゃんとした定義とか，CVSから取ってきたデータと最新ソースのデータの取り扱いとか，ちゃんと論文が出てから確認したいところ．