[速報レポート] try! Swift TOKYO 2017 2日目 午後Ⅰ #tryswiftconf

はじめに

こんぬづは、カンファレンスに参加すると新しい人に出会えるという魅力もありますが、全国各地の知り合いが集まって来てくれて久しぶりに話ができるのも魅力だと感じている田中です。Twitterなどでアイコンは知っているけどお会いするのが初めての人とかも嬉しいですね。

本日はtry! Swift 2日目です！この記事では午後Ⅰのまとめをお届けします。

↓カンファレンスに参加するブロガー（男性）のイラストです。

「きちんと型付けされたメッセージ」 Krzysztof Siejkowski

この講演はSwiftのコードの可読性に関するものです。達成するために明確に定義された目標ではなく、あなたが向かうべき方向性を決めるためのものです。普及しているCocoaパターンとSwift言語の構成概念の違いを見てみると、可読性のトレードオフと改善の可能性があることを確認していきます。 また、Swiftの型システムのパワーを使って、可読性を向上するためのテクニックを学んでいきます。

スライド

説明

• コードの可読性について話をします
• Maintaining Mental Models: A Study of Developer ... というマイクロソフトからの出典
  • コード片の背景について理解する
  • チームメンバーからの質問に答えるということ
• コードを説明する立場にも、コードについて質問する立場にも両方に立ったことがある
• 付帯する複雑性をコントロールし、可読性の高いコードを得る
• 可読性を得るにはいくつかの方法がある
• 1. APIデザイン
  • func split(email: String) -> (String, String)? のシグネチャを見る
  • Level1. Comments
    • このメソッドが何をしてくれるかはコメントを見ればわかる
    • これはコンパイラ言語を自然言語に変換すること
  • Level2. symbols
    • これは自然言語をSwiftとして表現すること
    • なぜOptionalなのか？という問い
  • Level3. wrappers
    • enumとして書くこと
    • enumとして書くことでOptionalで書いた意図が伝わる
  • Level4. concepts
    • Either型を使う
  • ここまでで、未だ可読性があがったかどうかはわからない
  • 複雑性を取り払うにはなんらかのトレードオフが発生する
• 1. Delegation
  • Level1. Initializer injection
    • 通知するオブジェクトの実装を読まなければいけないという問題がある
  • Level2. Weak closure
  • Level3. Weak function
    • closureで渡すときにweak化されたdelegateを渡す
  • Level4. Weak wrapper
    • この方法によって可読性が向上することはない
  • Delegationを改善したからといって、可読性が向上するだろうか？
  • Appleが提供したコンセプトを離れると理解が難しくなる
  • 読みやすいコードを得るには視野を広げる必要がある
• 1. Empathy (is the god mode)
  • 共感ということが大切
  • そもそも決定的な可読性などというものは存在せず、読みやすさを決定するのはそれぞれのエンジニアの経験

「忙しい人のためのApp Transport Security」 niwatako

WWDC2016にてATS(App Transport Security)の必須化がアナウンスされました。しかしご存知の通り、必須化は延期されました。また、iOS10で新たなATSの設定を行うInfo.plistのキーが導入されましたが、iOS10のマイナーバージョンごとに仕様が異なります。このLTでは、制度も情報も仕様も混乱しているATSを5分でマスターしていただくことに挑戦します。

スライド

説明

• 聞き起こしブログの人です
• 京都から来ました。金色の金閣寺が綺麗ですね。僕の祖先が作ったそうです。お金持ちですね。
• 僕はお金持ちではありませんが、Macbook Goldを持っています。綺麗ですね。
• ATSというのはHTTPS以外の通信をブロックする仕組み
• HTTPSに安全なものと安全でないものがある
  • ATSは一定以上の基準を満たしたHTTPSでないと許可しない
  • $ nscurl --ats-diagnostics を使うと、ATSに対応できたHTTPSかどうかを確認できる
  • ATSを無効化するにはNSAllowsArbitraryLoadsを設定する
• 新しいATSに関するオプションが追加された
• はてなブログではユーザーがブックマークしたWebを開くことができる
  • Webで開く際にNSAllowsArbitraryLoadsInWebContentを設定した
  • NSAllowsArbitraryLoadsInWebContentにはiOS 10.2でWKWebViewにおいて表示できてしまうバグがある
  • Appleのドキュメントを信じるだけではダメで、結局OSごとに動作確認するしかない！
• でも！ATS対応必須化は延期されたので、とりあえずNSAllowsArbitraryLoadsを設定すればよいというだけになってしまいました！

「Swiftで堅牢なカラーシステムを構築する」 Laura Ragone

これまで以上に多くの企業が、新しく増え続けるユーザーに今までよりも魅力的なアプリだとアピールするために、アプリを再設計しています。この講演ではあらゆる規模のプロジェクトにスケールできる堅牢なカラーシステムを構築するための戦略について議論します。これらのアプローチはデザイン上の決定を迅速に繰り返すのに役立ち、実行時にカラーパレットのテーマを変更するようなこともできるかもしれません。さらに、iOS 10で導入された新しいカラーフィルターのアクセシビリティ機能を使用して、色覚の問題を抱える人を支援することにも応用できることを示すデモンストレーションも行います。

