netail.net

_ [近況] WheelPad.exe がメモリをやたらと消費する ▲

AOSD 2008 の参加途中に気づいたのですが，Let's Note R7 の WheelPad.exe がやたらとメモリを消費します．

設定ダイアログでスクロール機能などほとんどすべてのオプションをオフにしているので，こいつは何もしてないはずなんですが，タッチパッドを操作すればするほど，メモリ消費量が徐々に増えていく感じです．

プロセス再起動すればメモリは解放されるので，実害はまったくないですが不思議な挙動です．

_ [近況][VolumeDeskbar] 月刊I/O ５月号をいただきました ▲

VolumeDeskbar が付属CD-ROMに収録されたので見本誌として５月号をいただきました．自分が知ってる雑誌に掲載されると，やはり嬉しいものです．

VolumeDeskbar は64ビット版対応を考えたら，やっぱり Visual Studio でコードを書き直したほうがいいのかという気がしてきたので，再び実験中です．サンプルの Deskband の実装すら64ビット版構成でコンパイルが通せてない（ヘッダの途中でエラーが出てしまう）ので，若干挫折気味．

_ [読書] 計算モデルの本 ▲

コンピュータプログラミングの概念・技法・モデルの日本語版(wikipediaのページ)のうち興味があったところだけ拾い読みしてみました．

計算モデル，言語の意味（操作的意味とか）について，関数型，OOP，論理型，制約プログラミング，並列計算など幅広く日本語で解説が読めます．私の場合は，意味論まわりの知識が不足気味だった（関連書籍も持っていなかった）ので，ちょうど役立ちそうな本を手に入れたという印象です．

章構成はプログラミング言語の概念にしたがっているので，「大規模プログラムの設計」みたいなソフトウェア工学のトピックは6.7節とか，7章の一部にこっそり埋まっています．リファクタリングやデザインパターン，契約による設計などについても，そのあたりで言及があります（別にすごいことが書いてあるわけではありませんが）．

事前知識としていくらかの概念を知っているとき，たとえば抽象データ型，コンポーネントベースプログラミング，オブジェクトについて，違いは何だろうか，みたいなことを調べたいときには良さげな本だと思います．

_ [論文] データの来歴を分析する ▲

久しぶりに研究関連の話題です．正確には論文じゃなくて CACM の記事ですが．

Luc Moreau et al.: The Provenance of Electronic Data. CACM, Vol.51, No.4, pp.52-58, April 2008. [ACM DL]

Provenance というのは，芸術作品や考古学などで登場する 品物の由来，来歴の意味で， たとえば絵画では，誰がいつ描いて，途中で誰が修復したか， といった情報らしいです． 電子データでも，そのデータがどうやって作られたか（誰が書いたか，どんな元データを使って作ったか，など），誰が所有していたか，などのデータを残すことで，そのデータを安心して使えるだろう，というのが記事の趣旨になります．

来歴データは，SOA システム上で記録するとしたら， サービスの状態，使用しているアルゴリズムなどへの言及や， メッセージの処理順序や時刻，関連についての情報などだと考えられます． そして，たとえばあるメッセージが，別のメッセージへの返信である， 別のメッセージのデータを元に計算されたデータである（M2 = f1(M1)）といった 関係を， "is-caused-by"，"is-response-to" という原因を意味する辺や "is-based-on", "is-justified-by" というデータ依存辺によって， 循環なし有向グラフで表現することができる，と述べています．

データの来歴の使い方については， 記事では病院での医療情報や，科学系の大規模シミュレーションの パラメータや計算プロセスなどの来歴を題材にしています． メーラでよくある「転送済み」「返信済み」みたいなフラグも， 派生データの存在を示すという意味で，来歴の一種かもしれません．

ソフトウェア工学だと，ソフトウェア・タグに話としては似ているし， もっと粒度の小さい履歴を記録しようという人たち （開発者の統合開発環境での振舞いを記録するアプローチとか） にとっても参考になる記事なのではないかと思います． また，「このデータはこういう方法で計算されたよ」という計算 過程を示すという意味では， JAIST の方々の法令工学でやりたいことの1つにも 関連してるかもしれません．

_ [Java] ファイルの一部だけ読む Reader ▲

既存のファイル処理コードに対して，手持ちファイルの一部だけをさも独立したファイルであるかのように読ませたかったので，あやしい Readerクラスを作成してみました．

このオブジェクトは，引数として与えられた Reader から，引数 pBegin バイト目から pEnd-1 バイト目までを読みます．long 値のオーバーフロー対策以外には特に工夫はありません．「読みすぎた分は単に捨てる」方式なので，元となった Reader が pEnd バイト目から続きを読めることも保証しません．

public class FileRangeReader extends Reader {
  private Reader r;
  private long size;   // どこまで読むか
  private long offset; // どこまで読んだか
  
  public FileRangeReader(Reader reader, long pBegin, long pEnd)
    throws IOException {
    r = reader;
    r.skip(pBegin);
    size = pEnd - pBegin;
    offset = 0;
  }
  @Override
  public void close() throws IOException {
    r.close();
  }
  @Override
  public int read(char[] buf, int off, int len) throws IOException {
    if (size == offset) return -1;
    int bytes = r.read(buf, off, len);
    if (offset > size - bytes) { // == offset + bytes > size.
      bytes = (int)(size - offset);
    }
    offset += bytes;
    return bytes;
  }
}

2個以上のReaderの中身をさも連続したストリームであるかのように読み込むReaderなんかも，上記のコードと同様に簡単に作成できるので，Decorator パターンはやっぱり強力だなと思います．良い設計かどうかはともかく，既存コードの変更量がとにかく少ない，というのがありがたいところです．

(追記: 2008/9/8) Reader は char 配列を読み込むため，ストリームのデータの中身を確認する必要があり，大量のデータを読み飛ばすには問題があるようです．InputStream をベースに同様のコードを作れば，byte単位で処理できるので，かなり高速になります．