Firebase, Google Analytics, Fabric, Apple App Analytics の個人的使い分け

昨今モバイル界隈ではアクセス解析に色々なサービスがあるが、それぞれにメリット/デメリットがあるため、複数併用するようにしている。4 つのサービスの個人的使い分けについて、iOS エンジニア視点で雑に書いていく。

なお、どれも無料枠での利用とする。

最初にまとめ

• ざっくり見たいときは Firebase を使う
• 細かく見たいときは Google Analytics を使う
• クラッシュ情報とリリース直後の状況を見たい場合は Fabric を使う
• 上記以外のデータが見たい場合は Apple Analytics 使う

Firebase

メリット	モバイルに特化しているので見やすい バージョン、コホート、デバイスなどデフォルトで多くの情報を取ってくれる ぱっと見いい感じにデータを見してくれる 最近入った STREAMVIEW というのがリアルタイムで使っている人を見れる
デメリット	Screen Transition が見れない GA で補完 詳しい情報を見たい場合は BigQuery 連携が必要 ぱっと見はいいけど詳しいところまで見れない 例えば iOS8 のユーザ数が見れない

Google Analytics

メリット	細かい情報まで見れる このカテゴリの人のこの情報 みたいな細かい指定ができる Screen Transition が見れる リアルタイム View が見れる
デメリット	細かい情報まで見れるけど、気が利かない iOS8 のユーザ数見たかったら、8.0 と 8.1 の数字出してくれてあとは自分で計算するとか なんかぐちゃぐちゃしてて見づらい

Fabric

メリット	Crashlytics のクラッシュ情報が見やすい Latest Release でアプリのリリースに問題ないかが確認できる
デメリット	Growth でユーザ分析ができるが、Firebase の方が見やすい なんかいまいち直感的に見れない Google に買収されてそのうち消える

Apple App Analytics

メリット	ソースから、どこ経由でインストールされたかが見れる アプリのダウンロード数(ユニット数)が見れる リテンションやセッション数、アクティブ数など結構情報が見れる
デメリット	まず iTunes Connect 開くのが面倒 ログインしてアプリ開いて分析ページまで遷移して...がだるい オプトインのみの情報しか見れない 30%がオプトインだから3倍ちょっとすれば数字が出るな... と頭の中で計算している

おわり

どれも便利なんだけど、いいところもあれば足りない機能もあり、結果として色々なサービスを使ってしまっている。
Firebase には一番期待していて、Fabric は Google に買収され Crahslytics が Firebase と統合されると発表があったし、STREAMVIEW というのが素晴らしく便利な気がしている。
STREAMVIEW があれば Screen Transition を取る必要もなくなるかもしれないので、とにかく Firebase に頑張ってほしい。

Mac の環境構築手順を整備した

今までも dotfiles と Brewfile を Github に置いて環境構築手順を整えていたが、 dotfiles は homesick、 Brewfile は homebrew-file というのを使っていたため管理がややこしくなっていた。

しかもそれらは全然 commit してなくて古くなってしまったため、エイヤで色々整えることにした。

Brewfile

homebrew-file を使うのはやめ、素の Brewfile を Github で管理するようにした。
下記コマンドで Brewfile を吐き出すことができる。

$ brew bundle dump --force

次回 brew のセットアップをするときは下記コマンドでいける、はず(試してないので本当にいけるかわからない…)。

$ /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
$ git clone git@github.com:starhoshi/Brewfile.git
$ brew tap Homebrew/bundle
$ brew bundle --file=Brewfile/Brewfile

dotfiles

必要な設定ファイルをレポジトリ管理するようにした。karabiner, hammerspoon の設定ファイルは実際には dotfile ではないかもしれないが、難しいことを考えるのはやめた。

これらの設定ファイルは↓のコマンドで install できる、はず。
zsh がすでに install されているのが前提なので、 brew の後に実行する必要がある。

$ git clone git@github.com:starhoshi/dotfiles.git
$ ./dotfiles/install.sh

dotfiles の設定では Deploy と Initialize を分けろとあるが「そこまでガチ勢じゃないしこのままでいいか」と思い， install.sh すればいい感じになるようにした。

