あなたのアプリケーションでは外部APIを参照していますでしょうか。
あるいは、あなたの作ったAPIを開発者に利用してほしいと考えていますでしょうか。

外部システムをプログラミング言語から使いやすくするパッケージはSDK(software development kit)と呼ばれることもあり、HTTPリクエストの発行やPHPクラスへのマッピングが主な責務になります。

基本的にはマニュアル通りの設定をしてメソッドを呼び出して使えるようにれば最低限使えるSDKができますが、開発やテストのしやすさという観点ではそれだけでは不足です。

このトークでは開発者とSDKユーザーの立場から、2023年現在で考えられるSDKの理想形とテスト手法について手短かに紹介します。

キーワード

• PSR-7, PSR-18, Asynchronous request
• 🙅🏻‍♀️ 不用意にGuzzleに依存しない
• HTTPlug Discovery

本稿の前提となる議論についてはPHPからのHTTPリクエスト (2016年版)にも掲載しているので、予習にどうぞ。

伝えたいんです。オフラインのカンファレンスの素晴らしさを。

カンファレンスに行ったことがない人、初めて参加した人などからはこういった声をよく耳にします。

• 「カンファレンスってすごい人がいっぱい行くところでしょ？」
• 「私は全然技術力ないし、普段勉強してないから行っても何もわからないし…」
• 「興味はあるけど知り合いが居ないから1人で行ってもなぁ…」
• 「自分はコミュ力無いから話しかけるのとか無理だ…」

そんなとき、私はいつも
「違うんです…！すごい人ばかりが来ているわけじゃないんです…！」
「わからなくても大丈夫！1つ単語を覚えて帰ってきたらそれでいい」
「カンファレンスでの会話にコミュ力は必要ないのになぁ…」
と、思いながらカンファレンスの良さや、初めて参加する人へのアドバイスをたくさんの人に伝えてきました。

このトークはそんな方に向けて、学生時代に初めてカンファレンスに参加したことがきっかけで自分の人生が変わった参加歴6年のカンファレンス大好きな私が、様々なカンファレンスに参加し続けたことで得た「カンファレンス参加者として楽しむためのコツ」をたっぷり詰め込んだトークとなっています。ぜひ聞きに来てください！
また、カンファレンスジャンキーの方も、我々の仲間を増やすためにどういうふうに良さを伝えたらいいんだろう…と悩んでいることでしょう。カンファレンスへの誘い文句の参考になるトークをするのでご安心ください。

※このトークはPHPerKaigi 2023のアンカンファレンスで「カンファレンスで友達を作るコツ」としてLTした内容をブラッシュアップしたものです。

話すこと

• カンファレンスに参加するメリット
• 当日聞くセッションの選び方
• セッションを聞いたスピーカーに話しかけよう！緊張しなくて大丈夫、スピーカーは話しかけられたくてたまらないんだ。
• 参加者同士で話題にしやすいカンファレンスで話しかけるときの鉄板フレーズ集
• それでも話しかけられない？そんなときは〇〇に話しかけよう
• カンファレンスで出会った人との繋がり方、その後のコミュニケーション方法について

Webフロントエンドのテストは書けていますか？テストを書いたほうがいいのはわかっているけど面倒でサボりがち、UIを変更するたびにテストも壊れてしまうし、いずれメンテナンスされなくなるくらいなら最初から書かないほうがいいんじゃないか...そんな気持ちになったことがある人も多いと思います。
このトークではDOMのテストに特化したオープンソースのJavaScriptテストユーティリティライブラリ Testing Library を紹介します。
Testing Libraryのおかげで、これまで億劫だったDOMのテストは、むしろ真っ先に書きたいテストに変わるかもしれません。テスト駆動開発との相性も抜群です。さらに、Testing Library を使ってテストを書いていくとWebアクセシビリティの改善にも役立ちます。
普段あまりDOMのテストを書いてない人もDOMのテストに苦手意識がある経験者もぜひ知ってほしい、Testing Libraryの世界を案内します。

