PHPカンファレンス2023に参加しました
はじめに
2023年10月8日にPHPカンファレンスが開催されました。
私も現地参加させていただきましたので、レポートを書いてみます。
持ち物
- PC
- 飲み物
- スマートフォン
PCを持っていくかどうかは結構悩みましたが、結果的には持っていって良かったと思います。
個人的には、PCの方が講演のメモを取りやすかったためです。
あと、PCでメモを取っておけば資料のリンクなども同時に管理できるし、後からこうしてブログなどにまとめる際にもスムーズに書けます。
全体の感想
参加してよかったです！
意識の高い方々と一緒の空間にいるだけでスキルアップできている感覚がありました。
講演もいろいろなバリエーションがあり、どれに参加するか目移りしてしまうほどでした。
PHPはどんどん使いやすくていい言語になっていると思いますし、PHP界隈がさらに盛り上がってくれると嬉しいですね。
残念だった点
基本的には大満足だったPHPカンファレンスですが、残念だった点もいくつかありました。
残念だった点1. Wi-Fiがつながらなかった
会場内にWi-Fiがあるのでつなげられます！という案内があったのですが、全くといっていいほどつながりませんでした。
参加者が多かったためにパンクしたのかもしれません。
仕方ないので、自分のスマートフォンでテザリングしてネットに接続していました。
残念だった点2. カメラのシャッター音がうるさかった
講演中、スタッフの方が写真撮影を行うのですが、そのシャッター音がうるさくて集中が途切れることが多々ありました。
講演を聞く側としては、シャッター音はオフにしてもらえるとありがたいです。
（最近のカメラであれば設定で簡単にオフにできるはずです）
聞いた講演
ここからは、私が参加させていただいた講演についての情報と、勉強になった点などをまとめていきます。
9:50 PHPの今とこれから
廣川 類氏
資料: https://www.slideshare.net/hirokawa/php2023
PHPはボランティアベースで開発している。
PHPバージョン7系が多い。6割強。
WordPressはもっと7系が多い。
7.4はすでにEOLを迎えている。
PHP8 JITについて
キャッシュ、JITを入れるとアルゴリズム系の処理は速くなる。
8.3の変更点
クラス変数の型を指定できるようになった。
クラス定数の動的参照ができるようになった。定数名に変数を指定できるようになった。
これまではPDOオブジェクトのメソッドを直接実行していた。
今後はラッパーを通すようになる。
PHP.iniの環境変数のデフォルト値を設定できるようになった。
（これまでは、未設定の場合はブランクになってしまっていた）
readonly属性を使えるようになった（8.0から）。
8.3ではcloneにも対応するようになった。
これまではreadonlyのディープコピーをしようとするとエラーになっていた。
JSON関連
json_validate()関数が追加された。
これまではjson_decode()関数を使っていた。
上記関数はデコードが主目的なので、あまり適切ではなかった。
ランダマイズ関連
ランダマイザクラスの機能強化。
ランダムな文字列を作る際に、例えば特定の文字列の比率を多くすることができる。
数字も、〇〇以上か以下かを指定できるようになった。
mb_str_pad()関数
文字列を特定の桁数に埋める関数。
これまではstr_pad()を使っていたが日本語のようなマルチバイト文字列を使う場合は想定通りになっていなかった。
埋める文字がシングルバイトの場合も、マルチバイトの場合も同じように想定とは違う動きとなった。
PHPの今後の動き
PHP8.4は今年の11月にリリースされるはず。
PHP9はPHPの実行エンジンに改良が加わると予想される。
新JITは、中間コードを生成するようになる。
今は中間コードなし。
AIによってコードを書かなくて済むようになるかも？
10:50 型安全なSQLテンプレートエンジンを構築する
資料: https://tadsan.fanbox.cc/posts/6821011
うさみけんた氏
セキュリティをしっかりとするのは受注者（開発側）の責任。
SQLインジェクションは開発者の債務である。
SQLインジェクションを防ぐ
whereのIN句の型を指定できる。
現在はMySQLのみ対応だが、PostgreSQLをサポートしたい。
実際にターミナルの画面を映して挙動を見せてくれたのが楽しかったし勉強になった。
PDOを使う際は型を意識しないと意図せぬ挙動になるので気をつけようと思った。
11:20 readonly class で作る堅牢なアプリケーション
河瀬翔吾氏
資料: https://speakerdeck.com/shogogg/readonly-class-tezuo-rujian-lao-naahurikesiyon
- readonly classとは？
- なぜreadonly classを使うのか？
- readonly classを使う際の辛さ
readonly classとは？
readonly classでは、全てのプロパティがreadonlyとなる。
イミュータブルにできる。インスタンス生成後に値を変更しようとするとエラーとなる。
readonlyプロパティ自体は8.1で導入された。
なぜreadonly classを使うのか？
イミュータブルではないインスタンスでは、どこかで値が変わっている可能性がある。
Carbonクラスはインスタンスの値が変わる。
Carbon Immutableが推奨されている。
コードをイミュータブルにすることで安心して開発ができる。
ただし、全てのアプリに導入すべきというわけではない。
単純で人数も少ないチームでは導入しなくてもいいかも。
複雑な開発においては導入するメリットは多いにある。
介護現場のシステムは非常に複雑。
ただでさえビジネスロジックが複雑なので、イミュータブルに保ちたい。
readonly classを使う際の辛さ
Eloquentなどからオブジェクトへ変換するのが面倒。
例えばLaravelでは、一度DBから取得したオブジェクトをもとにして新たにイミュータブルなオブジェクトを作成する、といった処理が必要。
キャッシュと相性がわるい。
解決先1: フレームワークの機能を使う
解決策2: キャッシュ専用のクラスを作る
12:40 良いテストとは何か:持続可能で保守性の高いテストを書く
当田 昇氏
テストの質が悪いと、テストが壊れやすかったり時間がかかったりする。
単体テストの考え方/使い方 p.96
良いテスト＝価値の高いテスト
価値＝機能÷コスト
テストの価値は、コードの正しさを判定するためだけでなく、フィードバックループの構築＆ドキュメンテーションである。
フィードバックループ
より早い段階でバグに気づく方が開発効率が上がる。
ドキュメンテーション
ドキュメントとしてのテストは信頼性が高い。
他のドキュメントはコードと紐づいていない。
実装コスト + 保守コスト + 運用コスト
テストコードは、プロダクションコードよりも基本的に多くなる。
良いテストを書くには？
正確なフィードバックがあることが大事。
偽陽性・偽陰性がない状態が望ましい。
ホワイトボックスよりブラックボックステストが望ましい。
質問: 具体的にどういうテストがホワイトボックス？どういうテストがブラックボックステスト？
回答: 意識するしかない。
偽陰性を防ぐため、テストピラミッドを作るようにする。
現在のpixivでは、ユニットテスト＋結合テストの実行時間は5分くらいで済んでいる。
テストする価値の高いシステムをテストする
テストの価値が高い箇所とは、コアドメインに近く、ロジックが複雑なところ。
テスタビリティ
DI, テストダブルの話。
13:10 Webアプリケーションのパフォーマンス・チューニングの勘所
曽根 壮大氏
計測するために必要なこと
- ログをとる
- New Relic, DataDog
- CPU, メモリなどのメトリック可視化
- スロークエリログなどのデータベースのログ
ログは検索できるようにしておくこと。
Linuxであればgrepできたが、SaaSなどではできないこともある。
AWSならCloud Watch Logsが便利。
計測したい理由を整理する。
計測する前に推測する必要がある（ジレンマ）
まずはOSのメトリックを見るのがおすすめ。
CPU, メモリなど。
キャッシュ
キャッシュは、使わないで済むなら使わないこと。
なぜなら、システムが複雑になるから。
使うなら最小限にする。
キャッシュの多段はNG.
例えば、RedisのデータをCDNに載せるなどはNG。
障害時などに、どこに原因があるかがわからなくなってしまう。
基本的にはクライアントキャッシュを使う。
クライアントに近いところにキャッシュを置くほど、ユーザーにとってレスポンスが速くなる。
13:45 スケーラブルサービス――疎結合に成長するシステムに不可欠な要素
成瀬 允宣氏
資料: https://speakerdeck.com/nrslib/scalable-system
システムにはライフサイクルがある。
システムのフェーズが変わる際によくあるのは、サーバーのスペックを変えること。
- スケールアップ
- スケールアウト
- スケールダウン
- スケールイン
開発者の開発能力もスケール対象となる。
モノリスよりも、マイクロサービスの方が費用対効果がいい、と考えられる。
スケーラビリティを考えるには、システムの構造が重要な要素である。
スケールアップできるか？ ＝ システムをメンテナンス状態にできるか？
特定の処理をスケールアウトできるか？＝ それはもうマイクロサービスです。
SLAが落ちてしまう。
99.9%だとする。
99.9% * 99.9% * 99.9% = 99.7%
3台に分けると、99.7%になってしまう。
メッセージ駆動が大事
メッセージブローカーを使う！
キューとストリーム
- キュー
- メッセージが届いたら消える
- ストリーム
- メッセージが届いても消えない。時間で管理する
キューの場合は、順序保証がない。
注文と取消の話。
もし取消が先にくると、注文が通ってしまう。
トランザクションの問題。
メッセージブローカーを使えば、処理間の依存をなくせる！
Laravelであれば、カフカというメッセージブローカーと連携することが多い。
メッセージブローカーは耐障害性が上がる。
処理A→処理Bを直接繋ぐのではなく、メッセージブローカーを挟む。
メッセージブローカーを挟むことで弾力性が増す。
処理が重くなった場合は、メッセージブローカーのスペックを強化したりできる。
イベントソーシング
状態ではなく、履歴を保持するという考え方。
JSONなどで全データを保持できるので、インピーダンスミスマッチを防げる。
組織的なスケーラビリティ
「イネイブリングチーム」という考え方。
他の人を手助けしながら開発をするチーム。
システムのイベントを網羅した設計図が必要。
PHPにおいては、Laravel+カフカを使うことによってイベントソーシングを作れる。
Javaの方が実装しやすい。
14:50 良いコードを書けるようになるコツは「エラーを気にする」 〜プログラマにとって
きんじょうひでき氏
資料: https://speakerdeck.com/o0h/phpcon-2023
エラー = フィードバックである。
もしエラーが全く起きなかったら、と考えると、ユーザーにとっては使いにくいシステムになってしまう。
PHPのエラーについて
エラーの程度によって分けられる。
例えば型定義。
エラーをなくす、という目的ではなく、システムに曖昧さをなくしたい、というモチベーションがおすすめ。
エラーレベルは絶対的なものではない。
組み込み関数でも、同じような処理だけどエラーレベルは違う、という関数がある。
おすすめ書籍： O'Reilly Japan - デバッグの理論と実践
エラーが出た際に、エラーメッセージはただ何が起こったかを示しているだけ。
どう直したらいいかは開発者が決めなければならない。
おすすめ書籍： コードが動かないので帰れません！ 翔泳社の本
未定義状態・曖昧な挙動を取り締まっていくことによって開発者は心の平穏を得られる。
PHPはどんどん曖昧さが減って、厳格になっているように感じる。
曖昧なところにエラーがある。
15:20 安全にPHPでWebアプリ開発するために実践していること / PHP Safety Development
篠田 北斗氏
資料: https://speakerdeck.com/pinkumohikan/php-safety-development
型機能をしっかり使うことでPHPで堅牢な開発ができる。
おすすめ書籍： レガシーコード改善ガイド 翔泳社の本
Googleは数年おきにコードベースを全て書き換えているらしい。
まずはテストを書くこと。
次に静的解析。
テストがないところもチェックできる。
静的解析ができる = IDEの補完が効く = 開発効率が上がる！
チーム内で課題感などを共有しないと、うまくいかないことも。
エラートラッキングツールを導入しよう！
Sentryがおすすめ。無料で使える。
DatadogなどでもOK。
エラー確認会を開催するのがおすすめ。
リアルタイム通知はどうしても見落とされてしまうので。
週1とか。
15:55 PhinxによるDBマイグレーションとサービス運用
ヒエイカザト氏
資料: https://speakerdeck.com/kazatohiei/phinxniyorudbmaiguresiyontosabisuyun-yong
既存のシステムにマイグレーションを導入する。
複数サービスが1つのDBをむいていたり、そもそもマイグレーション運用されていない場合にどうするか？という話。
Phinx（CakePHPが運用）
composerで簡単にインストールできる。
GitHub Actions上でマイグレーションを実行する。
おまけ
うんち漏れそうWi-Fiの人、大丈夫だったかな……。
