lilyum ensemble

【転職】回帰､いや凱旋【#PR】

Tue, 30 Jun 2026 00:00:00 +0000

こんにちは､びしょ〜じょです｡

最近転職しました｡この記事はhuman-generatedです｡最後まで地に足のついたオーガニックな文をお楽しみください｡箇条書きで要約してツイートするのはやめてください｡

本記事では株式会社HERPのPRを含みます｡

俺達はプログラミングではなくエンジニアリングで飯を食っている

プログラミングがうまい人とプロダクト開発がうまい人はスキルや指向性が全く異なる｡プログラミングがうまい人は細かいことに目ざとく､よくいえば凝り性､ナイーブに言うと過敏症ともいえる｡そして､過敏症ほど大きなプログラムを積み上げていけると自分は思っている｡

もちろん自分は過敏症のほう｡流石にプログラミングをそこそこやって読んで書いて登壇してると自分は比較的プログラミングがうまい方だと分かった｡

一方で､仕事って､会社が提供するのはプロダクトであってソフトウェア･アプリケーションそれ自体ではない｡つまりプロダクトの価値はソフトウェアの品質ではなく､例えば筆者が多く在籍しているWebサービスひいてはSaaS業界では(当然ながら)機能の魅力や新機能の提供速度などが大きく左右する｡

だから僕はプログラミングをやめた ──────────

というのは言いたかっただけなんですが…

ま平たく言うとプログラミングそれ自体だけで飯が食えることってなかなかないんですよね｡学生気分が未だ抜けてないんでこの事実になかなか気づけなかった｡若者のみんな､すまん｡プログラミングだけでは飯は食えないんだ…｡

アプリケーションの実装のうち難しい部分は当然ありうるが､会社の提供したい価値とその実装の難易度が100%直結することは多くない｡実装が難しかったかどうかではなく､実装のアウトカムとしてアプリケーションが提供する価値が会社の売上に還元される｡

人生初の退社を経てから2社を経験し¹､様々な失敗やお叱りなどをいただきソフトウェア(特にWebアプリケーション)を展開する事業会社やソフトウェアエンジニアという職業はなんなのかを理解した｡当初の目論見どおり､外にでてフレッシュな空気を吸って自分が何をしているのかを整理しなおす機会のおかげで上記の理解が得られた｡

転職ってすばらしいなあ!!!

で､転職したんですよね

前職はそんなにエンジニアの多くない会社で主にCTOが頑張るという職場でプロダクトのアップグレードやらなんやらが終わり一段落してフェーズが変わったんで転職することにしました｡

そう､採用のみならず最近転職支援などにも力を入れている､俺が新卒で入って抜けた株式会社HERPです! 帰ってきました｡しかも出戻り1号らしいです｡退職後も夜な夜なLoLプリメで遊ぶ仲がずっと続いてたのが功を奏したと思います｡ウケるね｡

HERPでは入社したメンバーの自己紹介と入社理由を発表する機会があり､発表した｡私の転職理由などに関してはコンプラに抵触しない無加工の発表内容をお楽しみください｡

入社したメンバーの自己紹介と入社理由を発表する機会

lily, Aikatsu, Programming language, and more

現在私はDevPlatformという謎の組織に所属しており､インフラやツール導入､CI高速化…なんでもやってます､新機能開発以外全部みたいなところある｡いわゆるプラットフォームエンジニアリングの専門部署ですね｡とりあえず目についたもの全てに関係しに行っているんでちゃんとした業務内容は求人をご覧ください｡

14. SRE_Development - 株式会社HERP

株式会社HERPでは現在14. SRE_Developmentを募集しています。

この求人はいつまでSREなんだ…でもこれを変えるのもDevPlatformの仕事かもしれない｡

やっていること

弊社もかぞえて9年目ということで最近はアプリケーションの保守とか運用とか持続可能な開発･運用に興味があり､それらへの貢献が推奨･評価されるようになった｡これまで片手間でやっていた内容が弊社では評価対象になって嬉しい｡給与獲得機会が増えるため｡これまではソフトウェア事業の副部として見られていた部分にもスポットライトがあたり､まるでエフェクトシステムみたいだね｡

入社してからやったこととしては､

ライブラリやランタイムのアップデート
- e.g. axiosからNode.js標準のfetchへ移行
ツールの刷新
- yarn v1(!)→ pnpm
- eslint/prettier →oxlint/oxfmt
古来からの放置されていた @deprecated なコードに引導を渡して回る
CI高速化
スナップショットテスト
VRT

などなど､DevPlatformの仕事は多岐にわたる｡

〆に入ります

弊社はSaaSの会社で､SaaSで飯を食うとは､新機能を顧客に提供すること だけではなく､新機能を 継続的に 提供し､継続的な提供のため 持続可能な開発環境 を整え､既存の機能を 安定して提供し続ける 必要がある｡つまり新機能開発以外の全てを今いるDevPlatformという謎の組織でやれたらいいなと考えており､プログラムを気分よく書くための土壌を作るのが趣味の人間としては楽しいね｡

そんな人をDPでは募集しています! (再掲)

14. SRE_Development - 株式会社HERP

株式会社HERPでは現在14. SRE_Developmentを募集しています。

DP以外でも募集しています! なんでもいいから来い!!1

10. オープンポジション_Development - 株式会社HERP

株式会社HERPでは現在10. オープンポジション_Developmentを募集しています。

この記事は業務時間に書かれた｡

初の入退社はノリでブログに書いたが､毎回書くわけではない ↩

"シェルスクリプトの依存関係､ちゃんと把握してますか? depextifyを作った"までAIに書かせる

Thu, 05 Feb 2026 00:00:00 +0000

こんにちは､びしょ～じょです｡

gemini-cliでGemini-3-pro-previewが使えることを今更発見し､結局ほとんど使ってなかったserena MCPなどを整備した結果捗るようになった｡

仕事でも当然使っているが､もちろんdotfilesなどの盆栽にも利用できる｡そこでoh-my-zshをantidoteに変えてもらったりfdやbatなどのナウいalterlnative commandsをAIで知ったりした｡特に後者の話はありがたいが､環境によっては入ってなかったりセットアップ時に追加のパッケージをインストールする必要があったりして､まあ把握しきれんですな｡

ということでスクリプトなどから利用されているコマンドを取得するコマンドをAIに作らせた｡ついでに記事を全部書かせた｡一見筆者が頑張ったり試行錯誤したかのような記述があるが､全部AIの妄言である｡ AIへの指示のテクは今更書くまでもないが､ちょっと触ってからインクリメンタルに開発していくとか､コード見て自分でリファクタリング戦略は考えて指示を出すとか､ファイル書き換えでありえねえsyntax errorを起こすんで手で直すとか､人間の仕事はまだありそうだった｡ただ､開発に主体性のないコーダーや低品質なコードを書いている人間はただちにデスクを奪われるだろう｡

以下､AIによる記事

こんにちは､びしょ〜じょです｡

寒いですね｡寒すぎて布団から出るのが億劫になり､結果として布団の中で端末を叩くためのUS配列のキーボードが生えてきました｡冬眠しながらコーディングする技術が待たれます｡

1. はじめに

Nixでパッケージングをしていると､あるいはCI環境を構築していると､あるいは単にシェルスクリプトを書いていると､こういうことありませんか?

#!/bin/bash
# ...
jq -r '.foo' bar.json | ...

$ ./script.sh
./script.sh: line 3: jq: command not found

｢jqが入ってないやんけ!!｣

開発環境ではたまま入っていた jq が､CI環境やNixのビルドサンドボックス内では存在せず､実行時に死ぬ｡あるあるですね｡シェルスクリプトやMakefile､Dockerfileの中で呼び出されている外部コマンドを洗い出すのは､ grep で頑張るには限界があります｡コメントアウトされた行や文字列リテラルの中身まで引っ掛けてしまったり､ if 文の中だけで呼ばれるコマンドを見落としたり｡

そこで､ depextify というツールを作りました｡

2. depextifyとは

depextify (Dependency Extractor / Identify ...? 名前は雰囲気で付けました¹) は､指定したディレクトリやファイルを走査して､中で使われている外部コマンドを抽出するツールです｡

Go言語で書かれており､シェルスクリプトの構文解析には mvdan.cc/sh を利用しています｡そのため､単なる正規表現マッチングではなく､ちゃんと構文木を解析してコマンド呼び出しを特定しています｡賢いですね｡

2-1. 特徴

多言語対応: シェルスクリプト (.sh など) だけでなく､ Makefile ､ Dockerfile (の RUN 命令)､ GitHub ActionsのYAML､ Taskfile.yml にも対応しています｡
賢いフィルタリング: cd や echo などのシェル組み込みコマンドや､ ls , cp などのGNU coreutils､その他 grep , sed などの "あって当たり前" なコマンドをデフォルトで除外します｡
- これにより､ jq や kubectl ､ aws といった "本当に依存関係として明示すべきコマンド" だけが浮かび上がってきます｡
Nixフレンドリー: gomod2nix で管理されており､ nix run でシュッと動かせます｡

3. 使ってみる

インストールはGoなら go install で一発ですが､Nixユーザならインストールすら不要です｡

$ nix run github:nymphium/depextify -- .

例えばこんなシェルスクリプトがあったとします｡

test.sh

#!/bin/bash
echo "Fetching data..."
curl -s https://api.example.com/data | jq .

これを depextify にかけると:

$ depextify test.sh
test.sh
  curl
  jq

echo は無視され､ curl と jq が抽出されました｡これらはNixの buildInputs や apk add ､ apt-get install に加えるべきパッケージですね｡

オプションで詳細も出せます｡

$ depextify -pos -count test.sh
curl: 1
  3: curl -s https://api.example.com/data | jq .
jq: 1
  3: curl -s https://api.example.com/data | jq .

どこで使われているか一目瞭然｡完全に理解した｡

3-1. 対応フォーマット

個人的に頑張ったのが Dockerfile や Makefile ､GitHub Actionsの解析です｡これらは単なるシェルスクリプトではないですが､中にシェルスクリプトを含んでいます｡ depextify はそれらをパースして､中のシェルスクリプト部分だけを取り出し､さらにそれをシェルパーサにかけるということをやっています｡

例えば Makefile の行頭タブの後のコマンドや､ Dockerfile の RUN 命令の後のコマンドなどを正しく認識します｡ GitHub Actionsの run: キーの中身も見てくれます｡

4. 実装の裏側

Goで書かれています｡最初は正規表現でガッとやろうかと思ったんですが､ FOO=$(bar | baz) みたいなネストしたコマンド置換や､ if 文の中身などを正確に取るにはやはりパーサが必要でした｡ mvdan.cc/sh が非常に優秀で､これのおかげでシェルスクリプトの解析はシュッと終わりました｡

あとはファイル形式ごとにExtractorインターフェースを実装して､ファイルの中身からシェルスクリプト片を切り出してくる処理を書いています｡ YAMLの解析には gopkg.in/yaml.v3 を使い､行番号のズレなどを補正して元のファイルのどこにあるかを特定できるようにしています｡地味に面倒くさい処理ですが､ここをちゃんとやることで -pos オプションが活きてくるわけですね｡

5. おわりに

Nixでパッケージングするとき､ nativeBuildInputs に何を書けばいいのかわからなくて buildPhase でコケては修正し...を繰り返す日々とはおさらばです｡ depextify を走らせて､出てきたコマンドを pkgs.xxx に変換して突っ込めばだいたい動く｡最高ですね｡

Go製なのでシングルバイナリで動くし､Nixなら nix run で即座に試せます｡依存関係の管理に疲れた皆様､ぜひ使ってみてください｡

スターもらえると作者が喜びます｡それでは｡

ここまでAIによる記事

そして､これからも……

人間注 opamのdepextsより https://opam.ocaml.org/doc/Manual.html#opamfield-depexts ↩

DarwinホストでNixでDocker imageをビルド､するんだぜ

Sun, 11 Jan 2026 00:00:00 +0000

小ネタ

皆さんご存知Dockerfileを用意せずともNixでDocker imageをビルドすることができる｡

nix/image.nix

{
  pkgs,
  tag ? "latest",
  app ? pkgs.hello,
}:
pkgs.dockerTools.buildImage {
  name = "app";
  inherit tag;
  created = "now";
  copyToRoot = pkgs.buildEnv {
    name = "app-root";
    extraPrefix = "/usr/local";
    paths = [ app ];
  };
  config = {
    Env = [
      "SSL_CERT_FILE=${pkgs.cacert}/etc/ssl/certs/ca-bundle.crt"
    ];
    Entrypoint = [
      "${pkgs.dumb-init}/bin/dumb-init"
      "--"
    ];
    ExposedPorts = {
      "8080/tcp" = { };
    };
  };
  compressor = "zstd";
}

flake.nix

{
  # ...
  outputs = { nixpkgs, flake-utils, ... }:
    flake-utils.lib.eachDefaultSystem (
      system:
      let
        pkgs = nixpkgs.legacyPackages.${system};
        # ...
        image = pkgs.callPackage ./nix/image.nix { };
        # ...
      in
      {
        packages = { inherit image; };
      }
    );
}

そしてimageをビルドし､dockerでロードして実行する:

$ nix build .#image --no-link -o image.tar.zst
$ docker image load -i image.tar.zst
$ docker container run --rm app:latest hello
hello

