トーク

人は言います——モジュールを疎結合にせよ、と。
人は言います——具象ではなく抽象に依存して実装せよ、と。

ソフトウェア設計におけるベストプラクティスは異口同音に関心の分離の重要性を説きます。SOLID原則の「D」ことThe Dependency Inversion Principle / 依存性逆転の原則を実装するための道具立てとしてDIコンテナ、あるいはIoCコンテナと呼ばれる仕組みが利用されることがあります。

「PHP DI」などで検索すると、さまざまな説明が読めることでしょう。……御託はわかった。しかし昔の私には問題意識も活用方法も理解できず時間は過ぎ去っていきました。フレームワーク嫌いの私も数年も経験を積み、いくつかのフレームワークに触れてそれぞれの長短がわかってくると「Laravelのこれだけ使いたい」とか「CakePHPのここだけ羨ましい」などと考えはじめるものです。

このトークではPHP-DIに触発された簡易的なDIコンテナの実装方法を紹介し、PSR-18のような外部と通信するインターフェイスを分離しオブジェクトの生成をDIコンテナのオートワイヤリングに任せることで、どのように実装を簡潔にできるかを説明します。発表内容は実装にフォーカスしており、設計原則やソフトウェアアーキテクチャについては言及しません。

今回の発表では以下のコードの実装時に得られた知見を含みます。

• 特定のフレームワークに依存せずPHP-DIを用いてオブジェクト生成とメソッドのディスパッチを行なったWebアプリケーション
  https://github.com/phppg/phperkaigi-golf
• リフレクションを用いてメソッドを動的ディスパッチするライブラリ
  https://github.com/bag2php/meta

2020年の10月に「Fukuoka.php Vol.32」という勉強会で Laravel Livewire のデモを発表する機会をいただきました。

概ね好評だったのですが、一部の方から
「キモい」
「ヤバイ」
「怖い」
「負荷で死にそう」
「次世代jQuery」

という感想もいただきました。これらの危惧を払拭すべく個人プロジェクトではありますがLaravel Livewireを使用したアプリケーションを作成しました。

作成したアプリケーションを例に Laravel Livewire の使い方、内部ではどのように動いているのか、作成時に気をつけたことなど説明します。

Laravel Livewire は決して怖くはありません！！！！

エンジニア向けイベントのスポンサー担当をここ数年やっています。
会社としてはもともとそんなに積極的にスポンサー活動をしていたわけではないので、どういったことをきっかけにするようになったかの背景を始め
・スポンサーするにあたって予算とかどうしている？
・効果測定は？
・実務面では何している？
について話します。
このトークをきっかけに、より多くの会社様がエンジニア向けイベントのスポンサーになってもらえればと思います。
もっともそれ以前に、スポンサー担当していると、自社のロゴがイベントサイトに掲載されたり、会場でロゴがあったりするだけでイベント参加が一段と楽しくなるので、そういう楽しさを是非共有したいです。

※ PHP カンファレンス 2020 でお話した内容の改訂版です。図表が増えたりデモを失敗しなくなったりします！

PHP は "PHP: Hypertext Preprocessor" の略ですが、この 25 年間で Web は高度化し、複雑化し、それに伴い Web サイトを作るための言語にも、いっそう複雑な機能が要求されるようになってきました。

昨年リリースされた PHP 8 では、満を持して JIT コンパイラ が導入されました。

典型的な PHP アプリケーションは I/O バウンド（DB バウンド）です。JIT はそのような既存のアプリケーションのためというより、これまで PHP が使われてこなかった、使えると思われてもこなかったような、新たな領域への扉を開くものとして、FFI や Preloading との組み合わせを念頭に提案されたものです。

一方、世間の CPU は着実に多コアの時代へと進んできました。今の時代にある程度 CPU を使うアプリケーションを作ることは、JIT を使うだけの話では済まず、何らかの並列処理機構を用いこの多コアの CPU とも向き合う必要があります。

このトークではそんな新時代における PHP を使い、

• FFI でシステムコールを呼び出し外部プロセスのメモリをのぞき見たり
• （非 Web の） GUI ライブラリを利用してデータを可視化したり
• ext-parallel によりプログラムをマルチスレッド動作させたり
• スレッドの動作効率化ため preloading を活用したり
• JIT によりそのようなプログラム全体の動作を高速化したり