※本トークの内容は PHP に関連しません。

万人を虜にし、数多くのエンジニアを型に嵌めたフレームワークという存在。某WordPressをはじめ、全世界のアプリケーションインフラを支える大黒柱ではあるが、彼らも時代とともに変わっていく。

自分自身も毎年脱皮を繰り返す彼らを業務上で付き合っていく中で、四苦八苦することがあるが、果たしてどのように関係を保てばいいものだろうか。

コントリビューターたちの軌跡を常にキャッチアップするほど、我々に時間は与えられていないし、業務は待ってくれない。

業務を通して、かつ、フレームワークの複雑さや進化と付き合ってきた、僕なりの方法をお話します。

・Laravelを使った開発における注意点
・PHPUnitを用いた設計・実装における勘所

PHP は、気軽にウェブアプリケーションを作れる言語として、初心者から熟達者まで、人気のプログラミング言語です。
しかし、せっかく作ったウェブアプリケーションも、保守・運用で扱いにくいとレガシーアプリケーションとか、技術負債などと呼ばれます。また、PHP を忌避するエンジニア達も存在していて、レガシー化しやすいから PHP で新しいアプリケーションは作りたくないと評されたりもします。

しかし、保守性の高いウェブアプリケーションとなると、難しい設計論とかアーキテクチャーとかの話が出てきて、どうやっていいかよくわからなくなります。
なんとか、PHP の気軽さを保ちつつ、保守・運用がしやすいウェブアプリケーションを作ることはできないだろうか？
本トークでは、なるべく難しい設計論を避けつつ、どうやったら無難で、レガシーになりにくく、レガシーになったとしても何とかなるウェブアプリケーションが作れるかをまとめます。

本トークでお話すること

• レガシー化しにくくなる PHP ウェブアプリケーションの基本方針
• 明快で分かりやすい開発時の約束事
• 負債を生み出しにくい開発フロー・開発組織の仕組み作り

ログでてますか？当たり前ですよね、でてますよね。しかし「ログを出す」事については無頓着な人が多い印象があります。

過去、ログで助かった人も大勢いるのではないでしょうか？しかしながら、APMなどが発達した今においてはログなんて適当でよいや、とかなってませんか？あるいはなんとなく出すだけでリリースしたら見てないな〜ってなってませんか？

• ログなんて書いたことが無いな〜
• Apacheやphp-fpmのエラーログのこと？
• フレームワークについているロガーで十分だよ

そういった方々、今一度ログについてかんがえてみませんか？

あなたはちゃんとログを出していますか？

話すこと(予定)

• PHPの標準ログ機能は便利で複雑
• ログと割れ窓
• デファクトスタンダードのmonologはいろんな事ができる
• より運用に沿ったログとは？

近年のWebアプリケーションに求められるUI/UXはどんどん上がってきており、SPAアプリケーションを構築する機会が増えてきていると思います。
「フロントとバックエンドが疎結合！」という甘美な響きの裏には、スキーマ管理・リポジトリ運用・API認証など様々なオーバーヘッドが存在しており、
中小規模アプリケーションの場合はSPAはコスト高で選択肢から外してしまったことはありませんか？

Laravel8から登場したInertia.jsを使うと、これまでのBladeを使ったシンプルなレンダリングと同じ手法で、お手軽にSPA開発が可能になります。
Controllerから変数をセット、レンダリングするビューを指定するだけで、認証やスキーマなどを意識せず、JavaScriptページコンポーネントへとデータが渡りSPAとして動作します。

この構成をInertia.jsの公式サイトでは「現代のモノリス」と呼んでいます。
APIを構築せず、密結合な構成にすることで生産性の向上を提唱する新しいWebアプリケーションの開発手法の1つです。

このセッションでは、そんなInertia.jsの概要の説明と簡単なチュートリアルをしながら、
実際のお仕事に導入した際に感じたメリット・デメリットも交えてご紹介していきます。