まとめると

次回のセットアップでは、

$ /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
$ git clone git@github.com:starhoshi/Brewfile.git
$ brew tap Homebrew/bundle
$ brew bundle --file=Brewfile/Brewfile
$ git clone git@github.com:starhoshi/dotfiles.git
$ ./dotfiles/install.sh

これで環境が整うようになった。

レポジトリ

• starhoshi/dotfiles
• starhoshi/Brewfile

参考

• MacBookの環境構築（Brewfile + mackup） – hello-world.jp.net
• 最強の dotfiles 駆動開発と GitHub で管理する運用方法 - Qiita
• 『GitHub+dotfiles』は環境構築を一瞬で終わらせるすごいやつ | vdeep

Swift2 から Swift3 への移行がだるすぎて諦めた

1年前くらいにリリースしたアプリ があるのだが、動かなくなったというレビューがきたので修正しようと思ったのだがだるすぎる。
何がだるいかというと、 Swift3への対応が一番だるい。ライブラリを更新して、マイグレーションして… ってやらないといけないけど、そもそもライブラリがSwift3対応してなくて諦めた。

だるさ

• Swift3移行がだるい
• Swift3対応していないライブラリがある
  • ReactKit/ReactKit: Swift Reactive Programming.
  • API 通信周り書き換えだるい
  • ページングがんばってて実装してて書き換えだるそう
• xml, html の parse がだるい
• 過去の自分のコードがイケてなくて読むのがだるい
• 利用者があまり多くないので作り直してもメリットが小さい
  • レビューで「動かなくなってつらい」ってきたので利用者はいる

結局

Xcode 7.2.1 をダウンロードして、Swift2 で修正することにした。
いつまでも Xcode7 で修正できるわけではないし、Swift3の移行はだるすぎるし、そのうちこのアプリは死ぬだろう。

悲しいが、 Apple 様の進化に追従できなかった者の末路である。しょうがない。

英語の五文型

中学・高校6年間の英語をこの1冊でざっと復習する

本を読んで英語の勉強を始めた。英語めっちゃ苦手なので、とりあえず中学英語から学び直している。

1章は五文型なんだけど今まで雰囲気でやっていたので全く理解できていなかったし、本読んでもあまり理解できていない。
なので思考の整理も兼ねてまとめてみる。

本の例文など引用しているが、引用しすぎな気もする。問題があれば消します。

文型

S, V, O, C らへんのはなし。

第2文型

S + V + C (主語 + 動詞 + 補語)。

• である(be動詞)
  • He is a singer.
• になる(become, get など)
  • She became a doctor.
• のように見える[聞こえる、感じる などの五感が中心]
  • She looks young.
• の(状態の)ままである
  • I kept quiet.

第5文型

S + V + O + C (主語 + 動詞 + 目的語 + 補語)。
目的語と補語の間に「主語 + 述語動詞」の関係がある。目的語と補語の間に be 動詞を入れてみて意味が通れば良い。

• 〜を…にする
  • He made me happy
• 〜を…と呼ぶ
  • He calls me Micky.
• 〜に…するよう要求する
  • I want you to go there.
• 〜を…にしておく
  • Keep your room clean.
• 〜が…だと思う
  • I believe my son honest.
• 〜を[に]…させる(使役動詞)
  • You made me happy.
• 〜が…するのを見る[聞く、感じる]
  • I saw him walking.

第3文型

S + V + O (主語 + 動詞 + 目的語)。

補語 / 目的語

補語は He is a student. のように、 He と student がイコールで結べる。
目的語は He wrote a letter. のように、 He と letter はイコールで結べない。

自動詞 / 他動詞

目的語は動詞の動作の影響を受ける語。
他動詞は目的語が必要で、自動詞は目的語が不要。
I went. だと「私は行った」で意味わかるが、 I play. だと「私はした」で訳がわからんので I play baseball. など目的語が必要。

第4文型

S + V + O + O (主語 + 動詞 + 関節目的語 + 直接目的語)。
第4文型の順番を入れ替えると第3文系にすることができる。
とりあえず O + O は 人 + 物 というふうに覚えておくのが良さそう。

