YAPC::Hiroshima 2024に参加してIdempotency-Key Headerの話をしてきた

表題の通りYAPC::Hiroshima 2024にスピーカー、およびスポンサー企業の一員として参加してきました。最近はブログ不精となっていてイベントに参加しても記事を執筆せずにいたものの、YAPC参加者のすさまじい熱量にあてられたので久々に筆をとってみます。

自分とYAPCとbuilderscon

YAPC初参加です。が、実はYAPCには思うところがありました。

YAPC::Asiaの後継として開催された（ですよね？）buildersconに2017, 2018, 2019と参加しており、このイベントからは過去にめちゃめちゃ感化されていたのでした。特に初参加のbuilderscon 2017に強く影響を受けてから僕は登壇やOSS活動を始めたので、勝手な思い入れがあるカンファレンスです。

「buildersconにもやがて登壇するぞ」と思っていたものの直近の数年は非開催となってしまったので夢が潰えたような気もしていました。ところがどっこい「buildersconに一番雰囲気が似てるカンファレンスはYAPCなのでは（想像）」「YAPCに登壇できたら目標達成では（妄想）」という気づきがあり、プロポーザルを出してみたところ採択いただき、広島凸という背景でした。

トーク「My Favorite Protocol: Idempotency-Key Header」について

YAPC::Hiroshimaのテーマが"What⁨ I like"ということで、僕の好きなプロトコルであるIdempotency-Key Headerの話をしてきました。RFCにはなっていないものの、StripeやPayPalといった著名決済SaaSでは実運用されている便利HTTPヘッダーです。

僕が携わるB/43でも2021年から導入しており、データ堅牢化に一役買っているという自慢をしました。

テーマ的にソフトトークやキャリア論でもプロポーザルを出せそうだなと思ったのですが、初見のコミュニティで顔を売るならしっかり技術的な内容で興味を惹きたいと思ったのでテクニカルな内容にしました。

ベストトーク賞は取れなかったものの同僚のmitaniさんが素晴らしいトークで広島凱旋&受賞という偉業を成し遂げていたのでオッケーです。いや、ぜんぜんオッケーじゃなくて悔しい！このような投票型の企画があるカンファレンスをあまり知らないので、今度登壇する際にはベストトークを獲りたい。

というわけで逃したものの「ベストトークとして投票しました！」という方に懇親会でお声がけいただいたり、複数の方がブログにて言及してくれたのを観測しており、しっかりと人の心に残る登壇ができたのはポジティブです。

登壇のふりかえり

前夜祭の番宣リレーで「冪等！冪等！冪等！」がウケてたようで良かった
- SmartHRのブースでinaoさんに挨拶したとき「あっ、冪等の人ですか」って言われて嬉しかった
時間が押してて即開始となってしまい、会場を暖める"前説"ができなかった
愛機のLogicool Spotlightがかっこいいと言われた
- けど会場でうまく動かないシーンがありちょっと焦った
質疑応答がいっぱい来て嬉しかった
- YAPC、全体的に質問が多くてとても良い雰囲気だった
大量のスライドを作っておきつつ「時間がないので」と言って飛ばしまくるテクを褒められた
- Appendixに書いてても読まれない・触れずに終わってもったいないので本旨に混ぜ込んだほうがいい
- 「ここで止まる」スライドが面白い

スポンサー企画「CTOを破産から救おうチャレンジ」

所属するスマートバンクが椅子スポンサー────椅子にチラシを掲載する権利を得る────となった機会を活かし、今回は軽めのコーディングクイズを出題してみました。

Idempotency-Key Headerを理解するとシュッと解ける問題になっており、僕のトーク内容で学んだことを実践し、身につけていただけるような教育的なクイズを意図しました。

github.com

Perl, Ruby, Goの3言語のいずれかで挑戦可能ですので、参加者も非参加者問わずまだ見ていない方はぜひ一度cloneして挑戦してもらえると喜びます（Xにpostしていただけると更に喜びます）。

