Webサービスを運用するとき、セキュリティやコンテンツ配信の効率化といった目的のために前段にCDNサービスを置くのはよくある構成です。弊社ではMicrosoft Azure上でWebサービスを運用する際、フロントにAzure CDN（Front Door）を配置しています。
運用中のWebサービスでエラー画面が稀に表示されるという問い合わせが寄せられました。しかしエラーの再現率が非常に低く、アプリ側には何のエラーも見当たらず調査は難航しました。
そんな中で見つかった、Azure CDNでのHTTP Status 421という見慣れないエラー。我々はこれを手がかりに調査を進めるうちに、Azure CDNでのドメインフロンティング対策やHTTP/2でのコネクション再利用の仕様といった多くの情報に直面し、問題解決に至りました。

本セッションでは我々が実際に遭遇した問題とその解決に至る過程をお話しし、以下について詳しく解説します。
・ドメインフロンティングについて
・Azure CDNをはじめ、CDNサービスにおけるドメインフロンティング対策について
・HTTP/2とドメインフロンティングについて
・実際に発生する問題とその解決方法

Psalm や PHPStan、あるいは PhpStorm などでの静的型解析の隆盛により、時には動的型の言語であることを忘れそうになってしまうのが現在の PHP という言語です。

しかし一方で PHP は古くからある言語ですから、その現代的なエコシステムの力を借りられない、ソースコード中にほとんど型情報のないレガシーコードを扱う現場も数多くあります。あるはずです。そうですよね？

このトークでは静的解析や動的解析によって PHP コードへ自動で型アノテーションを付与する方法をいくつか紹介しつつ、各手法の良いところ・悪いところを比較検討してみます。

想定する聴講者は以下です。

• 「最近の PHP は型がけっこう使えるだって？そうかい俺の目の前のこのコードを見てみろよ！」という気持ちに日々なっている人
• コードの静的解析や動的解析が好きな人
• 暇な人

いまや、Webアプリケーションをコンテナとして動かすことが当たり前になってきています。インフラをクラウドベンダーにお任せできて便利です。

一方で、コンテナの思想や制約もあり、定期的にスクリプトを実行したり、SSHして別のプロセスを起動したりが、いままで通りにできなくて困った経験はないでしょうか？
当社では、オンプレ環境からAWS環境へ移行した際に、大量のcronやメール受信後の処理を置き換えることに四苦八苦しました。順序は気にしないといけないのか？冪等性は担保されているの？などなど気にすることも様々です。

本セッションはAWSで動かすことを前提に、ジョブ実行の様々なパターンについて特徴を説明します。
事例として、オンプレからの移行時にキューイングサービスを利用しスケーラビリティを得られた話なども交えてお話しします。

話すこと

• ジョブの実行方法。ワーカーの実行環境と実行のトリガーのパターン例
• AWSでの実装とセキュリティ
• 自社での大量実行に失敗した事例と現状、得られたもの

持ち帰って欲しいもの

• ジョブ実行のアーキテクチャのパターンを知り、状況に応じた選択ができる
• 実装において注意すべきポイントを知る

想定する聞き手

• 最近コンテナデビューした人
• コンテナ内にSSHをしている人
• あれ、マイグレーションってどこでやるんだ？ってなった人

私はtblsというツールを開発しています。

https://github.com/k1LoW/tbls

2018年にtblsはデータベースのスキーマ情報からドキュメントを生成するツールとして誕生しました。

そして、現在も多くの企業やユーザに使われています。

ある海外のサイトでは次のように紹介されました。

The project has been open-sourced for 5+ years, but the number of stars had a spike earlier this year. Anyone has any idea what happened in between?
（このプロジェクトは5年以上前からオープンソース化されているが、今年の初めに星の数が急増した。その間に何があったのか、どなたかおわかりになりますか？）

tblsは2018年から継続的に開発しており、まだ機能的な成長を続けています。

ところで、私はドキュメント運用のアプローチとしての"Documentation as Code"について考えてきました。その一部は https://speakerdeck.com/k1low でみることができます。

