TerraformライクなツールCarinaをつくりはじめた動機のひとつに、「型システムの強化」がある。 Terraformではプリミティブな型（string, number, bool）に加えて、listやmap、objectなどの複合型がサポートされている。しかし、型システム自体はあまり強力ではない。 例えば、regionやcidr_blockのような特定のドメインに特化した型は存在しない。そのため、これらの値を扱う際には単なるstring型として扱われ、誤った値が設定される可能性がある。誤った設定をした場合、validateやplanで気づけるのであればまだ良いが、planが通ってしまい、apply時にエラーになってはじめて間違いが発覚することもある。 これを防ぐために、Carinaではドメイン固有型の導入を試している。現在実装しているものとして、region型やcidr型がある。こ

開発環境現状確認の検索結果（b.hatena.ne.jp） 懐かしのブログコミュニティっぽい流れができていたので参加 OS2024まではDHHおまかせUbuntuなどを使っていたが今年はmacOSをメインで使用。昨年の初めにMac miniを景品でいただいたのでそれをメインにプライベート利用した。 mizchiさんと同じく「新しいマシン＝新しいツールを試す」方針なのでいくつか新規導入をした。手始めにNixを導入してみたたがうまく構築できなくて続いてない。 エディタVS Codeに完全移行。長年使っていたJetBrainsライセンスを継続しなかった。PHPプラグインの一部機能が有料だったりするのがネックだったが急にAIが来てプラグインデベロッパー達のビジネスが破壊されていた。 IDE全体で有効にしたい愛着あるプラグインはとくにない。 AIコーディングツールClaude Code。使い方はこの

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

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

自分の中で今 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

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

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

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

結果が出たので、運営側から見た感想を纏めます。 本記事は長文を読みたくない方向けにポイントをまとめています。1問で観測できることなんてたかが知れてるので、chokudaiの予想を多分に含みます。 OpenAIの用意したエージェントは2位相当。素直に凄い。12人参加者9位相当になるのでは？というのが事前のchokudai予想 SakanaAI開発のALE-Agent(ID: fishylene)も4位相当（6桁円ほどのコスト）。これは事前の分析より 遥かに良い結果であり、AIが得意な問題であったと思われる。実装量の多い問題であったため、人間が10時間では足りない、というのが最大の理由。 OpenAIのロジックはALE-Agentから1段階実装量がとても多いのが増えている。増えたロジックはAIが苦手とされていたビームサーチ。モデルがめっちゃ良いorどんだけお金かけたの？ 前回記事予想の「現ルー

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

similarity-tsでリファクタsimilarity-tsを使えば重複コードの分析ができ、それをClaude Codeなどに食わせることでリファクタが捗るらしいので、導入方法から実践方法まで書いてみました（AIじゃなくて人力💪だよ）。 similarity-ts でAIと人間が書き散らした重複コードを見つける https://zenn.dev/mizchi/articles/introduce-ts-similarity 特にVibe CodingでAIにコードを書かせていると類似コードが生産されがちということなので、定期的にsimilarity-tsを使うと良さそうです。 X上でも効果を実感している人を見かけます↓ similarity-tsのセットアップcargoをインストールsimilarity-tsはcargoでインストール・実行する必要があります。 cargoのインストー

X : #claude_code_deep_dive connpass : https://cartaholdings.connpass.com/ev... 【パネルディスカッションテーマ】 ・実用で見え始めた「技術的負債」やハイプ・カーブの"幻滅期"におけるリアルな課題 ・AIで「脳のリミッターが外れる」感覚とは何か？そして、現在の破壊的な価格設定は持続可能か？ ・AIのコード生成量に人間のレビュー能力が追いつかない。人間がボトルネックとなる現実に対し、我々は何を諦め、どう開発プロセスを変えるべきか？ 【登壇者】 t-wada タワーズ・クエスト株式会社 取締役社長 プログラマ、テスト駆動開発者 学生時代にソフトウェア工学を学び、オブジェクト指向分析/設計に傾倒。執筆活動や講演、ハンズオンイベントなどを通じてテスト駆動開発を広めようと努力している。 『プログラマが知るべき97のこと

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

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

2025年8月にO'Reillyから出版される『Vibe Coding: The Future of Programming』のEarly Release版として2つの章が公開されていたので読んでみた。 The 70% Problem: AI-Assisted Workflows That Actually Work Beyond the 70%: Maximizing Human Contribution learning.oreilly.com タイトルとは裏腹に"Vibe Coding"の話は少なく、むしろ副題の"The Future of Programming"やこれから AI を活用していくエンジニアに求められるスキルに焦点が当てられているのが興味深かった。実際には"AI-assisted Coding: The Future of Programming"という言葉のほうがタ

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 で