日本でも大人気のウェブアプリケーションフレームワーク「Laravel」
ある程度のデータ量までは、割と速い速度で動いてくれる Laravel をあの手この手で低速化させてみようという試みです。どのようなコードが Laravel を低速化させるのかを学ぶことで、逆説的に Laravel の速度劣化を防ぐソースコードの考え方が身につきます。

このトークでお話すること

• ミドルウェアによって Laravel を遅くする方法
• インフラ環境によって Laravel を遅くする方法
• ソースコードの書き方によって Laravel を遅くする方法
• 遅くしないで妥当な書き方をした Laravel の処理スピード計測

B+木というデータ構造をご存知でしょうか？RDBMSでよく採用されているデータ構造で、ディスクの効率的な利用や、検索を行いやすいなどの特徴があります。しかし、耳学問で聞いてみてもイマイチ特徴がピンと来ないのです。

本トークでは、PHPでB+木のデータ構造を実装して、RDBMSでB+木が採用される理由、インデックスの構造的な仕組み、何故検索が速くなるのか？などなど、データベースの仕組みの根幹を覗いてみましょう。

このトークでお話すること

• B+木の特徴
• B+木は何故ディスクの利用効率が高いのか
• インデックスとは何か
• なぜ、データベースはB+木を採用しているのか

現在、正規化という手法はDB設計においてよく知られている手法となっています。

しかし、現場では以下のようなテーブルを見かけることは珍しくありません。
・1 つのカラムに複数の値が入ったテーブル
・カラム数が多いまたは、1 つの情報変更で更新処理が多く必要なテーブル
・JOINすると期待通りの結果が得られないテーブル

これらは低次の正規化により一定解決できます。もちろん闇雲に分割すればいい訳ではなく、
正規化の概念を正しく理解した上で分割を行う必要があります。

そこで本セッションでは、リレーショナルデータモデルが集合論に立脚していることから、数学的背景に着目して第１〜第２正規化について紹介します。
具体的には、RDBの用語(候補キー・関数従属性・情報無損失分解・正規形)を適宜厳密に解説しつつ
実際の正規化の例を通して、PHPer が向かうべきテーブル分割の手法を持ち帰っていただきます。

今回参加されている皆様は、普段のお仕事でPHPでWebアプリケーションを書いている方が多いと思います。
しかし、どのような仕組みでサーバ内でPHPが動作してブラウザに返却されているか正確にイメージできている方はいますでしょうか？
この仕組みについて、実際のコードを交えながら時間の許す限り解説をしていきたいと思います。

Laravel Dacapoという自作のOSSライブラリの話をします。
https://github.com/ucan-lab/laravel-dacapo

・開発初期段階のマイグレーションについて
・マイグレーションで困っていること
・ダカーポを導入するメリット
・簡単な使い方やコマンドのご紹介

皆さんお世話になっているPHP、そのソースコードを読んでみませんか？

プログラミング言語のソースコードを読むのはハードルが高いと思われがちですが、方法さえ知っていれば意外と読めたりデバッグできたり簡単な改変もできちゃったりします。

本トークではphp-srcを読む上で必要なC言語の知識から、php-srcのコードの構成、ビルド・デバッグの方法などphp-srcの読み方をご紹介します。プログラミング言語のソースコードを読むのは夢ではありません。PHPの深淵の入り口に招待いたします。

PHPからもC#のライブラリを呼べるようにした dotnet_ffi という PHP Extensionをつくりました。
C#側で処理することにより15倍ほど処理が高速化できたり、
UnityなどのC#で書かれるクライアントと処理を共通化したりといった用途を想定しているExtensionです。

このdotnet_ffiをどのように作ったのかを解説したいと思います。
現状例えば下記のようなトピックを考えています
・動機(なぜ作ろうと思ったか)
・Extensionを作るにあたって公式ドキュメントが不足しているのでPHPのソースを追った話
・CからC#を呼ぶCoreCLRの使い方とPHP Extensionへの応用の仕方
・ExtensionのPHP8対応のポイント
・できるだけPHPバージョンアップ時に修正が少なくなるようなExtensionの設計
・PHPのFFI機能との違い

dotnet_ffiソース
https://github.com/pg-ito/dotnet_ffi

