netail.net

_ [読書] オブジェクト指向設計は直観的？ ▲

CACM Vol.51 No.5の記事に，オブジェクト指向設計のときに使う用語の意味と，日常生活での常識的な感覚にずれがあるので，それがミスにつながる，という話が出てました．

たとえば，継承関係は「抽象クラスを継承して具象クラスを作る」のに対し，単語の使い方として「たくさんの財産，知識などを持ってる人から，それを継承する」という感覚があるため，うっかりメンバーの多い具象クラスからメンバーの少ないクラスを派生させようとしてしまう，というのが起こるようです．

まあ，「自然に考えられる」パラダイムであっても，直観に頼らずに落ち着いて考えましょう，という程度のことなのかもしれませんが．

_ ACM ICPC 国内予選の監督 ▲

監督を頼まれたので，やってきました．

参加したことがなかったので知りませんでしたが，時間制限があって，かつ Web での調べものが禁止されているので，必要になるツール（エディタ，コンパイラ，デバッガなど）を一通り迷わず使える，というのがけっこう大事っぽいみたいですね．

最近，コードを少し書いては動かしてその部分をテスト，というようにコーディングしてばかりなので，見てる範囲ではだいぶ新鮮でした．

_ [ツール][読書] USBファイアウォール ▲

IEEE Spectrum 2008 June p.23 に，Yoggie Gatekeeper Picoという製品の紹介が載ってました．ファイアウォールとアンチウィルスを実行する追加ハードウェアで，外とのコネクションをこいつ経由で張ることでシステムを保護すします．リソースを食うアンチウィルス系ソフトをデバイス側で実行してもらうことで，PC本体の処理を軽くする，というのが売りのようです．

Spectrumの記事では，アイディアは良いが，Vista がデバイスによって保護されていることを認識できないとか，ネットワークゲームを動かす場合にファイアウォールがうまく動作しなかったとか，パフォーマンスも期待したほどではなかった，と指摘されていたりもします．現状，モバイルPCを出先のネットワークにつなぐ場合には良さそうだとして，また「今後に期待」として締めくくられていました．

日本語だとExpressCard版 の紹介記事がありました．英語ではThinkComputersにレビューがあります．

_ [研究] 研究の前提ツール／知識リスト（仮） ▲

研究室に配属された人々の研究テーマに向けた準備もおおむね完了したので，翌年に備えて，研究関連で序盤に学習してもらいたい知識を整理中です．

• Java プログラミング：開発用の言語として，かつプログラム解析の対象として必要．付随して，バイトコードと仮想マシンの概念など．慣れてない人には練習用の課題をやってもらう．
• Eclipse：Javaでコードを書くなら必須．最近はプログラミング演習の授業でも使っていたりするので，学科内では普及率上昇中（使ったことを覚えていてくれれば……）．
• CVSあるいはSVN：バージョン管理ツールが使えないと，既存の開発リソースにアクセスできない．SVNならクライアントはTortoiseSVNとかSubclipseあたりで．
• SSH：使えると何かと便利．TortoiseSVN で SSH+SVN とか使うならputty形式の鍵生成が必要だというのもあったりする．
• ネットワーク上でのファイル共有：研究室でのディレクトリ構成についての知識を含む．
• メールを研究室外から読む方法：転送，SSH，VPN等によって自宅や出先で問い合わせメールが読める方法．突発的なイベントが発生したときに何かと便利（読める＝休日に反応するとは限らない）．

プログラミングについては，やはり作業時間を多く取られるので，「紳士たるもの○○くらい使えなくては」（○○は任意のプログラミング言語．ML，C++，Ruby，COBOLなどお好みで）と言いながらコードを読み書きできるような人のほうが，研究の道具立てという面では有利だと思います．そんな人は（研究室配属の段階では）あまりいませんけど．

_ [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単位で処理できるので，かなり高速になります．

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

久しぶりに研究関連の話題です．正確には論文じゃなくて 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つにも 関連してるかもしれません．

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

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

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

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

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