PHP 8.5で導入されるパイプ演算子（|>）、楽しみですね！

パイプ演算子を使うと、
strtoupper('hello')
と
'hello' |> strtoupper(...)
が同じ意味になります。

実は、例にあげた2つの式は、opcodeとしても同一です。

このトークでは、php-srcのソースコードを読み解きながら、パイプ演算子がどのように実装されているかを見ていきます。

具体的には以下の内容を扱います

• vldでのopcodeの比較
• opcodeのコンパイルに使われるzend_astとznode
• パイプ演算子を処理するzend_compile_pipe

PHPの新機能を通じてphp-srcに入門してみましょう

現代のPHPフレームワークでは、Dependency Injection(DI)が標準機能として組み込まれ、その有用性は広く認知されています。
しかし、既存の動いているアプリケーションへ適用するにはどうすれば良いでしょうか？

本トークでは、実運用されているレガシーアプリケーションや、Ray Di for Laravel など、複数のDI適用事例を基に、実践的な戦略を共有します。
フレームワークとユーザーコードの境界線、既存のライフサイクルに配慮した依存性注入の活用、マーカーパターンによるルートオブジェクトの識別など、既存アプリケーション特有の課題と、その解決策を具体的なコード例と共に紹介します。

本トークを通じて、既存アプリケーションにDIを導入する際に考慮すべきポイントを持ち帰っていただき、明日から実践できる知見を提供します。

皆さんは機能を作成する際に、何から始めますか。

私は情報設計に取り組むチームに所属しており、日々情報設計と向き合っています。
情報設計とは、Web に限らず情報の整理が必要なあらゆる場面で活用できる普遍的な設計の考え方で、受け手が望んだ情報を適切に与える方法を作ることです。

先日、私たちは概念オブジェクト（ユーザーがイメージする「写真」や「メール」のような対象物）を発見し、Slack ワークフローを作成するワークショップを主催しました。

ワークショップでは「なに が なに を どうする」という構文から概念オブジェクトを発見しました。発見された概念オブジェクトは開発者以外にも伝わる共通言語となりました。

本トークでは、ワークショップでおこなった誰にでも分かりやすい概念オブジェクトの発見の方法から、PHP のコードがどのように現れるかを考察しどのような恩恵が得られるのかをお話します。

プログラミングにおける "関数" は 数学の写像とは同じではないものの、一部似た性質を持っています。
数学における写像は集合と密接に関係しており、それらは関数と型に対応します。

集合なしには写像は定義できず、プログラミングでも型なくして関数は定義できないと言っても過言ではありません。
しかし、PHPのような型の宣言を省略できる言語では、型の理解というのは往々にして後回しになることがあります。

本発表ではプログラミングにおける型や関数を、集合と写像によるメンタルモデルで捉える方法について解説し、 PHPのための設計に落とし込む方法を説明します。

お話したいこと

• 数学における素朴集合論と写像
• 写像とプログラミングの関数の違い
• 集合を使ったモデリングと型のメンタルモデル
• PHPアプリケーションの設計への落とし込みと他言語との比較

お話ししないこと

• 圏論

本講演は2016年から続けている「PHPで堅牢なコードを書く」シリーズの最新版です。

PHPはバージョンを追う毎に機能が強化され、堅牢なコードを書くための機能が充実してきました。本講演ではPHP 8.4（および 8.5）をベースにして、誤りを想定してチェックするのではなく、そもそも誤りにくい設計とはどのようなものか、つまり「予防」の観点を軸足に、堅牢なコードを導くための様々な設計のヒントをご紹介します。

参考:
PHP7で堅牢なコードを書く - 例外処理、表明プログラミング、契約による設計
https://speakerdeck.com/twada/php-conference-2016

予防に勝る防御なし - 堅牢なコードを導く様々な設計のヒント
https://speakerdeck.com/twada/growing-reliable-code-phperkaigi-2022

私は京都のスタートアップで働くエンジニアです。

スタートアップでは、売上拡大のために新規顧客獲得が重要になりますが、既存の業務フローがある顧客にはそのままでは導入できないことも少なくありません。

個別のカスタマイズ要望は、プロダクト開発のヒントとなりうる反面、その後の開発に影響を与える要因にもなります。

このトークでは、以下のテーマを主に扱います。

標準機能にするのか個別の機能にするのか
個別機能開発をする際にどのように作るのか
リファクタリングをいつ行うか
このトークを通じて、プロダクトの今と将来を両立するための考え方の一例を提案したいと思います。

私はdeckというMarkdownファイルからGoogle Slidesのプレゼンテーションを生成するツールを開発しています。
https://github.com/k1LoW/deck

Markdownからプレゼンテーションを生成もしくは実施するツールは既に数多くあります。
一見単純な機能ですが、後発のdeckは明確なコンセプトを持って開発をしています。

• 継続的なプレゼンテーション作成
• コンテンツとデザインの分離

