Laravel・Symfony をはじめとする PHP のフルスタックフレームワークの多くは、DI コンテナを提供しています。
もちろん、そのようなフレームワークを使わなくても、PHP の DI ライブラリ は OSS として利用できるものがたくさんあるため、適宜導入が可能です。

もはや我々にとってなくてはならぬ存在となった DI コンテナですが、みなさん一度は自分で作ってみたいと思ったことがあるのではないでしょうか？

このセッションでは、最低限、どのような要件を満たせば DI コンテナと言えるのか、PHP で広く知られる規約であるPSRの定義を起点に、各種フレームワーク・ライブラリの実装を追いかけながらなんちゃって DI コンテナの要件定義をやってみようと思います。

ソフトウェアエンジニアには抽象化の能力が重要と言われます。
では実際に抽象化とはどのような能力なのでしょうか？

実際の事例を交えながら、抽象化を理解し、実務に活かせるようにします。#

話すこと

• 抽象化と具体化とは
• 抽象化のメリット
• 現実で身につける抽象化の階層
• 抽象と具象の往復とは
• ソフトウェアと抽象化

話さないこと

具体的なソフトウェアの実装における抽象レイヤーの話

テストコードを書くって、最初はハードルが高いですよね？
私は、まったくテストコードが書けずに悩みました。しかし、今では少しずつ書けるようになり、テストのタスクを自ら進んで取りにいくことやレビューで指摘できるまでになりました。

この発表では、PHPUnitを初めて触れた時の挫折から、業務を通じて学んだこと、そしてどのように成長していったかをジュニアエンジニアの視点でお話しします。
また、テストを書くことが私の開発プロセスにどのような変化をもたらしたのかについてもお話します。

話すこと:
・初めてテストコードを書いた際の失敗と学び
・テストコードを書くために必要な考え方や技術を習得したプロセス
・テストコードを書いたことでの変化

対象者:
・これから自動テストを学ぶ方
・テストを書くことに苦手意識を持っている方

皆さんは使われていない不要なコードを消していますか？？
長い期間運用保守しているものだと使われなくなったコードはたくさんできてくると思います。
そのような不要なコードを削除するって結構大変です。

そこでこのトークでは、どんなコードが不要なのか、それをどのような手順で削除していくのかについて話をしていきます！

話すこと

• 不要コードとは？
• 不要コードはなぜ生まれ、なぜ消さないのか
• 不要コードを消す手順

本番でエラーが発生！
焦りますよね。
まずは、ユーザが困っていないかの判断をしましょう。
さてその次は？
ログやデータベースなどの事実を元に例外が発生している原因の調べ方と向き合い方について話したいと思います。

例外を出さないように品質高いものをリリースすることは大前提ですが、
それでも例外は起こるもの。
例外が起こるということは？ユーザがふかく使っているということだ！ハッピー！
例外をローカルで再現できた！ハッピー！
（サービスの特性によってはマジでこんなこと言ってられないと思いますが）
例外対応は、エンジニアの華ですよね。楽しくやっていきましょう。

仕事でもプライベートでも多くの方が目標設定をしていると思います。
私が目標設定をする際に、次のような悩みを抱えている時期がありました。

• 同じような失敗を繰り返している
• 何も行動出来ず時間だけが過ぎる
• 行動してるけど思った様な成果が出ず目標達成できない

改善方法を探す中で様々なふりかえり手法に出会い、取り入れたことで以前のような悩みが無くなりました。
その結果、設定した目標を達成できる事が多くなりました。

このトークでは私が目標達成に向けて利用しているふりかえり手法を具体的な事例を交えてご紹介します。
過去の私のように目標達成までの道のりで迷子になってしまっている方にお届けしたい内容です。

サービスは生き物のようなもので、放置すれば腐ってしまいます。
適切なメンテナンスとアップグレードが必要です。
本セッションでは、古くなったPHPフレームワーク(Laravel)を再生するための具体的な戦略を解説します。

ユニットテストの導入、Laravelアプリケーションのコンテナ化によるインフラ刷新、Laravelアプリケーション/MySQLのバージョンアップなど、数々の挑戦とそれを克服した方法を紹介します。

これにより、デプロイ頻度の向上、テストコードによる仕様の明文化、システムの安定性を向上させることができました。

実際の成功事例を通じて、参加者はPHPプロジェクトの持続的な進化を支える具体的な戦略を学ぶことができます。

「この関数の実装、頭に入りきらないな...」「結局このコード何がしたいんだ...?」
みなさんこんなことを思った経験はないでしょうか？
これ、もしかすると抽象レベルが整っていないことが原因かもしれません。

