私たちのチームはPHPとRDBMSを用いた受託開発を中心に開発してきました
チーム文化としてクライアントニーズに迅速に応えつつ柔軟性を持って開発を進めることを大切にし、時代の変化に対応しながら受け入れることを得意としてきました

そんな中話者は自分の得意なサーバーレスをどうやってチームの文化に共存させ、開発価値の向上を行うかを考え続けていました
その中で知ったPlatform Engineeringの考え方に目をつけ、 「サーバーレスが得意な私ではなく、チームとしての開発価値を向上」に挑戦して一つの形が見えました

今回はその挑戦の中で見えた「自身でリードするのではない、チームにServerlessをフィットさせる挑戦とその価値」についてお話します

• 想定聴講者
  • サーバーレスをチームに浸透させたい人
  • Platform Engineeringがなにか知りたい人

エンジニアなら、「メール通知機能」を実装したことがありますよね？

Webサービスにおいて、メールはユーザへの通知方法としてほぼ必ず利用されます。
近年でメールに関する"セキュリティ"はより重要視されるようになりましたが、
実はちゃんと理解できていないエンジニアも多いのではないでしょうか？

2024年4月から本格的に始まったGmailの"メール送信者のガイドライン"の運用によって
エンジニアだけでなくカスタマーサクセスのメンバやさらにはユーザまでもこれらへの理解が求められるようになりました。
これはエンジニアがメールセキュリティを「理解する」だけでなく、「他人に理解させる」ことも求められるようになったことを意味します。

この発表では、DKIM、DMARC、SPF といった基本的な仕組みについて解説しつつ、
できるだけ平易な言葉で他人に伝えるためのヒントをお話しします。

Laravelアプリケーションと事業の成長に伴い、フェーズごとに最適なアーキテクチャは変化します。

本セッションでは、シードフェーズからシリーズA、さらなる成長フェーズに至るまで、各段階でのアーキテクチャの変遷と最適化ポイント(スケーラビリティ、コスト効率、開発速度などのバランス)をメインの観点として保ちながら、持続可能なシステム設計を実現するためにやった施策を交えて紹介します

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

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

■ 発表内容
新しく組成された8人のチームが、新規機能の開発を「1ヶ月の期限で」と任された。

不確実性に対処しつつ円滑に開発を進めるために、
スクラム、XP、DevOps（リーンとDevOpsの科学）のプラクティスを取り入れて開発を進めた結果、時間が経つごとにチームは一致団結。

しかも、ビジネスチーム、セキュリティチーム、CSチームなど部署の垣根を超えた開発の実現に成功。
チームの誰もが「真のアジャイルチームになった」という手応えを感じていた。

何がうまくいったのか。3ヶ月に渡るチームの取り組みを総括します。

■ 発表の構成
・スクラム（スクラムイベントなど）、XPのプラクティス、DevOpsのケイパビリティの概観
・各プラクティスのチームへの導入と改善の様子をスプリントごとに提示
・チーム外の人と協働して効果的だったエピソード
・メトリクスを紹介して開発の成功度合いを定量的に説明

RESTful APIの仕様を記述するためのフォーマットとしてOpenAPIは、多くの企業やプロジェクトで採用されており、エコシステムも充実しています。しかし、OpenAPIでAPIドキュメントをまとめる際には、エコシステムが充実しすぎていて、どのように書くべきか悩むことがあります。

• OpenAPIのフォーマットをサポートしたエディタを使う？
• APIドキュメントからコードを生成する？
• 逆にコードからAPIドキュメントを生成する？

など。
これらの悩みの本質は、継続的なドキュメントのメンテナンスをどうするかという点にあります。言い換えると、APIドキュメントとコードの乖離を如何に防ぐかという問題です。
この問題を解決する、ライブラリeg-r2を紹介します。
eg-r2は、APIドキュメントとコードの乖離を防ぐための新しいアプローチを提供し、従来の自動化の問題を改善しています。

ここ数年、私はRaspberry PiでCPUを作っています。
これは、Z80というCPUをコンピュータから取り外して代わりにRaspberry Piで作った自作CPUを取り付けて動かすというもので、PiZ80と呼んでいます。

