プロポーザル

PHPではtry-catchを使った例外処理が一般的ですが、「この例外はどのレイヤーで処理すればいいのか？」や「どの場面で例外を使うべきなのかが曖昧だ…」と感じたことはありませんか？例外の種類や扱い方が曖昧だと、設計の混乱やコードの保守性低下を招きます。この課題に対するヒントとして、Rustなどの言語で採用されているResult型の考え方があります。

Result型は、成功と失敗を型として扱い、例外に頼らずエラーを管理する手法です。これにより、エラーの種類や処理責任が明確になり、設計の一貫性を保ちながら保守性を高めることができます。このセッションでは、Result型をPHPに応用する方法を具体例を交えて解説します。

取り上げる内容：

• 例外の種類や扱い方が曖昧になる原因とその解消方法
• Result型の基本的な考え方とPHPでの実装方法
• try-catch採用プロジェクトでも活かせる学び

例外の扱いをもっと明確にし、エラー処理を改善するヒントをお持ち帰りください！

皆さん、ちょっとしたコードの動作確認をしたい・サクッとRDBを参照/書込する作業をしたい、等の場合に何を使っていますか？

コードを対話式で実行できるREPL(Read Eval Print Loop)は書き捨てのスクリプトを作ったりせずにコードを実行でき、開発を大いに助けてくれます。

PHPではphp -aコマンドで起動されるランタイム同梱のインタラクティブシェルや、より高機能で補完機能やコード実行結果の自動出力機能などを備えたPsySH (bobthecow/psysh)などがあります。

また、laravel/tinkerやcakephp/replなど特定の用途向けに作成されたREPLも存在し、筆者は簡単なRDBの読み書きであればREPLから行うこともあります。
実はそれらのREPLはPsySHをベースとして開発されています。

そんな便利、かつ他のツールの基盤となっているPsySHはPHP製のOSSです。
そう、PHPerが普段使い慣れた言語で作られているのでコードを読めば仕組みがわかります。

この発表では、REPLの基本である「入力の読み取り (Read)」「評価 (Eval)」「出力 (Print)」を軸に、PsySHがどのように実装されているのか・laravel/tinkerなどがどのようにPsySHを拡張しているのかを深掘ります。

• 発表の対象
  • PsySH（やそれを拡張したツール）のREPLとしての機能
• 話さないこと
  • REPL以外の機能 (デバッガ、コマンドライン引数で受け取ったコードの実行など)
• 対象聴衆
  • 普段REPLを使っている人
  • (普段REPLを使っているかどうかは関係なく) REPLの仕組みに興味がある人

みなさん、ドメインイベントって使っていますか？

このトークでは、ドメインイベントを使ってPHPコードをリファクタリングする方法についてお話しします。
ドメインイベントは、ビジネスドメインで発生する「出来事」を表現するモデルです。注文の完了やユーザー登録のようなビジネスプロセスの特定の状態変化を表現できます。
これをうまく使うことで、副作用をわかりやすく整理し、システムをシンプルにできます。

ドメインイベントを導入してみると、「あ、こんな風に設計すれば良いんだ！」と新しい発見があるはずです。リファクタリングを通じて、どうやってドメインイベントを設計し、活用するのか、その具体的な手法をお伝えします！

話すこと

• ドメインイベントって何？
• リファクタリングでドメインイベントをどう導入するか
• システム間の連携を簡単にするイベントの使い方

運用中のPHPアプリケーションに後からCDNを導入する際、特に歴史的な経緯により、複数のカスタムドメインを使用している場合、移行作業には慎重な計画が必要です。このセッションでは、AWSのCloudFrontを例に、複数ドメインを持つ既存アプリケーションにCDNを導入する際のベストプラクティスを解説します。

まず、複数ドメインで運用している環境で効果的なCDN導入が難しい理由を整理します。たとえば、静的リソースのURLがハードコーディングされている場合や、既存のキャッシュ制御ヘッダーが正しく設定されていない場合、移行中にアクセス障害やパフォーマンス劣化を引き起こすリスクがあります。これらの課題を特定し、解決するための準備ステップを紹介します。

