アイカツ! カードの固有番号は枯渇しないのか

Posted on 2015年3月3日(火) 23:39

カードダスといえば、1998年から展開しているバンダイのトレーディングカードで、ちょうど僕が小学生くらいの時に出てきた覚えがあります。

2005年からはバーコードが印刷され、お店の筐体（ゲーム機じゃなくてカード販売機という事で風営法を逃れているらしい・・）（追記：←嘘です）でゲームと連動するデータカードダスが展開されています。
最初のタイトルはドラゴンボールだったような気がします。

プリキュアシリーズやアイカツはだいぶカード種類が多いと聞きます。
想定外に売れて、妖怪メダルのように割り当て固有番号が不足するんじゃないかと不安になります。

玩具のコードって徹底的に省略されてるじゃないですか。

さて、頑張ってシンボルを解読するぞー！
と思ったんですが、どうもコレCODE128の既存の規格そのままですね。

シンボルを読んでみます。
以下のようになります。

数値でいうと、103,33,43,20,18,17,55,43,40,46,53になります。

103はCODE Aの開始、つまり英数＋制御コードでキャラクタが構成されることを示します。(小文字含まず）
53はチェックサムですね。
計算すると確かに53になります。
最後のシンボルはSTOPシンボルです。

というわけで、このカードの固有IDはAK421WKHNです。
ちなみにカード名称は「ピンクトルテシューズ」(星宮いちご)

本当に固有記号としての意味しかないようです。ただし最初のAKはアイカツを表しているようです。

iPhoneでバーコードを読み取るプログラムを書いてみました。
結果はこんな感じ。

実はorg.iso.Code128をセットすると、iOS標準のライブラリで認識可能。数行で実装できます。。

CODE128には、コードA～Cまでの文字セットがあります。
コードAは英数字＋制御文字、コードBはASCIIのみ、コードCは数字のみ。

というわけで、DCDではコードAで記録しているようです。
データ領域は英数字で９文字分ということになります。

最初の２文字はコンテンツの種類を表しているようで、アイカツ！の場合は”AK”から始まります。
ちなみにプリキュアは”PR”のようです。まぁ、なんとなく理解できる記号ですね。

バーコードのデータ９文字から”AK”の２文字を引くと残りは７文字です。
このあたりで、もう表題に書いたことは無かったことにしたい感じですが、、

とりあえず英数字のみで割り当てるとします。
そうすると、アルファベット26文字+数字10文字の36通り×７桁なので、78,364,164,096 種類のカードを発行できることになります。

つまり780億種類以上なので、カード側の固有記号が枯渇することは全く持ってありませんね…。
AKの部分に新たな記号を追加することだって出来るわけですし。

そういえば前期プリキュアのプリカードは、パッと見ても嫌な予感のする変な切り込みがありますね。
これはたぶん玩具で読み取りを意識した、本当に省略されたコードだったと思われます。

妖怪ウォッチ ともだちウキウキペディアはどうやらQRコードに変わってるようですね。

NBNS(NetBIOS名の解決）に失敗する

Posted on 2014年10月24日(金) 01:00

タイトルのとおり。

どうも、Windows相手にNetBIOSの名前解決を試みると失敗することがあるようです。
ネットワーク・アナライザで見ると、リクエストは飛んでるのに応答が来ない。
発生条件は不明ですが、テストで変なリクエスト送ったあとに起きやすい気がするけど、何もしてなくても起きる時もある。

理由は不明ですが、一旦失敗するようになると、特定のIPアドレスから発信したものに対して応答が返らなくなる模様・・・。

全くそのままでIPアドレス変えると動くようになります。

このあたりエラーメッセージを簡略化してたので（接続できませんでしたくらいに）、次からメッセージ入れようと思います。
基本ここで失敗はしないと思っていたので。

どうもSMB/CIFS周りはロバスト性に欠けてやっかいですわー。
Windows同士でも調子わるいときありますもんね。

無駄にSMB/CIFS周り（のバッドノウハウ）に詳しくなっていく・・・。

socket()の戻り値0は正常値である！！！

Posted on 2014年10月10日(金) 21:00

ネットワークプログラミングの基本中の基本。socket()関数があります。
（基本すぎて今ではもう直接使う人はいないのかもしれませんが僕は使います。。）

socket()関数は戻り値としてソケットのファイル・ディスクリプタを返します。
このソケットのファイル・ディスクリプタが何故か現代人には勘違いしやすいようで、うっかり0をエラー値だと思い込んでしまいます。socket()はエラーが発生したときには-1を返します。
これがうっかり間違えます。実際0が返ってくることがありますのでたまに動かないという分かりにくい不具合の原因になります。

わかっているのにうっかり間違えた例が以下のような感じです。本当に良く見かけます。自分も間違えますが・・・。

int fd = socket(AF_INET, SOCK_STREAM, 0);
if (fd <= 0) {
	// COV_NF_START - we'd need to use up *all* sockets to test this?
	startFailureCode = kGTMHTTPServerSocketCreateFailedError;
	goto startFailed;
	// COV_NF_END
}

おそらくポインタを返す時の失敗はNULLだろう、ハンドルを返すときのエラーは0だろう的な思い込みがあるせいではないかと思います。
WindowsのAPIは成功すると非ゼロを返すという仕様のものが多いので、そういう普段使っている環境での慣れもあるのかも・・・。

ちなみに上記のコードはGoogle Toolbox for Macの一部にありました。

同様に

if(soc){
	close(soc);
}

みたいなミスもうっかりやりがちなのでお気をつけください。

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

Posted on 2014年9月30日(火) 23:40

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

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

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

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

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

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

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

Posted on 2014年9月19日(金) 20:14

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の廃止

馴染み深いこの２つが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と同じ解像度

Posted on 2014年9月19日(金) 16:24

とりあえず速報です。

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の画面サイズ早見表

Posted on 2014年9月17日(水) 23:30

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

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

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

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

Posted on 2014年9月8日(月) 23:53

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)は、２バイトの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の表記

Posted on 2014年9月2日(火) 23:07

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

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

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

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

CentOS7にJIRAをインストール

Posted on 2014年8月28日(木) 23:15

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

有料なのですが、ユーザーが１０人以下だと激安（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/ のような感じにしたい場合は