Toodledoによる一週間のタスクサマリ(2011/6/23～2011/6/30)

今日もやります．できるだけ続けたいです．

さて，前回からの変更点は

l  「資格」フォルダを削除

l  「Study」コンテキストを追加

です．資格はよく考えるとフォルダを作るレベルではないと思いました．というわけで資格の勉强時間などはStudyコンテキストへ割り当て，ライフに統合しています．Studyコンテキストですが，

l  知識を得ることによって完了できるタスク

と定義しています．Investigationタスクとの違いは，知識を得る手段がそのまま目的につながるかどうかということと，知識を得る元となる泉がはっきりしているかどうか，です．Studyは知識を得ることが手段であり目的ですがInvestigationは目的が別にあるでしょう．また，Studyは参考本や演習ページなど知識の泉があらかじめはっきりしていることが多いです．Investigationはどこから知識を得るかということも含めて考えなければならないでしょう．

たぶん来週はCodingタスクが追加されることになると思います．

一週間のサマリ

今週の「タスクの絶対数」は以下のようになりました．

圧倒的研究．少しずつ自分のやりたいことであるライフも増やしていきたいです．

今週の「タスクに費やした時間」は以下のようになりました．

研究さんです．調査もさることながら，何をやるかわかっているExecutionタスクに関してもとにかく長い．しかし，Executionタスクは短縮させねばなりません．自動化の対象です．特に一度やったことに関しては現在自然言語のスクリプトに甘んじているので手順を再現しているに過ぎません．これを実際のプログラムで書ければ一歩進むように思います．雑務は少なければ少ないほどよいので一時間未満をキープしたいところですが今週は雑務タスクが溜まってしまっています．ライフタスクにかける時間はもっと必要です．

最後にコンテキストごとの平均時間です．これはこれまでの累積で算出しています．

先日の発表資料作成が効きPresentationが相変わらず飛び抜けています．研究以外の時間ではよく本を読んでいますね．また，研究関連の調査にも時間を費やしているようです．

ところで，このようにタスクのサマリを計算する前々から，一週間に一度研究報告をする機会があり，そこでは研究のWriteDocumentにあたる作業をおこなっていました．体感では3時間くらい毎週それに費やしていたように感じていたのですが，いざこのようにコンテキストを分け時間をしっかりはかると2週間での平均は49.5分となり実は一時間もかかっていないことがわかります．以前は調査しながら書いていたことが長く感じる原因でしょうか．しっかりと作業を切り分けることにより効率化が望めそうです．

Toodledoによる一週間の作業履歴サマリ

 折角Toodledoを使っているので，履歴データを活かそうと思いこれまでの作業記録をまとめることにしました．…が，しかし，Toodledo Free アカウントでは履歴データが一週間分しか保存されないことを完全に見落としており，それ以前のデータは消え去ってしまったという悲しい事実があります．一週間ごとにまとめる，あるいは時間がなければ履歴データのページをEvernoteにでもクリップしておくべきでしたね．とても残念なサンプル数となっていますが結果は以下です：

タスクの分類

Toodledoには「フォルダ」と「コンテキスト」という分類方法があり（タグもあるそうですが使っていません），これを用いてタスクを分類します．自分の場合，

【フォルダ】

タスクの所属．何のためのタスクか，何を達成するためのタスクか．フォルダは必要に応じて追加できるし，必要なくなれば削除してよい．

l  研究

l  雑務

l  資格

l  ライフ

【コンテキスト】

タスクを達成するための手段．基本的に永劫変わらない．

l  Mail

Ø  名の通りメールを送信することによって完了できるタスク．ほとんど時間はかからないだろう

l  Execution

Ø  タスクを完了するためのプロセス，タスクを行ったことによる結果がわかっているもの．あとはやるだけ！みたいなの．時間も見積もりやすいはず

l  Presentation

Ø  スライド作成，発表練習によって完了できるタスク．非常に時間がかかりそう

l  WriteDocument

Ø  キュメントを書くことによって完了できるタスク

l  ReadDocument

Ø  ドキュメントを読むことによって完了できるタスク