次に、CloudFrontを活用して既存のアプリケーションにCDNを導入するプロセスを具体的に解説します。CloudFrontのディストリビューション作成方法、複数ドメインを扱うためのカスタムオリジン設定、HTTPS対応のためのACM（AWS Certificate Manager）の証明書設定について実例を交えて説明します

さらに、移行中の段階的なテスト方法についても触れます。たとえば、特定のリクエストのみCloudFrontを経由させる設定や、デバッグ用にキャッシュを一時的に無効化する方法など、移行時に安全性を確保するためのテクニックを共有します。

このセッションは、複数ドメインで運用中のPHPアプリケーションを対象に、後からCDNを導入する際の手順と注意点をわかりやすく解説します。AWSを活用した実践的なアプローチに興味があるエンジニアの方に、移行作業をスムーズに進めるための知識を提供します。

話者は普段PHPをBrefというOSSを利用してAWSにデプロイしています
この方法は非常に有用で、サーバーレス環境にPHPアプリケーションを載せるための標準手法として紹介してきましたが
一方で第三者が構築しているOSSに対する不安を感じる方もいるはずです

既存コードをどのようにサーバーレス化すれば良いのか、またカスタムな環境構築がどこまで信頼できるのかといった懸念があるかもしれません
特に既にLaravelやSymphonyなどのフレームワークを用いて開発されたアプリケーションを、
既存のワークフローを大きく変えずにクラウドネイティブな環境へと移行したい場合、そうした課題はより顕在化します

そこで今回はAWSが構築を行っているAWS Lambda Web Adapterを利用します
PHPerはサーバーレスの利点を享受しつつ、従来のWebアプリケーションをシームレスに移行する手法を身につける事が出来ます
さらにLaravelに適用する際には、既存のルーティングやミドルウェア、コントローラ群をそのまま活用し、AWS Lambda上でリクエスト-レスポンスサイクルを再現することが可能です

AWS Lambdaの可能性を広げるWeb Adapterを利用したサーバーレスPHPの普及に助力出来れば幸いです。

• お話すること

  • AWS Lambda Web Adapterについて
  • Laravelのデプロイ手順

• 想定聴講者

  • サーバーレスPHPに興味がある方
  • AWSを利用してPHPを利用している方

クラウドネイティブやマイクロサービスアーキテクチャの普及に伴い、アプリケーションは複雑化し、
従来のモニタリング手法では原因特定が困難な障害やパフォーマンス劣化が増えています

こうした状況下で注目されるのがObservability（可観測性）です
Observabilityは、システム内部の状態や相互作用を可視化し、迅速な問題解決や改善策の立案を可能にします

本セッションでは、業界標準化が進むオープンソースプロジェクト「OpenTelemetry」を活用し、
PHPアプリケーションにObservabilityを導入する手順を段階的に解説します
Observabilityの基本概念をMonitoringとの違いを交えつつ明確化し、実際のトラブルシューティングシナリオを示します
これにより「なぜObservabilityが今必要なのか」を理解します
さらに、OpenTelemetry自体が何なのか、その本質と狙いをOpenTelemetryの特徴やコンポーネントをわかりやすく整理します
公式SDKのセットアップ、計測ポイントの挿入、外部サービスとの接続方法をサンプルコードを交えながら示し、PHPアプリへの適用ステップを紹介します

このセッションで参加者が次の開発・運用プロセスでOpenTelemetryを用いてObservabilityを導入できる一歩目を提供します

• 想定する聴講者
  • OpenTelemetryを知らない方
  • OpenTelemetryが何故必要とされているか知らない方
  • OpenTelemetryを利用してみたい方

