[速報レポート] try! Swift TOKYO 2017 1日目 午後II #tryswiftconf

はじめに

こんにちは！初日からtry! Swiftの熱量に圧倒されている加藤です。
1日目午後後半のセッションをレポートします。

↓ネームタグです。可愛いですね(^^)

「SwiftのWeb APIとアプリをともに構築する」 Kyle Fullerさん

概要

この講演では、私たちのiOSアプリの1つを動かすためにSwiftでWeb APIを構築した経験を共有します。既存のインフラとWebサービスをSwiftでどのように書きかえたのかを説明します。SwiftでのWebサービス構築に必要なことと、ハイパーメディアと宣言型プログラミングを活用して長年進化していけるAPIを設計し利用する方法を探ります。

スライド

説明

• 良いAPIとは
  • 実装の詳細を公開しないAPI
• ブログのAPIで説明します
  • GET /postsは全てのポストが返される
  • ページネーションが必要になる
  • GET /posts{?page}
  • この方法だとページが変わった場合に内容が重複してしまう
• このページネーションの問題をどう解決するか？
  • idで解決する
  • GET /posts{?before}
  • では、この変更をどう導入するか
• APIをバージョンで分ける方法がよくある
  • /v1/posts/{?page}
  • /v2/posts/{?before}
• 新しいAPIが新しい問題を発生させることがある
  • RDBを変える場合、例えばidが無い場合、クライアントに変更が影響してしまう
  • 古いAPIを破棄することもある
• REST
  • 変更を予期する
  • サーバーとクライアントが独自に進行していく
  • ハイパーメディアはRESTの重要部分
• Web Linking
  • RFC 5988
  • WebLinking.swift
  • レスポンスを使ってリンクを見つけることができる
• Web Frameworks
  • Frank
  • IBM Kitura（非常にパワフル）
  • Vapor（ドキュメントが豊富。ライブラリが豊富）
• Frankを採用
  • ドメインに特化した言語
  • マイクロフレームワーク
• テストについて
  • XCTest
  • Dredd（HTTPテスティングツール）
  • API Blueprint
• デプロイについて
  • herokuがもっともシンプルだと思っている。メンテの心配がないので。
  • Webサーバーを実行する方法
  • herokuコマンドラインツールを使う
  • IBMのBluemix（herokuのフォーク）
  • dockerも使える
  • 手動デプロイもできる
• モニタリング
  • Papertrailなどで特定のインシデントを見ていくこともできる。
  • 統計情報を活用してグラフ化できる
• もっとも重要なのはAPIの設計である。

「⚡️? 楽しく便利なSwiftチャットボット」 Ray Tsaihongさん

概要

自分自身の日本語の学習を補助するために、パーソナライズされた言語学習ツールとしてチャットボットをSwiftで作りました。どうやったかをお話しします。

スライド

(資料が公開され次第更新します)

説明

• ChatBotを使った体験について
• デザインが良くなるとBotは使い勝手が良くなる可能性がある
• 言語学習Botを作った（デモ）
  • 日本語を学ぶChatBot
  • BotがGoogle翻訳APIを呼ぶ
  • 写真をGoogleかMicrosoftに送って画像認識をしてもらう
• Botを作ることで何が学べるか
  • メッセンジャーアプリは制約があるのでどのようなファンクションが必要か考える
  • コールアンドレスポンスにどんなタイプがあるか（テキスト、画像、音、ロケーションデータ...）
  • とくかくシンプルにすること
  • コマンドラインのインタフェースが複雑化してしまう。
• いろんなリソースがある
  • FaceBook
  • LINE
  • Heroku + Vaporなど
• ぜひBotを作ってみてください！

「Realmを使ってコラボレーションアプリを作る」 Marius Rackwitzさん

概要

このトークでは、オープンソースのRealm Mobile Databaseを紹介し、サーバーサイドコンポーネントと合わせてRealm Mobile Platformsがどのように完成したかを示します。これを利用すると、テクノロジスタックの実装詳細として同期とネットワークを扱うことができます。 これまで大仕事だったライブコラボレーションのような機能を、不意にすべての開発者が簡単に利用できるようになったのです。このトークでは、残りのデータベースの部分をベースとしてリアクティブにアプリを構築する方法を示します。

スライド

説明

• コラボレーションアプリとは？
  • 複数のユーザーが同じ作業をすることが可能になるようなアプリ
  • slack、todoist、JIRA、Google docs、EVERNOTEなど。
• Realm Mobile Databaseについて
  • Realm is not ORM
  • データーベースそのものである
  • モバイル機器のために開発された
• NoSQL
  • スキーマレス？違う
• オブジェクト指向
  • （コードを見せて）Realmのオブジェクトの定義について説明
  • すべてはオブジェクトである
• Realm Mobile Platformについて
  • サーバーサイドにデータベースをデプロイできるようになった
  • データーベースを既存インフラ or クラウドにデプロイできる
• Realm Mobile Platformの活用事例
  • データのバックアップ
  • デバイス間の同期
  • リアルタイムな共同編集
  • 例として、Picture in Pictureを使った字を書く作業
  • 永続性をサポートしているのでオフライン状態になっても問題ない
  • ローカルにデータは保存されてオンライン時に同期される
  • 既存のバックエンドシステムを置き換える
