monolithic kernel

固定した mise のバージョンを multi-gitter でまとめて更新する

Fri, 20 Feb 2026 15:00:00 GMT

GitHub Actions で mise-action を使うときの再現性のために mise のバージョンを固定したのだが、これによって、mise のバージョンを更新する手間が生じるようになった。同じことをやっているリポジトリが複数ある場合、リポジトリの数だけ作業を繰り返す必要があり非常に面倒。

同じ操作を繰り返すだけの単純作業なので、まとめて更新したいと思い調べていたところ、multi-gitter というツールを見つけた。複数のリポジトリでコマンドを実行して、ファイルが正常に更新されたらその内容を push するという、今回の目的にはまさにぴったりなものだった。

#!/bin/sh
MISE_VERSION="$(curl -s https://mise.jdx.dev/VERSION)"
MISE_VERSION="$MISE_VERSION" multi-gitter run "./mise-up-internal.sh" \
  --token "$(gh auth token)" \
  --repo org/repo --repo ... \
  -m "Bump mise version to $MISE_VERSION" --skip-pr

#!/bin/sh
perl -i -pe "s/^(\s*version:\s*)[0-9.]+/\${1}$MISE_VERSION/" .github/actions/setup-mise/action.yml

--token には事前に gh auth login でログインして用意しておいたアクセストークンを渡している。今回は個人用なのでデフォルトブランチに直で push しているが、Pull Request を作成することもできる。

これで、リポジトリがいくら増えても大丈夫そう。

mermaid-rs-renderer でブラウザ依存なしで Mermaid をレンダリングする

Sat, 14 Feb 2026 16:00:00 GMT

mermaid-rs-renderder (mmdr) という Rust で書かれたスタンドアロンの Mermaid のレンダラーを使うことで、ブラウザ依存なしで Mermaid の図をレンダリングできる。Mermaid の公式の実装では Puppeteer や Playwright が必須で、静的サイトの構築やサーバサイドレンダリングにおいては実行環境の構築に躓きやすくなるため、ブラウザ依存がなくなるのはうれしい。

mmdr は Rust で書かれているので、Rust のアプリケーションであればライブラリとして組み込むこともできるが、そうでない場合は CLI のコマンドで使うことになる。

このブログに組み込んでいる Mermaid のレンダリング機能の場合は、以下のようなコードで mermaid-cli から簡単に置き換えられた。

import * as child_process from "node:child_process"

const renderSVG = async (mermaidContent: string): Promise<string> => {
  return await new Promise<string>((resolve, reject) => {
    const child = child_process.execFile("mmdr", ["-e", "svg"], (error, stdout) => {
      if (error != null) {
        reject(new Error("Failed to render mermaid diagram", { cause: error }))
      } else {
        resolve(stdout)
      }
    })
    const stdin = child.stdin
    if (stdin == null) {
      reject(new Error("Failed to write to mmdr process"))
      return
    }
    stdin.write(mermaidContent)
    stdin.end()
  })
}

// ...

mmdr のインストールには mise を用いている。

[tools]
"github:1jehuang/mermaid-rs-renderer" = "0.2.0"

これも結構実行環境を選ぶ要素になってしまう気はしつつ、自分の場合は GitHub Actions なのでまあいいかなと。npm にパッケージがあるとうれしい。

npm にパッケージがあってブラウザ不要という意味だと、beautiful-mermaid がよさそうかもとも思った。ただ、こちらは文法の互換性がそこまで高くないようで、図を修正しないとエラーになってしまったので、今回は mmdr を選んだ。

Astro で1つのコードベースから複数のサイトを生成する

Sat, 31 Jan 2026 18:00:00 GMT

Astro で複数のサイトを生成していると、コンテンツは異なるがコードはほとんど同じということがある。そのような状況で、コードベースを一本化してメンテナンスを楽にする方法を検討した。

公式に案内されているものがあればそれを採用したかったのだが、見つけられなかったので、あまり凝ったことはせずに、シンプルにシンボリックリンクを使った方法で実現してみた。

サイトの構成

以下のようなディレクトリ構造にして、content のシンボリックリンクが示す先を切り替えることで、生成するサイトを切り替える。

.
├── sites/
│   ├── site-a/ # サイトAのコンテンツ
│   │   ├── blog/
│   │   ├── public/
│   │   └── metadata.json
│   └── site-b/ # サイトBのコンテンツ
│       ├── blog/
│       ├── public/
│       └── metadata.json
├── content -> sites/site-a/ # シンボリックリンク
└── src/ # 共通コード

package.json にサイト切り替えコマンドを用意している。

{
  "scripts": {
    "switch:site-a": "ln -sfn sites/site-a content",
    "switch:site-b": "ln -sfn sites/site-b content"
  }
}

ビルド前にこのコマンドを実行することで、ビルド対象を切り替える。

pnpm run switch:site-a
pnpm run build

Astro 側は、content 以下を参照してビルドするように普通に設定している。サイトごとに挙動を変えたい場合は、設定ファイルも content 以下に配置して読み込めばよい。

ビルド・デプロイ

GitHub Actions の matrix 機能を使い、各サイトを並列にビルド・デプロイしている。自分の場合だと Cloudflare Workers をデプロイ先にしているので、wrangler.toml にサイトごとの環境を定義しておいて、デプロイ時に指定している。

get-sites:
  runs-on: ubuntu-latest
  outputs:
    sites: ${{ steps.set-matrix.outputs.sites }}
  steps:
    - uses: actions/checkout@v6
    - id: set-matrix
      run: |
        SITES=$(ls -1 sites | jq -R -s -c 'split("\n")[:-1]')
        echo "sites=$SITES" >> "$GITHUB_OUTPUT"

