Laravel eloquentを使ったRDS上での検索クエリは、テーブル間のJOINやクエリの複雑さが検索パフォーマンスに悪影響を与えていました。特に、利用頻度の高いクエリがレイテンシー低下の主因となり、その改善を目指してOpenSearchを導入しました。

結果、検索速度が飛躍的に向上し、レイテンシーも大幅に改善されました。また、OpenSearchのPHP DSLライブラリを導入することで、クエリの構築をシンプルにし、保守性を高める工夫も行いました。

Laravel eloquentとの共存を図りながら、検索機能のパフォーマンス最適化を実現しました。これらの経験を基に、検索機能改善の実例を紹介します。

このトークは、パフォーマンスに課題を抱える開発者や、検索機能の改善に興味のある方に向けた内容です。

PHPでCookieを管理する際、セキュリティ面やライフサイクルについては意識するものの、
サーバーサイドとクライアントサイドの境界を意識することはほとんどありません。
しかし、近年ではSSR（サーバーサイドレンダリング）の普及により、
サーバーとクライアントの役割が明確に分かれ、Cookieの扱いにも違いが生じています。

このトークでは、PHPとSSRにおけるCookie管理の違いに注目し、
両者の処理の境界がどのように影響を与えるかを解説します。

PHP開発者がSSRで直面しやすい問題点や、それに対するよりベターなプラクティスを紹介し、
Cookie並びにフロントエンド技術への理解をより深めていただくことを目指します。
実践的な知識を持ち帰り、PHPからSSRへの移行に役立ててもらうことを期待しています。

画面開発で、こんなお悩みを抱えていませんか？

• デザインに統一感がない
• デザインレビューの観点が曖昧
• ゼロからデザイン制作とコーディングが必要
• CSSの保守が難しい

これらの課題が原因で開発効率が低下しモチベーションも低下してしまいました。その解決策の一手として、デザインシステムの導入を進めました。
今回は、すでに存在していたデザインリニューアルのデザイン案をベースに、プロダクトにデザインシステムをうまく反映できていなかった状況から、仕組みを整備して導入を進めるまでの一連の取り組みをお話します。

話すこと

• デザインシステムとは
• 導入に向けての取り組み
• 導入前の課題、導入後の効果
• 導入が進まなかった要因・進んだ要因

対象者

• 画面開発にお疲れぎみの人
• フロントエンドのレガシーな構成にお悩みの人
• デザインシステムに興味がある人

最近では、DevOpsの中にSecurityを意識した活動を含める、DevSecOpsの様な考え方が広まっており、この様な流れの中でSAST（Static Application Security Testing）やDAST(Dynamic Application Security Testing)の様な検査をCI/CDに組み込む事例を見かける様になってきました。

このセッションでは、SASTツールの一つである、SonarQubeの基本的な機能や特徴、実際にCIに組み込んでの活用方法、実行環境の構築例などについてお話しします。

話すこと

• SonarQubeの概要
• 現場でのSonarQube活用方法
• 実行環境の構築例

SQLにおいて、最も重要なのは「正確さ」、次に優先すべきは「速度」です。
これらの要件を満たすため、どれだけ努力しても、時には可読性が犠牲になることがあります。
本セッションでは、正確さと速度を最優先した結果、可読性が低くなってしまったものの、非常に高い精度と高速性を持つSQLを実例を交えて紹介します。
一見して何をしているのか分かりにくいかもしれませんが、その背後には緻密な工夫が詰まったSQLの世界をご覧ください。

主に非エンジニア、WEBディレクターや初心者向けのセッションです。

対象:
• WEBディレクター
• 企業などのWebサイト管理者
• PHPにこれから触れるかもしれない人

ゴール：
エンジニアとの要件定義内容の確認やベンダーとの会話が少しはスムーズになれたらいいな。

内容:
受託会社で働いていると、改修や運用案件で、どうしてPHPを選ばなかったの？ または、その反対にどうしてわざわざPHPにしたの？ って案件にめぐり逢います。
クライアントから相談いただく「運用しにくい」「更新が自由に行えない」といったサイトやサービスは、PHPの使われるところが間違っているのでは…と感じることが多いです。
ちょっと知識があれば、防げたかもしれない…！

非エンジニアの人に役立っていただけそうなことをお話できればと思います。

リッチなUIを実装するために多くのアプリケーションでjQueryが利用されています。
導入がしやすい、使いやすい、プラグインも豊富といった利点がありますが
DOM操作の命令的なコードはロジックやUIが複雑になると保守性が悪くなる傾向にあります。

一方で、ReactやVueなどのフレームワークは、宣言的UIにより保守性が上がりますが
学習・運用コストなど過剰な技術となるケースも少なくありません。

本トークではLaravelのMPAにおけるフロントエンドの実装手法についてお話します。
Alpine.jsを使ったUI実装を中心に、jQueryの使いどころ、ViteやNative ESMによるJavaScriptの管理、Blade連携、コンポーネント化について紹介します。
チームやプロダクトに適したアーキテクチャを選択し、より本質的な課題解決ができるきっかけとなれば幸いです。

