NSURLについての覚え書き。

何回かやってて、毎回ハマる所。 文字列NSStringから、webアクセスする時のNSURLConnection に渡すときの覚え書き。

NSURL *url = [NSURL URLWithString:[endpoint stringByAddingPercentEscapesUsingEncoding:NSUTF8StringEncoding]];

つうか、原因不明なんだけど背中がバッキバキで長時間作業が出来ない感じ。なんとかしてくれー。

CoreMotionの使い方

次のアプリに着手してるんですが、CoreMotionで順調にハマっております。
マジで、最高にややこしいです。やっぱ行列苦手とか言ってられないですね。

まず、最初にハマったのが、実行速度が遅い事。
全然数字あってねー、とか思ってたらガンガン処理落ちしてました。

例えば、こんな感じでCoreMotionを呼ぶのですが、

@property (nonatomic, retain) CMMotionManager *manager;
- (void)viewDidLoad
{
    [super viewDidLoad];
    self.manager = [[CMMotionManager alloc] init];
    
    //加速度
    [self startCMGyroData:50];
}

- (void)startCMGyroData:(int)frequency
{
    // ジャイロスコープの有無を確認
    if (self.manager.gyroAvailable) {
        // 更新間隔の指定
        self.manager.gyroUpdateInterval = 1 / frequency;  // 秒
        // ハンドラ
        CMGyroHandler handler = ^(CMGyroData *data, NSError *error) {
            double gyro_x = data.rotationRate.x;
            double gyro_y = data.rotationRate.y;
            double gyro_z = data.rotationRate.z;
            //testGyroRectangle.position= CGPointMake(160+160*gyro_x,240+240*gyro_y);
            testGyroRectangle.frame = CGRectMake(160+160*gyro_x, 240+240*gyro_y, 30*gyro_z, 30*gyro_z);
        };
        // センサーの利用開始
        [self.manager startGyroUpdatesToQueue:[NSOperationQueue currentQueue] withHandler:handler];
    }
}

ここで幾つか落とし穴。

• Blockの所の引数（ここではCMGyroData *data)は使わない。後述のNSLockを使う場合の障壁になる。
• 状況に依るけど、空間座標絡みは、CMRotationMatrixを使うべき。ややこしいけど、理解すれば非常にスマートに処理出来る。
• Block内で、データ取得の際は、NSLockを使う。そーすると、他の処理に引きずられる事無く、割とリアルタイムに数字が取れる。GDCでも良いかも。
• Blockの中のNSLockで記述される処理は極力減らす。（CALayerの更新とかは１つ以上だとスゲー重くなる。）優先度の低い処理は別途timerなどで処理する。

実際の所、CoreMotionの処理は中々の高負荷なので、サンプルコードまんまだと処理が重い場合が結構ある。処理落ちすると、データの追随性が極端に悪くなって、傾けたのに反映されるのが5-10秒後で全然使い物にならない事がままある。
なぜそんなに重いのかというと、カメラと重ねてたから。描画はCALayerなので比較的軽いハズなのだけれども、AVCapture自体が結構重いので、CoreMotionを重ねると激重となってた次第。別スレッドに分けるなどすれば非常に改善されるので、使用する場合はスレッド処理必須かと思う。

また、CoreMotionで取得出来るデータは、幾つか種類があるけど、加速度データは非常に扱いが難しい。
これはジャイロセンサーの特性に依るので、仕方ない。でも、極座標データに変換してくれる関数が入ってる。
取れる値は、CMRotationMatrix、CMQuaternion、CMAttitudeとあるが、それぞれ特性があるので用途によって使い分けるべきところ。
でもオススメは、CMRotationMatrix。情報が少なく概念を理解するのは骨が折れるが、概念を理解すれば、やりたい事が一発でバチっと決まる。計算量が少なく済むので、当然処理も早い。CMAttitudeはオイラー角なので、変換の計算がどうしても多くなる可能性がある。
RotationMatrixはこんな感じで呼ぶ。

        CMDeviceMotionHandler handler = ^(CMDeviceMotion *motion, NSError *error) {
            
            //引数のmotionは使わない。
            CMDeviceMotion* deviceMotion = self.manager.deviceMotion;
            
            CMRotationMatrix rotmatrix = deviceMotion.attitude.rotationMatrix;

　　　 /*各種処理*/
}

こんな感じで、rotmatrix.m11とかそんな感じの3x3の行列が渡される。 最初これ、中身の意味が解らなくて、結構悩んでたんだけど、恐らく下記の様な感じ。

    rotmatrix.m11  //デバイスのx方向を指示するベクトルを表す絶対x軸方向の座標点 　多分-1〜1の範囲。
    rotmatrix.m12  //デバイスのx方向を指示するベクトルを表す絶対y軸方向の座標点 
    rotmatrix.m13  //デバイスのx方向を指示するベクトルを表す絶対z軸方向の座標点 
   /* 以下略 */