PHPユーザーであれば、日々APIのパフォーマンスと向き合うことがあるかと思います。
中でもGolden Signalと呼ばれる4つの指標（レイテンシー、トラフィック、エラー、サチュレーション）は、システムが「健全」であると判断する基準となるものです。
本セッションではGolden Signalを中心に、Performance Insightや周辺のメトリクス、モニタリングツールの操作、問題の特定や推論を可能にする為のTipsについて話します。

• Golden Signalについて
• 価値のあるログとは何か、どこにあるのか
• Performance Issueをどう特定するか
• ケーススタディ、 ex: このアプリケーションは20時台にCPU Usageが跳ね上がるのってなぜ？
• ログとメトリクスからユーザー特性を推論する、問題発生箇所のコードを探す技術

本セッションではTerminal IDEを、VsCodeやJetBrains製品が提供する「統合開発環境」としての機能をVimとTUIを利用してTerminal内で表現する事であると定義します。
LSP、DAP、補完やGitにDocker操作等々のIDEとしての環境をVimで構築するまでのステップと、その効率性について解説する内容になります。
皆さんに「こんな選択肢があるのか」と自分の開発環境を見直す機会になることがGoalです。

話すこと

• なぜTerminalで完結させているのか
  -Terminal IDEとIDE製品のPros/Cons
• Lua言語について
• Terminal周りのOSS事情と、Rust製の勢い
• 自分が大規模コードをNeoVimのみで編集できるようになるまでの四苦八苦
• PHPでのライブコーディング

何かを作ることって楽しいですよね。プログラミングを始めたキッカケは、それぞれ違うでしょうけれど、「動くもの」ができたときに得る快感は、およそ共感できるでしょう。
ところで、日々のお仕事に忙殺されて、その得られる快感が薄くなっていませんか？業務ではさまざまな制約があることでしょう。

そんなあなたに、自由な開発をする後押しをしたい。そして自由を糧にしてあなたのWayを作って欲しいのです。

想定ターゲット

• お仕事でしか開発をしない人
• 日々のお仕事に忙殺されてる人
• 個人開発ってなんだろう、どうすればいいんだろう、という人

話さないこと

技術的な詳細には触れませんが、トーク後に質問をいただければ大歓迎です！嬉！

ISUCON は「いい感じにスピードアップコンテスト」の略で、ほぼ同様の処理をするよう作られた Web サービスの参考実装が複数の言語で用意され、参加者は競技中好きな言語を選んでその性能改善をしていきます。2024 年に実施された ISUCON14 でも PHP 用の参考実装が用意され、実際に PHP を使って参加し、良い成績をおさめたチームもありました。

このトークでは ISUCON14 の問題の PHP 参考実装を使い、時間制限を気にせず、参加者の感想ブログの取り組みを平然とパクりつつ、PHP で優勝チームに勝てるスコアを出せるか試した際の知見をお話します。

かつて PHPerKaigi 2023 で ISUCON12 本選問題を使って同様の試みを行った際は、

• 計測の重要性
• DB ネックの間は他言語と同じような改善が効く
• 処理系へボトルネックが移ると同じやり方は使えない
• AltFPM の有効性
• CPU をより多く割り当てる必要性
• 徹底的にやれば PHP でもスコアは出る

といった知見が得られました。
今回もそれらの知見にもとづき同様の改善の道筋をなぞりつつ、FrankenPHP や PHP 製アプリケーションサーバに PHP 8.4 など、前回は存在しなかった・試せなかった取り組みを上乗せで行っていきます。

みなさん、PHPのテストを書くときに「他のクラスや依存関係のせいでテストが難しいな…」と思ったことはありませんか？
そんなときに役立つのが、PHPのモックフレームワーク Mockery です！

Mockeryを使えば、依存するクラスやインターフェースの動作をモックして、テストをもっとシンプルに、効率的に進められます。このトークでは、Mockeryの基本的な使い方から実際の業務で役立つテストケースまで、具体例を交えて解説します。

取り上げる予定の内容はこちら！

• モックを使ったメソッド呼び出しの検証方法
• 高度な引数の比較を使った柔軟なテスト
• 実務でのテストケースの実例紹介

