try swift 2018 tokyo day 2 参加メモ

try swift 2018 tokyo 2日目の参加メモです。

Expression Problem を解決する

発表資料
niwatakoさんのまとめ

  • MapViewのようなものを作るときUIViewのサブクラスを作って解決する
  • UIViewだとMacOS, Webで使えない
  • どうするか
  • Expression Problem: 拡張性の問題
  • 解決策
  • enumで解決できないか?
  • EnumKit
  • こういうenumを定義
enum View {
  case button
  case textField
}
  • renderメソッドを定義
extension View {
  func renderSomething() -> Something {
  }
}
  • iOSだとUIViewで実装
extension View {
  func renderSomething() -> UIView {
  }
}
  • Viewを追加したいときにどうするか
  • ライブラリに追加するのはよくない
  • non exhaustive enumkit はどうか
  • デフォルト実装が必要になりよくない
  • protocolを検討してみる
  • Selfに注目
protocol View {
  static func button() -> Self
  • SelfがREALに置き換わる
extension REAL: View {
  static func button() -> REAL
}
  • 新しいViewを追加するときはprotocolを追加
protocol WithMapView {
  static func map() -> Self
}
  • もっと知りたい方は Final Tagress Style で検索すると関連した話題が見つかる
  • もっと詳しく知りたい人向けに4つの資料を紹介(詳しくは発表資料で)

⚡️🎤 Swift もくもく会 in Barcelona

niwatakoさんのまとめ

  • 開発者が一箇所に集まって共同作業する場を提供した

Swift によるアルゴリズムの可視化

niwatakoさんのまとめ

  • Bezier曲線の話
  • アルゴリズムについて理解する必要がある
  • Playgroundを使ってSwiftで描いてみる
  • ライブコーディング

Kitura で Codable ルーティング

niwatakoさんのまとめ

  • JSONエンコード、デコードについて
  • jsでは簡単
  • swiftは型安全に処理する必要がある
  • Swift4からEncodable, Decodableが提供された
  • Encodableに準拠するコードも大変
  • Kitura: Build end-toend application in Swift
    • クライアント、サーバを同じ言語で書ける
    • Swiftはメモリのフットプリントが低くサーバサイドの実装に向いている
  • Kituraとクライアントの実装について。JSONのEncode/Decodeを中心に

⚡️🎤 超解像+CoreML+Swiftを使ってアプリの画像データ転送量削減に挑戦する

niwatakoさんのまとめ

  • 超解像: 解像度の低い動画を高くする技術
  • SEMethod
  • Deep Learingを使ったテクニック
  • 低解像度の画像をダウンロードし、クライアントサイドでSR On Core MR
  • MLModelを学習して用意した
  • Modelをアプリに取り込む。とても軽量
  • OpenSourceで公開

iOSでCharlesを導入する

niwatakoさんのまとめ

  • プログラミングを学び始めた1985年ごろデバッグは難しかった
  • AdobeでFlushの開発をしていた
  • ネットワークを多く使う開発だった
  • 問題が発生するとネットワークが問題なのかクライアントが問題なのか判断が難しかった
  • iOSでCharlesを使うのは少しめんどくさい
    • wifiの設定を変更しなければいけない
  • iOS用のCharlesを用意しようと思った
  • CharlesはJavaで実装されていた。大変だった
  • iPadでも動く
  • iOSのCharlesにデータが残る
  • デスクトップで確認することができる
  • プロキシ設定不要
  • コンピュータ不要
  • wifi不要(mobile通信でもOK)
    • まだAppleレビュー中

拡張現実における体験設計

niwatakoさんのまとめ

  • 現実の種類
    • VR
    • AR
    • Mixed R
    • 素晴らしいAR体験をするためにどうすればいいのか
  • デザインプロセスの話
  • 頭にあるアイデアは完璧に思えるので紙にかけ
  • イテレーションのサイクルを短くする

Swift エンジニアのための Kotlin 入門

niwatakoさんのまとめ

⚡️🎤 Swift5のOwnershipに備える

niwatakoさんのまとめ

  • メモリのパフォーマンスの高度な制御が可能になる
  • sharedキーワードを使う
  • コピー不可能な型の提案もされている
  • 先発のRustでも学習コストが取り上げられている
  • Rustは理解必須だが、Swiftはオプトイン機能

デジタル信号処理 in Swift

niwatakoさんのまとめ

  • DSP
  • 信号を操作するテクニック
  • デジタル音声はフーリエ変換なしに考えられない
  • フーリエ変換とは音を聞いたときの耳の反応
  • AVFoundaionはかなり強力
  • Swiftで見逃しがちの事に焦点を当てたい

内容が難しく理解できなかった。

15:25 - ⚡️🎤 Codableが導く型安全な世界

niwatakoさんのまとめ

  • Codable: Support Encoding, Decoding
  • Codableはjson以外にも使える
  • protocolと組み合わせるとうまく使える
  • userDefaults/keychainにも使える
  • Dictionary, URLQueryのCordableを実装してみた

iOS / Swift における対話型インターフェースの作成

niwatakoさんのまとめ

