皆さん、こんにちは。
PHPerKaigi 2024 コアスタッフのmuno92です。
PHPerKaigi 2024の開催がいよいよ今週末に迫っていますね。
この記事では、事前収録されたトーク動画を元に一足早くトークの感想をお届けします。
トークの事前収録とは
PHPerKaigi 2024ではトークの事前収録システムを採用しており、オンライン登壇の方は事前収録必須、現地にて登壇される方もトークの事前収録を推奨、としています。
（体調不良で当日登壇出来ない可能性などを考慮）
そして、収録されたトーク動画はコアスタッフによって確認が行われています。
録画チェックをいくつか進める内に「ちょうど3連休だし全部のトーク見るか」という気分になり他の人がチェックした分も含めて全てのトークを見たので、トークの紹介も兼ねて個人的な感想をつらつらとまとめてみました。
以下、注意事項です。
- この記事の対象となるトークは「事前収録が実施された && フル尺で録画できていた」トークのみです。
- この記事はPHPerKaigi 2024運営としての意見を伝えるものではありません。
- 【重要】 この記事はPHPerKaigi 2024のネタバレを含んでいます。新鮮な気持ちで当日発表を見たい方はタブを閉じる事をおすすめします。
・
・
・
・
・
・
・
・
・
・
・
・
はい、大丈夫ですね。
ではトークをORDER BY 発表開始時間, トラックで見ていきましょう。
day0 (3/7)
マイクロサービスがほしいと思ったときに本当に必要だったもの〜なぜ人は共通基盤の夢を見るのか〜
PHPerKaigi 2022でPHPerでもできる！マイクロサービスという発表をされた77webさんによる続編（？）です。
前回のおさらいとして発表における「マイクロサービス」の前提を揃えた上でマイクロサービスが欲しくなる理由を4つ挙げ、それぞれに対して「それはマイクロサービスじゃないといけないの？」とマイクロサービス以外で解決出来るものはその解決法を提示されていました。
詳しい内容は当日ご覧頂くとして、結論が刺さりました。
- 一番大事なのはアプリケーションを持続的に開発可能にすること
- 他の選択肢があることを知って比較・検討するのが大事（マイクロサービスに限らず）
（自分はどちらかというと「分散泥団子つらい」だけでマイクロサービスに否定的になっていたので）
PHP で読む楽しいコアダンプ
コアダンプ、「なんかクラッシュした時に吐かれるやつ」位のイメージだったので「よく分からんがすごいことやってる」と聞いていました。
発表ではそもそもコアダンプは、から始まりコアダンプが吐かれるケース、どうやればプロセスを殺さずにコアダンプを取得できるか（ここを説明する際の例えにはクスッときましたw）、と続き最後にPHPプロセスをコアダンプを使って解析する方法について解説されていました。
その中で
- Reli（sjiさん自作のプロファイラ）はPHPによるELFのパーサを持っている
- 元々（後でなんとなく融通が効きそうな気がしていたので）Reliのメモリ読み取り機能は抽象化してあった
- なのでコアダンプ用の実装をすることで生きているプロセスを解析するようにコアダンプを解析できた
- わりと大したことない変更でコアダンプが読めた
とサラッと述べられていたのがすごいなと思いました。
「大道芸みたいなツールでも適当に各所を抽象化しておくと後が楽」と仰っていましたが、そういった勘所を自分も磨いていきたいです。
day1 (3/8)
古くなってしまったPHPフレームワークとPHPのバージョンアップ戦略
PHP7.3 -> PHP8.1、FuelPHP1.8.2 -> FuelPHP1.9-develop (!)にバージョンアップした際に上手くいった戦略についての発表でした。
上手くいった戦略をプロジェクトマネジメント視点・技術視点でそれぞれ解説されていたのですが、特にプロジェクトマネジメント視点での
- 遅延リスク（不確実性の高い課題）の察知と対処が上手くいった
- （上手く言語化出来ないが）分からないこと・不明瞭なことがどこにあるのか常に目を光らせるが大事になるのではないか
がとても気になっています。
Laravel OpenAPIによる "辛くない" スキーマ駆動開発
とてもテンポが良く、発表を聞いていて面白かったです。
自分もOpenAPI自体は使っているものの、なんとなくドキュメント・APIのテスターとして使っているだけだったので、
- フロントエンド -> サーバーサイドの依存を仕様書を間に挟んで逆転させる
- 安定したインターフェース記述言語へ依存させて秩序を強制させ、品質を向上させる
という発想になるほど！となりました。
履歴データテーブルとの向き合い方
この発表は履歴データとの向き合い方ももちろん参考になったのですが、それ以上に「業務を知った結果より良い設計になった」という話がとても良いなと思いました。
（余談ですが、発表されているげんえいさんの背景にある本棚（バーチャル背景ではなくリアル本棚）の蔵書量がすごくて圧倒されましたw）
10年以上動いているレガシーなバッチシステムを Kubernetes（Amazon EKS） に移行する取り組み
Kubernetesちょっとしか触ったことがなかったので、実際にEKSでバッチを実行するとしたらこんな選択肢があるのか、と参考になりました。
あとは当初要件に合わなかったサービスがバージョンアップによって要件を満たすようになり、採用したことを受けて
と仰っていて、確かにそういう場合もあるかも、と思いました。
パフォーマンスを改善するには仕様変更が1番はやい
- 挙動を変えずに頑張ってパフォーマンスを改善しようとするだけでなく、挙動を変えてしまう手もあるよね
- ただ「はやく」するのではなく本質的に「はやく」できるといいよね
という発表。
挙動を変えずにパフォーマンスを改善した例を1つ挙げた後、いくつかの実例と共に「仕様を変えてパフォーマンスを改善する」方法を紹介されていました。
自分がこれまで関わってきたシステムを振り返って「確かにそういうやり方あるよね」というものもあれば「その発想は無かった」となるものもあり、自分が無意識に前提として考えていることなどを疑ってみるの大事だな、と実感しました。
CSRF対策のやり方、そろそろアップデートしませんか
従来のCSRF対策であるトークン方式に始まり、CookieのSameSite属性を使う方法やOriginヘッダーを使う方法、Sec-Fetch-*ヘッダーを使う方法、と新しいCSRF対策が紹介されており、最近のCSRF対策についていけていなかった自分の頭の中をアップデートする良い機会になりました。
そして、発表で伝えたかった事
がとても良いなと思いました。
「わたしたちのコード」を安定させるためにフレームワークとの距離を保つ
フレームワークは便利だけどそれに依存しすぎると困る場合もあるので距離を保つことも考えよう、という発表。
「所属されてる会社リンケージさんだしEloquentからDoctrineに切り替えたりしたのかな・・・」と考えながら聞いていたら見事にその疑問が回収されていて面白かったですw
フレームワークとの距離を保っていて良かった実例として挙げられていた
- 開発初期に画面を作り込まず、クラス単位で実行可能にしてコマンドラインで実行する形に出来た
- スピードを求められる初期の開発とのバランスが取れていた
は自分自身やったことがある方法だったので共感出来ました。
また、メール配信サービスの切り替えは「確かにそれは可能性として十分あり得そう・・・！」となりました。
どうやってWebサービスのページ表示速度を1/3にしたか
何故パフォーマンスチューニングが必要なのか、何からやったいいのか、Core Web Vitalsやプロファイルツールなど基本からまとまっているのが良いなと感じました。
発表中に仰っていた「わかんない時に頑張って推測してもあまり良い答えに辿り着かないので計測するの大事」は本当にそうだなと思います。
そして最後に触れられていた「定番の設定」はあるあるですねw
レガシーシステムへのPHPStan導入から半年での課題と効果
PHPカンファレンス関西2024（ぺちこん関西）でも発表されたいたPHPStan導入の話。
ぺちこん関西の参加ブログにも書きましたが、なんとなくPHPStanを導入したのではなくnullチェックに問題を抱えているからlevel:8で導入、と目的がはっきりしているのが良いですね。
また個人的な話にはなるのですが、ぺちこん関西の時はBaselineを使っている事を聞き逃していたので、もう1度発表を見れてよかったです。
day2 (3/9)
B+木入門：PHPで理解するデータベースインデックスの仕組み
これまでアルゴリズムやデータ構造をあまり意識せずに手癖でやってきたので「B木・B+木はすごいのか」位の理解度に留まっています・・・
- データ構造そのままにアルゴリズムだけで処理速度を改善するのは限界があるのでデータ構造を工夫する必要がある
- データ構造は向いているアルゴリズムがある
- データ構造に興味を持ったきっかけは、LeetCodeをやっていてアルゴリズムだけでは限界があった事
- ただデータをこねくりまわすのではなくどういった構造のデータに対してこねくり回すか考えないとだめ
という話が印象に残っています。
このままだと手癖でどうにかならない壁にぶち当たるか、壁を壁と思わず自分がやれる範囲内に留まってしまうか、になるような気がしているので基礎を身に着けなければ・・・
RubyVM を PHP で実装する〜Hello World を出力するまで〜
スタックマシンや命令セットという前提を抑えた上で、Rubyの実行環境（RubyVM）を実装する話。
スタックマシンについての説明が前半にあったので、なんとなく分かったような気になりながら話を聞けました。
企業主体で開発されていて仕様書が充実しているJVMに比べるとドキュメントの整備に限界があるRubyVMを実装するためにどうしたらいいか
-> Cで書かれたコードを読む
はphp-srcに潜っていく人々のように「やっぱりそこに行き着くのか」感がありました。
ファイル先頭の use の意味、説明できますか？ 〜PHP の namespace と autoloading の関係を正しく理解しよう〜
- useはエイリアス作成に使う演算子
use App\Models\Flight=use App\Models\Flight as Flightと同じ
- namespaceの説明
- useはエイリアス
- じゃあどうやって読み込んでいるの？
- Composerによるautoloading
- vendor/autoload.phpの読み込みを書いたこと無いよ？
- index.php
- 名前空間だけで対象のファイルをどうやって見つけているの？
- PSR-4
と順を追って説明しているのが分かりやすくて良かったです。
useがエイリアス作成の演算子というのは知らなかったのでなるほど、となりました。
（余談その2。おかしょいさんはバーチャル背景にPHPerKaigi 2024のサイトを使用されていたのですが、編集後に出来上がる動画に付くL字フレームがサイト上部の画像と同じ色味だったのでとてもマッチしてました）
phpunit/php-code-coverageって何をしてるんだ
カバレッジとは、から「じゃあphpunit/php-code-coverageはどうやってカバレッジを計測しているか」の話。
静的解析しかりこういう裏側の話は大好物なので、Xdebugで取得できるカバレッジ情報の配列ってこうなってるんだー、と楽しく聞いていました。
「ブランチやパスの分析にはOpCodeの情報が使われており、それについては別に資料を展開する予定」と聞いて「それ早く読みたい」と思っていたらブログを書き上げるのに時間が掛かっている間に公開されていました。
こちらの資料を事前に読んでおくとより楽しめること間違いなしです。
そして、
- 気になったことの仕組みを突っ込んで調べてみたら納得感があったし面白かった
- 身の回りの「実はよく知らないかも」に気づいてズブズブと足を踏み入れてみよう
という結びの言葉がとても良かったです。
はじめてのメンバー育成。マネージャーとメンバー視点で振り返る1年間
メンバー育成を「探り合い期」「あれもこれも期」「集中期」と分けてマネージャー/メンバーそれぞれの視点で振り返った話。
探り合い期の話で
- メンバー側の人がチャット上にもやもやを書けてはいたが、分かっていないことに気づいていなかった
- アウトプットだけ見るのではなくアウトプットに行き着くプロセスの考え方含めて理解するのが大事
と仰っていて、確かに、と思いました。
また、途中で「timesは大勢の人がいて分からないことを投稿するハードルが...」と仰っていて、自分のtimesに持っているイメージは逆（他のチャンネルに比べるとチャンネルに参加している人が少ない）だったので「そういう所もあるのかー」と新鮮な気持ちになりました。
PHP Parserで学ぶPHPと静的解析
過去に
- Psalmで"完全に理解した"静的解析 ( PHP Conference Japan 2022)
- PHP Parserで学ぶPHP (PHPerKaigi 2023)
- Rectorと目指す負債をためないシステム開発〜はじめの一歩〜 (PHPカンファレンス福岡2023)
と静的解析関連の発表をされてきたinocoさんによる、簡易的な依存可視化ツールの作成を通して静的解析・PHPを学んでみようという発表。
クラスの完全修飾名を取得するロジックを
- xxにはyyで出来る（シンプルに思いつく方法）
- こんな問題がありました
- それzzで出来ます / こういう風に実装を改善しました
と段階を追って説明されていたのが分かりやすかったです。
こういう風にPHP Parserを使えるのかー、と楽しく聞いていました。
（PHPについてもなるほど、となるポイントはあったのですがPHP Parserの方に目が行ってしまうのは好みゆえですね・・・）
privateメソッドのテストって書かない方がいいんだっけ？
PHPカンファレンス北海道2024で失敗例から学ぶSOLID原則の発表を聞いた時も思いましたが、
- privateメソッドのテストをガンガン書いていた
- それで困ったケースがあった
- どういったユニットテストが良いのか
というストーリー展開が上手いなあと感じました。
それと、privateメソッドのテスト（というかpublic/private問わずスタブを多用したりと開発の持続可能性にあまり寄与しないテスト）の良し悪しは置いといて
- privateメソッドのテストだと全体のつながりを期にしなくてテストが書きやすくなった
- privateメソッドのテストをガンガン書いた時期にテストコードの書き方が手に馴染んだ
というのは良い話だなと思いました。
テストコードは書けば書くほど書き慣れていく感覚があるのですが、逆に書かないでいるとずっとハードルが高いままになってしまうと思うので。
まとめ
以上、PHPerKaigi 2024の事前収録トークの感想でした。
通して見てみて、山岡さん・きんじょうさんのトークで伝えたいことが共通して「身近なものの仕組みに興味を持ってみよう」だったり、それ以外にも身近なツールなどの仕組みを深堀りした発表があったのが良かったなあと印象に残っています。
また、トークを全部見てみて、スタッフをしていると当日や会期後1週間のフィードバック期間では見れる発表に限りがあったりするので、意外と事前にトークを見てみるのアリだな、と思いました。
（本番までにブラッシュアップされる可能性や当日その場で発表を聞くことでしか得られないものを考えると事前収録さえ見ておけばOK、とは思いませんが）
ただ、今年は現地登壇の方向けには「必須」ではなく「推奨」としていたので去年の約半数の本数にはなっていたのですが、それでも全て見るにはある程度の時間が掛かりました。
それを考えると去年全部見ていたuzullaさんは本当にすごいです・・・
（開催されたとして）来年も全部見るかはその時の自分にどれくらい余裕があるか次第ですね・・・
という訳で事前収録トークの感想をお届けしましたが、PHPerKaigi 2024の開催はすぐそこです。
皆さん、楽しんでいきましょう！