deploy:
  needs: get-sites
  strategy:
    matrix:
      site: ${{ fromJson(needs.get-sites.outputs.sites) }}
  runs-on: ubuntu-latest
  steps:
    # ...

    - run: pnpm run "switch:$SITE"
      env:
        SITE: ${{ matrix.site }}

    - run: pnpm run build

    - run: wrangler deploy --env "$SITE"
      env:
        CLOUDFLARE_ACCOUNT_ID: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}
        CLOUDFLARE_API_TOKEN: ${{ secrets.CLOUDFLARE_API_TOKEN }}
        SITE: ${{ matrix.site }}

[env.site-a]
name = "site-a"

[env.site-b]
name = "site-b"

jdx/mise-action で mise のバージョンを固定する

Wed, 28 Jan 2026 16:00:00 GMT

GitHub Actions におけるサプライチェーン攻撃への対策として、サードパーティのアクションを利用する際に commit SHA を指定するという方法がある。これによって、commit SHA を書き換えない限りはずっと固定のバージョンが使われることになり、ワークフローの書き換えなしでいつの間にか悪意のあるコードが実行されていた、ということを防げる。

mise を GitHub Actions で使用するための公式のアクションとして、jdx/mise-action がある。これを使うときも commit SHA を指定しておけば安心かというと、個人的には不十分なのではないかと考えている。というのも、jdx/mise-action では、mise のバージョンを指定しなかった場合に自動的に最新の mise がダウンロードされるようになっている。つまり、最新の mise が侵害された場合には、ワークフローの書き換えなしで悪意のあるコードが実行されることになってしまう。

対策としては、mise のバージョンも固定してしまえばよい。mise のバイナリは GitHub Release からダウンロードされるようになっており、mise のリポジトリでは Immutable Releases が有効なので、バージョンを固定しておけば常に同じバイナリが使われることになる。

- uses: jdx/mise-action@6d1e696aa24c1aa1bcc1adea0212707c71ab78a8 # v3.6.1
  with:
    version: 2026.1.8

jdx/mise-action を何度も使う場合、すべての箇所でバージョンを指定するのはかなり面倒である。変数を使うのもよいが、Composite Action を使うのがスッキリ書けてメンテナンスもしやすいのではないかと思う。

name: Setup mise
description: Setup mise with version pinning
runs:
  using: composite
  steps:
    - uses: jdx/mise-action@6d1e696aa24c1aa1bcc1adea0212707c71ab78a8 # v3.6.1
      with:
        version: 2026.1.8

使う側では uses: jdx/mise-action@... の代わりに以下のようにすればよい。

- uses: ./.github/actions/setup-mise

chezmoi でのスクリプトキャッシュをクリーンな環境で作る

Wed, 26 Nov 2025 08:00:00 GMT

過去に、chezmoi のテンプレート機能を使ってシェルの起動を高速化する方法を紹介した。

chezmoi のテンプレート機能を使ってシェルの起動を高速化する

基本的にはこれでうまくいくのだが、コマンドによっては問題になる場合がある。呼び出し時の環境変数の内容を考慮して初期化処理を変えるような場合である。mise なんかがそれに該当する。

普段使っている環境で chezmoi コマンドを実行すると、その時の環境変数で chezmoi コマンドが実行され、そこから起動されるプロセスにも引き継がれる。それによって、期待したスクリプトのキャッシュが生成されない場合がある。

これを回避するためには、呼び出し元の環境変数の影響を排除して chezmoi コマンドやそこから呼び出されるコマンドを実行できればよい。そのために、環境変数をリセットして chezmoi コマンドを実行するようなラッパーを作成した。

#!/bin/bash
# Run chezmoi in a clean environment with Homebrew environment variables set up.
set -eu

exec env -i \
  HOME="$HOME" \
  HOMEBREW_PREFIX="${HOMEBREW_PREFIX:-/opt/homebrew}" \
  GITHUB_ACTIONS="${GITHUB_ACTIONS:-}" \
/bin/bash --noprofile --norc -s "$@" << 'EOF'
eval "$(/usr/libexec/path_helper -s)"
eval "$("$HOMEBREW_PREFIX/bin/brew" shellenv)"
exec chezmoi "$@"
EOF

env コマンドの -i オプションを指定することで、継承した環境変数を無視してコマンドを実行できる。そこから起動する bash コマンドにも --noprofile --norc オプションを付けて設定の読み込みを抑止している。それだけだと必要な環境変数も消えてしまうので、最低限必要になる HOME や /usr/libexec/path_helper の結果 (macOS の場合) や、Homebrew でインストールしたコマンドを使うための brew shellenv の結果も設定したうえで chezmoi コマンドを実行している。

zsh-smartcache とかのほうが本来の実行タイミングでキャッシュを作るので問題が少ないのかなと思いつつ、一旦これでもできてますということで。chezmoi コマンドの中でやるのにふさわしい複雑な操作がでてきたら価値が出てくるかもしれない。

Deno と Bun から Node に戻ってきた

Sat, 18 Oct 2025 02:00:00 GMT

個人的なコードで、ちょっとしたスクリプトでは Deno、本格的な開発では Bun というように、JS のランタイムを使い分けていたのだが、Node に戻ってきた。

きっかけは、Deno だと Dependabot が使えず、Renovate を使うのにもかなり労力が必要だったこと。cooldown したかったので結構残念に感じた。

もともと TypeScript を手軽に使いたくて Deno を触り始めたのだが、Node でも TypeScript を実行できるようになったことで、実は Deno である理由ってそんなにないんじゃないかと思った。Deno は周辺ツールがオールインワンなところもよかったりするのだが、Biome が進化してきたことで、こちらも Deno ならではの魅力としては映らなくなってきた。