  • 対話型インターフェースの音声のインターフェースについて
  • おじいちゃん、おばあちゃん。対話型インターフェースなら使える
  • 魅力:面倒なことはソフトウェアが行ってくれてユーザの負担が少ない
  • 音声認識を行う方法はいくつもある
  • いずれも音声認識はサーバ側で行われ、結果がクライアントに戻ってくる
  • iOS Speech Recognition APIの実装の紹介
  • Amazon Lexの実装の紹介

UIImageView vs Metal

niwatakoさんのまとめ

  • Metalを通してGPUレイアについて
  • UIImageViewとMetalのグラフィックスレンダリングパフォーマンスの比較

画像表示とGPU

  • 画像表示の基本的な処理の流れ
    • processor -> FrameBuffer -> screen
    • 60フレームならprocessorが1秒に60回書き込む
  • processerは2種類
    • CPU:スポーツカーのイメージ。はやいが多くの人は乗せられない。
    • GPU:バスのイメージ。はやくないが多くの人を乗せられる。
  • pixelの処理順番が変わってOK。画像処理はGPUに向いている

metalとopenGL

  • yourapp -> metal -> GPU
  • metalとopenGL
    • openGLiOS以外の多くのプラットフォームで動く
    • metalはAppleのハードウェアに最適化されている

metalの実装

  • metalを使うとコード量が多い
  • Metalのwrapperクラスがあれば良いのでは
  • MetalImageViewを作った

パフォーマンス比較

  • TableViewに画像を表示するサンプル
  • metalの方が早い
    • UIImageView: 0.4 0.6
    • metal: 0.02 0.05
  • スクロールするとMetalが遅い
  • 先程の計測だとGPUの処理が含まれていなかった
  • 修正結果
    • UIImageView: 0.4 0.6
    • metal: 40 200
  • UIImageViewは既に早い
  • WWDC2017のPlatforms states of the unionでUIKitは既にmetalを使っていると発表されていた
  • metalを使った自分の実装がなぜそんなの遅かったのか

実装の確認

  • Instrumentsでtraceしてみた
  • resize->renderingという処理
  • この処理の間に時間がかかっていた
  • GPUの処理完了をCPUで待っていた
  • resize, renderingでCPU,GPU行き来していた
  • resizeとrenderingを同じCommandBufferにまとめた
  • 短縮できた
  • texstureのキャッシュが必要
  • GPUではどこでキャッシュするか気をつけなければいけない
  • CPU側にキャッシュしてしまうと遅くなる

⚡️🎤 Swiftが動くDockerコンテナの各OSの性能比較

niwatakoさんのまとめ

  • Ubuntu 14.x and 16.x
  • Swiftのバージョンアップにより安定した環境を用意するのは難しい
  • Dockerを使う
  • vaporのDocker Imageを用意した
  • Ubuntuバージョン間のパフォーマンス比較をしたが、差がほとんどなかった
  • imageの容量の差 16.xのほうが小さかった

⚡️🎤 型とパフォーマンスで見るType-erasureの利点

niwatakoさんのまとめ
https://github.com/tarunon/try-erasure

  • closuereを使用しないtype erasureの実装の紹介
  • 各type erasureのパーフォマンスの比較
  • 詳しくはgithubを見る

VisionとCoreGraphicsで顔をでかくする

niwatakoさんのまとめ

  • 顔の領域を取得する方法を探した
  • Visionでは顔の下半分しかとれない
  • Visionの下半分の情報を反対側にも描くことでやってみた
  • 点の操作にCoreGraphics
  • うまくいった

開発者ツールと経験への時間投資

niwatakoさんのまとめ

いくつか例を見ていく

コンパイルに時間がかかる

フレームワークを分ける

フレームワークを分けられない場合

データに対する依存

手動データ入力(ログイン画面など)

  • 開発時にいちいちデバイスに手入力するのは面倒
  • 自動化すべき
  • breakpointを設定して設定すると一番簡単
  • 多くのステップが多い場合は向かない
  • #if でデータを設定するようにする

問い合わせ対応

  • ユーザが見た最後のViewModelをシリアライズ化して保存し、バグレポートに含める
  • 単方向アーキテクチャを使うとログをすべて記録できて再現できるようになる
  • 本当に素晴らしい

ボイラープレートコードを書くこと

  • 毎回お決まりのコードを書く必要はない
  • ライブラリを作った
  • ライブラリが動くなくなったら削除し、コードを書く作業に戻すだけ。導入しやすい・
  • テストのFakeオブジェクト作成にも使える

asset

try swift 2018 tokyo day 1 参加メモ

try swift 2018 tokyo 1日目の参加メモです。

裏 Swift Tour

発表資料

  • 以下の順で紹介
    • 値への代入
    • オプショナルな値への代入
    • Closure
    • enum
    • Never
    • inout
    • return
    • didSet
    • defer
    • init, deinit

以下、気になった点のみメモ

