netail.net

_ 読書 ▲

部室に転がっていたので，きたみりゅうじ「SEのフシギな生態」を読んでみた．

ちょっと漫画も入ってて読みやすい本．SEが仕事でこけた，失敗談集みたいな感じで，SEに必要な技能（コミュニケーション能力，業界知識，etc）と発言に対する責任とか，プロとはどういうものか，といった話などが説明されている．わりといい本かも．

_ AspectJ ▲

Volkmann, Mark の投稿によれば，Eclipse と AspectJ 1.1 が JSR-45 をサポートするまでは-XnoInline オプションを使わないとステップ実行がうまくいかないらしい．加えて，advise コード中には breakpointが置けないらしい．

_ AspectJ ▲

Eclipse 用 AJDT は JDT に依存しているが，JDT は .java をハードコーディングしてるので.aj なファイルは，ステップ実行のときに認識できないことがあるらしい．なんだかなー．しかも，Eclipse 3.0 待ち（JSR-45実装待ち）らしい．

_ AspectJ ▲

７月３１日付けで，AspectJ 三冊目の書籍 AspectJ in Action がリリースされたらしい．

_ paste ▲

暇つぶしに「UNIX コマンド ポケットリファレンス」を読んでいたら，「行を連結する（改行を任意の文字列で置き換える）」paste コマンドの存在を初めて知った．

あと，知らなかったのは cmp, comm （ファイルの差分計算）くらいか．実際には awk や sed も使ってないといえば使っていないのだが．

_ 住基ネット ▲

豊中市の広報を見てたら，住基カードというのがもらえるらしい．名前だけ or 名前＋住所＋写真という，市民IDカードみたいなものらしい．使えるようになるまでは時間がかかりそうだけど，身分証明のためだけに免許証取る人は減りそう．

_ Ruby ▲

Ruby 1.8.0 リリースらしい．

_ DRT ▲

Design Recovery/reverse engineering Tool 0.3.5 をcygwin で make しようとしたが失敗．普通の Linux とかの上で build したほうが安全なのかも．

それにしても，X Window でしか動かないと言うところをみると，やはり X でのイベントをフックしまくりなのかなぁ．

_ Java ▲

Java World 9月号を読んでたら，Torque というものが紹介されていた．Object と Relational DB の世界をマッピングして，テーブルに相当するクラスに doSelect(Criteria) とか叫んだりできるらしい．マッピング自体は XML で記述．

DBごとの SQL の方言などを消せる点が有利らしい．

_ IWPSE2003 ▲

黙々と発表準備．OO2003 のほうはおおむね固まっているが，こっちもデモシナリオの準備とかがあるのでほうっておくわけにもいかない．旅行で４日間は allocate されているので，そのぶん今働く :-)

_ AspectJ ▲

AspectJ in Action, JBoss AOP を関連リンクに追加．最近 AspectJ でコーディングしてないので本来のコンテンツがあまり充実してないような気もする．

_ ワイン ▲

お土産に買ってきた梅ワインを飲んでみる．梅酒に近いけど，甘くなくて微妙に違う感じ．氷入れたら美味しそう．ワインの飲み方ではないけど．

_ ZAQ ▲

ZAQ も Web メールを提供しまっせ，というメールが届いてた．まあ，activemail も Web メールがあるので，ZAQ アカウントを使おうという気はないのだが．

以下の URL は 8月6日から available らしい．https://pw1.zaq.ne.jp/support1/cgi-bin/webmail_top.cgi

_ AspectJ ▲

アスペクト指向な Java フレームワークが世の中にはあるらしい．AspectWerkz は AroundAdvice クラスとか，アドバイス１個が１オブジェクトになるらしい．配備は XML を使う様子．http://aspectwerkz.codehaus.org/

複数のアドバイスが協力したいときはどうするんだろ．アドバイス間を横断するアドバイスでも定義するんだろうか．

_ ワイン ▲

ワインが無事到着．要冷蔵らしいので，さっそく冷蔵庫へ移動．代金の支払いが，てっきり代引きだと思っていたのだが，「インターネット代引き」という謎の記述がされていた．楽天のシステム使って，クレジットで落とすだけだろうか？

