とある機能を実装していたときのことです。その機能には、動的に作成・削除されるファイルの存在有無によって分岐する処理がありました。
検証環境でのテストも問題なく、満を持して本番環境にデプロイしたところ、なんと大量のエラーアラートが！
エラー内容を見てみると、どうやら削除したはずのファイルがなぜか存在すると判定されてしまっているようなのです。
調査の結果、PHPの意外な仕様が原因であることがわかりました。

上記の経験をもとに、あなたの知らない（かもしれない）PHPのファイル操作にまつわる仕様とその対策をお話しします。

Laravel でのドメインバリデーションをどこに書くか迷いますよね。

Controller に直接書くか、Model に public メソッドを生やすかのどちらかが一般的ですが、Model のライフサイクルイベントに対するフックで行うという方法もあります。

本LTでは、実際に行った実装を例にフックを使ったドメインバリデーションを紹介します。

DDD（ドメイン駆動設計）に興味があるけど、どの本から読めばいいか迷ったことはありませんか？

数多くのDDD関連書籍をすべて読むのは大変ですが、安心してください！とりあえず、手に入る本は全部読んで見ました！
本トークでは、どんな人がどのDDD関連本を読めばいいのか、独断と偏見で発表します！

このセッションでは、「何か」を求めカンファレンスや技術イベントに参加して次のアクションに繋げたいと思っている方に「今からできるアクション」をお伝えします。

私は、技術同人誌即売会にスタッフ参加したら、パソコン雑誌に記事を投稿できること知り、記事を投稿したら、掲載していただけました。
参加している最中は、実際に「執筆する」というアクションまで想像できていませんでした。
しかし、参加したことで、「なんとなく執筆してみたい」が「このような記事を執筆したい！」に変化し、次のアクションに繋げることができました。

皆さんも何かを求めてカンファレンスに参加していませんか？その何かに出会うために、PHPカンファレンス名古屋2025からできるアクションをお伝えします。

話すこと
私の

• カンファレンスから次に繋げる方法
• カンファレンス開催中の動き方
• カンファレンスが終わった後の動き方

このトークでは、画像処理やお絵描きをPHPでする方法を紹介します！

GDライブラリを用いることで、画像処理やお絵描きをPHPでも簡単にできます。WordPressでもアイキャッチ(OG画像)の生成はGDライブラリを用いて行っています。

ブログのアイキャッチのように文字を画像に重ねるだけではなく、図形なども用いて簡単なイラストを描くことも簡単にできます。

このトークで、実際に作ったイラストを紹介しつつ、どのようにGDライブラリを用いてイラストを生成しているのかもソースコードも合わせて紹介します。

DDDといっても、複数のアーキテクチャ(クリーンアーキテクチャ、オニオンアーキテクチャ、ヘキサゴナルアーキテクチャなど)があると思います。この中でどのアーキテクチャを選定するかって悩みませんか？
そんな方向けに各アーキテクチャの比較をした話をします！

話すこと

• プロジェクトの検討観点(開発規模、開発メンバーの体制、外部システムとの連携など)
• 各アーキテクチャの比較(クリーンアーキテクチャ、オニオンアーキテクチャ、ヘキサゴナルアーキテクチャなど)
• 各アーキテクチャごとの向いているプロジェクトは？

2025/02/07にPHPUnit 12がリリースされます。
PHPUnit 12で削除されるメソッドやオプション、Attributeなどの機能はなーんと25以上！

そんな削除予定の機能について、どう変更 / 対応したらよいかとセットで時間いっぱいかけて高速解説します！

LaravelのORMであるEloquent。さっと使いたい時はとても便利ですが、使い方を誤るとパフォーマンスの低下やセキュリティホールになりかねません。
そこで本トークでは実際にコードを見ながら、EloquentはどのようにしてDBを操作しているのかを見ていきます。

話すこと
・Eloquentの内部構造

話さないこと
・Eloquentを利用した実装

仕様確認の遅れや認識のズレで開発が滞ってしまった経験はありませんか？

私は「エンジニア↔︎営業」と「営業→ユーザー」の2つのフェーズで課題に直面しました。
前者は、話し合いが後回しになっていたため、仕様確認の遅れや認識のズレが原因で開発が滞りました。
後者は、エンジニアが思い描くユーザーへのアプローチ方法が営業でうまく使ってもらえず、ユーザーへ価値がうまく届いていませんでした。また、営業にリリースした機能の価値が十分に伝わっていなかったこともありました。

そこで、以下の取り組みを行いました。
・ 何を決めたい時間かがひと目でわかる会議名をつける
・ リファインメントやランチで関係を深める
・ リリース後のアプローチ方法を営業と一緒に決める

このトークでは、エンジニアと営業が協力し、リリース後の価値を最大化するための取り組みと、その結果生まれた変化を紹介します！

最近、私は多くの人と一緒にプロポーザルを考える機会が増えています。
その中で気づいたこととしては、「話してみたい」と思っていても、それを具体的なトークにまとめるのが難しいと感じる人が多い、ということです。

そんな人たちの背中を、私はこれまで何度も押してきました。
このLTでは、その「背中の押し方」を共有します。
あなたも、身近にいる「トークをしたいと思っている人」や「トークができそうな人」の背中を押してみませんか？

話すコト

• なぜ「トーク応募」を促すのか？〜相手のため、自分のため〜
• どのように「トーク応募」を応援しているのか：問いかけと引き出し
• 受からなくても活かせる方法はたくさんある！