ちなみにLTにはこのクイズに関連したコード難読化ネタで応募していました。残念ながら非採択でしたがどこかにて供養したいと考えています。

fortee.jp

良かったトーク

naoyaさんの「関数型プログラミングと型システムのメンタルモデル」

以前の講演のスライドだけ目を通していたがリアルに聞くとさらに面白かった
これは型にとどまらないモデリングの話だと僕は捉えている
- なので静的型付けを用いない言語であってもある程度のエッセンスを活用できる
  - RubyでUserをActiveUserとDeactivatedUserに分けたって良い
  - classである必要がないならDataやStructで宣言したって良い
- 型は検証のためのツール。それでもメンタルモデルに影響を与えるので型とモデリング間の相互作用が生まれるので当然あると良い
どうしたって副作用はあるけどどうする？という問いに「純粋関数の世界とIOの世界を分けるという」のは納得感が高い
- 僕が過去に抄訳した「状態、結合、複雑性、コード量の順に最適化する」とも通ずるものがある
- 世界を分けるコストとトレードオフもあるだろうとは思う

...のようなことを思っていたらご本人も同じようなことをpostされていました。

YAPC の質疑応答で少し話したことを記録として残しておこう。

静的検証をもっとうまく使いたいとおもってオブジェクトの表現を型に寄せていくと、代数的データ型 (ADT) がほしくなり、ADT を使うとその分解にパターンマッチが必要になって、設計が自然と関数型よりに寄っていく。
— naoya (@naoya_ito) 2024年2月12日

naoyaさんにできれば質問したかったのは、「世界を切り離さずに済む、あるいは近づける方法としてRDBでイミュータブルモデリングを実践するのはどうか？」という点。

世界を切り離すことへの納得感はありつつ、RDBにおける物理表現と論理表現の間にギャップがあるのは大部分の開発者にとって難しい（変換の認知負荷が生じる）と考えていて、そこを埋めるアプローチがあるのではないか？

t_wadaさんの「理解容易性と変更容易性を支える自動テスト」

自動テストについて最もよく整理された資料だと感じており、折に触れて引用したい
Test ScopeとTest Sizeのマトリクスが特に好き
僕はデトロイト学派

「変更不可能な外部からの要求で大量のパラメーターを送りつけられるWeb APIのように、自分たちが管理できないコードベースとの接合点で信頼性の高いテストを書くにはどうすればいいか？」という質問をさせていただきました。

仮定をテストに混ぜ込むしかない、自作自演にならざるを得ない、実物をCIで呼び出せない...といったことが起こりがちなこの課題に対して「腐敗防止層やHumble Objectの導入でTest SizeとScopeを狭めていき、信頼性の高いテストの割合を増やしていくと良い」という回答を頂いた。

mitaniさんの「VISAカードの裏側と “手が掛かる” 決済システムの育て方」

身内びいき抜きに一般公募では最も感銘を受けたトークでした。

今回のmitaniさんの登壇内容に、僕はmoznionさんの「Javaカードの世界」(2018) を勝手ながら重ねており、どちらも技術者の心のくすぐり方が最高に巧かったなと感動していました。そういえば、どちらもカードの話題だな...。

このように業務上で学んだことを公知にしていく試みがベストトーク賞というのも感慨深いものです。というのも、登壇しない/できない理由の第一位は「ネタがない/業務で大したことやっていない」というものだからです（ohbarye調べ）。いち事業会社の中で必要に迫られ行う日々の業務の延長にも、このように多くの人の心を捉える登壇があるのだ... と多くの人が思えたのではないでしょうか。

加えて、クレジットカードのように現実世界に存在する物理的なアイテムとソフトウェアの交差点に存在する難しい課題と、それらをどう解いていくかに関心を抱くエンジニアは思っていたよりも多そうだというのも発見でありました。