> ClickHouse と StarRocks を比較した人がいるのか気になる。数か月前は StarRocks の結合性能のほうが良さそうに見えた
https://d2.naver.com/helloworld/1168674

5年前に公開ベータを開始したときに記事として投稿して、共同創業者が来てコメントも残していましたが、この間にものすごく成長しましたね（笑）
Supabase 公開ベータ開始 - オープンソースの Firebase 代替

ああ、私はOpenAIの将来ビジョンやBrowser+AIの改善されたイノベーションをけなすつもりはありません。
私が言いたいのは、OpenAIがそのような方向の試みをするのであれば、ChromiumやFirefoxのような主要ブラウザが公開されている以上、開発にあたって別途買収が必要な状況ではないと思う、ということです。

技術的な堀を築くうえで、買収は必須ではないという点です。
そのため、買収を検討するのであれば、技術面よりも市場シェアを通じた拡大のほうが主導的だと考えます。

単にChromiumベースの新しいブラウザを出すだけなら、Chromeから移行しないユーザーにとっては大きなメリットはありませんが、Chromeを買収すれば、ブラウザ市場の70%を占めるユーザーに対して、公式にアップデートを通じて自社のAIモデルサービスを体験させることができます。新規サービスの拡大障壁が画期的に下がります。

おっしゃる通り、Edgeが拡大していないという現象も、似た文脈に見えます。ブラウザ市場は本当に保守的です。OpenAIもこうした点を考慮してChromeの買収を検討しているのだと思います。だからこそ、OpenAIが「AI主導のウェブブラウジング」を開くという話は、OpenAIの能力そのものよりもChrome市場の影響のほうが大きいと見ています。

個人プロジェクトでとても重宝しています。

急にGodotが…？！

SupabaseはCRUDベースのシステムに適しているのが特徴で、APIサーバーを開発・運用しなくてもフロントエンドからCRUDを実装できるため、バックエンド開発の負担が少ないです。フロントエンドとバックエンドの開発者はAPI規約の代わりにテーブル定義でコミュニケーションし、機能としてはWebコンソール、認証、オブジェクトストレージを主に使っています。

フロントエンドがDBテーブルやビュー、関数定義に依存するため、データ変更の追跡にはやや気を配る必要があります。サーバーサイドのロジックが必要であれば、WAS/REST APIを別途構築するほうがよいと思います。

サイドプロジェクトをやりたい人には、いつも Supabase を第一候補としておすすめしています。Supabase がもっと成功してくれるとうれしいですね！

とても気に入っているサービスです。複雑なバックエンド/DBの設定なしに、フロントだけでサービスを作れます。
実際にサービスで活用しようと熱心に使っているのですが、私としてはむしろFirebaseより開発者体験が良かったです。
国内リージョンもあり、かなり寛大なフリーティアを提供していて良いです。self hostingもできますし。
シリーズDの調達とのことで良いニュースですね！ ただ、意見でも繰り返し言及されているように、持続可能な事業なのかという不安はあります。

個人的な考えでは、ベンダーのサーバーレスサービスを利用するのは危険ですが、コンテナを使って会社独自にサーバーレス環境を提供するのは良いと思います。サーバーレスをサービスではなく一つの概念として活用すると良さそうですね。

「バナナが欲しかったのにジャングルを持ってこられた」という言い回し、すごく面白いですね。

他の人たちがなぜこれほど批判しているのかをよく考えて、あなた自身も今後、思い上がってこんなくだらないことを言いふらさないでください。

コンピューティング技術に情熱を持って働いている方もたくさんいます。自分の考えや経験をもとに一般化しないでください。その方々に対して侮辱的ですから

以前とは違って、1人が担当しなければならない領域が広がることで生じる問題があります。

・以前に比べて、1人のエンジニアに期待される範囲が広く大きくなっているのは確かです。そして以前に比べて、はるかに多くの現実世界がコンピュータシステムの中に入り込み、それだけ抽象化と実装の難易度も急速に高まっています。現実でもっと大変な仕事を並べ立てたからといって、この仕事は大変ではない……と主張する必要があるのかなと思いますね

