Title

WindowsのソフトウエアRAIDを監視してメールで通知するソフト

・・・タイトルのようなソフトをリリースしましたのでお知らせします。

リリースしたのは少し前ですが、記事にしていませんでしたので。

最近のWindowsではソフトウエアでボリュームのミラーが作れるようになり、HDDの故障に備えることができるようになりました。
Windowsのミラーの良いところは何より扱いやすいことです。BIOS画面一切さわる必要ありませんし。

しかし、いざ障害が起きた時にそれを知る手段がイマイチないのが問題でした。

というわけでステータスが変わったらメールするソフト作ってみました。

こちらでございます。
http://arinkosoft.com/download/asvolumestatuschecker/

iOS8対応時の問題点、注意点

iOS8対応にあたり苦労する箇所、問題になった箇所です。
iOS7以降からのアプリの移植に際するものです。
最初からiOS8だけ考えるなら苦労することはありません。

間違ってもこれからiOS7も対応しよう! なんて無駄なことはしないことです。。

まずiOS8は見た目はあまり変わっていないにも関わらずメソッドやクラスの廃止、仕様変更がかなり大胆に行われています。
これはiOS3以降、過去をみても最大規模じゃないかと思います。
(どの程度影響するかはアプリによって違うので個人的感覚になりますが)

しかも苦労して対応しても使い勝手が良くなるような性質のものじゃないのが主です。うわー。
犯人はswiftだと思います。swiftから使いやすいように古い設計のものを一新したんだと思います。

画面の回転

まず最大の難所は画面の回転周りが大幅に仕様変更になったことです。
メソッドの廃止とか生易しいレベルではなく、座標系が変わりました。

例えばUIScreenが返す画面サイズの仕様が変わり、画面の回転に応じてサイズが変わるようになりました。
それに関連して、UIWindowが勝手にサイズが変わるようになり、しかも座標軸まで変わりました。
(以前はUIWindowは回転せず、Viewが回転していました。iOS8からはUIWindow自体が回転&サイズ可変になりました)

デバイスが横向きの時の座標軸を図にしたものがこちら。

このあたりはアプリがどのように作られていたかにもよりますが、場合によっては大幅に修正が必要になり相当苦労すると思います。
特にviewよりも深いところを使っていると悲惨。
特にiOS7以前もサポートし続ける場合はアプリ内で複数の座標系が存在するという地獄絵図に・・・。
僕もアプリは回転する画面が50個以上あり、UIWindowに直接Viewを貼ったりしていたので見事悲惨でした。

更にinterfaceOrientationなどもdeprecatedになっており、これまでと違う設計を強いられます。
回転という概念から、リサイズという概念に変更されているようなイメージです。

UIViewControllerからはデバイスの向きを取得できなくなりました。
どうしても取得したければUIApplicationのstatusBarOrientationがかろうじて使えます。よかった・・。

UIAlertView、UIActionViewの廃止

馴染み深いこの2つがdeprecatedになっています。
UIAlertControllerに置き換えることになります。
たぶん大量に使っているのでひどい目似合います。

また、このUIAlertController、ボタンを押した後の反応が悪いです。
詳しく言うとアニメーションが終わってからしかActionが呼ばれません。
以前はボタンを押した時、Viewが消えた時と順次イベントが発生しましたので時間のかかる処理は先に実行しておくことができました。

個人的には大問題だと思いますので、もう自分で実装しようかな・・・。(時間が出来た頃に)

また、iPadではActionSheetが矩形を指定してそっからポップオーバーするようになりました。
矩形位置を指定しないといけなくなり、これまでの実装からの移植は苦労すると思います。
といって操作しやすいわけでもないし、上記のとおり遅いし・・・。うーん。なにこれ。

実はiOS8でもUIAlertView、UIActionView共に動作するので無視して使うという手もあるかもしれません。

UISearchDisplayControllerも廃止

なんでか分かりませんがUISearchDisplayControllerもdeprecatedです。
UISearchControllerを使うことになります。
別に特に便利でもなくめんどくさいです・・・。