加えて、pnpm に minimumReleaseAge が入ったことで、久しぶりに pnpm を触ってようと思い、Bun のコードも含めて全部 Node に揃えてしまおうと思った。

# 後で気付いたけど Bun にも minimumReleaseAge 来てたので、Bun に関してはあんまり移行する理由なかったかも。

Bun のコードは、package.json に書かずに使われていた依存があったので pnpm 化で多少の修正が必要になったものの、Astro のアプリケーション部分は何も変更せずに Node に持ってこれた。すごい。

一方、Deno に関しては Deno 固有の API を使っている部分を書き換える必要があった。現在は Deno でも Node 互換の API が整ってきているのだが、昔からのコードだと厳しい。この作業を経て、今となっては、Deno で書くにしても Node の API を使っておいたほうがよいように思った。

# シェルスクリプトの代替的な利用を便利にしてくれる dax は、dax-sh というパッケージで Node でも使えるようになっていた。素晴らしい。

依然として Deno ならではの点として残るのはパーミッションだろうか。これは普通に使い所はかなりある気がしている。Node も追従しているものの、Deno ほどのものではなさそう。ただ、実行時にならないと必要なパーミッションが分からないのがちょっとしたスクリプトには面倒で、結局 -A みたいなことになってしまう。あらかじめ使うパーミッションを宣言しておいて、それに応じて API を使えるかどうか実行前にわかるみたいなモデルがほしい。

Bun は独自の API を増やしまくっているが、先述の Deno API の話と同様で、個人的には魅力だとは感じない。Node との互換性は高いので Node とどちらでもいいと言えばいいのだが、だからこそ今回みたいなちょっとした違いでも切り替えて使えるということで、移行して試してみることにした。

pnpm の面倒なところとして、pnpm を使うための準備が面倒というのがあった。手元にしても CI にしても Node を入れるだけでは使えず、追加で一手間が生じるし、その一手間も分かりやすいとは思えない。これについては、今だと mise を使うことで楽になると気付いた。mise は言語処理系だけでなくパッケージも管理できるので、pnpm を mise でまとめて管理しておけば、mise install 一発で pnpm も含めて Node 環境を構築できる。

[tools]
node = "24.10.0"
"npm:pnpm" = "10.18.3"

まだとりあえずの切り替えが終わったところだが、各ランタイムが競争して進化していることが分かってよかった。今後、移行したことで何かしら困っても、また別のランタイムにすぐ移行できると分かったので、かなり身軽な気分になった。

Apple のリマインダーに外部システムから項目を追加する

Thu, 18 Sep 2025 13:00:00 GMT

Apple のリマインダーはアプリとしては必要十分な機能があって便利なのだが、外部システムから項目を追加しようとすると、簡単な方法が用意されていなくてやりづらい。他社のサービスだと、専用のアドレスにメールを送ったり、API を呼び出したりすることで追加できるので、似たような感覚で外部システムと連携できるとうれしい。

調べてみた感じでは、いくつか方法がありそうだった。

IFTTT でメールをトリガーとしてリマインダーに追加する

iOS デバイスに IFTTT アプリをインストールしていれば、リマインダーへの追加をアクションとして実行できる。IFTTT は無料だとかなり制限が多めではあるものの、メールをトリガーとしてリマインダーに追加するだけに使うのであれば無料の範囲で使える。メールではなく Webhook を使いたいという場合は有料になる。

Microsoft アカウントをリマインダーアカウントに追加する

iOS や macOS では Microsoft アカウントでログインしてリマインダーを使うことができる。この状態では Microsoft To Do のデータを読み書きすることになるので、Microsoft To Do 側でデータを流し込めればリマインダーアプリ上でも確認できる。

Activepieces というノーコードの自動化ツールが Microsoft To Do への項目の追加に対応しているので、Activepieces 側で Webhook などをトリガーとしたフローを構築し、項目を追加すればよい。

これを Apple のリマインダーに項目を追加したと呼ぶかは微妙だが、アプリ上で一元管理できるという意味では使い勝手に大きな問題はない。

メール受信をトリガーとしてオートメーションを実行する

iOS のショートカットでは、特定のアドレスや件名のメールを受信したことをトリガーとしてショートカットを実行するオートメーションを設定できる。ショートカットが使えればリマインダーの操作もできる。

ただ、メールも受信してしまうので邪魔という問題がある。専用のアカウントを用意して通知が飛ばないようにしておくなどの工夫が必要になりそう (他の方法を採用したので深追いはしなかった)。

Pushcut で Webhook をトリガーとしてショートカットを実行する (有料、未確認)

有料サブスクリプションの契約が必要になるので試していないが、Pushcut というアプリで Webhook をトリガーに任意のショートカットを実行できるようだった。ショートカットが使えればリマインダーの操作も理屈的にはできるはず。

個人的な選定とその理由

個人的には上から順に気に入っていて、現在は IFTTT を使っている。Microsoft アカウントで連携する場合もそこまで問題はないのだが、リマインダーが複数アカウントを使っているときの UI になって若干煩雑になるのと、Microsoft アカウントだとリストのアイコンを設定できないのが気になって、結局 IFTTT に流れた。

メール受信のオートメーションは、ゴミメールが溜まる問題を解決できそうであればありな気がする。IFTTT で困ったら考える。

Pushcut は他の方法で無料でどうにかなっている限りは個人的には興味が沸かない。

これで何をしているのか

