Swiftの世界的カンファレンス、
最終日である3日目に行われた11のセッションのうち、
Hiroki Kato氏「Motivation based library abstraction」
初めにこの日最初のセッションでもあった、
はてな社のアプリは現状ほぼすべてSwiftで書かれているそうですが、
"必要は発明の母"と言うように、

このレポートでも順番に内容を振り返ってみます。
UTIKit
名前の通り、
- 簡潔な記述
- 同一性の確認
(Equality) - パターンマッチによる識別
(Confirmance)
例えば、
UTI(MIMEType: "image/jpeg") == UTI(filenameExtension: "jpeg")
HUDKit
続いて紹介したHUDKitもアプリケーション開発の中で生まれたもので、
- ブログ記事投稿後のユーザの操作への割り込み
- SNSへのシェアの際にシェアするかどうかの確認
HUDに関しては既存のライブラリもありますが、
- HUDPresentationController
- UIPresentationControllerベースで自由にviewControllerを指定できる
- HUDProgressViewController
- 進捗状況をHUDとして簡単に表示できる
HTTPRequestMatcher
最後に紹介したHTTPRequestMatcherは、
let URL = NSURL(string: "http://example.com/blog/123/article/456")
if case .Match(let parameters) =
PathMatcher("/blog/{blog_id:[0-9]+}").match(URL) {
let blogID = parameters["blog_id"].first!
// ..
}
}
問題の一般化
これら3つライブラリはどれも実際に直面した問題について、
- Generalize
- Parameterlize
- Abstraction
この"一般化可能かどうか"については、
- 直感
- 向き合っている問題がどのドメインに属している問題なのか。
- 自分たちの固有ドメインでなければチャンス
といったものを判断材料にしているとQ&Aで回答していました。我々開発者がやるべきことは誰かの要望を叶えるアプリを作ることですが、

Yasuhiro Inami氏「Parser Combinator in Swift」
続いてはLINE株式会社所属で、
Parser Combinator
Inami氏はまずParser Combinatorとそれを構成するParser
- Parser
- テキスト等のデータ、
特にLexer (字句解析器) の結果としてのトークンを入力として受け取り、 AST (Abstract Syntax Tree) のようなデータ構造を生成 - ボトムアップなアルゴリズムとトップダウンなアルゴリズムの2種類が存在
- テキスト等のデータ、
- Parser Combinator
- Combinatorによって複数の小さなParserを組み合わせ、
より複雑なParserを構成 - 結果として1つの大きいParserが動いているように見える
- Combinatorによって複数の小さなParserを組み合わせ、

SwiftでのシンプルなParser
以上を踏まえた上で、
struct Parser<A> {
let parse: String -> (A, String)?
}
これは次の状態の変換を行うコンテナと言えます。
- 入力: String
- 出力: 出力と入力の残りのタプルのオプショナル値
(失敗することがあるため)
これを利用し、
func pure<A>(a: A) -> Parser<A> {
return Parser { (a, $0) }
}
こういったシンプルなParserを多数定義していき、
func symbol(str: String) -> Parser<String> {
return skipSpaces() *> string(str) <* skipSpaces()
}
その後、
TryParsec
TryParsecは今回のカンファレンス用にInami氏が実装したParserで、
以下のような特徴を持っています。
- CSV、
XML、 JSONのパースをサポート - HaskellのAttoparsec/
Aesonにインスパイアされたもので、 Monadicである - 独自のParserも簡単に作成可能
実際にSwift標準の機能を利用せず、
extension Model: FromJSON {
static func fromJSON(json: JSON) -> Result<Model, JSON.ParseError> {
return fromJSONObject(json) {
curry(self.init)
<^> $0 !! "string"
<*> $0 !! "num"
<*> $0 !! "bool"
<*> $0 !! "null"
<*> $0 !! "array"
<*> $0 !! "dict"
<*> $0 !! "object"
<*> $0 !? "dummy"
}
}
}
SwiftでJSONを扱う際の有名なライブラリの1つであるthoughtbot/