テストに必要なPHP環境を設定できるGitHub ActionsのアクションであるSetup PHP Actionは、PHPの各バージョンに対応しているだけでなく、さまざまな拡張モジュールやツールを活用できます。さらに、マルチプラットフォームに対応しており、LinuxだけでなくWindowsやmacOS上で手軽にテストを実行させることも可能です。このLTでは、テストやOSSのコントリビュートにも役立つ、Setup PHP Actionの使い方を紹介します。

SOLID原則・凝集性・結合度・関心の分離・DDD・クリーンアキテクチャ...
設計を考える際、学ぶべき原理や手法が多すぎて圧倒されてしまうこともありますよね。

しかし、これら設計原則は、実は私たちがよく知っている「英語の文法」にヒントが隠されているかも...?
英文法の基本的なルールに着目することで、仮に設計原則を知らなくても、シンプルで明確な設計ができるようになるかもしれません！

このトークでは、SVO・SVOCなど基礎的な英語文法がどのようにコード設計に応用できるかを具体的に解説します。
例)

• S(主語)やV(動詞)の明確化が単一責任原則の遵守に繋がること
• 「S(主語)がV(動詞)した」とクラス設計を考えることの恩恵
• コード上での形容詞・副詞の在り方

想定聴講者

• 設計詳しくないけど興味がある人
• 設計に原理・手法多くてなかなか手を出せないでいる人

皆さん、チームを分割してみたけど、結局また一つにまとまっちゃったことありませんか！？

チームが分かれれば効率も上がる、役割も明確になる…なんて思っていたのに、なぜかチームが再び一つに引き寄せられてしまったんです。

その原因、実は「コンウェイの法則」にあったんです！

このLTでは、どうしてチームを分割したのに再統合が起きたのか、そしてその結果として何が得られたのかを赤裸々に語ります。

私たちが直面した課題や学びをシェアして、みなさんの組織設計にも活かしてもらえたら嬉しいです！

自分の会社の製品には多くのサードパーティサービスが組み込まれています。
それらのサードパーティサービスは頻繁にバージョンアップするので、よくパラメータを更新する必要があります。例えば base URL や secret など。
HashiCorp Vault を使用して、ララベル向けの Config 管理インターフェースを実装することで、ゼロダウンタイムで Config の変更が可能なだけでなく、エンジニア以外の同僚も一緒に Config の管理できます。

郵便番号とは、当たり前に都道府県・市区町村が特定できるものだと、そう思っている人はいませんか？
まさか「複数の都道府県にまたがる郵便番号」なんてあるわけない、そう思っている人はいませんか？

そんな罠にはまった私が、郵便番号に関する実装をする際に気を付けるべき知見を、クイズ形式で紹介します！

ご存知の通り、レビューとは「講評」「批評」という意味です。
そのためコーディングにおけるレビューも、どうしてもレビュワーから実装者への一方通行コミュニケーションになりがちな側面を持っています。

しかしレビューとは、実装者とレビュワーが解釈をすり合わせる場であり、
双方向のコミュニケーションをしてこそ、漏れなく効率的なすり合わせができると私は思っています。
今回は私がPRレビューを双方向コミュニケーションの場にするためにしていることを、3つお話しします。

• 些細な違和感を逃さない[Q]と[MEMO]
• レビュー修正者を迷わせない効率的レビュー
• チームメンバーの癖を把握した、メンバー特化型レビュー

テストを書くことにもだいぶ慣れてきましたが、いまだに嫌で仕方ないものがあります。それがデータプロバイダです。

データプロバイダを書くのは面倒くさい。本当に本当に面倒くさい。
というのもリリース恐怖症の私は、テスト対象のありとあらゆる条件やパスを通したくなります。
「いや〜書かなくても大丈夫だろうけど、怖いし一応書いとくか…」を繰り返すうちに、どんどんテストパターンが増え、データプロバイダが膨大になります。

ここでは、私をそんな無限コピペ地獄から救ってくれた「差分だけデータプロバイダ」をご紹介します。
同地獄に陥っている方の一助となれば幸いです。

⁠対象者

• いつもデータプロバイダが太りがちな方
• ツールなど使わず手動で、大量のパターンをテストしなければいけない方
• データプロバイダを書くのが億劫で仕方ない方

概要

PHPでWebアプリケーションを作る際、ほぼ全てのケースでデータ永続化の為にデータベースを利用するでしょう。
長年運用していくにつれ、テーブル数やカラム数の増加によって、認知コストやコミュニケーションコストが増加する一方です。
これらの負荷を下げる為に「DBスキーマを可視化する」ということは非常に有用であり、tblsは継続的な運用に耐えうるだけの機能を持ち合わせています。

本トークではtblsを用いたDBスキーマ可視化の実例を上げつつ、具体的なツール導入とCI設定の方法を紹介していきます。

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

• tbls紹介
• 運用例紹介
• tbls新規導入と基本的な設定
• GitHub Actions活用方法

テストコードの意図をより明確にするテクニックとしてGiven-When-Then構文というものがあります。
Given-When-Then構文はどのテストフレームワークでも適用できる万能な書き方になります。
直ぐに始められて一歩先をいくテストコードを書いてみませんか？

毎日チームの朝会でアイスブレイクから始めています。
アイスブレイクってホントになんでもいいんですけど
しょうもないネタでその人の人となりが分かる瞬間、とても嬉しくなります。

しょうもないネタ集と人となりを知るポイントなどを話したいと思います