トーク

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

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

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

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

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

このセッションでは

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

などをお話しします。

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

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

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

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

こんな人に

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

伝えたいこと

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

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

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

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

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 の変更点

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

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

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

概要

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

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

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

ターゲット

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

関心を持ち続けながら勉強会に参加していると、ふとしたことがきっかけでさまざまな情報がつながり、点から線そして面に変わり、勉強会で学んだ情報が業務に役立つことがあります。

勉強会でプログラムの本質的構造を示すASTのハッシュ値が同じであればプログラムの変更前と変更後の間に差分がないと判断できるという発表を聞いたことがきっかけで、実際のプロダクト開発においてPHP 8.1からPHP 8.2にバージョンアップする作業の一部をスムーズに進められることに気づき、結果として大幅にテスト工数を削減できました。

この発表では、ASTを取得およびそのハッシュ値を比較する方法やハッシュ値の確認時に留意する点を解説しつつ、ASTがPHPのバージョンアップ時にも役立った事例の1つを紹介します。

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

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

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

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

『自分がJOINしたチームで障害がよく起きていてチームが大変そうにしているときにどうしますか？』

私の場合はサービス監視・オブザーバビリティがこのチームに必要なことだと考え推進してきました。
そしてその結果、障害は減りチームは機能開発も安定して行える状態になることができました。

このトークでは、

• どのようにサービス監視・オブザーバビリティを推進したか
• オブザーバビリティを通してのチームリード
  についてお話します。