PHPerKaigi 2021 に登壇した

3/27 に PHPerKaigi 2021 に登壇した。 既に半年以上経過しており、時機を逃したのでもう記事にしなくても良いかなとも思ったのだが、紹介したいソースコードや個人的な反省など書き留めておきたいこともあったので、ブログを刷新したこの機会に読むことにした。

トーク内容

スライドは以下。

Laravel のメール認証の内部実装を掘り下げる - PHPerKaigi 2021 - Speaker Deck

Laravel のメール認証をテーマに、機能を拡張しやすいようにインターフェースを活用して依存関係を整理するアイデアについて紹介した。 オレオレ設計パターン的な要素が多分に含まれていることは正直否めないが、それでも設計パターンの具体的な適用例はあまり見かけないので、その意味で多少の価値はあるのかなと考えている。

ちなみにトーク中に紹介したコードを含むサンプルプロジェクトを GitHub に公開している。

hamakou108/laravel-separate-user-sample - GitHub

登壇前

実は上記のトーク内容は、プロポーザルを提出した時点の構想とは大きく異なっていた。

Laravel のメール認証をテーマに取り上げたきっかけは、仕事の開発プロジェクトでこの機能を利用したことだ。 その当時に利用していた Laravel 7.x のメール認証の機能は、その枠組みにそのまま乗るだけなら利用しやすいが、独自の機能を付け足すには厄介な部分があった。

具体的には、例えばルーティングの部分だ。 Laravel 7.x 以前だと以下のように Auth ファサードを使ってメール認証用のルーティングを作成することが勧められている。

Auth::routes(['verify' => true]);

これだけでメール認証を実装できるのは非常に便利だが、メール認証関連のパスを変更したり、独自にクエリパラメータを付け足したりしたい場合には Auth ファサードをそのまま利用するのは難しい。 そのためこのメソッドによってどのようなルーティングが定義され、そのルーティングに紐づいている Controller ではどのような処理を行っていて、さらにメールの署名はどのように作っていて...と内部実装を辿って理解する必要がある。 この過程を整理して発表するというのが、元々頭の中に思い描いていたストーリーだった。

しかし Laravel 8.x になってから、上と同じ処理は次のように実装できるようになっていた。

use Illuminate\Foundation\Auth\EmailVerificationRequest;

Route::get('/email/verify/{id}/{hash}', function (EmailVerificationRequest $request) {
    $request->fulfill();

    return redirect('/home');
})->middleware(['auth', 'signed'])->name('verification.verify');

Auth::routes を使わず、フレームワークの利用者がパスを定義し、必要なミドルウェアを設定し、コントローラーも自分で書いてね、という方針に変わっていた。 これが良い具合に抽象化されており、わざわざ内部実装を読みに潜らなくても直感的に機能を追加できるようになっていた。

このことに気づいたのはプロポーザルが通った後だったため、少し関心をずらして App\Models\User の責務を分離するという話にピボットしたのだった。 このテーマもそれはそれで面白いものの、結果的にトークのタイトルと内容がずれてしまった ^1 。 プロポーザルを提出する前に、フレームワークの最新バージョンの事情を把握しておく必要があったと反省している。

登壇後

自分にとって初めての20分登壇で不安もあったが、 Twitter や Discord などを通して想定以上に多くのフィードバックを頂いた。 Twitter のフォロワー数も急に10人くらい増えて、イベント登壇の影響力を感じた。

一方、トーク内容から具体的な議論に繋げることができなかったのは反省点だった。 トーク終了後に @kubotak さんから、「 Laravel ユーザーは玄人と素人の溝が大きい気がしている。玄人は通った道なので関心が薄く、素人は疎結合の良さがわからないので関心が薄そう。」とコメントをいただいた。 今回のイベントで個人的に面白いと思ったトークは、何が課題なのかを明確化し、そこから解決策の話に展開しているものが多かった印象がある。 自分のトークの内容を振り返ってみると、疎結合な設計というソリューションありきで出発しており、聴衆の方々が共感しにくい論理展開だったと反省している。

あと今回は資料作成に reveal.js を使ってみた。 スライドがぬるぬる動くので見栄えが良く、トーク終了後にツールに関心を持たれた方がちらほらいたようだ。

ただスライド作成は結構大変だった。 コードブロックの修正が必要になった場合、ハイライトの行番号を全て書き換えなければならず、この作業で結構な時間を消費した。 それなりに大きなコードブロックを見せたい場合、ライブコーディングする技術を身に付けた方が長期的には ROI が高そうだ。

またスライドを PDF に変換した時のデザイン崩れにも手を焼いた。 アスペクト比が 16:9 でないコンテンツが1ページに収まらない、スクロール可能なパーツは一部しかコンテンツを表示できないなどの問題があり、発表用スライドとは別に公開用スライドを否応なく用意する必要があった。

まとめ

PHPerKaigi 2021 の登壇の前後に考えたことについてまとめた。 反省点も多かったが、初めての20分登壇をやり切ったことは自信にも繋がった。 今後もコンスタントにイベント登壇を続けていきたいと思う。

登壇の機会を与えてくださったイベント主催・運営者の皆様、トークを聞いてくださった皆様、ありがとうございました。