2011年12月16日金曜日

任意のプログラム実行に対して自動でoprofileを開始・終了するシェルスクリプト

研究の実験の際に作成しました.ご自由にお使いください.
使い方は,下記ソースコードを適当なシェルスクリプトのファイル(例えばhoge.sh)として保存し,
# . hoge.sh 任意の実行コマンド及び引数群
などとすれば利用できます.


2011年12月14日水曜日

VMWare Serverを利用して測定したデータを公開するときの制約

が,あるそうで,

VMware Serverを利用して構築した仮想マシン上で測定した性能の情報を公開するためには,VMware側の許可をもらう必要があるようです.


具体的にはサイト:http://www.vmware.com/download/eula/server.html 3.3 Restrictions. にある記述,
You may use the Software to conduct internal performance testing and benchmarking studies, the results of which you (and not unauthorized third parties) may publish or publicly disseminate; provided that VMware has reviewed and approved of the methodology, assumptions and other parameters of the study. Please contact VMware at benchmark@vmware.com to request such review.”


 を元にしています.これは例えば,仮想マシン上のL2キャッスミス数や消費電力の値について計測したとき,その妥当性について確認を行う,という旨だと理解しています.


つまり修士論文のための実験結果を出してから,論文を提出するまでの期間でVMware側にデータを確認してもらう必要がある,ということになりますね.時間の猶予を考えると難しい.というか無理.

2011年12月9日金曜日

VMware Server2のインストール環境まとめ

先日,Apache VCLを構築する機会があり,その過程であるVMware Server2のインストールでハマりにハマったのでメモしておきます.

ちなみに,Apache VCLとはクラウド環境を構築するための一つのソリューションおよび環境セットです.大きく,マネジメントノードデータベース+ウェブノード管理対象ノードにマシンの役割が分けられ,管理者は,管理対象ノードに立ち上がる仮想マシンを一般ユーザへ提供する形となります.

特徴はなんといっても無料で構築できる点です.最低マシンが2台あればすぐに試すことが出来るでしょう.

ややOpenStackなどの影に隠れている感はありますが,ブラックボックス化されてしまっているクラウドコンピューティングの仕組みを理解するのにはうってつけの教材の一つだと思います.



本題です.このVCLですが,管理対象ノードの仮想化エンジンにはVMware Serverを利用します.しかしこのVMware Server,ヴイエムウェアがサポートを終了した関係もあってか,Linuxカーネルの進化に追いついていないようです.具体的には新しいカーネルであるほどインストール時に問題が発生する傾向にあります.

結論から言うとCentOS5.7(kernel-2.6.18)+VMware Server2+glibc-2.5-34という環境で動作を確認していますので,この組み合わせが無難ではないかと考えています.


以下,僕が遭遇した問題についてまとめておきます.


2011年11月5日土曜日

PyramidフレームワークでPython+WSGIのWebアプリ(2)インストール 〜 Hello, world

前回に続き,pyramidのインストールおよび簡単なhelloworldプログラムの実行までを紹介したいと思います.基本的にWindowsでも可能ですが,自身の環境が基となっているのでCentOS向けの内容です.

インストール

それでは早速pyramidのインストールとhelloworldの表示まで進めていきます.

今回使用した環境は以下のような構成です:
OS : CentOS5.7
CPU : Intel(R) Core(TM)2 Duo CPU @ 2.40GHz
Mem : 512MB
Disk : 20GB

必要なパッケージをインストールします.ここで,CentOS5.7の場合だと標準のyumリポジトリではPython2.4が最新です.pyramidはPython26を想定していますのでEPELリポジトリを追加します.

Python2.6をインストールします.
# yum install python26 python26-devel --enablerepo=epel 
 以降,python26を基本コマンドとして使用していきます.

さて,pyramidのインストールにはeasy_installを使用します(Rubyのgemにあたる仕組みです).これを使えるようにするためにはez_setup.pyというファイルを利用してeasy_installを取り込みます.
#python26 ez_setup.py

