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の今後の展開と共に共有したいと思います。

最近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を活用しやすくし、負債解消手段の選択肢を増やす。
• 静的解析の仕組みについて少し理解を深める。