My Favorite Things - Coding or die.

とある技術者の経験記録、的な。

try! Swift 2017 Tokyo に参加してきた - 2. 1日目

1日目の内容を感想を混ぜつつまとめていきます。
https://www.tryswift.co/tokyo/jp

通訳で聞いた内容で、ちゃんと聞き取れなかった箇所もあったと思うので間違っている箇所もあると思います。

なお迷ったのですが、箇条書きについては発表の場で書いたものをそのまま載せています。なのでたぶん講演を聞いていないと、あるいは聞いていても分からないような表現もあるかもしれませんがご了承ください。(まぁそこは自分用のブログなので、ということで)

一見して不要な情報に思えても、あとから見るとそうではないこともあると思うので。

Swift開発者が知りたかったけど聞きにくい機械学習のすべて

メモ

  • 機械学習、最新の技術をキャッチアップしていくのは大変。
  • データを集めて、関数を定義。
  • 誤差 → エラー
  • 線形回帰?
  • 驚くような結果を出すので、みんな熱中してる
  • Swiftの開発者にどんな関係があるか?
    • YES
    • そのうちどこでも採用するようになって普通になる?
    • 勉強していなくても出来る
    • 代数的データ型
    • Swiftが普通になったように、機械学習も同じようになる
    • Pythonは科学技術の分野でたくさん使われていたから
  • AVFoundation、CoreImage
    • 遅延実行モデル?
    • UIと同じように正確ではない(ユーザに見せてみるまで分からない)
  • どこから始めればよいのか?
    • 誰も専門家ではない
  • まとめ
    • 単なる流行りではない

感想

最近のビッグワードではある「機械学習」について、Swift開発者にとっても今後、あるいは既に関係してきている、という話。

そこまで目新しい内容があったわけではないけれど、機械学習というものが一般化してきているということをあらためて感じた。

今まであまり強い興味を持ってはいなかったけれど、勉強してみようと思った。

Swift on Android

  • なぜ?
  • C言語のABIは安定している
  • Android NDK は中途半端
  • Bionic(libcは使ってない)
    • いろんなプラットフォームから取ってきた寄せ集め
  • Lua→組み込み向けのスクリプト言語(AnsiCに互換)
  • 様々なNDKバージョンがある
    • バイナリを公開してもNG
  • libICU
  • staticにリンクすれば良いけれど、DLLにしないとだめ?
  • JNI
  • Cに見えるけれどSwiftのコードになっている
  • Swiftの関数に対して、C向けの設定をできる(@_cdecl)
  • イベントループをブロックしてはいけない
  • ObjcRuntimeはAndroid上ではない
  • グローバル変数の扱いには注意(DLLがメモリ読み込み済みだと前回の値が残る)
    • 再初期化用のAPIを用意する
  • 3つのテクニック
    • SwiftPM
      • 使えない
    • 自分でやる
      • 超大変
    • CMake
      • Android Studio でサポートすることを表明
      • Xcodeのプロジェクトを生成できる
  • IUP
    • Luaを作ったのと同じ大学?
    • GUIだけ
    • Cで書かれている
    • モバイルでも行ける
    • ダイアログをViewController、Activityにマップ
    • デスクトップ、モバイル、全部サポート
  • まとめ

感想

AndroidとかWindows上でSwiftのコードを動かす、という話。 なんというかハッキリ言って大変難しい内容でした(笑)

Swiftの関数宣言に@_cdeclという属性をつけることで、C言語から呼び出せるインターフェースにできるというのは知らなかったので、そんな機能が備わっていたのか、と思いました。

おそらくこれらのテクニックを自分で使うことはないと思いますが、クロスプラットフォームについていろいろ聞けて面白かったです。機会があればクロスプラットフォームとまでは行かないにしても、SwiftでModelコードを書いて、それをAndroidJava)のJNIから呼び出せるようなことが出来たら面白いと感じます。

SwiftのPointy Bits

