概要

LaravelにはOctaneというLaravelアプリケーションを高速化するための拡張ライブラリが存在しており、
従来のPHP-FPMより大幅な性能向上を実現します。
本セッションではFrankenPHPのZTS（Zend Thread Safety）環境でのワーカープロセス管理、
octane:startコマンドの内部動作、Octane Tables/Cacheの実装制約などを紹介していきます。
またOctane導入前後でどれくらいのパフォーマンスの差が出てくるのかを検証します。

話すこと

• ZTS環境でのワーカー管理とOctaneの連携実装
• octane:frankenphpコマンドの内部動作
• Octane Tables/CacheのFrankenPHP環境での実装と制約
• Octaneの有無でのパフォーマンス差異

概要

従来のPHP環境でリアルタイム通知を実装する場合、Node.js等を組み合わせた複雑なインフラ構成は悩みの種でした。
FrankenPHPではこの課題を解決するためにMercureが内蔵されており、PHPスタック内でシンプルかつ高速なリアルタイム通信を実現しています。
本セッションでは、実際に動作するアプリケーションの動作デモを交えながら、以下の技術的なポイントを紹介します。

話すこと

• 従来構成での実現の難しさを再確認する
• FrankenPHPがリアルタイム通信を実現する流れの紹介
• WebSocketとServer-Sent Events(SSE) の技術概要と差異
• FrankenPHPを使ったリアルタイムWebアプリケーションの具体的な実装方法と実演

話さないこと

• Mercureの技術詳細

フレームワークを作るためのフレームワークと言われ、実際にLaravelでもコアとして利用されているSymfony。
そのため、初心者向けの導入説明や上級者向けの抽象概念獲得のための解説などの知見を聞く機会が多くあります。

一方で、実用としてのSymfonyの知見を聞く機会があまりありません。
同様にPHP5.4で導入されたtrait（特性）の実用としての知見を聞く機会もあまりありません。

そこで、この登壇ではSymfony6.3および7.2において本番実証済みのtrait（特性）活用例をお話します。

このトークで得られる知見

• Symfonyの特性に沿った特性(trait)の活用事例
• traitの使いどころ
• 省力かつ安定し安全な機能改編の実例

このトークで扱わない内容

• Symfonyの使い方

注意事項

• サンプルコードの公開は間に合いません。悪しからず。

国内外であまり知られていないAstroのContainer API。主にコンポーネントテストのために使われますが、実はバックエンドフレームワークとの組み合わせも可能にするAPIです。
本発表では、Astro Container APIの紹介、バックエンドフレームワーク組み込みのための使い方、APIを使うときの落とし穴について語りたいと思います。HonoやLaravelなどを利用し、実例を紹介しながら発表します。
「Astroを使ってるけどバックエンドを追加したい！」　「既存のバックエンド知識を活かしながらモダンなUI開発をしたい！」　という方に向けたトークです。

このトークでは、ある仮説を提案します。

技術的負債の、「利率」にあたる部分はチームメンバーの増加によって見かけ上増える

プロダクトの開発で機能とソースコードが変更されると貸借対照表の借方に新機能によって得られる価値(正味現在価値)が入り、貸方に技術的負債が入ると捉えられます。この、貸方に入る技術的負債が通常の負債とは異なる性質を持つと言うのが、この仮説の骨子です。

トークでは、貸借対照表や正味現在価値などの用語についても解説を加えます。

この仮説を通して、各チームで
・技術的負債の解消をするかどうか
・いつ技術的負債を解消するか
・カスタマイズをすべきかどうか
・カスタマイズをする場合はリファクタリングを計画するか
などについて議論を深めるきっかけにしていただくことを目指します。

※内容の正確さには注意を払いますが、私は会計学の専門家ではありません。

API仕様書を管理するWebアプリケーション開発において、「スキーマと実装の乖離」は頭の痛い問題です。

以前、apidocでAPI仕様書を管理していましたが、各種問題がありました。
特にドキュメントの品質管理が個人に依存しがちで、実装との乖離が発生していました。

単なるツール移行では根本解決にならないと判断し、人ベースの品質管理からの脱却を目指しました。
開発プロセスから見直し、それを実現するアーキテクチャを検討した結果、swagger-phpをベースとした独自ライブラリを開発することになりました。
結果として、構造的な問題を解決し、スキーマ駆動開発にも対応できました。OpenAPIエコシステムの恩恵も得られて高品質且つ、開発者体験の向上にも繋がりました。

今回の登壇では、ライブラリ開発の経緯に加えて「eg-r2」の具体的な使い方を紹介し、OSS化の狙いについてもご説明します。

どのようなビジネス、プロダクトであろうと運用していくのに必要なのが管理画面
ただ、管理画面を作っているとこういう課題に出会ったことはないですか？

• 調査依頼が来てもどこを見ればいいかわからない
• おかしなデータが入ったことに気づけない、ログを追うのが大変
• 調査依頼からバグを再現するのが難しい

これらを1つ1つ向き合って解決し、プロダクトとビジネスの成長をさせるための管理画面の作り方を話します

話すこと

• 管理画面におけるログやデータの残し方
• 管理画面におけるアプリケーションの設計

話さないこと

• アプリケーション設計における具体的なコードの説明
• 画面のUI

PHPのmbstringのRFCを投げていても、最近ではなかなかAcceptされにくくなってきました。
それでは、代わりに何が来るのかというと、Unicodeを扱う関数であるgrapheme関数で、それを作っています。

皆さん、これからやってくるであろうUnicode大時代に向けてキャッチアップしませんか？

テストコード、書いていますか？

今日において、自動ユニットテストを整備することが開発生産性の向上に寄与することはもはや疑う余地がありません。また AI の活用により、テストコードを書くコストは従来に比べて大幅に減っています。

しかし「テストコードの書き方や導入方法がわからない」「テストコードがあるだけで満足してしまい十分にその効果を発揮されていない」「テストコードが負債化し開発の足枷になっている」などの課題に直面している方も多いのではないでしょうか。

AI がコードを書く時代になっても……いや、むしろ AI がコードを書く時代だからこそ「価値のある」ユニットテストについて一緒に考えてみませんか？

お話しすること

• AI 時代における自動ユニットテストの価値とは
• 価値のあるテストコードを書くための基本的な考え方
• よくあるアンチパターンと処方箋・テクニック

AIを利用したコーディングによって生産性が高まっていることは間違いありません。
0→1の生産性が高まった反面、設計不備による低品質なコードやテーブルも量産されてしまいます。

だからこそ、今こそデータモデルのあるべき姿を考え、その形にデータベースもリファクタリングしていくことが必要です。
そこで今回は下記の項目についてご紹介します。

• データベースのリファクタリングの手法
• データベースリファクタリングに必要な準備
• 大きく捉えて小さく設計する

ADRとは略称で、 Architecture Decision Records の頭文字をとったものです。直訳すると アーキテクチャ決定の記録 というところでしょうか。
その名の通り、構築計画中のソフトウェアアーキテクチャの重要な側面に関してチームが取った選択について説明する文書のことを指します。

このセッションでは自身がテックリードとして所属するチームにADRを導入する→してみてどうだったか？までを一貫してお話します。具体的には以下の通りです。

• (改めて)ADRとは何か
• なぜADRが必要だったのか
• 導入までにやったこと
• 導入までに困ったこと
• 実際の運用フロー
• 導入により得られた効果