皆さんはDaemon（デーモン）をご存じですか？Daemonとは、バックグラウンドで実行され続けるプログラムのことです。ジョブキュー、バッチ処理、アプリケーションサーバー、クローラーといった役割を担うプログラムがその例です。

このトークでは、PHPを用いてDaemonプログラムを「飼いならし」、実用的に運用する方法についてお話します。具体的には、Daemonとはどのようなものなのか、その基本構造や必要な技術を解説します。PHPでのメインループの実装、シグナル処理、終了時のリソース解放といった基礎から、安定稼働を支えるスーパーバイザー（systemdやコンテナ）との連携、監視の仕組み、さらには並列処理やワーカーの協調についても取り上げる予定です。

もし、まだデーモンを「飼いならした」ことがない方は、Daemonという言葉だけで少し身構えるかもしれません。でも安心してください。初心者でもわかるシンプルなDaemonプログラムの構築方法から丁寧にお話しますので、召喚する楽しさ、支配するスリルと万能感を得られる要になると思います。

単純なウェブアプリや、Cronによるバッチで物足りないPHPerのあなたも（あるいはそうでないあなたも）、この機会にDaemonを造り、飼いならしてみませんか？

2年前、私は「Laravelへの異常な愛情」と題し、Laravelの基礎的な考え方と、そのレールがもたらす開発上の効果を紹介しました。Laravelをモデルに対するCRUDに特化したリソース志向フレームワークと捉え、コード量を削減しスタイルを統一する、これがLaravel Wayです。

しかし、現実のアプリケーションが、この枠組みの範囲に収まることはありません。

枠組みを超えた要件はプロジェクト固有の設計やルールで解決する必要があります。この試みは、成功することもありますが、それが「ほころび」となりコードベース全体の保守性を脅かすこともあります。これもまた、Laravelというフレームワークの特徴です。

逆に考えましょう。枠組みの外に出るのではなく、枠組み自体を拡張すれば良いのです。その手法を紹介します。

個別のテクニック

• 認証の拡張
  認証プロバイダを理解し、Eloquentに依存しない認証や外部の認証基盤との連携を実現する
• リクエスト処理の拡張
  Laravelの処理ライフサイクルを理解し、変則的な要件に対応する
• Eloquentの拡張
  データベースドライバを理解し、データベース固有機能を自在に利用する
• レスポンス処理の拡張
  Responsableを理解し、モダンフロントエンドへ対応する

拡張の考え方

• あらゆるものを拡張
  Laravelの内部設計を知り、拡張の考え方を理解する
• 再利用性と安定性
  パッケージ化による責務分離と、バージョンアップへの備え

題材として扱うOSS

• Laravel Doctrine ORM
• Laravel PostgreSQL Enhanced
• Laravel Debugbar
• Inertia.js
• Testbench

Web アプリケーションのセキュリティ設計において、特定のユーザーに対してどの操作を許可するかという認可の設計は欠かせない要素です。近年では、マイクロサービスやゼロトラストの考え方が普及し、サーバー間の認可を含むより複雑な機能が求められています。

このような複雑な認可を効果的に管理する方法の一つとして、認可ロジックをアプリケーションから分離し、外部化して再利用可能なポリシー言語で定義する手法があります。AWS IAM はこのようなポリシー言語の一例ですが、AWS に限定されない一般用途にも Open Policy Agent (OPA) が広く知られています。

本セッションでは、認可の課題に対する新たなキラーソリューションとして、Cedar を紹介します。Cedar は AWS によって開発されたポリシー言語で、Amazon Verified Permissions としてマネージドサービスが提供されているほか、AWS 以外の環境でも使用可能な OSS としても公開されています。

OPA と比較した Cedar の顕著な特徴は、大量のルールを定義した場合のパフォーマンスにあります。このパフォーマンスは、一度評価された条件を部分的にキャッシュし再利用する仕組みにより実現されており、そのキャッシュ戦略の正当性は数学的に厳密に証明されています。このように、Cedarは高度な理論が実際のプロダクトに価値を提供する興味深い事例といえるでしょう。

Cedar は 2024 年に論文が発表されたばかりであり、理論的な詳細に関する日本語情報はほとんど存在しません。そのため、本セッションでは参加者が認可エンジンの内部機構と特性を深く理解し、実際のアプリケーションのセキュリティ設計に役立てられることを目指して、Cedar に対して応用と理論の両面から Deep Dive します。

このセッションではPHPのマイクロサービスアーキテクチャにおける分散トランザクション管理の新たな方法として、
アクターモデルとPhluxorを使ったSagaパターンの実装を紹介します。

