TBD

php-src。それはPHP言語のソースコードのことです。
そのため全て読むのは大変です。
php-srcを読む際、適当なtest.phpを作り、ast\parse_codeを利用しながら気になる挙動の構造を確認したり、気になるfunctionにブレークポイントを仕込んでdebugしていくこととなるでしょう。

しかし、debug環境を整えようとすると、一筋縄ではいかないことが多々あります。少なくとも経験の浅い僕にとっては簡単ではありませんでした。
MacやWindowsなど、デバッグを試す環境の違いにより色々な知見を得ながら環境整備しなければなりません。
それだけの労力を割きながら、いざphp-srcのmake testをしてFailだらけになると気が滅入ってしまうものです。

そこで、Dockerを利用してphp-srcのためのsandbox環境を整えました（発表当日にはgithub上でpublicリポジトリとして公開します）。
本セッションでは、そんなsandbox環境とVSCodeを連携方法や、それらを用いたfunctionへのアプローチ（debug）方法をお伝えいたします。

もうphp-srcの環境構築に迷うことはありません。
素敵なphp-srcリーディングライフを送りましょう！

対象者： php-srcを読んでみたい方/読もうとしたけど環境構築で挫折した方

私たちが古くなったPHPアプリケーションをRuby on Railsに移植することを決断したのが2016年―。
私たちが移植対象としたPHPは下記のようなものです。

• とっくにEOLなPHPバージョン
• オレオレ・独自フレームワーク
• 標準サポート終了しているAmazon Linux AMIなEC2サーバー
• PEAR/PECLなライブラリ管理
• 自動化されていないテスト・デプロイ
• 仕様ドキュメントほぼ無し（ソースコードが仕様書）
• 担当プロダクトオーナー不在

過去に本PHPアプリケーションの移植プロジェクトは断続的に立ち上がっていたものの、それらは局所的な移植として終わってきました。
2022年、この戦いに終止符を打とうと本格的な移植プロジェクトが再始動、ついに2023年、移植を完遂しました。

本プロジェクトは正直、カッコいい移植プロジェクトとは言い難いものです。
そんな泥臭く長い移植の軌跡を、技術的負債解消の一事例としてお話できればと思います。

想定聴講者

• 技術的負債の解消に興味がある方
• 現在進行系で技術的負債と闘っている開発者

話すこと

• なぜ移植するか
• どのように移植を進めたか
• 移植前後の改善結果
• 移植後も山積する課題と今後の展望

話さないこと

• ナウい技術的負債の解消方法
• 移植後のシステムの技術的詳細

このトークでは、10年以上にわたり運用されているサービスにおけるPHPフレームワークの進化(FuelPHP 1.8.2からFuelPHP 1.9-devへの移行)とPHPのバージョンアップ(PHP 7.3からPHP 8.1へのアップデート)の戦略について語ります。

プロジェクトマネジメントと技術の観点から、ソフトウェアのバージョンアップを成功させるための「プロジェクトをリードする上での力学」や「バージョンアップにおいて有用だった技術的アプローチ」について具体的にお話します。

FuelPHPを使っている方はもちろん、それ以外のPHPフレームワークを使っている方も対象に、PHPフレームワークとPHPのバージョンアップの知見を共有します。
様々なトレードオフやハードルを乗り越えるために、どのように計画し、アプローチしたかをお話します。

皆さん普段どのようにPHP実行環境を組んでますか？私はなんだかんだLAMP推しです。もうCDNが前段にいればええやろ。

さておき、PHPはモジュラ式に拡張できるしインタプリタ(諸説あります)だし、php.iniは山ほどあるし、httpdは別途に必要だしで実は非常に複雑です。
つまりメンドウ。なので多くの人がパッケージマネージャでいれてると思います。

よって、気になる人は「なんかPHPの環境構築は{所定のブログ記事}のコピペでやってるな〜秘伝のタレだな〜」みたいな感じと思います、どうですか？
(まあ私もremiったりondrejつかったりもしますのでそれは間違いではありません)

