いかに簡潔で当意即妙なコードを書くかはプログラマーにとって永遠の課題であり、実装パターンや標準ライブラリなどの知識と経験がモノをいうところです。逆に古いPHPの経験が長く最新のPHPをキャッチアップできていないと、現在では単純な関数呼び出しで済むものを冗長でパフォーマンスの悪い方法で書き続けてしまうということもありえます。

PHPには数多くの標準関数とシンタックスがありますが、その中には使いどころのわかりにくいものもあり、関数リストを全て読むといった学習法はあまり効率がよくありません。
今回のトークでは筆者がコードレビューやオンライン上の技術記事へのコメントを通じて指摘した内容を軸に、押さえておきたい関連知識を紹介します。

• PHPマニュアルの見方と標準関数について
• 古いイディオムとパフォーマンスについての考えかた
• 標準関数を使ったイディオム
• 静的解析 vs 標準関数
• オンラインサンドボックス環境の使いかた
• さっぱりを捨てるとき 〜 避ける余地のある標準関数

みなさんは「初めて見るコードの仕様を爆速で理解したい！」と思うときはありませんか？
例えばプロジェクトに初参画したときや、使用しているOSSライブラリの調査をするときなど・・・

そんな時には既存のテストコードを活用すると便利です。
見通しの良いテストコードやテストケース管理は、テスト対象となるコードの仕様理解を手助けします。

今回のセッションでは、PHPUnitの実装コードや公式ドキュメントサイトを一切見ずに、
PHPUnit内で書かれているテストコードを読みながらPHPUnitの仕様を理解していきます。

当セッションはこんな方におすすめです！
・自分以外の人が実装したテストコードをあまり読まない人
・PHPUnitのコードを読んだことがない人

SPA(Single Page Application)の普及が一層進んでおり、従来型のMPAを知らないウェブ開発者も生まれつつあるようです。SPA対応のフレームワークでは基本的な脆弱性については対策機能が用意されていますが、それにも関わらず、脆弱性診断等で基本的な脆弱性が指摘されるケースはむしろ増えつつあります。
本セッションでは、LaravelとReactで開発したアプリケーションをモデルとして、SQLインジェクション、クロスサイトスクリプティング、認可制御不備等の脆弱性の実例を紹介しながら、現実的な対策について紹介します。LaravelやReact以外のフレームワーク利用者にも役立つ説明を心がけます。

様々なロジックが密に結合したモノリシックなアプリケーションは開発速度を遅くする一方で、マイクロサービスアーキテクチャはサービス間のコミュニケーションやトランザクションなどといった別の課題があります。
モジュラーモノリスは、モノリシックなアプリケーションの中にドメイン境界を引いて疎結合な状態をつくる、モノリスとマイクロサービスの中間的なアーキテクチャです。

このトークでは、モジュラーモノリスをLaravelアプリケーションに適用する方法を具体例を用いながら紹介します。Laravelを例にしていますが、他のフレームワークにも適用できる内容です。

Laracon Onlineで話した内容に少し付け加えて日本語で話します。
https://www.youtube.com/watch?v=0Rq-yHAwYjQ&t=4057s

トーク内容

• モノリスとマイクロサービスのメリット・デメリット
• モジュラーモノリスとは
• Laravelアプリケーションのディレクトリ構造をドメインごとにモジュール化
• ドメイン間のコミュニケーション
• モジュラーモノリスなアプリケーションのテスト
• ドメイン境界を超えたコードの自動検知

アプリケーション開発をしていると、どうしても不具合は生まれます。
バグ、障害、故障、エラー…近接する概念が色々とありますが、その中でも「プログラムetcの修正で修復できるもの・根治できるもの」が確かに存在します。

実際の所、皆さんのサービスで、それらはどのくらい発生しているでしょうか？その内、直せるはずの「バグ」「欠陥」はどのくらいあるでしょうか？
パッと答えが浮かばない、という方も多いと思います。
どうやってこの状況を脱していきますか。

とにもかくにも、「可視化」「現実的な目標」「コントロール可能な状況を作る」「割れ窓状態を脱する」のが重要だと思います。
そして、それに勝るとも劣らず「なぜ、エラーを少ない状態を実現したいのか。そこにどんな価値があるのか」という認識の統一も欠かせません。
チーム全体を方向づけ、小さな実践を押し進めながら「それらは夢物語なんかじゃない」と勇気づけるような成果を上げていきましょう。