あとはpyramidをインストールするのみです.
#easy_install-2.6 pyramid
いろいろなパッケージが自動ダウンロードされると思います.すべて pyramidを構成する依存パッケージです.

これで,pyramidを使用してwebアプリケーションを作成する準備ができました.

Hello World

公式のドキュメントによれば,最も単純なpyramidアプリケーションの記述は以下です:
この記述をhelloworld.pyとして保存します.あとは,ウェブ用などの一般ユーザにて,
$ python helloworld.py
serving on 0.0.0.0:8080 view at http://127.0.0.1:8080
 という状況になればOKです.ブラウザに以下のURLを打ち込みます.
http://127.0.0.1:8080/hello/hogehoge
hogehogeというメッセージが表示されているウェブ画面が確認できれば完成です.

PyramidフレームワークでPython+WSGIのWebアプリ(3)MVCに則ったサンプル(BankAccount)

2011年10月20日木曜日

PyramidフレームワークでPython+WSGIのWebアプリ(1)とっかかり

Webアプリケーションを作成するとき,そのための道具は枚挙に暇がありませんが,Python界隈がにぎわっているようです.


僕はこれまでJava系のフレームワークしか利用したことがなかったのですが,スクリプト言語でのWebアプリも興味深いですね.


というわけでPythonでのWebアプリ作成を検討します.


理由は上記のものもありますが,ちょっと遊んでみようと思って,日本語でのドキュメントやチュートリアルなんかが少ないな,と感じたので,皆さんと共有できれば幸い,というのが大きいです.


Google App Engineも,PythonのWebアプリケーションフレームワークで実装しているんだとか.


そうだ,Pyramidをつかおう

さて,早速PythonでのWebアプリ作成にとりかかりたいと思います.


ここで気になるのが道具ですね.どうも,Python単体では,いろいろやろうと思うと限界がありそうです.そこで,JavaでいうTomcatやglassfishにあたる,Webアプリケーションフレームワークが欲しくなります.


Python界では本当に多くのフレームワークがあり,選択肢が多いです:
  • Twisted
  • Zope
  • CherryPy
  • TurboGears
  • Django
  • Pylons
老舗にあたるのがどうやらTurboGearsのようです.が,ここではPylonsに注目してみようと思います.理由は,開発スピードが早く日本語のドキュメントが少ないこと,Ruby on Railsを彷彿させるMVCアーキテクチャを採用していること,包括的に多くのフレームワークを持ちつつ,シンプルな記述も可能であること,などです.
フレームワークのフレームワークとでも言えばいいでしょうか.Pylonsは他の多くの仕組みを自身に持っています.アプリケーションサーバでいうと富士通のInterstageがSpringやStrutsなどのオープンソースフレームワークを抱えていますが,ちょうどそのようなイメージです.


そして,Pylonsを含む上記リストアップしたフレームワークの特徴として,WSGIに準拠している,というものがあります.
WSGIとはフレームワークを用いてサーバとアプリがやりとりをするとき,その方法をPythonで定義したものです.ちょうど,JavaでいうServletやjspみたいなものです.
よって,Pylonsを使ってWebアプリを作り続けたが,他のフレームワークへ移行したいというシーンがあったとき,それまでのがんばりが無駄になることはありません.WSGIに準拠したフレームワークであれば,我々はその実装を意識することなく,Webアプリのコードが書けます.


が,このPylons,開発スピードが速いのもあってか,バージョン1.0を境にサポートは行うが新しく開発はしないというメンテナンスモード,レガシーステータスに設定されてしまいました.
事情としては,
The Pylons web framework 1.x line will continue to be maintained, though not enhanced. We will provide a package that allows Pylons 1.x applications and Pyramid applications to run in the same interpreter. The future of Pylon-style web application development is Pyramid
ということらしいです.
かわりに,このPylonsを統合するような形で新しくフレームワークがリリースされました.それがPyramidです.このフレームワークについては日本語のドキュメントが圧倒的に少なく,また利用事例も少ないようです.


