創刊Volと最初のハードウェア実証が出たあとの一週間。Signalの質感が少し変わった — 以前が「それはできるのか」だったとすれば、今週は「ではうちの場合は?」が多かった。
今週のSignal
「うちの業種でもできるのか」が入り始めた。 パネル業者がHMIを30分で載せた記事のあと、最も多かった反応は称賛ではなく当てはめだった。「うちは計測器だが」「うちはセンサーモジュールだが」「うちはキオスクだが — 同じようにできるのか?」良いSignalだ。実証の目的は感嘆ではなく、相手に「自分の場合に置き換えて考えさせること」だから。この連載が業種を一つずつ増やしていく理由でもある。
最初の画面を立ち上げた人が出てきた。 コーディング記事に沿って画面を一つ立ち上げてみた読者からの短い感想が届く。共通点が印象的だ — ほぼ全員が「ビルドを待つ段階が無いのが一番慣れなかった」と言う。馴染んだコストが消えると、その空白がかえってぎこちなく感じられる。そのぎこちなさが、この転換の最も正直な証拠だ。
「サーバーが画面を定義すると遅くないか」という誤解。 今週最も多く訂正した誤解だ。毎瞬サーバーを呼ぶという図から来た心配だが、実際には画面の定義だけが行き来する — 重いコードバンドルではなく、「ボタン一つ、テキスト一つ」の軽い仕様だ。しかも一度受け取った定義はキャッシュされる。本当に重い描画エンジンは、すでに端末にネイティブで在る。体感性能はネイティブそのままだ。
ツール・パッケージ・メモ
今週のメモは状態について。画面に値を結ぶとき、初心者が最も詰まる場所は「値が変わったのに画面が変わらない」だ。原因はほぼ常に同じ — 画面を直接いじろうとしたからだ。サーバー定義方式では画面をいじるのではなく、状態をいじる。状態が変われば、それに結ばれた場所がひとりでに従う。「描き直せ」とは命じない。このVolのコーディング二本目がまさにこの点を扱う。
短い考え
「30分」という数字について。その数字の半分以上は、ビルドを待たなくてよかったから生まれた余裕だ。私たちが気軽に「開発時間」と呼ぶものの相当部分は、実は待つ時間だ — コンパイル、焼き込み、審査、配信。作る行為そのものではなく、作ったものが届くのを待つ時間。その待ちがゼロに近づくと、同じ人が同じ手でずっと遠くまで行く。速くなったのはタイピング速度ではなく、試すと確かめるの間の呼吸だ。
現場から
ある読者が送ってくれた一行が長く残った。「ボタンの色を変えて保存したら、別の部屋にあったタブレットの画面がただ変わっていた。何もしていないのに。」この雑誌が長々と説明したことを、彼は一文で要約した。
今週の問い
あなたの仕事で「一度作れば終わり」ではなく「ずっと手を入れ続ける」画面はどれだろう。価格表、メニュー、状態ボード、設定画面のように、よく変わるもの。そういう場所ほど、焼かずに定義する方式の利得が大きい。来週は、その「よく変わる画面」を扱うドメイン事例を取り上げる。
makemind.dev 「更新」— 1月第3週。「うちの業種でも動くのか」という問いに数字で答える。