サブのスマホやタブレットのバッテリー残量が低下した際に、リマインダーにそのデバイスを充電するという項目を追加する使い方をしている。これだけ聞くと、バッテリー残量が低下したらリマインダーに追加するオートメーションを組めばよいと思うかもしれないが (というか実際そう)、自分の場合は Android のスマホや別の Apple アカウントでログインした iPhone についても連携したいため、このほうな方法を採っている。

GitHub Actions の Ubuntu 24.04 で Puppeteer が動かない問題

Tue, 16 Sep 2025 13:00:00 GMT

表題の通り、Ubuntu 24.04 (記事公開時点での latest) を使っていると、Puppeteer が動かない問題がある。

[Bug]: "No usable sandbox!" with user namespace cloning enabled · Issue #12818 · puppeteer/puppeteer

これは、Ubuntu の AppArmor が Puppeteer がダウンロードした Chrome のバイナリを実行させないようにしているために起きている。Ubuntu 22.04 (ubuntu-22.04) を使うことでも回避できるのだが、Ubuntu 24.04 を使いたい場合には、SUID sandbox という古い sandbox で実行することで回避できるようである。

Troubleshooting | Puppeteer

GitHub Actions の workflow に落とし込むと以下のようになる。

jobs:
  task:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
      - uses: actions/setup-node@v5

      - run: |
          npm ci

      # https://pptr.dev/troubleshooting#issues-with-apparmor-on-ubuntu
      - name: Prepare puppeteeer SUID sandbox
        id: sandbox
        run: |
          SANDBOX=$(find ~/.cache/puppeteer -type f -name chrome_sandbox | head -n1)
          sudo chown root:root "$SANDBOX"
          sudo chmod 4755 "$SANDBOX"
          echo "sandbox_path=$SANDBOX" >> "$GITHUB_OUTPUT"

      - run: |
          npm run task
        env:
          CHROME_DEVEL_SANDBOX: ${{ steps.sandbox.outputs.sandbox_path }}

Dependabot の cooldown 機能でサプライチェーン攻撃のリスクを緩和する

Sun, 07 Sep 2025 05:00:00 GMT

今まで Bun なら bun update などで手動で依存ライブラリを更新していたのだが、Dependabot を使うようにした。わざわざ手動でやるべきことでもないよねという話もあるものの、一番大きいのはサプライチェーン攻撃対策のため。

適当にライブラリを更新していると攻撃コードの入ったバージョンを踏んでしまうリスクが現実的に高まっているのを感じていたので、Renovate のようにリリースしてから一定期間経過した更新だけを取り込むようにしたいと考えていた。ただ、Renovate は導入するのに手間がかかりそうで、なかなか導入するに至っていなかった。

それが最近になって Dependabot で cooldown としてサポートされたことで、簡単に導入できるようになった。これによってついに導入する気になった。

ただ、手間という面だと、自動化すると便利というよりも大量の Pull Request が作られて、むしろ厄介なんじゃないかという懸念もあった。あまりメンテナンスされていないリポジトリにおいて、Dependabot が作成した Pull Request が大量に並んでいるのはよく見る光景である。

# Dependabot CLI を使えばローカルで cooldown ありで更新できるのかもしれないが、使っている人がそこまで多くなさそうなので試していない。

これについては、Groups という機能を使うことである程度解決できそうだった。条件に当てはまる更新をひとつの Pull Request にまとめてくれる機能で、ひとまずマイナーな更新は全部まとめてしまうようにした。

version: 2
updates:
  - package-ecosystem: "bun" # See documentation for possible values
    directory: "/" # Location of package manifests
    schedule:
      interval: "weekly"
    cooldown:
      default-days: 14
    groups:
      dependencies:
        patterns: ["*"]
        update-types: ["minor", "patch"]

# 無いと思うけど、みんな cooldown するのが当たり前になったらどんどん cooldown 期間を延長しないと意味ないねってなったりするんだろうか……？

M5Stack CoreS3 SE と GR-M02U で位置情報を取得する

Tue, 26 Aug 2025 16:00:00 GMT

前回作った環境で、実際に位置情報を取得するコードを動かしてみた。前回も使用した felis/USB_Host_Shield_2.0 に含まれている pl2303_tinygps を動かせばいけるかと思いきや、それでは位置情報を得られずトラブルシューティングが必要だった。

試行錯誤の結果を PlatformIO で動くようにしたのがこちら。

https://github.com/mono0x/pl2303_tinygpsplus

pio run -t upload
pio device monitor

--- Terminal on /dev/cu.usbmodem1101 | 9600 8-N-1
--- Available filters and text transformations: colorize, debug, default, direct, esp32_exception_decoder, hexlify, log2file, nocontrol, printable, send_on_enter, time
--- More details at https://bit.ly/pio-monitor-filters
--- Quit: Ctrl+C | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H

Acquired Data
-------------
Location: xx.xxxxxx,xxx.xxxxxx
Date/Time: 2025-08-26 13:14:43.40
Altitude: x.xxm
Course: 0.00deg
Speed: 0.07km/h
Satellites: 9
HDOP: 1.41
Chars: 10236  Sentences: 100  Failed checksum: 0
-------------

具体的には、TinyGPS だと動かなくて、TinyGPS を改造するか TinyGPS++ に移行する必要があった。というのも、TinyGPS は NMEA データのうちの Talker ID が GP であるもののみサポートしていたのに対して、GR-M02U では GN で出力していたため。GN は複数衛星混在の情報であることを示しているようで、GR-M02U は衛星ごとに Talker ID を使い分けることはないようだ。TinyGPS++ では、Talker ID のサポートが拡大されていて問題なかった。

M5Stack CoreS3 SE と USB Module with MAX3421E v1.2 で GR-M02U を扱う

Sun, 24 Aug 2025 06:00:00 GMT