メモ

  • Safe / Unsafe
  • ExeBadInstruction
  • off by one
  • 未定義動作
  • unsafe API を使えばメモリ操作が出来る
  • 8byte=ワード(64bit)
  • メモリアドレスは最小単位が8byte
  • なぜ4つのタイプがあるのか?
    • 型あり
      • 中途半端な位置にアクセスすることはない
      • Intなどの具体的な値がpointeeで返ってくる
      • UnsafePointer
      • UnsafeMutablePointer
    • 型なし
      • UnsafeRawPointer
      • UnsafeMutableRawPointer
    • インスタンスではなくタイプでMutabilityを制御
  • どういったときに使うのか?
    • CのAPIを使う
    • SKSearchFindMatches、暗黙的な変換が行える
      • ので、明示的にRawPointerなどを渡す必要はない
    • 安全性と引き換えにスピード
    • defer
    • UnsafeMutablePointのstaticメソッドを使えば余計な初期化も省ける
    • バブルソート
      • Unsafe使うとかなり速くなる
  • ポインタの誤用(2つ)
    • ポインタをエスケープしない
  • FAQ
    • rawPointerを使うと未定義動作に繋がる(エスケープに注意)

感想

Swiftでポインタ操作とかをやる、という話。

安全性と引き換えにスピードが必要な場合、あるいは本当にローレベルのプログラミングが必要な場合に使えるテクニックだと感じました。

個人的にポイント型がいろいろあってあまり理解できていなかった部分が整理できて良かったです。

ポインタのエスケープがマズイという話が最後にあったのですが、そのあたりは微妙に理解できませんでした。

アプリを新次元に導く3D Touch

メモ

  • iPhone6+ 以降で導入
  • 5年かかった
  • 早く機能にたどり着ける
  • 3D Touch 対応だとストアでも目立つ
  • APIとして使いやすい
  • 最大4つ
  • static / dynamic
  • static
    • コンパイル時に決定
    • info.plistに書く
    • 必須が2つ、他はオプショナル
  • dynamic
    • コードで生成
    • ユーザが使ったことがないと表示されない?
    • 直近で使ったメニューを表示とか(カフェ)
  • Widget
    • compact / expanded
  • Peek / Pop
    • プレビューとか(画面に遷移せずに見れるというメリット)
    • 確認すべきこと:ユーザが使えるか(自分でOFFにも出来る)
      • viewDidLoadでチェックすると良い
      • アプリを使っている最中でもOFFにされる可能性がある
      • 互換性
        • UIGestureRecognizer(Long)
    • 実装
      • UIViewControllerPreviewingDelegate
      • showだけでコミットできる
    • UIPreviewInteraction
      • 0〜1で生の値を取れる(例:スピード調整)
      • ソースとなるViewを設定する
  • 通知にも利用できる
    • ユーザの目を引く
    • 実装
      • UNNotification framework #別プロセス
  • FAQ
    • テストできるか?
    • ラッパーはあるのか?

感想

3Dタッチは簡単に導入できて、ユーザビリティを改善できるからみんなも導入してみては、というお話。AppleStoreでも目立つので、そういった意味でも良いとのこと。

3Dタッチの知識が不足していたので、いろいろと技術的な説明もあってありがたかったです。そしてAppleがこれを開発するのに5年を要したというのは驚きでした。

3Dタッチを利用して、画面に遷移させずにプレビューさせる、という使い方を初めて知ったのですが、個人的にはユーザにどうやって気付かせるか、というのが課題だと感じました。

まだ3DタッチはUIとして新しいものなので、今後広く使われるようになったタイミングで真価が発揮されるのかな、とも思います。

Pixcels、プロセスと情熱

メモ

  • 暴露療法
  • モチベーションを維持するのは大変
  • 実験とフィードバックを繰り返しながら(小刻みに)
  • 解決ではなく課題に注目するようになった
  • プロダクトではなく人々が大変
  • 自分や周囲を含めて幸せを目指す(自分のモチベーションを保つの大変)
  • コネクションを大切にする
  • 快適なゾーンを抜けてみる
    • 最低でも何かを学ぶことが出来る

感想

プロダクトを開発する過程についてのお話。

このような発表の場で「モチベーションを維持するのは大変」という事実を話してくださって、個人的には勇気づけられました。

そして「解決ではなく課題に注目する」というのは面白い視点だと思いました。

毎日リアクティブ