このセッションでは

• 認知負荷を抑えたロジックを書く方法
• ロジックの情報量をコントロールする方法
• 抽象レベルを整えるとなぜ関心の分離ができるのか

などをお話しします。

「テスト(自動化テスト)を書くのが苦痛」という人がいる一方で
「書いた方が開発が早くなる」という人もいます。なぜ？

「楽に仕事を進める」を追求したに過ぎないのです
「全部そうしよう」と思わず「楽に書けそうな所なら書く」という面もあるでしょう

肝となるのは
「必要なものを考える↔コードを書き上げる」の一連の動きの内で
何をどう切り取り、何で仕事を担い、どんな順番で実行し…の捉え方＝マインドセットです
(ちょっとだけ道具の使い方も！)

プログラミングの捉え方をちょっと変えて
「テスト好きじゃない」から「書いた方が早い」への一歩を踏み出すためのトークをします

こんな人に

• テストが苦手だ、嫌々やっている
• テストに興味があるけど、どこから始めれば良いのか分からない・環境がない

伝えたいこと

• テストで楽をする・早くなるってどんな感覚？
• やりやすい所から始めよう！！

私が主宰するカンファレンスではSNSアイコンが印刷された名札をご用意しています。
この名札は「バリアブル印刷」といって印刷所に「このIllustratorデータをテンプレートにしてココにアイコンをココに名前を入れて下さい」的にお願いして作っていますが、なかなかツラく時間がかかる作業です。

今年3月に開催されたPHPerKaigi 2024ではカンファレンス運営支援ツールforteeに名札生成機能を実装し、印刷所への依頼から作業完了までの日数を3営業日まで縮めることができました。

このトークでは印刷所に入稿できる名札データをPHPでいかにして作るかをお話しします。透明色入りPDFデータ、CMYK変換、フォント埋込など、泥臭く手探りの世界でどう苦しみ、どう解決したかをお楽しみください。

「PHPは脆弱」

PHPerの方ならこの言葉一度は聞いたことがあるでしょう。

これなんでなんでしょうね〜〜！？！？！？わかるひとーーーー！！！！？？？？

ということで、本トークでは「PHPは脆弱」と言われるようになった原因について以下のようなワードに触れつつ、歴史から振り返ってお話をします。
そして、その内容を踏まえ、我々は「どのようにプログラミングをしていけば、より安全なソフトウェアを開発していくことが出来るか」について自分なりに述べさせていただきます。

• PHPの実行形態・言語の特徴
• 静的解析
• IPA
• ラスマス・ラードフ
• PHP財団
• 標準化
• CVE
• セキュリティ
• エンジニアバブル

普段PHPを利用している方も、これから書いてみたいという方も楽しめるトークを目指します。

ソフトウェア開発を行っていると以下のような用語を見かけると思います

• 〇〇の原則
• 〇〇パターン
• 〇〇アーキテクチャ

これらの用語に触れると、興味と好奇心を掻き立てられると思います。
いざ調べてみるとこれらの用語が具体的に何を意味するのか、どのように適用されるのかが分からなくて圧倒されます。
これらの用語の具体的な例や実践を通じて理解するのもいいですが、かなり数も多く時間がいくらあっても足りません。
特に〇〇アーキテクチャというものが色々な人々が語っていますが、具体的なイメージがつかず、気軽に試す事もままなりません。
そこで、一つ一つの用語を覚えるよりも体系的な理解を行っていくことが必要なのではないか？と考えています。
本トークではこれらの用語がどのように関連し合っているのか？どのように向き合っていけばいいのか？をお話いたします。

PHPドキュメンテーション
「password_hash() は、 アルゴリズムやコスト、ソルトといった情報もハッシュに含めて返すことに注意しましょう。 」
ぼく
「え、ソルトも同じところにあったらセキュリティ的に意味ないんじゃ？」

このセッションでは、そんな疑問に答えるべく、password_hash関数について掘り下げて解説します。
そもそもパスワードをハッシュ化する目的や、パスワードにまつわる攻撃手段とその対応を見ていきましょう。

話すこと

• ハッシュ化とは何か
• なぜパスワードはハッシュ化する必要があるのか
• ソルトは何を解決するか
• ブルートフォース攻撃やタイミング攻撃への対応

クリーンアーキテクチャを学ぶと、まず目にするのがあの同心円構造です。
そのため、構造、レイヤーの配置に注目されがちですが、本質は依存の向きを整えることにあるとわたしは思っています。

クリーンアーキテクチャが伝えたいのは、構造や配置ではなく、オブジェクトの依存関係を制御することで得られる柔軟性や保守性を高めるための考え方です。