l  Investigation

Ø  調査タスク．方法もゴールもわからないことが多いため，時間の見積もりが一番きかなそう

一週間のサマリ

早速ここ一週間の作業結果をみてみます．今週は金土日と別件で取り込み中でしたので，作業時間は少ないです．本当はもっと履歴データがあったのに…とつくづく自分の適当さを悔やみます．

さて，まずは「タスクの絶対数」です．

やはり研究関連のタスクが多いですね．資格ゼロとは世の中舐めきってます．それから雑務はメールを送ることが多いようです．一週間でこれですから，累積していくと結構な数になりそうです．

次は「タスクに費やした時間」です．

圧倒的研究．バランスが非常に悪い．よろしくないですね．

最後に「１タスクあたりに費やした平均時間」です．これはコンテキストごとに合算しています．

PresentationとInvestigationの長時間っぷりが目立ちます．これらの作業時間を見積もるときは注意したほうがよさそうです．ReadDocumentは小説を一冊読みました．本当は論文やら技術書やら読むべきなのですが．

今週の分は以上です．サンプル数が少ないのでなんともいえないところも多いですが，続けていくことで有用な時間見積もりのための履歴データができあがることを信じています．もっともいつまで続くかはわかりませんが．物は試しです．

【VDMTools】TCファイルの仕様考察

     VDMToolsにおけるtcファイルの仕様

VDMToolsのtcファイルを使うことによってカバレッジ情報の確認が可能となったが，「どの命令が実行されていて，どの命令が実行されていないのか」については清書機能を用いる必要があった．tcファイルの仕様が不明だったためである．以下，tcファイルのカバレッジに関する部分について理解している範囲で詳述する．

まず，下記のようなVDM++のサンプルコードを用意する．

Sample.vpp

class A

operations

public op: bool ==> nat

op(b) == if b

        then return 1

        else return 2;

end A

次に，このコードに対してop(true)を実行する．

すると，カバレッジは以下のように出力される：