公式のドキュメントはこれでもかというほど充実しているので,それらを紐解きつつ,実践的なWebアプリを実装していきたいと思います.


と,いうわけで次回から実際にインストールしてみて,使ってみた時の記録をまとめていきたいと思います.





PyramidフレームワークでPython+WSGIのWebアプリ(2)インストール 〜 Hello, world



PyramidフレームワークでPython+WSGIのWebアプリ(3)MVCに則ったサンプル(BankAccount)


2011年10月8日土曜日

開発環境と実行環境があるときのデバッグ

今研究室のプロジェクトで,電力や水量,二酸化炭素量といったエネルギーデータを測定する九州大学のメータから情報をひっぱってきて一元的に管理するシステムみたいなのを作っています.

開発では,各自のPCにEclipseを入れ,ソースをSVNで共有しています.
実行環境は別にあり,DBやアプリケーションサーバがインストールされています.

で,ここで疑問に思ったのが,アレ,デバッグどうやってやろうか,ってことです.
僕はこういう環境だとこれまではプロジェクトをjarなりwarなりで固めて開発環境の方へ投げ,チェックポイントのログや例外のスタックトレースなんかを適当なファイルに吐かせて確認していたのですが,統合開発環境のデバッグ機能って便利ですよね.それを使えないのはもったいないな・・・って思ったんです.

開発環境と実行環境がある場合のデバッグ方法はいくつかあると思います.その長短について自分なりの考えをまとめます.


  • 開発環境では開発のみ行い,デバッグはすべて実行環境で行う
僕が採っている方法です.実用への感覚をつかみやすく「修正→再ビルド→再実行」の流れをスムースに行えますが,統合開発環境のデバッグ機能が使えません.


  • テスト用コードと実行用コードを用意する
つまりDBなどが実行環境にある場合接続部分をローカル用とリモート用両方用意し,開発段階ではリモート用のコードを使うというやり方です.統合開発環境のデバッグ機能が使え障害箇所を特定しやすいですが,「バグ発生→デバッグ→修正→再ビルド→再実行」という流れの中でテスト用と実行用のコードを書き換えないといけないのが億劫です.


  • 開発環境に実行環境と同じサーバ機能を再現する
統合開発環境のデバッグを使え,コードもローカルやリモートといったことを考慮せずに済みます.しかし開発環境と実行環境とでOSが違う場合に発生する問題や,利用しているサーバソフトウェアのバージョンの違いなどを考慮する必要がでてきます.いざ問題が発生すると原因の特定に時間がかかること必至っぽいです.

と,いうわけで現在これといった決定打もなく勝手なやり方でデバッグしております.もしかしたらこのへんのわだかまりを解消してくれるフレームワークみたいなのはあるかもしれませんが,Springとかみてると大抵ああいうフレームワークは巨大です.今回のような小規模なシステムに対しては大げさに感じてしまいます(そのような発想でシステムが大きくなるといわゆるツギハギになってしまうのかもしれませんが).

みんなはどんなふうにデバッグやってるのかな〜統合開発環境使いこなせてなくてごめんなさい.

もう少し調べてみます!

2011年10月3日月曜日

EclipseからSubversionを使う

ひととおりの手順をメモ


◯前提
Eclipse(Indigo)がインストールされ,使用出来る状態にあること

◯手順
インストール編
  1. EcipseのHelp -> Install New Software
  2. リポジトリを追加する Name:適当(SubclipseとかでOK) URL:http://subclipse.tigris.org/update_1.6.x
  3. 取得したパッケージをすべて選択し,Next
  4. Temsに同意してインストール,Eclipse再起動

