netail.net

_ 読書 ▲

Deborah G. Johnson著，水谷 雅彦，江口 聡 監訳「コンピュータ倫理学」読了．

道徳と法律，記述的な話と規範的な話の切り分けなど，判断基準に関する示唆をたくさん含んでいる本．文字ばかりなので読むのは疲れたが，それなりの知識は手に入った，と思う．暇があったら何度か読み返したほうがよいかもしれない．

_ 論文 ▲

先ほどのつづき，関連研究だけ別に整理．この量はさすが TSE というべきか．

関連研究としては，Wilde, Scully らによるSoftware Reconnaissance での機能の分類法で・f が実行されるされないに関わらず実行されるもの・f が実行されるときに実行されることがあるもの・f が実行されるときは必ず実行されるもの・f が実行されるときは必ずかつそのときのみ実行されるものというような分類があるらしい．

また，静的情報を使う系統ではChen, Rajlich らによるCase Study of Feature Location Using Dependence Graph (IWPC95) というのが，ソースコードをグラフに抽象化するアプローチらしい．ただし，この論文の筆者らは，「どこから探していいか分かってないときには　この手法は向かない」としている．

Concept Analysis の活用についてはSiff and Repse: Identifying Module via Concept Analysis,Deursen and Kuipers:Identifying Objects using Cluster and Concept Analysisなど．

表示関係ではKoskimies and Mossenbock: Schenario-Based Browsing of Object-Oriented Systems with Scene.Lange and Nakamura: Program Explorer: A Program Visualizer for C++.Lange and Nakamura: Object-Oriented Program Tracing and Visualization.などが挙げられている．

_ [論文]Concept Analysis による機能の実装位置特定 ▲

Thomas Eisenbarth, Rainer Koschke, and Daniel Simon, Locating Features in Source Code, IEEE Transactions on Software Engineering, Vol. 29, No. 3, pp.210-224, March, 2003.

「ある機能を実行するテストケース」を実行して，各機能に対してどのユニット（関数 or クラスなど）が実行されたかを実行履歴から取得し，その結果に Concept Analysis を行うというもの．Concept Analysis を行うことで特定の機能に固有なもの，共有されているもの，といった情報が手に入るので，それと静的な関係図をもとに開発者が手動で Feature-Code マッピングを作成する．

「何をテストしているのか」という知識などが多少必要になること，最終的な分類は人手に頼ること，などが少し弱いといえば弱いが，それなりの結果は出ているようだし，アプローチも面白い．

ケーススタディにおけるルーチン間の接続などを見ると，相互に密な結合をしている部分とばらばらの部分があったりして，プログラムによってはかなり分類ができる可能性が分かる．

Concept Analysis 自体は学習も容易で便利だが，手続きなどを単位とするとConcept Lattice が大きくなってしまい作業しづらくなる，といった弱点はあるよう．

また，テストケースの選び方による偏りが生じるので，プログラム保守のタイミングなどで，「ここを直すのが一番影響が少ない」とかいったことを調べるにはこの手法は対応していない．（あくまで特定の機能がどこにあるかを理解することが目的で，　そのユニットが他の機能に関わるかどうかまでは考えない）

_ 学祭 ▲

洗って再利用する，リターナブル皿が推奨されているのは分かるのだけど，なぜ returnable なんだろう．reusable とかじゃない不思議．

_ 論文 ▲

Joel Winstead and David Evans:Towards Differential Program Analysis.Workshop on Dynamic Analysis. 9 May 2003.

プログラムの差分（主にバージョン間差分）を認識するタイプの解析方法が重要だ，という立場の position paper．

この筆者たちは，ふたつのプログラムの実行結果が変わるようなテストケースを見つけることが大事だろう，と言っていて，プログラム変更箇所から入力パラメータなどを simulated annealing など経験的手法で生成していく方法について紹介している．

生成した入力パラメータを使って実行してみて，評価として条件式の true/false を変えるような値に近いほうが優れている，とするらしい．いちおう小さな実験結果が載っていて，この判定基準を使うかどうかで，差分が分かるような入力セットを見つけられるかどうかの試行回数を大きく削減できるらしい．（300万回かかっても７割くらいの確率でしか見つからないものが　70万回くらいで発見できている）

……とはいえ，小さな手続き１個が相手で試行が70万回というのは多いか少ないかは意見が分かれそうだが，自動デバッグな世界の人らしい考え方な気はする．

_ Download ASCII ▲

サービス停止，のはずだった Download ASCII だが，サービス移管されるらしい．

移行先はシーサー株式会社．オンラインショッピング＆ブログサービスらしい．http://shop.seesaa.jp/

_ 論文 ▲

Rainer Koschke: Software Visualization for Reverse Engineering.Software Visualization, LNCS 2269, pp.151-162, 2002.

ソフトウェア可視化に関する Survey か Position Paper ．Software Visualization はソフトウェアを他の（グラフィカルな）表現にマッピングすることであるが，その方法として代表的なものにグラフとハイパーリンクがあり，特にグラフはほとんどの既存研究で使われている．

ところが，関数などを単位としたグラフを作ると高々５万行程度でも辺や頂点の数が5000~10000といった数になってしまうので，見せ方はとても重要．

また，ツールの構築では，以下のようなことに気をつけること，としている．

