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

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

天然の問題の養殖の問題より奇なり。
現場で見つかった驚きの事実を皆様にお送りします。

※フィクションです

PHP8が2020年11月26日に登場してから、日々進化し続けているPHP。
つい最近はPHP8.3の登場もあり、以前の言語とは比べない程に型システムの改善や、パフォーマンス向上されてきました。
一部機能を取り上げれると以下の改善があります。

• JITコンパイラの利用
• Union Types, Mixed Type
• 属性(Attributes)の使用
• エラーハンドリングの改善
• Constructor Property Promotion

筆者も普段はPHP8で業務のコードを書いて、その恩恵を受けています。
このプロポーザルでは、PHP8の沢山ある機能の中でも実際の業務を通じて、学んだ事のアウトプットとしてPHP8で堅牢にコード書くTipsについて紹介します。

エンジニアは開発だけではなく、仲間集めを会社から求められることもあります。
多くの採用フローでは最初にカジュアル面談というステップがあり、候補者に会社について興味を持ってもらう場が存在します。

採用フローの入り口であり、ここを上手くできなければその後の面接に繋がらない大切な会ですが、慣れるまではなかなか上手く行かなかったり、何話したらいいのか分からないことも多いと思います。

自分もここ1年ほどで週1〜3回カジュアル面談を担当しましたが、最初はめちゃめちゃ難しかったです。

この経験を踏まえて、採用におけるカジュアル面談ってどういう準備をして、何を話して、どうやって次の面接につながればいいのかお話します。

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

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

『リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック』（Boswell & Foucher）
エンジニアのみなさんなら、一度は読んだことがあるのではないでしょうか。

私はブライダル専門メディアを自社開発・運営している会社で保守開発を担当しており、
現在はサイトの一部機能を削除する案件にジョインし、開発を行っています。

Laravelで構築された弊社のサービスは、約20年続く結婚式場のクチコミサイトです。
改修に改修を重ね長年運用されてきたサイトの機能を削除することは、簡単ではありません。
例えば、以下のような問題に苦戦しました。

・表記揺れをしている、または意味を汲み取れない関数名・変数名である
・あちこちでクラスが継承され、メソッドやViewファイルの依存関係が複雑である
・おそらくもう二度と使われないプログラムをきれいさっぱり削除できているか、不安になる

この経験から、普段からシンプルで美しいコードで運用・保守していくことの大切さを痛感しました。

本トークでは、歴史ある大規模サービスの機能を削除する上で直面した問題と、そこから得た学びを共有します。
“機能削除”という観点から、『リーダブルコード』をどのように意識して実践していくべきか、一緒に考えませんか？

ソフトウェア開発において、品質と生産性の向上は常に追求される目標です。
しかし、これらの目標を達成するための手段として、コードレビューの重要性がしばしば見落とされます。

本セッションでは、
・効果的なPRテンプレートの作成方法
・レビューイが良いコードレビューを受けるためのポイント・テクニック
・レビュアーがコードレビューをする上で気をつけるべきポイント・テクニック
などの我々が実際に取り組んできた効果的なコードレビューの実施方法とその重要性について解説します。

「コードレビューをどのように行えばよいかわからない」「他のチームはどのようにコードレビューを行っているのか知りたい」という方々にとって、
本セッションは有益な情報を提供します。

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

この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 と友達になれるかも

WEBアプリケーションを開発するうえでセキュリティは切っても切り離せない重要な事柄です。

WEBセキュリティの情報や教科書はたくさんありますが、全てを勉強するのは大変です。
実際に現場であった事故やコードの例を紹介し、最近のフレームワークを活用したWEB開発で起こりがちなセキュリティ事例をお話しします。

◆対象者
・ある程度PHPでWEBアプリケーション開発をしているジュニアorミドルエンジニア
・チームが書くコードをセキュアにしたいリードエンジニア

◆書くこと
・コードレビューしてたらこんな危ない書き方があった！
・こんな脆弱性があった！
・こんな攻撃を受けた！

WEBアプリケーションを開発するうえでセキュリティは切っても切り離せない重要な事柄です。

WEBセキュリティの情報や教科書はたくさんあります。
皆さんも勉強されていることでしょう。

しかし、セキュリティ事故が起きたら一体どんなことが起きるのでしょうか？
PHPで書かれたWEBアプリケーションが攻撃され、実際にセキュリティ事故が起きた時にとても辛かった思い出を面白おかしく話します。

◆対象者
・ある程度PHPでWEBアプリケーション開発をしている人

◆話すこと
・前提の状況
・実際に起きたこと
・どんな対応が起きたか
・どれだけ寝れなかったか

C 言語で書かれている PHP 処理系の内部にはクラスを表現するもの、オブジェクトを表現するもの、配列を表現するもの、値を表現するもの、実行中のコールフレームを保存するものなど、様々な構造体が存在しています。これらがどのような構造をしているか、各フィールドがどのような意味を持ちどのような使われ方をするか、とりとめなく漫然と書き出してみます