メモ

  • リアクティブ楽しい
  • パラダイムをmixして使っている
  • 非同期に変更されるデータに対して反応する
  • ポイント
    • Stateを減らす
    • 宣言型のコード(How -> What)
  • FW
    • RxSwift
    • RxCocoa
    • SwiftBond
  • 背後にあるアイディア(コンセプト)は一緒
    • 1回学べば潰しが効く
  • いつ使うべきか?
    • 複雑なアプリケーション
    • MVVM
    • async ops
    • 解決を目指す
  • トレードオフ
    • デバッグが辛い(コールスタックは使えなくなる)
      • 怪しいストリームをロギングする
    • 命令形のコードを混ぜるとリアクティブの意味が無くなる
      • bindを使う
    • Hot/Cold
      • 副作用は本当に必要な場合だけにする
    • カオスを避ける
      • 別スレッドから呼ばれるケースを考える
      • 値を変更せずに新しい値を生成するとか
  • リアクティブプログラミングの展望
    • AppleのFWなどのリアクティブ前提でないものとの連携は大変
    • APIがちゃんとリアクティブをサポートするように

感想

特定のFW(RxSwift)とかではなく、リアクティブプログラミング一般についての話。発表でもいろいろなFWのコードが混ぜて説明されていました。

個人的には「デバッグが辛い」というのが利用者にとっての共通の課題だということを知って安心しました。

そしてアンチパターンについてもきちんと言及されていたのも良かったです。頭でわかっていてもこうやって講演で実際に聞けると自信が持てるものです。

リアクティブプログラミングという考え方はやはり有用だと思うので、適材適所をよく考えて適用していきたいと感じました。

⚡️🎤 Unsafe Swiftの安全性

メモ

  • 未定義動作は辛いよ
  • Swiftではいろいろ考えている
    • 非初期化されていない値へのアクセスは許可しない
  • Set/Dictionary

感想

ハッシュ値の計算をメモリ内容からやったら良いんじゃないか、という話。 コード内容を覚えていないのですが、あとでスライドが公開されていたら試してみたいと思いました。

ちなみに文字列連結によるハッシュ値計算はよく使っていたのですが、ヒープアロケーションが増えるというのは本当なのかな、と思いました。SwiftのString型は構造体なのでスタックに確保されると思ったので。そのあたりも含めて理解したいところ。

クックパッドアプリのテストを味わう

メモ

  • UIの刷新を何回かしている
  • リリース
    • 1ヶ月単位
    • 5000 -> 100,000Loc
  • 品質
    • Must-be(最低限の品質)
      • クラッシュしないこと
  • ユニットテストを先に書く、はやらない
  • 内部から
      1. UI Tests
      1. re-write / re-factor
      1. Unit Tests
  • 外部から
  • UIテスト
    • 非常に重要
    • 時間もすごくかかる
  • テストピラミッド(上に行くほど小さい)
    • UI Test
    • Integration Test
    • Unit Test
  • 汚いコードで自動化するのはやめろ
  • 8割くらいUITestサポートしてる
  • ターニップ?
  • アンチパターン
    • XPathはView階層に依存するので良くない
    • ラベルを使う
  • バリデーションとかはUIではなくメソッドでテストする
  • Image diff
  • ネットワークリクエストの回数とかも記録してる
    • 余計なリクエストとかが増えてないか、とか
  • 怖がることなく変更できる
  • アールグレイとかも検討(Appiumは使い続ける予定)
  • UIテストは re-enginering をサポートする
  • FAQ
    • XCUITestだとシステムアラートが出ない
    • 遅いけれども毎回クリーンな状態で実行できる Appium を選択している

感想

クックパッドさん定番?のテストについての話。

UIを刷新するタイミングで大規模なリファクタリングが行えているのは、素直にすごいなと思いました。それだけ回帰テストがうまく回さているのだと思います。

個人的にはAppiumでのテストでキャプチャを取って、それを前回のキャプチャとdiffを取る、というテクニックがクールだなと思いました。個人的にもUIテストを導入するのであればぜひやりたいと思っていたテクニックなので、UIテストを今後やることがあれば是非取り入れたいと思いました。

テストについてのいろいろな知見が得られたので、勉強になったセッションです。

⚡️🎤 データレイヤを分離する

