プロポーザル

文字コードが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との比較

php-fpm は PHPアプリケーション の実行環境として広く利用されていますが、その内部処理についてご存知でしょうか。

PHP プログラマから見ると、php-fpm はランタイムですが、php-fpm 自身は単に C 言語で実装されたアプリケーションにすぎません。これは我々が日頃から実装している PHP アプリケーションと領域や抽象度は異なりますが、一つのアプリケーションであるという点は同じです。

ただ、php-fpm ではより低いレイヤを扱っています。これは PHP アプリケーションレベルでは隠蔽されている処理が実装されているともいえます。普段、PHP コードを書くだけであればこうした底レイヤを意識する必要はありません。しかし、こうした下のレイヤがどのように動作しているのかを知ることはより深く PHP とそして自らが書いた PHP コードの挙動を理解することができます。そして、何より自分が書いたコードが内部でどのような仕組みで動いしているのかを知ることは楽しいものです！

本セッションでは、一歩レイヤを下りて、php-fpm がリクエスト受信から PHP アプリケーションを実行してレスポンスを返すまでの流れを内部実装やデバッガを元に追いかけてみましょう。

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

Web アプリケーションのセキュリティ設計において、特定のユーザーに対してどの操作を許可するかという認可の設計は欠かせない要素です。近年では、マイクロサービスやゼロトラストの考え方が普及し、サーバー間の認可を含むより複雑な機能が求められています。

このような複雑な認可を効果的に管理する方法の一つとして、認可ロジックをアプリケーションから分離し、外部化して再利用可能なポリシー言語で定義する手法があります。AWS IAM はこのようなポリシー言語の一例ですが、AWS に限定されない一般用途にも Open Policy Agent (OPA) が広く知られています。

本セッションでは、認可の課題に対する新たなキラーソリューションとして、Cedar を紹介します。Cedar は AWS によって開発されたポリシー言語で、Amazon Verified Permissions としてマネージドサービスが提供されているほか、AWS 以外の環境でも使用可能な OSS としても公開されています。

OPA と比較した Cedar の顕著な特徴は、大量のルールを定義した場合のパフォーマンスにあります。このパフォーマンスは、一度評価された条件を部分的にキャッシュし再利用する仕組みにより実現されており、そのキャッシュ戦略の正当性は数学的に厳密に証明されています。このように、Cedarは高度な理論が実際のプロダクトに価値を提供する興味深い事例といえるでしょう。

Cedar は 2024 年に論文が発表されたばかりであり、理論的な詳細に関する日本語情報はほとんど存在しません。そのため、本セッションでは参加者が認可エンジンの内部機構と特性を深く理解し、実際のアプリケーションのセキュリティ設計に役立てられることを目指して、Cedar に対して応用と理論の両面から Deep Dive します。

PHPで大量データを扱う際、コードが正しく動いていても、パフォーマンスの低下が発生し、ユーザーの離脱につながったりすることがあります。
本トークでは、私たちのプロジェクトで直面した「strposによる文字列検索が原因で処理が30秒以上かかった」事例をもとに、計算量の重要性とパフォーマンス最適化についてお話しします。

問題の背景は、数千件の文字列を1件ずつ、約1万件の集合と照合する処理でした。
文字列の部分一致のチェックをstrposで実装していましたが、線形検索（O(n)）のため、1回の検索がミリ秒単位でも、繰り返し処理が積み重なり、最終的には数十秒に達しました。
処理の遅延が原因でタイムアウトが発生し、ユーザーが機能を使えない危機に直面しました。

解決策として、array_flipとarray_key_existsを用いて、検索処理をハッシュベース（O(1)）に変更することで、処理時間を30秒から約6秒に短縮しました。
この経験を通じて、パフォーマンス問題を解決するには計算量の意識が不可欠であると学びました。

