2012年5月1日火曜日

VirtualBox in MacOS-X: VMの移行ではまる

電源が入らなくなったMacMiniからVMのファイルだけが救出できたので、新しいMacMiniに移行しようとした。

1)必要なファイルをコピーして、VMの追加 => xxx.xml を指定すると、以下のような
メッセージが出てしまって追加できない

?????"/opt/VirtualBox/Machines/VM4Daicho/VM4Daicho.xml"??????????
A differencing image of snapshot {773bf732-3682-42d8-9d77-d64287538436} could not be found. Could not find an open hard disk with UUID {3a85ec8d-b6ab-4292-879e-3701f8febab3}.
????? :
NS_ERROR_FAILURE (0x80004005)
???????:
SnapshotMachine
????????:
IMachine {5eaa9319-62fc-4b0a-843c-0cb1940f8a91}
?????:
IVirtualBox {c28be65f-1a8f-43b4-81f1-eb60cb516e66}


色々調べて、UUIDを以下のコマンドで確認したり変更できることが分かった。

VBoxManage internalcommands dumphdinfo HDDファイルへパス
VBoxManage internalcommands sethduuid HDDファイルへパス

該当するUUIDのファイルを読めそうな場所に置いて、何度かチャレンジするも一向にうまく行かず、これは定義ファイル(xx.xml)を自力で編集かなと思ってちょっと手を加えたがやはりだめ。

それならと、メッセージにあるようにOpenしてみようと別のVMを新規に作成してHDDとして当該UUIDのファイルを追加してみた。するとメッセージが変化した。

うまくいった方法

VirtualBoxの仮想DiskManagerを開いて、登録してあげればいい!
 ただし、+ボタンがないので登録の仕方で難儀したが、D&Dするだけだった
 さらに、SnapshotsのファイルもD&Dすると正しい順序で連結された!!

2012年3月29日木曜日

JMXに関する覚書

org.jboss.system.ServiceMBeanSupport を使用した場合の注意点:

JMXで使用するMBeanに対して、javax.management.MBeanRegistration を実装すると以下のメソッドが自動的に呼ばれることになっている;
 void postDeregister() 
 void postRegister(Boolean registrationDone) 
 void preDeregister() 
 ObjectName preRegister(MBeanServer server, ObjectName name) 

上記メソッドでは、JBossサービスに依存した初期化をおこなうことができない。
JBoss特有の初期が必要な場合は以下のライフサイクルメソッドを実装する;

 void create() throws Exception
 void destroy()
 void start() throws Exception
 void stop()

または、上記が定義された 「org.jboss.util.Service」インタフェースか、String getStateString()などが追加された「org.jboss.util.ServiceMBean」インタフェースを実装することでJBoss特有の初期化ができる。

JBossでのMBean作成上の注意
 抽象クラス「org.jboss.util.ServiceMBeanSupport」を継承して作成することが一般的だが、start(), stop() などのライフサイクルメソッドをOverrideしても子クラスのものが呼び出されずに親クラス(ServiceMBeanSupport)のメソッドが呼ばれる仕様になっている。
 子クラスでOverrideすべき専用メソッドを実装すること!!

 void startService() throws Exception
 void stopService()

*詳しくはServiceMBeanSupportのJavaDocなどや、JBossマニュアルを参照すること。

2012年3月22日木曜日

トラブル対処の原則考

修正したヘルスチェックスクリプトがうまく動作しないというので、調査していた。
本来ならNGとなるべき出力がOKのままだという。その時実施した対応は、

1)状況の聞き取り
2)ログなどのエビデンス収集 => ログなどが0バイト
3)部分的な実行による切り分け

結局のところ、部分的に実行していった段階でミスに気付いたのだが、これをもっと早く確実に発見する方策がないだろうか?

3-1)主要スクリプトを単独実行 => 出力空
3-2)上記スクリプトを手で実行(SQLPLUS) => 空
3-3)確実に出力があるように変更して実行 => no rows selected

ここにいたって、Oracleのつなぎ先が違うのでは?という疑いが発生し、調べたらまさにそうであった。

教訓1:調査開始時点での前提を明らかにして疑ってみる
 => 原因の上流の確認は作業が容易で効果が大
教訓2:前提を明確にできるような工夫をスクリプトに入れておけばよかった
 => または、文書としてコメントに入れておくか、前提確認用スクリプトなど
 例)前提:Oracleとの接続、スクリプトの配置場所、XXファイルの書き込も権限
   前提違反時の振舞:エラーメッセージ、空文字出力、、、