メモ

  • 階層がきちんと分離されていれば良い
  • 最小限のアーキテクチャ
  • 層の詳細な実装が隠されるべき
  • DTO、translatorを用意する
  • 複数のチームでも機能する(実装の詳細が隠されるから)
  • 変換コードを書くのは時間かかるけど、スレッド間の問題を負うほうがよっぽど時間かかる
  • チームごとに必要なことだけを知る

感想

データレイヤを分離して、複数チームでも円滑に実装できるようにしよう、そのために昔ながらのDTOを使ったら良いんじゃないか、という話。

個人的にはシンプルだけれど良いアイディアだなと思いました。アーキテクチャがどうのというよりは、複数チーム間で機能させるように考えた、というところがです。

こういう話を聞くと、正解のアーキテクチャなんて無くて、プロジェクトやチームに応じた最適なアーキテクチャがあるだけなのだということを再認識させられます。(これも何度となく言われていることではありますが)

UIをSwiftyに書く

メモ

  • 事前に決めておくこともある
  • けれどコーディング中にパターンが見えてくることもある
  • UIは冗長なコードになりがち
  • 4つのパターン
  • シュレディンガーのコード
  • layoutSubviews
    • 大きくなると辛い
  • Storyboard
    • チームだとコンフリクト解決が辛い
    • 色などが定数で書けない
    • 文字列ベースになってしまう -> Swiftの型安全性がない
    • Outlet接続が間違っているとクラッシュしちゃう
    • AutoLayoutは使わない
  • コードで書く
    • レイアウトが分からない(たった5行であっても)
    • Cartography
      • 宣言的なコードで記述できる
      • 線形方程式を書いている
  • ステート
    • 取得中
    • 成功
    • 失敗
  • 単純にフラグ変数で用意すると不必要な状態も持ち合わせてしまう
  • enumを使う
    • .loading
    • .loaded(item: [MovieItem])
    • .error(message: String)
  • didSetだけで状態を更新する
  • viewのロジックを一元化できる
  • protocolを使って複数画面でも共通化する?
  • デフォルト実装を使う

感想

StoryboardがSwiftの型安全とマッチしないという点と、プロトコルを使った共通的なパターン(取得中、成功、失敗)の実装方法が面白かったセクション。

個人的にはわりとStoryboard派ではあったのですけれど、ちょっと考え方を変えてみても良いかなと感じました。そしてプロトコルの使い方はとてもおもしろかったので、今度サンプルコードとか書いてみたいと思いました。

SwiftのWeb APIとアプリをともに構築する

メモ

  • 良いAPIとは?
  • ページネーションで重複するのを解決する
    • 最後の項目のidを渡す(before)
  • 変更をどうやって管理するか?
    • バージョニング(原始的なアイディア)
  • REST
    • APIの結果にURLとかDOMの情報を含める
      • クライアントが変更不要になる
  • Frank
    • ちっちゃな感じ?
  • Kitura
  • Vapor
    • Web FW
  • Heroku
    • Procfile
    • web: Hello
    • BluemixはHerokuの拡張?
  • Papertrail
  • まとめ

感想

良いAPIの設計指針としてバージョニングではなく、レスポンス自体に画面描画や次のリクエストを含めるという話。あとはSwift製のWebFWについての紹介。

APIの設計指針については微妙に理解が怪しい感じではありますが、なんとなくコンセプトは理解できたような気がします。

WebFWについては個人的にVaporとKituraは触っていたのですが、それぞれの特徴がしれて良かったです。そしてHerokuへ簡単にデプロイ出来ることもわかったのも収穫でした。

⚡️🎤 楽しく便利なSwiftチャット

メモ

  • 良いUIを作ればボットはまだまだ可能性がある
  • たくさんのインターフェースを詰め込みすぎないようにする
    • manページが必要になる
  • Heroku + Vapor
  • Bot用のインターフェースはいっぱいある
    • 文字
    • 画像
    • ロケーション

感想

ボットはUIやアイディア次第でまだまだ可能性はあるよ、という話。

ボットというと地味なイメージがあったのですが、デモを見たらわりと面白いと感じました。個人的にもなにかボットを作ってみたいなという思いもしました。

Realmを使ってコラボレーションアプリを作る

