Swiftが3月2日~4日の3日間にわたり、渋谷のサイバーエージェントのオフィスにて開催されました。本イベントの興味深いセッションをいくつか、日ごとにレポートしています。1日目のレポートに続き、2日目の模様をレポートします。Nonakaさん(@ayanogagon)は、Boundariesで得た知見を元に実践的なSwiftのコードに落としこむテクニックを発表しました。Shell」をどう活用できるか悩んでいたそうです。悩んだ結果、最初は理論を感覚で捉えて、実装時に「使えるのでは?」と思った時に使えば良いと考えるようになったそうです。Shellをネットワーク環境による表面として例示しました。Coreとして振る舞うことができます。Shellとして振る舞うことができるとのことでした。境界(Boundary)を見つける実装設計をする上で、コードのどの部分が不変なもので「堅実なパターン」に適しているか把握し、そして同じようにどの部分がネットワークコードのように「流動的なパターン」に適しているかを把握するのが大切だと言います。「⁠堅実なパターン」と「流動的なパターン」のバランスをとり、境界(Boundary)を見つけることで、安全で将来性のあるコードが書けると述べていました。Bellさん(@b3ll)は、アニメーションのプロトタイピングについてセッションを行いました。7以降のフラットでシンプルなUIのアニメーションを振り返りました。7以降のアニメーションはシンプルなものになっていました。アニメーションが不要になったというわけではなく、アプリケーション自体を楽しくさせるためにアニメーションは重要な要素であると指摘しました。アニメーションは何が起きるのかを見せるものであって、必ず目的と意図が必要とのことです。アニメーションを入れない選択肢をしないまた、アプリケーションの動作が遅くなるからといってアニメーションを入れないのではなく、適切な方法で実装すべきとのことでした。CoreAnimationはフレームを落とさないように設計されており、CARenderServerで高い優先度で処理されるため、最適化をしていないコードで使わない限り遅くなることは無いと説明しました。Xcodeのplaygroundでプロトタイピングアニメーション作成のプロトタイピングツールとしてXcodeのPlaygroundを使った方法を実践していきました。次期バージョンよりジェスチャも使えるようになるため、タップした際のアニメーションも結果が見やすくなっていました。XcodeをSwiftで簡単にプロトタイピングができるようになったので、自分の限界を引き上げるようなコードに挑戦してくださいと述べていました。Gillinghamさん(@gillygize)は、プロトコルエクステンションに至るまでの言語の歴史を紹介しました。継承と抽象の問題まずはオブジェクト指向のなかで、継承という概念が生まれ、やがて抽象クラスの概念ができました。シングルインヘリタンスはクロスカッティング問題が存在します。構造が違うサブクラスが2つ以上存在する場合、片方のサブクラスからサブクラスを作成した場合、もう片方のサブクラスの実装コードの共有ができなくなってしまいます。同じインターフェースを持つ親を複数継承したときインターフェースが衝突してしまう問題があります。この問題はダイヤモンド継承問題と言われています。プロトコルの誕生そこでメソッドの名前で具体的な実装情報は持っていないprotocolという概念が生まれました。protocolはメソッド名のみで実装コードを持たないため、実装コード同士が衝突してしまうダイヤモンド継承問題を解決しました。extensionが生まれ、継承関係のないクラス同士でもクリーンな形で実装コードの共有ができるようになりました。extension同士が衝突した際の問題など、別の複雑さが導入されていることに注意しました。Satoさん(@himisanta)は、コミュニティの運営に関わるきっかけとSwiftとの出会いを紹介しました。プログラミングとの出会い以前在籍していた会社を休職していた時にプログラミングと出会い、コードアカデミーなどのオンライン学習サイトでHTMLやJavaScriptなどを学ぶうちにプログラミングの楽しさに目覚めたそうです。Codeを知ったそうです。Codeはサンフランシスコに本部がある組織で、テクノロジ業界のすべての女性のエンパワーメントを目的として活動しています。当時は日本に支部がなかったのでCEOに直接メールを送ったところ「じゃあ日本でやったら?」とオファーされたとのことです。日本でキックオフイベントを行い、それから1ヶ月ニューヨークに滞在してmeetupに参加したそうです。日本における女性エンジニアを取り巻く環境は決していいものと言えるものではありません。エンジニア全体における女性比率は11〜14%程度の割合で、それ自体が業界自体にネガティブな印象を与えてしまっています。Himiさんは、「⁠海外では意欲的に学ぶ女性や、その人達をサポートする企業があるので、日本でもこの活動が活発になるために日々行動し続けている」と話していました。Bobbinsさん(@bobbins)さんは、心理学や認知科学から考えて製品を設計することについてセッションを行いました。ユーザーに対してフレンドリーなコードD.A.ノーマン著『誰のためのデザイン?』を読んだ時、コードの設計にも当てはまるのではないかと気づいたそうです。コードベースをやり取りする人(同僚、将来のチームメイト)をユーザーと捉えらていました。デベロッパーが無意識のうちに行っている行動を段階別に7つに分類し、そのユーザーに対してフレンドリーなコードを書くためのテクニックを説明しました。Discovarabilityチームメンバーがコードを見た時、どうしたら何ができるかを発見できるようにすることが重要です。そのためには、命名規則を作ることと、Publicなどを正しく指定して、見つけるべきもの見つけないものを区別することです。Feedbackテストなどで、失敗したら修正が必要なことを伝えたり、コンパイルエラーやWarningなど、自動化されたフィードバックが重要です。概念モデル概念モデルについては読み手の経験、バックグラウンド、教養によって様々に解釈されるため、わかりやすくなるように情報提供をすべきです。Affordance意味のあるメソッド呼び出しをすることと、getter/setterを正しく設計することが重要です。SignifierSwiftは様々なSignifierを持っており、それらが何らかのシグナルをデベロッパーに伝えています。データstruntで宣言されたオブジェクトの場合はコピーしても問題ないことを表しているなど、デベロッパーに対して重要な情報を伝えます。Signifier.xcodeprojの構成で部品の関係性を伝えています。制約Swiftの場合は型が正に最高の制約です。間違った型の使い方をするとコンパイルエラーが出るため、Objective-Cであったようなミスが無くなります。DataのAPIをベースにSwiftに置き換えていく方法を紹介しました。Dataに関する仕事をしていたこともあるそうです。Data』も執筆しています。以下の方法で置き換えていきました。Object従来だとエンティティ名をStringで指定していたので型安全ではありませんでした。Extensionでエンティティ名を切り出しました。インサート処理の際に切り出したメソッド名を呼ぶようにすることでコンパイルでチェックできるようになります。Coding従来の方法だとキーの値をタイプミスしやすく型安全ではありませんでした。Extensionを利用し、キーの値にEnumを用いることで、型安全に指定できるように改善できました。ExtensionでSortDescriptor処理を実装することでシンプルに改善できました。Predicateを使用する場合も同様です。ExtensionにA→Bの変換、B→Aの逆変換をそれぞれ実装し、typealiasで宣言しておくことで様々な型に適用できるようにしました。NSNotificationClosureでDelete、Updateなどを処理できるように修正しました。Extensionで通知を確認し、Closureで返すヘルパーを実装し、DidChangeNotificationをラップすることでシンプルな書き方に改善していました。Extensionを駆使して既存APIをベースにSwiftコードに置き換えていました。これにより、既存APIのスピリットを尊重しつつ、Swiftの書き方で活かすことができると話していました。Khanさん(@novallkhan)さんは、デバッグコンソールを使ったテクニックを紹介しました。LLDBについてLLDBのデバッグコマンドを知ることで、エラーをより早く見つけられるようになるそうです。compilerの2つのコンパイラを持っています。コンパイラが内蔵されているため、デバッグコンソールに打ち込んだコードは実行中のアプリケーションで呼び出すこともできます。モジュール(UIApplication)にもアクセスできます。SwiftのエラーハンドリングLLDBはSwiftのエラーハンドリングに対応しており、該当箇所でブレークした後、LLDBのコマンドで「expression」を使用すればthrowされるエラーの結果を見ることができます。swift」とすればエラー発生時にブレークされるようになります。EnumError」と指定すればよいそうです。CustomStringConvertibleまた、ネストされたデータ構造をデバッグ出力するときに、出力結果を見やすくする方法を説明しました。CustomStringConvertibleを実装することで、出力されるデータ構造を見やすくなるとのことです。Huiさん(@jeffhui)は、Swiftのライブラリの開発についてセッションを行いました。テスト(CI)について一定のレベルを保証したいのでテストは必ず組み込むようにしているそうです。CIが有効な選択肢で、.travis.ymlファイルだけで設定が完了するのでオススメとのことです。テストスクリプトもプラットフォームごとに同じことを書けば良いとのことでした。実際にライブラリを例に作業手順を説明しました。パッケージマネージャへの対応その際、以下の3つへの導入を考慮すべきとことでした。Managerの注意点として、SwiftLinux自体が安定していないことを挙げていました。新しいバージョンが毎週出るほど問題があるそうです。そのため、SwiftEnvという環境ツールを使って指定のスナップショットからインストールしなければならないと話していました。リリースの際のバージョニングセマンティックバージョンの付け方についても言及がありました。詳しくはsemver.orgを参考にしてくださいとのことです。Programmingを適用したネットワーク関連のコードに関するセッションを行いました。NSURLSessionをProtocolを使ってラッピングする実装のゴールとしてはリクエストの型を指定すると自動でレスポンスの型が決定され、型安全にレスポンスが取得できるようにすることでした。この設計にProtocolが適している理由は以下の2つだそうです。リクエストとレスポンスを紐付けが可能になるProtocol内でtypealiasなレスポンスを宣言し、レスポンスを返すメソッドを作成することで、リクエストとレスポンスを紐付けることができます。リクエストの結果を受け取った時にレスポンスを返すメソッドを使用することで、リクエストごとに違う型を返すことができます。デフォルト実装をフレキシブルに実装できるDecodableというProtocolでdecodeメソッドを定義します。ExtensionのメソッドでResponseからdecodeメソッドが呼べるようになります。参考になるソースコードは以下のものだそうです。Protocolsページングなどの制約をprotocolで表していました。上記のProtocolに準拠したページネーションクライアントを実装Protocolで定義したメソッドでしか実装しないことで汎用的なページネーションタイプのクライアントになれるとのことです。Stream最後にRxSwiftを用いて、リフレッシュとネクストページをトリガーにしたリアクティブプログラミングをライブコーディングを行っていました。Cramerさん(@mennenia)は、Sketchをつかったアプリアイコンの作成方法を紹介しました。例としてSketchを使ってアプリのアイコンを作りました。矩形はShiftを押してドラッグすると必ず正方形になるそうです。矩形を組み合わせてビルを表現したり、楕円を組み合わせて雲を表現していました。ウェブアイコン(地球儀)も円、縦線、曲線をうまく組み合わせて作成していました。して10分くらいでアプリのアイコンを作成方法を説明しました。Devicesというデバイス画像のテンプレートを使うのがオススメとのことでした。Controllerの使い方を紹介しました。セッションで使用されたコードはGitHubで公開されています。シンプルなTableViewを作成し、最終的にはGenerics、Structを用いて編集した内容を戻すUndo機能を実装していました。TableViewConfiguration次に、TableViewConfigurationというItemをGenericsで指定されたStructを作成しました。TableViewに表示するitems、TableViewのstyle、cellのstyle、editable、セルの設定を行うclosureも実装しました。TableViewを表示するのに必要な構成要素をStructに切り出したことで、TableViewController側に表示制御するためのコードがなくなりました。TableViewControllerの実装がシンプルになり、TableViewConfigurationの要素を変更すればTableViewControllerを再利用できる構造になりました。Undoの実装そして、UndoHistoryというItemをGenericsで指定されたStructを作成しました。Itemを2重のArrayにすることで操作によるItemの変化を逐次残せるような構造になっていました。懇親会2日目のセッション終了後にスポンサー限定の懇親会が開催されました。スピーカーの方々や参加者とコミュニケーションしたりと貴重な経験となりました。次回はスポンサーとして申し込むことも検討してみてはいかがでしょうか?(3日目のレポートに続きます。Ltd.ページ内容の全部あるいは一部を無断で利用することを禁止します⁠。個別にライセンスが設定されている記事等はそのライセンスに従います。