トーク

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

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

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

話す内容

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

フレームワークのドキュメントに従って、あるいはプロジェクトの既存のコードに従ってファイル上部に書いた「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での活用例、そのほかの活用例

について話をします。

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

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

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

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

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

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

トークで話す内容

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

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

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

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

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

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

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