  • オプショナルな値への代入を使って、成功時のみ処理を実行する事ができる
    • (obj.v = 10)?.map { /* do */ }
  • int?にintを足し算できない。一度アンラップしなければならない。
    • 自前でint?にintを足し算するoperationを追加できる
  • Int!を使っているところでIntを使うテクニック
    • 初期値としてnil, 意味のないダミーの値ではなくクロージャを使って解決
    • クロージャはどんな型でもとれる
    • let a: Int = { fatalError() }()
  • inoutの挙動   - didSetがある変数を渡すとコピーが渡され、inoutの関数の最後に代入される   - didSetがない変数を渡すと参照が渡され代入される度に代入される
  • differ
    • initでの値設定ではdidSetが呼ばれないがdiffer内の変更は呼ばれる

SIL入門

niwatakoさんまとめ

  • Swift Compailerの開発の中で得た学びを共有
  • Swift Compailerの中のSILについて
  • なぜSILなのか
    • Swiftの型システムが学べる
    • いろいろな最適化が行われている
    • 楽しい

Clang モジュールの探検

niwatakoさんまとめ

  • Cocoapodsの開発者の発表
  • インポートとかモジュールマップに関する話
  • Ccoapodsの苦労が垣間見える

レスポンダチェーンを知ろう

niwatakoさんまとめ

関心の分離と単純化のためのSwiftコードの最適化

niwatakoさんまとめ

  • コードは書かれることよりも読まれる事のほうが多い
  • howからwhatを切り離す

関心の分離と単純化を行ったサンプルを紹介

  • 1,2: extensionの例
    • utf16.countが複数
    • 例えば3ヶ月後にわからなくなる
    • private extensionでurf16.countをどうして使っているのかの意図を明らかにする
  • 3,4: Autolayoutの例
  • 5: UITableViewの例
  • 6: UserDefaultsの例
  • 7: SafeAreaの例
  • 8: Viewの例
    • タップ領域を確保するViewクラスを用意した
  • 9: UIStackViewの例
  • 10: ViewControllerの例

コーダーがデザインすべきなのか

niwatakoさんまとめ

  • デザインとはどう機能するか
  • コンテキストの欠如を回避する必要がある
  • デザイナは考えないエッジケースをエンジニアが見つける
  • エンジニアとして技術的に何が可能化をチームメイトに理解させる手助けをすべき
  • ユーザはデザインに習慣化していく(ios標準のアラートなど)
  • 子供からは多くの質問が上がってくる、そのようは質問に全て応えられるようにすべき
  • 子供の視点を大切にすべき。未来はそうなっているかもしれない。
  • Appleの3例
    • 録画時のシャッター音を消す
    • Active Device
    • Face ID

Event driven networking for Swift

niwatakoさんのまとめ

変性のダイヤモンド

niwatakoさんのまとめ

  • Swiftの共変、反変の話

SwiftyPi

発表資料 登壇者のリポジトリ
niwatakoさんのまとめ

  • RaspberryPiでSwiftを使う話
  • Swiftがいろいろな環境で使えるようになってきた
  • OSを選ぶ。 Raspbianかubuntuがおすすめ
  • ラズパイをどう立ちあげるのか
  • Swft4.1のARMv7対応はまだ
  • Swift3.1.1をバイナリダウンロード
  • Swiftからpinを指定するにはGPIO番号を使う

我が家を支えるSwiftの技術

niwatakoさんのまとめ

使ってるサービスや技術

UI Test の楽しさとメリット

発表資料
niwatakoさんのまとめ

  • Trelloのエンジニア
  • コードのテストは簡単
  • UIのテストは難しい
  • たくさんのレベルがある。どこのテストを自動化するのか検討する。
  • XCUITestを採用することにした
    • 原因不明の失敗が20%発生するので導入はおすすめしない
  • kickstarterはUnitTestでほとんどテストできているのでUIテストを行っていない
  • 現状のTrelloのGOAL
    • smokeテストの自動化
    • MockAPI
    • Snapshot testing

ブロックチェーンのクライアントをSwiftで実装する

niwatakoさんのまとめ

  • ethereumはAppstoreのようなもの
  • objc or js で実装する
  • block chainはクライアント開発に向いている
    • web3.jsは、ReactNative or webKitを使う

Protocol Oriented WebAPI Abstraction

niwatakoさんのまとめ

👾

niwatakoさんのまとめ

  • Swiftでゲーム開発する話
  • Xcodeでゲーム開発環境は充実している
  • SpriteKitを使って開発
  • SpriteKitはSceneとNodeからなる。UIViewControllerとUIViewの関係のようなもの
  • GameplayKitにゲーム開発のデザインパターンがまとまっている
  • ゲームでrx
    • rxSpritekit

AST メタプログラミング

niwatakoさんのまとめ

