皆さんはPHPアプリケーションのリアルタイムログ分析は行っていますか？
適切にログを収集することで、問題の早期発見や素早い意思決定などのメリットがあります。

今回紹介するのは、高い柔軟性と信頼性を持つデータ収集ツールのFluentdです。
Fluentdはクロスプラットフォームで動作し、アクセス、アプリケーション、システム、データベースなどの様々なログの収集に対応しており、
PHPアプリケーションのログ管理も非常に効率的に行うことが出来ます。

このセッションでは、リアルタイムログ分析の基礎的な部分から、PHPアプリケーションとFluentdの統合の手法まで、Step-by-Stepで解説します。

話す内容

• リアルタイムログ分析とは
• Fluentdの概要
• Fluentdを用いたPHPアプリケーションのログ分析手法

BEAR.Sundayの分散キャッシングフレームワークは、クライアントサイドとサーバーサイドのキャッシュ管理を統合することで、Webアプリケーションの堅牢性とパフォーマンスを大幅に向上させます。このキャッシングフレームワークは、静的な情報APIと動的な計算APIの2つのタイプに基づいて、それぞれ異なる戦略を採用します。従来のTTLキャッシュを超えて、依存管理を伴うイベントドリブンキャッシュ、静的と動的コンテンツを効率的に分離するドーナツキャッシュアプローチ、そしてネットワークキャッシュの重要性について詳しく解説します。

このプレゼンテーションは、単に特定のフレームワークの機能紹介に留まりません。DI（依存性注入）やAOP（アスペクト指向プログラミング）のようなソフトウェア設計の原則を組み合わせることで開かれる新たな可能性を探ります。REST原則に基づいてHTTPや最新のCDN機能を最大限に活用するキャッシュシステムの構築にも深く焦点を当てます。このセッションを通じて、参加者は技術的な理解を深めるだけでなく、設計者としての視点も獲得できるでしょう。

キャッシュはパフォーマンスを劇的に改善する効果がある反面、使うと簡単にはやめられない複雑性と中毒性があります。
その特性から キャッシュは麻薬 と言われ、安易な利用は忌避されています。

しかし、キャッシュがもたらすパフォーマンスの改善効果は無視することはできず、コンピュータの世界において有効活用されているのも事実です。
そこで今回は、キャッシュの手法と有効な場面での活用方法、逆に失敗してしまいやすい注意事項を説明しながら、実務の中でのキャッシュとの付き合い方を説明します。

話すこと

• キャッシュが有効な例と失敗例
• キャッシュを実装パターンと始めるときの勘所

対象者

• アプリケーション開発などでパフォーマンスに苦労したことがある人
• キャッシュを利用したサービスの運用で苦労をしたことがある人
• とにかく今すぐパフォーマンス改善したい人

みなさんは何かしらの VM （Virtual Machine）を作ったことがあるでしょうか。私自身は過去に PHP で JVM (Java Virtual Machine) を作ったことがあります。
現職は Ruby on Rails がメインの企業です。Rails どころか Ruby 初心者である私が Ruby の気持ちを理解するにはひと工夫必要だと考えました。
そこで，過去に PHP で JVM を作ったことがある経験を活かし，RubyVM を自作して Ruby の気持ちを理解し学習速度を加速させようという考えに至りました。
本トークでは PHP でどのように VM というものを作るのか，そして RubyVM はどのように作っていくのかを，初心者でも「ちょっとわかったかも」と思えてもらうことをゴールとして解説します。

フレームワークのドキュメントに従って、あるいはプロジェクトの既存のコードに従ってファイル上部に書いた「namespace」「use」といったキーワード。

この意味、正しく理解していますか？
「ディレクトリ名と対応させて書くやつ」「他の言語でいう import みたいなやつでしょ？」みたいな認識をしていませんか？

実は PHP の機能としては namespace（名前空間）とディレクトリ名、ファイル名には一切の関係はありません！

「じゃあ、なんで require とかを書かずに他のファイルに定義したクラスを使えているの？」と思ったあなたに、その仕組みと、それらを支えている存在をお教えします。

『リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック』（Boswell & Foucher）
エンジニアのみなさんなら、一度は読んだことがあるのではないでしょうか。

私はブライダル専門メディアを自社開発・運営している会社で保守開発を担当しており、
現在はサイトの一部機能を削除する案件にジョインし、開発を行っています。

Laravelで構築された弊社のサービスは、約20年続く結婚式場のクチコミサイトです。
改修に改修を重ね長年運用されてきたサイトの機能を削除することは、簡単ではありません。
例えば、以下のような問題に苦戦しました。

・表記揺れをしている、または意味を汲み取れない関数名・変数名である
・あちこちでクラスが継承され、メソッドやViewファイルの依存関係が複雑である
・おそらくもう二度と使われないプログラムをきれいさっぱり削除できているか、不安になる

この経験から、普段からシンプルで美しいコードで運用・保守していくことの大切さを痛感しました。

本トークでは、歴史ある大規模サービスの機能を削除する上で直面した問題と、そこから得た学びを共有します。
“機能削除”という観点から、『リーダブルコード』をどのように意識して実践していくべきか、一緒に考えませんか？