話すこと

Inertia.jsとは
LaravelでのInertia.jsの使い方と例
導入して感じたメリット・デメリット

皆さんAPIシナリオテストを書いていますか？

単体テストでコントローラーまでは書くけれど、APIをE2Eテストは実際のクライアントから叩いたり、curlで実行する方が大勢かと思います。
E2Eテストを書くのは色々ハードル高そうというイメージで諦めていませんか？
確かにフロントエンドを含めたE2Eテストは実装と維持が凄く大変です。
そこでAPIにフォーカスしたテストに絞ってみて書き始めてみることをオススメします。
個人的に非常にコストパフォーマンスが高いテストだと感じています。
このセッションではAPIシナリオテストを導入検討して導入してから感じたことを紹介したいと思います。

1秒間に PHP が受信する HTTP リクエストが最大 10,000 回以上———

そんな世界が存在します。その一つが 「ソーシャルゲーム」 です。メンテナンスが明けた瞬間、イベントが始まった・終わる瞬間、様々なタイミングでゲームサーバーは瞬間的に高負荷になります。もちろん、サービスをリリースし PR をたくさん出し始めたその瞬間が、プロジェクトで最も高負荷となるでしょう。それらに耐えうるサーバー構成が求められていますが、「リリース直後にサーバーがダウンした」「限定イベントが始まったらすぐ緊急メンテナンスが始まった」という話はちょくちょく聞こえてきます。その 瞬間的な高負荷(いわゆる "スパイク") を耐えるには、事前準備を怠らないことが重要です。
ソーシャルゲームにおいては、他の Web アプリケーションに比べ 書き込みヘビーなワークロード であることが多いです。読み込みは比較的簡単に分散出来ますが、書き込みを分散することは容易ではありません。
そういった要件を達成するため、私のチームで行っている、 Laravel による高負荷を耐えるサーバー設計をご紹介したいと思います。

ターゲットユーザー

• 高負荷案件でも Laravel は使えるの？と疑問に思う方
• どのようにスパイクをさばいているのかを知りたい方

概要

プロダクト開発激化時代において、 より魅力的で競合優位性のあるプロダクト開発をしていくために組織育成は必要不可欠であり、その中でも特に育成が重要であること。
開発組織の開発力、生産性を上げるために避けては通れないエンジニア一人ひとりの技術力アップをどのように推進しているか。
私がEMとしてここ数年考え実践してきたエンジニアの教育において必要な要素や考え方について整理して話します。

トーク内容

プロダクト開発におけるエンジニア教育の効用
良いプロダクトを作るために必要な組織の特徴
組織を作るために欠かせない採用と教育
エンジニア教育する際のマインド、モチベーションをいかに引き出すか
質とスピードはトレードオフでは無いが、成長機会とトレードオフである
表面的なスキルからより基礎、より根幹のマインドが大事なワケ
レベルごとの教育スタンス（ティーチング、コーチングの使い分け）
教育にまつわる理論（認知特性やラーニングピラミッドを活用する話）
カンファレンスでしか得られない栄養
個のスキルから組織のスキルへの転換の仕組みづくり

想定視聴者

組織のエンジニア教育にミッションを持ち悩んでる人
エンジニアとして今後の成長方針に悩んでる人
教育に興味がある人

補足

本セッションは https://tech.willgate.co.jp/entry/2022/12/24/113000 に投稿したものを加筆し、よりブラッシュアップしたものになります。

含まれないもの

エンジニアに必要な個別技術の習得方法
エンジニアとしてどのような個別技術を学ぶべきか

ソフトウェア開発において、私が重要だと考えるアプローチは「可能性を狭める」というものです。例えば、型宣言を指定して値が取り得る範囲を絞り込みます。これにより、コードを読む際に考慮しないといけない範囲を限定できます。これは認知負荷を下げることに繋がり、引いては読みやすいコード、変更しやすいコードにできます。さらに、宣言する型を独自に定義した型にすることでその範囲をより狭くできます。こうした型による制約は、静的解析ツールや PHP ランタイムによって機械的にチェックされると言うのも大きな利点です。

