2024/07/30 Matt Stauffer x Taylor Otwell

Laravel Podcast Episode 14

https://www.youtube.com/watch?v=VVKxu_KzG1g&t=1722s

Laracon US

Taylor)
今の所準備は順調。会場には950人が来る。今までで最大のLaracon USになる。
最近SNSで私が静かなのは、Laraconの準備で忙しいから笑
多くの大きい発表があるから、少し緊張もしているけど、楽しいものになると思う。

Matt)
Taylorが登壇するのはいつ？

Taylor)
8/27の最後に話す予定。
Livewireは他の人が話すけど、inertiaの話は私がすると思う。あと他のオープンソースのものの話とか、新しいプロダクトのこととか。

Laravel Nova とFilament

Matt)
Laravelで管理画面を作るパッケージとして今まで色々なものがあったけど、Laravel Nova とFilamentが2大勢力になっているように思う。
そして2つのパッケージには共通点と相違点があるよね。
Novaの将来はどうなるかな？そして、NovaとFilamentについてどのような考え方 (メンタルモデル)が関連している？

Taylor)
Novaの始まりについて話すと、2017年ごろ、David Hemphillという人物が私に「Laravelのための管理ツールのプロトタイプを作った」と提案してきたんだ。
その時はBeamと呼ばれる、Bladeだけで作られたもので、基礎的なリレーションや項目の更新をするやつだった。
私は「これはクールだけど、TablePlusとかSQLproでやれば良くない？」って感じだった。
そしたら彼は「時々SQLクライアントでやるには面倒な独自の操作をしたい時があるでしょ」と言ったんだ。
だから、私にとってNovaの背後にあるアイデアは基本的にTable PlusとかPHPMyAdminに独自のアクションがついているようなイメージなんだ。
アプリケーションを作るためのツールではなくて、開発者やクライアントがデータの編集をしたり閲覧するためのもの。エンドユーザーのためではなくてね。
Novaの現状としては、Novaのために働くフルタイムの開発者をちょうど採用したところなんだ。
そして、Nova 5のリリースのために準備をしていて、LaraconUSで少し発表できるかもしれない。
タブとかフィールドパネルとか新しい項目の追加とか。でも、ツールの哲学を変えるものではないよ。
そして、Filamentは最近Laravelコミュニティーの中でとても人気になっているけど、私の感覚では、Novaとは非常に異なったアプローチなんだ。
私とDavidはNovaをアプリケーション作成に使うべきではないと言って譲らなくて、多くの人が「Novaはカスタマイズ性が低い、拡張しようとしたけど意図通りにならない」と不満を感じていたとおもうんだけど、Filamentはそれに応えられると思う。
FilamentはNovaと同じようなスタイルの管理画面を作れるし、エンドユーザーが使う実践的なアプリケーションを作るのにも使える。
アプリケーション構築用のカスタムLivewireコンポーネントもあるし。
だから、NovaとFilamentは非常に異なったゴールを持っていると思うし、Filamentの方がずっと難しいゴールだと思うよ。それは私達がやりたくなかったことだから笑
それを達成するにはツールを柔軟でカスタマイズ可能にしなきゃいけなくて、それをメンテナンスするのは管理画面のみに特化したものをメンテナンスするより頭痛が絶えないことだよ。
そして私たちはNovaのWebサイトを更新したり、Aaron Francis(技術系インフルエンサー)にもNovaはアプリケーション作成用ではなくて管理画面用なんだと言ったりしてる。
人々にそう認識してもらいたいからね。管理画面を作るならNovaは最も早く作れる手段の一つだ。でも、アプリケーション作成ツールを探しているなら、Novaにはがっかりしてしまうと思うし、他の手段を探した方がいいと思う。
実はFilamentはこんなに人気になっているのにまだ使ったことがないんだ。だからFilamentについて語ることはできないんだけど、哲学的なゴールが異なっているというふうには思うよ。

