try! Swift 記録 2日目

iOS カンファレンス Swift

try! Swift に参加してきました！

www.tryswift.co

ので、メモっていたことを書きます。 本当に雑なので、間違っているかもしれません。 ２日目の分です。 １日目の分はこちら。

テスト可能なコードを書くということの２つの側面

なぜテスト

  • バグを防げる
  • テストができるコードだけ書くようにしている
  • 関数型のように
  • テストをドキュメント化している
  • それに向かって振る舞うように実装している
  • ファイルを読み出してその内容を計算してコンソールに出力して結果を返すという場合
    • 入力と出力を分ける
    • 入力は引数以外にも、関数の内部から直接呼び出しているものも隠された入力と言える
    • 明示的なインプットと暗黙的なインプットがあるということ

アウトプットに関して

  • 難しいのは side-effect があるから
  • でも sideeffect はコード上で判断できるようにしておくべき
  • どうやるか
    • print の引数を直接返すようにする

インプットに関して

  • 難しいのは co-effects があるから
    • これは新しい分野なので詳しい説明はない
  • 何が操作されるのかが見えないといけない
  • グローバルに扱うものに関しては singleton などを直接使わずに間に struct を挟む
    • グローバルに定義しないでグローバル用の一つの struct を用意して入れてしまう
    • currentUser とか date も cookieStrage も langage も apiClient も scheduler も userDefaults も
    • 基本的に全て protocol を間に挟んで行う
    • こうして挟んだ protocol を使って引数を挟むようにする。

Q.どのタイミングでテスト書いているか
テスト駆動開発でやっている

Q.プロパティベースのテストは行なっているか
行なっていないが行いたい

誰もが知りたいSequenceとCollectionのすべて

Sequence

  • エレメントのリスト
  • 有限である
  • 一度だけしかイテレートできない
  • Sequence Protocol は map や fileter が適宜されている protocol
    • これに沿って何かを実装するれば、 map や filter が使えるようになる
  • 型に条件を持たせるには where を使う
    • 副作用として複雑になってしまう

BidirectionalCollection

  • 前にも後ろ戻りもできる Collection
  • 他にも Collection が3つあるのでそこら辺見ると良さそう

Iterator の何が嬉しいか

  • 基本的は内部で使っているだけなのであまり使うことがない
  • 自分で何か順番で見ていく処理を追加したい時に Iterator を見るというようにすることができる。

iOSにおけるDocument IndexingとApp Search

App Search を使う

  • Core SpotLigth API
  • spotlight で検索したときにからアプリ内のデータを返してタップしたらアプリを開く
  • 実装
    • import CoreSpotlight
    • CSSearchableItemIndexDelegate protocol を実装する
    • 情報を最新にしておく
  • beginBatch is background thread
  • apple のドキュメントはない
  • endBatch を呼んでから beginBatch する
  • スレッド処理は手動でやらないとならない
  • developer setting の identifer で Extension を取り出せる

きちんと型付けされたメッセージ

  • 可読性の高いコードを書く
  • メソッドのインターフェースに着目する
  • 引数にどういう処理がされて返り値が返ってくるのか
  • 返り値が何のための値なのか

方法

返り値をどう分かりやすくするか

  • コメント
  • 返り値の型を typealias で作る
    • この型がどういう定義なのかを確認しなければいけなくなる
    • 一度しか使わないのであればデメリットの方が大きい

返り値が optional の場合にはどうするか

  • typealias
  • enum で valid, invalid を作る
  • これらをやると結局複雑になっているので必ず良いとは言えない

weak の値をつかう場合

  • weak はいかを表す
    • 保持されていない
    • 要件ではない
    • 変更可能
  • これは本当に必要なものなのか
  • こういったことは慣習を元に用意されている
  • これを防ごうとしてラッパーを用意するとまた複雑になってくる
    • 慣習であるならば隠蔽すると逆にわかりづらくなってくるのでは

結論

  • 最適解というのはない
  • 他者がどういうところを疑問に持つのかを考える
  • メンバーの価値観を把握してコードを書くことが大事

モックオブジェクトをより便利にする

  • メソッドが呼ばれたことを判断するフラグは Bool じゃなくて Int にすれば回数まで担保できる
  • フラジャイルテストは避ける
    • 壊れて欲しくないときにも壊れてしまうようなテスト
  • エラーメッセージを良いものにしよう
    • 引数に file や line を メッセージ をメソッドに渡す
  • Hamcrest Matchers おすすめ

Client-Side Deep Learning

  • MPSCNN
  • metal は早いのでリアルタイムの画像解析が行える
  • ニューラルネットワークをつかうことでクライアントサイドでディープラーニングができるようになった
  • リアルタイムでサーバサイドと通信すると負荷がすごくなるのでクライアントサイドでやれると嬉しい