一方、こうした制約を設けずに多機能なクラスを作成することで、可読性やメンテナンス性が低下し、問題が生じると言う経験をした人もいるのではないでしょうか。

このアプローチは、型システムだけでなく、クラスやモジュール設計、ソフトウェアアーキテクチャ、デバッグやパフォーマンスチューニング、自動テストなど、開発の多くの側面に適用可能です。

本セッションでは、特にまだ開発経験が浅い方や開発タスク自体はこなせるようになってきた方に向けて、今後さらに現場で活躍していけるように基礎となる考え方として知っていただきたい内容をお話しできればと思います。

私はtblsというツールを開発しています。

https://github.com/k1LoW/tbls

2018年にtblsはデータベースのスキーマ情報からドキュメントを生成するツールとして誕生しました。

そして、現在も多くの企業やユーザに使われています。

ある海外のサイトでは次のように紹介されました。

The project has been open-sourced for 5+ years, but the number of stars had a spike earlier this year. Anyone has any idea what happened in between?
（このプロジェクトは5年以上前からオープンソース化されているが、今年の初めに星の数が急増した。その間に何があったのか、どなたかおわかりになりますか？）

tblsは2018年から継続的に開発しており、まだ機能的な成長を続けています。

ところで、私はドキュメント運用のアプローチとしての"Documentation as Code"について考えてきました。その一部は https://speakerdeck.com/k1low でみることができます。

tblsはDocumentation as Codeを実現したツールの1つと言えます。そしてtblsは当時考えていたDocumentation as Codeの範囲を越えようとしています。

本セッションではDocumentation as Codeのその先について、tblsの今後の展開と共に共有したいと思います。

プロジェクトを成功させるためには、「効率よく仕事を進める」「手戻りや足止めの時間を減らす」みたいな事を頑張りたいですよね。
タスク間の依存関係をほぐしたり、属人性の高いタスクにスペシャリストが良いタイミングで着手できるように整えるのは、いわゆるプロジェクト管理といわれる領域の成果であり責務です。
それと同時に、いかにソフトウェアを設計するか？によっても、プロジェクト管理のリスクのコントロールに影響します。すなわち、設計次第で「手戻りやタスクのブロックを軽減する」ことに繋がるのです。
これは、突き詰めると「変更容易性」「開放閉鎖原則」で説明することが可能です。

このトークでは、「どのようにして、ソフトウェア設計の観点からプロジェクト管理の難しさを和らげるか」について共有します。
設計と、スケジュール管理と、チームによる分業を総合して考えることで、よいプロジェクト人生を手に入れましょう！！

話すこと

• 「どこから作っていけば良いのか」で考えるPJの進め方
• 「ハリボテ」を活用して、実装の意思決定を遅延させる
• それでも「後回しに出来ない実装」にチームで如何に立ち向かうか

主な参考書籍

• アジャイルソフトウェア開発の奥義
• ライティングソフトウェア
• 実践テスト駆動開発

Interfaceって...

• 具体的な実装が書けないし、何のためにあるのかよく分からない
• 先輩に言われてDIする時に使ってるけどなんでそうするのかはよく分かってない
• ライブラリとか作る人じゃないと使わないんじゃないの？
• Repositoryパターンの概念は分かったけど、実装を差し替えるなんてそうそうなくない？

そんな風に思っていたりしませんか？
私は思っていました！

このトークでは自称中級PHPerが上記のような状態を脱するきっかけとなった経験を元に、Interfaceの使い所や有用となりそうな場面などについてロガーライブラリのデファクトスタンダードであるMonologを題材に考察してみます。

このトークのゴール

「Interfaceよく分からない...」から「機会があれば使ってみようかな？」と思えるようになること

対象者