UIViewControllerのもろもろタイミング変更

よくわかりませんが、viewDidLoadをはじめとする各種イベントの呼び出しタイミングが少し変わってます。
十分検証が必要です。

iPhone6 Plus

こいつはiPadなのかiPhoneなのかハッキリしろ的なもどかしさがあります。
というのもHOME画面が回転するなど、iPad的です。
起動時に横向きになっていることもあるわけで、このあたりiPadだけ区別して対応していたならば修正が必要になります。
あと画面大きすぎてシミュレータ表示できない。。。

iPhone6 Plusの拡大モードはiPhone6と同じ解像度

とりあえず速報です。

iPhone6 Plus買いました。
でかいですね。

最初の設定時に気づいたのですが、「拡大モード」というのがあります。
シミュレータにはありませんでした。

その名のとおり、画面の要素全体が大きめになります。
アプリ側でそのような情報は来なかったと思うので、どのように対応しているかと思ったらピクセル数がiPhone6と同じになるようです。

さらにHOME画面も回転しなくなったりなど、まさにiPhone6のようになります。
よって、開発者はiPhone6PlusがあればiPhone6の解像度もテストできますよね。ステキ!

以下が検証結果です。
なんと!
iPhone6 Plusの拡大モードは、ピクセル数はiPhone6と同じですが、画面のscaleが@3x相当になってますね。
つまりまさかの新しいスクリーンサイズが今日新たに判明です! ステキ!

iPhone 6 シミュレータ

deviceName=x86_64
[UIScreen mainScreen].bounds=(375.000000,667.000000)
[UIScreen mainScreen].scale=2.000000

iPhone 6 Plusシミュレータ

deviceName=x86_64
[UIScreen mainScreen].bounds=(414.000000,736.000000)
[UIScreen mainScreen].scale=3.000000

iPhone 6 実機

deviceName=iPhone7,2
[UIScreen mainScreen].bounds=(375.000000,667.000000)
[UIScreen mainScreen].scale=2.000000

iPhone 6Plus 実機・標準モード

deviceName=iPhone7,1
[UIScreen mainScreen].bounds=(414.000000,736.000000)
[UIScreen mainScreen].scale=3.000000

iPhone 6Plus 実機・拡大モード

deviceName=iPhone7,1
[UIScreen mainScreen].bounds=(375.000000,667.000000)
[UIScreen mainScreen].scale=3.000000 ←New!

開発者向けiPhoneの画面サイズ早見表

画面サイズの数字がよくわからなくなるので早見表作りました。

Model 論理サイズ 物理サイズ 物理/論理比
widthxheight 比率 近似 x1 x2 x3 Pixel
4s以前 320×480 2:3 2:3 320×480 640×960 640×960 1
5/5s 320×568 40:71 9:16 640×1136 640×1136 1
6 375×667 375:667 9:16 750×1334 750×1334 1
6plus 414×736 9:16 9:16 1242×2208 1080×1920 約0.870
iPad 768×1024 3:4 3:4 768×1024 1536×2048 1536×2048 1

物理サイズはRetinaモデルのものを書いてます。
iPhoneのx1サイズは3GSが最後ですので、新しいOSのみに対応するなら無いものと考えてOKです。
iPadはiPad mini(初代)がx1です。
iPhone6 Plusのみ論理座標と物理ピクセル数に差があります。

5sを基準として座標を変換するために倍率を計算しました。
(将来に備えてこの数字を直接使うのではなく、内部で計算したほうが幸せになれるとは思いますが)

Model 倍率
だいたい
5/5s 320 568 1.0 1.0 1.0
6 375 667 1.171875 1.17429577465 1.173
6plus 414 736 1.29375 1.29577464789 1.295

UTF-8をUTF-32に変換するコード

UTF-8って素晴らしいですよね。

