epics 2025-07-16 | 親コメント | トピック: サム・アルトマンのスタートアップ・プレイブック日本語訳 (latpeed.com) ありがとうございます〜 jhk0530 2025-07-16 | 親コメント | トピック: サム・アルトマンのスタートアップ・プレイブック日本語訳 (latpeed.com) latpeedのリンク先の505studioは、mobeah(https://x.com/mobeahmi)のことだと思います。単にご本人… dnflajt3 2025-07-16 | 親コメント | トピック: 過度なJavaScript中心の開発がWebを壊している (jonoalderson.com) React や Vue のようなものがなければ、 同じ機能を実装するにしてもコードをもっと複雑に書かなければならないのでは? 特にポップアップを扱うとき、props を 1 つ渡すだけでも純粋な JavaScript でやるとコードがかなり複雑になります。 こんな簡単なことでもコードが複雑になるなら、本当に 複雑な機能は実装しにくくなりますよね ffdd270 2025-07-16 | 親コメント | トピック: DogWalk - 無料のオープンソース・カジュアル・インタラクティブストーリーゲーム (blenderstudio.itch.io) https://godotengine.org/article/godot-showcase-dogwalk/ Godotブログのインタビューと https://studio.blender.org/blog/our-workflow-with-blender-and-godot/ Blender開発チームがGodotとのワークフローをどのように構築し、アセットをどう管理したのかについて書かれた記事がとても面白いので、強くおすすめします。 znjadong 2025-07-16 | 親コメント | トピック: サム・アルトマンのスタートアップ・プレイブック日本語訳 (latpeed.com) https://drive.google.com/file/d/… ここでは番号を入力せず、そのままご覧ください。 kuthia 2025-07-16 | 親コメント | トピック: サム・アルトマンのスタートアップ・プレイブック日本語訳 (latpeed.com) この記事を書かれた方は、スリーブロックス.エーアイという会社のアン・グァンソプ代表なのでしょうか? blizard4479 2025-07-16 | 親コメント | トピック: サム・アルトマンのスタートアップ・プレイブック日本語訳 (latpeed.com) 携帯電話番号を収集する理由は何でしょうか? honglu 2025-07-16 | 親コメント | トピック: サム・アルトマンのスタートアップ・プレイブック日本語訳 (latpeed.com) 読みたいですが……受け取るには番号を入力しなければならないので、ためらってしまいます。 xguru 2025-07-16 | 親コメント | トピック: Comcastが嫌で、自分たちで地元の光ファイバーインターネット会社(ISP)を立ち上げた2人 (arstechnica.com) アメリカは国土が広いからか、こういう試みも可能なんですね。興味深いです。 yangeok 2025-07-16 | 親コメント | トピック: Apple、MLXにCUDAサポートを追加中 (github.com/ml-explore) いい話ですね(笑)。早くCUDAに対応して、Macでも高速学習ができるようになってほしいです〜! fastkoder 2025-07-16 | 親コメント | トピック: Claude Squad - マルチAIコードエージェント向けターミナルワークスペース管理ツール (github.com/smtg-ai) 結局、分岐したブランチをどうマージするかという問題点を正確にあらかじめ認識して、開発を完了してしまうんですね ng0301 2025-07-15 | 親コメント | トピック: JavaScriptにおける通常の関数とアロー関数の違い、いつどの構文を使うべきか (jrsinclair.com) 根本的な点と同じくらい、prototype の有無も ... 生成される高階関数のリファレンス方法も ... slowandsnow 2025-07-15 | 親コメント | トピック: 過度なJavaScript中心の開発がWebを壊している (jonoalderson.com) 必然的な複雑さだ。昔のような単純なテンプレートHTMLではないものを rikko 2025-07-15 | 親コメント | トピック: ツールをスタンドアロンの静的バイナリとして配布すべき理由 (ashishb.net) 単純な推論用に使うCPUランタイムならまだ少しはマシですが、最近求められるLLMサービスのせいで、トラフィックもトラフィックなりに、容量も容量なりに増えていくので、コスト計算するときは悪態をつきたくなります(笑) nicewook 2025-07-15 | 親コメント | トピック: ソフトウェアを素早く開発する私なりの方法 (evanhahn.com) 共感できる話が多いですね。 コメントも良いですが、こうして誰かが整理して語り、つまり場を設けてくれると、それに対する反論や支持、補足を経て、より完成度が高まるのだと思います。 追記。最近「退屈な技術」という表現をよく見かけますが、英語では boring technology なんですね。 tested 2025-07-15 | 親コメント | トピック: AIはオープンソース開発者を遅くする。Peter Naurはその理由を説明できる (johnwhiles.com) > 逆に、「とにかく動けばいい」という प्रकारの作業であれば、AIの活用が効率的な場合もある。 開発者に限った話ではありませんが、さまざまな志向を持つ人がいる中で、たまたま開発者をしていて、コードを書いたり読んだりすることを嫌ったり怖がったりし、体系的な構造や保守性の観点で解釈するよりも、とにかく動けばいいというマインドであるほど、AIへの依存や盲信が強いように感じます。違っていたらすみません eususu 2025-07-15 | 親コメント | トピック: ツールをスタンドアロンの静的バイナリとして配布すべき理由 (ashishb.net) pytorch+cuda 依存関係で、バージョン違いだけで引っかかるパッケージがあって……本当にひどいです。 大した機能もないのに、小さなデーモンごとに依存関係が2GB近く入ります…… tsboard 2025-07-15 | 親コメント | トピック: 300人のユーザー向けにセルフホストLLMサーバーを構築できるか? (reddit.com) 私も必要に迫られて、あの貴重な H100 GPU を4枚使いながら RAG ソリューションを作っていますが、ハードウェアへの直接投資だけでなく、電気代や各種冷却ソリューションのコストなどまで考えると、結局は API を呼び出すほうがはるかにましなのでは、という考えがずっと頭をよぎっていました。 私も最初は Ollama でテストを始め、同時接続3人すらまともに捌けないことを確認してすぐに vLLM に移り、あれこれしながら RAG ソリューションを構成したのですが、(同時接続10人を想定)これだけでもすでに H100 GPU を2枚ほぼフルで使う必要があります。埋め込み処理や検索処理も vLLM で立ち上げて使っていますが、H100 を4枚でも本当にぎりぎりでした。1枚あたりの VRAM が 90GB ほどあるのにこの状態です。 もちろん私は AI にそれほど詳しいわけでもなく、部署で必要なものと社内のセキュリティ規定をあれこれ合わせていくうちに、とにかく手探りでやっているだけなのですが……これで合っているのかと思ってしまいます。ChatGPT Enterprise でしたっけ? 本当に破格の価格設定だと思います。 eususu 2025-07-15 | 親コメント | トピック: AIはオープンソース開発者を遅くする。Peter Naurはその理由を説明できる (johnwhiles.com) 私も似たような考えを持っていましたが、どう表現すればいいのか曖昧でした。 メンタルモデル、いいネーミングですね。時々使ってみようと思います。 odlwlkiime 2025-07-15 | 親コメント | トピック: 経験豊富なオープンソース開発者の生産性に与える「AIのインパクト」を測定する (metr.org) 時給150ドル?の時点で、もう変数統制からしてwwwww コメントをさらに読み込む
ありがとうございます〜
latpeedのリンク先の505studioは、mobeah(https://x.com/mobeahmi)のことだと思います。単にご本人…
React や Vue のようなものがなければ、 同じ機能を実装するにしてもコードをもっと複雑に書かなければならないのでは? 特にポップアップを扱うとき、props を 1 つ渡すだけでも純粋な JavaScript でやるとコードがかなり複雑になります。 こんな簡単なことでもコードが複雑になるなら、本当に 複雑な機能は実装しにくくなりますよね
https://godotengine.org/article/godot-showcase-dogwalk/
Godotブログのインタビューと
https://studio.blender.org/blog/our-workflow-with-blender-and-godot/
Blender開発チームがGodotとのワークフローをどのように構築し、アセットをどう管理したのかについて書かれた記事がとても面白いので、強くおすすめします。
https://drive.google.com/file/d/…
ここでは番号を入力せず、そのままご覧ください。
この記事を書かれた方は、スリーブロックス.エーアイという会社のアン・グァンソプ代表なのでしょうか?
携帯電話番号を収集する理由は何でしょうか?
読みたいですが……受け取るには番号を入力しなければならないので、ためらってしまいます。
アメリカは国土が広いからか、こういう試みも可能なんですね。興味深いです。
いい話ですね(笑)。早くCUDAに対応して、Macでも高速学習ができるようになってほしいです〜!
結局、分岐したブランチをどうマージするかという問題点を正確にあらかじめ認識して、開発を完了してしまうんですね
根本的な点と同じくらい、
prototypeの有無も ...生成される高階関数のリファレンス方法も ...
必然的な複雑さだ。昔のような単純なテンプレートHTMLではないものを
単純な推論用に使うCPUランタイムならまだ少しはマシですが、最近求められるLLMサービスのせいで、トラフィックもトラフィックなりに、容量も容量なりに増えていくので、コスト計算するときは悪態をつきたくなります(笑)
共感できる話が多いですね。
コメントも良いですが、こうして誰かが整理して語り、つまり場を設けてくれると、それに対する反論や支持、補足を経て、より完成度が高まるのだと思います。
追記。最近「退屈な技術」という表現をよく見かけますが、英語では boring technology なんですね。
> 逆に、「とにかく動けばいい」という प्रकारの作業であれば、AIの活用が効率的な場合もある。
開発者に限った話ではありませんが、さまざまな志向を持つ人がいる中で、たまたま開発者をしていて、コードを書いたり読んだりすることを嫌ったり怖がったりし、体系的な構造や保守性の観点で解釈するよりも、とにかく動けばいいというマインドであるほど、AIへの依存や盲信が強いように感じます。違っていたらすみません
pytorch+cuda依存関係で、バージョン違いだけで引っかかるパッケージがあって……本当にひどいです。大した機能もないのに、小さなデーモンごとに依存関係が2GB近く入ります……
私も必要に迫られて、あの貴重な H100 GPU を4枚使いながら RAG ソリューションを作っていますが、ハードウェアへの直接投資だけでなく、電気代や各種冷却ソリューションのコストなどまで考えると、結局は API を呼び出すほうがはるかにましなのでは、という考えがずっと頭をよぎっていました。
私も最初は Ollama でテストを始め、同時接続3人すらまともに捌けないことを確認してすぐに vLLM に移り、あれこれしながら RAG ソリューションを構成したのですが、(同時接続10人を想定)これだけでもすでに H100 GPU を2枚ほぼフルで使う必要があります。埋め込み処理や検索処理も vLLM で立ち上げて使っていますが、H100 を4枚でも本当にぎりぎりでした。1枚あたりの VRAM が 90GB ほどあるのにこの状態です。
もちろん私は AI にそれほど詳しいわけでもなく、部署で必要なものと社内のセキュリティ規定をあれこれ合わせていくうちに、とにかく手探りでやっているだけなのですが……これで合っているのかと思ってしまいます。ChatGPT Enterprise でしたっけ? 本当に破格の価格設定だと思います。
私も似たような考えを持っていましたが、どう表現すればいいのか曖昧でした。
メンタルモデル、いいネーミングですね。時々使ってみようと思います。
時給150ドル?の時点で、もう変数統制からしてwwwww