5/31 Wantedly 技術見学会 〜iOS編〜に参加してきました #WT技術見学会
こちらの勉強会にブログ枠で参加してきたので報告します。
Wantedly People ViewModel with Rx@杉上 洋平さん
- Wantedly People
- 3ヶ月でリリース
- 名刺を複数同時に撮影して取り込むことができる
- ViewModelのイニシャライズ
- ViewModelとUIViewControllerを疎結合にする場合
- ViewController作ってViewModelが普通だが、ViewModelを予め作っておくことができる。
- 特に何もなければイニシャライズ時に注入でも
- ViewModelの入力精査
- Rxで空白除去してからdependenciesで渡ってきたバリデーションを適用するなど
- ValidationResult
- Rxのサンプルに載っている
- ViewModelの通信処理（通信中とリトライ）
- アラート内に「もう一度」ボタンがあるケース
- Wireframe
- 厳密にはControllerを介さなければいけないが、そうすると綺麗に書けないのでMVVMには反するが限定的にWireframeを返して通信中とルーティングを扱えるようにしている
- Realm中心設計
- 通信が成功した時にRealmに保存している
- 名前を変更した時に一覧、詳細画面にもその変更が反映されてほしい
- Relamで書いてNotificationで伝えることによって書き換えがスムーズに行える
自分が理解できるレベルになるまでメモを取っていたのでかなり長くなりました。資料に既に書かれている部分はなるべく消したつもりです。Realm中心設計については以前別のスライドでも紹介されていました。
Wantedly Peopleのスキャン画面の裏側@後藤 慎一さん
- スキャン画面の処理の流れ
- 名刺検出
- 検出をフィードバック
- シャッターボタンを押す
- リサイズ、アニメーションなど
- 画像アップロード
- OCR
- クラシフィケーション（名前、会社名）
- 表示
- Wantedlyデータとのマッチング
- レスポンス描画
- 不安定な検出結果への対処
- 3枚目のフレームを1つのシーケンスとして扱う
- 最も良いフレームを投票して決定
- トラッキング中でもシーケンスを考慮している
try!Swiftでもスキャンの話をされており（スライドはこちら）、今度は違った角度で様々な苦労を知ることができて面白かったです。
Wantedly Peopleの連絡先一覧について@多和田 侑さん
- 単純なデータ同期
- クライアント側でフェッチ時間を保存
- それをパラメータで渡してフェッチ
- データ取得時にどのプロパティが欲しいという指定ができる
- データベースのスキーマと一致しているわけではない
- エラーハンドリング
- 失敗しても、ちょっとずつ更新されている
- アプリが重い原因
- RLMObject -> Structへの変換等
- →簡略化
- 並べ替えのインデックス生成
- iPhone6で分単位の時間がかかっていた
- →ソートに関する部分はRealmのソート機能にまかせてしまう
- ソートに使いたいキーが直接使えない状態だったので直接見るテーブルにそのカラムを追加
Realmオブジェクトからstructへの変換でこんなに時間がかかるというのは意外でした。が、_monoさんの記事を見て、DateFromatterをいちいち初期化していたことも原因ということがわかり、なるほどーと思いました。これは自分で気づかないうちにやってそうなので今度気をつけて見てみようと思いました。
Wantedly Visitの検索・フィルター機能@藤原 慶貴さん
- ユーザグロースチーム
- データ分析をして課題を見つけるところからやる
- 検索について
- Webと比べても圧倒的に社名で検索している→なぜ？
- 仮説を立てて検証、を繰り返す
- 改善系
- cellの種類が増えてくる
- cellに表示したいコンテンツにreuseIdentifierを持たせるようにするなど
- 行間が大きい、余白が大きいなどは負債返済日を作って一気に修正
- cellの種類が増えてくる
- デザイナーとのAssetsの受け渡し
- Zeplinが便利
- 社内のハッカソン
- 1回につき2日間
- 手軽に書けるBigQueryツールを作るなど
仮説を立てて改善活動を回していくということがスムーズに出来ているようでとても良いなーと思いました。あとエンジニアが多いとミッションに分かれて開発したりその他諸々良さそうだなと地味に思いました。。。
限られたリソースで進める段階的なSwift移行@永島 次朗さん
- アプリは3年前リリース
- 新規事業の関係で、一時は一人で開発を担当することも
- ネットワーク周りにRestKitを使っていた
- Obj-C実装ということもありメンテナンス頻度が低い
- 一部のクラッシュ要因にもなっていたのでこのライブラリに依存しない設計にする必要性が出てきた
- リスト表示の部分でも複雑性に耐えうる実装をする必要性が出てきた
- Swift移行と並行してこれら問題を解決しなければならない
- 3つの段階に分けて移行を実行
- フェーズ1
- Swiftの部分導入をユーザへの影響が小さい部分から始める
- フェーズ2
- ユーザへの影響が限定的な範囲で代替実装を進める
- フェーズ3
- ユーザへの影響が大きい画面の代替実装を進める
- Swift移行の工夫
- 段階的に進める
- 新規機能 / 画面で試してみる
ついこの間Swift3移行が終わったところだったのでとてもタイムリーでした。自分のところでも、ついでだからと言って各種ライブラリのアップデートや、それに伴いメンテがされていないライブラリを別の実装に置き換えるということをやりました。そんなに多くなかったので一気にやってしまいましたが結構時間はかかりましたね。。。