unicodeは元々、世界中の全ての文字を16bitで表現するという英語圏以外の人からすればあまりに愚かな試みからスタートしましたが、もちろん破綻。
16bitを使いながら、サロゲートペアを使って16bit以上のコードも表現するようになりました。

結局サロゲートペアが必要な時点でUTF-16は欠点ばかりのものとなってしまいました。
最近よく使われるのはUTF-8です。ASCIIコードと互換性が保ちやすく大変便利ですね。

UTF-8は結局のところUTF-32をシリアライズしただけのものなんですが、へぇよく考えてるなぁという感じなのです。
任意のバイトストリームから混同せずに文字列を取り出せます。

ただ欠点もあって、色々処理をするときに文字ごとに長さが違うので厄介です。
そこでUTF-8から32bit表現(UTF-32)に変換するコードを書いてみました。
プログラムの内部的にはUTF-32を使うと捗りますので。

このようなUTF-8の欠点はサロゲートペアがある時点でUTF-16でも同様なんですが、サロゲートペアはあまり出てこないので無視してしまってる駄目な処理系もあるような気がします。

なお、セキュリティの観点からはUTF-8の冗長表現が問題になることもあります。
本来ASCIIコードである文字でももっと大きなバイス数で表現することが出来てしまうので不正文字チェックを抜けてしまうということです。

例えば0xC0 0xAF(11000000 10101111)は、2バイトのUTF-8として扱うと[101111]の部分がデータになりますので、0x2F(バックスラッシュ)と等価になります。
つまりより小さいバイトのコードは大きなバイト数でも表現出来てしまうため、単純チェックだとすり抜けるということです。

仕様ではこのようなバイト列は不正なUTF-8バイト列としなければなりません。
また5バイトと6バイトのUTF-8も現在ではUnicodeとしては不正とされていますがISO/IEC 10646では存在しています。
以下のコードではそのような不正なUTF-8もそのまま変換します。

unsigned long utf8ToUtf32(unsigned char *input, int *bytesInSequence)
{

	unsigned char c1, c2, c3, c4, c5, c6;

	*bytesInSequence = 1;
	if (!input)
	{

		return 0;
	}

	//0xxxxxxx (ASCII)		7bit
	c1 = input[0];
	if ((c1 & 0x80) == 0x00)
	{
		return c1;
	}

	//10xxxxxx				high-order byte
	if ((c1 & 0xc0) == 0x80)
	{
		return 0;
	}

	//0xFE or 0xFF			BOM (not utf-8)
	if (c1 == 0xfe || c1 == 0xFF )
	{
		return 0;
	}

	//110AAAAA 10BBBBBB		5+6bit=11bit
	c2 = input[1];
	if (((c1 & 0xe0) == 0xc0) &&
		((c2 & 0xc0) == 0x80))
	{
		*bytesInSequence = 2;


		return ((c1 & 0x1f) << 6) | (c2 & 0x3f);
	}

	//1110AAAA 10BBBBBB 10CCCCCC		4+6*2bit=16bit
	c3 = input[2];
	if (((c1 & 0xf0) == 0xe0) &&
		((c2 & 0xc0) == 0x80) &&
		((c3 & 0xc0) == 0x80))
	{
		*bytesInSequence = 3;
		return ((c1 & 0x0f) << 12) | ((c2 & 0x3f) << 6) | (c3 & 0x3f);
	}

	//1111 0AAA 10BBBBBB 10CCCCCC 10DDDDDD		3+6*3bit=21bit
	c4 = input[3];
	if (((c1 & 0xf8) == 0xf0) &&
		((c2 & 0xc0) == 0x80) &&
		((c3 & 0xc0) == 0x80) &&
		((c4 & 0xc0) == 0x80))
	{
		*bytesInSequence = 4;
		return ((c1 & 0x07) << 18) | ((c2 & 0x3f) << 12) | ((c3 & 0x3f) << 6) | (c4 & 0x3f);
	}

	//1111 00AA 10BBBBBB 10CCCCCC 10DDDDDD 10EEEEEE		2+6*4bit=26bit
	c5 = input[4];
	if (((c1 & 0xfc) == 0xf0) &&
		((c2 & 0xc0) == 0x80) &&
		((c3 & 0xc0) == 0x80) &&
		((c4 & 0xc0) == 0x80) &&
		((c5 & 0xc0) == 0x80))
	{
		*bytesInSequence = 4;
		return ((c1 & 0x03) << 24) | ((c2 & 0x3f) << 18) | ((c3 & 0x3f) << 12) | ((c4 & 0x3f) << 6) | (c5 & 0x3f);
	}

	//1111 000A 10BBBBBB 10CCCCCC 10DDDDDD 10EEEEEE 10FFFFFF		1+6*5bit=31bit
	c6 = input[5];
	if (((c1 & 0xfe) == 0xf0) &&
		((c2 & 0xc0) == 0x80) &&
		((c3 & 0xc0) == 0x80) &&
		((c4 & 0xc0) == 0x80) &&
		((c5 & 0xc0) == 0x80) &&
		((c6 & 0xc0) == 0x80))
	{
		*bytesInSequence = 4;
		return ((c1 & 0x01) << 30) | ((c2 & 0x3f) << 24) | ((c3 & 0x3f) << 18) | ((c4 & 0x3f) << 12) | ((c5 & 0x3f) << 6) | (c6 & 0x3f);
	}

	return 0;
}