Mockeryを使えば、テストのストレスが軽減され、もっとスマートにテストが書けるようになります！ぜひ参加して、PHPのテストを楽にする方法を学んでください！

「アジャイルなんてオシャレな自社開発企業だけの特権でしょ？」

そう思っていた時期が自分にもありました。

その後、自組織へのアジャイル導入を主導し、実践を重ねた今となっては、アジャイルはチーム単位や、ひとりからでも始められる！と確信しています。

このセッションでは、アジャイルの魅力、そして「はじめの一歩の踏み出し方」についてお話しします。

こんな人に聞いて欲しい

• アジャイルのことは知っているけど、まだ実践できていない人
• 受託開発だからアジャイルは無理、とあきらめてしまっている人

お話しないこと

スクラムや XP などについての細かいお話はしません。

現在担当しているプロダクト（建設DX領域のバーティカルSaaS）で多言語対応プロジェクトに参画した際の学びを共有したいと思います。

背景

プロダクトは10年以上運用しているものでリポジトリのファイル数は3千を超えます。
図面を見たり写真を撮ったりという標準的な機能のほか、外部機器と連携して検査をするというオプショナルな機能をあわせると30以上機能があります。
標準的な機能は多言語対応が完了していましたが、オプショナルな機能をこれから多言語対応していくというタイミングでした。

本トークで話すこと

• サービスを多言語対応をするうえでそもそも起こりうる、日本語と英語で文字数や記号による違いなど、表現について。
• 長く運用しているプロダクトの複雑な仕様を理解しながら進める多言語対応。
• 考慮不足によって発生したバグからの学び。

発表者について

プログラミング歴約2年半で転職して入社した会社での話し。
入社から数カ月後に参画したプロジェクトが多言語対応でした。

対象者

これから多言語対応をする予定の方、今多言語対応している方。
多言語対応で起きる問題に興味がある方。

皆さんはパスキーと聞いて何を思い浮かべますか？
なんか新しいすごいやつ、パスワードがいらないやつ、顔認証するやつ、デバイス間で同期してくれる、公開鍵暗号、チャレンジ………

このトークでは、近年GoogleやGitHubなど主要なWebサービスでも採用されてきている新しいユーザー認証方法「パスキー」に入門します。

• パスキーとは何か
• パスキーで何ができるのか
• なぜパスキーが推されているのか
• 従来のユーザー認証と何が違うのか

などのような基本的な部分から、

• パスキーでログインをするために必要な実装
• パスキーを実装する上での注意点
• パスキーを運用する上での注意点

など発展的な部分まで、一通りパスキーでの認証ができるようになるレベルを網羅します。

このトークがお勧めな人

• パスキーに興味がある人
• ID / パスワードによる認証とさよならしたい人
• よりセキュアなユーザー認証を実現したい人

このトークで得られること

• パスキーの仕組みの理解
• パスキーの実装方法
• パスキーの運用のあれこれ

皆さんはゲーム大好きですか？
わたしもネットがあまり普及されてない頃、攻略本を片手にずっとゲームをやってました。

実はPHPにも攻略本があります。ナ、ナンダッテー！？
全て印刷したら六法全書になるであろうボリューム。その名はPHPマニュアル！
本当にコントリビューターの方々には頭が上がりません。いつもありがとうございます。

もちろん、、、PHPerと名乗るからにはPHPマニュアルマラソンをやったことありますよね？
え？やってない？
それなら、一緒に習慣化するしかない！

この発表を経て、PHPの素晴らしさを再認識しましょう！

本セッションでは、CSVファイルのダウンロード速度が遅すぎて切り戻しになった知見をもとに、Laravelアプリケーションのパフォーマンス改善のデモンストレーションを行います。
「頑張って作ったのに遅すぎて使ってもらえない」では悲しすぎるので、ご参考にしていただけますと幸いです。

