PlayStation5導入

ヤマダ電気の抽選販売で当たったので、買ってきました。 まだ恩恵はそんなに無いんですけどね…

Corne Cherry 破損と修理

自作キーボードのCorneCherryのキットを購入し、組み立てて利用して、早4ヶ月。そろそろ、慣れてきた頃ですが、そんな折、右側のキーボードが認識しなくなりました。

TRPSケーブルを抜いて個別に確認すると、どうやら左側は正常動作、右側は、起動せずのトラブルです。

困りましたが、仕事が押していたためその日はすぐ調査を開始せず、一旦取り外して、普通のキーボードで仕事。

時間ができたので次の日調査を開始するため、テスターを当てます。TRPSケーブルを繋いでいると、右側の正常の方が赤点滅していたので、何かなと思っていたんですが、左側のVccとGNDがショートしていました。

この時点で大体絞り込めてて、Pro Microの破損か、LEDの破損です。＊回路図見るとわかる。 切り分けのため、Pro Microを外すと、まだVcc -GNDで導通していたため、LEDの破損で確定です。

LEDの破損の場合、場所の特定が困難です。そのため、一個一個外して、Vcc-GND間の導通を確認、という手法を取ったところ、運良く、４つ目のWS2812を外したところで、導通がなくなりました。

チェックしたところ、Pro Microも動いたみたいなので、修理完了です。シリアルLEDってこんな壊れ方するんですね。静電破壊でしょうか。勉強になりました。 所要時間１時間程度でしたが、勘所がないと結構ハマるところかと思います。この辺は昔取った杵柄なのです。

ちょっとネット漁ってみたけど、同様の情報がなかったので共有しました。お役に立てれば幸いです。

Swift4 utf-8をshift-jisに変換

本来であれば、サーバ側のインターフェースはUTF-8にして欲しいところですが、諸事情によりshift-jisの文字列をクライアント側で作成しなければいけない場合があって、変換しました。あとで絶対忘れるので、備忘として。

let str = "ほげ"
let sjisStr = str.cString(using: String.Encoding.shiftJIS)

ここでそのまま表示できない形になります。
こんな感じ
[-126, -39, -126, -80, 0]

これはCのcString型になります。実態は[CChar]型です。

これを逆変換でString型に持ってくるのは

let result:String = String.init(cString: sjisStr!)

Swiftの文字列操作周りは未だにコロコロと表記が変わるのでSwift3まで使えた記法がSwift4から全然使えなかったりします。
特にsubStringがなくなってしまったので、文字列操作は結構戸惑います。慣れれば表記が統一されているので使いやすいんじゃないかと思うんですが。。。

なかなか、追っかけるのが大変な言語ですね。

Swiftの数値型と文字列変換のメモ

Swiftで16進数をゴニョゴニョする需要があって、ちょっと調べました。

まず、Swiftでの16進数(n進数)の最もお手軽な扱いは、

Stringで定義する

だそうです。

具体例を挙げると

String(11, radix:16) 　// a

とか。

ちなみに

Int("a", radix: 16)  //10

はイケますが、Intなので全て10進になります。マジかよ。

なので、計算は10進で行って表示など必要な時に、n進数に変換して表示するのがお手軽です。

で、メモなんですが、この"radix"とやら、2とか8とか16とか区切りのいい数字以外にも、17とか、7とか変な数字を17進数とか7進数にしてくれます。

で出てきた疑問。

何進数まで変換できるの？

試して見た所、36進数まで変換できました。36進数？32じゃなくて？

なんだろうとしばし考えたんですが、

0-9とA-Zで表現できる文字の合計が36文字なので、36進数になってるみたいです。

それ以上のn進数が欲しい場合は、素直に割り算の余りを使いましょう、ということみたいです。

つーか

n進数とかでバリバリ計算したいという向きの方は、素直にObjective-Cで書いた方がいいっぽいですね。

近況

ご無沙汰です。

あけましておめでとうございます。

本年もよろしくお願いします。

近況ですが、実は結婚しまして、神奈川に引っ越しました。

そんなですが、今後ともよろしくお願いします。

Macに新幹線のアナウンスを喋らせる。

気がついてみれば、ほぼ１年越しの投稿になります。

忙しさにかまけて、アウトプットするのをサボっていましたが、まあまたボチボチ更新していきたいと考えています。

