iOS/Xcode/Swift3: CoreData はSQLが使えないRDB？

　久しぶりの更新。Swift3でアプリ開発をしているが、CoreDataというDBラッパー(内部はSQLiteらしい)を使用している。テーブル定義を専用ファイルに書き込むだけでデータコンテナとなるクラスが自動生成され、リレーションもつけられので、それなりに便利だが、通常のSQLを使ったクエリーを書けるようにはなっていない。

条件を指定して検索するのだが、せっかく自動生成していても、カラムの名称などは手入力しないといけないし、条件式も文字列とプレースホルダーで与える形だ。 また、Swift3になってデータ型がNSのついた古いもの(NextStep由来の Object-C 型)から、NSのつかないものに切り替わっているため、その相互変換もやや煩わしい。

let nsdate = NSDate()
let date:Date = nsdata as Date

 などでもできるのだが、タイムゾーンの扱いが微妙に異なる気がするので、複数の国や時間帯がある場合は注意を要しそうだ。

OS-X Yosemite でプリントできない！

　　OSをYosemite(10.10)に更新してから、NEC MultiWrite 8250N での印刷ができなくなっていた。調べてみると、CUPS(**nix/**bsd系の印刷システム)でSandBoxになっているのが影響するらしいとのこと。以下をターミナルから実行してみた。

sudo sh -c 'echo "Sandboxing Off" >> /etc/cups/cups-files.conf'
sudo launchctl stop org.cups.cupsd

　書いてあったのは、こちら　＝＞　MacOS1010YosemiteKnownIssues

　結果としては、印刷できるようになったので、良しとしよう。

iPhoneのホームボタントリプルクリックではまる

iPhoneの画面操作がおかしくなって焦った。これは修理か交換かな？と思って調べてみると、どうもトリプルクリックが原因だったようだ。

症状：
１）アイコンを押すと黒い枠がでるだけで、ダブルクリックしないと押した事にならない
２）ドラッグが効かない：メッセージなどのインフォが見れない
　＝＞　実は、ダプルクリックして指を置いたままにするとドラッグできた

原因：
　ホームボタンをトリプルクリックしてしまったこと。

　トリプルクリックには、特定の機能が割り振られており、アクセシビリティの設定になっていると、通常のタップやドラッグができなくなってしまう！

当初は、パスコードの入力もできなくなったと思い、相当焦った！！
液晶保護シートを外したり、掃除したり色々やったが、無関係でした、、、orz

Gradle での他プロジェクトへの依存性

Gradleが便利なので利用するようになった。利点は以下のもの。

1)Mavenのリポジトリが利用できる
2)Groovyなので、小回りがきく

Eclipseでplungin  をいれて利用していたが、２つ作成したGradleプロジェクトに依存関係を入れる時にちょっとはまる。
Eclipseのビルドパスで、他のプロジェクトを指定すると、Eclipseではコンパイルも実行も問題ないのだた、GradleのInstallAppなどを指定すると、とたんにコンパイルエラーとなる。
G が E の依存関係を理解していないのが原因。ググってみても簡単な解決策なし。最初から親子プロジェクトにしておけば、以下の形式でOK。

 compile project(':projectA')

結局、maven プラグインを追加して、ローカルリポジトリを利用した。

■参照される側の build.gradle => install タスクにてローカルリポジトリに作成される。

apply plugin: 'maven'

version = '1.0'
group = 'net.korabo.app'
//archivesBaseName = 'UmlGenerator'
version = '1.0'

■参照する側の build.gradle => mavenLocalの指定が必要

repositories {
mavenLocal()
    mavenCentral()
}

dependencies {
    compile group: 'net.korabo.app', name: 'UmlGenerator', version: '1.0'
    ....
}

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

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

１）必要なファイルをコピーして、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すると正しい順序で連結された！！

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マニュアルを参照すること。

トラブル対処の原則考

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

１）状況の聞き取り
２）ログなどのエビデンス収集　＝＞ ログなどが０バイト
３）部分的な実行による切り分け

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

３－１）主要スクリプトを単独実行　＝＞ 出力空
３－２）上記スクリプトを手で実行(SQLPLUS) ＝＞ 空
３－３）確実に出力があるように変更して実行 ＝＞ no rows selected

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

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

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

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

なぜなぜ分析セミナー

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

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

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

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

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

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

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

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

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

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

文章の濃度

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

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

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

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

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

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

１）開発プロセスの変遷からの類推

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

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

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

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

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

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

Windws7 に SSHサーバ(Copssh)ではまる

サービスでの起動で問題発生
最初は、FreeSSHDをインストールしたが、サービスから接続すると"cannot create child desktop" だの、"入力不可" などで断念。
次に、Copsshを入れてみたが、これはCygwinのサブセットみたいなのでコマンドの少ないbashが使用できる。これもサービス起動だとうまく動かず、、、ググっていると、「サービスで使う場合はインストール時手で管理者アカウントでやるべし」みたいなのを発見し、その通りしてみると何とか動いた。ちなみに、コントロールパネルも管理者アカウントで起動してユーザを追加しないと効果ないようだ。また、インストール後に再起動も必須の模様。

　なお、ユーザ追加の時に変なドメイン「.」を指定してしまうと、エラーが発生して２度とコンパネが起動しなくなるのは困ったものだ、、、

参考：http://www.sevenforums.com/customization/19864-ssh-windows-7-a.html

Once you download this run it as administrator and accept the default settings. It will than prompt you to all the settings you would like to use.

Once done you will need to manual setup users through the Copssh folder in the Start menu. (hint if you want to add an account that is not YOURS) just type in in over the drop down.


途中までやりかけたFreeSSHDのサービスアカウントのポリシー変更に関してはこちら、
参考：http://linlog.skepticats.com/entries/2010/10/Got_freeSSHd_mostly_working.php

I believe you have to grant the freesshd service access to create system tokens.

Run gpedit.msc (or apply group policy from the directory)

replace "sshd" with whatever account the process is running as, the default is SYSTEM

Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> User Rights Assignment

Access this computer from the network -> add sshd
Act as part of the operating system -> add sshd
Adjust memory quotas for a process -> add sshd
Allow log on locally -> add sshd
Create a token object -> add sshd
Create global objects -> add sshd
Log on as a service -> add sshd
Replace a process level token -> add sshd

Comment posted on Tuesday 29 Mar 2011 at 5:54pm
By W. Strucke

開発方法

大きな流れとしては「要件定義、分析、設計、製造、テスト、配備、運用」となるのだが、
構造化にしろ、OOにしろ、DOにしろ、いまいちしっくり来ない感じがしていた。

ベストプラクティスとしての方法を紹介するというスタンスであって、
論理的でない部分が多かったように思う。
今にして思えば、論理的に説明するための基礎が不足していたからではないだろうか？

そこで、いくつかの素案をメモしておく；

・要件定義：実現したいシステムを表現したもの(単なる要望でなく、実現基準を持つ)
・分析：モヤモヤしている要件を複数の次元に分解して詳細を明らかにしたもの
　　例）業務機能、基盤機能、性能、システム把握、運用性、操作性、、、
・設計：上記の複数次元からなら定義を１つのシステムとして実現(実装、運用)できるような要素に分解し、その作成の筋道を明らかにしたもの
・製造：設計指示をもとに実行できるコードを生成し、単体レベルテストを実施する
・テスト：システム全体の要求を満たすかのテスト
・配備：実際の運用環境に適用する
・運用：

■トレーサビリティ

システム開発で分析や設計に力をいれるのは、トレーサビリティを確保するためだと思うようになった。
というのは、実際のシステム運用において、障害が発生したり拡張要求が発生した場合に大元の要件と対応する実現物(コードなど)の対応がとれないことが多く、これがシステムの理解を悪化させているのではないかと思えたからだ。トレーサブルでないシステム(これが大半だと思うが)では、システムの現状に関して信頼できる資料は実際に動作しているコードのみとなる。要件とコードの対応がつかないのでは当然である。

しかし、トレーサブルでないことがデファクトとなっているシステムをトレーサブルなものにすることができるのであろうか？これに対する構想を以下に述べる；

■現在使用可能なトレーサブル

たとえば、DBのテーブルやOOのEntity定義などはほぼ完全にトレーサブルと言える。要件として、「これ、これ、これ」と指定された項目をまとめて管理するという枠組みは非常にシンプルであり、正規化などで形式が変わってみていても上流の定義に戻すことは容易である。つまり、下記のような双方向変換が容易にできる。

データ定義　＜＝＞ モデル ＜＝＞ コード

■モデリングの限界

UMLなどのモデリングでは、なんでも出来そうに思われるが、それは上記のデータ構造に関してであり、動的な側面の記述という観点からは、基本的に用意された定義だけを使っている限り意外と表現力が乏しいと感じる；

例えば、簡単は電卓の動作をUMLだけで記述することが出来るであろうか？ 特にNキーロールオーバのような複数同時実行する場合の挙動を記述するのは簡単ではない；さらに、それが出来たとしても、そこから何らかの言語への変換が出来るであろうか？ 既存の変換ツールは状態変化(ステート図)を対応するクラスの挙動に変換するという極めて狭い領域をカバーするものが多いと感じる(すべてを見たわけではないのだが、、、)

■代替えとしてのDSL

では、UML以外のモデリングとして何が考えられるであろうか？ それはDSLだと考えている。
UMLで特定のDSLを記述することができれば間接的にUMLで表記したことにはなるが、そこにこだわる必要性を今は感じない。

例えば、機能表現に特化したDSLでシステム要件の機能部分を分析し、性能に特化したDSLでシステム性能要件と記述するという形にすれば、分析作業とは「システム要件をM次元の直交要素に分解しそれを固有のDSLで記述すること」と考えることができる。

さらに、設計は記述されたDSL要素から実現コードへのコンバータの生成(定義)と捉えることができる；
DSLをテストフレンドリにしておけば、生成されたコードをDSLを使用してそのままテストすることができ、要件が変わってDSLを書き換えたらテストまで自動で流すことができるようになる。

要件 ＜＝＞ M次のDSL記述 ＜＝＞ 実行コード

■開発作業の変化

DSLを中心に捉えてみると、システム開発作業は以下のような形にすることができる；

１）要件定義：聞き取りと文書化
２）DSL作成
３）コンバータ開発
４）生成、テスト
５）システムテスト

DSL作成の中でもUI部分やデータ定義などで分業できる要素があり、コンバータ部分は開発会社の強みとして自社で抱え、システムテストは人件費の安いところに外注するという工程も成り立つと思う。

そのためには、DSL ＝＞システムテスト という生成ツールが欲しいところである。

コードレビュー

レビューの目的などをまとめてみた：
参考： http://www.ibm.com/developerworks/jp/opensource/library/j_os-codereview/#resources

■目的：
　コードが問題なく単体テストを通っていても、前提とする仕様が誤っていたり誤って解釈していれば、「誤った仕様に沿って正確に動作するコード」となり当初の目的を果たしていない。そもそも単体テストは開発者が作成するのが通常であり、誤って解釈してコーディングされていれば、単体テストも同じ過ちの上に組み立てられいて整合することになり、正しい仕様との乖離は発見できない。
　そこで第3者の目を通してのコードレビューが必要になる。コードレビューは、ソフトウェアレビュー／ソフトウェアインスペクションの一つであり、コード自体を調査することで以下のことを目指す；

障害の可能性を発見：潜在的なバグ(仕様どおりに正しく動作しなくなる可能性)など
コーディングの間違いや勘違いを発見：仕様との乖離
ユーザによる誤操作や誤解を誘発する恐れのある部分を発見：表記、操作順序、UI配置など
管理、運用上での必要データの取得漏れや不適切な保持を発見
性能やりソースに問題をもたらす恐れのある部分を発見：メモリーリーク
基盤(F/W)に対して適合しない部分の発見：認証、認可、セキュリティの迂回ルートなど
将来の保守(修正、拡張など)や移植において問題なる可能性を発見

レビューの過程を通して以下の活動も行われうるが、オプションとする；

テストケースの抜け、漏れの発見と指摘
テスト条件、テストデータの抜け、漏れ、不適切値の発見と指摘
基盤部分の改善や拡張(生産性や保守性が向上する場合)
脆弱性を持つ部分の発見(意図しない情報漏えいや悪意のある操作への対応)

以下の活動は原則として目的としない；これは基盤(アーキテクチャ)や運用環境の課題とする

システムとしてのパフォーマンスチューニング
負荷分散や可用性の向上策
リソースプランニング
秘匿情報の漏洩対策
業務妨害などの攻撃への対策
管理上のファシリティ

■レビューの観点(パースペクティブ)
レビューは種々の観点から行うことで幅広く問題点を指摘することができる；

システム利用者(ユーザ)
システム業務管理担当者
システム運用管理担当者
品質管理担当者

■前提条件：
レビュー開始時点で、ソースが以下の条件を満たしていること；

コンパイルエラーなし
FindBugやCheckStyleでの重大な問題なし
単体テストはAllGreen

■レビューに必要な資料
開発対象概要(業務ユースケース、モジュール構成、データ構成、)
プロジェクト概要(目的、方針、体制)
動作基盤概要(方式、構成、I/F仕様など)
製造要件(要件定義、要件分析、S/W設計、コード表、データ)
製造規約類(コード規約、製造指針、テンプレート、コードテーブルなど)

■レビュー体制
以下の役割で複数人が参画すること；
進行役(モデレータ、司会)
レビューア/インスペクター(問題の指摘；指摘分野を絞る場合もある)
記録係
オーガナイザ (レビュー会開催および結果活用の幹事)
作成者(オーサ、コーダー)
プレゼンター (対象コードの説明役)

■レビュー結果の活用
コードレビューを通して、この種のバグや潜在バグの下地(将来の修正や拡張時にバグを生みやすい構造)を発見して取り除いていくことで、以下の効能がある。

開発者に対して実践的トレーニングをすることになり、技能的向上が見込める
これにより、手戻りが少なくなり、品質、納期、保守性などが向上する

■典型的な指摘例
コードレベルでの指摘
１）変更不可変数の扱い
　必ず使用する変数やフィールドは初期化忘れ防止のためにも「final」宣言をする
　＊不変オブジェクト(生成したら変更不可のもの：String, Integer など)はコンスタント扱いとなる
＝＞ この場合は「static final」が定数の意味合いを強調できるので更によい
　＊不変でないオブジェクトは内容を変更できる
＝＞ フィールドの場合、フィールド定義文またはコンストラクターにて初期化する

２）変数名称
　コードが読み易く、誤解を招かないような名称と長さを保つ

３）スコープの選択
可能な限りスコープを狭くする；他のクラスからの干渉を制限でき、修正や拡張に対する影響を狭くできる；
　内部変数やサブルーチン的なメソッドは「private」
　抽象クラス(abstract)で子クラスが使用するものは「protected」(同じパッケージ内の他クラスからも使える)
　どこからも使えるよう公開する場合は「public」

■基盤部分などの共用コードに対する指摘例
１）スレッド対応
同じデータに複数のスレッドがアクセスする場合、以下の点を考慮する
　ConcurrentXXXX クラスを使用する(Java5以降)
　変数に「volatile」宣言をする
　「synchronized」で囲む：ロックの発生による性能劣化の可能性に注意

JBoss/Seam の@In がOverrideできない

@In
public void setXXX(CCC ccc){...}

のインジェクションを子クラスで
@override
@In(required = false)
public void setXXX(CCC ccc){...}

としてみたが、効果なし？？

Solaris/sparc での64bitJVM

32bit版をまずインストールし、次に64bit版を入れる；
JAVA_HOMEは共通にする；
例） JAVA_HOME => /usr/jdk1.6.2
64bitで動かす時はOptionとして”-d64”を指定
例） JAVA_OPTS="-d64 ....."

Esxi 4.1 Update のカスタム版

　インストール元がCD-ROM固定になったようで、USBにカスタム版を作っても、途中でメディアが見つからないといって止まってしまう。
　しかたがないので、USBで起動するがCD-ROMも用意して途中から読み込ませることにした。無事にインストール自体は終わる。
　今回、カスタム版にしたのは、D525MWのNIC(RTL1111?)が認識されないことによる。
詳細は、ここにあるようにoem.tgzというファイルを追加して中には必要なNICなどのドライバと定義がはいっていればよい；ただし、起動時に認識できてもインストールした後のものにはoem.tgzはコピーされないため、別途コピーが必要。

oem-r8168-8.018.00+ssh+ftp+wget+rsync.tgz　のファイルは、フォーラム中に埋込まれている。

Tomcatのオプション

-Xmx などの指定をJAVA_OPTSにしろと指示している情報が多く見られるが、これには問題がある。
１）このOPTSはtomcatに関連する全Javaプロセスに適用されてしまう
２）stopや、statusなどのメモリフラグが意味をなさない場合にも適用されてしまう
３）JMX_AGENTなどのListenPortを使う指定をここで行うとstopなどの場合に競合してしまう

正しくは、CATALINA_OPTSでやる。このOPTSはstartの時だけに効き目があるので、起動するtomcatのプロセスのみに適用したいオプションはここに書くとよい。
　また、catalina.sh と同じ階層に、setenv.sh という名前のファイルを置いておくと自動的に読み込んでくれます。形式はbashの変数指定の形式。
例）
CATALINA_OPTS="$CATALINA_OPTS -Xmx2048m"

Oracle DataPump

10gを利用しているが、丸々一晩かかったImp/Expも、DATA_PUMPを利用すると
わずかな時間で完了する。長足の進歩だ！ただし、不満もある。

impdp .....

で、fatal_error とログに出るのに何の情報もなく、手探りで調べると
ディレクトリオブジェクトに対しての権限が不足していたようだ、、、

impdp usr121/usr121 directory=DATA_PUMP_DIR dumpfile=EXPDAT-20110405-01.DMP logfile=IMP-3.log schemas=usr21 remap_schema=usr21:usr121

GRANT READ ON DIRECTORY "DATA_PUMP_DIR" TO "USR121"
GRANT WRITE ON DIRECTORY "DATA_PUMP_DIR" TO "USR121"