PiZ80はZ80採用のパソコン・MSXを動かすことを最終目標にしています。
現在のPiZ80は同じくZ80採用のコンピュータ・SBCZ80でZ80よりも高速に動作する様になっていますが、ここに至るまでにはさまざまな改善がありました。

このトークではそもそもCPUを作るというのはどういうことか、CPUを作る時にどこに速度的な課題があるのか、そしてMSXでPiZ80を動かすまでの道のりをお話します。

このトークを聞いた方がCPUやハードウェア自作を好きになり、そしてあわよくばPiZ80のソフトウェアをいっしょに改善していけることを願っています！

　テーブルのデータ量が増えることで、今までスムーズに実行できていた検索クエリが段々と遅くなっていく…ある程度長く運用しているシステムではあることではないでしょうか？今、私が参加しているチームでは、まさにこのような問題を起こしているばかりでなく、数年後には性能劣化によるサービス停止を引き起こしかねない、とあるMySQLの巨大テーブルのリモデルに取り組んでいる真っ最中です。
　本セッションではこの取り組みの中で、チームがどのような決断をしていったか、そして現在進行形でどのようにリモデルを進めているかを共有します。DBアクセスが抽象化されていないモノリスなレガシーシステムで、億単位の行を持つMySQLテーブルをサービス停止なしでリモデルする事例として、皆様のご参考になれば幸いです。

保育・教育施設向けICTサービス「CoDMON(コドモン)」は2015年のリリース以来、多くのサービスを提供してきました。
　ありがたいことに長くご利用くださるユーザー様が増える一方で、DBのデータ量がもはや看過できなくなるほどの増加ペースに達しており、今年5月からDB負荷増大のリスクと対策を検討するチームを発足して、この問題に取り組んでいます。
　本セッションでは、この取り組みの中で、データ量の増加に起因するDB負荷の問題をPHPのモノリスなレガシーバックエンドや、適切でないテーブル設計との関係の中でどのように分析し、リスク評価し、対策を考えたのかをお伝えします。皆様のご参考になれば幸いです。

このセッションでは、LaravelとInertia.jsを組み合わせたモダンなフルスタック開発について紹介します。
Inertia.jsは、ReactやVueなどのモダンなフロントエンド技術のメリットを活かしながら、サーバーサイドアプリケーションのシンプルさを維持するためのツールです。これにより、複雑なAPIやクライアント側の状態管理なしで、モダンでインタラクティブなウェブアプリケーションを構築できます。
ReactやVue、TypeScriptと組み合わせて使用する方法や、Inertia 2.0で導入される新機能、UIコンポーネントライブラリのshadcn/uiの活用法、ライブバリデーションを実現するPrecognitionについても説明します。
さらに、VitestやDuskを使ったテストの方法や、Laravel公式のVS Code拡張機能を活用する方法についても触れます。

The 1brc is "a fun exploration of how quickly 1B rows from a text file can be aggregated with Java", but let's face it, we should be able to do this in PHP too, right?
Let's see how fast we can actually aggregate 1 billion rows in PHP and learn about optimising the performance of PHP software along the way.

Ever dreamt of becoming a PHP core contributor but felt overwhelmed by the prospect of creating RFCs, maintaining extensions, or writing C code? Worry no more!
We'll discover how to make an impact on the PHP core by writing tests. Join me for an interactive session where I'll live code a test on stage, demystifying the process and equipping you with essential techniques.

This talk focuses on leveraging modern PHP features like arrow functions, typed properties, and named arguments to write robust, clean, and maintainable code. It offers best practices for structuring and organizing code and includes examples of bad code, showing how to resolve these issues with specific PHP features.

PHPUnitを支える仕組みに、イベントシステム(Observerパターン)があります
何故？
もちろん、無闇にイベントが設計されている訳ではありません
「フレームワーク(FW)の作者や利用者が感知したい・拡張したいはず」のポイントを察知して
要所要所にイベントが仕込まれている！と考えられるでしょう

イベントを知る=FWの思想に触れる手掛かりになります
普段とは少し違う視点で、PHPUnitを眺めてみましょう！