_ クレジット ▲

出張で泊まる予定のホテルでは JCB カードが使えるようなので現在の限度額でも問題ないのだが，念のためということで Citibank クリアカード (VISA) の限度額の増額を申し込んでみたら，「このカードは増額不可能です」と自動音声応答にあっさり蹴られた．まあ，実際には何の問題はないのだが……．

_ PC-98 ▲

とうとうNEC PC98シリーズが終了したらしい．http://www.zdnet.co.jp/news/0308/07/njbt_03.html

PC-8801MH，PC-9821Cx を３年ずつ使った身としては少し感慨深いものがある．

Factory系の FC シリーズとかは，サポートまで打ち切りになったようなマシンでもまだ現役稼動してるらしい．レガシーシステムの置き換えって難しいんだろうなぁ．

_ ワイン ▲

結局，シャンボールミュジニー 1934年，アンリ・ド・ヴィラモンは年数のわりに飲みやすくて（渋みはすごかったけど）美味しかった．

残念ながら，ラベルはがしは失敗したが記念写真だけ撮ったのでよしとしておこう．

コルクはかなりぼろぼろ．抜くとき，崩れそうなくらいやわらかくなっていた．ボトル写真

ボトルはこんな感じ．ボトル写真その２

注いでみると，赤色が微妙に違う．ワイン

_ AspectJ ▲

AspectJ-Users ML で，"Any useful examples" というSubject で，Kenworthy, Edward がロギング以外に，AOP でないとできないことはないのだろうか？他のものは，デザインパターンなど，他の技術でもできるような気がする．とかいう感じの投稿をしていた．

「AOPでなければならない」ことというのは難しいと思うのだが．計算可能性という意味では同じなわけだし．

でも，これに対して，使い方の例として，R. Dale Asberry が，プロパティのデフォルト値を設定するのに使っている．before(call(System.getProperty()))をトラップして，もしプロパティが設定されていなければ他のプロパティの値を読み込んだり特定の値をセットしたりして，コンソールに「プロパティの値が設定されていないのでｘｘｘにするよ」と出力する，なんて使い方もできるよーと投稿してた．Property Manager を作ると無駄に依存関係が出てしまう，プロパティの値はデフォルト値を初期化できるタイミングが違うことがあってコードが分散してしまうことがあるが，それを防げる，とか言っていた．

これはこれで，面白い使い方かも．

_ Java ▲

さらにメモ．

(6) JDK 1.2 では，Exception.printStackTrace() の結果は implementation depends である．Java VM の改造以外の方法で，正確な例外発生場所を知ることはできない？……とか言ってたら，スタックトレースがオブジェクトとしてアクセスできるよういなったので，今ならたいていは情報を持っていると考えても良さそうではある．

(7) Java Virtual Machine Profiler Interface (JVMPI) のソースは Visual Studio 6.0 では nmake all でコンパイルできる（環境変数の設定が必須）．生成されたjdk/bin ディレクトリに配置しておく必要がある．-Xrunhoge (hoge.dll の場合)オプションをつける．

_ Java ▲

さらにメモを移動．今度は I/O 関連．

(3) BufferedInputStream は，読み込み途中でデータが途切れた場合， in.read(buf, 0, size) で size 分を完全には読み込まないことがある．in.readFully を使うか， in.read(..) の戻り値を使ったほうが安全．

(4) finalize() は終了処理を記述する場所ではない．GC から呼ばれた場合の処理を書く場所．ファイルをフラッシュして閉じる処理などは，Runnable.run() で flush, close を行うようなオブジェクトを用意しておいて，Runtime.getRuntime().addShutdownHook を使う．

(5) 純粋なテキスト入出力処理だけでは，PrintStream での print, println 呼び出しは例外処理を行っている分遅い．ObjectOutputStream の writeObject もわりと遅い．手動で char から byte へのキャストを行ってwrite(buf, 0, len) で書き込んだほうが高速になる．BufferedOutputStream のバッファサイズは 64K くらいまで．

_ Java ▲

古いメモファイルを発見したのでこっちに移動．

(1) javax.swing 系コンストラクタは L&F (Look and Feel) File Loading Thread で動作する．

