テスト放送

DDDの戦術パターンや、複雑化してしまったシステム、
マイクロサービスアーキテクチャなどとうまく付き合うためにはイベント駆動型のシステムが必要不可欠です。
再度ES+CQRSという仕組みに注目されている方も多いのではないでしょうか？

APIベースのアプリケーションではなぜ難しくなってしまうのでしょうか？
なぜES+CQRSなどが必要になっていくのでしょうか。
PHPだけで実現するには複数の手法を組み合わせる必要がありますが、
本セッションでは実際にES+CQRSを導入する際のポイントや、アンチパターン、
ドメインモデルからの落とし込み方、他言語での実装方法なども踏まえて簡単に解説します！

BEAR.Sundayの分散キャッシングフレームワークは、クライアントサイドとサーバーサイドのキャッシュ管理を統合することで、Webアプリケーションの堅牢性とパフォーマンスを大幅に向上させます。このキャッシングフレームワークは、静的な情報APIと動的な計算APIの2つのタイプに基づいて、それぞれ異なる戦略を採用します。従来のTTLキャッシュを超えて、依存管理を伴うイベントドリブンキャッシュ、静的と動的コンテンツを効率的に分離するドーナツキャッシュアプローチ、そしてネットワークキャッシュの重要性について詳しく解説します。

このプレゼンテーションは、単に特定のフレームワークの機能紹介に留まりません。DI（依存性注入）やAOP（アスペクト指向プログラミング）のようなソフトウェア設計の原則を組み合わせることで開かれる新たな可能性を探ります。REST原則に基づいてHTTPや最新のCDN機能を最大限に活用するキャッシュシステムの構築にも深く焦点を当てます。このセッションを通じて、参加者は技術的な理解を深めるだけでなく、設計者としての視点も獲得できるでしょう。

データベースの寿命は、アプリケーションよりも長い。
多くの人が感覚として持っているのではないでしょうか。

この10年間で多くの技術が生まれ、そして変化し、開発の現場も進化してきました。
そんな中、データベースの世界では何十年もRDBMSが活躍しています。

それはなぜでしょうか。
この10年間のRDBMSの変化から開発に必要なことが見えてくるはずです。
そして、そこからこの先の10年を見据えたシステム開発の勘所を紐解きます。

OracleDBやSQL Serverのような商用データベースに対して、MySQLやPostgreSQLのようなOSSデータベースは如何に追従しているのでしょうか。
そしてAmazon AuroraやGCPのCloud Spannerのようにクラウドならではの新しい形のデータベースも次々に生まれています。

これらを題材に今、あなたが新しいサービスを作る時、10年戦えるデータベースの作り方を見つけていきましょう。

キャッシュはパフォーマンスを劇的に改善する効果がある反面、使うと簡単にはやめられない複雑性と中毒性があります。
その特性から キャッシュは麻薬 と言われ、安易な利用は忌避されています。

しかし、キャッシュがもたらすパフォーマンスの改善効果は無視することはできず、コンピュータの世界において有効活用されているのも事実です。
そこで今回は、キャッシュの手法と有効な場面での活用方法、逆に失敗してしまいやすい注意事項を説明しながら、実務の中でのキャッシュとの付き合い方を説明します。

話すこと

• キャッシュが有効な例と失敗例
• キャッシュを実装パターンと始めるときの勘所

対象者

• アプリケーション開発などでパフォーマンスに苦労したことがある人
• キャッシュを利用したサービスの運用で苦労をしたことがある人
• とにかく今すぐパフォーマンス改善したい人

皆さん普段どのようにPHP実行環境を組んでますか？私はなんだかんだLAMP推しです。もうCDNが前段にいればええやろ。

さておき、PHPはモジュラ式に拡張できるしインタプリタ(諸説あります)だし、php.iniは山ほどあるし、httpdは別途に必要だしで実は非常に複雑です。
つまりメンドウ。なので多くの人がパッケージマネージャでいれてると思います。

よって、気になる人は「なんかPHPの環境構築は{所定のブログ記事}のコピペでやってるな〜秘伝のタレだな〜」みたいな感じと思います、どうですか？
(まあ私もremiったりondrejつかったりもしますのでそれは間違いではありません)

しかし「PHP環境のビルド」は色々出来るんです。今回は真心を込めて「カリっとしたPHPをつくる」そういう遊びをしてみませんか？