新規共有プロジェクト作成編
  1. 普通にJavaプロジェクトを作成し,ビルドし,実行したりする
  2. 満足したところでパッケージエクスプローラのプロジェクト名のとこを右クリ
  3. Team -> Share Project -> SVN ->Next ->ロケーションはakbのリポジトリを指定 ->Next
  4. プロジェクト名をフォルダ名として使用にチェックを入れFinish
  5. ユーザ名やパスを入れる
  6. これで自分のプロジェクトのフォルダがサーバー側に出来上がります
  7. パッケージツリーで右クリ -> Team ->コミット
  8. これで作成したJavaファイルなどがアップロードされます


他の人がSVNにあるプロジェクトを共有する編
  1. EclipseでFile->Importを選択
  2. SVN->SVNからプロジェクトをチェックアウト を選択し Next
  3. AKBのSVNがなければ新規リポジトリ作成,すでに作っていっれば既存のリストにあるはずなのでそれを選択
  4. リポジトリを選択するとフォルダリストがでてくるのでインポートしたいプロジェクトが入っているフォルダを選択
  5. 次の画面(チェックアウトオプション)で「新規プロジェクトウィザードを使ってプロジェエクトとしてチェックアウト」を選択->Finish
  6. プロジェクトの特性(Java?Tomcat?)に従い新規プロジェクトを作成
  7. ソースなどはSVNのものが,ライブラリなどはローカルのものが導入されたプロジェクトが完成

2回目以降編
  1. チェックアウトしたプロジェクトを編集する前は必ず更新する
  2. 編集したプロジェクトをアップロードする場合はコミットする


ここでSVNの設定をしたのがきっかけでちょっとばかしgitについて調べてみたのですが,いやはやバージョン管理ソフトウェアって相当奥が深いですね.

学生のうちでもなるべく現場に近い作業を積んでいって,こういったユーティリティソフトウェアをただ道具で終わらせるのではなく,
  • どう嬉しいのか
  • 誰が嬉しいのか
  • このソフトウェア固有のものは何か
といったことに思考をめぐらせると面白いですね.

2011年9月3日土曜日

失敗例から学ぶStartupWeekend@Fukuoka

先日の話です.
8月25日(金)の夕方から8月27日(日)の夜まで,StartupWeekendが開催されました.
大雑把にいうと「約50時間強で起業のスタートアップをする」というものです.無茶苦茶な.
流れは,

  • 自分のアイデアを発表したい参加者がみんなの前で1分間のピッチを行う
  • アイデアを上位8つに絞る
  • 参加者は8つのアイデアのうち自分が携わりたいものを選ぶ
  • それで集まったメンバーがチームとなる
  • チームは残り時間で開発,マネタイズの確立,プレゼンの準備を行う
  • プレゼンで8つのうちから(いろいろな)トップを決める
という感じでした.


失敗の原因
最初に申し上げておきますが,以下の内容は誰々がどうだったとか,もしああしていれば・・・とかそういう辛気臭く仲間を批判するような内容とは程遠いものです.よしなに.

結論からいうと我々のチームは見事に失敗しました.
「ああ,こうやって間に合わなくなっちゃうんだな」って体感した気がします.
で,何がだめだったかを考えたのですが,以下の項目に集約されると思います.

  1. 問題に対する解決策が明確でない
  2. 動くものがない

問題に対する解決策が明確でない
私たちのチームは問題を解決する手法を決めるのに多くの時間を費やしてしまいました.
方向性が決まらないことには,各メンバーの得意分野の作業にとりかかることができません.
それで,結局完全なストーリーを一本つくることができず,成果物もプレゼン内容も確定していない状態で発表することとなってしまたのです.


この部分を反省するにあたり,まずStartupWeekendで発表するときの心構えみたいなものを説明しておきます.

StartupWeekendでは,ひとりひとりのピッチも,最後のプレゼンも,基本的には「世の中のこういう問題は,我々のつくったサービス(orアプリorデバイスetc)で解決できる!」とうロジックで話を進めます.