本セッションでは、まずは「エラーやバグがもたらす不経済」について説明します。併せて「なぜ、検知と修復を急ぎたいのか」「遅れが何をもたらすか」も扱います。
その後に、自身の体験も踏まえながら「どうやって・何を努力していき、チーム一丸となって”エラーを減らす”を実現していくか」について共有します。

想定するオーディエンス

• 「エラーを減らしたいな」「バグを減らしたいな」という気持ちのある人
  • もしくは「減らせるのだろうか」と気にしたこともなかった人
  • とはいえ「ガチガチのレギュレーション」や「窮屈さ」は望んでいない人
• チームの生産性に課題を感じている人、向上させたいと考えている人

本セッションで得られるもの

• 「なぜエラーを減らしたいか」の理論的な背景、根拠となりそうな情報
• 組織として、どのようにエラーやバグを減らしていくか？という導入-出口の戦略
• アプリケーションエラートラッキングツールの活用方針
  • Sentryの利用を想定しています

本セッションで話さないこと

• アーキテクチャや「良いコードの書き方」といった、品質面の話

関連リンク、参考書籍

• ウェッブアプリケーションのエラーを無くしていきたいわよねという話 - 大好き！にちようび
  • 過去に、エラー管理についてのスタンスについて吐き出した自ブログの記事
• LeanとDevOpsの科学
• This is Lean
• レガシーコードからの脱却
• アート・オブ・アジャイル・デベロップメント
• アジャイルプラクティス

PHPからもC#のライブラリを呼べるようにした dotnet_ffi という PHP Extensionをつくりました。
C#側で処理することにより15倍ほど処理が高速化できたり、
UnityなどのC#で書かれるクライアントと処理を共通化したりといった用途を想定しているExtensionです。

このdotnet_ffiをどのように作ったのかを解説したいと思います。
現状例えば下記のようなトピックを考えています
・動機(なぜ作ろうと思ったか)
・Extensionを作るにあたって公式ドキュメントが不足しているのでPHPのソースを追った話
・CからC#を呼ぶCoreCLRの使い方とPHP Extensionへの応用の仕方
・ExtensionのPHP8対応のポイント
・できるだけPHPバージョンアップ時に修正が少なくなるようなExtensionの設計
・PHPのFFI機能との違い

dotnet_ffiソース
https://github.com/pg-ito/dotnet_ffi

かつて自分がPHP MeCab Extensionを実装したときはC言語でバインディングを書くのが一般的な方法でした。
しかしPHP 7.4からはFFI (Foreign Function Interface) が導入され、C言語を書かなくてもC言語で書かれたライブラリが利用できるようになりました。
php_mecabをFFIを使って再実装する実例を元に、以下の解説をします。
・FFIの基本的な使い方
・メモリ管理
・FFIでできること
・FFIでできないこと

trait は当初 2008 年に PHP の言語開発者コミュニティへ提案され、長い議論期間を経て 2012 年リリースの PHP 5.4 で導入された機能です。
それから 10 年がたち、trait は「ちょっと試しに使ってみよう」というものから、各開発現場において使われる中で少しずつその立場を変えてきました。

さて、実際どのように変わったのでしょうか？

先日、今年に出る PHP 8.2 へ向けて言語機能追加の RFC を提出しました。PHP の trait で定数を定義できるようにするというものです。
静かな議論期間を経ての RFC の投票開始後、PHP の開発者向けメーリングリストから最初に得られたのは驚くべきリアクションで、要約すると次のようになります。

「trait は言語にとってまったく不要なものであり、使われるべきでないものを改善すべきではない」

続々と RFC に No の票を投じる人が現れ、一時は Yes が 3 票に No が 10 票というような圧倒的劣勢の局面を迎えます。

さて、なぜこのようなことになったのでしょうか？
何がこの 10 年で trait をこうも徹底的に嫌われる言語機能としてしまったのでしょうか？

このトークでは PHP によってプログラム部品を構成する言語機能としての trait に焦点をあて、来歴とその性質、適切な使いどころと、他の言語機能とくらべての弱点を紹介します。そして trait 定数の RFC が結局どのような顛末を迎えたのかを踏まえて、trait の将来の可能性について検討します。

なおトークの本題は言語機能としての trait の性質についてで、trait 定数の RFC 自体については「なぜこの話を今するのか」の舞台設定として早口で触れるくらいとする予定です。