このように、1回の処理がわずか1ミリ秒遅延しただけであっても、大規模データでは致命的な影響を与える可能性があること、計算量や計算時間が特に大事になってくることを学びました。
このようなパフォーマンス改善は、ユーザー体験を向上させ、機能の価値を最大化するための重要なステップです。
ユーザーが快適に使える環境を提供するため、私たちエンジニアが取り組むべき課題を一緒に考えてみませんか？

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

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

現在、我々のプロダクトでは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を直接読みに行く」という選択肢が広がることを願っています。

SOLID原則・凝集性・結合度・関心の分離・DDD・クリーンアキテクチャ...
設計を考える際、学ぶべき原理や手法が多すぎて圧倒されてしまうこともありますよね。

しかし、これら設計原則には、「英語の文法」にヒントが隠されているかも...?
英語文法の基本ルールに着目することで、設計原則を詳しく知らなくても、シンプルで明確な設計を行うための手がかりを得られるかもしれません！

このトークでは、SVO・SVOCなど基礎的な英語文法がどのようにコード設計に応用できるかを具体的に解説します。

• S(主語)やV(動詞)の明確化が単一責任原則の遵守に繋がること
• 「S(主語)がV(動詞)した」とクラス設計を考えることの恩恵
• コード上での形容詞・副詞の在り方

想定聴講者

• ソフトウェア設計に詳しくはないが興味を持っている方
• 設計の原理や手法が多くてなかなか手を出せずにいる方

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

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

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

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

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

重複送信のため削除

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

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

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

組織によっては、フロントエンドの専門エンジニアがいないケースも多く、バックエンドエンジニアがフロントエンドを兼任することがあるかと思います。そのような組織においては、フロントエンド領域における技術的課題が溜まりがちではないでしょうか。

私が所属していたチームでもそのような課題を抱えていました。特にフロントエンドのテストが非常に乏しく、ちょっとした変更のたびにマニュアルでのテストが必要な状態でした。

このトークでは、バックエンドを主担当としてきた私が、フロントエンドテストの拡充するために行った取り組みを紹介したいと思います。主に以下のお話を考えています。

• フロントエンドテストのキャッチアップをどのように行ったか。
• リファクタリングを容易にするために、関数単位のユニットテストよりも、コンポーネント単位のユニットテストを重視。
• フィーチャー開発の手を止めずに実現した、朝の30分活動でのテストコード追加。
• チームメンバーに浸透させるために行ったハンズオンや、AIコードエディタ(Cursor)によるテストコード生成。

このトークを通じて、バックエンドエンジニアでもフロントエンドテストを充実させることが可能であることを示し、参加者の組織におけるテスト拡充の一助となれば嬉しいです。

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

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

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

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

対象者

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

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

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

恐らく今や多くの現場でPHPStan, Psalm, Rector, php-class-diagram等の静的解析ツールが利用されているのではないでしょうか。その縁の下でPHP Parserがせっせと働いています。さて、そのメジャーバージョンが繰り上がり5.0.0がリリースされて1年程が経ちました。そして継続的にメンテナンスされ今ではPHP8.4にも対応しています。

そろそろ5系をのぞいてみたくありませんか？

このトークはPHP Parserの働きを効率よく理解できるようにすることを目指します。そのために、5系において定義されているノードの全体像を整理します。そして、PHPコードの具体例を使用し、コードとノードの対応関係について説明します。ノードとはPHP Parserがコードを解析して生成するASTの構成要素です。単なるテキストの羅列ではなく構造化された情報であるASTにより効果的な解析が可能になります。それを理解する事は、例えば、静的解析ツールの仕組みの理解を深める際や、そのカスタムルールを作成する際に役立つと考えられます。

このトークの目的はもう一つあります。私達はPHP Parserから大きな恩恵を受けています。しかし、その事を気に留めることはほとんどないのではないでしょうか。年に1度、5分だけ、1年分の感謝を込めてPHP Parserだけを見つめASTに想いを馳せる。そんな時間にしたいと思います。