CQRSは、読み取り操作と書き込み操作を分離することでシステムの効率性を向上させる設計パターンです
本来は大規模で複雑なシステム設計で用いられることが多いですが、あえて小規模・シンプルなケースでCQRSを採用した場合、その真価をどのように引き出すことができるのでしょうか？

このセッションではAWSのサーバーレスアーキテクチャを活用することで問題解決に取り組みます
複雑さを抑えつつ柔軟性と拡張性、コストメリットと実装コストのバランスを考え小規模システムにおける適用の実装例を提示を行います

具体的には、DynamoDBをデータストアとして活用し、DynamoDB StreamsやAWS Lambdaを組み合わせることで効率的なデータ同期を実現します
またAPI Gatewayを使用したデータ提供やAWS X-Rayを用いたモニタリングによる運用の最適化も触れ、シンプルなユースケースでも長期的なコストメリットを享受できる設計が可能になります

AWSを活用したCQRSの実装例を通じて、シンプルなケースでも有効な設計手法を学び、シンプルなシナリオでもCQRSを採用する意義を再発見しましょう！

• 対象者

  • CQRSに興味があるエンジニア
  • サーバーレスアーキテクチャの導入を検討している方
  • 小規模システムでのコスト効率を追求したい開発者

• 想定学習成果

  • CQRSの基本的な考え方とサーバーレスを利用した実装方法を理解
  • 小規模システムにおけるCQRS導入の具体的メリットと課題を把握

• 話さないこと

  • 課題に対する細かな解説と考察内容
  • 実装に対する細かな解説（GitHubでのソースコード解説を用意します）

opentelemetry 拡張では任意の関数やメソッドをフックして、実行前後に PHP コードを差し込むことができます。つまり、DB への SQL 文発行や外部 API 呼び出しなどの実行をフックして計測コードを追加して計測を行っています。この機能は自動計装で有効であり、いくつかの自動計装パッケージではこの機能が利用されています。

PHP は内部の主要な関数が関数ポインタとなっているので、内部処理を差し替える、いわば内部動作をハックすることでこうした機能は実現可能でしたopentelemetry 拡張ではどのような仕組みで動いているのだろうと調査したところ、PHP 8 から追加されている Observer API （通称）で実現されていることが分かりました。Observer API を利用することで内部関数を差し替える事なく、関数やメソッドをフックする処理を追加できるようになっています。

この仕組みは PHP 内部で実装されているものなので、PHP コードから直接利用することはできません。つまり、独自に PHP 拡張を実装するか、opentelemetery 拡張のようにすでに実装されているものを通じて利用することになります。実は、opentelemetry 拡張以外にも Datadog の PHP 拡張である dd-trace では Observer API が利用されており、間接的に利用している人もいるかもしれません。

このセッションでは、PHP の Observer API という興味深い機能に焦点を当てて、その動きや PHP 内部の実装を見ていきます。

PHP開発者の皆さん、普段から使用しているvar_dumpやvar_exportの関数について、内部でどのように動作しているのかを考えたことはありますか。
このトークでは、これらの関数の違いを簡単に紹介しながら、PHPのソースコードをC言語でどのように実装しているかを一緒に読み解いていきます。

var_dumpとvar_exportは、あらゆる変数を扱える強力なツールです。これらを詳しく読むことで、PHPの型や変数がどのように動作しているのかを深く理解することができます。
具体的には、php-srcのvar.cファイルやZendのマクロ関数を順に追いながら、PHPの細かい仕様について紐解いていきます。

このセッションは、php-srcのソースコードリーディングを初めて体験したい方や、過去に挑戦したことがあるけれども細部まで追ったことがない方を対象にしています。
このトークを通じて、PHPの詳細な仕様を理解するために「php-srcを直接読みに行く」という選択肢が広がることを願っています。

デザインシステムって「ルールの塊」や「UIライブラリ」みたいなイメージを持ちます。でも実際は、それだけではありません。デザインシステムの本質は、 運用を含む仕組み にあります。