なぜこのコンセプトに至ったのか、そしてそれをどのように設計・実装したのか。
本セッションでは、ゼロからv1リリースまでのdeckの設計と実装の変遷を追体験できるように構成します。
単なる一つのOSSの例ですが、小さなプロダクトが多くの人に受け入れられるようになるまでの設計と実装のログです。
皆さんが自身のプロダクト開発に役立つ気づきを得るきっかけになれば幸いです。

GitHubには多くの便利な機能があると知りつつも、 「結局どれを使えばいいのか分からない」 「CI/CDやAI活用をどう始めればいいか迷っている」 と感じている方は多いのではないでしょうか。
開発のスピードと品質を高めるActions、Codespaces、Copilotなどの機能は、単体で使うだけでなく、DevOpsの実践やチーム開発の改善にもつながります。

本セッションでは、GitHubを使っている・これから活用したい開発者を対象に、私が実践しているGitHubの活用方法を30分で紹介します。
10月にはGitHubの年次カンファレンスである「GitHub Universe」に参加予定ですので、カンファレンスの様子も交えてお話しする予定です。

設計について話をすると、実に多くの「◯◯概念」「◯◯原則」が付いて回ります
あるいは、「良い設計を考えよう」とか「設計を学ぼう」とかして、多様な知識が必要で大変だ！と感じた事はありませんか？

全く逆のアプローチで
「たった1つの軸を決め、多くのことを説明できないか」と考えてみましょう
その拘りは、あなたの設計の地力の向上に繋がるはずです

今回は、その回答に 「フィードバック」に注目する という提案をします

フィードバックとは、何かを伝え、その反応を受信することであり、
関係性に意味をもたらすものとも言えます

この「フィードバック」という眼鏡を通じ、システムを覗き込むと？
──設計について多くを語る武器になり得ます
ソフトウェアにとどまらない、組織についても使える武器です
分割、配置、バランス、そこから生まれる相互影響について、
よりシンプルに思考し尽くせるようになるでしょう

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

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

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

話すこと

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

話さないこと

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

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

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

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

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

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

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

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

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

話すこと

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

話さないこと

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

概要

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の技術詳細

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

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

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

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

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

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

• Symfonyの使い方

注意事項

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

AI 全盛の時代、開発を楽しみながらも、より広い視野を持ちたいと考えている方も多いのではないでしょうか。ディープな技術に没頭するのが好きな方がいる一方で、最近ではプロダクト開発や経営的な課題に関心を持つエンジニアも増えてきたように感じます。

とはいえ、経営層ではない一介のプログラマーが、経営課題やプロダクト戦略の本質に触れる機会はそう多くありません。実際、エンジニアリングマネージャーやテックリードといった役職に昇進して初めて、その重要性に気づくという人も少なくないでしょう。私自身も、まさにそうでした。

そこで本セッションでは、スタートアップから上場企業まで CTO を務めた経験をもとに、なぜプロダクト開発を行うのか、プログラマーは経営とどう向き合うべきかといったテーマについて、エンジニアの視点に立ってわかりやすくお話しします。

今や AI 全盛の時代。コーディングの多くを Coding Agent に任せることが一般的になってきました。私自身も、簡単なタスクであれば積極的に AI に頼っています。

しかし、AI も万能ではありません。指示が曖昧であれば、同じファイルに処理を詰め込みすぎてしまったり、結果としてコードの可読性やアプリケーションのパフォーマンスに悪影響を及ぼすこともあります。そのまま開発を進めてしまえば、後からの保守や拡張も難しくなってしまうことでしょう。

AI 時代の今こそ改めて「プログラミングの基礎」や「PHP の基礎」を理解することが重要です。本セッションでは、その土台となる知識を整理し、AI と協調して開発するための実践的な視点をお伝えします。

OpenAI の API は、関数呼び出し機能である「Function Calling」をサポートしており、LLM に外部関数を呼び出させることで、より柔軟で実用的なインターフェースを構築できます。近年では、単なる Q&A を超えて、ユーザーと対話しながら外部サービスの操作やデータ取得を行う AI エージェント（いわゆる Copilot 型）の実装が活発になっています。

本セッションでは、PHP を使って OpenAI の Function Calling を活用し、AI から関数を安全かつ動的に呼び出すことで、どのようにインタラクティブなアプリケーションを構築できるのかを掘り下げていきます。

車輪の再発明は楽しいもので、それが普段よく使っているツールなら尚のこと輝きます
ライブコーディング━━それもまた、楽しいですよね

という訳で、 30分一本勝負、Composerをその場で作るぞ とチャレンジします
「内側はどんな仕組みになっているの？」「あの機能はどう動いているの？」を一緒に体験しましょう

やること

Composerの仕組みについての簡単な解説(実況)を交えつつ、ゼロから書いてきます
ただし、時間枠に収めるために、対応する機能やシチュエーションは限定するものとし、複雑なアルゴリズムの実装は割愛(他の簡素な実装で代替)します

• ゴール
  • require コマンドによる、新規パッケージの複数追加とその依存解決。ソースの展開・配置
• やらないこと
  • 依存解決の計算量最適化の実装
  • 正規のモノと互換性があるlockファイルの生成