トーク

LaravelでのStripe APIの統合方法、特にサブスクリプション機能の管理とテスト手法にフォーカスし、実用的な実装例を紹介します。
またStripeのAPIを統合して課金を実装する内容を分けて説明します

1. CustomerPortalを利用する場合
2. CustomerPortalを利用せず、課金を実装する場合
3. Webhookをどう活用していくのか

このセッションは、以下の方を対象としたセッションになります。

• LLMとの付き合い方に悩んでいるPHPer
• 開発生産性を上げたいPHPer
• LLMを使った開発効率向上に興味があるがセキュリティ的な問題で導入に悩んでいるテックリード

GitHub Copilotを使ったコード補完や自動生成による開発効率化に加え、現在のリポジトリのコードを分析・説明するためのLLMの活用方法についても言及します。さらに、ローカルにLLMを導入し、開発環境内での活用方法・困りごとについても具体的な手法を解説します。

皆さんゴールデンパスという用語はご存知でしょうか？
ゴールデンパスとは「迅速なプロジェクト開発に役立つ巧みに統合されたコードと機能のテンプレート構成」になります。
凄く端折った説明としては開発プロセスのベストプラクティスを詰め込んだテンプレートリポジトリのことになります。
いざ新規プロジェクトを立ち上げようとした場合に使用するライブラリやテスト、開発環境、CI/CDなど多岐にわたり、考えることがあります。
登壇者が、いま現時点で考えているゴールデンパスの要素の数々を紹介いたします。

サーバーレスはサービスの基板側にてスケールが想定されているため、
パフォーマンスがでやすいアーキテクチャだと考えます

しかしサーバーレスを採用しているからといって、
必ずしもすべてのアプリケーションが高いパフォーマンスを発揮するわけではありません

利用するのはもちろんPHPで、環境はAWS
サーバーレスにおけるパフォーマンスチューニングについて計測と分析を行い、
結果を元に改善する流れの実践法についてお話します

サーバーレスのパフォーマンス最適化のための実践的な知識を共有することで、
パフォーマンスチューニングを実践できるようになる手助けができれば幸いです

• お話する内容

  • AWSリソースの最適化戦略
  • コードプロファイリングと分散トレーシング

• 対象の聴講者

  • サーバーレスに興味がある人
  • パフォーマンスチューニングが好きな人

話者は普段PHPをBrefというOSSを利用してAWSにデプロイしています。

一方で第三者が構築しているアプリケーションに対する不安を感じる方もいるはずです。

そこで今回はAWSが構築を行っているAWS Lambda Web Adapterを利用します。
この手法によりPHPerの皆様がサーバーレスの利点を享受しつつ、
従来のWebアプリケーションをシームレスに移行する手法を身につける事が出来ます。

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

• お話すること

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

• 想定聴講者

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

昨今リアクティブなウェブアプリケーションが当たり前な世界となっています

そのリアクティブなウェブアプリケーションを支える通信技術に踏み込みたいと考えました

今回はPHPを使ってWebSocketサーバーを構築することで、具体的な手順からWebSocketの基本的な理解を深めます

実際に作ったリアクティブなアプリケーションのデモを通じてWebSocketのが生み出す強力なユーザー体験を、
PHPを通じて学びながら、PHPerとフロントエンドエンジニアを繋ぐ理論について共有が行えると幸いです

• お話すること

  • WebSocketサーバーをPHPで構築する手順
  • 構築したWebSocketとブラウザが通信を行うデモ

• 想定聴講者

  • WebSocketを知りたいPHPerとフロントエンドエンジニア
  • WebSocketを作りたいPHPer

プログラミング界の十徳ナイフ、正規表現を使いこなせていますでしょうか！
正規表現は文字列処理において多くのタスクをこなせ、テキストエディタなどPHP以外の場でも利用できる汎用性の高い道具です。

しかしながら正規表現を自信をもって使えるようになることにハードルを高く感じる初心者も多く、曖昧なまま使い続ける中級者も多い技術でもあります。

このトークでは初心者向けの正規表現入門から、中級者にも役立つテクニック、Unicodeとの関連と正規表現の罠まで含めて、基礎を固めて使いこなせるようになるヒントをお伝えします。

登壇経験ありません!

新卒エンジニアとして、まずは新人研修でLaravel 11をゼロから学び、実践的なプロジェクトを通じて必要なスキルを養いました。
その後、初案件では環境構築や画面設計、メインコーダーとして開発業務に挑戦しました。

