MacBook Pro のセットアップ

By | 2014年11月10日

設定がいつもわからなくなのでメモってみた。

真っ先にすること

  • Xcode を App Store からインストール
    • MavericksでCommand Line Tools for Xcodeをインストールする
    • Dropbox をインストール
    • homebrew のインストール
      ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
      brew install ack chisel class-dump coreutils colordiff ctags findutils git gnu-sed hub keychain libxml2 readline reattach-to-user-namespace the_silver_searcher tig tmux tree vim watch wget xctool zsh

    OS の設定

    起動シェルを /usr/local/bin/zsh に変更

    * スリープするとすぐにロックするようにする

    * 修飾キーの変更 (fn キーは Karabiner で変更)

    * 三本指のスワイプでページ(コンテンツ)移動。
    * 四本指の左右スワイプでデスクトップ移動。

    * Dock の設定

    * Keyboard の設定

    Software の設定

    • Google IME
    • Google Chrome
    • Karabiner
    • iStat Menus 5
    • Google Drive
    • iTerm 2
    • BetterTouchTool
    • CotEditor
    • Firefox

    iTerm2 の設定

    * 画面サイズをいい感じにして Appearance の設定

    Karabiner の設定



    private.xml

    <?xml version="1.0"?>
    <root>
        <appdef>
            <appname>SLACK</appname>
            <equal>com.tinyspeck.slackmacgap</equal>
        </appdef>
        <item>
            <name>For Slack CTRL+N=move next channel, CTRL+P=move previous channel</name>
            <identifier>private.app_slack_move_channel_with_ctrln_ctrlp</identifier>
            <only>SLACK</only>
            <autogen>__KeyToKey__ KeyCode::N, ModifierFlag::CONTROL_L, KeyCode::CURSOR_DOWN, ModifierFlag::OPTION_L</autogen>
            <autogen>__KeyToKey__ KeyCode::P, ModifierFlag::CONTROL_L, KeyCode::CURSOR_UP, ModifierFlag::OPTION_L</autogen>
        </item>
        <item>
            <name>For Slack CTRL+TAB=move unread channel</name>
            <identifier>private.app_slack_move_channel_with_ctrl_tab</identifier>
            <only>SLACK</only>
            <autogen>__KeyToKey__ KeyCode::TAB, ModifierFlag::CONTROL_L, ModifierFlag::SHIFT_L, KeyCode::CURSOR_UP, ModifierFlag::OPTION_L, ModifierFlag::SHIFT_L</autogen>
            <autogen>__KeyToKey__ KeyCode::TAB, ModifierFlag::CONTROL_L, KeyCode::CURSOR_DOWN, ModifierFlag::OPTION_L, ModifierFlag::SHIFT_L</autogen>
        </item>
    </root>

    BetterTouchTool の設定


    開発環境の構築

    dotfile

    cd ~
    git clone git://github.com/dealforest/dotfile.git --recursive
    cd dotfile
    ./dotsetup.sh

    ruby

    cd ~
    git clone https://github.com/sstephenson/rbenv.git .rbenv
    mkdir -p ~/.rbenv/plugins
    cd ~/.rbenv/plugins
    git clone https://github.com/sstephenson/ruby-build.git
    git clone https://github.com/sstephenson/rbenv-default-gems.git
    cd ~/.rbenv
    echo "bundler
    pry
    cocoapods
    cocoapods-browser
    robocop
    tmuxinator
    cupertino" > default-gems
     
    export PATH="$HOME/.rbenv/bin:$PATH"
    eval "$(rbenv init -)"
     
    rbenv install 2.1.4
    rbenv global  2.1.4
    rbenv rehash
     
    ruby -v

    perl

    git clone git://github.com/tokuhirom/plenv.git ~/.plenv
    mkdir -p ~/.plenv/plugins
    cd ~/.plenv/plugins
    git clone git://github.com/tokuhirom/Perl-Build.git perl-build
     
    export PATH="$HOME/.plenv/bin:$PATH"
    eval "$(plenv init -)"
     
    plenv install 5.20.1
    plenv global 5.20.1
    plenv install-cpanm
     
    perl -v

    golang

    brew install go
    go get github.com/motemen/ghq
    go get github.com/peco/peco/cmd/peco
