11,364 文字
なぜUpload Thingを使うのでしょうか？それはただのS3のラッパーではないですか？なぜS3を使うのでしょうか？それはただのハードドライブとさまざまなサーバーファームのラッパーではないですか？なぜサーバーファームを使うのでしょうか？それはただの自分のクローゼットに置けるサーバーのラッパーではないですか？なぜLinuxを使うのでしょうか？それはただのラッパー…というように、お分かりですよね。
あなたがどのレイヤーに住んでいるか、スタックのどの層に存在しているかによって、全てがラッパーに見え始めます。これは新しいことではありません。世界が変わったからといって、私が突然ツーチェインズのようにラップし始めたわけではありません。全てがラッパーである理由は、私たちが時間の経過とともに技術を改善してきたからです。このビデオを作らなければならないなんて信じられませんが、人々がラッパーは悪いものであり、ソフトウェアが改善されていない例だと考えているようなので、必要だと感じています。実際には、過去30年以上にわたってソフトウェアに見られた主要な改善のほとんどは、多くの面でただのラッパーでした。
もしJavaを擁護し、AWSについて話し、なぜT3 ChatがOpenAIよりも優れた製品だと思うのかを詳しく説明する私を見たいなら、少し待ってください。まず広告を出さなければなりませんので。
最近、BoltやVzero、Lovableなどのツールを使って一回限りのアプリを素早く構築するのが好きですが、それらがうまくできないことがいくつかあります。特に彼らが苦戦している一つがOth（認証）です。ゼロからアプリケーションを構築するのは不思議なほど簡単なのに、サインインボタンを機能させるのは不思議なほど難しいのです。今日のスポンサーであるClerkを使わない限りは。
Clerkは、認証を管理したり、デプロイしたり、最新の状態に保ったり、ユーザーテーブルを混雑させたりすることを心配せずに、適切に認証を設定する最も簡単な方法です。Clerkを使うことになるかどうかにかかわらず、私の言葉を信じてください。ユーザーテーブルをデータベースから取り出し、認証を別のサービスやマイクロサービスで管理できるようになれば、より良くなります。それは私の人生をとても楽にしてくれましたし、それが可能だとは思っていませんでした。
しかし、Clerkが私の生活を楽にしてくれることはそれだけではありません。彼らには完全なコンポーネントライブラリが組み込まれています。サインインボタンから実際のユーザープロファイル、組織からユーザー向けの招待まで、すべてを管理するための優れたUIを提供してくれます。本当に素晴らしいです。
真剣に言うと、もしあなたがNext.jsを使っていて、まだ認証を設定していないなら、Clerkよりも良いおすすめはできません。滑稽なほど簡単です。パッケージをインストールし、middleware.tsファイルにClerkミドルウェアを取り込み、単にデフォルトでClerkミドルウェアをエクスポートします。検証したくない他のものをスキップしたい場合は、この設定を入れます。レイアウトに移り、アプリをClerkプロバイダーでラップします。そして、サインインとサインアップボタンを使いたい場所に配置するだけです。サインイン時にのみレンダリングしたいものがある場合は、signedinコンポーネントでラップします。サインアウト時にのみレンダリングしたいものがある場合は、signedoutコンポーネントでラップします。
そのユーザーボタンは、クリックするとユーザーの全情報を表示する素敵な小さなメニューで、サインアウトしたり、使用しているメールアドレスを確認したり、プロフィールを設定したりできます。すべてが組み込まれています。エンタープライズケースについては、彼らはすべてのSSO料金を撤廃しました。
あなたご存知の有名なSSO攻撃、SSOをオンにすると高すぎる料金を請求する企業を批判する恥の壁があります。彼らはそれをしません。そして彼らは認証会社なのです。普通ならそれをすると予想されるところです。一般的に、彼らの価格設定は非常に公平です。
特に、一度サインインした後24時間後に戻ってこなかった人たちを月間アクティブユーザーとしてカウントしないことを考えると。そのため、誰も変換しない大量のトラフィックのスパイクで多額のコストがかかる心配をする必要はありません。なぜなら、それらのユーザーは数字にカウントされないからです。素晴らしいですよね。とても素敵なことであり、もっと多くの企業がこのようなことをしてほしいと思います。本当に素晴らしいことです。認証が必要なら、今日soyb.link/clerkでチェックしてみてください。
これは私が問題を起こすことになるビデオの一つですが、気にしません。なぜならこれはあなたたちが聞く必要のある重要な意見だからです。完全に透明にしておく必要があります。これが取り上げられる特定の理由が一つあります。T3 Chatについては、何らかの理由でここにいるのに知らないとしたら、それは印象的でしょう。T3 Chatは私が既存のものに満足していなかったために構築したAIチャットアプリです。モデルが悪いわけではありません。
特に、ClaudeやOpenAIで行われているほとんどのこと、特にOerモデルは素晴らしいです。問題は彼らのUIがあまり良くないことでした。すでに彼らのUIを批判する動画を出しているかもしれません。もしまだなら、お楽しみに。重要なのは、このレイヤーに満足していなかったということです。理解すべき重要なことは、ウェブサイトはラッパーだということです。
chat GPTサイト、chatgbt.comは、OpenAIが提供するさまざまなAIモデルのラッパーです。T3 chatによる私のレイヤーは、それらすべてのものの異なるラッパーです。私たちは皆、モデルとその動作をラッピングしています。これらのラッパーの品質が重要なのです。そしてT3 Chatはこれらのラッパーを書いた最初の例ではありません。
ここで私の会社、スタートアップのPingのホームページに行くと、4つのものがあります。すべてのLLMのラッパーであるT3 chat、S3とR2と私たちが行っている他のハイブリッドなものの一種のラッパーであるupload thing、画像管理のためのいくつかの異なる背景除去サービスのラッパーであるP thing（これは面白いことにupload thingのラップも行っています）、そしてping.ggがあります。これはクリエイターがライブコラボレーションを行うための高品質なHDビデオ通話を提供するためのWebRTCプロバイダーのラッパーです。これらのツールはすべてラッパーですが、ラッパーではないツールを示してほしいと思います。なぜなら、結局のところ、すべてはある種のラッパーだからです。
コンピュータの最も低いレベルまで行くと、このようになります。しかし、それは最も低いレベルではありません。なぜなら、これらの0と1の各々は、オン状態かどうかによって特定の値を持つシリコンを表しているからです。したがって、私たちはプロセッサに存在する値を示すバイナリでラップすることでこれを表現します。それから私たちはアセンブリと呼ばれるこれをインターフェースするための言語を発明しました。アセンブリは、デバイス、メモリ、システムで定義されているような値とレジスタとすべてのものにアクセスするための構文です。
もしCが登場したとき、「なぜCを使うのか？それはただのアセンブリの貧弱なラッパーではないか？自分でアセンブリコードを書くべきだ」と反応したとしたら、あなたはRoller Coaster Tycoonの開発者かFFmpegの開発者か、あるいは間違っているかのいずれかでしょう。
そう、Cの利点はアセンブリよりも書きやすいということだけではありません。実際、もっと先に進みます。Cの利点は、アセンブリが一つだけではなかったということです。MIPSがあり、x86アセンブリのような他のアセンブリもあり、現在ではARMアセンブリがあります。Cが存在する必要がないと思われるとき忘れがちな利点は、Cのような一つのレイヤーがあることで、このレイヤーが同時にさまざまな異なるものをすべてサポートできるということです。
私たちはこの一つの巨大な共有抽象化を持っています。それはただのラッパーですが、ARMアセンブリにとっても、MIPSにとっても、x86にとっても、ただのラッパーなのです。このラッパーは、コードでの作業における開発者体験を意味のある形で向上させるからこそ価値があります。コードが読みやすく、書きやすく、レビューしやすく、維持しやすくなるからです。
そして、これは異なるアセンブリタイプにポートするために使用できるシンプルなポータブルレイヤーであることを意味します。これは大きな勝利です。アセンブリを書くのがどれだけ上手くても、すべてのプラットフォームで動作するこのような共有言語を持つことは非常に価値のあることです。だからこそJavaはそれをさらに推し進めるためだけに存在したのです。
Javaの目標は、ここにあるものよりもさらに異なる環境で、同じコードを実行し、同じアプリケーション体験を持つことができる抽象化でした。当時のBlackberryや他の貧弱なスマートフォン向けの奇妙で難解なプラットフォーム、ウェブページに埋め込むためのプラットフォームなどです。Javaは、再コンパイルさえせずに書けるコードを持つことができるという点で素晴らしかったのです。
なぜなら、少なくともCでは、私のコード、つまりCコードを取って再コンパイルし、すべての異なるプラットフォームと互換性のあるアセンブリを出力しなければならないからです。より高いレベルの抽象化としてのJavaは、効果的にCをターゲットにすることができます。なぜなら、Cには置きたいと思うすべての異なる場所でJavaのためのランタイムが書かれているからです。
ターゲットとするプラットフォーム用のJavaランタイムがある限り、コンパイルさえ必要ありません。コードをそのランタイムに投げるだけで、それが処理してくれます。これは魔法のようなものです。そして、その魔法は一度だけ書いたコードが複数の場所で動作するからだけではありません。魔法は、これらの抽象化を交換できることです。
ここにJavaランタイムがあります。Javaランタイムはかなり良いです。素晴らしいわけではありませんが、特に当時としては信じられないほど素晴らしかったです。しかし、より高速なJavaランタイムを作るために多くの開発がなされてきました。Java世界での最大のイノベーションの一つはGrowlでした。これはより高速なランタイムであり、Javaコードでうまく動作します。
そして、あなたのランタイムをGrowlや、コードをより良く、より速く、よりポータブルにするためのランタイムレイヤーで起こる他のどんな変化にも交換することができます。この抽象化が存在するため、ユーザーのコードが存在する場所をより良くするための抽象レイヤーでできることがたくさんあります。
この抽象化によって、Javaは少なくとも理論的には書きやすくなったので、これは素晴らしいことです。私たちは多くの教訓を学ばなければなりませんでした。しかし、それは同時に、このレイヤーが改善され、どちらの側も変更を必要とせず、両方の側が意味のある勝利を見ることができることを意味します。これは多くの技術に当てはまります。これはReactにも当てはまります。
例えば、React Nativeは、Reactのように感じられ機能する構文ですが、それらのネイティブな動作との非常に複雑なバインディングレイヤーを持たなければなりません。そのバインディングレイヤーは過去10年間で大きく変化し、現在ははるかに高速になっています。そして、ほとんどの場合、React Nativeパッケージのバージョンを上げるだけで、これらの大きなパフォーマンスの勝利を得ることができます。
最初からパフォーマンスが理想的ではなかったからこそ、それらのものが必要なだけだという反論をすることができます。しかし、私はこう言いたいです。書くのがとても難しいために存在しないアプリよりも速いアプリはありません。そこで、今私たちが話そうとしているT3 chatに話を戻しましょう。
T3 chatはVerscell AI SDKの抽象化であり、それはopen AI SDK標準の抽象化です。その標準はS3のAPIと同じくらい標準的です。そしてもしS3のAPIが標準だと思うなら、自分でupload thingを他のものに構築しようとしてみてください。それが標準ではないことを約束します。せいぜい最も曖昧な意味でのみ標準です。
しかし、open AI SDK標準があるため、それがVerscellのAI SDKが構築している基盤です。どのAILMプロバイダーでもそのOpenAI標準をサポートすることができます。OpenAIが明らかにサポートしていますが、あなたたちが聞いたことのある会社としてはAnthropicや、本当に詳しい人なら、DeepSeek、あるいはもしここに十分長く滞在しているなら、GrockがあるでしょうKではなくQです。違いがあります。
ここで素晴らしいのは、私たちがVerselliSDKを抽象化レイヤーとして操作しているため、これらのプロバイダーと連携するための単一の構文、単一の方法を持っていることです。それにより、私たちはそれらすべてをサポートできます。そして私たちはそれを行っています。私が全てのモデルをサポートすると言うとき、ほぼそのとおりです。
このビデオが公開される頃には、もっと増えているかもしれません。私たちのスケジュールを考えると、ほぼ確実です。しかし、これらすべてのモデルは、上に抽象化があるためサポートできるのです。私たちはこれらすべてのものをラップしているだけですか？ある意味では、はい。しかし、正しいものをラップしていることで、より良い体験、より多くの移植性、そして最も重要なことに、ユーザーにとってより多くの選択肢を提供することができます。
ラッパーであることは悪いことではありません。もう一つの面白い例は、最初は私たちが何をしているのかわからないと言われたupload thingです。upload thingはかなりのラッパーです。なぜならupload thingはファイルストレージソリューションだからです。そしてupload thingパッケージはS3をラップしていません。
それはupload thingのインフラをラップしています。upload thingのインフラはかなり複雑です。私たちは独自のインジェストを持っており、そのインジェストサーバーは多くの異なることを処理しなければなりません。データベースレイヤーをラップし、それを最新の状態に保つ必要があります。ファイルが入ってくるのを処理し、ユーザーがアップロードに問題がある場合に備えて、通常はReddusのようなものを通じてローカルの状態を維持する必要があります。
停止して再開し、インターネットが切れるなど、多くの問題があります。それらは最悪です。これは今どこかでサービスされなければなりません。そうです、私たちはデフォルトでS3を通じてそれらを提供しています。しかし、S3はファイルのための最良の場所ではないことが多いです。ファイルが十分にアクセスされる場合、S3の出力コストは信じられないほど高いです。
そのため、特定のしきい値に達すると、一部のファイルをCloudflare R2に保管します。もしupload thingのような抽象化がなければ、私たちが現在できるようにファイルごとに適切なことを行うことはほぼ不可能でしょう。もし直接S3を使用するなら、実際にトラフィックを処理している場合、より多くのお金がかかるでしょう。なぜならS3を通じて直接それらのファイルを提供するのは高価だからです。
そしてそうでなければ、あなた自身が独自のクラウド形成呼び出しや、そのキャッシュレイヤーの処理でS3をラップしています。CloudFrontや他のキャッシュを前面に置いていなければ、直接S3にアクセスすることはできません。そうすれば大変なことになります。しかし、私たちがそれを処理することを許すなら、あなたは大変な思いをせずに済みますし、私たちはあなたのためにそれを処理します。私たちはまた、クラウドを離れなければできない最適化も処理します。
ファイルシステムのコスト、パフォーマンス、および全体的な特性を最大限に活用するために、S3を離れ、AWSを離れる必要があります。R2は遅いです。R2はファイルを保持するのにより高価ですが、それらが保持されると提供するのははるかに安価です。したがって、ファイルがどのようにアクセスされるかの特性に応じてファイルがどこに行くかを最適化することは、ラッパーとしてのみ行うことができる抽象化です。
ラッパーであることで、私たちはラッパーでなければできないことを可能にしています。だから、あなたのものをラップすることは、それを持っていける柔軟性のためだけでなく、後から変更できる能力のためだけでなく、より良いのです。また、それは他の方法ではできない強力な動作を可能にします。
Javaがコードを変更せずに複数の環境で実行できるのと同じように。T3 chatが変更なしに異なるモデルプロバイダーをすべてサポートできるのと同じように。upload thingは変更なしに最適な場所にファイルを配置することを可能にします。一緒に言ってください。変更なし。抽象化は良いものです。
ラッパーは私たちが使うすべてのツールやテクノロジーを強化するものです。スタックトレースを見て、あなたが使用しているプログラムがいかに深くさまざまなものをラップしているかを見たら、より良いAPIでブラウザ標準をラップするウェブ開発者をからかうのは非常に愚かだとわかるでしょう。なぜなら、Rustのようなものであなたが使っている平均的なパッケージは、ネイティブレイヤーまで下がる15以上のレイヤーのものをラップしているからです。
そしてこれらのラッパーは良いものです。今日私たちが使用しているツールがとても上手くパッケージ化され、バンドルされ、ラップされているのは素晴らしいことです。ほとんどの場合、開発者はもうこれらの低いレベルに降りる必要がありません。Javaのようなツールがよくなるにつれて、より複雑なツールの必要性は減少します。
そして時間が経つにつれて、これらの抽象化がどんどん良くなると、気にしなければならないことはどんどん少なくなります。それは存在しなくなるという意味ではありません。特定の方法で最適化できないという意味ではありませんが、ここの下のセクションでは長い間意味のあるイノベーションは起きていません。アセンブリコードを処理する方法やバイナリ値を保存する方法には意味のあるイノベーションはありませんでした。
いつか量子コンピューティングが来るかもしれませんが、おそらくそれはないでしょう。実際、私たちはもうそのレイヤーでイノベーションを起こしていません。Cと次のレイヤーでは、Rustのようなツールでいくらかイノベーションが起きています。それは見られて良いことです。なぜならそれはイノベーションが必要だからです。しかし最近まで、そのレイヤーさえ触れられていませんでした。
そして私たちはある意味でこのランタイムの世界に住んでいました。それが私たちが毎日働き、戦い、イノベーションを起こしている抽象化のレベルでした。それは悪いことではありません。私たちはCを学びたくないひどい、邪悪な、愚かな開発者だからこれをしたわけではありません。
この抽象化レイヤーで作業することがより生産的だからこれをしたのです。この低いエリアに住むツールを構築した素晴らしいエンジニアはたくさんいますが、彼らはもうそこで働いていません。彼らはスタックを上に上げました。なぜなら彼らはMIPSアセンブリとx86アセンブリの違いを知っていることを自慢することよりも、良いソフトウェアを提供することを気にしているからです。
良い開発者は特定のボックスに永遠に住むために戦いません。良い開発者は、彼らが構築しようとしているものに必要な場所に応じて上下に移動します。ここに住むべきだと言う開発者は、ここに住むべきだと言う開発者と同じくらい悪いです。あなたがやっていることに意味のある場所に行くべきです。
そして、ほとんどの人々がユーザー向けのアプリケーションを構築している場合、Cの中に住むことは全く意味がありません。それが、良くも悪くも、このレベル以下を見ることができない開発者が今たくさんいる理由です。それが悪いことだと思いますか？ある程度は。より多くの開発者がこれらのものがどれだけ深く行くのかを理解するのは良いことでしょう。そうすれば、なぜ特定のことが動作したり動作しなかったりするのか、そしてなぜ特定の方法でものごとを行うべきか行うべきでないかを理解できるでしょう。
しかしあなたはそれらの問題に遭遇するでしょう。そして、あなたがそれらの問題に遭遇していないなら、下のものをどれだけ良く知っているかは本当に重要ですか？抽象化は良いものです。ラッパーは素晴らしいものです。そしてもしあなたがこれをビジネス的な観点で考えているなら、T3 chatのようなものはOpenAIやAnthropicよりもはるかに粘り強い体験を持っています。なぜなら彼らはまだこれらすべてを自分たちで構築しなければならないからです。
OpenAIのサイトを見ると、OpenAIのサイトは彼らのモデルをラップしていますが、はるかに小さな方法でラップしています。あなたが得るのはこのようなものです。そして今、これらのそれぞれは独自の特別な方法でラップしなければなりません。なぜならラッパーは単に私たちが楽しみのためにやったことではないからです。
ラッパーはこれらの部分を適切に機能させるための必要な抽象化です。そしてこれを見て、「ええ、あなたはただラッパーを売っているだけです。chatgpt.comのような本物のサービスを使うべきです。それは全く同じものです。」と言うのは愚かです。「それはただのラッパーだ」という言い方がいつどこで聞かれたかによっては理解できないでしょう。なぜならCでさえただのラッパーだったからです。
そして今、人々は言います、「なぜあなたはそれらのラッパーをすべて使っているのですか？それをCで書くことができます。」あるいはさらに面白いのは、「なぜKotlinのようなものを使っているのですか？Java自体を書くことができます。」いいえ。これらのラッパーが存在する理由は、ネイティブレイヤーが提供していないものが必要であり、特定のネイティブレイヤーに依存したくないので抽象化が欲しいからです。抽象化は良いものです。
ラッパーは良いものです。それらを理解していないなら、文句を言うのをやめてください。そして、悪いラッパーの例があれば教えてください。私の経験では、ラッピングが悪いのではなく、ラッパーを構築した開発者が悪かったか、それを書いたときに悪いインセンティブや目標を持っていたのです。
ほとんどの場合、ラッパーは私たちが毎日持つ開発者体験の意味のある改善を表しています。そして私たちは「ラッパー」という言葉がどういうわけか魔法のように悪い言葉であるかのように話すべきではありません。それを理解したことはありませんし、これからも理解できないでしょう。それはすべてラッパーなのです。ラッパーについて気にできる唯一の理由は、あなたがどこかに線を引いて、「この線より上はダメなラッパーで、この線より下は本物だ」と言っているからです。
しかし、あなたがその線を引くとき、暗黙のうちにCはラッパーではないが、Javaはラッパーだと言っているのです。それは無意味です。絶対的な無意味です。気にしません。T3 chatは非常に成功しているサービスです。なぜなら私たちは存在するツール、テクノロジー、モデルのセットのための良いラッパーを構築したからです。
upload thingは良いサービスです。なぜなら私たちはAWS3とR2をはるかに消化しやすく、統合しやすく、維持しやすく、スケールしやすい方法でラップしているからです。これらのラッパーは素晴らしいものであり、私は理由があってそれらを構築しています。それらは実際の問題を解決します。そして私は、柔軟性が低い似たようなラッパーである代替品や競合サービスを誰かが示してくれることを望みます。なぜなら私が構築するラッパーは、私や他の人が持つ実際の問題を解決するためのより良い、より柔軟な方法だからです。
Little Fingerがここで言ったように、悪いラッパーは存在し得ますが、それらはラッパーだから悪いのではありません。それらは上手く機能しないから悪いのです。はい、あなたが話す人々は、追加の抽象化を提供しないラッパーを定義するでしょう。私はそれらの人々に、それが当てはまる単一のラッパーを示すよう挑戦します。なぜなら、もしそれがラッパーという用語の使い方であるなら、彼らは単に「私が理解していない抽象化」としてラッパーという用語を使っているだけです。
なぜなら、もし誰かが特定の方法で何かをラップする価値を見ることができないなら、それはあなたのためのものではありません。それは進みましょう。もし何かに対して持っている唯一の議論がそれがラッパーであるということなら、あなたはそのものを褒めているのです。なぜならそれについて他に何も問題を見つけられなかったからです。ツールの問題がそれがただのラッパーだということなら、それは問題ではありません。
それはただあなたがそれを理解していないということを意味します。もしあなたがT3 ChatやUpload thingのようなサービスや、他の多くの人が作った同様のラッパーについて文句を言いたいなら、実際の建設的な不満を出す方法を見つけるべきです。なぜなら「それはただのラッパーだ」と言うことは、あなたがそれを理解していないと言っていることだからです。
そして私はこの不満にとても疲れているので、今あなたたちは私がそれについて文句を言うのを聞かなければなりませんでした。私とそれらの人々の違いは、私は実際にそれらの人々に何が問題があるかについて具体的な考えを形成できたということです。そして彼らの問題は、彼らの脳が完全に発達していないということです。
これらの人々について言うことは他にありません。彼らはArch Linuxの設定を磨くことに戻り、ソフトウェアを出荷することはありません。なぜなら私はこれらの不満を言う人のタイプを正確に知っており、彼らは本物の開発者ではないからです。そしてもしあなたが使いたくないと文句を言っているラッパーについて、そのような人々を扱っているなら、彼らにこのビデオを送り、この最後の部分が彼らのためのものであることを確認してください。
それが私の言うことのすべてです。次回まで、ソフトウェアのラッピングを続けてください。
コメント