トーク

One of the reasons that PHP Developers give for not doing TDD (Test-Driven Development) is that it takes a lot of time to learn. This is a fair reason: doing TDD with PHPUnit can be quite difficult, and doing things like mocking / using doubles can get very complex if you are using a Web Application Framework such as Symfony or Laravel.

Enter PEST: a new Open Source testing framework with its own code style. Built by one of the Laravel core team, it takes much of its structure from the Jest JavaScript testing framework. Its focus is on human-readable, simple yet powerful code to make testing a delight.

In this session, we'll learn:

• How PEST is structured
• How to write tests for common scenarios
• How to use PEST on your existing code

Mercari JPでは、全社的にマイクロサービスアーキテクチャへの移行、関連するサービスの Kubernetes化に取り組んでおり、新しいサービスは Golangでの開発、Kubernetes環境で運用しています。

一方で創業期から存在するモノリスサービスはPHPでオンプレミス環境で運用されていたため、言語の違い、環境の違いにより、学習コスト、メンテナンスコストに問題があり、Kubernetes移行に取り組んでいました。

2022年6月に完了したMercari JP のモノリスサービスのKubernetes移行を以下の視点で紹介したいと思います。
・どうやっておこなったか
・どんな困難があったか
・PHPならではでの問題にどう対応したか
・そして、今後どうなっていくか

古くはフルスタックエンジニアと呼ばれた人たちは、物理サーバーへのOS/各種ミドルウェアのインストールからネットワーク設定をし、さらにその上で動くアプリケーションを開発してきました。幾年が経ち、我々の前にはクラウドインフラが立ちはだかります。物理的な経験があるエンジニアにとっては、良くも悪くも抽象化されたインフラをどうにか乗りこなしているようです。
翻って、業界に入ったときからクラウドがある世代の PHPer にとっては、インフラは無限に知ることがある領域になってしまっているように感じます。
アプリケーションを構築するようにインフラをコードで表現できる AWS CDK を使って、インフラをより身近に感じて貰えるような話をしたいと思います。
※ AWS CDK なので AWS のみです
※ TypeScript で書くので PHP は登場しません
※ ベストプラクティスの話はしません、あくまで入門です

※ こちらのトークはオンライン登壇になります

本年、Chatworkはリリースから11周年を迎えました。Chatworkで使われているプログラミング言語といえば、Scalaのイメージが強いかもしれません。
しかし、サーバーサイドのコードをPHPで実装されて以来、PHPコードは今でも現役でChatworkを支え続けています。

Chatworkではcommit毎に約6000ファイルのテストケースを実行しています。しかし、型エラーなどが発生していたとしてもテストでカバーしきれないところは、最悪の場合そのまま本番環境へリリースされてしまうという問題がありました。
それによって過去実際にユーザー影響のある障害が発生してしまったこともあり、Chatworkを安定稼働させ続ける上でも大きな問題点でした。

上記のような課題感から、PHPアプリケーションのCIに静的解析ツール(PHPStan)を導入し、コード品質の向上に役立てています。

本セッションでは、歴史の長いPHPで実装されたプロダクトコードにPHPStanを導入するにあたり、「導入に当たっての障害」「開発チームにスムーズに受け入れられるために取り組んだ事」「導入して得られたメリット」などに焦点を当てて紹介したいと思います。

WebアプリケーションでUIをリッチにしていくには欠かせない、JavaScript。
しかし、バックエンドを作りながらフロントの動きを作っていくのは意外と骨が折れます。

なるべくJavaScriptを書かずにUIをリッチに作っていくためにSymfonyには『Symfony UX』があります。
生まれて約1.5年のSymfony UXですが、大幅に改善・進化しました。
そんなSymfony UXの魅力や使い方について紹介していきたいと思います。

話すこと

• Symfony UXとStimulus
• Symfony UXの各コンポーネント
• 実際の使い方

話さないこと

• Symfonyの基本的な使い方
• オートワイヤリングの詳しい説明

PHP で書いたコードをいち早く世に送り出すために、 AWS では昨年から次々と新しいサービスをリリースしています。その中から、フルマネージドのコンテナ実行基盤 AWS App Runner と、自動でデータベースがスケールできる Amazon Aurora Serverless v2 をご紹介します。

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

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

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

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

こんな話をします。

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

話さないこと

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

TiDBはスケールアウト可能なMySQLプロトコル互換データベースです。負荷やデータ量に応じて、柔軟なスケールアウトが可能となっています。
さらに、マネージドサービスなTiDB Cloudをご利用いただくことで、サーバーインフラの管理を行わず、データベースをご利用いただくことができます。

本トークではTiDBの優れたアーキテクチャと、TiDB CloudとPHPでのWebアプリケーションの組み合わせについてご紹介します。

弊社の運営しているサービスに、フィーチャートグルを導入して約１年が経過しました。
15年以上の歴史を持つこのサービスは、テストも無く、独自フレームワークで書かれたレガシーコードとなっています。そのため１年前までは、一つの機能追加に大きく時間を費やしてしまっていました。
そこに導入されたフィーチャートグルは、必要最低限の質素な実装でしたが、リリースまでの時間は大幅に減少させ、開発速度を大きく向上させました。
そこから１年経過した今、脱レガシーに向かう新しいコードに合わせて、フィーチャートグル自体の実装も少しずつ変更を加えてきました。

本トークでは、レガシーコードにフィーチャートグルを導入して得た効果や、導入から現在に至るまでの実装をご紹介します。

話すこと

• 弊社サービスにおけるフィーチャートグルを導入した効果
• フィーチャートグルの導入〜現在に至るまでの実装
• 導入後にテストを可能にするための改善