以下のテーマに沿ってデモをしていく予定です。
・ しくじり談
・ DBからのデータ取得時に気をつけること
・ 取得したデータを加工するときに気をつけること
・ 加工したデータを出力するときに気をつけること

キーワード
・ Eloquentとクエリビルダ
・ N+1問題
・ メモリ
・ ジェネレータ

想定視聴者
パフォーマンスを意識したコードを書ける・レビューができるようになりたい方

テストコード実装によるアプリケーションの実装設計や中長期の運用メンテナンス性に変化が出た話をします。
当初、ファットコントローラーや行数の多いメソッド、ライブラリへの依存性高い設計などが原因で、メンテナンスしにくいPHPアプリケーションを運用していたチームがテストコードの実装から技術負債を徐々に解消していけるようになりました。
理由は「テストコードを入れやすい実装と設計」をするようになったこと。
挙げた課題へどのような実装・設計の変化が起きたかリファクタリングの具体例や、テストコード導入による設計の変化を紹介します。
またテストコードによるリプレイスを叶えたアプリケーションを立ち上げた事でPHPやフレームワークバージョンアップへの適用性、テストコード実装スピード向上の変化についても語ります。

新卒から6年間所属した部署から大異動で全く別のチームに配属された先には鳴り響くアラートの日々が待っていました。
みなさんも、プロダクトの監視の状況で以下のようなケースに出会ったことはないでしょうか？

• 何をしたらいいのか、何が問題なのかわからないアラート
• 既存チームメンバーから無視され続けているアラート
• アラートが来ても反応するメンバーが限られている、対応できるメンバーが限定的
• アラートが頻繁に来ていてチームがアラート対応に疲弊している

上記のアラートについて見ていくと異動先のチームには、以下のような問題を抱えていました。

• アラートの詳細を詳しく見なければ問題がないことを判断できない
• アラートの判断は属人化している
• ほとんどのケースにおいて問題ないアラートが飛び続けている
• 最初に監視を設定した人はすでに社内におらず、意図がわからない
• メンバー間のアラートに対する認識齟齬

これらに対して、一つ一つ向き合って出してきた答えについてお話します。
聞いて欲しい方

• 新たに配属されたが、アラート対応ができなくて悔しいと思ってる人
• アラート対応に課題感を持っている人
• 一緒に見直していく仲間を増やしていきたい人

皆さんは、Laravelでの定期実行をどう実現していますか？？

我々のチームでは、サービスをECSにてデプロイしていることもあり、Laravelのタスクスケジュール機能を使わない選択をしました。

しかし、ECSのLaravelサービスに対して定期実行する方法には、以下のようなものがあります。
・ECSのスケジュールされたタスク
・Amazon EventBridge SchedulerからのECSタスクの実行
・Amazon EventBridge SchedulerとLambdaを使用したAPI呼び出し
この中から「早くて安くて安心な」手段を選ばねばなりません。
そこで、AWSのコストを抑えつつ、必要な要件を満たし、運用が簡単な方法を見つけるべく我々はアマゾン（AWS）の奥地へと向かいました。

そして冒険の果てに見つけた、最適な定期実行の方法をお話します。

DKIM、DMARC、SPF
これらを説明できるでしょうか？

これらの技術はメール認証技術であり、フィッシングやスパムから守るために重要な役割を果たします。
2024年4月から本格的に始まったGmailのガイドラインに基づくメールの受信拒否設定によって、メールセキュリティの考慮は他人事ではなくなりました。
これは、非エンジニアにとっても同じです。
場合によっては、サービスの利用者にGmailガイドラインに対応するよう依頼する必要があるからです。

しかしながら、これらの知識はどうしても専門的な技術知識なしでは説明しづらく、非エンジニアにとってはなおさら理解しづらい分野です。
難しい専門用語を使わないよう注意しながら、非エンジニアの方に理解してもらおうと頑張って資料を用意して説明した方も多いのではと思います。

この発表では、非エンジニアの人にも伝わるよう、今押さえておくべきメールセキュリティについて解説します。