コードの自動修正を行うツール、Rector。提供される修正ルールは700超！
大量で多様なルールに対応する裏には、高い拡張性を実現する「良い設計」があります

中核的なコンセプトの1つは、対象コードを抽象構文木として扱うことです。 そして、各ルールはVisitorパターンで適用されます
──ツリーに対してVisitor。美しく王道的なアプローチの魅力を、一緒に覗いてみましょう

• 目的
  • 普及しているOSSという実践的な例から、Visitorの概要と効果について学ぶ
• 対象
  • これからデザパタやVisitorパターンを身に付けたい
  • Rectorやカスタマイズに興味がある
• 話すこと
  • Rectorの概要
  • ルールを自作して基礎を掴む
  • Visitorパターンの概要、使われ方

与えられたテキストを文法に則って解析し、別の構造へと変換するのが、構文解析器(パーサー)です
独自のPHP製パーサーを生成する、PHP-Yaccをご存知ですか？
文法を定義するための記法(BNF)を使い、本格的なパーサーを生み出すものです
有名どころでは、nikic/php-parserにも利用されています

本トークは、「JSONをPHPのデータに変換する」をお題に
自作パーサー開発の入門レベルの解説を行います
どんな風に作るの？どんなコードができるの？を味わいましょう

これを聞いたら、次はあなたが自作パーサーに入門する番です！

話すこと

• パーサージェネレーターを使ってみる
• 文法の定義(.yファイルを書く)

話さないこと

• レキサー、パーサーの詳細なアルゴリズム、実装パターン

PHPのロゴがどんなデザインか、皆さんは即座に思い浮かべられますか？
「たしか楕円…」「青と紫の中間色？」「このロゴって何代目？」「っていうか背景色あったっけ？」など、さまざまな思いが頭をよぎるかもしれません。

「知ってるつもり」だったPHPロゴについて、公式ドキュメントをベースに正しい仕様を紐解いていきたいと思います。
スライド作成中に「あれ、どのロゴが正しいんだっけ」と迷った経験のある方、一緒に答え合わせをしてみませんか？

対象者

• 資料作成などでPHPロゴを使ったことがある方
• PHPロゴの正しいデザインを覚えて帰りたい方

話すこと

• PHPロゴクイズ
• 正しいロゴの仕様確認
• 入手方法と使用ルール

「DDDは難しい」と思っていませんか？実はコア業務の定義と依存関係の整理こそが成功の鍵です。

レセプト業務という複雑ドメインで法改正に挑んだ実体験から、「何をコア業務とするか」「何に依存させて何に依存させないか」という依存関係の設計がシステム全体の安定性をどう変えるかをお話しします。

コア業務を安定させた結果、以下の効果がありました。

• 開発プロセス全体が改善
• スキーマ駆動開発が自然に導入できる
• チーム間の調整コストが激減

依存関係の逆転によってスキーマ自体も安定化。その安定度を高める具体的施策も含めて、理論より実践重視で解説します。
3年に一度の大規模法改正に立ち向かった実話の例とともに、段階的にアーキテクチャを進化させていくための、現実的な道筋をお伝えします。

技術コミュニティへの参加は、エンジニアにとって学びや刺激を得る貴重な機会です。
しかし、様々な制約がある中で「どこまで集中して参加できるか分からない」という不安から、足が遠のいてしまうこともあるのではないでしょうか。

先日子連れでPHPカンファレンスJapanに参加した体験では、参加者・スタッフの皆さんの温かい配慮に支えられ「全力で参加できなくても、コミュニティとの小さな繋がりがエンジニアのモチベーションを支えてくれる」ことを実感しました。
あまりセッションを聴けなくてもブースでの何気ない会話から仕事のヒントが得られたり、同世代・若い世代のエンジニアのアウトプットに刺激を受けたりと、予想以上の収穫がありました。

実際の参加体験から得た気づきや感謝、そして参加後の変化までをお話する予定です。
同じように「全力のコミュニティ参加」を迷っている方の背中を押すきっかけになれば幸いです。