世の中に入門書や入門者向けの記事は溢れています。
上級者向けの書籍や記事も増えています。
入門書を終えた後、次のステップに進むために何を学ぼうか悩んでいるビギナーの方は多いのでは無いでしょうか？

PHPを使って業務で開発を行っていくうえで、次のステップとして学ぶと良いことを具体的なケーススタディやコード例を交えてお伝えしていきます。

PHPerKaigiでは上級者向けの面白いトークや記事が沢山ありますが、技術コミュニティとして裾野を広げるためには、初中級者向けのコンテンツも有用と考えます。
これらの方々へ有益な情報をなることを期待します。

◆対象者
・入門書をやり終えた程度のPHP初心者
・簡単なWEBアプリケーションが作れるようになったPHP初中級者

◆書くこと
・バグを生み出しづらい書き方
・チーム開発において読みやすい書き方
・コメントの入れ方
・セキュリティを意識した書き方
・コーディング規約
・エラーメッセージの見方

チームの成長と改善を促進するために、定期的なふりかえりは重要です。
しかし、「単なる会議に終わってしまう」、「カイゼンが継続しない」、「なんか微妙な雰囲気で終わってしまう」...など、ふりかえり自体がなんだかうまくいかないことってありませんか？
実際に私も上記の経験をしてきました。その失敗たちを元にカイゼンを重ねていったわたしの「最強のふりかえりファシリテーター法」をお話します！

私が大事にしていること

• ポジティブな雰囲気作り
• 気になったもののみを深ぼる、選択と集中
• チームの雰囲気に合わせて手法を選択する
• カイゼンを継続させる

オブジェクト指向プログラミングにおいて重要な概念となる「SOLID原則」 。
本セッションでは、自分が違反して書いてしまったコードを例に、SOLID原則を紹介していきます。

どのSOLID原則に違反しているか

• 違反がもたらす具体的な問題
• 正しい実装
• 多くの書籍でSOLID原則に関する具体例が示されていますが、このセッションでは「実際の失敗例」を通じてSOLID原則を理解していただこうと考えています。

自分がミスってしまった実装例を、時間の許す限り赤裸々に公開します！！

開発って実はお金かかるんです！
え、そんなのは知ってる？

じゃあ、新しい機能を作るとき、どのくらいのお金がどこにかかるか、考えたことあります？
私は詳細まで考えたことはないです。なので今から実際のプロダクトを例に考えてみましょう！

たとえば、PHPだけじゃWebサービスは提供できませんよね。
そのWebサービスがAWSなどの従量課金制のプラットフォームで動いているならアクセス量に応じてお金がかかりますよね。
PHPとそのサービスを動かす仕組み自体にも当然運用コストが乗ってきます。

ところでPHPを書いている人は？仕組みを組み立てている人は？そのサービスはエンジニアだけいれば成り立ちます？
つまり、機能の開発にも運用にもお金がかかるのです。

当然時間もかかるので、綺麗事抜きに、これから作る機能は、そのお金を払ってまでも作る価値はありますか？と問いかけて作っていったほうがいいのはないでしょうか。
その機能を作ることでどれだけの人の労力と時間を削減できるのか、それをお金に換算するといくらなのか、を考えることで
あらためて自分たちが生み出すことができる価値の大きさを知ることができるような気がしています。

「良いプロダクトを作るためにもっとエンジニアとビジネスサイドで協力していきたい！」
その想いを胸に半年前からスクラムを使ってプロダクトを作っています。

それまではエンジニアとビジネスサイドが同じチームで深く関わって仕事をすることがあまりありませんでした。
スクラムを入れる上でコミュニケーションの取り方をガラっと変えたかったのですが、ちょっとハードルが高いかもな、、と感じました。

そのため最初は敢えて「不完全」な形式でスクラムを始めました。
スクラムの良さをチームで実感するにつれて、徐々に「完全」なスクラムになっていきました。
そして今は「チーム全員で良いプロダクトを作っている」という感覚があります。

本トークでは、どのようにスクラムの体制を改善していったのか実体験をベースにして紹介します。

このトークの対象

• スクラムに興味がある人
• 組織的な課題でスクラム導入に悩んでいる人

テストコードの品質は、開発プロセスにおいてとても大事です。
その中でも、適切なAssertionメソッドの使用は、テストコードが読みやすく理解しやすいものにする一歩と言えます。

私は読みやすいテストの一歩は「適切なAssertionを使うこと」だと思っています。
いつも「assertSame」にしちゃっていませんか？Assertionメソッドはたくさんあります！このトークで学んでいきましょう！！

スクラムでの開発にはレビュー会という、スプリント内で実装した価値をお見せする場がある。
決まっていない部分はダミー実装で後回しにして、Interfaceを切ってIOだけを明確にして、とそこまでは順調だった。

だがしかし、レビュー会までにプロダクトは出来上がらなかった。

不確実なことを抽象のままできるだけ後回しにして実装したのに、詳細の実装が間に合わなくなってしまったのはなぜなのかを実装の進め方とともに振り返ってみようと思う。