トーク

PHPはZend VMの上で動いており、すべてのPHPプログラムはそのopcodeに変換され実行されます。
本発表では、そのopcodeを眺めてみて、他の言語処理系との違いについてご紹介します。
発表者はいくつか仮想マシンを作ったことがあり、とくにRubyの仮想マシンについてちょっと詳しいので、そういった観点でご紹介できればと思います。
参加者の皆様には、他の言語処理系との比較を通じて、Zend VMの独自性や利点を理解していただければと思います。

__get() 経由で読み取り可能な protected プロパティに対し、外部から empty() を使用した際、値が存在するにも関わらず true (空) が返ってくる現象に遭遇しました。

「直接アクセスでは値が取れるのに、なぜ empty() は空と判定するのか？」

調査の結果、原因は empty() 関数の内部仕様にありました。
empty() はアクセス不能プロパティに対し、いきなり get() で値を取りに行くのではなく、まず isset() で存在確認を行います。
ここで __isset() が未定義だと、問答無用で「存在しない＝空」と判断されていたのです。

本LTでは、この意外なハマりポイントの解説と、get() を使うなら必ず isset() も実装すべきという「お作法」について、実例を交えて共有します。

※PHP7.4のお話です。
8.1以降なら public readonly でプロパティを定義すれば __get() とか使わなくて良いはずですが、実際には8.1まで上げられていないプロジェクトもあると思うので…。

2015年、PHPコミュニティは内戦状態でした。Scalar Type Declarations RFCは、賛成108票、反対48票という異常な投票数を記録し、厳密派と寛容派が激しく対立しました。なぜ最終的にstrict_typesは「ファイル単位のオプトイン」になったのでしょうか。

背景には、PHP 5.4で削除されたmagic_quotesの苦い教訓がありました。php.iniの設定次第で同じコードが環境によって異なる動作をし、SQLインジェクション脆弱性を生む原因となった経験から、PHPは環境依存の設定を避ける方向に舵を切りました。さらに、Composerエコシステムとの共存も不可欠でした。もしグローバル設定が可能だったら、vendorディレクトリ以下の数百のパッケージが想定外の動作モードを強制され、エコシステム全体が壊れる可能性がありました。

この設計は「漸進的型付け」という学術的アプローチに基づき、後方互換性、エコシステムの安定性、開発者の選択の自由を守りました。「全部ONにすべきか」という問いへの答えは、あなたのプロジェクトが決めることです。Whyを知るとHowの判断が変わります。

Laravel×Inertia.js構成のSPAで、CSVから5,000件のデータを取得し複数テーブルを参照して表示する処理を実装した結果、ユーザーは真っ白な画面を十数分待つことになってしまいました。

まずEloquentのlazyById()で1,000件ずつ分割処理を試みましたが、すべての処理完了まで画面表示できず、5分待たされます。次にInertia.jsのlazyプロパティを導入したところ、初回表示が短縮され、重い処理は後から非同期で読み込まれるようになり、ユーザー体験は大きく改善しました。

さらにlazyに関して調査を進めると、Inertia.js v2.0で追加された「Deferred Props」という機能に出会いました。実際に導入してみると、lazyよりもパフォーマンスが向上し、コードもシンプルになりました。しかし、なぜDeferredの方が優れているのでしょうか。

本セッションでは、lazy propsとDeferred Propsの違いを内部実装から読み解きます。具体的には、HTTPリクエストの発生タイミング、サーバーサイドでのデータ解決の仕組み、なぜDeferredの方がパフォーマンスが良いのかを、LaravelとInertia.jsのコードベースを追いながら解説します。そして最後に、実践的な使い分けパターンをお伝えします。

このトークは、Inertia.jsを使っているけど遅延読み込み機能を使ったことがない方、v2.0の新機能が気になる方、大量データ表示で困っている方、「なぜ速くなるのか」を理解したい方に是非聞いていただきたいセッションです。

「コードレビューお願いします」と投げたプルリクエストが、いつまでも待ち行列に並んでいる・・・。
そんな状況に心当たりはないでしょうか？

私たちのチームではレビュー待ちが大量に溜まっている状態が当たり前になっていました。
開発速度は落ち、レビュー品質の劣化、コンフリクト多発、リリースサイクルの悪化、
そんな悪循環をなんとか断ち切るべく、様々なことに取り組みました。

・PHPStanによる静的解析の導入
・プルリクエストのテンプレート改善
・AIコードレビューの導入

しかし、これらを実施してもレビュー待ちは減らず、最終的に効いたのは「毎日決まった時間にレビューする」という固定時間制の運用でした。
カレンダーに事前にスケジュール登録することで差し込み会議を防ぎ、優先度が下がりがちなレビューに強制的に着手する仕組みを運用したことでレビュー待ちが劇的に改善したのです。

このトークでは、レビュー待ちがチームにもたらす悪影響についてや、静的解析やAIでは解決しなかった理由、
シンプルな運用ルールがなぜ劇的に効いたのかを、実体験をもとにお話しします。

