takt で Codex・Cursor・Claude Code を協調させてみた ― 5回 ABORT して気づいた設計の急所
これはなに？ takt という AI エージェントオーケストレーションツールを使って、自作 OSS に新機能を追加してみた体験記です。Codex CLI で仕様レビュー、Cursor で実装、Claude Code で受け入れ検査という3つのエージェントを1つのワークフローで協調させました。 実際の PR はこちらです。 takt とは takt は複数の AI コーディングエージェントを順番に動かすためのツールです。「仕様レビュー → 実装 → テスト確認」のような一連の流れを YAML で定義しておくと、各工程を異なる AI エージェントに自動で割り振って実行してくれます。 takt ではこの一連の流れを「ピース」、各工程を「ムーブメント」と呼びます。工程ごとに Cursor、Codex CLI、Claude Code など好きなエージェントを指定できるのが特徴です。 正直なところ、t
Prisma から Atlas + Kysely への移行 - Supabase 環境での実践記録
これはなに？ 本番環境で約2年間 Prisma を使っていたプロジェクトを、Atlas + Kysely に移行した記録です。Supabase の PostgreSQL を使っている環境だったので、いくつか注意点がありました。この記事では、移行の動機から具体的な手順、そして移行リスクを抑えるために追加した E2E テストまで、一連の流れを共有します。 プロジェクトの背景 このプロジェクトは 2021年8月に Next.js で開発を開始し、約4年半運用しています。 技術スタックは何度か変わっていて、最初は Next.js と Supabase SDK を使っていました。認証も Supabase Auth を使っていたのですが、2023年7月に Remix へ移行したタイミングで Supabase SDK を外し、Prisma と自前の認証に切り替えました。2024年11月には React
Prisma 7 がつらくて Atlas + Kysely に移行した - Turso + better-auth 環境での実践
これはなに？ SlideCraft という、AI でスライドを修正・再構成するアプリを開発しています。React Router v7 + Turso + better-auth という構成で、認証基盤を Prisma 7 で管理していました。 しかし Prisma 7 へのアップグレードで色々とつらくなってきたので、思い切って Atlas + Kysely に移行したら想像以上に快適になりました。その経緯と手順を共有します。 Prisma 7 のつらみ ドライバーアダプター必須化 Prisma 7 から、SQLite 系のデータベース（Turso/LibSQL 含む）を使う場合はドライバーアダプターが必須になりました。 import { PrismaClient } from '@prisma/client' import { PrismaLibSQL } from '@prisma/ad
ルートファイルの凝集度を上げる React Router v7 リファクタリング
これはなに？ 前回の記事では、購入者・出品者・管理者のように異なるロールの機能を「同じカテゴリだから」とまとめてしまう問題を扱いました。コロケーション構成でルートを機能単位に分けることで、条件分岐が散らばらず保守しやすくなるという話でした。 今回は、その「分けたルートの中身」に注目します。ルートを適切に分割しても、ひとつのルートファイルの中で関係ない処理が混在していると、結局コードの見通しが悪くなってしまいます。 この記事では、ありがちなルートファイルを段階的にリファクタリングしながら、凝集度を上げるとはどういうことかを体感してもらいます。 本記事の内容を Notebook LM でスライド化したものも公開しています。視覚的に概要を把握したい方はこちらもどうぞ。 本記事のガイドラインを Claude Code などの AI アシスタント向けに CLAUDE.md へ記載する例を付録に用意し
機能的凝集とコロケーションで保守しやすい React Router v7 コンポーネント設計
これはなに？ 複数のユーザーロールや類似機能を含むフロントエンドで、コンポーネントをどう分割すべきか悩んだことはありませんか？本記事では「機能的凝集」という考え方と、remix-flat-routes のコロケーション構成を組み合わせることで、条件分岐が散らばりにくく保守しやすい設計を紹介します。 本記事では以下の技術スタックを前提としています。 React Router v7（framework モード、loader / action 使用） remix-flat-routes（Nested folders with flat-files convention） route.tsx をエントリポイントとしたコロケーション構成 本記事の内容を Notebook LM でスライド化したものも公開しています。視覚的に概要を把握したい方はこちらもどうぞ。 本記事のガイドラインを Claude C
ソフトウェア資産化ポエム
あるスタートアップが新しいSaaSプロダクトを開発しています。エンジニア10人、月給一人100万円なので、月の人件費は1000万円です。 経営者は「このプロダクトは絶対売れる」と確信しているので、会計士に相談して開発費の8割を資産化することにしました。月1000万円の開発費のうち800万円を資産として計上し、費用は200万円だけです。他の経費が月300万円、売上が月600万円あるので、PLは月100万円の黒字になります。経営者は「うちは利益が出ている」と喜び、投資家にも胸を張って報告します。 しかし実際のキャッシュは違います。売上600万円から人件費1000万円と経費300万円を引くと、毎月700万円が出ていきます。経営者は「黒字なのになぜ金が減るのか」と首を傾げますが、会計士は「資産化しているからです」と説明し、それで納得してしまいます。 半年が経ちました。PLは累計600万円の黒字です
React Router v7 の内部構造を探る：リクエストからレンダリングまでの道のり
はじめに React Router は、React アプリケーションにおけるルーティングライブラリのデファクトスタンダードとして長年利用されてきました。v6 で Data API が導入され、フルスタックフレームワークとしての側面が強化されましたが、v7 ではさらに進化し、Vite との統合、Single Fetch、Lazy Loading といったモダンな機能がデフォルトで組み込まれ、より洗練された開発体験とパフォーマンスを提供します。 しかし、これらの機能がどのように連携し、ブラウザのリクエストがどのように処理され、最終的にページが表示されるのか、その内部構造は少し複雑に見えるかもしれません。 この記事では、React Router v7 で構築されたアプリケーションの動作フローを、主要なパッケージやコンポーネントの役割、データ取得の仕組み、レンダリングプロセスなどに焦点を当てて、内
Turso の DB を drizzle でマイグレーションやってみる。
$ pnpm init Wrote to /Users/coji/progs/spike/turso/turso-drizzle-migration-example/package.json { "name": "turso-drizzle-migration-example", "version": "1.0.0", "description": "", "main": "index.js", "scripts": { "test": "echo \"Error: no test specified\" && exit 1" }, "keywords": [], "author": "", "license": "ISC" }
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
