トーク

あれ気付いちゃいましたか？
PHPerの皆さんがとっても仲良しのIDE、PhpStormくんのかわいさ（便利さ）に。

あ、まだ気づいてない（知らない）んですね！
じゃあこのLTを聞いてPhpStormくんを布教されてください！！
わたしの推しのPhpStormくんの超かわいいところ（超便利な機能）を時間が許す限り詰め込んで紹介します！！

例えば、私の推しポイントはこんな感じだよ！！

• コード書いててヤバそうなところあったら教えてくれるとこ超優しい🫶
• 一発でメソッド抽出したり、簡単にリファクタリングが出来るところ超かわいい🫶
• ファイルの外部で定義されている PHP クラスを参照すると自動で保管してくれて超カッコいい🫶

他にももーっといっぱい推しポイントあるから当日楽しみにしててくださいね！！！
PHP初心者の方にとっては新しい発見に、PHP玄人の方には新たなPhpStormくんの推しポイントに気がつくきっかけになれば嬉しいです！
かわいいのはアイコンのカラーだけじゃないんですよっ！

「デプロイ頻度」は開発生産性を測る重要な指標の一つです。
2、3ヶ月程度かかる大きめの機能開発で、機能をまるっと作ってからリリースしようとすると、このデプロイ頻度が落ちてしまう経験をした方は多いのではないでしょうか？
このようなとき、プルリクエストが肥大化しレビューが複雑になり、見落とされた不具合や障害が発生しやすくなってしまいます。

このトークでは、私のこれまでの反省を活かし、大きめの機能開発でもデプロイ頻度が高い状態を維持した事例を紹介します！皆さんの日々のチーム開発に取り入れられるよう、具体的なテクニックについて順を追って説明します。

話すこと

• 細かくデプロイするために必要な設計の工夫
• タスクを分割するには、インタフェースだけ先に実装してデプロイしよう
• テストコードが先に書いてあると安心して実装できる
• チームでデプロイ頻度を上げるために取り組んだ施策

新卒入社して2、3年後ぐらいで出来ることが増え、大きな機能開発も任されるようになったとき、設計をどのようにすればいいか分からない、大きい変更のタスク分割が難しいと悩むことがあると思います。
このトークではその悩みを解決するヒントを見つけられる(かもしれない)のでぜひ聞きに来てください！

「◯◯の機能について、ここをこうして欲しいんですよね…」
（◯◯なんてあったっけ、あれかな…）
「はいっ！できました！」
「それ、◯◯じゃなくて××だと思うんですが…」

みたいな経験を一度は皆さんはしたことはありませんか？

本トークではプロダクトに機能を追加するという開発業務の中に、「情報設計」というステップを追加した時に具体的に何をやったのかについてのお話をします。

みなさん情報設計という言葉を聞いたことはありますか？
PHPerのみなさんは普段からどういった情報を扱っていますか？

情報設計は、扱う複雑な情報を整理することでチーム開発をより円滑にすることが期待されます。

本トークでは情報設計という考えを実プロダクトの開発フローに組み込み、具体的に何をやってどんな知見を得られたかをお話しします。

また導入はしていないが、他の情報設計を開発フローに組み込むかの方法についても考察します。

PHP8.3ではOpcacheにも改善が入りました。php.iniを僕は雰囲気で使っていますが、これを機会にしっかり最高の設定を考えたい。本業でECSで利用しているphp.iniについて最高のパフォーマンスを出すためのPHP
にするための設定を考えます。

PHPerKaigiが行われる3月という時期では、php-srcの新機能どころか、バージョン番号すら話せるタイミングにないことが多いです。
それは一体なぜなのか、というと、リリースマネージャーすら決まっていないことが多いためです。

本セッションでは、3月ごろでは何が行われているのか、年末になるリリースに向けて何が行われているのかというスケジュールを俯瞰して見られるようにしてみます。