話さないこと

• 自分が経験していない事（他社の導入事例など）
• ライブラリの紹介

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

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

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

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

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

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

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

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

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

アジェンダ

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

スキーマ駆動開発してますか？

一応OpenAPI(Swagger)書いてるけど、実装と乖離して放置されてませか？

レスポンスクラスなどをきれいに書こうとしたものの、データクラスが増えて面倒になっていませんか？

これまで2年以上開発してきた経験から、スキーマ駆動開発の勘所をご紹介します。

正しくOpenAPIを書いて、OpenAPI GeneratorやPostmanを使いこなせば、リクエスト&レスポンスのデータクラスやAPIクライアント、テストコードが自動生成できます。

本トークでは最大限OpenAPIを使い倒して、楽に効率化することを目指します。もちろんスキーマと実装の乖離は絶対におきず、複雑な設定ファイルは必要ありません。

PHPを前提に話しますが、多くの部分は他の言語で応用可能です。結合テストの実行で少しDI（Dependency Injection）が出てきますが、DIの考え方など基礎的な内容に触れません。

■話すこと
・スキーマ駆動開発とはなにか
・スキーマ駆動開発のメリットとデメリット
・OpenAPIとは
・OpenAPI GeneratorでAPIクライアントの自動生成
・スキーマと実装をずれないようにする
・Postman（Newman）で結合テストの自動生成
・DIで副作用を防ぐ

■話さないこと
・OpenAPIの詳しい書き方
・DIの考え方
・DIのライブラリについて
・npmについて

■想定対象者
・スキーマ駆動開発をやってみたい人
・スキーマ駆動開発をしているが、実装がスキーマとズレて困っている人
・APIの結合テストを自動作成したい人

何度も遭遇する PHP の「Allowed memory size of ...」。しかし、結局解決方法がわからず、最後には「ini_set('memory_limit', -1)」でその場を凌ぐという苦い経験をした方も多いのではないでしょうか。
PHP ではガベージコレクションもそれなりに発達しており、メモリを気にしないで書けるから良いと思っている人も少なからずいらっしゃると思います。
しかし、裏を返すと、メモリについてあまり考える機会がないとも言えます。PHP7.4 から弱参照といった機能も入り、メモリ管理に少しずつ関心が寄せられてきているのではないかなと思います。
そこで本トークでは、PHP でどのようにすれば省エネにメモリを使えるか、書き方のヒントまで含めてお話できればと思います。

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

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

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

概要

私が 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 は多くのプロジェクトで採用されている

資料

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

テスト書いてますか？
テストを書く理由と実際のテストコードを紹介する実践編に分け、TDD を3年間実践してきた経験に基づいてお話しします。

テストを書いたことのない方が、テストを書いてみたいと思ってもらえることを目指します。
サンプルコードは PHP + PHPUnit ですが、他言語でも通用する考え方を紹介します。

■ 概要
・なぜテストコードを書くのか
・レガシーコードとは、テストのないコード
・テストはコストが安いフィードバックループである

■ 実践編
・テストケースは日本語で書こう
・いろんな assertion を知ろう
・arrange / act / assertion のテストコード実装パターン
・set up / tear down を使って前処理/後処理をする
・dataProvider でテストをまとめる（ただし早すぎる抽象化に気をつけよう）

私はこの数ヶ月、趣味プロジェクトとして1980年代に栄華を誇った名作CPUであるZ80のハードウェアエミュレータを開発しています。
これはZ80で動作しているハードウェアからZ80を取り外して、代わりに自作のZ80ハードウェアエミュレータを取り付けて動作させるというもので、Raspberry Pi に自作のハードウェアを接続した形になっています。

PHP Conference Japan 2019で "「CPUとは何か」を PHPで考える" というタイトルで「プログラム実行環境としてのCPU」「エミュレート対象としてのCPU」「電気回路としてのCPU」という3つの立場から「CPUとは何か」について解説しました。
このトークではその続編として、Z80のハードウェアエミュレータの設計と実装を通してハードウェアエミュレータから見るとCPUはどう見えるかをお話します。

このトークを通じて、CPUに興味を持ち、CPUについて語る仲間が増えることを期待しています！

HTTPとPHPは切っても切れ離せない関係があります。

PHPもその周辺のミドルウェアもHTTPを正しく理解することで、さらにその力を発揮する事が出来ます。

そんなHTTPに関するRFCが2022年6月に新たに公開されました。

HTTPは実際にどのようなメッセージを送信、受信していてそのメッセージにはどのような意味が込められているのか、
PHPerにとって知っておくべきHTTP仕様をこのタイミングでRFC911*から振り返ってみましょう。

• 想定する聴講者
  • HTTP仕様について興味がある方
  • HTTP Messageの中身、やり取りについて知りたい方
  • HTTP header による挙動変化について知りたい方

年に1度(数年に一度？)巡ってくるPHPのバージョンアップという大仕事。

今回PHPのバージョンを8系にバージョンアップするための作業を実施したのですが、そのためにはまず依存ライブラリのバージョンアップと向き合う必要がありました。

小さくコツコツ手をつけておけばよかった・・・そんな気持ちと戦いながらもバージョンアップをなんとか完了させました。

1つ1つ丁寧に目の前の課題・問題点を洗い出し、対処していけば必ずバージョンアップを完遂できると思いますが、本トークではPHPバージョンアップのための依存ライブラリ更新とどのように付き合いながらPHPのバージョンアップしたか、PHPのバージョンアップ後の依存ライブラリ管理についてお伝えさせていただければと思っております。

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