K君の話

友達に”K君”という人が居て、K君は僕が今まで生きて来た中で出会った人の中ではトップクラスのバカで、どういうバカかというと、仕事で車使うのに全然平気で飲酒運転とかしちゃうし、それでオマワリサンに捕まって、免停になっても平気でクルマ乗っちゃう感じのバカです。（※たとえ話です。）

飲みながら話をした時に、あんまり反省してないっぽかったので、ちょっと今までに会った事のないタイプの人だなあと面白く観察しておりました。
非常に愛嬌のあるキャラクターで、コンプアライアンスの概念が欠落している所を除けば非常に面白い男で、皆に愛されております。
そんなK君は30代も中盤。結構いいオッサンです。で、K君と仲良しなM君というのが居ます。
M君はまだ20そこそこ。見た目はまぁ、ヤンキーです。黒地に金の刺繍の派手なジャージ上下で見かける事が多いです。僕は最初結構偏見持ってたんですが、これが見た目に反してすげー良い若者で、もの凄く純だしモラリストだし仕事もスゴくマジメに取り組む好青年です。

K君とM君はスゴく仲が良くて、お互いの家に入り浸ったりしてます。例えるなら、まるで大学生のツレ同士が仲良くしてる感じの付き合いです。
K君は色々バカだけど、僕がK君の事を一目置いてるのは、年齢が一回り以上離れた人とも全然フラットに付き合える事。
自分に置き換えて考えてみると、10以上違う人って以外と共通の話題が無かったりするんだよなーと。お互いの家にふつーに行き来するレベルまで仲良くなるのって、自分の中の相手に対するハードルをもの凄く下げないと出来ない事な訳で、多分K君が愛されキャラなのは、誰に大しても抵抗無くハードルを下げられる所にあるのかなと思ったりします。コミュ力が高いってこういう事なのかな。

でも二人は、客観的に見ると田舎のフツーのDQNなので、”身内にはスゲー甘いけど外野には異常に排他的”という特徴があります。共通の知り合いの紹介とかだと一気に身内扱いですが、そうでないと、ただのDQNです。なんなんでしょうね、この傾向。

さておき、後生畏るべし。という言葉がございますが、M君に限らず、最近の知り合う若い人は良く出来た人が多いです。自分に当てはめてみて、俺20の時こんなしっかりしてなかったよーと思う事しばしばです。なんというか、着実に前の世代からの失敗から学んでる感じがします。例えば意外と結婚が早かったりしてね。こういう所は逆に色々学ぶ所が多いなと思う事しきりです。

最近、この二人には会ってないんだけど、ふと思い出したので。K君元気かな。

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を使う場合は設計の初期段階から使うって決めウチした方が楽です。
作り始めてから、データの永続化の仕組みなどが必要になった場合は、とりあえず他の手段を検討してみる事をお勧めします。