※ ちなみに trait 定数の RFC の投票結果が出るのは PHP カンファレンス 2022 のトーク募集締切から 3 日後で、このトーク概要を書いている時点ではまだ確定していません

Psalm（サーム）はコードの問題を見つけてくれる静的解析ツール（PHPStan的なもの）です。

PHPでは、せっかく型を宣言しても実行してみるまでエラーに気づくことができません。
では、型を宣言することに意味はないのでしょうか？
そんなことはありません。
コードを実行しなくても静的解析がエラーを検出してくれるからです。

そんなPHPの開発に欠かせない静的解析ツールですが、どのような仕組みで動いているかご存知でしょうか？

先日Psalmにコントリビュートしたのですが、職場でEMになり手を動かす機会が減ったため、コードを書く機会を作りたいというのがそれを始めるモチベーションの一つでした。しかし、実際には仕様を理解するためにコードリーディングに多くの時間を使いました。せっかくなので、これからPsalmに触れてみたい人がコードを理解するのを助けるために私が費やした時間を捧げたいと思います。

誰向けのセッション？

• 静的解析の仕組みに興味がある方
• 静的解析のルールを作ってみたい方
• PHPStanやPhanは知っているが、Psalmって何かね？という方

本セッションの目指すところ

• 静的解析の一事例であるPsalmがどのようにコードを解析しているのか、その原理を少し理解して喜ぶ。
• これからPsalmにコントリビュートしたい方や拡張を作りたい方のハードルを下げる。
• PHPStanやPhanをメンテナンスする方がPsalmの仕組みを参考にできるかもしれません。

※ このトークはリモート登壇です

繝｢繧ｸ繝舌こ

文字化けとは↑のようなことを差しているように思われますが、
文字化けに悩まされた時代の文字化けはこんなものではなかったように思います。

例えば、Shift_JISではたくさんの亜種が生まれていました。
①は機種依存文字だから使ってはいけないよとか言われました。
メールをJIS(ISO-2022-JP)で送信する際の関数はmb_send_mailの前にmb_languageを設定するのだっけ？

閑話休題。
PHP 8.1から、major overhaul of mbstringという、mbstring拡張の大規模な改修が反映されるようになってきました。
そのためか、後方互換性の失われた動作をする文字を見つけてIssueにて報告しました。
確かに仕様通りに実装するとそうだったけども、当時の実装はそんなに厳密じゃなかったがゆえの後方互換性の破壊だったようです。こういうことこそが文字化けな気がしてきますね。

このトークでは、上記のようなことがあったことから、文字コードがどのように扱われていたのかをおさらいし、きちんと記録に残しておきたいです。

PHPでWebアプリケーションを作る場合はデータをPostgreSQLやMySQLのようなデータベースで管理することが多いと思いますが、
その中で取引記録、センサーから取得したデータ、システムに対する操作といった時系列データを扱いたい場合があります。

しかし時系列データには以下の特徴があり、データベースで扱うことが難しい場合があります。

・時間とともに保存するデータ量が増える
・一日のデータ量が多いかつ保存期間が長い場合はデータ量が膨大になる
・データに対する操作は追記と削除のみで更新は必要ない

リレーショナルデータベースはトランザクション機能や違う種類の入ったテーブルを結合するなど複雑なデータ処理が得意ですが、
トランザクションや結合の必要ないログのようなデータを扱うには機能過多かつデータ量が増えるたびに処理が遅くなると
いった問題があります。

私が開発に参加しているサービスはPHP + PostgreSQLで開発していますが、システムに対する操作をPostgreSQLに保存しています。
通常のユーザの操作では記録されるログの量は多くありませんが、バッチ処理やデータインポートが多い環境では一日あたり数百件
のログが記録される場合があります。

このような環境ではデータベースのサイズの半分以上がログになる場合があり、処理やメンテナンス作業の遅延が発生します。

そのため、このログが増える問題に対してPostgreSQLの拡張機能であるTimeScaleDBで対応できないか検討しました。
TimeScaleDBには時系列データを管理するための以下の機能があります。

・テーブルパーティショニングによる処理の高速化
・一定期間を過ぎたデータの圧縮

また、PostgreSQLの拡張機能であり、既存のSQLをそのまま使えるため、アプリの改修無しで適用することができます。

このセッションではTimeScaleDBの仕組みや適用した場合の効果について検証した結果を紹介します。
時系列データをすでにデータベースで扱っている方や、今後扱う予定がある方の参考になれば幸いです。