netail.net

_ 学祭 ▲

RPG研のOB会があるので，学祭に出かける．

今回の発見は，ジャムうどん．食べたのはイチゴ（マーマレードもあった)．

外見はこんな感じ．梅肉と言われたらわからないかも？ジャムうどん写真

混ぜるとこんな感じ．果肉の部分は適度に分散したり沈殿してたりします．種が一見すると七味唐辛子とかに見えるかも．ジャムうどん写真２

まあ，ちゃんと売ってる当人たちも試食したことがあるみたいなのでOK(?)．

５人ほどで食べた結果の感想は次のとおり．・甘い果肉とだし汁のミスマッチがひどい・かまぼこが最低・麺自体は普通に食べられる・ジャムのべたつき感がとろろ昆布を入れたときの感じに近い・においが微妙

まあ，なかなかチャレンジングな食べ物を販売していて「たいやきそば」以来の当たりかも．

_ 廃盤.net ▲

廃盤になった曲を販売するなんてのがとうとう商売になってきたんだなーと感心．曲数が少ないから厳しい気はするけど，過去の曲が大量ダウンロードされるとは考えにくいので，サーバの負荷対策も新曲を扱うのに比べれば楽そうだし，過去の資産を無駄にしないという意味でも悪くないビジネスかもしれない．http://www.haiban.net/

_ Explzh ▲

すっかり愛用になってしまった Explzh の4.00 がリリースされた．3.99 の次は 3.100 だと思っていたのに……．

_ 論文 ▲

軽く読み流した論文２本．

Marek Majkut, Bogdan Franczyk:Generation of Implementations for the Model Driven Architecturewith Syntactic Unit Trees

Syntactic Unit Trees というのは，ソースコード片などをノードとするようなツリーのこと．ノードいくつかで上位のノードを構成する．XVCL などが近い．

MDA でソースコードを生成するとき，プラットフォーム依存/非依存モデルに適当な情報を加えてツリーノードに対応付けることでソース生成するというもの．他のテンプレートやフレームといった手法よりは簡単である，と筆者らは主張している．

David Oglesby, Kirk Schloegel, Eric Engstrom:Cross-aspect Queries and Dynamic Views for Model-based Development

モデル図が複雑になってきた場合に，クエリーを発行してフィルタした「Dynamic view」を作って図を分割しよう，という話．例として，オブジェクト名と接続関係に対するパターンマッチを使っている．たとえば "Sensor" と "Timer" の両方が絡むのは，とかいったクエリーになる．これ自体は特別新しい試みではないような気がする(grep などの延長に近い)が，実際に作った人っていうのはいなさそうなので楽しみではある．

_ Guevara ▲

Guevara Terminal Emulator をインストール．.NET Framework が必要だったので，バックアップを一式取ってから Framework をインストール．バックアップ取ったついでに Norton Internet Security を2004 に上げておいた．

_ IPADIC ▲

OUCC の学祭で使う文章合成用に名詞・形容詞・副詞などをipadic から抜き出す．正規表現は適当に書いた

