try! Swift 最速レポート 2日目午前 #tryswiftconf

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

• try! Swift 最速レポート 1日目午前
• try! Swift 最速レポート 1日目午後
• try! Swift 最速レポート 2日目午後
• try! Swift 最速レポート 3日目午前
• try! Swift 最速レポート 3日目午後

昨日の午後に引き続き、田宮がお送りいたします。

try! swift 最速レポート 2日目午前

こんにちは！朝のコーヒーが欠かせない田宮です！ 今日もマークシティーからSwift開発者たちの大規模なカンファレンス・try!swiftの模様をお伝えします！Developers.IOでは、この模様を随時お届けしていきます！ このイベントでは世界中のSwiftデベロッパーが一堂に会しています。知識や技術を互いに共有し高め合うことを目的としています。 では、さっそくいってみましょう！

目次

オープニング

実践的 "Boundaries"

プロトタイピングの魔法

プロトコルエクステンション：歴史について

Building Women Who Code in Tokyo

Swift版「誰のためのデザイン？」

ランチ！

開会の挨拶

岸川さんから、２日目の注意事項などが説明されました。 本日は、フィリピンから３０人の学生さんがいらっしゃっているとの紹介がされました。Welcome to Japan and enjoy the conference!

実践的 "Boundaries"

発表者：Ayaka Nonaka さん

レポート