技術者としてだけでなく、見積もりや顧客とのミーティング、要件定義、PMやチームメンバーとの認識の共有など、多岐にわたる業務を経験し、コミュニケーション力や調整力を大きく伸ばすことができました。
さらに、課題解決に向けたコミュニケーションやスケジュール管理、プレッシャーへの対応を通じて、プロジェクト完遂に必要なスキルを幅広く習得しました。

当日は、研修で取り組んだ内容から、初案件で直面した課題やそれをどう乗り越えたかについて、具体的な事例を交えてお話しします。
これからLaravelに挑む方や新卒エンジニアにとっても役立つリアルな体験談をお届けします！

約2年の間、私は新規プロダクトの開発責任者としてプロダクトの完成を目指してマネジメントを行っていました。

チームの発足当時、社内には該当プロダクトに関するドメイン知識がほとんどなく、「そもそもプロダクトとして成立するのか？」といったところの検証から繰り返しながらの進行となりました。

そのくらい不確かな出発点ですので様々なハードルに見舞われます。
増えゆく要件、進まない開発、ぶれるプロダクトの定義......。

しかし蓋を開けてみれば、特に本番リリースまでの半年間の間、社内の既存のどのプロダクトよりも生産性（ここではリリース頻度を指します）高く開発をすることができていました。

一体何が功を奏したのか？

本発表ではその要因となった考え方や具体的な取り組みを、新規プロダクト開発の試行錯誤の中で得た知見とともにお届けします。

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

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

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

モックを使ったメソッド呼び出しの検証方法
高度な引数の比較を使った柔軟なテスト
実務でのテストケースの実例紹介
Mockeryを使えば、テストのストレスが軽減され、もっとスマートにテストが書けるようになります！ぜひ参加して、PHPのテストを楽にする方法を学んでください！

わたしは十数年間この業界にいますが、いろいろなサービス層を見てきました。

• DB処理が大量に詰め込まれたサービス
• トランザクションスクリプトがひしめくサービス
• どこからでも呼ばれてしまう「神」サービス
• 複数のサービスと手を組み、仲良く連携するサービス
• ドメイン層を支えるサービス
• 取り急ぎ作られた「なんちゃって」サービス

そこには、愛らしいサービスもあれば、目を背けたくなるサービスもいました。
そしてこう思うのです「人には人それぞれのサービス層がある」と。

なぜ、人はみなそれぞれのサービス層を作ってやまないのか謎に迫りつつ、

• サービス層とはそもそも何なのか
• 憎まれるサービス、愛されるサービスとはなにか
• 理想のサービス層とはどんな姿をしているのか

について、SOLID原則、特にSRPを切り口として理想的なサービス層について考察したいと思います。

みなさん、モックは好きですか？わたしは好きです。
外部依存から隔離してテストの実行を容易にしたり、テストを高速化できるからです。最高。

ですが、わたしが観測している限りどうやらモックというのはテストが壊れやすくなるので、なるべく使わない方がいいという風潮も耳にします。
ではテストが壊れにくければモックは使っていいのでしょうか。モックを使うとテストが壊れやすくなるのでしょうか。善いモックというのは無いのでしょうか。

そういった疑問を解消すべく、果たしてモックは悪いのか、善いモックというのはあるのか、モックの使い方はどうあるべきかをお話できればと思います。

キーワード

• 壊れやすいテストとは何か
• 実装の詳細が漏れるとは何か
• ロンドン学派vs古典学派
• アウトサイドインvsインサイドアウト
• モック、スタブ、スパイ
• モックとしての振る舞いとスタブとしての振る舞い

本セッションは、Laravelを使って現場でCIをぶん回すエンジニアを対象に、CI/CDパイプラインのベストプラクティスを紹介します。

PHPUnitとParatestなどを活用し、テスト時間を短縮しつつ、GitHub Actionsでコストパフォーマンスを最大化する方法を具体例とともに解説します。

⚪︎ CIの高速化
⚪︎ 効率的なリソース管理
⚪︎ カードで必要な変更

を交えつつポイントを共有します。

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

このトークでは、ドメインイベントを使ってPHPコードをリファクタリングする方法についてお話しします。ドメインイベントは、ビジネスドメインで発生する「出来事」を表現するモデルで、これをうまく使うことで、副作用をわかりやすく整理し、システムをシンプルにできます。

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

話すこと

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

OOP はクラスやオブジェクトというものを前提としています。また、「抽象化」や「一般化」「共通化」というような用語がプログラミングでは普通に使われます。
OOPの設計・実装では「こう書けば後からうまくいく」式の解説ばかりですが、その実OOPの本質に立ち向かったものは少ないのではないでしょうか。

