自分は2019年2月に個人事業主となって以来、３つの副業案件を経験しました。
本LTでは自身の体験をもとに以下について話をできればと思います。

• 副業を始めるための準備として何が必要か
• 副業案件の契約締結にあたっての重要事項
• 副業を継続していく秘訣と個人事業の将来

主力言語としてPHPを掲げ、それゆえに思い通りにいかないこともありましたが、
それなりに自身を広げ、Re:born できることを示すことができれば嬉しいです。

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 の性能の伸びしろに思いを馳せたい人
• しょうもないマイクロベンチマークが好きな人

■ お話しないこと

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

「重い処理を早くしたい」といえば、処理の非同期化です。
「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の良さを発見することを目的としています