おそらく,わかりやすいからでしょう.学生の身分ではあまり多くを語れませんが,NEEDSベースな部分に人々はお金を落としていくのではないでしょうか.つまり,問題に対して共感できるというのが,プレゼンにおいて重要なんだと思います.

さて,この現象を回避するためにはどうすればよかったのか.
  • チームのアイデア源である人が多少強引にでもひとつの解決案を押し通す
  • 誰が見ても明らかでわかりやすい解決案である
こんなところを考えています.「問題は共感できるんだけど,なかなか解決策が思いつかない・・・」というシーン,あると思います.リーダーの人,ファイト!



動くものがない
上記にも関連するのですが,結局この手のイベントは動くものを見せないと始まらないのでしょう.

「おお,なんか面白そう.俺も使ってみたいわ.できるのかな?あ,できてるんだ,スゲー」

聴衆にここまで思わせれば優勝ですたぶん.
前半部分がおろそかなのは論外,後半部分が不十分なのは机上の空論で終わってしまいがちです.

今回福岡で優勝したOooiのプレゼンをみたとき僕が思ったのは,まさにこんな感じでした.たぶん他の人も同じでしょう.だからこそ圧倒的な支持をもらえたのだと思います.

動くものをつくるためには,「問題に対する解決策の意思統一がとれていること」がとても重要になってきます.作ったものが支離滅裂だったらどうしようもないですものね.

意思統一にかける時間を最低限にし,あとはその道のスペシャリストに作業を分担するという流れが理想的です.エンジニアがプレゼンを気にする必要はないでしょう.


起業に必要な要素
ってでかくいってますが,「こんなイベントに必要なこと」と読み替えてくださって問題ないです.

アイデアの普遍性
投票性である以上ニッチな話題は不向きです.誰もが潜在的に抱えている問題をそれっぽくばらまくのがよさげです.

問題とその解決案のわかりやすさ
共感を得やすいですし,さっさと開発作業にとりかかれます.

プロトタイプ
とにかく動くものを見せることが重要です.

プレゼンのわかりやすさ
最初,最終発表の5分という時間は短いと思っていましたが,わかりやすさを追求するならば納得です.

リーダー的存在
この場に必要なのはボスではなくリーダーです.ゴン蔵ではなくたけしなのです.
世の中に存在しない解決策を講じようとしているのだから,皆が不安を覚えるのは当然です.
リーダーの人は,多少のバッシングなどなんのその,責任をもってメンバーを引っ張っていくべきでしょう.皆,リーダーのアイデアに共感して集まってくれたのですから.



以上を一言にまとめると,

スタートアップイベントは,リーダーがアイデアのわかりやすさを維持し,エンジニアとデザイナーが開発し,それをドヤ顔で自慢するように発表する

ですよ.

また参加したいです!

2011年7月16日土曜日

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

Toodledoは一週間しか履歴を保存できませんが,一週間ごとにEvernoteにクリップすればほぼ半永久的に蓄積できることに気が付きました.さらに,このように表やグラフにまとめれば本家の有料版タスクサマリ出力機能にひけをとらない効果を得られるはずです.その分時間はかかりますが,自分に合った分析ができ,なおかつ文書化できますのでどっこい以上を期待していいでしょう.

一週間のサマリ

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

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

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

勉强していない.聞けば,学部4年の後輩の皆さんは大学院試験へ向けて毎日一時間その対策のための勉强に時間を費やしているそうです.
彼らのほうがよほど自己管理できている.見習いたいものです.

2011年6月30日木曜日

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分となり実は一時間もかかっていないことがわかります.以前は調査しながら書いていたことが長く感じる原因でしょうか.しっかりと作業を切り分けることにより効率化が望めそうです.

2011年6月24日金曜日

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

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

タスクの分類

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