I’ll give you a pencil. -> I’ll give a pencil to you.

第1文型

S + V (主語 + 動詞)。
第一文型 にあるように、完全自動詞のみのは少ない。

There is ~ . は S が後ろに来たりする。

古い iOS アプリが Apple に削除された

www.itmedia.co.jp

これの対象になったようで、4年くらい前にリリースしたけど全くアップデートしていなかったアプリが削除された。

削除されたアプリは Anison Tube というやつで、AppStore ではもう見れなくなっている。

作ったアプリがアプリストアに14個並んでるんですよ〜って言ってたけど、13個になってしまった。

削除されるまでの流れ

2017年5月6日

Your app, Anison Tube (733552119), does not comply with one or more App Review Guidelines.

For details, or to directly contact the App Review team, go to the Resolution Center on iTunes Connect.

というメールが届く。

ああ、ついに自分のアプリも粛清対象になったのだなと感慨深い思いになる。

Apple に抗議をするかアプリを更新するかが必要のようだ。しかしこのアプリは動かないと言っても過言ではないし、まあ消えてもしょうがないという思いだったので放置した。

2017年6月10日

前回のメールから1ヶ月とちょっと後に、削除に関する2通のメールが届いた。

1通目

削除したよって内容。

Your app, Anison Tube (733552119), has been removed from the App Store due to an unresolved issue.

2通目

アプリのステータスが変更されたという内容で、これはよく見るメール。

The status for the following app has changed to Removed From Sale.

App Name: Anison Tube
App Version Number: 1.0
App SKU: com.anisontube
App Apple ID:733552119

iTunes Connect

iTunes Connect の該当アプリを見ると、 ストアから削除済み というステータスになっている。なんとかしてステータス変えようと思ったが無理そう。再度アプリをストアに出したいときは新しいバージョンを出すしかない。

価格および配信状況 > 配信可否は「すべてのテリトリで配信可能」になっているので、ここをいじってもダメだった。

どんどんやってくれ

自分が開発したアプリがストアから消されるのは悲しいことなんだけど、ユーザから見たらノイズでしかないようなアプリが消えていくのはいいことである。

Apple はどんどんやっていってほしい。

寂しさ

しかし 32bit アプリも消えていくのだろうな、と思うとちょっと悲しい。
web だと00年代のサイトとかまだ全然動いてるし、そういうサイト見ると懐かしさが込み上げてくる。ネイティブアプリはプラットフォーム依存だししょうがないけど、やっぱり悲しい。

血便がでた

昨日の夜になんかお腹の調子悪いな〜ってトイレ行ったら血便が出ていた。血便にも色々あるのだが自分のは鮮血で、痔とかじゃなくて腸がやばそうな感じがしていた。

allabout.co.jp

これを読むと良くて痔とか腸炎で、ヤバいと癌らしいので戦々恐々として病院に行った。

検査入院とか言われたりしたけど、結論から言うと癌とかではなく普通に食中毒的なやつなので何事もなく明日からも行きていける、良かった。

診察の流れ

オフィスビルの病院で診察

1. 痔じゃないか確認する

肛門に指を入れられて確かめられる、たぶんなんか変な声出た。

触診の結果「入り口すぐのところに膨らみがありそれが痔っぽいですけど念のため午後に大腸にカメラ入れる検査もしますか」という流れになる。

2. 採血

ヘモグロビンの量を測りたいので血を取ります、と言って血を抜かれる。しかし血便ですでにかなりの量を出血していたせいか採血後に失神して、起きたら知らない天井だった。

3. 大腸カメラ準備

下剤をひたすら飲む、10 分間に 200ml 飲むのを9回繰り返して 1800ml 飲まねばならない。しかし下剤はアクエリアスみたいな味がして全然飲めた。

下剤を飲み始めて 30 分後くらいにトイレに行き、やっぱり血便なのだが、それを看護師さんにみてもらう。なんか看護師さんが「こりゃ痔じゃない、大腸だわ…」みたいな空気を醸し出すも下剤は飲み続けろと言われる。