(2) Class.getName(), Thread.currentThread() は native call を含むため，呼び出しコストが大きい．Class.getName() については，HashMap.put(obj, obj.getClass().getName()) などのように結果をキャッシュして高速化できる場合がある．Thread については，なるべく使わないようにするしかない．

_ バージョン ▲

Windows 2000 のシステムCD内にあるsupport/apcompat.exe でプログラム名 + OS を選択するとOSのバージョン情報をごまかせるらしいと聞いて，昔々のプログラムを実験的に動かしてみたが，やっぱり動かなかった．さらに，Win32s など一部の非互換APIを使っていると異常終了するらしい．

_ アルゴリズム ▲

旅行から帰ってきて，部屋の片づけをしていたら，擬似一様乱数を発生させるためのアルゴリズムのメモを発見．紙のメモのほうは捨ててしまうことにする．

  x[0] = 適当な初期値
  x[n] = (A * x[n-1] + C) mod M
  M = 2^N, A MOD 8 = 5, C MOD 2 = 1 のとき一様乱数となる。 
  ex. A = 109, C = 1021, M = 32768

_ AOSD ▲

aosd-discuss MLで，Aspects and the Event-Driven Model という Subject でJody Sharpe が，イベントドリブンモデルとの違いは？という質問をしていた．

Gregor Kizales の投稿によれば，イベントドリブンモデルでは，イベントが発生したことを知らせるためのメソッド呼び出し文などが各所に分散する．また，AOP では，「何がイベントか」（pointcut 定義）と「イベントに対して何をするか」（advice 本体の定義）が分離されている点も特徴である，とのこと．

Events と AO の違いはAspect-Oriented Dependency Inversion:http://www.cs.ubc.ca/~kdvolder/Workshops/OOPSLA2001/submissions/12-nordberg.pdfが実は詳しかったらしい．

_ 実家 ▲

NHK ローカルニュースで，高校のときの友人がニュースを読んでいるのを目撃．さすがに，入社１年目なので，そこまで上手ではないが．

親とかはどんな気持ちで見てるんだろう．

_ 本 ▲

実家の本を整理．いらない単行本を中心に，１００冊程度（所有の約５０％）を処分することを決定．判定の基準は「過去１年に読まなかったものは次の１年にも読まない確率が高い」．

_ Eclipse ▲

Eclipse プラグインからダイアログを表示しようとして，SWTから「スレッドが正しくないよ」と怒られた．

GUI用スレッド以外からはダイアログ表示などをさせてくれないらしい．ある意味当然かもしれないが．

結局，Display.asyncExec でGUIを扱う Runnableのインスタンスを渡せばいけるらしいということが分かって解決．

_ 紅茶 ▲

レピシエのダージリン・ビクトリアフォールで水出し紅茶を作ってみた．１時間半くらい漬けた時点で，かなり渋みが出てたので，わりと失敗かも．

ダージリン全般が，そんなに水出しに向いてないのかな？カンチェンジュンガのときはうまくいったのに……．

_ bun45 ▲

まったく最近進展（状況の変化）がないので，bun45 サーバ管理関連の残りの課題を整理する． ・次期管理者探し・文学部統合サーバへの移行はどうなった？ という二点．前回，ディレクトリ構造の改変をして

/usr/local/cgi 以下     => /home/httpd/cgi-bin/seiyousi/util
/home/httpd/html 以下   => /home/httpd/html/seiyousi
/home/httpd/cgi-bin 以下 => /home/httpd/cgi-bin/seiyousi

と変えたので，統合サーバへはファイルコピーだけでいける……はずなのだが．サーバ移行の話はどうなったのだろう． ディレクトリの置換作業は，次のように実現．手抜きだなー．

sed s/\/usr\/local\/cgi/\/home\/httpd\/cgi-bin\/seiyousi\/util/g

_ bMobile ▲

現物支給ということでもらった bMobile，出張に向けてセットアップしてみた．約100kbpsで，やはり遅いが，これで場所を（そんなに）選ばずメールが読める．

_ アルゴリズム ▲

