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実装で共通化すると良さそう
- java８からあるが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のコードを読む
Android における Model-View-Intent アーキテクチャ
セッションは聞いていないのでtwitterを見ていて気になったところだけメモ
- autoconnect replay(0)を使うとActivityのライフサイクルを超えて状態を管理できるらしい
マルチモジュールのすヽめ
なぜマルチモジュールなのか
- 主要機能だけではなくログイン・ログアウトや強制アップデートのサブ機能が多く複雑になっている
- ログイン・ログアウト、強制アップデートの機能をモジュールとして切り出してマルチモジュール化
- 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
- 機能整理する
- 明らかに主要機能から外れている機能を探す
- 機能間の依存関係を洗い出す
- グルーピングして依存関係を考える
- 基盤機能を考える
実際にマルチモジュールにしてみる
モジュール間の連携について
- moduleをまたがった情報を表示するときどうするか
- 各moduleでfragmentを定義して、まとめ画面ではatatchするだけにしている
- 他モジュールから情報を取得したい
- 最上位層のみを公開する。ViewとServiceで分けている
CA.kt #4 (Kotlin Conf報告会) 参加メモ
『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』藤原 聖
- AndroidでKotlinこう書くべきというドキュメントが発表された
- Androidの話はなかったがSpringの話は4つあった
- kategory.ioの話が２つ。関数型プログラミングのライブラリ
- Two Stones One Bird のセッションが良かったpinterestの人
- Kotlin ConfのアプリはiOS/AndroidもKotlinで書かれている
『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のナレッジが理解できるようになるらしい
次に機械学習をやる場合について教えてもらった
- Courseraのこのコースが良いらしい
- 書籍も2冊紹介頂いた
次にデータ分析を業務で行うことについて教えてもらった
- データ分析をもの凄くシンプルに言うと、①データを整形する / ②データを可視化する ができれば大概の事は出来ると
- データを整形するについては次の書籍を紹介してもらった。
- データを可視化するについては次の書籍を紹介してもらった。
次に業務を離れてそもそもデータ分析とはについて聞いてみた
- そもそもデータ分析は必要なのか？や概念を知るには次の書籍がおすすめらしい
追加で聞いてみた
- 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基礎
- zaimのiOSエンジニアの方
- 自然言語と対比される人工言語（プログラミング言語）
- NLP APIに沿って自然言語処理を説明
- NLP APIの処理の流れ
- 言語判定
- トークン化
- 品詞タグ付け
- レンマ化
- 固有表現抽出
- 現状、日本語はトークン化まで対応
言語判定
- 文字N-gramを活用して判定を行うことが多い
- 言語判定は簡単ではないので、予め言語がわかっていれば指定したほうが良い
- 例えば、HELLOは英語、イタリア語、ドイツ語ある
トークン化
- 文を単語に分けるようなこと
- 日本語の制度は微妙
品詞タグ付け
- 単語に対して品詞をつけていく
レンマ化
- 辞書の見出し語を抽出する処理
- 過去形から現在形、複数形から単数形を取得するような処理
固有表現抽出
- 固有名詞や時間表現をテキストから抽出する技術
- テキストにおいて固有名詞は重要情報
まとめ
iOSと人工知能(AI) -GPU並列演算の仕組みと機械学習
人工知能とは
- 生物の知能を模倣する技術
- 強いAIと弱いAIがある
- 強いAI:人の知能に迫るAI
- 弱いAI:限定的な問題解決や推論
- 弱いAIの利用例：画像処理、音声会話、文章の認識サウ性、機械制御、作曲絵画
- 種類：機械学習、遺伝的アルゴリズム、群知能、その他にもファジイ制御、エキスパートシステムなどある
機械学習とは
- Appleが力を入れている分野
- 機械学習のアルゴリズム：サポートベクターマシン、強化学習、決定木、ニューラルネットワークなど
- ニューラルネットワークによる機械学習は神経細胞のネットワークを模倣したもの
- メジャーなアルゴリズム。バックプロパゲーションによる学習
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上のキューに積まれ制御される
- パフォーマンス最適化のためにシステムの都合でスケジュール
- 失敗したら自動リトライ
- 制約
- 呼び出せれる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 の賞金を放置しておくと１年でどうなったか？！
iOSDC 2017 day 2 午前 参加メモ
iOSDC 2017 2日目午前の参加メモです。
新しい画像フォーマットHEIFを用いたiOSアプリの通信量削減
- 日経新聞社のiOSエンジニアの方
- Live Photosのようなシーケンス画像を効率的に取り扱える
- 深度、透過に対応
- iOS11/iPhone7以上の写真がHEIFで保存されていることを確認
- WebにアップするときはHEIFからJPEGに自動変換される
- 日経新聞の朝刊画像を1週間分HEIF/WebP/JPEGで比較した
- WebPはJPEGと比較して32%削減
- HEIFはJPEGと比較して52%削減
- エンコード処理は細かく調査していないがHEIFが一番遅かった
- HEIFだとハードウェアデコードが可能（A9chip以降に限る）
- HEIFは特許的にグレー(ffmpeg, GPAC/MP4Box)のところがあるので商業目的で使うのは避けた方がいい
- 特許的にクリーンな方法を考えてみた（力技）
- iPhoneをサーバしてHEIFエンコードするシステム
結婚式を支えた技術 Firebaseを活用したサーバレスiOSアプリケーション開発
- メルカリ カウルのiOSエンジニアの方
- 結婚式用のアプリを作成したアプリ
- 写真を取って、サーバに送る
- その写真にいいねできる
- お知らせの表示
- Push通知
- Firebase Storage, Firebase Database, Firebase Notificationを利用して実現
触り心地の良いInteractive Transitionをマスターしよう
- エウレカでリードエンジニアとスクラムマスターを経験
- アニメーションにこだわっているアプリは海外製が多い
- アニメーションの基礎をマテリアルデザインから持ってきた
- iOSのガイドラインにはあまりアニメーションについて書かれていない
- easing curveとdurationを意識
- duraionの基準を設けてアプリで統一すると良い
- 画面外への移動
- 画面内への移動
- フルスクリーンの移動
- 人が遅いと感じる限界は400ms。その基準も設ける
実装について
- アニメーションの2つのプロトコル
- AnimatedTransitioning 通常のアニメーション
- InteractiveTransitioning インタラクティブなアニメーション
- 遷移のアニメーションはTransitioningDelegateで決める
- 今日はInteractiveTransitioningについて
- PanGestureでdispossしていく
- duration 0.1にすると素早くジェスチャーした時に自然に見える
- 指を離した時にSpringAnimationをしたい
- UIViewAnimationのDurationを指定する必要がある
- 適切なDurationの値は連立方程式を解く必要がある
- そこでFacebookのpopを使う
AutoLayout と友達になる方法
- CyberAgentのエンジニアの方
- IB上で行うAutoLayoutの設定の話
- 友だちになる＝1人でAutoLayoutを組めるようになる
- 大切なこと２つ
- 制約の正しい付け方と種類を理解する
- 本当に正しい制約が貼られているか確認する
iOSDC 2017 day 1 午後 参加メモ
iOSDC 2017 1日目午後の参加メモです。
Build high performance and maintainable UI library
- SpreadsheetViewを題材にした発表
高速なUIコンポーネントを書くためには
- パフォーマンスチューニングのために大切なこと
- 計測すること
- 多くの場合トレードオフがあることを理解すること
- 基本は負荷の高い処理を減らす
- UIを遅くする要因を知る
- UIViewが何をしているのかを理解する
- UITableView/UICollectionViewのテクニックを学ぶ
- UIViewについて
- ビューの数が増えるほど遅くなる
- 生成のコストは比較的高い
- パフォーマンスチューニングにはコードの読みやすさやテストのしやすさが犠牲になることが多い
- バランスの見極めが腕の見せ所
メンテナンスしやすいコード
- テストしやすいコードはメンテナンスしやすいコード
- 内部状態、入力、出力が明らかだとテストしやすい
- UIのテストが困難な理由
- 内部状態が複雑
- 状態を変化させる要因が多い
- テストしやすいコードのために大切なこと3つ
- データの流れを1方向にする
- 状態をモデルに分離する
- 振る舞いを分離する
- アクション→モデル→ビューと一方向にする
- 役割を複数担っていても1方向にすることは価値がある
- 依存関係には2つある
- 状態の依存関係
- 振る舞いの依存関係
- 状態をモデルに分離する。こちらの方が簡単に分離できる
- 振る舞いの依存関係をなくすにはMockを使う
- テストしやすいコード、薄いビュー、分厚いモデルで良いコードに
RxSwiftのObservableとは何か
- ドワンゴの人
- Reactive ExtensionのObserverbleについて
- RxSwiftのコードを読む時に参考になる情報がまとまっっている
Observerパターンについて
- 通知について考えてみる
- 通知元が通知先に伝える時にどうすればいか考えてみる
- 通知元が通知先に通知することが解決できる
- 通知元が複数の通知先に伝える時にどうすればいか考えてみる
- 通知先のInterfaceが共通でないと、通知先が追加された時に通知元の実装も変更しなければならない
- そのため通知先に共通するプロトコルを切り、インタフェースを共通化
- 通知先を配列で持てるようにもなる
- 通知元がObservable観測可能なオブジェクト
- 通知先がObserver観測するオブジェクト
Observerパターンのバリエーション
- pull型のObserverパターン
- 通知先に通知が届き、通知先が通知元の詳細を知る必要がある場合は取りに行く（pull)
- push型のObserverパターン
- 基本構造はpullと同じ
- 通知先に通知元の詳細を通知する
Rxについて
- RxのObservableは3点拡張している
- 通知先に通知する値はEvent(next, error, completed)
- next以外のEventが通知されるとそれ以降は通知されない
- unsubscribeの責務をDisposableに分離している
- push型でもunsbscribeのときはもとのオブジェクトに参照する必要があったがそれを避けるためにDisposableが用意されていると考えている
File数が1300ある巨大SNSアプリを全てSwiftに書き換えてるNow
- ひま部 学生限定SNSアプリのiOSエンジニア
- ViewController106個あった（＝画面数が106個という意味ではない）
- 現在のアーキテクチャ積極的な継承を認めるMVC
- 最大継承数7, 平均継承数3くらい
- 直面した問題
- BaseClassの変更で意図しないところでBugが発生する
- BaseClassの管理が難しくなり開発スピードが下がる
- Class継承は変化の伝達が横方向
- Protocolは変化の伝達が横方向
メルカリで実施した過去最大規模のABテスト「ドロワー vs 下タブ」の舞台裏
- メルカリでUSアプリの下タブ開発を担当した方
下タブ化とメルカリUSについて
- 下タブ化は一人で担当した
- スピード最優先
- コードベースは4年物
- 画面数200くらい
メルカリのABテスト
- 独自実装
- サーバー側でコントロール
- 開発当時は20個程度並行して実施
- 現在のメルカリJPだと40個程度並行して実施
- ABテストの目的
- 効果測定
- 不具合発生時のリスク軽減
- 深観測のための段階リリース
下タブのABテスト
- rootViewControllerを変えてABテストを実施
- AppDelegateがでかくなりそう
- AppDelegateを見直す
- Windowいらない
- WindowのサブクラスのMainWindowを作成
- obj-cから使えないのでNS_FEFINED_FOR_SWIFTを使ったりした
- 初回起動時にAB切り替えたいと言われて苦労した
- depplinkの情報にタブのIndexがなくて苦労した
ABテストの結果
- 圧倒的な差が出て下タブになった
- しかし、下タブと同じタイミングで他の変更もしたので本当にタブが良かったのかわからなかった
The latest info of ReactiveSwift and ReactiveCocoa
- ReactiveSwift と ReactiveCocoa の最新情報について
第３の課金形態「寄付モデル」ってどうなの？
- Bitcoinによる寄付モデル
- 最終的にTip Jarにした
- 今のところ寄付率0%
SwiftでShift_JISをデコードする
Swiftで音楽を奏でる
- AVAudioEngine, AVAudioNodeを使って音楽を奏でた話
iOSDCだけではもったいない！iOSアプリケーションエンジニアの他言語コミュニティ生存戦略
- みんなにカンファレンスのスタッフに興味をもってもらうための話
多次元宇宙と画面遷移
- 画面遷移をrootViewControllerで管理した話
ARC vs. GC？ARC in GC？
iOSで利用できるデバイスファームのメリット・デメリットの紹介
ローカライズの苦しみに立ち向かう
- 日本語英語対応しているsansaniOSアプリのローカライズで苦しんだ話
この単語、なんて読むんだっけ？
- 開発で出て来る読みづらい単語の紹介
クラス名に個人の名前を含めるとこうなる
- BASEアプリに個人名（イニシャル）を含めた話
- Crashlyticsに出てきたりISSUEになったりしてねたになる
はじめよう！OSSコードリーディング！
- コードリーディングのメリットデメリットについて
- コードリーディングのはじめかた
IPAファイルの中身を覗いてみよう
子育てエンジニアの家庭内生存戦略
- 子育て用のアプリを開発した話
これ、リークしますか？
- メモリリークの話
iOSDC 2017 day 1 午前 参加メモ
iOSDC 2017 1日目午前の参加メモです。
Auto Layoutのアルゴリズム
内容が難しすぎたので間違っている可能性があります。
- Auto Layout制約はレイアウト属性と関係性を定義する
- Auto Layoutは宣言的に記述でき、ビュー階層に依存しないなどの特徴がある
- Auto Layoutは等式だけでなく、不等式も扱えるため、連立方程式ではなく最適解を求める必要がある
- 線形計画問題。実行可能領域を定義しそれに別の式を与えて解を求めていく。例としては、生産計画問題など。
- 解法はシンプレックス法と内点法がある。
- シンプレックス法は差分更新ができるので便利
- ここでcassowary。いくつかの言語でサポートされている
- 数式の説明
- Zを小さくしていく
- x1はマイナスなので大きくするとZが小さくなる
- x2はマイナスなので大きくするとzが小さくなる
- シンプレックス法は外側の線に沿って最適解を求める
- シンプレックス法で最適解が求められない場合がある
- 2段階シンプレックス法を使う
- さらに効率的な方法として双対シンプレックス法がある
- cassowary+シンプレックス法
- レイアウトはマイナスの変数がある
- シンプレックス法を適用するためにマイナスを含む制約と含まない制約に分ける
- autolayoutは2つの属性の関係性のみ制約をつけるが、cassowaryは2つの属性のみではない
- cassowaryのライブラリを公開しているが業務では使わないほうがいい
両OSやるマンという選択
- レアジョブで両OSやってる方
- アップデートはAndroidのほうが頻繁に行っている
売れ方について
- 日本でもAndroidのシェアが増え半々くらいなってきている
- 中国はPlay Storeがないがシェアが高い
- Androidはストアの内容をほぼ全てABテストできる
- ランキングにソーシャルの影響が出る
作り方について
- デザインガイドラインが異なる
- Androidのマテリアルデザインガイドラインに「マテリアルはメタファーである」とあるがよくわからない
- クロスプラットフォームはキャリアとして怖いのでネイティブでやっている
- Androidの方は開発環境と言語の依存が少ない
- CI/CDはiOS/AndroidともにBitriseを使っている
- 簡単に使えるのでおすすめ
- AndroidはPlay Storeに上げるために一手間必要
作るものについて
- SwiftとKotlinの違いをさくっと
質疑
アプリエンジニアはどのように事業に貢献すべきか
- Fablicのチームリーダの方。アプリエンジニア6年目
- アプリチームは3人チーム
- どうやってユーザを喜ばせるか、ビジネスを成功させるか、これらを両立させるかについて考えている
- 自分が考える理想のサービス：ユーザと自分たちでポジティブなサイクルを回せるサービス
- ユーザが価値を感じ、その価値に対して対価を払ってもらえること
- 対価をもって、よりよいサービスを提供していけること
- FRILの価値
- ものの売り買いを安心してできることがもともとの価値
- 遠く離れた知らない人でも安心して売り買いができること
- フリマアプリはUIや機能性による価値は弱まっているのが現実
- このような環境でもアプリエンジニアとしてどうやって貢献していけばよいか
- ポジティブなサイクルがあるならユーザに喜んでもらうことが一番
- アプリの重要度はさがっているかもしれないが、サービス本来の価値をもとにアプリを改善していく
- サービスの価値をアプリにどう落とし込むかがミッション
- ユーザからみたFRILの価値
- アプリは手段でしかない
- アプリの機能だけではなく取引体験を良くしていく必要がある
- 自分たちで課題を発見して改善していく仕組みを頑張って整備している
- アクセスログやBigQueryにExportしたFirebaseAnalyticsの生ログをRedashからアクセスできるようにしている
- アプリの変更点をサポートチームに共有しサポートしやすいように