最近、JXAというJavascriptでMacを動かす、AppleScriptの亜種みたいなものを覚えたので、何かに使えないかなーと思ったんですが、案外情報が少ないので、暇を見て色々試しつつ、勉強しています。

シェルでいいじゃんとか、そういう意見もあるかと思うんですが、shellScriptだとちょっと面倒な処理、例えばファイル名で判定して処理を変えるとか、出来ないわけじゃないけどちょっと面倒とか、そういうケースに対してサクッとできたらいいかも的な。あと、アプリケーションの対応次第なんですが、アプリケーション自体もJXAから弄れるらしいので、その辺で差異が存在理由なんじゃないかなと思います。

ドキュメント等を見ていると、Macのシステムの読み上げ音声で任意のテキストを喋らせる事が出来るようなので、一発目として試してみます。

最近、新幹線通勤になってしまったので、なんとなくうろ覚えの新幹線のアナウンスを喋らせることにしましょう。

まず、アプリケーション＞ユーティリティ＞スクリプトエディタを開きます。

 
function talkToMe(args){
 var app = Application.currentApplication(); // 現在のアプリケーションオブジェクトを取得する
 app.includeStandardAdditions = true; // 標準コマンドを使用可能にする
 app.say(args);
}

talkToMe("We will soon make breaf stop at ODAWARA.");

これで、スクリプトエディタで実行するととりあえず喋ります。 でもイントネーションがなんとなくおかしい。これ、システムの設定で、読み上げが日本語になっているのが原因です。なので、英語の読み上げ設定に変更します。

これで、それっぽく喋るようになりました。

JXAはシェルだと直接いじりにくいようなシステムに絡んだ設定項目なんかに対して正規の方法でアクセスできるみたいなので、何かうまい使い方がないか色々考えています。

Swiftでカメラアプリを作る。

最近、暇を見つけてはSwiftを勉強しています。
今日は半日くらいマルッと使えそうだったので、Swiftでカメラアプリなぞ作ってみました。

先人達のコードを参考にしつつ、XCode6.01のSwiftで書き直してあります。

コードはこちら。 Github

どーせ書き方が違うだけだろと思ってたんですが、全然そうでもなく、Obj-Cで書いたプログラムをそのまま書き直せば動くっていう感じでは無さそうです。
また、言語としての抽象度が上がっているので、逆に色々ハマりどころがあります。

以下ハマった所。
なかなかdeviceInputが取得出来なくて苦労しました。サンプルを持って来ると何故かnilが帰ってくるという。とりあえず、こんな感じに修正して動きました。

    var videoDevice:AVCaptureDevice?

~~~~~~~~~~~~~中略~~~~~~~~~~~~~~~~
        var error:NSError?
        videoDevice = CameraViewController.device(AVMediaTypeVideo, position: AVCaptureDevicePosition.Back)
        let videoDeviceInput = AVCaptureDeviceInput.deviceInputWithDevice(videoDevice!, error: &error) as AVCaptureDeviceInput

~~~~~~~~~~~~~中略~~~~~~~~~~~~~~~~
    class func device(mediaType: NSString!, position: AVCaptureDevicePosition) -> AVCaptureDevice? {
        var devices = AVCaptureDevice.devicesWithMediaType(mediaType) as [AVCaptureDevice]
        
        if devices.isEmpty {
            return nil
        }
        
        var captureDevice = devices[0]
        for device in devices {
            if device.position == position {
                captureDevice = device
                break
            }
        }
        return captureDevice
    }

あとイメージをキャプチャして保存するのが結構ハマりました。

 
    func takePict(sender: AnyObject){

        var layer : AVCaptureVideoPreviewLayer = previewLayer! as AVCaptureVideoPreviewLayer
        
        self.stillImageOutput?.connectionWithMediaType(AVMediaTypeVideo).videoOrientation = layer.connection.videoOrientation
        
        var error:NSError
        
        self.stillImageOutput?.captureStillImageAsynchronouslyFromConnection(self.stillImageOutput?.connectionWithMediaType(AVMediaTypeVideo), completionHandler: {
            (imageDataSampleBuffer,error) -> Void in
            if ((imageDataSampleBuffer) != nil) {
                var imageData : NSData = AVCaptureStillImageOutput.jpegStillImageNSDataRepresentation(imageDataSampleBuffer)
                var image : UIImage = UIImage(data: imageData)
                ALAssetsLibrary().writeImageToSavedPhotosAlbum(image.CGImage, orientation: ALAssetOrientation.fromRaw(image.imageOrientation.toRaw())!, completionBlock: nil)
            }
        })

    }

