ideviceinstallerで「Could not connect to lockdownd. Exiting.」と出てアプリのインストールに失敗する
$ ideviceinstaller -u b93fd1bed1bbdf952070fa4160a34510efbe71ee -i /Users/woshidan/to/app/dir/iOSApp/build/sym/Release-iphoneos/iOSApp.app Could not connect to lockdownd. Exiting.
Mac OS X El Captain以降のバージョンだと、iOSアプリのインストールに利用している ideviceinstaller
が依存している libimobiledevice
のバージョンが古い場合、iPhoneにアプリをインストールする際に操作する必要のある /var/db/lockdown
の編集権限がない場合があります。
この場合は、libmobiledevice
から新しく入れ直してした後、古い /var/db/lockdown
ディレクトリ以下を削除してやり直すと自分の場合は解決しました。
brew uninstall ideviceinstaller -g brew uninstall libimobiledevice -g brew install --HEAD libimobiledevice -g // libimobiledeviceの新しいバージョンを入れ直す brew install ideviceinstaller -g sudo rm -rf /var/db/lockdown/*
NoSQLの種類とNoSQLのアプリケーションの例について
NoSQLは、一人のユーザーが書き込んでから他の人が参照するデータに反映される間には少し時差があるけどいいだろうというゆるい整合性(結果整合性)で動いているんだ、といった話をこちらあたりで読んでなんか面白かったので少しだけメモします。
RDBMSとNoSQL
RDBMSは即時での一貫性を求められる基幹システムや在庫管理システムなどをはじめとしてWebアプリケーションのデータベースとして広く採用されています。RDBMSはデータの整合性を保証する代わりにトランザクションのコミット前に通信や待ちが発生するため、アプリケーションがたくさんのリクエストに応える必要が生じるにつれ、パフォーマンス的に厳しいものが出てきました。
NoSQLはこのRDBMSの状況の対抗策として登場したものとなります。 ざっくりいうと、ネットワーク上でデータを分散して管理するシステムにおいて、RDBMSの整合性を保証する代わりに遅い、という部分の逆をいく、みたいな形で作られたものであって、じゃあ逆ってなんなのだ、という話になります。
CAP定理
ネットワーク上の分散システムの性質に関して「CAP定理」*1があります。CAPのそれぞれの文字は
- Cが Consistency(整合性) = 複数のシステムのノード間で読み書き結果が矛盾しない
- Aが Availability(可用性) = (特に更新)停止しない
- Pが Partition Tolerance(ネットワーク分割耐性) = ネットワークの一部に障害が起きても動作可能(SPOF(単一故障点)を持たない)
から来ています。
CAP定理は、ネットワーク上の分散システムは、この三つのうち二つしか満たすことができないというものです。後に、提唱者のBrewer氏自身により、CAP定理の過度な単純化は問題であるとされ、割合やバランスの問題であるという具合に訂正されています *2 。
しかし、ここでは単純のため、RDBMSを含むデータベースがどの性質を満たすのか、どういったアプリケーションがあるのかを考えてみます。
C, A, P | アプリケーションの例 | データベースの種類 |
---|---|---|
C(整合性), A(可用性) | 銀行口座など,データの矛盾が許されないリアルタイム処理 | RDBMS, Vertica(Column-Oriented) |
C(整合性), P(ネットワーク分割耐性) | 検索エンジンのインデックス処理など,データの矛盾が許されない非リアルタイム処理 | MongoDB(Document-Oriented), memcached(K-V), redis(K-V) |
A(可用性), P(ネットワーク分割耐性) | ユーザーに近く、ダウンタイムがないビジネスで利用する。ショッピングカートやSony PlayStationネットワークなど | Cassandra(Column-Oriented) |
CA以外、正直、データベース=RDBMS脳の自分にとってはわかりにくいですが、たとえば、Googleの検索エンジンの更新処理やソシャゲのランキング処理がユーザーの私達から見て秒単位でリアルタイムである必要はなさそうです*3。
また、APについては、整合性より、書き込めることが重視されていますが、ゲームのネットワークであるSony PlayStationネットワークが銀行のネットワークシステムより整合性を捨てて速さを優先する、と言われたら、そこ速さがなかったらゲームにならないもんなーと納得したりしますが、実際は個々のものについて触れたり触れなかったりしてその折に考えることになるのでしょう。
現場からは以上です。
参考
- Cassandra実践入門―Twitter,Facebookが採用するNoSQLシステム|gihyo.jp … 技術評論社
- 12年後のCAP定理: "法則"はどのように変わったか
- BrewersCapTheorem - ブリュワーの CAP 定理
- NoSQL登場の背景、CAP定理、データモデルの分類 - Publickey
- すごいアプリケーションを作りたいならCassandraを使ってみよう (1/2):EnterpriseZine(エンタープライズジン)
*1:数学的には定理ではない
*2:http://www.publickey1.jp/blog/13/capcap32.html や https://www.infoq.com/jp/articles/cap-twelve-years-later-how-the-rules-have-changed
*3:ガチ勢じゃ無くてすみません。。
データベースのデータのバックアップの種類について
データベーススペシャリストの問題を見ていて、データの更新範囲や内容によって、差分バックアップと増分バックアップの使い分けを検討する話が面白かったのでメモ。
なお、最初に断っておきますが、リストア周りについて実際業務で担当したことはなく、興味があったので調べたことをまとめているだけなので、何かあったらマサカリください。
差分バックアップと増分バックアップとは
インターネットで検索したら、記事によって定義が揺らいでいてそのまま使って大丈夫か、という感じだったので、
http://www.atmarkit.co.jp/ait/articles/0306/14/news003.html https://www.backstore.jp/blog/2016/08/17/differential_and_increment_backup/ http://qiita.com/Tocyuki/items/f34ca92b8bf6e0014923
あたりを参考にまずこの記事の中でいちおう言葉の定義をしておきます。それで肝心の定義ですが、
- 毎回、最後にフルバックアップを取った時点からのデータの差分のバックアップを取るものを 差分バックアップ
- 最初にバックアップを取るときは、最後にフルバックアップを取った時点からのデータの差分となるが、それ以降は前回バックアップを取った時からの差分になるものを 増分バックアップ
とします。図にすると下図のようになります。
差分バックアップと増分バックアップの使い分け
データの更新され方による使い分けの話
取り上げられていたのは、平成28年度の午後Iの問題なのですが、
- 結構大きなテーブルで、一部だけが頻繁に更新されるテーブルのバックアップを取る場合
- 更新範囲が重複しがちなことがわかっている場合、差分バックアップにすると増分バックアップより適用する必要のあるバックアップの量が小さくなる
- 何かの履歴といった増えることはあっても後から更新されることがないテーブルのバックアップを取る場合
という趣旨の内容で、いままで二種類あるけどよくわからないな、差分は容量が増えて悪いやつだ、みたいなゆるふわなイメージを持っていた自分には面白かったのでした。
運用に関するもの
www.backstore.jp www.atmarkit.co.jp
差分バックアップと増分バックアップの定義について調べていたら、そういえば、復旧作業に関する話も出てきていたのでこちらもメモ。
さて、問題に取り上げられていたような巨大な業務用システムのデータベースなどだったら、バックアップのデータをバックアップ用のサーバに転送する時間もバカにならないので上記のようなことを計算してみて考える必要がありますが、実際、ノートPC上のファイルの中身程度だったら毎回フルバックアップで十分ということもあります。
増分バックアップは復元時の各バックアップファイルを適用していく作業が煩雑だったり、途中のバックアップファイルが欠落した場合戻せなくなってしまったりするため、手動で管理する必要がある場合は大変そうです。
差分バックアップはそれぞれのタイミングでのバックアップのデータサイズが前節であげた場合以外は大きくなりがちで、バックアップを取りたいタイミングが増えるにつれて容量を圧迫しがちですが、更新作業に必要となるのは、フルバックアップ + 差分バックアップのファイルのみであり、手順もわかりやすく復旧処理が簡単だそうです。
実際のコマンドについて調べて書こうかと思ったけど、火傷しそうだったのでやめます。
emulator: ERROR: This AVD's configuration is missing a kernel file!
エミュレータネタ連発。上記エラーが発生した時に確認することを順にメモ。
エラーメッセージ全体
Cannot launch AVD in emulator. Output: emulator: ERROR: This AVD's configuration is missing a kernel file! Please ensure the file "kernal-qemu" is in the same location as your system image. emulator: ERROR: ANDROID_SDK_ROOT is defined (/Users/woshidan/Library/Android/sdk) but cannot find kernel file in (/Users/woshidan/Library/Android/sdk/system-images/) sub directories
発生したエミュレータのAPIバージョンとABIとどこ製か
一部のエミュ(主にARM系)のエミュにはGoogle社製のものとAndroid Open Source Projectによるものがあって、自分の手元で発生したのは
で発生。
kernal-qemuとは
QEMU(仮想マシンエミュレータ)のハード的なところとソフト的なところをつないでくれるソフト。カーネル。 どうも、Androidのエミュレータは、QEMUを利用してARM系のエミュをx86などのCPUのPC上で動かしているそうです。
今回のエラーはエミュレータ作成の時に指定したターゲットに対して、このファイルがないと言われています。
実はでもなく、システムイメージが何かよくわかってないので用語や文末がふわふわですが、エミュレータに指定できるターゲットに相当するディレクトリがありまして、そのディレクトリの中に kernal-qemu
がないと言われていることになります。
発生した場合に確認すること
- SDK Manager上で該当システムイメージがインストールされているか
- 一度エミュレータを作成した後にシステムイメージが壊れていたり、Android StudioのAndroid SDKのパスの設定がおかしくて認識されてなかったりするかも?
- システムイメージが入っているディレクトリを開いてみて
kernal-qemu
があるか
実際に当該ディレクトリを覗いてみた例
// エラーが出ない $ ls /Users/woshidan/Library/Android/sdk/system-images/android-15/google_apis/x86 NOTICE.txt kernel-ranchu source.properties build.prop package.xml system.img kernel-qemu ramdisk.img userdata.img // エラーが出る $ ls /Users/woshidan/Library/Android/sdk/add-ons/addon-google_apis-google-16-1/images/armeabi-v7a NOTICE.txt build.prop ramdisk.img system.img userdata.img
どうするか
本来はないと言われているkernel-qemu
を調達できればいいのですが、いまのところ、Linuxよくわかってないし、方法不明*1。
もしかすると、SDK Managerをアップデートした後、システムイメージをアンインストールして再インストールすると直るかもしれないですが、最新バージョンのシステムイメージが欲しい場合などを除き、Android Open Source Projectの方のディレクトリには kernel-qemu
が含まれていたため、未検証です。
また、自分がこの不具合に遭遇したARM系というのはたいていの実機が該当するので、実機で検証するか実機が欲しいと交渉した方が早いかもしれません。
現場からは以上です。
*1:誰かわかったら教えてください
ERROR: resizing partition e2fsck failed with exit code 8
Androidのエミュレータの設定をいじっている最中、上図のエラーダイアローグを稀によく見かけていたような気がするのですがいままで原因がわからないうちになんか回避してしまっていたのでした。その原因と対応がなんとなくわかったのでメモ。
Androidのエミュレータの設定やデータは /Users/${username}/.android/avd
ディレクトリの中にそれぞれのエミュレータ専用の設定ファイル(.ini
)と設定ファイルやデータをしまうためのディレクトリ(.avd
)が用意されています。
avd$ pwd /Users/woshidan/.android/avd avd$ ls 5.1_WVGA_API_21.avd 5.1_WVGA_API_21.ini API15.avd API15.ini ...
個々のエミュレータ用の設定やデータが入っている.avd
の中身は以下となっています。
API15.avd$ ls cache.img hardware-qemu.ini userdata.img config.ini sdcard.img emulator-user.ini userdata-qemu.img
件のエラーはこの中のデータなどが入っているファイルシステムである .img
ファイルの形式がおかしいため起こるようです。これは、エミュレータの設定をいじってから再起動などをしていると起こることがあります。
エラーメッセージ中にあるe2fsck
コマンドについてはこちらによると、
ext2/ext3/ext4ファイルシステムの整合性をチェックし、修復する。マウント中のファイルシステムに対してはこのコマンドを実行しないようにする(修復をかけるとファイルシステムが壊れる恐れがある)。
なので、このコマンドがうまく走ってくれたらファイル形式の問題は解決しそうです。
また、一部の .img
ファイルは起動時に存在しなければ作り直されるので、中に入っているデータに未練がなければ消して作り直してみてもよさそうです。エミュだし。ということで、
- 手動で
e2fsck
を各ファイルにかけてみる cache.img
,userdata-qemu.img
を削除する- エミュレータを作り直す
などで解決しそうですというか、私は2つ目と3つ目で解決した後StackOverflowで一つ目の方法を見つけたのでした。
現場からは以上です。
AppiumでiOSのテストのサンプルを動かすところまで
iOSやAndroidのUIテストをSeleniumのように書くことができるAppiumというものがあるそうですが、 説明を見ていてもさっぱり挙動がわからなかったので、動かしてみたメモです。
各種のバージョンは
- Appium 1.5.3
- maevn 3.3.9
です。スクショにAviraが映っていますが、昨日のAvast誤検知祭りの名残です。
DLしてきたAppiumを起動
Appium: Mobile App Automation Made Awesome.からAppiumをDLしてきて起動してみます。
テストが実行される様子
今回は
のサンプルコードを実行してみます。
また、サンプルコードの実行にはmaevnが必要なので事前にDLしておきます。
iOSのシミュレータが起動。
デフォルトではテスト終了後iOSのシミュレータはシャットダウンされます。
参考
iOSのidentifierForVendorとadvertisingIdentifierについて
お仕事で調べる必要があったのでメモ。
identifierForVendor
https://developer.apple.com/reference/uikit/uidevice/1620059-identifierforvendor?language=objc
- アプリのベンダー(開発元)ごとにデバイスが一意に見えるように発行されるアルファベットと数字からなる文字列
- もう少し具体的に言うと、アプリのベンダーを識別するためにvendor IDというものを発行していて、vendor IDに対して一意
- nilになるような場合
- しばらく待ってから再び値を取得し直す
- どういう事例があるかと言うと、ユーザーがアンロックしているのに、デバイスが再起動しているとき(ユーザーがアンロックしている状態で起動したとき?)
- 同じベンダーのアプリを全部アンインストールしてから再インストールすると値が変わる
- 同じベンダーのアプリが1つでも残っていたら値が変わらない
ASIdentifierManager
https://developer.apple.com/reference/adsupport/asidentifiermanager
- 広告を提供する専用のIDへのアクセスを提供
- これはユーザーが広告トラッキングを制限しているかどうかを示すフラグ
- このクラスは広告を提供するシステムを実装する開発者によって利用されることを想定
- 一般のアプリ開発者は、彼らが開発する広告用SDKとのリンクのためであっても、このクラスに直接メッセージを送る必要はない
- 広告IDの取得方法
advertisingIdentifier
https://developer.apple.com/reference/adsupport/asidentifiermanager/1614151-advertisingidentifier
- アルファベットの文字列でデバイス毎に一意になるように発行される数字の列
- UIDeviceから取得できるidfvとは異なり、この値はすべてのベンダーのアプリ内で同一の値を返す
- このIDは変化するかもしれないので、キャッシュしてはいけない
- たとえば、ユーザーがデバイス(との連携?)を消したなどで
- 広告トラッキングが制限されている場合、iOS10.0かそれ以降ですべて0の文字列になっている
- 値がnilの場合
- この値は再取得される
- これが起きる理由としてはユーザーがアンロックしているのに、デバイスが再起動しているとき(ユーザーがアンロックしている状態で起動したとき?) (IFDVと同様)