  • Abstract syntax tree
  • SourceKitが生成したASTを使ったライブラリがいくつもある
  • ASTはSourceKitのものだけではない
    • SourceKit, SwiftKitten
    • swiftc -dump-parse, SwiftSyntax
    • swiftc -emit-syntax
    • swiftc -dump-ast
  • SoureceKitはc++。SourceKittenはswiftのラッパー
  • swiftc -dump-ast はすべての型情報が含まれている。ただパーサーはない。文字列出力のみ
  • swiftc -emit-syntax jsonフォーマット
  • SwiftSyntax ASTの生成から変更するAPIを提供している
  • SwiftSyntax, swiftc -dum-pastはspecがまだ固まっていない

Aspect Oriented Programing in Swift

  • レイアにまたがった処理の実装。ロギングなどに向いている
  • Swiftのbuildphaseをインターセプトする方法は用意されていない
  • コード生成して再ビルドする仕組みを作った
  • 作ったもの

Droidkaigi2018 day2 参加メモ

詳解 ViewGroupのレイアウト内部実装

http://seto-hi.hatenablog.com/entry/2018/02/03/163035

各ViewGroupの内部実装がどうなっているのか理解できる素晴らしい発表でした。
内容が盛りだくさんでほとんどメモ取れていないので少しだけ。詳しくは資料で。補足も充実してる。

  • MeasureSpecでどの程度でMeasureしてほしいか指定する
  • ConstraintLayoutはCassowaryを使っている
  • Cassowaryを使うほど複雑ではないViewの場合にOptimizerを使う実装になっている

Elastic Team Building

https://www.slideshare.net/YukiNanri/elastic-team-building

  • 現場の生々しい話
  • エラスティックリーダーシップは良い本
  • フェーズ毎に取るべきリーダーシップは異なる
    • サバイバルフェーズ: チームに学習する時間が十分にない状態
    • 学習フェース: 十分なゆとり時間があり、その時間を使って学習や検証を行っている
    • 自己組織化フェーズ: 自分がいなくてもチームがある程度回る
  • それぞれのフェーズでどのようなことがあったか紹介

サバイバルフェーズ

採用

  • 採用に苦労した。コネがない、エンジニアのことがわからない、誰も来ない。
  • グローバルの存在に気がつき、グローバルもターゲットにした。
  • 面接効率が悪い。
  • 面接を2段階にした。1段階目がダメならそこで終了し、効率良くした。

チャットコミュニケーション

  • プライベートメッセージでコミュニケーションする人が多い。情報共有が一部だけになる。
  • プライベートメッセージが来たらパブリックに促すようにする
  • slackのAnalyticsでプライベートとパブリックの比率が見れるので定量的に傾向を分析できる

会議

  • 会議が増えてきた。会議は何も生み出さない。
  • アジェンダのない会議が多く、非効率
  • アジェンダを事前共有してもらうように促していった。フォーマットも用意。
  • ブレストはOK。だが、ブレストで何を決めるかまで明確にして効率的にする。

グローバルメンバーとのコミュニケーション

  • 日本語で始まった会話でも英語になるように促してあげる
  • コミュニケーションを定量化して評価することが難しい
  • 英語を学んでいこうという雰囲気にはなった

学習フェーズ

ドメイン設計

  • ドメイン知識がプランナーからエンジニア等に広がっておらず、認識のずれが大きくなってきた
  • DDDのユビキタス言語の整備と分からないと発言しやすい環境にする

技術的負債

  • 問題になっている箇所をメンバーで話し合う
  • 定量化しずらいなのでどのように評価するかチームで話し合う必要がある

自己組織化フェーズ

  • リモートワークで、自分がいない環境になった
  • 自分がいなくても機能していた
  • リモートワーク大変。解決できていない。

React Native Androidはなぜ動くのか

Reactとは

  • Viewがツリー階層になる。propsもツリー要素になる。
  • 再描画が強い

Reactではないもの

  • React, React DOM, React Nativeに役割分担されている

React Native Andriodとは

JSとJavaのブリッジ機構

  • JavaのクラスをJavaScriptの公開するイメージ
  • @ReactMethodのメソッドは先程のスレッドなのでネイティブのUI処理はUIスレッドで行う必要がある
  • jsとjava側の両方に仮想DOMがある

すばらしきGraphQLのSEKAIへようこそ

https://speakerdeck.com/gfx/subarasikigraphqlfalsesekaiheyoukoso

SSD Schema Driven Development

  • schemaとロジックの開発を同時に進めること

  • リソース取得系が非常に柔軟かつ強力

  • リソース更新系はメリットは少ない
  • GraphiQl
  • リクエストからレスポンスがだいたいわかる
  • 方は基本JSONと同じ。intとfloatの違いはある
  • non nullも定義できる
  • relay
    • ...
  • クエリは手書き

GraphQLとAndroid

  • Appolo Client。クエリからJavaコードを生成するライブラリ
  • 本命はjavascriptかなという感じはある
  • view componentとqueryを同じファイルに書く
  • モデルや腐敗防止層は不要になりそう

gRPCとProtocol Buffersで作る、一味違う通信周り

https://speakerdeck.com/kmats/protobuf

RPC

