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

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

話すこと

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

話さないこと

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

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

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

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

• お話すること
  • OAuth2.0の仕様
  • OAuth2.0のアンチパターン
  • Laravelでの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の仕様

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

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

最近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

LaravelのEloquentはRailsのActive Recordを元にしていることはご存知でしょうか？
では、Active Recordは、P of EAAの「アクティブレコード」パターンを元にしていることは？

アクティブレコードパターン以外にも、Eloquentの構成には、P of EAAの各種パターンに基いた個所があります。

このセッションでは、Eloquentの構成を通してP of EAAのパターンを学んでいきます。また逆に、P of EAAのパターンを通して、Eloquentの理解も深めます。
難解なP of EAAも、普段から使っているEloquentを通して考えると、とてもスムーズに理解することができるはずです。

当時インターン生としてジョインした僕。
初手で与えられた仕事はPHPバージョンアップ。
PHPはHello Worldレベルなのに！
それも5.6を使ってるらしいじゃないですか。2022年やぞ！
そんなこんなで正式入社・配属を経て現在まで圧倒的キレ芸をかましながらレガシーと戦ってきました。
その結果いくつかのサービスはアップデートを成し遂げました。
ですがアップデートの仕事はそこで終わってはいけないはずです。

このトークではアップデートをするまでにやったこと、失敗したこと、ひいては戦略的塩漬け、社内への啓蒙活動、葛藤、闇落ち、それらを経て見えてきたPHPバージョンアップという仕事は何たるかについて新卒１年目が稚拙ながら赤裸々に語ろうと考えています。

対象者

• レガシーに疲弊してる方
• 若気の至りを眺めてキャッキャウフフしたい方

Webサービスは生き物。
機能追加によって常に成長し、変化しています。
そんな日々の中で、機能追加する際のデータベースに対する変更はつきものです。
しかし何気ないデータベースの変更が障害の元になったり、機能追加の障壁になっていたりしませんか？

• 本番にALTERを流したらロックでサービスが死んだ
• 特定のカラムを毎回確認するifの列挙が辛い
• Viewで表示されるデータがSELECTしないとわからない
• 仕様追加の際にテーブル変更が怖い

そんな不安、心配を持っている皆様に明日からできるテーブル設計についてお話します。

対象者

• 正規化をちゃんと勉強したことがない
• MySQL、PostgreSQLを使っているけどなんとなくでテーブル追加、変更をしている
• 実行計画、INDEX、言葉は知ってるけどよくわからない

開発組織の開発力、生産性を上げるために避けては通れないエンジニア一人ひとりの技術力アップ。
私がEMとして、ここ数年考え実践してきたエンジニアの教育において必要な要素や考え方について一部実例を交えつつ、整理して話します。また、組織･チームとしてのスキル獲得のための方法論、文化継承についても話します。

トーク内容

メンバーを教育する際に気をつけていること
エンジニア教育する際のマインド
レベルごとの教育スタンス（ティーチング、コーチングの使い分け）
教育にまつわる理論（認知特性やラーニングピラミッドを活用する話）
得意な勉強タイプごとの教育戦略

想定視聴者

組織のエンジニア教育にミッションを持ち悩んでる人
エンジニアとして今後の成長方針に悩んでる人
教育に興味がある人

含まれないもの

エンジニアに必要な個別技術の習得方法
エンジニアとしてどのような個別技術を学ぶべきか

彗星のように現れた人工知能 言語モデル ChatGPT
PHPerにとって脅威か、救世主か！？

Stable Diffusionも衝撃的でしたが絵しか描けないことでプログラマーには少し距離がありました。
ChatGPTは日本語など各国語で会話ができて、何とプログラムも書ける！

PHP、JavaScriptなど有名なプログラミング言語はもちろん、フロント、サーバーサイド、インフラ、ドメイン駆動設計、テスト、CI/CDの設定、コンテナ、オーケストレーションなど何でも書けちゃうぞ！

プログラムだけじゃない。
採用のアドバイス、部下、上司の悩みまでアドバイスをくれる。
上下挟まれ続けるリーダー、マネージャーにとっても良き相談役になれるかも！？

