PHP カンファレンス2024に行ってきました #phpcon
表題のイベントに参加してきたのでご報告申し上げます。
7トラック同時進行という大ボリュームでした。当然すべてはチェックできないわけですが、いくつか聴講したセッションから心に残ったものをいくつかふりかえり。
PHP の今とこれから2024
恒例の廣川 類さん講演。
W3Techs の統計ではサーバーサイド言語の3/4を引き続き PHP が占めているとのこと。書店の雰囲気とか若手エンジニア市場とかを見ているとだいぶ Python がのしているなあと感じるんですが、エビデンスベースでは PHP が引き続き強い。
2021年に起こった PHP コア開発者 Nikita Popov の離脱と PHP Foundation 設立、そしてその後追加募集されたコア開発者が新たに活動を開始し、先日リリースされた PHP8.4においては日本から Saki Takamachi 氏が3人のリリースマネジャーのひとりとして参画しました。
PHP 8.4、リリースされました！！https://t.co/RSmOOnIRi5
— Saki Takamachi 🇯🇵さきち❤️ (@SakiTakamachi) 2024年11月21日
PHP 8.4の主なトピックス：
- JIT に IR フレームワーク導入。直接的な性能改善というよりは、今後性能を改善しやすくするための布石
- プロパティアクセスフック
- 非対称プロパティ可視性
- オブジェクト初期化の遅延
- DOM インタフェースの HTML5対応ほか改善（※ HTML5 はすでに廃止されているわけですが…）
- PDO にドライバ固有のサブクラス新設
- BCMath オブジェクト API
- アトリビュートでの
Deprecatedアノテーション array_find関連の関数追加- deprecation
- 暗黙の nullable 型宣言
- すでに役目を終えていた
E_STRICT - GET/POST での Cookie 伝播
講演の最後に言及されたブログ記事。
ちなみに、上記記事の URL を探そうと Google に表題を打ち込んだら先生は以下のようにおっしゃいました。きいてないって。
Beyond ORM
ななうぇぶこと菱田さんの講演。
"Entity" の定義は文脈によってさまざま。DDD におけるエンティティは ID をもって同一性が識別される何かだったし、クリーンアーキテクチャでは中核的なビジネスルールをカプセルした何かだったし、ORM におけるエンティティは当該 ORM 作者それぞれが定義したところのエンティティである。であるなら、ORM ユーザーが自身のビジネスロジックを ORM 作者の定義するエンティティに実装してやる義理はない。ORM のことは「高級なクエリ―ビルダー」と割り切って、ビジネスロジックは自分の都合のよいところに書く手もある。ORM から取ってきたエンティティは、自分たちで定義したエンティティに「詰め替え re-packing」をしてやればよい。ORM は使っても使われるな。
かつてわたしにも、CakePHP の規約からすれば Cake の提供する「テーブル」「エンティティ」にビジネスロジックを集約してやらなければならないんじゃないか、でもやってみたらモデル層が太りすぎて身動きが取れないんだけど、と悶々としていたことがありました。その頑張りは報われないとある時期から気がついて、語彙としては知らなかったものの結果として「詰め替え」の戦術にたどり着いたのでした。フレームワークのレールの外に出てしまってよかったんだろうかとやや自信が持てていなかったんですが、今回のお話はまさに自分のやったことを理論武装してくれるものでした。ありがとうございました。優勝。
QA環境で誰でも自由自在に現在時刻を操って検証できるようにした話
Toshiyuki Fujitaさんのオトバンク在籍時代の取り組み。
表題どおり「QA 環境」の整備としても有用なんですが、そもそもは「アプリケーションにとって現在時刻とは何か」という話だと思う。この話には QA 環境にとどまらない応用性がある。
たしかに同一トランザクション中で現在時刻を複数回参照する処理については「1回目と2回目のわずかな時間経過で日付をまたいだりしたら汚いんじゃないか、でもそんな細かい話誰も気にしないか」と気にしないふりをしていたのでした。たまたま時刻にさほどシビアでない案件が多かったのでこれまでやってこられていましたが、落ち着いて考えるとやっぱり気持ち悪いんですよね。とはいえじゃあどの時刻をあてにすればいいのかと思ってたんですが、 $_SERVER['REQUEST_TIME'] のことはまったく盲点でした。次からこれ使おう。
情報漏洩させないための設計
M&Aクラウドの久保田さんの取り組み。
ここでの「情報漏洩」とはおおよそ、機密とすべき情報がアプリケーション実装の不具合により第三者に渡ること。不正アクセス対策は徳丸本を読もう。ある情報を見せる・見せないの制御を UI 層にいちいち実装するのは漏れが出そうでこわい。DDD いうところの「境界付けられたコンテキスト」にならって、画面を閲覧するアクターそれぞれに対応するデータオブジェクトを定義しよう。そしてコンテキスト境界を踏み破って参照すべきでないオブジェクトを参照することがないよう、deptracで保護しよう。
『セキュア・バイ・デザイン 安全なソフトウェア設計』ってこういうことをやれという話だったのかな、とふと思った。こういうシンプルな実践例があるとすごく納得感がある。そしてななうぇぶさんのところに書いた「詰め替え」の機構を担うクラスに対して、ちょうど先週思いもよらないレイヤーからの参照が追加されるプルリクエストがあったところで、いまいちど開発メンバーに各レイヤーの依存関係についてレクチャーしないといけないと思っていたところだった。レクチャーもいいけれど、deptrac を導入してやばい参照は CI で落とすのが先か。こういう話って、人間同士が口頭で話すとしばしばすれ違いが起こるけれど、「なんかよくわかんないけど CI が落ちる」となれば人は CI のいうことをなんとなく聞いてしまうんですよね、なぜだか。
