「早くPHP 8.1を使いたい… でもうちはまだ7.3なんだお…」

PHPの新バージョン8.1の機能は既に確定していますが、PHPは毎年11月末にリリースされるので、あと2ヶ月待たなければいけません。
また、そもそもリリース済みの7.4や8.0の機能を使いたいけれど、自分の一存では上げられない… そんなこともあります。
このLTではそんなときに便利なsymfony/polyfillと、その限界についてお伝えいたします。

型付けしてますか？ PHPで型安全なコードを追求しはじめると、やや取り回しの悪いPHPの標準関数の型に煩わされます。
そのような型には歴史的事情があるのですが、このLTでは標準関数の型の問題を解決するthecodingmachine/safeパッケージについて紹介します。

先進技術を貪欲に取り入れ続ける皆様にとって、PHPとGoを組み合わせた全く新しい (ver1リリースが2017年) FrameworkであるSpiral Frameworkの存在は周知のことかと思います。今回はこのSpiralとそれが採用しているCycleORM利用することで、エンティティの定義からデータベースのテーブル定義を同期させる機能をご紹介いたします。
Laravelなどのような積み上げ式のデータベースマイグレーションを採用している場合、時とともにマイグレーションファイルが増えていき、現在のデータ定義がわかりにくくなっていきます。一方、CycleORMを採用するSpiralでは、エンティティのプロパティ定義を利用して、データベースのテーブル定義との差分を検出し、定義内容を同期する機能が用意されています。この機能を活用することで、積み上げ式のマイグレーションファイルは不要となり、テーブル定義もエンティティのプロパティを見ればわかるようになります。
今時だとLaravelやCakePHPが割と覇権みたいに言われていますが、だからこそ、あえて、このSpiral Frameworkを通して、新しい開発体験をしてみてはいかがでしょうか。

近年、PHPの機能強化により型宣言だけで安全に書ける範囲が広まっています。

その一方でPHPStanやPsalmといった静的解析ツールはPHPでは表現できない強力な型を提供することでコード品質向上の価値を高めることが可能です。PhpStormはPHPプログラマに静的型の恩恵をもたらした一方、先述のツールと比べサポートする型について見劣りする点がありました。
ところが最近リリースされた待望の新バージョンである2021.2はこれまで静的解析ツールの専売特許だった型のいくつかがサポートされるようになり、型検査だけでなく入力補完などの恩恵を受けられるようになりました。そこで追加された型のひとつがジェネリクス（総称型）です。

本発表では、PHPの型についての基礎知識（今日からできる安心型付け入門）があることを前提として、PHPにジェネリクスは入るのか？の内容を軸に、PHPの型宣言では現時点で賄えない部分、特に配列の型およびジェネリクスの概念、class-string型の概念、そしてジェネリクスを実際に活用するためのテクニックを説明します。

Discord Channel: #track2-4-php-type

AWS Lambda の新機能としてコンテナイメージのサポートが開始されました！

PHPerがサーバーレスラーになれる！嬉しくてたまりませんね！

じゃあどうすれば良いのか、具体的なデプロイ手順をライトニングなトークでお話します！

デプロイさえ出来ればあとはあなた次第、
めくるめくサーバーレスライフを堪能しましょう！

■想定する聴講者
　- サーバーレスアーキテクチャに興味がある方
　- とにかくPHPをサーバーレスで動かしたい方

■お話しないこと
　- Productionで利用できるようなためになるお話
　- 細かい理論

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

ではどうすれば良いのか

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

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

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

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

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

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

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

なんとなくやってるパフォーマンスチューニング、
チューニングを行うとPHPWebアプリケーションはなぜ速くなるのでしょうか。

意識的に作った遅いアプリケーションを使い
OS、Webサーバー、PHP、RDBMSが遅い原因を知ることで、
遅くなった原因を一つ一つ分解して解説します。

パフォーマンスチューニングを行うに当たり必要な基礎理論を見直し、
なぜ遅いのかを知り、どうすれば速くなるのかを知ることで、
具体的なチューニングをなんとなくではなく、意志を持って選択出来るようにしましょう。

