Supabase は、PostgreSQLを中心に「欲しい機能がだいたい揃ってる」優れたBaaSです。一方で、プロダクトが伸びる前段の個人開発やMVPだと「まず固定費を抑えたい」「リソース使用量が読めない」といった理由で、コストが気になる場面もあります。関連記事は baas と supabase にまとめています。
自分は なんでも解説動画ジェネレーター で、ジョブキュー管理のために PocketBase を採用しました。理由は単純で、要件がそこまで複雑ではなく、運用コストを最小にしたかったからです。
本記事では、PocketBaseを「Supabaseの代替」として雑に推すのではなく、PocketBaseを選ぶべき条件（そして選ぶべきでない条件）を整理します。どちらも素晴らしいサービスで、勝ち筋は要件次第です。
このブログのサイト内検索を、Google検索（site:）からPagefind
に移行しました。
Hugoで生成したpublic/をビルド後にPagefindでインデックス化し、静的サイト内で検索が完結する構成にします。
「ちょっと試したいことがあるから、新しいディレクトリ作って、tmux起動して…」という作業を毎回やっていませんか？
以前紹介したtry （詳細は「try: 深夜2時のひらめきを翌朝見つけられるか？ 」参照）は実験用ディレクトリを日付プレフィックス付きで管理してくれる便利なツールですが、そこからtmux セッションを起動するのは別作業でした。この2つを繋ぐためにtmux-try を作りました。
技術ブログやドキュメントを読むのは好きだけど、動画で見たいときもある。そんなときに「URLを入れるだけで解説動画ができたらいいのに」と思って作りました。
なんでも解説動画ジェネレーター は、URLを入力するとずんだもんや四国めたんといったキャラクターが内容を解説する動画を自動生成するWebアプリです。
この記事では、使い方と技術的な裏側を紹介します。
Every （テック/ビジネス系メディア「Every」を運営）が公開したCompound Engineering Plugin は、Anthropic のClaude Code （ターミナル向けAIコーディングアシスタント）用のプラグインです。
「機能を追加するたびにコードベースが複雑になる」——これは従来のソフトウェア開発における常識でした。しかし、Compound Engineering Pluginはこの常識を逆転させます。「機能が増えるほど開発が楽になる」という、一見矛盾した状態を実現する開発手法です。
本記事では、Compound Engineeringの核心である「Plan/Review 80%、実装 20%」という比率の意味と、技術的負債を資産に変える仕組みを解説します。
Ethereum でdApp（分散型アプリケーション）を作ると、ユーザーに「ウォレットを用意して」「ETHを買って」「ガス代を払って」とお願いすることになります。これが普及の壁です。
Account Abstraction（アカウント抽象化）は、この壁を崩すための仕組みです。EIP-4337 とEIP-7702 という2つの仕様があります。
結論から言うと、EIP-7702の登場で、4337の出番は大幅に減りました。単一ユーザーのバッチ実行や権限管理は7702だけで実現できます。4337が必要なのは「パーミッションレスなガススポンサー」と「複数ユーザー集約」の2つのケースに限られます。
本記事では、まず「なぜAccount Abstractionが必要か」を整理し、その上で7702と4337の使い分けを具体的に示します。
既存のWebサイトに対して「ここだけもう少し使いやすくしたい」「自分のワークフローに合わせて表示や挙動を変えたい」と思うことはありませんか？
「AI がブラウザを操作する」ツールは、Playwright や Puppeteer で既に実現されています。でもBrowser Code が狙っているのは、そこではありません。
「AIが操作する」のではなく、「AIが常駐するuserscriptを育てて、サイトを自分仕様に作り替え続ける」。それがBrowser Codeの本質です。
ブラウザ自動化（操作の再生）ではなく、userscriptの動的生成（改造の永続化）です。この違いを理解すると、どこで使えて、どこで使えないかが見えてきます。
「tmux 重そう、もっと軽いのないかな？」
100並列でAI開発環境のopencodeを動かすとき、ふとそう思いました。セッション管理ツールといえばtmuxですが、バイナリサイズも大きいし、もっとシンプルで軽量なツールがあるんじゃないか。そう考えて、tmuxの代替ツールを片っ端から試してみました。
結論から言うと、100並列ならtmuxが最軽量でした。
先日、プロジェクトの.envファイルをGitにコミットしたくてdotenvx-rs
で暗号化を試したんですが、毎回dotenvx runを打つのが面倒で挫折しかけました。「direnv
と組み合わせれば自動化できるのでは？」と思って試したところ、かなり快適な構成ができたので共有します。
「要件定義書はどこ？」「この設計、どの要件から来てるの？」「あれ、このリンク切れてる…」
チームが大きくなると、要件や設計ドキュメントが散らばり始めます。Confluence 、Notion 、Excel、Wiki、Markdown…ツールはバラバラ、リンクは切れ、誰も全体像を把握できません。
SARA （Solution Architecture Requirement for Alignment）は、この問題を「Markdown + Git + 知識グラフ（ドキュメント同士の関係をグラフ構造で表したもの）」で解決するCLIツールです。要件をMarkdownで書き、YAMLフロントマター（Markdown先頭のメタ情報）で関係を定義するだけで、トレーサビリティ（要件から実装までを辿れる性質）を自動で検証できます。