Web ApplicationをPHPで記述するときに, 多くの場合, 文字列の正規表現を扱うコードは必要です. また, 正規表現を使ったコードは重要な部分を担うことが多いです. 例えば, uriのroutingをする時に正規表現を使うことがあります. また, ユーザー名やIDに使うできる文字を制御するのに用いることもよくあるケースです.

しかしながら, 同時に私たちプログラマを最も悩ませる問題の一つでもあります. urlやemaliのValidationに苦労された経験を持つ方は多いのではないでしょうか？
その理由としてよく「記述した正規表現パターンの理解のミスが起こりやすいこと」や「正規表現パターンを記述したコードが長くなってしまうこと」が挙げられます.

本セッションでは難解な正規表現を扱うコードを理解しやすくする方法を紹介します. 正規表現が大好きなみなさんもちょっと苦手意識のある方も是非お越しください！

ターゲット

正規表現を使ったコードを書いたことがある方
正規表現の実用に興味のある方

話すこと

正規表現を扱うコードを理解しやすくする手法

話さないこと

正規表現の使い方などの初歩的な話
正規表現の成り立ち

今までサマータイムとタイムゾーンについて雰囲気でやってきていませんか？僕は少なくとも雰囲気でやってきました。
実際そんなに困ることねーし・・・！とそう思っていたそのとき！困る時がやってきます・・・。(震え声)
RFCなどを追いつつ、PHPの実装をどうするのか？といったところまでふかぼっていきます！

複数のプロダクトやサービス事業を展開している企業で一度は言われる「共通基盤を作りたい」。
近年、エンジニア側も「よし、共通基盤だ！マイクロサービスを作ろう」と安易に呼応してしまうことがでてきました。このように始まったマイクロサービス開発では、往々にして失敗したマイクロサービスが負債として残り、エンジニアチームは「マイクロサービスはダメだ」という感想を持ってしまいがちです。

「共通基盤だ！」と言い出したとき、本当にマイクロサービスが必要だったのでしょうか？
前職で数年にわたってマイクロサービスを開発・運用し、PHPerKaigiでマイクロサービスを布教したこともある私ですが、現職では「共通基盤だ！」にNOを突きつけています。
共通基盤というマイクロサービスがほしくなる動機を解きほぐし、マイクロサービス採否ジャッジの基準、ニーズをマイクロサービス以外の方法で満たす方法についてもお話しします。

本セッションでは、高負荷下でのPHP WEBアプリケーションのパフォーマンスを支えるために、nginx+ngx_mrubyプロキシとGo言語で構築した仮想待合室サーバをどのように統合し、活用しているかを具体的に解説します。

トラフィックのピークをクールに処理し、ユーザーエクスペリエンスを最大限に高めるためのチューニングの詳細、通知、ダッシュボードを用いた運用プロセスを含めて紹介します。

実際に運用している環境から得られた貴重なデータを基に、PHP開発者が同様の問題に直面した際に役立つ実践的なソリューションを提供します。このセッションは、高トラフィック時の対応策を模索するPHP開発者やアーキテクトにとって、必見の内容を含んでおり、技術的な深堀りとともに、ビジネスの継続性と成長を支えるインフラとしてのPHPアプリケーションの強化方法を提案します。

皆さん、コア吐いてますか？

コアダンプファイルは実行中のプログラムのある時点でのメモリ内容を、丸っとファイルへ吐き出したものです。Linux や Unix 系 OS では、プログラムがクラッシュした際など、設定によってその原因究明のためのコアダンプファイルを吐き出させることができます。

我々 PHPer にはコアダンプファイルは馴染みの薄いものです。PHP スクリプトの実行でコアが吐かれるのは、ふつう処理系や C 言語拡張部分の不具合を踏んだ場合です。PHP は仕事で使われることの多いビジネスマンの言語で、仕事でそのような不具合を踏みやすい環境を常用することは珍しいでしょう。