もともと Android スマートフォンを GPS ロガーとして使っていたのだが、用途に対してオーバーキルすぎるとは感じていたので、他の選択肢を検討している。Raspberry Pi 系のデバイスは、試してみて動くものを作れそうな感じはしたものの、ディスプレイやボタンなどの操作系がないために、出先でのコントロールが難しそう。

そこで、そのあたりをカバーできる可能性を探っていたところ、M5Stack にたどり着いた。M5Stack は、ESP32 という無線モジュール付きのマイコンに、ディスプレイ、ボタンなど UI 周りを揃えたパッケージングがされているため、ハードウェアに明るくない自分でもどうにかなるのではないかと思った。

ところが、実際やってみると、インターネット上に情報が少なく、ChatGPT などもまったく役に立たないために相当に苦戦した。まだ完成どころかやっとこさ GPS の信号を受信できたという段階だが、少しでも参考になればということでメモを残しておく。

本体は M5Stack CoreS3 SE で、GPS レシーバーには GR-M02U を使った。GR-M02U を接続するために、USB Module with MAX3421E v1.2 を使った。

# USB の GPS レシーバーを使おうとしていることで難易度が跳ね上がっていると思うので、何もないところから始めるなら GNSS モジュールを使ったほうがよさそう。こちらは解説している情報もいくつかあるっぽい。

もともと、M5Stack CoreS3 SE に USB OTG、CDC 機能があるという記述を見て手に取ったのだが、調べてみても使い方がさっぱりわからなかったため、USB Module を使うことにした。開発やデバッグの際に本体側の USB を PC と繋ぎっぱなしにできるので、こちらの構成のほうが現実的だと思った。

純正の USB Module を使ったとしても、引き続き使い方がわからず途方にくれることになった。DIP スイッチで構成変更できるので、CoreS3 にも対応できるという記述はあるものの、DIP スイッチをどう設定すればいいかという説明はどこにも見当たらない。

困っているのは自分だけではなさそう。

公式の m5stack/M5-Max3421E-USBShield は使い方がわからず。いろいろ調べていく中で、felis/USB_Host_Shield_2.0 という M5Stack に限らない USB Host のライブラリを見ていたところ、つい最近 (2025年8月) CoreS3 対応のコードを入れてくださった方を発見。最新バージョンで試したら動作した。

Added the pin definitions to support the m5 usb model on m5stack s3 by zer044 · Pull Request #843 · felis/USB_Host_Shield_2.0

DIP スイッチは Pull Request に書かれているように SS と INT どちらも CH2 を ON に設定した。

https://i.imgur.com/BvlmodC.jpeg

(CH2 のみ両方左側で、他は右側)

この状態で、README に沿ってライブラリをインストールした上で、examples/USB_desc や examples/pl2303/pl2303_gps のコードを Arduino IDE 上で動作させることができた。いろいろハマりポイントもあった。

M5Stack 本体と USB Module のピンでの接続がギリギリのようだったので、しっかりはまるようにした
- 固定方法がわかっていないのでマスキングテープで抜けないようにしているが、どうしたらいいんだろう
GR-M02U を直接 USB Module に繋いでもインジケータ LED が点灯しなかったので、USB 電源補助ケーブルで給電した (手元にあった UPAC-UT07M を使用)
pl2303_gps に関しては lc.dwDTERate を GR-M02U 側の Baud Rate に合わせて (自分の場合は 115200) 更新した
- 間違っていても接続さえできていれば文字化けしまくったデータが Serial に流れてくるので、そもそも動いていないこととの区別はできる

これでやっとこさやりたいことを実現するアプリケーションに取り掛かれる。険しい道のりだった。

<del>でも Android スマホの便利さを痛感したのでもうそれでもいいかも……。</del>

Astro で使っている BudouX のバージョンを 0.7.0 に上げた

Fri, 27 Jun 2025 18:00:00 GMT

見出し部分の折り返しを自然にするために使っている BudouX のバージョンを最新の 0.7.0 に上げた。0.6.4 から 0.7.0 に上がる際に JSDOM を linkedom に置き換える破壊的変更が入ったことで、参考にしていたコードが使えなくなって困っていたのだが、Claude Code に調べてもらって解決した。

結論としては、wbr 要素を作るために linkedom を使うようにすればよかった。

npm install linkedom

import { HTMLProcessingParser, jaModel } from "budoux"
import { parseHTML } from "linkedom"

const { document } = parseHTML("")
const wbr = document.createElement("wbr")

const parser = new HTMLProcessingParser(jaModel, {
  className: "budoux",
  separator: wbr,
})

export function budouxProcess(html: string) {
  return parser.translateHTMLString(html)
}

他の部分は参考にしたページのものから変更なしで動いてそう。やはり、静的サイトジェネレータを使っているからにはこういった処理は静的に解決できるのが気持ちいい。

Astro のブログで Embedding を計算して類似の記事を表示するようにした

Fri, 27 Jun 2025 12:00:00 GMT

以前バックリンクを解析したときの延長で、各記事の Embedding を計算して類似の記事を探索し、記事の末尾に表示するようにした。

Astro Integration の中で強引にファイルを読んで、Remark プラグインとして類似記事の識別子を入れ込むという大まかな流れは同じ。各記事ごとに Embedding を計算する部分は OpenAI の Embeddings API (と記事が長すぎるときの要約に Chat completions API を少々) 利用し、計算した全記事の Embedding を hnswlib-node に流し込んで Embedding が近い記事を探索している。

ビルドのたびに Embedding を再計算していると遅すぎるしお金が掛かるので (と言っても全記事処理しても数円程度)、永続化しておいて記事ファイルのハッシュ値が変化したときのみ再計算するみたいな工夫も入れ込んでいる。

