I will write an English version later to give back to the moonbit community. Addition: https://gist.github.com/mizchi/aef3fa9977c8832148b00145a1d20f4b この記事はリバースエンジニアリングを含んでいる。公式の Discord サーバーで質問して得られた内容を含むが、ここに書かれたものは自分の理解であって、公式の見解ではない。 前の紹介記事では煽り気味だったので、実際に調べながら書いてみてどう感じているかという実践的な話をする。 作者と開発組織 開発母体は深センの研究組織 IDEA 元 Meta で BuckleScript | ReScript を開発していた Hongbo Zhang 氏がチーフアーキテクト。 ReScript を知らない人の

LangChain なんか使わなくてもシュッと作れたので記事にしておく。 RAG とは 生成AIに検索能力をもたせるやつ。 要は検索機能をこちらで提供してやって、AIにそれを読ませる。 AnthropicAI Tool OpenAI でいう Function Calling JSONSchema で関数シグネチャを与えると、それを使うDSLを生成する。実際の関数は自分で実装して、AI が生成した引数(JSONSchema に従う)を渡す。 TypeScript の Mapped Types でツールの実装部分に型をつける簡単なラッパーを書いた。 RAG の CLI を作る Google検索をするAPIを実装 Google Custom Engine API を使った 本文要約をするAPIを実装 Mozilla の実装を使った 与えられた URL を fetch して、その本文部分を抽出する

tl;dr ディレクトリ構成と運用を先に考えた それに従ってコード生成を行うCLIツールを書いた 想定ディレクトリ構成 こういうディレクトリ構成を考えた。 xxx-module/ deps.ts mod.ts mod.test.ts lib.ts v0.ts v1.ts v*.ts README.md PROMPT.md 外部依存はすべてここで宣言しないと使えないとする。スコープを小さくすることで、精度を上げる。 v*.ts バージョニングされたファイル。生成される度に、新しい v*.ts を生成する。都度コミットして git history から引っ張り出してもいいが、コマンド叩く単位で git に保存をしたくないので、こうした。 lib.ts と deps.ts から依存を import する。 複雑なコードを生成させる時、ある種のブラックボックスとして扱うことがあるので、どの時点で動

色々あって WebAssembly の component model を調べていたら、未来が見えた気がしたのでここに書いておきます。 「今の WebAssembly」 とは何か WebAssembly の Web の部分は忘れてください。これは単に JVM version 20xx です。ポータブルなバイナリ仕様です。 実行にあたっては今はホスト言語として JS が使われていますが、実際にはホストがJSである必要すらなく、なんならホストが不要なスタンドアロン環境すらあります。(wasmtime/wasmer) じゃあ WebAssembly は何かというと、サンドボックスで実行される VM の仕様です。比較的高水準なバイナリで、 V8 や Spider Monkey に付属する WebAssembly Runtime や、 Wasmtime や Wasmer といった WebAssemb

去年末ぐらいから Deno を使う割合がグッと増えてきた。最近のJS関連は7割ぐらい deno 環境の VSCode でコードを書いている気がする。 今回はいくつかの実例を示しながら、実際に Deno 使えるじゃんというイメージを持ってもらうためのユースケースを紹介していく。 というか、 deno が普及してくれないと、自分が作ったツールの紹介を全部 deno のインストールから書かないといけなくなる。みんなインストールしといて。 最初に: なぜ Deno を使いたいか 一番の問題点、Node は新しいプロジェクトを一式整えるための手間が非常に重い。 とくに ts で書いたものを他の環境に渡すための方法が未だにしんどい。ある環境で動いたコードをそのままコピーしても、プロジェクト設定の非互換を踏む可能性が非常に高い。 deno にそういう側面がないとは言わないが、非常に少ない。とくに TS

エアプにならないために、実際に moonbit を使ってコードを書いてみた感想を書く。 JSON Parser を書いた パッケージレジストリである https://mooncakes.io を見た限り、使いやすい json parser がなさそうなので、とりあえず自分用のをでっち上げた。 mooncakes.io に publish してあるので、 moon add mizchi/json で使える。品質が良くなくても ネームスペース付きで publish するので別に邪魔にならない気がした。 なんで作ったかというと、公式 example の cloudflare workers の example は単純なフィボナッチを計算するだけで、構造的なデータを返すことができない。 moonbit と js 間の文字列の受け渡しについては、あとで別の記事を書く。 使い方 fn main { l