tblsはDocumentation as Codeを実現したツールの1つと言えます。そしてtblsは当時考えていたDocumentation as Codeの範囲を越えようとしています。

本セッションではDocumentation as Codeのその先について、tblsの今後の展開と共に共有したいと思います。

開発環境を柔軟に構築でき、それを簡単に共有できるDockerですが、都度適切な環境を構築することが新米エンジニアの私にはとても高いハードルでした。
しかし、ある出来事によりそのハードルがここ最近ガクッと下がりました。AI技術の急速な進化です。

このLTではAIツールを活用して0からDockerでLaravel環境を構築できた実体験をお話しすることで、
Docker × Laravel環境の作り方をわかりやすくご紹介すると同時に、プログラミングにおけるAIツール活用のコツもご提供できればと思います。

話すこと

• DockerでLaravel10環境を構築する流れ
  • ディレクトリ構成・ファイル構成
  • 設定ファイル（Dockerfile、compose.ymlなど）の書き方
• AIツールをプログラミングに活用するためのコツ

対象者

• DockerやLaravelをなんとなく知ってはいるけど使いこなすことは難しいと感じている方
• AIツールをプログラミングに活用したいと思っている方

SymfonyのFormTypeはフォームの定義をバックエンドとフロントエンドで共有できる非常に強力なツールですが、
FormTypeの一種で<select>などの選択式フォーム項目の選択肢をエンティティと自動でマッピングしてくれる「EntityType」を使う際には、
パフォーマンスの面で気をつけなければならない点がいくつかあります。

特に重要なのは、N+1問題の考慮です。大量のレコードを持つエンティティに対して無造作にEntityTypeを使ってしまうと、しばしばN+1問題が発生し、意図せず大量のクエリが発行されてしまいます。

また、<select>のユーザー体験を向上させるためにSelect2やselectize.jsなどのライブラリを導入してインクリメンタル検索などを実現することはよくあると思いますが、EntiyTypeによってエンティティのレコード数だけ<option>を持つような<select>が出力されてしまうと、Select2やselectize.jsの初期化処理に数秒オーダーの時間がかかってしまい逆にUXが悪化するといったこともよく起こります。

Symfonyユーザーの多くがEntityTypeが持つこれらの問題に長らく苦しめられてきましたが、実はそれも今は昔。
Symfony UX Autocompleteというライブラリの登場でこれらの問題は完全に解決してしまいました。

Symfony UXは、Symfonyアプリケーションにフロントエンドの処理を簡単に追加するためのライブラリ群で、その中でも私の一押しがSymfony UX Autocompleteです。

このトークでは、上述のEntityTypeの問題をSymfony UX Autocompleteによって完全に解決するまでの手順と実際のユーザー体験の変化を具体的にお伝えします。

話すこと：
・Symfony UX Autocompleteについて
・EntityTypeが使われているSymfonyアプリケーションへのSymfony UX Autocompleteの導入方法
・Symfony UX Autocomplete導入前後のユーザー体験の変化について

話さないこと：
・Symfonyの基本的な使い方
・Autocomplete以外のSymfony UXライブラリについて

最近LaravelのスターターキットであるLaravel BreezeにもTypeScriptサポートが追加されたように、LaravelにもTypeScriptを導入したフロントエンド開発需要が高まっています。
しかしTypeScriptでの開発を行っていると、Laravel側のコードと重複している箇所が多くあると感じます。

例えば

• 「Laravelのusersテーブルのカラム名が変更になった場合は、マイグレーションファイルを修正した後、TypeScriptのUserタイプも修正する必要がある」
• 「LaravelのEnumをそのままTypeScriptでも使用したい場合」
• 「Laravelのルーティングを修正した場合は、フロントエンド側のHttpリクエスト処理のURLも修正する必要がある」
• 「Laravelのバリデーションルールをフロントエンド側のフォームバリデーションにもそのまま適用したい場合」
  などです。

OpenAPI Specificationなどを利用してのフロントエンドコード生成やバックエンドのAPIテストを行うことでこれらの問題は解決されるかもしれませんが、APIスキーマファイル運用コストや開発速度の観点から採用が難しい場合もあります。
さらにInertia.jsなどそもそもAPIの送受信処理を省いてしまっている構成の場合にはこのようなAPI仕様書は有効ではありません。

