https://gihyo.jp/magazine/SD/archive/2025/202503
その標準仕様としてMinimum Common APIを策定・維持することが挙げられています。ただし、この標準は既存のWeb標準を変更したり分岐させたりするものではない点が強調されています。
ほんとに〜?
タイムリーな話題で面白かった. 簡単に検知できるのであれば仕組みで解決すべきだし, 事業者もそういうサービスを提供すべきではと思った.
濃い. 前半の「［Part1］人気のエディタの魅力を深掘り」は比較的普通の Visual Studio Code, Vim, Emacs, Cursor の特徴と機能の解説. だいぶこの時点で熱量を感じる. 後半の「［Part2］エディタを極める理由」はエッセイ. ブログとかで積極的に読みにいかないと得られないコンテンツなので面白い.
個人的に面白かったのが, Vim の操作体系は身体的学習を伴うということがわかったこと. そりゃ Vim にハマるのもわかるなと思った. ソフトウェアエンジニアとエディタの関係性が独特なのは使う道具と作るものが同じということ. 他のエンジニアリングでは自分で使う道具を作るということはあまりないはず.
この記事ではエディタ のカスタマイズに重点を置いているが, 私個人としてはほとんどカスタマイズせず, VSCodeに入っている拡張機能も片手で数えられるくらいしか入れないので違いを感じられてよかった. 私はPC3台を年1で入れ替えながら多数の言語を同時に扱うので(VHDL, C++, Java, Rust, Typescript, Python, Flutter), エディタを設定するよりもプロジェクトごとに editorconfig を設定したり, Dev Container 使うほうが便利なのでそうなった（ある意味これもカスタマイズかも）. なので他人がどういう背景でエディタの使い方をカスタマイズしているのかが気になる.
この記事はTyporaで書きました.
そもそものコンテナランタイムの説明があって良い.
OCIはOracle Cloud Infrastructureと略称が重複していますが、関係ありません。
これ本当にまぎらわしいので略称使わないでほしい.
User Namespaces は有用そうなので覚えておこう.
とても良い記事. テストしやすい実装を考えていくと, ソフトウェアとして正しい設計になっていくんですね.
最近のLLMアプリケーションはどれもマルチエージェントの形をとっているので作り方や考え方を覚えておくとよさそう.