try! Swift 記録 1日目
try! Swift に参加してきました!
ので、メモっていたことを書きます。 本当に雑なので、間違っているかもしれません。 1日目の分です。2日目の分はこちら。
Swift開発者が知りたかったけど聞きにくい機械学習のすべて
- 機械学習ではデータを集めて関数を定義する
- 誤差をエラーという
- 身n長を平均する関数の場合
- 男女で分ければ誤差が違うので精度が上がる
- 複数の要素の係数を定義して足し合わせていくと正確度が上がっていく
- 線形回帰
- アプリ開発者に影響があるか
- ある
- 自分でも理解が深くなくてもできるか
- できる
- 機械学習は言語でいうとまだ ver1.0 みたいなもの
- 普及してきていて勉強できる機会が増えている
- グーグルの TensorFlow とか
- 機械学習はSwiftでできるのか
- 以下の2STEPでできる
- モデル定義して訓練
- デプロイして動かす
- モデルにはパイソンとテンサーフローを使うべき
- テンサーフローのライブラリをSwiftでバンドルすることができる
- Swiftでモデルのポーティングができる
- 以下の2STEPでできる
- どういう時に使える
- AVFoundationやCoreImageを使うようなもの
- UIデザインを使うようなものに似ている
- 確実ではないものに対して
- 機械学習のモデルのインプットはUIのような曖昧なものに向いている(例えば入力フォームとか)
- どこから始められる
Q.例で挙げたメガネの作り方は
サーバで演算して結果をモバイルに送ってレンダリングしている
ニューラルネットワークはすごいので今後はサーバ側でやっていることもモバイルでやりたい
Swift on Android
- SilverSwift の話ではない
- C言語は全ての橋渡しとなる言語
- Swift はそのC言語を触るのが得意
- UIKit は Android に移植されることはない
- Swift が Android で動くことを考えるので UIKit とかのライブラリとかは関係ない
- 本当の Android は SDK(java)で書かなければならなかった
- NDK はお粗末
- Lua
- Blurr SDK
- CMake でプリロードしてそれをシッピングする
- twitter は @codingswift
Q.メモリ管理の違い
SDKではNDKを使っている
Android はJavaメモリ管理を使っている
NDK ではあらゆるメモリを使えるようにしている
SwiftのPointy Bits
- Swiftを安全にしているもの
- 安全とは
- クラッシュするコードもかけてしまう
- 予期せぬ振る舞いの時だけクラッシュする
- 予期せぬ振る舞いを防ぐという意味で安全
- メモリアドレスはbiteが最小単位
- バッファポインタはメモリアドレスのrangeを格納する
アプリを新次元に導く3D Touch
メリット
- 3DTouch はやりたいことに早くアクセスできる
- 3DTouch 特集という取り上げられ方もある
- 3DTouch API は使いやすいよ
実装
- ホーム画面で3D Touchした時には static と dynamic アクションがある
- static は Info.plist で定義する
- 必須項目が二つあって二の項目はオプション
- dynamic はコード上で動的に定義する
Peek & Pop
- プレビューするやつ
- ユーザが3DTouch使えるか確認する必要がある
- viewDidLoad とかで forceTouchCapability == .availabe をチェックする
- 3D Touch 使えない場合はロングプレスで代替機能を実装できる
- updateもする(表示するデータの更新?)
- デリゲートメソッドは二つだけ
- UIPreviewInteraction で圧力の強さも0~1の範囲でアクセスできる
Q.テストできるのか?
まだ試していない
Q.後方互換としてロングプレスを実装することで一応対応できるといったがラッパークラスは用意しているか
OSS があるのでそれが使えそう
Pixcels プロセスと情熱
- 高価なものを安価に利用できるようにするためにアプリを作った
- 大事なこと
- 課題に注目するが大事
- 技術ではなくて人のモチベーション
- 自分のコネを生かす
毎日リアクティブ
どのような時に使うのか
- 複雑なコードがある場合に一定までは複雑になるがそれを越えると簡素化される
- 非同期なイベント(UIや通信)に有効
問題
- call stack が使えないのでデバッグがしづらい
- 一定のストリームごとでデバッギングする
- KVO がパワルのなのでどこでも使いたくなる
- オーバーヘッドがでかく、パフォーマンスが悪くなる。
- バインディングを使っていくことで解決できる
- サイドエフェクトに注意深くinjectしなければならない
- 混沌を避ける
Q.初見の人がいる場での導入できるかと学習コストはどうか
学ぶのは楽ではないがそれほど問題ないだろう
毎日触れていれば大丈夫
リアクティブを試すコミュニティも増えている
クックパッドアプリのテストを味合う
- 全コードは10万行くらい
- Swift コードは 30%
- リリースサイクルは2週間から最近は1ヶ月
- 狩野モデルにいて最低限必要なこと(must be quality)は画面遷移でクラッシュしないこと
- なぜUIテストを実装し続けてきたか
- クラッシュを防げる
- tarnip(ターニップ)でシナリオを書いている
- 設定とかでパスが必要な場合はバージョンに依存してしまうのでハードコーディングしない
- UITest は image diff でやると良い
- API の request 回数のテストも書いている
- UIの8割のテストをカバーしている
- そのおかげで早く安定して開発を行えている
- Appium を使っている
Q.Appium を選択した理由
アーキテクチャの関係
独自のツールを構築する
- ネイティブはコンパイル遅いからリアクトネイティブやってみた
- 抽象化してみようとやってみたところドメイン思考にいきつく
- 再利用できないという結論に
- プロジェクトを分けて差分だけビルドしようと思ったけど長期的に見ると複雑になって大変そう
- API志向にネイティブ開発は向いていないがリアクトネイティブは向いている
Q.どんなアプリでもリアクトネイティブにできるか - 高度なアニメーションをしたいときにはリアクトネイティブが適切かというとどうだろうか - やろうと思えばできるだろうが
Q.???
- ポッドで入れた
- ライブラリーのような扱いで入れた
- メインのアプリケーション起動ではアプリとして扱うようにした