たとえば、デザインレビューを通じて品質を保ったり、デザイナーとエンジニアでフィードバックをし合いながら改善を続けたり、変更があったときにガイドラインやドキュメントを更新して全員が迷わないようにしたり。これらの運用があってこそ、デザインシステムは単なるルールやライブラリから「使えるシステム」に進化していきます。

このセッションではプロジェクトでデザインシステムを立ち上げた経験を元に「どう作るか」「どう運用するか」をエンジニア視点でのポイントを紹介します。

Webサービスの開発で、認証・認可が必要になる場面が多々あると思います。
Laravelで認証・認可を実装しようとすると、Laravelが提供しているライブラリだけでもFortify、Sanctum、Passport、Socialiteなどなどたくさんの選択肢があります。
各ライブラリの具体的な特徴や、どのような状況で使用すべきでしょうか？

本トークでは、それぞれのライブラリの違いや使い所を紹介します。

システム開発の現場ではヒューマンエラーによるシステム障害・トラブルは避けられない課題です。
うっかりミスで損害を出してしまったときに再発防止を図る際に「今後はもっと注意する」では実効性もなくビジネスサイドからの納得も得られません。
一方で製造業から輸入された「なぜなぜ分析」は「なぜ」を5回繰り返すという単純な方法で広く普及しましたが、簡単過ぎる故に本来の問題事象への対策検討という目的に反して個人攻撃に使われてしまう現場もあり、辛い思いをされた方もいるのではないでしょうか。

本トークでは、IPAの先進事例を元にヒューマンエラー分析手法と効果的な対策を紹介します。
ヒューマンエラーを時系列と要因分析により事実関係を把握し、対策発想マトリクスによって個人を責めることなくバグを生み出した環境を改善することを目指します。

話すこと

• なぜなぜ分析の何が良くなかったのか
• スイスチーズモデルによる事故発生メカニズムの理解
• 他業種における問題分析の紹介
• 個人への責任追及ではなく、システム改善に繋げるための分析手法
  • ヒューマンエラー分析手法の５つのステップ

AWS CDKでサポートされていないPHPでInfrastructure as Code的なことをやるとしたら？という興味とその実装が本発表の論点です。
AWS SDK for PHPから提供されるクラスを使用して全てのインフラリソースをコード化し、その場合の構成管理や関連するAWSとPHPの知見を共有する内容になります。
今回のインフラ構成の題材としては、下記のサービスを使用したシンプルなServerlessApplicationを考えています。
APIGateway, Lambda, DynamoDB, EventBridge, IAM

扱いたいトピック

• SDK for PHPから提供されるクラスの概要
  • Aws\ApiGateway\ApiGatewayClient
  • Aws\Lambda\LambdaClient
  • DynamoDb\DynamoDBAttribute
  • Aws\EventBridge\EventBridgeClient
  • Iam\IAMService
• ServerlessApplicationの基礎とSDK for PHPでの実装コード
• AWS CLIから発生するログの読み解き方
• SDKで作成するリソースのResourceName重複を避けるロジック（CDKなら書く必要がないが）
• インフラリソースのSDKによるライフサイクル管理（CRUDの実装）

PHPユーザーがあまり使わないクラスの使用例を挙げつつ、楽しくPHPとAWSについてを学べるセッションにできればと思います

PHP のアップグレードしたけど、既存コードを新しい構文へ更新する時間がない。
そんな悩みありませんか？

えんさがそっ♪ でも、PHP のアップグレードを随時実施していますが、新しい構文への追従が十分にできていませんでした。
単純にリファクタリングする時間を確保できなかったからです。
しかし、そんな課題を解決してくれる神ライブラリを発見しました。その名は...rector！

rector を使えば、従来なら数週間かかるリファクタリング作業をわずか数分で完了させることが可能です。
さらに CI へ追加することで、自動的にリファクタリングしてくれる優れもの！
これにより、継続的なレビューの効率化やコードの品質向上も期待できます。

皆さんも快適な rector ライフを過ごしませんか？

本番環境のプロファイルを継続的に取得する継続的プロファイリングは、ログ・メトリクス・トレースに続く可観測性ツールにおける4つめの柱として近年注目を集めています。
Datadog や Blackfire などの商用サービスもPHP向けの継続的プロファイラをリリースしており、PHPアプリケーションのモニタリングでも今後さらに注目されていくことでしょう。