一応こんな感じで何とか動いてます。（正直まだ良く分からない所が多い。）

なんというか、Obj-Cよりも難しいなと思うのは、書き方のパターンが色々ある所とXcodeがまだ自動補完とか完全で無い感じの所ですね。
構造体とかの使い方が特徴的らしいので、その辺りをマスターすればよりSwiftっぽい書き方になるんじゃないかなーと思います。

参考になれば幸いです。

ipython notebookとscikit-learn

だいぶご無沙汰です。
ここの所、iOSやったりAndroidやったり色々でした。
ちょっとアルゴリズムの検証として数値計算するニーズがありまして、Rでも覚えようかどうしようかなと思っていた所kzfmさんからipython notebookとscikit-learnがいいよと教えて貰ったので、早速インストールしてみました。
インストールはpythonのパッケージ管理ツールpipが動けば全然楽勝だったんですが、最初easy_install pipしても

DistributionNotFound: setuptools==0.6c12dev-r85381

とか言われて全然インストール出来ず。ググったら親切な外人が/usr/bin/local/以下のeasy_installが複数入ってる可能性があるから一個消せば動くよって教えてくれたので、解消しました。感謝！


で、pipが動く様になったら後は楽勝です。まずは、ipythonのインストールから。あ、環境はMac OSX marverikです。

$ sudo pip install ipython

としてから、

$ sudo pip install jinja2
$ sudo pip install tornado
$ sudo pip install pyzmq

として

$ ipython notebook

ってやると、おもむろにブラウザがこんな感じで立ち上がります。こりゃ便利そう。


んで、数値計算の方なんですが、scikit-learnを動かすにはnumpy,scipyが必要なので、こちらもpipでインストールしてから、

$ sudo pip install scikit-learn

でインストール完了です。どうも途中Xcodeのcommand line toolが必要みたいなんですが、既に入ってるので、問題ナッシンでした。

とりあえず、これで準備は完了なんですが、とりあえず色々触ってみたいと思います。

コードを書く上で、最近気をつけている事について

ここの所、思う所ありコーディングのスタイルを改善しようと思い立ってます。
７月は”コード美化月間”です。

という訳で、気をつけようと思っている事を列挙します。
・インデントの徹底
Pythonですと、普通に書いていれば割りとインデント合うのですが、obj-cはインデントキチンとしてないと後で非常に読み難いです。PHPも徹底すると可読性がグッと上がるので、特に気にして書いています。

・メソッドの機能コメント
メソッドの先頭に機能のコメントを英語で短く書く様にしました。こうする事で、Xcode6Betaで出る自動補完が効かない不具合を回避出来るってのが一番の理由ですが、副産物として考えが整理されるというメリットを発見しました。（英語苦手なだけに）
割と良いかもと思うので習慣化したいです。

・１行コメント
１行コメントで１行使うの辞めました。コードの末尾に書く事に徹底。すげースッキリ。