vpp> rtinfo vdm.tc

   66%      1  A`op

さらに，「ni」コマンドを使ことによりコードとカバレッジのマッピング情報を知ることができる．この出力には「ノード」と「トークン」に関する情報が含まれており，3行ごとにノード情報を表す．一行目がノードID，トークンID，カバレッジなどを表し，2行目と3行目はノードの最初と最後のトークンを示しているとのことであった．ここでノードとトークンという用語の定義に対する理解に至っていない．推測では，トークンが文字列，ノードが意味のある文字列のブロック(classやoperationなど)のことを言っていると考えた．

ここで注目すべきは「count」のラベルがついたノードである．ここがカバレッジの集計対象であり，この部分がすべて実行されていれば先で実行したVDM++コードのカバレッジが100%ということになるはずである．この例の場合，以下に記載する部分である：

41943049 ( 16, 16, 16), 1, nil, nil, 0, true, false --> count: 1

( 1,  6,  6,  6, 13),( 1,  6,  6,  6, 14),0,0,426,b

( 1,  6,  6,  6, 13),( 1,  6,  6,  6, 14),0,0,426,b

41943050 ( 19, 19, 19), 1, nil, nil, 0, true, false --> count: 1

( 1,  7,  7,  7, 21),( 1,  7,  7,  7, 22),0,0,433,1

( 1,  7,  7,  7, 21),( 1,  7,  7,  7, 22),0,0,433,1

41943051 ( 18, 18, 18), 2, nil, nil, 0, true, false --> count: 2

( 1,  7,  7,  7, 14),( 1,  7,  7,  7, 20),0,0,401,return

( 1,  7,  7,  7, 14),( 1,  7,  7,  7, 20),0,0,401,return

41943052 ( 22, 22, 22), 0, nil, nil, 0, true, false --> count: 0 <= UNCOV =

( 1,  8,  8,  8, 21),( 1,  8,  8,  8, 22),0,0,433,2

( 1,  8,  8,  8, 21),( 1,  8,  8,  8, 22),0,0,433,2

41943053 ( 21, 21, 21), 0, nil, nil, 0, true, false --> count: 0 <= UNCOV =

( 1,  8,  8,  8, 14),( 1,  8,  8,  8, 20),0,0,401,return

( 1,  8,  8,  8, 14),( 1,  8,  8,  8, 20),0,0,401,return

41943054 ( 15, 15, 20), 1, nil, nil, 0, true, false --> count: 1

( 1,  6,  6,  6, 10),( 1,  6,  6,  6, 12),0,0,348,if

( 1,  8,  8,  8,  9),( 1,  8,  8,  8, 13),0,0,330,else

41943055 ( 15, 15, 22), 0, nil, nil, 0, false, false

( 1,  6,  6,  6, 10),( 1,  6,  6,  6, 12),0,0,348,if

( 1,  8,  8,  8, 21),( 1,  8,  8,  8, 22),0,0,433,2

41943056 (  5,  5, 14), 1, nil, nil, 0, true, false --> count: 1

( 1,  5,  5,  5,  8),( 1,  5,  5,  5, 10),0,0,426,op

( 1,  6,  6,  6,  7),( 1,  6,  6,  6,  9),0,0,360,==

count対象ノードが7，うち実行されているノードが5で，カバレッジは5割7掛ける100，と考えたのだが，結果は66%のなので計算方法が違う．疑問が残るが，ここで見ることのできる情報は「未実行のノード情報」であるので置いておく．未実行のノードについてはUNCOVラベルに注目すれば抽出できそうだ．この例でのUNCOVラベルのついたノードは「２」と「return」である．この出力を処理してユーザへ未実行部分の情報を与えるケースを考えた場合，未実行ノードをばらして見せるのではなく，行数情報や文字数情報を活用し，体裁を整えてから見せたほうが親切だろうと考える．

ここまでの話をまとめる．

【わかったこと】

ž   テストを実行した後，”ni”コマンドによってコードの実行されたノード，実行されていないノードを確認できる

ž   “ni”コマンドの出力には，ノードとトークン情報が含まれており，そのトークンが何行目何文字列目かといったこともわかる

【不明点】

ž   「ノード」「トークン」の正確な定義

ž   カバレッジの算出方法

ž   ノードやトークンに関する情報の正確な読み取り方

新しいglibcとVMware Server 2 の相性問題

 CentOS5.5へのVMware Server 2.0.2インストール

PBLでApache VCLを用いたプライベートクラウド環境の構築を行っている．その際，CentOS5.5にVMware Server2.0.2をインストールする機会があった．VMwareServerが参照するglibcというソフトウェアのバージョンが新しすぎると，相性の関係でVMware Serverがクラッシュするという問題に遭遇した．具体的には，起動しているVMware Server関連のすべてのデーモンが落ち，起動している仮想マシンも使えなくなる．PBLで使用したマシンにはバージョン2.5-58がインストールされていた．Webで調査する限りだと，2.5.-42以上で同様の問題が発生しているようである（http://www.natzworks.com/digital/entries/2009/000237.html）．このページではglibcのダウングレードを行って問題を解決していたが，VMware Serverのみ参照するglibcを古いものにすることによってより簡潔に対応できる．今回は以下のように対応した：

1.       古いglibcをダウンロード(@CentOS5.5 i386)

#wget ftp://ftp.sunet.se/pub/Linux/distributions/scientific/53/i386/updates/fastbugs/glibc-2.5-34.el5_3.1.i686.rpm

2.       rpmファイルからsoファイル抽出

#cp glibc-2.5-34.el5_3.1.i686.rpm /tmp/vmwarelibc/ 

#cd /tmp/vmwarelibc 

# rpm2cpio glibc-2.5-34.el5_3.1.i686.rpm | cpio –ivd

3.       VMware Server をインストール

4.       一旦VMware Server を終了し，古いglibcへの参照を設定する

5.       /usr/sbin/vmware-hostdを書き換える；下から二行目に以下を追記：

export LD_LIBRARY_PATH=/usr/lib/vmware/lib/libc.so.6:$LD_LIBRARY_PATH

6.       VMware Server 再起動


これでクラッシュを回避できる．