スライド

説明

• Today, we'll learn...
  • いかにして基本的なカラーシステムを構築するか
  • カスタムテーマを追加するための戦略
• Reasons to Build a Color System
  • 色にアクセスするのが簡単になるから
  • 外観を作っていくイテレーションをスムーズにすることができるから
  • AppleのHIGが定期的に変更されるから
  • iOS 10でも新しくなりました
• Design Decisions
  • カラーシステムを作ることの理解を持ったうえでどんな設計にするべきかを見ていく
  • IBはここ何年かでとても強力になっている
  • Sketchを通してデザイナとプログラマがcolor pickerを共有することができる
  • Programmatic
    • Pros
      • UI要素はUIColorを参照する
      • IBではなくUIColorを使うことでProgrammaticになる
      • UIColor Extensionを作って、その中にstructを作ることでパレットを定義することができる
    • UIColor Extension Etiquette
      • これまではclass varの計算型プロパティとして各UI要素に対する色を返すように定義していた
• Integrating Themes
  • Basic Themes
  • Basic Themes: ColorUpdatable
    • ColorUpdatable protocol
  • Basic Themes: ColorChangeObserving
    • ColorChangeObserving protocol
      • didChangeClorTheme notificationを持つ
      • 色が変更されたことを通知する
    • add/removeColorThemeObserver, didChangeColorThemeをprotocolとして持つことでNotificationCenterを管理する
• Inclusive Design
  • 色覚障害について
  • 全ての色のコントラストをiOS管理で変更することができる
  • Visual Quality Assuranceをテストするには、見る人がどのように見えているかをテストする必要があります。
  • Display Accommodations
  • Strategies
    • 全ての色を考えるときに色だけでなくコンストラスト比にも焦点を当てるべき
• Summary
  • 堅牢なカラーシステムを作る基本としてプロトコルを用いる
  • 上記のプロトコルによってruntimeでカラーテーマをアップデートする
  • 色覚障害についても考えるべき

「サーバサイドSwiftの実例」 Tatsuya Tobioka

http://nsdateformatter.com/ というサイトを知っていますか？オンライン上でNSDateFormatterを試せる面白いサイトです。私はこれの影響を受けてNSURL版( http://nsurl.serversideswift.net/ )を作成しました。また、自作のライブラリもブラウザ上で触れるようにしています。( https://stringfilter.herokuapp.com/ ) VaporやBluemixのおかげでこの種のサイトは驚くほど簡単に作れます。是非やってみましょう！

スライド

説明

• 多くのWeb frameworkがありますが、私はVaporをよく使っています
• 最近はXcodeでコードの編集をして、dockerを使っています
• Vaporを使って実際に作っていきましょう
  • DEMO
  • マークダウンエディタができました！
• 必要であればHerokuに対してデプロイすることもできます
• 小さなアプリで試してみてください！

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

Swiftでは、手作業でモックオブジェクトを作成します。その設計がどのようにユニットテストを書けば良いかという方針を決めています。テストをより表現力豊かにするようモックオブジェクトをより強力にすることはできるでしょうか？モックライブラリから何を学ぶことができるでしょうか？OCMockitoというObjective-C製のモックライブラリを書いてきた私の経験をSwiftの手作りモックに応用してみます。

スライド

http://qualitycoding.org/files/SwiftMocks.pdf

説明

• Swift環境でMockオブジェクトをいかにして作っていくか
• なぜMockオブジェクトが必要なのか？
  • レストランを例にあげます
    • お客さんがウェイターに注文して、ウェイターがコックに注文を伝える
    • 実際の料理はリソースを多く使う
    • Unit Testでみると、Fakeのコックが必要
    • ウェイターの単体テストを行うとき、実際に料理させるのではなく「(Fake) Cookに対して注文を伝える」という機能をテストしたい
• 実際のコードで紹介します
  • ウェイターの単体テスト
    • 「ラーメンの注文をコックに伝える」ウェイターの単体テストを作る例
    • 多くの場合、MockCockに対してメソッドが呼び出されたのかどうかをテストするためにBoolプロパティを持つことがある
    • BoolをIntに変えて、呼び出されたかどうかではなくメソッドが呼び出された回数を確認する
    • こうすることで、本来1度呼び出されればよいものが、実は二回呼び出されていたりするバグを発見することができたりする
    • Assertionは一つのテストに対して一つを心がける
    • Closureを用いる
• テストを作る理由は、コード変更を大胆に行うための補強材料
• Hamcrest Matchers
• Fake Objectを使うのはいつか？
  • Global Objectを変えてしまうような場合
  • 実際に処理が呼ばれたのかどうかを確認する場合
• まとめ
  • BoolではなくIntを使って、呼び出し回数をテストしよう
  • など
  • テストが目的ではなく、テストを通してリファクタリングすることが目的である
  • ガラスのように繊細なテストは必要ない、竹のように強くしなやかなテストが必要です
  • 続きはWebで（ソースコードなどもある）
    • qualitycoding.org/tryswift2017