トーク

test

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

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

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

想定する観客

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

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

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

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

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

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

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

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

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

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

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

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

概要

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

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

ターゲット

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

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

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

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

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

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

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

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

PHPは時刻を文字列から取得する仕組みとして、日付/時刻パーサーを提供しています。
このパーサーが受け付ける表現の幅広さは凄まじく、その特性を利用することによって、開発者の意図をより正確にコードへ反映することが出来ます。

本トークでは、PHPの日付/時刻パーサーが受け付ける表現にはどういったものがあるのかを紹介します。
またそれを詳しく知ることによって、コードの表現はどう変わるのか、どう分かりやすくなるのかをお話させていただきます。

お話すること
・PHPの日付/時刻パーサーが受け付ける表現の種類
・高い表現力を利用した場合における、日時操作のコード(DateTimeImmutableクラス, date_parse(), etc...)
・実務でパーサーの高い表現力を利用したコードを書く際に注意すべきこと

注意事項
・日付/時刻パーサーの内部的な実装については基本的に触れません

「カンファレンススタッフは敷居が高そう...」「どんなことをするのか分からない...」「私でもできるのだろうか...」
そのような不安を感じていませんか？

私は2025年「カンファレンススタッフをやってみよう！」と行動し始め、これまで5回ほど当日スタッフとしてカンファレンスに携わりました。
このLTでは主に当日スタッフとしてやったこと、実際に当日スタッフをやってみた感想についてお伝えします。

話すこと
・カンファレンススタッフとは
・「スタッフをやってみよう！」と思ったきっかけ
・当日スタッフとしてやったこと
・スタッフとしてカンファレンスに携わった感想

このLTを通して「カンファレンススタッフをやってみよう！」と思ってくれる方を増やし、ひいては関西コミュニティの持続可能な運営体制の構築に寄与することを目指します。

陰キャの陰キャによる陰キャのためのPHPカンファレンスの楽しみ方を紹介します。

話すこと
・陰キャエンジニアのための、PHPカンファレンスを楽しむための心構え
・カンファレンス会場での効果的なぼっち行動
・疲れないための休憩戦略
・懇親会でぼっち飯にならない方法