Try! Swift 2017のまとめ

  • 20
    いいね
  • 0
    コメント

今回3/2,3/3の2日間に渡ってプレゼンがあったので、3/2をDay1,3/3をDay2としています。
Day1-3というのはDay1の3番目のプレゼンという意味です。

プレゼン内容の整理

Swift言語だけでなく、iOSアプリ的なもの、開発のプロセスに関わるものなど幅広くプレゼンされていました。トレンドなのは機械学習と、アプリ品質に関わるテスト関係の話のようです。サーバサイドSwiftなどサーバ・クライアントの言語を共通化しようという傾向もありました。

行動・組織論

 Day1-5  Pixcels、プロセスと情熱
 Day2-6  スタートアップのSwift
 Day2-12 チームの生産性を改善するために決断疲れを最小化する
 Day2-14 オープンソースコミュニティをスケールさせる
 Day2-17 なぜ登るのか  

機械学習

 Day1-1 Swift開発者が知りたかったけど聞きにくい機械学習のすべて
 Day1-12 楽しく便利なSwiftチャットボット
 Day1-15 リアルタイム物体検出アプリでよりよいフィードバックを提供する
 Day2-13 Client-Side Deep Learning

テスト

 Day1-8  クックパッドアプリのテストを味わう
 Day2-1  テスト可能なコードを書くということの2つの側面
 Day2-11 モックオブジェクトをより便利にする
 Day2-15 Swiftでのエラーハンドリングとエラー耐性についての教訓

Swift

 Day1-2 誰もが知りたいSequenceとCollectionのすべて
 Day1-3 SwiftのPointy Bits
 Day1-7 Unsafe Swiftの安全性

サーバサイド

 Day1-11 SwiftのWeb APIとアプリをともに構築する
 Day2-3 様々な場面でSwiftを使う
 Day2-10 サーバサイドSwiftの実例

UI/UX

 Day1-16 UXエンジニアという働き方
 Day2-9 Swiftで堅牢なカラーシステムを構築する
 Day1-10 UIをSwiftyに書く

iOS

 Day1-4 アプリを新次元に導く3D Touch
 Day2-5 iOSにおけるDocument IndexingとApp Search
 Day2-8 忙しい人のためのApp Transport Security

データ層

 Day1-9 データレイヤを分離する
 Day1-13 Realmを使ってコラボレーションアプリを作る

Reactive Programming

 Day1-6 毎日リアクティブ
 Day1-14 独自のツールを構築する

Android

 Day1-2 Swift on Android

AppleWatch

 Day2-16 👾 & ⌚️

VR

 Day2-4 VRの革新と新たなユーザー体験

各テーマごとのまとめ(記載中)

テスト

Day1-8:クックパッドアプリのテストを味わう

テストを継続的に行い、それをリファクタリングにつなげている。
UIテストにAppiumを導入し、テスト工数を少なくしている。
画面遷移の8割にUIテストを導入している。
さらに、UIだけでなくイメージ差分やネットワークトラフィック(リクエストカウントなども)もチェックしている。
Appiumを利用する理由はシミュレータのシステム領域のクリア可能で再現性が高いため。

Day 2-1:テスト可能なコードを書くということの二つの側面

テストを行うには入力によって出力が一意に決まる関数(pure function)である必要があるが、
実際は入力や出力には作用するものがあり、条件によって出力が変わる。
そのためテストの際はこの作用を分離する必要がある。
分離方法としてグローバル変数群や動作や値が変化するプロトコルを一つのstructなどにまとめて入力する。

Day 2-11:モックオブジェクトをより便利にする

二つのオブジェクトのインタラクションテストを行うのであれば、プロトコルを利用する。
必要な変数と操作をプロトコルで定義し、プロトコルに準拠したモックを用意してテストする。
UnitTestではアサーションは一つしか定義できないので、
繰り返し呼ばれるのであれば呼び出された数、期待される値と実際の値などを表示する関数をアサーションで呼び出す。
細かくメッセージを出すのはリファクタの参考にするため。