Matt)
そうだね。NovaはFilamentよりスコープが狭いと思うんだ。そしてそこには利点と欠点がある。
私はNovaの「一つのことをうまくやれる」という利点を評価しているよ。
Novaを試したことはないんだけど、Filamentでアプリケーションを作ったこともないんだ。
使うとしたら管理画面用だろうね。でもFilamentはもっと大きく広いビジョンを持っていて、それは利点でもあるけど時にして害にもなるよね。
私たちはjQuery時代のようなJavaScriptのプラグイン戦争を見てきて、それは複雑になっていく。
もちろんFilament チームがその問題を避けるために全力を尽くしているのは知っているんだけど、あなたが言うように克服が難しいよね。そしてNovaは克服が必要ないよね。
Novaが継続してアップデートされてること、二つの大きい候補を持っていることを嬉しく思うよ。

Taylor)
そうだね。そしてFilamentにはとても感謝しているし、ただNovaとは異なるというだけなんだ。
FilamentのWebサイトに行くと、「次の"アプリ"開発に最適な出発点」と書いてあるんだ。そしてそれはNovaが言っていることとはとても異なっている。そう思うよ。

Matt)
そうだね。そしてどちらも試したことのない人のために言っておくと、二つを外側から見たときの最も大きな違いはFilamentはLivewireでNovaはVue.jsであることだね。

Laravel チームによるOSS Laravel プロジェクト

Matt)
TaylorやLaravelチームによって作られたオープンソースのLaravelプロジェクトはあるかな？
過去にはあったと思うんだけど最近あなたが書いたオープンソースのものはあるかな？

Taylor)
残念だけど、答えは多分「ノー」笑

Matt)
うん、それでも全然問題ないよ。

Taylor)
Laravel Octane等の近年リリースされたパッケージを見てもらうと私が書いたコードに近いものはあると思う。
私が書いた最新の商用アプリケーションはVaporで2019年にリリースされたもので、もちろんオープンソースではないんだ。Vaporはいまだにお気に入りのアプリケーションだよ。コードの品質とか気に入ってる。それを公開できたらいいけど、もちろんそれは出来ないよね(商用だから)。
でも、私は常日頃からLaravelでどうコードを書くかの例を公開できたらいいなと思っているんだ。
もちろん私の書き方と同じ方法である必要はないけどね。私は独自のスタイルだと思うし。
いつかそういったものを作れたらいいけど、他のプロジェクトで時間が取れない状況でもあるんだ。

Matt)
私はLaravelコミュニティーの人々の多様なプログラミングスタイルが大好きなんだ。
いつも言っているけどDDDの仲間がいたり、別の考えの人がいたり、そんな感じで。でも最近気づいたのが、イデオロギー的に似ている人々の間であっても多くの違いがあるんだ。
みんなLaravelを使っているんだけど、違っているんだ。まあ、一つの絶対的に正しいやり方なんてないってことなんだろうけどね。

Taylor)
うん。絶対ないね。
大きな哲学のようなものは共有していると思うんだよね。
Laravelはアーキテクチャの"宇宙飛行士"のような会社のように振る舞っていないと思うんだ。
これはちょっと失礼な用語の使い方だったかな。つまり私たちはただ座って一日中DDDをするようなことはしていないんだ。いい比較が思いつかないんだけど、強いて言えばJavaよりRuby on Railsみたいな感じというか。

Matt)
そうだね、とても簡潔にLaravelを使う人もいるし、より重厚にエンタープライズ向けに使う人もいるよね。
今までのPodcastで話していると思うけど、個人の趣向や色々な状況によって異なるよね。100人規模のチームなのか300個の異なるサーバにデプロイしなきゃいけなかったり。
これらの状況が異なるコードを作るよね。前話した「modularity」みたいな感じで。いろんな背景があってそのアーキテクチャに辿り着いているんだ。
一つの正解・不正解はなくて、これが「私たちのやり方」って感じでいいんだよね。

Taylor)
うん、それは多くのプログラミングのトレンドのコアとなる部分で、マイクロサービスだったりDocker, Kubernetesだったり。
これらは一定の大きさのチームのためのツールだよね。小さいチームにも有用かもしれないけど、チーム開発を低速化させる原因にもなるよね。小さいチーム向けには作られてないから。

Matt)
それに関連してbuiltwithlaravel.com(laravelを使っている会社のキュレーション)というサイトをちょうど作ったんだ。
Laravelを採用するか迷っているCEOに対してこのサイトを見せてもらって「え、この会社も使っているの？」というふうに思ってもらえたりするんじゃないかな。
そしてこのコードを公開しているんだ、Tightenだったり僕のコードが見られると思うよ。