偶々見つけた，遺伝的アルゴリズムの解説．いわゆる N-Queen パズルを解いてるのだが，Pc=60, Pm=30 で 100 世代ちょっとで解に到達して感動．

http://kaz.cyteen.nagoya-bunri.ac.jp/knowledge/nqueen/GAqueen.html

_ 読書 ▲

秋田禎信，魔術師オーフェンはぐれ旅「我が聖域に開け扉（上）」読了．発売から半年近く経っているはずなので，いまさらという感じではあるが．

伏線消化モードに入ってるせいか，ストーリーの展開が速く見える．まあ，シリーズ開始（１０年くらい前？）から付き合ってる作品なので，完結が見えてくると，感慨深いものがある．

_ CD ▲

飯塚雅弓「SMILE×SMILE」購入．ポスターはいらないので後輩にあげることにする．

_ AspectJ ▲

AspectJ-users MLで，AspectJ の advice にはなぜ名前がないの？という質問があって，adviceexecution や advice のオーバーライドで使うかもしれないが，adviceexecution は登場が遅かったから考えに入ってなかった，という返事をしてた．構文的にはサポートしてもいいが，特に意味のない情報（コンパイルエラーとかでは意味があるが）になるかもしれない，とのこと．

_ OO2003 ▲

OO2003本会議１日目．基調講演は Bertland Meyer で，Trusted Component という話．よいコンポーネントとは何か，とか色々．

午後から，Web アプリケーションのセッションに参加．・フレームワークを作ってやると再利用性が上がる．・デバイスごとのページを，設計時に生成しておくのではなく， 実行時に生成することで管理が楽になる．・デバイスごとのページを，デバイス非依存モデルから デバイス依存モデルへ，と落としていく．・みんな Struts を使っている．というような感じだった．

さらに，パターン系の人々のパネルディスカッションに参加．建築でのデザインパターンとの対比が面白かった．家のユースケースとして雨風をしのぐ，というのは書けるけど明るさがどうこう，というのは実は書けないとか，パターンランゲージはGUIデザイナのためだけのものではないとか，ソフトウェアのほうが，建築よりも分析と設計の間のギャップが大きいとか，システムに対する要望を一貫して保持するコーディネータが必要だとか，建築の世界では実はデザインパターンというのは意外と少数派だったりとか，ソフトウェアで使ってる人のほうが知識の整理に使えるとか色々な考えを持っているとか，色々な話がぽんぽんと飛び出してた．話に乗ってる人々，みんなすごいなぁと感心．

_ OO2003 ▲

初日は Meyer による Eiffel チュートリアル．ツールのインタフェースがちょっと格好よかった．"Multiple inheritance is easy" とかあっさり言うあたりがすごいかも．AOP については，「アーキテクチャをいじらずに，外側から（ソフトウェアを良く知ってる人が）ソフトウェアを改変するもの」という感じの認識らしい．アスペクトがいっぱいあると保守しにくそうと思っている様子．純粋にオブジェクトだけで頑張るタイプの人なんだろうか．

アスペクト指向といえば，福岡工大の趙先生に，研究室の名前とAOPやってます，というだけで名前を当てられてしまった．実は密かに有名だったりするんだろうか？

_ ▲ ホテルまでの道が分からなくて微妙に苦戦．途中，休憩のため，初めてスターバックスに入った．普通の喫茶店（紅茶）を利用する人間なので今までまったく縁がなかったのだが，人に驚かれた．

_ IE ▲

セキュリティホールに伴う WindowsUpdate が２つばかり出てるのだが，bMobile ではダウンロードするのが大変なので出張が終わるまで見送る．研究室のマシンも，いつもならリモートデスクトップ~とか使うところだが，こっちも bMobile では手が出ない（たぶん）．

_ OO2003 ▲

発表が無事終了．IBMの方に興味を持っていただけたので，名刺だけいただいて，後でメールでツールのURLを投げることに．

懇親会で，名前だけは知っていたhttp://dolphin.c.u-tokyo.ac.jp/~kazu0/ の作者の人に会う．実は同い年でびっくり．一杉さんらと AOSD-JP (?) メーリングリストを発足させよう，ということで合意を取った．実はこれが最大の成果かもしれない :-)とりあえず，用語（Crosscutting Concerns など）の和訳を統一できたらいいなぁ，などと思う．こういうのは一人ではできないし．