• Interface書いたことない方
• 書いたことあるけど、よく分からんという方
• 抽象とか部分型とか言われても分からん！もっと簡単に説明してくれ！って方

非対象者

• Intefaceバリバリ書いてるし理解してるぜって方
• 抽象とか型理論を肴にお酒が飲めるレベルの皆様方

最近LaravelのスターターキットであるLaravel BreezeにもTypeScriptサポートが追加されたように、LaravelにもTypeScriptを導入したフロントエンド開発需要が高まっています。
しかしTypeScriptでの開発を行っていると、Laravel側のコードと重複している箇所が多くあると感じます。

例えば

• 「Laravelのusersテーブルのカラム名が変更になった場合は、マイグレーションファイルを修正した後、TypeScriptのUserタイプも修正する必要がある」
• 「LaravelのEnumをそのままTypeScriptでも使用したい場合」
• 「Laravelのルーティングを修正した場合は、フロントエンド側のHttpリクエスト処理のURLも修正する必要がある」
• 「Laravelのバリデーションルールをフロントエンド側のフォームバリデーションにもそのまま適用したい場合」
  などです。

OpenAPI Specificationなどを利用してのフロントエンドコード生成やバックエンドのAPIテストを行うことでこれらの問題は解決されるかもしれませんが、APIスキーマファイル運用コストや開発速度の観点から採用が難しい場合もあります。
さらにInertia.jsなどそもそもAPIの送受信処理を省いてしまっている構成の場合にはこのようなAPI仕様書は有効ではありません。

そこで私はLaravelのModelからTypeScriptの型などを生成できるライブラリを自作し、ライブラリとして公開しました。
これを実際に業務でも採用しており、バックエンドとフロントエンドでの型共通化による開発の効率化やバグ防止に繋がったと感じています。
その他にもLaravelのバリデーションルールからTypeScriptのバリデーションライブラリZodのコード生成を行うライブラリを作成したりなど、バックエンドとフロントエンドでコードの重複をなくす取り組みを行っています。

本セッションではLaravel（PHP）のコードから型定義などのTypeScriptコードを自動生成する仕組みを導入することでコード重複問題を解決し、効率良く型安全なフロントエンド開発を行う手法を紹介します。

皆さん、技術的負債、返済してますか？
プロダクト開発も進めたいし、負債も返済したい、けどリソースは限られている！と思ったことはありませんか？ならば静的解析を使ってもっと効率的に進めよう！そう思ったことがある人、実行している人も多いのではないでしょうか。

私たちは元々PHPStan等のツールを利用していたのですが、コードの修正まで手掛けてくれるRectorも利用することで更なる効率化を目指そうとしました。標準ルールを使うことは容易に思えました。しかし、カスタムルールを作ろうとなった時にハードルがありました。

インターネットを探すといくつか情報が見つかります。ただ、説明がシンプルだったり、理解するのにある程度の知識が必要だったり、シンプルなルールを書くのにもちょっとした難しさがありました。よりスムーズに入門できるよう、もう少しハードルを下げたいと感じました。

このトークでは、Rectorに入門しようとする過程で整理したナレッジを共有します。
カスタムルールの書き方を理解する上での勘所があると私は考えています。理解を促すいくつかの視点、ルールを書く際に利用できるクラスやその探し方を提案したいと思います。
RectorはPHP Parserの上に成り立っています。これからカスタムルールを書いてみようという方にもとっつきやすいよう、基礎となるPHP Parserの仕組みにも触れつつ説明したいと思います。

誰向けのトーク？

• Rectorでカスタムルールを書くことにハードルを感じたことがある方
• 技術的負債の返済方法を模索している方
• 静的解析の仕組みに興味がある方

本トークの目指すところ

• Rectorのカスタムルールを書き始めるまでのハードルを下げる。
• それによりRectorを活用しやすくし、負債解消手段の選択肢を増やす。
• 静的解析の仕組みについて少し理解を深める。