• Realmの通知機能
  • 各プロパティの変更を監視（KVO）
  • オブジェクトの変更を監視
  • コレクションの変更を監視
    • TableViewあるいはCollectionViewとつなげていくことができる
  • ファイル全体の変更を監視
  • すべてのRealmファイルの変更を監視
• イベントハンドリング
  • クーポンを使う例
  • クーポンコードをサーバー側で検証し、validになればクーポンが有効となりユーザーがクーポンを使える
• アクセス権の管理について
  • REST APIを使うのではく、Realmを使う
• 特別なRealmがある
  • admin.realm すべての権限を一元管理する
  • management.realm 権限を変更する
  • permission.realm 権限の状態を一覧・確認する

「独自のツールを構築する」 Orta Theroxさん

概要

あなたは、最小のコード量で、すばやく、最大限のインパクトがあるアプリケーション開発をしたいでしょう。これを適切な抽象化を習得することで実現できますが、これには長年の訓練が必要です。Artsyのモバイルチームには、複数のSwift製アプリがありますが、それは我々のアプリの未来ではありません。 このトークでは、Swiftの利用方法の構築とそれがReact Native導入につながる議論をどのように引き起こしたかについて説明します。

スライド

(資料が公開され次第更新します)

説明

• Swiftから離れた事について
  • アプリを開発するにはいろんな技術があり、それぞれメリット、デメリットある
• 私がSwiftと呼んでいるのはネイティブツーリングとしてのSwiftのこと
• 問題
  • アプリの構築するのに時間やコストがかかるようになった
  • 3人のフルタイムのメンバーがいた
  • カスタムViewControllerがたくさんがある
• パターン
  • コードの再利用がうまくできていないことが原因
• REACT IN SWIFT
  • KATANAみたいなものを作ろうとしたが、React Nativeが良いということに。
• React Nativeでやってみた
  • React Nativeは素晴らしかった
• Swiftのメリット
  • 既存のコードベースとの整合性
  • 人々がワクワクしていた
  • 進化する言語
  • 抵抗が最小限だった
• Swiftのデメリット
  • コンパイルに時間がかかった
  • とにかく遅いという印象
  • API指向のアプリには向いていない
• React Nativeについて
  • デメリット
    • 依存性が593もある
    • 成熟していない技術
    • ものすごくめまぐるしく変更がある
    • 実践的に作られているので、まずFacebookの問題が優先的に修正される
  • メリット
    • API指向アプリにはものすごく良い
• 結論
  • 自分たちのプロジェクトではReact Nativeが理にかなっている
• React Nativeで作ったアプリのソースコードの説明
  • ViewやLabelを使う
  • どこかでリクエストし、データをpropに入れる必要がある
• Relayについて
  • Relay.createContainerをexportする
  • データをキャッシュし、キャッシュされていなければAPIリクエストする

「⚡️? リアルタイム物体検出アプリでよりよいフィードバックを提供する」 Shinichi Gotoさん

概要

近年のコンピュータの画像技術と計算資源の進歩により、iOSデバイス上でリアルタイムに物体を認識するアプリケーションの構築が、以前より容易になりました。しかし、デバイス自体に認識技術を実装することは、アプリ開発の一部にすぎません。ユーザーのやりとりと組み合わせて、適切なフィードバックを提供することは、ユーザーフレンドリーなアプリにとって非常に重要です。このＬＴでは、Wantedly People というカメラで名刺を認識するiOSのアプリの開発時に直面した際の、いかにより良いユーザーのフィードバックを得て解決するかのお話をいたします。

スライド

説明

• Wantedly Peopleについて
  • カメラに写っている名刺を検出できる
  • 検出プロセスについてどうやって実装したかを説明する
• CardFeatureとしてエリアの座標がわかっている
  • DetectionViewControllerがAVFoundationを使っている
  • これだとブレがある
• １つのオブジェクトだけ検出すればいいのであれば簡単

• 複数のオブジェクトがある場合は難しい

  • ルールを定義しなければわからない。そのためにはトラッキングが必要
• トラッキングについて
  • トラッキングIDで物体を管理
  • トラッキングロジックを独自に作った
• 何を検知するのかによって何を使うかは変わる
  • 顔を検知するにはCoreImageを使えば顔面を検出できる
• まとめ
  • 検出するものによって方法は様々だが、最初からトラッキングについて考えると良いかもしれない

「⚡️? UXエンジニアという働き方」 akatsuki174さん

概要

エンジニアとはいえどコーディングができるだけでは良いサービスを創り上げることはできません。このトークではエンジニアがUXを考えることの大切さ、その手法をご紹介します。

スライド

説明

• なぜエンジニアもUXを考える必要があるのか
  • そもそも何のためにコードを書いているのか？
    • ユーザーに気持ちよく使ってもらうためではないか
• UXを良くするためにやっていること
  • ユーザーテストの実施
    • 読書、勉強会への参加で知見を得た
    • ユーザーの気持ちに寄り添った開発ができた
  • デザイン思考はデザイナーの思考法を活用し、イノベーションを起こすプロセス
    • 今は本で勉強中
• まとめ
  • エンジニアは技術に目が向きがちだがUXを考えることが大事