プロポーザル

Laravelの監査ライブラリ「Laravel Auditing」は、Eloquentモデルでのレコードの作成、変更、削除を詳細に追跡する強力なツールです。しかし、Query Builder経由の操作は監査対象外のため、重要な変更が見落とされるリスクがありました。
私たちのチームでは、この課題を解決するため、Query Builderによるレコードの作成、編集、削除も監査ログに残せるように拡張を行いました。

本LTでは、以下の内容をお届けします。

・Query Builderの操作をログに含める必要性
・Laravel Auditingの仕組みを理解するポイント
・Query Builder操作のログ拡張方法（実装の工夫や設計の考え方）
・拡張後のメリットと運用のポイント
これにより、監査ログが取りこぼされるリスクを大幅に低減させ、システムの透明性と信頼性を向上させる方法をご紹介します。

EloquentとQuery Builderの両方を活用するチームにとって、日々の開発に役立つ内容をお届けします。

対象者
・Laravelを使ってシステム開発を行うエンジニア
・Laravel Auditingを導入している、または導入を検討しているチーム
・EloquentとQuery Builderを併用して開発を進めている開発者

このセッションではPHPで作成したアプリケーションをVercelにデプロイする方法を紹介します。

Vercelは「Vercel のフロントエンド クラウドは、開発者にフレームワーク、ワークフロー、インフラストラクチャを提供し、より高速でパーソナライズされた Web を構築します。」(X：@vercelより引用)で、PHPのイメージはありませんが、PHPのアプリケーションをデプロイすることができます。

また、VercelにはVercel PostgresというPostgreSQL(データベース)を提供するサービスもあります。PHPとVercel Postgresを用いてアプリケーションを作成し、Vercelで公開することができます。

このセッションでは、VerceでPHPを用いたアプロケーションを公開する方法とVercel Postgreの紹介をします。

私はコミュニティ活動として、PHPTeaNightというオンラインイベントを定期開催しています。

その会でPHPStanをテーマとして参加者の方からいただいたPHPStanとの向き合い方がとても良かったので共有したいと思います。
baselineは減らすにはどうしたら良いのか？そもそも減らすべきなのか？レベルはどのくらいが良いのか？
など普段疑問に思っていることを利用者はどう感じて、どうPHPStanと向き合っているのかLTでお伝えできればと思います。

（あと、そんな利用者の声が聞けるPHPerTeaNightについても知ってもらえたらと思います）

皆さんyield使っていますか？
使う人は結構使うし、使わない人はとことん使わないyield文ですが、非常に味わい深い挙動となっています。
サンプルコードに対しての期待値を皆で考えてみて学ぼうという趣旨です。
時間が足りなくて銅鑼が鳴るか？それともネタが尽きるのが先か？そんなネタLTです。

ISUCON（Iikanjini Speed Up Contest）とは年に1度開催されるチューニングコンテストで私自身毎年参加しています！
遅いプロダクトを限られた時間内でチューニングしていき速度が上がっていくのを体験するのはとても楽しいです。
しかし実際に同じような状況が仕事で発生したとしたらどうでしょうか。。

顧客の要求している性能を満たせていないプロダクト、迫る納期、頻繁に連絡してくるクライアント。
やることは同じチューニングなのに冷や汗しかかかない状況に残念ながらしばしば直面することがあります。
ISUCONでは改善に失敗しても良い経験だったで終わりますが現実だとそうはいきません。
制限時間（納期）までに必ず「顧客が求める性能」をクリアしないといけない。
まさにリアルISUCON状態になった時、皆さんはどうするでしょうか？
実際のISUCONと同じように計測してボトルネックを治す。インフラ構成を見直す。対応は色々あると思います。
大会と現実で違うのはサーバーそのもののスペックアップを行う、仕様や画面設計そのものを再検討するなど顧客の要求をクリアするために広範囲の手段を取れることだと思います。
そして大会と同様システムそのもの改善も行いながら達成のために様々な手段を用いて顧客の要求を満たしていきます。

このトークでは、悲しくも現実でリアルISUCONが始まってしまった場合の私なりの戦い方をお話しします。

PHPは1994年に誕生し、現在でも多くのプロジェクトで活用されている歴史ある言語です。
そんな長い歴史を持つPHPには、これまでに多くの「奇妙な歴史的経緯」が存在します。
本セッションでは「PHPマニュアル 日本語版」に記述される「歴史的経緯」について5分で紐解き、その背景を紹介します。

