jic5760 2026-01-11 | 親コメント | トピック: RSAは陥落した。 (threads.com) text out と korean out を見ただけでも、でたらめだと分かるのに… 論文と称しているものも、たった2ページしかない（おそらくAIで作られた）でたらめ… euphcat 2026-01-11 | 親コメント | トピック: フーリエ変換の不合理なほど優れた有用性 (joshuawise.com) いやでも本当にWikipediaを調べてみたら、ジョゼフ・フーリエがフーリエ変換を発表したのが1822年で、（それ以前の断片的な発表を除くと）FFTが定式化されて発表されたのが1965年、もう少し早いものでも1932年で、しかもガウスがFFTを記録していたのに発表しなかったのがなんと1805年なんだそうです。Gauss is gonna Gauss（ガウスはガウスしただけ）というコメントに納得するしかないですね… euphcat 2026-01-11 | 親コメント | トピック: フーリエ変換の不合理なほど優れた有用性 (joshuawise.com) 「HNの意見」より: 6人の子どもがいながら、あれほど生産的だったとは驚きだ ...? cshj55 2026-01-11 | 親コメント | トピック: Vibe Kanban: AIコーディングエージェントの作業を並列管理するカンバンボード (vibekanban.com) ありがとう、ありがとう。とても助かりました t7vonn 2026-01-11 | 親コメント | トピック: Google AI StudioがTailwind CSSのスポンサーに (twitter.com/OfficialLoganK) 年間100万ドル以上の支援があるのに、プロジェクトが維持できないというのはちょっと不思議ですね.. t7vonn 2026-01-11 | 親コメント | トピック: Oh My Zshは不要なオーバーヘッドを追加する (rushter.com) ターミナルを頻繁に使うなら、omz によって追加される遅延はかなり不快です。 zxcv123 2026-01-11 | 親コメント | トピック: Oh My Zshは不要なオーバーヘッドを追加する (rushter.com) 開発者らしいというか、どうでもいい数 ms くらいで大騒ぎしてるな（笑） pmnxis 2026-01-11 | 親コメント | トピック: Embassy - Rustとasyncベースのモダンな組み込みフレームワーク (github.com/embassy-rs) embassy-rs を使って STM32G030C8T6 で製品開発から量産までやってみましたが、使っていて欠点はいくつかあります。 一般的ではない HAL にアクセスするときは、結局 RTIC フレームワークを使っていたときのようなアプローチが必要になります。 async のため、メモリ効率が悪くなる可能性が高く、注意が必要です。 フラッシュメモリが 32KB 以下の環境で開発するにはかなり制約があります。(log+debug symbol など) NRF/STM/ESP/RP を外れたエコシステムで開発しようとすると、事実上かなり難しいです。 embassy-rs で Rust embedded を触ってみるのは良いですが、その後の量産やキャリア面での改善を望むなら、RTIC をもう少し触ってみるのがよさそうです。 一方では、advanced rust arduino のようになってアクセスしやすいことが、かえって難易度の高い開発をするときに厄介な状況を生む問題が発生するのではないかと懸念しています. yangeok 2026-01-11 | 親コメント | トピック: Wirebrowser - ブラウザ内部解析向けCDPベースのネットワーク・メモリ統合デバッグツール (github.com/fcavallarin) 難読化されたjsファイルも、フォーマットまできれいにしてくれると、さらに便利だと思います。 darjeeling 2026-01-10 | 親コメント | トピック: Anthropicエンジニアリング: AIエージェント評価（Evals）の実践ガイドと方法論 (anthropic.com) 内容が良かったので、韓国語訳を追加します。 https://rosettalens.com/s/ko/demystifying-evals-for-ai-agents kimjoin2 2026-01-10 | 親コメント | トピック: フーリエ変換の不合理なほど優れた有用性 (joshuawise.com) 工業数学で本当に頭がおかしくなりそうだった変換シリーズ…（泣） aer0700 2026-01-10 | 親コメント | トピック: フーリエ変換の不合理なほど優れた有用性 (joshuawise.com) 以前、ノイズ除去や反復パターン除去のロジックを書いたときに使った記憶がありますね。 似たようなものを最近はオートエンコーダで実装しているようです。 ndrgrd 2026-01-10 | 親コメント | トピック: Cが最良だ（2025） (sqlite.org) どうせPRも受け付けないプロジェクトなんだし……自分たちが使いたいものを使ってるってことですね sudosudo 2026-01-10 | 親コメント | トピック: Dell、消費者はAI PCに関心がないという現実を認める (pcgamer.com) 最近の新技術は ai というキーワードだけを使いたがっていて、むしろ技術そのものは退化しているように思える…… devjeonghwan 2026-01-09 | 親コメント | トピック: 2026年のWeb開発で新たな標準になる変化 (blog.logrocket.com) LLMの性能がますます向上するにつれて、最終的にはあらゆる職種が代替されるのでしょうが、Web開発の分野は近いうちに代替されそうな気がします。 nomak 2026-01-09 | 親コメント | トピック: Craigslistはインターネットに残された最後の本物の場所 (wired.com) Craigslist がまだ生きていたんですね？！ dongho42 2026-01-09 | 親コメント | トピック: Vibe Kanban: AIコーディングエージェントの作業を並列管理するカンバンボード (vibekanban.com) わずか13分前に付いたこちらのリポジトリのコミットを見ると https://github.com/BloopAI/vibe-kanban/… 修正するつもりはなさそうですね（笑）.. dongho42 2026-01-09 | 親コメント | トピック: Vibe Kanban: AIコーディングエージェントの作業を並列管理するカンバンボード (vibekanban.com) 以前少し試してみたのですが、https://github.com/BloopAI/vibe-kanban/issues/431 のような issue が放置されたまま修正されていなくて、実運用は難しいと感じました……。コミット名も「完了しました」「修正されました」「これから確認してみます」といった感じで出てくるので 😅 cherrycoder 2026-01-09 | 親コメント | トピック: Tailwindの開発元、エンジニアリングチームの75%を解雇 (github.com/tailwindlabs) 人員削減は結果にすぎず、本当の原因は収益モデルの崩壊でしょう。オーナーの立場からすれば、AIのおかげで少人数でもプロジェクトを回せる時代になったうえ、ちょうど収益まで悪化したのだから、75%削減は合理的な判断だと思います。 nemorize 2026-01-09 | 親コメント | トピック: ユーザーが直接Issueを作成できない理由 (github.com/ghostty-org) ディスカッションとIssueに違いがあるからではなく、単に別々のタブに分かれているほうが好みに合っていたのでしょう。 Issueタブに一種のToDoリストとディスカッションの両方を投稿し、それをタグで管理するのか、 vs IssueタブはToDoリスト専用、ディスカッションはディスカッション専用として使うのか コメントをさらに読み込む
text outとkorean outを見ただけでも、でたらめだと分かるのに…論文と称しているものも、たった2ページしかない（おそらくAIで作られた）でたらめ…
いやでも本当にWikipediaを調べてみたら、ジョゼフ・フーリエがフーリエ変換を発表したのが1822年で、（それ以前の断片的な発表を除くと）FFTが定式化されて発表されたのが1965年、もう少し早いものでも1932年で、しかもガウスがFFTを記録していたのに発表しなかったのがなんと1805年なんだそうです。
Gauss is gonna Gauss（ガウスはガウスしただけ）というコメントに納得するしかないですね…「HNの意見」より:
...?
ありがとう、ありがとう。とても助かりました
年間100万ドル以上の支援があるのに、プロジェクトが維持できないというのはちょっと不思議ですね..
ターミナルを頻繁に使うなら、omz によって追加される遅延はかなり不快です。
開発者らしいというか、どうでもいい数 ms くらいで大騒ぎしてるな（笑）
embassy-rsを使って STM32G030C8T6 で製品開発から量産までやってみましたが、使っていて欠点はいくつかあります。一般的ではない HAL にアクセスするときは、結局 RTIC フレームワークを使っていたときのようなアプローチが必要になります。
asyncのため、メモリ効率が悪くなる可能性が高く、注意が必要です。フラッシュメモリが 32KB 以下の環境で開発するにはかなり制約があります。(
log+debug symbol など)NRF/STM/ESP/RP を外れたエコシステムで開発しようとすると、事実上かなり難しいです。
embassy-rsで Rust embedded を触ってみるのは良いですが、その後の量産やキャリア面での改善を望むなら、RTIC をもう少し触ってみるのがよさそうです。一方では、advanced rust arduino のようになってアクセスしやすいことが、かえって難易度の高い開発をするときに厄介な状況を生む問題が発生するのではないかと懸念しています.
難読化されたjsファイルも、フォーマットまできれいにしてくれると、さらに便利だと思います。
内容が良かったので、韓国語訳を追加します。
https://rosettalens.com/s/ko/demystifying-evals-for-ai-agents
工業数学で本当に頭がおかしくなりそうだった変換シリーズ…（泣）
以前、ノイズ除去や反復パターン除去のロジックを書いたときに使った記憶がありますね。
似たようなものを最近はオートエンコーダで実装しているようです。
どうせPRも受け付けないプロジェクトなんだし……自分たちが使いたいものを使ってるってことですね
最近の新技術は
aiというキーワードだけを使いたがっていて、むしろ技術そのものは退化しているように思える……LLMの性能がますます向上するにつれて、最終的にはあらゆる職種が代替されるのでしょうが、Web開発の分野は近いうちに代替されそうな気がします。
Craigslist がまだ生きていたんですね？！
わずか13分前に付いたこちらのリポジトリのコミットを見ると https://github.com/BloopAI/vibe-kanban/… 修正するつもりはなさそうですね（笑）..
以前少し試してみたのですが、https://github.com/BloopAI/vibe-kanban/issues/431 のような issue が放置されたまま修正されていなくて、実運用は難しいと感じました……。コミット名も「完了しました」「修正されました」「これから確認してみます」といった感じで出てくるので 😅
人員削減は結果にすぎず、本当の原因は収益モデルの崩壊でしょう。オーナーの立場からすれば、AIのおかげで少人数でもプロジェクトを回せる時代になったうえ、ちょうど収益まで悪化したのだから、75%削減は合理的な判断だと思います。
ディスカッションとIssueに違いがあるからではなく、単に別々のタブに分かれているほうが好みに合っていたのでしょう。
Issueタブに一種のToDoリストとディスカッションの両方を投稿し、それをタグで管理するのか、
vs
IssueタブはToDoリスト専用、ディスカッションはディスカッション専用として使うのか