2021 年 11 月、PHP の処理系と言語そのものの開発に一大転機が訪れました。

• PHP の様々な側面での近代化に関わってきたコア開発者 Nikita Popov さんの活動規模縮小
• それを契機とした The PHP Foundation の発足

The PHP Foundation は寄付を募り、PHP 処理系の実装と言語仕様の改善へ取り組むコア開発者へ資金を提供して、日中の仕事として PHP の開発を行えるようにする団体です。寄付が集まるほど PHP の開発が加速し、私達 PHPer がその恩恵を受けられることになります。
https://thephp.foundation/

すでに日本を含めた世界中から多くの寄付が集まり、The PHP Foundation によって雇われた数人の開発者によって、実際に多くの言語改善が成し遂げられました。このような PHP の開発事情をすでによく知っていて、所属会社からも寄付を行っている、という方もいれば、「PHP という言語自体の開発を生身の人間がやっていて、彼等がどう日々のご飯を食べているかが我々のビジネスに強く関係している、なるほどその発想はなかった」という方もいらっしゃるかと思います。

このトークでは The PHP Foundation の成り立ちと意義、これまでの活動内容をあらためて紹介し、「そういうわけで皆も会社のお金で The PHP Foundation に寄付をしよう！」というお話を、The PHP Foundation の関係者でもないのに外野から勝手に力強くやっていきます。

LT 枠でめっちゃ早口になって舌も回りきらずよく聞き取れない部分が多くなる可能性がありますが、その場のライブ感とともにパッションをぶつけるのがきっと大事なことなので、細かいことはあまり気にしない感じでやっていきます。

皆さん。
皆さんは型を書いていますか？
私は書いています。

なのに、いつの間にか型情報は消えているんです。
mixedになっているんです。
不思議ですね？

最近のPHPはバージョンアップのたびに型付けに対するサポートがどんどん厚くなっています。
それに合わせて開発環境が型情報をもとに補完候補を適切に表示したり、
静的解析によるチェックが高精度になり、
開発体験・開発速度が良くなっているはずです。

なのに、大切な型情報は消えてしまいます。
悲しいですね？

そこで、
どんな時に型情報が消えるのか、
どうやって回避するのか、はたまた回避は無理なのか。

主にLaravel・PHPStanとVSCode環境を例に最近の型にまつわる開発支援環境について発表します。

テスト初心者の皆さん、このような悩みを抱えていませんか？
・テストメソッドとテストデータが混在していて読みづらい
・テストの出力結果が見づらい
・テストの実行範囲を明確にしたい

このトークでは、PHPUnitのアノテーション機能を使って初心者でも可読性と保守性の高いテストコードを書ける方法を紹介します。
・@dataproviderを使ってテストケースをまとめ、再利用する
・@testdox × @dataproviderでテストメソッド名をよりわかりやすく表現する
・@groupを使ってテストをグループ化する

これらの機能は明日からすぐに使える簡単なものです。
アノテーションを活用し、見やすいテストコードでスムーズにテストを実行しましょう！

ChatGPTを使って、AWS上で簡単にサーバーレスアプリケーションを開発する方法を紹介します。
このセッションでは、結婚式やパーティーなどの余興に活用できる写真投稿アプリケーションを例に、ChatGPTとServerless Frameworkを使った構築手順を解説します。AWSに自信がない人でも、簡単にサーバーレスアプリケーションを開発できる、そんなChatGPTの活用方法をお話します。

内容
・サーバーレスアプリケーションとは？
・写真投稿アプリケーションの設計
・ChatGPTを使ってServerless Frameworkを用いてAWS Lambda、S3、API Gateway、DynamoDBなどをAWS上にデプロイする手順

対象者
・AWS初心者、特にサーバーレスアプリケーションに興味がある人
・ChatGPTを使ってAWS上でアプリケーションを開発したい人
・結婚式やパーティーなどの余興に活用できるアプリケーションを開発したい人