日本でも大人気のウェブアプリケーションフレームワーク「Laravel」
ある程度のデータ量までは、割と速い速度で動いてくれる Laravel をあの手この手で低速化させてみようという試みです。どのようなコードが Laravel を低速化させるのかを学ぶことで、逆説的に Laravel の速度劣化を防ぐソースコードの考え方が身につきます。

このトークでお話すること

• ミドルウェアによって Laravel を遅くする方法
• インフラ環境によって Laravel を遅くする方法
• ソースコードの書き方によって Laravel を遅くする方法
• 遅くしないで妥当な書き方をした Laravel の処理スピード計測

※こちらのトークは、リモート登壇になります。

想定課題

開発がスケールしたり、開発年数が経過すると、様々な要因で開発生産性の低下が起こります。
そこで現場のエンジニアは改善をしたくなるかと思いますが、大抵の場合、ステークホルダーと工数確保の合意が必要になります。
その際にこのようなことを言われがちではないでしょうか？

• 今動いているものを直す必要ある？
• 効果測定どうやんの？
• 費用対効果はどれくらい？

パフォーマンスチューニングの世界には「推測するな計測せよ」という言葉がありますが、開発組織における生産性についても測定してモニタリングする必要があると思います。

本セッションの目標

以上を踏まえ、本トークでは開発組織とステークホルダーの間の共通言語を獲得することを目標に以下の内容についてお話します。

• State of DevOpsとは
• Four Keysとは
• 27のケイパビリティとは

ライセンスの都合でローカル環境での開発環境構築が不可能な、CMSに密結合したWebサービス。
CMSの仕様に引っ張られてトリッキーな実装がされることもしばしば…といった状況もありました。

そんなJava製CMSを利用して構築していたサイトを、2年間かけてPHP + Laravel にリプレイスしました。
ソースコード管理もGitで管理でき、EC2で動いていたサイトをDockerを用いてローカルでの開発も同時に実現しています！
ステージ環境やプロダクション環境はAWSサービスである、Fargate、Codeシリーズを活用でき、柔軟にスケーリングできるようになりました。
CMSに密結合していた部分もLaravelに変更することで、モダンなサイト開発体制に近づけることができました。

この発表では、10年以上運営されている大規模な求人サービス「はたらこねっと」でのリプレイスプロジェクトにて、工夫した点や苦労した点についてお話しします。画面は数百単位、PHPのコードだけで数千単位、単体・結合テストの項目数は数万単位のプロダクトです。
コード面やアーキテクチャでの工夫、継続的な開発を意識したCI/CDの活用、監視体制の改善など様々なチャレンジをしながら、リリースを実現しました。
本トークは中〜大規模なサービスリプレイスをお考えのオーディエンスにとって参考になるトークになるものと思います。

またリプレイスや現在の開発・運用も協力会社の方とともにやっています。
大規模なプロダクトなので、参加人数が多くなりチーム体制やマネジメントといったところも試行錯誤しています。
現状の開発体制も踏まえ、協力会社と一緒に開発するという組織づくりやチーム体制についても参考になれば幸いです。

このリプレイスを通して特に活用できた技術は下記です。

• PHP
• Laravel
• PHPInsights
• Docker
• DataDog
• NewRelic
• AWS
  • Fargate
  • CodeBuild
  • CodeDeploy

現在、正規化という手法はDB設計においてよく知られている手法となっています。

しかし、現場では以下のようなテーブルを見かけることは珍しくありません。
・1 つのカラムに複数の値が入ったテーブル
・カラム数が多いまたは、1 つの情報変更で更新処理が多く必要なテーブル
・JOINすると期待通りの結果が得られないテーブル

これらは低次の正規化により一定解決できます。もちろん闇雲に分割すればいい訳ではなく、
正規化の概念を正しく理解した上で分割を行う必要があります。

そこで本セッションでは、リレーショナルデータモデルが集合論に立脚していることから、数学的背景に着目して第１〜第２正規化について紹介します。
具体的には、RDBの用語(候補キー・関数従属性・情報無損失分解・正規形)を適宜厳密に解説しつつ
実際の正規化の例を通して、PHPer が向かうべきテーブル分割の手法を持ち帰っていただきます。

現在私が所属するGrowfit株式会社ではLaravelで作られたStraym(ストレイム)というアート作品のオーナー権販売サービスの開発・運用を請け負っています。

自分が参画したのは2020年頃で、コードを見たところルールや方針もあまりなく、技術的な負債に対してあまり改善ができていない状況でした。
すぐにでも改善したいところですが、開発体制はCTO+私の2名(たまに助っ人)体制で新機能開発/保守運用の全てを行っており、かつ成長途中のプロダクトということもあり新機能開発が最優先で負債を解消していく時間を別途確保するのは難しい状況でした。

それでも負債をそのまま放置せず、機能開発と並行しながら負債と向き合い、少しづつではありますが継続してリファクタリングを行うことで保守性の向上に努めています。

この発表では、参画してからの2年で行ってきた少人数チームでの負債との向き合い方や実際の取り組みについてお話しします。

「なんかXXXの機能が開かないんだけど、、」
深夜に自分がリリースしたものが原因で次の日に全企業に響く様な障害を起こしてしまいました。

本トークでは以下の2軸をお話していきたいと思います。

■ なぜ障害が起こったのか
根本原因は「フレームワークの機能を使わなかった」からなのですが、なぜそうなってしまったかを
実際にコードリーディングしながら解説します。

■ 我々の組織の障害フロー
障害かな？から障害対応、そのあとのポストモーテム方法を取り決めています。
これにより良くなったこと・改善できたこと、などをご紹介します！

自分が起こした障害ゆえ発表するのも恥ずかしいのですが、、、言わぬは一生の悔い！！
ぜひ今後の人生の教訓にどうぞ。

※こちらのトークは、9/24 Track3 15:15 から、9/25 Track4 13:20に移動しました

私が担当するSaaSプロダクトは15年続くサービスで、メインシステムはいわゆるレガシーシステムになっています。
そんなプロダクトで、新機能実装にあたり新たに小規模なサブシステムを構築することになりました。
メインシステムとはある程度切り離されたシステムなので、せっかくならモダンな技術を存分に取り入れたい！と思いつつも、環境面の制約や既存資産の流用、チームメンバーの学習コストといった課題も考慮しながら技術選定やアーキテクチャ設計を行う必要がありました。
そして検討の結果、既存資産を一部活用しながらも、新規要素としてフレームワークにはSlimを採用し、アーキテクチャはオニオンアーキテクチャ（風のアーキテクチャ）を取り入れることにしました。

このトークでは、Slimを使ったアプリケーション構築の一例として、サブシステム構築時に考慮した技術選定・アーキテクチャ設計のポイントをご紹介します。

みなさんモビングしてますか？
モビング（モブプログラミング、モブプロ）とは複数人でプログラミングを行うことを意味します。
なぜモビングをやるのか？ どうやるのか？ ペアプロとなにが違うのか？ 結局生産性はあがったのか？
ずっとモブプロするのか、ときには並行作業するのか？

マーク・パール著「モブプログラミング・ベストプラクティス 」を実践してみて学んだことをギュッと圧縮してお話しします。

明日から役立つモブプロのエッセンスをお伝えできたら幸いです。

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

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

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

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

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

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

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

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の仕組みや適用した場合の効果について検証した結果を紹介します。
時系列データをすでにデータベースで扱っている方や、今後扱う予定がある方の参考になれば幸いです。