• 超ニッチなオタク話です
• ミドルウェアや*nixやLinuxの話になります
• 仕事には多分役立ちませんが、「なんでBrewのPHPが壊れるのか？」みたいなことはわかるかも
• もしかすると、「コンテナサイズを超小さくする派」とかには刺さるかも？(php方面にいるのか？)
• もはや廃れた(？？？) INSTALL.mdとかにある configure と make all と友達になれるかも

私たちが開発しているPHPサーバーは色々な人から受け継がれ秘伝のタレが継ぎ足され続け、よく分からないバグが稀によく起きます。
これまでその解消の武器をいくつもそろえましたが、最近はオブザーバビリティエンジニアリングという武器を使っています。

オブザーバビリティがあるシステムは新しいコードをデプロイせずともデバッグができるシステムです。
OpenTelemetry はそれを実現できる技術の一つですが、PHPで始めるのはいくつかの障壁と意思決定ポイントがあります。
例えば、collectorやbackendといった登場人物の理解、小さく始めるにはどのotel backendを採用すべきか、計装ライブラリは何を使うべきか、どこに仕込むべきかがあります。

私たちはオブザーバビリティエンジニアリングを実践すべく、OpenTelemetryを導入しました。
しかし満足のいくようなアプリケーションのトレーシングとメトリクスを出すまでに色々な失敗を繰り返しました。
このトークではOpenTelemetryを既存サービスに導入するにあたってどのような選択肢があるかを紹介し、どの選択をした結果どのような失敗をしたかをお話しし、PHPでの計装の事例紹介をしたいです。

2023年9月、初めてPHPで Hello World しました。

私はいわゆるサーバーアーキテクチャを勉強するのが好きです。これまでにプリフォークサーバー、マルチスレッドサーバー、イベントループサーバー、グリーンスレッドの最小構成を自作したことがあり、ブログにまとめたこともあります。（ https://blog.ojisan.io/server-architecture-2023/ ）

そんな私が PHP の勉強として docker-compose + MySQL + PHP で簡単な掲示板サーバーを作り、それをクラウド上にコンテナでデプロイしようとしました。しかしこれはとても難しかったです。Laravelアプリケーションをコンテナデプロイするためにはアプリケーションサーバー(PHP)とウェブサーバー(Nginx, Apache)に分離して開発、場合によってはそれらを FastCGI で繋ぐことに驚きました。当初私はアプリケーションサーバーだけを配置、もしくは前段にCDNを置くだけといった構成を想定していたためです。正直なところ PHP サーバーのコンテナデプロイを納得するためには低レイヤーでの理解が求められると感じました。そこでこのトークではPHPサーバーとコンテナデプロイでお世話になる低レイヤー技術（主に並行プログラミング）や新鋭のライブラリや環境についておさらいします。

本トークでは、Laravelで作られた基本的なウェブアプリケーションを例に上げて、ウェブアプリケーションのチューニングとはどのようなことをすればよいのか？どのような原因でウェブアプリケーションが遅くなるのかを説明し、その対処法について紹介します。

本トークで話す内容

• ウェブアプリケーションが遅いとはどういうことか？
• パフォーマンスの計測方法と評価
• 実際のチューニング方法

PHP は、気軽にウェブアプリケーションを作れる言語として、初心者から熟達者まで、人気のプログラミング言語です。
しかし、せっかく作ったウェブアプリケーションも、保守・運用で扱いにくいとレガシーアプリケーションとか、技術負債などと呼ばれます。また、PHP を忌避するエンジニア達も存在していて、レガシー化しやすいから PHP で新しいアプリケーションは作りたくないと評されたりもします。

しかし、保守性の高いウェブアプリケーションとなると、難しい設計論とかアーキテクチャーとかの話が出てきて、どうやっていいかよくわからなくなります。
なんとか、PHP の気軽さを保ちつつ、保守・運用がしやすいウェブアプリケーションを作ることはできないだろうか？
本トークでは、なるべく難しい設計論を避けつつ、どうやったら無難で、レガシーになりにくく、レガシーになったとしても何とかなるウェブアプリケーションが作れるかをまとめます。

本トークでお話すること

• レガシー化しにくくなる PHP ウェブアプリケーションの基本方針
• 明快で分かりやすい開発時の約束事
• 負債を生み出しにくい開発フロー・開発組織の仕組み作り