TALLスタックはまだ有効か

Matt)
TALLスタックの中でAlpineはまだ重要かな？
Livewireに触れたりすることはある？

Taylor)
Laravel Pulseで使ったね。あれはLivewireで作られているから。
アプリケーション監視のための比較的新しいOSSパッケージだけど。
でもLivewireで作った商用プロダクトはないかな。それはLivewireがリリースされてから商用プロダクトを作ってないからなんだけど笑
君はどう？

Matt)
私たちはLivewireをたくさん使っているよ。私の会社には多くのVue, React開発者がいてそれらで構築されたアプリケーションがたくさんあるけど、非常にたくさんのクライアントはLivewireから恩恵を得られることに気づいたんだ。
なぜならクライアントは小さなチームでフロントエンドの人材がいないことがあるんだ。
こう言った時にLaravelとVue/Reactどちらも知見を持ったチームを作るよりはLaravelとLivewireにした方がハードルが低いんだ。
Livewireを気に入っているクライアントはいっぱいいるし、Livewireを使う時はAlpine.jsを必ず使っているよ。これが質問の答えかな。
前にLivewireのプロジェクトで酷い例を見たことがあるんだけど、そこではLivewireを採用したからLivewireだけで構成されるべきと考えていたんだ。モーダルを開く時、ページ全体が更新されて、モーダルつきの新しいLivewireページがレンダリングされるんだ。
ただモーダルを表示するのにAlpineを使えばいいんだけなのに。
Livewireを使うことはJavascriptを使うことを恐れることではないんだ。LivewireとAlpineはとても相性がいいよ。
Calebのコードやチュートリアルを見れば彼がいつもそうしていることがわかるよ。
正直に言えばAlpine抜きのLivewireは良いソリューションではないと思うよ。Alpineと一緒のLivewireは素晴らしいソリューションだと思う。

Taylor)
うん、私も「AlpineがLivewireに必要ない」とか「Alpineは良いアイデアじゃない」とかいう意見に同意したことはないよ。だから君の意見に完全に同意だ。
Alpineはとても素晴らしいよ。Laravelの外の人もAlpineについてそう言っているのを見るよ。

Matt)
そうだね、AlpineはVueの軽量な代替だと言っている雑誌や記事を見かけたよ。
個人的には、Livewireを使っていてJavaScriptが必要なとき、最初はバニラJavaScriptを使うんだ。昔よりずっと良くなっているからね。それでバニラJavaScriptでは対応が難しい時はAlpineを使うようにしているよ。
Alpineは完全なSPAコンポーネントのようなもの以外については非常にうまく扱えると思うんだ。
他のものだとこんなに簡単に扱えないと思うよ。

Taylor)
その通りだね。

テストを書くタイミング、フロント・E2Eテスト

Matt)
次はtestについての質問。
テストは最初に書く?それとも最後に書く？
また、duskのようなブラウザベースのテストやフロントエンドテストは使う？

Taylor)
普段テストを最初に書くことはしないね。コードを書いた後にテストを書くよ。
テストを先に書くことは滅多にないね。理由はうまく説明できないけどこのやり方の方がうまくいく気がするってだけ。
自分が書いたコードを後から確認できる感じというか。
ブラウザテストについてはLaravel Novaでは広範囲で使っているよ。ForgeやVaporのようなものについてはブラウザテストにあまり取り組まないね。テストを遅くしたり、メンテナンスを難しくしたりするから。だから可能なら避けようとしているよ笑
私たちは主にバックエンドのテストを書いているよ。フロントエンドのテストもそんなに多くは書かないね。実際のところ、たくさんのフロントエンドテストがなくても、それほど問題がないと感じているんだ。
私たちのテストの99%はバックエンドだね。

