現在プロダクトのインフラの選択肢は格段に広がっています。
AWSだけでも、EC2、ECS on EC2、AWS Fargate、AWS EKSがあります。
ただし、LambdaはPythonやnode.jsなどをサポートしていますが、PHPをサポートしてないということで選択肢に上がりません。
近年LambdaにWeb Adapterが登場したことで、様々な言語・フレームワークを動かすことができます。

本セッションはLambda Web Adapterで実際に動かした経験談をベースに、Lambda Web Adapterの良さや苦労話を共有できればと思います。

本セッションの対象者
・Lambda Web Adapterを聞いたことがない人
・Lambda Web Adapter or Bref + Laravelで開発話を聞きたい人
・Serverlessに興味がある人

みなさんは、どのような時にパフォーマンスが上がったと感じますか？
PHPコードが綺麗に書けた時、コードやDBを最適化できた時、
上司から評価してもらった時、単に体調が絶好調の時 etc.

その中でも今回お話ししたいのは、「自分で」「今すぐに」できるパフォーマンスの上げ方として
自分に合った開発スケジュールの立て方についてお話しします。

私は今年の4月に新卒入社し、半年間の社会人経験を経て「自分の意志でスケジュールを立てることの重要性」に気付くことができました。

今回は
・社内のPHPエンジニアにアンケートを取り、性格（MBTI）や経験年数などから考えられるスケジュールの取り方の傾向
・私自身のスケジュールを立てる上で大切にしていること
・（上記を踏まえて）育成側に立たれている方に考えてみてほしいこと
をお話ししたいと思います。

求人サービス「エンゲージ」はサービス開始からLaravelのモノリスなアプリケーションとして開発が行われてきました。サービスの内製化を目指して組織が急拡大していますが、毎回の機能追加のたびに発生する大規模な影響調査、チーム間のコミュニケーションコストの増加等の理由で開発速度が低下し、ビジネスサイドと開発サイドが協調して素早くサービスの価値を最大化するという、内製開発のメリットが活かしづらい状況でした。

弊社はそのような問題に対して、イベントストーミングやドメイン駆動設計、モジュラーモノリスといった開発を選択し、開発速度の向上やオーナーシップの強化を目指して取り組んでおり、その取り組みの軌跡や失敗の経験、今後の展望についてお話しします。

普段からドメインを意識した開発に取り組まれている方、これから組織に導入していこうと考えている方をはじめ、一つの事例として参考にしていただけると幸いです。

It is the year 2024 and PHP developers are still arguing about double quotes vs single quotes.
Lets explore if that actually still matters, see why it does not, learn what happens before your code gets executed and find the answer to the question: What has the OPcache ever done for us?

新入社員がテストコードを書けない場合、どのように教えますか？
日頃書く人は感覚的に書けますが、書いたことのない人はコツを掴むまで時間がかかってしまうものです。
皆様も経験があるのではないでしょうか？

本セッションでは、そんなテストコードのチュートリアルをpublicリポジトリとして公開・そのリポジトリの利用方法やテストコードを書く上でのテクニックをお話します。
Docker環境さえ整っていれば誰でもLaravelフレームワーク内でPHPUnitのテストを書くための問題集にチャレンジできる内容となっております。
全ての操作用のコマンドやREADMEを用意しているので、Dockerの知識がなくてもテストの実行やテスト用DBの中身を確認できます。

これを機にテストコードを書けるようになりましょう！

対象者：
・テストコードを知りたい方
・育成コストに悩んでいる方

サービスは生き物のようなもので、放置すれば腐ってしまいます。
適切なメンテナンスとアップグレードが必要です。
本セッションでは、古くなったPHPフレームワーク(Laravel)を再生するための具体的な戦略を解説します。
ユニットテストの導入、Laravelアプリケーションのコンテナ化によるインフラ刷新、Laravelアプリケーション/MySQLのバージョンアップなど、数々の挑戦とそれを克服した方法を紹介します。
これにより、デプロイ頻度の向上、テストコードによる仕様の明文化、システムの安定性を向上させることができました。
実際の成功事例を通じて、参加者はPHPプロジェクトの持続的な進化を支える具体的な戦略を学ぶことができます。

年月を経たレガシーなアプリケーションの検索処理は、肥大化したロジックによりパフォーマンスが劣化しがちです。本セッションでは、実際に直面した検索遅延を、OpenSearchを活用して改善した実例をもとに、選定理由から実装の課題、実際の効果までをお話します。

ターゲット

• OpenSearch導入を検討している方
• レガシー環境でのパフォーマンス改善に悩む方

お話すること

• OpenSearchの概要
• 社内で抱えていた課題
• 選定理由
• 実装時の躓き
• 実装後の効果
• 今後の課題

何が得られるか

