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

■ 想定する聴講者

• PHP スクリプトの行レベル / VM 命令レベルでの性能や測定方法が気になる人
• 今後の PHP の性能の伸びしろに思いを馳せたい人
• しょうもないマイクロベンチマークが好きな人

■ お話しないこと

• 明日から業務に使える役立つ知識

去る9/19〜9/21にiOSDC Japan 2020という技術カンファレスがオンラインで開催され、60本のトークと20本のLTが実施されました。
実施された60本のトークはすべて事前収録され、それを当日に再生する形でカンファレンスを開催しましたが、60本の動画の編集にかかった日数は3日ほどでした。動画編集に詳しい方であればちょっと驚く期間かと思います。

この高速編集を支えたのはPHPでした。

このトークでは私がどの様にPHPでオンラインカンファレンス向け録画システムを構築したのか、そして、同じ様なシステムを作りたい方のためのサービス連携のコツをお話しします。

• Zoom, YouTube Live, Dropbox を連携させた収録システムの作り方
• GD, ffmpeg を使用したオンラインカンファレンス用動画編集システムの作り方
• PHPでサービス連携するためのコツ

このトークを聞いたみなさんが、PHPで高度なシステム連携アプリを作るきっかけになることを期待しています！

参考:
iOSDC Japan 2020
https://iosdc.jp/2020/
iOSDC Japan 2020 トーク動画
https://www.youtube.com/playlist?list=PLod2oSGQp3W4BV6sLUdMwlZD0NHt9mHP7

Track ID: Track3-5-B
Discord Channel: #track3-5-b-online-conference-system

「重い処理を早くしたい」といえば、処理の非同期化です。
「PHPで非同期」というと、「Swooleだ」「pcntlを使って」といった声が聞こえて来そうです。
あるいは、(HTTP)リクエストについてならば、「guzzleのasyncで」「curl_multiで」と耳にします。

さて、「MySQL 改良版拡張モジュール MySQLi」を皆さんは活用できていますか？
昨今の一般的なPHP環境であれば、こいつを使えば「重いSQL処理をMySQLにパラレルで投げておく」が可能になるわけです！！

本セッションでは、今一度、改めて「MySQLiを使って非同期処理を行うには」という方法について学んでみたいと思います。
(そんなに高度ではない内容です)

想定する聴講者

• あんまり mysqli::pollやmysqli::reap_async_query という文字列にピンとこない方
• 「何が何でもレイテンシを下げたいんだ、しかし必要なSELECTが多すぎて・・・」と悩んだ事がある方

おしながき(仮)

• PHPで書いたコードでの「非同期処理」の制御の仕方
• 「MYSQLI_ASYNC」モードを指定した時の動作
• 実用性のあるコードで利用可能にする

Composer の普及により、PHP における Web アプリケーション開発において外部ライブラリやフレームワークを活用にするのは一般的になりました。みなさんもアプリケーションで要求される機能要件、非機能要件の観点からライブラリを選定して利用しているでしょう。

今抱える課題を解決するため、欲しい機能を実装するために導入したライブラリですが、アプリケーションに組み込むということは、これからアプリケーションが動き続ける長い道のりを共に過ごすということになります。

導入した当初はその時点における安定したバージョンや最新バージョンであったとしても、時間の経過と共にライブラリはバージョンアップを続けていきます。それに逐次追随できれば良いのですが、いつもそれが簡単にできるわけではありません。特にメジャーバージョンアップにより、後方互換性を失う変更が入った際は容易ではありません。そのライブラリを利用している箇所全てが影響を受けるので、単に composer update すれば済むという話ではありません。

このようにライブラリの導入は容易ですが、その後の長い運用を想定してアプリケーションにどのように組み込むかという視点が必要となります。

本セッションでは、下記のようなトピックを交えて、アプリケーションにおけるライブラリの活用戦略を考えていきます。

• ライブラリへの依存
• PSR に準拠したライブラリなら良いのか？
• 要求をインターフェイスにする
• フルスタックフレームワークとオリジナルフレームワーク

