4/27(水)に株式会社FiNCさんで行われたHealth Swift Meetupという勉強会にまとめ枠として参加してきました。
初まとめ枠で不慣れなところもあるため、何かありましたら編集リクエストお願いします。
あと申し訳ないことに、スライドは後で公開されるだろうという思い込みの元メモを取っていたので、スライドが公開されていない発表についてのまとめが弱くなっております。。。
タイムスケジュール
| 時間 | 内容 |
|---|---|
| 19:00 ~ 19:10 | ご挨拶と会場のご案内 |
| 19:10 ~ 20:10 | ゲストスピーカーによるプレゼンテーション |
| 20:10 ~ 20:20 | 休憩 |
| 20:20 ~ 20:50 | LT |
| 20:50 ~ 21:50 | 懇談会（ヘルシーな軽食、フィットネスタイムあり） |
テーマ
Swiftで気持ち良く開発をするためには
FiNCさんによるご挨拶
■会社紹介
一生に一度のかけがえのない人生の成功をサポートする。
■サービス紹介
FiNCプラス 法人向け
ダイエット家庭教師 個人向け
パーソナルカラダサポート
■iOS開発環境
Swift100%、Swift2.2
slack / github / JIRA を使っている
ゲストスピーカー発表
@kishikawakatsumiさん
■Swiftらしいコードとは
一概に言えるものではないし、同じことをやるにもいろいろな表現と、それに伴うメリット・デメリットがある。ゆえに、それぞれの適性を理解した上で書けるようにすべき。Swiftらしさに拘って盲目的に使うべきではない。
■Protocolについて
Dependency Injection with the Cake Pattern in Swiftのエッセンスを紹介。
昔はDIコンテナを使ってDIを行っており、DIするためにDIを覚えなければならなかった。しかしCake Patternは言語の機能によってDIを実現できるものであり、特にライブラリを導入する必要はない。
プロトコルに切り出すという行為はSwiftらしいけど、実装するのは1箇所だけ、という場合であれば無理にプロトコルに切り出す必要はない。「同じような機能が出てくるかもしれないから今のうちに切り出して。。。」と考えることもあると思うが、たいてい出てこないので出てきた時に考えれば良い。
プロトコルに切り出すメリットの1つはtestableになること。
テストをするためにRealmに保存しているデータをクリーンして、テスト用のデータを挿入しなきゃ、というのは大変。ここで、決まったものを返すようなモックを作ると簡単にテストができる。プロトコルに依存する設計になっているとテストの時だけ一時的に実装をすり替えるということができる。
@akio0911さん
スライド
「SwiftTask, Repository Pattern and Type Erasure」
https://speakerdeck.com/akio0911/swifttask-repository-pattern-and-type-erasure
■SwiftTask
- アニメーション完了時に次のアニメーションを書こうとすると結構ごちゃごちゃ→SwiftTaskを使うとすっきり書ける
- なんでもかんでもSwfitTaskで作ればいいわけではない。カオスな処理になってきて、導入したほうがいいのであれば導入すべき。
■repository pattern
場合に応じて、保存するデータは同じだけど別々のところに保存したいということがあった。
→ストレージの切り替えを行うDataManagerを用意してHealthKitを許可していたらHealthKitに、許可していなかったらRealmに書くという処理を実現。
(HealthKitにだけ保存する HealthKitしか選択肢がないというのはApple審査的にダメだった)
ストレージを使うコード側にはどちらに保存するか意識しなくてもいいようにする。
■Type Erasure(型消去)
(以下はスライドを参照しつつお読みください)
Pokemonを継承したPikachuがあった時に、
let p1: Pikachu = Pikachu()//←これはできるけど
let p2: Pokemon = Pikachu()//←これはできない
PokemonTypeが抽象的なままなのでエラーになる。
→ラッパーを作る。
@mo_to_44さん
「Swiftにおける中毒体験談とSwiftの進化に疲弊しないための予防策」
Swiftについて、振り返ってみて悪かったなと思ったこと、進化のライフサイクルについていくためにやっておいた方がよいことに言及
■Swiftの特徴
Safe, Fast, Expressive
継続的に進化していく
いろんな書き方ができてしまう
■中毒体験について
●guard中毒
何らかの条件が成立しなかったらその後の処理意味ないという場合に使うべき。
●map中毒
forEachでいい時もある。
●if-else if中毒
全部読まないとわからない状態より、switchにしてしまえばいい場合もある。
複数の値を見るのであればタプルにし、その中で無視してもいいのがあれば「_」を使用する。
これからもSwiftは進化すると思われる。
何らかのバージョンアップ時は公式のドキュメントのrevisionを見る。「まだ最新版には移行しないけど、次で●●が使えなくなるから以降は●●を使わない実装をしよう」とすることでスムーズに移行することができる。
LT
@haptaroさん
スライド
https://speakerdeck.com/kotaro/swiftdeqi-chi-tiliang-kukai-fa-sitaapuriwoqi-chi-tiliang-kusubmitsuru
「Swiftで気持ち良く開発したアプリを気持ち良くSubmitする」
■Provisioning Profilesとは？
→開発者とアプリ、実機の情報を関係づけるもの。アプリでiOSを動作可能にするために必要なもの。
■なぜあまり理解できていなかったのか？
→Xcodeがうまくやってくれたから
■必要なProvisioning Profilesの数
→iOSアプリだと2つ、WatchKitだと6つ
■XC Wildcardとは？
→どんなアプリでも実機でテストをすることができるもの
@takasekさん
スライド
https://speakerdeck.com/takasek/jian-kang-de-namvvm-shu-itemasuka-mvvmantipatanji
「健康的なMVVM 書いてますか？ ~MVVMアンチパターン集~」
不健康なViewModelを診察。
①でしゃばりViewModel
②混線しているViewModel
③ガラスのViewModel
④舌足らずなViewModel
⑤監督不行届なViewModel
⑥神経質なViewModel
⑦メタボリックシンドロームViewModel
上記のようにならないように意識しつつ、健康的なコード、設計、エンジニアライフを！
@ezuraさん
スライド
https://speakerdeck.com/ezura/swift-falsebiao-xian-li-wole-simou
「Swift の表現力を楽しもう！」
標準ライブラリを理解すればSwiftに調和したコードを気持ちよく書けそう。
→今日は3分間で標準ライブラリと遊んでみる
お題：5...2
5〜2の範囲(Range)ってできるのだろうか？
RangeはForwardIndexType(一連の空間の中にある離散値を表す)に準拠している。
IntはForwardIndexTypeに準拠しているので扱うことができる。自作の型をForwardIndexTypeに準拠させるには次の値を設定しておく必要がある。曜日の列挙体を作る場合には日〜土がループするようにしてあげればいい。
冒頭の5…2は以下のように自作の型を作れば可能。
let roopRange: Range<LoopIndex> = 5...2
// つまりlet roopRange: Range<LoopIndex> = LoopIndex(5)...LoopIndex(2)
// 詳しい実装はスライドで。
注：上記のようなことはできるが、トリッキーなことをするときは慎重に！
hirose_yudaiさん
Swiftで気持よく開発をするためのライブラリを開発したので紹介。
■SegueAddition
Point：performSegueWithIdentifierを使いやすくする。
通常の問題点：命令を出す場所と下処理をする場所が離れていて可読性が良くない。
→すっきり書くことができる。もうprepareForSegueなんていらない！
■ResourceKit
Point：ハードコードをなくす。
通常の問題点：Typoでランタイムエラーが発生してしまう可能性があり、安心感がないコードになってしまう。
→すっきりと安心感のあるコードを書くことができる。ビューの名前を変えてもXcodeのビルドが走ったタイミングで変更されるため、ランタイムエラーが確実に減る。
閉会
最後は皆で軽いフィットネスをするというFiNCさんらしい終わり方でした。
社内案内
残っていた人たちは社内を案内してもらえました。
開放的で清潔感のある空間、快適な椅子と机など、働きやすい環境が整っていました。
togetter
@koogawaさんがまとめてくださっていました。
http://togetter.com/li/968211