といった、一味違った PHP の利用方法への挑戦を紹介するとともに、そこで得られた知見、現状の制限についてお話します。

比較的モダンなフレームワークでは、例外処理や例外発生時の検知・ロギングが仕組まれていますが、PHPでは検知をすり抜けてアプリケーションを終了させる手段が多数存在します。本セッションではPHPのプログラム実行の仕組みから、どのようにすれば検知の網の目をすり抜けることが出来るのかを解説します。この知識を得ることによって、逆にどのようにアプリケーションを作成すれば、比較的安全を担保できるのかが理解できるようになります。

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

• PHPの例外検知機構と検知不能が発生する仕組み
• 最後の悪あがき「register_shutdown_function」の仕組み
• 検知不能状態を検知する方法の提案

バージョン 8 にしてとうとう僕らの PHP にも JIT がやってきました！
が、PHP 8 の JIT は生まれたてで、同じ 8 でも JavaScript の V8 にはまだまだ速度的な面で追いつかない部分があります。
PHP と JavaScript のそれぞれについて、おおむね同等の処理を行うマイクロベンチマークのコードを用い、プロファイルをとりながらああだこうだ言いつつ速さの特性差や PHP の現状の限界、得意な点や不得意な点を探っていきます。

■ 想定する聴講者
典型的な Web アプリケーションは主に I/O バウンドとかそういう現実の話は脇に置いておいて、PHP スクリプトの性能や測定方法が気になる人
今後の PHP の性能の伸びしろに思いを馳せたい人
しょうもないマイクロベンチマークが好きな人

■ お話しないこと
明日から業務に使える役立つ知識

新規サービス開発において、PHPウェブアプリケーションを実際に世界に向けて動作させるためのインフラが必要になります。では、一体どのようにしてインフラを選定したら良いのでしょうか？プログラミングの世界ではDRYやYAGNI等の格言や、アーキテクチャー選定の考え方が浸透していきていますが、インフラにおいては、基準が曖昧です。本セッションでは、ウェブアプリケーション初期構築時のインフラについて実例を紹介しつつ、妥当なインフラを選択するための基準を紹介します。

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

• 選択可能なインフラ環境
• 選定時の基準
• 各環境の利点と欠点

ステートレスなHTTPをステートフルに変えてくれる仕組みがセッションです。ユーザのログイン、リダイレクト後のエラーメッセージの表示、CSRF対策等、現代のウェブアプリケーションで多用されているセッションですが、セッションがどのように動いているかと聞かれた時に正しく答えられますか？
初心者に近いPHPerがセッションを多用すると、中堅クラスのエンジニアから「セッションは危ないから多用しないように」とアドバイスされることも多いと思いますが、それは何故でしょうか？

本トークでは、ウェブアプリケーションにおけるセッションについて、その正体を分かりやすく解説します。また、セッションの正体を知ることで、ウェブアプリケーションのアーキテクチャーに対してセッションが及ぼす影響についても解説します。セッションにまつわるアレコレを解説することで、初心者とベテランエンジニアの間に存在する知識と経験の差を少しでも埋めることが狙いです。

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

• セッションの仕組み
• ウェブアプリケーションフレームワークにおいて利用されているセッションの例
• セッションが本番アプリのアーキテクチャに与える影響

bugs.php.net は PHP の公式 issue トラッカーで、処理系本体と公式バンドル拡張、PECL 拡張をあわせて現在 2000 以上の未解決のバグが登録されています。

古いものでは PHP4 時代のチケットで残っているものもあり、現在サポートされている処理系バージョンにおいてすでに解決済のものや、そもそもバグではないもの、当初は明らかにバグだったとしても 10 年以上その挙動が続いたことで、もはや仕様としてしまった方がよいのではないかと疑われるものなど、色々なチケットがあります。

そんな bugs.php.net の古くからある塩漬けチケットについて、現在サポートされている PHP 7.4 以降でも再現するか、レポート内容が妥当かなどを検証しつつ、修正可能なものについては PR を投げ、修正不可能であったり修正の必要がないものについてはコメントを追加して現在の状況を付記する、という清掃活動に取り組んでみました。

bugs.php.net 自体やチケットの調べ方について紹介しつつ、見つけて面白かったチケット、実際に対応したチケットについてお話します。