4. でかい病院に行くことになる

主治医っぽい人が「便を見ましたがこれは痔じゃなくてもっとヤバいやつなので、今からでかい病院を紹介するのですぐに検査入院してください。タクシーでいけますか？救急車乗りますか？」といきなり言ってくる。いきなりすぎて少し混乱したが、救急車ってほどヤバい体調じゃないのでタクシーで行く。

5. タクシー

乗車10秒で酔った。5分しか乗らなかったけど病院ついた時は吐きそうだしトイレ行きたいし最悪な気分だった。

でかい病院で診察

6. 採血・CTC検査

また採血した、今度は失神しないよう寝ながら採血してもらった。CTC で大腸のレントゲンもとった。

7. 大腸内視鏡検査

肛門からカメラ入れて、大腸でおかしいところないか確認するやつ。人生初浣腸をした。
カメラ入れながら腸を広げるために空気も入れるので、お腹が張ってめちゃくちゃ辛かった、お腹もずっとギュルギュルいっていた。

カメラでみてると大腸の奥の方に数カ所の出血があった。

8. 診察完了: 食中毒

カメラでみた感じ癌とかではなさそう、というか普通に食中毒じゃないですかねと言われた。おととい電子レンジで生の鶏肉をレンチンして食べたんだけど、それっぽい感じだった。レンチンなので、局所的に火が通ってなかったりとかあったのかもしれない…。

ちゃんとした病名はナントカカントカ腸炎だったけど忘れた。

9. 支払い

21000円だった、高い…。自炊なんかして適当に飯食べるより外食した方が安全で安上がりなのでは？

血便が出たらどうすべきか

1. メシを食べない
   • 大腸内視鏡検査をするためには腸を綺麗にしないといけない
   • 血便が出た以降は診察を受けるまでメシを食べない
2. ちゃんと病院にいく
   • 気合いと根性で治るやつと、治療しないと治らないやつがある
   • それは診察しないとわからないので安心感得るために病院にいけ

人生

よく考えると明日死ぬかもしれないし圧倒的成長とか意味ないのでは？パン屋さん開業したい、パン屋さんになりたい、顧客に直接価値を届けたい…

— スターホシ (@star__hoshi) 2017年5月22日

癌かも？とか思った時にちょっと人生について考えて、やっぱパン屋さんいいよなというのを昔から思っている。パン屋さんというか接客業をやってみたいのかもしれない。

迷走にも書いたけど、ソフトウェアエンジニアじゃない職もやってみたい。人生長いようで短い気がしているのでやるなら今なのかもしれない。

見たくない画像を置換する Chrome Extension を作った

chrome.google.com

Image Switcher という、指定した画像を別の画像に置き換える Chrome Extension を作った。

仕事で GitHub とか Google とか使うじゃないですか、それに自分の見たくないアイコンを使っている人がいるじゃないですか、でもその人に「そのアイコン嫌いなんで変えてもらえますか」なんて言えないじゃないですか、だから自分でなんとかした。

設定画面で from: に見たくない画像の URL を指定して、 to: で新しく表示する URL を入力する。to: はデフォルトで Image Switcher のアイコンが指定されるので、実際は from: だけ指定すれば良い。

Extension の中身は何をやっているかというと、 img.src を書き換えているだけ。

しかしこれには問題があり、

1. "run_at": "document_idle" のタイミングで実行しているので一瞬元の画像が表示される
2. SPA とかで DOM を後読みされると document_idle が発火せず置換されない
3. background-image: url(image/hoge.gif); に対応していない

というのがあるが、まあ今のところ利用に支障はないのでいいか、となっている。面倒だしたぶん自分しか使わないだろうし。

Chrome の拡張を作ったのは2年半ぶりだったが、大きく仕様が変わっているわけでもなさそうでサクっと作れた。

ソースコードも公開している。
starhoshi/ImageSwitcher

他にも作りたい Chrome Extension あるしやっていきたい。

Xcode で A valid provisioning profile for this executable was not found. が出た時の対処法