Jesse Squires氏 - Contributing to Open Source Swift(オープンソースSwiftへの貢献)
JSQMessagesViewControllerの作者としても知られる、
Squires氏はまず以下を順に解説しました。
- LLVMのコンパイラアーキテクチャ
- Clangのパイプライン
- Swiftのコンパイル時のパイプライン
例えばSwiftのコンパイル時のパイプラインは以下のようになることを述べました。
- Swiftで書かれたコードをパースしAST
(Abstract Syntax Tree) を生成 - 意味解析によってAST*を生成
- SILGenでraw SIL
(Swift Intermediate Language) を生成 - 最適化によりcanonical なSIL*を生成
- IRGenによってLLVM IR
(Intermediate Representation) を生成 - LLVMによって最終的なバイナリを生成
実際にシンプルなコードに対し、
- ステップ1のASTを生成する部分 => apple/
swiftのlib/ Parse - ステップ2のAST*を生成する部分 => apple/
swiftのlib/ Sema

こういったことを説明した上で、
- Swift core
- コアの部分。コンパイラなどはC++の知識が必要で、
難易度が高い - Compiler
- stdlib
- SourceKit
- コアの部分。コンパイラなどはC++の知識が必要で、
- INFRA
- 深い知識が必要で、
Contributeするのが難しい部分 - もうある程度固まったもので、
開発が活発でない
- 深い知識が必要で、
- Parckage Manager
- Cライブラリを多くラップしている、
チャレンジングな部分
- Cライブラリを多くラップしている、
- Core libs
- Contributeを始めやすい部分
- Evolution
try! contribute()
我々は具体的にどのようにContributeしたら良いのでしょうか。氏は次のように説明しました。
- ディスカッションはメーリングリストでスタート
- レベルに関係なく意見を言う
- 困ったら助けを求める
- Pull RequestについてはCONTRIBUTING.
mdを守り、 ベストプラクティスに従う - たとえPull RequestがRejectされてもそこで落ち込まず、
Contributeをそこでやめるべきではない
- コアチームはすべての人に参加してほしいと思っている
Pull Requestに関しては、
Making small improvements is the way everyone starts getting involved!
最後に以下のような熱いメッセージを残し、
- Swiftの成功が我々開発者にとっての成功であるのだから、
Contributeすべき - コードだけではなくアイデアもContribute
- Swiftは単なる言語ではなくコミュニティ
Ash Furrow氏「An Arsty Testing Tour(Artsyにおけるテスト手法の紹介)」
try! Swift最後のトークとなったのは、
- テストにおいては完璧、
理想形を目指さない。100%のカバレッジを目指さない。 - コンポーネントは小さくし、
Publicなインターフェイスのみをテストする。 - 新しいアプリケーションも小さなコンポーネントから始める。
その上で、
以下で順番に紹介します。トークを通してコードはほとんど用いず、
artsy/Emergence
Apple TV用のアートワークを見るためのアプリケーションであるEmergenceが最初の例でしたが、
artsy/energy
アートギャラリーのアプリケーションのテストケースの紹介です。元々はテストはなかったのですが、
まず、
- 良いテスト => 外部に対しての振る舞いのテスト
- クラスは小さく保つ
- Dependency Injectionを多く活用
- オブジェクトは必要のないものは生成しない
- RSpecスタイルでのテストで、
共通処理は外に出す
artsy/eigen
eigenというアートのアプリについても後からテストを加える形だったそうですが、
- 複数の箇所からネットワークアクセスがある状態へのテスト
- => Mockを使用
- iPhone, iPadという複数のプラットフォームに対してテストが必要
- => shared_
exampleを利用
- => shared_
また、

その他にも以下のような説明をしていました。
- 新しいコードはテストがなければならないというルールを設けた
- クラスはできるだけ小さく保つ
- テストは小さな要素から始める
- よくないコードを書かなければならない場合でも、
どう修正したいのかを残しておく
artsy/eidolon
最後にアートオークションのアプリであるeidolonでのテスト事例の紹介です。Swiftが出た直後から始めたプロジェクトで、
// XCTest
XCTAssertEqual(1 + 1, 2, "...")
// Nimble
expect(1 + 1).to( equal(2) )
// Or
expect(1 + 1) == 2
最後に冒頭の3つの項目を繰り返し、

終わりに
すべてのトークを紹介できないのが残念ですが、

日本でのMobile・
以上がtry! Swift3日目のレポートになります。主催者のNatashaTheRobotさんが以下ブログで語っていますが、
Do you believe in magic? The making of try! Swift Conference Tokyo 2016