さて、OSS の可観測性ツールとしてとても人気がある Grafana を開発する Grafana Labs は 2023 年、Pyroscope という継続的プロファイリングツールを買収しました。
私も Grafana を使っているので、Grafana で PHP アプリケーションのプロファイルも監視できるようになるのでは？と思ったら、なんと Pyroscope は現在 PHP に対応していません😭

「Grafana で PHP アプリケーションのプロファイルが見たい！ Grafana にメトリクスやトレースと一緒にプロファイルが並ぶかっこいい画面が PHP でも見たい！」
この夢を叶えるために、PHP プロファイラである xhprof のプロファイル結果を Pyroscope で受け取れる形式に変換するライブラリを自作しました。

本トークでは、

• PHP プロファイラ（ xhprof, phpspy など）の仕組み
• xhprof のプロファイル結果を Pyroscope に送る方法
• 継続的プロファイリングによる PHP アプリケーションのパフォーマンス改善
  についてお話しします。

本トークを通じて、

• 継続的プロファイリングを使ったパフォーマンス改善の明日役に立つ実践的な知識
• PHP プロファイラの2種類の仕組みや pprof フォーマットについての明日役に立たない豆知識
  をお届けできれば幸いです。

LaravelとInertia.jsによるモダンなフロントエンド開発において、Vue3 Composition APIを活用した保守性の高い設計パターンを解説します。
Composablesパターンによるロジックの再利用性、Laravelのバックエンドとの効率的な統合、テスタビリティの向上について、実装例を交えて紹介します。
Inertia.jsは、モノリシックとSPAのベストプラクティスを融合させた革新的なアプローチです。フロントエンドが複雑化する中で、開発者は保守性の高いコードベースの実現に課題を感じています。

本セッションでは、LaravelとInertia.js、Vue3の実践的な組み合わせに焦点を当てます。特にComposition APIを活用したComposablesパターンにより、ビジネスロジックの再利用性を高め、テストしやすいコンポーネント設計を実現する方法を解説します。フォームハンドリング、状態管理、APIリクエストなど、実際の開発現場で直面する具体的な課題に対する解決策を、実装例を交えながら紹介します。

Laravelの強力なバックエンド機能とVue3の洗練されたフロントエンド機能を最大限に活かし、保守性と開発効率を両立させる設計パターンを、ぜひ一緒に探求しましょう。

Laravel 11で導入されたStreamlined Application Structureの主な特徴と利点を詳しく解説します。

新しいbootstrap/app.phpの役割や、変更されたディレクトリ構造、
そして一元化された設定管理がプロジェクトにどのような影響を与えるのかを紹介します。
はたして設定や構成の管理が容易になるのか、コードの可読性と保守性が向上するのか、といった観点を交えながら、
既存のプロジェクトへの適用方法についても共有いたします。
さらに、これらの変更が実際の開発プロセスにどのように寄与するのかを探っていきます。

新しいアーキテクチャを自分のプロジェクトに効果的に取り入れるためのヒントになれば幸いです。

PHPはCGIからPHP-FPMへと実行環境を移行し、最近ではFrankenPHPが登場しました。
本セッションでは、PHP実行環境の歴史を振り返り、初期のCGIからPHP-FPMへの進化過程を簡潔に解説します。
また、各環境の移り変わりにより、パフォーマンスやスケーラビリティ、セキュリティがどのように改善されてきたのかを具体例を交えて紹介します。
さらに、最新技術として登場したFrankenPHPの誕生背景やアーキテクチャ、特徴を紹介し、PHP-FPMとの比較を通じてそれぞれの利点と欠点を明らかにします。
本セッションを通じて、プロジェクトに最適な実行環境を選択するための基礎知識と視点を提供できれば幸いです。

想定聴講者

• 会計システムや EC サイトなどでお金を扱う開発をしている人
• PHPのstring, float, intがどのように相互変換されるのか挙動に興味がある人
• 設計に興味がある人

話すこと