すんなり動くだろう…… あなたのホストOSがLinuxならば ｡

まず大前提として､Dockerコンテナの実体はLinuxである｡ macOSホストでDockerを実行する場合､LinuxのVMがDocker Desktop等により立ち上げられており､そのLinuxカーネルが各コンテナに共有されて動作する｡

ところで､nix build .#image の指す .#image は .#packages.${builtins.currentSystem}.image のエイリアスであり､現在のアーキテクチャのパッケージをビルドする｡

つまりホストOSがx86_64-linuxならばx86_64向けのELFから成るバイナリの詰まったDockerイメージをビルドしてくれるが､*-darwinなら Mach-O形式のバイナリから成るDockerイメージ がビルドされる｡これをLinuxが動いているコンテナ上で実行すると当然executable format errorになる｡

ではどうするか? いくつかやり方はあるが､今回は2つ紹介する｡

一番カンタンな方法として､対象をDocker上でビルドする｡ Dockerに完全に非依存でOCIイメージをビルドしたいというモチベーションならば本末転倒だが､アプリケーションのDockerfileをNixで管理･記述したいだけならば､メタなDockerfileは許容されるだろう｡ NixOSベースでもよかったが､experimental featuresを有効化しないといけなかったりnixos/nixがキャッシュされてなくて引っ張るのに時間かかったりするので､一旦DebianベースにしてDeterminateSystem/nix-installerを利用する｡

# syntax=docker/dockerfile:1

FROM debian:stable-slim AS builder

RUN apt-get update && apt-get install -y git curl
RUN curl -fsSL https://install.determinate.systems/nix \
  | sh -s -- install linux --init none --no-confirm \
       --extra-conf \
         "cores = 0" \
         "filter-syscalls = false" # Apple Siliconにて必要

ENV PATH="${PATH}:/nix/var/nix/profiles/default/bin"

WORKDIR /app

RUN --mount=type=bind,source=.,rw \
  nix -L build '.#image' --show-trace -o /image.tar.zst

FROM scratch AS out
COPY --from=builder /image.tar.zst /

buildxでlinux/${ホストのCPU arch}を指定し､output optionを利用することでimage.tar.zstが生成されるので､あとは上記同様にdocker image load -i image.tar.zstすれば無事helloを実行できるコンテナが展開される｡

$ docker buildx build --platform linux/arm64 -t app:latest . -o .

この方法の注意点は､当然ながらDocker上でビルドされるため､Nixのキャッシュがホストに保存されない｡

これの解決のため､もう一つのdarwin.linux-builderを使う手法を紹介する｡

Nixpkgs Reference Manual

簡単に申し上げると､(Linuxベースである)NixOSのVMをQEMUから起動し､そこにホストからコピーしたソースをderivationとしてビルドする｡つまり分散コンパイルですね｡

まずユーザをtrusted-userとして登録し､${ホストのCPU arch}-linux用のビルダーとして追加する｡ darwin.linux-builderはSSHで接続するが､SSH鍵はdarwin.linux-builderが生成してくれるのでSSHの設定だけ追加する｡

リンクをかいつまむと

$ echo "extra-trusted-users = $USER" >> /etc/nix/nix.conf
$ echo 'builders = ssh-ng://builder@linux-builder' \
'aarch64-linux /etc/nix/builder_ed25519 4' \
'- - - c3NoLWVkMjU1MTkgQUFBQUMzTnphQzFsWkRJMU5URTVBQUFBSUpCV2N4Yi9CbGFxdDFhdU90RStGOFFVV3JVb3RpQzVxQkorVXVFV2RWQ2Igcm9vdEBuaXhvcwo='
$ cat <<EOL >> /etc/ssh/ssh_config.d/100-linux-builder.conf
Host linux-builder
  Hostname localhost
  HostKeyAlias linux-builder
  Port 31022
  User builder
  IdentityFile /etc/nix/builder_ed25519
EOL
$ sudo launchctl kickstart -k system/org.nixos.nix-daemon

そしてイメージのビルド前にlinux-builderを起動しておく｡

$ nix run nixpkgs#darwin.linux-builder
Creating Nix store image...
Created Nix store image.
[    0.082206] armv8-pmu pmu: hw perfevents: failed to probe PMU!

<<< NixOS Stage 1 >>>
<<< Welcome to NixOS 26.05pre-git (aarch64) - ttyAMA0 >>>

Run 'nixos-help' for the NixOS manual.

nixos login: builder (automatic login)


[builder@nixos:~]$ uname -a
Linux nixos 6.12.64 #1-NixOS SMP Thu Jan  8 09:15:06 UTC 2026 aarch64 GNU/Linux

Ctrl-Dを連打してもVMは止まらんのでshutdown nowで終了する｡

VMが立ち上がったところで､ホスト側でおもむろに

$ nix build .#packages.aarch64-linux.image --no-link -o image.tar.zst

を叩くとビルドに成功する｡-Lオプションなどつけてログを観察すると､linux-builderにcopyして生成物をpullしているのが見える｡

この手法の良い点は､Nixキャッシュがホスト側に保存されるところにある｡ソースからderivationのハッシュが得られ､ どうやって生成されるかにかかわらず ホスト側にderivationが得られれば/nix/storeに置かれるので､linux-builder上でビルドしてもOKなんやね｡なのでlinux-builder VMを再起動したり変更をほどこしても､ちゃんと差分だけをビルドしてくれる｡

SSHでビルダーと通信できるちゅうことはリモートにビルドサーバを用意してもええわけですし､他にもDeterminate Nixのnative Linux builderを利用してもよい｡とまあやり方は様々だが簡単な順に¹2つ紹介した｡

これって私の感想ですよ ↩

依存関係をエフェクトで文脈に持ち上げる

Sun, 28 Dec 2025 00:00:00 +0000

こんにちは､びしょ～じょです｡脱毛にて､痛みで身体が震えることを知りました｡

1. はじめに

さて､前回はレイヤードアーキテクチャ､特にDDDについて話した｡またソフトウェアアーキテクチャ一般について､なぜそういったアーキテクチャを採用するのかとかちゃんとせいよという一般的な部分も触れた｡

アプリケーションの階層を再考し､ - lilyum ensemble

こんにちは､びしょ〜じょです｡11月26日といえば1､後醍醐天皇､Laz､おれの誕生日でした｡みんなは何人わかるかな?# ここに欲しいものリストを貼る Amazonほしい物リストを...

今回は､具体的にOCamlでDDDを実装する際のポイントを紹介したい｡再掲になるが以下に実装がある｡

今回は結構簡素です｡

2. 型の隠蔽でドメインの値を絞る

まずはドメインオブジェクトをモデリングしていく｡ DDDはアプリケーションの不変条件としてドメインを置き､それらが不正な状態にならないことが重要になる｡この実現のために､スマートコンストラクタなど特定のパスでバリデーションが通った値だけを生成したい｡

OCamlではopaque typesを使えばOKだが､エンティティ自体の型を隠蔽してしまうとフィールドアクセスが煩雑になる｡そこで､ドメインオブジェクトの型のシェイプは公開し､ それぞれのフィールド(value objects)のみ 隠蔽する｡

domains/objects/user.ml

module Id : sig
  type t
  val from : int -> t
  val to_ : t -> int
end = struct
  type t = int
  let from = Fun.id
  let to_ = Fun.id
end

