やさしくわかる MVVM

@kazu0620 さん
資料: https://speakerdeck.com/kazu0620/yasasikuwakarumvvm

内容

MVC では UI とロジックが混じりがちになってしまうが、Model, View, ViewModel に分ける MVVM ではそこをきれいにに分離できる。
UI の実現に徹する View, View と Model の仲介をする ViewModel, ビジネスロジックを実現する Model のそれぞれがやること、やらないこと。
RxSwift を使う場合のコード例。

感想

最近 RxSwift の本を読んでいて MVVM が出てきたところだったので知識の整理ができて助かりました。コード例がRxSwift なのもちょうどよかったです。

DeNA における SWET の役割

@tarappo さん

内容(資料がアップされたら書き直します)

DeNA のテストチームの構成、役割など

感想

DeNA のテストチームのレベルの高さを見せつけられた！

15分で分かる Core Motion の全て

@tattnさん
資料: https://speakerdeck.com/tattn/15fen-defen-karucore-motionfalsequan-te

内容

CoreMotion
- 各種センサ(加速度、ジャイロ、磁気、高度、GPS)から様々な情報を取得できる。
- iPhoneの世代によって利用できるセンサは異なる。
実装方法
- Info.plist の設定
- 関連するクラス、メソッド
- データの取得方法
- 定期取得と期間取得
- データを取得するためにはユーザーから許可を得なければならない。
実装上の注意点
全機能を使ったサンプルアプリ

感想

CoreMotion 簡単に使えそうやん？って気がしました！

デバッグを助ける構造的差分ライブラリ開発時の悲劇・喜劇

@orga_chemさん
資料: https://speakerdeck.com/orgachem/gou-zao-de-chai-fen-raiburarikai-fa-shi-falsebei-ju-xi-ju

内容

MirrorDiffKit を使うと２つのオブジェクトの違いを diff 形式で表示でき、テストの結果表示がわかりやすくなる。
MirrorDiffKit は Mirror 構造体によって実現されている。
Mirror の悲劇
- nil が代入された Any 型インスタンスと nil は常に == が false になる。クラッシュの危険もある。
- associated value が 1 つ付いている列挙型と 2 つ付いてる列挙型で mirror した時の振る舞いがことなる。1 つのものはスカラ、2 つのものはタプルとして扱われる。
- Swift のマイナーバージョンアップでも Mirror の挙動が変わる。
以上は MirrorDiffKit では対策がなされている。
Mirror は夢が広がるがつらみも覚悟で。

感想

低レイヤな話は好きなのでリフレクションネタとして面白かった。associated value の話は聞いている時はわからなかったがこれを書きながら読み直してわかった。MirrorDiffKit は何か機会があれば使いたいなー

#　郵便屋さんの演算子

@S_Shimotori_pub さん

内容

ユーザー定義演算子として使用できる文字とできない文字がある。
- 使えそうな ASCII 文字は使える
- identifier で使える文字は基本的に使えない
- 数学記号が結構使える
- 意外と括弧はプライムが使える
- 同じ種類の文字が全部使えるわけではない
- 演算子に使える絵文字もある

感想

着目点面白い！
絵文字演算子を乱用のキラキラコード書けない(悲しみ
修論そっちのけで発表しまくっててすごい

React Nativeで開発するマルチプラットフォームアプリ

@mybさん
資料: https://speakerdeck.com/myb/react-nativedekai-fa-surumarutipuratutohuomuapuri-1

内容

ほぼネイティブでコードの大半を共有できて実績も安心感もあり流行りそうだったので採用した。
React は UI(ビュー)を構築するための JS ライブラリ。props, state というデータが変化すると関連するビューだけが自動的に再描画される。
Redux は状態管理のための JS ライブラリ。情報の流れを 1 方向にするのが特徴。React と相性がいい。
ReactNative は React を用いてネイティブアプリをつくるためのライブラリ。iOS/Android に対応。View, Text, Image 等のコンポーネントが用意されている。
- いいところ
  - コンポーネントベース
  - 思い通りのレイアウト(AutoLayout よりも CSS に近いしくみをつかう)
  - デバッグしやすい
  - パッケージもたくさん
- ツライところ
  - JS(型がない、自動度が高すぎ)
  - バージョンアップ早すぎ。破壊的変更も多い。
  - 良くも悪くも Facebook に依存することになる。(少し前に物議を醸していたライセンスとか)

感想

個人的にもチュートリアルをやってみたり本を読んでみたりとちょっとかじってみていたところで興味深かった。@myb さんはデバッグしやすいというところで挙げていらしたけど、Swift に比べると write&run のサイクルがずっと速く回せるのは大きなメリットだと思う。逆に Swift とアプリの作り方が全く異なり学習コスト大きいのもつらいところだと思う。

UIライブラリはどう設計されるべきか

@kazuhiro494949 さん
資料: https://speakerdeck.com/kazuhiro4949/uiraiburariha-doushe-ji-sarerubekika

内容

あるページング UI のライブラリを使って開発していたが、だんだん要件を満たせなくなってきたので新規開発した: PagingKit
PagingKit の使い方
改善されたこと
以下の条件を意識することで、再利用性を維持しつつクラスの共通化ができた
- インタラクションを責務に持つクラスとして切り出す
- レイアウト変更に対しては自由度が高いほうがいい
- 内部コンポーネントの配置は自由である必要がある
- addSubview(_:)やaddChildViewController(_:)で利用できるようにする。
共通クラスを開発するときは再利用性の観点で責務を意識する。実装のシンプルさと柔軟性は通常トレードオフ。
iOS で UIKit のレイヤに構築する場合には、インタラクション・レイアウト・個々のコンポーネントの順に自由度を挙げていくのが無難なのではないか。

感想

発表内容とは少しずれるけどカスタム UI ライブラリを新規開発するコストも払ってでも凝った UX を作るか、それとも既存のライブラリでできる範囲の UX にしておいて開発コストを抑えるかという判断は他の会社ではどうやってるんだろうというところが気になってしまった。