PHPerKaigi 2022に参加していろいろわからないことがあったので調べたりして

PHP 日記

今年は4/9(土)夜～11(月)という楽しい日程だった。土曜日は前夜祭で夜からとはいえ、1日目・2日目は割と朝から晩までずっとセッションが続くパワフルな展開で、見てるだけなのになかなか大変だった。実際仕事の日よりつかれた。

そのせいで普段なら全時間帯どれかのセッションを見るところ、今回は所々休憩入れつつ見た。のであまりツイートもしてないと思ったのだが、それでもツイート数二位とのことで景品をいただいたり。

Discordもいいけど、みんなもっとツイートしよう。

さて本題、見たセッションの簡単な感想と、わからなくて調べたこと

今年はツイートも(自分の気分的には)だいぶ少なく、後から振り返ってもどういう感想を抱いたか忘れてたりもするので、感想はいつもよりさらに簡単めに、で、セッション聞いててわからなくて調べたことなんかがあるところでは、それを書いていくスタイルにしてみる。

見たセッションぜんぶではないです。

Datadog APM で始める Laravel アプリケーションのパフォーマンスチューニング

スライドはこちら

LaravelでEloquentのアクセサ内でリレーションからデータ引いてクエリ実行しちゃったりするとN+1問題起きやすかったりするけど、開発中に気付けなかったときにどうするか、そこでDatadog APMでアプリケーションパフォーマンス監視です、みたいな話。

Datadog APMの紹介に終わらずそれを使ってどういうフローで対応していくか、みたいなところも抑えられていてよかった。

なおこんなことを呟いていたが、よく考えると俺もアクセサでリレーションにアクセスしてたわ。とはいえ、hasXxx()的なのをアクセサにはしない。そこはメソッドじゃないと。

ちなみに今確認してて気付いたんだけど、Laravelのアクセサ、9からメソッド名ベースじゃなくなってたし、protectedで書く形になってた。まあpublicの意味がないのは元々だけど。

Eloquent：ミューテタ／キャスト 9.x Laravel

予防に勝る防御なし - 堅牢なコードを導く様々な設計のヒント

スライドはこちらから

わざわざ語るまでもないいい話なんだが一点だけ気になってて、findAll()はDateTimeRangeを直接使うんじゃなくて、開始・終了のどちらがinclusiveでexclusiveかを持った派生型を作ってそれを受け取る形の方がぜったいわかりやすいと思うんだがどうだろう。

PHPとGraphQL

スライドはこちら

興味はあるけどなかなか使う機会がなくてよくわからないGraphQLの話。俺はそんなのばっかり。今まで特にピンと来なかったのは、サーバサイドでどうするかなんだけど、このセッションではそっちの視点からの説明もあってとても「わかった」感じになった。

サーバサイドは、REST APIでやるよりちょっと面倒そう。そこをショートカットできるあれこれもあるみたいだけど、銀の弾丸がある感じではなさそうなので、やっぱりトレードオフなのかなと。どういう場合にGraphQLにメリットが大きいか、みたいなところの話もあって、いい話だった。

また、この話に出てきた"Relay"というのがわからなかったので調べたが、これはクライアントサイドのGraphQLライブラリらしい。Apolloはよく聞くけど、同じ系統のもののようだ。こんなこと呟いてたけどアーキテクチャ関係なさそう。

BASE大規模リアーキテクチャリング　モジュラモノリスを中心に据えた中長期的なアーキテクチャ戦略について

スライドはこちらから

話にも勢いがあったいい話だった。感想書くほど詳しくないので割愛。スライド内によさげな本がいくつも出てきて、こういうのは好き。とりあえず「LeanとDevOpsの科学」が気になる。

【視聴者参加型】PHP この記号はなんでしょう？【高速 LT クイズ】

スライドはこちらから

感想というかなんというか。後半のネタ問題を除いた5問中、2問しか解けなかった……。PHPバージョンと累乗はさすがにわかったんだけど、ほかは。もうちょっと時間かければ行けたと思うんだけど。

CakePHP Fixture Factories の登場によって変化する、PHPプロジェクトにおけるテストフィクスチャ管理の選択肢

スライドはこちらから

2日目はもう頭が回ってなかった。このセッションは、前半はテストのフィクスチャの概要の話、後半はCakePHP用のLaravelのファクトリみたいなのの話だったんだけど、前半でいろいろ混乱してしまった。

Fresh FixtureとShared Fixtureというパターンがあるようなのだが、いまいち後者のイメージが湧かない。その前に話に出ていたInline Setup, Delegated Setup, Implicit Setupがそれぞれテストメソッド内で直接必要なクラスのコンストラクタを呼び出すことで、専用の作成メソッド経由で呼び出すことで、setUp()から暗黙的に呼び出すことで、いずれにしても「直接クラスのコンストラクタを叩いてフィクスチャを作成する」もので、それらのようなパターンがFresh Fixtureだというところをしっかり把握できていればもうちょっと理解できたと思うが、リアルタイムではできなかった。

Shared Fixtureというのは、こちらの元ネタページを読んでみればなんということはない、Fresh Fixtureがテストごとに別々のインスタンスを使うことに対して、Shared Fixtureはテストで同じインスタンスを共有する、というパターンのようだ。

Shared Fixture at XUnitPatterns.com

ということで、以下のツイートは完全な誤解であった。

カオナビでのチーム開発の舞台裏

スライドはこちらから

よいセッションだったのだがそれはともかくとして、本題とは別のところがやたら気になってしまった。チーム7、8人で1年かかる「機能」を実装する際のチーム開発の課題の話だったんだけど、その規模の「機能」ってなんなんだ、と思ってしまって。

7、8人年って、テーブル100超えみたいな規模のシステムが一からできる規模だと思うんで、大規模サービスとはいえ一つの機能でそのレベルってどういう感じなんだろう、みたいなところばかり気になった。

テストコードの DRY と DAMP

スライドはこちらから

テストコードではコードの重複に対して、プロダクションコードとは違う見方も必要だよ的な話で、とてもいいトークでした。

すごい個人的な感想(ほかもそう)で、最近関連するようなことを考えていたので。というのも、テストコードでプロダクションコードと同等のコードでフィクスチャを作成していて、それがバグっていたためにテストあったのにバグが防げない、みたいなことがあって。

そこは単純にDAMPで、変にDRYにせずに静的に書けばまあよかったんだけど、単純にそれだけじゃなくて、たとえばコードレビューするときに人が同じようなコードの共通化していたとき、どう説明して指摘すればいいかな、みたいなことをちょっといろいろ考えてて、とはいえ答えも出てないのでこの話はここまで。

来年

そろそろツイートだけじゃなくしっかり参加したいので、次はスピーカーで参加したいところ。

去年は一応セッション応募(本名名義で)はしてたんだけど落ちて、今年は応募すらできなかった。来年は応募して、受かって話すのを目標に。