うちのブログ程度にこんなものが必要あるかといえば無いとは思っているのだが、触ってみたかったもろもろの API やライブラリに触れるのと、Claude Code にコード生成させてみるお題として取り組んでみた感じ。Claude Code は取っ掛かりのわからなさや面倒くささをどうにかしてくれるという意味ではよかったものの、コードについてはなかなか納得いかなくて試行錯誤することも多かった。今はそれが新鮮だから楽しいなという感じ。長い目で見てどうかはさっぱりわからんね。

生成させたコードの品質に完全には納得いっていないというのと、そこそこデカいというのもあってコードは掲載していない。前回と今回の記事の情報があれば結局ある程度コード生成させることはできるだろうし、それが各自のコードベースに基づいて行われるならそのほうが手っ取り早いのかなというのもある。

VSCode や Cursor の Integrated Terminal 使用時に Git のコミットメッセージエディタを切り替える

Sun, 11 May 2025 11:00:00 GMT

知人に git commit で何のエディタを使っているか訊かれて、答えたら感心されたので紹介する。

個人的には、ターミナルを使っているときはターミナルでそのまま編集したいし、Visual Studio Code (VSCode) や Cursor の Integrated Terminal を使っているときは、VSCode や Cursor 自体のエディタで編集したい。それを実現するために、状況に応じて起動させるエディタを分岐させるシェルスクリプトを書いて、エディタの代わりに指定している。

#!/bin/sh
set -eu

if [ -n "${CURSOR_TRACE_ID:-""}" ] && [ -x "$(command -v cursor)" ]
then
  exec cursor --wait "$@"
elif [ "${TERM_PROGRAM:-""}" = 'vscode' ] && [ -x "$(command -v code)" ]
then
  exec code --wait "$@"
elif [ -x "$(command -v nvim)" ]
then
  exec nvim "$@"
else
  exec vim "$@"
fi

[core]
  editor = /path/to/commit-message-editor

Integrated Terminal 内にいるかどうかは、環境変数を見れば判断できるらしい (当時調べて書いたはずだが忘れた)。また、コミットメッセージの編集に使う上では、code や cursor に --wait オプションを付けておけば編集が終わるまで待機するような挙動にできる。気が利いてる。

ブログのデプロイ先を Cloudflare Workers に切り替えた

Fri, 02 May 2025 02:00:00 GMT

もともと Cloudflare Pages を使っていたのだけど、今後は Cloudflare Workers がよいそうなので乗り換えてみた。といっても、Astro で生成している静的な Web サイトだし、Functions とかを使う必要性もないので特に何か恩恵があったりはしない。

そして、すんなり移行できたかというとそういうわけではなくて、Pages ではビルド時に Puppeteer を使えていたのが Workers では使えなくなってしまった。Bun 1.2 のサポートでも bun.lock を認識してくれない問題があったし (こちらは軽微)、今後も Cloudflare のビルド環境で悩まされるリスクを感じて、GitHub Actions 上でビルドしたものをデプロイするだけにした。

こちらは特に困らなかったが、公式の wrangler-action を使ったとしても. deprecated な wrangler が入る (？) っぽく、結局自前で npm の wrangler を使うことになった。

name: deploy
on:
  push:
    branches:
      - main
jobs:
  deploy:
    # https://github.com/puppeteer/puppeteer/issues/12818
    runs-on: ubuntu-22.04
    if: ${{ github.event.workflow_run.conclusion == 'success' }}
    steps:
      - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
      - uses: jdx/mise-action@5083fe46898c414b2475087cc79da59e7da859e8 # v2.1.11
      - run: |
          bun install --frozen-lockfile
      - run: |
          bunx puppeteer browsers install chrome
      - run: |
          bun run build # astro build
      - run: |
          bun run deploy # wrangler deploy
        env:
          CLOUDFLARE_ACCOUNT_ID: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}
          CLOUDFLARE_API_TOKEN: ${{ secrets.CLOUDFLARE_API_TOKEN }}

とはいえ無料で使えて設定 UI はわかりやすくパフォーマンスも良好と魅力の多いサービスなので、これからも使っていきたい。

Everything の快適なファイル検索を Mac で実現した Cling

Sun, 13 Apr 2025 04:00:00 GMT

クロスプラットフォーム対応のソフトウェアが増加し、特定の OS 専用のソフトウェアを使う機会が減っている。そんな中でも、Everything は個人的に使っていた数少ない Windows 専用のツールのひとつ。

OS にも標準のファイル検索機能はあるが、それとは比べ物にならないくらい速く、ファイルパスだけに着目したシンプルかつコアユーザーのための検索であるというのが素晴らしい。UI もキーボード操作しやすいのがうれしい。

これがあるから Windows から離れられない、とまでは言わないまでも Mac に乗り換えたらそれなりに不便になると覚悟していたのだが、2025年になって Everything for Mac を謳うソフトウェアが出てきた。それが Cling である。

こちらもシンプルで美しい UI で、キーボード操作しやすい。検索も普通に速くて快適。

正直なところ、まだちょっと触ってみた程度なのだが、日本語圏であまり知られていないようだったし、ChatGPT で Deep Research を掛けたときにも漏れてしまっていたので、少しでも知られて盛り上がるといいなと思い紹介した。Everything が好きな Mac ユーザーにはぜひ使ってみてほしい。

気になった点としては、外付けのディスクに関してはリアルタイムでインデックスを最新に保ってくれるわけではないっぽい。わざわざこういう仕様にしているのだから対応が難しいのかもしれないけど、なんとかなったらうれしい。

Astro のブログに Expressive Code を導入してリッチなコードブロックを実現する

Sat, 08 Feb 2025 03:00:00 GMT