昨年のPHP Conference Japanにて、「Composerがどんな課題を取り扱い、それをコード上でどう表現しているのか」という発表をさせていただきました。
そして今、2016年04月のリリース以来、Composerは初めてのメジャーVersion Upに向けて準備が進んでいます。
(そう、”Re:born”ですね！)

昨今のPHPの進化を語る上で欠かせない存在となったComposerは、数年間の時を経てどんな進化をする(した)のでしょうか？
「どんな機能が増えて」「どんな改修が行われて」「それはどんなコードで実現しているのか」、興味がありませんか。

本セッションでは、主要な機能の紹介を、内部実装の”見どころ”を交えながら行います。

想定する聴講者

• [ ] Composerは利用しているが内部処理まで追っていないという方
• [ ] Comopser v2の実戦投入を目論んでいる方
• [ ] ドキュメントをggったりエラーコードをじっくり読み解くのが面倒くさいからソース読みたいな、という方

Track ID: Track2-4-A
Discord Channel: #track2-4-a-composer2

待望の PHP8 が出ましたね！
パッケージマネージャーで PHP をインストールすることが多い昨今、ビルドって実際にどうやるんだろう？と疑問に思っている方も多数いらっしゃると思います。
敷居が高そう、難しそう、そう思っている方もいらっしゃると思います。しかし本当は PHP そのもののビルドはそんなに難しくありません。
ということでトークの時間を目一杯使って PHP8 のビルドをオーディエンスの皆様と一緒にライブ形式でやってみたいと思います。
本トークで、ビルドをどうやるのか感覚を掴んでいただき、ぜひ様々なシーンでご活用できるようになっていただければと思います。

カンファレンス開催の頃には満を持してリリースされているPHP8。より厳密な処理が書きやすくなり、実行速度は速くなり、メタプログラミングに使いやすい機能も増えました。

本トークでは、Webアプリケーション開発を取り巻く環境の変化やPHP8の新機能を考察しながら、PHP8時代にも次々と出てくるであろう新しいWebアプリケーションフレームワーク（以下単にFW）の動向や既存のFWの変化について独断と偏見により予想します。

また、FWの内部の仕組みに触れることで、独自FWの作成に興味を持つ方が増えれば幸いです。

●お話したいこと

• FWの共通部分の仕組み
• PHP8の新機能の軽い紹介とFWへの活用
• FWの"個性"
• デプロイターゲットの多様化
• オレオレFWのすゝめ

●お話しないこと

• 次に流行るFWの具体名の予想

Track ID: Track5-4-B
Discord Channel: #track5-4-b-php8-framework

最近やっとこさ本番環境もDockerで動かすようにできたのですが、そこまでの道のりは長いものでした。既存のアプリケーションをそのままDockerにのせてえいやと本番で動かせるケースは少ないと思います。アプリケーションを改修したりインフラの構成を変更したり・・・トップダウンで(本番環境から徐々に)進めようとすると手元の環境はなかなか改善されません。

でもまずは手元の環境を新しくしたい・・・手元の環境だけでもモダンな感じにしたい・・・でも最初からGithubやAWSにお金はかけられない・・・みたいな状況だったとしても打つ手はあります！

このLTではわたしが開発環境カイゼンをはじめた際、最初に取り組んだことをご紹介します。

PHPを書きながらフロントエンドも書いている！という人も多いのではないでしょうか？わたしも最近そんな感じでバックエンドはLaravel、フロントエンドはNuxt.jsを使って開発をしています。

APIはPHPに任せてフロントをNuxt.jsで実装しているとかなり責務が分かれていい感じだなと思っているのですが、その分Nuxt.js側でのCSSの変更などによるデグレが気になるようになりました。そこで最近取り入れているのがAtomicDesignとビジュアルリグレッションテストです。AtomicDesignの採用によりコンポーネント単位で実装するようになるので、そのコンポーネント単位で見た目のテストができ意図しない変更に気付きやすくなります。

このセッションでは、わたしがStorybook、REG-SUIT、CodeBuild、Github Enterpriseを組み合わせて構築したビジュアルリグレッションテスト環境の技術要素や運用状況についてご紹介します。

