netail.net

_ 学祭 ▲

学祭１日目が無事終了．寒かった上にあちこち歩き回ったのでけっこう疲れた．デジカメで色々取った写真の整理をして，web にアップするための準備をする．

_ 学祭 ▲

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

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

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

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

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

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

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

_ 廃盤.net ▲

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

_ Explzh ▲

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

_ [論文] デバッグ用のスクリプト ▲

Guillaume Marceau, Gregory H. Cooper, Shriram Krishnamurthi, Steven P. Reiss:A Dataflow Language for Scriptable Debugging. Proceedings of ASE 2004, pp.218-227.

なんでデータフロー言語という名前が付いてるのだろう，というのがふと気になって前に読んだのをもう一度読み直した．

FrTimeという scheme 系の言語でプログラムの状態を監視し，制約検査を行うのだが，FrTime は，プログラム内部の状態変数に対して， その値を常に反映するような変数を定義することができるらしい（AspectJのargsやthisなどはその時点での値にアクセスできるだけなので，だいぶ意味合いが違う）．で，この変数を使うと，プログラムの状態を常に反映した条件式が書けるので，プログラムが何らかの制約違反を起こした場合に即座に検知することができる．

"dataflow language" というのは，プログラム中のデータが，検査式に直接接続されているという意味合いで，他の言語などで，情報集めのための文をあちこちに埋め込む必要がなくて嬉しい，とかいう話らしい．

_ [論文]プログラム中の実行パスの表現 ▲

B. Bruegge and P. Hibbard. Generalized path expressions: A high level debugging mechanism.

In Proceedings of the ACM SIGSOFT/SIGPLAN Software Engineering Symposium on High-level Debugging, pages 34-44, 1983.

プログラムのパスを正規表現に近い形で記述し，そのとおりにプログラムが動いているかどうかをテストする． 呼び出されうるメソッドの列なんかを正規表現とかオートマトンとかで書くこと自体は（今となっては）そんなに珍しくないのだが，これはwhile文とかまで記述対象にできるところが面白い．

CHECKPATH Loop {WhlleLoop[ACT(Whileloop) < 6] | PlaceLines}

という記述を行うと，PlaceLinesメソッドが呼ばれるまでは while 文のループが６回以上起きてはいけない，とかいった条件になる．検出する条件自体はブレークポイントのループカウント＋条件付ブレークポイントで普通に実現可能な機能かもしれないが，記法は何かに使えるかも？

_ スタイルシートをちょっとだけ変更 ▲

zaurus搭載のNetFrontからだとページが崩れていたので，修正．サイドバーがポジショニングのabsoluteで右側に固定されていたのを，floating を使って本文を左側に，サイドバーを右側に移動するようにした．

_ [論文] アスペクトを使ってアーキテクチャのプロトタイピング ▲

Ingolf H. Krueger, Reena Mathew, Michael Meisinger: Efficient Exploration of Service-Oriented Architectures using Aspects.

Proceedings of ICSE 2006, pp.62-71.

あまり詳しくは読みきってないけど，アイディアが面白かった論文．

目的は複数のアーキテクチャ候補の比較評価．シーケンス図やロールモデル，コンポーネントのマッピングを記述して，それらに基づいてアスペクト（AspectJ ソース）を生成し，プログラムとして実行することで性能の試算などを行おうというもの．

アーキテクチャごとに，コンポーネントがどう接続されるか，どう相互作用するかという部分をシーケンス図やロールモデルで記述する． 登場する個々のエンティティは，比較的単純にクラスとしてマッピングすることができる（と思う）．

シーケンス図に書かれたメッセージ列は，「C1.A の実行が終わったあとに C2.B を実行する」というように解釈すれば，機械的にafter(): execution(C1.A) { C2.B; } のようなアドバイスに変換できる．

また，ロールドメインモデルで，「Manager は Broadcaster にアクセスする必要がある」と書いてあったらインタータイプ宣言を使って Manager に Broadcast 型の変数と setter/getter を作成することができる．

クラスとアスペクトを一通り生成したら，あとは weaver に任せてコンパイルを通し，実行して評価するだけ．従来だと，シーケンス図に登場する各クラスに相互のメソッド呼び出し用のコードを適切な順序に並べて埋め込んでいくとかいった手間のかかっていた部分が，ほとんど weaver 任せになっている．

生成されたコードはえらいことになる気がするけれど，保守するわけではないので問題なし．

アスペクトだけでコードを書くと「アスペクトが全部の処理を接続して，クラスはデータ構造を宣言するだけになる」というのは想像したことはあったけれど，そういうコードを生成してプロトタイピング的に使ってしまおう，という考え方にはすごく感心してしまった．