・意味が一貫していて理解しやすいこと．　たとえば UML なら，継承関係が上下方向に並ぶとか．・大きくなると，「すべてを一度に見る」のは現実的ではない．　「現在位置」のようなものが常に分かるように　しながらレンズでズームアップする，といった　メンタルモデルが重要．・保守作業などでは，システムはどんどん変化するので　変化に追随できる機能が必要．・大規模ソフトウェアの保守はチームワーク．　複数人が（できれば地理的に離れた場所でも）　利用できるようなシステムが好ましい．・同一のシステムを複数の perspective から見られるようにする．・静的特性，動的特性を両方とも扱えることが重要．・認知モデルの構築・相互運用性の実現

そのほか，何％くらいのツールが UML 表現だったりグラフを使っていたり，といった数値が載っていたが，それを見た限りではグラフが多いこと，UMLが意外と少ないこと，またアニメーションなどは稀だということ，くらいだろうか．

_ ライセンス占い ▲

ソフトウェアライセンス占い．http://u-maker.com/42212.html

面白いなーと思ったのが，質問への回答がテキストでの自由回答なところ．いったいどうやって判定しているんだろう．文字コードからの乱数とかではないのかなぁ．質問への答え方によるのかな？

_ ちなみに旧 BSD ライセンスでした． ▲

---以下，引用---旧 BSD ライセンスが適用された貴方は、落ち着いていて伝統重視の、とても洗練された人。時の厳しい選別に耐えた品のあるもの、優雅なものを好むタイプで、あくせくした暮らしは好きではないでしょう。といっても、それにふさわしいだけの心の余裕や、品位があればよいのですが、なかなか難しいかもしれません。浅ましく世間ずれした連中に出し抜かれてしまいがちで、経済的な生活レベルは普通かそれ以下になってしまうかも。慎ましく現状維持を念頭に置いた生活、そして侘び寂びや諸行無常の境地が、そんな貴方の日々の生活に自ずと潤いと美をもたらしてくれるでしょう。そんな貴方の恋愛面は、意外なことにとても積極的。俺が私がとどんどん自分をさらけ出し、相手に自分のエゴイスティックな刻印を残そうとするでしょう。でも大枠では、相手に合わせた恋愛をしていきそうです。

_ 読書 ▲

レイモンド・スマリヤン「パズルランドのアリス」文庫版の分冊１読了．

いわゆる論理パズル．分冊１は「不思議の国」のお話と登場人物を踏まえて展開している．解説が３分の１を占めていてけっこう丁寧だが，難易度の高いものもいくつか．もっとも，難易度が高くないと面白くないのだけど．ちょっとずつ時間つぶしに読んでいくのにわりとちょうどいい．

ちなみに原著名はAlice in Puzzle-LandA Carrollian Tale for Children Under Eightyらしい．

_ [OUCC] CPU ▲

おーさか＠OUCC様のPCの，負荷をかけたら（インストール途中くらいで）落ちて，挿しなおしたら動くとかいう怪しい動きをしていたCPUは，結局，別のものに交換したら動いたので，CPUが損傷していたらしい．

CPUとマザーボードが損傷して，怪しい挙動の中でハードディスクを道連れにしたといったところか．

_ FLASH Paper ▲

flash で pdf みたいなのが見られるものらしい．flash paper で書かれた原稿を見せていただいたのだけど，けっこう軽く動いて，読み始めが快適なのに感心してしまった．

_ ビザ審査を通過 ▲

カナダ大使館の人ががんばってくれたのか，ぎりぎり間に合うように（２週間ほどで）ビザ申請の審査が終わったから出国していいよという連絡が来た．で，９月にASE／AO-ASIA参加のために一度戻ってくる予定．そのためにポジションペーパーか何かは確実に書かないといけなくなったけど．

ウィークリーマンションに結局ネット環境はなかったので，OUCC部室のネットワークを借りつつ作業の予定．ウィークリーマンションは７日までで移動日は８日なので，空港に近いホテルを取ってのうのうと過ごすかな，というところ．

問題は，バンクーバーでの住居（大学の寮のようなもの）の申請の返事が来てないこと．とりあえず問い合わせ．

_ [ゲーム] スペランカーの岩の飛び越え ▲

１コンと２コンの両方でキャラクターが動かせることを利用して，片方で左を押して左に動き出してる間にもう一方のコントローラで右＋Ａを押すと右ジャンプできて，岩にあたっての跳ね返りは（左移動中のジャンプなので）右側になって岩を飛び越える（と理解している）技があるけど，知らない人もいるようなので書いておく．

_ [近況] クリッカープロを買ってみました ▲

マウス売り場で自宅用の小さいマウスを１つ買っておこうと思っていたんですが，クリッカープロなるものを発見したので衝動買いしてみました．

私の場合だと左手でタッチパッド操作を行うので，余った右手でスクロール操作ができるのはけっこういい感じです（左クリックボタンも付いてますが，いまいち押しにくいので使ってません）．ホイールのように回転量ではなく上下方向へ押してる時間で入力が入るので，ホイールメッセージをただ１回だけ与えるような細かい操作には不向きな気がしますが，ブラウザ上などで大雑把にスクロールぶんにはかなり良さげです．

私の使ってるテキストエディタでは，キーボードから手を離さず，画面を上下スクロールできるので，エディタで文章を書いてる最中にちょっとだけ下や上の文章を見たいというときに便利です．