サービスが成長し、機能が追加され、データ量が増大してきたある日、サービスが速度面で劣化してきます。そのような状況ではウェブアプリケーションの処理速度を改善するためのチューニングが求められます。しかし、チューニングの経験がない場合、何をすべきか分からず、効果のない改善作業を繰り返してしまいます。本トークでは実際の例を参考にして、どのようにウェブアプリケーションのチューニングを行っていくべきなのかを丁寧に解説します。

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

• アプリケーションが遅いとは？
• 問題の特定方法
• レイテンシーの評価
• チューニングを行う判断基準
• ケーススタディーで学ぶ「実際のチューニング」

PHP 8で導入されたattributes。
今まで（やむをえず）PHPDocを用いて実装されてきた様々な書き方が、だんだん置き換わっていこうとしています。
今回は、DIの代表的なライブラリであるPHP-DIが新しいバージョン（7、2021年1月19日時点では未リリース）でどう変わろうとしているか、また、Symfonyなどの変化もあわせて紹介しつつ、PHPにおけるDIの行方について話したいと思います。

PHP 7.4 で追加された FFI を通じて、 Linux の FUSE を利用することができます。
つまり、今や我々は PHP でファイルシステムを作ることができるのです。
たとえば WordPress ファイルシステムを作ってマウントすることで、grep や sed を通じて DB 内の記事データを編集するような誰得な操作も可能となります。
このセッションではそんな FFI による大道芸、PHP によるシステムプログラミングの実例とそこで使われている技術について簡単にお話します。

あるシステムを理解して開発を開始するとき、必要なのはInfrastructure as Codeを含むソースコードだけでは大抵の場合は不十分です。では挙動がわかるようなテストコードがあれば十分かというとそうでもありません。
いわゆる「オンボーディングの効果的な運用」「開発開始までのオーバヘッドの削減（PHPerKaigi2020で発表）」は継続的な生産性向上のためには考えなければならない要素です。
そして、上記を補完するためにしばしばドキュメントが書かれます。

私はドキュメント運用のアプローチとして「コードによる生成を含んだドキュメント運用」に興味を持っています。
私はこれを「Documentation as Code」と呼んでいます。そして、そのような概念はすでに世の中にあり、時として「Documentation as Code」と呼ばれているようです。
例えばPHPDocなどはソースコード自体の構造とアノテーションをトレースしてドキュメントの自動生成を実現しています。
OpenAPIのように構造化されたデータとして情報を記述することでドキュメントと同時にAPIクライアントやの自動生成が実現できている例もあります。 これらはコードによってドキュメントが管理されており、継続的なドキュメンテーションも実現可能です。
さて、ドキュメントと言っても「何を解決するためのドキュメント」なのかを考える必要があると思います。
本発表では、上記のような「Documentation as Code」を実現するツールを独自にモデル化してそれぞれの特性について考えます。
そして、どのような「Documentation as Code」が「開発開始までのオーバヘッドの削減」に繋がるのか、私が実際に取り組んだ（また取り組んでいる）事例を交えて考えていきたいと思います。

Everything Will Be Serverless.
そんな未来は来ないかもしれません。
しかし、私はそんな未来を信じてお話します。

話者は昨年AWS上でFull Serverless SPAの構築を行いました。

今までサーバーを意識したPHPのWebアプリケーションを作成する事が多かったの話者が、
サーバーやRDBMSを使わないFull Serverless なWebアプリケーション構築を通して学んだ知見を共有します。

ServerlessなGo APIとReactのSPA構成を構築して実感した所感もお話できればと思います。

■利用言語、フレームワーク

• Go
• React x TypeScript

■利用AWS リソース

• AWS Lambda
• Amazon DynamoDB
• Amazon S3
• Amazon CloudFront
• Amazon Cognito
• AWS Amplify
• Amazon Athena、Amazon S3 Select
• Step Functions、AWS Batch

■想定する聴講者

• Serverlessに興味がある方
• AWSが好きな方
• 理論はわかるけど実際に構築したことが無い方

■お話する内容

• 実際の構成について
• ServerlessなSPAの開発手法について
• APIとフロントエンドの結合部について
• 開発からリリースまでで実感した所感

単体テストを作り込んでいくと、「データベースを使う部分をどうするべきか？」という悩みにぶち当たる場面があると思います。
「そもそも”コードのテスト”なのにデータベースに依存するなんて」や「どうしても全体実行に時間がかかるな」などです。