中身が解ってしまえば、こっちのもの。後は回転行列に放り込むなりなんなりで、結構自在に操作出来る感じです。
コツは鉛直方向のベクトルは３次元位置補足済みであれば常に(0,0,-1)を示すので、デバイスの表示面がxy平面だと言う事を意識すると色々上手く運びます。
ちなみに、補足までに時間が掛かり、タマに意図せず狂うので、補正が必要です。
こーいうの結構好きなんで楽しかったです。

これを使ったアプリはリリースし次第またご報告します。

アプリをリリースしました。（してます。）

ひっそりと告知でございます。
２本ほどアプリがリリースされてます。

http://muchicoapps.tumblr.com/

一つはなんとイカと一緒に写真が撮れるという画期的アプリ、”イカメラ”。
完全に出落ちです。すいません。一笑して頂ければ幸いです。

もう一つは、色の電卓”ColorCalc”です。
RGBと16進数のカラーコードを相互変換して、保存も出来ます。
保存エリアは10個までですが、課金で増やす事も可能です。

両方とも開発期間は夕方〜の開発で一週間程。電卓の方は、年末年始を挟んだので、審査とおるのに一ヶ月近く掛かりました。

宜しければ、ダウンロードして使って頂ければと思います。
レビュー書いてくれたら、もの凄く嬉しいです。あと、アド踏んでくれたら嬉しいです。

まだまだ、リリース予定のアプリがありますので、乞うご期待です。

ここでアプリサイトをTumblrにした理由なんぞ書き連ねたいと思います。

・サーバがタダ。
まずココがデカイですね。カスタム性が高くて、最近は割と安定してますしそれで無料。

・拡散性に期待。
まだまだ狙い通りでは無いんですが、フォロワーを増やす事によって、リリース情報が拡散しないかなーと言う目論み。実験的な側面が強いです。

デメリットは
・多言語対応したいけど、そんなにページが沢山作れない。
・カスタムが結構メンドクサイ。（特にCSS,JSをどうホストするか。)

あと、この辺のプロモーションは中々難しいですね。アプリベンダーもこの辺が非常にネックなんだろうなと思います。方法論は頭で解ってても、実際ヤルとなると工数が掛かりすぎて、開発止まってしまいますしね。AppStoreが検索性悪いので、競合多いと埋もれてしまいますし。そりゃレビューサイト流行るわ。

本年も宜しくお願いします。

あ。

ッという間に年が明けてしまいました。

本年も宜しくお願い致します。

という訳で、最近のトピックを幾つか。

今までGitは使っていたのですが、ほぼ一人作業なので、ブランチ切ったりとかしないで、commitとaddの直線管理的な運用しかしていなかったんですが、先日ちょっとブランチ切ろうとしたら、上手く出来なくてキィィィイィとなってました。

環境はNetBeansを利用していたんですが、ブランチ切れてる筈なのに、切った先に切り替えると中身が何も入っていないという謎現象。
小２時間ほど悩んだ結果、コマンドラインでやったらアッサリ上手く行きました。

で、後で仲間内で聞いた所、NetBeansのブランチ機能の挙動おかしいよねって話になりましたとさ。

で、SouceTreeなるソフトを勧められたんですが、これがまたイイカンジ。
基本Gitはコマンドラインで運用するのに分かり易い作りになっているので、コマンドライン運用で全然問題無いんですが、SouceTreeはブランチの可視化機能が非常にイイカンジかなと思いました。あと脳細胞が死んでいてコマンド忘れるので、そういう向きにも良いですね。あと黒い画面を触ると死ぬ病気の人とかにもオススメです。

んで、このソフト。BitBucketなるサービスにアカウントつくるかねーって初手から聞いてくるんですが、このBitBucket何ぞやと調べてみた所、無料でプライベートリポジトリが無制限に作れるとの事。プロジェクトに参画するユーザー数で課金するモデルですね。
世に出すには恥ずかしいコードしか書けない身としては、これは有り難いです。
という訳でとりあえずアカウントだけ作ってみましたとさ。

色々環境整備に追われつつ、新しいのが出てて触ってみつつとかやってたら、新年ももう９日です。まじかー。

やっとコードが書ける感じになってきたので、ちょいと頑張りますよ。

LINEが嫌い

今更ながらですが。全然眠れないので。