Matt)
うん、私たちも一緒だよ。
フロントエンドのテストを行うのは、シングルページアプリケーション（SPA）の場合がほとんどだね。
例えば、VueやReactでSPAを開発する場合には、Jestなどを使ってテストを書くよ。なぜなら、アプリケーションの大部分のロジックがそこに含まれているから。もちろん、バックエンドのテストも書くよ。コントローラーやAPIにもテストが必要なので、それは理にかなっていると思うんだ。
でも、SPAじゃなければ書かないし、duskも使わない傾向にあるよ。テストしたいユーザー操作の大部分はgetやpostの出力がどうかということだから、duskや他のツールを使う必要がないんだ。
そして、duskやフロントエンドのテストは少し不安定で速度も遅いし、バックエンドのテストほどどこでも実行できるものではないよね。
だから、私たちはできるだけ多くをバックエンドのテストでカバーして、もし重要なロジックがフロントにあったら、フロントエンドのテストを書くんだ。

Taylor)
うん、それは理にかなっていると思うよ。

Matt)
あ、それと私もテストを後に書く人だよ。TDDは素晴らしいし、TDDが有効な場面や自分がTDDを使うこともあると思う。でも、私がアプリケーションをつくるときのほとんどは、その場で何を作るか考えながら進めるんだ。だから最初に書くテストがないんだよね。まず機能を作って、それから安定化させるっていう形で進めるんだ。リファクタリングをする前にテストを書くかもしれないんだけど、テストが実装より先に来ることはないんだよね。

Taylor)
どうなんだろう。変な話だけど、最近は誰もTDDについて話さなくなった気がするんだよね。
あなたはどう思う？

Matt)
公にはあまり話されていないと思うね。

Taylor)
かつてはTDDやその他の概念について結構話されていたと思うんだよね。最近はあまり話題に上がらないよね。少なくともSNSでは見かけないな。もしかしたら私が狭い世界にいるのかもしれないけど笑
以前ほど重視されていないように思えるんだ。

Matt)
そうだね。クライアントが来たときによくあることなんだけど、話してる途中で『テストカバレッジどうなってる？』って聞くと、相手がちょっと恥ずかしそうな顔をして、『TDDやらなきゃってわかってるんだけどさ…』って言うことが多いんだよね。
それで、たまにテストカバレッジが全然ないってことを打ち明けたり、逆にめっちゃしっかりしてるってこともあるんだけど、どっちにしてもTDDやってないことを恥ずかしがっている感じなんだよね。
これはTDDを教えてる人を責めてるわけじゃないんだ。
TDD自体はすごくいいんだけど、かつて『これが正しいやり方だ』っていう大きな波があって、それからみんなあんまり話さなくなったんだと思うんだよね。
私も完全に同意するし、実際、私はその期待からみんなを解放しようとしてるんだ。
『TDDは私のコーディングスタイルじゃない』って公言してるし、だからこの質問がポッドキャストで取り上げられるのがすごく嬉しいんだ。
私が言いたいのは、少なくとも私たちのコミュニティではほとんどの人がTDDやってないってことなんだ。みんなテストはするよ。私たちもテストするし、テストはとても重要だ。
でも、TDDが絶対ってわけじゃないんだよね。TDDって結構大きなマインドシフトが必要だから、それが逆にテストをやりにくくしてるんじゃないかなって思うんだ。
だから私は『TDDをする準備ができたらやればいい。今はまず、コード書いた後にとりあえずテストをちゃんと書いて、それをどうにか組み込んでいくことが大事だよ』って言ってるんだ。

Taylor)
そうだね。
実際に、今まで一緒に働いた中で、書いたコードすべてにTDDを徹底的にやってた人っていないと思うんだよね。そんな人と働いたことないよ。君はどう？

Matt)
うん、私はアダム(TailwindCSSの作成者)と働いたことあるけど、彼もTDDを徹底的にやってたわけじゃないと思う。私が知ってる中では彼が一番TDDをやってたけどね。

Taylor)
聞かないとわからないと思うけど、TailwindはTDDで作っていないと思うんだよね。
もしかしたらやっているかもしれないけど笑

Matt)
うん、そうだね。彼は私が知ってる中では一番TDDをやってた人だよ。それに、アダムと一緒に働いてたおかげで、私もかなりテストが上手くなったんだよね。これははっきり言っておきたいところだね。
今もTightenにはTDDをやってる人がいるけど、誰一人として徹底的にやってるわけじゃないんだ。50%すらやってる人がいるかどうかも怪しいと思うよ。間違ってるかもしれないから、彼らにも聞いてみるつもりだけどね。