PHPerKaigi 2023の場で、面白い活用方法、仕事で使う上でのリスク、対応方法など、話し合いましょう！

「ブラウザでURLを入力してwebページが表示されるまでの仕組みを説明してください」
こんな質問をされたら、あなただったらどのように答えますか？

webアプリケーションを開発する上で、多くの技術的要素を理解していることが求められますが、
正直なところ現時点では上記の質問に対してうまく説明できるかは不安です。

この状況を踏まえ、普段何気なく利用しているブラウザの向こう側の仕組みについて、
自分なりに色々と調べてみて、当日の登壇では時間の許す限りその調査結果をお伝えしようと思います。

テストコードの書き方について説明する資料等は世の中に充実しつつあります。
一方で具体的にテストコードを書いていく様子を説明、実演する資料というのはまだ数が限られています。

そこで今回はソフトウェアテストの領域でよく題材とされる「マイヤーズの三角形問題」の実装を取り上げ、
素朴な PHP コードからはじまり、テストコードを補いながら、ときにつまづきつつ、解くべき問題を捉えたコードへと洗練させていく過程を実演します。

本セッションで扱うテーマ

• テストファーストなアプローチによるコーディング、リファクタリング
• PHPUnit の基本的な使用法と data provider の活用

本セッションで扱わないテーマ

• テスト戦略やテスト設計について

同じPHPでも、単一ファイルでWebページを表示するのとフレームワークを使うのとでは書き方が大きく変わります。
みなさんは不思議に思ったことはないでしょうか？

• どうしてURLと対応するPHPファイルがなくてもHTTPリクエストを処理できるのか
• どうしてHTTPリクエストを受け取るとControllerのメソッドが呼ばれるのか
• どうしてecho等をしていないのにHTTPレスポンスを返せるのか
  そんな数々の「どうして」は、処理の起点となるindex.phpを読み解くことで答えが見えてきます。

フレームワークが動く仕組みを理解すれば適切な実装方法を判断したり、デバッグの際に役に立つでしょう。

本トークでは以下に示すフレームワークを取り上げ、index.phpを起点にフレームワークが動く仕組みを説明します。

• CakePHP
• Laravel
• Slim
• Symfony

PHP現場に放り込まれた、右も左も分からないジュニアエンジニアがどうサバイブすればよいのか…を偏見で語ります

• どの本・サイト・Youtubeをみるべき？
• 「『武器』は装備しなきゃ意味ないぜ！」
• 「『わからないこと』がわからないこと」に立ち向かう
• ちょっとまってその実装！実装前にまず設計(？)！
• コミット前、PR前に一息つこう
• 恐ろしい(？)レビューに落ち着いて対処
• Merge後に振り返り
• 忙殺(主観)や無力感(主観)を避ける

PHPエンジニア初心者が心がけるべき事を紹介します
「先輩」へのメッセージもあります

※ N個の現場経験を元にしており、特定現場の話ではない
※ もっと良い「先輩」がいればそちらを優先せよ
※ 「お前はそんな立派なの？」「自分を棚上げは『先輩しぐさ』の基本ですよ」

「 なんてこった！PHPウェブアプリ公開は何かと金がかかる！なんでかJS方面は無料が多いってのに！？」そんな嘆き声が聞こえてきます。どうですか？

「当たり前では？」と思いますが、やはり金はかけたくないと思う、リーンですよリーンスタートアップ。

あげく円安の時代、t2.microですら¥2000円弱/月かかる今、我々PHPerはどのように無料もしくは低料金でPHPを使えば良いのでしょうか…？
安くあわよくば無料でPHPウェブアプリを公開する縛りプレー(？？？)のテク紹介をしたいと思います。

副次的に、様々なPHP環境構築やサービスの紹介になる予定です。

• 保証をするものではなく、実践は自己責任です
• 規約的に多分グレーでも、「倫理」的にはギリギリな要素を含みます
• 初心者でもOKです、多分
• 「昨今のフロントエンド界隈、うらやましいなァ！」

