long forgotten now…

同僚と物理参加。ネイティブアプリへのFlutter組み込みで、Add-to-app の存在は知っていたが具体的な手法を知れて良かったし懇親会でも詳しく話を聞くことができた。ほかiOSDC運営の方ともお話しでき、今年のiOSDCでは5、6年ぶりに当日スタッフで参加しようかと考えていたところなので、その熱意をお伝えした。

イベントページ：https://potatotips.connpass.com/event/341264/

Flutter の Add-to-app でナビゲーションスタックが Flutter → ネイティブ → Flutter になってしまう場合の技術選定事例

@tfandkusu さん

• Add-to-app : ネイティブの一部だけをFlutter実装
• 3つの概念
  • FlutterEngine：ネイティブから作成、複数可
  • FlutterFragment (or FlutterViewController)
  • MethodChannle：ネイティブ間との情報受け渡し
• 2つの問題
  • 以前の表示が一瞬残る
  • 1つのFlutterEngine x 複数の FlutterFragment で古い方が真っ白
• 解決方法：FlutterFragment の付け外しをせず複数使う
  • アプリの性質上 Fragment 間の連携なさそうだったのでOK

iOSアプリの定期リリースとそのための自動化

@hiragram さん

大規模なSwift移行プロジェクトから、最新のiPadOS対応のテクニックまで。
Pro SwiftUIは、発表を聞くに4、5年前に読んだ「Thinking in SwiftUI」と重なる内容も多いと推測されるが、あらためて最新情報を体系的に学びたいため、プレゼン終わり即購入した。

イベントページ：https://dmm.connpass.com/event/336359/

DMMオンラインサロンのSwift移行

大門 弘明 さん

• SwiftUI アプリで Redux を採用
  • VIPER での課題を解決したい
  • RN 時代の設計を流用、宣言的 UI や SSOT な状態管理を実現したい
• Redux を SwiftUI でどう実装したか
  • Redux+Saga
  • SelectState と UseDispatch
• 状態の更新が View に即座反映され、共通処理の一元化ができるようになった
• 処理順序が旧アプリと同じのため、移行時にビジネスロジックの考慮漏れを防げた
  • が、同時にイケてない部分の解消ができなかった
• パフォーマンスに課題があり（メモ化検討）

Q&A

• TCA 採用に至らなかった理由
  • 流行り始めたのが Swift 化のあと、キャッチアップに時間が掛かる
  • 外部ライブラリへの依存をしたくなかった（RxSwift の二の舞）
  • Redux であれば Web でも使っているし、薄く作れるものとして採用
• 既存実装の再利用について
  • アーキテクチャは全て捨てたが、API クライアントやコンポーネントなどは再利用した

DMMブックスへのTipKit導入

宗像 恒 さん

良いユニットテストの書き方、イベントログの確認方法とaskenさんおふたりの発表内容が自社課題にダイレクトヒットして明日から実践したいと思える内容だった。失敗談から導かれた「コト」に向かう組織作りの取り組みも、目指したい効果に立ち返ってトライしたいと思った。

イベントページ：https://hey.connpass.com/event/335971/

開発生産性から振り返るエンジニアリングマネジメントの失敗2選

@sudo5in5k さん

• Four Keys の計測結果から得られたEMとしての失敗
• ドメイン知識に対するメンバー間の知識差から、組織体制変更の影響が発生 → 誰が欠けても生産性を出し続ける仕組みづくり
• 組織で「コト」へ向かうために
  • モブプロ／ドキュメント作成／プロセス標準化（担当が変わっても取り組めるくらい丁寧に。チケット、PR、docs）
• Four Keys 測定意図のすり合わせ
  • 本来の意図は健康状態の測定だったが手段と目的が逆転
  • 共通理解・共通価値観の設定が大事 → パフォーマンスを出すにはケイパビリティを変えよ（DORA Core Model から）
• 個人の価値観にブレはあるが、会社のバリューは絶対的価値観
  • バリューに即した価値観や行動の洗い出し

いいね問題に対する技術選定事例

@tfandkusu さん

空間コンテンツをテーマに映像作家と開発とが一堂に会するイベント（実は参加者要件を深く知らずにエントリーしたため、映像系の参加者が多かったことには驚いた）。空間コンテンツの制作にあたって、映像作家、アプリ企画開発の両観点から工夫に共通点が多くあった点が印象的だった。実は以前参加した「Apple Vision Proホルダー限定Meetup」でも、とある映像クリエイターの方とお話しする機会があり、今回の映像x開発の組み合わせは自然と腑に落ちた。懇親会では360度VRの映像制作を専門とする方に、180度／360度映像の制作における表現手法の違いや難しさについて教えていただき学びになった。