当トークでは、この「依存の向き」と「依存の制御」がなぜ重要なのかを深掘りし、以下の点に焦点を当てます。

■ 依存の向きの重要性
「依存性は、内側だけに向かっていかなくてはならない」というルールがなぜ重要で、システムの安定性にどう貢献するのか。

■ 依存性逆転の原則（DIP）
SOLID原則の一つである依存性逆転の原則を取り上げ、依存の制御がシステムの柔軟性と保守性にどうつながるのか。

一緒に依存の向きの大切さを理解し、設計へ活かす方法を学びましょう。

このセッションでは、FrankenPHPにおけるPHPの稼働方法とその高速性の理由について解説します。以下のポイントを中心に進めます。

• FrankenPHPの概要: FrankenPHPの基本構造と仕組みを説明し、他のPHPランタイムと比較してどのように異なるかを紹介します。
• PHPの稼働メカニズム: FrankenPHPでPHPがどのように実行されるか、そのプロセスフローを詳述します。
• 高速性の理由: FrankenPHPが高速である理由を技術的な観点から解説します。

対象者

• 高速なPHP実行環境を求めている方
• ウェブアプリケーションのパフォーマンス最適化に関心がある方
• FrankenPHPに関心がある方

一時期「PHP とバージョン番号の変遷が似ている」と言われた MySQL。

つい最近バージョン 5.7 から 8.0 へのマイグレーションが済んだばかりの方も多そうな気がしますが、バージョン 8.0.34 / 8.1.0 からリリースモデルが変更になり、LTS として 8.4 系が、イノベーションリリースとして 9.x 系が登場するなど、すでに「8.0 より後の世界」に進んでいます。

このセッションでは、 普段 MySQL の動向について追いかけていない方々に向けて、以下のような内容をお伝えします。

• リリースモデル変更ざっくりおさらい
• 8.0 以降のバージョンへのマイグレーション
• 周辺ツールの変化
• たまには思い出してあげてほしい HeatWave
• 【おまけ】 phpMyAdmin の Issues から眺める MySQL の変更点

みなさんはシステムの設計を進めた後で、「こうしておけばよかった」と思う瞬間はありませんか？私はたくさんあります。

初めてテックリードとしてプロジェクトにアサインされ、技術選定やシステム設計を試行錯誤して進めました。
プロジェクト当初はうまくできたと感じていましたが、開発メンバーが増え、プロジェクト規模も大きくなり、振り返ると「こうすべきだった」と思う場面が増えてきました。

特に痛感したのは、技術選定やシステム設計といった基盤部分は、後からの変更が難しく、当時の判断がプロジェクト全体に大きな影響を与えることです。
本セッションでは、そんな経験を踏まえ「もしもう一度やり直せるならこうする」という視点で、以下の内容を中心にお話しします。

・テスト設計について
・アーキテクチャ設計について
・ドキュメント設計について

技術選定や設計に悩んでいる方にとって参考になる情報をお伝えします！

Garbage collection (GC) とは、確保したメモリ領域を適切なタイミングで解放する仕組みのことです。
メモリが比較的潤沢になった今でも、メモリ溢れによるサーバ障害は決して珍しくありません。
PHP における GC を理解し、メモリを意識したプログラミングをすることで、本番サーバを夜中に落とさないようにしましょう。

主な対象

• 普段メモリを意識してプログラミングしていないかた
• 言語処理系の内部実装に興味があるかた
• メモリ溢れで本番環境をダウンさせたことのあるかた

話すこと

• PHP における GC のアルゴリズム
• 確保したメモリはいつ解放されるのか
• メモリ溢れを起こさないプログラミング

話さないこと

• GC のパラメータをいじってチューニングする

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

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

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

概要

PHPUnitはPHPテストフレームワークのデファクトスタンダードとして長年使われており、普段PHPを書いてる方であれば目にしたことがあるツールの1つです。
プロジェクト規模が大きくなればなるほどテスト数が増加し、PHPUnitの実行時間が増え、CI待ちがボトルネックになるといったことが多々あります。
今回はPHPUnitをあの手この手で低速化する方法をお伝えすることによって、逆説的にPHPUnitの実行速度劣化を防ぐ考え方が身につきます。

このトークでお話すること

• PHPUnit実行速度とボトルネックの計測の仕方
• 並列化やDB I/Oが実行速度にどれくらい寄与するか
• etc...

ターゲット

• PHPUnitが遅いプロジェクトを担当している方
• 現状のPHPUnitの実行速度を速めたい方
• PHPUnit自体の仕組みを理解したい方