もともと Shiki でシンタックスハイライトしつつ自前で表示を調整していたのだが、いろいろやりたいことがあって、自前で対応するよりは既存のもので済ませたいなと思うようになったので切り替えた。

具体的には、クリップボードにコピーするボタンを配置したかったのと、幅が収まり切らない場合にスクロールではなく折り返し表示したかった。折り返し表示は単純なものならブラウザがやってくれるのだが、ソースコードはインデントで階層を表現しているので、それだと不十分。

Expressive Code には、折り返し時に元の行のインデントを維持してくれる preserveIndent というオプションがあったので、インデントしていても比較的わかりやすく表示できる。追加で行番号も出してあげると折り返ししていることが明確になるのだろうが、限られた幅を行番号に取られてしまうと折り返される頻度が上がって本末転倒な気がしたので、インデントだけで表現するところに落ち着いている。

導入については、公式のドキュメントにもほとんど何も書いてないくらいに簡単。astro add astro-expressive-code がだいたいやってくれる。

ただ、MDX Integration を使っている場合だと、integrations の並び順を調整して mdx よりも expressiveCode が手前になるようにする必要があった。これはビルド時に丁寧なエラーメッセージで教えてくれたので困るほどのことではなかった。

import mdx from "@astrojs/mdx"
import { defineConfig } from "astro/config"
import expressiveCode from "astro-expressive-code"

export default defineConfig({
  integrations: [
    expressiveCode({
      defaultProps: {
        wrap: true,
        preserveIndent: true,
      },
    }),
    mdx(),
    // ...
  ],
  // ...
})

ブログの更新を Activepieces を使って Bluesky に通知するようにした

Sun, 02 Feb 2025 07:00:00 GMT

Bluesky をメインで使っている人もいくらかいるようなので、試しにやってみた。

# 自分の場合は Twitter (X) の使用頻度が下がったことで、代わりに Threads や Bluesky を使うわけでもなく、Obsidian でプライベートなメモに書くようになった。思ったことをストレートに書けるし検索性も高いのでよかった。

Activepieces は、ノーコードでサービス間連携などのちょっとした自動化ができるツール。IFTTT みたいな感じだけど、ノードを複数つないでよりリッチなことができるし、無料でも結構使える。オープンソース版があるので (個人的には面倒なのでやりたくないものの) セルフホスティングもできる。もともと RSS の新着をトリガーに Twitter に投稿していて、RSS の新着をトリガーにする部分の状態管理を任せられるのがうれしかったので今回も採用した。

# なので、ノーコードがうれしいというよりは状態管理やサーバ管理を任せられるのがうれしくて使っている。Activepieces のグラフィカルなエディタは結構使いやすいとは思いつつ、YAML とかで書けるならそれに越したことはないという気持ち。

出力部分に関しては、Twitter への投稿は Activepieces の標準機能でいけたものの、Bluesky との連携はサポートされていないので、自前で API を叩く必要があった。

といっても、com.atproto.server.createSession で認証して、返ってきた JWT で com.atproto.repo.createRecord を呼ぶだけなので簡単。投稿時に時刻を渡してあげる必要があったので、そのためのステップも挟んでいる。ハッシュ値や HMAC の計算とかもできるので、もうちょっと使うのが難しい API でも対応できそう。

参考までにフローをエクスポートしたものも貼っておく。

{
  "created": "1738479770166",
  "updated": "1738479770166",
  "name": "ブログの更新を Bluesky に通知",
  "description": "",
  "tags": [],
  "pieces": [
    "@activepieces/piece-rss",
    "@activepieces/piece-http",
    "@activepieces/piece-date-helper"
  ],
  "template": {
    "displayName": "ブログの更新を Bluesky に通知",
    "trigger": {
      "name": "trigger",
      "valid": true,
      "displayName": "New Item In Feed",
      "type": "PIECE_TRIGGER",
      "settings": {
        "pieceName": "@activepieces/piece-rss",
        "pieceVersion": "0.3.7",
        "pieceType": "OFFICIAL",
        "packageType": "REGISTRY",
        "input": {
          "rss_feed_url": "<RSS_URL>"
        },
        "inputUiInfo": {
          "customizedInputs": {}
        },
        "triggerName": "new-item"
      },
      "nextAction": {
        "name": "step_1",
        "skip": false,
        "type": "PIECE",
        "valid": true,
        "settings": {
          "input": {
            "url": "https://bsky.social/xrpc/com.atproto.server.createSession",
            "body": {
              "data": {
                "password": "<APP_PASSWORD>",
                "identifier": "<USERNAME>.bsky.social"
              }
            },
            "method": "POST",
            "headers": {
              "Content-Type": "application/json; charset=UTF-8'"
            },
            "failsafe": false,
            "body_type": "json",
            "use_proxy": false,
            "queryParams": {},
            "proxy_settings": {}
          },
          "pieceName": "@activepieces/piece-http",
          "pieceType": "OFFICIAL",
          "actionName": "send_request",
          "inputUiInfo": {
            "customizedInputs": {}
          },
          "packageType": "REGISTRY",
          "pieceVersion": "0.6.1",
          "errorHandlingOptions": {
            "retryOnFailure": {
              "value": true
            },
            "continueOnFailure": {
              "value": false
            }
          }
        },
        "nextAction": {
          "name": "step_2",
          "skip": false,
          "type": "PIECE",
          "valid": true,
          "settings": {
            "input": {
              "timeZone": "Asia/Tokyo",
              "timeFormat": "YYYY-MM-DDTHH:mm:ssZ"
            },
            "pieceName": "@activepieces/piece-date-helper",
            "pieceType": "OFFICIAL",
            "actionName": "get_current_date",
            "inputUiInfo": {
              "customizedInputs": {
                "timeFormat": true
              }
            },
            "packageType": "REGISTRY",
            "pieceVersion": "0.1.6",
            "errorHandlingOptions": {
              "retryOnFailure": {
                "value": true
              },
              "continueOnFailure": {
                "value": false
              }
            }
          },
          "nextAction": {
            "name": "step_3",
            "skip": false,
            "type": "PIECE",
            "valid": true,
            "settings": {
              "input": {
                "url": "https://bsky.social/xrpc/com.atproto.repo.createRecord",
                "body": {
                  "data": {
                    "repo": "{{step_1['body']['handle']}}",
                    "record": {
                      "text": "{{trigger['title']}}",
                      "embed": {
                        "$type": "app.bsky.embed.external",
                        "external": {
                          "uri": "{{trigger['link']}}",
                          "title": "{{trigger['title']}}"
                        }
                      },
                      "createdAt": "{{step_2['result']}}"
                    },
                    "collection": "app.bsky.feed.post"
                  }
                },
                "method": "POST",
                "headers": {
                  "Content-Type": "application/json; charset=UTF-8",
                  "Authorization": "Bearer {{step_1['body']['accessJwt']}}"
                },
                "failsafe": false,
                "body_type": "json",
                "use_proxy": false,
                "queryParams": {},
                "proxy_settings": {}
              },
              "pieceName": "@activepieces/piece-http",
              "pieceType": "OFFICIAL",
              "actionName": "send_request",
              "inputUiInfo": {
                "customizedInputs": {
                  "data": false
                }
              },
              "packageType": "REGISTRY",
              "pieceVersion": "0.6.1",
              "errorHandlingOptions": {
                "retryOnFailure": {
                  "value": true
                },
                "continueOnFailure": {
                  "value": false
                }
              }
            },
            "displayName": "Send HTTP request"
          },
          "displayName": "Get Current Date"
        },
        "displayName": "Send HTTP request"
      }
    },
    "valid": true,
    "schemaVersion": "1"
  },
  "blogUrl": ""
}