優先順位マトリックスを考えてみた:
 作業の困難性  => 当該部分に問題があるかどうかの確認作業の時間やスキル
 影響範囲の大小 => 当該部分の障害から本件が発生しうる確率
 優先順位 => 容易で影響大 -> 困難だが影響大 -> 容易で影響小 -> 困難で影響小
  *中央の2,3番目の部分は時間配分やメンバースキルによって反対にした方がよいか
   または、メンバーに余裕があれば並行して作業するといい

今回の件だと、Oracleの接続先のような前提条件は
「作業が容易で影響範囲が大」となり、優先順位が高いものといえる。
環境変数の設定も、同じ範疇だ。しかし、個別スクリプトの問題となると
「容易で影響小」となる。

2012年3月1日木曜日

なぜなぜ分析セミナー

== なぜなぜ分析に関しての考察 ==
2012/03/01 ST(KRB) NEW.
2012/03/15 ST(KRB) REV.

セミナーに参加して気付いたことのメモ
------------------------------- セミナー概要 -------------------------------
日経情報ストラテジーセミナー
     改善・改革活動の基礎スキル「なぜなぜ分析」演習付きセミナー
     講師:小倉仁志 (マネジメント・ダイナミクス社長)
     日時:2012年2月28日(火)
     場所:品川フロントビル会議室
     参加者:目測で120名程度

     講義編:なぜなぜ分析を考える時の定石
          ●ヒューマンエラーを分析する際のよくある失敗例
          ●「なぜ?」を考える前に、原因追究の勝負は決まる
          ・漏れの無い課題の摘出で、会社として抜けの無い仕組みの構築を目指す
          ・見たまま、かつ的確に事象を表現する
          ・分析対象を正確、かつ詳細に把握・理解する
          ・前提条件を整理し、分析上の除外要件を明確にする
          ●「なぜ?」を考える時の定石
          ・論理的に展開するための定石
          ・漏れなく展開するための定石
          ・狙い通りに展開するための定石
          ・展開された「なぜ」を正しく検証する
          ・導き出された対策の展開の仕方
          ●なぜなぜ分析の進め方
          ●ヒューマンエラー防止に向けた、なぜなぜ分析の運用のしかた
          ●なぜなぜ分析事例
          ●なぜなぜ分析の様々な用途例

     個人ワーク:なぜなぜ分析の間違いを見抜けるか
          よくあるヒューマンエラーの「なぜなぜ分析」を、自分なりに修正することで、
          「なぜなぜ分析」の定石を再確認しよう
          ●講義で学んだことを基に、分析上の間違いを指摘し、自分なりに修正する
          ●回答例と比較し、なぜなぜ分析で陥りやすい間違いや注意点に対する理解を深める

     グループワーク:トラブル事例をグループで解き明かそう
          品質クレームへの適切な対策を、「なぜなぜ分析」の進め方に沿って導き出してみよう
          ●グループで事例を分析し、論理的に漏れなく要因を洗い出し、
          再発防止策を1つ以上導き出す
          ●グループでの分析作業を通じて、数人で分析するメリットを実感する

     質疑応答
          今回の講義・演習内容や、なぜなぜ分析を行う上での疑問点などに講師がお答えします
-----------------------------------------------------------------------------

以下は筆者の受け取った内容(通常の文書)、および感想や心情([角カッコ内の文書])。
(順序は講義の通りではない)
参考書籍:
小倉仁志:なぜなぜ分析徹底活用術
小倉仁志:なぜなぜ分析実践編

・「なぜなぜ分析」とは、実務家が利用する改善のための道具にすぎない
     [問題を深く問い直すことで具体的で即応可能な原因を追究してその対策をたてる、業務改善活動の1つ]

・目的は何か => 職場、作業、業務、、を変えるため
     誰の為にするか => 3人(顧客のキーマン、自分、同僚)
・失敗は仕事に不完全な部分があるから => 完全を目指すのが人の役割
     トラブルの原因追究ができる人は少数 => ベテラン中のベテラン
・何故の回数より狙いにこだわるべき
     再発防止につなげるのが大切;現場と管理では策が異なる
・知ったかぶりはやめる
     (謙虚に事実と向き合う)
     事象は、先入観をいれずにありのままで表現する:忘れた => していない(忘れたかどうかは本人の確認が必要)
・分析を始める前の過程が重要     [直感として8割方の成否を握る]
     刑事ドラマに例えると、事件(発生事象)の把握(証拠物と登場人物などのアクティビティ調査)をすること
     脇役の刑事のように早合点してはいけない
・事象の洗い出しは紋切り型にしない
     発端の事象と処置ミスの事象、、[収集して関連明らかにする]