■想定する聴講者
　- PHPWebアプリケーションのパフォーマンスに興味がある方
　- PHPのインフラを整備するエンジニア
　- なんとなくオススメのチューニング設定を貼り付けてる方

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

Discord Channel: track2-3-a-php-performance

話者はPHPerですが、なんとなく全部出来るからという理由で
渡されるインフラの整備に疲れている時期がありました。

そんな中メンテナンスフリーと言われてきたサーバーレスという技術に興味を持ち
今では全てがAWSのマネージドサービスにて構成されているアプリケーションを作成する術を身に着けました。

それは話者の悩みを全て解決するものではありませんでしたが、
本来解決したかった以上の課題を解決し、初期認識よりも出来る事の幅の広さも感じました。

PHPerがフルサーバーレスアプリケーションを構築出来るまでに至った軌跡をなぞり、
メンテナンス、コスト、疎結合化などのメリットやデメリットについてお話します。

■想定する聴講者
　- サーバーレスアーキテクチャに興味がある方
　- サーバーレスアプリケーションの開発フローに興味がある方
　- サーバーコストを最小化したい方

■お話しないこと
　- PHPを中心としたアーキテクチャ
　- 完全なメンテナンスフリーインフラを手に入れる事

コンテナは便利、開発環境の構築から本番の運用まで様々なメリットがあります。

そんな中Dokcerを使った開発を行っている中で発生する、
パフォーマンス問題などのデメリットが存在するのも事実です。

今回はパフォーマンス、テスト実行まで意識した
Dokcerの開発環境整備について解説したいと思います。

不便な点もあるけど便利だから我慢しているという方に
少しでも快適なDokcerライフを送って頂ける一助になれば幸いです。

■想定する聴講者
　- Dokcerを使って開発しているPHPer
　- CircleCI等を使ってCI/CDを回している方

■お話しないこと
　- ProductionへDeployするためのテクニック
　- Windows、Macにおける細かな違い

2021年8月に開催された「ISUCON11予選」に参加してきました。
GopherやRubyistが巣食う予選で、PHPerはどれだけ成績を残せたのでしょうか...！

本トークでは、予選に参加する過程で生まれたエピソードや成果をご紹介します。

例えば、以下のような話題を扱う予定です。

• 予習って何をやった？
• 過去問って docker-compose でPHP参考実装が動かないじゃん！ぷんぷん！！！
• 過去問ってどんなフレームワークで書かれてるのか調べてみました！

私はこの数ヶ月、趣味プロジェクトとして、1990年代にアーケードゲームやハイエンドパソコンで輝きを放ったYAMAHAのFM音源チップ、YM2151を制御するためのハードウェアとソフトウェアの開発をしています。

こう言うと難しく聞こえるかもしれませんが、実はハードウェアの世界にも私たちソフトウェアエンジニアが「API」や「プロトコル」と呼びそうな決まりがあり、その決まりに従って音源チップに命令を与えることで音を鳴らすことができるのです。

このトークでは私が開発しているYM2151制御ハードウェア・ソフトウェアを題材に、コンピュータシステムの周辺ハードウェアがどの様に制御されるか、そしてその制御をソフトウェア的にどの様にするかを解説します。もちろん制御ソフトウェアはPHPで書いていますのでPHPerのみなさんであればスッと読めると思います。

このトークを通じてコンピュータシステムの動作について興味を持っていただく方が増えることを期待しています！

Discord Chanenel: #track3-5-b-php-hardware

• PHPerと言っていますがPHP関係なくサーバサイドアプリケーションエンジニア向けの内容です。
• MySQLとインデックスの話をベースに、仕組みよりは「理屈は置いておいてやり方」にフォーカスします。
  • 参考: 仕組みの話 ⇒ MySQLとインデックスと私 - Speaker Deck https://speakerdeck.com/yoku0825/mysqltoindetukusutosi
• スローログを出して、集計して、EXPLAINにかけて、インデックスを足す、のプラクティスを紹介します。
  • これの続きかもしれません: 片手間MySQLチューニング戦略 https://www.slideshare.net/yoku0825/mysql-80571224