「PHPUnitでテストカバレッジを取ろう」とすると、phpunit/php-code-coverage というパッケージによって分析・レポート出力がなされます。
カバレッジのデータは、Xdebug(など)の拡張によって、PHPスクリプトの実行情報を取得されるものです。

一言で「テストカバレッジを取る」といっても、複数のレイヤーに登場人物がいて、それぞれの果たすべき役割が組み合わさって実現されていると言えます。

さて、実際に「それぞれで、どういうデータが出力され、どう変換されるのか」「どのような流れで、カバレッジの収集処理が起動・完了されるのか」が気になりませんか？
内部的な仕組みを知ることで、「単体テストでのテストカバレッジ計測」以外の活用方法も見いだせるかも知れません。
例えば、Xdebugの作者がYoutubeに展開している「Code Coverage for Websites」などは、興味深い例の1つでしょう。

このセッションでは、

1. Xdebugのカバレッジ機能 & どのように実行され、どのようなデータを出力するのか
2. php-code-coverageは、何を受け取りどんな分析をしているのか
3. PHPUnitでの活用例、そのほかの活用例

について話をします。

育成について悩んだことはありませんか？

2023年1月。エンジニアのマネージャーになり、人生ではじめてメンバーマネジメントをすることに！

メンバーをどうやって育成したらいいのか、どう向き合ったらいいのかはじめはわからないことだらけでした。育成されるメンバー側も悩むことがあると思います。

私たちは二人三脚で1年間かけてさまざまな施策を行い、改善を繰り返してきました。

例えば…
・お互いの価値観を共有する
・毎日夕会
・slackのtimesチャンネル活用
・ペアレビュー
など

本セッションでは、中途若手社員をどうやって育成していけば良いのか悩みながらも、一緒に試行錯誤した1年間をマネージャー視点とメンバー視点の両軸から振り返ります。

対象者
・メンバー育成のナレッジを知りたい方
・これからメンバー育成を任されたい方
・もっと成長確度をあげていきたい若手エンジニア

オープンロジのシステムは10年ものということもあり技術的負債が溜まってきており、開発生産性に影響を及ぼしています。
今後の事業拡大に向けて現在負債解消に向けた機運が高まっており、全社的に取り組みを開始しています。

その中で私はアプリケーションの負債解消専門チームに所属しており、システムの心臓部である巨大で重要な処理「出庫依頼作成処理」のリファクタリングと向き合っています。
リファクタリング自体はまだまだこれからという感じですが、

・どのような負債が溜まってしまっているのか
・どのようなステップでリファクタリングを実施しようとしているのか
・今は何をやっているのか
・どのような工夫をしているのか

などについてお話できればと思います。

このトークではPHP Parserを利用して静的解析ツールを作る話をします。

題材は簡易的な依存可視化ツールです。クラス間の依存の方向、数、深さからコードの複雑さを認識すること、バッドスメルを察知して設計を見直すこと等を目指すものです。

静的解析はコードを隅々まで見渡し、人が認識しにくい気づきを与えてくれます。これを活用しない手はありません。しかし、静的解析だの抽象構文木だの小難しく敷居が高く感じられるかもしれません。

このトークでは、具体例を通じて静的解析というものの解像度を高め、より身近に感じられるようになることを目指します。
また、実装する際の思考過程や設計判断に触れつつPHP Parserをどのように使ったのかを説明し、静的解析を知ることを通じて解析対象であるPHPの理解を深めることも目指します。

PHP、静的解析の仕組みや付随する設計に触れ、日頃の開発にいかせるヒントを見つけていただけたら幸いです。

privateメソッドのテストを書くか書かないか問題はよく話題にあがるかと思います。
実は、私もかつてはprivateメソッドのテストをたくさん書いていた時代がありましたが、今はprivateメソッドのテストは書かずにテストを書いています。
自分の思考の整理をするのに繋がった「単体テストの考え方/使い方」という本の内容からも引用しつつ、
実体験をベースに「なぜprivateメソッドのテストを書かないのか」というところをお話します！

トークで話す内容

• かつて私が書いていたprivateメソッドのテスト(と、その理由)
• なぜそれが良くなかったか？「偽陽性」「偽陰性」の視点から考える
• どのようにテストを書くべきだったか？
• privateメソッドのテストは書かない方がいいのか？(※経験に基づいた持論)

皆さんはリリース後に文字化けが発生して、道頓堀に飛び込みたくなったことはありますか？
私はあります(※)。

PHP8.2の下位互換性のない修正の1つにmb_detect_encodingの文字コード検出の仕様変更があります。

私が担当しているメール共有サービスのメールディーラーで、バージョンアップ後に一部の受信メールが文字化けをしました。
原因は受信したメールのエンコード時に、前述のmb_detect_encodingを使っていたことです。

下位互換性がないPHPの仕様変更だったため、文字化けを回避することができませんでした。
その結果、メールヘッダに文字コードの指定がないRFCに準拠していないメールまで対応することとなり、大変苦労しました。

