netail.net

_ [Java] String.intern の簡易版を作ってみた ▲

開発中の某システムで，同じ文字列がたくさん含まれたファイルをストリームから読み出すとき，文字列が各行ごとに個別にインスタンスが確保されてしまうので，HashMap を使って単一インスタンスに置換するようにしてみた．

実装は次の通り．すごく適当．

private static Map stringTable = new HashMap();
public static String toSingletonString(String s) {
  if (stringTable.containsKey(s)) {
    return (String)stringTable.get(s);
  } else {
    stringTable.put(s, s);
    return s;
  }
}

しかし，こんなものでも，ストリームから読み込んでいる文字列のインスタンス数が少なく見積もって50万〜，互いに異なる文字列が数万と推定される環境で，フットプリントが1.3GB→1.0GBと減少．手間のわりには効果があって満足です．

_ [近況] 雪が降りました． ▲

冬の滞在先は温暖な地域にしておけば良かった，と少し思わなくはないです．

しかし，研究の参考文献としてリストアップした良さげな論文は全部UBCの関係者（既に他所へ行った人含む）のものだったので，ここを選んで正解ではあったと思います．

_ [hyCalendar] 1.5βから1.5リリースの差分（予定） ▲

ご意見をくださった皆様，ありがとうございました．

日付カウントダウン機能について，以下の３点を実装中です．来週ないし再来週には出せるんではないかと思います．

(1)「誕生日まであと10日」のように，日付／周期予定に対して別名を指定するオプションを追加します．

(2)指定した日を過ぎたら自動で翌年の同じ日までの日数を出すオプションを追加します．

(3)編集方法が少し変わります．現在は項目を設定して「追加」ボタンを押す形ですが，これからは「新規」ボタンを押すとアイテム追加，項目の情報を操作すると即座に反映（保存などのボタンなし）となります．

_ ゲーム検定の結果 ▲

ゲーム検定 (日経エンタテインメント)なんてのを教えられたので，試してみました．

けっこう難しかったです．ハードウェアに関する知識が多いのは，ベーマガがマイナーなものまで幅広くカバーしていた影響です．たぶん．

（得点表の横の xx/yy という実際のスコアは，自動出力ではなく，後から手で追加したものです．）

あなたの総合得点は64点　　全国平均　54点
 
全国順位（11月24日 4時現在）
9560位（57197人中）
 
−−ジャンル別得点表−−−−−−−−−−−−
　　　　　　　　　　　　０＿＿＿＿＿＿＿＿＿50＿＿＿＿＿＿＿＿＿＿100％
ハードウェア　　　　　　　■■■■■■■■■■■■■■■■　13/16
ゲームシステム＆テクニック■■■■■■■■■■■　　　　　　16/28
キャラクター　　　　　　　■■■■■■■■■■■■■　　　　10/15
ビジネス　　　　　　　　　■■■■■■■■■■■■　　　　　16/26
雑学　　　　　　　　　　　■■■■■■■■■■■■　　　　　 9/15
−−−−−−−−−−−−−−−−−−−−−−−−−−
 
あなたは「ゲーム大臣」
これだけの知識があれば、たいていのゲーム好きの人間とは
楽しく会話ができるはず。しかし、この先、もっと深く広い
知識を得ることで、世界はさらに広がるだろう。
 
貴方がもっとも詳しいゲームのジャンル：
　　　ハードウェア
貴方がもっとも詳しいゲームの年代：
　　　90年代前半を中心としたゲーム発展期

_ PSP ぽいことをはじめてみる ▲

PSPといっても，ゲーム機じゃなくて Personal Software Process のほうです．

コード書きや，論文の執筆とか他人の原稿のチェックとかにどのくらい時間を使っているのか，少し見積もりができるようになってみようと思って，作業時間を記録してみることにしました．

時間記録・管理の支援ツールとかもあってもよさそうなんですが，これといったものが見つからなかったので，計測用タイマーは普通の時計で，記録は Excel にしました．

「どのくらい作業ができたか」を記録する実績値は，論文の場合，とりあえず２段組でのページ数にしてみます．

_ [論文] プログラムの条件分岐を無理やり変更してデバッグ ▲

Xiangyu Zhang, Neelam Gupta, Rajiv Gupta: Locating Faults Through Automated Predicate Switching.

ICSE 2006, pp.272-281.

プログラム実行中のある時点でデータに誤りが発生した場合，それはそこまでの実行経路に問題がある．直前ないし近い位置の分岐で別方向に進んでいたらプログラムはうまく動いていたかもしれない．だから，そういう条件分岐（"critical predicate"）がもしあるのなら自動的に見つけよう，という論文です．