最近 moonbit という言語を知ったのですが、これが調べれば調べるほど好きになる言語だったので、紹介させてください。 文法的には GC 付きの Rust で、 WebAssembly にコンパイルされます。とくに CDN Edge Worker 上での実行を想定しているようです。もう好き。 注意: まだ若い言語なので、これから言語仕様がガンガン変わっていくと思われます。あくまで現時点での情報です。 tl;dr Pros だいたい GC あり Rust と捉えていい 文法面のキャッチアップが容易 ライフタイムの難しさを考えなくていい すでに vscode 拡張やパッケージマネージャ等のエコシステムが整っている Cons まだ安定していない / しばらくはソースコードが公開されない 現時点では学習リソースやパッケージ数が足りず、書き手の腕力が求められる はじめに: JS/TS/Rust へ

TypeScript の Extract について調べていたら、自分がユニオン型の分配法則について何も理解していなかったことに気づいたので、記事にまとめておく。 Extract の基本的な使い方 // https://typescriptbook.jp/reference/type-reuse/utility-types/extract type Grade = "A" | "B" | "C" | "D" | "E"; type FailGrade = Extract<Grade, "D" | "E">; //=> "D" | "E" これは単に ("A" | "B" | "C" | "D" | "E") & ("D" | "E") のインターセクションを取ってるだけなのでは？ と今まで考えていたが、全然違った。 Extract 型の TypeScript 上の定義はこうなっている。

https://zenn.dev/chimame/articles/d3e7af9a612038 で prisma-d1 を動かすことはできるが、サイズ面の難があるという話 PrismaがやっとEdge Functionsに対応してきましたが、残念ながらまだまだ使うには超えなければならないハードルがあります。それは容量です。PrismaはEngine部分をwasm化してEdge Functionsに対応してきましたが、Prismaの容量が1MBを超えます。 経験上、remix や next は React のコンポーネントなどのUIのライブラリがビルドサイズをかさ増しするので、そもそもWebフレームワークとは別のサービスに分割して、完全にAPIエンドポイントとして分割すればいいのでは？ と考えた。bundled プランでしか動かないのは変わらないが、bundled のさらに上限を回避するの

なぜ cloudflare-workers: 運用が楽 なぜ claude3: GPT-4 より体感性能がいい 動いてるもの /claude <prompt> で claude 3 が答えてくれるチャットボットで、 cloudflare-workers 上で動く。 ただし、AI は自分のことを FF7 のクラウドだと思い込んでいるミッドガル在住の中年男性という設定になっており、時折魔晄中毒で幻覚を見始める。 (アイコンは bing で生成させた) (最近 FF7リバースをクリアしたので...) 自分の課金で claude3 の APIキーを使って動かしてるので、一般公開はしない。代わりにソースコードは公開している。 claude3 を動かす 以下の記事を参考にした。 とりあえず課金してAPIキーを手に入れる。この課金登録フローが少々面倒だったが、調べれば出てくるのでこの記事では割愛。 トー

自分はフロントエンドのロジックを考えるのは得意なんですが、CSS は苦手です。 なので 自分は AI にコード変更を依頼して実行結果を目視でプレビューしつつ、その生成結果を受けいれるかどうかの判断だけすればよくね？と考えて、それを CLIとして実装してみました。 ボタンの色を書き換えるという簡単な例ですが、こんな感じで動きます。 主に React Component の修正をターゲットにしていますが、class(Name) を書き換えることを優先するプロンプトを与えているので、ロジックを保ちつつ、見た目を綺麗にするためのツールになっています。 実装した背景 vscode ターミナル上で画像を表示できる OpenAI API はgpt-4-vision-preview のモデルで画像をアップロードして認識させることができる これらを使って、vscode terminal で実行することを前提

// in const longLongVar = 1; console.log(longLongVar); // out const o = 1;console.log(o); 主に terser や esbuild のポストプロセスとして行われる。 この記事では mangle のベストプラクティスについてまとめる。本当は jsconf.jp で話したかったが、時間がなかった。 例えば vscode(本体)では外にexportされないプライベートメンバを mangle することで大幅なコード量の削減に成功している。 Shrinking VS Code with name mangling ライブラリ作者やサードパーティスクリプト作者に必要な技術だが、一般的なコードにも適用できる話でもある。何度か自分の発表資料に書いてきたが、単体記事になってないのでここでまとめておく。 極限環境で最終ビル

書き終わって気づいたが、この記事とだいたい一緒 https://zenn.dev/ptna/articles/a3882d095fa685 せっかく書いたので別視点の記事として残しておく。コンセプトの理解というより、コードの中身を掘り下げる。 typechat そのものを使うというより、 typechat がどのようにコードを生成するプロンプトを生成しているか、という視点で参考にするためにコードを読んだ。 Typechat とはなにか MS謹製の自然言語をコード実行ステップに変換するプロンプトジェネレータ。 TypeScript の API スキーマを定義して、自然言語の入力をそのAPIに対するコード実行にステップに変換する。 自分の大雑把な理解 プログラマは呼び出し可能なAPIのスキーマと、それを実行するインタープリターを実装する chatgpt は入出力を加工して API 呼び出しのス