• PHPでstring, float, intを相互変換するとどのような問題が起きるのか、どのように実行されているのか
• センシティブな数値を扱う時、どのように扱うべきなのか

話さないこと

• 既存の技術選定について
• 既存システムの苦悩と戦いについて

普段開発している時はあまり意識せずに数値を型変換することがあると思いますが、そこには思いもよらぬ潜在的なバグに繋がる挙動が潜んでいます。

会計システムを作る時にPHPの数値仕様をしっかり理解した上で作らないと、後々大変なことになってしまう可能性があります。
小数点以下の誤差によって1円が消えたり増えたりしてしまうことがあり、1円の行方を巡って終わりのない、解決もしない調査の旅に身を投じることになるでしょう。
それが今なのか、いつなのかは分かりませんが、知っていれば防げる問題でもあります。

本セッションでは数値にはどんな問題があり、扱う時に何を気をつける必要があって、さらに扱いやすくするためにおすすめの方法をお話しします。

依存性注入(DI)は、単体テストを書きやすくして、変更容易性を上げるために有効なアプローチです。また、Laravel等のフレームワークでも使われており、その動作を把握するためには、DIの理解が必要になります。

しかし、学び始めたタイミングでは直感的ではないため、難しく感じることもあるかもしれません。

このトークでは、依存という概念を「使う・使われる」という、簡単な言葉で整理して、理解しやすくすることを目標とします。

話すこと

• 「依存している」とは「使っている」ということ
• 依存すると何が困るのか
• 依存を外から与える(注入する)メリット
• DIの実装例

近年、プロダクト開発におけるフルサイクルエンジニアリングの重要性が高まっています。これに伴い、バックエンドエンジニアがフロントエンドスキルを習得するニーズも増加しています。しかし、フロントエンドの学習に対して「自分には難しい」という心理的なハードルを感じる方も多いのではないでしょうか？

本セッションでは、オブジェクト指向プログラミング（OOP）の知識を土台に、Reactを使ったフロントエンドの基本的な考え方をわかりやすく解説します。バックエンドエンジニアが親しみやすいOOPの概念と、Reactの「コンポーネント指向」の類似点や相違点を比較しながら、フロントエンドの基礎的なメンタルモデルを解説します。

具体的には以下の内容を取り上げます。

・OOPとReactの共通点と違い: クラスとコンポーネント、オブジェクトグラフとUIツリー、MVCとFluxの対応を具体例を用いて比較。
・状態とイベントの管理: React Hooks (useState) を使った状態遷移を解説。

これらをブログの記事「Articleクラス」と「Articleコンポーネント」を比較して解説します。

短時間でフロントエンドのエッセンスを把握することを目指すこのセッションを通して、「フロントエンドもできるエンジニア」を目指す一歩を踏み出すきっかけをお届けします。

OSSへのコントリビュートは敷居が高いと感じていませんか？「何から始めればいいのかわからない」「自分のスキルでは貢献できない」といった壁を感じる方も多いでしょう。
しかし、自分のプロダクトのPHPのバージョンアップ作業をきっかけに、自然とOSSにコントリビュートを始めることができます。

本セッションでは、以下の内容をお話しします：

PHPのバージョンアップで直面した課題とその解決方法
バージョンアップ作業を通じてOSSプロジェクトにフィードバックを返す方法
初心者がOSSコントリビュートに取り組むための具体的なステップ
実際の体験を交えながら、どのようにOSSコントリビュートを「ハードルの高いもの」から「身近なもの」に変えられるのかをお伝えします。PHPのバージョンアップは単なる技術負債解消にとどまらず、コミュニティ全体の改善に貢献する第一歩でもあります。
初心者でも始められるシンプルな方法を知り、開発者としての新たな一歩を踏み出しませんか？

皆さんOpenSearchを活用してますか。

自社プロダクトのパフォーマンスを上げるためにAmazon OpenSearch Serviceを採用してます。
今まで事業部の人が事業運営する上で欲しいデータをエンジニアが直接DBから抽出して、都度共有していました。
OpenSearchからじゃないと取得しづらいデータがあり、そのデータが必要になるたびにエンジニアが稼働していました。
そこでエンジニアの負担を減らすために誰でもGrafanaからデータを見れるようにしました。