CFBundleShortVersionStringの表記

昨日、ComicGlassのアップデートのためiTunes connectにアプリを送信したところ、CFBundleShortVersionStringが無いということで警告が出ました。(警告は出ましたがアップロード自体は受理されてステータスはWaiting For Reviewに)

ComicGlassを最初に作ったのはiOS3の頃です。その時にはCFBundleShortVersionStringが無かったようでxcodeで自動的に作られなかったので今までずっと無いままでした。CFBundleShortVersionString無いなーとは思ってたんですが、バージョンアップのとき変更するの一つでいいし楽だからいいやと放置してました。
前回までは警告出なかったので最近警告が出るようになったんだと思います。

このCFBundleShortVersionStringですが、本来はピリオドで区切った3つの数字を用いるのが正しい表記のようです。10.0.1みたいな感じですね。現在ComicGlassのバージョン表記は7.50といった2数字表記になっているのでいつか改めないといけないかもしれません。警告が出るようになったということは今後厳格にチェックが入る前触れかもしれないので・・・。
なお、現在のところCFBundleShortVersionStringが3数字になっていなくても(7.50.1ではなく7.50とかでも)警告なく通るようです。

新たにアプリ作るときは正しいフォーマットでバージョン番号を付けたほうが良いと思われます。
お気をつけください。

CentOS7にJIRAをインストール

JIRAは課題管理システムで、おそらく(というか当然)チームで使うものですが、一人で使ってみることにしました。
何やるべきかすぐ忘れてしまうので・・・。

有料なのですが、ユーザーが10人以下だと激安(US10ドル)みたいです。

インストールで予想外にハマったのでメモです。

■MySQL

CentOS7ではyum install mysqlとやってもMySQLではなくMariaDBがインストールされてしまうので手動でインストールする。
インストールしちゃった場合は削除してから。
yum -y remove mariadb-libs
yum -y remove mariadb

MariaDBでもいいのかもしれないけど、JIRAのデータベース選択肢には出てこないので一応。

インストールしたらMySQL上のユーザー等を作っておく。

なお、JIRAのデータベースは後から変更できますとりあえずはお試しで!みたいなメッセージ出ますが、あとから変更するの面倒なので最初からセットアップしたほうがいいと思います。

■JIRA

基本的にはインストーラーがやってくれるが、いざMySQL利用しようとするとConnector/Jが無いと言われるのでダウンロードして自分で入れる。
http://dev.mysql.com/downloads/connector/j/

mysql-connector-java-5.xxxx-bin.jarをJIRAのインストールディレクトリのlibに入れる。
デフォルトでは/opt/atlassian/jira/lib/