Taylor)
そうだね。私にとってテストで一番大きなブレイクスルーだったのは、適切な抽象レベルでテストすることを学んだことかな。
これはそれぞれが見つけるべきことだと思うんだけど、時々Laravelのフレームワークにプルリクエストが来ると、すごく過剰にモック化されたテストを目にするんだよね。
そういうのを見ると、何もテストされていない感じがして、ただモックを正しく設定しただけって印象なんだよ。だから、あまりモックを使わなくてもいい抽象レベルでテストすることを学んだのが、自分にとってテストが壊れやすいものじゃなくなった一番のポイントだったと思うんだ。

Matt)
うん、まさにそうだね。その通りで、テストってシンプルに見えるけど、実はすごく重要な要素があるんだよね。「コードがちゃんと動くか」をテストしてるのか、それとも「特定の方法でコードを書いたこと」をテストしてるのか、っていうニュアンスの違いは理解する必要があるよね。
そして、その話をする上でモックの使い方も重要な要素のひとつだよね。でもさ、もしコードが同じように動作していて、入力と出力が同じなのに、コードを書き換えたらテストが壊れるっていうのは、ちょっとヤバいサインだと思うんだ。
絶対に間違ってるってわけじゃないけど、たまにそういうこともあるけどね。
でもベストなテストは、入力と出力をテストしてるから、ちょっとコードをいじったくらいで壊れたりしないんだよね。もし、これを置き換えて、これが呼ばれて、これが動いてっていうテストだったら、それはあんまり良くないテストだと思うな。

PWA

Matt)
次の質問はPWA（プログレッシブウェブアプリ）に関するものだね。知らない人のために説明すると、PWAはiOSやAndroidのアプリストアで配布されるアプリのような機能をウェブアプリでも実現するための技術なんだ。
例えば、インターネット接続が切れても動作を続けたり、カスタムアイコンを持ったりして、ウェブベースのアプリケーションがモバイルデバイス上でネイティブアプリのように動作するようにするんだ。
昔からこれは素晴らしいアイデアだと思われていたんだけど、Appleがそれを妨げる最大の要因だったんだ。でも最近、Appleも少しサポートを始めたから、話題になってきてるんだ。
この人が言っているのは、Rails 8でやっているように、LaravelにPWAの明確なサポートを追加する計画はありますか？という質問なんだけど、正直言うと、PWAについては私も追っていたんだけど、最近Railsが何をしてるのかは追ってなかったんだ。
だから、もしあなたが知らなければ、この話題はスルーしてもいいけど、Rails 8とPWAに関して何か知ってる？

Taylor)
いや、知らないな。私もそれについては聞いたことがない。
多分、DHH（Ruby on Railsの作者）が最近、AppleのApp Storeの閉鎖性に対して行っている運動に関連してるんじゃないかと思うけどね。
でも、PWAに関して彼らが何をやってるのかは、まだ把握してないんだ。

Matt)
うん、今ちょっと記事をざっと見たんだけど、主なポイントは、PWA用のファイルを自動生成するってことみたいだね。新しいアプリを作るときに、必要なファイルをいくつか生成してくれるらしい。
それと、新しいプッシュ通知のフレームワークもあるみたいだけど、ざっと見た限りでは、今あるものより良いのかどうかは分からないな。
だから、もし誰かがLaravelでPWAをやりたいって思ってるなら、そのサポートをどうするかって話をどこかで議論してみたらいいんじゃないかな。
例えば、『こうすればLaravelでPWAがもっと良くなる』みたいな形でね。
もしそれが単にいくつかのファイルの問題だけなら、フレームワークに最初から組み込む必要はないと思うけど、実際に何か内部的なサポートが必要なら、その点を話し合う価値はあると思うよ。
正直、PWAを作ってたときは全部フロントエンドの話だと思ってたんだ。要するに、マニフェストがここにあるかどうかとか、そういう感じで。
でも、もしLaravelで何か機能的なサポートが必要なら、その話を進めてもいいんじゃないかな。最近は追えてないけど、PWAが前よりももっと可能性があるなら、まだまだポテンシャルはあると思う。ただ、Appleみたいなところが邪魔しなければね笑