ISUCON（イスコン）？Iikanjini Speed Up Contest（いい感じにスピードアップ コンテスト）？なんだか難しそう……！！私はよく分からないし、すごい人ばっかり出てるし、いつか分かるようになったら出ようかな？
そんなことを考えていましたが、2023年11月開催のISUCON13に初参加してきました！
1人のPHPerとして、1人のエンジニアとしてISUCONに参加して人生の楽しみが増えました。

このLTは、ISUCONって何？練習はどうやるの？当日はどうだった？てか、PHPでもできるの？という、1年前のワタシに向けたISUCON初心者向けの解説LTです！

もしかして、ISUCON次回は参加してみたいかも……！！という勇気の後押しが出来たら嬉しいです！！

LTで届けたいもの

「ユニットテスト、あまり好きじゃねぇぜ〜」という人に、「少しお世話になってみようかな！」と思えるキッカケを！

前口上

「テストが苦手、抵抗感がある…」という人が、「テストって良いかも！」と言うようになった瞬間を目撃した事があるのですが、
そのキッカケは「テストがあると便利なんだなと思えた」ことだったそうです。

テーマ

「便利で助けになる」と感じられる場面の1つが、「実装を低カロリーに読み解く、知る」です。
例えば、フレームワークやライブラリの挙動を知りたい時。
「このクラスどう使うの？」「このメソッドの引数はどんな？」
──英語や日本語で書かれたドキュメント以上に、PHPで書かれたテストコードは、「こういう事ね！」を感じ取りやすいです。

特に、エッジケースや微妙な値(境界値や「引数が逆だったら」etc.)については
わざわざドキュメントに書かれないものでも、テストとして明確になっていたりします。
更に！ちょっと書き換えて動かして試す〜なんて事も可能に・・そう、テストならね。

実例を交えて説明しますので、「積極的にテストに絡みに行ってみよ☆」となっていただきたい。
そんなLTです。

話すこと

• Test as Documentationの威力を知る
• 「コードに関する疑問を解いてみる」の実例
• テストを「使う」際のコツ

WordPressが好きなエンジニアがいるでしょうか？いいやいない。と反語を使いそうな勢いで、エンジニアは嫌いだという方を多く見ます。
もしかしたら、そんな中で良いところや悪いところを整理できていないかもしれないと考えました。
(ああぁ！！！！と叫びたくなる衝動を抑えて)冷静にWordPressの良いところ、悪いところを整理して発表します。

ジュニアエンジニアが多く、テックリードがあまりいないかも・・・？そんな環境でお仕事した方々はいないでしょうか？
ジュニアエンジニアの方々はすごく頑張ってくれているので、しっかりレビューしたいけど、する時間がない！
やるならできれば自分が本当に必要なレビューだけ頑張れるようにしたい！そう思っている方々も多いことでしょう！特にLaravelなら！！！
そんな時に僕がやっていたCI/CDを公開しつつ、何を考えてそのようなことをやっていたのか？についてお話しさせていただきます！

今までサマータイムとタイムゾーンについて雰囲気でやってきていませんか？僕は少なくとも雰囲気でやってきました。
実際そんなに困ることねーし・・・！とそう思っていたそのとき！困る時がやってきます・・・。(震え声)
RFCなどを追いつつ、PHPの実装をどうするのか？といったところまでふかぼっていきます！

TechTrainというエンジニア教育のサービスを3年ほどECSで雰囲気で動かしてきました・・・。
バッチの処理についてはWebサーバー全く分割されておらず、サーバー負荷が高まると落ちる可能性もあり、落ちたかもわからない。そんな状況でした。
よくある移行ではあるものの、詳細が話されることがなさそうな、ECSのTaskをECS Task Scheduleにバッチ処理を移行し、移行した際に困ったことや実は公開してなかったけど、起こっていたことをお話しします。

このトークではPHP Parserを利用して静的解析ツールを作る話をします。