・証拠とアリバイから不要な選択肢を減らしておいて、深く調査してゆく
     [情報システムでの証拠(エビデンス)は、操作記録やログ、複数の証人が同じ認識をしていることがらなど]
・事象抽出(事象を認識して表現する)で、焦点を当てるよりどころは、担うべき使命
     [現場のチームか、マネージメント側かによって導き出す対策の焦点が異なってくる為]
     チームでトラブルを考えさせる => 使命感を共有し深化させるチャンス
・慢性トラブルでは、事象を1件だけ選択する
     へたに統計や類型分類などしないほうがよい
     1つを明確にできなければまとめたり類別したりはできない
・事象明確化の作業方法
     事実の収集、順序・つながり の確認
     的確、論理的、もれなく、狙いよく
・事象の状態(頻度、傾向)を具体的に表現すること;曖昧なものは避け、比較で記述する場合は対象を明示する
     例)Cが表示されていない => 100個中1個の割合でCが表示されない
     [相対的な表現より計量的な表現にする]
・前提(証拠、アリバイ)を固めれば不要な選択肢を分析から排除できる
     [原理・原則からアプローチをすると選択肢が増えてしまうので、どう絞るかを知りたいとう質問への回答]
・分析上の注意
     文中の言葉に着目してなぜを出す:泣いた => それってどういうこと?[泣くとはどういう行為?]
     前提によってなぜの選択肢が変わってくる:いつから泣いていたか、10分前はどこで何をしていたか、、、
     現場の現状だからと予断してはいけない、ミスリードすることが多い
     [前提(付帯情報)によって、何故の爆発を防止でき、焦点を絞れる]
     [選択肢が増えすぎるようなら、~~かどうか知るためには何が必要か、と考えて前提を増やしてゆくとよいかも]
     1つのなぜに要因を2つ以上入れてはだめ:「~せずに~したから」のような複合分にしないで、分解する
     意味はっきり、ストレート表現:主語述語、時点や傾向、図などで補う
          例)温度の設定が悪い => 担当者Aさんが温度設定を誤った
               温度が低下した => 10:30から22:30にかけて1時間に2℃の割合で温度が低下した
               上にずれてしまった => 図を使用して、ずれた長さや方向を実数で表示
     時間、場所、内容を細かく分け、時間の早い順、場所の近い順に並べる
     後ろのなぜが解消されたら前のなぜが解消するかをチェック
          これを判断できる人をチームに入れておく
     基準を発揮とさせる、反対から見る
          例)~が多すぎる => 通常の材料の割合に対して、今回は水が15%多すぎる;[~が多くない限り~~は発生しないか?]
     逆に読み返して筋が通るか
     背景を加えた表現で筋道を正す
          ~じゃしょうがない、、は言い訳になってしまう => ~にもかかわらず、~~した
          心情を考えるのではなく、「掘り下げるべき弱点」を見出す[クールに評価するのは対応策を見出す為]
     狙いは再発防止
          火急の問題では暫定処置を出す
          1)発生しない、しにくい状態にする
          2)発生しても、気付きやすくする[工夫とルール化]、気づけるようにする[努力とトレーニング]
・分析には、発生した問題を解決することを主眼とするものと、トラブルチェックシート的に使うためのものがある
     [発生事象を元にすると前提が限定されるため選択肢を絞り込みやすい]
     [事象からのなぜは、現にある問題を解決するためのなぜであり、AND関係にあるものを見つける:XXX以外に何があろうと問題が発生していたか?]
     [チェックリストのなぜは、将来発生する問題の可能性を見つけるためのなぜであり、OR関係を見つける:XXX以外に原因となる場合はないか?]
・対象の事物のつながりを正確、詳細に把握するためには、登場人物の活動をフロー図にしてみるとよい
     [BPMNのBP図やUMLのアクティビティ図にそっくりのレーン分けされた図で登場人物の活動とその関連を表記]
     [発生事実の連携の中で直接的な原因は素直に見通せるようになる]
・人為ミス(ヒューマンエラー)は「やらなかった」と「間違えた」に分ける
     やらなかった:やることを知らなかった、知っていたができなかった、、、
     間違えた:4段階で考える
     忘れた、の追及は途中で切る、そうしないと言い訳ばかりで分析にならない
     間違いの発生には4つの局面(情報、受容、判断、動作)があるので、どこで問題が発生したかを分析し対策へつなげる
          例)情報[刺激]:材料のラベル自体が間違っていた => ラベルがなくても識別できるような知識や訓練、明確な違いを持つ材料を利用する
               判断:別工程と間違えて不要な材料を入れてしまった => 開始前に再確認できる仕組みを作る
               動作:となりのビンと取り違えてしまった => となりのビンの形や色を変えておく
     個人的な話は避ける(プライバシー)
     ミスの要因例の想定:紛らわしさ、~ずらさ[不適切]、作業時のノイズ、役割分担の不備[責任の所在]
