netail.net

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

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

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

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

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

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

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

_ [近況] 研究室のページを更新 ▲

新年度の４年生向けに，研究室の研究紹介ページをがんばって更新してみました（日本語版は，もう新しい版に差し替わっています）．

今までは色々と研究テーマを列挙していただけでしたが，今回はカテゴリ分けを試みたので，だいぶ疲れました．

_ [VolumeDeskbar][PptWatch] Volume Deskbar + IE7 の動作確認 ▲

今までは XP+IE6 と Vista+IE7 で動作確認していたんですが，XP+IE7 も試してみたら，普通に動いてました．

PptWatch も Office2007 に対して動くようで，見事なバージョン互換性があるようです．

_ [読書] 五十嵐先生の OCaml 本 ▲

Standard MLに比べて，OCamlにオブジェクトが入ってることの嬉しさが良く分からなかったので，五十嵐 淳: プログラミング in OCaml（技術評論社，2007）を読んでみました（買ったのはだいぶ前でしたが，修論・卒論シーズンが終わってようやくちゃんと時間を取れました）．

結局，オブジェクトは副作用があるもののようで，関数型言語中でのオブジェクトの使い道が確立されてるわけではないらしい（ライブラリもオブジェクトだらけというわけでもないらしい）というあたりで，分からないなりに，ちょっと納得はしました．

本自体は，レコード型やヴァリアントあたりの，普通の関数型言語としての嬉しさが分かりやすく説明されていて，また，型についての知識を確認できたので，お買い得感はありました．

_ [近況] 伊予柑うどん ▲

先日のワークショップ帰りに買ってみたので，食べてみました．

釜揚げあるいは冷やしで食べるのが推奨のようですが，普通に作ってみました．写真は撮ってみたものの，黄色さは分かりにくいかもしれません．

茹でてる最中から漂うくらい伊予柑の香りが強いです．香り付けのためにゆずの皮とかをうどんに入れることがありますが，それに近い味わいでした（麺に香りが付いてる分，だいぶ強力ではありますが）．かき揚げを載せて食べてみましたが，けっこう美味しかったです．

_ 実験のやり方 ▲

みんなで一斉に同じ作業をやって時間を計測するという実験で気づいたことと，過去のメモを合わせて軽く整理してみました．

良い実験のやり方というのをきちんと習ったことがないか，あるいは忘却したので，間違ったことを書いてるかもしれません．

実験関連では，プログラム理解に関する実験のやり方についての論文もあったりします．

• [環境] 作業環境のうち，個人でインストールするもの（JDKなど）は 事前に通知してバージョンを確認させておく．
• [環境] Eclipse はコピーで配れるので非常に便利．自分で別PCにコピーして確認し，入力すべき workspace の位置などを確認する．
• [環境] ノートPC持ち寄りでツールを実験する場合，たとえばディスプレイの大きさやCPU性能などがツールの使いやすさに影響しないか検討が必要（データの可視化系や解析系だと影響がありそう）．
• [計画] 事前説明＋トレーニング用の練習問題で，１時間半程度はかかる．たとえば，比較対象としたい手法A，Bのどちらにも馴染みがなく，それらを使って課題X，Yを解くという場合，A,B の説明とトレーニングに加えて課題 X,Y の説明するので，時間はかなり必要となる．トレーニング部分（手法A, B の説明）だけを切り離して実施するという手もある．
• [計画] 課題をクリアしたことを本人が確認する方法があると，明確に作業時間を計測できてよさそう（デバッグなら JUnit の通過とか）．
• [計画] 作業時間を，どの程度細かい作業単位で記録してもらうかの判断が必要．課題単位よりは，その中の作業単位ぐらいのほうが良さそう（たとえばデバッグ作業の実験では，原因解明までと修正の時間は分けていたほうが考察がしやすい）．
• [計画] 作業時間は，普通に時計を見てその時刻を記録する（分単位で計測する）ので十分．資料（あるいは作業記録シート）には，あらかじめ作業手順と，各ステップでの記入欄を用意しておくというのが良さそう．
• [計画] 作業時間で評価するなら，予定よりも時間がかかっても大丈夫かどうかを考えておく．長時間作業になりそうな場合，適宜休憩を入れられるか考えておく．
• [資料] ツール使用の実験などでは，操作手順を聞き逃しても追いつけるように（あるいは説明を省略できるように），操作手順を積極的にスクリーンショットなどで撮影しておき，資料に含めておく．
• [実施] 誰がどの課題を解くかを，直前に改めて確認する．
• [実施] 細かい質問（ツールの使い方等）はちゃんとサポートする．トレーニング用の問題を用意しておくと，課題に取り組んでいる最中でも，具体例をその問題のデータを使って示せるので楽になる．