しかしこのコアダンプ、プログラムのクラッシュ時以外でも取れば取れるもので、気合で読めばけっこう楽しいものでもあります。みなさんもこのトークを聞いて、毎日じゃんじゃんコアを吐いていきましょう！

php-src。それはPHP言語のソースコードのことです。
そのため全て読むのは大変です。
php-srcを読む際、適当なtest.phpを作り、ast\parse_codeを利用しながら気になる挙動の構造を確認したり、気になるfunctionにブレークポイントを仕込んでdebugしていくこととなるでしょう。

しかし、debug環境を整えようとすると、一筋縄ではいかないことが多々あります。少なくとも経験の浅い僕にとっては簡単ではありませんでした。
MacやWindowsなど、デバッグを試す環境の違いにより色々な知見を得ながら環境整備しなければなりません。
それだけの労力を割きながら、いざphp-srcのmake testをしてFailだらけになると気が滅入ってしまうものです。

そこで、Dockerを利用してphp-srcのためのsandbox環境を整えました（発表当日にはgithub上でpublicリポジトリとして公開します）。
本セッションでは、そんなsandbox環境とVSCodeを連携方法や、それらを用いたfunctionへのアプローチ（debug）方法をお伝えいたします。

もうphp-srcの環境構築に迷うことはありません。
素敵なphp-srcリーディングライフを送りましょう！

対象者： php-srcを読んでみたい方/読もうとしたけど環境構築で挫折した方

私たちが古くなったPHPアプリケーションをRuby on Railsに移植することを決断したのが2016年―。
私たちが移植対象としたPHPは下記のようなものです。

• とっくにEOLなPHPバージョン
• オレオレ・独自フレームワーク
• 標準サポート終了しているAmazon Linux AMIなEC2サーバー
• PEAR/PECLなライブラリ管理
• 自動化されていないテスト・デプロイ
• 仕様ドキュメントほぼ無し（ソースコードが仕様書）
• 担当プロダクトオーナー不在

過去に本PHPアプリケーションの移植プロジェクトは断続的に立ち上がっていたものの、それらは局所的な移植として終わってきました。
2022年、この戦いに終止符を打とうと本格的な移植プロジェクトが再始動、ついに2023年、移植を完遂しました。

本プロジェクトは正直、カッコいい移植プロジェクトとは言い難いものです。
そんな泥臭く長い移植の軌跡を、技術的負債解消の一事例としてお話できればと思います。

想定聴講者

• 技術的負債の解消に興味がある方
• 現在進行系で技術的負債と闘っている開発者

話すこと

• なぜ移植するか
• どのように移植を進めたか
• 移植前後の改善結果
• 移植後も山積する課題と今後の展望

話さないこと

• ナウい技術的負債の解消方法
• 移植後のシステムの技術的詳細

このトークでは、10年以上にわたり運用されているサービスにおけるPHPフレームワークの進化(FuelPHP 1.8.2からFuelPHP 1.9-devへの移行)とPHPのバージョンアップ(PHP 7.3からPHP 8.1へのアップデート)の戦略について語ります。

プロジェクトマネジメントと技術の観点から、ソフトウェアのバージョンアップを成功させるための「プロジェクトをリードする上での力学」や「バージョンアップにおいて有用だった技術的アプローチ」について具体的にお話します。

FuelPHPを使っている方はもちろん、それ以外のPHPフレームワークを使っている方も対象に、PHPフレームワークとPHPのバージョンアップの知見を共有します。
様々なトレードオフやハードルを乗り越えるために、どのように計画し、アプローチしたかをお話します。

人類が増えすぎたPHPを品質保障(Quality Assurance)するようになって既に20年が過ぎていた…
開発環境の周りの巨大なContinuous IntegrationはPHPerの第二の故郷となり、人々はそこでプロダクトを生み、育て、そして死んでいった。