しかし「PHP環境のビルド」は色々出来るんです。今回は真心を込めて「カリっとしたPHPをつくる」そういう遊びをしてみませんか？

• 超ニッチなオタク話です
• ミドルウェアや*nixやLinuxの話になります
• 仕事には多分役立ちませんが、「なんでBrewのPHPが壊れるのか？」みたいなことはわかるかも
• もしかすると、「コンテナサイズを超小さくする派」とかには刺さるかも？(php方面にいるのか？)
• もはや廃れた(？？？) INSTALL.mdとかにある configure と make all と友達になれるかも

Webアプリケーションには多くの「良い」とされるデザインが存在します。
例えば、インターフェースである画面やAPI、その実装であるアーキテクチャのデザインなど。
そして、持つ機能が発展していくにつれて適切なデザインも変わります。
では、CLIツールはどうでしょうか？
手元での実行が主だったり、Webアプリケーションと比べて複雑なビジネスロジックを持つことも少ないです。主なターゲットは開発者です。
だからと言ってデザインを疎かにして良いわけではありません。
発表者は多くのCLIツールを開発、メンテナンスをしています（ https://github.com/k1LoW ）。
機能も想定実行ケースも様々です。また、Webアプリケーションほどではありませんが、5年を超える開発をしているものもあります。
本発表ではその経験を元に、CLIツールの開発をする上で考える様々なデザインを紹介します。

スキーマ駆動開発は非常に強力な開発手法です。

• API仕様とサーバ実装が確実に一致し、クライアントライブラリは自動生成されます。
• フロントエンドは型システムの力により、「サーバ」を意識せずに開発が可能です。
• 「APIの繋ぎ込み」タスクや結合テスト時の問題切り分けが不要になります。

なるほど、完璧な作戦っスね―――ッ
不可能だという点に目をつぶればよぉ～

スキーマ駆動開発はしばしば「辛い」と言われます。

• スキーマと実装とをそれぞれ書かなければいけません。
• 開発中の変更がフロントエンドのCIを予期せず壊すことがあります。
• 破壊的変更を避けるために類似のエンドポイントが乱立しがちです。
• 実際には、仕様と実装が常に一致しているとは限りません。

これらの課題をLaravelおよびLaravel OpenAPIを使用して解決します。

• ライブラリの機能を活用し、スキーマと実装との二重化を解消します。
• 仕様と実装との不一致を自動的に検出します。
• フロントエンドのCIを壊さないスキーマの運用を行います。
• そもそもスキーマ駆動開発とは何かを解説します。

これまでOpenAPIやスキーマ駆動開発に苦労したことのある方はもちろん、これから導入を検討している方々にとって有益な内容です。

人類が増えすぎたPHPを品質保障(Quality Assurance)するようになって既に20年が過ぎていた…
開発環境の周りの巨大なContinuous IntegrationはPHPerの第二の故郷となり、人々はそこでプロダクトを生み、育て、そして死んでいった。

西暦2023、静的解析が開発環境に取り入れられるようになり、いくつかの現場ではめざましい成果を挙げたが、別の現場では疎まれ、また別の現場では開発プロセスに投入できないまま散っていった。

このトークでは、私の考える静的解析導入時のバッドプラクティスをお伝えします。

• 何のために型をつけるの？
• コードの型付け、どこから手をつける？
• 「えっ、せっかくならlevel:maxにしないと意味なくない？」
• 汝、 @var を憎め
• あなたのユニオン型の使いかたは間違っている

例外はただのトラブルシューターじゃありません。コード内の誰が何を担当するのかを教えてくれる、責務の指針なんです。

『PHPの例外、多すぎてどれ使えばいいかわかんない！』『例外、いつキャッチすればいいの？』『エラー情報、どこに吐き出すのが正解？』こんな疑問を持ったことはありませんか？

PHPの組み込み例外クラスの選び方から、自分で独自例外を定義するノウハウまで、コードをもっと読みやすく、管理しやすくするための実践的なアプローチについて考察してみます。