題材は簡易的な依存可視化ツールです。クラス間の依存の方向、数、深さからコードの複雑さを認識すること、バッドスメルを察知して設計を見直すこと等を目指すものです。

静的解析はコードを隅々まで見渡し、人が認識しにくい気づきを与えてくれます。これを活用しない手はありません。しかし、静的解析だの抽象構文木だの小難しく敷居が高く感じられるかもしれません。

このトークでは、具体例を通じて静的解析というものの解像度を高め、より身近に感じられるようになることを目指します。
また、実装する際の思考過程や設計判断に触れつつPHP Parserをどのように使ったのかを説明し、静的解析を知ることを通じて解析対象であるPHPの理解を深めることも目指します。

PHP、静的解析の仕組みや付随する設計に触れ、日頃の開発にいかせるヒントを見つけていただけたら幸いです。

スキーマ駆動開発は非常に強力な開発手法です。

• API仕様とサーバ実装が確実に一致し、クライアントライブラリは自動生成されます。
• フロントエンドは型システムの力により、「サーバ」を意識せずに開発が可能です。
• 「APIの繋ぎ込み」タスクや結合テスト時の問題切り分けが不要になります。

なるほど、完璧な作戦っスね―――ッ
不可能だという点に目をつぶればよぉ～

スキーマ駆動開発はしばしば「辛い」と言われます。

• スキーマと実装とをそれぞれ書かなければいけません。
• 開発中の変更がフロントエンドのCIを予期せず壊すことがあります。
• 破壊的変更を避けるために類似のエンドポイントが乱立しがちです。
• 実際には、仕様と実装が常に一致しているとは限りません。

これらの課題をLaravelおよびLaravel OpenAPIを使用して解決します。

• ライブラリの機能を活用し、スキーマと実装との二重化を解消します。
• 仕様と実装との不一致を自動的に検出します。
• フロントエンドのCIを壊さないスキーマの運用を行います。
• そもそもスキーマ駆動開発とは何かを解説します。

これまでOpenAPIやスキーマ駆動開発に苦労したことのある方はもちろん、これから導入を検討している方々にとって有益な内容です。

Laravel開発でのフロントエンドとしても使用されるVue/Reactは、コンポーネントを分割して開発する手法が多く取り入れられています。
その際、コンポーネント単位での開発を可能にするStorybookを活用し、コーディングはもちろん、Visual Regression TestやUIレビューのような、コーディングの先の運用についても活用してみませんか？

このLTでは、Storybookの開発元であるChroma SoftwareのSaaS「Chromatic」について、下記リストに挙げられる、実際に導入して得られた知見について共有します。

対象の方

• Storybookをもっと活用したい、という方
• VRT入れるの大変そうで手を出せてない、という方
• イケてるSaaSを入れたいけどセキュリティ or コストの面で自社への導入を躊躇している方

本トークを通じて、Chromaticを導入することのメリットと、導入ハードル突破の知見を共有し、Storybookをもっと活用し、フロントエンド開発をもっとスピードアップする方法を紹介します。

みなさんはこういった経験が無いでしょうか。

「PHPStanのレベル5まで対応完了！よしっ！」
「つづいて、レベル6っと、ッターン！」

Method xxx() return type has no value type specified in iterable type array.

「えぇっ！？」

このように対応レベルを上げた際、新たなエラーに直面した経験が誰しもあると思います。
特に、レベル6の型ヒントの欠落を報告での対応から厳しくなる印象です。

そんなとき、こう思った人も少なからずいるのではないでしょうか？

「PHPStanはLevel6で何を見ているのだろう」 と。

本トークでは、そういった疑問をコードリーディングを交えつつ、みなさんと一緒に解き明かしたいと思います。
PHPStanが見ている世界を知ることができれば、PHPStan(ひいては静的解析ツール)ともっと仲良くなれるはず！

■ 話すこと

話す内容としては、まずPHPStanのレベルについて概要を説明し、その後、レベル5とレベル6での解析方法の違いや、
字句解析や構文解析、評価などの基本的な概念について触れていきたいと思っています。

