すごい。sqliteがこうなったら、本当に大騒ぎになる気がする。もちろんセキュリティ脆弱性も一緒に。

パフォーマンスが劣化し、保守作業が難しくなり、障害発生時には管理ポイントが多く原因追跡が困難になります。
管理ポイントを減らし、運用工数を削減しようとする k8s 本来の目的とは正反対の状況が生じます。

ああ、もう少し記事を読んでみると、エディタが速くなるといった話もあって混乱していたようですね。

• tsc が10倍速くなる。つまり、ts -> js のトランスパイル時間が大幅に短縮される。
• VSCode のような ts で開発された大規模プロジェクトをロードするときの速度が非常に速くなる。つまり、ts の構文チェックなど、tsc の機能を共有するロジックが高速化されたという意味。
• VSCode 自体の動作速度が速くなったわけではない。
  そういう内容だったんですね。

VS CodeのCmd+KをCmd+Rに置き換えてしまってあまり使っていないのですが、みんな生産性向上の体験談を次々に語っていますね。ふう、乗り換えるべきかな

ギークニュースで何度も言及されていた本『フェニックスプロジェクト』でも、似たような話が出てきます。稼働率が100%に近づくほど、応答時間は指数関数的に長くなる、と。

私はこの記事で示されている内容に全面的に同意しつつ、ご指摘の問題にも同意します。
実際、私自身が悩んでいるポイントでもあります。
スクワッドごとに違いはありましたが、スプリントプランニングにチームメンバーを積極的に参加させると、ご指摘の問題は発生しませんでした。プロジェクトの文脈を共有し、スプリントごとに変化する状況を共有しながら、変わっていく作業を十分に認識できるよう努める一方で、作業はかなり細かく分解して分けてみようと求めました。
おっしゃる通り、管理の観点で進捗状況、作業速度の測定、予期しない状況への対処、作業内容が意図通りにならなかったときの機会費用を考えると、細かく分けたほうが結局はうまく進むことが多いですね.

理解できない。アカデミック水準どころか、小学生のコーディング水準にも達していないものを、なぜ共有するのか……

• ライフサイエンス分野の従事者として、簡単に使ってみた結果を共有したい。

> Research mode は2種類用意されている。

1. Quick summary

• 所要時間は約5〜6分程度（4070 ti super、16GB基準、Mistral および Gemma 3:12b）
• ハルシネーションがあるため Reference を直接生成するが、文書内でリンクが張られる Ref は出典が明確なようだ。
• 質問に対する答えを 新技術 に焦点を当てて回答しようとする意図がある。特に AI と関連付けようとする。

2. Detailed Report

• 所要時間は約1時間（4070 ti super 16GB、Gemma 3:12b）
• 1本のレビュー論文を作ってくれるようなもの。ただし Reference が大幅に減ってしまう問題がある。内容が正しいとしても根拠を示せないので、多少の改善が必要だ。（おそらく反復処理を行って文章のクオリティを高めているようだが、この過程で Ref link が失われているように見える。）
• ただ、確かに Quick summary よりはクオリティの高い内容を提供する。

Config ファイルではさまざまな設定が可能。検索するデータベースを PubMed のみに限定して、資料のクオリティをさらに高めることができる。一度に検索するテキストや、RAG 使用時にどれくらいのチャンクを作るかも設定できる。

現在 0.01V であることを考えると、Local マシンでここまでのレポートを作り出せるのは非常に驚きだ。特に生命科学の分野では Chatbot が 一般化された記述 を使うことが多いが、このプログラムで作成されたレポートは非常に科学的な記述を用いる。

このプログラムは現在日本語をサポートしていない。質問を日本語でしてもレポートは英語で出力される。
また、PDF エクスポートで PDF ファイルとして回答を受け取る際、日本語が表示されない問題がある。

レポート生成中に Ref が消える問題と、ハルシネーションを起こす問題さえ解決されれば、本当に強力なツールだと思う。

www

Obsidianの多数のプラグインに疲れてしまい、
Reflectに乗り換えましたが、大満足しています

いつ頃からかTSに触ることが少なくなっていたけど、こういうニュースを見るとまた気になってきますね？

だから私は金曜午後は、個人開発の時間として完全に空けてあります！

このコメントには強く共感します。技術的な部分に対するマイクロマネジメントが発生するリスクがありました（あります）。本当に簡単ではありません。

正規表現対応を捨てたうえで ripgrep より2倍しか速くないのなら、活用度はやや低いですね。
私は普通に、正規表現が使える ripgrep を引き続き使うと思います。

GOAT..やばい

中国の躍進、すごいですね

個人的には、ts は場合によって型がとても複雑になってしまって……ほとんど諦めるようなケース（そのまま any で書いてしまう）もあるのですが、やはり言語への理解が足りないからなんでしょうか？ 状況によっては、本当に赤線を消すためだけにかなり時間を無駄にしてしまいます。

業務を80%、余白を20%確保しようとしていますが、どんな基準で決めるべきか…毎回悩みますね。単純に時間ベースで考えるべきなのかとも思います。

上海に一時1年ほど住んでいたときに杭州へ遊びに行ったことがあったのですが（そのときは何かの印象公演のようなものを見るために）、街もきれいで西湖の風景も良くて、本当に住みやすそうだと思っていました。今では企業するにも良い場所になったようですね。

韓国語の性能に関する内容はありませんが、試してみたところ悪くなさそうです