トーク

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向けプロダクトになるので、大きく異なる点もお楽しみいただけるかと存じます。モノリスの方で採用されているクリーンアーキテクチャやドメイン駆動開発についても絶賛勉強中のため、(ミドル層以上の方に取っては今更な内容かもしれませんが、)ジュニアの方に分かりやすくご説明できればと存じます。
熱意:社外での登壇経験は無く初めてになりますが、少しでも参考になることがあるように精一杯磨き上げるのでよろしくお願いいたします！

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

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

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

サイトにくるお問合せの約80%を若手エンジニアチームで対応奮闘中！！

"お問合せ対応はレスポンスの速さが大切"だと思っています。
そんな中、メールでお問合せを集めていると調査に必要な情報が記載されておらず、
まず認識のすり合わせからと調査開始までにかなりの時間を要していました。
また、メールの通知に気づかなかったり気づいてもらえなかったり。
同じお問合せ内容を何度ももらったりと、お問合せ側も対応する側もハッピーに慣れない日々...

そこで、メールのテンプレートで欲しい情報を記載し、送ってもらうことに！
しかし、テンプレートが普及せず結果変わらず。
次こそはと、slackのワークフロー機能を用いてお問合せを貰うように！対応開始までの時間や、やりとりもスムーズに変わりました。
ナレッジの貯め方、若手同士のサポートや先輩方との関わり、両者がハッピーになるように行った工夫などなどお話します！

オンプレだったPHPアプリケーションをコンテナ化してWEBとバッチをクラウド化（AWS）しました。
今まで全くインフラの仕事はしていなかったのですが、ずっと興味がありました。
そして機会があったため手をあげて、SREと協力しながら実現させました！

「普段アプリケーションをさわってるけど、インフラもやっていきたいんだよなあ・・・」と思っている人のはじめの一歩を
私が体験した作業を軸に「やわらかく理解」できるようにお話します！

◆ 想定する観客
1年前の「インフラ興味あるけどなんもわからん」と思っているアプリエンジニアの私向けに作ります
総合して初学者向けです

◆ 話すこと
クラウド化で発生する作業って？（ECS / Docker / デプロイ / … ）
実際のタスクを進める上での悩み・詰まりポイント
クラウド化後に起こった想定外だったこと

DX(Developers eXperience) という言葉を聞いたことはありますか？ Digital Transformation の略称として使われることも増えていますが、別物です。
IT エンジニアの需要が増加傾向にある昨今、「コーディング自体を助ける 『優れた開発者体験』 」が重要視されています。

このトークで話すこと

このトークでは、潤沢な Laravel エコシステムを活用して、 DX を最大化させ、効率的なアプリケーションの開発を行う手法を紹介します。

• ローカル開発環境(Sail)
• 静的解析, Pint と Pest
• ファーストパーティ認証システム
• React フロントエンドバンドル(JetStream+Inertia.js)

ターゲット

Laravel を用いて効率的で安全にアプリケーションを開発したいあなたに。

業務知識とコードがリンクしていないと、PdMやビジネスサイドと会話をした時に上手く噛み合わなかったり、ある業務に関するコードを変更した際に思わぬ副作用が出たり、ビジネスサイドからの機能要望に応えることが根本的に厳しい状況に陥ると自分は考えています。

トーク内容

新卒二年目の自分がやっている業務知識とコードを結びつけるためにやっていることをお話しします。

話さないこと

• DDDについて（意図せずDDDっぽいことを話すかもしれませんが、DDDについては全くの素人なので悪しからず

エンタープライズアプリケーションアーキテクチャパターン(以下P of EAA)は、有用ですがなかなか読み解きにくい本です。

このセッションでは、P of EAAのパターンに基いた構成になっているEloquentと関連付けることで、P of EAAのデータソースレイヤ回りのパターンの概要を、わかりやすいく説明します。

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を通して考えると、とてもスムーズに理解することができるはずです。

1995 年から 30 年近く進化を続けている PHP 。私はその歴史でも一つの大きな転機となった PHP 5.3 あたりから、 8 年ほど開発に携わっています。
ここ 5 年弱の PHP の変遷はめざましく、大きくその姿を変えています。 IT 業界が揺れ動く中でも安定した需要を見出しているのではないでしょうか。

このトークで話すこと

このトークでは、これらのことについてまとめています。

• これまでの私の知りうる限りの PHP の進化の過程
• 現在の PHP 8.2 時点で作れる堅牢なアプリケーションの作り方
• この先 PHP がどういった道を進むのかを RFC を見ながら想像

ターゲット

• これまでを振り返りたい方
• 今どう書くのがオススメなのか知りたい方
• 未来の PHP に期待している方々

PHP に関わるみなさんに聞いて欲しいと考えています！

「ユニットテストなんてダルいよなー」「疎通動確の方が速いよなー」
そんな方へお届けする「気張らないでやれる」「"プログラマにとって"有用・有益なユニットテスト」についてのお話です。

また、次の症状にお悩みの方にも有効です。
・ユニットテストはやってみたいけどPHPUnitの導入で挫折した
・PHPUnitほど高度ではなくて良いので、もうちょっと気軽にユニットテストしたい
・大分古いPHPからのバージョンアップを実施したい
・バージョンアップのたびに動かなくなるテストスイートってどうなの