新卒３年目が新チームに入って皆から良くなったと感謝されることが増えました。
何が良かったの分からなかったので、改めて自己分析した話をします。
明日からできる簡単なことなので、お話きいていいなぁと思ったら是非実践してください！

Track ID: Track2-2-B
Discord Channel: #track2-2-b-hamee

年末から年始にかけて開始予定のウェブ・セキュリティ実務知識試験(徳丸実務試験）とPHP8上級試験の解説をいたします。徳丸実務試験に合格して徳丸皆伝ステッカーをもらおう。稟議に使えるPHP市場データも解説。

Track ID: Track2-2-A
Discord Channel: #track2-2-a-tokumaru-exam

【概要】
弁護士ドットコムでも、半年くらい前にPHPStan静的解析をはじめました。

徐々に対象ファイルを増やし、現在では2000超のファイルをスキャンしています。
level0（不明なclass、関数の参照などの基本的なチェック）から段階的に厳しくして、level2(未知の全ての関数のチェック、PHPDocの検証)に上がります。

レガシープロジェクトにありがちな名前空間がない、PHPDocがないといった問題を、nikic/PHP-Parser(https://github.com/nikic/PHP-Parser)を武器に乗り越えてきました。
PHPDocで補いきれない部分は、自作のYii1フレームワーク用のPHPStan拡張で解析しています。
レガシープロジェクトで、静的解析を進めてきた方法を話します。

Track ID: Track2-1-B
Discord Channel: #track2-1-b-bengo4

アプリケーションのモニタリングしていますか？
デプロイした後のパフォーマンスチェックしてますか？
障害が起きてから監視ツールを眺めていませんか？

BASEでは最近、PHPで書かれているプリケーションの監視のためにNewRelicを本格的に導入しました。
NewRelicはAPMの印象が非常に強いですが他にも数多くのソリューションが存在します。
それらを使って自分達のオブザーバビリティプラットフォームを作りプロアクティブにアプリケーションをモニタリングしていくことができます。
APMに始まりNewRelic logsによるlog収集、Browserによるフロントエンドパフォーマンス監視、InfrastructureによるAWS監視、Syntheticsによる一歩進んだ外形監視。
そしてそれらの監視をNRQLというクエリ言語と組み合わせてダッシュボードにまとめて統合監視プラットフォームの構築を実現していきましょう。

Track ID: Track2-1-A
Discord Channel: #track2-1-a-base

PHPから派生し独自進化を遂げたHackを使ったアプリケーション開発では、
PHPと異なり、静的型付け言語のような堅実なアプリケーション開発をサポートする強力な機能が多く用意されています。
本セッションではそれらを使い、アプリケーションアーキテクチャ設計と、
Hackならではの実装コードに落とし込んでいくヒントを紹介します。

何らかの理由によって「既存のクラスやAPIの使い方が変更された、それに対応しないといけない！」という場面が、
しばしば開発の現場には発生します。
その時に、なるべく「人間の目と手で作業する」という負担は避けたい・・面倒くさいな・・と思うのが人の心情ではないでしょうか。

https://github.com/rectorphp/rector は、既存のPHPコードのリファクタリングやアップグレードを自動実行するツールです。
こいつを上手く使えれば、あの退屈で機械的な作業を真の意味で「機械の作業」にする夢が叶うかも知れません！！

本セッションでは、Rectorについて紹介し、具体的に活用するための方法を話したいと思います。

おしながき

• Rectorってなに？
• どういう仕組で動いてるの？
• 具体的にどうやって使われてるの？ 〜CakePHP4の アップグレードコマンドを例に〜
• 独自ルールを作ってみる

アプリケーションのモニタリングしていますか？
デプロイした後のパフォーマンスチェックしてますか？
障害が起きてから監視ツールを眺めていませんか？

ライセンス形態が大きく変わり、監視プラットフォームとして使いやすくなったNewRelicを利用して
NewRelicはAPMの印象が非常に強いですが多くのソリューションが存在します。
それらを少しずつ使って自分達のオブザーバビリティプラットフォームを作り、プロアクティブにモニタリングしていきましょう。
APMに始まりNewRelic logsによるlog収集、Browserによるフロントエンドパフォーマンス監視、InfrastructureによるAWS監視、Syntheticsによる一歩進んだ外形監視。
そしてそれらの監視をダッシュボードにまとめていく、といったところまでをお伝えします。

概要

「PHPで何かを作ろう」と思った時に「今風のコードを書くのに必要なもの」を考えてみました。
新しいプロジェクトをスタートする時に、「こういうのがあったら良いのでは」という案を
みなさんと共有して、知見を育みたいです。

過去に個人ブログにも投稿した内容をベースに、「狙い」や「考えたこと」を紹介します。
PHPお手軽スタートキットを作った - 大好き！にちようび

イントロ

人は、熱しやすく冷めやすい生き物です。
例えば、あなたが「あ！ちょっとこういうライブラリを作ってみよう！！」と思ったとします。
その時に、ゼロから「必要なもの」を考えますか？
「まずはphpunit.xmlを用意して、あと静的解析も入れたい。PHPStanのルールってどうやって書くんだっけ？CIも入れなきゃ・・あ〜GitHub actionsのworkflowの書き方がさぁ・・・」
そんな事に煩わされている間に、どんどんと「腰が重く」なり、「着手が遅れ」、そして「熱が冷め」てしまう。

そんな経験はありませんか？
私は、過去に何度も「README.mdだけコミットしてある空レポジトリ」を消したことがあります。

やったこと

この「腰の重さ」を支えて、「浮かんだアイディアを試すためのコードを書き始める」までを軽減したいと思ったのです。
そこで、「このくらいの要素が揃っていれば、気持ちよくPHPアプリケーションの開発をスタートできるだろう」という、
「ぼくのかんがえた さいきょうの いまっぽい PHPのツールたち」を揃えてみることにしました。

お話したいこと

まずは、「PHPアプリケーションのボイラープレート」に含めた内容を紹介します。
この内容をモチーフにして、「今日におけるPHPの開発体験を高く保つためには」というテーマに触れられたらと思います。

バージョン 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。より厳密な処理が書きやすくなり、実行速度は速くなり、メタプログラミングに使いやすい機能も増えました。

本トークでは、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

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は私達に何をもたらしてくれるのか。

私達は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が独自のセッション管理を行う理由
• セッションが本番アプリのアーキテクチャに与える影響