西暦2023、静的解析が開発環境に取り入れられるようになり、いくつかの現場ではめざましい成果を挙げたが、別の現場では疎まれ、また別の現場では開発プロセスに投入できないまま散っていった。

このトークでは、私の考える静的解析導入時のバッドプラクティスをお伝えします。

• 何のために型をつけるの？
• コードの型付け、どこから手をつける？
• 「えっ、せっかくならlevel:maxにしないと意味なくない？」
• 汝、 @var を憎め
• あなたのユニオン型の使いかたは間違っている

例外はただのトラブルシューターじゃありません。コード内の誰が何を担当するのかを教えてくれる、責務の指針なんです。

『PHPの例外、多すぎてどれ使えばいいかわかんない！』『例外、いつキャッチすればいいの？』『エラー情報、どこに吐き出すのが正解？』こんな疑問を持ったことはありませんか？

PHPの組み込み例外クラスの選び方から、自分で独自例外を定義するノウハウまで、コードをもっと読みやすく、管理しやすくするための実践的なアプローチについて考察してみます。

例外をマスターして、エラーハンドリングをもっとスマートに。

みなさんのアプリケーションには履歴データはありますか？
履歴データは大量に増えたり、必要なデータへのアクセスにすぐにアクセスしたかったり、履歴なのに改変できたりといろいろな要望を言われることがあると思います。
履歴データの取り扱いをする上で考慮しないといけないことを話します。

PHP8が2020年11月26日に登場してから、日々進化し続けているPHP。
つい最近はPHP8.3の登場もあり、以前の言語とは比べない程に型システムの改善や、パフォーマンス向上されてきました。
一部機能を取り上げれると以下の改善があります。

• JITコンパイラの利用
• Union Types, Mixed Type
• 属性(Attributes)の使用
• エラーハンドリングの改善
• Constructor Property Promotion

筆者も普段はPHP8で業務のコードを書いて、その恩恵を受けています。
このプロポーザルでは、PHP8の沢山ある機能の中でも実際の業務を通じて、学んだ事のアウトプットとしてPHP8で堅牢にコード書くTipsについて紹介します。

パフォーマンス改善と聞くとどんなことを想像するでしょうか？
大半の人はクエリチューニングであったり、ロジック改善であったり、キャッシュ化であったり
元の仕様を変えずに速度向上をする、というイメージがあるかと思います。
ISUCONなどはまさにこれで、元のテスト（ベンチマークツール）が通るように改善を行っていきます。

しかし現場で10年ほど開発経験を積んできた私の持論としましては
「あれ？これちょっと仕様変えるだけで劇的にパフォーマンス良くなるのに、元の仕様を変えない理由ってなんだっけ？変えれば良くない？」
という結論に至りました。
もちろんケースバイケースで絶対仕様が変えられない状況下でパフォーマンス改善していく、ということはあると思います。
しかしもし仕様から変えて良いものであれば、それは仕様再検討から実施することで圧倒的なパフォーマンス改善を実現できると私は考えています。

本セッションでは

• パフォーマンス改善の勘所
• 実際に行った「仕様変更を伴うパフォーマンス改善」

このあたりをお話できればと思っております。

PHPの世界では、CSRF対策としてセッションを利用したトークンを用いた方式が採られることが多いのではないでしょうか。
例えばLaravelの場合、「@csrf」とBladeのテンプレートファイルに記述して、Middlewareを用いれば簡単にトークンベースのCSRF対策が可能です。

しかし待ってください、例えばNext.jsにCSRF対策の機能はあるでしょうか。SvelteKitには？
実は、最近出てきたWebアプリケーションフレームワークでは、CSRF対策を標榜するような機能は入っていません。

本トークでは、SameSite Cookieを用いたCSRF対策について解説すると同時に、CSRF対策について改めて考察します。
当たり前だと思っていた、今までのCSRF対策を見直すきっかけになってくれたらうれしいです。

