try! Swiftに参加してきた
3/2~3/4の三日間、try! Swiftというカンファレンスに参加してきた。
33セッション * 30分という超濃密な構成で過去参加したカンファレンスの中でも最も充実した内容だった。特に、下のようなトピックが多かったような印象がある。
- Protocol extensionなどのSwiftのパワーを使った、より洗練された実装方法の話
- Swiftを使った関数型プログラミングの話
- デザインやアニメーションなどUIにまつわる話
ちょうどいま直面していた課題に関わるようなトピックもあり、セッション後のQ&Aコーナーでスピーカーに話しかけて、ペアプロまでしてもらった。おかげでその課題はすっきり解決できた。
今回のtry! Swiftで最大の収穫は、英語を本格的に学ぼうと思うきっかけがあったことだった。それは、try! Swift公式アプリで自分のライブラリが使われていたことだった。
公式アプリの開発者の方と直接お話しする機会があった。本当はもっと伝えたいことがあったのだけど、あまりに英語ができなくて、ほとんど伝えられなかった。このライブラリのように海外の開発者に伝えられるコンテンツをもてるようになったものの、肝心の英語ができないばかりに非常にもったいないなーと強く感じた。それがきっかけで先月から英語を勉強しはじめている。
SwiftCSVをフルスクラッチした
おととしSwiftCSVというCSVをSwiftで扱うためのライブラリを作った。
けっこう思いつきで作ったので、あんまりちゃんとパースできないし、思ったよりissueがたくさん来てつらくなってしまったので、放置していた。仕事でもSwiftをまったく書けずにいて、Swiftを触るモチベーションも低かった。
今年に入ってSwiftをガンガン仕事で書くようになってモチベーションが復活したので、ひどい有様だったSwiftCSVをフルスクラッチすることにした。幸い、テストコードはギリギリあったので振る舞いは変えずに内部のコードを綺麗にし、Swift 2.1に対応した。
SwiftCSVを書くにあたって活躍したのはGeneratorType
とSequenceType
というprotocolだった。これらはfor ... in
文に渡すことができる独自のイテレータを定義できる。これらの使い方は以前Qiitaにまとめたので参考になるかもしれない。
これらを使うことで、「イテレートされる要素を作る責務」と「その要素を使う責務」を切り分けて、別々のオブジェクトとして定義できる。実際にSwiftCSVでは以下のように切り分けられている。
// CSV.swift init(string: String, delimiter: NSCharacterSet = comma) { let headerSequence = HeaderSequence(text: string, delimiter: delimiter) for fieldName in headerSequence { header.append(fieldName) columns[fieldName] = [] } // ... }
// HeaderSequence.swift struct HeaderGenerator: GeneratorType { typealias Element = String private var fields: [String] init(text: String, delimiter: NSCharacterSet) { let header = text.lines[0] fields = header.componentsSeparatedByCharactersInSet(delimiter) } mutating func next() -> String? { return fields.isEmpty ? .None : fields.removeAtIndex(0) } } struct HeaderSequence: SequenceType { typealias Generator = HeaderGenerator private let text: String let delimiter: NSCharacterSet init(text: String, delimiter: NSCharacterSet) { self.text = text self.delimiter = delimiter } func generate() -> HeaderGenerator { return HeaderGenerator(text: text, delimiter: delimiter) } }
GeneratorType
とSequenceType
を使うことで設計上はうまく整理できたものの、CSVパーサとしての機能はかなりショボい。ダブルクォーテーションに囲まれた,
や改行を認識できていない。けっこう大変そうで僕だけでは対応ができないので、Pull requestを募集している。
HIGで推奨されているアラートをSwiftで効率的に組み立てる
最近、Swiftにおけるエラーハンドリングについて興味をもっている。エラーハンドリングの中でアラートを組み立てて表示するコードをよく書いたり、目にしている。アラートを実装する際に気をつけているのは、ユーザーが目にしたときになるべく怒らせないようにすることだ。ユーザーフレンドリーなアラートを実装する上で参考にするため、Human Interface Guidelines(以下、HIG)を読んでいる。HIGを読むと、アラートの実装にあたって問題点が見えてきた。
問題点
UIAlertController
でアラートを組み立てるとき、テンプレのようなコードを長々書かないといけない。UIAlertController
を使ってHIGで推奨されるアラートを組み立てるには、HIGの理解と注意深い実装が必要になる。
解決策
Swiftの表現力を駆使して、テンプレのようなコードをなるべく排除し、HIGの中で望ましいとされるUIを効率的に組み立てられるような設計を考えた。HIGでは、アラートは1つまたは2つのボタンを持つべきで、ボタンが3つ以上の場合はアクションシートを検討すべきだと書かれている。アラートを1つのボタンを持つConfirmation
と2つのボタンを持つSuggestion
という2つのタイプに分類して、以下のようなenumで表現することを考えてみた。
enum Alert { case Confirmation case Suggestion }
このAlert
という型の値からUIAlertController
を生成する必要がある。アラートに表示する情報はエラーオブジェクトから取得できると、エラーごとに表示すべき情報が統一されて効率的だと思う。そこで、以下のようにNSError
を各caseに関連付け(前回記事を読むとNSError
ではなくFriendlyErrorType
を使うべき場面だと分かる)、viewController
というプロパティを定義した。
enum Alert { case Confirmation(NSError) case Suggestion(NSError) var viewController: UIAlertController { switch self { case .Confirmation(let error): let alertController = buildAlertControllerWithError(error) let cancel = UIAlertAction(title: "OK", style: .Cancel, handler: nil) alertController.addAction(cancel) return alertController case .Suggestion(let error): // 省略 } } }
ここでのbuildAlertControllerWithError(_:)
はNSError
のもつ各情報を使ってUIAlertController
を初期化するようなイメージだ。
Suggestion
の場合、エラーから復帰するためのアクションをユーザーに提案することになるため、その「復帰するためのアクション」をRecovery
として以下のように表現してみる。
struct Recovery { let name: String let style: RecoveryStyle let recover: UIAlertAction -> Void enum RecoveryStyle { case Nondestructive case Destructive } }
RecoveryStyle
は復帰するためのアクションが破壊的(=アクション前に戻せない)か、非破壊的(=アクション前に戻せる)かを表している。なぜこれらを区別するかというと、HIGでは破壊的なアクションは赤字のタイトルにし、アラートの左側にボタンを置くべきとされているからだ。逆に非破壊的なアクションのためのボタンは右側に置くべきとされている。
Recovery
を踏まえると、Alert
の実装は以下のようになる。
enum Alert { case Confirmation(NSError) case Suggestion(NSError, Recovery) var viewController: UIAlertController { switch self { case .Confirmation(let error): // 省略 case .Suggestion(let error, let recovery): let alertController = buildAlertControllerWithError(error) let cancel = UIAlertAction(title: "Cancel", style: .Default, handler: nil) switch recovery.style { case .Nondestructive: let recover = UIAlertAction(title: recovery.name, style: .Default, handler: recovery.recover) alertController.addAction(cancel) alertController.addAction(recover) case .Destructive: let recover = UIAlertAction(title: recovery.name, style: .Destructive, handler: recovery.recover) alertController.addAction(recover) alertController.addAction(cancel) } return alertController } } }
RecoveryStyle
によってaddAction
の順番を変えている。これによってHIGで推奨されているボタンの配置になる。
利用例
let alert = Alert.Confirmation(error) presentViewController(alert.viewController, animated: true, completion: nil)
let recovery = Alert.Recovery(name: "Recover", style: .Nondestructive) { action in print("Recover!!") } let alert = Alert.Suggestion(error, recovery) presentViewController(alert.viewController, animated: true, completion: nil)
let recovery = Alert.Recovery(name: "Recover", style: .Destructive) { action in print("Recover!!") } let alert = Alert.Suggestion(error, recovery) presentViewController(alert.viewController, animated: true, completion: nil)
まとめ
- HIGに沿って実装するとユーザーフレンドリーなアラートになる(はず)。
- HIGに沿って実装するのは、HIGの理解と注意深い実装が必要になる。
- 上記のようなSwiftの表現力を駆使した設計によって、効率的にHIGに沿ったユーザーフレンドリーな実装を可能にできる。
関連記事
FriendlyErrorType
新しいエラーハンドリング
Swift 2でthrow
を使ったエラーハンドリングが新たに導入された。従来のNSError
を使ったエラーハンドリングの問題点は、メソッドにNSError
ポインタの代わりにnil
を渡すことで無視できてしまうことだった。新たに導入されたエラーハンドリングでは、throws
キーワードが宣言されたメソッドを呼び出す際にdo-catch
文で囲うことを強制される。throw
で投げられるエラーはNSError
ではなくErrorType
というprotocolを実装した値だ。Cocoaフレームワーク内のNSError
を使っていたメソッドはthrows
を使うように置き換えられており、今後は独自のエラーを定義する場合はNSError
ではなくErrorType
を使うのが望ましいと考えられる。しかし、ErrorType
にも問題点はあり現実的な設計方針を検討する必要がある。
アプリ独自エラーの実装
NSError
の代わりにErrorType
を使っていく流れがあるものの、ErrorType
にはNSError
が持っていたlocalizedDescription
やuserInfo
といったエラー情報がないという問題点がある。そこで、ErrorType
を継承した新たなprotocolを定義するという方針を考えてみた。
protocol FriendlyErrorType: ErrorType { var summary: String { get } var reason: String? { get } var suggestion: String? { get } }
このFriendlyErrorType
を使って以下のように独自エラーを定義できる。
enum ApplicationError: FriendlyErrorType { case SomethingWrong case DecodeFailed([String]) var summary: String { switch self { case .SomethingWrong: return "Something wrong" case .DecodeFailed(_): return "Decode failed" } } var reason: String? { switch self { case .SomethingWrong: return .None case .DecodeFailed(let fields): let failedFields = fields.joinWithSeparator(", ") return "Failed to decode following fields: \(failedFields)" } } var suggestion: String? { switch self { case .SomethingWrong: return .None case .DecodeFailed: return .None } } }
また、CocoaフレームワークのメソッドはErrorType
を投げるようになったものの、Alamofire等のライブラリを使う際にはNSError
を使うことになるため、FriendlyErrorType
を実装するようにNSError
を拡張する。
extension NSError: FriendlyErrorType { var summary: String { return localizedDescription } var reason: String? { return userInfo[NSLocalizedFailureReasonErrorKey] as? String } var suggestion: String? { return userInfo[NSLocalizedRecoverySuggestionErrorKey] as? String } }
なぜprotocol extensionではなく継承なのか
protocol extensionだとErrorType
にデフォルトの実装を与えることになる。その場合、ErrorType
として渡されたエラーに対してメソッドを呼ぶと、すべてそのデフォルトの実装の結果が返るようになる。一方、FriendlyErrorType
はただのprotocolなので、メソッドの結果はメソッドを実装する各クラスの結果を反映する。
extension ErrorType { var summary: String { return "" } } extension NSError { var summary: String { return localizedDescription } } let error: ErrorType = NSError(domain: "com.github.naoty.playground", code: 1000, userInfo: [NSLocalizedDescriptionKey: "Something wrong"]) print(error.summary) //=> "\n"
protocol FriendlyErrorType: ErrorType { var summary: String { get } } extension NSError: FriendlyErrorType { var summary: String { return localizedDescription } } let error: FriendlyErrorType = NSError(domain: "com.github.naoty.playground", code: 1000, userInfo: [NSLocalizedDescriptionKey: "Something wrong"]) print(error.summary) //=> "Something wrong\n"
エラーの利用例
FriendlyErrorType
を実装したエラー型を実際に利用してみる。Alamofire、SwiftTask、Himotokiを使ってQiita APIを呼び出している。
return Task<Void, [Item], FriendlyErrorType> { progress, fulfill, reject, configure in Alamofire.request(.GET, "https://qiita.com/api/v2/items").responseJSON { response in switch response.status { case .Success(let value): if let objects = value as? [AnyObject] { var items: [Item] = [] for object in objects { do { let item = try decode(object) as Item items.append(item) } catch DecodeError.MissingKeyPath(let keyPath) { reject(ApplicationError.DecodeFailed(keyPath.components)) } catch { reject(ApplicationError.SomethingWrong) } } fulfill(items) } else { reject(ApplicationError.DecodeFailed(["root"])) } case .Failure(let error): reject(error) } } }
NSError
を拡張しているため、ApplicationError
とNSError
をFriendlyErrorType
として並べて扱うことができている。
FriendlyErrorType
を使ってアラートを表示する実装は以下のようなイメージだ。
let title = error.summary var message = "" if let reason = error.reason { message += reason message += "\n" } if let suggestion = error.suggestion { message += suggestion } let alertController = UIAlertController(title: title, message: message, preferredStyle: .Alert) presentViewController(alertController, animated: true, completion: nil)
以上のような方針に基づいたサンプルアプリケーションを用意した。
関連記事
2015年の振り返りと2016年に向けて
2015年
2015年はRailsをやってる時間が長かった。Androidを少々書いていた時期もあり、ほんの僅かな時期iOS(Objective-C)をちょろっとやってた。Rails自体への意識を高めていこうとした時期もあり、その結果として初のrails本体へのコミットも果たした。ただ、コードを書くこと自体よりも、チーム全体の成長や開発効率を高めることに集中していたように思う。どれか一つに注力していたわけではなかったので、外部イベントで話せるような深い話がまったくできなかったのが歯がゆかった。
関数型プログラミング、DDD、Go言語など新しい分野の勉強もしていた。特にGo言語は、自分用の小さいツールをたくさんGoで書いたことでそれなりに書けるようになってきたと思う。一番驚いたのは、naoty/Timepieceがなぜかバズって、海外からStarをたくさんいただいたことだった。
開発以外のトピックとしては、7、8年かけてたメガネをやめてコンタクトにしたこと、卓球ハウスが解散して練馬区に引っ越したこと、いろいろあって"社会的状況"になりつつあることがある。
開発以外の時間が充実しすぎてあんまり開発してなかったが、最高の一年となった。開発してても幸せにはなれない、そこに幸せはない、という数年来の想いが確信へと変わった一年だった。
2016年
今年こそはiOSアプリ開発に専念できたらしたい。Railsはいい加減コリゴリなので。アプリ開発に専念するからには、UI設計などのデザイン業務にも徐々に慣れていきたいなーと欲が出てきている。
前述のTimepieceの保守も継続させて☆1000を突破したい。ただ、これ以外にも他のジャンルで新しいiOS開発関連ライブラリを作っていきたい。できれば、少し大きめのイベントでも発表できるようになっていきたい(これまではあまり外部での発表に重きを置いてなかったけど、なんだかいろいろ心配になってきたので)。
あとは、12月の引っ越しを期に人生初の自炊生活を始めたので、ちゃんと自炊を習慣にしていきたいというのが大きな目標。
本年も何卒宜しくお願い致します。
「エンジニアのための時間管理術」を読んだ
- 作者: Thomas A. Limoncelli,株式会社クイープ
- 出版社/メーカー: オライリー・ジャパン
- 発売日: 2006/10/19
- メディア: 単行本(ソフトカバー)
- 購入: 11人 クリック: 322回
- この商品を含むブログ (153件) を見る
この本を読もうと思った背景は2つある。1つは、前回のエントリーでも書いた通り、最近は仕事を効率的に終わらせてプライベートの時間をちゃんと確保しようとしていることだ。もう1つは、7月から新卒のメンターを担当しており、作業の割り込みが増えたことだ。新人には分からないことがあればどんどん割り込んでほしいと伝えているため、メンターが割り込みを処理しつつ普段の業務もそつなくこなす必要がある。
この本は「エンジニアのための」と書いてあるが実際はシステム管理者をターゲットとしており、プログラマーである僕とは少し事情が異なるかもしれない。それでも、割り込みへの対処法やタイムマネジメントなど、その他の職業にとっても有用なノウハウがたくさん書いてある。
本書を通して感じたことは「考えることを減らして、目の前の作業に集中しよう」というメッセージだ。良い習慣を身につけたり、外部記憶装置やカレンダーのようなツールを使ったり、単純で頻繁に行う作業を自動化したりすることで、考えることを減らすことができ、割り込みやタイトスケジュールによって作業効率が落ちるのを避けられるという話が多かったように思う。
その中で特に印象に残ったのは、とにかく外部記憶装置を多用しようという話だ。本書ではPDAがその例として出てくるが、若者はPDAなんて使わないと思うので、仕事でよく使うツールに置き換えて読んでいた。本書で言われていた通り、頭のなかで覚えておく作業が増えてくるとだんだん目の前の作業に集中できなくなってくる気がする。
僕の場合、会社ではメール、スケジュールはすべてOutlookで管理されているので、やるべき作業もすべてOutlookで管理するようにしてみた。その日のTODOリストは自作のtodo管理ツール*1で管理しているが、1日の始まりにOutlookからやるべきことを棚卸ししてTODOリストに追加している。逆に、すべてのTODOをTODOリストで管理してしまうと、TODOリストがいつになっても空にならず達成感がもてなくなってしまう。すべてのタスクを記録する外部記憶装置と短いTODOリストに分けることでうまく機能しそうだ。
その他にも今すぐ実践できそうなノウハウがたくさんあったので試行錯誤して効率的に仕事をこなせるようになりたい。
近況
最近大きな環境の変化があったり先日行ってきたYAPCで影響を受けて心境が変わってきたので、近況という形でブログに残しておきたい。
大きな心境の変化として、プライベートの時間の使い方を変えようと思っている。より優先度の高いことに時間を使うようにして、プライベートでプログラミングする時間は以前より少なくなりそう。あれこれ手を出すというよりは1つのことに集中して時間を充てる方が効果的なんじゃないかと思うようになったので、何にしようか考えている。
- 仕事で使う可能性がありそうなScalaとPlayFrameworkに興味がある。以前にすごいH本を読んで関数型プログラミングを実践してみたい気持ちがある。
- あとは、いま仕事ではRailsプロジェクトに携わっているけど、リファクタリングを喫緊の課題として感じていて、プライベートの時間でいかに対処すべきか本を読んで考えてみたり、必要なライブラリの開発に時間を充てるのもいいかもしれない。
- JavaScriptをキャッチアップしたい気持ちもちょっとある。YAPCのセッションでES6の話を聞いて、ちゃんと学んで既存のプロジェクトに手を加えたい気持ちが湧いてきた。ただこれは上のリファクタリングが済んだ先の話だと思った。
- 「ドメイン駆動設計」をずっと読んでたけど、引き続き「実践ドメイン駆動設計」も読んでみようかなという選択肢もある。ただ、まだ仕事で使えるような段階にはない気がする。
- naoty/Timepieceの開発は停滞しているけど、どうしようかなと思っている。仕事でSwiftが書けるのであればまだモチベーションを維持できるのだけど、残念ながらそのような環境にはいない。
こう整理してみると、リファクタリングについてプライベートでも時間をとるのがよさそうだなと思う。それが一段落ついたらJavaScriptのリファクタリングとかDDDとかに移っていけそう。もっと余裕が出てきたらScalaやろうかなぁ。
なんとなくあと2, 3年先までの見通しが立ってきた。仕事ではとりあえず今のプロジェクトを地道に改善していくことになりそう。自分の成長というよりはプロダクトの成功やチームの成長にフォーカスしていきたいという気持ちに移ってきている。Rubyの上にも3年、という感じ。iOS/Androidもやるけど。プライベートでも、今の生活の先に明るい未来が見えてきている。堅実に仕事を進めつつ、貴重な時間を大切にしていきたい。