オブジェクト指向を学ぶ私たちは、必ず一度は「SOLID原則」に触れる機会があると思います。
私も何度も学習を重ねる中で、その原則がもたらす恩恵や、守ることの重要性を徐々に理解してきました。

…ただ、「リスコフの置換原則（LSP）」だけは「これを守るとどう良いのか？」がいまいちしっくりきていませんでした。
「同じ気持ち！」なあなたに向けて、このセッションでは、以下のようなお話をします。

• LSPとは何か？よくある例と「なぜピンとこないのか」
• 実際に私が遭遇したLSP違反の具体例
• LSPと"継承"の関係性をしっかりと理解する

「なるほどLSP完全に理解した！」といってもらえるようなトークにします！

小さくコツコツ手をつけておけばよかった…そんな気持ちになることもあるかもしれません。。
日々降ってくる、マイナーバージョン・パッチバージョンの更新を適応するのはとても大事です。

メジャーバージョンがあった場合はどうでしょう？？
依存パッケージ間の依存関係があるなど、マイナーバージョン・パッチバージョンの更新と比較して、複数のパッケージの同時更新が必要だったりもします。

・composer updateのおさらい
・composer updateで何ができるのか？何が起こるのか？
・パッケージ更新のはまりポイント
・コツコツパッケージを更新していくために…

パッケージを更新するコマンドであるcomposer updateを軸に、日々のパッケージ更新のヒントとなるポイントをお伝えできればと思います！

ここ数年、私はRaspberry PiでCPUを作っています。
これは、Z80というCPUをコンピュータから取り外して代わりにRaspberry Piで作った自作CPUを取り付けて動かすというものです。

このトークでは私が作成した2つのバージョンのCPUを題材に、以下の様なことをお話します。

• 少ないGPIOで多くの信号線をコントロールする工夫
• CPUを作るというのは具体的に何をするのか
• 手配線で作るCPUと基板発注して作るCPU
• 自作CPUのデバッグ方法
• Linux上でプログラムを動かすことのメリットとデメリット
• 全てを手放して速度を得る - ベアメタル開発

このトークを聞いた方が「CPUを作るというのはどういうことか」をちょっぴり理解し、CPUやハードウェア自作が好きになることを願っています。そしてあわよくば一緒に自作CPUを楽しみましょう！

2024年1月、「なぜキャッシュメモリは速いのか」が話題になりました。
この質問に答えるのはなかなか難しく、X（Twitter）ではいろいろな回答がされていました。この回答はさまざまな立場・理解からされていて、Xのタイムラインをご覧になっていた方はいまいちしっくりこなかったのではないでしょうか。

このトークでは「なぜキャッシュメモリは速いのか」に答えるのに必要な知識を、初心者の方にもわかりやすくご説明します。

• キャッシュメモリとは何か
• なぜキャッシュメモリを使用するのか
• キャッシュメモリとメインメモリは何が違うのか
• 結局なぜキャッシュメモリは速いのか

キャッシュの使いこなしは現代コンピュータにおいて避けることはできず、キャッシュを制するもののみがコンピュータを高速に動作させられると言っても過言ではない状態です。キャッシュを理解し、キャッシュを楽しみましょう！

昨今需要が高い子どもの安全確保に応えるべく、保育・教育施設向けICTサービス「CoDMON(コドモン)」では、園児の登降園時間帯の所在確認機能を短期間で開発しました。

本セッションではプロジェクトを進行するにあたり、どの様な課題を経てリリースできたのか、以下のことに触れながらお話しできればと思います。

1. 機能の全体像とユーザーに届けられた価値
2. 毎日の数百万近い子どもの打刻データを捌きつつ
   • 複数ドメインにまたがるデータを駆使して園児の所在確認を行う複雑性
   • 他の機能群に負荷を与えないインフラの構築課題
3. 課題に対して選択したアーキテクチャとその効果
4. 開発後の保守における課題

概要: オブジェクト指向プログラミングの基本概念である「Class」と「インスタンス化」を、弊社エンジニアが後輩に教える時の例として、ポケモンを例によく用いています。
具体的には、ピカチュウをクラスに例え、モンスターボール内のピカチュウがインスタンス化され、技を使うという流れで説明のようなものです。静的変数（static）やインターフェースといった概念も、ゲームの要素を用いて理解しやすい形で説明します。
上記の内容に加えてSOLID原則などのより詳細なオブジェクト指向設計などを用いて話せるよう内容付与していき、初学者の方も、初学者に教える方も、参考になる内容です。

キーポイント:
・クラスとインスタンス化の基本概念の紹介
・インスタンス化によるコストの考察
・静的変数やインターフェースをポケモンに例えて解説
・さらにSOLID原則などオブジェクト指向設計の参考になる詳細事例

