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年でどうなったか?!

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を組めるようになる
  • 大切なこと2つ
    • 制約の正しい付け方と種類を理解する
    • 本当に正しい制約が貼られているか確認する

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 の最新情報について

第3の課金形態「寄付モデル」ってどうなの?

  • Bitcoinによる寄付モデル
  • 最終的にTip Jarにした
  • 今のところ寄付率0%

SwiftでShift_JISをデコードする

Swiftで音楽を奏でる

  • AVAudioEngine, AVAudioNodeを使って音楽を奏でた話

iOSDCだけではもったいない!iOSアプリケーションエンジニアの他言語コミュニティ生存戦略

  • みんなにカンファレンスのスタッフに興味をもってもらうための話

多次元宇宙と画面遷移

  • 画面遷移をrootViewControllerで管理した話

ARC vs. GC?ARC in GC

  • GCの話
  • ARCもGCの一部
  • GCは参照カウント
  • JVMGCはトレーシングコレクタ
  • トレーシングコレクタと参照カウントの比較
  • GCは静的自動と動的自動に分類できる

iOSで利用できるデバイスファームのメリット・デメリットの紹介

  • バイスファームを使った見た話
  • AWS Device Farm, Xamarin Test Cloud, Testdroid TextObjectの比較

ローカライズの苦しみに立ち向かう

発表資料

  • 日本語英語対応しているsansaniOSアプリのローカライズで苦しんだ話

この単語、なんて読むんだっけ?

  • 開発で出て来る読みづらい単語の紹介

クラス名に個人の名前を含めるとこうなる

  • BASEアプリに個人名(イニシャル)を含めた話
  • Crashlyticsに出てきたりISSUEになったりしてねたになる

はじめよう!OSSコードリーディング!

  • コードリーディングのメリットデメリットについて
  • コードリーディングのはじめかた

IPAファイルの中身を覗いてみよう

  • 仕事柄ipaファイルを確認するDeploygateのエンジニアの方の発表
  • ipaファイルをunzipして中身を確認した話

子育てエンジニアの家庭内生存戦略

  • 子育て用のアプリを開発した話

これ、リークしますか?

iOSDC 2017 day 1 午前 参加メモ

iOSDC 2017 1日目午前の参加メモです。

Auto Layoutのアルゴリズム

niwatakoさんのまとめ

内容が難しすぎたので間違っている可能性があります。

  • 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テストできる
  • ランキングにソーシャルの影響が出る

作り方について

作るものについて

  • SwiftとKotlinの違いをさくっと

質疑

  • 細かい改善はAndroidで実施し良かったものをiOSに反映させるようにしているとのこと

アプリエンジニアはどのように事業に貢献すべきか

  • Fablicのチームリーダの方。アプリエンジニア6年目
  • アプリチームは3人チーム
  • どうやってユーザを喜ばせるか、ビジネスを成功させるか、これらを両立させるかについて考えている
  • 自分が考える理想のサービス:ユーザと自分たちでポジティブなサイクルを回せるサービス
    • ユーザが価値を感じ、その価値に対して対価を払ってもらえること
    • 対価をもって、よりよいサービスを提供していけること
  • FRILの価値
    • ものの売り買いを安心してできることがもともとの価値
    • 遠く離れた知らない人でも安心して売り買いができること
  • フリマアプリはUIや機能性による価値は弱まっているのが現実
  • このような環境でもアプリエンジニアとしてどうやって貢献していけばよいか
  • ポジティブなサイクルがあるならユーザに喜んでもらうことが一番
  • アプリの重要度はさがっているかもしれないが、サービス本来の価値をもとにアプリを改善していく
  • サービスの価値をアプリにどう落とし込むかがミッション
  • ユーザからみたFRILの価値
    • アプリは手段でしかない
    • アプリの機能だけではなく取引体験を良くしていく必要がある
  • 自分たちで課題を発見して改善していく仕組みを頑張って整備している
  • アクセスログやBigQueryにExportしたFirebaseAnalyticsの生ログをRedashからアクセスできるようにしている
  • アプリの変更点をサポートチームに共有しサポートしやすいように

iOSDC 2017 前夜祭 参加メモ

iOSDC 2017 前夜祭の参加メモです。

SiriKit and Me

SiriKitについて

  • 対応しているアプリ
    • 全国タクシーとUberでタクシーを呼び出せる
    • LINEでメッセージが送れる
    • OpenTableでレストランを予約できる
  • Siriを使えば目の見えないユーザに対してもサービスを提供できる。
  • HomePodの発売も控えている(今のところアプリの発表はされていない)

SiriKitの実装について

  • SiriKitはフレームワークではなくIntentsとIntents UIフレームワークで実装する
  • SiriKitはAppExtensionの一種
  • iOS11では23種類のAppExtensionがある
  • AppExtensionはHostAppと一緒にリリースされるが、プロセスは別
  • iOSではメモリ空間がプロセスごとに制限されている
  • HostAppとの情報共有はアプリ間で共通で使えるFile StorageのAppGroupを利用する
  • Siwikitの処理にはタイムアウト制限がある
  • ネットワーク処理は厳しいのでキャッシュを使う必要がある
  • Sirikitはエラー情報の取得が難しい。成功、失敗しか返さない。
  • エラーの情報はSirikitのフレームワークのログを見て確認する
  • SiriKit更新が早い。マイナーバージョンアップで破壊的な変更やUIの変更がある。
  • 英語では正しく動くけど日本語では動かないということよくある
  • SiriKitは実装量は少ないが、デバックが大変