■JIRAのデータベース設定

ブラウザでポート8080にアクセスすると設定画面が開く。ウチの環境では起動後しばらくはめちゃくちゃ遅い。
JIRAが起動していない場合はservice jira startで起動

初期設定画面で日本語を選ぶと表示が崩れてうまくいかなかったので、まずは英語でセットアップした(後で変えられる)
(たぶんすぐに改善されると思いますが、表示がくずれる場合は英語にしてみてください)
なお、データベース設定に失敗したら/var/atlassian/application-data/jira/dbconfig.xmlを消すとデータベース設定からやり直せる。

なお、外からつなぐ場合(つなぐに決まってますが)ファイアウォールの設定が必要。
ポート8080を許可してください。
デフォルトのファイアウォールがiptablesでなくfirewalldになってます。
ポートの許可は
firewall-cmd –add-port=8080/tcp
firewall-cmd –add-port=8080/tcp –permanent
(上は現在の設定のみ変更、下は恒久的に変更。ただし下だけ実行してもすぐには反映されませんのでとりあえず両方実行しときます)

■Apacheでリーバスプロキシを設定してSSL経由でアクセス

SSLでアクセスしたい&標準ポートでアクセスしたいので、リバースプロキシを設定する。
これが結構面倒で、普通にApacheの設定後JIRAの設定もいくつか必要。