歴史的経緯を知ることは、PHPに対する理解を深め、より良いコードを書ける手助けになるかもしれません。
皆さんはいくつの「歴史的経緯」を知っていますか？

開発をしているときにコメントがあると助かりますよね。
「なるほど、ここはそういう処理をしてるのか！」と、コードの中身を詳しく読まなくとも実装を進めることができます。
しかし、時としてコメントは嘘をつき、あなたを陥れます。
特に古いシステムではこれまでに蓄積され、忘れられ、熟成されたコメントが至るところに散りばめられています。

私が以前開発に関わっていたメール共有サービス「メールディーラー」はリリースから20年以上経過しているサービスであり、熟成されたコメントが多数存在します。
このLTでは私が実際に遭遇したレガシーコードに潜む奇妙なコメントをご紹介し、コメントを盲信することが如何に危険なことであるかを知っていただきます。

コメントを信じるか信じないかはあなた次第です！

※PHPカンファレンス関西2024で発表した内容と同じものです

PHPUnitのデータプロバイダーは、1つのテストメソッドを引数を変えて実行する「パラメタライズドテスト」を実現する仕組みです。
PHPUnit 10以降ではアトリビュートを使って実装しますが、そのときに使えるアトリビュートは実は4種類もあるのをご存知ですか？

このLTでは、これら4種類のアトリビュートを紹介した上で、私自身がどう使い分けてデータプロバイダーを実装しているのかお話しします。

お話しすること

• データプロバイダーとは何か
• データプロバイダーを使う利点
• PHPUnitにおけるデータプロバイダーの実現方法
• 4種類のアトリビュートの使い分け方の提案

想定する観客

• PHPUnitを使っているがデータプロバイダーを知らない人
• #[DataProvider]/@dataProviderしか使ったことがない人

2,147,483,647
これ何の数字か分かりますか？
そうですね！INTの最大値ですね！

DBを設計していて何となくIDカラムをINT型にしている人、多いのではないでしょうか？
初めのうちはいいのですがサービスの成長と共にレコードが増え、INTの上限値になった場合どうなるのでしょうか？

本セッションでは

• 実際に弊社で起きた事象と対応
• DB設計において気をつけるべき点

をお話できればと思っております！

PHPUnitは、いわゆる「xUnitファミリー」といわれるソフトウェア群のいち実装であり、
2024年時点で最新版は11と、とても老舗のプロジェクトと言えます。

時代に適応して変わっている部分はあれど、根底にある思想は共有されているはずです。
昔から変わらない？変わった？じゃあ、クイズの時間ですね！！！

このLTを聞いて、明日からPHPUnit 1 (もしくはPHPUnit 11)にちょっとだけ詳しくなりましょう。

学べること

• 明日から、職場でPHPUnit 1を用いたテストコードを書く際にも、少し自信を持って取り組めるようになります

得られるかもしれないこと

• 長く続くソフトウェアプロジェクトの実例から、「本質的で変わっていないこと」「変化に晒され、淘汰されたもの」について思いを馳せる機会になるかもしれません

発表すること

• まず簡単に、PHPUnit1を実行している様子をお見せします
• 機能や設定を紹介して、「1にある」「11にある」「両方にある」の3択クイズをします
• 特にアサーションメソッドの有無について、多く出題されます
• 同一のメソッドに置いて「どちらの挙動か」を問われるものもあります

PHPマニュアルって、マジで、マジでめちゃくちゃ読みやすくないですか？
駆け出しだったときにありがたかったし、なんなら今でも本当に感謝するレベルだし。あの丁寧さのおかげで今の私があります。
そんなわたしですが、2024年、はじめてPHPマニュアルの翻訳作業に貢献することができました・・・！

このトークでは、PHPマニュアル翻訳のOSSコントリビューション物語を通じて、「きっかけの掴み方」や「得られたこと」についてお話しします。

• その機能を知るきっかけになり、自分のためになる
• 「このページの一部を作った」という嬉しさ
• さまざまな貢献の仕方があることを実感する

使うものから、みんなで育てていくものへ。
このトークがあなたの素敵な一歩の後押しになることを目指します！

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

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

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

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

「List とは、キーが連続した数値 (0 から count($array)-1) である配列」これだけ覚えて帰ってください。

その上で、このライトニングトークでは

• PHP 内での扱われ方
• 静的解析
• 内部実装

の 3 つの視点から List についてお話します。