・「XXに気付かなかった」のような「なぜ」は、対象や期間を明確にする
     [考えると、これは「しなかった」ことが原因となるケース:意識にないものを見つけだすのは難しいが、本質的な対策の糸口になりそうだ]
     [つまり、なぜを考えるときに、「した」ことによるなぜと、「しなかった」ことによるなぜを想定する必要がある]
     [直前に原因発生から、次の事象発生までの間に、もしXXXしていれば防止できた:という観点で点検してみてはどうか?]
     [上記に期間に活動できる人はだれで、どんか活動が可能だったかを考えてみる]
     [単純に「XXXXすればよい」を対応策には(十分に細かくないので)できないと思うが、対応策に直結するなぜを導く一里塚になる]
     [目安ができれば、そこに立って考えることで新しい視野が開けると思う(Vision:焦点の移動)]
     [対策が正しくても、事象(これから実行されるものも含む)と離れすぎていると判断がつかないし、やったことの効果が分かりにく]
     [どのような仕組みや(業務プロセス)や体制(組織と制度)があれば防止できたか?]
・トラブルは会社を強くするチャンス
     [分析により弱点を認識でき、対策がとれるレベルにまで詳細化できる]

[余談だが、講師のしゃべりがみのさんを連想させる感じがあり、面白かった]

2012年2月18日土曜日

文章の濃度

文章には濃度がある。濃厚なものは味わいが深いが解釈に予備知識を必要とし読み下すのに手間がかかる。一方薄いものはさらさらと読めるが、本質には影響を与えないような枝葉が数多く含まれる。

小説として楽しむなら薄い方がよい。ちょうど主食として常食する材料がどれも薄味であるのと同じだ。
一方、記録や智恵の書の場合は、濃い記述になっている。これは言葉を凝縮していることによる。

例:
濃い文章
 法王アレッサンドラ6世の死後、ジュリオ2世により囚われの身となったチェーザレ・ボルジアが逃亡した先はシャルロットの兄であるナヴァーラ国王の元であり、パンプローナから自由宣言が発せられた。

薄い文章
 チェーザレ・ボルジアの父である法王アレッサンドラ6世(ロドリーゴ・ボルジア)がローマにおいて死去したまさにその時、チェーザレ自身も生死をさまよう重病であった。続く法王ピオ3世はチェーザレに同情的であったが即位から1ヶ月もたたずに世を去ってしまう。その後、チェーザレは最大の誤りを犯すことになる。ボルジアに煮え湯を飲まされてきたローヴェレ枢機卿の法王就任に対して手を貸してしまったのだ。ジュリオ2世として即位した新法王は、チェーザレを破滅されることを画策し、ボルジア家の故郷でもあるスペインへの軍務を餌にして誘い出し、幽閉することにも成功する。しかし、スペイン王家の内紛に乗じて逃亡したチェーザレは、フランスに残してある妻シャルロット・ダルブレの兄であるナヴァーラ国王の元へとたどり着き、自由の身となることができた。ナヴァーラ王国はフランスとスペインの国境近くにあり、その首都パンプローナからイタリアの各地へとチェーザレの自由宣言の手紙が発せられた。

2012年1月27日金曜日

オブジェクト指向の光と影

ソフトウェアの構成物をオブジェクトという単位で捉えるオブジェクト指向は、ブームからコモディティへとこなれてきたと思う。しかし、そこには指摘する人が少ない影の部分が存在していると感じたので、それを記しておく。

1)開発プロセスの変遷からの類推

 ウォーターフォールからアジャイルへの変化や分化などは最適化の結果と捉えている。
 地図を例にとると、平面の四角い紙に表す地図(メルカトル図法)は、一定の狭い範囲での表現としては最適であるが、地球全体にまで領域を広げると形が歪んでしまう欠点がある。逆に地球儀のアイデアを狭い範囲で忠実に実現しようとしても精度的に無意味になってしまう。
 つまり、対象とする事物や扱う方式によって最適なものは変化するということだ。
 ユニファイドプロセスなどは、ウォーターフォールのやり方を部分最適な方式として捉えており、ソフトウェア開発をモジュール化してその一部を実行する時のプロセスとして採用し、これをイテラティブ・インクリメンタルに行うこととした。
 一方アジャイル開発では、ウォーターフォール的な手法を採用する場面はもっと限定的になる。

 開発方法論は、統一(Unified)のかけ声よりも、現実に即した進展をしたと思う。それは、1つの手法ですべてを統一するのではく、状況に合わせて最適なものを採用するという方式だ。

