今では生成AIがコードを書けるようになったのに、ガベージコレクタが依然として必要なのか気になります。
> 示唆的ですね……

あっ… これは後で修正します。

では、<selectlist> は不要になるのでしょうか？

Show GN: キャラクター設定バトル/ランキングWebゲーム

余談ですが、Slackボットではタイトルの <select> が表示されないですね（笑）

昨日見たときは気づかなかったけど、Microsoftなんですね……使ってみよう

どうやら、新しいコミットを監視しながら新機能を予測していたブロガーたちは残念がることになりそうですね。

わかる..！

この記事で主張されているように、「文書化」する能力は本当に重要です。
自分自身の強みをアピールし、成果を主張するのに使えるだけでなく、業務をやりやすくし、ほかの人に指示を出す際にも役立ちます。

最初から立派な資料や文書を作成する必要はありません。単純でも整理して文書を作成する習慣を身につけることが重要です。
私も頭では分かっていますが、なかなか実践できていませんね……本当に難しいテーマです。

基礎の奥深いところまでは分かりませんが、基礎を知らないと本当にあきれるような、とうてい想像もできない結果を生み出すのを見てきました。
例えば、DBにあるすべてのレコードをメモリに入れてから、メモリ上で検索するように実装する。
レコードが少ないときは問題なく動きますが、レコードが多くなるとメモリがあふれる。
メモリとDBがどう違うのかをまったく分かっていないので、こういう書き方になります。
これは一つの例にすぎませんが、毎回本当に想像もつかない方向に実装します。
普通の(?)プログラマーには本当に想像できません。

https://ja.news.hada.io/topic?id=4138

Coolify というものもあります。

私もこの記事に共感します。
抽象化された状態値で問題を定義することが、問題発見に有用だと考えていますし、ダイアグラムなどによる状態の可視化や、Unreal Blueprint やワークフローのように、視覚的かつ明示的で明確な状態管理ツールを作ろうとしているのですが、

まずは言語を先に見るべきですね

計算理論の専攻授業を思い出す文章です！プログラミングをする方には勉強してみることをおすすめします。

すごくいいですね？ こんなものまでオープンソースであるなんて（笑）

もっと悪いほど、より良い！

いずれにせよ、ソフトウェアエンジニアリングの実務は大きく変わるでしょう。コードマシンたちの競争力は落ちるでしょうが、実際に製品をEnd-to-Endで作れるエンジニアたちは生き残ると、私は賭けています。

私も OpenAPI の function calling のほうがいいのではないかと思います。これを MCP プロトコルで作り直すのも手間なんですよね。

開発業務をしていた中で、しばらくの間、数年間企画業務をしてみたことがあったのですが、本文の「売る（Sell）」べきだというメッセージがとても心に響きます。
どれだけ一生懸命準備し、企画した製品であっても、周囲の同僚たちを効果的に説得して売り込めなければ支持を得ることはできず、
結局、課題は円滑に前へ進めなくなってしまいます。

思いついたアイデアがあるなら、それを周囲の人たちに効果的に伝えて支持を得るといった活動も不可欠なのだという教訓を得ました。

Docker Desktopですら Kubernetes を使う時代に、Docker Swarm しかサポートしていないのは少し残念ですね。

> ERROR: Unsupported distribution 'manjaro'

試しにテストしてみようとしたら、Manjaro はサポートされていないのですね。少し残念ですが。