トーク

test

PHPUnitにおける「データプロバイダー」とは、1つのテストメソッドを引数を変えて実行する「パラメタライズドテスト」を実現する仕組みです。
#[DataProvider]アトリビュートを使うと実現できるのですが、類似のアトリビュートに#[TestWith]があるのはご存知ですか？

以前はちょっと使いにくかったのですが、最近では#[TestWith]もとても便利になってきていて、私自身#[DataProvider]よりも#[TestWith]を使う機会が増えてきています。

このLTでは、パラメタライズドテストを実現するアトリビュートの種類と、私なりの使い分け方をお話しします。

想定する観客

• PHPUnitを使っているがデータプロバイダーを知らない人
• #[DataProvider]は使ったことがあるが#[TestWith]は知らない人

考えるより感じろ！

「今やってるこれ、何度もやってるな…これ、便利ツールにしたら二度と書かなくて済むのでは？」って思う瞬間、ありませんか？

そんなときにバイブスあるコーディングです！！！

このLTでは、そうした“ノリ”で作る小さなPHPツールの実装Tips、サクッと役立つテクなどを紹介します。
難しい理論や設計の話はナシ！Vibeのままコードを書いて、便利にして、また次のコードへ。

今日のバイブスが明日の時短になるかも。

過去のカンファレンスでOSI参照モデルのプロトコル実装に関する発表を聞いたとき、「自分でも実装してみたい」と思うと同時に、このような“階層による責任の分離”は、コード設計や組織構造にも通じるのでは？と感じました。
OSIが解決している課題や、層が混ざったときに起こる問題を紐解くことで、私たちの設計やチーム運営にも活かせる視点が見えてきます。
本LTでは、異分野から学んだ“構造を守る”ための考え方とその応用についてお話しします。

PHPカンファレンス関西2025ではカンファレンスに初めて来るという方も多くいることと思います。

私が、カンファレンスに参加したときは知らない世界をたくさん見ることができ、大いに刺激を受けた一方で、レッドピルを飲んで真実を知ってしまったような感覚も味わいました。

業務で扱うコードは制約もあり、せっかくカンファレンスで学んだことを活かせないことも少なくありません。

そんな中でも、今日カンファレンスに参加したあなただからこそできることがあります。

このトークでは、カンファレンスに参加したあなたが明日から、自分の周りから少しずつ、改善を始める方法をお話しします。

現代の多くのスクリプト言語は行末に ; を必要としないシンタックスを提供している一方、PHPは基本的に式文の終端に ; を要求しているため、他言語からPHPへの参入障壁となっています。このトークではPHPの言語機能を駆使して、コード上に ; を書かずに任意の処理を記述するテクニックを紹介します。

具体と抽象の関係は、プログラムだけでなく実際の仕事でも非常に重要な概念です。

しかしながら、具体と抽象の関係性は、知らなければなかなか気づくことができません。
いろいろなタスクに具体と抽象の関係性を見つけ出し、チームで布教活動を行っていたところ、チームメンバの発案で「具体と抽象 ―世界が変わって見える知性のしくみ」（細谷 功 著）の読書会を行いました。
すると、日々の会話やタスクの進め方にもみるみる変化が...
この発表では、「具体と抽象」に入門し、日常的に使うようになったチームの日常を紹介します。

共通クラスへの仕様追加、みなさんどうしてますか？
私は一度、抽象クラスに処理を書こうとして「これ全テスト壊れるやつだ」と震えました。
Factoryパターンを導入して処理を切り出したことで、影響範囲の限定、レビューの見通し改善、テストのしやすさまで一気に良くなりました。
このLTではその設計改善の実体験を共有します。

PHPのアップデートといえば、新しい文法や関数が使えるようになって開発者体験が向上した！みたいなどちらかというと攻めの意味合いに目が行きがちだと思います。
しかし実際に CVE 対応を検討する中で、OS のバージョンによりパッチの適用に課題が生じた経験から、“守り”の視点の重要性を実感しました。
このLTでは、アップデートにおける“語られない守り”に光を当て、今を守りながら未来を選び取るための向き合い方を共有します。

以前、別のカンファレンスで「var_dumpとvar_exportの理解から始めるPHPのソースコードリーディング」というタイトルで、
php-src の中身を読んで調べた内容を発表しました。
発表の準備として、改めてvar.cやzend系の関数を読み直す中で、不安だったところを丁寧に確認し、自分なりの理解を深めていきました。
その過程を経て、今ではphp-srcを読むことが自然な選択肢になり、調査や設計判断の場面でも「読んで確認する」ことが当たり前になったと感じています。
このLTでは、発表がきっかけで“読む”という技術の向き合い方が変わった、自分自身の小さな変化を共有します。

近年、LLMの進化に伴い、AIを用いたコーディングが現実のものとなってきました。
しかし、AI Codingには課題も多く、うまくAIが動いてくれない。思ったとおりにコーディングしてくれない。と、もやもやしている人も多いかと思います。
そんなときに役に立つのが呪術廻戦です。
呪術廻戦における呪術の理論体系を参考にAI Codingの課題と性能のトレードオフについて語ります。

PHPでResult型（クラス）を再現してみるセッションです。
Result型とは、処理結果を「成功（Ok）」または「失敗（Err）」のいずれかの値として表現し、例外を使わずにエラー処理を構造的に記述するための手法です。