• OpenSearchの強みと効果
• レガシーな環境での落とし穴

バックエンド開発を担当しながらスクラムマスターを務めることになり、気づけば約1年が経過しました。この1年間、開発チームの速度を向上させるために、さまざまなアプローチを試み、試行錯誤を重ねてきました。

チーム内のコミュニケーションの改善、プロセスの見直し、ツールの導入など、いくつかの施策を実施してきましたが、特に効果が現れた方法に焦点を当ててお話しします。

本セッションでは、実際に取り組んできた施策の背景、その成果、そして今後の展望についても触れながら、皆さんと共有したいと考えています。

DRY（Don't Repeat Yourself）原則はコードの重複を減らし、保守性を高める効果的な手法ですが、適用の仕方によっては仕様変更に対応できなくなることがあります。
私が直面したのは、二つの似た処理を一つのメソッドに統合し、フラグで細かい違いを切り替えるコードでした。しかし、片方の処理を変更すると、もう片方にも影響が出てメソッドが複雑化する…これ本当にDRYなん？と思いました。

このトークでは、当時はDRYだったものが、時間とともに保守性を損ない、結果的にDRYではなくなったケースについて紹介します。
何を共通化し、何を分離すべきかを考え直し、どのようにリファクタリングを行ったかについて具体的な事例を交えてお話します！

「当時はこうでよかったが、今ここに大変更を加えたい」と感じている方や、似たような体験をした方にとって、私の対処方法が参考になれば嬉しいです！

PHPは言語仕様として様々な条件分岐を持っています。if, else, elseif, switch, 三項演算子, match, &&, ||...職業PHPエンジニアの皆さんは日々これらを使いこなして仕事をしていることと思います。では、ユーザー要求や要件の中に、あるいは要求以前のビジネスの中に、仕様書やフローチャートに表される前の条件分岐の形を見出す力はどうでしょうか？自信ありますか？
このトークでは、PHPの様々な条件分岐を概観した上で、日常で人間が行っている様々なビジネス上の判断をPHPの条件分岐に落とし込む考え方についてお話しします。
様々な条件分岐が「見える」生活をしてみませんか？

This session bridges the gap between PHP and JavaScript by comparing modern features like arrow functions, classes, and destructuring in both languages. Attendees will see how PHP has evolved to include features familiar to JavaScript developers, simplifying cross-language development.

みなさんのプロジェクトは、どのようなソフトウェアアーキテクチャを採用していますか？
明確なアーキテクチャが決まっておらず、各メンバーが異なる設計をしているプロジェクトも少なくないかもしれません。
私たちのプロジェクトもその傾向にありました。

本セッションでは、プロジェクトのリニューアルを機にオニオンアーキテクチャを導入した経験について、以下の内容を中心にお話しします。

• オニオンアーキテクチャを採用した理由
• Laravelにオニオンアーキテクチャを導入する際の具体的な手法
• Laravelでの実装時に直面するであろう課題とその解決策
• アーキテクチャを維持するための取り組み
• 導入によるメリットとデメリット

「オニオンアーキテクチャって難しそう」「導入してみたけどうまくいかなかった」
という悩みを持っている方々にとって、参考になる情報をお伝えします！

驚くほど人間的な回答で世間を賑わせたChatGPT。
しかし2024年時点では工夫をせずに依頼をすると「突然英語で回答する」「架空の資料を元に回答する」など、ビックリさせられます。

本トークでは、ChatGPTに思い通りの回答をさせるためのマインドやTipsを紹介し、少しでも思い通りな回答をさせる方法についてご紹介します。

お話しすること

• ChatGPTに上手い回答をさせるためのマインド
  • ChatGPTの裏側 (LLM) を知る
  • 人間と思って接しない
• ChatGPTに変な回答をさせないためのコツ
  • Custom instructions
  • プロンプトエンジニアリング
• 業務で使う場合の注意事項
  • 学習オプトアウト
  • 機微情報のマスク

コミュニケーションは様々な場面でギャップが生じてしまいます
発された言葉「以外」の解釈コストが高くなると、受け手のイラッ・モヤッに繋がります
(何が伝わっていないの？」など)

「明瞭な部分の比率を高める」のは有効です
例えば、発言時や受信時には「事実・解釈,意見・評価,要求」の区分が助けになります
こうした工夫が、自他を尊重した態度の表現に繋がります

発表者自身が「気にしている事」「気にしすぎないために考えている事」を共有します

役に立つ事

• コミュニケーションのgood/ungoodを知ることで、仕事の「邪魔」な要素を減らす
• 言語化・形式知化された情報を手に入れることで、現場の「モヤッ」にフィードバックしやすくなる

例題