日本語と英語の両方でプレゼンをされていた Ayaka Nonakaさん。(Swiftは英語）。2014年のWWDCトーク。「新しいアイデアを得た時は、使えるかな、と思った時に活用すればいい」というメッセージから始まりました。

Boundaries

• 関数型プログラミングで出てくるイシュー。
• ファンクショナルにすることで、副作用なくすることが出来るが、UIKit は副作用ばかり。副作用だらけのものは "imperial shell"を使おう。
• ポケモンボールのように、一部を外にだすことが出来る。
  • アプリのアーキテクチャを俯瞰すると、利用例がいくつも出てくる。
• 2014年のWWDCトーク
  • 「新しいアイデアを得た時は、使えるかな、と思った時に活用すればいい」
• 今日は、幾つかの事例を紹介したい。

imperial shell

• 命令する = imperial(OOP) = functional の逆
• coordinator VCがお互いを知ってる状態を無くしたい
  • VCをUIViewと同じように扱う = immutable　＝　状態を持たないように = 依存性のあるコードを抽出

Coordinator pattern

• 新しいアプリを開発することで、いろんなアイデア、例えばCoordinatorを使うようになった
• ViewController同士知りたくない
• Coordinatorパターンを使うと、アプリは木構造になる。枝を増やせる。

• アプリのフロー全体をCoordinatorに任せると、良い感じ

• ViewContorlllerはimmutableであることを実現
• VCはお互いに依存しないようにしたい

抽象化

• インターフェイスが綺麗というだけでなく、インターフェイスで抽象化するだけでは足りないと気づいた
• 将来性のあるコードをかくために
  • 堅実(Solid)
    • まず、アーキテクチャのどの部分が堅実なパターンに適しているのかを知る
  • 流動的（Fluid）
    • 流動的パターンに適しているのはどこか
  • fluidとsolidのバランスをとる

プロトタイピングの魔法

発表者：Adam Bell さん

Facebook で働かれている Adamさんは、プロトタイピングの話をされました。iOS6までのデザインと、iOS7以降の違いや、PlaygroundとPOPフレームワークを使ったインタラクティブなプロトタイピング技法についてお話されました。

レポート

初期のiPadの広告動画をおぼえていますか？ワクワクした

• iBooks
  • 本をめくれる
  • 本をかえる
• Map
• Mail
  • 紙のように積み上げて、使い勝手のいいもの
• アニメーション・インタラクションがユーザー体験を気持ちいいものにしている。魔法のような感覚。
• 「十分に発展した技術は魔法と区別がつかない」
• それまではなかった体験

iOS7

• システムを通じて、新しいインタラクション、アニメーションが少なくなったり
• ちょっと残念な変化
• たとえば、iOS6のPasbookはとてもアニメーションがあり、分かりやすい。
  • iOS7アニメーションは混乱してしまう。何が起こっているのかわからない。

iPad Pro

• フラットにして、iPhoneアプリをただ引き伸ばしただけ。。
• Garagebandは、いい感じ！
  • こんな感じでパラダイムシフトしてかないと
• アニメーション
  • インタラクションの前、途中、後のギャップを埋めるもの
  • ドキュメントを選択し、ひらき、閉じる
  • みやすいだけでなく、ユーザーが階層のどこにいるかを明示できる
• フラットでシンプルだけど、インタラクションとアニメーションが後回しな昨今

アニメーションはいらない？

• アニメーションはストーリー・命をアプリに吹き込む
• アニメーションは「進行」を示す
• アニメーションを消すと、理解を妨げる
• つまらくなったらその先にユーザーが進まない
• アニメーションやり過ぎは良くなくて、次にな何が起きるかを見せるという意図が必要。
• アニメーションのためのアニメーションはNG

アニメーションは遅い？

• Core Animation は遅くない
• GPUベースで動くし
• 技術的に遅いわけではなく、アニメーションデザインとして、時間が長いとかが問題
• ズームインに５秒は長すぎですよね。早く満足出来るものに。
• 完全にスクリーンをブロックして、決定事項をアニメーションで表示するなどはよくない
• ★１つ！
• アニメーションはシンプルかつ素早くうごかそう。

アニメーションを作るのはむずかしい？

• しかし、やりがいがある
• 開発しているとき「ノー」とは言わないでください。
• 回していく。やめない。

プロトタイプでやりたいことを確認していく

• XcodeのPlaygroudがプロトタイピングに使える。
  • Xcode 7.3 のPlayground で、インタラクティブな、Gesture Recognizerでアクセスできるようになったらしい
• プロトタイピングアニメーション
• POP - 素晴らしいライブラリ
• POPはCAのうえで動く
• CALayerは非同期
• CAPropertyAnimation vs. POP
  • POPでは同期ができるメリット
• Xcode7.2ではPOPをインポートしよう

ポケモンずかんアプリのデモ

• ボール投げるとポケモン出てくるアニメ
  • Phisicsを使うのに絶好
  • Pan Gesture Recognizer
    • ドラッグして、投げるアニメーションの実現
    • 投げる速度を取得
  • 地面にぶつかったことを検知してボールのアニメを止める
  • 少しボールを小さくすることで、遠くに飛ばした感覚を実現
  • スピンしてストップ
    • decay
    • テーブルビューでスクロールがだんだん遅くなりストップするように
  • ボールが爆発するアニメ
• Playgroundでつくったら、あとはアプリにコピペすれば、大体動く

プロトコルエクステンション：歴史について

発表者：Matthew Gillingham さん

iOS Tokyo Meetupなどで活躍されている Matthewさん。これまでのプログラミング言語周りの歴史を紐解きながら、プロトコルエクステンションがどのように生まれたのか、などについて話されました。

レポート

• 歴史はALGOLからはじまる
  • サブクラス
• サブクラスの考え方
  • ただ「車」を作るだけでなく、「トラック」や「カー」など、別の要素をもつものを作る
• 単一継承

別のプログラム言語 - アランケイの Smalltalk でのアイデア

• 後のプログラミングに出てくる考え方が出てくる
• 理想的なアーキテクチャ
  • 抽象的なものをつくり、それを一連のクラスで具象化していく
• 他のプログラム言語で必ずしも良いとは限らない
  • 現実世界とはかけ離れたオブジェクトになってくることがある。
  • OOPがベストアンサーとは限らない

継承への取り組み

• アランいわく、継承は、難しい。
• Obj-Cの開発者は、単一継承には価値が無いという
• Cross-Cutting
• 同じコードを書く必要があったり、コードの共有化ができない

プロトコルエクステンション

• Lisp(MIT)
• OOP
• 複数クラスから継承することの問題
• ダイアモンド問題
  • ２つのサブクラス、同じ実装
  • どの親のメソッドを使いたいのか
  • 1960 / 1970年代のOOPで横断的な問題の解決方法として、複数の継承が解決方法だと思われたが、ダイアモンド問題が認識された。
• ブラッドコックスさん
  • Objective-Cを作った
• プロトコルの良い所
  • プロトコルに準拠していないとコンパイラがエラーを出してくれる
  • requiredメソッドが実装されいるかチェックできる
  • ダイアモンド問題がない
    • 実装がないので、おなじメソッドネームがあっても、コンパイル時にエラーが出ない

Apple

• 1996年、AppleがNext買収
• AppleのOSに取り込まれていった
• 2015年、SwiftはOOPではなく、POPであるとした
• デフォルトの実装ができるプロトコル拡張
• iOS9 アンカープロパティ、UILayoutGuide
• UIView, UILayoutGuide双方に、Layoutableプロトコルに準拠させることが出来るように！
  • ダイアモンド問題の解決
• プロトコルエクステンションはCross-cutting問題を解決するが、別の部分で複雑さが出てきてしまう
  • 名前が衝突してしまう問題

Building Women Who Code in Tokyo

発表者：Himi Sato さん

女性にフォーカスした技術コミュニティーの東京支部で活動している Himi Satoさん。生い立ちから現在の活動までお話されました。

レポート

• Woman for Code 東京支部の共同創業者の Himi Satoさん
• Swift初心者
• テクノロジーはやらず、文学専攻。
• 前職では危険物を運ぶ車に乗っていたという。

Women Who Code Tokyoとは

• NGO
• 女性のテクノロジーへのエンパワメントを目的としている
• 日本唯一の支部
• 全世界50,000人メンバー / 東京は420人
• ミートアップを頻繁に開催
• さまざまな企業がスポンサー

活動を開始したきっかけなど今までの話

• パワハラ、セクハラを３人から同時に別々に受けてきた
• 拒食症に数ヶ月陥り、仕事ができなくなった
• 体重も大きく減った
• 公共交通機関に乗れず、スーツを着た男性恐怖症
• 今は回復したが、未だに困難を抱えている

プログラミングとの出会い

• 休職中にプログラミングを書いた
• 何書いたか忘れたが、すごく楽しかった
• Code Academy HTML CSS JavaScriptを学んだ
• Woman who Codeを知り、参加したいと思ったが、日本になかった
• サンフランシスコのCEOにメールしたら、CEOは「やってみたら？」
• 日本でキックオフ後、NYに行き、ミートアップにも参加
  • 意欲的に技術を学ぶ女性や、企業や社会のサポートがあり、日本でもやりたいと思った
• Woman for code tokyo 火曜のミートアップでは、ホスト企業にお願いし、場所、Wi-Fi、軽食、ドリンクの提供を受け、ミートアップを開いている
• それでも、USとはサポートに違いはあったが
• ミートアップに来たらご飯を食べて欲しいと思った。大切。身を持って体験したこと。
• 在宅の仕事を調べた。経済的にも大変だった
• 救ってくれたのが、woman for codeだった

活動内容

• Rasberry Pi や、IBMの bluemix、Pepper
• 米国大使館共催イベント
  • データ可視化イベント（公私はボランティア）
• Japan Times経由でつながった
• ケネディ大使ほか沢山の素晴らしい女性たち
• 女性から男性にメイクで変身する「リリメン」

Why Swift?

• 女子アプリハッカソン（昨年）
• 朝からキュンキュン目覚ましアプリ
  • 時間になると、自分のタイプのキュンキュンボイスで起こしてくれるアプリ
  • Web applicationだったが、Swiftでネイティブにしたかった

所感

• アプリを完成させる、などのゴールを設けると、続く
• モチベーションを保つために
• 職業別女性比率：エンジニアの女性割合は約１割。
• 女性が少ないということは、業界へのイメージか。
• 性別関係なく、人生のステージにより、会社に通えないから、と諦めることも多いのでは

woman for code tokyo

• 新しい人をドンドン取り入れてきた
• Swiftは新しい。そのコミュニティもそう。
• try!Swiftのようなイベントが沢山あればいいな、と思う
• 開発経験、業界に詳しい、に縛られ無いことが大事では。新しい人を受け入れるようなマインドが大事。コミュニティを育てるために。
• 行動してみるのが大事。
• 人間万事塞翁が馬 - A joyful evening may follow a sorrowful morning

Swift版「誰のためのデザイン？」

発表者：Rachel Bobbins さん

ドナルド・A・ノーマンの誰のためのデザイン?を、UXやデベロップメントに応用する考え方やその実践についてお話されました。

レポート

誰のためのデザインを応用する

• 認知科学の考え方
• ひょっとすると、お互い関係ない領域なのでは、と思ってきたが、同時に素晴らしいアイデア何では、とも思ってきた。
• 可読性高くクリーンなコードを創るためのデザイン思考のHowtoを話したい。
• 構造化、テストしやすいコード

• user focused design

  • ユーザーを中心にしたデザイン
  • Swiftデベロッパとしてどうするか
• 今回のユーザー定義
  • コードを書く人と定義する。デベロッパ。

VCで「ようこそ」と一画面で表示するアプリを例にする

• ゴール、計画、特定、perform
• NSLayout(iOS9)、Localization を使ってみる
• うまく動かない。
  • おかしいと認識する、interpret, compare, 新しいゴールを考える
  • アプリを位置から作るのとは違う、新しい目標考える
  • 間違ったコードを修正すると、問題解決

Action の 7つのステージ

• Goal, Plan, Specify, Perform, Perceive, interpret, Compare
  • 潜在意識で、コーディング、デバッグのなかで、脳の中で起こっている認知プロセス

Desingの7つの原則

• Discoverability（見つけやすいこと）
  • コメント、ドキュメンテーション
  • public, private, internal
  • 名前に気をつける
• Feedback（フィードバック）
  • 自動：コンパイラのエラーフィードバック、実行時のクラッシュ、実行時の体験
  • 人間：ペアプログラミングによるフィードバック、コードレビュー、バグレポート、App Storeのレビュー
• Conceptual Model（概念モデル）
  • iPhoneをスティーブ・ジョブズが紹介した時
    • ３つのデバイスがあります。internet communicator, iPod, Phone, これらは全てひとつのデバイスです。
  • 人間は、いつも概念モデルを頭のなかに描く。それは、属している文化などに影響される。
• Affordances（アフォーダンス）
  • オブジェクトに対して、アクションを起こしたくなる仕組み
  • アプリであれば、ボタンや、UI要素に対して応用できる
• Signifiers（記号表現）
  • 最小値と最高値をもつスライダーの両端にあるアイコン
  • Public, private, internal, names, comments, etc. 全てのコードは、何らかの形で記号表現をもつ。
• Mappings
• Constraints（制約）
  • ハサミは、使い方が決められている
  • Swiftの型システムも然り

ランチ！

昨日に引き続き、様々なお弁当が出ました。デリシャス！

まとめ

今日も海外から沢山の方がいらっしゃって、とても国際的な雰囲気があるイベントだな、と感じました。休憩時間には、様々な場所で輪ができて、技術的な話や、自己紹介、自分たちが作ったアプリの話がされていました。

２日目午前中を振り返ると、imperial shell や coorinator といった、構造・設計の話、プロトタイピングのデザインや実装よりの話、プロトコルエクステンションの歴史、コードと人生・コミュニティー活動の話、誰のためのデザイン？をデベロップメントに応用する話と、大変広範だったと思います。ですが、そのどれもが、実は相互につながっていて、様々な方面からSwiftの世界を見ることが出来、大変勉強になりました。

次は、田中孝明から、２日め午後の模様をお伝えします。お楽しみに！