はてなブックマーク

前々から自作ブラウザを作ってみたかったんですよね。作ります。 今回はブラウザのGUI周りの、主にレイアウトの座標計算モジュールを自作しました。CSS のボックスモデル, Flex, Grid の座標計算というのが伝わりやすいでしょうか。 HTMLパーサ/CSSパーサ/CSSクエリエンジン/ペインティングも一部実装しましたが、レイアウト可視化のテスト用と割り切っていて、ちゃんと作ったのは主にレイアウトの座標計算周りになります。 作ったもの 雑なプレイグラウンド こんな感じです Terminal で Sixel を描画して Google を表示したもの。今回は主に座標計算周りの実装なので background-color やフォント周りは未実装なんですが、矩形だけでは自分の目視デバッグもしんどかったので、最低限のビットマップフォントをレンダリングできるようにしました。 リポジトリ npm:@m

MoonBit で書いたシンタックスハイライトを、WebAssembly Component Model 形式で wa.dev に公開してみました。 これです。 wa.dev とは wa.dev は、WebAssembly Component Model のパッケージレジストリ。npm や crates.io の WASM Component 版のようなものです。 Warg (WebAssembly Registry) プロトコルに基づいており、以下の特徴があります。 言語非依存: .wasm で配布されるので、言語に依存しません 型安全な相互運用: WIT で定義されたインターフェースにより、言語間で型安全にライブラリを共有できます 分散型: Warg プロトコルにより、複数のレジストリを連携可能 WIT については Component Model Documentation を参照して

Moonbit Advent Calendar 最終日の振り返りです。 このカレンダーを作った目的は、自分を追い立てつつ(結果として Luna UI が完成しました)、隙あらば皆さんにもMoonbit触れてもらう機会にしたい、と言う気持ちがありました。。 結果的に10記事近く自分が書きましたが、当初の想定以上に参加者を集めることができ、その目的は達成できたと思います。 本音としては、本当はもっと軽いリファレンス的な記事を連投してお茶を濁すつもりでしたが、 @ramenha0141 さんの熱量が入った記事が投稿されてきた段階でそうも言ってられなくなりました。なのでいずれの記事も結構コスト掛けて書いてます。 (まだ、2~3空いてる日がありますが、自分がまだ温めてる記事があるので、後日埋めておきます。) Advent Calendar 振り返り 自分で言うのもアレですが、自分は日本では Reac

UIライブラリのオタクとして、React に始まり、様々なUIライブラリを試してきましたが、ついに自作することにしました。 何年経っても不満は既存のライブラリで解決できないか解決困難なままなので、今こそ自分が本当に欲しいものを作ります。 軽量ランタイムによるポータビリティ Signalによる細粒度リアクティビティ 十分に小さいのでコンパイル時最適化が不要 WebComponents SSR + Hydration に対応(おそらく世界で最初) というわけで、作ったのが Luna です。ドキュメントサイトも作りました。 Moonbit+Luna自体で書いて、SSGから自作しています。 GitHub 既存のUIライブラリへの不満 React: でかい。既存資産との互換性で動きが遅い。RSC 実装の方向性が好きになれない Qwik/Solid: コンパイル時展開が邪魔 svelte/vue: S

人生で5度目ぐらいの Markdown Editor 実装をしました。今回が最速です。 ここで試せます。 実際に地上最速かはいろんなパフォーマンスの軸があるのでなんとも言えないんですが、少なくともエディタ上のインクリメンタルコンパイルという視点では、他に負けないと思います。(ベンチマークは記事後半にあります) 自分で言うのもなんですが、とにかく速いです。差分コンパイルなので分量が多くても耐えます。プレビューと編集の自動同期が便利で。試しに20000文字突っ込んでも表示ラグはなく、 60fps を維持しています。 FFIを使わないピュアなMoonbit実装なので、js/wasm/native でライブラリとしていずれの環境でも使えます。 というわけで、今回は Moonbit による実装の可能性を皆さんに見せつけたい、と思ってこの記事を書いています。その js ビルドを npm の @mizc