こんな感じで投稿できた。

https://bsky.app/profile/mono0x.bsky.social/post/3lh6ik6rkms2w

# 記事への投稿の埋め込みは oEmbed で普通にできた。

chezmoi のスクリプト実行機能で zcompile を試した

Fri, 24 Jan 2025 14:00:00 GMT

zsh の起動を高速化するという話になるとよく zcompile が出てくる。

source コマンドを上書きして zcompile を呼び出している事例なんかもあって、それもすごいと思ったのだけど、chezmoi を使って別のアプローチが取れそうだと思ったのでやってみた。

chezmoi には、chezmoi apply 時に任意のスクリプトを実行できる機能がある。ファイル名を run_ としておけば対象となり、かつ run_after_ のようにすれば chezmoi の処理の最後に実行してくれる。.zshrc などのファイルを chezmoi で配置し終えた後で zcompile するスクリプトを実行すれば、.zshrc などの実行時に何もせずともコンパイル済みのファイルを読み込めるし、chezmoi apply の中に組み込めばコンパイル漏れもないという寸法である。

具体的なスクリプトは以下のようになった。

#!/usr/bin/env zsh
for file in ~/.zshenv ~/.config/zsh/.zprofile ~/.config/zsh/.zshrc ~/.config/zsh/**/*.zsh ~/.local/share/sheldon/**/*.zsh
do
  echo "zcompile $file"
  zcompile "$file"
done

パスの部分は各自の環境に合わせて変更する必要がある。自分の場合はプラグイン管理に sheldon を使っているので、そちらで管理しているプラグインも zcompile するようにしてみた。

試してみたところ、自分の環境では zsh の起動時間はほぼ変わらなかった。もともと 10～20 ms で起動する程度までチューニングされているし、zsh-defer での非同期読み込みも多用しているので、効果が出にくかったのかもしれない。効果がないのにわざわざ複雑にする必要もないので、結局導入は見送ったのだが、chezmoi の使い方としては面白いかなと思っている。

DxO PhotoLab で External Selections をまとめて削除する

Fri, 17 Jan 2025 13:00:00 GMT

DxO PhotoLab では、Lightroom Classic などの外部アプリケーションから DxO PhotoLab に転送した場合に、External Selections のリストに項目が追加されて管理される。転送するたびに項目が増えていくが、まとめて削除する方法はなく、1件ずつポチポチしていく必要があり面倒。

Bulk remove External Selections entries - DxO PhotoLab - DxO Forum

2019年にスレッドが作成されてから今に至るまで改善されておらず、対応には期待できないので、自分でどうにかすることにした。

DxO PhotoLab のデータ構造を調べたところ、SQLite になっていて、直接データベースを操作すればよさそうだったのでやってみた。

SQLite の CLI は Windows であれば scoop などでインストールする。macOS には最初から入っている。

scoop install sqlite

DxO PhotoLab が起動していない状態で以下のようなクエリを実行する。Windows と macOS でデータ構造が何もかも違っていて衝撃だった。

sqlite3 "${env:AppData}\DxO\DxO PhotoLab 8\Database\PhotoLab.db" "DELETE FROM Projects WHERE ProjectTypeDiscriminator = 'EFDOPExternalSelection'"

sqlite3 ~/Library/DxO\ PhotoLab\ v8/DOPDatabaseV8.dopdata "BEGIN; DELETE FROM ZDOPLIST; DELETE FROM Z_8PROJECTS; COMMIT"

とりあえず自分の環境ではこれで動いた。本当に問題がないかはわからないし、ミスすると危険だと思うのでやるなら自己責任で。