はてなブックマーク

(これは某所でやる Cloudflare の入門チュートリアルで、そこの肌感に合わせています。) アカウント登録が終わっていることは前提とします。 Hello World いちばん簡単な TypeScript のワーカーのサンプルを作ります Hello World Worker only TypeScript npm run dev で起動。 この中身を解説します。 仕組みを知る Wrangler Cloudflare Worker は wrangler という CLI でコードを管理します。gcloud や aws-cli みたいなものだと思ってください。 wrangler は npx wrangler でもいいですが、プロジェクト毎に devDependencies 経由にすることを推奨します。 (全体的にはかなりおせっかい気味な CLI です) CLI から認証 デプロイやクラウドリ

現時点で個人の感想です。流動的なので、明日にでも意見は変わってると思います。 モデル Claude-3.7-sonnet コーディング性能が圧倒的に良い。迷ったらとりあえずこれを使っておけばよい だいたい1ファイル1000行ぐらいが管理できる限界 Gemini 2.5 今なら無料で使える。今のうちに使い込んでクセを把握するといい。 巨大コンテキスト理解ができるので、「大量にコードを読んでちょっとだけコードを書く」つまり一般的な業務プログラミングに向いてる。 リリースから一週間は負荷が高くて不安定だったが、最近安定してきた さすがに単純なコーディング性能は Claude-3.7-sonnet に劣る deepseek-chat Cline で使うには遅すぎて役に立たない AIツール作るときの壁打ちに使っている。雑に巨大データ送りつけても安くて安心 コーディングエージェント/拡張 Cline

pglite + pgvector で文章の類似度検索を実装します。 動機 とにかく手っ取り早くローカルにデータを突っ込んでおいて検索する RAG の雛形がほしかったんですが、調べても大規模ストレージを前提とした大掛かりな実装が多いです。 スクリプトを書いたらポンと実行できるセットアップ不要なものがあると、色々と実験ができます。 mastra/rag を読んでたら、簡単にできる気がしたのでやりました。ただ、chunk のドキュメント分割相当のものはまだ作ってません。そこまで難しい概念でもないので、雑に作れそうではあります。 qrdrant も検討しましたが、サーバーを建てるのが面倒でした 準備: ベクトル化用の関数 今回は @ai-sdk/openai を使ってベクトル化をします // OPENAI_API_KEY= import { openai } from "@ai-sdk/open