• 「肯定？否定？」「主張したいこと」がハッキリすると楽
• 「褒め」が大事なのか、あるいは必須なのか
• 「〜では？」が何故イラつかせるのか

良いコードは拡張しやすくて、そのためには適度な抽象化が必要でね──

プログラマーとしての向上を目指すと、いつでも「抽象化筋」が立ちはだかります。
が、「抽象化をできるようになるには？」と聞くと、抽象的な答えが返ってきがちで。
こいつは何だ？

私自身が「抽象に依存する、なるほど」「インターフェースって便利」と思えたきっかけの1つが、
「たぶん何かがここら辺にあって、そこに良い感じに話しかけると、きっと処理してくれるだろう」
で進む開発するスタイルに触れた事でした。

裏を返せば「話しかける相手は分からないけど、欲する事は明確である」が求められます。
抽象化思考の1つのヒントが、正にこの「過不足なく欲求を明確にし、表現する」にあるのです。

このトークでは、こうした感覚的な部分の言語化と共有を試みます。
更に、この思考とコードの記述を繋ぐ手法として「テスト駆動開発」の実践方法を紹介します。

「ライブラリが古いせいでやりたいことが出来ない」「利用バージョンのドキュメントが既にこの世に無い・・・」そんな経験はありませんか？

古いライブラリはセキュリティリスクをもたらし、技術的負債にも繋がります。
本トークでは週次でのライブラリバージョンアップを1年以上続けている実体験をもとに、継続的バージョンアップのメリットや安全に実施するために出来る工夫、はじめ方についてお話します。

想定観客

• バージョンが古いせいで苦しんでいるかた
• ビッグバンバージョンアップでつらい思いをしたかた
• セキュリティやパフォーマンスに敏感なかた

お話しすること

• なぜライブラリをバージョンアップするべきか
• バージョンアップ時に見るべきポイント
• 安全に上げるために整えている仕組み
• 継続的バージョンアップのはじめ方と文化作り

レイヤードアーキテクチャをはじめ、オニオンアーキテクチャ、ヘキサゴナルアーキテクチャ、いわゆるクリーンアーキテクチャ、他には独立したコアレイヤーパターンやADOPなど様々なレイヤ化アーキテクチャが存在していることからわかるように、レイヤを元にアプリケーションを構造化することはとても良いアイデアです。

しかし一方でレイヤを増やしたもののあまりメリットを享受できない場面も存在します。

このセッションでは、なんのためにレイヤ化をするのか、どういった観点でレイヤが作られるのか、レイヤ化することによってアプリケーションの複雑性がどのように管理しやすくなるのかといったことを考えてみたいと思います

Laravelの魅力でもあるEloquent Model。
良くも悪くも雰囲気で書けてしまう反面、特定条件下では正しく動かなかったり、パフォーマンスの悪いコードを書いてしまう恐れがあります。

本トークではEloquent Modelを使うときにハマりがちなトラップを取り上げて、それらが「良くない理由」と「どうすれば良くなるか」をご紹介します。

想定観客

• 雰囲気でLaravelを書いている方
• 不具合が起きにくいコードを書きたい方
• パフォーマンスの良いコードを書きたい方

お話しすること

• そのコード、nullが返ってきたとき死にます
• そのコード、クエリ1,000回発行されるけど大丈夫？
• そのコード、メモリ1GB使うけど大丈夫？
• 良くある間違いを仕組みで防ぐ (Laravel IDE Helper x PHPStan)

Renovate や Dependabot などが広く使われるようになったことでライブラリバージョンアップの対応頻度が高まっている現場は多いのではないかと思います。
ライブラリは導入することによって開発コストを大きく削減できる一方、使い方によってはバージョンアップの対応コストが必要以上に高くなりますので、バージョンアップ対応にそこそこの工数が取られている人も多いのではないのでしょうか。

このセッションではバージョンアップが楽になる使い方をいくつか提示し、それぞれのメリットデメリットを整理することでライブラリとの使い方・付き合い方について考えていきたいと思います。

PHP 8.4で追加された pg_result_memory_size() は、SQL実行結果の中でも memory_get_usage() に計上されない隠れたメモリ使用量を可視化します。特に大量データ処理時のメモリ不足リスクを軽減する重要なツールです。

この関数の実際の動作を見ながら、PHPでデータベースを扱う際の注意点と解決策を検討します。

1. メモリの種類: PHPが管理するメモリとそうでないメモリ。これらはサーバの動作にどのような影響を与えるのか。
2. 実例: PHP 8.4で実際に大量データを扱い、リソースのメモリ消費量を観測。
3. 開発者へのインパクト: ライブラリやインフラストラクチャ層での考慮ポイント。リソース管理の重要性。

対象者:

• PHP開発者で、メモリ管理やデータベース接続の効率化に関心がある方
• PHP内部の実装について興味がある方