「やる気が出ない。でも何かしなきゃ。」
そんな焦りに飲み込まれていた自分が、少しだけラクになれた経験をお話しします。

仕事での責務が増えてアウトプットが止まり、アウトプットするネタも浮かばず、周りがどんどんアウトプットしているのに自分だけが取り残されているように感じて、焦っていた時期がありました。
そこで私は、無理に動かず“できる範囲だけ続ける”ことを選びました。

このセッションでは、私が試してきた工夫や気づき、そして“やる気がない前提でどう設計するか”についてお話します。
やる気が出ないことにモヤモヤしている方、立ち止まっている自分に不安を感じている方へ、エンジニアとして長く続けていくための“ペースのつくり方”の一例として、少しでもヒントになれば嬉しいです。

カンファレンスに行き始めた頃、「カンファレンスの歩き方」に迷っている自分がいました。
セッションを通じて学ぶことが多く、満足はしていたものの、どこか聞いて終わりで完結してしまっている感覚がありました。

そんな中で、あるカンファレンスの懇親会に参加したことをきっかけに、一気に世界が広がりました。
登壇者からセッションでは語られなかった裏話を聞いたり、遠い存在に感じていた人たちと気軽に話ができたり、自分の悩みを相談できたり、参加することで得られるリターンの質が大きく変わったのを感じました。

このセッションでは、自分の中でカンファレンスの価値が「学ぶ場」から「つながる場」へと広がっていった体験をもとに、ちょっとした行動で変わる景色についてお話しします。
初参加の方や、踏み込みきれていない感覚を持っている方に届いてほしいなと思っています。

プロジェクトやプロダクトのマネジメントにおいて特に難しいのはステークホルダーやチーム外でのコミュニケーションだと思います。
マネジメントにおいてこういう課題に出会ったことはないですか？

• ビジネスから後から差し込まれ続ける要件
• プロジェクト/プロダクトを進めたい方向に進めようとしてもビジネスや外部のステークホルダーが納得しない
• 外部パートナーにお願いしたのに動いてくれない

これらの課題に対して1つ1つ向き合って解決していくための考え方と進め方について話します。

話すこと

• プロジェクトを進めたい方向に向かわせるためにステークホルダーとどう対話していくか
• プロジェクト/プロダクトの中で自分たちのコントローラビリティをどう高めていくか

話さないこと

• プロジェクト/プロダクトの具体的なチケット管理の仕方
• プロジェクトチーム内のピープルマネジメント

オブザーバビリティという言葉もよく聞くようになり、常にサービスの状態をモニタリングすることが運用において重要になってきていると思います。
モニタリングするためにダッシュボードを作って見るようにすると思いますが、あなたのチームのダッシュボード、いつの間にか"見る人しか見ない"飾り物になっていませんか？

本トークでは、その形骸化したダッシュボードから脱却するため、ダッシュボードをTerraformでテンプレート化し、コードとして管理する取り組みを実施しています。
コード管理することで、新規開発した機能や画面のダッシュボードも即座に出力することができ、一定水準のダッシュボードを開発・運用チームに配布することができます。
複数の開発チーム間で同じ構成のダッシュボードを利用することでダッシュボードを「開発組織の共通言語」へと進化させ、みんなが頼るダッシュボードにするための取り組みを紹介します。

世界で最も利用されているCMSであるWordPressをご存知でしょうか。
WordPressは、PHPを使用して構築されたコンテンツ管理システム（CMS）です。そして、おそらく殆どの企業が独自にカスタマイズし、プラグインを導入して利用していると思います。
近年、コーディングエージェントという技術が進歩しており、プロンプトに指示をしてコードを開発してもらうことが多くなっています。
果たしてカスタマイズされたWordPressの環境で実用可能なのでしょうか？

本トークの内容
このトークでは、実際にカスタマイズされたWordPressに対して以下の点を具体的に説明いたします：

• どのような指示を行ったか
• 何を改善できたか
• 何を改善できなかったか