東工大の千葉先生の Join Point = 結節点，というのは初めて聴いたけど，何となく正しいような気がする．

_ aosd-jp ▲

なんと，現時点で120人．この５時間くらいで30人が加わったことになる．みんなどこから情報集めてるんだろう．

_ 論文 ▲

Exception Handling in Object Oriented SystemsECOOP2003 の Workshop の文献を消化，その２．

Johannes Siedersleben:Errors and Exceptions -- Rights and Responsibilities

概要は次の通り．

みんな例外を正しく使っていない．一番よいもので，ある種のロギングという程度で，何もしないものも多い．

コンポーネントが何をしてよいか分からない(Emergency)ときに例外を使うべきである．また，これらの例外はできるだけ早く検出するべきである．

アプリケーションエラーは，場合の数が限定されるので，動作の失敗を返すだけなら，戻り値でよい．戻り値で返せないときだけ例外を使う．また，アプリケーション関連の例外だけは直接の呼び出し主が捕まえ，外へ出してはいけない．（戻り値の一種という以上の意味を持たせてはいけない）

Emergency 例外のチェックを行わないコンポーネント群をRisk Community というかたまりで考える．ある Risk Community へは，Safety Facade という例外を吸収する Facade オブジェクトを介してアクセスする．（Facade は Emergency 例外 -- RuntimeException -- を吸収する）

事前・事後条件について，事前条件は，呼び出し側と呼び出される側とどちらが働くかの取り決めで，失敗した場合は ViolatedPreconditionException を生成すると良い．事後条件は誤った実装による戻り値から呼び出し側を守るためにあり，事前条件と役割が異なる．

例外を扱う10個のルール：

1. Emergency とアプリケーションエラーは区別する．

2. Emergency はできるだけ早く捕まえる．

3. 事前条件が違反された場合は呼び出しを失敗させる．

4. 入力パラメータは，通常は null でないと仮定する．

5. Risk Community は Safety Facade を介してアクセスされる．

6. Emergency を捕らえるのは Safety Facade に任せる．

7. Safety Facade は，事前条件違反以外のすべての例外を捕まえる．

8. アプリケーションエラーは，できるだけ戻り値で表現する．そうでない場合，Checked Exception を使う．

9. アプリケーションエラーはすぐに捕まえる．

10. 制御フローを扱うために必要でない限り，例外クラスを勝手に作らない．

_ 論文 ▲

Exception Handling in Object Oriented SystemsECOOP2003 の Workshop での論文を消化．

Ricardo Mendonca da Silva, Paulo Asterio de C. Guerra and Cecilia M. F. Rubira:"Component Integration using Composition Contracts with Exception Handling"

Computational Layer, Coordination Layer, Application Layer と三階層に分けて，Computational Layer にコンポーネントを置いて，そのサービスを Coordination Layer にあるComposition Connector が連結し，処理を行う．で，クライアントコンポーネントはApplication Layer に置かれる．

ここで，Composition Connector はComposition Contract Component を使って構成されるらしい．Contract をコンポーネントで表現してるとこが新しいのかな？と，ちょっと良く分からないが．

_ aosd-jp ▲

何人くらい登録してるんだろう？と思ったら，既に登録者数が93人．どこかの ML で見たことがあるアドレスがいくつかあった．実は潜在的需要は大きかったのかなぁ．

_ OO2003 ▲

OO2003 のパターン関連ツールデモンストレーションとして紹介されていたツールのメモ．

Pattern Studio for Eclipse: Eclipse でデザインパターンを適用したコードを生成する． コードの生成にたまに失敗する，らしい．

Borland Together: デザインパターン適用ツール．Eclipse用のバージョンでは デザインパターン検出とかもできるらしい． 商用だけあって，いい速度で動作しているし， パターンのカタログも充実していた． しかも，メタデータを使わずに（変なコードを生成せずに） 動作するあたりがかなり偉い．

PTIDEJ: ソースコードからのデザインパターン検出ツール． もちろん，検出率は100％ではないらしい．