  • RPCは他のアドレス空間にある処理を実行すること
  • REST:リソースを中心に考える
  • RPC:アクションを中心に考える
  • RESTが向いているサービス:ブログAPI(CRUD)
  • RPCはURLにアクションが入ってくる(事が多い。仕様で決まっているわけではない)
  • CRUDに収まるのであればRESTの方が良い
  • RPCが向いているサービス:slackのようなチャットサービス   - チャンネルを去る leave   - チャンネルから強制的に退出させる kick   - 同じような処理だがちょっと違う   - RESTでは難しい。RPCにしてしまおう。   - 実際SlackのWebAPIはRPC

gRPC

gRPC-Android的に

  • 通信に必要なコードが自動生成される
  • RPCフレームワークとして無難。Googleの安心感
  • 双方向ストリーミング

デメリット

  • 世の中の情報がまだ十分ではない
  • セキュリティに不安
  • Twitch
    • 内部実装の浮く雑さに起因する問題
    • HTTP/1.1を使えない
  • TwitchがTwirpというフレームワークを使った   - シンプル   - HTTP/1.1化   - protobufだが、json mapping化(gRPCはない)prodobufにはある

protbuf

gRPC/protobuf

  • リクエスト部分までコード生成される

開発の工夫

  • 書く環境で.protoファイルをどのように同期するか
  • github webfuck - google cloud functions - digdag

ウィンドウサイズの変更に強い堅牢な画面の構築

https://speakerdeck.com/nakamuuu/droidkaigi-2018

  • 変更
    • 画面回転
    • マルチウィンドウ
  • 弱い画面とは?
    • レイアウト崩れ
    • 画面の状態を適切に保持できない

レイアウトの構築

  • マルチウィンドウ機能により
    • 幅高さともに狭い状態のレイアウトを考慮する必要がある
    • 通常と異なるシステムUIの配置
  • ステータスバーの高さを取得するというアプローチはいったん疑うべき
  • fitsSystemWindows問題
  • fitsSystemWindowsは一つのViewにしか設定できないのか。そんなことはない
  • View#onApplyWindowInsetsをオーバーライドしなくてもOnApplyWIんどwInsetsListnerで横取りすることができる
  • WindowInsetsの扱いを工夫する

画面の状態を適切に保持

  • android:configChangesを指定して自前でも管理できるが基本的にはなし
  • Handling COnfiguration Changeに詳しく書かれている
  • toolargetool
  • onSaveInstanceStas¥te or setRetainInstance
  • 寿命が違うのでデータの保持
  • 復元可能化どうかで使い分ける
  • サーバから取得して復元可能なものはsetRetainInstance
  • 入力途中の状態のものはonSaveInstanceState
  • onSaveInstanceStateからの移行
    • retainer を作った
  • 寿命が異なるものを用いたときの整合性を担保したい
    • AACのViewModelを使う

Gradleプラグインを作って開発効率を改善しよう

https://speakerdeck.com/tnj/guide-to-build-gradle-plugin-for-efficient-development

  • build.gradle
    • 純然たるGroovyスクリプト
    • .gradleファイルはリモートにおける
  • Projectはbuild.gradleと同義に考えて良い
  • Extension
  • 設定値を格納するオブジェクト
  • 実態はJavaBean
  • setting.gradleはルートを示すために必要なのでからで良い
  • バージョン指定するだけ
  • groupは先程のidの前半。 archivesBaseNameは先程のidの最後

Droidkaigi2018 day1 参加メモ

まだ途中

Kotlinアンチパターン

以下の環境で得られたアンチパターンについて紹介

  • 巨大なアプリ
  • メンバーの開発経験が様々
  • 最大11人

lateinitのnull初期化

  • 通信後などonCreateなどよりはるか後の処理で初期化してしまい、初期化前にアクセスしてしまう

補足

  • kotlin 1.2 から isInitializedが追加され

apply内でプロパティアクセス形式の処理を書く

  • ローカル線数を宣言すると参照する変数が変わりバグになる

解決策

  • メソッドがあればメソッドアクセスにする
  • apply内はthis必須にする
  • applyを禁止してalsoを使う

nullableのままデータを引き回す

  • 毎回nullの考慮が必要になる

nonnullにするために無効なデータを入れる

  • 無効なデータに意味がある場合にバグる
  • nullが何を表すかで処理するレイヤを決めることで解決

data classのインスタンス生成用のメソッドで制約を持たせる

  • copyメソッドで1部のプロパティのみ変更できるので、制約が守られなくなる

処理を共有化するためだけにBaseクラスを肥大化させる

  • javaでは継承余地も異常と言われていたが、intefeceのdefault実装で共通化すると良さそう
  • java8からあるがminSDKversionを24以降にする必要があったのでKotlinのアンチパターンとして紹介
  • 状態を使いたい場合はclass delegationを使うと良い

拡張関数

  • 一般性がない、局所的にしか使わないメソッドを追加する
  • 公式でありそうな名前なのに雑に実装する
  • 拡張関数が便利なので乱発しがち
  • interfaceのデフォルト実装のスコープに限定する

通常の代入、lazy、custom getterをよくわからすに使う


補足