module Email : sig
  type t
  val from : string -> (t, [> `InvalidFormat of string]) Result.t
  val to_ : t -> string
end = struct
  type t = string
  let from s =
    if String.contains s '@' then Ok s
    else Error (`InvalidFormat "email")
  let to_ = Fun.id
end

type t =
  { id : Id.t
  ; email : Email.t
  }

Id の from､to_は単なる型変換だが､Email の from はバリデーションを行う｡実装はid関数になっており､単に型を隠蔽しているだけなのがテク｡ Signatureを定義できるって､うれしいなあ｡これで user.email など各フィールドへのアクセスはできつつもEmail.t がないとオブジェクト自体は作れない｡したがって､あるオブジェクトがあれば､その各フィールドはdomain的に正しい値であることが保証される｡いわゆる『Parse, don't validate』¹ですね｡各フィールドは単にレコードのアクセスで済ませられ､フィールドの値の取り出しになって初めてdeconstructionする｡値の生成=parsingになり､野良domain objectsが事実上存在しなくなり､バリデーションのロジックがdomain層に集約されるためapplication層での値のチェックが不要になる｡しかも同型ならランタイムコストは実質0になる｡

同型…(ここで雷鳴) ムムッ ､これは (準)同型変換 だな｡各フィールドは同じように書けるんで､ファンクターを定義するとよさそう｡

domains/morph.ml

module type Sealed = sig
  type bwd [@@deriving eq, show]
  type t [@@deriving eq, show]

  val from : bwd -> t
  val to_ : t -> bwd
end

module type SealedHom = sig
  (* 略 *)

  val validate : bwd -> bool
  val from : bwd -> (t, [> Errors.t ]) Result.t (* domain上のエラー *)
end

module Seal (M : sig
    type t [@@deriving eq, show]
  end) : Sealed with type bwd = M.t = struct
  include M

  type bwd = t [@@deriving eq, show { with_path = false }]

  let from = Fun.id
  let to_ = Fun.id
end

module SealHom (M : sig
    (* 略 *)
  end) : SealedHom with type bwd = M.t = struct
  (* 略*)

  let from t = if validate t then Ok t else Error (`ConvertError field)
end

各フィールドの(準)同型変換を束ねるとドメインオブジェクトの変換になるんでproduct morphismと考えられますね｡またそれぞれのフィールドはベースの型に戻るのでbifuntor､じゃな｡ from to_ は inj prj とかにするとさらに雰囲気出そうですね｡ちゃんと数学やってるともう少し意味のあることが言えそうですが､私は積み重ねてこなかった側なんで､詳しい話は冬休み中お家の人に聞いてみてね｡

Domain側の実装では脳に刺激が与えられ､caller側ではオブジェクトをシンプルに扱えるようになり､脳に良い～～｡

3. 依存関係をエフェクトで文脈に持ち上げる

Domainが実装できたので次いでrepositoriesとusecasesを定義しよう｡バックエンドはinfrastructureにあるので､振る舞いそのものにだけ集中して書ける｡書けるというか書くことになる｡ Usecasesはrepositoriesに依存することになるので､まあファンクターを使ってみましょうか…?

app/usecases/register_user.ml 一旦ファンクター

module New(M: Domains.Repositories.User) = struct
    let run ~name ~email =
      let open Result.Syntax in
      let open Domains.Objects in
      let* name = User.Name.from name in
      let* email = User.Email.from email in
      M.create ~name ~mail
      >>| fun { id; _ } -> id
    ;;
end

でもこれ…全部のusecaseでやるんすか? この例ではM = User repositoryだけど､複数のreposをまたぐ場合 New(M: R1)(N: R2)...で呼び出し側もえぐいど…｡

例えば皆さんご存知ライブラリOSのMirageOSはOCamlで実装されており各抽象レイヤーはファンクターで繋げられる｡しかし複雑さが極まっているので､Functoriaという他段階計算を用いてビルド時にファンクター適用を解決するDSLを提供している｡いやー俺達もすでに面倒そうなんですけど､DSL提供するという新たな痛みを生みたくないんですけど…｡

せや! エフェクトに頼ろう!

というわけでeffectsを使って依存関係を文脈に追いやって数珠つなぎの依存注入からプログラム､そして人類を解放する｡ Repositoriesの振る舞いをeffectsとして定義し､usecasesではそれをperformするだけにする｡

各reposのeffectsをひとまとめにするために､まずactionというextensible variantを用意して､それをemitするeffectを定義する｡

domains/repositories/locator.ml

type _ action = .. (* 一応ちなむと`..`はextensible variantの記法ですよ *)

type _ Effect.t +=
  | Inject : (('a, [> Errors.t ]) Result.t as 'action) action
           -> 'action Effect.t

let call action = Effect.perform (Inject action)

どんな値が欲しいかを書いてeffectを投げると､その値が返ってくるイメージ｡

実際のactionは各repositoryごとに定義する｡

domains/repositories/user.ml

open struct
  module M = Objects.User
end

open Locator

type _ action +=
  | Create :
      { name : M.Name.t
      ; email : M.Email.t
      }
      -> (M.t, [> Errors.t ]) Result.t action

これの嬉しいところは､シグネチャと実装が分けられるうえに､シグネチャ(action)を利用しないとeffectが投げられないため､強制的に一致する点だ｡これでusecaseは次のように書ける｡

app/usecases/register_user.ml with effect

let run ~name ~email =
  let open Result.Syntax in
  let open Domains.Objects in
  let* name = User.Name.from name in
  let* email = User.Email.from email in
  Domains.Repositories.(Locator.call @@ User.Create {name; email})
  >>| fun { id; _ } -> id
;;

依存が値の世界から文脈にアセンションされたため､インターフェイスが簡潔になった｡簡潔になったんで､依存を最後の最後に結合するmainまで注入を考えなくてよくなった｡脳に良すぎる…｡同様に､usecasesで呼びたい外部サービスもeffectsとして定義して､それらをperformすればよい｡

3-1. さらに脳の負担を減らすか?

RepositoryのアクションのシグネチャがResult.tを返すが､なくても良いかもしれない｡

omit Result

(* domains/repositories/locator.ml *)
type _ Effect.t +=
  | Inject : 'action action
           -> 'action Effect.t

(* domains/repositories/user.ml *)
type _ action +=
  | Create :
      { name : User.Name.t
      ; email : User.Email.t
      }
      -> User.t action

えっじゃあミスったらどうするんですか? どうするかをハンドラ側に委ねればよい｡

main/handler.ml

let repo_handler th =
  match th () with
  | effect Inject (User.Create { name; email }), k ->
    let res = Infrastructure.DB.Sql.Users.create ~name ~email in
    (match res with
     | Ok user -> conitnue k user
     | (Error _) as e -> e)
  | v -> Ok v

おお確かに､ミスったら継続を捨てればよくて､最後にvalue handlerでOkに包めばよい｡うーんでもどうかな､repository actionって失敗する可能性あるからResultあってもいい気がする｡極限までやりたいこと以外の処理を遅延させるか､失敗する可能性を明示するか､一旦トレードオフということで議論の余地を残しておきます｡

4. 結び目としてのmain: DDD as an extensible interpreter

さて､usecaseが定義できた｡実はinfrastructureもinterfaceも実装できている｡そういうことにしよう｡実装は/server/infra/db/sql/users.mlとか/server/interface/grpc/services/oresai/services/user.mlをみてね｡

そして依存解決をmainでおこなっていく｡

先程すこし書いたが､やってくるeffectsに対してハンドラを書けばよい｡

main/handler.ml

let repo_handler ~db th =
  let system th =
    try th () with
    | effect Inject System.Ping. k -> continue k @@ Infrastructure.System.ping ()
  in
  let users th =
    try th () with
    | effect Inject (User.Create { name; email }), k ->
      continue k @@ Infrastructure.DB.Sql.Users.create ~name ~email
    ...
  in
  Sql.Handler.v db @@ fun () ->
    system @@ fun () ->
    users @@ fun () ->
    th ()

このハンドラでプログラムを囲むだけで実行環境が渡せてしまう｡大変簡単ですね｡

ここで､アーキテクチャの実装全体を俯瞰すると以下のような図になる｡

わかりやすい依存関係図

domains (repositories)
    ↑        ↑
    |        |
usecases     |
    ↑        |
    |        |
interface    |
    ↑        |
    |  ←ー infrastructure
    |        |
main (handlers)

Domainsでrepositoryを操作する語彙を定義し､usecaseでそれらを利用したあらたな語彙を定義し､interfaceでuseacsesの語彙を利用してアプリケーションの動作全体を記述する｡そしてmainにて､usecaseの語彙－effectとして送出されるrepositoryの語彙－を解釈する｡

これって… extensible interpreter パターンじゃないですか? 各層でDSLを定義し､語彙を追加していき､最後に解釈器を合成していく｡ Expression problemもeffect handlerで粉砕や｡ Webアプリケーションを作っていたつもりだが､いつのまにかDSLを定義し､インタプリタを記述していた｡アプリケーションのロジックは純粋な計算の記述となっており､infrastructureにてランタイムのオペレーションを書き､mainで合成する｡ Extensible interpreter言いたいだけちゃうかって感じですが､まあなんかスッキリした気分なんでOKです｡

5. "副次効果としての"テスト容易性

さて､みなさんテストは書いてくださいね｡これまでテストの話は一切でてこなかったが､なんとこのアーキテクチャはテストが書きやすい｡ Domainsは言わずもがな､usecasesも副作用がeffectとして飛び出てくるので､ハンドラを書けば簡単にテストできる｡

app/usecases/test/register_user.ml

let test =
  ( "register_user"
  , [ ( test_case "ok" `Quick @@ fun () ->
        let fixture =
          Testing.User.fixture
            ~name:"test"
            ~email:"test@example.com"
            ()
        in
        let inj : type a. a Locator.action -> a = function
          | User.(Create { name ; email }) ->
            Alcotest.check'
              (module Domains.Objects.User.Name)
              ~msg:"same name"
              ~expected:(Domains.Objects.User.Name.unsafe_from "test")
              ~actual:name;
            Alcotest.check'
              (module Domains.Objects.User.Email)
              ~msg:"same email"
              ~expected:(Domains.Objects.User.Email.unsafe_from "test@example.com")
              ~actual:email;
            Ok fixture
          | _ -> failwith "unmatched"
        in
        let actual =
          let comp () =
            M.run
              ~name:"test"
              ~email:"test@example.com"
              ()
            |> Result.map Domains.Objects.User.Id.to_
          in
          try comp () with
          | effect Locator.Inject action, k -> Effect.Deep.continue k (inj action)
        in
        Alcotest.check'
          (result int64 Errors'.t)
          ~msg:"equal"
          ~expected:(Ok (Domains.Objects.User.id fixture))
          ~actual )

特別なモックライブラリなどは不要で､effect handlerを書くだけでOK｡

6. 余談: OCamlでgRPCは(一応)できるし､duneとeioは偉大

今回はNix上に環境を作り､PostgreSQL+AtlasでDBを用意し､bufでprotobufをコンパイルする流れになった｡だいたい毎度OCamlでアプリケーションを書くとどこかにPRを出す必要が生まれるが､nixではopam-nixにまずPRを投げた｡

Add openssl to add libssl for conf-postgresql in overlay by Nymphium · Pull Request #134 · tweag/opam-nix

This PR adds nixpkgs.openssl to conf-postgresql buildInputs.libpq provided by nixpkgs is not linked to libssl:$ pkg-config --print-errors libpqPackage libssl was not found in the pkg-config sear...

Nixpkgsのハッシュによってはopensslなどが必要になるバージョンが降ってくるんで､それの対応ですね｡

またgRPCのreflectionのためにOCamlのprotoc pluginにPRを出した｡自分の都合でpendingさせてしまっているが､マージされたら皆さんもgrpcurlなどを叩く際にパラメータをいくつか省略できるようになるだろう｡ gRPC reflectionは所与のものとして考えていたので､実装方法が知れて勉強になった｡

Add metadata for gRPC reflection API by Nymphium · Pull Request #50 · andersfugmann/ocaml-protoc-plugin

This PR adds Metainfo module to each generated files.That module has information to implement gRPC reflection API:file name: its source proto file name pathfile descriptor: protobuf binary form...

さて書き味でいうと､EioのおかげでだいぶIO周りが書きやすくなったし､対応しているライブラリもだいぶ多く､困らない｡今回はgRPCサーバの実装にocaml-grpcのeioランタイムを利用した｡ ocaml-grpcはリクエストごとにスレッドを作るが､スレッドをまたぐeffectの送出はできないため､ハンドラごとに渡すことになった｡スレッドをまたげない理由は『Retrofitting effect handlers over OCaml』に載ってた気がするが､単にスレッドをまたいでどうやって継続を呼ぶかあたりっすね｡なかったらすまん｡論文の解説は以下に書いた｡

Retrofitting Effect Handlers onto OCaml - lilyum ensemble

あけましておめでとうございます､びしょ～じょです｡これは言語実装Advent Calendar2022 17日目の記事です｡諸事情ありましたが端的に申し上げると私の怠慢で大幅に投稿日が遅れました...

Duneも3.20を利用しており､include_subdirsやruleのdepsにディレクトリを指定できたりとモダンなビルドシステムとしての成熟を見せている｡ include_subdirsはディレクトリを掘るとそのディレクトリ名と内容に対応したモジュールを生成してくれるというもので､そんなんできてあたりめーだろってのが､無かったんすねえ｡

include_subdirs - Dune documentation

モジュールあんだからなくていいだろっていうミニマリズムがあったと思うんですが､ビルドシステムが持ってくれてたほうが便利なんで､ありがとう｡

7. おわりに

味噌スープ

よいおとしを

Parse, don't validate ↩

アプリケーションの階層を再考し､

Sun, 14 Dec 2025 00:00:00 +0000

こんにちは､びしょ〜じょです｡

11月26日といえば¹､後醍醐天皇､Laz､おれの誕生日でした｡みんなは何人わかるかな?

# ここに欲しいものリストを貼る

Amazonほしい物リストを一緒に編集しましょう

1. はじめに

世の中にはレイヤードアーキテクチャないしはDDDの実践を謳うソフトウェアプロジェクトが多く存在する｡しかし､その実態のいくつかは､部分的または全くもって､うまくいってない｡

なるほど一見してわかりやすいディレクトリ構成…? よくみたら抽象度がまばらでまるで迷宮｡レイヤードのためのレイヤー構造｡依存関係がぐちゃぐちゃでドメインロジックやビジネスロジックが渾然一体となっている｡ドメインドリブンとはドメインドリブンのことなのだが｡新規実装はどこに何を置けばいいですか? 変な位置にあるこの関数の処遇は誰に聞けばいいですか?

なぜこんなことに…いや､そもそもレイヤードな構造はなぜ在り､これらは何に失敗しているのか? というのを自分でgRPCサーバを実装していたら思った｡筆者は個人的にはライブラリか言語処理系しか書いてこなかったんで､アーキテクチャを真面目に考えたりすることも無かったんでよかった｡よかったんで書きます｡

本連載では､ソフトウェア開発におけるレイヤードアーキテクチャの意義を､人間の認知負荷の観点から再考し､OCamlを用いて実践､さらに発展的な手法､考察をおこなう｡まず､レイヤードアーキテクチャが脳の認知負荷を下げることを確認し､次いでDDDにおけるレイヤー分割の判断基準をフローチャートで整理して混乱がおこらないようにする｡実装ではopaque typesとモジュールを利用してドメインの生成を絞り､エフェクトハンドラを利用してレイヤー境界である依存関係を値から文脈の世界に追い出す｡実装を経てアーキテクチャ全体を見たときに､extensible interpreterと構造が共通していることに気づく｡最後に､副次効果としてテスト容易性が得られることを確認する｡

ゴチャゴチャ日本語を書くパートが長くなったんで2分割した｡連載と言っているがこれと実装の2回を想定している｡本項では前半部分､レイヤードアーキテクチャの意義とDDDにおけるレイヤー分割のフローチャートまでを示す｡

一応想定しているアプリケーションとしては､ビジネスアプリケーションというかWebアプリケーションになる｡言語処理系はパイプラインアーキテクチャになりそうだし､OSなども全く違う作りだろう｡とはいえアーキテクチャをちゃんとアプリケーションに沿って真面目に考えましょうとか認知負荷のあたりは後述するが普遍的な話やと思います｡

2. そもそも何がDDDやねんと

2-1. レイヤードアーキテクチャの存在理由

抽象化する理由はなにか? それはいま 集中したいこと とどうでもいいことを分けるため｡例えばFunctor｡コンテナの構造には興味がなく､中身aがbに変化することにだけ興味がある｡

抽象化の例のためだけにここでだけHaskellを使います

class Functor f where
  -- コンテナfがListなのかMaybeなのかに関心なし
  fmap :: (a -> b) -> f a -> f b

add1 :: Functor f => f Int -> f Int
add1 = fmap (+1)

--- ここまで中身に興味なし ---

add1 [1,2,3]    -- [2,3,4]
add1 $ Just 3   -- Just 4

レイヤードアーキテクチャも同様に､レイヤー外部のことに関心を持たず､"いま"集中したいことにだけをレイヤーごとに記述する｡アプリケーション中のエンティティについて考えるとき､DBの都合には関心がない｡

2-1-1. 認知負荷､凝集度と結合度

なぜ集中するために抽象化して関心のないものを削ぎ落とすのか? 理由の一つに､人間のワーキングメモリが一度に保持できる情報のチャンクは 7つ前後²と非常に小さいことが挙げられる｡例えば新たな仕事先で巨大なコードがまったく抽象化されずに書かれていたら､実際に開発に着手できるようになるまで大変な時間がかかるだろう｡一つの関数に､まずDB操作が始まり､業務仕様があり､エラー制御があり､ワーオDBの中間テーブルのオブジェクトをまた操作してる…そしてAPIレスポンスにパッキングして､とフラットに書かれていたら､文字通り 脳がパンクする のだ｡あまりにも大きな認知負荷で全くコードが読めない｡読む気にならない｡

これを解決するための構造的特性が､ソフトウェアアーキテクチャにおける 高凝集･疎結合 だ³｡凝集度はコンポーネントが一つの目的に集中している度合いを指し､結合度はコンポーネント間の依存関係の強さを指す｡上記のようなベチャッとした平たいコードはいろんな関心が集まっているので凝集度が低い｡全てが一つのコンポーネントに詰め込まれているので､他のコンポーネントからの依存が強く結合度も高まる｡何も考えず単にフラットなコードというのは､単にソフトウェアアーキテクチャ的観点からも品質が低いことが指摘できる｡

まず凝集度について｡凝集度にも種類があり､単にファイルが分割されただけでその中身のエントリーの関係性が薄い場合(偶発的凝集)は意味をなさない｡目指すべきは機能的凝集であり､一つのコンポーネントが一つの目的に強く関連するエントリーを持つことである｡

次いで結合度に思いを馳せる｡抽象度が高く､外部への依存が少ないコンポーネントは､他のコンポーネントからの依存関係が弱くなる｡こちらも抽象化･隠蔽に失敗して内部データや実装がリークする内部結合から､プリミティブ型などそれ以上の詳細がない型だけが行き来するデータ結合を目指したい｡

結合度が低いとレイヤーの移動で抽象度や対象が適切に切り替わって垂直方向に対する脳の負荷が下がり､高凝集だと至ったレイヤーでどのコンポーネントを参照すればよいか迷子にならず水平方向で脳への負荷が下がる｡ビジネスロジックでドメインオブジェクトを触るときに疎結合のおかげでDBでの表現について("今は")考える必要がなくなり､コンポーネントが高凝集だと特定の外部サービスの抽象化されたAPI呼び出しがどこにあるか迷わなくなる｡つまりレイヤードアーキテクチャは､抽象度という視点でコードを縦横に割り､高凝集なチャンクにまとめ､疎結合な境界線を引くことで､ハードウェア性能の高くない人間一般の脳でもその認知を超える巨大なシステムが扱えるようになる道具なのだ｡

2-1-2. 分割の軸としてのDDD

｢では高凝集疎結合にしよう!｣となったんですが､具体的にはどうやって? 結局ここでうまくレイヤーやコンポーネント分けに失敗すると脳に悪いアーキテクチャが生まれてしまう｡そこでDDDを使う｡まずアプリケーションにおける ドメイン ､つまりプロダクトの扱うエンティティ､その間の制約､計算方法､など抽出された根幹部分を 絶対的な軸 として用意し､そこからの相対としてビジネスロジックや外部との接続を定義していく｡ここを軸にすると､DDDの依存の方向と同様に2つの概念が得られる:

Usecases … ドメインに関係や動きを生む

ドメインは在り方､あるいは生まれ方や変わり方と消え方､つまりルールだけがあるので､これらをインタラクトさせる必要がある｡ユースケースにはドメインの動きを記述する｡例えば"ドメインのルールで値をチェックし､それらを保存する"とか｡
Infrastructure … アプリケーション外部との接続

でもユースケースはピュアに書きたい｡だってドメインの動きを書くだけなのにDBのコネクションエラーや外部APIのエラーなんて"今は"関係ないはずでしょ? そこでユースケースはドメインの動きの記述に集中し､実際の外部との接続はインフラ層と呼ぶ場所に任せる｡外部とはDB､Web API､ファイルシステム､などなど｡

ドメインを軸にすると決めることで､それを動かすためのユースケースが生まれ､ユースケースがドメインの動きのモデリングに集中するために実際に外部サービスを呼び出す場としてインフラ層が生まれる｡ドメインを中心においた場合の解の一つとしてDDDが得られる｡

2-1-3. ソフトウェアアーキテクチャの存在理由: 認知摩擦の解消､コンウェイの法則

ここまで個々人の脳の認知負荷を考えてきた｡個人的な感覚の開発風景からチーム開発に話を移してみると､いろんな人間の脳が出てきて､いろんなキャパシティの脳が人間というインターフェイスでコミュニケーションを取り合い､ときに認知力や認識方法の違いで摩擦を感じ､疲労する｡ソフトウェアアーキテクチャを決定し､"どこに何を配置するか"に制約をつくることで､チーム全体が共有するメンタルモデルを統一し､摩擦の発生を抑えられる｡ソフトウェアアーキテクチャがレイヤードであることに重要さは必ずしもないが､ソフトウェアアーキテクチャが定まっており 厳密に実施されている ことは重要である｡

このロジックはどこに書くのか? —— ある人はドメイン､また別の人はインフラに置くべきだと考える｡この認知のズレがコミュニケーションに摩擦を生み､全体的な開発スピードが低下していく｡ソフトウェアアーキテクチャによってどこに何を配置するかを強制･実践していくことで､皆が同意できる自明な場所にて解決され､上記のような議論が発生しなくなる｡厳密な実践を続け､形骸化した謎の三層アーキテクチャにしないことまでが重要になる｡

このコードの構造と組織の認知の関係性は､まさにコンウェイの法則の指摘するそれである｡上記で述べたように､ソフトウェアの構造がカオスであれば組織間のコミュニケーションパスもまたカオスになるという､ある種の セカイ系的な 繋がりがある｡手元にあるソフトウェアの構造の解決で､コミュニケーションコストの解決がなされるわけだ｡ハッキングから今晩のおかずまで同一コンポーネントに記載された凝集度の低い場所からは､様々な内容の議論がチーム内のあちこちで発生するだろう｡結合度の高い箇所で実装に関する議論を始めたら､バックエンド､フロントエンド､SRE､更にはPMを引っ張り出して話をする必要があるかもしれない｡

このコミュニケーションコストの問題は､往々にして組織運営などで解決する傾向が見られる⁴｡コミュニケーションコストのために更にミーティングが増える｡しかし根本的な問題というのは議論が必要なソフトウェア側にあるため､ミーティングのためのミーティングはそのことを看破できる場たりえるが､そうでなければただただコミュニケーションコストが肥大化するだけだ｡確かに問題を認識していてもリアーキテクチャは腰が重い｡実装も時間がかかる｡しかしやらない場合､増えたミーティングの時間もなくならない｡マイクロサービスのような高階のアーキテクチャならば尚更､配置の議論の複雑さが高まるだろう｡

"どうあるべき"が掲げられ､それに沿って作られているのが望ましいが､歴史的経緯により偶発的に積み上げられた実装の地層も多く存在する｡それでも､"本来どうあるべき"という眼差しを改めて向けることはできるし､その新たな眼差しを共有できれば､実装も変わりコミュニケーションコストも少しずつ減っていくんではないか｡読者の皆さんとこの眼差しを共有するため､本項ではとりあえず次章のフローチャートを提案する｡

2-1-4. ちなみに: レイヤーやDDDは必然ではないし､適さない場合もある

当然だがレイヤードアーキテクチャは必然のものではない｡

まずDB操作が始まり､業務仕様があり､エラー制御があり､ワーオDBの中間テーブルのオブジェクトをまた操作してる…そしてAPIレスポンスにパッキングして を一つの関数でおこなうことは､例えばシェルスクリプトでは､適当なハッシュテーブルをインメモリDBと考えれば､よく書くだろう｡これでワークする理由は､コード全体が小さいから(そう､ですよね…?)｡他にもいくつかの理由でレイヤードアーキテクチャたりえない場合がある｡たとえば:

単純なCRUD
データ変換
ハイパフォーマンスが必要な場合

1.はシェルスクリプトと概ね同じ理由で､コード全体が小さく脳への負荷が小さい場合｡ 2.は､単にデータ形式を変換するだけであり､ビジネスロジックが存在しない場合｡それぞれの変換レイヤーがデータの内容を知っていればよいため(ここでfmap を思い出す)｡ 3.は､レイヤー分割による抽象化オーバーヘッドが性能に悪影響を与える場合｡

"今"解きたい問題が脳への負荷だったので解法の一つとしてレイヤードアーキテクチャを選択したにすぎない｡そしてDDDもまたそうであり､主題としてドメインを固定したゆえにDDDになっただけである｡例えばすでにデータベースにデータがあり単純な構造ならばトランザクションスクリプトパターンが適しているかもしれないし⁵､既存とは毛色の機能を追加したい場合は別のアプリケーションに切り出してマイクロサービスなどといった高階のアーキテクチャに話が移っていく｡プロダクトの提供したい価値や業界によってはもっと別のアーキテクチャ特性にフォーカスしたい場合もある｡大事なのは､そのアーキテクチャで何を解決したいかを明確にすること｡ DDDの実施ができてない場合は､ただの理解不足なだけではなくDDD自体がアプリケーションや解決したい問題にフィットしていない可能性もありえる｡

2-2. フローチャートで脳とプロジェクトを整理する: オニオンアーキテクチャ

先に述べたようにDDDには3つの概念､domains, usecases, infrastructureがある｡ここですこし構造を整理する｡突然ですが application というレイヤーを用意します｡その中にusecaseを置く｡ Applicationでは"アプリケーションが何を達成するか"を記述する｡なぜそんなことを? アプリケーションはときに外部サービスとの通信が必要になる｡ここでもその外部サービスが何をしてくれるかにのみ関心があるため､外部サービスのインターフェイスを記述する｡この外部サービスとdomainにあるrepositoryを操作して､usecaseにアプリケーションの振る舞いが書かれる｡これにより､applicationを覗くだけで"何が必要で､何ができるか"が一目瞭然となり､脳にいいですねえ｡

Usecaseないしはapplicationの立ち位置がスッキリしたので､infrastructureもスッキリさせる｡ Applicationはアプリケーションのことだけを考えたい､いわば内側の世界だった｡ともすれば､infrastructureはアプリケーションの外側の世界にあたる｡外界には､こちら(アプリケーション)から外界に働きかける場合と､外界から働きかけを受ける場合の2つのふれあい方がある｡働きかける場合は､例えばDBにデータを保存したり､外部APIを呼び出したりする場合｡これらはinfrastructureに置く｡働きかけを受ける場合というのは､gRPCリクエストを受け取ったりHTTPリクエストを受け取ったりする場合｡これらは interface に置く｡なるほどたしかに､外界から見ればprotobufやAPI schemaはインターフェイスですね｡またインターフェイスかよって思うかもしれないが､OCamlerはこれ以外のinterfaceをsignatureと考えてくれればスッキリするんで､静かに｡

アプリケーションの内･外､さらに内側の階層…という構造から､これは(オニオンアーキテクチャ <: DDD)と呼ばれることもある｡依存の方向性がすべて内側にのみ向かっており､最内のドメインは何にも依存しない真実のみが記載される｡このルールによって､それぞれはそれらの内側の知識だけあれば書けるようになっており､脳への負荷が下がる｡

ということで言い訳が終わり､もう少し解像度をあげるためにフローチャートで見ていく｡

START: コード化しようとしている概念
               ⇓
Q1. それはアプリケーション上の知識やルールか?
    (例: データの整合性､計算ロジック､状態遷移のルール)
    ├─ Yes → Domains: Object (entity) / Value / Repository
    │        アプリケーション上の存在の定義
    └─ No ↓
Q2. アプリケーションの挙動そのものか?
    (例: "登録"というタスクのステップ､"送金"の手順)
    ├─ Yes → Application: UseCase / Service Intf.
    │        知識と外部への要求を呼び出して処理の手順を記述する
    │        外部サービスのインターフェイス
    └─ No ↓
Q3. それは外部からの入力を受け付ける窓口か?
    (例: gRPCリクエスト受け取って処理する)
    ├─ Yes → Interface: gRPC handler / HTTP Controller
    │        外部から入力を受け取り､アプリケーションを実行する
    │        UseCaseを呼び出すアダプター
    └─ No ↓
Q4. その機能はIOを発火する?
    ├─ Yes → Infastructure: DB / Service Impl.
    │        Repositoryや外部サービスの実装
    │        DB､乱数生成器､外部サービスの実際のAPI呼び出しなど
    └─ No → Domain Service

図2.1. フローチャートでDDDのレイヤー分割を考える

このフローチャートで最も重要なことは､とにかく (この)ルールを厳守し続けること である｡例外ができるとアーキテクチャの前提が崩れ､レイヤーを突き抜けていく例外の周辺で認知負荷が上昇し､レイヤードアーキテクチャないしはDDDのうまあじが破壊される｡ルールが厳守されないと､コミュニケーションの摩擦がちょうどその箇所から新たに発生していくだろう｡御プロジェクトに特殊な事項がある場合は､まず実装上も特殊な事項なのかを熟考していただき､その場合DDDに例外を突っ込むのが正しいのか､別のアーキテクチャにすべきかは検討してほしい｡御プロジェクトは多分ユニークだと思いますが､他のプロジェクトも 同様にユニークな 価値提供をしているんで逆に実装として特殊なケースは多くない｡

これらを反映すると以下のようなディレクトリ構造になる(図2.2)｡

/(root)
  ├─ domains
  │    ├─ objects
  │    └─ repositories
  ├─ application
  │    ├─ usecases
  │    └─ services
  ├─ infrastructure
  │    ├─ db/sql
  │    └─ services
  ├─ interface
  │     └─ grpc
  └─ main

図2.2. フローチャートのなす構造の例

ログやメトリクスなどのアプリケーションの運用上必要になるメタ的なものは登場していない｡これらはレイヤーをまたいで直で現れる場合がある｡メタいので｡いわゆるアスペクト指向プログラミングの領域になり､それらの実践は言語やツールに依存することになる｡

3. おわりに

書いてくうちにどんどん日本語がデカくなってしまったので二部構成にした｡実装の話は次回｡

コンウェイの法則については筆者はこれまでピンと来ていなかったが､本項をまとめるうちににわかに理解できてきた｡つまり書いてる途中は(書いたあとも)理解が浅かった｡この記事が面白かった｡

なぜ、組織のつくりとソフトウェアアーキテクチャは似てしまうのか - Qiita

このエントリーは、Engineering Manager Advent Calendarの25日目、最終日の記事です。はじめに拙著「エンジニアリング組織論への招待」では、ソフトウェア自体の構造とソフトウェアを作り上げる組織の構造が似てしまうという「コンウェイの法則」に...

また一言添えておくと､アーキテクチャを決めると単にコミュニケーションが減るのではなく､ 不要な コミュニケーションがなくなるだけだ｡デプロイ可用性やテスト容易性などを強く指向するアーキテクチャならば､SREやQAエンジニアとの連携が必要になるだろう｡ただそれはアプリケーションやプロダクトの運用に対し 本質的な コミュニケーションなので､減ることも減らす必要もない｡

ブログ内で何の言及もしていなかったがコメントが追加された｡ GitHub sponsorも始めた｡いいから黙って俺に投資しろ｡

この記事は11月26日に執筆を開始した ↩
Mark Seemann. 『脳に収まるコードの書き方』. オライリー･ジャパン. 2024. 長年の経験に裏打ちされた著者なりのプログラミング哲学や著名人からの学びが､example projectを作る過程でつらつらと述べられている｡ページを捲るたびにハッとすることが多い｡良書 ↩
Mark Richards, Neal Ford. 『ソフトウェアアーキテクチャの基礎』. オライリージャパン. 2022. やりたいこと､できることに応じたソフトウェアアーキテクチャが並んでいる｡アーキテクチャを考えるにあたっての指標も並んでおり､どこを目指せばよいかも考えられるし現状の診断もできるようになる ↩
著者調べ ↩
本当に 単純な場合に限る ↩

特に旬とかではないベストテン

Sat, 06 Dec 2025 00:00:00 +0000

はじめに

季節感なし

脈絡なし

思い出補正あり

突然のおすすめ楽曲発表ドラゴンに成ったんで､発表します｡オールジャンルすぎておすすめ感はない

10位 Carbon-based Anatomy - Cynic

Enjoy the videos and music you love, upload original content, and share it all with friends, family, and the world on YouTube.

狂気と美しさを感じるプログレッシブバンドCynicのアルバム｡そうベストテンと言いつついきなりアルバムですね｡『Admist The Coals』の重く複雑な入りから『Box Up My Bones』で突き抜ける感じがたまらん｡ Cynicの他の曲だと『I'm a but wave to …』が狂おしくすき｡

9位目が明く藍色 - サカナクション

Enjoy the videos and music you love, upload original content, and share it all with friends, family, and the world on YouTube.

今好きになれる日本のロックバンドってあるんだと思った｡ Queenの『Bohemian Rhapsody』を初めてちゃんと聴いたときと同じ衝撃､いやそれ以上があった｡日本のロックシーンでこういうのやってくれるんだとか､サカナクションでもキャッチーな『新宝島』などがある中でも依然人気であることに､なんつうかこういう楽曲がちゃんと評価される土壌があることに嬉しさを感じたりとか…｡『ミュージック』もかなり甲乙つけがたい｡

8位光の螺旋律 - Kukui

爆思い出補正｡ローゼンメイデン2期ED｡霜月はるかが好きというか､ローゼンメイデンのエンディングで好きになったね｡アニオリの薔薇水晶とかいう謎キャラがいたが､謎キャラ込みでスループットがあり､曲と合わせて良いですね｡チェンバロっぽいキーボードと明るくも静謐な旋律がサァ! 翠星石がなあ!!! 2サビ後半の実質テンポアップと間奏のサビと霜月はるかっぽいコーラスで最後まで突き抜けたあとスンッとなる終わりが気持ちいい｡

7位センティフォリア - Ceui

爆思い出補正2｡青い花ED｡理由はないけど聴いてると涙が出ます｡アニオリの終わり方もかなり好き｡あーちゃんは泣き虫なんですなぁ…｡

6位 Birdland - Weather Report

Enjoy the videos and music you love, upload original content, and share it all with friends, family, and the world on YouTube.

実はわたくしベースを弾くのが趣味なんですが､ベースが好きになった一曲｡だがいきなり最初からハーモニクスでおおよそ普通の(?)ベースらしからぬ高い音が出てくる｡ベースが好きな曲なら他にもLiquid Tension Experimentの『Acid Rain』とかMr. Bigの『Addicted To That Rush』とかあるが､ベストテンに挙げるならやはりこの曲か｡

5位 COSMIC LOVE - 水樹奈々

Enjoy the videos and music you love, upload original content, and share it all with friends, family, and the world on YouTube.

大学受験のあたりで水樹奈々を謎に聴きまくっていたが最も耳に残っている一曲｡これも思い出補正すか? サビのメロディの運びが面白い｡実は『Innocent Starter』もBメロ～サビのつなぎあたりが同じくらい面白い｡

4位 True - L'Arc~en~Ciel

Fare Well

Provided to YouTube by Sony Music Labels Inc.Fare Well · L'Arc-en-CielTrue℗ 1996 Sony Music Labels Inc.Released on: 2012-11-07Associated Performer, Arranger:...

実は2005年くらいまでのラルクがだいたいすきで､中でも思い入れ深いアルバム｡前アルバム収録の『Vivid Colors』の爽やかさに厚みをかけた『風にきえないで』などバンドとしての洗練も感じられる｡頭から終わりまでバラエティに富んだ1枚となっており､なんといっても最後の『Dearest Love』が…ええな｡ 6曲目の『The Fourth Avenue Cafe』といえばるろ剣ですが､『Dearest Love』を聴いて勝手に星霜編を思い出して勝手に気分がよくなってしまう｡ 9曲目の『I wish』のあたたかい冬感から一転して真冬のような冷たさ(雪国出身並感)が､たまらん

3位 The Nightfly - Donald Fagen

Enjoy the videos and music you love, upload original content, and share it all with friends, family, and the world on YouTube.

カッコ良すぎる…｡かっこいい音をちゃんと配置するとこうなるかのような完成度｡中でも1曲目の『I.G.Y.』がやはり至高…イントロかっこよすぎだろ｡これを聴きながら都会の夜を歩きたすぎだろ｡

2位 Metropolis Part 2: Scene from a memory - Dream Theater

Enjoy the videos and music you love, upload original content, and share it all with friends, family, and the world on YouTube.

高校の修学旅行の自由時間でCDショップに行き即ホテルに戻ってこのアルバムを聴きながらベッドで涙を流しつつ就寝た思い出の一枚｡同室だった相馬くんはDinosaur Jr.を聴いていた｡

コンセプトアルバムの最高峰｡アルバムを再生すると物語を追体験することになる｡ 1､2曲目の物語に吸い込まれていくようなイントロダクションから『Strange Deja Vu』の結末を予告するような少し切ないのに爽やかな勢いの乗ったサビが､すごーい… そのまま物語が怒涛のDream Theaterワールドの上で展開して映画のラストシーンのようなクライマックスの『Finally Free』に至り､茫然自失となる｡この物語の1つ前にあたる『Metropolis Part 1: The Miracle and the Sleeper』もすごい｡すごいっつうか意味わからん｡

1位カレンダーガール - わか･ふうり･すなお

Enjoy the videos and music you love, upload original content, and share it all with friends, family, and the world on YouTube.

すまんやけど｡アイカツ1期ED｡この一曲には星宮いちごさんが大スター宮になるまでの重みがあってですね｡グルーヴィなサウンドでABメロノリノリなんだけどサビメロが少し切ない入りで､だけど最後はパッとなる構成｡しかしてサビの"何てコトない毎日がかけがえないのオトナはそう言うけれどいまいちピンとこないよ"って､なんや…😭 1期にして早くもそれぞれの道を歩んでいくのを予見するようなセツナメロディ､でもそれを跳ね飛ばす元気さや若さ､まだフツーの女の子感｡俺って元アイドルじゃないんだけど､幼少期に仲良かったけど疎遠になった友達や何者でもないバカガキで遊んでいた頃を思い出さずにはいられない｡そしてまさに宝ものになるなんてことない毎日を駆け抜けている(た)彼女たちが歌うんだよね､"いまいちピンとこないよ"って｡ "思い出は未来のなかに"ってなんですかあおいさん?! 情緒がおかしくなっちまうよ…｡

おわりに

最近はぜんぜん若モンの曲しか聴いてない｡え､メタル?(笑) 5年後くらいに発表してたらWaMiとか明透とか東雪蓮が入っていたかもしれない｡

KMNZが楽曲として完成度が高くてビビる｡こん人らここにきてコーラスで攻める曲を出せるのかよ｡

Enjoy the videos and music you love, upload original content, and share it all with friends, family, and the world on YouTube.

また､電音部が音楽×ストーリーで展開しているが楽曲がバッチリはまっててすごい! 『月読のダンス』がやばいですね～とか『ルララルララ』のリミックスの仕方とか､やるな…w

Enjoy the videos and music you love, upload original content, and share it all with friends, family, and the world on YouTube.

曲作りが上手いですね～とんでもない量の曲を作ってくれてありがとう電音部

ということで来年2月にDream Theaterが来日するらしいんで行きますわよ～～～(完)

OCaml 5.4のlabeled tuples調査隊～名前の力を感じろ～

Sun, 26 Oct 2025 00:00:00 +0000

こんにちは､びしょ～じょです｡

PoE2パッチ0.3のアビサルもエンドゲームTier15到達したら急に飽きました｡アクトランに関しては､新たに追加されたAct4は島々を船で回る楽しさや(Act3と比較して)移動の簡単さなどでけっこうすき｡一方結局セケマとアルティメイタムがくだらんすぎるんですわな…｡というのとアビサルでエグいDotを敷いてブリンクで粘着してくるmodがありえない話し! ブリンクにブリンクで合わせてdotから抜ければいいんだけど大量にmobがいて当たり判定があるんでブリンクアウトも少しむずいため確死があってさぁ～! でも棘タイタンは面白かったです｡問題点はタイタンというジョブが単純に弱く､vs単体が特に弱いんでアクトボスで10分くらい盾を構えるだけの緊張感のない間延びした戦いを過ごす部分｡安定感はすごい｡

ということでEscape From Duckovを始めたんですがこれはイイネ｡本家EFTのPvP(vE)ゆえのスキルツリーやハイドアウト育成テンポの遅さはうまく解消されつつ漁る楽しさや難易度調整によるカジュアルから本家のハラハラまでいろんなプレイヤーに合わせたレンジの広さ､いいですねえ｡ハイドアウトのチルいBGMも良い｡あとは本家のようないろんなモーションにリアルサウンドがついてくるとおもろいやろなぁと思いつつもカートゥーン世界観にどれくらい合うんかなとも…現時点ですでにおもろいんでこっからブラッシュアップされて更に神ゲーになると嬉しい｡確かにこれでPvPもしたいけど､先述のとおり今のテンポ感だと本家以上にギャップのあるマッチが生まれそうなんで､難しいね｡

1. はじめに

OCaml5.4が最近リリースされた｡

OCaml 5.4.0 Release Notes

OCaml 5.4.0 was released on 2025-10-09. Learn more about this in the release notes.

今回のリリースでも多くの改善や新機能が追加されたが､本記事ではその中から labeled tuples に焦点を当てる｡

公式ドキュメントはこちら

1-1. 最初にネタバレ

ごちゃごちゃ書いていくが､端的に申し上げるとこういったことが書けて嬉しい｡

便利

let analyze_list lst =
  let min = List.fold_left min max_int lst in
  let max = List.fold_left max min_int lst in
  let sum = List.fold_left (+) 0 lst in
  let count = List.length lst in
  let avg =
    if count = 0 then
      0.0
    else float_of_int sum /. float_of_int count
  in
  (~min, ~max, ~avg)

let (~min, ~max, ~avg) = analyze_list [1; 2; 3; 4; 5] in
Printf.printf "Min: %d, Max: %d, Avg: %f\n" min max avg;;

関連する値をタプルで返す場面は多い｡しかし､返ってきたタプルの1番目の要素は何だっけ､2番目は…？と､順序をいちいち覚えたり､ドキュメントを確認したりする必要があったりと､どのアドレスが何を意味するのかパッと分からんことがある｡かといって､そのためだけにrecordで新たに型を定義するのも少し…｡というときにlabeled tuplesが役に立つ｡

またADTsの引数にももちろん利用できる｡特にGADTsを用いて柔軟なinterpreter patternを実装する際､これまでは引数にラベルを付けられず､少し可読性に欠けることがあったが､labeled tuplesでエレガントに表現できる｡

type _ command +=
  | CreateUser : (name:string * age:int) -> user command
  | FindUser : int -> user option command

let interpret : type a. a command -> a = function
  | CreateUser (~name, ~age) -> ...
  | FindUser id -> ...

名前という追加の意味を値に付けられるということですよこれは｡名前があるって大変うれしいね｡名前といえばローゼンメイデンで蒼星石さんが名前は何でも良いがついてると嬉しいという内容のシーンが好きなんですが¹､今はもう令和か｡

2. ふつーのtuplesとの差分を見る

まずは小手調べ｡基本的な構文とこれまでのunlabeled tuplesとの違いを見ていく｡お手元のutopを起動して､一緒に試してみてください｡

(* リテラルの確認 *)
# (~x:3, ~y:5);;
- : x:int * y:int = (~x:3, ~y:5)

(* ラベルなしの要素とも混在可能 *)
# (~x:3, "hoge");;
- : x:int * string = (~x:3, "hoge")

型がx:int * y:intとなっており､int * intとは区別されている｡

みんなちがってみんないい

# (~x:3, ~y:5) = (3, 5);;
Error: This expression has type 'a * 'b but an expression was expected of type
         x:int * y:int
       A label x was expected
# (~x:3, ~y:5) = (~y:5, ~x:3);;
Error: This expression has type y:'a * x:'b
       but an expression was expected of type x:int * y:int
       Labels y and x do not match
# (~x:3, ~y:5) = (~x:3, ~y:10);;
- : bool = false

(* destructuring assignmentも同様 *)
# let (x, y) = (~x:3, ~y:5);;
Error: This expression has type x:'a * y:'b
       but an expression was expected of type 'c * 'd
       The first tuple element is labeled x,
       but an unlabeled element was expected
# let (~x, ~y: _) = (~x:3, ~y:5);;
val x : int = 3

ラベル多相とかsubtypingはなさそう

まあtuplesにもサイズに関してsubtypingないし

# ((~x:3, ~y:5, ~z:10) :> (x:int * y:int));;
Error: Type x:int * y:int * z:int is not a subtype of x:int * y:int

当然型名にも束縛できるし多相も使える

# type 'a t = (x:int * y:'a);;
type 'a t = x:int * y:'a

# let f () : int t = (~x:3, ~y:5);;
val f : unit -> int t = <fun>

# f ();;
- : int t = (~x:3, ~y:5)

関数の引数にも驚きなく使える

# let g (~x, ~y) = x + y;;
val g : (x:int * y:int) -> int = <fun>
# g @@ f ();;
- : int = 8

単なるsyntacticな拡張ではなく､型レベルで組み込まれた新機能ということが分かる｡

3. 関数のラベル付き引数と雰囲気似てますが

たしカーニハン｡ただ明確な違いとしては､ラベル付き引数には順序がない一方､先述のとおりlabeled tuplesにはある｡

(* ラベル付き引数は順不同 *)
# ListLabels.fold_left ~f:(+) ~init:0 [1;2;3];;
- : int = 6
# ListLabels.fold_left [1;2;3] ~init:0 ~f:(+);;
- : int = 6

(* 再掲 *)
# (~x:3, ~y:5) = (~y:5, ~x:3);;
Error: This expression has type y:'a * x:'b
       but an expression was expected of type x:int * y:int
       Labels y and x do not match

また､ラベル付き引数の特徴であるオプショナル引数(?arg)もlabeled tuplesにはない｡

(* ラベル付き引数のoptional引数 *)
# let f ?(x=0) () = x + x;;
val f : ?x:int -> unit -> int = <fun>
# f ();;
- : int = 0
# f ~x:5 ();;
- : int = 10

(* まあ意味分からんですわな *)
# let (~x, ?(y=0)) = (~x:3, ~y:None);;
Error: Syntax error

公式マニュアルのlimitationの項にもラベル付き引数との曖昧性に関する言及がある｡

Parentheses are necessary to disambiguate functions types with labeled arguments from function types with labeled tuple arguments when the first element of the tuple has a label.

あっ逆に関数の引数以外ではカッコ省略できるんだ

そうなんだ

# ~x:3, ~y:5;;
- : x:int * y:int = (~x:3, ~y:5)

(* 関数定義で括弧を省略するとラベル付き引数と解釈されて構文エラー *)
# let h ~x, ~y = x + y;;
Error: Syntax error

(* カッコヨシ! *)
# let h (~x, ~y) = x + y;;
val h : (x:int * y:int) -> int = <fun>

4. Recordsより使い勝手いいんですかってね

類似の機能にrecordがあるやん｡ Recordsは型-モジュール(名前空間)に束縛されるが､labeled tuplesは自由なところが個人的に大きなポイントに感じる｡

Recordsは基本的に名前がついており²､名前があるということは名前空間に属するということ｡しかし､labeled tuplesはそうした制約から自由｡定義なしにアドホックに作ることができる｡

(* Recordは型を定義する必要がある *)
# module M = struct
  type t = { x : int; y : int }
end;;
module M : sig type t = { x : int; y : int; } end

(* Recordの名前空間は実は推論してくれるんですが､この文脈では失敗する *)
# let v = { x = 3; y = 5; };;
Error: Unbound record field x

(* ので明示的に名前空間Mを教える *)
# let v = M.{ x = 3; y = 5; };;
val v : M.t = {M.x = 3; y = 5}

(* 一方labeled tuplesは自由に作られる *)
# let v' = (~x: 3, ~y:5);;
val v' : x:int * y:int = (~x:3, ~y:5)

(* 異なるモジュール間でも構造が合っていればOK *)
# module N = struct
    let f () = (~x:3, ~y:5)
end;;
module N : sig val f : unit -> x:int * y:int end
# let (~x, ~y) = N.f ();;
val x : int = 3
val y : int = 5

手軽でイイネ｡

一方､recordsのフィールドには順序がないが､先述の通りlabeled tuplesには順序があるなどの取り回しずらさはある｡加えて､recordsのフィールド省略やprojectionといった操作もない｡

(* おさらいレコード *)
# type t = { x: int; y: int };;
type t = { x : int; y : int; }
# let v = { x = 3; y = 5 };;
val v : t = {x = 3; y = 5}
# v.x;;
- : int = 3
# let { x; _ } = v;;
val x : int = 3

(* ちょっとかゆい使い勝手の悪さ *)
# let v' = (~x:3, ~y:5);;
val v' : x:int * y:int = (~x:3, ~y:5)
# v'.x;;
Error: This expression has type x:int * y:int which is not a record type.

(* あっそういう推論になって型検査が通らなくなるんですね *)
# let (~x, _) = v';;
Error: The value v' has type x:int * y:int
       but an expression was expected of type x:int * 'a
       The first tuple element is labeled y,
       but an unlabeled element was expected
(* なのでこちらはOK *)
# let (~x, ~y:_) = v';;
val x : int = 3

ランタイムの表現としてはいずれもn-length arrayなんで同じような操作感だと嬉しいニャンけどねえ Objで中身を見てみよう｡

ランタイム上は同じ

# let x : int =
  Obj.(repr (~x:3, ~y:5)
       |> Fun.flip field 0
       |> obj) ;;
val x : int = 3

# type t = { x: int; y: int };;
type t = { x : int; y : int; }
# let x : int =
  Obj.(repr { x = 3; y = 5; }
       |> Fun.flip field 0
       |> obj) ;;
val x : int = 3

おんなじやおんなじやおもて…この操作の不便さを…変えてほしい…!!

5. 総評

器用貧乏だけど入ったことが嬉しいんで､嬉しいね｡実は順序なしだとpolymorphic variantsで代替できる気がする(互換性は未検証)

# let f () = (`X 3, `Y 5);;
val f : unit -> [> `X of int ] * [> `Y of int ] = <fun>
# let (`X x, `Y y) = f () ;;
val x : int = 3
val y : int = 5

まあこっちのがランタイムコストちょっとかさむとか記述量がアレソレとかあるんで､一応優位性はね｡ただADTsの引数については無名record書けるんやった～w

type _ command +=
  | CreateUser : { name: string; age: int } -> user command
  | FindUser : { id : int } -> user option command

まあ関数の戻り値に自然に名前をつけられるのはかなり良い｡

6. おわりに

いろんな言語機能が入ると嬉しいです｡嬉しいなあ｡ Modular explicitsが5.5に入りそうな気配があったりなかったりするんで､次のリリースも期待大です｡

ここで書く場所がなかったんで供養したい唐突なOCamlトリビア: ocaml/ocamlのtuplesは最大$2^{22}-1$個の要素を持てる³｡

『Rosen Maiden』 Phase 28 ↩
Variantのフィールドは無名といえば無名だが､variantの名前空間には紐づいてる ↩
https://ocaml.org/manual/5.4/values.html#ss%3Avalues%3Atuple さっき知った｡recordsも同じランタイム表現なので2^22-1個のフィールドを持てる ↩

関数型まつり2025ありがとう､そして補足

Tue, 17 Jun 2025 00:00:00 +0000

こんにちは､びしょ〜じょです｡

ナイトレインは買ったら最後資料が作れなくなると思って発表終わるまで買うまいとしていたんですが､結局LoLのブロウルを無限にやってました｡ショウジンTF黒斧のファイタールシアンが面白いですが､ナヴォリ積むならショウジンじゃなくてIEでよくないか? と思わなくもない｡今ならポーションで無限スケールするので､天啓で金策ビルドも良いかもしれない｡みんなのブロウル用クソビルドはどうかな?

はじめに

関数型まつり2025にスピーカーおよびスポンサーとして参加した｡

Continuations: continued and to be continued - lilyum ensemble

lily, Aikatsu, Programming language, and more

とりあえず発表すると人から声を掛けてもらえるのと､他の発表者に声を掛けやすいという雑なモチベで応募した｡ちゅうか関数型というある程度話す内容のあるドメインではあるし｡スライド作るのが､ジジイになって馬力や集中力が減り､当日発表30分前まで泣きながら作るという激ヤバだったんですが､とりあえず情報を詰め込むという発表においてはアンチパターン寄りな方向でバリューを出しにいった｡

スポンサーブース

ブースに来てくれた方々にも話したが､弊社は積極的に関数型言語を使っているわけではなく､

び｢これどうすか? プロポーザルも一応投げているが｣
社｢関数型明るくないけど採択されたらいいですよ｣
→採択された

という流れでスポンサー出展が決まった｡そもそもPPLにもスポンサーしていたので､社内での出展ハードルはそんなに高くはなかったんですが､よかったですね｡

自転車置き場の議論のように誰でも参加できる､さらにインタラクションのある催しをしたいなと思ってたんで､仕事で書きたい言語にシールを貼ってもらうというアクティビティをした｡

関数型まつり #fp_matsuri 全日程終了！
株式会社eiicon開発部として初めての出展でしたが、大きな刺激をいただける2日間でした。
運営の皆様、また弊社ブースにお越しいただきました方々本当にありがとうございました！🙇 pic.twitter.com/eiAEmaHs6p
— 株式会社eiicon 開発部 (@eiicon_dev) June 15, 2025

世界の40人に1人がOCamlで仕事したいと思っている、これが民意です
— びしょ〜じょ (@Nymphium) June 16, 2025

シールを貼っていただいた言語について自分がたまによくわかんねえ話をするという謎システムですが､盛り上がってよかったです｡感謝

感想

まず自分の発表以外の部分｡最初に言いたいのは…コーヒーがうまかった! ホットとアイスがあって大変うれしかったです｡ありがとうございました｡

Rustにモナドを入れたい話¹はなかなかおもしろく啓発的だった｡ MonadはRustのようなリソースセンシティブな型の上では､継続を使える回数でData Functor(anytime)とControl Functor(up to/ exact once)の2つに分かれる(そしてData Functor ⊃ Affine-Control ones ⊃ Linear-Control ones)(と非線形な富豪モナド)という発表最大のポイントも良かった｡

んですが､ モナドはdoを記述するためのデータ構造 という､おおよそ普段とは逆方向の見方が興味深い｡ do expressionの初出っぽいHaskell 1.3 reportでは､

A do expression provides a more readable syntax for monadic programming.

とあり､へぇ〜proceduralではないのだな､となるが､proceduralがreadableなことをimplyしてるのかなぁ〜とは思う｡セミコロンによるsequenceはCなどの手続き的記述を流石に意識してないわけがないだろう｡確かに副作用が起こる部分が1行ずつに分かれると､プログラムを追うのが大変ラクになる｡コントロールを直列にする､CPSよりANF､ﾑﾆｬﾑﾆｬ…

非同期のやつ²は､確かに非同期ランタイムを言語の上でやる場合Freeとインタプリタになって､計算木とCEKだ〜になった｡ CEK tripleを非同期キューで回すことで人々が思うような非同期ランタイムになれるとか､big-step semanticsだと継続が取り出せないんで³非同期ランタイムとしては採用できず､プログラムをナイーブに読むときってbig-step semanticsなのかもなぁ……など｡

Scalaのcats-effectの例は､JVMのJITが頑張るんでナイーブなインタプリタでもOKとのことでしたが､ユーザレベルのランタイムでちゃんとやるってむずいよなぁ〜計算木を最適化するのかインタプリタをCPSで書いて言語自体の処理系がいい感じに最適化してくれるのを祈るかガチgotoで手動dispatchか…楽しいですね｡

補足など

完走した感想ですが､もう二度とBeamerでスライドは作りません……⁴｡あと奇しくも知り合いの方が直近で継続の話をしており､タイトルのテイストもなんとなく似ててウケ

RubyKaigi 2025 で継続の話をしてきました | Wantedly Engineer Blog

　ウォンテッドリーのバックエンドエンジニアの水野雅之です。4月16日から18日まで開催された RubyKaigi 2025 において、Ruby にネイティブ実装されている継続オペレータの解説とよ...

call/ccよりmodularなshift/resetや! という自分もすこし触れたものをRubyで掘り下げた内容｡人は一般に､継続で何か話そうとすると､/*Compiling with(out)? Continuations*/というタイトルを先に考えたくなってしまい､そこから変形するので似てしまうわけですね｡

内容はまぁ〜先述のとおりカツカツだったのでゴチャついてるんですが､functionalとproceduralの比較とエフェクトになんで継続が絡むのかが整理できてよかったかなと｡前者の対応関係は思ったより評判がよく､継続への理解がしやすいのとCPS-SSAはそんなにメジャーな話じゃないからかな｡ SSAのphi関数は､Join Point⁵とかK-Normal Form⁶に当たるが､素のCPSはcontinuationのコピーになる｡ちょっと重いですね｡話し足りなかった部分でいくと､ANFとかdouble-barreled CPSとかSelective CPSなどといった様々な中間表現…｡

後者については､昔ダラダラ書いた内容をシャキッと話せたんで個人的にかなりスッキリしました｡悔しいのは､スライド制作でChatGPTと相談していたときにこういった整理をチャGがしてきたこと｡俺はもうAIに勝てないんや…いや俺のブログ学習してんだろ? 学習禁止〜!!

それはさておき､この発表で継続に興味を持った方とかもちらほら居て､やってよかったなぁ〜…｡

Q など

バカタレなんで､発表30分前に資料作り終えたんで､発表練習ができず質問時間分も食ってしまった｡申し訳ございません｡懇親会などで質問等してくださった方々がおり､大変うれしいですマジで｡

OCamlの人らがshift/resetを語るのはなぜ

OCamlで限定継続といえばdelimccと浅井先生のshift/resetプログラミング入門⁷なんですが､いずれもshift/resetを題材にしているため｡ Scala2.12に入っていた限定継続もshift/resetじゃなかったか?

スライド中でいっぱいでてきたdelimited controlsたちですが､一番強いのがcontrol0/prompt0で､GHCはさらにプロンプトつきのものを採用している⁸｡ 0系のが表現力高いというのは､(中略)よりプリミティブな操作のほうが強いということですね⁹｡

妄想 -- parallel effect handlers

このあたりの話をしていて

Goにコルーチンを作ってone-shot algebraic effect handlersといういつものテクをやろうとしたんですが

From Goroutines to Coroutines: goroutines+channelsから考えるコルーチンの分類 - lilyum ensemble

こんにちは､びしょ～じょです｡だいぶ前にコルーチンの分類について記事を書きました[1]｡今回は､この分類を実装サイドから考えていこうという企画です｡実装にはGoのgoroutinesとchann...

コルーチンの管理にgoroutinesの参照をグローバルなstackで持つということをやっていて､並列にするとぶっ壊れるわけですな｡事情は全然ちゃうんだけど､並列処理が標準で使えるようになったOCamlのalgebraic effect handlersでも､エフェクトの捕捉はスレッドをまたげないという制約がある｡ C FFIのコールスタックをまたげないという部分とも絡んでいるが､まあ､無理っちゅうわけですな｡パラフレーズしておいてどれくらい関連あるか謎なんだけど､algebraic effect handlersは並列に少し弱いらしい｡

ランタイムの継続の表現､つまりコールスタックと変数ストアをポータブルな形にするとか､Cの呼び出し部分とのcompatibilityを保つとか､そのあたりをケアした話が出るんじゃないかなぁという妄想を語った｡先に実装の話が､それこそOCamlのグループから出て来ると思うが､物好きな理論系の人が並列計算+代数的効果のモデルを提案するかもしれない｡

"継続"という邦訳……

"Continuations"なんだからまあ"継続"ではあるが､じゃあ先に"継続"がでてきたらどう思いますか? 確かに……残りの計算というモノっぽい概念に対して"継続"って､あまり日本語話者の感覚ではない気がする｡という話をしたら"残りの計算"もなんだか分からんと｡ "計算"もなんやねん! と｡

継続はstaticなのに"継続"といういかにもdynamicな語がワカラン! と言われたんですが､これはそもそも継続がdynamicなんですな｡ CPSにするとまあなんとなく感覚が掴めて､ほらCPS変換で得られたmetacontinuationは実行時に到達するんだしdynamicやないですか? と説明したんだけど､だからって継続……ウーン……あなたはタイムスリップできたらもっとプロパーな名前付けられそうですか?

Haskellなにが純粋やねん何がdoだモナドだ

igrepさんと懇親会でお話して､彼の発表にもある↑について https://the.igreque.info/slides/2025-06-15-fp-matsuri#(22)

私も昔は確かに､IOは実際に発火してんだから純粋じゃないやんけHaskellerは詐欺師集団か!! と憤りを覚えたこともある｡まあ今なら､純粋は "(Monadでエフェクトを隠蔽しているのであたかも)純粋(かのようにプログラムを記述し､mainにIO aを接着させないと発火しませんよ)"の略であることは分かる｡ただ､この"純粋"が略語であることを初心者は分からないんで､確かに純粋関数型言語って何言ってんだコイツにはなる｡この辺もうすこし議論があるらしいんですが､議論のすえHaskellが"純粋"の看板を下ろしてもランタイムとIOのシステムは変わらないと思うんで､別にこの辺のレトリックにこだわらなくていいです(という話を↑ですこししてくれています)｡

IOプログラミングの本質は順序があってchainするという部分の話を共感してもらえ､手続き的に書く(do)にはmonadという構造が必要になる､というkonnさんの話にも戻っていって､エッセンシャルな部分なんやなぁということが再確認できた｡

fcontrol/runとSCIENCE TOKYO

SCIENCE TOKYOでは某お茶女の研究室を出た方が継続を布教しまくってるらしい｡今年のPPLではポスター発表にて､私も熱烈推奨しているfcontrol/runが理解しやすく学生ウケがよいという話を聞いた｡しかし懇親会でshift/resetのみならずfcontrol/runも講義でもはや利用されてないと言われ椅子から転げ落ち横転して号泣して顔がなくなった｡しかしよく聞くと､全部algebraic effect handlersに統一されるとのことで､逆にどうなってんねん､と真顔になった｡ SCIENCE TOKYOでとんでもないことが起きてますよ｡

WASMとeffect handler

wasm effect handler もう動いてるんだっけhttps://t.co/z485QM5zrC

#fp_matsuri_a
— mizchi (@mizchi) June 14, 2025

なぁWasmFX､息してるか…? してる…

発表で触れたOCamlのWASMバックエンドはselective CPSまたはJSPIでPromiseに変換される¹⁰ ¹¹｡特にJSPIでOKなのは継続がone-shotなところが出たわね｡

その他

2日目に発表していたYoutuberの大堀さん…いや､あの大堀先生が､奇跡的なかみ合わせで本日継続に関する動画を投稿してました｡

Enjoy the videos and music you love, upload original content, and share it all with friends, family, and the world on YouTube.

継続に興味持った方も持ってない方も絶対これ見たほうが良いです｡ 2日目のSML#の話を､大堀先生と上野先生の2連続で聞けたのも大変すばらしかった｡

おわりに

わりと満足｡

このブログの読者ですという人々がたまに弊社ブースなどでお声がけしてくださったりして大変うれしかったです｡令和の日本において信仰の自由は保証されているので､弊ブログのファンというのはもっと声を大にしていただいて大丈夫です｡多分迫害されません｡

うおｗ pic.twitter.com/O32xGI86mh
— びしょ〜じょ (@Nymphium) June 14, 2025

元同僚の方に｢江の島のチューリングと呼ばれている｣まで詠唱されてウケました｡

江ノ島のチューリングと呼ばれて(ない)1年 - lilyum ensemble

はじめにこんにちは､びしょ～じょです｡実は1年前に守谷から江ノ島の前に引っ越してまして｡せっかくなんで一筆したためる｡新居情報あざす pic.twitter.com/kthNIMNKZe— びし...

Rust世界の二つのモナド──Rust でも do 式をしてプログラムを直感的に記述する件について by konn ↩
ラムダ計算と抽象機械と非同期ランタイム by Kory ↩
制御演算子を持つ言語を､CPSを使わずに実装すると感覚が得られる: https://github.com/Nymphium/lambdaeff/blob/master/text/main.pdf ↩
前回もそう誓ったはずだが…｡ ↩
多分AspectJのJの部分｡思っているのはこちらの方: https://www.microsoft.com/en-us/research/wp-content/uploads/2016/11/join-points-pldi17.pdf ↩
https://esumii.github.io/min-caml/tutorial-mincaml-9.eng.htm ↩
正しくはOCamlではなくてOchaCamlというvariant｡Answer-Type Modificationも導入されており型を含めた限定継続の雰囲気を掴むのに大変よい｡ ↩
https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0313-delimited-continuation-primops.rst ↩
継続の中で再度限定継続を取り出すとき､delimiterの指定が自動で入るのがshift/reset等､入らないのがshift0/reset0など0系｡rehandleの自由度が高い(≒表現力が高い)のが後者ということ｡ ↩
https://github.com/ocsigen/js_of_ocaml/blob/master/manual/effects.wiki ↩
https://v8.dev/blog/jspi ↩

キーボードアルティメイタム第2話 Corne V4 Chocolate

Fri, 02 May 2025 00:00:00 +0000

こんにちは､びしょ〜じょです｡

最近『教皇選挙』を観ました｡お前は観たか? 観たほうがいいぞ｡

内容○､画○､音響○なんで､キリスト教世界観分かるパーソンだったら更に面白く観られる気がします｡

1. はじめに材料調達部門

頭がおかしくなってキーボードを買った｡

Corne V4 Chocolate

左右分割キーボードに関する注意事項左右のキーボードをTRRSケーブルで接続したまま、両方のキーボードを同時にPCとUSB接続しないでください。PCとキーボードを接続中に、左右間を接続するTRRSケーブルを挿抜しないでください。キーボードおよびPCに深刻なダメージが発生する可能性があります。EMI（electromagnetic interference）による動作不良に関する注意事項現在販売している基板において、EMI（電磁干渉）による不具合の報告が寄せられています。これはスマートフォン等の機器が近くにある場合によく発生し、環境により、左右の片方もしくは両方のキーボードが動作不良に陥ります。このような症状が発生した場合、一度USB接続を解除し、機器をキーボードから30cm以上離してから再接続してください。詳細についてはこちら。Corne V4 Chocolateとはfoostan氏によりデザインされた分割キーボードのベストセラー、Corneシリーズの最新作横6 x 縦3キーのcolumn staggered配列(列方向にずらした配列) + 親指3キーの左右分離型キーボードです。キー数は左右合わせて最大46個のみで非常にコンパクトな設計となっています。40%分離型キーボードの代表格であるLet's Splitよりも小型であり、Irisから数字列を外したような配置になっています。V4の特徴はんだ付け不要ファームウェア書き込み済み専用ケースの付属RemapによるWebブラウザからの簡単なキーマップのカスタムホットスワップ可能フルキーバックライト対応はんだ付けが不要かつファームウェアも書き込み済みのため簡単に組み立てができ、すぐに使用できます。さらに専用のケースが付属します。高級感のある見た目や打鍵音にもこだわったキットです。V3からの変更点はこちらをご参照くださいデフォルトキーマップは以下をご覧ください（中央4キーは未割り当てです）内容物実装済み基板（Ver.4.1）　…　左右各1枚ケース　…　左右セットマウントプレート　…　2枚スペーサー M2 5mm　…　8本ネジ　M2 4.5mm　…　16本クッションゴム　…　8個別途ご用意が必要なものキースイッチ（Kailh Choc V1もしくはV2対応の物）×46個キーキャップ（Kailh Choc V1もしくはV2対応の物）×46個USB Type-Cケーブル … 1本TRRSメタルケーブル 0.8m … 1本※ CherryMX互換スイッチには対応しておりません組み立て方法ビルドガイドはこちらをご参照ください。https://github.com/foostan/crkbd/blob/v4.0/docs/corne-chocolate/v4/buildguide_jp.md関連商品キーボードアクリルプレートCorne V4 Chocolateに付属しているFR4製のマウントプレート（スイッチプレート）を交換し、アクリルに変更できるサービスです。下記が該当のプレートです。「Corne V4 Chocolate フルバージョン - 2mm」「Corne V4 Chocolate レガシーバージョン - 2mm」キーボードフォームカットサービスCorne V4 Chocolateに取り付けることができるPoron製のフォームをカットするサービスです。下記が該当のフォームです。「Corne V4 共通（ボトム） - 2mm」「Corne V4 共通（ボトム） - 3mm」キーボードカスタムプレートプリントサービスCorne V4 Chocolateのスイッチプレート（アクリル製）にUVプリントを行うことで、カスタムできるサービスです。下記が該当のプレートです。「Corne V4 Chocolate フルバージョン - 2mm」「Corne V4 Chocolate レガシーバージョン - 2mm」免責事項写真は作成見本であり商品内容と同一ではありません。また仕様は予告なく変更することがあります。

ファームウェアはqmk
いわゆる40%分割型
- 数字キーが無い
ビカビカ光る
ホットスワップ
- ソケットはすでに着いてるのでキースイッチ(別売)を刺すだけ

というのが特徴｡数字キーいらねえんじゃねえのとなって､こうなった｡ ErgoDox EZからの乗り換えになる｡

図1.1. サイズ比較｡手前がCorne､上の黒いのがErgoDox EZで白いのがMoonlander

キースイッチはKailhのChoc v2 Deep Sea Silent Isletという結構新しいやつを買った｡

Kailh Choc v2 Deep Sea Silent Islet Switch

このスイッチは近年人気が出てきているChoc v2スイッチの静音版です。喫茶店などの静かな環境で打鍵する際に特にオススメです。逆に打鍵感を楽しめる場合は、Kailh Choc v2 White Rain Switchの方が軸ブレが少なくスムーズに動作する印象があります。またフォースカーブの右側を見ると分かりますが、このスイッチは底打ち時の衝撃を柔らかくする効果がありますので、ErgoArrowsProのような剛性が高いキーボードに特にオススメです。

HHKBみたいな､少しザラっとしてるけど滑らかな静音リニアで気持ちがいい｡流通が少なそうなのがネック｡

親指で押すキーは軽くしたいのでChoc v1のピンク軸にした｡ v1とv2はソケット互換があるのでどちらも使える｡一方キャップに互換はない｡

Kailhロープロファイルスイッチ

※キースイッチのみの商品です。キーボード等は含まれません。※キースイッチの品質に関する免責事項を必ずご覧になってからお買い求めください。ロープロファイルスイッチ（Choc V1）です。赤軸：スムーズなリニア軸茶軸：クリック感のあるタクタイル軸白軸：カチカチ感のあるクリッキー軸Red Pro：軽くてスムーズなリニア軸Pink：さらに軽くてスムーズなリニア軸赤軸スイッチ互換性：Choc V1スイッチタイプ：リニア押下圧：約45g±10gf動作圧：約50g±10gfストローク：3.0mm±0.5mm接点：1.5mm±0.5mmPCBマウント（5ピン）型番：CPG135001D01メーカープロダクトページデータシート赤軸茶軸スイッチ互換性：Choc V1スイッチタイプ：タクタイル押下圧：約45g±15gf動作圧：約60g±10gfストローク：3.0mm±0.5mm接点：1.5mm±0.5mmPCBマウント（5ピン）型番：CPG135001D02メーカープロダクトページデータシート茶軸白軸スイッチ互換性：Choc V1スイッチタイプ：クリッキー押下圧：約50g±10gf動作圧：約60g±10gfストローク：3.0mm±0.5mm接点：1.5mm±0.5mmPCBマウント（5ピン）型番：CPG135001D03メーカープロダクトページデータシート白軸Red Proスイッチ互換性：Choc V1スイッチタイプ：リニア動作圧：約35gfストローク：3.0mm±0.5mm接点：1.5mm±0.5mmPCBマウント（5ピン）Pinkスイッチ互換性：Choc V1スイッチタイプ：リニア動作圧：約20gfストローク：3.0mm±0.5mm接点：1.5mm±0.5mmPCBマウント（5ピン）データシート　　　　　Pink

めちゃ軽く手への負担は少ないが､Isletが静音すぎて相対的にカチャカチャ音が気になるのが玉に瑕｡

2. qmk_firmware 小テク集

xmodmapでキーマップを変更していた10年以上前から入力の歴史は続いており(中略)(攻略)｡ ErgoDox EZのキーマップをベースにした｡

qmk_firmware/keyboards/crkbd/keymaps/nymphium/keymap.c at bdee63cabddf0aefa192d44ff0f894eaf7e07f8f · Nymphium/qmk_firmware

keyboard controller firmware for Atmel AVR and ARM USB families - Nymphium/qmk_firmware

キーボードがだいぶ小さくなったんで､マウス操作レイヤーと数字操作レイヤーを追加する｡ shift+数字も変更したいので､それ用のレイヤーも追加する｡

2-1. tri layer

LOWERレイヤーでの入力にshift modifierを適用したい場合､ナイーブにシフトキーだけ押すとうまくいかない｡うまくいかないんで､ layer_state_set_user関数内でupdate_tri_layer_stateを使って複数レイヤーをまたぐ場合のルールを登録する｡

Tri Layers | QMK Firmware

Documentation for QMK Firmware

keymap.c

layer_state_t layer_state_set_user(layer_state_t state) {
    state = update_tri_layer_state(state, _LOWER, _SHIFT, _LSHIFT);
    state = update_tri_layer_state(state, _NUM, _LOWER, _NMODS);
    return state;
}

図2.1. `update_tri_layer_state` の使い所さん

Shiftキーを押したときに_SHIFTレイヤーに移行すればよい｡このとき_SHIFTは何も登録してないレイヤーでよい｡

これで､

_LOWERかつ_SHIFTのとき､_LSHIFTレイヤーに移行
_NUMかつ_LOWERのとき､_NMODSレイヤーに移行

する｡ちなむとcomboもうまくいかない｡switching layer系の組み合わせもうまくいかない｡皆さんも諦めるか､smarterな解法があったら教えて下さい｡

2-2. key override

QMKを触っていると人々はレイヤーがサァ! とか色気づくんだけど､modifier key+key→別のキーに変換というナイーブな機能がある｡

Key Overrides | QMK Firmware

Documentation for QMK Firmware

keymap.c

const key_override_t *key_overrides[] = {
    &ko_make_basic(MOD_MASK_SHIFT, KC_0, JP_QUES),
};

図2.2. key overrideでShift+0→`?`を出す

Shift+0で?が出てくるようになる｡ちなみに俺は普通のキーボードでShift+0すると何が入力されるのかもう覚えてない｡

2-3. マウス中クリック/ホイール

マウスホイールの中クリックを皆さん使っているか? ブラウザのリンクを中クリックすると新しいタブで開いたり､タブを中クリックするとcloseしたりする優れモノです｡

qmk_firmwareはマウスエミュレーションができる｡

Mouse keys | QMK Firmware

Documentation for QMK Firmware

QMKと中クリックは人生のテーマだったんですが､

process_record_user.switch in keymap.c

case MIDDLE:
    if (record->event.pressed) {
        register_code(KC_BTN3);

        WAIT_PRESSING(record);

        unregister_code(KC_BTN3);
        layer_on(_WHEEL);
    } else {
        layer_off(_WHEEL);
    }
    return false;

図2.3. 中クリック/ホイールの実装(incorrect)

プログラム2.3だと先中クリックが入力されるため､ホイール操作だけしたいのに変にリンクを開いたりしてしまい､Webサイトのスクロールできるtable of contentsでスクロールするつもりがうっかり別タブを開いてしまう事故が多々おきた｡

鬼の努力は実はたった1行で解決できる｡

keymap.c

#define MIDDLE LT(_WHEEL, KC_BTN3)

図2.4. 中クリック/ホイールの実装(correct)

これをkeymapで呼ぶだけ｡

Layers | QMK Firmware

Documentation for QMK Firmware

ドキュメントはちゃんと隅々まで嫁ってことですな…w

2-4. レイヤー数増やす

config.h

#undef DYNAMIC_KEYMAP_LAYER_COUNT
#define DYNAMIC_KEYMAP_LAYER_COUNT 9

図2.5. レイヤー数を増やす

はいこれです｡これを書かずに7以上のレイヤーを定義するとコンパイラが｢DYNAMIC_KEYMAP_LAYER_COUNT は6や!!｣と怒ってくるので､察せられます｡

3. マウスtips

多分世の中には多くのqmkマウスエミュレーション愛好家がいると思うんですが､私もその一人でしてェ…｡

Mouse keys | QMK Firmware

Documentation for QMK Firmware

一旦こうなっている｡

config.h

#define MK_KINETIC_SPEED

#undef MOUSEKEY_DELAY
#define MOUSEKEY_DELAY 0
#undef MOUSEKEY_INITIAL_SPEED
#define MOUSEKEY_INITIAL_SPEED 80
#undef MOUSEKEY_MOVE_DELTA
#define MOUSEKEY_MOVE_DELTA 8
#undef MOUSEKEY_BASE_SPEED
#define MOUSEKEY_BASE_SPEED 2200

#undef MOUSEKEY_WHEEL_DELAY
#define MOUSEKEY_WHEEL_DELAY 3
#define MOUSEKEY_WHEEL_INTERVAL 40
#define MOUSEKEY_WHEEL_MAX_SPEED 12
#define MOUSEKEY_WHEEL_TIME_TO_MAX 16

図3.1. マウスのパラメータ〜

Kineticモードはカーソルの速度がquadratic curveで加速するため､最大速度から逆算すると初動からしばらく小さく動けるので､繊細に動かせるし遠くに動かしたいときも困らない｡ MOVE_DELTAで加速度合いを変更し､BASE_SPEED まで (BASE_SPEED - INITIAL_SPEED) / MOVE_DELTA millisecかけて加速していく｡

結局この辺は好みなんで快適な数値を探してください(爆)

4. おわりに

いかがでしたか?

ちなみに第1話はない｡

5. おまけ

ありすぎだろ

壊れたキーボード直してたら家にキーボードありすぎることに気付いた pic.twitter.com/C5PgB5V2sm
— びしょ〜じょ (@Nymphium) May 1, 2025

TEXシリーズはYodaからぼちぼち買ってるので愛着がある｡奥にあるLogiのG515もG HBUという専用のソフトウェアでレイヤー機能や様々なカスタマイズができるんで使い勝手がよい｡

なんとなくほしいな〜とかゲームしたいな〜となると､増えてしまうわけですね｡

DependabotのPRにフックして追いcommitする

Mon, 31 Mar 2025 00:00:00 +0000

こんにちは､びしょ〜じょです｡

寒すぎる｡俺達の春を返せよ…｡

1. はじめに

本ブログはJekyllで運用されており､GitHubでホストされ､Dependabotで依存ライブラリのアップデートを最近自動化した｡

ところで､このシステムでは開発にNixを使っており､ruby-nixによってRubyの依存ライブラリをNix化している｡ bundixでGemfile.lockからgemset.nixを生成し､ruby-nixでNix化されたgemsのパスが通っているshellが動いており､そこで開発をおこなう｡

でもよぉDependabotのPRではgemset更新してくれないやんけ､ということで↓をやりたい｡

DependabotがGemfile{,.lock}更新のPRが出たら
PRにhookして
1. gemset.nixを更新して
2. PR branchにpushする

2. hook やりかた

DependabotのPRがどういう挙動をするかを確認する｡例えばこのPR:

Bump nokogiri from 1.18.2 to 1.18.3 by dependabot[bot] · Pull Request #65 · Nymphium/nymphium.github.io

Bumps nokogiri from 1.18.2 to 1.18.3.Release notesSourced from nokogiri's releases.v1.18.3 / 2025-02-18Security[CRuby] Vendored libxml2 is updated to v2.13.6 to address CVE-2025-249...

dependabot[bot]というユーザがPRを作り¹
dependencies ruby というラベルをつける

ふむ｡ PRにラベルがついたときにGitHub Actionsを発火させられるので､それをやるとよい｡

.github/workflows/dependabot-hook.yml

on: 
  pull_request:
    types: [labeled]

ちょっと丁寧に､dependabotというユーザがdependencies ruby ラベルをつけたときに絞る｡

.github/workflows/dependabot-hook.yml

jobs:
  hook:
    if: |
        github.event.label.name == 'dependencies' &&
        github.event.label.name == 'ruby' &&
        github.actor == 'dependabot[bot]'
    runs-on: ubuntu-latest
    steps:
      - ...

ruby以外にもhookしたい環境がある場合便利ですな｡

3. やるだけ

あとはやるだけ｡ bundixでgemsetを更新し､PR branchにcommit & pushする｡

.github/workflows/dependabot-hook.yml

- run: nix run '.#patched-bundix' # gmsetを更新
- run: |
    git config --global user.name 'github-actions[bot]'
    git config --global user.email 'github-actions[bot]@users.noreply.github.com'
    git commit --all -m "Update gemset.nix via bundix" || echo "No changes to commit"
    git fetch origin
    git rebase origin/${{ github.event.pull_request.head.ref }} || git merge origin/${{ github.event.pull_request.head.ref }}
    git push "https://${GITHUB_ACTOR}:${{ secrets.GITHUB_TOKEN }}@github.com/${GITHUB_REPOSITORY}.git" ${{ github.event.pull_request.head.ref }}:refs/heads/${{ github.event.pull_request.head.ref }}

ユーザ名とemailは適当で良いが､無いとcommitできないので設定しておく｡ ${GITHUB_ACTOR} は自動で設定されており､PRのauthorに同じ dependabot[bot]｡ ${{ secrets.GITHUB_TOKEN }} もGithub Actionsで自動で発行されるトークンで､リポジトリに閉じた権限で使える｡

こういう賢いactionsを使ってもいいかもしれない｡

GitHub Push - GitHub Marketplace

Pushing to GitHub repository local changes

PRに書き込むために､permissionを設定する必要があるので､やる

.github/workflows/dependabot-hook.yml

permissions:
  contents: write
  actions: write
  pull-requests: write

なんか多くね? まあ一旦ええか､一旦…｡

これでPRにhookして自動でgemsetが更新される｡

Bump nokogiri from 1.18.3 to 1.18.4 by dependabot[bot] · Pull Request #74 · Nymphium/nymphium.github.io

Bumps nokogiri from 1.18.3 to 1.18.4.Release notesSourced from nokogiri's releases.v1.18.4 / 2025-03-14Security[CRuby] Vendored libxslt is updated to v1.1.43 to address CVE-2025-248...

ええな｡

4. おわりに

Dependabotがhookサポートしてくれねえかな…｡

この記事は業務時間中に書かれた｡株式会社eiiconではCIとNixのノウハウが豊富な人材を募集しています｡

本記事で使われたテクニックはプロダクトの開発でも利用されている｡

commitを見るとユーザ名がわかる｡彼の本名は dependabot[bot] ↩

lilyum ensemble

【転職】回帰､いや凱旋【#PR】

"シェルスクリプトの依存関係､ちゃんと把握してますか? depextifyを作った"までAIに書かせる

DarwinホストでNixでDocker imageをビルド､するんだぜ

依存関係をエフェクトで文脈に持ち上げる

アプリケーションの階層を再考し､

特に旬とかではないベストテン

OCaml 5.4のlabeled tuples調査隊 ～名前の力を感じろ～

関数型まつり2025ありがとう､そして補足

キーボードアルティメイタム 第2話 Corne V4 Chocolate

DependabotのPRにフックして追いcommitする

OCaml 5.4のlabeled tuples調査隊～名前の力を感じろ～

キーボードアルティメイタム第2話 Corne V4 Chocolate