トーク

AWS Lambda PHP！って言い続けている僕ですが、スループットは出る！とも言い続けています

実際スループットには満足してますし、運用には支障が出ていません

でもEC2と比べるとどうなんだろう…？と思ったので比べてみることにしました

EC2にはPHPを運用出来るレベルのインスタンスサイズを選んで、無理しない範囲で公平性を保ちスループットの比較を行ってみます

• お話すること

  • 比較のレギュレーション
  • パフォーマンス比較結果

• お話しないこと

  • パフォーマンス結果の考察

• お約束できないこと

  • 厳密な公平性

私が株式会社ウィルゲートで開発･運用を担当しているサービスのある機能で、設計をやり直して一からリファクタリングを行いました。
その機能は新卒1年目の私が開発を担当した機能でした。
アカウントが無いユーザ向けの機能のため、通常のログイン認証とは別の方法で認証する必要がある機能です。

2年目でその機能の不具合を修正した後に、実装当初想定されていなかった別の要件を満たす必要があることが分かりました。
その要件を満たすために設計を一から見直して作り直した中で分かったこと･体験談をお話をします。

話すこと

• 1年目で実装したときはどういう設計だったのか
• なぜその設計がイケてなかったのか
• 当初の要件で漏れていた要件はなにか
• 既存の設計と新しい設計の両方をmiroを使って図で整理したこと

話さないこと

• ソースコードを用いた詳しい実装方法

2022年夏。とあるベンチャー企業で3年間PHPerをやっていた男が、データ基盤を新規に構築するプロジェクトにアサインされた──

「データ基盤とは一体……？」
「BigQuery, Redshift, Sknowflake 一体どれを選んだらいいのか」
「データソース層、データウェアハウス層、データマート層の3層。ふむ、なるほど」
「え！？この3層をDWHの中に配置するのが流行ってるって？」
「 SQLでデータ加工。話題のツールdbtとは…」
データエンジニアリングの世界に異世界転生したPHPerが、ベンチャー企業におけるデータ基盤構築についてお話します。

とある案件で「Google Cloud で、Laravelアプリを」というオーダーに巡り会いました。
「AWS Fargate 上に Laravel プロダクトを載せる」ことをやりきっていた自分は、
Compute Engine ではなく Cloud Run 上に、Terraform module を利用して構築することにしました。

やると決めてから、Google Cloud のインフラを、初めて IaC で構築していきました。

このLTでは、その過程で感じてきた

• それまでに慣れていたAWSとの様々な違い
• Terraform module を利用することで手軽にクラウドインフラを組み上げることができる素晴らしさ

といったあたりの、新サービス構築事例をご紹介したいと思います。

OAuth 2.0は柔軟な認可フレームワークです
Facebook、Twitter、Googleなどのエンタープライズ企業も利用しており、実装頻度も必然的に多くなって来ます
またHTTPでの利用を想定して設計されており、PHPerにとっても抑えておくべき技術になります

一方で「柔軟で拡張可能なフレームワーク」で有ることから実装者が考慮すべき点は多いです
実装を見誤るとセキュリティ事故が起こってしまいかねません

今回はOAuth2.0の仕様について振り返りながら、考慮すべき事項をLaravelでの利用実装例と併せてご紹介します
OAuth2.0を適切に扱い、柔軟で堅牢なシステムを構築しましょう

• お話すること
  • OAuth2.0の仕様
  • OAuth2.0のアンチパターン
  • LaravelでのOAuth2.0利用実装例
  • OAuth2.1の状況

OAuth 2.0は柔軟な認可フレームワークです
Facebook、Twitter、Googleなどのエンタープライズ企業も利用しており、実装頻度も必然的に多くなって来ます
またHTTPでの利用を想定して設計されており、PHPerにとっても抑えておくべき技術になります

一方で「柔軟で拡張可能なフレームワーク」で有ることから実装者が考慮すべき点は多いです
実装を見誤るとセキュリティ事故が起こってしまいかねません

今回はそんなOAuth2.0の仕様についてお話します
OAuth2.0を適切に扱い、柔軟で堅牢なシステムを構築しましょう

• お話すること
  • OAuth2.0の仕様
  • OAuth2.0のアンチパターン
  • OAuth2.1の状況

HTTP/3 はHTTP/2に続くハイパーテキスト転送プロトコルの3つ目のメジャーバージョンです

話者はPHP Conference Japan 2022にてHTTPの仕様を振り返ったのですが、
その中でHTTP/3にはより高速なインターネットを実現するための夢が詰め込まれていましたし、高速化以外にもメリットがあります。

今回はHTTP/3に絞ってHTTP/2から何が変わるのかについてお話します。

クライアントからサーバーへのリクエストがどの様にレスポンスされてくるのか、
その期待が溢れる仕様について理解できる限りお話します。