メモ

  • Realmとは
    • オブジェクトデータベースではない
    • モバイル機器のためにゼロから開発
      • SQLiteはモバイル向けに設計されたわけではない
    • 特別な記法は必要ない
  • データベースの同期
    • バイス間の同期
    • 共同編集
    • コンフリクトした場合は自動的に解決してくれる
    • オフラインでも大丈夫
  • Realmの通知機能
    • プロパティの変更監視
    • オブジェクトの変更
    • コレクションの変更
    • ファイル全体の変更通知
    • すべてのRealmを同期

感想

ちょっとRealmの宣伝的なセクションだったような気がします。(まぁスポンサーだし仕方ないね!)

まぁしかしRealmでデータベースの同期がシンプルに実現できるというのは勉強になりました。まぁFirebaseでも出来るようですが :-)

独自のツールを構築する

メモ

  • DANGER(コードレビューを楽にする)
  • 問題
    • アプリ開発はスケールしない
    • もっと早く開発できるようにしたい
    • アプリの全体または部分を再コンパイルする必要がある(から遅い)
    • 画面ごとにXcodeプロジェクトを作るというアイディア
      • 長期的には現実的ではなかった
    • ReactNativeが良かった
      • 開発者のエクスピリエンスは満足
    • コンパイル時間長くて辛い
      • ネイティブ開発は辛い
      • インジェクションというテクニックを使うとビルド時間は1秒くらいに
    • 画面に関するコードは結構な量になる
  • ReactNative
    • デメリット
      • 依存性は593 -> 理解するのはほとんど不可能
      • 若い
      • 変更される
      • 万能薬ではない(当然ながら)
    • JavaScriptのテストはネイティブよりずっと進んでいる
    • TypeScript(現代のJavaScriptは楽しい)
  • React
    • View階層をマスクしようという試み
    • ネイティブ階層を作る
    • JavaScriptをネイティブコードに変換するようなことはしていない
    • Relay便利
  • Appleの主要なアプリでネットワークを使っているのは2つくらい?
  • まずはApple向け、次に外の開発者向け
    • だから良い企業になった
  • Appleは超安全なリリースが重要
  • 我々はそこまで必要でないこともある
    • Xcodeの外に目を向けてみるのも手

感想

開発速度を改善するためにあえてReactNativeを使った、という話。

Swiftは型安全ですし、個人的にも結構気に入っている言語ではありますが、如何せんコンパイル速度は遅いです。そうした現実を受けて、あえて型安全がない代わりにコンパイル速度(開発サイクル)が高速なJavaScriptを選択した、というのは非常に勉強になりました。

Swiftという言語がApple社内向けに作られた言語であり、その次に外の開発者向けである、という洞察にも舌を巻きました。なるほどその考え方は無かったです。

⚡️🎤リアルタイム物体検出アプリでよりよいフィードバックを提供する

メモ

  • ユーザにフィードバックを提供する
  • ラッキング(物体にIDを振る)
  • 検知だけではなくトラッキングについて考えるのも手

感想

リアルタイム物体検出で、トラッキングしたりしてユーザにフィードバックするとより良いUIが提供できるよ、という話。

Wantedlyさんのアプリだったと思うのですが、なかなか良い感じのUIが出来上がっていて、とても良いと感じました。

⚡️🎤 UXエンジニアという働き方

メモ

  • 使ってもらえるから意味がある
  • UXを良くするためにやっていること
    • ユーザテスト
    • デザイン思考
      • 優秀なデザイナーが行っていること
      • 「共感」がポイント
  • まとめ
    • ユーザを忘れない
    • 小さなことでも出来ることから

感想

エンジニアでもUIとかUX大切ですよ、という話。

個人的に「デザイン思考」という優秀なデザイナー日々行っているという言葉を初めて知って勉強になりました。

1日目の終わりに

慣れない通訳でのプレゼンに戸惑いながらも、すごくいろいろな事が聞けて、とても刺激的な一日でした。(あらためてメモをみると、最初はなかなか苦労していましたね・・・やはり)

いやはや、なんというか1日で咀嚼できるボリュームではとてもありません。

Swiftのカンファレンスでありながら、それ以外の発表も多くあったりして、最初はちょっと戸惑ったのですが、結果的にはいろいろな知識を吸収できてよかったような気がします。