インストールという単位がない — 直せば次の接続でもう変わっている

前の一編で装置が自分の画面を渡すと書いた。この一編は、その画面がどうやって届くかだ。

この構造のいちばん静かな違いがここにある。

アプリの世界での配布の単位

インストールされるソフトウェアの世界では配布の単位がバイナリだ。

画面の文言をひとつ直しても手順は同じである。コードを直し、ビルドし、署名し、上げ、審査を受け、利用者の端末がダウンロードする。だから「その一行だけ直してください」が数日仕事になる。

これは誰の怠慢でもなく、単位の問題だ。配布されるものが端末の中にインストールされる物なので、その物を丸ごと作り直して丸ごと送り直す以外に方法がない。

ほとんど空のスチール棚

この構造では配布の単位が接続のときに渡される文書だ。

装置が自分の画面を記述として持っていて、クライアントがつなぐときにそれを受け取る。だから記述を直せば次の接続でもうその画面である。あいだにビルドがなく、署名がなく、ダウンロードがない。

この雑誌に無人店舗を扱ったサンプルがある。アプリはフォルダひとつで、ビルド成果物がない。画面を直して開き直せばその画面だ — 検証に編集の前後、二枚が並んで残っている。前の一枚と後の一枚のあいだにビルドがない。

ここが「囲いと土地」とつながる場所だ。

インストールがあれば、そのインストールを管理する席ができる。何がインストールされてよいかを決める側、審査する側、取り分を決める側。その席があるから囲いが成り立つ。

インストールがなければ、その席もできない。装置をつくった側が自分の画面を自分で決め、その画面は自分の装置につないだ人にだけ行く。あいだに入る席が構造的に生まれない。

便利さの問題ではなく、誰を経由するかの問題だ。

ここで原文を手で直す場面を見せるのは正直ではない。記述を手で直せることと、それが実用的な作成方法であることは別の話だ。実際にはツールの中でつくり、つなぎ、確かめる。

だからこの一編が見せるのは結果だ。直した、開き直した、変わっている。あいだに何がなかったかが要点である。

同じサンプルでログと絵が食い違ったことがある。ログには在庫不足が三点と出ているのに、キャプチャには「不足なし」が出ていた。

原因は、画面を移ると新しい画面が自分の初期状態から始まることだった。前の画面が持っていたデータがついてこない。ログはサーバー側の事実を記録し、画面は自分の事実を描いていたので、どちらも嘘ではなかった。

直したあと、検証に規則をひとつ入れた — ログとキャプチャの時点が合っているかを検査する。画面を移った次の行にその値がなければ通らない。

「画面がサーバーについてくる」はこう食い違うことがあり、目だけで探すと見落とす。