• お話すること
  • HTTP/3の仕様
  • HTTP/2との違い
  • QUICについて
  • HTTP/3リクエストとレスポンスの様子と比較
• お話しないこと
  • HTTPの仕様

PHPの実行環境は日々選択肢が増えてきています
先日はAWS App Runner PHP8.1がサポートされました

喜ばしいことだと思うのですが、私達は一体どの実行環境を選べば良いのでしょうか

今回はAWSにおけるPHPの実行環境の比較を行い、PHP実行環境の選択肢についてお話します
各環境のユースケースを自分たちの環境へ当てはめ、より良い選択肢を取りましょう

• お話すること

  • PHPの実行に必要なもののおさらい
  • AWSにおけるPHP実行環境の比較
  • それぞれのPHP実行環境のユースケースについて

• お話しないこと

  • 利用方法の具体的な設定方法
  • AWS以外の環境について

PostgreSQL には json 型 / jsonb 型からなる JSON データ型 という型があります．
「RDB での採用は慎重に行うべし」とよく耳にする JSON 型ですが，PostgreSQL のjsonb 型においては正しく使うことで大きな力を発揮してくれます．
しかし， jsonb 型を本格的に採用している事例はあまり見られないのに加え， Laravel アプリケーションで jsonb 型を扱う事例は更に少なかったため，社内のLaravel アプリに jsonb 型を採用する際，jsonb 型との安全で快適な付き合い方を研究しました．

【本セッションで話すこと】
・jsonb 型の概要 / パフォーマンス
・JSON Schema の概要
・migration 時に JSON Schema による Check 制約を付与する
・カスタムキャストで JSON に型を付ける

Design Doc とは、開発者がコーディングに着手する前に、ソフトウェア設計の基本的な要点を説明するためのドキュメントです。
新しく追加する機能の設計を Design Doc を用いてドキュメントにしてきましたが、不慣れなうちは質の低い Design Doc を書いて、シニアエンジニアに指摘されてきました。
そんな自分の失敗を振り返る発表をしたいと思います。

話すこと

• 要約で伝わるようにする
• Design Doc で Approve を貰うことが目的ではない
• 体裁が整ったものが良い Design Doc ではない
• とにかく手を動かす

弊社では月に一度、各々が揃ってリファクタリングする日を設けています。

みんなが積極的にリファクタリングを行い、どんどんリリースしていくお祭り、それがリファクタリングデーです。

この発表では、実際どのようにリファクタリングデーを開催しているか、運用していく上で得た知見などをお話します。

プロダクトコードと対になって書かなきゃいけない「テストコード」。
今まで、「ルールとして存在していたからテストコードを書いていた私」が「あれ・・・？テストコードあるとめちゃくちゃ安心なのでは・・・？」「テストコード・・・スキ！！！」となった経緯を話します！

好きになる前の私「何でアプリケーションコードと、テストコード、2回同じことを書くんだろう・・・」
好きになった後の私「テストコードがあるから自分の実装に自信が持てる、バグらない自信あるかもしれんこれ」

この発表でテストコード書くことにピンと来てない人がちょっと書きたくなるな、となってくれるのを願い・・・！☆彡

概要

テストのメリットは「変更に強い」「動作の保証」「仕様書代わり」などが挙げられますが、この恩恵は保守フェーズを待たずにコードレビュー中から受けることができます。
レビューを受ける側はレビュー反映後の動作確認がしやすい、レビューを行う側はプログラムの構造が見やすくなりレビューの正確性と速度が上がるなど、双方にメリットがあります。
本トークではユニットテストを通じてコードレビューの効率を上げる方法をご紹介します。

トークの対象者

• コードレビューを行う人
• ユニットテストのメリットがイマイチわからない人

トークの目的

• コードレビューの心理的ハードルを下げる
• ユニットテストを書く人を増やす

話すこと

• コードレビューを受ける側/行う側双方におけるユニットテストのメリット

話さないこと

• テストコードの書き方
• PHPUnitの使い方

時代の進化によって、我々は様々な文明の利器を獲得してきた。

火🔥
石器🪓
電気💡
車🏎️

そして令和現在、、、、

🐘🌪️🐘🌪️PhpStorm🐘🌪️🐘🌪️

だがしかしPhpStormは便利すぎるが故に、飼い慣らすことが難しい。
時代の利器を手にしたとしても、使い方がわからねば宝の持ち腐れである。

PHP Conference 2022 で意外と要望が大きかった、PhpStorm の便利ショートカットをLTで披露しようではないか。

真の意味でPhpStorm🐘🌪️を、獲得しよう！

皆さんは社内勉強会は開催していますか？
勉強会の効果は、モチベーションが上がる・コミュニケーションが活発になる、などいいこと尽くめですよね！！