PHPによる分散処理を諦めた方は多いのではないでしょうか？
並行処理の理解やサーバについての知識、結果整合への理解や、
障害対応方法や復旧方法など分散システムになればなるほど難しくなり、PHP以外の知識が要求されます。
アクターモデルはそれらを強力にサポートしてくれる仕組みがたくさんあります。
そんな仕組みを活用したデータ整合性の維持やレジリエンス向上に役立つ例として、
在庫管理やショッピングカートなどをテーマに実践的なアプローチを実装コードを交えて解説します。
アクターモデルによるメッセージングや、アクターによる振る舞いの変更、
state管理やSupervisionの活用、アクターの永続化などを用いて詳しく解説します。
複雑なワークフローをシンプルにし、スケーラビリティとフォールトトレランスを向上させる具体的な手法を習得しましょう！

WindowsでPHPをビルドする場合、PHP 8.0からPHP 8.3まではVisual Studio 2019を使ってビルドしていましたが、PHP 8.4ではVisual Studio 2022の使用が推奨されるようになっています。このトークでは、Windows環境におけるPHPのビルド手順や最新情報に興味がある方を対象に、ビルドに必要な準備や実際の手順についてデモを交えて解説します。Windows版のPHPをビルドするにあたって知っておきたい情報やPHP 8.4における変更点もあわせて紹介する予定です。

インターフェイスという言葉は、さまざまな文脈で使用されます。具体的には以下のようなものがあります。

• プログラミング言語に備わっているInterface（オブジェクトインターフェイス）
• interface型
• Web API（のI）
• ユーザーインターフェイス（UI）
• コマンドラインインターフェイス（CLI）
• etc.

本セッションのスコープとなるインターフェイスは「その全て」です。

本セッションではソフトウェア開発において意識せざるを得ないインターフェイスというものについて考えてみます。
前述したようにひとことでインターフェイスといってもさまざまな種類があります。
それぞれのインターフェイスの特性を明らかにし、それらに共通する要素を探ります。この共通点を本セッションでは「インターフェイスという考え方」と呼ぶことにします。

本セッションではソフトウェア開発において強力な武器となるインターフェイスという考え方について、私なりに言語化して共有します。

例えばテストも、名前重要も、スキーマ駆動開発も、モジュラモノリスも、CQRSも、全てインターフェイスが意識されています。
インターフェイスという考え方は、空気のように当たり前に自然と活用されている一方、意識するだけで開発に新たな視点を得られるものだと感じています。

本セッションを通じて、参加者の皆さんがインターフェイスという考え方に改めて気づき、インターフェイスを意識することで、参加者が自身の開発プロセスに新たな視点を得ることができるようになることを目指します。

何らかの技術の理解を深めるのに最も適した方法は、その技術のサブセットを自分で実装することです。
PHP、ひいてはプログラミング言語というものを理解するために、PHP で PHP のサブセットを実装しましょう。
プログラミング言語処理系における「セルフホスト」とは、その処理系のソースコードをその処理系自身が処理できることを指します。つまり、今回作るPHP処理系の上でそのPHP処理系を動かすことを目指します。

話すこと

PHP で書く PHP 処理系（のサブセット）の作り方

• 字句解析
• 構文解析
• 実行 (今回の実装では AST を直接実行します)

必要なソースコードはすべて公開され、このトークを聞かれた方が同じものを作成できるように構成します。

話さないこと

実際の PHP 処理系 (php-src) の実装方法に近づけることは目指していません。説明のしやすさや実装の容易さを考慮し、適宜アプローチは変更します。PHP 処理系へのコントリビュート等を目標としたものではありません。

モジュラーモノリスは近年、マイクロサービスの代替として注目を集めています。このトークでは前半で設計の話を、後半で開発の話をします。

私が所属するBASE社では10年以上モノリシックなサービスでの開発が続いていましたが、デプロイ時間の増加や依存関係の複雑さにより機能提供のスピードに課題が出てきました。その課題を解決するためにモジュラーモノリスの新システムへの移行が始まって丸4年が経過しました。

本トークでは、モジュラーモノリスの基本的な設計概念から、その実現する方法論、また実践例について解説します。モジュールはコアドメインとサブドメインの考え方に基づいて区切られており、各モジュールの中ではアプリケーション層とドメイン層が分かれており、UnitOfWork での永続化管理やドメインイベントを用いた実装が可能になっています。

また、モジュラーモノリスを選択した際の利点とトレードオフについても議論します。具体的には、テストのしやすさ、デプロイの単純化、チーム間のコミュニケーションの向上など、エンジニアリング全体に与える影響を掘り下げます。メリットは多くありますが、それでも生じる課題についても触れていきます。

このトークを通じて、モジュラーモノリスというアーキテクチャの現実的な価値を理解し、チームやプロジェクトの規模に適したアプローチを選ぶための指針を得られれば幸いです。

概要

