トーク

副業でPHP（Laravel）を教える中で、技術力だけでなく、自分のエンジニアとしての姿勢やスキルにも大きな変化がありました。

「このエンジニアに教わりたい」と思ってもらえる存在を目指し、GitHubの自己紹介やブログに力を入れたり、プライベートでコードを書く時間が増えたりと、活動の幅が広がりました。
また、人に教えるには深い理解が必要なため、「分からないことを徹底的に調べる」「ドキュメントやコードを読む」「一次情報にあたる」などをこれまで以上に重視するようになりました。
教える中では、短時間での原因切り分けやペアプロのナビゲーションを行う場面もあり、そこで得た経験と気づきは、自分の成長に大きく寄与していると思います。実際業務でデバッグするときにも、まず現状を把握する、どこまでできているかを探る、1次情報に当たるなどがより一層実践でき、課題を解決するまでの時間を短くできているのではと思います。

このセッションでは、副業での教える経験を通じて得た学びがどのように業務に活かされているかを具体的にお話しし、参加者の皆さんが自分自身の成長に役立てられるヒントを提供します。

Laravelでの開発経験者ならおなじみのBladeテンプレート。
あなたは本当に使いこなせていますか？

このセッションは、まず日常的に使う基本的なディレクティブ @if や @foreach といったディレクティブをおさらいし、意外と知られていない隠れたディレクティブのご紹介や、 @csrf などのディレクティブの裏側で行われている処理内容、さらには独自のニーズに応えるカスタムディレクティブの作成方法まで幅広くご紹介します。

「実はこんな使い方ができたのか！」と思わず驚くトピックを盛り込みつつ、テンプレートコードをシンプルかつ可読性を高めるコツをお伝えします。

このセッションを通じてBladeディレクティブを使いこなし、テンプレートを効率的に管理するスキルを身につけ、日々のLaravel開発を一層効率化しましょう！

私が携わっている長年稼働しているサービスには、巨大連想配列$resultsが存在します。これは、元々は小さな配列だったものが、改修を重ねる中で次第に肥大化していきました。
巨大連想配列は可読性やメンテナンス性を低下させるため、私は以下のアプローチで改善を進めています。

1. Xdebugの活用
   配列の構造を可視化し、一目で理解できるようにする。
2. 新規部分の改善
   新しく作る部分は値オブジェクトを導入して書き換える。
3. 分離と整理
   大きなキーを別の変数に切り出したり、I/O形式が異なる場合はメソッドを分ける。

お話しする内容

• 配列の構造を一目で把握するためのXdebug活用術
• 巨大連想配列を生み出さないコツ
• 巨大連想配列を分解して整理する方法

巨大配列で頭を悩ませている方の改善のヒントになれば嬉しいです。

「いつまでも できると思うな 夜メンテ」

深夜メンテナンス作業を経験したことはありますか？
作業には様々なメリット・デメリットがありますが、何よりも体力的に辛いですよね。

あるカラムの暗号化作業を進める中で、深夜メンテナンスが必要だという結論になりました。しかし、シニアエンジニアに相談したところ、「今回は深夜メンテができるが、できないサービスも世の中にはある。深夜メンテ不要でリリースする方法を一度考えてみては？」というアドバイスを受け、リリース方法をチームで再考しました。
その結果、リリースを3段階に分けた小さなリリースを採用することで、深夜メンテを回避することができました。さらに、小さくリリースしたことで、各リリース段階で不具合が発生した際も原因を特定しやすく、迅速に戻せる状態の確保ができました。

お話しする内容

• 小さくリリースすることのメリット・デメリット
• 「小さくリリースできるかも？」と考えるためのヒント

開発者にとっても、ユーザーにとっても、メンテナンス時間は短いほど嬉しいものです。
このLTでは、深夜メンテに頼らずにリリースを進めるための工夫や実例を共有し、参加者にとって実践的なアイデアとなるような内容をお届けします！

2024年11月24日にPHP8.4がリリースされました！皆さんは既に8.4へアップデートしましたか？

私は昨年にPHP7.3→8.2化をしたので、「余裕でしょ」と思っていたら、PHP8.3→8.4化で300個近くのテスト、10個近くのライブラリが落ちてしまい、全くすんなり行かないことが分かりました。

とは言え、マイナーバージョンアップをサボっていると、後のアップデートで苦労する羽目になります。

そこで、PHP8.4化をテンポ良く行うために、リファクタリングツールのRectorや簡単にパッチを当てられるcomposer-patchesといったツールを駆使し、実際に取り組んだ手法を5分で解説します！

今、めっちゃ流行ってますよね、AI。
抽象的な質問しても、結構いい感じで答えを提示してくれます。

コーディングもさせることが出来て、「◯◯のアプリを作って」みたいな指示で
コードを仕上げてくれます。割といい感じでそのまま使えるものもあれば、
エラーハンドリングがまだまだのものもあります。
たまに、全然意図を履き違えてるものもあります・・・笑

今回は、そんなAIに作ってもらったコードをみなさんで見ながらワイワイしましょう。
ツッコミ大歓迎。プロンプトと出力結果を見比べて、どう改善したら良いかをXで呟くのもアリ。
今回ばかりはマサカリも飛ばしてもらって良いですよ

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 についてお話します。