これに対する意見，要望，疑問は，

・使えるデザインパターンをどれだけ知っているか？

・知らないパターンを使えるようになるか？

・適用されているデザインパターンを「除去」できるか？

・デザインパターンの「再発明」をユーザに見せられるか？

といったところ．パターンといっても，GoF 以外のはほとんど知らないので本当に使いきれるのかなぁ，と疑問ではある．

_ AspectJ ▲

aosd-jp ML のことを追加．……ちなみに ML の参加者は既に300人を突破．たいしたものだ．

_ OO2003 ▲

OO2003 で集めた情報その２．

ポストオブジェクト技術のセッションでの発表:

オンデマンドなアスペクトウィービングを使ったWebシステムのパーソナライズの話:・動的ウィーブで，必要なところだけキャッシングして高速化・クライアントごとに別クラスローダを用意して， 別アプリケーションとして認識させるらしい．・JIT Aspect Weaver を使うことでウィーブのコストを下げる．

しかし，問題として，・生成したアプリケーションの生存期間をどうするか．・クライアントの数が多くなったとき， パーソナライズしすぎて死ぬ？といったものを挙げていた．生存期間をアクセス頻度などから推定するとかするんだろうか．ちょっと面白そう．

_ Mixin によるプログラミングの話: ▲

Mix-in = 抽象サブクラス，という説明はとても面白いと思う．Mixin を追加した Java （Javaへ変換する形で実装可能）McJava: http://kumiki.c.u-tokyo.ac.jp/~kamina/mcjava/を実装したらしい．

合成されるクラスにインタフェースを requires セクションで要求できるらしい．Mixin ID requires Interface { ... }合成は ID::ID::ID というようにMixinとクラスの識別子を連結するだけ．

関連研究の調査が充実していた．ABT: Sullivan, Abstract Behavioral Type -- イベントを定義しておいてイベントをListen したい人を登録しておけるようにする．クラスをあらかじめ ABT にしておかないといけない．

AspectJ : AspectJ では Aspect はファーストクラスでないのでオブジェクト間の関係のインスタンスが書けない？とか言っていた実は Aspect は class Aspect のインスタンスだし関係オブジェクトは素直にブジェクトにすればいいのになぁ，と思う．

Epsilon モデル: Ubayashi, N. et al., 2001役割，役割間の関係を分離するらしい．暇があったら見てみよう．

クラス（デザインパターンなど，インタフェースによる分離）による実装とMix-In による実装とで，結合度とかが違うのか？という質問があった．アスペクト使った場合もそうだが，実装方法にかなり依存しそうで，Mixin 使わないとできないこと，は少ないような気がする．

_ OO2003 ▲

OO2003 で集めた情報の整理，その１．

チュートリアル：アスペクト指向ソフトウェア開発:

デザインパターンのうち，オブジェクト間の連携に関するものは AOP で書こう，というのを考えている人は多いらしい．

デザインパターンの典型的な実装問題として，継承ベースでの構築はアプリケーションの基本機能を再利用できない．（例: 一度 Observer にしちゃうと，再利用するときに Observer はいらないよーとは言えない）

しかし，継承でObserverを実装している場合のような，型の安全性を捨ててるように見受けられる，という意見もあったり．そんなことはないと思うのだが……．

挙げられていた参考文献はたいてい読んだことがあるものだった．

サブジェクト指向に関しては: Harrison, W., Ossher, H. (IBM)Subject-Oriented Programming- A Critique of Pure Objects, Proceedings of OOPSLA 93

ロールモデルに関して： ロール実現に使う基本的な手法 Kendall, E.:Role Model Designs and Implementations with Aspect-Oriented Programming, OOPSLA 99

アスペクトでメンバを導入したりして実現するテクニック集

Katara, M. "Architectural Views of Aspects", AOSD2003

アスペクトの観点からアーキテクチャを設計 -- ロールベースのアイディア aspect architecture == view type の一種，アーキテクチャを設計するための要素とその間の関係を定義.

Aspect-Oriented Design: 設計のレベルでアスペクトを使う，-- ウィーブを設計レベルで，あるいは言語で，というように選択肢はあるらしい．