本発表では、西洋哲学の知恵を借りてOOPという営みを捉え直すというチャレンジをします。
最初に「クラスはプラトンのイデア論に似ている」というOOP界隈で真っ先に言及されるこの命題が真か偽か考察することから始めます。
プロポーザル執筆時では、プラトン、アリストテレス、カント、ウィトゲンシュタイン（後期）には言及する予定です。
なお、アラン・ケイの考えていた本当のオブジェクト指向にも言及する予定です

■ 発表内容
「オブジェクト設計スタイルガイド」という書籍の良さについて熱弁します。

スタイルガイドという名前がついているものの、その実はOOPの設計のベストプラクティスを集めた設計・実装集です。
この本は頭から一つずつ書き方を見ていくだけで、自然と以下の重要概念が身につく優れた書籍なのです。

・サービス層とドメイン層の違い
・SOLID原則
・クリーンアーキテクチャ
・CQS（コマンドクエリ分離原則）
・エンティティ・バリューオブジェクト（もちろんミュータブル・イミュータブルの考え方も）
・ドメインイベント
・DI
・リファクタリング

OOPのベストプラクティスを学ぶことができる新時代の「リーダブルコード」と言っても過言ではないでしょう

チームでこの本の読書会を実施しているので、そこで出てきた「現場の意見・疑問」もお伝えします（発表時には終了予定）

このセッションでは、PHP ユーザ向けに OpenTelemetry を導入して、PHP アプリケーションを計装する手法について解説します。OpenTelemetry は、サービスやアプリケーションのテレメトリーデータ（トレース、メトリクス、ログなど）を収集、送信するためのオブザーバビリティフレームワークです。ベンダーニュートラルな OSS であり、PHP 版 SDK も提供されています。これを利用することで、PHP アプリケーションの動作を外部から観測することができます。手軽に利用できるので、オブザーバビリティツールの最初の一歩として触ってみるのも良いでしょう。

本セッションでは、OpenTelemetry SDK の導入、手動計装と自動計装、OTel Collector の活用によるテレメトリデータの送信、ローカル環境と本番環境でのセットアップなどについて紹介します。

例外処理って「エラーをキャッチするもの」と思いがちですよね？
でも、実はもっと重要な役割があります。例外を使うことで「自分のコードがどこまで責任を持つべきか」を明確にし、処理を他に委任することができるんです。

このセッションでは、例外を活用してエラーハンドリングを整理し、過度なキャッチによるコードの複雑化を防ぐ方法をお伝えします。
さらに、フレームワークが担うべき役割や、ビジネスロジックを表現するカスタム例外の作り方も紹介します。

ぜひチームでのディスカッションに活用してみてください！

話すこと

• 例外の型の使い分け
• ビジネスロジックを表現するカスタム例外
• 例外をハンドリングする方法

　PM Aさんこれから一緒にプロジェクト頑張ろうね
私は初めてプロジェクトに参画することになった
　PM じゃあ次Aさん進捗どうですか？
進捗を聞かれてもいつでも答えられるし、開発はスケジュール通り開発できている。何も問題はない。
　PM Aさんいつもオンスケで助かるよ。お陰でプロジェクトも順調だよ。次この機能開発してくれる？
プロジェクトのことはよくわからないけど、プロジェクトも順調らしい。
「あれ？でも、この機能って前にやった機能といっしょに開発したほうが早かったな。それに前カンファレンスで聞いた〇〇って技術使えばもっといい感じにできたかもな。」
「でもテックリードでもPMでもないし、機会が回ってきたときでいっか」
本当にそれでよかったのでしょうか？
本セッションでは、メンバー目線での情報がプロジェクトの成功にいかに重要であり、メンバーだからこそ貢献できるテクニックを話します。

現代において、エンジニアの仕事は常にチームで行われます。
チームで仕事を進める以上、他人との「意思疎通のスピード」が、チーム力に直結してしまいます。

チーム力を上げるために、組織ではさまざまな施策が実施されているかと思いますが、エンジニア個人でできる意思疎通のテクニックについて考えたことはないでしょうか？
チームで行われているコミュニケーション施策に乗るだけでなく、自らコミュニケーションを円滑に進められるよう能動的に動くことで、チームの力をもっと上げることができます。

本発表では私が仕事で実践している内容をもとに、明日から使えるチーム力向上を目指したコミュニケーションのテクニックと考え方をお伝えします。
これを聞けば、明日チームメイトから「ちょっと変わったね」と言われること間違いなし！