  • delegated propertyを使うとgetter/setter処理を移譲できる

fragmentのviewをlazyにする

custom getter 値を取得する過程で副作用がある、計算量が多い

  • このような場合はメソッドにする

custom setter で常に必要とは限らない処理をしている

  • 値だけを変更することができなくなってしまう
  • 更新用の処理は関数で提供するほうが良いケースも有る

Deep dive into LayoutManager for RecyclerView

  • キャッシュは2つある
    • recycle
    • scrap
  • RecyclerView.LayoutManagerのsupportsPredictiveItemAnimationsを紹介

DataBindingのコードを読む

  • BindingAdapterをインスタンスメソッドに定義できる
    • Componentを用意して追加する感じ
  • InverseBindingAdapterを使って双方向バインディングの定義ができる

Android における Model-View-Intent アーキテクチャ

セッションは聞いていないのでtwitterを見ていて気になったところだけメモ

マルチモジュールのすヽめ

なぜマルチモジュールなのか

  • 主要機能だけではなくログイン・ログアウトや強制アップデートのサブ機能が多く複雑になっている
  • ログイン・ログアウト、強制アップデートの機能をモジュールとして切り出してマルチモジュール化
  • Android Instant App対応するにはマルチモジュールする必要がある
  • Android Gradle Plugin 3.0.0からマルチモジュールプロジェクトのパフォーマンス・チューニングが行われた
  • domainそうにAccessTokenを持っていてでもそれはinfra層から使うよね。
  • AccessTokenを別モジュールに分けることで上位の層を用意していろいろなところからアクセスできるようにした

デメリット

  • databindingとの相性が悪い
  • appにもmoduleにもdatabindingの生成物か生成作られるようになった
  • moduleでrecyclerViewのBindingaAdapterを定義した場合にappにもrecyclerViewを追加するする必要がある
  • Data Binding Compiler V2で解消される予定

モジュールの分け方について

  • レイアで分ける or 意味のある単位で分ける
  • レイアだけでやるのはおすすめしない。
  • 意味あるまとまりで分けて、さらにレイアで分けると良い

Case Annict

  • 機能整理する
  • 明らかに主要機能から外れている機能を探す
  • 機能間の依存関係を洗い出す
  • グルーピングして依存関係を考える
    • 基盤機能を考える

実際にマルチモジュールにしてみる

  • New Moduleすれば追加できる
  • Androidに依存するならAndroid Module。そうでなければJava Module。
  • modulesディレクトリを作ると見通しが良くなる

モジュール間の連携について

  • moduleをまたがった情報を表示するときどうするか
    • 各moduleでfragmentを定義して、まとめ画面ではatatchするだけにしている
  • 他モジュールから情報を取得したい
  • 最上位層のみを公開する。ViewとServiceで分けている

CA.kt #4 (Kotlin Conf報告会) 参加メモ

cyberagent.connpass.com

『Kotlin Conf Keynote』森 洋之

  • 一言でいうと kotlin anywhere
  • 様々なplatformで採用されている

server side

  • パワフルなJVM
  • KtorというKotlin製のWebフレームワーク
  • コルーチンがたくさん使われている
  • コルーチンはexperimentalだが、experimental=不安定ではないので、今すぐ使おう

kotlin android

  • GoogleI/Oでの発表以降Kotlin製のアプリが2.5倍に増えた
  • アプリのKotlin採用率は17%
  • Android Studio 3.0
    • Plugin同封
    • Lintサポート
    • プロジェクトテンプレート
  • Support Library 27.0.0からKotlinのNullablityの対応がすすでいる

各プラットフォームのコードシェアについて

  • 共通のロジックを作る仕組みが導入された
  • expectとactual

『Kotlin Conf Overview』藤原 聖

『Spring and Kotlin』長澤 太郎

  • Bootiful Kotlinが良かった
  • ライブコーディングなので動画待ち
  • SpringはReactorというライブラリを使っている
  • Exposed
    • Kotlin製のSQLライブラリ

『Kotlin Types』荒谷 光

  • FRESHのエンジニア。サーバサイドでも使っている。
  • KotlinのStringはJavaのStringをいい感じにラップしている
  • Unitとvoidは一緒

『Kotlin Puzzlers』仙波 拓

データサイエンティストにどうやって学べば良いか聞いてみた

ざっくりどうやって学べば良いか聞いてみた

  • https://www.datacamp.com/を紹介頂いた
    • ハンズオンでデータ分析を学ぶ感じ
    • ここで概要を理解すれば、後はWEBのナレッジが理解できるようになるらしい

次に機械学習をやる場合について教えてもらった

次にデータ分析を業務で行うことについて教えてもらった

次に業務を離れてそもそもデータ分析とはについて聞いてみた

追加で聞いてみた