Day 2-15:Swiftでのエラーハンドリングとエラー耐性についての教訓

エラー耐性を高めるときに考えるのは、正常系、Error型、予期せぬ不具合がある。
予期せぬ不具合から復帰して影響を最小限したい、入力に作用するグローバル変数・シングルトンを明示するようにする。
暗黙的なものとして状態がある。状態はある時間で実行されているコードの順番で定義される。
状態を明示するには、コメントや順序指定コンパイルなど。
コンパイラで実行順序はある程度指定されている。
データ移行など以前は存在しないものを利用する場合は型による明示的な依存関係にしていく

Optional型
・正しいか正しくない または、あるかない
・入力で使用すれば任意の値を意味する
・大抵の場合はこの型が正解
・情報量が少なく起こりがちなエラーに
Error型
・異常系で発生率が低く影響範囲が広いエラーで利用する
・スローして対処
・情報量が多く、コンテキスト依存な稀なエラーに

機械学習

Day1-1:Swift開発者が知りたかったけど聞きにくい機械学習のすべて

機械学習では、大量のデータと人間の考えを使って、ものを識別する関数を作る。
補助的なデータ、例えば身長を判定するのに、性別や年齢、体重、靴のサイズなどのパラメータを係数を使って積算していく、というのは線形回帰で求めること。
ニューラルネットワークでは多層のネットワークを用いて、ものを分類する関数を作っていく
様々な層ではぼやっとしているものを認識していく。
機械学習では、学習とその学習データを利用したアプリの段階があり、学習ではPythonとTensorFlowのような学習APIを使って学習データを作成し、アプリではSwiftを使って様々な入力と学習データを利用した認識結果を様々な結果として見せるアプリを作れる。

Day1-12;楽しく便利なSwiftチャットボット

日本語を学ぶために、個人的にカスタマイズしたLINEのようなbotを作った。
まず吹き出しを長押しすると Siriで話せるようにした。
次に入力した文章をGoogle翻訳に通して、翻訳された文章を話すようにした。
写真を送れば、写真内の文字を認識して描かれているものの画像を表示するようにした。
スタンプでbotに指示を出せるようにした。
UIはシンプルにすること。
画像をアップするとDropboxに保存され、URLを返答してくれる。

Day1-15;リアルタイム物体検出アプリでよりよいフィードバックを提供する

Wantedly Peopleというアプリでは、複数の名刺を認識できる。どのようにしているか?
まず名刺を検知する。そして複数の名刺であればトラッキングすることで常に各名刺を見分けているように見せる。検知するものについてAPIを使い分ける(顔だったらUIDetectionとか)

Day2-13;Client-Side Deep Learning

iOS10ではMetal Performance ShaderにCNN(Convolution Neural Network)の計算APIが用意された。GPUを使って計算するのでリアルタイムレベルで結果を出せる。TensorFlowなどで学習したデータを用いてリアルタイム認識可能。
カメラでリアルタイムで認識するアプリの画面を写して見せた。

行動・組織論

Day1-5  Pixcels、プロセスと情熱

結局のところ、ものづくりというのはこれを作りたいと思う人がいて、
それに共感した人が互いに自分のスキルを生かして、共同でものを作っていく流れになる。
そのような中で

  • チームやプロジェクトの内外の人にモチベーションを持ってもらい、互いにハッピーになることが大事な課題
  • ネットワーキングも大事。自分ができないことは人の助けを借りる必要がある
  • コンフォートゾーン(いつもの環境)を出て、刺激を受けることが重要

Day2-12 チームの生産性を改善するために決断疲れを最小化する