例外をマスターして、エラーハンドリングをもっとスマートに。

みなさんのアプリケーションには履歴データはありますか？
履歴データは大量に増えたり、必要なデータへのアクセスにすぐにアクセスしたかったり、履歴なのに改変できたりといろいろな要望を言われることがあると思います。
履歴データの取り扱いをする上で考慮しないといけないことを話します。

サイボウズのGaroon開発チームでは「完成度低いの歓迎LT大会」を不定期に開催しています。
このLT大会の目的は、登壇のハードルを下げることです。
https://note.com/sakay_y/n/n4ffd91ad8a09

昨年のPHPerKaigiでは、スポンサーセッションとアンカンファレンスで「完成度低いの歓迎LT大会」出張版を開催しました。
https://fortee.jp/phperkaigi-2023/proposal/b3cf069f-e7bb-44e5-97cc-4f2def2a6aa6
https://twitter.com/tomio2480/status/1639136756238008325

昨年は「完成度が高い」という指摘を多数いただいてしまったので、今年こそ「完成度が低い」状態でもどんどん登壇する姿勢を見せていきたいと思います。

Chatwork ではリリースから10年以上経った現在も機能の大部分はPHPで実装されています

PHPのアプリケーションの大部分は Amazon EKS 上で運用されていますが、現在も100以上のバッチの処理が Amazon EC2 で運用されています

そして Amazon EKS と Amazon EC2 の 2重運用となっていることから PHP のバージョンアップや環境変数周り、インフラ管理等が負担となっていました

これを解決するために Amazon EC2 で動いているバッチを Amazon EKSへ移す取り組みを始めています

本セッションでは Amazon EC2で動いているレガシーな PHP アプリケーションを、どのように Amazon EKS へ移行しているのか？ 実際に移行するにあたってどのような問題が発生したのか、今後どのように進めていくのか？の事例を紹介したいと思っています

「WebAssembly」という技術が、さまざまな領域で耳目を集めています。
WebAssembly を実行する仮想機械 (VM; virtual machine) を PHP で作成し、その動作原理や注目が集まる理由について話します。
WebAssembly だけでなく、PHP などの任意の言語の処理系についても、そのおおまかな内部構造を知るきっかけになればと思います。

話すこと

• WebAssembly とは
• VM とは
• 作ってみる
• WebAssembly に注目が集まるわけ
• WebAssembly を拡張する提案 (WASI、WASIX など)
• 作った VM の上で WebAssembly にコンパイルされた PHP 処理系を動かす

対象者

• WebAssembly について知ってはいるが、技術的な詳細や使用シーンについて知らない方
• プログラミング言語の処理系の構成を知りたい、作ってみたい方

なんとなく口にしがちな「"品質"が高いコード」。

定義があいまいで要領を得ないため、すり合わせはおろか万人が万人の「願望する"品質"」の話に終始してきました。

一方で「品質」は工業規格としての定義があります。

このトークでは工業規格の定める「品質」に基づいて、「"品質"が高いコード」の定め方と達成の仕方についてお話します。

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

1. "品質"の定義
2. "高品質"の達成の仕方
3. ユニットテストにおける"「どこまでやるか？」の割り出し方"
4. "品質"を高めるためのテストとは

このトークで話さない事

1. 品質工学

2023年9月、初めてPHPで Hello World しました。

私はいわゆるサーバーアーキテクチャを勉強するのが好きです。これまでにプリフォークサーバー、マルチスレッドサーバー、イベントループサーバー、グリーンスレッドの最小構成を自作したことがあり、ブログにまとめたこともあります。（ https://blog.ojisan.io/server-architecture-2023/ ）