基本的にはここ(https://confluence.atlassian.co.jp/pages/viewpage.action?pageId=54919378)に書かれてるけど、わかりにくい。

の中の設定が必須。
とりあえず見本からProxyNameだけ変えてコピペすれば良い感じ。

加えて、配置がルートの場合は不要だが、https://xxxx/jira/ のような感じにしたい場合は

今さらSnow LeopardとXcode4.2を利用する方法

Snow Leopardの次から色々と断絶があり、現在のxocdeでSnow Leopard以前で動くバイナリを作ることは出来ません。
iOSについても同様で、iOS4.x以前向けのSDKは現在のxcodeには含まれていません。

もう無視していいかなーと思っていましたが、今だに必要になったのでメモ。

必要なもの
・Mac(MacOSX のバージョンは新しいものでOK)
 なお、Snow Leopardが動くMac実機が用意できれば何の問題もありません。普通にそれ使って下さい…。
・Snow Leopardのインストールディスク
・Xcode4.2のインストーラ

Xcode4.2の入手方法

Xcode4.2を入手する方法について困る方がいらっしゃると思います。
Xcode4.2をダウンロードしたことがあるAppleアカウントがあればAppleのサイトから再ダウンロードできます。
(Downloads for Apple Developersのページにて”Xcode 4.2″で検索)

Xcode4.2を購入した事があるか、当時有償で開発者登録しておりXcode4.2をダウンロードしたことがある場合は何の問題もなく再ダウンロードできると思いますが新規アカウントなどでは検索しても出てきません。

実はXcode4は600円の有償販売でした。よって今でも無料ダウンロードは出来ないということになっているようです。
しかも今はもう買えません・・・。
勝手にXcode4.2のインストーラを置いているサイトがあるかもしれませんが、それは違法コピーということになりますのでご注意ください。
アップルさんにはこの際無償公開して欲しいところです。せめて再販売・・・。

現在の環境構築手順

1.VirtualBox(無料)をダウンロードしてMacにインストール
 MacはMarvericksで大丈夫です。

2.仮想マシンにSnow Leopardをインストール
 特に気をつけることはなく普通にインストールできます。
 ちなみにWindowsでやろうとしても無理ですし、ライセンス的にもNGです。

3.Downloads for Apple Developersのページにて”Xcode 4.2″で検索
 ・・・ここでXcode4.2が出てこなかった方。
 大変残念ですが、ログインしているアカウントではXcode4.2はダウンロードできません。

4.Snow LeopardにXcode4.2をインストール
 ・・・「インストールが失敗しました」。となる場合はソフトウエアアップデートをかけてください。
 Appleインストーラの更新がこの時期にかかっており、アップデートしないとインストールに失敗します。

以上です。

新しいxcodeのプロジェクトをXcode4.2で開いたりするとぶっ壊れますのでご注意ください。
また、Xcode4.2で使っていたプロジェクトを新しいXcodeで開いてしまうと、二度とXcode4.2では開けなくなりますのでご注意ください。

ComicGlass、SMB2及びSMB Server対応

詳細

後日また詳細に書こうと思いますが、ComicGlassの次バージョンにてSMB2プロトコルへの対応とSMBサーバ機能が利用できるようになりました。

SMB2はWindows Vista以降で利用できるプロトコルでWindowsXP/WindowsServer2003以前で使われていたSMB1の後継プロトコルになります。
現在ほとんどの機器がSMB1に対応して動作していると思いますが、XPのサポート期限も切れ、WindowsServer2003のサポートもまもなく切れますのでSMB2以降が主流になってくるかもしれません。
Windows8以降では高セキュリティ設定をするとSMB1が使えないことがあります。

SMBサーバ機能は、文字通りSMBサーバ(ファイル共有サーバ)として動作する機能です。
WindowsのエクスプローラーからComicGlass内のファイルを読み書きできます。
書き込みはもちろん、読み出しも出来ますし、直接ファイルを開いて確認することも可能になります。
フォルダを内容を含めてコピーしたり、ファイル名をPCから編集することも出来ますのでファイルの管理やバックアップが大変便利になります。

ただし、エクスプローラーで開いたままiPhoneをスリープしたりアプリを終了してしまうとWindows側がタイムアウトするまで困ったことになりますので使い方には少し注意が必要です。
(一応、ファイルへのアクセス中は自動的にiPhoneがスリープしないように実装してあります)

実装について
SMBの実装はVisuality Systems社のCIFS NQを使っています。
製品なので、接続互換性のテストがしっかりされており、(おそらく通信相手の仕様間違いも含めて())色々な相手と正しく通信できると思います。
基本用途は組み込み向け製品向け製品なのでiOSに移植するために実装した部分で不具合がある可能性は多分にありますが、とりあえず安定した通信が期待できるのではないかと。
(一応当面は旧独自実装も使えるよう、選択式にしてあります。これまで問題なかったのに問題が起きたという場合には旧設定にしてみてください。そして発生状況を教えて頂けると大変助かります)

GoogleDrive対応

重い腰を上げて、GoogleDrive対応を実装しました。
前にAPIを少しみた段階で”うえっっ”てなって放置していたのですが、ちょっと癖があるんですよね。
基本はHTTPなので、通信内容に癖があるわけじゃないのですが、SDKが微妙に使いづらいのです。
といっても作りが悪いわけでなく、GoogleDriveだけでなくGoogleの汎用ライブラリを使っているのが原因です。

ファイルのダウンロードは比較的簡単ですが、ストリーミングが少し面倒でした。
どうしても細切れにアクセスすることになるのでパフォーマンスがいまいち。
もう通信自体Googleのソース使わずに全部独自に実装してやろうか・・と思いましたがあまりに大変すぎて断念。

また、ComicGlassではリモートのファイル一覧を開いた状態のまま、アプリのスリープ中や終了後も状態やリストを保持する機能があります。
モバイルデバイスですから、前の状態からいつでも再開できるというのは重要なことです)

ここがまた問題で、GoogleDriveが返すファイルにアクセスするためのユニークURIが時間が経つと(正確にはセッションが新しくなると)勝手に変わります。
といわけで、前回開いていたファイルが現在どのファイルなのかをマッチングする必要があります。
この辺もURIが変わったら自動的に情報を再取得することで問題を回避しました。
たまに失敗しますので、どうしてもエラーになる場合は接続からやりなおしてください。

カレンダー

2017年11月
« 7月    
 12345
6789101112
13141516171819
20212223242526
27282930  

▲Pagetop