・"=>"とか"->"とか"="とかの扱い
例えばなんですが、

  
    public  $hasOne     =   array(
                    'hoge' =>  array(
                        'className'  =>  'UserInfomation',
                        'foreignKey'  =>  'user_id',
                        'conditions'  =>  'hoge',
                        'fields'  =>  'fuga',
                        'order'  =>  'hage',
                        'dependent'  =>  false
                    )

こんな感じの所を、こんな感じに直します。

  
    public  $hasOne     =   array(
                    'hoge' =>  array(
                         'className'  =>  'UserInfomation',
                        'foreignKey'  =>  'user_id',
                        'conditions'  =>  'hoge',
                            'fields'  =>  'fuga',
                             'order'  =>  'hage',
                         'dependent'  =>  false
                    )

ラインが揃って超スッキリ。後で読む気になります。
書き直している時に見直しが入るので、間違いも見つけやすいです。

あとは、リスト内包表記で複雑な書き方しないとか、SQL文も改行入れて読みやすくするとか、後で人が読んでも恥ずかしく無い様なコードを書く習慣付けをしています。
地味なんですが、レベルアップして行く為にも必要な事だってのが何となくわかって来たので。

まあ、成果物そのものよりも、多分心がけの問題なのかなとは思いますが、いい習慣だとは思うのでなるべく続けて行きたいなぁと思っております。

iOS開発向けのコマンドラインツール、Nomadが便利そう。

ナゾの背中痛で薄ら死にそうになってるんですが、久々のブログ更新です。

アプリ開発の方が色々と入り組んで来たので、色々省力化の手順を模索していました。

こんな本読んでみたりとか、（ちなみに結構いい本。オススメ）webで情報漁ってみたりとか、まだまだ色々模索中です。

そんな中で、やりたい事、必要そうな事が朧げに見えて来ました。
何をしたいかっていうと、
・似た様なアプリを複数リリースする為に、Assets（素材）やクラスをターゲット毎に切り替えたい。
=>　ビルドターゲットの切り替えで、１つのプロジェクト内でバージョンの少しずつ異なるモノを別々に管理出来る。
=>　共通コードはそのままなので、アップデート時の事故が減る。
=>  それでも不安なので、テストを書く。
=>  ターゲットが増えると、手動でビルドしまくるのは非常に面倒だし時間も掛かる。
=>  CIツール導入検討、もしくはビルド用のシェルスクリプトを書く。

と言う訳で、CIツールを導入検討すると、オンラインで出来るCIサーバとか結構あるんですよね。しかも無償でBitbucket連携とか。
でもでも、それはwebに限った話。そもそもMacでないとiOSのCIサーバ立てられません。コンパイル出来ないからね。なんで、オンラインは無理。
そろそろ、開発用のPCもガタが来てるので、Mac miniを予備機で購入してCIサーバにあてようかと検討していたんですが、そこはちょっと保留。設定に時間取られるのがシンドイ状況なので、とりあえずもう少し時間が出来てから。
じゃあとりあえずビルド用のスクリプト書きますか、という流れです。

実はXcodeはコマンドラインツールは完備していて、シェルスクリプトでビルドからリリースまで一環して行う事が出来ます。ここにテストの工程を挟めば立派なCIの流れが実現可能です。
まずは、テストはXcode上で行って（そもそもまだ一部しか書いてない。）配布、リリース用は個別にスクリプトを書く事にしました。
つーても、コレが結構面倒です。何か楽にする方法無いのかなーと思ってたらありましたよ。こんなのが。

http://nomad-cli.com/

一言でいうと、普通に考えられるiOS開発用のコマンドライン操作を使いやすくまとめたツール郡です。機能別に都市名が付いてて、Cupertinoはアカウント管理関係。Dev Centerの操作とかが可能。HustonはPush通信のトークン周り。（コレ地味に有り難い。）
DubaiはPassBook発行関連。VenisはIn-App-Percheceの管理周辺。Shinzhenはアプリ配布やリリース関連と、イイカンジで揃ってます。
特に、Shinzhenはビルド完了時にTestFlightで配布とかを自動化出来たりします。
ただ現状やりたい事に完全にマッチするかといわれると問題があって、簡易な使い方を目指してるのでビルドターゲットの指定が出来ないです。
なので、ここはちゃんとXcodebuildでビルドスクリプト書くしか無いっぽい。残念。

とはいえ、結構使えそうなツール郡なので、活用してみますよー。

例えば：
Automator君でフォルダアクションを作成して、連携して走るshにコレ書いとけば、フォルダにipaファイル放り込めばテストフライトにアップロードとか簡単に出来る予感。


そんなお話でした。

ライブドアブログの自動投稿について

はい、ご無沙汰です。

ちょっと調べる必要がありライブドアブログの自動投稿をテストしてみて、あまり使えない事が判明したので、メモです。

自動投稿は指定のURLにAtomPubで整形した文書をリクエストするだけ。pythonなどでは普通にurllibとかurllib2なんかで対応可能。
こんな感じのURL
https://livedoor.blogcms.jp/atompub/(ここに自分のブログ)
ブログ設定でAPI Keyという項目があるので、ここで確認出来る。自動投稿をonにするとパスワードも発行されるので、メモっておく。

ブログの自動投稿プロトコルは、xmlrpcやらAtomPubやらあるみたいだけれども、それぞれ規格があるので詳細はそちらを参照されたし。

実際試してみた所、どうも投稿が上手く行く場合とそうでない場合がある。
どうやら以下の様な制限があるみたい。

• 文字数制限（大量のテキストはダメっぽい。制限文字数は未検証）
• 特定のタグを使用していると投稿出来ない（少なくともリンク付きAタグはダメだった。他未検証）
• 仕様がコロコロ変わるっぽい。しかもドキュメントが無い。

自動投稿を認めているサービスとしては、まあ普通にあり得る内容。
まあ、中々使い難い仕様ではある。編集も出来る模様なので、長文でも数回に分けて投稿すればもしかしたら通るのかも知れない。けどリンク貼れない時点で、使い途としては相当制限される印象。
実際こういう使い方したいのであれば、自前のブログシステムをWordPressか何かで作ってそこに投げた方が、制限無くていいんじゃないかなという結論でした。

そんな感じ。

Polaroid PoGoを買ってみた

最近、運動不足が極まって、腹回りがどうにもヤバくなっていて、とうとう体脂肪率が25%をオーバー。体脂肪計によれば、立派な肥満体らしいです。
という訳で、日中ヒマを見つけて運動する様に心がけています。主に自転車でブラブラするだけですが。

んでもって、ついでにハードオフに寄ったら、ジャンクコーナーでこんなの見つけました。

Polaroid のモバイルプリンタ。PoGoっつーのらしいです。

なんと、お値段¥540。
箱、マニュアル無し、動作保証無し。でも見た目は比較的奇麗。
その場で軽く仕様を調べると、Bluetoothで繋がるモバイルプリンタ。iPhoneはムリみたいだけど、Android、Macからは大丈夫との事で、試しに購入。

ジャンクコーナーだし、値段も値段だし、動かねーかなーと思いながら、帰宅後あけて見ると、中に専用用紙が2枚程入っていて、予習通り試しにMacから印刷してみると、、、

普通に動きました。

どうやらバッテリーが死んでるらしく、充電は出来ませんでした。
用紙の入手性が悪そうなので、稼働は良く無さそうですが、540円のオモチャとしては上出来な模様。
持ち歩きの時はACアタプタと一緒に持ち歩けば、問題無さそう。（電源ある所じゃないと印刷出来ないけどね）
コレだからチョイチョイ行っちゃうんですよね、ハードオフ。

plistの読み込み

毎度の事ながら、いつも忘れるのでメモ。
プロパティリスト(plist)は、アプリケーションで持たせたい初期値などを独自のファイル形式で持たせ、アプリケーションのロード時とか、結構色んな所で使うんですが、いつも忘れます。

    //pList読み込み。
    NSBundle* bundle = [NSBundle mainBundle];
    //読み込むファイルパスを指定
    NSString* path = [bundle pathForResource:@"elocution" ofType:@"plist"];
    NSDictionary* dic = [NSDictionary dictionaryWithContentsOfFile:path];

よく使う場面は、CoreDataなんかは初期値を持たせられないので、初期値を持たせたい場合に初回起動時にplistから読み込んでCoreDataに放り込んだりする処理を書きます。
あとはゲームの面データとか、そういう後から調整が必要で固有値をハードコーディングしたくない場合にも使います。
利点はデータを一カ所に纏めるので、更新、閲覧性が良い事と、後々webからデータを引っ張って来る形式にしたい場合に変更が容易です。
例えば、開発段階はローカルのplistから読み込み。途中の段階で、サーバにアップされたplistを読み込む形式に変更などといった具合。

xmlでもいいんじゃないかなーと思ったりしてましたが、実は中身は全くxmlです。拡張子違うだけっぽい。
なので、ちょっとしたツールを作れば割と大規模な初期値データなんかも比較的簡単に管理出来たりします。データ更新の必要が無ければ、コンテンツはplistで管理するのは結構現実的かと。

ここの所、全く時間が足らず。キツいです。自習時間が取れない。
おかげで色々と事は進んでいるんですが、結果として現れるのはもう少し先になりそうなので、まあアレだ。早くやれって感じです。
色んな事情で、進められるのに進まない事ってあるんですよねー。なんだかなあと思います。

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