iOSDC 2023 3日目！

各セッションについてのメモ。

freee は業務としてカンファレンスに参加できるが、iOSDC は例年ブースを出しているのでその運営も兼ねて iOSDC に参加した。

顔写真メイクアップアプリの開発におけるプライバシー保護とコスト削減のための手法

10:25~ TrackA
https://fortee.jp/iosdc-japan-2023/proposal/6aa80fd7-ec73-4261-8ea0-563cbfa52df5

LIPS のバーチャルメイクの実例

バーチャルメイクはどういうものか

• 色を選択
• 顔を撮影（静止画だったり動画だったり）
• 顔の分析をして、顔のパーツの配置などを特定
• 画像を編集してバーチャルメイクを施す

この中で顔の分析と編集をローカルで完結させる

結論

顔の分析・加工を端末内で行うことで外部に漏れることを防ぐ

分析

Vision Framework を利用する

事前準備

顔の分析は Apple 純正のモデルだと足りないので、独自に準備する必要がある。
face-parsing という ML model を利用した
https://qiita.com/john-rocky/items/6b846c1cdb152bded40b

モデルの取り込みはドラッグアンドドロップで完了する。DDでモデルクラスというのが自動で出来上がる。

Core ML Helpers

OSS だったりする。
これがあるとモデルの活用が更にしやすくなる（？）

ソースコード

割愛。

感想

めちゃめちゃおもろかった。シンプルに発表がうまいのもあるが、めちゃめちゃ勉強・刺激になった。

今回の iOSDC でしばしば CoreML の話を聞いているが、もっとなにかに使っていきたいな。

StoreKit2を使った課金システムのフルリニューアル

11:00~ TrackB
https://fortee.jp/iosdc-japan-2023/proposal/38b684f3-86a6-43be-8d27-48d9710626bf

tapple の話！

なぜやったのか

おおきく分けて消耗型とサブスク型の2タイプがある。
またセールを実施することもある。

システムが複雑化していく中で、KMM, BFF を使った課金関連の共通化。Androidとロジックの共通化をしたかった。
またお試しオファープロモーションオファーも導入したかった。

StoreKit2 について

Product.products()

これだけでプロダクトを取得できる。
そして Product.purchase() で購入できる。

アプリ起動時・復元時のトランザクションどちらも容易に実装できる。 タップルでは root view で listen している。

ソースコードと解説

割愛。

注意点！

• 購入力ごとアプリ起動時に listen している Transction.update() (?) の2回分発火している

やってみてどうだったか

レシートが不要になった！

これめちゃめちゃうれしいな。originalTransactionId をサーバーに送ればよいらしい。
デバッグが楽になったり、課金の理解がしやすくなった。

StoreKit1 と StoreKit2 を混在させてはダメ

Apple に問い合わせたとのこと。資料参照。

感想

StoreKit2 めちゃめちゃ使いやすそう！
確かに課金周りは知識が属人化しがちなので、API がシンプルになることで誰でも容易に理解できるってのはかなり大きなメリットかも。

複雑さに立ち向かうためのコードリーディング入門

13:00~
TrackB
https://fortee.jp/iosdc-japan-2023/proposal/6229ba41-0675-4f62-839e-6cde07311585

認知プロセスを活用したコードの読み方

情報過多シンドローム

コードを読むために、理解しようと闇雲に情報を取り込むことで脳が疲弊すること
負の連鎖になる

ここからコードの理解と認知機能は関係しているらしい。読む力が上がると開発業務の効率が上がる。

なぜ複雑に感じるのか

• 知識不足
• 情報不足
• 処理能力不足（変数の状態を覚えている必要があるとか）

認知プロセス

• 短期記憶（今読んでいるコード）
• ワーキングメモリ（短期記憶していることを処理していく）
• 長期記憶（昔書いたコードとか）

これらを利用して認知していく

認知プロセスと不足の関係

短期記憶 = 情報不足と関係。短期記憶には限界があり、古い情報は抜けていく。
「あれ、さっきのなんだっけ？」という状態。

ワーキングメモリ = 処理能力不足と関係。限界がある。
「頭が回らないなぁ」というとき

長期記憶 = 知識不足と関係。限界はないが、そもそも知らない。 「何もわからない。とりあえず調べよう」の状態。

とはいえ3つのプロセスはそれぞれ連携しているので、個別には考えられない。

連携について

つまり1つのプロセスでも不足があると、複雑に感じる。

対策

大事なのは認知プロセスが妨げられないようにすること

短期記憶

限界があるので、chunk化する。
chunkとは人間が一度に認識できる情報の単位

情報のチャンク化のチェック

例えばスライドにあるコードを30秒でどこまで暗記できるか。

俺の回答↓↓

guard i < j else { return }
let m = (i+j)/2
slowSort!()
slowSort!()
if 
slowSort!()

チェック項目はスライド参照

どうすれば chunk 化できるか

ポイントは長期記憶化。連携しているので、長期記憶化すれば容量の限界を期にしなくていい。
スキーマを活用。関連したものごとが紐づいたネットワーク構造。

コツ

• 定期的に情報に触れること（人は忘却する。ただし、何度か覚えようとすると知識は定着する）
• 保存強度（どれだけ長く）
• 検索強度（どれだけ早く思い出せるか）