2)分析・設計手法におけるオブジェクト指向

 ソフトウェアの世界をデータと振舞を内包した要素とその関連として捉えるオブジェクト指向は、ある領域では最適だと言えるが、無制限に一般のソフトウェアを対象に出来る訳ではない。
 オブジェクトは仮想的なモジュールとして捉え、それがデータを内包し、他のオブジェクトと関連を持つと捉えるのがOOの基本であるが、この考えはある程度の固まりとしてのソフトウェアコンポーネントやサブシステムという単位ならとてもしっくりするのであるが、細かくなってくると現実と整合しずらい部分が出てくる。
 たとえば、機能や振舞を細分化し抽象化していくと、特定のオブジェクトやそのクラスに属する限定をしないほうが扱いやすい、純粋に抽象的な機能というものも見つかり、無理やりにオブジェクトと捉えると何のデータも持たない要素となってくる。また、データの方も同様にまったく何の機能を持たせる必要性がない固まりというのも存在する。さらに、振舞に関する関連とデータに関する関連では、構造を定義しているという点では同じだが、意味合いは全く異なっており、データ同士の関連は状態を意味する一種のデータとして使われるが、振舞同士の関連が状態を意味することは通常ない。
 通常と言ったのは、振舞同士の関連に状態を持たせようと思えば出来るからであり、この「やろうと思えばできる」的な曖昧さが、OOでの分析・設計をぶれの大きなものにしてしまっているように感じる。
 異なっているのに、共通的に取扱えるから同じ用語やコンセプトで押し通されてしまうと、本当に重要な”違い”が見過ごされてしまうような気がする。

ではどうするかは、これからの検討課題とする。

2012年1月12日木曜日

OSGI:felix:bundleIDの戻し方(GFv3)

uninstallしても、bundleIDがインクリメントされてしまう。同じIDを再利用できなかと調べてみたら、以下のファイルに保存されているようだ。

osgi-cache/felix/bundle0/bundle.id

このファイルを編集して番号を戻し、以前と同じIDを使用できるようにしようと思ったのだが、単に変更しただけではだめだった。

refresh かけた => だめ
update 0 => GlassFish自体が落ちてしまった
再起動 => うまくいった

結果オーライだが、くれぐれも既存のbundleを上書きしないように注意しよう。

OSGI:bundleの不思議な挙動

OSGIのbundle(モジュール)をインストールしたところ、新しく追加したリソースが見えていないような症状となった。

[#|2012-01-11T14:49:15.740+0900|WARNING|glassfishv3.0|net.korabo.cmt.spord.svc.msg.plugin.FireSubscriberPluginWRpldChk|_ThreadID=187;_ThreadName=Thread-1;|ErrorInCheckOF:[net.korabo.cmt.spord.svc.msg.CommonMsg@152886a]
com.ibatis.sqlmap.client.SqlMapException: There is no statement named MSGACCEPTANCE_ALT.selectTsRpldByPrimaryKey in this SqlMap.
at com.ibatis.sqlmap.engine.impl.SqlMapExecutorDelegate.getMappedStatement(SqlMapExecutorDelegate.java:231)

実際のパッケージ(jar)やGlassFishV3 の domains/domain1/osgi-cache/felix/を見てもファイルは更新されているはず、、、

telnet localhost 6666 (felixの場合)でOSGIのコンソールに入って様子を見ると、、、

ps
[ 219] [Active ] [ 1] spord-controll-osgi (1.0)
[ 223] [Active ] [ 1] spord-appstarter-osgi (1.0)

inspect package requirement 223
spord-appstarter-osgi [223] imports packages:
---------------------------------------------
ibatis; version=0.0.0 -> spord-appstarter-osgi [220]
org.osgi.framework; version=1.5.0 -> org.apache.felix.framework [0]
..........

となっており、PSでは見つからない220番を参照していることになっている!?

ちなみに osgi-cache/felix/bundle220 は存在しており、MANIFESTでの定義は、

Import-Package: ibatis;resolution:=optional

となっていた。

手順としては 220番が存在していた時に unistall して、同じパッケージを新たなbundleとして install しただけ。

じつは、これだけだと変更がコミットされていなかった! 変更後に refresh をかけることが必須である。

参考:http://d.hatena.ne.jp/IkeT/20090325/1237945826

んで、推奨手順:

# 新規のみ
# install xxxxx.jar
# 更新時
stop
update file:///xxxxx.jar
# 共通
refresh
start