Objective-C++を使ってMRCで快適に開発する

Swaggerで始めるAPI定義管理とコードジェネレート

発表スライド

  • なぜAPI定義を明文化するか
  • サーバ、クライアントでOptionalなどの認識を合わせられる
  • Swaggerはコードジェネレートも用意されている
  • コードをジェネレート、設計とコードの乖離を防止する
  • Swift, Kotlin Javaにも対応している

Swiftのコードジェネレート

  • Swift4絶賛対応中
  • JSONパースはCodableで実装
  • API ClientはAlamofireがベース
  • RxSwiftとも連携可能
  • CocoaPodsライブラリとして出力できる

節子、それViewControllerやない…、FatViewControllerや…。

発表資料
togetter

  • なぜViewControllerの責務分けが注目されるのか
  • ViewControllerがiOS開発の重要な機能を多く持っている
  • それゆえに多くの機能が実装される
  • Fatはコード量ではなく責務が多いことが問題
  • いかにして責務わけを実現するか。本日はMVPを紹介
  • Presenterにおける描画処理をInterfaceとして定義
  • ViewControllerがInterfaceを実装

良い目標の4つの特徴

  • 明確
  • 小さく
  • 肯定的
  • 行動の形

try! Swift Tokyo 2017 day1 参加レポート

www.tryswift.co

先日、上記イベントに参加させて頂きました。その1日目のレポートになります。

各セッションの詳細は後日realmからアップ予定の動画や、niwatakoさんの聞き起こし一覧にお任せして、
本記事では各セッションの内容を簡単に紹介します。

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

10:20 - Swift on Android

  • niwatakoさんの聞き起こし
  • SwiftでAndroid開発をする話でした。
  • ほとんどがCとC++の話で詳細は理解できずに、難しいことだけわかりました。
  • Android NDKも関係してくるのですが、こいつはお粗末な実装になっていてGoogleのサポートも弱いそうです。

11:40 - SwiftのPointy Bits

  • niwatakoさんの聞き起こし
  • SwiftのメモリとSwiftでPointerを使う話。
  • あまり使う機会がなく詳しくないのですが、非常にわかりやすくま止まっていたと思います。

12:05 - アプリを新次元に導く3D Touch

  • niwatakoさんの聞き起こし
  • 3D Touchで実現できる事とその実装に関する発表でした。
  • 3D Touchはユーザに気が付かれにくく、実装しないことが多いと思いますが、3日目におこなられたハッカソンで優勝したチーム(1人チーム)は3D Touchをフルに使ったアプリを開発していました。

12:30 - Pixcels、プロセスと情熱

  • niwatakoさんの聞き起こし
  • 情熱を持ってプロダクト開発に取り組むアプリをリリースした話でした。
  • 「大変なのは技術ではなく人」というフレーズが印象的でした。
  • Swiftと関係ない発表でした。

14:30 - 毎日リアクティブ

  • niwatakoさんの聞き起こし
  • Swiftでリアクティブの話というよりは、リアクティブの話をSwiftのサンプルコードを使って紹介するという感じでした。
  • なので、Swiftではこうやるみたいな話はありませんでした。
  • 発表者はUstreamのエンジニアで、リアクティブライブラリは何を使っているかという質問にたいして、自社で開発したライブラリを使っていると言っていました。

14:55 - ⚡️🎤 Unsafe Swiftの安全性

15:05 - クックパッドアプリのテストを味わう

15:25 - ⚡️🎤 データレイヤを分離する

15:35 - UIをSwiftyに書く

  • niwatakoさんの聞き起こし
  • UIの実装に限った話ではなく、WebAPIを叩いて表示するシンプルなアプリをSwiftyに書く発表でした。
  • enumやprotocolの強力な面を紹介していました。

16:30 - SwiftのWeb APIとアプリをともに構築する

16:50 - ⚡️🎤 楽しく便利なSwiftチャットボット

  • niwatakoさんの聞き起こし
  • LINEのエンジニアによるチャットボットに関する発表でした。
  • UIが改善されればもっと良いものになると言っていました。(今後に期待!?)
  • Swiftと関係ない発表でした。

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

  • niwatakoさんの聞き起こし
  • お絵かきアプリ(?)をRealm Mobile Platformを使って実装する発表でした。
  • Swiftの発表というよりはRealmの発表でした。

17:30 - 独自のツールを構築する

  • niwatakoさんの聞き起こし
  • SwiftをやめてReact Nativeでアプリを開発した話でした。
  • Swiftのメリット・デメリット程度の話はありましたが、React Nativeメインの発表でした。

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

  • niwatakoさんの聞き起こし
  • Wantedly Peopleの複数名詞を読み取る機能を実装した際に得た画像処理に関するナレッジを紹介していたLTでした。

18:10 - ⚡️🎤 UXエンジニアという働き方