■ ターゲット

• PHPStanの対応(特にレベル6)で苦労したことがある人
• PHPStan(静的解析ツール)と仲良くなりたい人

私の所属する株式会社リンケージは、CTOの曽根壮大をはじめPHPコミュニティに関わりの深いエンジニア社員・業務委託が多く働いています。

私は、エンジニア社員に誘われたのをきっかけに、今年の6月に福岡で開催されたPHPカンファレンスに参加してみたのですが、あまりの楽しさと魅力に感動しました。
その結果、その後に開催された沖縄、東京の両方のカンファレンスに参加したり、Xを通してPHPerの方々と交流したりと、もはやPHPerと言っても過言ではない（！）くらいの日々を送っています。

私自身はPHPのコードを書くわけではなく、職種は事業開発出身のプロダクトマネージャーです。
傍から見ると、PHPコミュニティに入っていっても、話している内容も分からないし、うまく交流できないのではないか？と思われるかもしれません。
私がなぜ積極的にPHPのコミュニティに入り込んでいくのか、その理由を「非PHPer」「非エンジニア」という稀有な視点から熱くお伝えします！

◆主な対象者
・PHPコミュニティの魅力をPHPerの外にも広げたい方
・PHPコミュニティの魅力をより知りたい方
・知り合いをコミュニティに誘うための謳い文句がほしい方

◆主な内容
・カンファレンスへの誘い
・PHPerとの出会い
・懇親会という楽園
・Xという理想郷
・PHPerとの出会いをきっかけに変わり始めた人生

このセクションではリアルなLaravelのプロジェクトを例に、ドメインイベントを用いてどうやってコードをすっきりさせるかをナビゲートします。

テストも楽チンになるし、コードも再利用しやすくなるような、ちょっとした工夫を伝授します。

リファクタリングって難しそう？

いえいえ、このセッション後は、もう怖くないですよ。

Laravelとともに、もっとコードライフを楽しみましょう！

例外はただのトラブルシューターじゃありません。コード内の誰が何を担当するのかを教えてくれる、責務の指針なんです。

『PHPの例外、多すぎてどれ使えばいいかわかんない！』『例外、いつキャッチすればいいの？』『エラー情報、どこに吐き出すのが正解？』こんな疑問を持ったことはありませんか？

PHPの組み込み例外クラスの選び方から、自分で独自例外を定義するノウハウまで、コードをもっと読みやすく、管理しやすくするための実践的なアプローチについて考察してみます。

例外をマスターして、エラーハンドリングをもっとスマートに。

私たちが古くなったPHPアプリケーションをRuby on Railsに移植することを決断したのが2016年―。
私たちが移植対象としたPHPは下記のようなものです。

• とっくにEOLなPHPバージョン
• オレオレ・独自フレームワーク
• 標準サポート終了しているAmazon Linux AMIなEC2サーバー
• PEAR/PECLなライブラリ管理
• 自動化されていないテスト・デプロイ
• 仕様ドキュメントほぼ無し（ソースコードが仕様書）
• 担当プロダクトオーナー不在

過去に本PHPアプリケーションの移植プロジェクトは断続的に立ち上がっていたものの、それらは局所的な移植として終わってきました。
2022年、この戦いに終止符を打とうと本格的な移植プロジェクトが再始動、ついに2023年、移植を完遂しました。

本プロジェクトは正直、カッコいい移植プロジェクトとは言い難いものです。
そんな泥臭く長い移植の軌跡を、技術的負債解消の一事例としてお話できればと思います。

想定聴講者

• 技術的負債の解消に興味がある方
• 現在進行系で技術的負債と闘っている開発者

話すこと

• なぜ移植するか
• どのように移植を進めたか
• 移植前後の改善結果
• 移植後も山積する課題と今後の展望

話さないこと

• ナウい技術的負債の解消方法
• 移植後のシステムの技術的詳細