本編で紹介された大型XRエンタメ施設「IMMERSIVE JOURNEY」（横浜）はぜひ行きたいと思っている。

イベントページ：https://vook.vc/n/7829

イマーシブビデオの演出について：「Submerged」「ザ・ウィークエンド：Open Hearts」を体験して

VR Director / Creative Director 渡邊 徹さん（Concent, Inc.）

• XR映画においては、体験の前後（観る前と観た後）設計が重要と言われる
• VR=仮想現実は誤訳：Realityを「virtual（実質上）」にどう再現するか
• Vision Pro イマーシブビデオに必要な要件：VR180フォーマット
  • 視聴者は基本前だけ見ているため180°、フロントだけだと破綻なく作りやすい
  • 視野角100°でその場にいると脳が錯覚、人間の視野角は200°近く、頭を振ることで追従可能
• コンテンツと体験者との双方向性が没入感を高める（e.g. 対象を目で追う、ナビゲータによる誘導など）
  • framedされた映像と異なり、視覚をジャックすることで、追体験、自分ごと化させられるのがVRの強み（体験をデリバリする）
• 体験コンテンツではユーザーを能動的にする必要がある
  • そのための「感情移入のレイヤー」プロセス（自己の投影→状況→環境→感情）
  • ユーザーにルールとミッションを与えることが重要
  • 没入の状態にどう誘うか
    • 「クロちゃんのモンスターパーク」の事例
• Apple のイマーシブビデオ（Submerged / Open Hearts）について
  • ワンカット・ワンカットは素晴らしい
  • カットが多く「そこにいる感」が損なわれる
  • 途中途中で人のドアップが入る、誰の視点で見ているかがわからない
  • 「感情移入のレイヤー」に従っていない

ひとり5分LTというスピード感や、まだ道なかばという内容の発表もあってよかった。Androidに関する登壇はほぼなかった。懇親会では登壇者の方々とお話しでき、発表内容に関する今後の構想をお聞かせいただいたり、自社プロダクトの採用技術やその背景について互いに意見交換できたので有意義な時間となった。

Vision Pro での個人開発をテーマとした発表がこうしたモバイル勉強会に浸透しはじめているのは、個人的に嬉しい傾向だと感じた。

イベントページ：https://wantedly.connpass.com/event/332981/

iOS18 SDK で登場した SwiftUI の機能をおさらいする

@_swiftty さん

• iOS 18で追加されたAPIを切り口変えて調べた
• モジュール定義（.swiftinterface ファイル）から差分をとりだした
• 定義ジャンプでは表示されない、_ はじまりのAPIも見ることができる
• .swiftinterface ファイルは SwiftSyntax で扱える
• SyntaxRewriter を用いてインターフェイス差分を取り出す実装をした
• Scroll や Accessibility の機能追加が確認できた

多言語対応アプリの負債返済：文字列管理の見直しで得た学び

@yuya_h_x さん

高田馬場イントロで、今年の目標にしていた「100曲演奏」を昨夜ついに達成したので、その記念に一筆残しておく。

高田馬場イントロと言えば、ジャズの生演奏を主体としたバー形態の店、いわゆるセッションバーだ。雑居ビルの階段を２周降りた地下にその店はあり、入店時はまずオーディエンスかミュージシャンかを尋ねられる。オーディエンスなら席へ案内されるが、もしミュージシャンなら続けて担当楽器を尋ねられる。あとは待っていれば、いずれマスターに呼ばれステージに立って演奏する。ざっとそんなシステムだ。

こうした種類の店は全国にも数多あるが、特にここはプロのミュージシャンも日々訪れる日本屈指のジャズスポットとして国内のみならず海外からも非常に有名。近年はインバウンド加熱の影響で、外国人が大勢詰め寄せているため、ミュージシャンたちは店外の階段で出番を待たされることも珍しくない笑

筆者がジャズセッションに通い始めたのが６年前で（パートはドラム）、頻度は多くても月１程度。縁あって何度か、横濱ジャズやすみだジャズのアマチュア枠で出演させていただく機会もいただけた。そんなコミュニティに属していると、当然イントロのことはよく話題にも上がるため、存在自体知ってはいたものの、同時に周囲が口を揃えて言うには「（レベルが高く）怖くて近寄れない」とのことで、雲の上の存在のように感じて足は一切向かず。ただ密かに「今年こそは」という誓いだけは毎年立て続けていた。

だが今年１月、いろいろなできごとが積み重なり、とうとうその扉を押し開く決心をしたのだった。