そこで私はLaravelのModelからTypeScriptの型などを生成できるライブラリを自作し、ライブラリとして公開しました。
これを実際に業務でも採用しており、バックエンドとフロントエンドでの型共通化による開発の効率化やバグ防止に繋がったと感じています。
その他にもLaravelのバリデーションルールからTypeScriptのバリデーションライブラリZodのコード生成を行うライブラリを作成したりなど、バックエンドとフロントエンドでコードの重複をなくす取り組みを行っています。

本セッションではLaravel（PHP）のコードから型定義などのTypeScriptコードを自動生成する仕組みを導入することでコード重複問題を解決し、効率良く型安全なフロントエンド開発を行う手法を紹介します。

サービス運営を行う上で切っても切り離せない管理画面ツール。
必要ではあるもののサービス自体と比較すると相対的に工数をかけにくく実際そこまで凝ったものは必要ない、というのがよくある要求で、
そういった背景から*-admin系のライブラリが数多く生まれてきている一方、言語やフレームワークに依存する部分も多く、
既存のプロジェクトで使えていたものが新規プロジェクトでうまく使えず歯痒い思いをするといったこともあるはず。
そんな中、Slackアプリによる管理画面ツール開発は一つの答えになるはず...

Block kitを利用した効率的なviewの開発、Slack APIに機能を移譲することで得られるメリットなど、実際に運用する中で得られた知見を公開します。

ドメイン駆動開発でレイヤードアーキテクチャを採用するパターンが良くありますが、初学者にとっては理解し難いものです。見様見真似でなんとなく層に分けてクラスを設計してみたものの。。アレ？という感じになってたりします。

実際に遭遇したよく陥りがちな避けるべき実装パターンを例に上げて

• 何が駄目なのか？
• どういった設計にしていけばよかったのか？

をまとめてみたいと思います。

想定対象

• レイヤードアーキテクチャで悩んでいる方
• トランザクションスクリプトから脱却したい方
• ドメイン貧血症になってしまっている方

Garbage collection (GC) とは、確保したメモリ領域を適切なタイミングで解放する仕組みのことです。
PHP ではメモリの確保と解放が処理系によって自動的におこなわれるため、あまり意識することはないかもしれません。
しかしながら、メモリが比較的潤沢になった今でも、メモリ溢れによるサーバ障害は決して珍しくありません。
PHP における GC を理解し、メモリを意識したプログラミングをすることで、本番サーバを夜中に落とさないようにしましょう。

主な対象

• 普段メモリを意識してプログラミングしていないかた
• 言語処理系の内部実装に興味があるかた
• メモリ溢れで本番環境をダウンさせたことのあるかた

話すこと

• PHP における GC のアルゴリズム
• あなたが確保したメモリはいつ解放されるのか
• メモリ溢れを意識したプログラミング

話さないこと

• GC のパラメータをいじってカリカリにチューニングする

目標

• PHP でメモリがいつ解放されるのかを知る
• メモリを食い尽くす実装を避ける手段を知る

みなさんはクリーンアーキテクチャを理解している/知っていますでしょうか？
ドメインモデル, ユースケース, アダプタ, インフラストラクチャ...etc, はい、私は全くわかりませんでした。

ただちょっと視点を変えて、それぞれのレイヤーを擬人化してみると、最近なんとなくわかった様な気になることができました。
(例えば、ユースケースをプロダクトオーナー、インフラストラクチャをステークホルダーとした時に、実装について直接会話させると何が起きるのか → なんかアカンそう → じゃあどうするか など)

そこで本トークでは、みなさんにも自分と同じようにクリーンアーキテクチャを少しでも理解してもらえることを目標としてお話しできればと思います。

■ 話すこと

• レイヤーを擬人化してみるとどうなるか
• レイヤーを意識しないとどうなるか
• 依存関係(DI, DIP)について
• クリーンアーキテクチャを理解すると何がうれしいのか

■ 話さないこと

• クリーンアーキテクチャの深い話