想定聴講者

• チームのレビュー待ちに課題を感じている方
• 技術的な解決策を試したが効果が出なかった方
• 開発フローの改善に興味がある方

ProgateでPHPを学び、2ヶ月でCRUD処理ができる掲示板を作れるようになりました。しかし機能を追加するたびにコードは複雑化し、どこに何を書けばいいか分からなくなり、収集がつかなくなっては最初からやり直す日々。
この地獄を抜け出すために「フレームワーク」を調べ始めましたが、LaravelやSymfonyの説明を読んでもありがたみが分からないし、漠然と機能を覚えていく学習に面白さを感じませんでした。ならば自分で作ってみよう。
MVC、ルーティングのディスパッチャー、コンストラクタインジェクション、バリデーター、CSRF対策、自動XSSエスケープ、Laravel風のヘルパー関数—これらをゼロから実装する中で、特に「依存性注入のメリット」と「設定より規約」の考え方が腹落ちしました。
本トークでは、フレームワーク自作を通じてこれらを理解していった過程を共有します。

トークの内容：

• スパゲティコード地獄から、フレームワーク自作に至るまで
• 実装した機能の紹介
• 「設定より規約」： ディレクトリに置くだけで動く、コンストラクタに書くだけで再帰的インスタンス化
• 「依存性注入」： サービスプロバイダで実装の差し替え、テストの容易さ
• まとめ： 作ることで「なぜ必要か」が腹落ちした

「間違いたくない」「正解を出したい」
かつての私は、はじめから完璧を目指しすぎて、かえって大きな手戻りを生んでしまっていました。

どうすれば、手戻りを減らせるだろうか？
試行錯誤の末に見えてきたのは、「はやく失敗する」ことの重要性でした。

このLTでは、手戻りの多さに悩んでいた新卒1年目の自分に伝えたい、はやく失敗するメリットと、その実現のために日々の開発で実践していることについてお話しします。
似た悩みを持つ方にとって私の経験が参考になれば嬉しいです！

アーキテクチャの刷新は、しばしば「決める人」が限定され、トップダウンでの進行になりがちです。
しかし、その方法では納得感が生まれず、チーム全体が新しいアーキテクチャに適応しきれないのではと私は感じていました。

そこで実施したのが、「俺の/私の最強アーキテクチャ決定戦」というイベントです。
全員が発言できるように場を用意し、メンバーがそれぞれ考える理想のアーキテクチャを持ち寄る形式を取りました。

この取り組みには二つの意図がありました。

1. トップダウンにせず、チームで方向性を決めたかった
2. 不満や現状の違和感を、発言機会を設置することで可視化したかった

実際に開催してみると、若手メンバーからも積極的な発信があり、各自抱えていた困りごと・改善の種を吸い取ることができました。
最終的に決まったアーキテクチャはひとつですが、その結論には全員の声が反映された状態をつくれました。
これによりトップダウンでは得られない、「自分たちで決めた」という納得感とオーナーシップが生まれました。

本LTでは、
・なぜトップダウンではなくイベント開催を選んだのか
・どのように発言機会を設計したのか
・若手の声を拾うことで何が変わったのか

チーム全員が新しいアーキテクチャに適合するための工夫を実体験に沿って紹介します。
アーキテクチャ刷新は設計だけでは進みません。
“決め方”を設計することでチームは刷新に適応できるようになる。
そんな学びをお伝えします。

■想定する参加者層
・トップダウンの設計決定に違和感を覚えたことがある人
・若手の意見を引き出したいリーダー
・設計刷新や合意形成に悩むチームメンバー

■Learning Outcome
・チーム内での考える人作る人の分断を防止できる
・チームが主体的に開発を進めていける
・チームがオーナーシップを持ってプロダクトを育てていける

皆さんはLaravelのアップデートを定期的に行っていますか？

私たちのチームは段階的にLaravelのアップデートを行い、最終的に9から12まで上げることに成功しました。
その過程の中、10→11の段階でアップデートしようとしてみたところ
composer updateの実行で何のエラーログもなく実行エラーとなってしまいました。

最初は原因が分からず困惑しましたが、なんとか解決し
その過程でLaravelが起動される時の流れをいい感じに学ぶことになりました。
今回はLTでその流れをご紹介したいと思います。

「PdMとのコミュニケーションに課題を感じる」「PdMが技術の壁を理解してくれない」と感じているエンジニアの皆さん、それは相互理解の機会不足かもしれません。本LTは、非エンジニアのPdMである私が、PHPコミュニティ（広島/香川スタッフ）での活動を通じて得た知見を共有します。PdMをPHPカンファレンスに送り込むべき明確な理由と、エンジニアの皆さんがPdMを巻き込むことで得られる3つの具体的なメリットをお話しします。プロダクト開発におけるPdMとエンジニアの連携の質を高めるヒントを持ち帰ってください。