概要

私が Symfony フレームワークを使っているとき、たまに目にしていた Serializer （シリアライザー）という言葉。これはフレームワークの一部でもあり、独立したライブラリでもある「Symfony Serializer Component」がその実体です。

Serializer が「PHP オブジェクトと JSON や CSV などの各種フォーマットとの相互変換をするもの」というのは、すぐに理解できるのですが、その使い方や応用方法については、ドキュメントを眺めてもパッと理解できるものではありませんでした。

それもそのはずで、公式ドキュメント [1] には「Serialization is a complex topic （シリアライゼーションは複雑なトピックです）」と書かれています。複雑な処理に関してのライブラリなので、理解にもちょっと手間がかかるというところでしょうか。

PHP での開発現場では、オブジェクトから JSON や CSV に変換したり、その逆を行なったりすることも多いと思います。そのような基本的、かつ、少し面倒な処理は、信頼のおける Serializer ライブラリ [2] に任せ、自分の時間はその他の重要なビジネスロジックの設計や実装に使いたいと思いませんか？

このトークでは、その複雑な内容を紐解き、Serializer Component についての理解を深めることにチャレンジしてみようと思います。

対象者

• PHP オブジェクトから JSON や CSV を出力する処理を書いたことがある開発者（フレームワークは問いません）
• 既に Serializer をマスターしている方も、発表者が間違った解釈をしていないかどうか、チェックしてくださると助かります 🙂

参考リンク

1. 公式ドキュメント
2. Serializer Component は多くのプロジェクトで採用されている

資料

• 発表スライド
• サンプルコード

みなさんは Feature Flag (Feature Toggle) についてご存知でしょうか？

コード中に Feature Flag の値による条件分岐を仕込んでおくと、その値を切り替えることで機能を有効化・無効化することができます。 Feature Flag を使うことで、機能リリースのタイミングの柔軟な制御や問題のある機能の迅速なロールバックを実現できます。

弊社では Feature Flag を使った開発・運用を1年以上続けてきました。その過程で、 Feature Flag を用いたコードのメンテナンスコストを下げるための工夫や、当初は想定していなかった方法による Feature Flag の活用を行ってきました。

このセッションでは、弊社の事例を中心に以下のようなテーマでお話しします。

• Laravel での Feature Flag の実装例
• 不要になった Feature Flag の条件分岐コードを機械的に削除する
• Feature Flag の値ごとのテストを作成する
• Feature Flag を使って機能のリリースを Slack へ通知する
• Feature Flag を使ってデータとコードの変更を同じタイミングで実行する

Psalm（サーム）はコードの問題を見つけてくれる静的解析ツール（PHPStan的なもの）です。

PHPでは、せっかく型を宣言しても実行してみるまでエラーに気づくことができません。
では、型を宣言することに意味はないのでしょうか？
そんなことはありません。
コードを実行しなくても静的解析がエラーを検出してくれるからです。

そんなPHPの開発に欠かせない静的解析ツールですが、どのような仕組みで動いているかご存知でしょうか？

先日Psalmにコントリビュートしたのですが、職場でEMになり手を動かす機会が減ったため、コードを書く機会を作りたいというのがそれを始めるモチベーションの一つでした。しかし、実際には仕様を理解するためにコードリーディングに多くの時間を使いました。せっかくなので、これからPsalmに触れてみたい人がコードを理解するのを助けるために私が費やした時間を捧げたいと思います。

誰向けのセッション？

• 静的解析の仕組みに興味がある方
• 静的解析のルールを作ってみたい方
• PHPStanやPhanは知っているが、Psalmって何かね？という方

本セッションの目指すところ

• 静的解析の一事例であるPsalmがどのようにコードを解析しているのか、その原理を少し理解して喜ぶ。
• これからPsalmにコントリビュートしたい方や拡張を作りたい方のハードルを下げる。
• PHPStanやPhanをメンテナンスする方がPsalmの仕組みを参考にできるかもしれません。