検索強度は中々あげられない。保存強度が高くても検索強度が高くないと思い出せない。 意識的に検索強度を上げるには、積極的に chunk 化をすること。ラベル付けしたり、どんどん深堀りすることで、スキーマのつながりが強化されて検索強度が上がる。

ワーキングメモリ

ここへの負荷 = 認知不可

• 課題内在性負荷（難しい数学の問題）
• 課題外在性負荷（問題に関係のない）
• 学習関連不可（長期記憶に情報を保存するための負荷で、必要不可欠）

課題内在性負荷（難しい数学の問題）

問題自体が難しい
常に複数の状態を意識しないといけないなど

難しさの分散をする。例えば変数の変化を状態遷移図として追っていくとか、図に書き出すとか。

課題外在性負荷（問題に関係のない）

問題に関係ないから解消したい。
認知的リファクタリング = 動作を変えずに自分の読みやすいコードに書き換える。これをすることで自分の慣れているコードとして読める。

長期記憶

誤認識という問題がある。
特に認知負荷が高いときや注意を払っていないときに起こる。

長期記憶の上書きが必要 = アンラーニングのこと
意識的に上書きする必要があるので、他の視点から思い込みを確認する。

• コードレビュー
• ペアプロ
• ベアプロ
• テストを書く

コードの意図について

内容は理解できるが、全体の中での役割が不明な状態で、何をすれば良いのかわからない。そして短期記憶の容量の問題が起こる。

対策

全体のイメージを掴む

全体を読んだあとに思い返してみる。これで感覚記憶から短期記憶に情報が送られる。

点から理解を広げていく

変数の役割を理解する

変数はその目的が違うので、その役割を理解する。例えば引数はなにかとか、何が最終的な返り値なのかとか。

文章読解とコードの読み方

脳は文章もコードも同じ場所を使って読む。

汎用的な対策

• 集中できる環境づくり。余計な情報が入らない状態にする。騒音、マルチタスクしない。
• 割り込みを無視する。一度割り込みがあるとすぐには戻れない。
• すぐに作業に戻れるように、あえて中途半端な状態だったり、メモをする

コードの読み方を書き方にも活用する

読み手の負荷をあげない

コードスメルを追加しない。長すぎるパラメータリストや重複するコード、特殊なシンタックス。

脳の仕組みを利用する

記憶、検索しやすくする
一貫した命名やコーディングスタイル、デザインパターン、自動ツールの活用など。

誤用しづらくする

人は勘違いしてしまう

• コンパイラの力を借りる（明示的な型を作ったり）
• テストを書く
• 見えるところにドキュメント

感想

めちゃめちゃおもしろかった。
まさに自分がプログラミングを身につけるときのプロセスが言葉で説明されていたりして興味深い。検索強度の話はまさに点が線になるプロセス。

個人的には、他人に声かけるときは割り込ませてしまうことを考えて、あとでも良いんじゃないかと一度止まろ。

また自分はエンジニアのコミュニケーションに着目した研究でもしてみたいと思うなどした。

CoreHaptics入門

14:30- TrackB
https://fortee.jp/iosdc-japan-2023/proposal/b630fa79-2c28-41ec-a6b2-6954b62f1858
https://github.com/shiba1014/HapticsDemo

Haptics は UIKit か CoreHaptics を使うことができる
UIKit は手軽に使える。CoreHaptics はカスタマイズできる

感想

本筋とは異なるが、誰がHapticsを決めるのかについて質問があった。その回答は、どこに入れたいかは企画の人、どういうHapticsにするかはデザイナーが決めている。LINE では Haptics デザインツールがあり、それを使ってコミュニケーションしているとのこと。

SwiftUIに適した新アーキテクチャの導入に挑む

15:00- TrackA https://fortee.jp/iosdc-japan-2023/proposal/edcec751-4f7f-46aa-9c17-92249a1a1771 Chatwork のりアーキテクチャの話

課題の認識を揃えるために

ワークショップを行った。何を課題と思っているか、なぜ課題と思っているかをポストイットに書いて話し合った。

進め方を決めるワークショップ

以下を把握するため

• プロジェクトの達成には何が必要か（実装などがどういう状態になっているか）
• どれくらい時間がかかりそうか

SVVS

Store

GlobalStore の管理をする。画面間で共有されるデータ
プロパティの保持と、取得・更新をするメソッドがある。

ViewState から依存される。ViewやViewStateには依存しない。

ViewState

Viewの状態を管理する

StoreのデータをViewの表示に適した状態にして、自身のプロパティに反映する。
ViewModel よりも View の状態に徹する。

Viewのアクションをメソッドで実装する

ボタンのアクションなど

依存

View から依存され、Storeに依存する。

View

画面単位での View を指している。 ViewState を @StateObject で保持する ロジックを持ちすぎないように、イベント処理は、ViewState のメソッドを呼ぶだけ。

ViewとViewStateは一対一。

データの流れ

ユーザーアクションが起こると、View→ViewState→Store にながれ、反映結果が逆の順序で View に伝えられて描画される。

感想

ワークショップいいな。
個人アプリくらいならこのアーキテクチャが何も考えずにそこそこレイヤーを分けて開発できそう。もちろん freee でもワークショップをやったり、ある程度 SwiftUI を本格的に導入するとなったら参考にしたい。