【フォルダ】
タスクの所属.何のためのタスクか,何を達成するためのタスクか.フォルダは必要に応じて追加できるし,必要なくなれば削除してよい.
l  研究
l  雑務
l  資格
l  ライフ

【コンテキスト】
タスクを達成するための手段.基本的に永劫変わらない.
l  Mail
Ø  名の通りメールを送信することによって完了できるタスク.ほとんど時間はかからないだろう
l  Execution
Ø  タスクを完了するためのプロセス,タスクを行ったことによる結果がわかっているもの.あとはやるだけ!みたいなの.時間も見積もりやすいはず
l  Presentation
Ø  スライド作成,発表練習によって完了できるタスク.非常に時間がかかりそう
l  WriteDocument
Ø  キュメントを書くことによって完了できるタスク
l  ReadDocument
Ø  ドキュメントを読むことによって完了できるタスク
l  Investigation
Ø  調査タスク.方法もゴールもわからないことが多いため,時間の見積もりが一番きかなそう

一週間のサマリ

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

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

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

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

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


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


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

2011年6月15日水曜日

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

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

VDMToolstcファイルを使うことによってカバレッジ情報の確認が可能となったが,「どの命令が実行されていて,どの命令が実行されていないのか」については清書機能を用いる必要があった.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行目はノードの最初と最後のトークンを示しているとのことであった.ここでノードとトークンという用語の定義に対する理解に至っていない.推測では,トークンが文字列,ノードが意味のある文字列のブロック(classoperationなど)のことを言っていると考えた.
ここで注目すべきは「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で,カバレッジは57掛ける100,と考えたのだが,結果は66%のなので計算方法が違う.疑問が残るが,ここで見ることのできる情報は「未実行のノード情報」であるので置いておく.未実行のノードについてはUNCOVラベルに注目すれば抽出できそうだ.この例でのUNCOVラベルのついたノードは「2」と「return」である.この出力を処理してユーザへ未実行部分の情報を与えるケースを考えた場合,未実行ノードをばらして見せるのではなく,行数情報や文字数情報を活用し,体裁を整えてから見せたほうが親切だろうと考える.
ここまでの話をまとめる.
【わかったこと】
ž   テストを実行した後,”ni”コマンドによってコードの実行されたノード,実行されていないノードを確認できる
ž   “ni”コマンドの出力には,ノードとトークン情報が含まれており,そのトークンが何行目何文字列目かといったこともわかる
【不明点】
ž   「ノード」「トークン」の正確な定義
ž   カバレッジの算出方法
ž   ノードやトークンに関する情報の正確な読み取り方

2011年6月8日水曜日

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

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

PBLApache VCLを用いたプライベートクラウド環境の構築を行っている.その際,CentOS5.5VMware 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 再起動


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


2011年5月16日月曜日

VDMTools Tips

 先日ソフトウェアエンジニアリングシンポジウムに提出した分の作業で,
VDMToolsを使用する機会があった.先行研究では主に実行可能なVDM++ファイルを扱っており,VDM++にテストデータを与える形で実行し,想定される結果と実際の出力を比較する.このとき,福次出力としてコードカバレッジ情報(VDM++中の式のちどれくらい実行されたかを示す指標)も出力されており,前回の研究ではこれを扱った.コードカバレッジ情報を整理する上でいくつかポイントとなる点があったので以下に記録しておく.

1.1 フレームワークが処理する部分とユーザが処理する部分
 フレームワークはVDMToolsが備える仕組みを用いて仕様の実行,結果の確認,コードカバレッジの出力を担う.このとき,コードカバレッジ出力の部分に関しては注意する必要がある.というのも,VDMToolsでコードカバレッジを出力するためにはいくつかのステップがあり,フレームワークはすべてのステップを実行してくれるわけではないからだ.ステップは以下である:
