Crashlytics から Bugsnag へ移行したお話

By | 2014年11月6日

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

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

By | 2014年9月3日

バグってんだけど…これちょっとおかしい…デザインくずれてんだけど…
といわれてスクショだけ送られてきたことが一度はあるかと思います。
(まぁどういう状況なのか見た目から推測できるので無いよりもマシだけども…)

さて、スクショだけを送られてきてバグってるといわれた時に何が困るでしょうか。

それは情報が足りずにデバッグを始める前に情報集めをしないといけないことです。
当然ユーザーのための画面にエンジニアが必要な情報が出ていることはまずないでしょう。

個人的にはこの情報を集めるのがクソめんどくさい!!!!!1

送ってきたユーザーはだれ?
デザインが崩れているデータはどれ?
自社で API も開発してる場合は原因はサーバーサイド?それともクライアントサイド?

スクショを撮った時に表示されてる UIViewController からなら上記のような疑問を解決するのは容易なのに…と思いながら、それらを特定するための情報を集めるところからはじまります。

リクエスト先の API が自社の場合だと Access Tokenと Request Parameter が分かれば、
実際にリクエストを送り原因がサーバーサイドなのかクライアントサイドなのかを特定することができて便利ですね。
(Access Token を出力する場合はセキュリティ上、注意が必要なので自己責任でやってください)

また UIWebView を使用している Application だと特定の WebStorage や Cookie が見れたらデバッグが捗るかもしれません。

デバッグに必要な情報は画面(UIViewController)毎に異なります。

前置きが長くなりましたが、デバッグに必要な情報を揃えてるプロセスがそもそも無駄だなと常々思っていました。

それを解決する方法を思いついたのでライブラリにして公開しました。

dealforest/DFTDebugScreenshot

方法はシンプルでデバッグ情報がほしい UIViewController に - (id)dft_debugObjectForDebugScreenshot
を定義し、デバッグに必要なオブジェクトを返すようにしておけばスクショを撮った際に、そのオブジェクトの description した結果が画像として出力されます。

demo

CocoaPods にも公開しているのですぐに使えます。

長くなってきたので、ライブラリの詳細については別エントリーにしようと思います。

yidev 第16回勉強会 で発表する予定なので、この辺りのことをまとめて話せればと思ってます。
もし他で話す機会があれば話そうかなと思います。

ではでは。

おまけ

Homebrew や PromiseKit で有名な Max Howell(@mxcl) 氏に公開してすぐにスターをつけてくれたのでやる気に満ち溢れています。

Posted in ios

Peco & ec2list で快適にEC2インスタンスにSSHする

By | 2014年7月1日

AWSのAPIをカジュアルに」の 24 ページ目に”Unix的な小道具を作る”とあるのですが、これがとても便利そうでした。
何をするのかというと EC2 インスタンスの一覧を取得し、選択したホストに SSH します。
というわけでさっそく Zsh に設定してみました。

事前準備

IAM Management Console」に登録して API へのアクセスキーを発行し、~/.aws/config に保存しておきます。
ここで Policy の設定をミスっていて API にアクセスできなかったので確認しておくと変にはまらないかと思います。

Peco をインストール

Homebrew を使っている場合

$ brew tap peco/peco
$ brew install peco

Go の環境がある場合

$ go get github.com/peco/peco/cmd/peco

ec2list をインストール

$ gem install ec2list

(※) ec2list は memoize しているので毎回リクエストが発生するわけではありません。

$ ec2list

これで一覧が表示されていれば成功です。
default 以外の profile を使用する場合は以後、 s/ec2list/ec2list –profile [profile名]/ で置換してください。
エラーがでる場合は Policy の設定がおかしいか、~/.aws/config の設定がおかしいかだと思います。

Zsh の設定

$ ec2list | peco | cut -f 3 | xargs -o -n 1 ssh

このコマンドで選択したホストに SSH ができれば成功です。
毎回これを実行するのもめんどくさいので alias か、もしくは keybind を設定しておけば幸せになれるかと思います。

alias

[~/.zshrc]
 
alias peco-ec2ssh="ec2list | peco | cut -f 3 | xargs -o -n 1 ssh"

keybind

[~.zshrc]
 
function peco-ec2ssh() {
  echo "Fetching ec2 hosts..."
  local selected_host=$(ec2list | peco | cut -f 3)
  if [ -n "${selected_host}" ]; then
    BUFFER="ssh ${selected_host}"
    zle accept-line
  fi
  zle clear-screen
}
zle -N peco-ec2ssh
 
bindkey '^q' peco-ec2ssh

これで ^q を押せば SSH できるようになりました。
便利ですね。

Peco と ec2list の組み合わせでやりましたが、ec2ssh‘$ grep -E ‘^Host[[:space:]]+[^*]’ ~/.ssh/config | peco | awk "{print \$2}" | xargs -o -n 1 ssh’ の組み合わせでもいいと思います。

ではでは。