  • Q: どういう数値を取っていくかというのは、勉強するよりも業務をやってく中で学んだり、他社事例をキャッチアップするという感じになりますでしょうか?
  • A: 最先端の手法を使うなどでもない限り、他社の模倣や定番の手法のみである程度のバリューは出せるかなという印象ですね。

最後に参考情報として次のサイト・ページを紹介頂きました

iOSDC 2017 day 2 午後 参加メモ

iOSDC 2017 2日目午後の参加メモです。

コード生成による静的なDependency Injection

発表資料
コード

  • DIの概要について
  • ConstructorInjectionについて
  • DIなし密結合だがインスタンスの生成が簡単
  • DIあり疎結合だがインスタンスの生成が面倒
  • 疎結合インスタンスの生成が簡単にしたい
  • DIをサポートする仕組み
  • インスタンスを自動的に取得する方法
    • DI用のInitializerを登録する(各ノードの生成を定義)
    • DI用のprovider Methodを用意する(全体の生成を定義)
    • コード生成による依存関係の解決

Swiftでの実践

DI用のInitializerを登録する

  • protocol Injectableを用意
  • associatedtype Dependencyを持ち、Dependencyを受け取るinitを定義
  • 依存するものをDependencyにまとめる

DI用のprovider Methodを用意する

  • マーカー用にprotocol Resolverを用意(定義はなし)
  • protocol Resolverを継承したprotocol AppResolver(命名は任意)を用意し、provider Methodを記述

コード生成による依存関係の解決

  • SourceKittenを使う
  • Resolverのprotocol extensionにインスタンスを取得するメソッドを生やす
  • Resolverの実装を行うだけで、インスタンスの生成が可能になる
  • 自動的に取得できないdependencyについては、resolveメソッドに引数を渡せるようにしてある

Human Interface Guidelinesから滲み出る限界感を考える

  • sansanのiOSエンジニアの方
  • Human Interface Guidelines(以下、HIG)の限界について
  • 3つの違和感
  • Apple Storeアプリを例に確認してみる
  • ボーダーのついたボタン
    • 購入するボタンはボーダーがついている
    • Webも同じ
    • AppleStoreのサービスとしてWebとも一貫性がある
    • 一貫性というガイドラインに準拠
  • Toast
    • アラートを使わないためにToast
    • アラートの使用は最小限というガイドラインに準拠
  • セクションの文字がボールド
    • ボールドナビゲーション
    • 要素を明瞭に区別する工夫
    • 明瞭性を上げるためにボールドにする
    • 明瞭性を上げるというガイドラインに準拠
  • AppleStoreアプリ以外でも使われている角丸View
    • iPhoneXで画面が角丸になるのでそれに合わせたのではないか
  • ストアレビューガイドラインには独自のアイデアを生み出してくださいと書いてある
  • 狩野モデルからアプリ品質を考える
  • UIの軸と機能の軸で見てみる
  • HIGは当たり前品質として考えられる
  • UIに魅力的品質を求めるのであればHIGに書かれていないようなことを実装していく必要がある

iOSエンジニアのためのNLP基礎

発表資料

言語判定

  • 文字N-gramを活用して判定を行うことが多い
  • 言語判定は簡単ではないので、予め言語がわかっていれば指定したほうが良い
  • 例えば、HELLOは英語、イタリア語、ドイツ語ある

トークン化

  • 文を単語に分けるようなこと
  • 日本語の制度は微妙

品詞タグ付け

  • 単語に対して品詞をつけていく

レンマ化

  • 辞書の見出し語を抽出する処理
  • 過去形から現在形、複数形から単数形を取得するような処理

固有表現抽出

  • 固有名詞や時間表現をテキストから抽出する技術
  • テキストにおいて固有名詞は重要情報

まとめ

iOSと人工知能(AI) -GPU並列演算の仕組みと機械学習

人工知能とは

  • 生物の知能を模倣する技術
  • 強いAIと弱いAIがある
    • 強いAI:人の知能に迫るAI
    • 弱いAI:限定的な問題解決や推論
  • 弱いAIの利用例:画像処理、音声会話、文章の認識サウ性、機械制御、作曲絵画
  • 種類:機械学習遺伝的アルゴリズム、群知能、その他にもファジイ制御、エキスパートシステムなどある

機械学習とは

iOSの中のAI

  • CoreML訓練済みのモデルをアプリに導入
  • MPS GPUを用いたMetalの高い演算機能をアプリに導入
  • MetalはCoreMLより下のレイア
  • MetalはCPUとGPUのシームレスな連携
  • Metalを用いた学習のデモ

15分でわかるバックグラウンドアップロード

発表資料

  • バックグラウンアップロードはドキュメントが少ない、サンプルがしずらい、デバックがしづらい
  • iOS7以降の処理のBackgroud Transfer Serviceの話
  • 他のアプリを使っている時も自分のアプリで比較的大きなファイルをアップロードできる
  • ForegroundではないイコールBackgroudではない
  • SuspendedやNotRunningもある
  • SuspendedはBackgroundと行き来する
  • バックグラウンド以外にもSuspended, Not Runningもある

仕様

