引っ張ってもしょうがないので「PHPer」の読み方は「ぺちぱー」だそうです。（ﾍﾟﾌパーみたいな感じだと思っていた）
2024年12月22日に開催された『PHP Conference Japan 2024』に参加してきましたので、レポートします。
ちなみに弊社株式会社YUZURIHAもブロンズスポンサーとして協賛しており、エンジニア募集と新サービスGigMatchのフリーランスエンジニア募集のチラシを配布させていただきました(以上宣伝おわり)
参加セッション
- PHP開発者が挑むDKIM導入：Googleガイドライン対応の実例と学び
- 入門 文字列
- 終了の危機にあった15年続くWebサービスを全力で存続させる〜Twilog・Togetter統合の舞台裏〜
- PHPでは気にならないCookie管理の境界線 SSRで直面するサーバーとクライアントの違い
- APIデバッグとリバースエンジニアリング
- ある日突然あなたが管理しているサーバーにDDoSが来たらどうなるでしょう？知ってるようで何も知らなかったDDoS攻撃と対策
- PHPerのための計算量入門
※抜粋
PHP開発者が挑むDKIM導入：Googleガイドライン対応の実例と学び
登壇者はラクス社の上村さん
2023年10月に公開されたGoogleのメール送信者ガイドラインへ、ラクスの楽楽販売でどうDKIM対応したかについて具体的な取り組みをお話いただきました。
内容
- ガイドラインの公開→開始までが短期間の中、ガイドラインにどこまでどのように対応すべきかをサービス特定に合わせて決定
- 事業側(主にCS)を巻き込み、エンジニアは技術背景の説明、CSは想定QAの作成など歩み寄りながら対応
- リリーススケジュールの都合もあり暫定対応と本対応を分けて実施
スライド
感想
楽楽販売の例では顧客側でも対応が必要ということで、どのように顧客に協力いただくかが重要と仰っているのが印象的でした。DKIMはじめメールセキュリティについては一般教養の範囲外だと思いますので、非エンジニアにも重要性と対応方法をどう伝えていくかに難しさがあると思います。
入門 文字列
登壇者はpixiv社のうさみけんたさん
PHPに限らず文字列という概念の概観と、歴史的な経緯などからどういった困難に立ち向かっていくべきかお話いただきました。
内容
- コンピューター内のデータは2進数→表示は16進数(バイナリエディタ)
- 1バイト(8ビット→8桁の2進数)に1つづつ文字を対応させれば2^8=256種類割り当てられる
- 昔は容量の問題で1文字1バイトでも減らす努力があった(例：ドラクエやポケモン)
- ASCIIコードの登場と、アスキーの問題点(引用符の開始と終了区別がない・ハイフンとマイナスが同じ・英語アルファベットのみetc...)
- ASCIIをローカライズする試み（ISO-646,ISO-8859-1）
- 日本語文字コードの試み（JIS漢字コード,Shift-JIS,CP932）
- 今の主流はUTF-8だが、これらの経緯で文字コードの取り扱いは難しい
- 翻ってPHPにおいて、strlen()は文字列のバイト数を得られる(文字数ではない。文字列でなくimgでもバイト数を返す)
- mb_detect_encoding()も必ず正確な訳では無い
感想
なぜこんなにも文字コードが乱立しているか、時系列で振り返っていただいたので納得感がありました。
ドラクエで収録文字を制限して容量削減している話はゲーム好きの間では有名ですが、つかみとしてウケが良かったので、文字コードを説明する際は真似してみようと思います。
終了の危機にあった15年続くWebサービスを全力で存続させる〜Twilog・Togetter統合の舞台裏〜
登壇者はトゥギャッター社のyositosiさんとアオヤマミントさん
Twitter APIの有料化をきっかけに、TwilogとTogetterの統合に至った経緯をお話いただきました。
内容
- AWSからさくらへの移行、SQLiteの採用と廃止など、システム移行における様々な試行錯誤を紹介
- 大容量ストレージの運用コストを削減するため、S3やSQLiteなどどの技術を選定すべきか
- 検討内容について実際のコストやメリット・デメリットについて
スライド
感想
MySQLからSQLiteに移行し、検証の結果やはりMySQLにメリットが大きいと判断して再度移行する決断が印象的でした。ストレージだけでなく、データ通信コストのなどハマったポイントを実感を込めてお話いただき興味深かったです。
PHPでは気にならないCookie管理の境界線 SSRで直面するサーバーとクライアントの違い
登壇者はbooost社のま@めさん
SSR (Server-Side Rendering) と CSR (Client-Side Rendering) の違い、特にCookie管理における問題とその解消についてお話いただきました。
内容
- NEXT.JSでCookieを使用する際に躓いたポイント→documentがないといわれる
- SSRでは、サーバー内で完結するものだけ処理しなければならない(ブラウザのdocumentは存在しない)。SSR→CSRにCookieを渡す処理が必要
- PHPにおいてそうした面倒な部分は、PHPがうまいことやってくれている！（ありがとうPHP）逆にパフォーマンス改善などはアクセスしずらくなっている
スライド（冒頭部分）
感想
Cookie管理はどの言語でも大して違いがないと思っておりましたが、SSRでの試行錯誤を通じてPHPが良きに計らってくれている領域があると相対化することができました。
APIデバッグとリバースエンジニアリング
登壇者はポストマン社の草薙さん
APIデバッグツールであるPostmanの使用方法についてレクチャーいただきました。
内容
- Postmanを用いたAPIリクエストのデバッグ方法を詳しく解説
- リクエストヘッダー、リクエストボディ、Cookieなど、APIデバッグに必要な情報を画面を交えながら
- インターセプター(ブラウザ拡張)や、プロキシを設定することで通過するhttp/httpsトラフィックをキャプチャできる機能の照会
スライド
感想
個人的にはAPIに触れる頻度は少ないですが、APIリクエストのキャプチャや後から同じリクエストを復元できるなどかゆいところに手が届いていそうな印象でした。
また、ブース出展でステータスコード福引(レアなステータスコードほど景品が豪華)をやっており、やってみたかったです(出遅れて終了してました)
ある日突然あなたが管理しているサーバーにDDoSが来たらどうなるでしょう？知ってるようで何も知らなかったDDoS攻撃と対策
登壇者はアカセさん
DDoS攻撃の仕組みから現状、具体的な対策方法についてお話いただきました。
内容
- DoS→標的となるサーバー、サービス、ネットワークに大量のデータを送る。DDoS→DoSは攻撃元が単一だが、DDoSは乗っ取られた機器などを介して攻撃元が複数になる
- 安価なDDoS代行業者が現れ、安易な目的でDDoS攻撃が行われる現状があり(身代金の脅迫から嫌がらせ、愉快犯など)年々増加傾向
- DDoS攻撃への対策方法は色々考えられるが効果が限定的なものも(攻撃元が複数なので正常なアクセスとの判別が困難・対策することでリソースを喰うものも)
- CDNやWAF側のDDoS対策を導入するなど有効なものはコストもかかるので、ビジネスへの影響とのバランスを考えながら適切な対策を準備しておく
スライド
感想
DDoS攻撃の基礎知識から対策方法まで知ることができました。なるほどと思ったのは「SNSで犯行予告を監視しておく」で、DDoS攻撃が来るとは限らないですが心づもりを含めた準備の猶予が得られそうです。
アカセさんはツナギメエフエムというポッドキャストも主催されているようですので聴いてみたいと思います。
PHPerのための計算量入門
登壇者はカオナビ社の富所さん
プログラムの効率化に不可欠な計算量の概念から、オーダー記法、組織での運用の仕方についてお話いただきました。
内容
- 計算量とは、コンピューターが命令を読み込んで計算を行った量。PHPのコンパイラが変換したオペコード1行分に近似
- アルゴリズムとデータ量によって計算量は異なり、オーダ記法で計算量の目安を表現できる→O(n)、O(n^2),O(n log n)など
- 計算量には時間計算量(計算回数)と空間計算量(メモリ使用量)がある
- 現場ではコアドメイン以外は負荷試験できないことが多いので、計算量概念を啓蒙するのが低コストな対策になる
- ただし計算量視点を手に入れたエンジニアは計算量警察になる(あらゆるアルゴリズムを改善しようとする)が、どんなアルゴリズムでもデータ量が少なければ計算量は少ないため、処理の分かりやすさなどとのバランスをとる
- 更に効果的なのはビジネスロジックを単純化し、複雑な要件を変えてしまうこと
スライド
感想
個人的には参加したセッションで一番面白かったです。概念しか知らなかった計算量について、現場で活用するための考え方を沢山示していただけました。
また、計算量を知ったエンジニアが計算量警察になる、というのもこの講演を聴いた人が計算量警察にならずに済んで良かったと思います。
参考図書も挙げられていましたので、スライドも参照してみてください。
さいごに
初めての参加でしたが、PHPの新しい技術やトレンドに触れることができました。来年のPHPカンファレンスのスケジュールも発表されていましたので、また参加してみたいと思います。