LINEが出たとき、うっかりダマされて、電話帳データを攫われて以来、ぜってー使うもんかと思ってたんですが、相変わらず流行ってるみたいですねLINE。ウチのオカンとか基本連絡がLINEベースです。
アプリ開発してると、”人様の電話帳データに触るのはちょっと…”とか”データの扱い間違えたらセキュリティクラスタにフルボッコやで”とか思って自主規制してしまいますし、同じ文脈でLINEが叩かれてるのをよく見ます。
でも、正直言って、そういう自主規制こそがウンコだと思いますし、現実問題としてあれだけ受け入れられているのを見ると、全然アリなんだなと思ったりします。うん。セキュリティクラスタの人が叩く程は悪く無い。むしろ、そういう言説で自主規制を求めてイノベーションを阻害している事の方が害悪じゃねーかなと思ったりね。

嫌いは嫌いなのは全然変わらないんだけど、電話帳データを攫うのも自由なんですよね実際。良い悪いはユーザーが決める事ってのもごもっとも。嫌なら使わなきゃいいだけ。俺は使わないけどね。

って思うと、変な自主規制で縛られてる事って意外とあるよねと思ったりします。

来年はそういう既成概念を超えて頑張る所存。

つか、テクノロジーは進歩しても人間って意外とやってる事、進化してねーんだなと最近凄く思う。もうちょっとコモンセンスを身につけたり色々知恵を絞りたいです。

CoreDataでドはまり。

Objective-CのCoreDataは独自仕様のO/Rマッパー的な物で、上手に使えば便利そうなのにイマイチ流行っていない。今回は、ドはまりした事で、その流行らない一端が垣間見えたので、メモ。

CoreDataの正体はアプリ内で管理されるSQliteを上手い事覆うO/Rマッパーな訳だけれども、以下の便利な点がある。
・一貫してObjective-Cで書ける。（SQL文を書かなくていい）
・モデル構造を視覚的に設計する事が出来る。
・実装の際、データのマイグレーションなどを気にする場合は管理がナンボかラク。
大体こんなイメージである。間違ってたらゴメンナサイ。

一方、使ってみて非常に不便だなと思ったのが、
・DB内の値の確認がやりにくい。
・データ構造が簡単だとコード量が増える（SQL直書き比で）

で、今回ハマった点は、
・プロジェクトに後からCoreDataを追加する場合、非常にめんどくさい。

というのも、CoreDataはNSManagedObjectContextというのをAppDelegateで生成して引き回して各クラスからCoreDataにアクセスするんだけれども、独自仕様な上に、初期から使う事が決まっていればコードがある程度自動生成される所が、後から追加しようとするとコレが非常に面倒だった。一応出来たけど。
CoreDataを生成した生のプロジェクトとAppDelegateを比較したりして、地道にやりました。でも、理解の浅い所なので非常に手間取った。

もう何となくお作法は理解したので、今後は大丈夫かとは思うけど、CoreDataを使う場合は設計の初期段階から使うって決めウチした方が楽です。
作り始めてから、データの永続化の仕組みなどが必要になった場合は、とりあえず他の手段を検討してみる事をお勧めします。

スターエンジニアに関する考察

いろんな所のCTOやスターエンジニアと呼ばれる人たちを見て、最近こんな事を思う様になった。

僕は1994年、理系の単科大学に入学した。で、その中で色々、コイツはスゲぇって人を見ているんだけど、一般的に出来るプログラマと言われるレベルの人は、理系の単科大学の電子、情報あたりにはそれこそゴロゴロ居た。

大学生の時からLinuxのコミッタをしていたり、限られたメモリで職人的なプログラムを書く人がいたり、シュミレーションを書かせたら右に出る物は無いとか。

僕自身も、ポケコンの性能を最大限引き出したツールを書くのが得意で、NANDを並べて論理回路を組むのには天賦の才があると思うくらい、出来たしすんなり頭に入って来た。

何が言いたいのかというと、多少の差こそあれ、各人何かしら得意なフィールドがあって、その分野なら第一線っていう事をよく見たという事。

今、スターエンジニアと言われている人たちを見ると、各人それぞれ得意な分野がある中で、得意分野が今関わっている業務内容とマッチしていて、甘んじず他の分野に枝葉を広げた結果であるんだろうなと思った。

技術の世界は積み重ねの結果であり、今注目されていてもそれは誰かの作った成果物の上に成り立っているんだって事は、忘れてはいけないって思うんだよね。
確かに相当大手に行かないとNANDを並べて論理回路を組む才能は発揮出来ないかもしれないけど、そういうのが得意な人の成果が今のコンピューターを縁の下から支えてる訳で、スターエンジニア扱いでは無いけれども同じ様に重要でスゴい仕事をしている事には変わりがないんだと思う。
という訳で、エンジニアは自分の得意な分野を見極めて、それを生かす戦略を考えたらいいんじゃないかなと思いました。