実践的な事例を通じて、WordPressとコーディングエージェントの現実的な活用方法をお伝えします。

「i18n」や「k8s」など、長い英単語を数字で省略する語をヌメロニム（数略語）と言います。

WEB 開発者であれば毎日のようにどこかで目にするこれらの言葉ですが、いつの間にか自分の知らないヌメロニムが当たり前のように使われていたり、その意味を理解したつもりが雰囲気だけで使っている……そんなことはありませんか？

この LT では我々PHP開発者の身の回りに溢れるヌメロニムをクイズ形式で出題しつつ、その意味をちょっとだけ深掘りしていきます。

あなたも今日からヌメロニムマスター！

PHP は2015年以来、毎年11〜12月頃にバージョンアップが行われており、11月20日には待望の PHP 8.5 がリリース予定です。

かつてはゆるふわ言語の代表格として知られた PHP ですが、7.0 以降は型周りの表現力が大幅に強化された他、Readonly Property/Class の導入など、堅牢で読みやすく、壊れにくいコードを書くための強化が行われてきました。

そして PHP 8.5 では Haskell や Elixir など「関数型言語」にあるような「パイプ演算子」が導入されます。PHP にパイプ演算子……隔世の感がありますね。

本トークでは PHP 8.5 で導入される新機能の内、個人的に注目しているパイプ演算子と NoDiscard アトリビュートを中心に、どのようなメリットをもたらすのかを具体的なコードと用例を用いて解説します。

テストコード、書いていますか？

今日において、自動ユニットテストを整備することが開発生産性の向上に寄与することはもはや疑う余地がありません。また AI の活用により、テストコードを書くコストは従来に比べて大幅に減っています。

しかし「テストコードの書き方や導入方法がわからない」「テストコードがあるだけで満足してしまい十分にその効果を発揮されていない」「テストコードが負債化し開発の足枷になっている」などの課題に直面している方も多いのではないでしょうか。

AI がコードを書く時代になっても……いや、むしろ AI がコードを書く時代だからこそ「価値のある」ユニットテストについて一緒に考えてみませんか？

お話しすること

• AI 時代における自動ユニットテストの価値とは
• 価値のあるテストコードを書くための基本的な考え方
• よくあるアンチパターンと処方箋・テクニック

弊社で運用しているサービスの一機能である検索機能は、数百万件以上のデータを対象に、ユーザから毎分3,000件以上もの検索リクエストが送られています。
検索機能のミドルウェアにはAWS OpenSearch Serviceを利用していますが、現行バージョンがEOLになる見込みがあり移行が避けられない状況でした。
移行にはアプリケーション側の修正も必要で、移行中にダウンタイムが発生するとサービス提供に影響が生じ、インシデントに繋がる可能性もあります。

本発表では、運用中のサービスを止めず・壊さず、段階的リリースやコードの移植を通じて実現したゼロダウンタイム移行の手法、移行を通じて浮上した移行しにくい設計、今後の設計改善についてお話します。

ターゲット

ミドルウェアのバージョンアップを実施・検討している方
ゼロダウンタイムでのリリース手法に興味がある方
既存設計の改善に興味がある方

弊社で運用しているサービスの一機能である検索機能は、数百万件以上のデータを対象に、ユーザから毎分3,000件以上もの検索リクエストが送られています。
検索機能のミドルウェアにはAWS OpenSearch Serviceを利用していますが、現行バージョンがEOLになる見込みがあり移行が避けられない状況でした。
移行にはアプリケーション側の修正も必要で、移行中にダウンタイムが発生するとサービス提供に影響が生じ、インシデントに繋がる可能性もあります。

本発表では、運用中のサービスを止めず・壊さず、段階的リリースやコードの移植を通じて実現したゼロダウンタイム移行の手法、移行を通じて浮上した移行しにくい設計、今後の設計改善についてお話します。

ターゲット

ミドルウェアのバージョンアップを実施・検討している方
ゼロダウンタイムでのリリース手法に興味がある方
既存設計の改善に興味がある方

概要

