PHPerKaigi 2023 トーク一覧
ブラウザの向こう側で「200 OK」を返すまでに何が起きているのか調べてみた

「ブラウザでURLを入力してwebページが表示されるまでの仕組みを説明してください」
こんな質問をされたら、あなただったらどのように答えますか?
webアプリケーションを開発する上で、多くの技術的要素を理解していることが求められますが、
正直なところ現時点では上記の質問に対してうまく説明できるかは不安です。
この状況を踏まえ、普段何気なく利用しているブラウザの向こう側の仕組みについて、
自分なりに色々と調べてみて、当日の登壇では時間の許す限りその調査結果をお伝えしようと思います。
Win Testing Trophy Easily / テスティングトロフィーを獲得する

「Testing Pyramid(テスティングピラミッド)」皆さんも聞いたことがあるのではないでしょうか?
テストレベルごとにテストの量(数・実行)を上層ほど小さく下層ほど大きく(ピラミッド型に)すると良いというコンセプトです。
一方、React Testing Libraryの作者であるKent C. Dodds氏は「Testing Trophy(テスティングトロフィー)」というインテグレーションテストに最も重点をおいたテストコンセプトを提唱しています。
発表者はあるAPIサーバの開発にあたり設計時点でテスティングトロフィーを目指す決定をしました。
本発表では「なぜそれを目指したのか(選択したアーキテクチャからテストコンセプト決定まで)」「いかにそれを実現していったか(インテグレーションテストを軽量に追加する仕組みでコストに対抗する)」について紹介したいと思います。
サイボウズGaroon開発チームの「完成度低いの歓迎LT大会」(PHPerKaigi出張版)

サイボウズのGaroon開発チームでは「完成度低いの歓迎LT大会」を不定期に開催しています。
このLT大会の目的は、登壇のハードルを下げることです。
LT大会を重ねるうち、より登壇ハードルを下げるため「完成度の低さ」が歓迎されるようになり、完成度の低い発表は実況スレッドで褒められるように、逆に完成度の高い発表には「完成度が高すぎる」と指摘が入る現象も発生しました。
このスポンサートークでは、完成度低いの歓迎LT大会を開催することになった経緯とその成果についてお話しした後、
実際にGaroon開発チームの3名による「完成度低いの歓迎LT大会」をお届けします。
直に完成度低いの歓迎LT大会の雰囲気を感じ取ってもらえればと思います。
どうぞ本家のLT大会のように、完成度の低い点を褒め、完成度の高い点には指摘しながらご参加ください。
PHP/Laravelで実現する建設DXサービス「建設支援クラウドPhotoruction」の今
株式会社フォトラクションでは「建設の世界を限りなくスマートにする」というミッションのもと建設支援クラウドPhotoructionを提供して早5年超。
サービスの基盤の大部分はPHP/Laravelで実現されております。
我々の提供するサービスがどのような課題を解決しているか、またそれらがどのような構成で実現されており、日々技術的な課題に向き合い改善しているかを紹介させて下さい。
それらを通じて、皆様に建設DXの世界を少しでも知っていただけると幸いです。
PHPで任意精度演算を行って「正しい」金額計算をする方法

例えば消費税や販売手数料等の金額計算をしなければならなくなったこと、ありませんか。
var_dump(0.1 + 0.2); が何を表示するかすぐに答えられるでしょうか。
このトークでは、PHPで任意精度演算を行って「正しい」金額計算を行う方法について説明します。
なんとなくintやfloatを使って計算するのは、もうやめにしてみませんか。
想定対象者:
- PHPで任意精度演算を今までやったことがない人
- 任意精度演算という言葉を初めて聞いた人
時間を気にせず普通にカンニングもしつつ ISUCON12 本選問題を PHP でやってみる

ISUCON は「いい感じにスピードアップコンテスト」の略で、ほぼ同様の処理をするよう作られた Web サービスの参考実装が複数の言語で用意され、参加者は競技中好きな言語を選んでその性能改善をしていきます。2022 年に実施された ISUCON12 の本選参加チームには PHP は使われなかったのですが、参考実装はきちんと存在しています。
このトークでは ISUCON12 本選問題の PHP 参考実装を使い、時間制限を気にせず、本選参加者の感想ブログの取り組みを平然とパクりつつ、PHP でどこまでスコアが伸びるか試した際の知見をお話します。
PHP はサービスをいい感じにスピードアップするのには不向きなのでしょうか。Go のような本選常連組の言語にはかなわないのでしょうか。それとも、本選で良い成績を残した他言語の参加者と同じ取り組みをすれば、同じようなスコアが出せるものなのでしょうか。
防衛的 PHP: 多様性を生き抜くための PHP 入門