Posted in mac

プロジェクト毎に Xcode のバージョンを指定する方法

By | 2014年11月6日

ソースコードに書く方法でもいいんですけど、他にうまいことできないかなと思って少し調べてみました。
どうやら Run Script でも同じようなことができそうです。

Xcode Run Script Build Phase debugging」をみて知ったのですが、echo "error: ***" とするとビルドを失敗させることができるみたいです。
ほかにも warnings や note といったものがあるようです。

ただ shell や bash だと意図した挙動になるのですが、他の言語だとビルドエラーにならないです。

ここで重要になってくるのが Run Script の実行する順番です。
Compile Sources の前に実行するようにしないと、一度目のビルドは通ってしまうので気をつけないといけません。

gist にサンプルがあるのでどうぞ。

Crashlytics から Bugsnag へ移行したお話

logo

Bugsnag という Crash レポート解析サービスがあるんですが、最近 Crashlytics から乗り換えたので、なぜ変えたのかをツラツラと書いていこうかなと思います。
実際 Bugsnag じゃなくてもこのような機能があるサービスの方が個人的には使い勝手がいいかなと思います。

Bugsnag は$29/monthかかります

なぜ Crashlytics から移行しようとしたのか

Crashlytics は便利なんでずっと使ってるんですけど、 Crash した場合にしかレポートを送信することができないのが一番の不満(※Fabric で改善されているかもしれません)

このあとに言及しますが、Social.framework 等を利用した場合のエラーを集めたかったんですけど、そのために Crash しないといけないとか、ありえませんし。なのでそれを取得するために自分でエラー情報を集めようとして、API を用意したりしてたんですけどアプリが増えると管理も億劫になるし、なにより情報が分散してしまうせいで管理にしづらいので乗り換えることにしました。

なぜ Bugsnag に移行したのか

任意のタイミングでレポートを送信できる

さきほど少しふれましたがこれが一番重要な機能です。なぜなら端末側の設定や状況によるエラーを取得したいからです。

例えばアプリのサインインに SNS(Twitter, Facebook等) を認証に利用している場合や IAP (In-App Purchase)など、エラーの原因が端末側でしか分からない場合があります。画面には「失敗しました」などのエラー文言を表示して終わっていることが大半だと思います。

この場合、端末やユーザーの状態に依存した場合もあるし、何が原因で起きたのかが判断できないケースが多いのでデバッグするのは正直不可能です。エラー情報(NSError や NSException や API のレスポンス)があるかないかで全然違うので取得しておきたかったわけです。

Xcode 上でビルドする際にソフトウェアをインストール、設定する必要がない

Bugsnag の場合、dSYM の送信等は Run Script Phase で行っています。

デバッグしようとして気軽に試そうとしたら、Crashlytics のソフトウェアをインストールし設定しておかないとビルドできません。まぁソフトウェアの方が Crashlytics が柔軟にメンテナンスできたりするのも分かるんですけど、とはいえ初期セットアップの工程を減らしたい思いもあります。

Bugnag SDK が Github 上で公開されている

なんだかんだでソースコードが公開されてることがとてもよかったです。意図した挙動をしない時などソースコードみればどうとなりますし、バグをふんでも自分でなおして PR おくればいいので、これは本当によかったです。

あって便利だなと思ったもの

CocoaPods で SDK を管理できる

リポジトリに入れて管理するわけではないので、バージョン管理がしやすい。

iOS のみでなく Application や他のプラットフォームのエラーレポートを一元管理できる

API や Android のレポートを同じサービスで集約して管理できるのは便利ですね

Github に issue をおこせる

ボタンひとつで issue を作成することができます。これがとても便利!
issue を close すると Bugsnag へも連携して…とかはできませんが、ただ作るだけでも相当便利です。

Adhoc や Release など Build Configuration によって分けられる

あるにこしたことがないですけど、この機能がなくても Adhoc 配布の場合は拙作の dealforest/DFTDebugScreenshot をつかえば、気軽に Adhock で配布した際の情報をを集めることができます。

Adhock 配布時の効率的なデバッグについて考えてみた」辺りが参考になります。

まとめ

今のところ Bugsnag で満足しています。Bugsnag 以外でも他に良さそうなサービスがあったら教えてください。
ではでは。