目標は、「クエリーレビューで怪しげなSQLを先回りして直す」！

Discord Channel: #track1-4-mysql-index

ORM が高性能になり、SQL (クエリ) を意識の外に置くことも増えてきました
おかげでより開発効率も向上し、スピーディ・高品質なコードが書ける率も上がっています

しかし…アラートは突然やってきます
落ちるページ表示速度、上がる DB サーバー の Load Average
そして大量のスロークエリ

もちろん原因はこれだけではありませんが、僕らの日常では、1つのスロークエリが DB サーバーを停止させることも少なくありません
SQL は書き方次第で簡単に障害に繋がります

また、障害発生時、プログラムがどんな SQL を実行しているのか
実装した SQL は速いのか、遅いのか
それがわからないと、障害解析で困る場面も多いです

障害などの緊急事態を回避する以前に、品質の観点でエンジニアには日常的に以下が求められると考えています。

• スローログ監視
• スロークエリ解消
• スロークエリ予防

本セッションは、実例をベースに上記を説明しつつ「現場で使えるスロークエリの倒し方」を持ち帰っていただき、クエリ (SQL) チューニングへの敷居を低くすることが目的です
SQL 見よう！

障害の完全な予測は難しいです
だからこそ打てる手は多く持ち、できれば早めに打っておきたい
その手の1つとして、実際に行っているスロークエリの見方・倒し方・予防方法をお話しします

SQL はチューニングすることで品質の向上が可能です
PHPer であっても、SQL を日頃からチューニングしていきましょう！

スロークエリの見える化

開発当初は快適に動いていても、スロークエリは突然やってきます
では見える化はどうしたら良いのか、を

• プログラムレベル
• MySQL サーバーのログ（スローログ）

の 2 パターンで解説します

SQL の分析

スロークエリが見つかった場合に実行する主な内容を、項目別に解説します
普段の実装時・レビュー時にも実行することでパフォーマンス劣化の予防もできます

• EXPLAIN
• インデックス
• インデックス管理

SQL の追求

要求仕様、設計から立ち帰り、そもそもこれ必要なんだっけ？を徹底的に疑ってみることも重要です
では何を追求すれば良いのか？を実例をもとにお話します

改善対応の流れ

まずいスロークエリを見つけ、解決していくまでの流れを、2つの事例から解説します

• SQL そのものに問題がある場合
• 複合インデックスで解消できる場合

スロークエリ予防

普段から予防のために実践していることをお話します

• コード・設計・企画レビュー
• 勉強会
• ペアプロ

Discord Channel: #track2-2-mysql-tune

皆さんLaravelは使っていますか？私はここ数年Laravelを使ったアプリケーションばかり書いています。
Laravelでの開発を続けていると、やりたいことがドキュメントに載ってない！ということが結構あると思います。しかし、LaravelのIlluminateにはドキュメントに詳しく説明されていないInterfaceやLibraryがあり、これを実装したり継承したりすれば、かゆいところに手が届くということが多々あります。このような例を実例と合わせて複数紹介させていただきます。

「この機能をリリースしたらユーザーって増えるの？」

・・・・・・・・・

「〇〇したら☆☆になる」が100発100中でできる人がいたら申し訳ありませんが、プロダクトづくりにおいてなんらかの問いに対して正解を持っている人はいないように思います。
しかし、「誰も正解をもっていないものをそれでも形にする」ということがプロダクトづくりをはじめ我々の仕事では求められるケースが少なくないと思います。
プロダクトづくりの「不確実性」は日々新しい技術が出現したり、ユーザーが持つ課題が多岐に渡ったり、関わるチームメンバー・ステークホルダーが様々だったりなど様々な要因がそうさせるのではないかなと思います。
そんな中、少しでもプロダクトを前進させるためにできることは仮説を立てその検証をするというプロセスをいかに素早く回していくかというのが大事ではないかと感じています。
さらにそれは自分1人で完結できるものではなく、チームの力が必要です。
現在わたしの現場ではスクラム開発を取り入れプロダクト開発を進めておりますが、よりよいコミュニケーションでよりよいプロダクづくりをチームでするためにやっていること、工夫してみていることを共有させていただきたいと思っています。