現状、最低限動いてはいるけどガバガバ Readability.js とは HTML から本文を抽出するライブラリ。 元々はArc90によって開発され、現在はMozillaのFirefox Reader View に使われている。 AIモデルではなくルールベースだが、かなり精度がでる。 自分はこれを AI に食わせるサマリを作るのに愛用していたのだが... DOM API 依存と Cloudflare でJSDOMが動かない問題 DOM API に依存しているので、 jsdom に依存してしまう。 import { JSDOM } from "jsdom"; import { Readability } from "@mozilla/readability"; import html2md from "html-to-md"; function getExtractContent(htmlC

参加してみたら結構面白かったので、フロントエンド/Node.js エンジニアはやってみてほしい。 あれこれ盛り上がりたいので。 (自分は作問担当でも中の人でもなんでもない。ハッカソン参加者) 自分の最終結果はスコア上は 365/1200 で 12位だったが、レギュレーション失格で落ちた、というかレギュレーションを通せた人が上位16人で1人だけ。 結果から言えばレギュレーション守って300点以上とるゲームだった。 学べること クライアントサイド ランタイム負荷の計測 静的解析によるバンドル解析 やばいアセットの発見 CSSの静的抽出による(CLS改善) サーバーサイド sqlite のチューニング SSR実装 動画配信のプロトコル とにかく大量のライブラリツールチェインを乗り越える力(現場っぽい) 富豪的な実装のライブラリを自分で置き換える力(時間内無理) 環境構築 node.js / pn

AI 経由でブラウザを操作する browser-use を deno で実装してみました。 元は python ですが、コア部分を自分で作れるように書き直しました。 注意: 勉強用の作例であって、本番で使えるものではないです。 以下の記事を読みながら実装しました tl;dr アクセシビリティ要素を列挙 各要素にブラウザ上でオーバーレイで操作用インデックスを書き込みつつ、インデックスに対応する xpath を作っておく claude のスクリーンショットと xpath を渡す claude に対応する xpath の操作方法を教える ツールとして対話的に実行 ステップ Tool Runner Puppeteer BrowesrTool Tool Runner まず、Tools を使って AI と対話する部分を作ります。 import { anthropic } from "@ai-sdk/a

やりたいこと 動機: Puppteer はプロセス外部のリソースを触るので、正しく終了させないとプロセス終了後にChromeが起動しっぱなしになってしまう。 TS 5.2 から使える await using と AsyncDisposableStack でリソース開放を逐次予約する。 tl;dr 本当は await using で個別にリソースを確保/開放したいが、まだ諸々のライブラリが対応してない 自分でラップするのが面倒 なので、 AsyncDisposableStack.prototype.defer に逐次放り込むのが楽 準備 Deno で単純な await using は使えるのだが、試した限りは AsyncDisposableStack の型は存在するがコンストラクタが存在しなかった。 後述する SuppressedError もなかった。なのでポリフィルが必要。 AsyncD

{ using log = createSampleLog<string>(5); log("a"); log("b"); // スコープを抜けるときに最大5件サンプリングされて表示される } using の使い所 やりたかったこと Cline が勝手にデバッグログを仕込みまくって膨大なログを食ってトークンを使いまくるので、そもそも出力するログに上限を設定したい。 ロガーは初期化したスコープに依存して、抜ける時に吐き出す。 前提知識: using と Symbol.dispose スコープから抜けるときの処理を書ける。 function useXXX() { return { [Symbol.dispose]() { console.log("xxx:disposed") } } } // スコープを作る { using xxx = useXXX(); // スコープから抜ける時に usi

Lighthouseのドキュメントを調べていたら、カスタムプラグインを作れるらしいのに気づきました。 カスタムな Audit を作りたかったので、やっていきます。 この記事の知識を多少要求します。 tl;dr Lighthouseのカスタムプラグインは「Gatherer」と「Audit」の2つのコンポーネントで構成される Gathererはデータを収集し、Auditはそのデータを使ってスコアを計算する Audit.meta.requiredArtifacts で必要なGathererを指定すると、自動的に Gatherer#getArtifact の結果が渡される カスタムプラグインを使えば、カスタム指標評価が作れる 最終的にこういうのが出来ました // Gatherer の生成物 🔍 MyGatherer { result: "gatherer-result" } // Custom

AI に自分のスタイルでコードを書かせたい。 自分のコーディングスタイルを端的にまとめると、たぶんこう。 TDD でミニマルにはじめるのが好き でも DDD で段階的にドメインモデリングもしたい 実装は関数型ドメインモデリングに寄せる これをAIに叩き込みたい。資料を読ませてプロンプトを作って、それにそって実装させる。 エヴァンスのDDDと軽量DDDの2つでやらせてみる。 コードはここ 自分のコーディングスタイルに合わせたプロンプトを作成する MCPエージェントで検索とURL展開を使える状態で次のように指示をした。(自作ディープサーチみたいなもの) インターネットでDDDについて調べさせる インターネットで関数型ドメインモデリングについて調べさせる インターネットでTDDについて調べさせる プロンプトとして使えるように要点を圧縮しろ 端的に圧縮しろ もっと圧縮しろ で、でてきたのがこれ。こ

CI まで一式動いてるのがここ pglite は postgres を wasm コンパイルしたもの。 これを deno + drizzle からマイグレーションして叩く。 なぜこの組み合わせか ローカルにAIエージェント用の簡単なDBツールを量産したかった。deno でスクリプトを書きまくってるので、 deno を前提に色々試した。 色々試したのだが、最終的に Pglite で Postgres を叩くことにした。インストールが不要で、DB周りのセットアップが一番手数が少ない。手数の少なさを最重要とした。 最低限これだけでいい。 import { PGlite } from "npm:@electric-sql/pglite"; const db = new PGlite(); // `{dataDir: ...}` で初期化パスを渡せる await db.exec("create ta

Cline を使い始めて2ヶ月ぐらい経った。 自分の直感として、Cline は真のイノベーションの入口であり、そして開けてはいけないパンドラの箱でもあったと思う。 ここでいう Cline は Cline型コーディングエージェントであり、広義には Devin / Cursor や Copilot Agent 等を含む話。だが、後述するように Cline でしか見えない世界がある。 その先の未来に、プログラマとしての自分はフルベットする、という話をする。 私たちが知っているプログラミングの終焉 大事なことは次の記事に全部書いてある。まずこれを読んでほしい。 (Google翻訳) Steve Yegge 氏は、置き換えられるのはジュニアおよび中級レベルのプログラマーではなく、新しいプログラミング ツールやパラダイムを受け入れず過去に固執するプログラマーであると指摘しています。 <略> これはプロ

なんか驚き屋っぽくてアレなんだけど、今回はさすがに驚く権利があると思うので、至急記事を書く。 やろうとしたこと 毎回手元の検証結果から技術記事を構成するのがだるい 自分のブログを適当に読ませておいて、その構成と文体を真似させればいいのでは 手元に mizchi/zenn というリポジトリがあり、ここに zennにポストする原稿を管理している。 $ tree ./articles ./articles ├── 1c35fdcc77065c02f631.md ├── 3e4742e24f2ca0118f70.md ├── 8a017097d3994ddc0a85.md ├── ai-code-generation.md ├── ai-programmer.md ├── ai-team-mate.md ├── antipattern-of-tournament-score-sheet.md ├─

やりたいこと 外部MCPではなく、その場でサクッと書いた deno スクリプト書いて使わせたい。 ローカル MCP は 標準入出力でJSONを喋るだけで作れる でもテストするのが面倒なので、インメモリでテストしておきたい これらを、Roo Code でいつでもできるように、手順を整理しておきます。 TODO: 本家 Cline のやり方はあとで確認 知っておくべきこと Cline/Roo/ClaudeDesktop はアプリケーション起動時に設定を読み、mcpServer のプロセスを起動して握る 明示的にリロードさせないと反映されない(面倒くさい) 簡単なMCPサーバーを実装する まず、getStringLength という、与えられた文字列の length を返すだけの簡単なサーバーを実装します。 (MCPとしての動作確認のためだけの実装です) どこでもいいですが、 ~/mcp/ser

なにこれ Deno はセットアップが非常に簡易で、スクリプトの書き捨てに便利です。 npm install xxx 相当のことをしなくても、import "xxx" と書いておけば裏側でキャッシュして型チェックしつつコードが書けます。 Deno を Jupyter Kernel として使って、 ログを .ipynb として保存すると、GitHub が対応しているので実行結果をプレビューできて便利です。 実際に試したURLはここ。 以下のURLは、実際に puppeteer を動かして、そのスクリーンショットを表示しているところです。 実行結果を保存してくれるので、実験用の書き捨てのスクラップを作るのに便利です。 環境のセットアップ vscode に deno と jupyter の拡張を入れます。 使いたいプロジェクトで、 Python と Kernel をセットアップします。 今回は u

Lighthouse のコードを読んだので、その実装を解説していきます。CLIの使い方から、直接APIを叩く方法、そして個別のAuditの実装を理解する流れを解説します。 これは Lighthouse を理解するための資料で、Lighthouseの使い方ではありません。 とはいえ、内部実装を理解することで Lighthouse についての理解が深まることでしょう。 Chrome Devtools Protocol Puppeteer が Chrome に向けて喋っているもの。Lighthouse も基本的に CDP を直接操作します。 Lighthouseの実装自体も、あんまり Puppeteer に依存せずに直接 CDP を操作する方向性を感じます。 CLI でデータを収集/解析 まず、lighthouse は計測対象である audits が存在します。これらの一覧を見てみましょう。 $

現時点の AI コーディングの実力を測るために、自分はプロンプトのみ、直接コードを書くのは禁止で Roo Code による VS Code によるエディタ操作のみでコードを書かせた。その感想 (急いで書いたのでいろいろと雑です) tl;dr 良し悪しはともかく、人類は確実にAIによる自動操縦型のプログラミング体験に依存するという確信を持った。 ただ、その基盤である CLINE(系)自体のツールとしての完成度はいまいち。 CLINE以外の、各モデルのコーディング性能も、現時点では物足りない。 CLINE とは何か(知らない人向け) いろいろと機能はあるが、コア機能としてはヘッドフルな vscode runner で、AI にコードを書かせるために必要な情報を受け渡しするインターフェースを持っている。ファイルの読み書きや、コマンドを実行結果をプロンプトにしてAIに渡す。puppeteer によ

株式会社スタディスト様の依頼で、フロントエンド傭兵として、Rails 内の巨大SPA の段階的なモダナイズの提案を行った事例紹介です。 いつもはパフォーマンス視点で仕事にかかるのですが、今回はマクロな設計視点でソースコードを読んでいきます。一旦は中期ゴールを提案しつつ、その作業の必要性を通して、なぜその変更が必要なのかという解説をしていきました。 コスパが良い部分からやりたいですね。でもコスパ感覚は人それぞれです。あくまでフロントエンド専門家の自分が優先度付けるなら、という観点でやっていきます。 今回の仕事にあたっていくつかの技術的な課題を取り上げますが、それはスタディスト様に問題があるという話ではありません。むしろ問題を修正しようという意思が強く、実際1ヶ月の期間中にいくつかの修正をマージすることもできています。 以下、敬称略。注意点として、今回の内容は中の人達が見返すための記述が多いの

import { createSelectorGenerator, toLocator } from "@mizchi/selector-generator"; const generateSelector = createSelectorGenerator(window); const selected = generateSelector(document.querySelector("div")); 与えられたDOM要素が、レイアウト上どのようなパスでたどり着けるかを解析して、その要素を Playwirght が選択するための locator コードを生成します。 生成されるコードの例。 page.locator('html') page.getByText('Click on the links above to') page.getByText('xxx') page.getBy

ポリシー: この世界では常に最新版を使うという気持ちで生きていく Node.js は枯れるという概念がなく、常に古いことはリスク という認識。LTS も短め(3年) 古いAPIのドキュメントは常に消失する モダンなツールは、モダンな前提を要求する ~2020: CJS/ESM 関連で断絶がある(jestが動かなくなりつつある) ~2019: パフォーマンス意識が低い時代の実装が多い ~2015: Node.js のみでしか動かないものが多い。peerDeps の意識が低い この辺で目視でポチポチする npm: npm-check-updates - npm yarn upgrade-iteractive pnpm upgrade -i サーバーランタイムには安定を、ツールチェインにはパフォーマンスを サーバーランタイム(Node.js) Node 本体は Stable LTS か、一つ前の

最近、技術書を読んでいると「完成形から逆算された、書き手にとって嬉しいコード」によく遭遇しています。 これが自分の理解ステップと噛み合わず、自分はこうだと嬉しい、といっても文句だけいうのも良くないと思い、自分の思う良いサンプルコードをまとめてみようと思います。 先に言っておきます。自分も自分の要求を全部同時に満たすことはできません。また、普段が自分が書くものは想定読者は自分として手を抜いています。手間を書けたとしても、一定以上の文量で必ず手間や実現性の部分でトレードオフが発生します。 自分の考える良いサンプルコード 最小スタート ステップ毎に何らかの動的/静的検査で検証できる。TDD だと望ましい 一度のコード追加は20行あたりが上限 上から順にコピペするとモジュールが動作する 最小スタート これは何らかのコンパイラを想定した適当なサンプルコードで、良い点悪い点両方あります。 // BAD

Server-Timing というヘッダがあります。サーバーからブラウザへのレスポンスヘッダとして、リクエスト内で発生した指標を送ることができます。 Server-Timing: miss;desc="Cache Miss", hit;desc="Cache Hit", db;dur=53.2, app;dur=47.2 何に使うかというと、ブラウザの DevTools や JS API からこの値にアクセスすることができます。 (現代のブラウザサンドボックスやJSではサーバーから送られたすべてのヘッダを覗き見れるわけではありませんが、これは見える値の一つです) サーバーから Server-Timing を返す方法 実験用の hono + deno で雑なサーバーをでっち上げます。 import { Hono } from "npm:hono@4.6.9"; const wait = (m

実践 いつ使うんだこれと思ってたら使う日が来たシリーズ。 今回、Deno で使ったんですが、 Node.js やブラウザでも Polyfill を入れれば動きます。 try finally で puppeteer を終了したい Deno で puppeteer を扱うために、こういうコードを書いてました。 // original import puppeteer from "npm:puppeteer@23.6.1"; import chromeFinder from "npm:chrome-finder@1.0.7"; let browser: puppeteer.Browser | null = null; try { browser = await puppeteer.launch({ headless: false, executablePath: chromeFinder(),