Laravel Podcast - 2024年10月
Maru2024/10/23 Matt Stauffer x Taylor Otwell
Laravel Podcast Episode 17
Intro
Matt)
やあ、みんな。
Laravel Podcast Season6へようこそ。ホストのMatt Staufferだよ。
Taylor)
やあ、Laravel創設者のTaylor Otwellだよ。
Matt)
さて、今回話したいことがいっぱいあるんだけど、たぶん全部には触れきれないかも。でも、とりあえず始めようと思うよ。最近いろいろ新しいリリースやアップデートが出てるみたいだし、その辺についてざっくり教えてくれないかな？
最近のリリース・アップデート情報
Taylor)
そうだね、いろいろやってることがあるんだ。まずオープンソースの方では、Laravelの導入プロセスを改善するために色々と取り組んでるよ。これは終わりのないミッションみたいなもので、常に少しずつ良くしていきたいんだよね。
最近では二つのことを新しく始めたんだ。
php.new
一つ目は、Marcelが手掛けた新しい php.new ってやつで、僕が長い間やりたかったことをようやく実現してくれたんだ。
もともとはLaravel Herdのアイデアの一つだったんだけど、もっとシンプルに、PHPだけの小さなアプリを作りたかった。
メニューバーにちょこんとあるだけで、ただPHPを動かすだけって感じで、UIもほぼなくて、Postgres.app みたいなイメージ。
僕はHomebrewをあんまり好きじゃないんだよね、巨大なブラックボックスみたいに感じるから。
何かアップデートすると他のも全部一緒にアップデートされて、気を使わないとすぐに環境が崩れちゃうんだ。Valetでも同じことが起こるよね。
そこで出てきたのが php.new。
先週リリースしたんだけど、基本的にはターミナルにコマンドをコピペするだけで使えるんだよ。
たとえば、curl php.new/install とかそんな感じで、それをターミナルに打ち込むとPHP・Composer・Laravelのインストーラーが自己完結型でインストールされる。
Homebrewとかのパッケージマネージャーを使わないから、すごくシンプルなんだ。
それで数秒で laravel new my-app みたいにしてLaravelアプリを作れるってわけ。
composer run dev
それから今週リリースしたもう一つのものが、新しいComposerスクリプトなんだ。これは実はもっと前に出しておくべきだったんだけどね（笑）。
Composerファイルに1行追加するだけで設定できる開発用のスクリプトで、Composerのスクリプト機能を使って composer run スクリプト名 で指定したコマンドを一気に実行できるんだ。
この新しいスクリプトでは、concurrently っていうパッケージを使って、Artisanのウェブサーバー、キューワーカー、Viteの開発サーバー、さらにログのtailまで、1つのターミナルウィンドウで全部動かせるんだ。
しかも、出力が色分けされてるから、どのプログラムから出力されてるかがひと目で分かるんだよね。
それで、composer run dev の1コマンドでアプリ全体を立ち上げられるってわけ。
php.newと組み合わせると、新しいラップトップでも一瞬でセットアップできる。
php.new、composer run devってやるだけで、アプリが立ち上がって、キューワーカーも走ってログもテールして、Viteがホットリロードで動く。
これがあると、Laravelに馴染みのない人にとっても導入が簡単で、親しみやすくなると思うんだ。
実はこれもTheo Brownからのフィードバックがきっかけだったんだ。
彼はTech教育者で、Twitterでも有名なんだけど、Laravelを試してみて、つまずいたポイントを記録してくれたんだよね。
ちょっと大げさに聞こえた人もいたかもしれないけど、悪意があったわけじゃなくて、彼の本心をそのまま出してた感じ。
それで、彼と個別に話をして、Laravelで何が分かりにくかったかとか、良かったところや悪かったところを一緒に確認したんだ。
このComposerの開発用スクリプトも、実は彼が自分のプロジェクトで使っていたコマンドを僕が「送って」って言ってもらって僕の方で少しいじって、リリースしたんだ。
すごい面白い経験だったと思うよ笑
Matt)
いいね。
Railsで開発してた時、Herokuに便利なツールがあって、プロセス定義をセットしてそのファイルを使ってHeroku上で実行させるんだけど、ローカルでも同じようなことができるツールがあったんだよね。
名前が思い出せないけど、middlemanみたいなやつだった気がする。違ったかな、、
Laravelプロジェクトで何度か同じ設定をしたことがあったけど、concurrentlyがあるとは知らなかったよ。
これはnpmパッケージなんだよね？
Taylor)
そうそう。
concurrentlyは本当にシンプルなパッケージで、concurrently って書いて、あとは同時に実行したいコマンドを全部並べて渡すだけなんだ。
Matt)
いいね。
で、これって自分のプロジェクトに合わせてカスタマイズもできるんだよね。
例えば、自分のプロジェクトでLaravelアプリに加えて3つの依存関係が必要だったとしても、そのコマンドをちょっと変えるだけで対応できる。
そうすると、あとからプロジェクトに参加する人も、何を動かす必要があるか細かく知らなくても、そのスクリプトを実行するだけで全部セットアップされる。
めちゃくちゃ便利だね。
Taylor)
だよね。
最初にこれを出したときに「artisan dev みたいなコマンドにすればいいんじゃない？」っていうフィードバックもあったんだけど、そうしなかった理由がまさに今君が言ったようなことなんだ。
Composerスクリプトであれば、Composerファイルを開いて自分の好みに合わせて簡単に編集できるっていうのが大きなメリットだよね。
たとえば、通常のキューワーカーの代わりにHorizonを使いたいとか、コマンドを追加したり削除したりしたい場合でも、Composerファイルの文字列を変えるだけで済むんだよね。
もしこれがフレームワークに組み込まれて artisan dev コマンドみたいな形になってたら、カスタマイズ用のフックやオプションも必要になってきて、かえってややこしくなる。
Composerファイルにちょっと書くだけで済むのが、一番シンプルで良いと思うんだ。
Matt)
うん、だよね。無理に高レベルにする必要がないなら、シンプルに低レベルに保つのが好きなんだよ。
たとえば、もっと複雑になってテストも必要になってきたら、そこでphp artisanに移行するのもアリかもしれないけど、そこまで必要ないならartisanを使う必要もないよね。
すごく良い考えだと思う。
最初に聞いたときも『お、いいじゃん』って感じだったけど、考えれば考えるほどチームにとってのメリットが大きいよね。
新しい開発者だけじゃなくて、新しい人がチームに入ってくるときもさ、『これが全部だよ』って見せるだけで済むっていうのが素晴らしいよね。
Tightenでプロジェクトを引き継ぐときも、最初にやるのは全体を見てセットアップして、新しい開発者が入るときのオンボーディングを速くするために手を加えることなんだ。
それはもちろん自分たちのためでもあるんだけど、クライアントが次に雇う開発者のためにもなる。
依存関係は何が必要か、何をインストールしておくべきか、毎回何を実行すればいいかってことが、このスクリプト一つで簡単になるから、フレームワークに慣れていない開発者だけじゃなくて、プロジェクトに新しく参加する人にとっても大きな助けになるよね。
Inertia 2.0
Taylor)
そうだね、すごくクールだよね。
それから、今週、いや先週末だったかな、Inertia.js 2の最初のベータ版をリリースしたんだ。
今回のリリースには本当にワクワクしてるんだ。
Inertia.js 2のベータ版にはVue、React、そしてSvelteのサポートも含まれているよ。
ただ、Vue 2のサポートは終了したから、Vue 3に移行してもらう必要があるけどね。
今回のリリースには、Laraconで紹介した全機能が入ってるんだ。たとえば、プリフェッチやデフォードプロップス（遅延プロップス）、無限スクロールなんかだね。
次のベータ版では無限スクロール機能もさらに強化される予定で、見えたら読み込むコンポーネントも追加されて、よりシンプルで無駄が少なくなるよ。
Laravelのページネーションに沿った設定で簡単に使えるようになってる。
あと、ポーリング機能なんかも全部入ってる。
今紹介した機能が全てベータ版で使えるようになったし、v2.inertia.js.com っていう新しいInertia.js V2のサイトも公開しているから、アップグレードガイドも見れるよ。
基本的にはVue 2のサポートが外れた以外に大きな変更はないから、既存のアプリを大きく変更する必要もないのがすごく良いところだと思う。
実はこのInertia.js 2は、Laravel Cloudの内部でも何週間もテストしてきたんだ。
今のところ、ほんとに調子がいいし、最高の出来だよ。
最近のリリース・アップデートを振り返って
Matt)
いや、盛りだくさんだね！
普段は『最近何か変わったことある？』って聞いても、『小さな変更がちょっとあったよ』くらいだけど、今回は3つとも結構大きなアップデートだね。
特に php.new なんだけど、なぜか最初のバージョンを見たときはあまりシンプルさがピンとこなかったけど、実際にはすごく簡潔にまとまってるんだね。
JavaScriptの開発者も数ステップで使えるし、WordPressの開発者にとっても同じく手軽に導入できる。
最近、5年とか10年前にWordPress開発者がLaravelを学ぶのをどう支援するかっていう話をいろいろしてたことを思い出してて、今の状況からしても、またLaravelに移行したいって人が増えそうな気がしてるんだ。
たとえばWAMPとかでやってた人が、これを使えばモダンな依存関係も含めてすぐに動かせるようになる。ほんとに素晴らしいと思うよ。
Taylor)
うん、ほんとにそうなんだよね。
実は php.new の利用状況も追跡してて、どのOSで使われてるかも見てるんだ。
意外にもLinuxユーザーの利用が多いんだよね。
正直、Linuxだったら apt-get install PHP みたいな感じで簡単にインストールできるから、あまり使われないと思ってたんだけどね。
でも、予想以上に人気が出てて面白いよ。
Laravel Cloud - サポート対象のPHP・Laravelバージョン
Matt)
いいね！
さて、前回の収録後に寄せられた質問がいくつかあるんだよね。
クラウド関連とかいろいろあって、まだ話せてなかったことがいくつか残ってるから、次の話題に入る前にそれをパパっと確認しておこうかな。
まず最初の質問だけど、Laravel Cloudには最低限必要なPHPやLaravelのバージョンが設定される予定はある？
Taylor)
そうだね、現行のCloudではPHP 8.2と8.3をサポートしていて、来月には8.4がリリース予定だから、Cloudが正式リリースされる頃にはPHP 8.4にも対応しているはずだよ。
Laravelの最低バージョンについてはいい質問だね。
PHP 8.2で動くLaravelのバージョンならサポートできるはずだから、具体的にどのバージョンになるんだろ。Laravel 10、いや、Laravel 9かな？
Matt)
うん、興味ある人は laravelversions.com ってサイトを見てみてほしいんだ。
そこでPHPのバージョン対応状況も見られるんだけど、どうやらLaravel 9が一番古いバージョンになりそうだね。
質問してくれた人のバージョンが6とかだったから、『いや、Laravel 6のサポートはさすがに無理だよ』って感じだった笑
Taylor)
そうだね、どちらかというとLaravelのバージョンよりもPHPのバージョンがネックになりそうだね。
PHP 8.2を最低サポートするなら、それに対応するLaravelバージョンが最低要件になるって感じだね。
Laravel Cloud - 公開API
Matt)
なるほどね。
次の質問だけど、Cloudには公開APIが用意される予定はある？
Taylor)
うん、将来的には確実に公開APIを用意するつもりだよ。
ただ、リリース初日にどこまで公開できるかはまだ分からないんだ。
来年の初めに一般公開するタイミングでは、少なくともデプロイをトリガーするAPIは提供したいと思ってる。GitHub Actionsとかと連携したいっていう声が多いだろうからね。
チームメンバーやプロジェクトの情報を取得する機能なんかも、いずれは対応していく予定だけど、まずは基本機能を整えて、そこから少しずつ改善していく感じかな。
Laravel Cloud - 旧Laravel Cloudプロジェクトの影響
Matt)
次の質問は、TightenのTony Misasからだよ。彼は最初にリリースされたLaravel Cloudのコードが大好きだったみたいで、そのコードはまだどこかで公開されているのかって聞いてるんだ。
彼自身も答えを知ってるかもしれないけど、一応聞いてみるね。
彼の質問は、最初のLaravel Cloudのコードが、新しいLaravel Cloudに直接的またはインスピレーションとして取り入れられているのかってことなんだ。
Taylor)
いや、特に直接のコード流用はないね。
最初のLaravel Cloudのコードはまだ存在していて、Laravel組織のプライベートリポジトリに保存してあるけど、今のLaravel Cloudにはそのコードは使ってないんだ。
リスナー向けに少し背景を話すと、Vaporを書く前に「Laravel Cloud」って名前で別のプロジェクトをやってたんだよね。
それが2018年後半か、2017年後半だったかもしれない。
その時のLaravel Cloudは、どちらかというとForge 2.0みたいなもので、YAMLファイルでウェブサーバーやワーカーサーバーを設定して、‘Cloud deploy’って実行すると全てをプロビジョニングする感じだった。
でもバックエンドはVPSだったから、完全なマネージドサービスとは言えず、今のLaravel Cloudみたいに本当のPaaS（プラットフォーム・アズ・ア・サービス）じゃなかったんだ。
そのプロジェクトではフロントエンドのデザインもやっていて、たしか当時僕と一緒に働いていたTailwindのSteve Schogerがデザインしてくれたんだ。
アプリ自体はほぼ完成していたんだけど、結局リリースには至らなかった。
Forgeに対するごくわずかな改善に過ぎなかったから、全く新しいプロダクトとして出すには正直なところ、それほど価値があるとは思えなかったんだ。
特に多くのForgeユーザーはスケーリングや複数のウェブサーバーにはそこまで関心がないだろうしね。
それで、そのコードは一度オープンソース化したんだけど、結局何かの理由で非公開に戻したんだ。
コードを見た人たちは、Laravelアプリの画期的な構築法があると思っていたみたいだけど、実際は公式ドキュメントに沿った普通の書き方だったから、少し期待外れだったみたい。
特に問題はなかったし、個人的には良いコードだったと思うよ。
このコードのスタイルは、Vaporの開発に100%受け継がれていると思う。
特に「ファットモデル」の書き方は、Laravel Cloudのデータベースで見られたスタイルそのものだね。
このやり方は今でも素晴らしいと思ってるよ。
だから、ある意味でVaporがLaravel Cloudの精神的な後継者と言えるかもしれないね。
オートスケーリングや次世代のインフラをLaravelアプリに提供するという目標の面でもそうだし、コードのスタイルや書き方の面でも、Cloudの特徴がVaporに受け継がれてるんだよね。
Matt)
そうだね、Cloudが非公開になる前にコピーを持ってた人や、一度でも目を通したことがある人にとっては、あれが『Taylorならこうする』っていう参考になる部分があったよね。
Taylor)
Laravel Cloud入りのゴールデンフロッピーディスクを売るべきかな笑
Matt)
それ、買うよ！そこに置く笑 (部屋を指差して)
Taylor)
それは面白いね笑
Taylorが使っているIDE
Matt)
じゃあ、最後の質問なんだけど、ある人が『LaraconでVS Codeの拡張機能を発表してたけど、ステージではSublime Textを使ってるのを見たよ。実際にはどのIDEを使ってるの？』って聞いてるよ。
Taylor)
まだSublimeを使ってるよ。Laraconの舞台裏でも笑ってたんだけど、『VS Codeのデモをやるのに、その後すぐSublimeに戻るのって変じゃない？』ってね（笑）。
もう完全に身体に染みついてる感じなんだよね。
もちろん、VS Codeもすごく気に入ってるし、いずれ移行したいと思ってるよ。
多くの開発者が使ってるし、CursorみたいにVS Codeベースのツールも試してみたい。
最近は開発にAIも少しずつ取り入れてるからね。
ただ、やっぱりSublimeはめちゃくちゃ速いんだよね。
Caleb Porzioの「VS Codeを最高に使いこなすためのebook」も読んで、VS Codeをかなり自分好みに設定できたから、もし明日Sublimeが使えなくなっても、プログラミングをやめるわけじゃなくて、VS Codeで生産的に仕事を続けられる準備はできてる感じだよ。
ショートカットキーもほとんど同じだしね。
Matt)
TightenのKeithもまだ強気でSublime Textを使い続けてるんだよね。
それどころか、Sublime Textでプレゼンをやったこともあるんだ。
タブを切り替えたりとか、ちょっとしたテクニックを駆使してて、僕が知らなかったようなSublimeの技も見せてくれてさ。
実は僕も一時PHP Stormに乗り換えたんだけど、PCで動かすには遅すぎて、結局Sublimeに戻ったんだ。
Caleb PorzioがTitanにいたとき、彼が「VS Codeへの説得」っていうチャンネルを作って、そこに少しずつVS Codeの便利なポイントを投稿してくれてね。
そのおかげで、僕も次第に気持ちが動いていったんだ。
Sublime Textから完全にIDEに行くのは抵抗があって、でもテキストエディタ以上のものは欲しいと思ってて。
だから、VS Codeはその「ちょうどいい真ん中」にいる感じなんだよね。
前にSublime TextでPHP開発環境を整える方法についてブログを書いたことがあるんだけど、プラグインが壊れたときどうしたらいいか分からなくて、結局VS Codeに移ったんだ。
VS Codeは、Sublime Textの精神的な後継者みたいな存在だと思ってる。
テキストエディタなんだけど、もっと賢いことができるように作られてるし、機能がしっかりしてる。
Sublimeだとちょっと無理やり感があるところもあったけど、VS Codeはちゃんとそれを補ってくれる。
Taylor)
TightenでのVimの採用状況ってどんな感じ？
Matt)
うーん、少なくとも2人は完全にtmuxとLinux、そしてVimでやってるね。
他にも、使ってるエディタにVimバインディングを設定してる人が半分くらいいるかな。
でも、本当にVimそのもので生きてるのは2人くらいかも。
画面共有すると『え、Vimってこんなことできるんだ』って驚かされるよね。
あの新しいやつも使ってるみたいで…
Taylor)
Neovim?
Matt)
そう、彼らはNeovimとtmuxを使ってて、画面にASCIIアートがいっぱい表示されてるんだよね。
なんか、今まで見たことないような世界観だよ。
きっと僕たちにもいろいろ教えてくれるんだろうな（笑）
Taylor)
それは確かにかっこいいね。
Matt)
僕も以前は完全にVimでやってみたことがあったけど、長続きしなかったんだ。
でも、彼らのセットアップだとそのあたりが解決されてるから、すごくスムーズにいろんなことを切り替えてるんだよね。
僕が使ってたときにはできなかったことが、彼らは普通にできてるから、びっくりするよ。
君の周りに完全にVimを使ってる人はいる？
Taylor)
間違いなくJess Archerがそうだね。
あやうくLaracon AUで発表するプロダクトのことを言いそうになったけど、JessはVimをハードコアに使ってるよ。他に誰かいるかは分からないな。
もしかしたらインフラ系の人たちが使ってるかもしれないけど、これは単なるインフラ担当のイメージなのかも（笑）
Matt)
なるほどね。
うちにはPHP Stormを使ってる人が何人かいるかな。
僕も定期的にPHP Stormに戻りたくなることがあるんだよね。
便利な機能を見かけるたびに『おっ』ってなるんだけど、日々書くコードの量がそこまで多くないから、乗り換えるほどの価値があるかって言われると微妙かな。
Taylor)
僕も最近、なるべく1日2時間くらいはコードを書くようにしてるんだよね。
昼間とか夜に少しずつ、Laravelのスキルを維持するためにやってる感じ。
Laravel Cloudを作ってるけど、実際には日々のコーディングにそこまで関わってないから、Laravelでアプリを書く感覚を忘れないようにするのは重要かなと思ってて。
ちょうど昨日もエディタについて考えてたんだけど、AIを使ってLivewireコンポーネントを書いたんだ。
Voltコンポーネントだったんだけど、クラスベースのLivewire構文を使って、アプリ内で会社を新規作成するためのシンプルなフォームを作ってみたんだ。
それをChatGPTに入力して、『このコンポーネントにLivewireのテストを書いてくれる？』って頼んでみた。
コンポーネント内にバックエンドとフロントエンドがまとまってたから、簡単なバリデーションテストとかを生成してくれるかなって思って。
そしたら、出力されたテストクラスが、ほとんど自分が書いたのと同じような内容で驚いたよ。
成功テストといくつかの失敗テスト、無効なメールとかもちゃんとカバーされてて、Livewireのテストヘルパーも使ってくれてたんだ。
ほとんど手を加える必要もなかったし、本当に感心したね。
それで、Cursorエディタとかも気になり始めて、まだ試してないけど、ぜひ試してみたいと思ってるよ。
Matt)
そうなんだよね。
こういう話を聞くと面白そうだなって思うんだけど、自分でも少し試してみたことはあるけど、まだ慣れるところまで続けられてなくて。
最初の使い始めのハードルを越えられたかも分からないし、使いこなせてるとは言えないんだよね。
あと、いろんな記事を読んでると、全体的には生産性が下がるって話もあってね。
短期的にはブーストされる感じはあるけど、長期的にはどうなんだろうって。
でも、将来的に本当に役立つようになるとしたら、単に機能を「持っている」だけじゃなく、どのタイミングでどう使うかの「使い方」を知ることも大事になりそうだよね。
エディタ自体にカスタマイズ機能が増えてきて、「こういうプロンプトは出して欲しい」「こういう補完は不要」とか、細かく設定できるようになるかも。
現状、業界全体で見ると、生産性はむしろ落ちている傾向にあるみたいだけど、それでも興味はあるんだよね。
特にチームの生産性を考えると、どんな方針で取り組むべきか悩んでるところだよ。
Taylor)
確かに、自分がフォームやページ全体を生成させようとしてたら、かえって時間がかかったかもなって思うよね。
自分でTailwindクラスを使って、細かいところまで思い通りに仕上げたほうが早かったかも。
でも、テストとか、地道なボイラープレートの作業には結構役立ったんだよね。
だから、これからも使っていく中でどうなるか楽しみだし、もっと便利に感じられる場面が増えたらいいなって思ってる。
Matt)
そうだね、Taylorはそれが役立つ場面と、逆にやっても楽しくない部分を見極めてたのが良かったんだと思う。
全部一気に任せるんじゃなくて、要所要所で使い分けるところにこそ上手な使い方のポイントがある気がするんだよね。
だから、どう使えばより効果的かっていう工夫が大事だと思う。
Taylor)
うん、本当にその通りだね。
Open Source Predge
Matt)
さて、次の質問なんだけど、Open Source Pledgeについて教えてもらえるかな。
最近、Open Source Pledgeの画像がタイムズスクエアあたりでちょっと話題になったみたいで、僕もそのサイトをタブで開いたままにしてあるんだ。
画像にはOpen Source Pledgeの名前があって、Laravelもそのグループの一員として載ってたんだけど、具体的にOpen Source Pledgeについて、あとTaylor自身の関わりについて教えてもらえないかな？
Taylor)
そうだね、Open Source PledgeはSentryが始めた取り組みなんだ。
Laravelも2017年頃からSentryとよく協力してきているんだけど、彼らがこのOpen Source Pledgeを立ち上げたんだよね。
簡単に言うと、社員のフルタイム開発者1人あたり年間2,000ドルをオープンソースプロジェクトに還元するという誓約をするというものなんだ。
そうだね、この取り組みの狙いとしては、自社が恩恵を受けているアップストリームのパッケージに還元することだと思うんだ。
例えば、うちだとPHP Foundationとか、Composerみたいなものが具体例だね。
実際、すでにこれらのプロジェクトには少しずつ寄付しているんだけどね。
僕たちは以前からオープンソースに対して年間2万ドルくらい寄付していて、今回の取り組みで少し増額するつもりなんだ。
主にPHP Foundationへの支援になるかな。
このイニシアチブは、オープンソース開発者に対する認知を広めたり、資金を還元するための取り組みだよね。
オープンソースの開発者たちは、世の中に多大な価値を提供しているにもかかわらず、従来十分な報酬を得られていないのが現状だからね。
WordPressの話題なんかもあって、オープンソース全般に関する議論が盛り上がっているけど、僕個人としては、オープンソースっていうのはオープンソースであって、公開した時点で報酬を期待するものではないと思ってるんだ。
もしお金が必要なら最初から有料にすればいい話だしね。
でも、それでもやっぱり企業がオープンソース開発者の価値を認めて、彼らのプロジェクトに寄付するのは素晴らしいことだと思うよ。
開発者たちが費やした時間やメンテナンス、バグ修正の努力に対して、少しでも還元する意味があると思うんだ。
今回のマーケティングキャンペーンも、オープンソースへの還元を呼びかけるためのもので、多くの多国籍企業はオープンソースソフトウェアの上に成り立っているからね。
例えば、nginxとかPHP自体もオープンソースで提供されているわけだから。
Matt)
そうだね。
僕も会社を経営していて、他の企業ともよく仕事をする立場として思うんだけど、もし特定のオープンソースソフトウェアがメンテナンスされなくなったら自社の運営が大変なことになるような状況で、しかも自分たちでそのソフトを引き継いでメンテナンスする能力がないとしたら、その開発者が最初から有料にしていなかったとしても、経済的にサポートする価値は十分あると思うんだ。
単に開発者にお金を払う義務があるという話ではないけど、純粋に経済的、そして安定性の観点から見ても、会社にとっては日々依存しているツールが安定していることが重要なんだよね。
開発者が燃え尽きてプロジェクトをやめてしまうのを防ぐために、経済的なサポートでそのプロジェクトを支えることは、会社にとってもメリットがあることだと思う。
Taylor)
本当にそうだよね。
多分、世界中のすべてのソフトウェア会社が、何かしらの形でオープンソースに依存してると思うんだ。
Linuxサーバーで動かしていたり、何か他のことをしていたりしても、きっとどこかでオープンソースソフトウェアを使ってるはずだよね。
WordPressの権利紛争
Matt)
そうだね、それで今WordPressの話も出たけど、事前にこれについて話す準備をしてもらってなかったよね。
このまま触れずにおくか、ちょっと話してみるか、どうする？
今は少しホットな話題[1]だからさ。
Taylor)
先日、Prime’s Podcastでこの話題に少し触れたんだけど、正直言って、WordPressのエコシステムについてはあまり詳しくないんだ。
ただ、見た感じではかなりドラマチックな状況に見えるね。
MattがWP Engineに対して求めている8%の収益分配なんかは、ちょっと大きすぎるんじゃないかと思うけど、それが本当に妥当かどうかはわからない。
全体の詳細についてはあまり知識がないから、あまり深くはコメントできないけど、Mattの行動は少し劇的で、ちょっと突飛な感じがするね。
でも、これはあくまで僕が見た範囲での印象だから。
Matt)
なるほどね。
僕としてもあまり多くは語らないけど、個人的な感想としては、何万人ものWordPress開発者たちのキャリアに悪影響を及ぼしているのは、本当に残念だと思う。
それが一番大きな問題に感じてるんだ。
責任が誰にあるのか、なぜこういう状況になったのかについては考えはあるけど、あまり炎上を招きたくないから、詳しくは言わないことにするよ。
でも、何年も、場合によっては何十年もWordPressを基盤にキャリアを築いてきた人たちが、今の不安定な状況にさらされているのは気の毒だよね。
特に今は技術業界全体が厳しい時期で、仕事もなかなか見つからないし。
僕としては、彼らが早く安定を取り戻せるように、事態が一刻も早く解決することを願っているよ。
今回の件は、オープンソースの世界でも慎重に考えなければいけないことだと思うし、実際に『Taylorも同じようなことをやる可能性があるのか』って聞かれることもあるんだ。
でも、まず第一に、Taylorはすごく穏やかな人だから、そんなことは考えられない（笑）。
それに、Laravelではこういった問題が起こらないように仕組みを整えているから、こういう事態にはならないと思ってる。
なんというか、やっぱり今回の件で多くの人の生活に影響が出ているのを見て、少し悲しくなったよね。
Taylor)
そうなんだよね。正直、僕も全部を完全には理解してないんだ。例えば、プライベートエクイティ（PE）についても同じような質問を受けたことがあるけど、PEはベンチャーキャピタル（VC）とは少し違うし、オープンソースとも違うよね。
今回のWordPressの件については、外から見る限りだと、PEが絡んでいるわけではなく、MattがWP Engineに収益の8%を自分に還元するように求めたり、いくつかの商標の問題が関わっているみたいだね。だから、ベンチャーキャピタルやプライベートエクイティがどのように関係しているのか、正直よく分からないんだ。
Matt)
確かに、かすかに関係しているとすれば、WP Engineがプライベートエクイティに買収されたことくらいだね。
でも、WP Engineは最初からWP Engineらしさを保ってきたし、プライベートエクイティが何かを変えて、今のMattの行動に直接つながったわけじゃないんだよね。
だから、名前だけでの関連に過ぎない感じだよ。
Laravelドキュメントの書き方
Matt)
さて、次の質問に進もうか。『Laravelのドキュメントを書くときってどんな感じなの？』っていう質問があるんだ。
確か、コードサンプルを最初に書くっていう話がTwitterで出てた気がするんだけど、誰のツイートだったか覚えてないんだよね。
たぶん1ヶ月くらい前にメモしてたやつなんだけど、新しい機能についてドキュメントを書くとき、Taylorはどういうプロセスで進めてるのかすごく気になるんだ。
新しいドキュメントを書く場合に限定して話を聞きたいんだけど、既存のドキュメントの書き直しではなく、全く新しい機能のドキュメントを書くときって、どんな流れで進めてる？
Taylor)
いい質問だね。
小さな機能の場合は、機能の実装が終わった後にドキュメントを書くことが多いよ。
たとえば、Laravelにプルリクエスト（PR）が来て、それをマージしたら、PRを送ってくれた人にドキュメントを書いてもらうのは手間だから、自分でさっと書いちゃうんだ。
小さい変更なら、その場でPRを見ながらドキュメントを書くのが早いからね。
でも、大きな機能に関しては、ドキュメントの一部を先に書くこともあるんだ。
たとえば、さっき話したInertiaの無限スクロール機能を改良しているところだけど、これはJoe Tannenbaumが無限スクロールのドキュメントを書き始めたときに、『これ、何かが足りない感じがする』って気づいた時とか。
Matt)
そうだね、その方が簡単になるよね。
Taylor)
そうなんだよね、これまでずっと話してきたけど、いわゆるドキュメント駆動開発（Documentation Driven Development）ってやつだね。
ドキュメントを書いていて説明が難しいと感じるときって、機能自体がまだ完成しきっていないとか、全体的な設計が不十分なことが多いんだよね。
だから、大きな機能については、最初にドキュメントを少し書いておくとすごく助かるんだ。
言葉が完璧でなくても、説明しようとすると設計上の問題が浮き彫りになることが多いから。
Laravelに大きな機能が追加されるときは、PRを書いてくれた人に、最初にドキュメントを書いてもらうこともあるよ。
彼らが一番その機能を理解してるからね。
もちろん、それが完璧な内容であることは期待してないし、僕がそのままマージするわけでもないけど、ざっくりとした下書きがあると、あとはそれを整えてLaravelのドキュメント全体のトーンに合わせるだけで済むから、全体として統一感が出るんだ。
そんな感じで、Laravelのドキュメントはいつもこんな感じで進めてるよ。
Matt)
そうだね。ちょっと掘り下げて話すけど、Taylorがドキュメントを何度も書き直しているのを見てきて、少なくとも10回以上はリライトしてると思うんだ。
毎回少しずつアプローチが変わっているけど、一つ変わらないのは、常に新しいユーザーの視点を意識していることだよね。
ドキュメントの構成も、機能ごとやセクションごとに整理してるときもあれば、物語みたいに「これをして、次はこれをして…」と手順を追って説明するスタイルにしてるときもある。
10年以上このプロセスに関わってきて、手順を追うようなドキュメントと、インデックス型のドキュメントのどちらが好みなのか、それとも状況によって使い分けるべきだと思う？
Taylor)
やっぱり、いろいろなスタイルのミックスが必要だと思うね。
特にこれから今年の後半から来年にかけて、もっとその方向にシフトしていきたいと考えてるよ。
今のLaravelドキュメントでは、左側に「キュー」「認証」「暗号化」などの機能ごとのインデックスがあって、各ページでそれぞれのトピックを掘り下げて説明しているから、単独で見れば理解しやすい作りになってると思うんだ。
でも、もう少し「最初の一歩」や、Laravel開発者としての成長過程の中盤あたりもカバーできたらいいかなと思ってる。
ブートキャンプみたいに、一つのアプリを作り上げていく流れを通して説明する感じだね。
今のブートキャンプもその役割をしっかり果たしているけど、もう少しガイド形式にして、ドキュメントの中でも統合的な内容にしていけるといいかなと思ってる。
Laravelの機能がどんどん増えて、より多くのパッケージが登場する中で、各ドキュメントが独立して良い内容になっているのは素晴らしいんだけど、新しいユーザーにとっては全体を理解するのが難しくなってきてるんだよね。
一つのページでLaravelの魅力を味わってもらえるようにして、あちこちのページを見なくてもスムーズに理解できるようにしたいと思ってるんだ。
Matt)
そうだね、最終的には全部読んでもらえたら理想だけど、最初の日にそれを全部やらなきゃいけないっていうのも違うよね。
何かを始めるために、いきなり全部読む必要がないのが一番だと思う。
PHP以外の言語でLaravelを作るとするなら？
Matt)
そうだね、まだ質問はたくさんあるんだけど、あまり長く引き留めたくないから、最後にこれだけ聞かせて（笑）。
この質問、何度も出てきてるんだけど面白そうだから投げてみるね。
今までに他の言語でLaravelを書き直してみたいなって思ったことはある？
例えば、RustベースのLaravelとか、JavaScriptベースのLaravelとか、ちょっと試しにやってみたこととかある？
もし試したことがあるなら、結局PHPに戻ってきた理由は何？
試したことがないなら、もし今からLaravelを作り直すとしたら、どの言語を選ぶと思う？
Taylor)
良い質問だね。
実際、別の言語でLaravelの新バージョンを本気で作り始めたことはないんだ。
PHPを使い続けている理由としては、やっぱり自分たちが一番よく知っている言語だからかな。
それに、別の言語でLaravelを再現することは可能だろうけど、すごく時間がかかると思うんだ。
Laravelのコア部分だけじゃなくて、エコシステム全体、たとえばNovaやHorizon、Cashier、Socialite、Scoutといったパッケージも含めて全部作り直すことになるから、それを考えるだけでも途方もない作業だよね。
今のLaravelと同じ機能レベルに持っていくには何年もかかるだろうし、その間にLaravel自体もさらに進化していくだろうから、現実的にはちょっと難しいんじゃないかと思ってる。
もし別の言語で作るとしたら、JavaScriptが一番無難かなと思うよ。
フロントエンドとバックエンドの両方で同じ言語を使えるっていうのは、やっぱりJavaScriptの強みだよね。
他には個人的にElixirも面白いと思ってる。
RubyもRailsがあるし、ElixirにはPhoenixがあって、どちらもフルスタックのフレームワークとしてある程度Laravelに近い体験ができる言語だね。
でも、よく『JavaScript版のLaravelを作る気はないの？』って聞かれることがあるけど、過去にAdonisJSなんかでLaravelに似た体験を再現しようとしたプロジェクトもあるんだ。
ただ、RemixやNext、さらにはNuxtみたいな他のフレームワークと同じくらい広く採用されることはなかったんだよね。
それがなぜかははっきりとは分からないけど、単に努力が足りないというわけじゃなくて、JavaScriptのエコシステムはPHPとは異なる文化やアプローチがあるからなのかもしれないね。
Matt)
そうだね、それに『タイミング』っていうのもあるかもしれないよね。
この話は以前もしたことがあるけど、僕の好きなポッドキャスターのGuy Razが、企業家にインタビューするたびに『成功の要因はどれだけがスキルで、どれだけが運だったと思いますか？』って聞くんだ。
正確な言葉は忘れたけど、Laravelが単に運だったと言うつもりはないけど、確かにタイミングや人、環境が整っていたのも要因だったと思うんだ。
だから、もしかしたら将来的に、もしくは過去に、JavaScriptでもこういうフレームワークが成功するタイミングがあったのかもしれないし、特定の人物や瞬間があればまた違ったかもしれない。
でも、たしかにJavaScriptのエコシステムではそういうフレームワークがなかなか成功しないって話はよく聞くんだよね。
AdonisJSがまさにその一例で、僕自身は使ったことがないけど、使ったことのある人からの話を聞くと、かなりLaravelに近い体験ができるみたいなんだ。
でも、なかなか広まっていない。
これはAdonisJS側の努力不足ってわけじゃなくて、もしかしたらそのタイミングが来れば突然人気が爆発するかもしれないし、そうなったら僕も嬉しいよね。
でも今のところ、JavaScriptコミュニティが求めているものとは少し違うのかなって感じがするんだ。
Outro
Matt)
じゃあ、そろそろここで終わりにしようかな。
今日話してないことで何か他にシェアしたいこととか、触れておきたいことはある？
Taylor)
うーん、特に他に話すことはないかな。注目してほしいのは、Laracon Australiaでの発表だね。今年の大きな発表はそこで行う予定だよ。
それから、年内にLaravel Cloudの早期アクセスも開始する予定なんだ。
来月にはまず信頼できる10名ほどのメンバーからスタートするかもしれない。
もう本当に数週間先って感じだね。
内部では、アクセスコードの招待システムなんかもすでに開発していて、今朝もNunoがデモを見せてくれたよ。
その後の数ヶ月で、数十人、最終的には数百人規模で早期アクセスを広げていく予定だから、これも楽しみにしててほしいね。
そしてもちろん、Laracon Australiaにも注目してほしい。
Matt)
そうだね。
今日は10月16日だから、Laracon Australiaまであと2週間半くらいだね。
このエピソードが公開される頃には、あと1〜2週間ってところかな。
実は、Laracon Australiaでの収録用にマイクもすでに用意してあるから、現地での特別な録音も楽しみにしてもらえると嬉しいな！
それじゃあ、Taylor、いつも通り一緒に話せて楽しかったよ！
皆さんも一緒に時間を過ごしてくれてありがとう。
それでは、またね！
Taylor)
みんなありがとう！