トーク

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

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

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

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

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

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

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

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

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

私たちはオブザーバビリティエンジニアリングを実践すべく、OpenTelemetryを導入しました。
しかし満足のいくようなアプリケーションのトレーシングとメトリクスを出すまでに色々な失敗を繰り返しました。
このトークではOpenTelemetryを既存サービスに導入するにあたってどのような選択肢があるかを紹介し、どの選択をした結果どのような失敗をしたかをお話しし、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にバッチ処理を移行し、移行した際に困ったことや実は公開してなかったけど、起こっていたことをお話しします。

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

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

想定聴講者

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

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

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

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

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

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

本トークで扱うもの

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

本トークで扱わないもの

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

Laravelで出来たアプリケーションの本番環境まだEC2使ってませんか？

OSのEOL対応、PHPのバージョンアップ、サーバ障害対応などEC2で管理していると保守するだけでも色々やらないといけない事が多いです。

Laravelアプリケーションをコンテナ化してECSにデプロイすることで、辛いサーバ管理から解放されましょう。
このトークでは、EC2で管理していたLaravelアプリケーションをECSに移行するために考える必要があるポイントや移行のために必要な手順、デプロイの仕組み、ECSで運用する際に便利だったツール（ecspresso）などをお話します。

想定聴講者は、EC2でLaravelアプリケーションを運用、移行検討してる方はもちろん、インフラとかよく分からないけど分かるようになりたいという方にもおすすめです。

PHPに限らず、プログラムは繰り返しても劣化しない正確さと速さが持ち味です。人間は繰り返すと集中力が落ち、集中力が落ちると正確さと速さが劣化しがちですよね。
私は素早く開発することを突き詰めた結果、定型的なPHPコードは自分で書くよりPHPに書かせた方が早いと考えるに至り、さまざまなコード自動生成を日々試しています。
まだまだ実験途上の試みではありますが、私がどういう不便を解消したいと考えているのか、その不便を解消するために使っているツールのアップデートの履歴、PHPerKaigi2024当日までの成果を発表したいと思います。

令和になっても相変わらず紙の書類の需要は大きく、Webアプリ開発においても帳票印刷機能は多くの案件で要求されます。
しかし、これがとにかく面倒くさい。

• 複雑なレイアウトの帳票をHTML/CSSでデザインするのが地獄
• かといって超微細Excel方眼紙でデザインするのはもっと地獄
• しかもPDFに変換するときに微妙に見た目が崩れてどうにもできない

帳票印刷機能を実装したことのある方には強く共感していただけると思います。

そんな面倒で難しい帳票印刷ですが、実は私は既に数年前に最強無敵のソリューションを編み出し済みです。

• ピクセル単位で細かく帳票をデザインできる（しかも簡単に）
• 帳票デザインの保守性が高い（修正が容易）
• 印刷時に見た目が一切崩れない

という条件を満たせる唯一（当社調べ）の方法です。

このトークでは、この至高のソリューションを具体的に解説します！

API Platformは、SymfonyをベースとするPHP製のオープンソースAPIフレームワークです。
Symfonyアプリケーションにアトリビュートを1行追加するだけで一瞬でREST APIを作れてしまう優れもので、
Symfonyのエコシステムにおいては既に決定版となっています。

しかし、ある程度複雑なことをしようとすると途端にフレームワークについての深い理解が求められたり、
痒いところに手が届かず強引なワークアラウンドが必要になったりするという面もあり、入門と実戦の間には大きな隔たりがあります。

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

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

生成系AIの勢いは止まりません
先日のOpenAI DevDayではGPT-4 TurboやAssistants APIなど更に出来ることや夢が広がったと感じました

一方で現状はCode InterpreterがPython前提になっていたり、
生成系AIの領域はPythonの領域のような感触もあります

そこで今回はインフラ構築、サーバーレスアーキテクチャ構築が得意なPHPerが
生成系AIのアプリケーションを作成する時にどのような選択肢があるのかを考えながら
実際にPHPの得意領域であるWebアプリケーションと生成系AIを組み合わせるサンプルアプリケーションを作成します

その中で感じたライブラリ選定まで含めた時の、プログラム言語の選択を含める課題感の共有を行います
今現状の課題感の共有と共に、皆さんと私自身の選択に関して議論できると幸いです

• お話すること
  • PHPerを中心に据えた時に生成系AIのWebアプリケーション構築
• 前提条件
  • PHP以外の選択肢も制限しません
  • 一部マイクロサービス化することも検討します
• 今回のトークに対する期待
  • 私のトークは答えではありません。しかし私の選択に対して皆さんと議論出来ると嬉しいです

近年、急速に"(コードの)質と(それの高さからくる開発)スピード"が注目されるようになってきました。

一方で「何故、"質とスピード"を求めるのか」に対するお話はあまり見かけません。

このトークでは「孫子の兵法」から見た「"質とスピード"は何のために必要なのか」、「"質やスピード"は本当に必要なのか」についてお話します。

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

1. あらためて考える「なぜ"質やスピード"が必要なのか」
2. "質やスピード"を求める場合の基準
3. 組織人として持続可能な組織を維持するために考える事

このトークで話さない事

1. 孫子の兵法の詳解