トーク

PHPUnitで書くテストケースは、基本的に返り値を持ちません。
普段は「返り値は void」として扱い、return しても無視されます。

でも #[Depends('...')] を付けた時には、あら不思議、依存元の返り値が依存先の引数として使えるようになります。
手で書き方を覚えてしまえばなんとなくは理解できるけど「どこで誰が拾って、どうやって次に渡してるの？」は意外と曖昧になりがちです。

このLTでは「おまじない」で片付けず、実際の実装まで踏み込んでいきます。
「使えるから使う」ではなく、「どう動いているかを知った上で使う」ための Depends の話をします！

話すこと

• そもそも Depends ってどんな機能？
• Depends がどのような実装になっているか
• Depends の使いどころ

CIのテストに時間がかかって困る…
時間がかかっていそうなテストの修正や、XDebug無効化などの対策は試したが思ったように短くならない

そんな経験はないでしょうか？

闇雲にテストを修正するのはもう終わりです！

PHPUnitのフック機能を使って、個別のテストにかかっている時間を計測し、それに基づいた改善でテスト時間を約30パーセント削減した事例をお話します。

テストも「推測するな、計測せよ」で改善しましょう

最近アップデートの勢いが増していて、フロントエンドのパッケージ管理ツールとして定着してきているpnpm。
npmからpnpmに移行してみて、pnpm v10系のアップデートで「これは良い！」と感じた3つの機能を紹介します。

本LTでは、主に下記の方を対象に、今日からプロジェクトの安全性と開発体験を少し良くできる便利機能を紹介します。

• PHPだけでなくフロントエンドにも携わるフルスタック寄りの方
• npmもしくはYarnから乗り換えようか迷っている方
• pnpmを使っているが最近のアップデートを追えていない方

pnpmを何となく使っている方にも、これから導入したい方にも役立つ内容です。

巷で噂される OpenTelemetry、PHP 8 以降でも、PHP 7 以前でも、思い切って始められる地盤が整備されてきているので、Step-by-Step で Metrics や Trace といった観測情報を可視化するまでを簡単にご紹介します。

• ローカルでアプリケーションを OpenTelemetry Collector と並べて動かす
• ローカルで 採取できた Metrics や Trace を 監視サーバーに送信する
• ローカル環境をクラウド環境に置き換えて同様の観測データ採取を実現する
• Processor の設定を調整して最適な情報に絞り込む
• Trace ID で Log とも紐付くようにして何が起きてたか可視化しやすくする

こんな感じで、みんなで Observability をやっていきましょう、というトークです。

TypeScriptでGitを再実装する機会があり、その内部構造の美しさに感動しました。ふと、これってPHPでも実装できるんじゃないかと思い調べてみると、CLIツールを作ることができる symfony/console と呼ばれるものがあることを知りました。じゃあ作ってみるしかないか...

本LTでは、PHPを使ってGitのコア機能を実装するプロセスを紹介し、Gitの内部構造がいかにシンプルで洗練されているかを共有します。

このLTで得られること

• Gitの内部構造に関する知識
• symfony/console を使ったCLIツール開発知識

Laravelアプリケーションを本番環境にデプロイするには、nginxやphp-fpmの設定、データベース、ロードバランサー、ドメインの設定など、様々な工程が必要です。
さらに、コンテナ化しようと思うと、Dockerfileを書いたり、ECSやkubernetesなどのオーケストレーションツールを使う必要があり、なかなか大変です。

俺はただアプリを開発してデプロイしたいだけなのに、何でこんなに大変なんだ！

Laravel Cloudを使えば、複雑な設定なしに、Laravelアプリケーションを簡単にデプロイし、趣味アプリから本格的なサービスまで運用できる環境を手軽に構築できます。

このセッションでは、 laravel new で新規Laravelアプリケーションを作成し、デプロイして公開するまでを5分でやってみます。
本当にできるのか？できるはず！試してみよう！

業務でよくある画像のアップロード機能。
ファイル形式やサイズのバリデーションはきっとやっていると思います。

では、画像の「中身」は見ていますか？もしユーザーがクレジットカードや免許証、マイナンバーが写った画像をアップロードしてしまったら？

「文字を読み取ってチェックする？OCRを使う？」
「でも自由に撮影された画像だと精度が出なくて…」
「そもそも文字が書かれていない場合どうするか」

そこで、AWS Rekognitionの物体認識で「写ってはいけないものが写っているか」を検出するアプローチに切り替えました。
OCRから物体認識への切り替え、信頼度スコアとの戦いについてお話しします。

バグバッシュ（Bug Bash）は、役割を問わずメンバーが短時間にプロダクトを集中的に触り、バグや違和感を洗い出すイベントです。
機能テストがAIや自動化で強化される今こそ、人間が作った機能を自ら触る機会が減り、チームのプロダクトに対する理解を意図的に増やすことが重要になってきていると感じています。
バグバッシュは役割横断でプロダクトを触りながら対話することで、バグを探すだけでなく仕様意図やUXの理解をすり合わせていけるイベントです。
私たちは2週に1度のプロダクト共有の場に合わせ、多様なステークホルダーに集まってもらいバグバッシュを開催しています。
チーム開発文化とプロダクト理解を同時に育て、チームがプロダクトを自分たちのものとして扱っていくためのイベントを紹介します。

導入

初心者エンジニアが技術的な成長を続ける上で、ライブラリ、フレームワークの公式ドキュメントやプロダクトコードを読む力は不可欠ですが、その難解さに挫折しがちです。
​非エンジニアのPdMである私は、以下の活動を続けています。
​毎年、マーケティング、哲学、人文学、工学書など150冊以上の広範な読書。
​この経験を通じて得た「文章の構造を把握する力」が、PHPコードや技術ドキュメントの理解力向上に直結することを発見しました。

​本LTで共有する内容（5分）

​この異色の経験に基づき、広範な読書から導き出した「技術的なテキストを抵抗なく、効率的に理解するための3つの思考法」を共有します。
​この思考法は、あなたが今後遭遇するすべてのドキュメントへのアプローチを変え、自己学習の質を高める助けとなるでしょう。

ユーザーが触れるインターフェースを設計しているのはデザイナーかもしれませんが、
実装の多くはエンジニアが行っています。
ローディングの出し方、待ち時間の扱い、エラーや進行状況の見せ方などは、
そのままユーザー体験につながっています。

本セッションでは、デザイナーとして、またフロント実装やプロダクトづくりに関わってきた経験から、
「実装の判断がどのようにUXを左右しているか」を具体例とともに紹介します。

UX/UIの原則・心理学を少し知っているだけで、
「この実装でユーザーはどう感じるか？」という視点を持ち込むことができ、
設計書から漏れていたこと・違和感に気づいたり、
より良い選択肢を提案しやすくなります。

本セッションでは、 よりよいプロダクトを作っていくための手段として、
UX/UIの話をしたいと思います。