そんな私が PHP の勉強として docker-compose + MySQL + PHP で簡単な掲示板サーバーを作り、それをクラウド上にコンテナでデプロイしようとしました。しかしこれはとても難しかったです。Laravelアプリケーションをコンテナデプロイするためにはアプリケーションサーバー(PHP)とウェブサーバー(Nginx, Apache)に分離して開発、場合によってはそれらを FastCGI で繋ぐことに驚きました。当初私はアプリケーションサーバーだけを配置、もしくは前段にCDNを置くだけといった構成を想定していたためです。正直なところ PHP サーバーのコンテナデプロイを納得するためには低レイヤーでの理解が求められると感じました。そこでこのトークではPHPサーバーとコンテナデプロイでお世話になる低レイヤー技術（主に並行プログラミング）や新鋭のライブラリや環境についておさらいします。

PHP8が2020年11月26日に登場してから、日々進化し続けているPHP。
つい最近はPHP8.3の登場もあり、以前の言語とは比べない程に型システムの改善や、パフォーマンス向上されてきました。
一部機能を取り上げれると以下の改善があります。

• JITコンパイラの利用
• Union Types, Mixed Type
• 属性(Attributes)の使用
• エラーハンドリングの改善
• Constructor Property Promotion

筆者も普段はPHP8で業務のコードを書いて、その恩恵を受けています。
このプロポーザルでは、PHP8の沢山ある機能の中でも実際の業務を通じて、学んだ事のアウトプットとしてPHP8で堅牢にコード書くTipsについて紹介します。

パフォーマンス改善と聞くとどんなことを想像するでしょうか？
大半の人はクエリチューニングであったり、ロジック改善であったり、キャッシュ化であったり
元の仕様を変えずに速度向上をする、というイメージがあるかと思います。
ISUCONなどはまさにこれで、元のテスト（ベンチマークツール）が通るように改善を行っていきます。

しかし現場で10年ほど開発経験を積んできた私の持論としましては
「あれ？これちょっと仕様変えるだけで劇的にパフォーマンス良くなるのに、元の仕様を変えない理由ってなんだっけ？変えれば良くない？」
という結論に至りました。
もちろんケースバイケースで絶対仕様が変えられない状況下でパフォーマンス改善していく、ということはあると思います。
しかしもし仕様から変えて良いものであれば、それは仕様再検討から実施することで圧倒的なパフォーマンス改善を実現できると私は考えています。

本セッションでは

• パフォーマンス改善の勘所
• 実際に行った「仕様変更を伴うパフォーマンス改善」

このあたりをお話できればと思っております。

PHPの世界では、CSRF対策としてセッションを利用したトークンを用いた方式が採られることが多いのではないでしょうか。
例えばLaravelの場合、「@csrf」とBladeのテンプレートファイルに記述して、Middlewareを用いれば簡単にトークンベースのCSRF対策が可能です。

しかし待ってください、例えばNext.jsにCSRF対策の機能はあるでしょうか。SvelteKitには？
実は、最近出てきたWebアプリケーションフレームワークでは、CSRF対策を標榜するような機能は入っていません。

本トークでは、SameSite Cookieを用いたCSRF対策について解説すると同時に、CSRF対策について改めて考察します。
当たり前だと思っていた、今までのCSRF対策を見直すきっかけになってくれたらうれしいです。

2024年に行われた/行われるPHP系カンファレンスの実行委員長ズをお招きしていろいろお話を伺います。

「わたしたちのコード（＝ドメインロジック）」は安定していますか？？

フレームワークを利用している場合にコードの境界がハッキリしていないと、強くフレームワークに依存することにもなりかねません。

フレームワークには便利な機能がたくさんあります。
たとえばLaravelには、Eloquent、Facede、サービスコンテナ、認証、ミドルウェア、Blade、artisanコマンドなどがあり、それらの機能を活用することで、スピード感のある開発ができるでしょう。

しかし依存のしすぎはビジネスの変化への対応による作り直しや機能のバージョンアップの際に思わぬ量のコード修正になってしまうことがあります。

わたしのチームでは主にInterfaceを利用して「わたしたちのコード（＝ドメインロジック）」をフレームワークから独立させ、安定させることを心がけており、その方法をご紹介できればと思っています。