意志決定をシンプルにして開発効率を上げていく。まずは日常生活を振りかえって考えてみる

  • 全体朝礼:新しいメンバーやユーザの紹介など会社全体的な話題の整理
  • プロジェクトの朝礼:昨日何があって、今日何をするか。メンバー間の共通話題の整理(ここでソースコード管理の話)
  • ペアプログラミング:INDEXカード、ピンポン(実装とテスト実装を交代で行う)、Driver+Navigation(熟練者がナビしてドライバーがコードを書く)エンジニアやデザイナ、PMもペア(Cross Function Pair Programmingと言ってた)になり、また毎日ペアを変えてチーム全体でコードを共有。利点としては、みんな内容を知っているのですぐフィードバックが帰ってくること
  • ランチタイム:プレゼンや動画を見る
  • ミーティング:プランニングについて(ここではソースコード管理の話)
  • 休憩:ペアで卓球してリフレッシュ
  • クロスファンクションペアリング:エンジニアやデザインなどでペアを組む(デザイン的なプログラミングの話)
  • レトロスペクティブ:チームメンバーだけで振り返り。KPTを集めてアクションアイテムを出して取り組むことで問題が大きくなる前に解決する

XPの中でKentBeckが言ってたこと
・真実や好き嫌いを話す勇気が、コミュニケーションと信頼を育てる。

常にチームの間でコミュニケーションと信頼を育てることでチーム内での意思決定の場面が少なくなっていく。
その結果、チームのリソースを、より重要な意思決定に向けられる。

Day2-14 オープンソースコミュニティをスケールさせる

OSSの発展段階としては

  1. ソースコードを公開
  2. 開発者があなたのプロジェクトを利用するようになる(PullRequestが来る)
  3. その分野のソリューションとなっていく(Twitterで推奨されたり、カンファレンスで発表される)
  4. 大きなプロジェクトとなる

人間的な要因として、どうインパクトを与えるか、どうサポートするかを考える必要が出て来る

  • モメンタムを維持する(初期のイノベーションができなくなる。機能変更や設定値を変えられなくなる)
  • サポートの扱い(実装よりもユーザサポートの時間が長くなる)
  • 機能要求の受付(GitHub issues、issuesをクローズできなければ別サイト用意)
  • 不要な要求を断るときの理由をしっかりさせる
  • 外部PRのレビュー、issueをレビューすることはコードを書くのと同じくらい重要
  • 情報の不均衡 ある一つのissueはユーザにとっては重要なissue

どのようにOSSプロジェクトをスケールさせるか

  • エラーメッセージの改善 文字色を赤にしてStackOverFLowへのリンクと再現するコマンドを表示
  • ボットを使って自動化
  • バグレポートの詳細化
  • 似たようなissueが来るなら原因やドキュメントを改善する。異なる解決策や対策を見つけて書く
  • issueに2ヶ月変更がないと、問題が完了しているかボットが聞いてきて、誰も応答しなければクローズされる。さらに1ヶ月後にロックする
  • 大半のissueはCIでテストパスしていることをチェックしているが、テストだけでどのようにコードが変わったかまではわからない。Ortaを使うことでファイル変更や修正ライン数の通知やテストを要求することが可能。
  • 方向性の舵取り Vision.comを使ってビジョンを共有する。
  • DSL(Domain Specific Language) コードが複雑になる程貢献できる人は少ない。できるだけフレンドリーにissueやPRに感謝を伝える。コードを拡張しやすいようにDSLで記述したりプラグインにすることも考える。

Day2-17 なぜ登るのか

ボルダリングの紹介

  • 難易度が異なるコースが混じっているので、レベルが異なっても同じ壁で楽しめる。
  • 登り方に人それぞれの工夫ができる。柔軟性、筋力、ジャンプ力をそれぞれ活かせる。
  • 一人でもチームでも楽しめる

Swiftにも言える。制限や条件は人それぞれで、それに合わせてソリューションを考える必要がある。
一人で仕事しても、時にはStackOverFlowやあるいはOSのバグなどで苦労したりすることでみんなと苦労とソリューションを共有できる。