chat.openai.com 上でマークアップを試行錯誤するための Chrome 拡張を試作してみた。 例えば html+preview のコードブロックを見つけるとその隣に HTML として挿入する。後述するが React Component もプレビューできる。 📎 をクリックすると展開したHTMLを画像としてクリップボードに入れることができる。 いい感じにコードを生成してくれるプロンプトのサンプル集はここに置いてる なぜ作ったか GPT-4 はそこそこ賢いコードを生成できるのだが、細かい修正は行うにはやはりプレビューしながら対話的に行う必要がある。 また、人間がその結果を言語化するより、生成されたHTMLを画像入力として修正プロンプトに使うのが精度がでる。 (備考: まだChatGPT Plus の一部ユーザーに開放されてない機能) react-component の生成: ts

tl;dr ChatGPT の画像入力でラフスケッチから簡単なマークアップを生成させることができる 生HTML はプロンプトとして弱い。 typescript(tsx) や headless-ui でコンテキスト情報を足すといい感じになる。 ChatGPT にスクリーンショットを入力し、 ChatGPT に puppeteer に操作させれて E2E 生成を自動化したり無限の猿BOT が作れるのでは。 マークアップエンジニアではなく、プログラマ視点でCSSを生成させたい。ロジックはこちらが考えるから、それに合わせたものを作ってくれ、という感じ。 まだ figma 連携とかは考えておらず、雑なラフを食わせたり、一般的なパターンを生成してもらえれば良いと思って試している。 とか考えてるうちに、うちの ChatGPT に画像入力が来た。まだAPIが来てないが、これが来ることを前提にマークアップ補

deno で CLI ツールを作っていたら楽しくなって色々作っていた。 課題: モノレポの諸々の操作がだるい npm/pnpm/yarn の workspace を使っていると、次のようなディレクトリ移動が段々面倒になってくる。 foo を build して bar を build してルートから bar のテストを流す、みたいなことをするとこういう感じになる。 $ cd packages/foo $ pnpm build $ cd ../bar $ pnpm build $ cd ../.. ## コマンドの中身を確認 $ cat package.json | jq ".scripts" { "test": "pnpm test:foo && pnpm test:bar", "test:foo": "cd packages/foo && pnpm test", "test:bar": "

次の記事の 2023 年版です。 tl;dr 次のコードを "deno.enable": true にしない(Node環境のまま)Node＋Deno両方の型チェックが通る vscode 環境にする。 // .ts 拡張子を許可 import { dep } from "./dep.ts"; // node_modules から npm module を解決 import ts from "typescript"; // deno/node 共用で Deno に型をつける const Deno: typeof import("@deno/shim-deno").Deno = (globalThis as any).Deno ?? (await import("@deno/shim-deno")).Deno; const source = ts.createSourceFile("test.t

注意: 本記事で扱う d1 や miniflare v3 はまだ安定してないので、将来的にこの記事のコードは動かなくなる可能性が高い。 大部分を次の記事を参考にしている。 が、現時点で色々動いたり動かなかったりしたので、だいぶアレンジしている。たぶん .wrangler/state/v3 のローカルDBのパスが頻繁に変わることが予想される。 この記事は何 prisma で d1 を migrations したい d1 は kysely-d1 を prisma の型定義を使って動かす wrangler dev/pages 以外の環境からでもテスト用に wokrerd から d1 の binding を取得する 最終的にはこれが動く import type { D1Database } from "@cloudflare/workers-types"; import type { DB } f

これができる拡張を作った。 TypeScript と HTML と CSS の LSP を動かせるようにしたので、 markdown 内部で補完が走る。 TypeScript に関しては補完だけではなく型診断の結果を表示している。 .md だけではなく .mdx にも対応している。 インストールと設定 インストールした上で .vscode/settings.json に次の設定を書く。 { "markdown-code-features.enable": true, // to enable completion in markdown "[markdown]": { "editor.quickSuggestions": { "comments": true, "strings": true, "other": true } } } 基本的に、markdown-code-features.

Qwik をマイクロフロントエンド基盤として使えないか検討していて思いついた色々。副産物で色々作った。 tl;dr Qwik は理論上は最強。だが難しい qwik-react を使えば選択的に Qwik/React を切り替えられるので、 Astro と同じメタフレームワークとして使えそう React 以外もその気になれば対応できるはず => qwik-svelte と qwik-vue を実装した 最終的な問題は Qwik が流行るかどうか Qwik/QwikCity とは何か Qwik は SSR First なUIライブラリで、 .tsx の React 方言からコンポーネントを生成する。 import { component$, useSignal } from '@builder.io/qwik'; export default component$(() => { return