実機インストールしようとしたらなんじゃこりゃ、というエラーが出た。ググってみると iPad 側にインストールされた証明書が悪い、などと出たのだが自分の場合はどれも違った。

Debug ビルドなのに Adhoc 証明書を使おうとしてた

のが原因っぽい。

ダメな例

問題ない例

Development 証明書を使うと

問題なく実機インストールできました。

よく考えればなんで開発環境で Adhoc の使おうと思ったんだ自分は、それが間違っていた。

「強いチームはオフィスを捨てる」を読んだ

強いチームはオフィスを捨てる: 37シグナルズが考える「働き方革命」

リモートワークいいぞという内容だが、むやみやたらとリモートワークを導入しろと言っているわけではない。

ちょうど リモートワークへの努力とは何なのか - axross.io という記事が話題になっており、この本と同じようなことを言っている。

リモートワークをするためには情報がオープンでなければならない、これは必須である。しかし、これはリモートワークに限った話ではないと思う。

働き方に関わらず情報はオープンであるべきだと思う。オフィスにいたとしても裏でこそこそ動いている案件があるべきではないし、チームが違うからといって情報にアクセスできないなんてのは良くない。口頭で会話したけど議事録も何もないというのはオフィスで働いていたって起こる。

大切なのは、必要な資料や情報を、いつでもみんなの手の届くところに置いておくことだ。

これらを普段からやっていない会社がリモートワークをやるとリモートワークがうまく機能しないのは当然で、そもそもこれができてないとオフィスで働いててもストレスが溜まると思う。

弱いチームはオフィスを捨てられないのである。

「小さなチーム、大きな仕事」を読んだ

小さなチーム、大きな仕事　働き方の新しいスタンダード (ハヤカワ文庫NF)

書籍の名前は聞いたことあったけど読んだことはなかったので読んでみた。 題名の通り少ない人数(例えば一人)であっても大きな仕事が可能だからやろうぜ、現に俺たちは少ない人数で大きな仕事をやっているよ、という内容。1つの章が3ページくらいになっててサクサク読めて良い。

無駄なことはせず、小さく始め、顧客のために良いプロダクトを作ろう、という話が中心となっていて、当然のことを当然のようにやることが大切であると言っているように感じた。最近いろいろな本を読んでるけど他の書籍でも同じことを言っていて、やっぱりこういうことをするべきなんだなという感じ。

また、個人アプリ開発者なので身にしみることがたくさんあった。弱小デベロッパは広告会社なんて使えないから Twitter で拡散したり口コミなど草の根でやっていくしかない。そういうやり方でいいからやっていこうぜと書かれていて勇気付けられる。

いくつか心に残る点があったのでメモ:

失敗は成功の源ではない

失敗しないならその方が良いし、成功する人は成功する。
おっしゃる通りだ…。

量より質

中途半端な完成品より、機能を半分にした良い製品が良い。

おっしゃる通りだ。

今すぐ世に出すべき

商品が最低限の要件を満たしているなら、いますぐ世に出すべきだ。

MVPだ、リーンスタートアップだ。

見積もりを間違ったタスク

最初に2時間で見積もったタスクが全然終わらず、16時間かかると判明したとする。 もともとは2時間予定だったそのタスク、16時間かかるとわかったらやるだろうか？途中でやめる方が有益か考えた方が良い。

ひとりきりモード

コミュニケーション依存症からの依存。インスタントメッセージ、電話、メール、会議を断念しよう。

最近読んだどの本にも書かれている。

競合相手

競合相手は製品はパクれるかもしれないが、製品の中にあるあなたまではコピーできない。だからあなたが信じていることで戦おう。

これは口で言うのは簡単だが実際にやるのはかなりの勇気がいると思う、けどその勇気を出してサービスを作っていきたい。

文化

文化は作るものでなく自然と発達するもの。

弊社、文化を作ろう？みたいな働きがあってだいぶエモい気持ちになる。

ビジネスで絶対に使ってはいけない四文字言葉

need(必要), must(しなければ), can’t(できない), just(ただ), only(だけ), fast(早く・速く)。

弊社オンパレードだって思った。