本セッションでは以下について話す予定です。
・Result型（クラス）の説明
・PHPでResultを実現するとどんな感じになるのか（コード例を交えて解説）
・自分なりに考えるPHPでResult型（クラス）を使うメリット・デメリット

多くのレガシーな PHP コードベースでは、インスタンスクラスを使わず、静的メソッドを関数のように扱うスタイルが一般的に採用されてきました。

しかしこの設計は、特にユニットテストの観点から見ると、静的メソッドのモックが難しいという課題があります。一般的なテストフレームワークでは静的メソッドのモックがサポートされておらず、そのため開発者は StaticMock のようなライブラリに頼る必要があります。

ただし StaticMock では、モック対象のメソッドが静的解析されないため、IDE のコードジャンプ機能が効かないといった不便さがあります。

そこで注目したいのが、PHP 8.1 から導入された「第一級 callable」構文です。これを使えば、静的メソッドをクロージャとして渡すことが可能になります。

本トークでは、この新しいアプローチとその実践的な活用方法について紹介します。

本LTではAWS Lambdaを題材にLambdaで開発したアプリケーションにおけるセキュリティリスクの1つの解説し、そのリスクをみなさんにも体験していただきます。
お手元に用意いただくのはスマートフォンのみです。

5分でセキュリティリスクを体験してみましょう。

ジョシュアツリーの法則って知ってますか？
「名前を知ればそれを認識できるようになる」「名前を知らないと認識できない」といった現象のことです。

我々エンジニアの身の回りには様々な現象があり、中にはみんなが経験したことがあるものも多数存在します。
そんな「現象」や「事象」の中にはあまりにも名前が付けられ、事象の解消や共有が行われているものがあります。
名前を知ることは認識すること！
この発表を聴いてそんな""あるある""の名前を知り、事象を正しく認識して、次に生かしましょう！

概要

カンファレンス登壇してみたいけど、難しそう。。。
そんな印象をお持ちな方（もしくは持っていた方）結構いらっしゃるんじゃないでしょうか？

しかしその印象はもしかしたら誇張して見えてる高いハードルかもしれません。
テストを書くかの如く、テストケースを洗い出してステップを明確に可視化し、登壇に挑戦してみてはいかがでしょうか？

ターゲット

• 登壇に興味はあるけど、一歩踏み出せない方

「登壇してみたいけど、プロポーザルの書き方が分からない・・・。」
そのように感じている方はいらっしゃいますか。

私は「PHPカンファレンス新潟2025」で初めてプロポーザルを出しました。
その結果、採択いただいたばかりでなく、「あのプロポーザルよかったね」とお褒めの言葉をいただきました。

このLTでは登壇未経験だった私が、初めて出すプロポーザルをより良いものにするためにやったことをお話しします。

⚪︎やったこと
・「募集要項」「実行委員長の思い」を確認する
・「プロポーザルの書き方」の資料を参考にする
・採択されているプロポーザルの構成を真似る
・ペルソナを決める

PHPカンファレンスでの登壇経験のない方が「プロポーザルを出してみよう」と一歩を踏み出すきっかけになれば嬉しいです！

レコメンド機能や新機能の効果予測など、ウェブアプリケーションで使われる機械学習はエコシステムが出来上がっているpythonで実装されることが多く、ウェブアプリケーション自体はPHPでもデータ取得や推論部分はpythonで実装されていることがほとんどだと思います。
課題は

1. データスキーマをPHPで定義した場合、スキーマを変更したときにデータ取得のpython側でもスキーマを考慮する必要がある
2. ウェブアプリケーションと違う言語なので、頭の切り替えコストが高い
3. python側とのリクエスト/レスポンスの設計が難しく、リアルタイムデータを推論エンジンに与えようとすると、POSTのbodyが超巨大になることもある

PHPのデータ整形/機械学習エコシステムは砂漠状態のため、どうしてもPHPで機械学習をしたい私がPHPの機械学習でできたこと/できなかったことを紹介します

古くなったプロダクトのコードをリファクタリングしようとして、逆に障害を招いてしまった。そんな経験を何度かしてきました。
特にPHPでは、なんとなくコードを変えただけで、思わぬところが壊れてしまうことも少なくありません。

今回は、そんなPHPリファクタリングでの失敗談を、びゃっと5分でご紹介します。
このトークが、みなさんのしくじりを防ぐヒントになれば幸いです。

皆さんは、インプットだけでなく、記事を書いたり、LTをしたりといったアウトプットをしていますか？僕は、1年前Qiitaに記事を投稿し始めるまではほとんどアウトプットをしていませんでした。

そんな僕が、去年の2月からQiitaに毎日記事を投稿し始め、約1年でなんと160記事を公開しました。
テーマは主にPHPやReactなど、日々の学びや実践で得た知見です。

「アウトプット経験ゼロ」からスタートした僕が、どのようにして投稿を続け、何を得たのかについてお話しします。

お話しする内容：
　・どんな内容の記事を書いたのか
　・毎日投稿して感じたメリット（知識の定着、反応がもらえる楽しさなど）
　・デメリットや大変だったこと（ネタ切れ、モチベ維持など）
　・投稿を通して得られた成長
　・やってみて感じた素直な感想

「自分も何か書いてみようかな」と思ってもらえるきっかけになれば嬉しいです！