DDDについては言葉だけ、浅ーく知っていたつもりが、完全無知・実践皆無であったことが判明、ほぼ知らない言葉ばかりで面食らった（よって下のメモも誤りあるかも）。キャッチアップからスタートし地道に取り組んだ実例に現場導入のリアリティを感じた。ドメインパターンという考え方は目から鱗。「スタイルガイド本」は早速熟読したい。

イベントページ：https://rosca.connpass.com/event/334002/

DDDを突き詰めていったら、イベントソーシングに流れ着いた話

高丘 知央さん 株式会社ジェイテックジャパン CTO

• 書籍『達人プログラマ』：アーキテクチャは生き物、建築というよりもガーデニングに近い
  • アーキテクチャも常に成長しないと老朽化する
  • 少しずつでも継続向上していくことが組織・個人成長にとって重要
• DDD導入の動機
  • FatVC、スキーマ駆動開発など、business logic が肥大化しメンテ大変
  • 会社で本買って勉強。はじめメンバー間で理解浸透に差があり苦労しつつ、結果的にテストが書きやすくなり、メンテナンス性が向上した
• 課題があり、さらに改善を進めた
  • チーム分かれてDDD経験をもとにした振り返り、KPTA
  • 「集約」、immutable data model、リッチな値オブジェクトを導入し改善
  • チームを超えたモブプロ参加、全体のレベルアップにチャレンジ
• なぜイベントソーシングを使い始めたか
  • 既存チームはDDD+RDBで改善続けている
  • CTOとして、さらに良くできる全体改善の新アーキテクチャの開発を開始
  • いつ、誰が、どのように変更したかが分からない追えない課題 → イベントソーシングなるものがあるらしい
• イベントソーシングとDDDとの関係：データを削除せずトレースを行うからデバッグが楽になる
  • イベントソーシング：Greg Young の提唱（2014年 Goto; Conference）
  • ハードル高いが、DDD実践がいつの間にかできていたと感じられる
  • OSS「Sekiban」として公開した
  • 鉄道思考プログラミング（Railway Oriented Programming）に対応

コンテキストマップの継続的な活用に向けて

東 優太さん 株式会社TOKIUM プロダクト本部 開発部 イネーブリング

ひさびさにLT系イベントの物理参加だった。休憩時間や懇親会では、LTの内容を受けて主催側や参加者の方と話が弾んだり、まさかな出会いもあったりし、現地参加の魅力を感じた。

イベントページ：https://potatotips.connpass.com/event/331173/

Kanagawa.swiftのWebページをIgniteで作ってみた！

@u5_03 さん

ブログ記事：https://ulog.sugiy.com/ignite-kanagawa-swift/

• Kanagawa.swift のWebページを DocC でなく Ignite で作った
• Ignite とは：静的Webサイトビルダー、内部的にResultBuilderを使っている
• SwiftUI や Jetpack Compose と同じ宣言的実装
• Localize、ID指定でのでリンク遷移を接続、OGP対応など

Android 15 でアクションバー表示時にステータスバーが白くなってしまう問題について

@tonionagauzzi さん

AVAudioRecorder をセットアップする。

import AVFAudio

let recorder = try AVAudioRecorder(url: fileURL, settings: [
    // 例
    AVFormatIDKey : kAudioFormatLinearPCM,
    AVSampleRateKey : 44100,
    AVNumberOfChannelsKey : 2,
])
// メータリングを有効
recorder.isMeteringEnabled = true

最新の値を取得する。

// recorderからの最大・平均入力値をリフレッシュ（最新値の取得時に必ず実行）
recorder.updateMeters()

// 0番チャンネルの最大・平均入力それぞれの値を取得（-160〜0のFloat型）
let peak = recorder.peakPower(forChannel: 0)
let average = recorder.averagePower(forChannel: 0)
print("Peak: \(peak), Average: \(average)")

これを繰り返し実行することで、以下のようにリアルタイムな値を取得できる。

 Peak: -38.29653 dB, Average: -49.813396 dB
 Peak: -38.29653 dB, Average: -45.75203 dB
 Peak: -36.77163 dB, Average: -47.29889 dB
 Peak: -36.77163 dB, Average: -46.575954 dB
 Peak: -36.77163 dB, Average: -46.979954 dB
 Peak: -22.248798 dB, Average: -22.248798 dB
 Peak: -17.44955 dB, Average: -19.18833 dB
 Peak: -13.695625 dB, Average: -19.736965 dB
 Peak: -12.488851 dB, Average: -12.488851 dB
 Peak: -12.488851 dB, Average: -12.966704 dB

recorder.isMeteringEnabled を必ず true に指定しておく必要がある点に注意。デフォルトでは false のため、最小値を示す-160しか返ってこない。