Track ID: Track2-5-B
Discord Channel: #track2-5-b-visual-regression-test

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

PHPWebアプリケーションを構成する要素として、
パフォーマンスを向上させるポイントはどこにあるのでしょうか。

今回はPHPWebアプリケーションを速くするポイントを
PHPに限らず幅広い視点で見直してみようと思います。

OS、Webサーバー、PHP、RDBMS等の見直すべき要素に関して触れ、
愚直に改善を行うべき場所を再考し、
堅実にパフォーマンスを改善する方法をお話しようと思います。

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

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

テストピラミッドとは、Mike Cohn氏が提唱した各層のテストコードの比率や費用対効果を表したものです。
テストピラミッドでは「UIテストを薄く、ユニットテストを厚くした状態」が理想となっていますが、各層のテストコードを実装していく中でどのように意識すれば良いのでしょうか？

そこで、実際のPHP製システムにE2Eテスト、featureテスト、ユニットテスト等を実装する流れを例にして、テストピラミッドを意識したテストコード実装戦略について解説していきます。

どのような題材にするかは未定ですが、「過去にLaravel公式ドキュメントにあったチュートリアルのシステム（https://laravel.com/docs/5.1/quickstart-intermediate）を、Laravel8.x / PHP8.0にバージョンアップする」を題材にする予定です。

Track ID: Track4-3-B
Discord Channel: #track4-3-b-test-pyramid

PHP8は速い、速いはずなんだ！

JITを中心にPHP8はパフォーマンスへの期待が高まっています。

今回は3分一本勝負でPHP8がいかに速いかをひたすら主張してみようと思います。

私達PHPerの夢を載せて、PHP8と共に3分間駆け抜けようと思います。

■想定する聴講者
　- PHP8のパフォーマンスに興味がある方
　- PHP8のベンチマークに興味のある方

■お話しないこと
　- パフォーマンス以外の話
　- 話す必要がないと感じたこまけぇ理論

「銀の弾丸はない」
ではPHP8は私達に何をもたらしてくれるのか。

私達はIikanjini Speed Up Contest、通称ISUCONの予選にPHPで挑戦しました。
結果は残念ながら468チーム中46位とあと一歩で本戦への切符を勝ち取る事が出来ませんでした。

実はどうしてもPHPでISUCON 本戦へ出場したい、その想いからPHP 8.0.0 Betaの投入を迷っていましたが
最終的に使うことなく敗退しました。そこに少なからず心残りはあります。

そんな中、先日PHP 8.0.0 Release Candidate 1が発表されました。
来年こそ、大手を振って導入できる事でしょう。

ISUCON は総合力の勝負です。
PHP8が銀の弾丸になることは無いのかもしれません。
しかし、私達PHPerはPHP8に壮大な夢を見らざるを得ません。
そこで私はPHP8のパフォーマンスに絞った内容調査を行う事にしました。

JITなどパフォーマンスに関して多大なる期待が寄せられているPHP8は、
私達をISUCON本戦の扉へ導く鍵となるかを検証してその成果をお話します。

今年、PHPを使ってISUCON 本戦へ進んだチームはただ1チーム
そのチームに続き、来年こそ私達PHPerの手でISUCON本戦への扉を開きましょう

■想定する聴講者
　- PHP8のパフォーマンスに興味がある方
　- PHP8のベンチマークに興味のある方
　- 来年こそPHPでISUCON 本戦への進む心意気のある方

■お話しないこと
　- パフォーマンス以外の話
　- PHPのgRPC利用について

Track ID: Track5-3-B
Discord Channel: #track5-3-b-isucon

PHP7でPreload, PHP8でJITと、PHPを高速化する仕組みが次々と導入されてきています。ベンチマークや解説記事などでどれくらいパフォーマンスが向上するのかをご覧になった方も多いかと思います。
しかし、一体どうして速くなるのか、どうのような仕組みなのか？Preloadとは何か、JITとは何をするものなのか、皆さんは答えられますか？

本トークではPHP8のソースコードレベルから、PreloadやJITの正体について、順を追って分かりやすく解説します。モダンなPHPが実行時にどのような動きをするのか、少し分かるようになってくれたら嬉しいです。

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