そこで、「vimeo/php-mysql-engine」という選択肢はいかがでしょう？

前口上

丁寧に、クリーンな構造を持ったアプリケーションであれば、その辺りはモックやスタブを利用しながら、「データベース接続」についての一切の関心を外に追いやったテストも可能になるものかと思います。
他方で、「そこまで行っていない」アプリケーションも多いでしょう。
いずれにせよ、既存のアプリケーションやフレームワークといったコードベースに、大幅な手を加えず、それでも「もっとライトにテストを回す」という願望は叶えられないものか・・・

本題

vimeo/php-mysql-engineは、実際のMySQLデータベースを用いずに、(PDO_MYSQLを想定した)RDBMS処理を再現できるライブラリです。
vimeo/php-mysql-engine - Packagist

既存のアプリケーション構造が、リレーショナルデータベースと疎結合にできる”testable"な状態になっていなくても、
php-mysql-engineを利用すれば少ない工数で「自動化テストの効率化」を狙えるかも知れません。

このトークでは、ライブラリの簡単な紹介と、実際にテストに組み込むにはどうすればいいか？を紹介します。

みなさんサーバーレスってますか？PHPerでもサーバーレスってますか？
どうやら世の中サーバーレスだったりマイクロサービスだったりがモダンなようです
AWSは使っていても、構成は結局LAMPどまり…というぼくが、次の新規案件にサーバーレスを採用しようと決めました
一足遅くなりましたが、このビッグウェーブに乗ろうとしたぼくの過程をお話ししたいです

ためしに、このトーク用に #サーバーレス で動くモノを作ってみたいと思います

皆さん、開発・運用では様々なツール、コマンドを駆使していると思います。
また、利用者もエンジニア、デザイナ、QAなど多様で、環境もローカル開発用PC、ステージング/本番サーバなど用途に応じてOS、プラットフォームを使い分けていることと思います。
そこで、makeコマンド(Makefile)で開発・運用をもっと楽にするための幾つかのノウハウを紹介いたします。

• 複雑な操作、一連の処理をまとめてタスク名をつける
• 必要なことだけをやる (依存関係、タイムスタンプ)
• 環境の違いを吸収する (開発/本番, Mac/Windows/Linux, etc)

※ phpに限定しない、汎用的に活用できるテーマです。

PHP界隈でもドメイン駆動設計の話題が盛んな昨今ですが、正しい設計のためには前工程としての要件分析が不可欠です。詳細な設計に入る前にプロダクトオーナーが読み解ける形式の文書で合意を取っておけば、最小のコストで「本当に必要なもの」を作るための足場となります。また、ドメインエキスパートを設計の深いところまで連れて行くための道標も手に入るでしょう。

このセッションでは、システムとユーザーの相互作用をユースケースシナリオとして表現し、そこからオブジェクト指向らしいクラス設計を導く手順を紹介します。設計スコープと目的レベルについて理解し、簡単なフォーマットさえ覚えれば、誰でも明日からユースケースシナリオを活用できるようになります。

速いは正義、アプリケーションは速くあるべきです。

ではどうすれば良いのか

細かい理論などは気にしない、こうしたら早くなった

結果を貼り付けながら、何をしたのかひたすら話しますが、細かいことは話しません

事前収録であることを生かして、OS、Webサーバー、PHP、RDBMS等の見直すべき要素に関して
情報を詰め込むだけ詰め込むことに挑戦します。

※注釈は付けますので細かな理論はそちらでご確認ください

■想定する聴講者
　- PHPWebアプリケーションのパフォーマンスに興味がある方
　- PHPのインフラを整備するエンジニア
　- PHPでISUCONに挑戦する方

■お話しないこと
　- パフォーマンス以外の話
　- アプリケーションコードによる改善
　- 劇的なパフォーマンス改善策

ここ数年、フロントエンド技術は目覚ましい進歩を遂げてきました。私たちバックエンドエンジニアもその流れに追随するよう努めていますがなかなかにツライものがあります。なんとかバックエンドでインタラクティブな web アプリケーションが作れないものか…と考えているそこのあなたに朗報です。

Phoenix LiveView
Laravel Livewire
Hotwire

と各言語でバックエンドからインタラクティブなwebアプリケーションを作成するためのライブラリが立て続けにリリースされています。

本 LT では Laravel Livewire を中心に業界の動きを紹介します。