Posted in ios

iPhone Simulator で zoom モードを再現するまでの過程

By | 2014年10月9日

「Xcode 6 時代のマルチデバイス対応 ~Size Classとベクター画像~」を参考にしながら 6/6 Plus に最適化させようとしていたのですが、iOS 8 から追加された zoom/standard モードを iPhone Simulator でデバッグするにはどうすればいいのかを調べていてカオスってたのでメモ。
そもそも iPhone Simulator で zoom/standard モードの切り替えができないのがどうかと思うけど。。。

先にまとめだけいうと、zoom モードにした実機でするのが一番確実

さて 6/6 Plus の解像度に対応しようとすると zoom/standard モードのサイズを考慮する必要があります。
サイズは 6 Plus の UIScreen の bounds です。
* zoom モード(375×667)
* standard モード(414×736)
* 解像度を対応させない(320×568)

6/6 Plus の解像度に対応させる方法

「Xcode 6 時代のマルチデバイス対応 ~Size Classとベクター画像~」より引用

* Launch 画像を登録する
* Launch Screen Fileを指定する

対応表

zoom/standard モードで解像度を対応している/いないかで [UIScreen mainScreen].bounds.size, [UIScreen mainScreen].scale, [UIScreen mainScreen].nativeBounds.size, [UIScreen mainScreen].nativeScale のそれぞれ値を取得してみました。

iPhone 6 Plus

bounds scale nativeBounds nativeScale
zoom – 非対応 320×568 2.000000 921.60004×1635.8401 2.880000
zoom – 対応 375×667 3.000000 1080×1920.9601 2.880000
standard – 非対応 320×568 2.000000 834.78265×1481.7391 2.608696
standard – 対応 414×736 3.000000 1080×1920.0001 2.608696

iPhone 6 Plus Simulator

iPhone 6 Plus Simulator では standard モードのみ実行可能。

bounds scale nativeBounds nativeScale
standard – 非対応 320×568 2.000000 960×1704 3.000000
standard – 対応 414×736 3.000000 1242×2208 3.000000

そこで zoom モードの解像度を再現するために Resizable Simulator を使えば可能なのでは?!と思いたって試してみました。

Resizable Simulator

起動後に w375 x h667 に変更して試してみました。

bounds scale nativeBounds nativeScale
非対応 768×1024 2.000000 1536×2048 2.000000
対応 768×1024 2.000000 1536×2048 2.000000

Simulator のサイズは変わってるけど、UIScreen の bounds が。。。
おそらくバグだと思われるけど UIScreen でほしいサイズはは Resize した後のサイズなのに。。。
UIScreen の bounds を元にしてコード上で自分でレイアウトしている場合はこれだと再現できないですね。

まとめ

AutoLayout のレイアウト確認くらいだと Resizable Simulator で確認できる。
とはいえ scale が 2 になっているためおそらく @2x を使いそうなので、その辺りの動作確認は zoom モードにした実機で確認するのが一番確実だと思います。
自力でレイアウトしている場合は何も考えずに実機でやりましょう。

あと Storyboard の preview も standasrd/zoom の切り替えはサポートしてないみたいですね。

何かいい方法があったりしたら教えてください。

Posted in ios

yidev 第16回で発表してきた

By | 2014年9月29日

先日 yidev#16 で発表してきました。
第16回 #yidev 横浜iPhone勉強会に参加してきたよ」がとても分かりやすいです。
また運営の @es_kumagai さんありがとうございました。

発表の際に @sonson_twit さんがデバッグ情報をスクショの EXIF に埋め込めば?というアドバイスをもらってそれだとコピペもできるしいいな〜と思ったので、実装しようと思ってた矢先にまさかの PR が。

仕事がはやい!!感謝感謝です。

というわけで 0.0.4 をリリースしました。
挙動は今までとかわりませんが、保存されたデバッグ用の画像の EXIF(userComment) に保存されています。

スクショを撮った時に Slack や Hipchat への自動送信の機能を考えてるので、それを実装する時にでも本物のスクショの EXIF を操作するようにしようかなと思います。

See also

* スクショを送られてきた時にデバッグを楽にするライブラリを作った

Posted in ios