「わたしたちのコード（＝ドメインロジック）」は安定していますか？？

フレームワークを利用している場合にコードの境界がハッキリしていないと、強くフレームワークに依存することにもなりかねません。

フレームワークには便利な機能がたくさんあります。
たとえばLaravelには、Eloquent、Facede、サービスコンテナ、認証、ミドルウェア、Blade、artisanコマンドなどがあり、それらの機能を活用することで、スピード感のある開発ができるでしょう。

しかし依存のしすぎはビジネスの変化への対応による作り直しや機能のバージョンアップの際に思わぬ量のコード修正になってしまうことがあります。

わたしのチームでは主にInterfaceを利用して「わたしたちのコード（＝ドメインロジック）」をフレームワークから独立させ、安定させることを心がけており、その方法をご紹介できればと思っています。

速さは正義。Googleもそう言っている。

Webページの表示速度はユーザ体験に直結し、ひいてはビジネスKPI (購買率、アクティブ率、解約率、etc...) にも影響を及ぼします。
本トークでは、Instagram分析ツール 「SINIS for Instagram」 のページ表示速度を約1/3にした事例をもとに、どうやって課題を見つけ、何の改善を試み、その結果どうなったのかについてお話します。

想定観客

• 自分のWebサービスの表示速度が何か遅いんだよな〜と思われている方 (高速化したいけど何からやっていいか分からない方)
• パフォーマンスチューニングコンテスト「ISUCON」が好きなかた

お話しすること

• Core Web Vitals
• ベンチマークツール Vegeta
• index見直しやSQL組み換えによるクエリチューニング
• XDebug x Webgrindでプロファイリング
• GraphQL Schema Caching
• PHP OPcacheでPHPバイトコードのキャッシュ

概要

PHP8.3で追加されたjson_validate()ですが、痒いところに手が届く大変素晴らしい関数です。
この機能について、具体的にどの辺が便利になったのかを、自身が経験してきたケースと実際の解決方法、json_validate()を用いた場合どう改善するかのご紹介をします。
そして内部処理がどのようになっているかphp-srcの内部処理から深掘りをしていきます。

アジェンダ

1. これまでのjson_validate()を用いない場合の実装ケース
   • これからjson_validate()を用いた場合の実装ケース
   • json_validate()の内部処理を深掘りしていこう

静的解析ツールは使っていますでしょうか？
昨今のPHPのバージョンアップでは型定義が厳しくなってきており、静的解析ツールを導入することの優位性が高まってきています。
15年以上続いているレガシーシステムにPHPStanを導入した際の課題と効果について紹介します。

・既存の静的解析ツールからPHPStanへの移行
・PHPStanの導入時の課題
・導入から半年での効果と課題

既存の静的管理ツールに課題を感じている方や、静的解析ツールを導入したいと考えている方にとって参考になる内容となっています。

※ PHPConference関西2024と同じ内容になります。

B+木をご存知でしょうか？RDBMSのインデックス作成に採用されているデータ構造で、ディスクの効率的な利用や、検索を行いやすいなどの特徴があります。しかし、耳学問で聞いてもイマイチ特徴がピンと来ないのです。

本トークでは、PHPでB+木のデータ構造を実装して、RDBMSでB+木が採用される理由、インデックスの構造的な仕組み、何故検索が速くなるのか？などなど、データベースの仕組みの根幹を覗いてみましょう。

本トークで話す内容

• B+木の特徴
• なぜ、データベースはB+木を採用しているのか
• インデックスとは何か

PHP を使っていると、予期しない、意図しない動作をすることがあります。
大抵は自分の書いたプログラムのミスですが、まれに PHP 本体のバグや意図しない挙動の変化であることもあります。
今回は "バグかな？" と思ったときの迅速な検証方法から、実際に php-src に報告を行うまでの流れを実例をもとに紹介させていただきたいと思います。
運用で回避せず、レッツコントリビュート！