  • 簡単な特徴
    • アップロードはiOS上のキューに積まれ制御される
    • パフォーマンス最適化のためにシステムの都合でスケジュール
    • 失敗したら自動リトライ
  • 制約
    • NSURLSessionはクロージャではなくDelegateを使う
    • Dataではなくファイルで渡す必要がある
    • ユニークなIDを生成して渡す必要がある
  • 呼び出せれるDelegateは2つ
  • エラーについてはアプリ起動時にAppDelegateに用意されているメソッドで検知できる(はず)

役立ツール

  • Network Link Conditioner(通信状況を悪くできる)
  • Charles(Proxyツール)
  • Swiftybeaver(ログライブラリ)
    • 反映に遅延があるのでその想定でつかう必要がある
    • バックグラウンドに入るログを確認する時に使える

ハマりどころ

  • timeoutが難しい
  • timeout関連のプロパティは2つ
    • timeoutIntervalForRequest
    • timeItervalForResource
  • forRequestは検証が難しくあまり理解できていないがサーバでの処理時間だと思われる
  • forResourceの方はリトライ含めたタイムアウトなので、望まないリトライはこれで制御できる
    • デフォルトは7日で長めに設定されている
  • iOS11からAPIが増えた
  • プロセスは別で動く

サポート効率を上げるログ収集環境の構築

発表資料

  • トレタでiPad担当をしている方
  • アプリが成長していく中で・・・
    • 再現性のない不具合問い合わせが増えてきた
    • コミュニケーションコストが増大
    • ハードウェアも使い始めてさらに複雑化
  • アプローチ
    • クラッシュ以外の通信エラーなどを検知できる体制
    • 調査に必要な情報をなるべく増やす
    • 問い合わせ時のコストを減らす

クラッシュ以外の通信エラーなどを検知できる体制

  • クラッシュ以外でもログを送れるサービスを選定
  • 今まではHockerAppを使っていた
  • Bugsnag, sentry, crashlyticsを比較
  • Bugsnagを採用することに
  • パンくずログが非常に便利なのでそれが使えるものを選んだ
  • パンくずログはエラーが発生するまでの道標を残す
  • iOS標準でもActivityTracingでパンくずログを確認できる(クラッシュ時のみ)

調査のヒントになる情報をとるように

  • どういう操作を行ったか、どういう状態、環境だったかを取る
  • どういう操作を行ったか
    • ViewControllerの遷移ログ
    • その他UIイベント
    • これらをパンくずに入れていく
  • どういう状態、環境だったか
    • ユーザの端末状態
    • 多くのサービスは自動収集
  • その他、Reachabilityのイベントをパンくずに追加している
  • コンソールのログ(AutoLayout崩れなど)を吐き出し場所を変更することができ、それも送っている

問い合わせ時のコスト

  • 課題
    • 調査に必要なログがそもそも取れてない
    • 日本語で的確に伝達するのが難しい
  • ロジックエラーも詳細に列挙すると良い
  • どういうエラーが発生したかを詳しく呼び出し側に渡す
  • エラーコードが大事
  • エラーコードをユーザにも表示して問い合わせしてもらうようにする

カンファレンスアプリを作ったぞ!!

  • BuildersConのアプリ
  • タイムテーブルについて

アプリ開発アンチパターンを踏み抜きながらアプリをフルリニューアルした話

  • sansanアプリをフルリニューアルしている話

5分でわかるServer-side Swift Vaporの魅力

  • vaporの紹介

関数を引数として渡す書き方のポイント

発表資料

  • 関数を引数に渡すところを少し書き方を帰るだけで、より宣言的に書ける方法を紹介

自分が欲しいとアプリを作った

発表資料

  • Typeというアプリを作った話

Fun with Swift 4 KeyPaths

  • Swift4の強力なKeyPathsについて

地方在住iOSエンジニアの生存戦略

  • 地方でどういう生活をしているかやどんなふうに情報をキャッチアップしているかなど

UIテストの実行時間の短縮に挑戦する

発表資料

  • bluepillや複数のMacを使ってUIテストを並列にして短縮した話

翻訳のススメ

発表資料

  • 翻訳作業を行っている方の翻訳のススメ

2017年におけるiOSアプリ開発のCI事情

  • CIそのものの紹介
  • CIサービスの比較

xcconfigの落とし穴

  • ビルド設定をconfigファイルに書くためのツール(xcconfig)の紹介

fastlane Contributorだけど何か質問ある?

  • fastlaneの運営の話やOSSの運用の話

拝啓 皆様。iOSチームの1人として伝えたいこと。

  • デザイナのポテンシャル発揮できていなくないか?と疑問に思い体制を変えた話。

いつかどこかで使ってみたい「着せ替えアイコン」を実装してみた

  • バックグラウンドで変更できない
  • 60x60を用意したらうまくいった
  • iPad用には専用のプロパティがある
  • キャッシュが強めに効くことがある

iOSDC Japan 2016 の賞金を放置しておくと1年でどうなったか?!