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%が開発されている その改善

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 で

tskaigi で発表した https://tskaigi.mizchi.workers.dev/ のコピペしやすい用にしたバージョンです。 ほぼ marp のソースコードそのままですが、プロンプトのコピペ用にそのまま公開します。 本資料の内容 うまくいくプロンプト うまくいかないプロンプト、その理由 現状認識 注意: 前日リリースのClaude 4 の評価は間に合ってません!!!! Claude 4 Opus の高すぎる怖い 数時間触った感じ: 改善傾向だが、抱えてる問題も同じ傾向 主張: 言語特化プロンプトが必要(今は) Coding Agent は言語ごとのユースケースに最適化されていない ベストプラクティスをユーザーが取捨選定する必要 TS 周辺は技術選定で発散しがち プログラミング言語間の転移学習は不安定 GitHub を丸暗記しても、コンテキストに応じて翻訳&参照できるかは別の

気合の脱 create-react-app からの、AIによるフロントエンド改修の自動化 (株式会社イルシル様) 株式会社イルシル様の依頼で、フロントエンドの近代化とパフォーマンス分析を行った事例を紹介します。 「イルシル」は、生成AIでスライド資料作成を自動化し、誰でも簡単にスライドやパワポが作れるサービスで、スライドのデザインは1,000種類以上あり、入力したテキストからスライドを自動生成できるだけでなく、オリジナルで作成することも可能です。 いわゆる、複雑フロントエンドの事例です。ブラウザ上でAI経由でスライドを生成して、それをUIから編集でき、最終的には PDF や パワーポイントとしてエクスポートします。 LCP や CLS ではなく、 TBT やメモリリークの調査がメインになります。 長くなったので最初に要約します。以下の内容を含みます。 泥臭い CRA => Vite 移行

やりたいこと Zenn で Git 連携時、リポジトリ内の images/xxx.png は  でアクセスできる。 また、vscode の markdown モードは Ctrl-V でクリップボードから画像を貼り付けることができる。GitHub や Zenn の Web 上のテキストエリアのような挙動。 これを組み合わせて、Windows の Win-Ctrl-S から vscode の Markdown 編集バッファで Ctrl-V を押した時、次のようにクリップボードから画像を挿入したい。

現状たぶんこれが一番安いと思います。(※個人開発前提のスタックです) 実現したこと opennext for cloudflare prisma (no-rust, no-engine) prisma-postgres (free plan) つまり Cloudflare 上で Next.js を動かして、現実的なビルドサイズで Prisma を動かせました。 自分の手元のビルドサイズです。 ┌ ○ / 149 B 102 kB ├ ○ /_not-found 978 B 103 kB ├ ○ /prisma-test 149 B 102 kB # ... + First Load JS shared by all 102 kB ├ chunks/770-76939705ff65587a.js 46.5 kB ├ chunks/96e220d1-21a0fdc894793ec0.js 53

(これは某所でやる 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

既存の LLM コード生成の問題 LLM は行カウントやワードカウントが苦手。 例えば自分は SourceMap を扱うコードのテストを書かせようとしたが、モックデータの line:column がガバガバな位置を指してまともにテストにならない。行カウント/ワードカウントができないのはつまり diff がうまく生成できない。 これらの問題があって、コードを生成するパイプラインを組む場合、 全文出力が主流になっている。 ここで何が問題になるかというと、コードが膨らんで来た時に、(書き変える対象が一部だとしても)生成が顕著に遅くなる。うまく生成できなかった時にリトライを繰り返すと、問題がさらに悪化する。 改善手法の提案: 明示的な Line Number の付与 最近の LLM は入力ウィンドウがある程度大きくても、そこそこの速度で応答する。(お金はかかるが...) 問題は生成速度にある。特に

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

本書はプログラマではない人向けに、AIを通したプログラミングを前提に、プログラミングの基本概念を説明することを試みたものです。 本書は非プログラマ・プログラマ・AIの間に共通語彙・共通理解を作ることを目標としています。プログラミングの理解なしにプログラミングができるようになる本ではありません。 注意: 書きかけです。現在、およそ半分程度はAIに書かせて、自分で軽くレビューしてる程度です。有料設定されていますが、投げ銭用であって全文無料で読めます。将来的に有料になる可能性はあります。

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

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 ├─

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

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

以下の公開計測会でやったものを個別に解説してみる。 細かいテクニックが多いのだが、それを可能な限りテキストとスクショで解説したい。使い方の解説が中心で、どういう意味があるかは解説しない。 Chrome131時点のスクリーンショットで、後で読む場合は頻繁にUIが変わっている点に注意。大事なのは意図。 宣伝: これを御社のサイトで解説する仕事をやっています。 デモのURL これに意味はなく、今日偶然見ていただけで意図はない。関係ないがエッジランナーズは最高のアニメ。 DevTools を開く F12 or 右クリックから「検証」 DevTools > Lighthouse この状態で計測 このとき、新しいプロファイルを作ったりして、可能な限り Chrome拡張が入ってない状態にすること。Chrome拡張による処理も計測に含まれてしまう。 Lighthouse レポートの読み方 点数部分にマウス

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

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