かつて自分がPHP MeCab Extensionを実装したときはC言語でバインディングを書くのが一般的な方法でした。
しかしPHP 7.4からはFFI (Foreign Function Interface) が導入され、C言語を書かなくてもC言語で書かれたライブラリが利用できるようになりました。
php_mecabをFFIを使って再実装する実例を元に、以下の解説をします。
・FFIの基本的な使い方
・メモリ管理
・FFIでできること
・FFIでできないこと

本トークではPHPを用いてソフトウェアシステムにおける大小さまざまな依存とその制御方法について解説します。

ソフトウェアシステムにおいて依存は重要な考え方です。
依存はさまざまな粒度で現れます。
比較的小さい単位であればオブジェクト単位で依存が発生します。
比較的大きい単位であればシステム単位で依存が存在します。

この依存を軽視するとさまざまな弊害が発生します。
たとえば、ビジネス的にクリティカルなモジュールがインフラ起因で大幅な改修を求められてしまう。
たとえば、インフラの乗り換えで大変な苦労をすることになる。
たとえば、あるチームに仕事が集中しすぎてしまい、待ち時間が発生する。
これらは依存が引き起こす弊害の一例です。

依存が弊害を引き起こすのであれば、依存を削減すればよいところですが、それは簡単な話ではありません。
なぜなら、依存は避けられるものではないからです。
ソフトウェアシステムを構築するうえでは、大小さまざまな形で依存が発生するものです。
避けようにも避けられない依存が随所で登場します。

依存が避けられないのであれば、私たちが取るべき手段は依存を御することです。

本トークではPHPプログラムを題材にプログラムレベルでの依存とその制御の仕方を解説し、それらをヒントに組織レベルの依存の制御方法についてお話します。

アジェンダ

• 依存とはなにか
• 依存関係逆転の原則
• 組織レベルの依存
• 組織の依存関係の制御

サービス開発するうえで、ユーザーや社内から様々のアイデアが寄せられます。
しかしいつだってそれを全て作る時間はありません。

「まず作ろう」と時間を割いてなんとかリリースしたが、「作ったけど使われない」、「なんか思ったのと違う」となり結果、技術的負債を生み出してしまうことに。。。
みなさん、このような経験をしたことは多かれ少なかれあると思います。

私が所属するROXXの back check ではフィーチャートグルの「Experiment Toggles」の概念をベースに実装したフィーチャートグルの機能を使って、
そのアイデアに価値があるのかを素早く検証し、限りある時間の中で「早く安全に失敗し学ぶ」取り組みをしています。

リリースや、運用にといったフィーチャーフラグの代表的な使い方以外の、「価値の検証」を目的としたフィーチャートグルのお話をします。

こんな話をします。

• なぜフィーチャートグルを使うのか
• フィーチャートグルを実装するうえで気をつけていること
• フィーチャートグルを使ううえでの調整の話
• メリット、デメリット

話さないこと

• 使っているサービスの説明・使い方

みなさんは「初めて見るコードの仕様を爆速で理解したい！」と思うときはありませんか？
例えばプロジェクトに初参画したときや、使用しているOSSライブラリの調査をするときなど・・・

そんな時には既存のテストコードを活用すると便利です。
見通しの良いテストコードやテストケース管理は、テスト対象となるコードの仕様理解を手助けします。

今回のセッションでは、PHPUnitの実装コードや公式ドキュメントサイトを一切見ずに、
PHPUnit内で書かれているテストコードを読みながらPHPUnitの仕様を理解していきます。

当セッションはこんな方におすすめです！
・自分以外の人が実装したテストコードをあまり読まない人
・PHPUnitのコードを読んだことがない人

～ オフショア先のコード品質向上は難しい ～

オフショアの場合、遠隔地であることだけでなく言語や文化、環境が違うため、お互いに意図を理解できているかや共通の認識を持てているかどうかが怪しくなってしまいます。
特に、コード品質向上のために行ったコードレビューのフィードバックについては、

・正しく内容を理解してもらえているか
・フィードバック内容を次回のコーディングに活かしてもらえるか

など、オフショア先との意思疎通が障壁となって、改善が行えない場合が多くあります。

そこで、私のチームではコードレビュー時に「再利用可能な」情報を提供することで、サービス全体のコード品質向上に取り組んでいます。
このセッションでは、

・どのようにしてオフショア先のコード品質向上に取り組めばいいのか
・オフショア先のモチベーションを保ちながらどのように改善を行っていくのか