それを比較する必要はないでしょう。

•タイトルが「狂気じみている」と訳されていますが、単に今の状況が人を気力を失わせるようなものだと表現したかったのではないかと思います。 そして私は本文にもある程度共感します。昔に比べて、一人のエンジニアに期待されることの範囲が広がり、重くなったのは事実です。さらに、昔に比べてはるかに多くの現実世界がコンピューターシステムの中に入り込み、それだけ抽象化と実装の難易度も急速に高まっています。現実におけるもっと大変な仕事を並べ立てたからといって、この仕事は大変ではない……と主張する必要があるのかと思いますね。

それはまったく別の例では？ ロールバックすれば終わりってことですか？ あなた自身の経験がすべてではありません。大規模な作業をしたことがないのですか

・SW開発を単にコード生成やAPI生成をすることだと誤解しているようですが、SW開発の本質は現実を抽象化してプロトコルとインターフェースを作り、そこに当てはめていくことにあります。異なる方式で動くもの同士をつなぎ、ひとつのもののように動作させることにあるのです。これは思っている以上に複雑な知的活動であり、だからこそSWエンジニアを育成するのは思っている以上に難しいのです。今は人が多いと言いますが、その中で本当にきちんと働ける人材がどれだけいますか？ 大半はツールを一度使ってみただけですが、それがSWエンジニアの核心ではありません。

•製造業と直接比較することに意味はあるのでしょうか。産業の高度化がまだ十分ではないという観点から、その比較対象は製造業に見えるのですが。製造業のパラダイムでソフトウェア業を理解しようとすると、手工業や趣味の開発のように見えるかもしれませんが、逆にこうした部分こそがソフトウェア開発ならではの柔軟で創造的な文化を作り、それを足場に成長しているのだと思います。

•過去と比べて、1人のエンジニアに期待されることの範囲が広がり、大きくなったのは事実です。そして過去に比べて、はるかに多くの現実世界がコンピューターシステムの中に入り込み、それだけ抽象化と実装の難易度も急速に高まっています。現実世界のもっと大変な仕事を並べ立てたからといって、この仕事は大変ではない……と主張する必要があるのかは疑問です。

•環境は変わりました。昔より市場で開発者に対する期待と報酬が大きくなっている理由は、単に彼らの技術、熟練度、専門性だけだとは思いません。人類の生活にITが深く入り込むほどソフトウェアは重要になり、多くのインフラを支えています。各開発者の能力が高まったから報酬が増えているのではなく、単に仕事そのものが高くなったのだと思います。以前より重要になったからです。

下に適切な批判がいくつかありますね。コンピューティング技術のアクセシビリティが高いことにも、SWエンジニアの貢献は大きいです。アクセシビリティが高いからといって、プロになりやすいということでもありません。料理へのアクセス性が高いからといって、料理の専門家になるのは簡単ですか?

•学びやすい。そこは認めますが、参入障壁が低いことが専門性の低さを意味するわけではありません。他の産業群、特に製造業の他の技術職に比べて学びやすい理由は、開発自体が簡単だからというより、オープンソース文化やリスクの低さにあるのではないかと思います。先に述べた開発者の多様性という面でも、素早く学んでできる仕事がある一方で、専門性を基盤にしなければならない仕事もあるのです。

•少し絵を学んで漫画家のアシスタントに入ったからといって、自分はプロだと言って回るんですか。あるいは料理学校に少し通って厨房に就職したら、料理の専門家、シェフだと言って回るんですか。それと似たようなレベルですよ。あなたの言っていることは。そんなに簡単なものなら、それをプロとは呼ばないでしょう

Springで開発するとき、いちばん大変なことの一つは依存関係の循環だった気がしますね..
無限にお互いを初期化しながら、メモリリークで落ちてしまうあのもどかしさといったら...

状況に合わない批判をしていますね。元の投稿を書いた方は誰かを見下したわけでもないのに、むしろSWエンジニアという職種の価値をおとしめて見下しているのは、あなたではないですか？