■ ターゲット

• クリーンアーキテクチャ？なにそれ、おいしいの？という人
• クリーンアーキテクチャを理解するにあたって、とっかかりが欲しい人
• クリーンアーキテクチャでやっているが、なぜやっているのか分からない、ただの雛形にそって作業している人

■ 補足

※ 決してクリーンアーキテクチャ原理主義者ではありません、あくまでも一つの考え方、知識として持っておくと幅が広がると思い話します
※ クリーンアーキテクチャと書いていますが、なるべくXXXアーキテクチャ全般に通じる話にしようと思っています

私はこれまでビジネスロジックとドメインロジックをほぼ同じものとして捉え、ドメインモデルにビジネスロジックを実装することで業務知識を表現するような実装を意識していましたが、最近の開発の中でドメインロジックとビジネスロジックはレイヤーの異なる概念なのではないかと考えるようになりました。

この2つのロジックを区別し、ドメインモデルからビジネスロジックを追い出すことで仕様変更に強いドメインモデルを構築することが出来るのではないか、という考えを今回のトークでお話ししたいと考えています。

このトークでは、以下のトピックに関する僕の考えを共有することを目標とします

• ドメインとはそもそも何なのか
• ドメインロジックとはどのようなものなのか
• 何をドメインロジックとして扱うべきで、何を扱わないべきなのか

Laravelで多機能なアプリケーションをモジュラモノリスとして開発・メンテナンスしていこうとする時、Modelの依存は悩ましい点になっていると思います。AモジュールにあるModelがUserを、UserがBモジュールにある別のModelを参照してしまうと、結局疎結合にできず、メンテナンス時に依存を排除できません。
LaravelであってもORMとしてEloquentではなくDoctrineを使うことで、モジュール同士が依存しない、疎結合なモジュールによるモジュラモノリスが実現可能です。
実践的なモジュラモノリスLaravelのサンプルコードとともに、LaravelからDoctrineを使う実装についてご紹介します。

SPA全盛の時代ですが、まだまだ古き良きMPA（Multi Page Application）のシステムを触る機会は多いですし、
凝ったUIを必要としない社内システムなどでは、新規開発でもMPA構成を採用することは普通にあります。

MPAだとビューのテストは基本的にPHPフレームワークが提供してくれる結合テスト基盤を使って行うことになると思いますが、
結合テストで検証できるのはあくまでHTTPレスポンスの内容までで、その後ブラウザ上でJavaScriptを使ってある程度複雑な処理が行われる場合に、その部分をテストすることができません。

MPAであっても、一部の画面にだけちょっとしたDOM操作や非同期処理が必要になるケースは多く（例えばいいねボタンとか）、
このようなJSの処理は上記の理由から自動テストがサボられがちです。

このトークでは、こういったMPA上のJavaScriptの処理を楽にテストする方法を、LaravelおよびSymfonyにおける実装例をもとに解説します。
（例としてLaravelとSymfonyを取り上げますが、他のフレームワークにも容易に応用可能な内容です）
既存のMPAに後付けで簡単に導入することが可能なので、すぐにでも実務に活かせる内容になると思います。乞うご期待。

現代では「動的な」ウェブサイトを作ることが当たり前になっています。しかしなぜ「動的」なものを作らないといけないのでしょうか。

「ウェブサイト」とは、かつてはサーバー上にある静的なドキュメントにアクセスするためのものでした。
しかし、CGI の開発により動的なコンテンツを扱うメディアとして進化を遂げていきます。

HTML 内で動的な値を表示することができる「ページインライン」モデルの PHP が生まれ、
データベースと接続したウェブアプリケーションが普及していきます。
全世界のウェブサイトの多くが WordPress によって作られるようになっていきました。
今は動的な値を扱うウェブサイトにおいて、いかに早くユーザー体験を損なわずに必要な情報を届けられるかの工夫がされるようになります。

本発表ではそうしたウェブサイトの歴史的背景に加え、動的なウェブサイトにおける課題と改善のために生まれた技術・手法について触れ、今後のウェブサイト・ウェブアプリケーションの開発動向についても考えていきます。

