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