iOSDC2017 前夜祭に行ってきました。
続きを読むpotatotips #43 の iOSブログまとめ枠で参加させていただきましたのブログです。
会場の Money Forward さんのオフィス。プレミアム会員になるぐらいにはお世話になっているのでテンションが上がる。
会場。とにかく新しくてオシャレという印象。
社員さんがいらっしゃったので、
「LINE Pay に対応して最高に便利になりました」
「bitflyerやmaneoとか銀行以外にも手広く対応してるのありがたいです」
「ただアプリで開くとあまりに堂々と総資産が表示されすぎて出先で開きにくいので非表示にするオプションをつけてくれ」
などなど日頃の感想を言いたい放題言いました。
以下発表内容です。間違いや気になるところなどあればご指摘ください。
BLEデバイス(peripheral)がアプリから見つからない(フォアグラウンドのスキャンでは引っかかるが、バックグラウンドだけ見つからない)ということがあった。
まずバックグラウンド特有の制限に引っかかっているのではないかと考えたが違った。アドバタイズ間隔が広すぎるとバックグラウンドで検知できないのではないかと考えたが、それも違った。
その後、BLEスニファーというものを使って、BLEの伝播をキャッチして通信内容を見た。iOSだとスキャンレスポンスは無視されるのだが、スキャンレスポンスにService UUIDが乗っかっていたのがわかった。
どうするか?iOSは過去に接続したことあるBLEデバイスのIdentifierを記録しているので、これを指定すればスキャンせずに接続要求できる。ベストプラクティスに従うと吉。
nRF Connect、BLEに触れてしまったカルマを背負うものの端末にはだいたい入っている気がする #potatotips
— どくぴー (@e10dokup) 2017年8月28日
BLE扱うのなかなか大変そう。どういう風に対処していったか、細かく紹介されていて参考になりました。
www.slideshare.net
まずVIPERの説明。VIPERとは
の5種類のModuleを使ってアプリを構成していく設計。
それぞれに Input と Output の protocol を持たせて、どういうI/Fでモジュール間のやりとりをするのかを規定する。Generambdaという自動生成機を使えばModuleを簡単に生成できて便利。
Routingは全Moduleを知っている唯一の存在。これに hyperoslo/Compass をつかうとすごく良い。
hyperoslo/Compass は、画面の呼び出しや機能の呼び出しを一括で文字列のスキームとして扱えるので、Routingを1モジュールでやる場合に相性が良いとのこと。
2つ目のtipsは時間がなくて終了。(Storyboard のインスタンス化をenumを使って便利に安全にやるというやつっぽい)
VIPER、何度も名前は聞いててMVVMで足りないときちょうど良さそう、という印象。
実際に使って作ってみたことがないのでそろそろ作ってみたい気分になりました。Generambda も使ってみたい。
Firebase Realtime Database を 良さげに Swift で抽象化した話。
Firebase Realtime Database はでっかいJSONをみんなで読み書きするようなイメージのDB。オフラインで読み書き可能で、再接続時に自動的にサーバーと同期してくれるのがお気に入りとのこと。
Firebase自体は便利なのだが、JSONそのまま扱うとぐちゃぐちゃになりそうで、抽象レイヤー(Repository層)を作りたいと思った。具体的にはモデルをプロトコル志向っぽく定義して、それらのプロトコル使って読み書きメソッドを共通化する。
たとえば RxSwift の Single<T>
を返却する fetchAllFromFirebase<T: FirebaseSchemaMaster>()
とかを定義して(FirebaseSchemaMasterは今回定義した、Firebaseのモデルが準拠するプロトコルで、マスターテーブルっぽく使う)、その中で firebaseDBRef を使う。
こうすることによって、FirebaseSchemaMaster に準拠しているモデル型は、fetchAllFromFirebase()を呼ぶだけでよくて、Firebaseに関する実装から切り離すことができる。
Repository層を導入したくなった動機として以下が納得感が強かったです。
Firebaseの抽象層をちゃんと作りたかった理由もう一つ、FBの機能ありきのコードがアプリ全体に散らばるのが一番最悪だと思っていて、適切に抽象化して特にUI層と切り離しておくことでFirebaseを辞めなきゃいけなくなったときに傷を浅くできるかなと #potatotips
— 🙌🐼ひらり🐼🙌 (@hiragram) 2017年8月28日
たしかにテストのこと考えても抽象化しておいたほうがよさそうです。
全く同じ理由で抽象化してます。その結果Mockを差し込みやすくなって、UseCaseのUnit Testがしやすくなりました。
— Daiki Matsudate (@d_date) 2017年8月28日
本筋に関係ないですが try
で JSON の値を取得してる拡張すごく直感的で良いので使ってみたいと思いました。
5分で理解が追いつかず hiragram さんには懇親会で色々質問しまくってしまったのですが丁寧にお答えいただきありがとうございました。
受託したアプリでFirebase使った。サーバーサイドが書けないのでmBaaS使いたかった。mBaaS の他の選択肢として、ニフティの NCMB を使うこともできたが、今回はプッシュ送りそうなのでFirebase を使ってみた。
手前味噌ですが140文字でいい感じにまとまったので貼ります。
Firebaseのストレージの画像URLが取れなくてSDWebImage使えなかったが、firebase/FirebaseUI-iOS使ってfirebaseStorageのrefをSDWebImageに渡すとSDWebImageが拡張されててよしなにできる #potatotips
— Kazumasa Kumamoto (@kumamo_tone) 2017年8月28日
Qiitaに追記されてましたが、本質的な原因は、downloadURL ではなく、 content-type が application/octet-stream になっていたからとのこと。
アップロードの際に content-type を image/jpeg などにすると、 downloadURL をそのまま指定してもいけるとのことでした。
downloadURL() で public なURLが取れるので、アクセス許可周りはいじらなくても大丈夫とのこと ( http://qiita.com/k-boy/items/3d6aa6c26a0c6510320e#comment-e712b0c042bcb5554765 )。
発表しっぱなしではなく、TwitterやQiitaコメントを拾って、本記事にスピーディーに反映していたのが素晴らしいなと思いました。
danger は プルリクエストで人力"you forgot to …" をしないように予めルールを定義してCIでチェックできるツール。
最初にRuby版のDangerがあり、最近DangerJSというのができた。そしてごく最近danger-swiftというのができた。Ruby版は cookpad/dokumi というOSSがベースになっているらしい。
CI回さずにコンソールからでも実行可能で、GithubからPRの情報を取得してwarn関数で出力することができる。
danger-swiftでは Dangerfile(設定ファイル)をSwiftで書ける。DangerJSを中で使っているぽくて、ステータスは開発中。
danger、話を聞く度に、すごく良さそうという気持ちにはなるのですが、後回しになっていて、そろそろ触ってみねばなという気持ちになってきました。
同じく jp_pancake さんの以下のスライドでは、fastlaneやRxSwiftでの事例も紹介されています。もっとガッツリ使うとどうなるのかも気になるところ。
Natural Language Processing and your Apps というWWDC2017のセッションのざっくりした内容と、裏側で使われている技術について。
セッションの内容に、ファーストパーティアプリでどのような活用がされるかという話があった。iMessageアプリで、予測変換で最初サジェストされていなかった語が、Webページを読むにつれ学習されていってサジェストされるようになるなど。
おそらく、固有表現抽出というのを使っている。固有表現抽出というのは、固有名詞、時間表現などをテキストから抽出する技術。 固有表現抽出の活用どころとして、Watsonなどの質問応答システムなどがある。
固有表現抽出とは何か?たとえば、「渋谷で明日19:30から予約できる店を探して!」とチャットボットに送ると、固有表現q=渋谷, 明日19:30を抽出する。
逆に、「昨日あった地震の最大震度、マグニチュード、震源地について知りたい」とやると、それに関して書いてある文章から固有表現を抜き出してというパターンもある。
固有表現抽出をするには、知識ベースで規則を定義しまくるか、SVMなどで学習することになる。でもNLP API ではそこら辺考えずに結果だけ使うことができる。
時間の都合上削った内容も含まれている完全版のスライドはこちら。
SiriだけでなくAmazon Echo, Google home, Clovaなどの音声スピーカーの台頭により、音声認識や自然言語処理に関してはこのあたりこの先盛り上がっていくことは間違い無しなので、ここらへんのカジュアルな話がアプリ開発者向けにアレンジされている発表は個人的にありがたい感じでした。
固有表現抽出の説明がとてもわかりやすくて、人に説明するときに使いたいなと思いました。iOSDCの発表も楽しみです。
Int型の連番のEnumのすべての要素を取得できるマイクロライブラリを開発したのでその紹介。
enumにどういうcaseがあるのか全列挙したり、要素の数が知りたいときに、自分で定義した Enumerable に準拠させれば、 .elements
と .count
でそれぞれ取れるようになる。
Hashable に準拠していれば使える版のブランチも用意しているとのこと。
内容自体はシンプルなextensionで、なるほど〜で終わってしまいそうですが、ライブラリにしていい感じに共有する行動力と瞬発力が素晴らしいなぁと思いました。
ちょうど自分のお仕事で関わっているリポジトリでも同じことやっている人が最近いらっしゃったので、個人的にタイムリーでした。
懇親会ではピザとポテチなどをいただきました。ポテチうまい!
全体的にバリエーションに富んだ発表でとても面白かったです。また参加したいです(毎回言ってる)
potatotips #42 の iOSブログまとめ枠で参加させていただきましたのブログです。
potatotips特製ポテトチップス #potatotips pic.twitter.com/plXo9YWRDa
— Kazumasa Kumamoto (@kumamo_tone) 2017年7月25日
手作りポテチ #potatotips pic.twitter.com/Bk27mvgh1e
— Kazumasa Kumamoto (@kumamo_tone) 2017年7月25日
様子です。クックパッドさんで開催されたのですが手作りポテトチップス以外にも手作りの料理(プロの仕業だとか)がテーブルに並んでおり大変おいしかったです。
では以下発表内容です。
HEVC(H.265)は、よく使われているH.264に比べて圧縮率2倍の映像コーデック。
このHEVCを、HLS(アップルが自社iOS向けに開発した、HTTPベースのストリーミングプロトコル)で配信しようとしたとき、うまく再生できないことがあった。原因はbitstreamがhev1になっていたから。
HEVCにはhev1とhvc1の2つの種類があり、iOS11/High Sierra で再生できるのはhvc1のほうだった。MP4Boxを使うとhvc1に変換できる。
というわけで、iOS11にHEVC動画をHLS配信するときは、bitstreamに気をつけましょうとのこと。
CoreMotionは端末の傾きや歩数など、デバイスの動きやそれからわかる人の動きなどを取得できるフレームワーク。iOS4から提供されているが、iPhone5s以降のコアプロセッサM7以降で大幅機能強化された。
使ってみて気づいたこととして以下のようなことがあった。
iOS11の新機能にも触れられていました(あんまり更新されてないなという印象)。ほぼ全機能を使ったCoreMotionのサンプルアプリを作ったので、CoreMotionを使ってどういうものが取れるか興味ある方は試してみてくださいとのこと。
NSAttributedString にはいろいろつらいところがある。
など。そのため NSAttributedString を簡単に扱えるライブラリを作った。メソッドチェーンで設定できて、使用例として、スライド中では激安感(お店のPOPとかでよくあるやつ)を表現するサンプルコードも紹介されています。
ライブラリは以下で公開されていて、issue、PR、コメントなどお待ちしていますとのこと。でも一番嬉しいのはスターとのこと(それはそう)
ベラルーシであったMobile Optimized 2017というカンファレンスに行ってきた。招待された経緯はオフレコ。
招待されるまでに、以下のような活動をされていた。
勉強方法として、WWDCのセッションやRealmが公開しているトークを聞いたり、Podcastを聞いたり、Slackでの英語のやり取りというのを挙げられていました。逆に、英会話や、TOEICなどの試験勉強はしたことがない(受けたことない)。
国際カンファレンスでは、英語が得意でない参加者もいたりして、下手な英語でもOKなのでゆっくりはっきり話すことが重要、英語のうまさよりいかにトークに惹きつけるかが重要とのこと。
スライドは公開され次第追加します(発見できていないだけでしたら申し訳ありません)
Autolayout が矛盾していたりしてコンソールにエラーが出たとき、意味不明でつらい。しかし、
しておくとエラーのメモリアドレスで表示されていた部分が、指定した Identifier になって読みやすくなる。
また、unsafeBitCastを使うとメモリアドレスから任意の型のインスタンスを得ることができて、たとえばUIViewにキャストして、背景色を変えるとか、色枠をつけるとかができる。
これを利用して、アドレスを渡すと対象のViewに色枠を付けてくれるLLDBプラグインをつくったとのこと。以下のブログで紹介されています。
スライドは GitPitch 形式で公開されています。 https://gitpitch.com/ezura/P_Swift4_Range/master?grs=github
Swift3 までの Range は、 Range
(0..<5.0
) ClosedRange
(0...5.0
) CountableRange
(0..<5
) CountableClosedRange
(0...5
) の4種類だった。Closed〜
は 閉区間、 Countable〜
はInt刻みとか、離散的な空間を表す。
Swift4 では One-sided Ranges が追加され、 ...i
のような、片側だけの範囲指定が可能になった。 (今までは0...i
のように両側指定するか、 let greeting = s[s.startIndex..<i]
のような冗長な書き方が必要だったが、可読性が向上した) 具体的には新たに PartialRangeFrom
(5.0...
) PartialRangeUpTo
(..<5.0
) PartialRangeThrough
(...5.0
) CountablePartialRangeFrom
(5...
) が追加された。
また、Swift3まではRangeを表すprotocolがなく、それぞれのRangeは独立した存在だったのですが、Swift4 では protocol RangeExpression
が追加され、すべてのRangeが準拠することで、統一的に扱えるようになった。
スライドでは具体的な使いかたも併せて紹介されています(zip(1..., ["🍎", "🍇", "🍐", "🍓"])
ができるのは面白いなと思いました)。文字列だけじゃなくてArrayの範囲だとか、発表者のezuraさんは最近、発表資料を作る前に技術的な部分をマインドマップで整理してるとのことで、coggleでまとめたものを公開されていました。併せて読むと理解が深まると思います。
最近、発表資料を作る前に技術的な部分をマインドマップで整理してる。発表という形態の持つ制約がない分書きやすい。これを作ってる過程が最高に楽しい ( ˘ω˘)https://t.co/dHm1rQDcay
— ezura (@eduraaa) 2017年7月26日
Ajimiというフィードバックツールを作ったので紹介。誰でもいつでも簡単にという意味合いを込めてAjimi(味見)。
フィードバックは大変。スクリーンショットを撮って→GHE開いて→issueを作る→スクリーンショットを貼り付け→どのデバイスで、どんなバージョンで使ったのかを書く…この一連の動作を自動化したかった。
既存のものとしてbalto、Instabug、SupporterKit(DeployGate製)を調べた。共通してSDKがある、画像と動画が扱える、コラボレーションツール(GithubやSlackに投稿する)などの利点がある一方、議論される場所が分離されてしまうという欠点もあり、それらを意識して作った。
GHE、deploygate、Gmazeを使っている。スナップショットを取る機能と、ビデオを撮る機能。ビデオは5秒間撮影可能で、 勝手に gif にしてGithubにアップロードしてくれる。課題に感じていることは、現状誰が投稿したのかわからないこと、GHEを使っているので社外ネットワークから使えないこと。
コードはGithubで公開されています。
Vision Framework は、iOS11で追加される、顔認識や特徴検出、画像の分類など機械学習の機能が使えるフレームワーク。同じくiOS11 で追加される Core ML が内部で使われていて、端末単体で動作することができる。
これを使ってバーコードリーダーを作った。 CIBarcodeDescriptorというのを使うとバーコードが取り出せるはずだ、と思ったができなかった。
正確には、バーコードの検出自体はできたのだが、CIBarcodeDescriptorにISBNコードの取得する関数などがあるのではないかと思ったのだが、実際には何も実装がなくISBNコードを取得することができなかったとのこと。ただバーコードの位置と、検出したものがISBNだということは分かっているもようで、ISBNコードの取得自体もそのうち対応される可能性はあるだろうとのことでした。
気合を入れないとインターネットに投稿できない。
一方、エンジニアとしては、できるだけ多くアウトプットして、考えを整理することや、フィードバックを得る機会を増やすことが重要と思う。
バランスを取るため、技術の話題に関しては、自分の中でできるだけフィルターを掛けずにpostして行こうと思う。
経験的にすぐにはうまくいかない気がするが、徐々にやっていこうと思う。