critical predicate が見つかれば，入力変数から critical predicate を経由して誤った変数値に到達するまでの経路の chopping を計算することで，バグの位置を普通のスライシングよりも絞れるだろうという見込みがあったりします．

方法自体はわりと単純で，動的解析でどの条件分岐を何回どちらに進んだかを記録しておき，コード書き換え技術を使って「このif文を20回目に通過するときは必ずTRUEだとみなす」というような細工を施してプログラムを再実行するというものです．どの条件分岐を変更するか，という選び方を工夫してます．

実験結果では，それなりに critical predicate を発見できていて（発見できないケースもあり），その結果を使って計算したスライスのサイズも小さくなっている，という評価を行っています．「デバッグの手間」というのは計測しにくいので，普通に計算したスライスのサイズと，critical predicate が分かっている場合のスライスのサイズを比較することで，開発者が調査するであろうコード量を比べています．

この手法は，ひたすらプログラムを再実行するという力技で，面白いやり方だなーと思います．特定の条件分岐を中身を気にせず強制変更するので，無造作にデータ構造を壊したりしないのか，という点は多少気になります．

_ [読書][AspectJ] ユースケースがアスペクトになる ▲

Aspect-Oriented Software Development with Use Cases という本が ACM の Online Books プログラムの無料で読める範囲に入ってたので読んでみたら，そういう記述があった．

ユースケースのシナリオを書いていくと，シナリオのうち特別なケースでのみ実行される alternate flow や，定義済みのシナリオを拡張する extends 関係が登場してくるが，これらは複数のクラスに影響を与えるので，クラスを拡張するアスペクトとして表現するほうが良い，と解説していた．（アスペクトが使えることを強く意識したシナリオの書き方になっているような気もする．）

ユースケースは，それに対応する「ユースケーススライス」というモジュールとして実現できる．ユースケース固有のクラスはそのままクラスとしておけるが，他のクラスを拡張する部分はアスペクトとしてインタータイプ宣言ないしポイントカット＋アドバイス表現を用いて記述する．これによって，特定のユースケースに関するコードを他のユースケース用のコードから独立したままに保つ．

異なるユースケースに所属するコードを分離したままで管理するために，ユースケース固有のコードを，それぞれ独立した（ユースケース名を付けた）ディレクトリに配置してしまおう，とも言及されていた．Eclipse では，コンパイル対象のソースコードが入ったディレクトリを指定することができるが，そこで各ユースケースのディレクトリを列挙すれば良いらしい．

非機能的要求も，できるだけ infrastructure use case としてシステム側の振る舞いを記述し，普通のユースケース（application use case）との関係を整理しておくらしい．そうすることで，システムのサービスを担うアスペクトなんかも設計時にきちんと扱うことができる．

別々に記述したものはそのまま混ぜずに置いておくという一貫した方針になっているので，けっこう読みやすい本だと思う．そのかわり，ユースケースとコードの中間（分析モデルとか）については扱いが小さい気がした．

(追記) この本，日本語訳が出てますね．まったく気づいてませんでした．

_ [論文] AOP でのミドルウェア構築についての講演 ▲

Charles Zhang という Aspect-Oriented Middleware をやってる人が喋りに来たのを聞いてきた．

ミドルウェアが含んでいる feature 間の相互作用部分をアスペクトに追い出して保守性を向上するという話で，そのためにマイニング環境 Prism と，変更後のコードレベル検証ツール ARV を構築し，リファクタリングを行ったらしい．

調査した結果によると，ミドルウェアに含まれていた６個のfeatureのうち50％ぐらいのモジュールは１つのfeature としか関連しないが，10％ちょっとのモジュールは３つ以上のfeatureと相互作用していて，コードの変更などを難しくしていた，と言っていた．一般化できる結果ではないと思うけれど，少数のモジュールが全体の保守性を悪化させているみたい．

そういうリファクタリングの結果，ミドルウェアの様々な feature がアスペクトとして分離される．それらを使って，アプリケーションのコンパイル時にどの feature が使われているかを調べ，必要な feature だけを取り込んだミドルウェアの configuration を生成する，なんてことも研究しているらしい．

feature が他のどの feature に依存するか，また同時に使用できない feature の存在はきちんと記述して与えないといけない．feature を実装する側がそれなりに（高価かどうかは良く分からない）コストを支払えば，使う側はかなり楽をできそうな仕組みに聞こえた．feature-oriented なアスペクトの使い方としてはけっこう面白いと思う．