ごんれのラボ

iOS、Android、Adobe系ソフトの自動化スクリプトのことを書き連ねています。

iOSDC Japan 2017 1日目に参加してきた

概要

こちらの勉強会(カンファレンス)に参加してきた。
iosdc.jp

前夜祭の記事は下記。 www.macneko.com

セッションの感想

会場で聞きながらメモをとったものを貼り付け。
スピーカーが発言した内容と、私の独り言が入り混じってるけど、ご容赦を。
なお、MBA のバッテリーが力尽きたため、途中で終わっています。
無念。

Auto Layout のアルゴリズム(Track A)

  • スライド speakerdeck.com
  • AutoLayout、いまだによくわかってないので、知りたい欲ある
  • Abema から8人登壇! すごいなぁ
  • このスライド、とてもほしいやつだ
  • コードで書くならサードパーティのライブラリを使ったほうがいいとのこと
    • たしかに素で書いたやつ、読めませんね
  • 行列計算の話がここでも出てきて、数学は学ばないといけない問題が再燃
  • 線形計画問題?初めて聞くぞ…
  • わかった、これは数学のセッションだ!
  • Cassowary
    • UI のための制約プログラミング手法
    • ヒクイ鳥
  • なるほど、わからん
  • スライドをあとから読み直そう。時間内に理解することは無理だわ
  • スライド通り、AutoLayout のアルゴリズムを解析ってことなんだな

インタラクティブ画面遷移の実践的解説(Track A)

  • こちらも Abema の人
  • 今回の内容はiOS9以降に対応
  • インタラクティブトランジションはSafariのエッジスワイプなど
    • 移動量に応じてアニメーションが変わる。シャドウの濃さとか
  • ユーザーの操作にあわせてアニメーションさせるってことか(たしかにそんなこと言ってたけど、ピンとこなかった)
  • 画面全面のモーダルはユーザーとしても邪魔なときがあるので、ユーザーが画面半分だけ表示できるように仕込んであげるのはいい手だな
  • ソースコードが見えないけど、あとでサンプルコードがあがるのかな
    • あとで公開されるそう
  • 画面外タップ、画面外スワイプで画面を閉じるのはよくあるけど、わりと面倒くさい印象
  • チュートリアルのように横にスクロールして画面遷移するのにも、インラクティブさを求められるのか
    • サンプルの動作を見せてもらったら「なるほど、これはやってみたい」って思った
    • 自分の目で見てみないと良し悪しはわからないね
  • UIScrollView をスクロール量を取得して、progress に変換しているとのこと
    • progress とはなんぞや。あとで調べよう
    • UIScrollView の移動量を他のなにかに転用するというのは、良い手段だな
  • 聞きやすくてよいセッションだった

Build high performance and maintainable UI library(Track A)

  • 岸川さんのセッション
  • 番組表のようなレイアウトを簡単に実現できる SpreadsheetView というライブラリを公開している
    • とても滑らかに動いていた
    • のちほどチェックしよう
  • パフォーマンスチューニングはトレードオフ。ちゃんと計測しよう
  • 画面内に表示しきれないViewの影響で、シンプルにViewをたくさん作ると動作が遅くなる(固まる)
  • 最低限必要な範囲のみViewを生成する、Viewを再利用すると良い
  • トレードオフを知る
    • コードの読みやすさ、テストのしやすさを犠牲にすることが多い
    • 得るものと失うもののバランスの見極めが腕の見せどころ
  • UIコンポーネントのテストは難しい
    • 内部状態が多く複雑
    • 状態を変化させる要因が多い
    • 状態が相互作用を及ぼす
    • 正しい挙動が明確ではない
  • テストしやすい構造とは
    • データの流れを1方向にする
      • ひとつのクラス内でロジックが書かれている場合でも1方向の流れにすることが重要
    • 状態をモデルに分離する
    • 振る舞いをモックに振り替える
  • 状態の瞬間瞬間もモデルに定義して(座標とかをパラメータにもつ)テストする
  • テスト対象が大きいとテストコードをあとから読んでもわからなくなる
    • 可能な限りテスト対象を小さくする
  • モック化の過渡期などに static をつけて、インスタンス変数にアクセスできなくするという手もあるのか
  • パフォーマンスチューニングはよく頼まれるので、参考になる良いセッションだった
  • テスト、書かないと…

Swift で数学のススメ 〜 プログラミングと数学を同時に学べ(Track B)

Swift プログラマのための今さら聞けない計算量の話し(Track B)

  • 続いて、数学のセッションに参加
  • スピーカーは RubyCocoa を作られた方。聞いたことあるな
  • 計算量とか初めて聞いた
  • 配列の値の取り出し方で o(1)、o(n) の説明。わかりやすい
  • Swiftのドキュメントで計算量について書かれているところ
    • コレクションに関するドキュメントに書かれている
    • Sequence、count
  • Sequence プロトコル
    • 期待される値のところに記載あり(Expected Peformance)
  • Count プロパティ
    • コレクションが空かどうかは isEmpty() プロパティを使うように書いてある
    • 計算量が異なる可能性があるので、意識して実装すると、効率良い実装ができる

Swift と Kotlin(Track B)

  • どっちが優れているとかそういう話じゃないと明言されてて安心
  • Swift と Kotlin は似ているけど、根底が異なるものもあり、一様に似ているとはいえないんだな
    • たとえば、Swift は型を拡張する感じ、Kotlin は型に追加する感じ
    • 構文だけぱっと見て似てると思ったけど、セッション聞いていると、構文似ているだけにいろいろハマる気がする
    • 実際に書いてみないとやっぱりわからんな
  • Kotlin のforeach は return で抜ける、Swift のforeach は return でスキップ

懇親会

何人かのスピーカーの方とお話ができて、「セッション超良かったです!」とお伝えした。 私の数少ない登壇でも聞いてくださった方々に感想を言ってもらえると嬉しかったので、機会があるときは頑張ってお伝えするようにしている。

来年開催時の希望

  • 懇親会チケットを申し込み忘れている人がかなりいたので、もっとわかりやすくアナウンスがされるといいな *チケットを「懇親会あり」「懇親会なし」でわけて申し込んでもらうのも手かなぁ
  • 電源席がほしかった
  • ノベルティを減らして、チケット代がもう少し安くなるといいなぁ

まとめ

お祭り感があって、セッションも多岐にわたっていろいろな内容があって、とても楽しかった。
来年も参加したい。