Swiftの動向とアツさを追う try! Swift参加レポート

try! Swift 3日目 参加レポート

この記事を読むのに必要な時間:およそ 5 分

Swiftの世界的カンファレンス,try! Swiftが3月2日~4日の3日間にわたり,渋谷のサイバーエージェントのオフィスにて開催されました。

最終日である3日目に行われた11のセッションのうち,4つを抜粋してレポートします。

Hiroki Kato氏「Motivation based library abstraction」

初めにこの日最初のセッションでもあった,株式会社はてな所属のHiroki Kato氏@cockscombによるセッションを紹介します。

はてな社のアプリは現状ほぼすべてSwiftで書かれているそうですが,その過程で小さなライブラリを数多く作ってきたことを氏はまず紹介しました。その上で,ご自身がこれまで開発の際に作成してきた以下の3種類のライブラリを例として挙げました。

"必要は発明の母"と言うように,これらのライブラリが実務中で必要に迫られて作り上げたものであることを述べた上で,どういった背景があったのか,どのような解決したい問題に対して取り組んだ結果なのか,を紹介していく形でトークが進みました。

  • UTIKit
  • HUDKit
  • HTTPRequestMatcher(カンファレンス時点では未公開)

画像

このレポートでも順番に内容を振り返ってみます。

UTIKit

名前の通り,UTI(Uniform Type Identifier)を扱うこのライブラリは,素のSwiftのままMIMEタイプを扱おうとした際にコードが複雑になってしまう,という問題を解決するために作成されたものだそうです。UTI自体はデータの種類を一意に識別することができますが,独自の構造を持っていることもあり,例えばJPEGのデータに対してその拡張子を取り出すというだけで読みづらいコードとなってしまいます。UTIKitはこの問題を解決するために以下のような特徴・機能を提供し,SwiftらしいインターフェイスでUTIを扱うことができるようです。

  • 簡潔な記述
  • 同一性の確認(Equality)
  • パターンマッチによる識別(Confirmance)

例えば,MIMEタイプがimage/jpegであるものと,拡張子がjpegであるものの等値性を以下のようにして確認できます。

UTI(MIMEType: "image/jpeg") == UTI(filenameExtension: "jpeg")

HUDKit

続いて紹介したHUDKitもアプリケーション開発の中で生まれたもので,以下のような場面においてHUDを利用するために作成されたそうです。

  • ブログ記事投稿後のユーザの操作への割り込み
  • SNSへのシェアの際にシェアするかどうかの確認

HUDに関しては既存のライブラリもありますが,viewベースのものでは不十分で,viewControllerとして扱うことができるHUDKitを作成されたそうです。このライブラリでは以下の2つのコンポーネントが提供されていることを紹介しました。

HUDPresentationController
UIPresentationControllerベースで自由にviewControllerを指定できる
HUDProgressViewController
進捗状況をHUDとして簡単に表示できる

HTTPRequestMatcher

最後に紹介したHTTPRequestMatcherは,Universal Linkやhandoffなどの対応で,特定のURLのパスでは特定のviewControllerを出したい,という際の処理を簡単にするものです。PerlのRouterSimpleを参考にしたもので,文字列でパスの制約を記述し,正規表現でのマッチングとキャプチャを行うことができると説明しました。例えば,あるURLが指定したblogのURLパターンとマッチしているかの判定,また,そのパターン内のblog_idのキャプチャ部分を以下のように書くことができます。

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で回答していました。我々開発者がやるべきことは誰かの要望を叶えるアプリを作ることですが,その過程で他の人にも役立つことがあればコードをシェアしていこうと語り,このセッションを締めました。

画像

著者プロフィール

後藤慎一(ごとうしんいち)

Wantedly, Inc.のソフトウェアエンジニア。

インフラエンジニアとしてサービスを支える仕事をしていたが、プログラマとしての能力を高めたくなり転職。現在はObjective-CでのiOSアプリ開発やRailsでのサーバサイド開発に従事。ヒマがあればSwiftと戯れて生きている。

Twitter:@_shingt

コメント

コメントの記入