_ カード ▲

宿泊予定のホテル (Scandic Hotel Grand Marina, Helsinki) で使えるカードの種類のリストが，日本語のどこかの Web ページで JCB 不可，英語のもので可能と書かれていて，しかも他の系列ホテルは（日本語のドキュメントでも）可能となっていたので，いちおう聞いてみたら使えますよ，と返事が来た．日本語のドキュメントもホテルの紹介リストで，量産っぽかったので，データ書く人がたまたま書き間違えたのかもしれない．

_ Bookmark ▲

Libretto 用に作ったブックマーク管理ツールを，そろそろ使わなくなってしまったのでソースだけ公開して凍結．

_ FSE ▲

FSE はなぜシングルトラックなんだろう，と思っていたら先生に「それが売りの会議だから」と言われた．

あまり関連のない分野の話も聞いてみる機会という意味ではいいのかも．シングルトラック→論文発表可能数が少ない→競争率が上がる→論文の質も上がるはず．FSE のほうが ICSE よりも引用したくなる論文が多い気がするのも，そのせいだろうか？

_ スライス ▲

研究用に作ったツールだが，「公開するもしないも好きにしていいよ」と先生から言われたので，もうしばらく refine してから公開も考えることにする．

_ IWPSE ▲

発練も一段落して，スライドの最後の調整中．

_ AspectJ ▲

最近カウンタの進みが速い．やっぱり aosd-jp で紹介されたからだろうか？

まあ，いいサイトだよって紹介されるような内容になっているらしいので，まだまだ頑張っていこうという気にもなれる．

_ イース ▲

昔，ソフトのおまけか何かでもらったDVD版 イース「天空の神殿」観賞．見ないまま何年か放置してた気がする．

原作をがんばって120分に縮めました，という感じで原作知らないと耐えられないようは気はするけど．

まあ，暇つぶしにはなった．

_ AspectJ ▲

AspectJ 1.1 での intertype declaration の微妙な変化のことをドキュメントに追加．まだ Introduction という表現になったままだったので，Introduction -> intertype declaration に修正．

_ AspectJ ▲

aosd-discuss ML にて，Obliviousness Principle in Aspect-Orientedというスレッドで，

Join Point というのはアプリケーション拡張のためのインタフェースの一つで，最終的なシステムがちゃんと動作するためには，クラスに private, public というアクセス制御があるように，Join Point にも何らかのアクセス制御が必要なのではないだろうか？（オブジェクトがアスペクトに「侵入」されるのを防ぐ方法などもあってもよいのではないか）

という話が出ていた．でも，過去の議論によれば，

「ソースコードを変更しないでね」と宣言するようなメカニズムを作ることは可能だが，実際にそれでよいのかというのは疑問．「予期せぬ変更」はAOSDの裏にある問題でもある．結局，明示したとして，「意識的な変更」を妨害することはできても，予期せぬ変更を防ぐことはできない．

……ということで，あっさり流された感じがする．

_ AspectJ ▲

inter-type declaration は，AspectJ 1.1 では特定のクラスに宣言はできても Object (A||B).hoge; のように複数宣言することはできなくなったらしい．

_ ワイン ▲

通販で，ボルドーの６大シャトーのヴィンテージワインが６ヶ月間，月１本ずつ届くサービスがあるらしい．個別で探す手間を考えると，１ヶ月あたり23,000円で悪くない金額ではあるのだが，もうちょっと手ごろな値段のワインを探したいところ．

_ JML ▲

Java Modeling Language 関連の論文を調べるべく，JML の公式サイトから論文を手当たり次第ダウンロード．出張中に消化できたらいいなぁ，くらいに考えておく．http://www.cs.iastate.edu/~leavens/JML.html

_ IWPSE/FSE ▲

＠Helsinki ２日目．ホテルに無線LANがあることが分かったのでホテルで15EUR/24h を支払って認証コードをもらう．

電話が 2EUR/分 なので，ダイヤルアップするよりははるかに得．せっかくモジュラーケーブルとかローミングサービスとか使えるように用意しておいたのだが，電話が高すぎて使えなかった．