データベースクエリの最適化

Matt)
さて、あと一つ質問に答えて、今日はこれで終わりにしようと思うよ。
最後の質問は、データベースクエリをどう最適化してるかについてだね。
パッケージを使ってる？それともその都度最適化してる？最後に一気に最適化する？

Laravel)
基本的には、その都度最適化してるよ。例えば、適切なインデックスが設定されているか確認する感じだね。実行してるクエリに対して EXPLAIN を使って、ちゃんとインデックスが使われていて、全テーブルスキャンになってないか確認することもできるけど、確実にその都度やるようにしてる。
最後まで気にしないでおいて、最後に全部のテーブルを最適化しようとするやり方は、私たちはやってないんだ。
最初からデータへのアクセス方法を考えて、適切なインデックスを置くようにしてる。最初からうまくいくこともあるけど、アプリケーションの方向性が見えてきたときに、インデックスの設定を後から調整することもある。だから、全体的にはその都度やっていく感じかな。

Matt)
うん、私達も同じだよ。基本的にはインデックスを考えながらクエリを書いてるけど、知ってる範囲で最も合理的な方法でクエリを書いてる感じかな。
でも、最後にこれが問題になりそうだと思ってた部分に気づくこともある。たとえば、複雑なサブセレクトを書くのに時間がかかりそうなときは、簡単な方法で書いておいて『あとで見直す』みたいなTODOを残しておくんだ。
実際に、Laravelでやったプロジェクトで同じようなことをしたことがある。例えば、すべての組織のサイトを選択する代わりに、各組織のトップサイトだけを選択するようにしようと思ってたけど、今の時点ではそこまで複雑なクエリを書く余裕がなかったから、まずは全サイトを選択する簡単な方法で書いて、あとでパフォーマンスの影響を確認することにしておくんだ。

ページの動き方を頻繁に変えるから、早い段階で複雑なサブクエリを書いて、最終的にはそれが不要になるっていうのも嫌だしね。だから、最初はシンプルな方法で書いておいて、最適な方法ではないと分かってるけど、あとで確認すると決めるんだ。だから、私たちもその都度最善を尽くしつつ、最後まで残しておく最適化の部分もあるって感じかな。

Taylor)
うん、それは理にかなっているね。

2024/07/09
CEO of Laravel + PHP Lambos - Taylor Otwell Interview - Melk & Cookies Ep. 3
https://www.youtube.com/watch?v=WjSvO6vm0gQ

Taylor Otwell氏は大学卒業後、トラック会社に就職し、COBOLや.NETでシステム開発をしていた。
自分で作りたいもののアイデアが浮かんで個人開発しようとしたが、.NETではVisual Studio買わないといけないし、公開範囲も限定されるので、公開しやすいPHPに行き着いた。
いろんなPHPフレームワークを使ってみたが、あまりピンと来なかった。
そこで、自分用にフレームワークを作った。これがLaravel。
.NETや当時人気だったRuby on Railsに影響を受けている。
いつの間にか、OSSで人気を博し、今に至る🔥

Taylorは現在でも全てのPRをレビューしており、毎朝階段を登ってPRを確認することから一日を始めている。
なるべく平等にレビューしたいが、そうは言っても始めて見たような人からのPRとこれまで何回も貢献してきた人とでは当然信頼度は違う。でも、なるべくオープンマインドでいたいと思っている。

Laravelのコアチームは今年に入って採用を強化しており今年だけで10名=>30名以上に増えた。
カスタマーサポートや開発者、デザイナーなど多岐にわたる。
今取り組んでいるのは、Vercelのようにデプロイを簡単にできる仕組みを作ること。
昔はPHPが一番デプロイが簡単だったが、モダンフロントエンドの台頭でシステムが複雑化し、デプロイが複雑になっている。この問題を解決したいと思っている。

Taylorが今懸念しているのは、PHP言語自体のメンテナーが少なく、高齢化していること。
PHPがどのように動いているのか理解している人がいなくなることを恐れている。

当面Laravelに力を注ぐつもりだが、Laravelを終えた後はDJをしたいと思っている。
学生時代ドラムをやっていて、音楽が好きだから。