などを、PHPのコードを紹介しながらお話しします。

※ このトークはリモート登壇になります

みなさんはWeb Assembly はご存知でしょうか？
ブラウザで利用するケースはもちろんのこと、最近ではサーバーレスアプリケーションで活用できるようになってきました。

このトークではPHPとWeb Assemblyに関連するエコシステムの紹介と可能ならデモも紹介します。

trait は当初 2008 年に PHP の言語開発者コミュニティへ提案され、長い議論期間を経て 2012 年リリースの PHP 5.4 で導入された機能です。
それから 10 年がたち、trait は「ちょっと試しに使ってみよう」というものから、各開発現場において使われる中で少しずつその立場を変えてきました。

さて、実際どのように変わったのでしょうか？

先日、今年に出る PHP 8.2 へ向けて言語機能追加の RFC を提出しました。PHP の trait で定数を定義できるようにするというものです。
静かな議論期間を経ての RFC の投票開始後、PHP の開発者向けメーリングリストから最初に得られたのは驚くべきリアクションで、要約すると次のようになります。

「trait は言語にとってまったく不要なものであり、使われるべきでないものを改善すべきではない」

続々と RFC に No の票を投じる人が現れ、一時は Yes が 3 票に No が 10 票というような圧倒的劣勢の局面を迎えます。

さて、なぜこのようなことになったのでしょうか？
何がこの 10 年で trait をこうも徹底的に嫌われる言語機能としてしまったのでしょうか？

このトークでは PHP によってプログラム部品を構成する言語機能としての trait に焦点をあて、来歴とその性質、適切な使いどころと、他の言語機能とくらべての弱点を紹介します。そして trait 定数の RFC が結局どのような顛末を迎えたのかを踏まえて、trait の将来の可能性について検討します。

なおトークの本題は言語機能としての trait の性質についてで、trait 定数の RFC 自体については「なぜこの話を今するのか」の舞台設定として早口で触れるくらいとする予定です。

※ ちなみに trait 定数の RFC の投票結果が出るのは PHP カンファレンス 2022 のトーク募集締切から 3 日後で、このトーク概要を書いている時点ではまだ確定していません

『ウマ娘 プリティーダービー』は、2021年2月24日にサービスを開始しました。
空前の大ヒットと呼ばれ、想定を上回る大きな反響がありましたが、サーバーダウンなく無事にローンチすることができました。

事前に行った負荷試験の約10倍という想定を遥かに上回るアクセスをさばくことができたのは、アプリケーションのボトルネックとなりやすいデータベースに対する処理の最適化を進めたためです。
トランザクションをできるだけ短くする、という考えを念頭におき、N+1クエリの改善、排他制御の方式変更、MySQL 5.7における降順ソートクエリに対応したインデックス作成、といった対策を行いました。

本セッションでは、それらの対策について「『ウマ娘 プリティーダービー』のローンチを支えたサーバーアプリケーションの最適化ノウハウ」と題してお話します。

API Platformは、SymfonyをベースとするPHP製のオープンソースAPIフレームワークです。
Symfonyアプリケーションにアトリビュート（アノテーション）を1行追加するだけで一瞬でREST APIを生成できてしまう優れもので、Symfonyのエコシステムにおいてはすでに決定版と言える存在となっています。

このトークでは、API Platformの導入方法から、Data Provider・カスタムコントローラ・Data Persisterといった重要な基本機能の概要までを、実際に動作するデモをお見せしながら一通りご紹介できればと思います。
皆さんにAPI Platformの概要を知っていただき、少しでも興味を持っていただければ幸いです！

PHPでPDFファイルを作る、楽しいセッションです！

このトークでは、以下の内容が含まれる予定ですが、時間の都合で一部省略したり変更したり順番を入れ替えたりする可能性もございます。
・PDFのファイルフォーマットの簡単な解説
・ライブラリを使わずに生のPHPで、簡単なPDFファイルを出力してみる話
・可変長の項目（見積書や請求書の明細行が増えていく様子をご想像下さい）と改ページの話
・文字列の折り返し処理の話
・PDFファイルを作成するための主要なライブラリの機能比較