トーク

文字コードがEUC-JPのソースコード編集で直面した問題とその解消法に着いて話します。

話すこと

• なぜソース編集しただけで文字化けが起こるのか
• git diff をちゃんと見よう
• pre-commit hookで安心を得よう

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

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

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

さらにシステム設計における現実的な課題として、データ同期の遅延や書き込み負荷の増加についても触れ、
最終整合性の採用やSQSによるリクエストのバッファリングなどの解決策を提示し、生成AIを用いた学習コストの低減についても触れます

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

• 対象者

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

• 想定学習成果

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

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

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

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

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

• 対象者

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

• 想定学習成果

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

• 話さないこと

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

Laravelのoptional()関数を使ったことはあるでしょうか？
Nullである可能性のあるオブジェクトに対してoptional関数を用いることで、nullでない時はオブジェクトの動きをさせ、nullの時はnullを返させることができるようになります。

optional関数を使って実装していたある日、ふと「どのようにして動いているのか」が気になりました。
調べてみると、Null Objectパターンというものを使って実装されていることがわかりました。

このトークでは、簡単なNullオブジェクトを自作することで、optionalがどのように実現されているのかを見ていきます。

話すこと

• optional関数の説明
• Nullオブジェクトの実装方法
• Nullsafe operatorとの比較

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 内部の実装を見ていきます。

「とりあえず削除フラグ」という言葉を、耳にしたことがある方は多いかと思います。
削除フラグは、データを物理的に削除せず、論理的に削除された状態を示す方法で、一般的にデータベース設計で使用されます。
これはデータベースのテーブル設計におけるアンチパターンとして、数多くの技術書で取り上げられているものです。
一般に、論理削除の実装方法としてフラグをテーブルに持たせるのは推奨されていません。論理削除を本当に採用すべきかどうかを慎重に検討するべきです。

それはそうなんですが、アンチパターンって実際に踏み抜いてみないと何でダメなのかわかりにくくないですか？
今回私は、既存のテーブルにあった削除フラグを安易に利用してしまい、想定外の箇所でもトラブルが発生し、改めて削除フラグの利用は慎重にしたほうがいいんだな、と
痛みを伴いつつも理解したので、みなさんには擬似的な痛みだけで済むように何が起こるのか、どんな状況だったか、どうすればよかったのか？などを説明します。

現在、我々のプロダクトではDDD（ドメイン駆動設計）とレイヤードアーキテクチャを採用しています。
しかしメンバー変更や技術的制約などの背景から、コントローラにビジネスロジックが散らばる・重複判定がDBのキー制約に依存しているなどの課題が発生しています。
これにより、コードの凝集性が損なわれ、責務が不明確になり、保守性や拡張性の低下を招いていました。

本トークでは、「ビジネスルールのうちどこまでをドメインモデルで担保すべきか？」という問いを中心に以下のポイントをお話します。

• ビジネスルールが散らばることでDRYやSOLID原則に反してしまい、結果起こり得るリスクと影響
• ドメインモデルに担保させるべき責務の境界線はどこまでか
• 責務を整理し、ドメインモデルを中心とした設計を再構築するための”Package By Feature”などの具体的なアプローチ

このセッションを通じて、ドメインルール整理の重要性を理解し、設計上の責務分担を考える時の具体的な指針を共有し、皆様のプロジェクトに役立てていただければ幸いです。

概要

私たちのチームが手がけるLaravelで構築されたサービスは、Layered Architectureを採用しており技術ごとにクラスやフォルダを分けていました。
6年以上運用されているこのサービスでは、アプリケーションの拡大に伴いディレクトリ構造が複雑化し、新機能追加時に複数のレイヤーにまたがる変更が必要となるなど、コード修正の困難化や影響範囲の肥大化といった課題に直面していました。

この課題を解決するために、私たちは機能ごとにクラスやフォルダを分離する考え"Package by Feature"という設計手法を採用しました。
本トークでは、術ごとの分離ではなく、機能ごとにコードを分離することで得られるメリットと、その実践例を実際の適用事例を通して共有します。

話す内容

• 機能単位でコードを分離するアプローチの概要とその目的
• 技術単位での分離との比較による利点
• 機能単位でコードを分離することで、他の部分への影響がどのように最小限に抑えられ、テストやデプロイまでがどれほどスムーズになったか
• 直面した具体的な課題と、それに対する解決策
• 複数の"Feature"間でデータやロジックを共有する必要がある場合の具体的な対処法と実例

本トークを通じて、よりスケーラブルで保守性の高いコードベースを構築するための手がかりを共有できたら幸いです。

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

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

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

PHPは型安全性の向上を目指して進化していますが、ジェネリクスを直接サポートしていないため、柔軟性と安全性を両立するには工夫が必要です。その解決策のひとつが、PHPDocの@templateタグを活用してジェネリクスを再現する方法です。

このセッションでは、PHPDocの@templateタグを活用してOption型を実装する具体的な手法をお伝えします。
Option型は、Rustなどの言語で採用されている設計で、値の存在（Some）と不在（None）を型で表現します。

これをPHPに応用することで、次のようなメリットを得られます：

• 型安全性の向上によりバグのリスクを軽減
• nullチェックの削減でコードの可読性を向上
• 設計が明確になり保守性が向上

本トークを通じて、PHPDocを活用した型安全性の向上方法を学び、実際の開発に役立てていただければと思います。
PHPDocで型システムを最大限に活用しましょう！

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

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

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

技術系の資格取得にチャレンジしていますか？
「エンジニアには資格は不要」という声も多い中、資格を取ることの意義について悩む方も多いのではないでしょうか。

本LTでは、営業職から未経験でエンジニアに転身し、さらにEMとしてキャリアを築いた私の経験を踏まえ、資格取得がどのようにキャリアを加速させたのかをお話します。

新たな業界への挑戦や社内で新たな役割を担う際、資格取得を通じて得た知識と自信が、新しい領域へのチャレンジを後押ししてくれました。

このLTを通して、一人でも多くの方が資格取得に興味を持っていただけると幸いです。

対象者

• 資格取得に意義を見出せずにいる人
• キャリアアップや新しい役割に挑戦したい人
• 未経験からエンジニアを目指している人

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 ライフを過ごしませんか？

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での開発をした経験はあるでしょうか？
現在では、Laravelなどの便利なフレームワークが多数あり、業務で使うPHPは専らフレームワーク上のもの、ということもあるかもしれません。

私は、非フレームワークなPHPを使って、リバーシや物理エンジンなどを作って遊んでいます。

フレームワークを使わないPHPでは、本で見た設計を柔軟に試せたり、必要なパッケージをミニマムな状態で試せたりなど、独特の学びがあります。

レールは自分で敷く、そんな開発を体験してみませんか？

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

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

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

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

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

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