LaravelにはOctaneというLaravelアプリケーションを高速化するための拡張ライブラリが存在しており、
従来のPHP-FPMより大幅な性能向上を実現します。
本セッションではFrankenPHPのZTS（Zend Thread Safety）環境でのワーカープロセス管理、
octane:startコマンドの内部動作、Octane Tables/Cacheの実装制約などを紹介していきます。
またOctane導入前後でどれくらいのパフォーマンスの差が出てくるのかを検証します。

話すこと

ZTS環境でのワーカー管理とOctaneの連携実装
octane:frankenphpコマンドの内部動作
Octane Tables/CacheのFrankenPHP環境での実装と制約
Octaneの有無でのパフォーマンス差異

概要

従来のPHP環境でリアルタイム通知を実装する場合、Node.js等を組み合わせた複雑なインフラ構成は悩みの種でした。
FrankenPHPではこの課題を解決するためにMercureが内蔵されており、PHPスタック内でシンプルかつ高速なリアルタイム通信を実現しています。
本セッションでは、実際に動作するアプリケーションの動作デモを交えながら、以下の技術的なポイントを紹介します。

話すこと

• 従来構成での実現の難しさを再確認する
• FrankenPHPがリアルタイム通信を実現する流れの紹介
• WebSocketとServer-Sent Events(SSE) の技術概要と差異
• FrankenPHPを使ったリアルタイムWebアプリケーションの具体的な実装方法と実演

話さないこと

• Mercureの技術詳細

「このレガシーコードから、いつか抜け出したい」──そう願いながらも、触れれば壊れる恐怖と日々のタスクに追われ、巨大な技術的負債を前に動けずにいませんか？
本トークは、そんな絶望的な状況から抜け出すための、現実的かつ具体的な「脱出計画」を提案します。
鍵は、一度きりの大規模リファクタではなく、チームで実践する持続可能な「1日1改善」です。
新機能には必ずテストを書き未来のバグを防ぐ。バグ修正の際は「来た時よりも綺麗に」を合言葉に少しだけ改善する。静的解析をCIに組み込み品質の門番とする。未来の調査を楽にするログを戦略的に仕込む。
この小さな一歩の積み重ねが、やがてチームを、あなたを負債のスパイラルから解放します。
明日から始める「脱出計画」で、もうコードに怯えず、楽しく開発していきましょう！

「このレガシーコードから、いつか抜け出したい」──そう願いながらも、触れれば壊れる恐怖と日々のタスクに追われ、巨大な技術的負債を前に動けずにいませんか？
本トークは、そんな絶望的な状況から抜け出すための、現実的かつ具体的な「脱出計画」を提案します。
鍵は、一度きりの大規模リファクタではなく、チームで実践する持続可能な「1日1改善」です。
新機能には必ずテストを書き未来のバグを防ぐ。バグ修正の際は「来た時よりも綺麗に」を合言葉に少しだけ改善する。静的解析をCIに組み込み品質の門番とする。未来の調査を楽にするログを戦略的に仕込む。
この小さな一歩の積み重ねが、やがてチームを、あなたを負債のスパイラルから解放します。
明日から始める「脱出計画」で、もうコードに怯えず、楽しく開発していきましょう！

フレームワークを作るためのフレームワークと言われ、実際にLaravelでもコアとして利用されているSymfony。
そのため、初心者向けの導入説明や上級者向けの抽象概念獲得のための解説などの知見を聞く機会が多くあります。

一方で、実用としてのSymfonyの知見を聞く機会があまりありません。
同様にPHP5.4で導入されたtrait（特性）の実用としての知見を聞く機会もあまりありません。

そこで、この登壇ではSymfony6.3および7.2において本番実証済みのtrait（特性）活用例をお話します。

このトークで得られる知見

• Symfonyの特性に沿った特性(trait)の活用事例
• traitの使いどころ
• 省力かつ安定し安全な機能改編の実例

このトークで扱わない内容

• Symfonyの使い方

注意事項

• サンプルコードの公開は間に合いません。悪しからず。