装置をもうひとつ付けた — ホストは触っていない

前の二編では装置ひとつを扱った。自分の画面を渡し、その画面がインストールなしに届く。

現場に装置がひとつだけということはない。操舵室には発電機とバラストと燃料計が一緒にある。この一編は複数を一つの画面にまとめるときに何が起きるかだ。

普通はホストが結合を書く

複数の装置を一つの画面で見るには、たいていアプリがその結合をコードで持っている。どの装置のどの値をどこに置くか、そのボタンがどの装置へ行くかをアプリが知っている。

だから装置をひとつ足すたびにアプリを直す。そして組み合わせがビルド時点で固定される。現場の機器構成が変われば、アプリもまた出ることになる。

UI DSL 1.4の合成プロファイルはその結合を文書へ降ろす。ホストがやることは二つだけだ — 接続を持つこと、そして文書が名指しした相手を開くこと。結合ロジックがない。

文書にはこう書かれる。ここにこの接続が渡す画面を入れよ。あそこにあの接続が渡す画面を入れよ。

プロファイルが定める性質が四つある。

四つとも仕様に書かれている。だから画面で測った。

線を束ねた配線盤

MCPノードを三つ立てた。Boiler A、Pump B、Valve C。それぞれ自分の画面を配り、自分の値を持ち、自分の道具を出す。互いを知らない。

そして三つを一ページに置く文書をひとつ書いた。その文書には何が描かれるかは書かれていない。どの接続がどこに入るかだけが書かれている。

① 三つのタイルがそれぞれ自分の画面として描かれた。それぞれ自分の名前、自分の単位、自分の色、自分の値。アプリはそのどれも書いていない。

② タイルのボタンが自分のサーバーへだけ行った。最初のタイルのボタンを押すと最初のサーバーの値だけが動く。サーバーに直接訊いて確認した — 29→30、残り二つはそのまま。二つめを押せば二つめだけ、三つめを押せば三つめだけ。

これが合成でいちばん静かに間違いうる場所だ。画面はきちんと描かれているのにボタンが別のサーバーへ行けば、その症状は画面に出ない。

③ ひとつを落とした。二つめのノードを止めた。そのタイルだけが代替表示になり、最初のタイルは生きていた。ページも、その下の内容も描かれ続けた。四つのうち一つが消えた画面は三つが生きている画面であって、白い画面ではない。

④ 三つめを足した。文書に二か所足した — 接続ひとつ、席ひとつ。そしてホストのバイナリのハッシュを追加前後で比べた。

同じだった。リビルドがなかった。

ここは正確でなければならない。アプリを触らなかったのではない。文書には二か所増えている。装置を増やすなら、その装置をどこに置くかは誰かが言わねばならない。

変わらなかったのはホストだ。実行ファイルがそのままである。それは審査を受け直さず、配布をやり直さず、現場の機器に触れないという意味だ。

測ったのがそれなので、題もそう書いた。

この測定は一度では通らなかった。最初はタイルが二つとも代替表示で、原因を探すのに対照の行をいくつも置かねばならなかった。

その過程でこの構造側の欠陥が四つ出て、すべて直った — 接続の失敗が30秒沈黙してからタイムアウトしていたこと、存在しない道具を呼ぶと成功として返っていたこと、失敗した接続が失敗の経路で来なかったこと、そして一つのコールバックに複数の動作を掛けると黙って捨てられていたこと。

そのうち半分は、こちらの文書が契約の外だったせいで出たものだ。画面が空だった本当の理由もそちら側だった。そして存在しない道具が成功で返っていたのは、原因を探すために横に置いた対照の行ひとつがつかまえた — 誰も探していなかった欠陥である。

合成を測るために組んだ盤で、その下の層の欠陥も一緒に現れた。