Web APIの成功は、その設計や機能だけではなく、どれだけ優れたドキュメントを提供できるかにかかっています。APIドキュメントは、開発者がAPIを正しく理解し、活用するための鍵であり、ユーザー体験とシステムの信頼性を大きく左右します。本セッションでは、モダンAPI開発に不可欠なAPIドキュメンテーションの基本的な考え方から実践的なツールの活用法、さらには継続的なドキュメントのメンテナンス手法まで具体的に解説します。

トピック:

• よいドキュメントのヒント、主要な構成要素
• Swagger/OpenAPI、TypeSpec、Postmanなど自動生成ツールを活用し、開発プロセスに組み込む方法
• ドキュメントのメンテナンスとその自動化

参加者はこのセッションを通じて、継続的にAPIユーザーに優れたAPIドキュメント体験を届けるための知識を習得できます。

Googleから2023年10月に発表され、2024年2月から適用された「メール送信者のガイドライン」。
メール送信機能を有するサービスは何らかの対応に追われたのではないでしょうか。

私が担当するサービスでも、他の開発スケジュールが立てられていた中でガイドラインへの対応を迫られました。
顧客数が多く、それぞれが異なる用途でメールを送信するサービスにおいて向き合った
　・事業サイドにガイドラインを説明してもうまく伝わらない
　・OpenDKIMとPHPによる2段階でのDKIMリリース
など、苦労と工夫をお話しします

皆さんは清水の舞台から飛び降りる気持ち(※)で自社サービスにAWSを導入したことがありますか？私はあります。

私が担当しているメール共有サービスのメールディーラーは2001年にローンチしましたが、すべての機能がひとつのサーバに実装されており、apacheとDBですら集約されています。

また、フレームワークを導入しておらず、ひとつのファイルにDBアクセスを行い、print文でHTMLを出力しています。

そのためプログラムの陳腐化が急速に進んでいます。

そんな「モノリシック」を地で行くサービスに、AWSを導入することになりました。

AWSを導入した目的とどのような効果があったか？また、今後どのようなアーキテクチャしようとしているかを、メールディーラーのテクニカルリーダである私が可能な限り具体的に事例をもって説明いたします。

※一世一代の決断をする意味のことわざ

皆さんはリリース後に文字化けが発生して、道頓堀に飛び込みたくなったことはありますか？
私はあります(※)。

PHP8.2の下位互換性のない修正の1つにmb_detect_encodingの文字コード検出の仕様変更があります。

私が担当しているメール共有サービスのメールディーラーで、バージョンアップ後に一部の受信メールが文字化けをしました。
原因は受信したメールのエンコード時に、前述のmb_detect_encodingを使っていたことです。

下位互換性がないPHPの仕様変更だったため、文字化けを回避することができず、
メールヘッダに文字コードの指定がないメールまで対応することになり、その対応に述べ約7人日かかりました。

メールディーラーのテクニカルリーダである私が、顧客対応で泣きをみたことを中心に苦労した経験をお話しいたします。

※実際には飛び込んでいません。

事業の成長スピードに追いつくためにスピード優先で開発した結果のコードに、このような特徴がありました。

• DBとの接続や外部サービス通信、業務ロジックなどすべてが詰め込まれている
• 何が業務ロジックで何がそうでないかが判断しづらい
• データに型がなくすべてがarrayである
• テストがない

あるとき、機能追加に伴いコードの保守性が低いことに危機感を感じてリファクタリングに踏み切り、業務ロジックの切り出しなどユニットテスト可能にしていく対応を行い、非常に扱いやすくすることができました。

このセッションでは、リファクタリング活動について、修正前コードと修正後のコードがどのように変化したのか、安全にリファクタリングを行うためにどのようなテストを用意したのか、リファクタリング活動を通して気づいたこと/学びについてお話します。

Rustは高いパフォーマンスとメモリ安全性を両立したプログラミング言語で、最近ではLinuxカーネルの開発に一部取り入れられたことでも話題になるなど、人気の高い言語の一つです。

そのRustで、PHPの拡張モジュールを作ることができるのをご存知ですか？
拡張モジュールは通常C言語で開発されますが、ext-php-rsというライブラリを利用すると、Rustで書いたコードをPHP拡張モジュールとしてコンパイルすることが可能になります。

このセッションでは、PHPerでありRust初心者の私がRustを使ってPSR-7ライブラリを開発した経験をもとに、以下のことをお話しします。

• Rustはどんなプログラミング言語か、PHPとの比較
• PSR-7について
• RustでのPHP拡張モジュールの作り方・デモ
• Rustを使ってみて感じたこと

障害が起こった時には全力で対応しますよね。
障害が起こった後の再発防止までちゃんと検討してますか。

このセッションでは、再発防止のアイディアを捻り出すための方法と、それを実行に移すためのチームルールについて共有します。

例えば、アイディアを捻り出す方法には、こんなステップを踏んでいます。

1. ロジカルシンキングで原因を網羅的に洗い出す。
2. 原因を解釈する。
3. 事実や解釈に対応する再発防止策を考えてみる。
4. 良いものが出なかったら突飛なアイディアも出してみる。
5. ロジカルシンキングでマッピングして、よりアイディアを抽出する。
6. ROIを考えて実行するものを決める。