本トークで得られるもの

• PHPUnitの仕組みに対する理解
• 拡張的な使い方をするための基礎知識

話すこと

前半: 基本編〜PHPUnitの骨格が分かる〜

• テスト実行ライフサイクルの概説
• 各イベントとイベント同士の関連

後半: 実践編〜Extensionが分かる〜

• イベントシステム利用の実例
• Extensionを自作してみる

ORMを使っている人は、それが「DBから取ってきたデータを、PHPのオブジェクトに変換して渡してくれるものだ」と知っています。
「SELECT文で取得した値からPHPの世界のインスタンスを作る所を、その目で見た事がありますか？」と問われると、如何でしょうか。

PHP製フルスタックフレームワークは、それぞれ特徴的なORMを有していることが多いです。
Active Recordか？Data Mapperか？という大局的な話から、もっと些細な「そのフレームワークっぽい癖や工夫」にも違いがあるでしょう。

このトークでは、少し踏み込んで「ORMのデータの取り方と組み立て方」を比較していきます。

題材

• doctrine/orm
• illuminate/database (Eloquent)
• cakephp/orm
• CakePHP2.xのORM 〜連想配列の使い手〜

API Platformは、Web APIの開発に特化したPHP向けのフレームワークです。
本格的なWeb APIの開発に必要な機能を幅広く備えており、PHPでWeb APIを開発する際の有力な選択肢の一つとなっています。

エンティティクラスにアトリビュートを1行追加するだけで一瞬でREST APIとOpenAPIドキュメントを生成できてしまう優れものなのですが、
ある程度複雑なことをしようとすると途端にフレームワークについての深い理解が求められ、入門と実戦の間には大きな隔たりがあります。

このトークでは、API Platformの導入方法から基本機能の概要、さらには実践投入に向けた各種ワークアラウンドや実装テクニックを、
実際に動作するデモをお見せしながら丁寧にご紹介します。

API Platformの実戦投入、あるいはその検討の一助になれば幸いです！

ソフトウェアエンジニアには抽象化の能力が重要と言われます。
では実際に抽象化とはどのような能力なのでしょうか？

実際の事例を交えながら、抽象化を理解し、実務に活かせるようにします。

話すこと

• 抽象化と具体化とは
• 抽象化のメリット
• 現実で身につける抽象化の階層
• 抽象と具象の往復とは
• ソフトウェアと抽象化

話さないこと

• 具体的なソフトウェアの実装における抽象レイヤーの話

エンジニアとして始めると必ず知る概念、それが「デザインパターン」です（諸説あり）。
私は新卒の頃、輪読会としてデザインパターンの本を読みました。そして、その知識を持て余したものです。
”デザインパターンを勉強しよう”で知ったデザインパターンは、その適用に失敗することの方が多いように感じます。
「道具として自然に出てくること」が大事であること、そして「道具としてもう使われないものもあること」を認識するのが大切です。
普段使用するフレームワークやライブラリに出てくるデザインパターンを参考に、今でもよく使われるデザインパターンを紹介していきます。

話すこと
・デザインパターンとの向き合い方（共通言語として”デザインパターン”を知っておく）
・フレームワークやライブラリに出てくるデザインパターン
・好んで使わないデザインパターン

※GoFのデザインパターンのことを指します。

何らかの技術の理解を深めるのに、最も適した方法はなんでしょうか。
私は、その技術のサブセットを実装することだと信じています。
PHP、ひいてはプログラミング言語というものを理解するために、PHP 言語のサブセットを実装しましょう。
プログラミング言語処理系における「セルフホスト」とは、その処理系のソースコードをその処理系自身が処理できることを指します。つまり、今回作るPHP処理系の上でそのPHP処理系を動かすことを目指します。

話すこと

PHP で書く PHP 処理系（のサブセット）の作り方
必要なソースコードはすべて公開され、このトークを聞かれた方が同じものを作成できるように構成します。

話さないこと

以下は実用的な言語処理系を支える重要な要素ですが、このトークでは意図的に省き、より容易に理解できる手法で代替します。

• LR 法のような実用的な構文解析手法
• 仮想機械