PHPerKaigi 2025 day1 - day2 に参加しました。これまで観た各トークセッションの感想です。順序はタイムテーブル順。
今後アーカイブで観た分は、Xのメンションで感想をお送りするかもしれません。優先的に見るべきセッションがあれば自薦他薦を問わず是非教えて下さい。
PHPによる”非”構造化プログラミング入門 -本当に熱いスパゲティコードを求めて- (資料) by きんじょうひでき
逆説的に「普段の開発で避けるべきこと」を知る
使う: gotoや標準関数は使う
プロポーザルの時点で、聴くことを決めていた。
1年ほど前から読んでいるPHP自体のソースコードでgotoが多く使われている。世界最高峰のプログラマーが集まるリポジトリで「過去の遺産」と言える書き方が出てくることに驚いたが、詳しい人に聞いても、どうやらそれが「ベストな書き方」のようだ。該当の箇所をgotoを使わず書き直した状態を想像してみると、確かに筋が悪そうに感じる。
goto自体が悪いわけではなく、gotoによりもたらされる典型的な状態が悪い、それを避けられるのであれば忌避する理由はない、ということになる。ルールに盲目的に従うのではなく、そのルールが存在する理由に目を向けることを私は大切にしている。
そんなような内容のプロポーザルに見えたので、そこを期待していた。期待通りの内容だった。
制御の一部をブラックボックス化し、入口と出口を固定する。これにより、人間の限られた認知能力を最大限に活かす。それを行った状態をコールスタックという形で図示。図とgotoとをセットで考えてみると、積まれたコールスタックを無視し自由に大域脱出したり復帰するような構造は、確かに人間の認知能力を超えそうだ。そう考えると、少し前に私が見かけたgotoも、スタック間を自在に飛び回るものでもなく、同じ層の中で少しの移動をしている控え目なものだった。直感通りの言語化と図示。
質問コーナーで「gotoの弊害はわかったが『良いgoto』を見たことはあるか？」という、少し意地悪(?)な質問をした。即答で「composerのコードで使われている」との回答があり、なんと資料のページまで用意されていた。
実はこの質問は、質問であると同時に、画一的なルールを当てはめることに対する全体への問題提起も意図していた。懇親会の酒席で聴いた話によると、私がその手の質問をすることはある程度予測していたそうだ。私はこの手の話が本当に好きらしい。「阿吽の呼吸」のようなやりとりで心地よかった。他の方の理解の一助にもなれていれば嬉しい。
BCMathを高速化した一部始終をC言語でガチ目に解説する (資料) by 高町咲衣
BCMath改善は、今回のトークのずっと前から注目していた。
話題を最初に目にしたのは Ya8 2024 - ヤパチー 令和六年最新版(仮) が開催された日だった。懇親会の最中にふとスマホを見たら演算子オーバーロードのアイディアが議論されているのを見つけた。目の前にいた @tadsan に興奮気味に話した記憶がある。それからリリースまでの8ヶ月間、ずっと楽しみにしていた。
改善時のプルリクエストを事前に読み概要は知っていたので、このトークには、コードには出てこない設計意図の話や、読んだ当時は難しくて理解できなかった箇所の話題を期待していた。
設計意図の話題としては、解析処理のチューニングの話が面白かった。ユーザー入力のパースなので、Webばかり扱っている自分からとしては「任意のユーザー入力の傾向を予測する方法など無い」「予測できない以上は素朴な実装に留めるべき」と早々に結論付けてしまいそうだ。ここに対しては、次のような仮説に基づいてチューニングを行ったとのことだった。
01.23という文字列が入力されるのは稀だろう。1.230000はあり得る。幾つかのDBでは指定桁数にあわせ右側のゼロ埋めした値を返す。
後者はおそらく、BCMathだけでなくPDOのメンテナとしても活躍されている経験が活きている。PDOメインからだいぶ毛色の違うBCMathにも手を広げているのを見て驚いたが、ひょんなところで経験は活きるものなのだと再確認した。
当時理解できなかった箇所の話題としては、文字列の解析処理の解説を聞けて良かった。「並列化のために拡張命令を使っている（らしい）」「そのために何か前処理をしている（ようだ）」という程度の理解しかなかったが、ポイントとなるコードが日本語のコメントとともに示され図による簡単な解説もあったので、トークを聴き後で幾つかのCPU命令を調べるだけで理解できた。
そしてやはり、一番面白かったのは四則演算の高速化の話だった。
一見すると難解または計算の難しい式も、少しの変形を施してやるだけで簡単な式に様変わりする。受験数学が好きだった私にとっては楽しく馴染み深い世界だ。数学のちょっとした問題を楽しむ感覚で、足し算、引き算、掛け算、これらの説明を聞くことができた。だが、聞く分には楽しくても発想に至るまでの道のりがとても長いことも知っている。資料に「思いついた」というフレーズが出てくるが、そこに至るまでの尽力に感謝したい。
なお、「割り算」は未だに理解できていない。
コメントで証明を書いた
この法則が既に世の中で発見されて名前がついているのかは知らないのですが、私はこれを自力で見つて証明しました。
読むのであればしっかりと理解できるところまで読みたい。時間とモチベーションの両方が揃ったタイミングでチャレンジしようと思っている。
移行できそうでやりきれなかった 10年超えのシステムを葬るための戦略 (資料) by 株式会社 fluct ⽯河 ⻯太
リプレイスプロジェクトで遭遇しがちな「生々しい苦労」と、それに立ち向かった記録のトーク。リプレイスの苦労はプロジェクトの状況に応じて様々なため、一般的な「正解」が存在しない。個別のノウハウを紹介しようとするとどうしても、外に出すのは憚れるような「生々しい話」が必要になる。それらを余すこと無く吐露し、それぞれ妥当と思われる個別の解決策も説明する貴重なトーク。
まずは計画。一般的に、リプレイス計画の多くは遅れる。または要件がブレて目的を見失う。プロジェクト管理としてそれをどう防ぐか、そのために誰とどのように話をしたか、何れも、強い意志を持って進めたのだろうと感じられる内容だった。次のようなフレーズが印象に残った:
機能提供の停止まですることを「葬り」と呼んでいる
期限がないなら⾃分で期限を決めるしかない
「使います?」だと「使います」と回答されてしまいがち
他の人から応援してもらえるかどうかは大切
開発者と運用者双方と対話をする
何れも、明確で能動的な意思を持っていないと出てこない言葉だと思う。技術ももちろんだが、この姿勢が、リプレイスを成功に導いたのだと思う。
次に作業。リプレイスでどうしても陥りがちな「把握できない」「判断できない」という状況への臨機応変な対応が上手いと感じた。有識者の話を聞くのは当然必要だが、それにも頼れず把握も判断も出来ない機能への対処のため、挙動を監視ツールで外部から観測できる手段を用意したのが印象的だった。
確かに私も、どうしても把握できない実装があった場合、ログなりプロファイリングなり複数の方法で外部から動作を観測する。トークの例の場合、最初の段階からツールを用意してしまったようなので、その後はかなりうまくやれたのだろうと思う。
広告というミッションクリティカルな分野での成功、誠にお疲れさまでした。
プロダクトコードとOSSに学ぶ例外処理の選択肢 — キャッチするのか、投げっぱなしにするのか (資料) by asumikam
表題の「OSSに学ぶ」という一節より、がぜん興味を持っていたトーク。
例外処理は、ビジネス要件やそれ以外の要件が入り乱れ、注意しないとすぐに複雑になってしまう。ビジネス要件はアプリケーションごとに異なるため、例外の設計や実装もプロジェクトごとに似て非なるものになる。こういった、正解や参考に乏しい分野の知識をOSSから得るやり方はとても気に入っている。同じことを他の人はどうやっているのだろう、それを知りたかった。
「Guzzle」「Slim」「PHPUnit」の順に紹介されたが、題材の選定が秀逸に感じた。アプリケーションレイヤーでの例外処理、ただし例外の出所が多岐にわたるため、否応なくそれらを分類した解説が必要になるGuzzleの例。例外を「キャッチしない」という選択肢と、最終的にそれがどのように処理されるか示すSlimの例。ここまでの「基礎」のような内容に加え、テストという特殊な状況に対応するため普段と少し違うハンドリングを行うPHPUnitの例。
身近な例、それを支える基盤の実装例、特性を理解し普段とは異なる活用をしている例、バランスが良い。多くの聴衆にとって、とても解りやすい説明だったのではないかと思う。
ソフトウェア開発におけるインターフェイスという考え方 (資料) by @k1LoW
昨年のPHPerKaigiではじめてk1LoWさんとお会いし、それから1年ぶりにトークを聴き話もできた。初めてお話を聞いた時に受けた、ソフトウェア開発へのとにかく真摯な姿勢の答え合わせを出来たようなトークだった。
前回お会いした時は、ちょうどrunnへ追加する新機能のデザインをkatzchumさんと検討しているタイミングのようだった。懇親会の場で検討の一端を聞けた。どんな機能を追加するのか自体は決まっている、それをどのような形で利用者に届けるか、この点の熟考を重ねているような印象を受け、そこに真摯さを感じた。
トークの内容は至ってシンプルだった。使用者と提供者が存在する場合、その境界に存在する「何か」は全てインターフェースではないか、という仮説の提起。ここまではごく当たり前の話なのだが、ユーザーインターフェースやオブジェクト指向でのインターフェースに限らず、「エラーメッセージ」「データベーススキーマ」などにまでその概念を適用し、トークの最後では「全て」とまで言っていた。
1年前に受けた真摯な印象とトークでの主張が、私の中で綺麗に繋がった感覚がある。
私も似たようなことを考えてはいる。ソースコードの多くのコメントは、関数や変数の名付けやシグネチャの熟考により多くが要らなくなると思っている。十分に検討されたデータベーススキーマであれば、「データベース定義書」と呼ばれる資料が無くとも要件のほとんどは把握できる。何れの場合も、独りよがりにならず利用者の目線でデザインすることが重要だ。
これらの対象を「全て」にまで拡張し特性を一般化する、この点に軽い衝撃を受けた。
「そこまで考えてたら、時間がいくらあっても足りなくないですか？」
「私は、手が遅いので…」
質疑での私からの質問と会場を爆笑させた回答だが、これは謙虚さの現れだと解釈した。神々は細部に宿る（資料中の引用）からこそ、時間をかけて熟考を重ねているのだと思う。
The PHPer’s Guide to Daemon Crafting, Taming and Summoning (資料) by uzulla
PHPスクリプトでデーモン（いわゆる「常駐プログラム」）を実装する際の注意点やテクニックの紹介。普段は触れないが基礎知識として重要な領域を扱うトークだった。
一見すると色物に見える技術を面白おかしく紹介しているようで実は示唆に富み役立つ内容が多く含まれる。これがuzullaさんの「芸風」だと思う。今回はそれが際立っており、とにかく楽しく興味深かった。
中盤、安定したデーモンを実装するのは難しい、という問題提起があった。現時点の私は、ここに対する難しさを「忘れていた」。何が難しいのかわからないまま説明を聴いたところ、ずっと以前にNode.JSでWebSocketベースのAPIサーバを苦労し怯えながら実装したことを「思い出した」。当時は確かに難しかったが、確実に現在の糧になっている。
ここで向き合わなければならない「難しさ」は、FrankenPHPなどのいわゆるAlt FPMを扱うときのそれと多くが共通する。あまり慣れていない領域だからこそ、例えばISUCONで戦う武器の技術的な背景を知る等を目的に今回のトークで紹介された設計を実際に実装してみる、これらの試みは役に立ちそうだ。
トークでは「他の言語」という選択肢も示されていた。ただ私の意見としては、「他の言語」を使ったとしても本質的な難しさは変わらないと思う。逆に言うと、PHPでデーモンを書くこと自体は決してそこまで突飛な選択肢ではない。Laravelのキューワーカーはデーモンに相当するし、トークでの紹介とほとんど同じコードなども登場する。
Systemd Serviceにも触れられていた。デーモンの制御を理解する必須の例だと思うが、個人的にはここにECS等でのシグナル制御などの話題を加えて欲しかった。Webアプリのコンテナ化でデーモンをうまく扱えず事故に遭遇する例をかなりの回数見ているためだ。…という個人的な要望はともかく、今回の話題、重要度は高いのにあまり知られていない、タスク上もポテンヒットになりやすい領域なので、多くの人に刺さる伝え方でトークにして下さった点が良かったと思う。
OSS開発者からバックオフィス系Saasに転職して感じたPHPの価値の違い (資料) by 斉田真也
筆者は2024年9月にECサイト構築用のOSS開発者から、企業向けバックオフィスのSaas開発会社に転職しました。
これも、プロポーザルの頃から必ず聴こうと決めていたトーク。
EC CUBE開発者（OSS開発者）から販売管理Saasの開発への転身、開発要件の似通ったキャリアを活かした転身であると同時に、課題領域やそれによる価値観の違いなどで戸惑うことの多い転職だったのではないかと想像していた。最近の自分の興味の対象である「OSSと営利アプリケーションの課題領域の違い」を洞察するヒントも多く得られるだろうと期待していた。
期待は想像以上だった。私にとって、「EC CUBE」は想像を絶していた。
トークやその後の登壇者との雑談で思い出したのだが、EC CUBEは長らく（今も？）「可哀想な状況」に置かれていたと思う。無保証のOSSなので利用はインシデント対応なども含め全てはショップオーナーの自己責任、のはずなのだが、世間はそうとは認識してくれない。「EC CUBEで不正決済」という見出しで記事になってしまうと、矛先はEC CUBEに向く。
それを防ぐには、仮に過剰だったとしても対策するしかない。OWASP ZAPによる脆弱性診断がコミットされた時は本当に驚いたし、トーク後にクレジットマスター攻撃の対策の話を登壇者から聴いたが、真っ先に頭に浮かんだ感想は「それはショップ側がインフラや他のソリューションの導入を通じて保護すべき箇所では？」だった。だが、よく考えてみると、月数百円のレンタルサーバにインストールされるケースなども想定しなければならない以上、対策は必要だ。戸惑った点を聞くためにトークに来たはずなのに、聞いていた私自身が激しく戸惑った。
前提の文章が長くなってしまったがここからが感想。この戸惑いを「価値の再発見」という形でトークに昇華した点が見事だったと思う。BtoCとSaaSの違い、アウトプットとアウトカムの違い、価値の担保を言語（PHP）にやらせるか他に任せるか、何れも「要件定義」「設計」と言った活動で当たりに検討することではあるが、考え方の全く異なる開発への転身を遂げたからこそ、それをグラデーション鮮やかに説明していた。それが印象的だった。
複数ドメインに散らばってしまった画像…！運用中のPHPアプリに後からCDNを導入する…！ (資料) by スー
まずCDNとは何かを説明。次に導入の考え方ややり方を紹介した後、特に注意すべき点として「プライバシー」を重点的に取り上げるという、バランスの良いトークだった。
Amazon CloudFrontは私が一番好きなAWSサービスだ。要はそこそこ精通している。なので、個人的にはもっと濃い話を聴きたかったという感想もあるにはある。ただ、使ったことのない人や雰囲気で使っている人にとっては、より使いこなす次の一歩を踏み出せるような内容のトークだったはずだ。
そう考えると、プライバシー対応（キャッシュ経由の情報漏洩のリスクへの対処）に多くの時間を割いたことは素晴らしい。何が危険なのか、安全にするにはどう対応すれば良いか、どのようにテストすればそれを確認できるか、全て説明されていた。
質問時間には「なぜ複数ドメインに散らばってしまったのか？」という質問があった。最初にS3 Bucketを作成した際の考慮不足やその後の設計上の制約が原因だったとのこと。つまりこのトークは「レガシー改善活動」の話でもあったのだが、機会があれば、その「レガシー」の詳細も聞いてみたいと思った。サーバサイドのNext/ImageがS3画像を取得するアーキテクチャでパフォーマンス問題が発生した理由やLambda@Edgeのユースケースがよく解らなかったのだが、とても楽しそうな（苦しそうな）話を聞けそうな気がする。スーさん、良かったら今度教えてください。
アーキテクトと美学：美しさがシステムにもたらす秩序と未来 (資料) by nrs
共感を抱けるトークだった。あまりにも共感を抱きすぎたために、懇親会で思わず「ネタにマジレス（マジ質問）」という大変恥ずかしい行動に出てしまった。本人としてはネタトークを多分に含む意図だったそうで、若干の苦笑いをされてしまった。それでも、私にとっては清々しいトークだった。
美しさは説明できる
「アート」という文脈でこう語られているが、設計やコードに対しても同じことが言える。「このコードは美しくない」とレビューで伝えたとて、お互い何のメリットもない。そんな指摘では改善は不可能だし伝えられた側も不快感しか残らない。より客観的で再現可能な言葉に言語化し「綺麗」の定義を共有知化する活動がソフトウェアの改善活動だと考えている。
そんなことを考えながら、日々コードを書いたり読んだりしたりしているのだが、たまに困ることがある。例えば資料例を借りて:
名画から学ぶアートの見方
- 三角形の構図
シンプルさと安定性
コードレビューでこのように「言語化」し指摘したとする。
三角形の構図がシンプルさと安定性をもたらす、これ自体は間違ってはいない。だが、三角形の構図を持てばそれは必ず名画になるとは限らない。因果が逆だ。
同じ誤謬をレビューで意図せず生じさせてしまうことがある。レビュイーにとっては「前回の指摘を率先して取り入れた」つもりが、結果的にアンチパターンを踏んでしまうようなケースだ。おそらく自分の説明が良くないのだが、安定してそれを回避する方法が見つからず苦労している。
美しさはつくれる
さもなければ巨匠は生まれない
再現性こそがアーティストを生み出す
より「再現性」を高めるには何をすべきか話したかったのだが、どうやら熱くなりすぎていたようだ。とはいえ、考える強烈な切っ掛けにはった。暫くの間思考を巡らせたい。
今回も登壇しました。それに関する記事は別途書く予定です。
毎度ながら、カンファレンスとしての完成度の高さに感心させられました。トーク外のちょっとした時間を有効活用させるための段取りの緻密さ、スタッフやスポンサー含む全参加者への配慮、素晴らしいカンファレンスをいつもありがとうございます。