TypeScript はJS由来の言語仕様が根本的に不安定、Rust はアプリケーション層を書くのには低レベルすぎる、そんな不満はありませんか？ MoonBit はそういう不満を解決してくれる言語です。ただし、今はエコシステムの力を借りず、全部自力で書く前提ですが。 この記事は 2025/11 時点の MoonBit への所感になります。 2024/4 時点と比べて、ネイティブバックエンド対応、組み込みJSON型、例外のサポート、非同期サポートと大きく進化しています。 そろそろ実用できるんじゃないか？と思い、自分は MoonBit を使って React のバインディングを書いて、SPAとして動作するのを達成しました。その所感を含めての記事になります。 Moonbit のここが嬉しい MoonBit は自分がTypeScript に感じる不満の多くを解決しています。 Rust風の構文の静的型

自分の中で今 Moonbit が熱いです。Moonbit を普段使いしたいですよね。 というわけで、js backend で FFI を駆使して React でSPAを書けるとこまで頑張ってみました。 React を書いたことがある人なら、以下のコードを見れば理解できると思います。 ///| enum CounterAction { Increment } ///| pub fn counter(_ : EmptyProps) -> @react.Element { let (count, dispatch) = use_reducer( (state : Int, action : CounterAction) => match action { CounterAction::Increment => state + 1 }, 0, ) let on_click = use_callba

gpt-5-codex を試すのに codex を調べています。 注意。2 つの手段を見つけましたが、過渡期っぽい無理矢理な方法です。 動機 claude code はプロジェクトごとに mcp 設定を独立させることができましたが、 現状の codex はグローバルに MCP を設定する方法しかありません。 例えばコード解析ツールの lsmcp や serena は常に起動したいわけではなく、プロジェクト固有の MCP プロセスとしたいです。 ドキュメントにもないので、直接 codex 本体のコードを読んで設定する方法を探しました。 (一応、lsmcp/serena どちらもカレントディレクトリを基準にコードを解析するので、常に起動するだけで動くには動きます) 手段 1 CODEX_HOME=$PWD/.codex CODEX_HOME= の環境変数の指定で、読み込みディレクトリを変更でき

「動いてるのがわかっている状態」からサンプリングして描画の揺れ幅を計測し、それを元に自動で差分テストを行うツールを書いてみました。 とにかくレンダリングの崩れを自動的に検出したい！でもそのためのE2Eテストは書きたくない！というときに使う想定です。 注意: 自分がCSSを修正に使う用、兼PoCです。ヒューリスティックなアルゴリズムスコアを多く含むので、アップデートすると出力はたぶん安定しません。 目視用のSVG出力例です。 これは何 視覚的なボックスモデルの diff をとって、差分を検出する 内部ロジック puppeteer で指定された URL をクロールして、全部の DOM に BoundingRect を付与して抽出する 座標のボックスモデルで(ヒューリスティックに)近似して、VisualNodeGroup という単位に要約する 2つの VisualNodeGroup[] の距離を

最近 claude-code が調子悪いので、 opencode kimi-k2 を試してみました。 openrouter+kimi-k2+opencode という構成で、ツールも動かせたんですが、ちょっと設定が面倒だったのでメモを残しておきます。 試した動機は laiso さんのの記事 SWE-bench Verified では 65.8%のスコアを達成しています。これは OSS のバグ修正パッチ生成タスクを計測してます。Gemini 2.5 Pro が 63.8%で Claude 4 Sonnet が 72.7%と比較しても高い水準です。 Kimi K2 の API 利用料は非常に安価です。プロバイダーによっては出力トークン価格（1M）$2.50 と設定されており、Claude 4 Sonnet が$15、Gemini 2.5 Pro が$10 と比較して大幅に安価です。 中国系のモデ

