Python と JSON を分離し、C# に移行し、GitHub Pages で公開するまで
対象リポジトリ
https://github.com/Nishiwaki-Takao/VolumetricGlassware-Schemas/
前回の記事では、
「計量器具（Volumetric Glassware）をコードで扱うことの違和感」から出発し、
Python で構造を定義し始めたところまでを書いた。
今回はその続きとして、
- なぜ Python と JSON を分離する判断に至ったのか
- なぜ 言語を C# に切り替えたのか
- なぜ GitHub.io（GitHub Pages）で JSON を公開する形にしたのか
を整理して書いておく。
なぜ Python と JSON を分離したのか
最初は Python で、
- 容量
- 許容差
- 規格（JIS / ISO）
- クラス（A / B）
といった情報をクラスや辞書で管理していた。
しかし作業を進めるにつれ、次の問題が顕在化した。
- 「コードが真実」になってしまう
- Python が読めない人にとって中身が見えない
- 計量値そのものが「実装詳細」に埋もれる
これは計量・規格の世界では致命的だ。
数値はコードの都合で変わってはならない
数値の意味は、実装よりも上位にあるべき
そう考えた結果、
「JSON を一次情報（Single Source of Truth）にする」
という方針に切り替えた。
Python（あるいは任意の言語）は
- JSON を読む側
- JSON を解釈する側
に退くべきだと判断した。
なぜ C# にしたのか
JSON を一次情報にした時点で、
言語に求める役割は明確になる。
- 厳密な型
- 不変性（immutability）
- 値オブジェクト（Value Object）
- 単位の明示
この点で、C# は非常に都合が良かった。
-
recordによる不変オブジェクト -
decimalによる計量向き数値 - JSON Schema との相性
- EF Core や MES/LIMS との親和性
特に重要なのは、
「数値を扱うこと」と「業務で使われること」
の距離が短い点だ。
研究用スクリプトではなく、
工場・品質管理・データベースに流れる前提で考えると、
C# は自然な選択だった。
なぜ GitHub Pages で JSON を公開したのか
JSON を一次情報にする以上、
- 誰でも見られる
- バージョン管理されている
- URL で参照できる
必要がある。
そこで選んだのが GitHub Pages だった。
- リポジトリ＝履歴
- タグ＝バージョン
- URL＝規格参照点
結果として、
https://nishiwaki-takao.github.io/VolumetricGlassware-Schemas/
https://nishiwaki-takao.github.io/VolumetricGlassware-Schemas/burette/
という形で、
- 計量器具の定義
- 容量と許容差
- 規格の違い
を 言語非依存で公開できるようになった。
これは API というより、
「計量器具のデータ規格書を、Web に置いた」
という感覚に近い。
JSON を「コードの下請け」にしない
この構成で一番大きかったのは、
- JSON がコードに従属しない
- 実装言語を変えても壊れない
- 将来、別言語・別システムでも使える
という点だ。
Python → C# に移行しても、
JSON は一切変更しなくてよい。
これは計量・規格の世界では重要で、
人が変わっても
言語が変わっても
数値は変わらない
という前提を守れる。
おわりに
今回やったことをまとめると、
- JSON を一次情報に格上げ
- コードは解釈者に徹する
- 公開可能な形で規格を置く
という、かなり地味だが強い設計に落ち着いた。
次は、
- 希釈工程をC# の Value Object にどう落とすか
あたりを書こうと思う。