1.       テスト対象となるVDM++ファイルを用意し,それをもとにカバレッジファイル(.tc)のブランクファイルを作成する
2.       VDM++の実行ファイル(.arg)を用意する
3.       VDM++ファイル,実行ファイル,カバレッジファイルを入力とし,テストを実行,カバレッジ情報を.tcファイルへ追記する
4.       カバレッジ情報を表示する
5.       カバレッジ情報を清書し,VDM++ファイルで実行された式,実行されていない式といった情報を表示する

フレームワークでサポートしているのは3番までである.すなわちテストを実行した後,フレームワークはtcファイルをテストの福次出力としてHDFSへ書き出す.ユーザは,このtcファイルからカバレッジ情報を確認することができる.


1.2 各手順でのコマンド
一連の手順をコマンドラインで行う場合,VDM++バイナリとVDMインタープリタを活用することで実現できる.
l   1でカバレッジのブランクを作成するが,これはLinuxのシェルを用いてVDMのバイナリを起動し,例えば以下のように入力する:
 $ vppde –p –R vdm.tc sorter.vpp dosorter.vpp
このtcファイルはsorter.vppdosorter.vppに記述されているクラスの情報をもつことになる.
l   3でのテスト実行とカバレッジ情報の出力だが,これは同様にVDMバイナリを用いて以下のように入力する: 
$ vppde –i –R vdm.tc sort.arg sorter.vpp dosort.vpp
l   4でのカバレッジ情報の表示については,VDMインタープリタを起動する.VDMインタープリタはシェルから引数を指定せずにVDMバイナリを呼ぶと起動する:
$vppde
その後,インタープリタにて以下を入力する:
>read sorter.vpp dosort.vpp
 >rtinfo vdm.tc
まず,tcファイルが持つクラスの情報をインタープリタ内へ取り込む必要がある.rtinfoはカバレッジ情報を出力するためのコマンドで,引数にtcファイルを指定する.結果は下の図のようになる.

l   ここで,tcファイルを操作することに関していくつかの機能を紹介する.テストによっては,例えばひとつずつのsorter.vppdosort.vppに対して複数のargファイルを用意,複数回のテストを実行し,複数のtcファイルが生成される場合がある(フレームワークで複数のMapを生成し並列分散処理を行うとこのような状況が発生する).散らばったtcファイルに関しては,以下のコマンドを実行するとひとつのファイルに情報を統合することができる:

> read 必要なvppファイル> tcov read vdm1.tc> tcov read vdm2.tc   …> tcov write  vdm.tc
tcov write コマンドで,それまでtcovが蓄積したカバレッジ情報を1ファイルに出力することができる.
l   5で,カバレッジ情報を清書して出力する機能を挙げているが,そのコマンドは今度はシェルからで,以下である:
Ø   $ vppde –lr sorter.vpp dosort.vpp
清書機能がオプションrつきで呼び出されると.実行したテストでカバーできていないDoSort, InsertSorted, Sortといった関数や操作の部分にマークがつく.ここで,いくつか注意しなければならないことがある:
Ø   このコマンドはvdm.tcという名前のカバレッジファイルに反応する.つまり,清書させたいカバレッジ情報は,vdm.tcという名前にしておく必要がある.
Ø   清書された文書はVDM++ファイルの入力形式に依存する.和田が把握している範囲では,ここで使用できる形式はリッチテキスト(rtf),Tex,そしてプレーンテキストである.カバーされているもの,されていないものといった情報を得たい場合,VDM++のクラスはリッチテキスト形式,またはTexで記述している必要がある.フレームワークの例として使用されていたエニグマ関連のVDM++ファイルはプレーンテキストで記述されていたため,清書してもカバレッジ情報が色分けされておらず手間取った.
ここでの例はTex形式での入力である.よって出力もTexであり,清書されたTexファイルをコンパイルしてPDF形式などにおこすと以下図の右のようになる.また.プレーンテキストの場合,以下図の左のようになる:

今回はリッチテキストが入力となる場合の手順は省略する.