アスペクト指向プログラミング（AOP）は、アプリケーションのコードベース全体に横断的に影響を与える部分（Cross-cutting concern）を効果的に管理するためのプログラミングパラダイムで、
オブジェクト指向プログラミングには無い新たな視点を提供します。

PHPにおいてAOPはあまり馴染みのないものかもしれませんが、いくつかのAOPを可能にするライブラリが存在します。

本トークでは、PHPにおいてAOPがどのように実現されているかに焦点を当て、
Ray.Aop と PHP-AOP の2つのAOP実装を題材とし、2つの実装における共通点や違いについて紹介します。

本トークでは、まずAOPの基本概念や利点について確認します。
その後、2つのAOPライブラリについて紹介し、どのように実装されているのかをライブラリによる違いや共通点に着目して深掘りします。
最後に、AOPを導入・活用するにあたってのポイントといった、より実践的なことを紹介します。

フロントエンドは得意なのだけど、バックエンドを作るのは苦手

そんな方の選択肢の一つとして、バックエンドレスなWebサイト構築についてお話します。
DBaaSを利用することでバックエンドのコードを書くことなく動的な情報を更新出来ます。

そこにUIを作成することが得意なフロントエンドを組み合わせることで、
リアクティブな動的なサイトとして、サーバーレスなWebサイトの公開する方法まで解説します。

この手順によりゼロスケールが可能なサーバーレスのWebサイト構築を実現して、低コストなWebサイト運営を実現します。
本セッションではその技術要素まで可能な限り解説を行います。

• 対象の聴講者
  • DBaaSに興味がある方
  • 低コストなサーバー運営に興味がある方

一般的に「WebフレームワークとAWS Lambdaは相性が悪い」という認識が存在し、この認識が移行や採用の障壁となることがあります。
今回は現場から見たWebフレームワークとAWS Lambdaを組み合わせるメリットに焦点を当て以下解説を行います。

• 開発速度の向上
• コードの再利用性と低い移行コスト
• 技術スタックの一貫性と共有知
• セキュリティと高度な機能

さらにWebフレームワークを利用する場合と利用しない場合で、同じ機能を実装した際の比較を行うことで、デメリットが許容できる可能性を提示します。

上記のような、実際の体験も踏まえたメリットの主張と、比較によるデメリットの許容可能性を示す事で採用障壁を下げ、
サーバーレスというアーキテクチャの適用範囲を更に広げる事を目的としています。

そして地方や小規模なチームにも適用可能である事を主張し、
その可能性が認められる事で更なるアーキテクチャの議論ポイントを提示出来ればと考えます。

解決すべき課題は「そのアーキテクチャがベストプラクティスに則っている事」なのかを今一度振り返る機会になれば幸いです。

概要

相当昔にLaravel 5.5でUploadedFileのことについてまあまあ詳細に書いてきたのですが、あれから数年も経ち2桁台に差し掛かってきたLaravelの現在のUploadedFileがどうなっているか、5年ぶりに暴いていこうと思います。

留意事項

現在リリースされている最新版の10.xでお話する予定ですが、11.xがリリースされた場合は、11.x版で修正してお話します。

アジェンダ

1. UploadedFileの歴史
2. UploadedFileの内容を暴く（表面上）
3. UploadedFileの内容を暴く(実装上)

多くのPHPerは日常的にGitを使用していると思いますが、理解して使いこなせているでしょうか？
このトークは、新卒PHPerやGit初心者を対象に、チーム開発におけるGitの“使いこなし方“に焦点を当て、実践的なノウハウをお届けします！

単にcommit&pushしているだけの「ただ使う」レベルから、わかりやすいPRを作るために適切なコマンドやオプションを選択できる「理解して使う」レベルへとステップアップしましょう！

具体的なトーク内容

• 具体的な実装を用いて、この修正に対してどうコミットすると良いかを解説！
• レビュアーにとってわかりやすいプルリクエストの書き方のポイント！
• チーム開発でブランチはどう切ると良いか？
• 便利なGitコマンド/オプションとその使い所！
• コミットやプルリクエストは今開発するためだけに必要なものじゃない。未来の開発者のために残していくものなんだ。

Gitを使いこなすことは、楽しいプロダクト開発に繋がるということを、皆さんに伝えたいです！

「デプロイ頻度」は開発生産性を測る重要な指標の一つです。
2、3ヶ月程度かかる大きめの機能開発で、機能をまるっと作ってからリリースしようとすると、このデプロイ頻度が落ちてしまう経験をした方は多いのではないでしょうか？
このようなとき、プルリクエストが肥大化しレビューが複雑になり、見落とされた不具合や障害が発生しやすくなってしまいます。

