トーク

今までVSCodeしか使ったことがなく新しいエディタに躊躇していましたが、新卒2年目の4月からPhpStormを使い始めました。
PhpStormくんと仲良くなるまでにやったこと、仲良くなって初めて知ったPhpStormくんのスゴいところをLTでお話します。

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

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

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

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

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

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

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

PHPerなら必ずと言っていいほどお世話になったことがある Composer ですが、自作したプログラムを Packagist に登録することは馴染みが薄い方も多いのではないでしょうか。
自作したプログラムを世界中のPHPerに配布する際、Packagist に登録するだけで Composer からインストールしてもらえるようになります。
ですが、せっかくインストールしてくれたユーザには、そのプログラムの内容をできるかぎり明確に伝えたいですよね。

本LTでは、自作したプログラムを Packagist に登録して世界中の PHPer に配布する際に気を付けたいことと、PackagistのWebの閲覧画面を確認する際に知っておくと良いポイントについてお話できればと思います。

■話すこと

・composer.json の書式に関する基礎知識
・Packagist への登録方法と閲覧画面で確認したいポイント
・親切な composer.json の書き方

■この発表をご覧いただくことで得られること

・composer.json の基礎知識
・Packagist への登録が想像より簡単だという実感

派手なSQLインジェクションは一般的なWebフレームワークを使用すれば基本的に発生しません。
しかし、LIKE検索を行う場合はDoS攻撃が成立してしまうことがあります。

LIKE "%a%b%c%d%e%e%f%g%@%.%"

上記のようなクエリはSQLエンジンに大きな負荷をかけます。
LIKE句のメタ文字はエスケープする必要がありますが、

$query->where('hoge', 'LIKE', '%' . $value . '%');

と直に書いてしまうケースは多いと思います。

LaravelでのこのLIKE句のインジェクション対策はおそらく３通りほどあると思うので、
それぞれのソリューションをご紹介していこうと思います。

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

PHP製の複数のサブシステムをもつWebサービスの開発運用の現場を、新卒2年目のWebアプリケーションエンジニアとSREが、2つの側面から紹介します。

1. Webアプリケーションレイヤにおける改善の取り組み
   新しい機能開発と並行してWebサービスのレガシーな部分を継続的に改善する取り組みについて、Webアプリケーションエンジニアの側面から紹介します。

2. カラーミーショップの改善におけるSRE活動について
   社内横断SRE組織が、カラーミーショップのエンジニアとともにWebサービスを改善するために行っている施策について紹介します。

Twitter:
やんまー: https://twitter.com/yammerjp
ほみるん: https://twitter.com/h0mirun_deux

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

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

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

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

PHPカンファレンスの初期の頃から続けている初心者向けのセッションです。

PHPとはどんな言語か
PHPの実行環境にはどんなものがあるか
スクラッチでのPHPの書き方の基本

このセッションをお聞きいただけると手元で簡単なPHPのコードを実行することが出来るようになります。

・対象となる方
このセッションでは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」の概念をベースに実装したフィーチャートグルの機能を使って、
そのアイデアに価値があるのかを素早く検証し、限りある時間の中で「早く安全に失敗し学ぶ」取り組みをしています。

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

こんな話をします。

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

話さないこと

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

フラットなPHPの書き方はわかった、では次はフレームワークへ…というとき、どんな基準でフレームワークを選んでいますか？なぜそのフレームワークを使ってアプリケーションを書くと良いのか、理解できていますか？堅牢でメンテナブルなアプリケーションを作るとき、なぜフラットなPHPでは難しいのでしょうか？
入門書や動画講座でPHPの基本文法を学んだあと、盲目的に次のステップとしてフレームワークを学習するのではなく、必要性を実感した上でフレームワークを学習してほしい、と私は常々考えています。
このトークではフラットなペラ1枚のPHPスクリプトから出発して、オブジェクト指向で自動テストのできるPHPアプリケーションへ、そして更にフレームワークを使ったアプリケーションになるまで、コードと考え方をお話しします。

◆含まれるもの

• PHPのオブジェクト指向の用語と書き方
• ありふれたスクリプトの中に埋め込まれた「仕事」の発見と整理の考え方
• PHPUnitを使った自動テストの基本
• Symfonyフレームワークを使ってHTTPリクエストを受け取ってHTTPレスポンスを返すまで

◆含まないもの

• データベース操作
• テーブル設計
• Laravelフレームワークの使い方

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

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

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

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

話すこと

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

話さないこと

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

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

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

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

サイボウズのGaroon（ガルーン）は今年で20周年を迎えるグループウェアです。
このセッションでは、20年にわたって開発が続いている巨大なレガシープロダクトのPHPバージョンを7.4から8.0にアップデートした際に得られた知見についてお話しします。

Garoonはさまざまな組織を支えるグループウェアであり、お客様の業務にまつわるデータをお預かりする性質上、セキュリティの確保が重要な課題です。
そのため毎年欠かさずにPHPのメジャー／マイナーアップデートを行い、常に最新のセキュリティ更新を取り込める状態を保っています。

しかしGaroonはPHP4系の時代から脈々と開発が続いているため、コードベースは巨大でありレガシーなコードが多分に含まれています。
さらにPHP本体にパッチを当てて自前でビルドしていることもあり、PHPのバージョンに対する依存度も高いです。
今年はPHP7.4からPHP8.0という影響の大きいアップデートを計画したため、約一年かけて準備を行なってきました。

その中で、比較演算子の問題をはじめとする、特に対処が困難であった以下のトピックについて詳しくお話しします。

• 厳密でない比較演算子の挙動変化を検出する仕組みの作成
• シリアライズされたデータに対する比較演算結果の保証
• 標準ライブラリ関数の見落としやすい変更点

結果的に、紆余曲折ありつつもPHP8.0へのアップデートが完了できました。
GaroonのPHPをアップデートするために具体的にどのように準備をおこなったのか、またその中で得られた知見を共有することで、
これからPHP8系へのアップデートを行う方々の助けになれたら幸いです。

本トークでは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の結合テストを自動作成したい人