普段我々が使っているコンピュータシステムというのは、階層的なシステムです。

物理法則から電気回路が作られ、ハードウェアが作られ、ハードウェアの上で動くファームウェアや OS があって、更にその上で動くアプリケーションがあって、アプリケーションの中でも C 言語で書かれた PHP 処理系、更にその上で動く PHP で書かれたスクリプト、というように、何重もの階層化がされています。
土台になるものから高く階層を積み上げていく、というイメージで、階層の上のほうにある技術を高レイヤー、下のほうにある技術を低レイヤーと呼んだりします。

PHP のスクリプトというのは比較的高レイヤーに属するプログラムなわけですが、PHP コードがコンピュータ上で実際にはどう振る舞っているのか、どういう仕組みでできているのか、というのは、当然より低レイヤーの技術で成り立っています。

今回のセッションでは、そんな PHP より低レイヤーの世界へ FFI を通じて PHP スクリプトからアクセスし、PHP 自身から階層をぶち抜いてスクリプトの動作を下の方から覗き見てみるという、少しひねくれたことをやるツール、php-profiler についてお話します。

雑に言うと、PHP スクリプトによって ELF/DWARF と procfs と ZendEngine の内部構造体をパースしつつ、FFI で外部プロセスのメモリやレジスタ内容を読み取り、gdb などのデバッガと同じようなやり方で、スクリプトの動作を処理系の内部動作レベルから盗み見るお話です。

ある瞬間に PHP プロセスが PHP コードの何行目を実行しているのか、どんな処理系内部のバイトコードを実行しているのか、そしてそのために処理系や拡張モジュールの C 言語コードのどの部分の何行目が実行されているのかを、観察対象の PHP スクリプトへ全く手を入れないままに読み取ります。

みなさんの現場では1on1は行われていますでしょうか？
わたしの現場では2週間に1回の頻度で1on1を行ってきました。
1on1回数を重ねていくごとに、エンジニアリーダー的な立場でメンターとしてメンバーと1on1を行っていた場合は、「この1on1は相手にとって有意義なものになっているのだろうか？わたしの自己満足になっているのでは？」と思うようになったり、逆にわたし自身がメンティーとして上長と1on1する際には「自分にとってはいい1on1になっている気はするけど本当にそうだろうか？上長にとっても期待した1on1になっているだろうか？」と考えモヤモヤしていました。
1on1の実態がお互いに期待している効果を生み出していないとするとそれはとても残念なことであり時間も無駄になってしまいます。
一般的にはチームビルディングやコミュニケーションの促進のために行われる1on1ではないかなと思いますが、現場によっても多少のニュアンスの違いは生まれるでしょう。また、1人1人のメンター・メンティーが1on1に期待することにも違いがあると思います。
そのような期待値の調整をするために1on1のふりかえりを行っているのですが、このセッションではわたしの現場で1on1ふりかえりをどのようにやっているのかを共有させていただきたいと思っています。

トークの概要

Google Cloud Platformの Cloud Run をご存知でしょうか。
Dockerのイメージで起動し、PHPで書いたWEBアプリケーションが直ぐにデプロイされて公開できる便利なサービスです。

デプロイするだけで証明書付きURLが発行されたり、トラフィック量調整によるカナリアリリースができたりと、
ものすごく便利でものすごく強力なのですが、意外に皆さんご存知ではないのでしょうか？
ということで、実際に現場で使っている感想も交えてCloud Runについてお話します。

トーク対象

• サーバレスでサクッとPHPを動かしてAPIを作りたい方
• サーバレスだけど、PHPのバージョンや自分で最新を維持したい方

分野

• Google Cloud Platform
• Cloud Run
• サーバレス

初めての登壇チャレンジです。 よろしくお願いします！

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

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

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

Discord Channel: #track2-3-b-php8-vs-v8

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

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

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

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