[^(]*\([^(]*\([^(]*\([^(]*\([^(]*\(([^ ]+)

とかいうのを使って取り出してみた．一部，それでは抜き出せないようだが，だいたい通ったのでよしとする．

# 本当は働き手のはずの３年生がいないのでけっこう大変そうではあるが．

_ AspectJ ▲

Prof. Laurie Hendren から，AspectJ のベンチマークとしてツールを使ってみたいんだけどだめかな？という連絡が来た．

オックスフォードって ox.ac.uk なんだなーと感心しつつ返事は保留．

_ MERP ▲

Web に公開していた情報をたぐって，Mr. Duckworth という人からメールをもらった．「MERP を日本でも遊んでる人がいるのね．もしよかったら東京近辺で遊ぶような人いないっすか」という感じ．で「とりあえず，そういう知り合いがいそうな人に転送しといたよ」と返事をしたら，「ありがとう．機会があれば色々話をしてみたい」とか返事が返ってきた．うーむ．

_ 学祭 ▲

微妙に働いている人を手伝う．１年生でまじめにびしびしと仕切ってくれる人がいるのは頼もしい限りだけど，負荷をもう少し分散しないと効率が悪そげ．

_ バトルテック ▲

久しぶりに遊んだはいいけど，やっぱり細かいところでルールをいくつか間違えていることが判明．

ルールをもうちょっと整理したレジュメ作ろうかなぁ．初級/中級/上級ルールに分解されていて微妙に参照しにくい．徐々に拡張されていく様子はクラスの継承に近い気もするが，順番に学習していく場合はいいけどいきなり上級ルールに取り込まれている「射撃ルール」というアスペクトを把握したい場合は使いにくい??

_ Vector ▲

hyCalendar の登録申請をした．

_ Calendar ▲

ひっそりと hyCalendar 0.4.5 リリース．ちょっと描画部分を直しただけ．

_ ReaD ▲

日本科学技術振興機構から調査票が届いた．実は誰がどこの所属とか全部管理されているらしい．http://read.jst.go.jp/

このサイト，技術系英語辞書を強化した機械翻訳とかも付いてる．どのくらい強いのかは知らないが．

_ 論文 ▲

Elissa Newmann and William L. Scherlis:Toward Query-based Constraints

Concern を探すのにsemantic なクエリーを使えるFEAT というツールの話をしている．FEAT そのものの話は ICSE にも出ていた．

この論文での制約というのは「このクラスのサブクラスはこれらのただ二つだけ」とか「このメソッドを呼びたいなら lock をしておけ」とかいう感じの制約のこと．

concern をモデルから取り出して，それらをクエリーによって定義して，concern 間の結合度や合成の制約をクエリーの与える制約によって調べたりできる……のかなぁ．これ自体は Position Paper だったので，素直に FEAT の論文を読んだほうがよさそう．

_ 論文 ▲

Sergei Kojarski, Karl Lieberherr, David H. Lorenz, Robert Hirschfeld:Aspectual ReflectionAOSD 2003 SPLAT Workshop

アスペクトのアプローチとリフレクションを分類した論文．Core Reflection Mechanism と Aspectual Reflection Mechanism を区分けしている．

Core Reflection == メソッド名などの構造的要素Aspectual Reflection == Join Points のような時系列的な要素

主なグループ分けとしては

Smalltak = CRM で実装されたリフレクションインタフェース RI^RAspectS = CRM で実装されたアスペクトインタフェース RI^AAspectJ = ARM で実装されたアスペクトインタフェース AI^ARaspect = ARM で実装されたリフレクションインタフェース I^R

と対応付けている（厳密には AspectJ ではリフレクションが使えたりするので RI^R な側面も持っていることも述べられている）．

_ 論文 ▲

Jeff Gray, Ted Bapty, Sandeep Neema, James Tuck:Handling Crosscutting Constraints inDomain-Specific Modeling

SPLAT2003あたりに出ていた論文．GPCE に出ていたのと同じで，モデルの制約記述をモデルと独立に書いておいてWeaver を使って結合する．基本は XML ベースで結合処理を行う様子．Meta-Weaver Framework からDomain-Specific な Weaver のインスタンスを生成するとか言っている．

_ 論文 ▲

Gary T. Leavens and Yoonsik CheonDesign by Contract with JML

論文というよりは JML の紹介原稿というべきか．

JML の良い点:invariants にも可視性がある． "public" 宣言しない限り，同一パッケージのクラスからしかその invariants は見えない．

representation invariants はクラスの外からは見えない．type invariants は見える．

ensures, signals で通常の終了，例外的終了を分けて書ける．

forall, sum, max, min といった述語が使える．

継承した場合は Liskov の置換原則を保持する．

モデル・フィールドを宣言することができ，実変数を対応付けることができる．同様に，モデルメソッド・モデルクラスを宣言することもできる．

_ ▲ JML の注意点:副作用を持たないメソッドについては不変条件の記述に使うことができるが，メソッドが副作用を持つかどうかを"pure" と自前で宣言しなくてはならない．（書けるだけマシなのだが）

_ 論文 ▲

aosd-discuss で，読んでみてくれーと流れていた論文．

Claudio Sant'Anna, Alessandro Garcia, Christina Chavez,Carlos Lucena, Arndt von Staa:On the Reuse and Maintenance of Aspect-Oriented Software:An Assessment Framework

アスペクト指向ソフトウェア用のメトリクスを提案している論文．

Separation of Concerns Metrics としてどのくらいのコンポーネントがひとつの concern に参加しているか，とかを数え上げている．また，結合度，凝集度，サイズを使っている．オブジェクト指向で書かれたソフトウェアでも同じものは測れるので，それを比較する形になっている．

品質モデルは Basili の GQM パラダイムがベース．実験では，OOとAOで同じシステムを設計して，メトリクス値を測る．システムにいくつかの変更を加えて，それに必要だった変更がどの程度か（いくつ Entity が変更されたか，など）というのをメトリクス値が示している性質と一貫した答えになっているかどうか，評価している様子．

_ 論文 ▲

Robert E. Filman, Daniel P. Friedman:Aspect-Oriented Programming is Quantification and Obliviousnessの続き．

実装上の問題として，スコープをどうするとか，本当に Obliviousness は達成できるのかとか，関連しあったアスペクト間の扱いをどうするのかとか，一貫性の問題は，とかが列挙されている．

アスペクト指向言語とは何なのか，ということも整理されている．・ルールベースのシステムとしてとらえる． しかし，対象プログラムがすべてルールベースだと AOP の議論はできない．・イベントベースの Publish/Subscribe モデルとしてとらえる． コンポーネント間がイベントで動作するモデルなら， Black-Box AOP として考えられる． プログラマが手動でイベントを生成しなければならないのなら， それは oblivious ではないので AOP ではない．・Intentional Programming / Meta-programming としてとらえる． それ自体を AOP というよりは，AOP の実現手段．・Generative Programming としてとらえる． これも AOP の実現手段． まとめ：・AOP の持つ，oblivious quantification というのは OOP とは独立の概念．・一箇所にしか登場しないものはアスペクトにしないほうがよい・より良い AOP システムは，より oblivious である．

_ 論文 ▲

Robert E. Filman, Daniel P. Friedman:Aspect-Oriented Programming is Quantification and ObliviousnessOOPSLA 2000 の論文らしい．

OOP までの概念では，特定のルール，たとえば「オブジェクトを移動させたらディスプレイをアップデートすること」といったルールをで実装するには，「クラスを継承したプログラマは super.foo をメソッドの終わりで呼ぶこと」といったプログラマが協調するためのルールを作る必要があった．

このようなルールが必要ないようにするのが "oblivious" で関連した文を選び出すことが "quantification" ということになる．

AOP でやりたいことは，In programs P, whenever condition C arises, perform action A.という条件ドリブンなプログラミングである．

Static Quantification はプログラムの構造上の情報で条件を定めるもの．特定のコンポーネントへのアクセスや特定のサブルーチン呼び出しをラップしたりする．アスペクトがどこまでベースプログラムの情報を使うかでBlack-Box AOP と Clear-Box AOP と分類している．Clear box はベースプログラムの中身を見るのでソースコード情報が必要だが，デバッグなどには適するし，しかし実装するのは難しい．Black-Box はインタフェースなどを基準に操作するので実装などは簡単だが使える範囲は限られてくる．

また，Dynamic Quantification としては，コールスタックのサイズであるとか，例外の発生や特定の実行パターンがある．

_ クレジット ▲

426USD の謎の請求．IWPSE は EUR で払ったはずだし……？でもどこかで見覚えがある，とひたすら研究室に置いた請求書やらの山を調べていたら，その正体は IWPSE の Reprint Order だった．うーむ．請求団体名の後ろに一言くらい添えられるような空間を用意しておいてほしい……．

_ Ruby ▲

サーバーの Ruby が 1.8 になったとたん，コンパイラの微妙な変化でエラーで落ちるようになってしまっていた．とりあえず式展開中のダブルクォートが怒られるようになったことが原因のようなのでそれだけ直した．

_ 論文 ▲

Curtis Clifton and Gary T. Leavens:Obliviousness, Modular Reasoning, andthe Behavioral Subtyping Analogy

これも出典はSPLAT2003．アスペクトが勝手にクラスを置き換えてBehavioral Subtyping を破壊することがあり，しかもクラスはこれに気づくことがない．（これはAspectJ の obliviousness であるという特徴）

しかし，実際には，それではプログラマは「１モジュールずつ理解する」ということができないので，このような Behavioral Subtyping を破壊するようなアスペクトについては "Assistants" と呼んで別扱いし，（破壊しないものは "Spectators" と呼ぶ）Assistants については明示的に取り扱いません？という論文．これ，出典は忘れたが前に同じ著者がどこかで出していた論文(or テクニカルレポート)と内容的には同じ．今後は Assistants を接続するような言語を作ったりしようか，とか言っている．

参考文献としてFilman and Friedman, Aspect-oriented programming is quantification and obliviousness (OOPSLA2000) を挙げている．http://ic.arc.nasa.gov/~filman/text/oif/aop-is.pdf

_ 論文 ▲

SPLAT2003 Workshop の論文を読む．Therapon Skotiniotis, Karl Lieberherr, David H. Lorenz:Aspect Instances and their Interactions

6ページ弱のショートペーパー．アスペクトを記述するときに，「あるクラスのインスタンスのみ」を指定しようとすると!call((Circle+ && !Circle).*) && call(Circle.*) といった記述になる．また，if(thisJoinPoint.getTarget().getName() == ...)といった式や aspectOf をうまく使おう，というテクニック紹介みたいな論文．

アスペクトのインスタンスを生成したり特定のオブジェクトに install したりするAspectS の設計は良さげだと思える，らしい．Dynamic Aspect なほうが柔軟なアスペクトの管理ができていいなぁ，ということなのかな？

_ hyCalendar ▲

期間予定のフォント設定機能を追加して，0.4.4 リリース．TODO リストの中身も一時期に比べると少なくなってきた．

それにしても，部室は学祭関連のプログラム構築で忙しい中関係ないプログラムを書いてるのも，ある意味申し訳ない気がする．それでも書くんだけど．