トーク

恐らく今や多くの現場でPHPStan, Psalm, Rector, php-class-diagram等の静的解析ツールが利用されているのではないでしょうか。その縁の下でPHP Parserがせっせと働いています。さて、そのメジャーバージョンが繰り上がり5.0.0がリリースされて1年程が経ちました。そして継続的にメンテナンスされ今ではPHP8.4にも対応しています。

そろそろ5系をのぞいてみたくありませんか？

このトークはPHP Parserの働きを効率よく理解できるようにすることを目指します。そのために、5系において定義されているノードの全体像を整理します。そして、PHPコードの具体例を使用し、コードとノードの対応関係について説明します。ノードとはPHP Parserがコードを解析して生成するASTの構成要素です。単なるテキストの羅列ではなく構造化された情報であるASTにより効果的な解析が可能になります。それを理解する事は、例えば、静的解析ツールの仕組みの理解を深める際や、そのカスタムルールを作成する際に役立つと考えられます。

このトークの目的はもう一つあります。私達はPHP Parserから大きな恩恵を受けています。しかし、その事を気に留めることはほとんどないのではないでしょうか。年に1度、5分だけ、1年分の感謝を込めてPHP Parserだけを見つめASTに想いを馳せる。そんな時間にしたいと思います。

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

我々はメモリの確保・解放をほとんど気にすることなく、プログラムを書くことができます。
PHPを触れていると、このGarbage Collectionを意識することもないと思います。

Garbage Collectionは、プログラムがメモリを効率的に利用できるようにする重要な仕組みです。
本セッションでは、PHPにおけるGarbage Collectionの動作やgc_XXX関数について簡単に解説します。

皆さんと共に、Garbage Collectionの恩恵を再認識し、より効率的なプログラミングを目指す旅に出かけましょう。

PHPで大量データを扱う際、コードが正しく動いていても、パフォーマンスの低下が発生し、ユーザーの離脱につながったりすることがあります。
本トークでは、私たちのプロジェクトで直面した「strposによる文字列検索が原因で処理が30秒以上かかった」事例をもとに、計算量の重要性とパフォーマンス最適化についてお話しします。

問題の背景は、数千件の文字列を1件ずつ、約1万件の集合と照合する処理でした。
文字列の部分一致のチェックをstrposで実装していましたが、線形検索（O(n)）のため、1回の検索がミリ秒単位でも、繰り返し処理が積み重なり、最終的には数十秒に達しました。
処理の遅延が原因でタイムアウトが発生し、ユーザーが機能を使えない危機に直面しました。

解決策として、array_flipとarray_key_existsを用いて、検索処理をハッシュベース（O(1)）に変更することで、処理時間を30秒から約6秒に短縮しました。
この経験を通じて、パフォーマンス問題を解決するには計算量の意識が不可欠であると学びました。

このように、1回の処理がわずか1ミリ秒遅延しただけであっても、大規模データでは致命的な影響を与える可能性があること、計算量や計算時間が特に大事になってくることを学びました。
このようなパフォーマンス改善は、ユーザー体験を向上させ、機能の価値を最大化するための重要なステップです。
ユーザーが快適に使える環境を提供するため、私たちエンジニアが取り組むべき課題を一緒に考えてみませんか？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

お話しする内容

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

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

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

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

本セッションでは

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

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

非常に便利な PHPStan ですが、大規模プロジェクト、特に Laravel を採用したプロジェクトだとものすごく時間がかかってしまったりすることも多いかと思われます
そんな PHPStan を様々な手法を用いて高速化を試み、最終的にどうなったかをライトニングにお話してみたいと思います

ISUCONにPHPで挑み続けて8回（ISUCON7〜ISUCON14）。
ふと、こんな疑問が頭をよぎることがあります。

「自分（私たち）は本当に成長しているのだろうか？」

8回も挑戦を重ねてなお、悔しさや「まだまだできないことが多いなぁ」という気持ちに直面します。
それでも、振り返ってみると、できることや考えられることが確実に増えていると実感しています。

「できない」と「できる」には壁があります。

しかし、その差は小さいことも多く、ふとしたきっかけで「できる」になるなと感じています。
この過程こそが成長であり、試行錯誤を通じて得られる価値ではないかなと思います。

ISUCONに挑む中で得た学びと、「続けることで見えてくる成長」について共有します。
技術的なノウハウだけでなく、挑戦することの意義や、それを続ける中で見つけたヒントをお伝えしたいと思います！