私の会社では30人規模ほどの社内勉強会を8年くらい継続していますが、
初期の頃は発表ハードルが高く、同じ人が発表したり、そもそもあまり発表者が集まらない、などの課題がありました、、！
「どうやったら発表してくれるかな？」という観点で改善を重ねた結果、今では溢れんばかりの応募です。
このLTでは「社内勉強会を開拓する」「発表者の発表ハードルを低くする」ノウハウを紹介します！

◆ 話すこと
取り組んできたハードル下げ方法「相談枠」「若手オンリー枠」「推薦枠」「カテゴリー絞り」「資料ハードル下げ」など・・・
その中で効いたアクション・効かなかったアクション

対象:実務経験開始～2年目位の方
内容:マイクロサービス(BFF)で10名以上のチームで開発していたプロダクトと、モノリスでほぼ1人で保守運用開発するプロダクトどちらも携わった経験から、アーキテクチャについてのメリット・デメリットと、開発体験についてお話します(どちらもVue.jsとLaravelを使用しています)。一方は大企業のC向けプロダクト、一方はベンチャーのB向けプロダクトになるので、大きく異なる点もお楽しみいただけるかと存じます。モノリスの方で採用されているクリーンアーキテクチャやドメイン駆動開発についても絶賛勉強中のため、(ミドル層以上の方に取っては今更な内容かもしれませんが、)ジュニアの方に分かりやすくご説明できればと存じます。
熱意:社外での登壇経験は無く初めてになりますが、少しでも参考になることがあるように精一杯磨き上げるのでよろしくお願いいたします！

「composer install打ったらいい感じになるよね」「なんかDockerfileに書いてあるよね」
かつて私のComposerとの向き合い方はこのレベルでした。
しかし自サービスをコンテナ化するにあたり、Composerときちんと向き合い彼らとの絆を得ました。
本セッションでは「Composerってなんだっけ？」から入り、Dockerコンテナにおける取扱いまで触れていきます。

◆ 話すこと
基本的な役割
主なコマンド
composer.json？composer.lock？
いろいろな実行方法（コマンド・composer.phar・Docker Image）
Docker(コンテナ)とComposer（マルチステージビルド）
自サービスで最終的に採用した方法とその理由

◆ 想定する観客
Composerをなんとな〜くで使っている方
Docker環境でComposer使いたい人

「Testing Pyramid（テスティングピラミッド）」皆さんも聞いたことがあるのではないでしょうか？
テストレベルごとにテストの量（数・実行）を上層ほど小さく下層ほど大きく（ピラミッド型に）すると良いというコンセプトです。
一方、React Testing Libraryの作者であるKent C. Dodds氏は「Testing Trophy（テスティングトロフィー）」というインテグレーションテストに最も重点をおいたテストコンセプトを提唱しています。
発表者はあるAPIサーバの開発にあたり設計時点でテスティングトロフィーを目指す決定をしました。
本発表では「なぜそれを目指したのか（選択したアーキテクチャからテストコンセプト決定まで）」「いかにそれを実現していったか（インテグレーションテストを軽量に追加する仕組みでコストに対抗する）」について紹介したいと思います。

「なんてこった！このライブラリはこの先のPHPでは動かない！」
サービス開発の現場では新機能の追加やクリティカルなバグ修正が優先されて中々ライブラリのメンテナンスまで手が回りませんよね？
そしてある日に「このライブラリはPHPのバージョンアップ動かない」なんてことが起こってしまいます！

このトークではそんなライブラリの中でも「影響範囲がサービスの画面ほぼ全部」という超ド級の物体のリファクタリングまでの道のりを紹介しつつ、広大な影響範囲のライブラリを置き換えるまでの戦略立てから実装までのノウハウをお話します。

サービス全体が影響範囲のリファクタリングなんてやりたくないですよね？でも、本トークを聞けば「どれだけ大きなレガシーコードでも向かい続ければ必ず直せる」という可能性を感じて貰えると思います。

皆さんは普段コンテナをどのように利用されていますか？

最近AWS App RunnerがPHPマネージドランタイムをサポートするなど、コンテナを手軽に利用する仕組みがますます充実してきています。

本トークでは、PHP開発でコンテナのマネージドサービスを使うメリットやPHPならではの課題についてお話しします。

話したいこと

• コンテナが使えるCaaS/PaaS
  • Cloud Run、App Runner、Fly.io etc.
• PHPの実行方式
  • mod_php、PHP-FPM etc.
• 1コンテナ複数プロセスとHTTPサーバ
• コンテナイメージのビルド方法
  • OCIイメージ、Cloud Native Buildpacks
• 非同期ワーカー、定時処理

話さないこと

• Kubernetes