実際に可視化する上でつまづいた点を実践的なステップで紹介します。

本LTが参考になる人
・可視化する上で選択肢として何があるのか分からない
・どういう観点でデータを可視化すべきか分からない
・AWSアカウントを跨いでデータを可視化したい
・データを可視化するためだけでOpenSearchを外部公開したくはない

本LTを通じて、皆さんもOpenSearchとGrafanaの翼を授かって、新しい世界に羽ばたきませんか？

私はEM1年生。 2024年4月に新規プロダクトをリリースし、現在はそのプロダクトをなんとか成長させていくべく邁進しています。

新規プロダクトのリリース、そしてその後のグロースにあたってはさまざまな進行上の課題がチームに襲い掛かりました。

・ スクラムを解釈した開発イベントがなぜかうまくいかない
・ 社内や社外からのフィードバックが集まらない
・ プロダクトマネージャーとタスクの温度感がすり合わない
・ プロダクトの課題が無限に積まれ、さばいてもさばいてもなくならない
......

これらの課題が発生した背景には、新規プロダクト開発においてはフェーズごとに求められる立ち回りが大きく変化するというものがありました。

本セッションではそのような状況に対応するため、繰り返し見直し、変更・改善してきた開発手法の変遷について、良かった点と反省点の両軸から振り返ります。

「どのような開発手法を採用すればいいか分からない」、「なぜだか現状の開発手法がしっくりきていない」といったお悩みを抱える方へ、
実践的な改善方法やそのヒントとなる知見をお伝えできたら幸いです。

画面開発で、こんな悩みを抱えていませんか？

• 画面ごとに統一感のないデザイン、曖昧なレビュー基準に振り回される
• 開発のたびにゼロからデザインとコーディングを繰り返す
• CSSの保守性が低く、改修のたびに手間がかかる

例えば、新しい画面が追加されるたびに微妙に異なるUIが作られたり、レビュー時に明確な基準がないことでデザインの決定が長引いたりした経験はないでしょうか。こうした課題が積み重なると、チーム全体の開発効率やモチベーションが著しく低下してしまいます。

これらの課題に対する解決策として、「デザインシステム」を導入しました。

今回のトークでは、既存のデザイン案を基に、FigmaやStorybookなどのツールを活用しながらデザインシステムを整備し、プロダクトへの導入を進めた一連の取り組みをご紹介します。

話す内容

• デザインシステムとは何か
• 導入に向けた具体的なステップ
• 導入前の課題と導入後に得られた効果
• 導入が進まなかった要因と成功に繋がった工夫

こんな方におすすめ

• 画面開発で課題を感じているエンジニア、UI/UXデザイナー
• レガシーなフロントエンド構成に悩んでいる方
• デザインシステム導入に興味がある方

トークを通じて、みなさんの開発現場でも役立つヒントをお届けできればと思います。

世の中には大小様々な企業があり、多様なチームが存在すると思います。
カンファレンスに参加されているみなさまはよいチームビルディング、よいチームを形成しているところに所属されていることが多いのではないでしょうか？

しかし、「よいチーム」とは現時点でも氷山の一角であると、現実で直面する場面は多いのではないでしょうか？
私も様々な現場を歩いてきた身として、多くの「よいチーム」「わるいチーム」というのを見てまいりました。
そういった現場では良いも悪いも関係なく、レガシーコードと向き合う機会が必ずやってきます。
さて、ご自身のチームはレガシーコードに立ち向かうことはできる「よいチーム」となっているでしょうか？

今回私がご提唱するのは、レガシーコードに取り組むのであれば、最初にチームを改善することで何が変わっていくのか、というものでお話をさせていただければと思います。

話すこと

• レガシーコードコードとは
• 「よいチーム」ってなに？
• 会社は「文化」、チームは「規約」
• 本題（レガシーコードの前にチームを改善する）

話さないこと

• 詳細なコードの事例とか

想定聴講者

• チームに不満を持っている人
• 昇格したチームリーダー、マネージャー
• レガシーコードにこれから立ち向かおうとしている方