try! Swift 最速レポート 3日目午後 #tryswiftconf

#iPhone

#勉強会

田中孝明

2016.03.04

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

try! swift 最速レポート 3日目午後

弊社のレポートは以下になります

こんにちは！モバイルアプリ開発部の田中孝明です。午前の部の田宮から引き続きお送りいたします。

Swiftトレーニング: 統計学を例に

発表者：Diana Zmuda さん

統計学をベースにどのようにどのようにSwiftで実装していくのか？
アニメのレートの計算をおこなうコードを例で紹介
- レーティングの計算についてランキングをどのように自動化するか見ていこう
Wilson Score Interval(信頼区間)で順位付けを行う
- どのようなオブジェクトもレート可能であるprotocolを作成する
文章を分類する（tokenizing）
bag-of-Words
テキストの中で信頼のできるものが出てくる（たとえばロボアニメなら宇宙）
Classifyingでトークン化された文字列の表現を見ていく
Summarizingでアニメの詳細をまとめるを作る
- いわゆる機械学習
- 代表サブセットを見つける（共通に持っている言葉をみて相似性をみる）
Generating
- テキストジェネレータ
- マルコフチェーンジェネレータ
Training algorithm 現状のステート（文字）から推測する
Swiftは新しい理論を試すのに適している
- 柔軟で再利用性のある特徴は重要

xcodeless the build system

発表者：Daniel Haight さん

CODE INJECTION FROM SCRATCH
functionalなcode injectionについて
ObjectiveC.runtimeを使用する方法
- アプリの外からなんらかのコードをロードしてつかう
- 古いメソッドを新しいメソッドへの置き換えを行う
dynamicというキーワードを利用しなれれば置き換えれない
- objective-cのdynamic dispatchを利用するため
使わない方法は？
- SwiftObjectの構造をalmost_swift_classとして実装
- vTableを計算してmemcpyをつかってメソッド入れ替えを行う
- Swiftのランライムは不安定だがCのクラス（memcpy等）がつかえるので頑張ることもできる
- ドキュメントが公開されていないため

デザイナーをSwiftのコードベースに巻き込む10の方法

発表者：Helen Holmes さん

デザイナがいればもっといいデザインになるが、コードを理解できないと協力できない
デザイナーはいたほうがいい
- エンジニアがUXを考える時間を確保するよりも効率が良い
- 連れてくるのに時間がかかってしまう
1.コードに興味があるデザイナを連れてくる
- コードを学ぶのも時間がかかる
2.メンターシップというチームに土壌を作る
- 様々なスキルセットを持つ方に対応できるようにする
3.storyboardを使う
- UXの全体図を見渡すことができる
  - 全体像を理解させるのにつかう
4.Autolayoutを使うようにする
5.@IBDesignableを使うようにする
6.DrawtoolをSketchに移行してもらう
- Xcodeと操作が似ているので移行コストが低くすむ
7.デザイナとなにか協力をお願いされたら一緒に協力する
- 新しいframeworkの提案などを前向きに検討する
8.デザイナをそのままほっとかないように
- コードベースで困っていることや、課題を聞いてあげること
9.ドキュメンテーションを余分に作成する
- 新人エンジニア向けのドキュメントの作成と同じくらい時間をかける
10.デザイナを迎える時は気軽に返せる時間の余裕があるときに
- エンジニアに時間の余裕あるときにする
成長できる環境はおだやかでポジティブな環境であること
- デザイナとエンジニアの関係が悪いとお互いのストレスが増える
  - お互いを理解することでストレスを緩和できる

パーサーコンビネーター in Swift

発表者：Yasuhiro Inami さん

ボトムアップ構文分析、トップダウン構文分析があり、トップダウン構文分析をベースに話を進める
applicative pureと　alternative emptyを用意
abindを（>>=）実装

curryをつかってApplicative Styleで記述
- Applicative styleに馴染みのある方にはいい？

今回のスライド用にTryParsecを公開したが、まだオープンソースで提供していません。

オープンソースSwiftへの貢献

発表者：Jesse Squires さん

どうやってcontributeしたらいいのか？
- 自分が貢献できそうなところはどこか？
全てを理解する必要はないがパイプラインの最低限の知識は知っておく
Swift core
- Compiler
- stdlib
- SourceKit
INFRA
- swift-llvm
- swift-clang
- swift-lldb
Package manager
- Swift package manager
- Swift-llbuild
Core Libs
- Foundation
- XCTest
- libdispatch
Evolution
- Proposals
- Development schedule
- Release Schedule
ディスカッションはJIRAなどで推奨されている
- ガイドラインはよく読むこと
Swiftというのはビギナーに取っても使いやすい言語を目指している
- typoの修正も重要
  - すぐにプルリクを出す
CONTRIBUTINGの際、心がけてほしいこと
- やさしくする、お互いの意見を尊重する
- 助けを求める
- ベストプラクティスをじゅんじゅ
- リジェクトされたからといってCONTRIBUTINGをやめないでほしい
- コアチームは我々の知らないプランを知っている
- コードオーナーのファイルがある
- 一人でやらずにみんなでやる、わからないことは質問する

Artsyにおけるテスト手法の紹介

発表者：Ash Furrow さん

4つのアプリケーションをそれぞれ違うアプローチでテスト
1.いそいでつくったシンプルなアプリ
- テストストーリーがなかった
- ローンチのプレッシャーがあり、テストを価値を上回った
2.過去からあったアプリ
- もともとはテストがなかった
  - 重要なのはバスファクター
    - このひとがバスに轢かれたらプロジェクトは大丈夫か？
- クラスはできるだけ小さくしておく
- Dependency Injectionをよくつかった
3.いそいでつくったがあとからテストを加えた
- ネットワークアクセスを利用していたのでMockを利用した
- facebookから提供されているios-snapshot-test-caseを活用
- リポジトリが重くなるのが問題（pngなため）
- できるだけ小さなクラスからテストから行うように
- 納得のいかないコミットコードも歴史を残しておく
4.最初からテストを追加したプロジェクト
- Swiftがβの頃から作成した
- 自分たちのSwiftの仕組みを理解するのに役に立った
Quick
- Rspecライクのテストが書ける
Nimble
- 見やすいmatcherを提供している
Rspecスタイルのテストを書く
できるだけ一つのテストに対してexpectはひとつ
- 短く、たくさんつくる
Artsyはコードを公開しているので質問などください
- emergence
- energy
- eigen
- eidolon