• Preloadとは何か？
• Preloadの仕組みと、実行の流れ
• JITとは何か？
• PHPにおけるJITの仕組みと、実行の流れ

Track ID: Track5-3-A
Discord Channel: #track5-3-a-preload-jit

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

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

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

• セッションの仕組み
• Laravelにおいて無意識に利用されているセッションの例
• Laravelが独自のセッション管理を行う理由
• セッションが本番アプリのアーキテクチャに与える影響

今でこそPHPはRubyと比較されることは少なくなりましたが、PHP5の時代はよくRubyもしくはRuby on Railsと比較され、そしてときにディスられもしました。

時は流れPHPはバージョン7を経てバージョン8へと進化し、Webアプリケーションフレームワークとして洗練されたLaravelも台頭してきました。今ではプログラミング言語人気ランキングでPHPはRubyより高い位置にランクインしています(*1)。

本発表は改めてPHPとRubyを比較することで見えてくる＜PHPらしさ＞に着目して、＜PHPの良さ＞の再発見をしたいと考えています。

本発表の想定オーディエンスは下記の通りです。
・Rubyに興味があるPHPer
・Rubyをちょっと書いたことのあるPHPer
・元・RubyistなPHPer
・元・PHPerなRubyist

*1 TIOBE Index https://www.tiobe.com/tiobe-index/

※発表者はPHPもRubyも好きなエンジニアです。発表の目的は、言語に優劣をつけることではなく、あくまでも言語比較・Webアプリケーションフレームワーク比較を通してPHPの良さを発見することを目的としています

PHPではIDEとして普及しているPhpStormのほか、静的解析ツールを活用することで実行なしでコードの問題点を検出できます。

さらには、Phan, PHPStan, Psalmなどの静的解析ツールが提供するタグや機能をPHPが本来持っている以上の能力を持った型を記述できます。
今回のトークではPHPが持つ基礎的な型と静的解析ツールが独自に提供する型、そして、これらだけでは解決できない型付けの問題についても紹介します。

アプリケーションコードや運用保守などクエリを書く場面は様々ありますが、皆さんはクエリを書くときにどんなことを意識していますか？
「えーっと、まずはSELECT句から書いて…」
簡単なクエリを書く分にはそれでも良いですが、複雑なクエリを書くようになったらどうでしょうか？

当LTではSQL実行順序に焦点を置いて、複雑なクエリを書くためのアプローチについて話していきます。

みなさんは億単位のレコードが存在しているMySQLテーブルをみたことがありますでしょうか？
もし、そのうち大半のレコードが不具合によって生み出されたものだとしたら、きっとDELETE文を実行したくなると思います。
でも待ってください。ただDELTE文を実行しようとしても、トランザクションは非常に大きくなり、ディスクIOやテーブルロックなどが原因となって、性能問題が生じてしまうでしょう。
このセッションでは安全に億単位の不要レコードを削除する方法をお話しします。

ある日、突然レガシープロジェクトに配属されました。
あなたはカンファレンスで色んな新しい情報を知っていて修正方法もおぼろげにわかるとしましょう。
何でも改善できます。
ただし、運用の中で少しずつ捻出される時間を利用して……ですよ？

・docker
・自動化テスト
・Linterの導入
・ドキュメント化
・DIやDDDの文脈の導入
・新しいツールやSaaSの導入

そういう状況になったときにどこから改善したらいいと思いますか？
もちろん一番大きな力になるのはツールや環境ではなくチームの地力を上げることです。
勉強会だったり、輪読会だったり、技術的な雑談です。
しかし怠惰なプログラマーたちは道具の点検も怠ることはできません。

では最大の効率を上げるため何から始めるべきでしょう？
取れる選択肢が多すぎて逆に選べなくなってしまった。
そんなときの改善ガイドを話すつもりです。

※技術的な話はしませんが具体的なツール名は説明なしにポンポン出ます。
※前提として話の合うチームメンバーが多少手伝ってくれるとします。

※ 初めての登壇になります。