PHP は歴史の中で大きく進化し,PHP 7 からは本格的に型付けをサポートし,PHPStan や Psalm といった強固に型を静的解析するツールも生まれました.チームで PHP を用いて開発していると,型や静的解析の方針や方法に差異が生まれてしまうことがよくあります.しかし,安全に継続して開発をしていくためには,その手法を統一し体系立てて利用されるべきです.また,手法から外れて開発を行うプログラマからコードを防衛すべきです.
このセッションでは,そうした防衛的な手法を多く取り入れて,安全に,長く PHP を使って(バージョンアップに遅れを取ることなく)開発を続けていくための方法をご紹介します.
話すこと
- PHP 8 時代の型・型検査
- 静的解析・フォーマットと IDE
話さないこと
- 静的解析や型を取り入れるべきかどうかの議論
- きのこ派かたけのこ派かの議論
詳説「参照」:PHP 処理系の実装から参照を理解する

PHP における参照に似た機能は、他の言語にも存在しています。C のポインタ、C++ の参照、Java の参照型、C# の参照渡し……。しかしこれらは、それぞれ細かな点で PHP のそれとは異なっています。
PHP における参照を完全に理解すべく、1) PHP レベルでの挙動を観察し、2) PHP 処理系 (https://github.com/php/php-src) のソースコードを追いかけます。
対象: 重箱の隅をつつきたい PHPer、または PHP の language lawyer になりたい人。PHP 処理系は C で書かれていますが、C の知識は (あまり) 要求しないようにするつもりです
目標: PHP の参照を、実装レベルで完全に理解すること、また、php-src を少しだけ探索できるようになること
話さないこと: 参照のメリット・デメリットや使うべき場面
Composerを「なんとなく使う」から「理解して使う」になる

「composer install打ったらいい感じになるよね」「なんかDockerfileに書いてあるよね」
かつて私のComposerとの向き合い方はこのレベルでした。
しかし自サービスをコンテナ化するにあたり、Composerときちんと向き合い彼らとの絆を得ました。
本セッションでは「Composerってなんだっけ?」から入り、Dockerコンテナにおける取扱いまで触れていきます。
◆ 話すこと
基本的な役割
主なコマンド
composer.json?composer.lock?
いろいろな実行方法(コマンド・composer.phar・Docker Image)
Docker(コンテナ)とComposer(マルチステージビルド)
自サービスで最終的に採用した方法とその理由
◆ 想定する観客
Composerをなんとな〜くで使っている方
Docker環境でComposer使いたい人
PHP Parserで学ぶPHP
PHP ParserとはPHPのコードをパースするライブラリです。これは静的解析やコードの操作等に用いられます。例えば、PsalmやPHPStanがこれを利用しています。
そんな言わばPHPを最もよく知るライブラリからPHPのことを学ぼうというのが本トークのテーマです。
本トークではPHPを構成する要素に着目します。PHP Parserはコードをパースし、ノードと呼ばれる単位に分解します。静的解析はノードを一つ一つ読み取り、コードを解釈します。ノードは170種類以上あるのですが、それはPHPが多様な要素から成ることを物語っているように思います。
ノードの定義を読み解くことで、PHPにおける文や式とは何なのか、どんなバリエーションがあるのか、PHPはどんなパーツから成り立っているのか等を確認したいと思います。(また、その過程でPHP Parserについても少し理解できると思います。)
データの民主化はじめました 〜俺たちの民主化はこれからだ〜

概要
このセッションは、自社での「データの民主化」の過程でうまくいかなかったことから得られた学びと、
その学びをどう生かしているのかという話をします。
「データの民主化」と調べると、データ基盤の構築や、BIツールの導入、ダッシュボードの構築などの話が多くでてきます。
これらは大事なことですが、しかしこれらを作っただけではデータの扱いに慣れていない方には一向に広まらず、
一部の人しか活用できてないという結果だけが残ってしまい、これだけでは「データの民主化」にはならないということを学びました。
この学びから、アプローチを変え再度「データの民主化」に挑戦していると話をします。
話すこと
- データ基盤構築の話(ちょっと)
- 最初の導入でうまく広まらなかった話
- データの民主化のための泥臭い取組
話さないこと
- 使っているツールについての説明
安全にプロセスを停止するためにシグナル制御を学ぼう!

PHPのプロセスは非常に脆く、簡単に処理が停止してしまいます。
処理途中で切断され意図しないデータが残ったりするケース、皆さん誰しも経験があるんじゃないでしょうか?
シグナル制御を行うことで処理を安全に終了することができます!
- データをキレイにしてから終了する
- どこまで終わったかを通知してから終了する
- 処理が終わるのを待ってから終了する
本セッションでは、安全にプロセスを停止するためのシグナル制御について解説します。
Rector ではじめる "運用を止めない" PHP アップグレード

みなさん、 Rector は使っていますか?
近年 PHP を語る上で欠かせなくなりつつある各種静的解析ツールですが、中でも Rector は PHPStan に由来する静的解析のパワーを最大限活用し、コードを意図した形に変換してしまうパワフルなツールです。最近 PhpStorm も標準で対応するなど、盛り上がりを見せています。
今回はこの Rector を最大限活用し、実際にプロダクション環境の PHP を 7.4 から 8.1 にアップグレードしたときのお話をさせていただきたいと思います。
ふんわり使う PlantUML

情報共有には「正しい文章」もさることながら「図で示す」のも重要です。
手書きで図を描いたり作図アプリで記述しても良いのですが、ここでは PlantUML によるテキストベースで図を描く方法について注目していきたいと思います。
「UML」と聞いて「仕様や細かいルールがあって難しい・面倒くさそう」と思っていませんか?
全てのルールに従って「正しい UML」を書くことにはとても価値がありますが、一部のルールに従いきれていなくとも「図を示す」ことにも価値があります。
ここでは、PlantUML をがんばり過ぎずにふんわりと使った図の共有についてご紹介したいと思います。
想定対象者
- 図を使ったドキュメントの共有をしたい方
- 図の差分管理をしたい方
- Mermaid 以外の描画ツールを知りたい方
クローズドなサービスをIdentity-Aware Proxyを使って安全に公開する

■ 背景
サービスの管理用システムや社内専用システムはどの様にアクセスを制限していますか?
外部からアクセスができないよう会社のIPアドレス限定でアクセス許可を行う形が多いかなと思います。
しかし、これでは在宅勤務時など社外からアクセスできない弊害が……。
そこで、Google CloudのIdentity-Aware Proxy(IAP)を利用し、クローズドなサービスにどこからでも安全にアクセスできるようにします。
■ お話すること
・IAPを活用してサービスを守りつつ、安全にクローズドなサービスを公開していくための構成やポイントをお話します。
・IAPで認証されたことを前提に、パスワードレスで利用できるサービスとしたPHPのコードも交えてお話していきます。
■ 前提
・Google Cloudを利用した構成についてのお話です
・Googleアカウントを使った認証をベースにお話します
CodeCrafters にチャレンジして PHP で Redis を作ってみる

みなさんは CodeCrafters というサイトを知っていますか?
このサイトは少し複雑なソフトウェアを作りながらプログラミングを学ぶことができるサイトです。
このサイトではRedisやDockerコマンド、SQLite などの基本的な機能を作るような練習問題があります
Redisを作る課題にチャレンジしました。そこで学んだことを話そうとおもいます。
■話すこと
・CodeCraftersってどんなサイトなのか
・CodeCrafters で Redis を作る手順について
・Redisのプロトコル(RESP)について
■ターゲット
・PHPの基本的な文法はわかるけど次に何をするか悩んでいる人
・PHP以外の言語でなにか作りたいけど作りたいものがない人
パフォーマンスを改善せよ!大規模システム改修の仕事の進め方

『パフォーマンスを改善せよ!』突如下された指令...あなたはこのミッションをクリアしなくてはなりません。
しかし、「方法論を知っていても実施困難」「改善効果が測りにくい」「予測を立てづらい」などの様々な課題を抱えているのが実情です。
では、効率的に確実にこのミッションを遂行するにはどうすればよいのか?
すぱらしいソフトウェアのお医者さん、ロブ・パイクは言いました。「推測するな、計測せよ。」 なんかかっこいい。
このトークでは、この格言の通りにパフォーマンス改善に挑んだ実話を基に「効率的な正しいアプローチ」「パフォーマンス改善方法」をご紹介させてもらいます。
■話さない内容
・詳細なツールの使い方
・解析結果の読み方
■主な内容
・パフォーマンス改善方法の紹介
・パフォーマンス改善業務の進め方
・パフォーマンス改善の失敗談
サービスと共にチームも成長する〜New Relicを利用したサービスとチームの定量化〜

我々のチームではサービスのメトリクス監視であったり、パフォーマンス可視化にNew Relicを活用しています。
また、開発プロセスの改善や活動量からエンジニアを評価出来る環境作りのために、開発チームのパフォーマンスをNew Relicで可視化、活用しています。
本トークでは、サービスのパフォーマンス可視化だけではなく、開発チームのパフォーマンス可視化も行えるNew Relicについて、弊社の活用事例を時にはコードレベルまで掘り下げながら紹介させていただきます。
サービスや開発組織のパフォーマンスの可視化にご興味のある方々に響くトークをさせていただきます!
不幸を呼び寄せる命名の数々 ~君はそもそも何をされてる方なの?~
開発をしていると「この変数は何を表しているのだろう?」とか、「この関数は何をしているのだろう?」とか、一目見ただけでは何を伝えたいのかが分からない命名を目にすることがあります。
意図が伝わらないだけであれば調べれば済むかも知れませんが、時には命名が誤解を招き大問題に発展することもあります。
そんな不幸を呼び寄せる命名をあなたも知らず知らずのうちにしているかも知れません。
ここでは実際に私が見た「君はそもそも何をされてる方なの?」と言いたくなる命名の数々をご紹介し、命名の重要性を論じていきたいと思います。
PHPで構築したWordPressをObservabilityツールで見てみる

PHPで構築したシステムの監視運用について、お悩みはないでしょうか。
あるいは、「最近Obserbavilityという単語を耳にするけど、実際なに?」という方も多くいらっしゃるのではないでしょうか。
本LTでは、PHP-fpmでWordPressをAWS EC2上に構築し、
Obserbavilityの3本柱と言われるAPM, Log, MetricsがObservabilityツールの一つであるDatadogでどのように見えるかみてみたいと思います。
Obserbavilityの基礎から実際の見え方までお伝えできるよう、基本概念からお話し予定です。