来週から Claude Code に 5 時間レートリミットではなく Week Limit が導入されるみたいです。辛いですね。 というわけで、元々考えてたコンテキスト消費を少なくするテクを実装してみました。 リポジトリはここで、主に .claude の下に色々おいてあります。 tl;dr 動いている前提で公開 API とテストケース一覧を AI にレビューさせる .claude/agents/*-reviewer.md を置いて、レビュータスクをここに書いていく .claude/commands/smoke-review.md をオーケストレーターとして reviewer を並列で発火させる *-reviewer の Agent を並列に起動して、コードをレビューしてください 最小ケース $ git clone https://github.com/mizchi/ts-starter-w

つまりこう。 基本は細かい制御をしない前提で、ホストマシンで一時的にサーバーを起動して、出先でポチポチする、ぐらいの想定です。 リポジトリ 最初に言っておきますが、コードや仕組み自体は単純ですが Discord のトークンを取得してサーバー ID とチャンネル ID を取得するのが面倒です。 どのように動くか 任意のディレクトリを起点に Claude Code を起動して、 Discord に接続 サーバーが起動すると Discord BOT がスレッドを作成して、ユーザー入力を監視 起動したディレクトリで claude-code SDK を経由して、ユーザー入力を claude-code に流す その結果を Discord に出力 注意 個人用の Discord チャンネルで使うことしか想定してません。 かなり強い権限を持ってるので、公開チャンネルで使わないでください。プライベートなサー

DeNA 社様で AI コーディングの社内勉強会の講師をやってきました。 最近、フリーランスでこのような仕事を依頼されていることがあり、余裕があるときに請けています。AI コーディングの講師は 3 回目です。4 回目の予約も入っています。 この記事では、AI を使ったプログラミングの講師として受講者に伝えたかったことや、他の方が講師をするときに何を考えるべきか？を一応書き出して、まとめておきたいと思います。 ノウハウを秘匿しておいても自分の食い扶持にもなりそうではあるんですが、それ以上に AI コーディングが一般化してほしいと願っています。 事前準備 事前に作例のリポジトリは用意しておきます。が、これを意図的に使わないようにしています。 なぜなら、これをフォークしてしまうと、AI は既存実装を「チラ見」してしまいます。結果ゼロからプロンプティングして組み立てているという体験を損ねてしまいま

関数型まつり以降、Unison 言語が気になっています。 最近、試しにAI用のLSPとか作ってたんですが、既存のプログラミング言語処理系にやや限界を感じています。既存言語の人間用のファイル参照と line:character の補完というインターフェースが、AIの操作単位と噛み合ってないじゃないか？という懸念です。 関数型まつりでも発表があった、関数型ドメインモデリングの Scott Wlaschin 氏いわく「副作用のない関数だけでプロジェクトを構成すれば、関数名はただの名前空間のルックアップテーブルに過ぎなくなり、その合成だけでドメインを表現できる」とし、関数を組み合わせるスタイルの Railway Oriented Programming を提唱していました。 関数型まつりで Unison 関連の発表があったわけではないんですが、関数型言語のうち自分がほしい特性をAIに相談したら、そ

講習会用にまとめたもの。可能なら公式ドキュメントを参照するのを推奨するが、この資料ではサッと使いはじめるために要点を絞って解説する。 claude-code は claude-code 自身で開発されており、恐ろしい速度で更新されてる点に注意。この資料は一瞬で古くなる。 アカウントの契約等は省略 インストールと実行

前回は TS に特化した MCP サーバーを作ったが、今回 LSP (Language Server Protocol) を使って任意の言語に対応できるように一般化するのに成功した。 https://github.com/mizchi/lsmcp TL;DR typescript-mcp の TypeScript 特化機能を LSP ベースに一般化 Rust、Python、Go、Moonbit など任意の LSP と連携可能 npx -y @mizchi/lsmcp --bin="rust-analyzer" のように LSP プロセスを握って起動するので、任意の言語に対応可能 (実際にリネームや Auto Import のような各コマンドに対応する操作ができるかは、LSP 側の実装に依存) 実際に Rust プロジェクトで動いている例： # Rust でのシンボルリネーム ● lsmcp

(この記事の AI 成分は 5 割ぐらいです) claude-code や gemini-cli を触った人なら、やたらリッチな CLI のインターフェースが一体どうなってるか疑問に思ったはずです。 これは ink というライブラリで実装されています。実体は React のカスタムレンダラーで、React の差分レンダリングで CLI を構築することができます。 中では yoga というレイアウトエンジンが使われており、これは React Native でも使われているもので、 Web で display: flex を使ったときと同じレイアウト計算モデルになります。 つまり、 React や ReactNative の知識で CLI (TUI) の アスキーアートの UI を作ってるわけですね。 実際に作ってみた例 React Ink の可能性を探るべく、ターミナルで動くゲームを実装して

$ gemini -p "Webで「Gemini APIの料金」について調べて" Gemini APIの料金は、主に従量課金制で、使用するモデルや機能、利用量によって変わります。無料利用枠と有料プランが提供されています。 ### 料金体系の概要 課金は、以下の要素に基づいています。 * **入力トークン数**: APIに送信するテキストやデータの量。 * **出力トークン数**: APIが生成・応答するテキストやデータの量。 * **キャッシュされたトークン数**: 会話の履歴を記憶させる機能を利用した場合のトークン数。 (略) brave search や perplexity がなくともこれで、馴染み深い Google の結果が返ってくるので、非常に使いやすいです。 自分は今からとりあえずこれを claude-code に繋いでみます。 => した。 .claude/commands/

claude-code sdk を使えば、TypeScirpt/Python コードから claude-code を呼べる。 これを使って、自動テスト中に自然言語によるアサーションをするという、(最悪な)アイデアを思いついたのでメモしておく。 // node --test ask-claude.test.ts import { test } from "node:test"; import { query, type Options } from "@anthropic-ai/claude-code"; // claude-code が起動し、prompt が条件を満たしたら MARKER を投げて停止する。 async function assertAI(prompt: string, options: Options = {}): Promise<void> { const MARKE

Analyzing code similarity... === Function Similarity === Checking 142 files for duplicates... Found 8 duplicate pairs: ------------------------------------------------------------ Similarity: 89.09%, Score: 8.0 points (lines 9~9, avg: 9.0) src/utils/getUserById.ts:4-12 getUserById src/utils/findUserById.ts:8-16 findUserById Similarity: 88.00%, Score: 14.1 points (lines 15~17, avg: 16.0) src/servic

TypeScript ツールチェインは多種多様で、毎回目的に沿ってプロジェクトを設定するのが非常に大変です。 なので、再現性のある環境構築手順を作って LLM に丸投げすることにしました。 (この記事の7割はAIに書かせて、自分で30分かけて書き直しました) tl;dr Claude Code に読ませる前提のTypeScriptの環境構築ガイドラインを作った docs/ts-guide/ にドキュメントを配置して、LLM（Claude）にそれを読ませる プロジェクトの要件を伝えて、LLMに適切な設定を追加させる ベースラインとなる基礎部分から始めて、対話的に必要な機能を追加していく How to use すごい雑に実態を説明すると共通セットアップとただのライブラリの使い方のドキュメントです。 # 新しいプロジェクトを作成 mkdir my-app cd my-app # ts-guide

最近もっぱら Roo から Claude Code をメインに移しているが、その界隈の進歩は今までの変化とは明らかに質が違うという感覚がある。それを今の時点で言語化しておきたい。 最初にいっておくと、自分はシンギュラリティ論自体には否定派というか、シンギュラリティが来たところで世の中の問題の大多数が解決されるとは思っていない。(特にレイ・カーツワイルは典型的なフェイク野郎だと思っている) 実現したところで、そんなものかになるという程度の話だと思っている。実現したところで、シンギュラリティ万能論者はゴールをずらし続けることで否定するだろう。終末論はいつもそうだ。 という前置きの上で、今確実に転換期を迎えている AI とプログラミングの話をしたい。 特異点があるとしたら、今はその瀬戸際。 tl;dr Claude Code は Claude Code によって 90%が開発されている その改善

tl;dr Roo Orchestrator の Claude Code 版を作ってみた Roo は並列タスク未対応だが、 Claude Code の Task の並列実行ができる はじめに 普段から Roo Orchestrator を愛用していて、その Claude 版が欲しかった。 Roo Orchestrator はタスクを段階的に分解して、個別にサブタスクに分解する。サブタスクは独立したセッションとして動き、タスク完了後は親にそのサマリを返す。 これはかなり効率的に動く。場合によるが、今までだと $6 かかっていたようなタスクが、$1 未満にコンテキストを圧縮できていた。動作も速い。 今回は、.claude/commandsディレクトリを使って、複雑なタスクを効率的に分解・実行する Orchestrator プロンプトを作成した。 事前知識: Task Tool と .claud

一旦 npm install typescript typescript-mcp -D で MCP サーバーが動くところまで作った。 主語大きめだけど、 npm の名前空間が空いてたので... これの続編 TL;DR 既存のエージェントの内蔵ツールはセマンティックな AST 操作ができない 書き換えてみて駄目だったら修正、みたいな挙動 MCP サーバーとして、 Rename, Move File, Go to Definition, Find References 等の LSP の機能を提供した 実際に動いている例 # Rename file ● typescript:move_file (MCP)(root: "~/s andbox/claude-mcp", oldPath: "examples/oth er-types.ts", newPath: "examples/types.ts"

claude code 安くて便利。 自前 MCP を大量に持ってると、手元に用意しておいた MCP サーバーに繋ぎたくなります。 以下のドキュメントによると、 claude --mcp-config=... でローカルな MCP サーバーを叩けるみたいです。 以下、claude code に手元の MCP サーバーを登録する例です。 追記: .mcp.json プロジェクトルートの .mcp.json が自動で認識されます。 ~/.zshrc 用のエイリアスを削除 ローカル MCP につなぐ MCP サーバー実装を書きます。 これは指定した URL を本文抽出して markdown で取得する実装です。 // .claude/mcp-server.ts // npm add -D @modelcontextprotocol/sdk zod @mizchi/readability impo

実装はここ https://jsr.io/@mizchi/domain-types@0.0.8 あらすじ 使い方 npm と jsr に公開しておいた。 Node/Deno どっちでも使える。 基本的な発想として、ある program の実行とは AsyncGenerator<Effect> あるいは Generator<Effect> のイテレータで表現できるとする。 program 定義とは別に、エフェクトの宣言とは別に対応するハンドラ(EffectHandler)を注入する。それが同期か非同期かはそれ自身ではなく、実行方式で決まる。 import { type EffectFor, defineEffect, performAsync, } from "@mizchi/domain-types"; const log = defineEffect< // unique effect

tskaigi で susisu さんの Generator で Promise ランタイムを作る発表をみて、昔作ったやつがもっとやれそうな気がしたので、やってみた話。 やりたいこと TS の言語システムが物足りなくて、ドメインを表現しきれない。とくに副作用を持つ関数に、なんとかして副作用の型を宣言したい。 過去に、 Async Generator でこれができるのを確認した。 function print(): void & Eff<Operation.Console> { console.log("hello"); } async function* main() { yield print(); } for await (const _eff of main()) { } // この型が最終的に発生した副作用の合計を表現する export type MainOps = GetEffe

Deno + Claude4 + RooCode。Claude 4 が進化しているので、それに合わせて Roo のプロンプトを書き直した。 リポジトリはここ たぶん .roo/rules/rules.md と .roo/rules-orchestrator/01_workflows.md だけ見ればいいです。 オーケストレーター用のプロンプト システムプロンプト側 AI へのお題はダイクストラによる経路探索の実装。 効いたこと ハイラムの法則と単一責任原則に言及しながらリファクタさせる https://ssaits.jp/promapedia/glossary/hyrums-law.html eslint の warn でかなり積極的なルールを採用して、それを根拠にリファクタリングさせる 最初は 単体ファイルだけで eslint を回す 通常のテストではログが邪魔になるので通所の CI で