新しく入社した会社で任される仕事は既存のシステムの技術的負債の返済。このような経験をほとんどの方が受けているのではないでしょうか。
「なんて醜いコードなんだ」と思ったり「こんなコード，メンテナンスしたくない」と思う時もあるはずです。

さらに言えば「なぜ初めからもっと丁寧に書けるエンジニアを採用しなかったのか」と思うこともあるでしょう。
そして「自分はこのようなコードを絶対に書かないぞ」と決心するはずです。

しかし，技術的負債は，なぜ生まれるのでしょうか。「採用力がなかったから」「経営陣の実力不足」「経営陣がエンジニアへの理解に乏しいから」など様々な理由を思い浮かべるはずです。
また，技術的負債を作った当人達は，人事評価で好印象を与えやすく，逆に後から入社したエンジニアは技術的負債を返済し，堅牢なアプリケーションを作っているのにも関わらず，満足行く人事評価を得られないことがあるなどして，軋轢が生まれやすところです。

技術的負債が生まれないようにするには，技術的負債が生まれる理由を知らなければ根本的な解決は望めません。
本トークでは，CTO という経営に近い立場から，技術的負債が生まれる原因を解明していきます。

そして，本トークを経て，オーディエンスの皆様が技術的負債と前向きに向き合うキッカケの一つになれば幸いです。

※本トークは，PHP に関連するトークではなく，汎用的なトークとなっています。

昨年11月のPHP TechCafe、『PHPerのための「PHPフレームワーク」を語り合う』でLTした、『それぞれの特徴から考えるフレームワーク選び』。それをもうちょっと深掘りし、今までWebアプリケーション開発で経験して感じた"Laravel", "CakePHP", "Symfony"それぞれのフレームワークの特徴と適している利用シーン、今後のプロダクト作りのフレームワーク選定する際に注目するポイントについてお話しします。

LT時のスライド：
https://speakerdeck.com/ippey/soresorenote-zheng-karakao-eruhuremuwakuxuan-hi

お話しする内容

• 各フレームワークの特徴、利点と欠点
• 実際に開発した際に感じた、恩恵と弊害
• フレームワーク選定時に注目したいポイント

発表者のチームではPull Request毎にProduction同等の動作確認用の環境を自動的に生成してリリースサイクルをスムーズに回せるようにしています。
GitOpsを用いたシンプルなインターフェイスと通知によって、デザイナーなどの非エンジニアでも簡単に利用できる工夫があります。
本発表では、その工夫について紹介するとともに、発生した課題に対してOSSを開発したり、ArgoCDに機能追加をした話を交えてお話します。

gRPCというワードを聞いて、「何から始めればいいの？」「何がメリットなの？」「REST
APIでよくない？」という疑問が浮かぶ方に向けて、gRPCの基礎から具体的なアプローチまでお話します。
gRPCの概要をはじめ、gRPCを活用したWebアプリケーション開発を中心にフロントエンドからバックエンドまでの実装における実践的なポイントについてお話します。
私自身もほんの数ヶ月前までgRPCが全くわからなかった人間なので、「大丈夫！gRPCは怖くないよ！」ということがお伝えできれば幸いです。

【トーク予定内容】

・ gRPCの概要
・ 各レイヤー(フロントエンド/バックエンド)の実装方法
・ 周辺ツールの紹介
・ 成功体験/失敗体験

など

以前まで PHP で非同期処理を扱うためには様々な制約をクリアする必要がありました。しかし，昨今の PHP では非同期処理を容易に扱うためのライブラリである Swoole や，parallel，PHP 8.1 からビルトインされた Fibers などがあります。
しかし，そもそも非同期処理とはどういったものなのでしょうか。非同期処理を調べていくと並行処理や並列処理，マルチスレッドやマルチプロセスなど様々な単語が出現しますが理解するのもハードルが高いと感じる方もいらっしゃるかと思います。
本トークは初級者から中級者向けに非同期処理について，拙著「Swooleで学ぶPHP非同期処理」からいくつか引用・補足し，非同期処理の基礎から PHP で非同期処理を実現する方法をお伝えします。