「オレオレフレームワークは忌むべきもの」ですが、昨今はライブラリや”設計”の浸透、PHPエコシステムの進化も進み、私見としては「禁忌する理由が減ってきた」という実感があります。

過去様々なオレオレフレームワークを作ってきた私の「令和5年最新版オレオレフレームワーク(仮称)」の設計をご紹介しつつ、私がオレオレフレームワークに取り組む理由である「既存のフレームワーク」のペインポイントと私がもつ”疑義”についてトークします。

同時に、なぜ過去のオレオレフレームワークが禁忌されたのか、ベタープラクティス・アンチパターン、「オレオレフレームワーク実行犯」である私の見解(≒自己弁護)もお話します。

さあ、再びフレームワークを我が手に

対象聴講者

• 中級以上、たとえばDI程度の概念を理解しているなど

PHPerKaigiに参加される方の中には、またプログラミング経験がほとんどなく
これからPHPを勉強しようと考えているという方も多くいらっしゃると思います。

そんな方々へ向けて、Webアプリケーション開発に必須の知識である
データベースやSQLというものを、世界一分かりやすく解説します！！！

このトークのゴールは、
・データベースという概念をなんとなく理解すること
・簡単なSQLを自力で書けるようになること
です。

僕自身が初心者の頃にこういう説明をしてほしかった…と思うような
順序と言葉遣い、例示を用いて、初心者向けに本当に世界一丁寧に（当社調べ）解説します！
ぜひお楽しみに！！！

※データベース/SQLというものを全く知らない方に基本のキを腑に落としていただくことが目的のトークなので、
分かりやすさを優先して厳密さを多少犠牲にする場面があります。上級者の方はご注意ください。

DORAによる調査State of DevOpsが近年、注目を集めています。
開発組織のパフォーマンスを計測する Four Keys という指標を耳にすることが増えてきました。
この Four Keysですが、計測してみたはいいものの、実際にはどのように改善していけばよいのでしょうか??
DORAは調査の結果からFour Keysの改善効果が高いことが特定されている組織の能力をDevOps Capabilities (27のケイパビリティ)としてまとめ、報告しています。
本トークではDevOps Capabilities (27のケイパビリティ) について、1つづつピックアップし概要をまとめ、ご紹介します。

本トークで話すこと

• DevOps Capabilitiesの概要
• DevOps Capabilitiesの紹介
• 今後新しく追加されそうなCapabilitiesの紹介

みなさんは「共通化処理」をしたことはありますか？
したことがあるという方の大多数はきっとその「共通化処理」によって様々な課題に直面した経験があると思います。
ある時は特定処理を達成のためのif文を共通化処理に追加、ある時は汎用処理で叶えられないので継承して新しく作り直すなど……
本当に「共通化処理」というものは存在するのでしょうか？

数十年に渡る「共通化処理」という夢物語を現実世界に置き換えたときの振る舞いや実際の見え方など、そして「共通化処理」という言葉の裏に隠れる真の意味を私の強い視点からお話できればと思っています。

本トークで話すこと

• 共通化処理と呼ばれるもの
• ソフトウェアにおける共通化処理の実態
• 本当に言われてほしい表現と実現について

本トークはPHP勉強会で発表した内容をフルリプレースする予定です

PHP は、気軽にウェブアプリケーションを作れる言語として、初心者から熟達者まで、人気のプログラミング言語です。
一方で、せっかく作ったウェブアプリケーションも、開発を続けていくと複雑性が増して、扱いづらくなってきます。

今まさに、目の前で積み上がる負債を見て見ぬ振りをしながら、追加開発を行うのは精神的にも辛いです。
本トークでは、今の開発をキープし、難解な設計論を避け、どうやったらレガシーになりにくく、レガシーになったとしても何とかなるウェブアプリケーションが作れるかをまとめます。

本トークで話すこと

• レガシー化しにくくなる PHP ウェブアプリケーションの基本方針
• 明快で分かりやすい開発時の約束事
• 負債を生み出しにくい開発フロー・開発組織の仕組み作り