このトークでは、私のこれまでの反省を活かし、大きめの機能開発でもデプロイ頻度が高い状態を維持した事例を紹介します！皆さんの日々のチーム開発に取り入れられるよう、具体的なテクニックについて順を追って説明します。

話すこと

• 細かくデプロイするために必要な設計の工夫
• タスクを分割するには、インタフェースだけ先に実装してデプロイしよう
• テストコードが先に書いてあると安心して実装できる
• チームでデプロイ頻度を上げるために取り組んだ施策

新卒入社して2、3年後ぐらいで出来ることが増え、大きな機能開発も任されるようになったとき、設計をどのようにすればいいか分からない、大きい変更のタスク分割が難しいと悩むことがあると思います。
このトークではその悩みを解決するヒントを見つけられる(かもしれない)のでぜひ聞きに来てください！

TechTrainというエンジニア教育のサービスを3年ほどECSで雰囲気で動かしてきました・・・。
バッチの処理についてはWebサーバー全く分割されておらず、サーバー負荷が高まると落ちる可能性もあり、落ちたかもわからない。そんな状況でした。
よくある移行ではあるものの、詳細が話されることがなさそうな、ECSのTaskをECS Task Scheduleにバッチ処理を移行し、移行した際に困ったことや実は公開してなかったけど、起こっていたことをお話しします。

スキーマ駆動開発は非常に強力な開発手法です。

• API仕様とサーバ実装が確実に一致し、クライアントライブラリは自動生成されます。
• フロントエンドは型システムの力により、「サーバ」を意識せずに開発が可能です。
• 「APIの繋ぎ込み」タスクや結合テスト時の問題切り分けが不要になります。

なるほど、完璧な作戦っスね―――ッ
不可能だという点に目をつぶればよぉ～

スキーマ駆動開発はしばしば「辛い」と言われます。

• スキーマと実装とをそれぞれ書かなければいけません。
• 開発中の変更がフロントエンドのCIを予期せず壊すことがあります。
• 破壊的変更を避けるために類似のエンドポイントが乱立しがちです。
• 実際には、仕様と実装が常に一致しているとは限りません。

これらの課題をLaravelおよびLaravel OpenAPIを使用して解決します。

• ライブラリの機能を活用し、スキーマと実装との二重化を解消します。
• 仕様と実装との不一致を自動的に検出します。
• フロントエンドのCIを壊さないスキーマの運用を行います。
• そもそもスキーマ駆動開発とは何かを解説します。

これまでOpenAPIやスキーマ駆動開発に苦労したことのある方はもちろん、これから導入を検討している方々にとって有益な内容です。

PHP を含む、クラスベースのオブジェクト指向プログラミング機能を持つ言語（あるいはそれ以外の言語でも）インターフェースを利用できます。
アプリケーションの実装上の設計を考えたことがある人は、インターフェースが使えると何が嬉しいのか？どんな場面で使えばよいのか？と思ったことがあるのではないでしょうか。

本トークでは、また設計の文脈で聞いたことがあるかもしれない「腐敗防止層」というワードとともにインターフェースの使い方、ひいては設計全般に通用する考え方をお話します。

想定聴講者

以下を満たす方が聴講することを想定します。

• PHP のコードは一通り書ける（フレームワーク上でも可）
• 機能追加等によって、実装上の設計を考える必要がある（考えたことがある）
• クラスベースのオブジェクト指向プログラミングにおける「継承」等の意味はわかる

フレームワークに備わっているようなクエリビルダや ORM、便利ですね。

一方で「この SQL 文はクエリビルダの機能では表現できないな」「長年使われてきた秘伝の SQL 文があってな......」といったケースで生の SQL 文を使わざるを得ない、というケースがあるかもしれません。

そこで今回は以下の 3 つの手段で生 SQL を扱う方法を説明します。

• PHP に組み込まれている PDO
• Laravel で使われている Eloquent
• Symfony で使われている Doctrine ORM

本トークで扱うもの

• 各手段で生の SQL を実行し結果をオブジェクトにマッピングする方法
• 具体的なコードやセットアップ
• それぞれのメリット・デメリット

本トークで扱わないもの

• 各 ORM の「王道」の使い方
• 実アプリケーションにおける応用