メールディーラーの保守運用・顧客対応チームのリーダである私が、顧客対応で泣きをみたことを中心に苦労した経験をお話いたします。
私と同様に顧客対応されているエンジニアの方々の参考になれば幸いです。

※道頓堀は大阪市中央区の繁華街である通称ミナミを流れる川の略称。
阪神タイガースの優勝やサッカー日本代表がW杯で勝ったとき、
年末年始のカウントダウンなどのイベント時に、
グリコの看板がある戎橋から道頓堀川に飛び込むことがある。
実際には私は飛び込んでいません。

PHPerKaigi 2024最後のトークセッション、LT大会です。
この時間帯はTrack Aのみ開催です。全員参加で楽しみましょう！

Composer使っていますか？使ってそうですよね！

パッケージマネージャーの魅力は、
「色々な環境や操作者に対して、画一的な成果物(依存解決)を提供できること」はもちろん、
「継続的なメンテナンスやアップデートを実現容易にすること」にもあると考えています！

前者はcomposer.lockによって自動的に実現され、後者は「良いcomposer.jsonを作ること」が肝です。
そして、composer.jsonの美しさが、Composer中級者としての実力を語るのではないでしょうか！？

このトークでは、私が「実際にComposerを使っているプロジェクトに関わる際に、意識していること・使っているツールや操作」を紹介します

お話する内容の例(一部)

• @stableや@dev、使ってますか？
• require-devに入れる？それとも、composer-bin-pluginを使う？
• config.jsonに書いておくと良いこと、CLIコマンドのオプション
• depends / prohibits で差がつくComposer運用
• Packagist Semver Checkerは良いぞ

AST, ASTというがASTって何かね？

恐らく今や多くの現場でPHPStan, Psalm, Rectorなどの静的解析ツールが利用されているのではないでしょうか。その縁の下にはPHP ParserがいてASTをせっせとつくっています（なんならPHP自体もですがそれはさておき）。PHPの開発現場においてそれは謂わば空気。欠かせないものですが、私たちがそれのことを気に留めることはほとんどありません。

ところで、概念を理解したい時、具体例を確認するという方法があります。そこで、PHPのコードを分析して生成したASTを図示して見える化したいと思います。PHP Parserを用いてAST可視化ツールを実装してみます。せっかくなのでこの9月にpre-releaseなBeta版として公開されたversion 5.xを使ってみます。

PHP Parserから見たPHPの世界をあなたものぞいてみませんか？

このトークでは、ASTを見ます。見ることで理解に迫ります。年に1度、5分だけ、1年分の感謝を込めてASTだけを見つめPHP Parserに想いを馳せる。そんな時間にしたいと思います。

2023年10月16日のChromeアップデートによりHTTPSファーストモードがデフォルトで有効になり、httpでアクセスするとhttpsに自動的に誘導されるようになりました。
このモードによってHSTS(Hypertext Strict Transport Security)ではないサイトでもhttpでアクセスするとChromeが勝手にhttpsにリダイレクトします。（特定条件で）
リダイレクトもWebサーバにリクエストを飛ばさずにChrome内部で307リダイレクトのレスポンスを擬似的に返します。
このようなChromeの独自世界観がインターネットに溢れ出すようになった令和の時代を生き抜くため、今回のChromeの動作の条件、動きの詳細を解説します。

参考ツイート
https://twitter.com/cakephper/status/1719275453943525571

参考ブログ
https://blog.ichikaway.com/entry/chrome-307-https-first

テストコードの品質は、開発プロセスにおいてとても大事です。
その中でも、適切なAssertionメソッドの使用は、テストコードが読みやすく理解しやすいものにする一歩と言えます。

私は読みやすいテストの一歩は「適切なAssertionを使うこと」だと思っています。
いつも「assertSame」にしちゃっていませんか？Assertionメソッドはたくさんあります！このトークで学んでいきましょう！！

みなさんは、PHPでOfficeファイルを取り扱いと思ったことはありますか？
もちろん、ありますよね？

このLTでは、PHPでOfficeファイルを取り扱う方法と、実際にどのようにプロダクトに使用しているかをお伝えします！

このLTで話すこと
・PHPOfficeライブラリの基本的な使い方
・読み込んだOfficeファイルをどのように利用したか
・PHPOfficeライブラリの難点

話さないこと
・Officeファイルの仕様
・PHPOfficeの細かい使い方

このLTを聞いて、みなさんもPHPでOfficeファイルを扱えるようになりましょう！

ユーザー数も1万人越えのモバイルアプリ(Flutter)のバックエンドにLaravelを採用して早や4年。
振り返れば
「ああしておけばよかった、、、。」
「ここが考慮できていれば、、、。」
といった悲しい「業」を残して来たと思います。
そんな「業」を新しく羽ばたく皆様が背負わないように、「技術的な側面」と、「上流的な側面」の両方の視点でここに失敗談を記し、皆さんの糧にしてもらいたいと思います。

PHPerKaigi 2024最後のトークセッション、LT大会です。
この時間帯はTrack Aのみ開催です。全員参加で楽しみましょう！