はてなブックマーク

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(),

Vue Vapor Mode をやる可能性があるので、調べることにした。 Svelteの知識があるので、自分の為のキャッチアップとして、Vue Vapor と Svelte 出力の比較を行う。SSR時の処理などは追ってない。 試した場所 https://vapor-repl.netlify.app/ の @2ed0be8 https://svelte.dev/playground 静的コンポーネント まず何もしない Static なコンポーネントで比較する。 Svelte import "svelte/internal/disclose-version"; import * as $ from "svelte/internal/client"; var root = $.template(`<h1>Hello</h1>`); export default function App($$an

ブラウザ内テキスト探索の高速化というテーマで改善を行いました。公開許可は頂いていますが、先方の希望で社名は伏せさせていただきます。 技術的には「再現性がある木構造のノード探索の条件の生成、その実行の高速化」という少しR&Dっぽいタスクでした。Playwright のコードを参考にしつつ、個別により速いパーツで置き換えていく、というもので非常に興味深いものでした。こういう仕事は楽しいので、いくらでも歓迎です。 今回は最初はドメイン理解に時間をあてて、その後十分にドメイン理解が進んだら計測しつつ改善する、という流れです。 以下、敬称略。 相談内容 ブラウザを自動操作する技術を開発している。技術的には一種のE2Eテストの応用技術で、サーバーに要素の探索条件と、その操作を登録する。 今回の相談では、その要素探索が重くなってしまうケースがあり、これを改善してほしい、という依頼。とくにテキストを条件に

株式会社ハウテレビジョン様で、 質問箱サービスMondのパフォーマンス分析と改善を行いました。 内容としてはLCPの内訳の計測、その解決方法の提案、そして一番大きな問題だった GraphQL リクエストの最適化という話になります。 現時点で全ての問題の修正には至っていませんが、開発的には全ての問題の内訳が認識可能になっていて、検証が終われば段階的にリリースできる、という状態です。 以下、敬称略 相談内容 mond.how のLighthouseスコアを改善してほしい 主要な技術構成 Next.js - Page Router Hasura CE - GraphQL Server Hasura のセルフホスティング版 計測と問題 最近は Chrome が出してくれる Lighthouse スコアの推移が見れるダッシュボードがある。 ここで Mond の直近のスコアをみる。 代表例として ht

パフォーマンスチューニングで、ソースコードに触らず非破壊でネットワークリクエストを書き換えて、LCPがどれだけ改善するかの実験ツールが欲しかったんですが、この目的で良いプロキシツールがないです。 世のローカルプロキシツールは DNS の設定を要求してきます。これは潜在的に意図しない状況を引き起こすので、使いたくありませんでした。 tl;dr puppeteer の page.setRequestInterception(true) でリクエストを覗いて、書き換えた ブラウザからリクエスト内容を奪う方法 テスト用HTML <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> </head> <body> <script type="module"> const x = await fetch('https://jsonp

Zaraz はCloudflare 版の GTM 要約すると Google Tag Manager の Cloudflare 版。クライアントだけではなく、Cloudflare CDN を通る時の CDN Edge でも動く。 メジャーなサードパーティスクリプトはCloudflare謹製のものがあるが、基本的には GTM にあるものをそのまま移せるようなものではなく、専用に実装されないといけない。 詳しい使い方はこちら Zaraz の目的 なんでわざわざ普及したGTMではなくこんなものを？という疑問があると思う。とくに初見だとこれがなんなのか本当にわからないはず。自分もサードパーティスクリプトの開発者を経験したからこそ分かる部分と、まだわかってない部分がある。 とりあえず次のブログでZarazの買収意図が書いてある。 あなたがサードパーティのスクリプト開発者で、スクリプトを適切に保護してい