筆者は2024年9月にECサイト構築用のOSS開発者から、企業向けバックオフィスのSaas開発会社に転職しました。
両者ともにPHPをメインの開発言語として置いていたのですが、「開発へのアプローチの仕方」や「PHPであること」の
意味合いはかなり異なったものでした。

例えば、以下の例

• 可読性を重視するのか、パフォーマンスを重視するのか
• 開発スピードを重視するのか、品質担保を重視するのか
• セキュリティをコードで担保するのか、ミドルウェアに任せるのか
  等々・・・

ソフトウェア開発における「あるある」でもあり、この問題と対峙している人は多いのではないかと思います。
OSS開発とWeb系Saasという2つの視点から、PHP開発における価値のあり方についてお話します。
筆者が実際に直面した課題もできる範囲でお話します。

対象者

• 開発におけるQCDSで優先順位どうするか日々悩んでる人
• 2つの宗教に挟まれた時に「どこに着地点を持っていくか」で悩んでいる人
• OSS開発のノウハウとWeb系Saas開発のノウハウを単純に比べて聞きたい方

得られるもの

• PHPのWeb開発における一つの価値基準
• 立場が変われば同じPHPでも取り組む姿勢が変わるという視点
• ソースコードとインフラの役割分担の考え方

本セッションはPHPで計算機を自作します。環境構築からコード全体を解説します。

自分たちが使っているPHPのインタープリタとは何をしているのか、普段使っているPHPがいかに高度なことをしているのかを理解することが目的です。

本セッションは初中級者向けです。コードの記法などは解説致しません。計算機やプログラミングに興味があるが作り方が分からない方、PHPの内部実装の想像がつかない方を対象としています。

そのため、初心者でも理解しやすいように以下の工夫をします。

スタック型です
型をintegerとfloatに制限します
型キャストを使った明示的な型の管理を行います
逆ポーランド記法を使います
ユーザー定義関数を使いません

上記の特徴を持った言語を作ります。つまづきやすい、複数の型に対する演算の定義やASTを構築するタイプの言語における二項演算、ユーザー定義関数を意図的に避けています。

実装を解説し、ある程度計算機を理解したうえで、以下の話をします。

PHPがASTを構築し中間言語をVMで実行するタイプの言語であること、本セッションで実装した言語との違い。
通常の言語における二項演算の処理方法。式、文など。
ここまで作成した言語でHello,worldをする方法 (任意の要素を受け取れるprint文を作り、asciiとして解釈させる)

本セッションを通して視聴者は、計算機を構築するのに何が必要か理解し、自ら新しい計算機を作り出せるようになるでしょう！

php-fpm は PHPアプリケーション の実行環境として広く利用されていますが、その内部処理についてご存知でしょうか。

PHP プログラマから見ると、php-fpm はランタイムですが、php-fpm 自身は単に C 言語で実装されたアプリケーションにすぎません。これは我々が日頃から実装している PHP アプリケーションと領域や抽象度は異なりますが、一つのアプリケーションであるという点は同じです。

ただ、php-fpm ではより低いレイヤを扱っています。これは PHP アプリケーションレベルでは隠蔽されている処理が実装されているともいえます。普段、PHP コードを書くだけであればこうした底レイヤを意識する必要はありません。しかし、こうした下のレイヤがどのように動作しているのかを知ることはより深く PHP とそして自らが書いた PHP コードの挙動を理解することができます。そして、何より自分が書いたコードが内部でどのような仕組みで動いしているのかを知ることは楽しいものです！

本セッションでは、一歩レイヤを下りて、php-fpm がリクエスト受信から PHP アプリケーションを実行してレスポンスを返すまでの流れを内部実装やデバッガを元に追いかけてみましょう。

コンパイルの世界では、中間表現というアイディアが存在します。
ソースコードを任意のデータ形式（中間表現）に変えてから、コンピュータが理解できるデータ形式（機械語）へ変換するというアイディアです。
一気に機械語へ変換するよりも、無駄な計算を省いたり複数フォーマットへの変換処理を効率化するなど効率化の恩恵をもたらします。

PHP8.0でJITによる高速化が導入されましたが、8.4では中間表現のアイディアを採用することで、さらなる高速化を図る変更が行われました。
https://wiki.php.net/rfc/jit-ir
中間表現を実現するにあたって、新しいフレームワークIRを使ってJITを実現しています。
https://github.com/dstogov/ir
このフレームワークでは、一体どのようにして中間表現を実現しているのでしょうか？

本セッションでは、まずJITと中間表現の基本概念を説明し、その後、PHP 8.4で導入されたフレームワークIRの詳細を解説します。
JITフレームワークIRを解説していくなかで、PHP8.4に導入されたJITでの中間表現について理解を深めていきます。