概要
iOSDC前夜祭に参加したので、そのまとめ。
参加したセッションまとめと、感想を記しておく。
セッションまとめと感想
登壇者が話したことと感想とが混じっているので、雰囲気で察してくれることを祈る
標準アプリから学ぶ、HIGが教えてくれないiOSデザインのこと
- 資料
- まだない
- ARKitの話も気になったんだけど、こっちにした
- HIGのお話
- 自動ドアとか建物とか、同じルールで使えてユーザーが困らないようにしようね
- 新しい標準が登場したときはその背景・使い方を知ろう
- OS Xのカラムレイアウトも最初は慣れなかったなー
- Home Indicatorが新しいUIなのはわかるけど、使いやすいUIなのかなぁ
- iPhone XのUIは旧来のiPhoneと違っている部分が多くて、好きじゃないんだよな
- 日常的に使っていたら印象も違うんだろうけど
- 画面が大型化することによってパラレルでユーザと会話することが可能になった
- セミモーダルも…うーん…
- 新しい機能の背景や使い方を知るというのは同意
キラリと光るテクニック、アプリをデモするときの心構え
- 資料
- デモすることも多くなりそうなので聞きに来た
- デモはオフラインでも動くもので行うのが良い
- 会場に丸投げだとWifiが制限かかって使えないなどよくあるらしい
- Wifi、Bluetoothは大規模会場ではほぼ使えない
- WWDCでも使えなかった
- 電力が心配
- 会場の電力量を確認しておくといいかも
- 東日本、西日本で光源にちらつきがでることがある
- 蛍光灯・LED光源のちらつきがうつることがある
- 光源をもちこむとよい
- あ、はい
- バッテリー問題
- 管理をちゃんとしよう
- 監視もあり
- デバイスの損傷・盗難の心配
- デバイスの落下は起きることを前提にする
- 動産保険に入る
- プロファイルなどの有効期限
- ちゃんと確認する
- iPadのClassroomを使う
- 60台ぐらいまでSafariでこのページを開くなどコントロールできる
iOSエンジニアの為のgrpc-swift入門
- 資料
- まだない
- メルカリ、Origami、CAなどが採用している
- gRPCのメリット
- APIの仕様と実装の乖離が減る
- 存在しないAPI
- 強い型付け、HTTP/2、ProtoBuf
- APIの仕様と実装の乖離が減る
- Protocol Buffers
- gRPC-Swift
- gRPC-Swiftの構成
- gRPC-C-Coreがベース
- その上にSwiftで書かれた呼び出し口がいる
- 他の人のTweet
- ドメインモデルの事例はリフト?さんの情報を追ってみるといいとこのこと
- Optionalの表現について
再利用可能なUI Componentsを利用したアプリ開発
- 資料
- まだない
- 課題
- テキストのサイズが異なる
- IBと色指定が異なる
- 複数の画面で同じような実装
- デザイナーのアプローチ
- デザインシステム
- 色とかサイズとか決める
- Sketchのシンボルの話っぽい
- デザインシステム
- SketchのシンボルのようにUIコンポーネントが作れたらいいのではないか
- Atomic Designの話かなーと思ったらやっぱりそうだった
- 社内のエンジニア共有会でAtomic Designの話を聞いて、これを取り入れたら良さそうと思ってたので、聞けて良かった
- DXELでもAtomic Designに関連する発表があったな
- Atomic Designで現状整理、いいね
- InVisionやZeplinだとスタイル情報、シンボル情報が欠落するので廃止したとのこと
- なるほどー
- デザイナーとどうするか決めるのもいいアプローチだな
- デフォルト実装でスタイルを適用するのか
- Storyboardでスタイル指定をやめた
- 石川さんの記事にもあったけど、自分としてもStoryboardで指定するのは限界がきていると思っているので、同意しかない
- Q.デザイナーとSketchファイルのやり取りはどうしているか
- Abstractを経由するのが手間だということで、Gitでやりとりしてる
- え、それはどうよ…
- Abstractを経由するのが手間だということで、Gitでやりとりしてる
ツールとして利用するUIテスト
- 資料
- かっくんさんのQiitaを見て前職の案件でUIテストを導入したのであった
- たくさんの画面サイズ、回転時のUI確認、大変よね
- UIテストをしているとしたくなること
- 特定の画面に遷移したい
- Lunchというライブラリを作った
- 良いのでは!
- 特定の画面に遷移したい
- Xcode9からScreenShotが撮影できるようになった
- 前職の案件で使ったなー
- ShellScript化するとよい
- Gistにあがっている
- UIテスト遅い問題
- 並列テストができるようになるらしい
- 良いのでは
- 並列化するとシミュレーターの数で実行速度が変わるっぽい
- 並列テストができるようになるらしい
- TestSummariesを作ったというお話
- デモを見せてもらったが、これは本当に良いぞ
- あの案件で導入したかった…
- UIテスト自体のハードルが高いのでなかなか手が出ないんだよな
- スクショ撮るツールとしてのUIテスト導入は実際に前職でやったことがあって良さしかなかった
- 人に教えるときに「これだけ画面あるので」とか話しやすいし、一度画像化しておくと変更も理解しやすいので、良さしかなかった
設計時空のリファクタリング〜複数アーキテクチャを抱えたアプリのリファクタリング事例〜
- 資料
- まだ
- BOOTHアプリのリファクタリングの話?
- 負債の話は日々直面するよね
- 複数のアーキテクチャパターンの混在はつらいだろうなぁ
- 途中から入る立場からすると「え、どれにあわせればいいの?」ってなるし、不安が重くのしかかる
- リリースが落ち着いているときに負債の返済
- わかる
- リファクタリングの方針を考える
- 手を付けるところから小さく直す
- 大きなリファクタリングに舵取りしなかった理由
- 自信がなかった
- わかる
- 仕様を理解していない状態では難しい
- わかる
- 自信がなかった
- コード理解のためのリファクタリング
- リファクタリングしながら設計などを理解する
- わからないことはメンバーにきいて、ドキュメントに残す
- 責務やフローを再検討する
- リファクタリングをしたあとにテストをする
- 都度手動テストはしんどいし、現実的に無理(というのは自分の経験上完全同意である
- 自動テストを書く
- UIテストを豊富に書く
- 経験がないとむずかしめ
- 単体テストができる形に設計を見直していく
- リファクタリングのためのテストが必要な問題でデッドロック
- こちらを選択した
- リファクタリングのためのテストが必要な問題でデッドロック
- UIテストを豊富に書く
- 「いきなり新人が仕事を増やしやがったと思われないように説明した」
- わかる
- イケていないコードに対する感情
- 当時は正しかったコードが時間経過で負債になる
- 反省点
- 不安を感じすぎてしまった
- 中途入社だとそうなるのはわかるし、実際自分もそういう心境だった
- お金が絡んでくる部分のリファクタ…
- 不安を感じすぎてしまった
まとめ
前夜祭から盛りだくさん。
資料はそのうち追記する。
明日も楽しみ。