tenjuu99(天重誠二)

くまスプレーがお店になくて、出会ったら格闘するしかない

クマ、ウサイン・ボルトより早いらしい https://yamap.com/magazine/53229

@polidog あした曇りでしたっけ？わりとちょうど良さそうな。

git の複雑さをスマホに持ち込んでしまうのはけっこうキツいなと思った覚えがある。でもメモツールって手元で・すぐ対応したいからスマホUIがほしい。

obsidian があんまりうまくいかなかったポイント、gitをスマホで使うのが無理すぎるという点にある。データを「複数台で共有」したいとき、スマホでもデータをみたいんだけど、git の設定がうまくいかなかったり、端末買いかえたら設定するのがめんどくさすぎたりして放置してしまう。

IDの仕組みってCMSで考えたら難しくなくて、URLがあります。ファイルパスをURLにマッピングする仕組みの場合はそれをIDとして考えてもかまわないし。

git に限らず、ftp でも rsync でも分散システムなんだけど、問題の本質はプロトコルにはなさそうで、 ftp とかのほうがもっと生っぽくて git のほうが調理済みという感じはある。あとは、巻き戻しとかできるのは明確なメリットとしてはあるけど、これはプロトコルではない。

CMS領域でひそかなアナロジーとして輸入しようとしているのは「原稿」と「出版」という概念で、というかCMSで draft/publishという組は出版のアナロジーから来ているとおもう。従来の執筆活動が分散的かというとなんとも言えないが、あちこちにメモがある人のことを考えてみれば、そこまで遠い問題ではないという気はする。そして出版されたものについてはデータが複数あるということはほとんどない(たまに同一ISBNで訳が違うものがあったりとかあるけど)。

だから既存の概念にあてはめて説明しようとしてもいまいちうまくいかないので「分散システム」を見せる必要があるということかもしれない > 分散システムが「見える」ようにしたほうが良い
https://hollo.tenjuu.net/@tenjuu99/019f4ca0-afab-722f-b55c-2a4919077fc4

非技術者にも、分散システムが「見える」ようにしたほうが良い、というのが自分の結論で、というかプログラマーが git で対処できるのは分散システムが見えるように設計されているからだとおもう。

複雑さとか必要な運用コストを隠したりなかったことにしようとしてもうまくいかないという経験的な印象はある
https://mstdn.jp/@pokarim/116896121224062343

CMSの場合は結局公開されたウェブサーバーが真であるというのは変わらなくて、そこに至るプロセスに競合がありうる。対処の方法としてはロックとっておくとかがあるかなとは思う。対等なコンピュータが複数台あるわけではなく、なんらかの中央サーバーを介在してコミュケーションするから(だからリモート/ローカルの状態差分を検討することができる)、対処の仕方はあるはずだとおもう。実際にチーム開発で人間は対処しているのだし。

自動同期みたいなことを考えたのは、obsidian がそうしていたからなんだけど、obsidian を git で管理するやつ(バックグランドで自動同期)はなんだかんだ言って難しいと感じた。

僕が今作ってるエディタも同期を考えてるところ。

「それぞれの環境ごとの別リビジョンがあるという前提でサーバに一旦保存され、マージしたくなったときにはあとからやる」

みたいなのでなんとかならないか考えてるところ。一本にすることよりもとにかくバックアップすることを優先してる。

Dropbox が概念設計の失敗例、気になる。 けどわからないではなくて、いろいろ考えたけど、自動同期(git で考えればバックグラウンドで add+commit+pushとpullを繰り返す)って擬似的な single source of truth を作ることではあるけど、これが分散システムのいいところかっていうとそうでもないというか。それならサーバーソフトウェアがあったほうが整合的では？みたいなことは思う。

Dropboxは『The Essence of Software』で概念設計の代表的な失敗例としてかなり批判的に分析されてた気がする

分散システムにおいて完全な同期を期待するほうがおかしいから、分散システムで発生しうるペインをいかに隔離できるかということが問題になる。

CMSという問題領域で考えたときに、問題の複雑さを回避する手段はたぶんいくらでも考えられ、整合的なモデルを検討することができる。claude code によれば分散システム一般における同期の問題に対して正面から対応してみせたのがDropboxとかiCloudとかで、「自動同期+競合時は競合コピーを成果物として残す」みたいな単純なモデルで、これで非技術者向けにも上手く機能するなら問題ないと言える。

というかどういうモデルを採用するかによって、同じ概念に解釈の差異が発生するので、そういうのがおもしろさあるなとおもって考えている。 「公開」をローカルにあった資材をリモートに同期することと捉えることができるが、他方でローカルとリモートが一致していても「公開」は原稿をビルドしてwebサーバーに展開することだと定義してしまえば、それはそれでまた異なった世界になる(ここで「原稿」という概念が導入される)。概念の定義の仕方でソフトウェアのあり方が変わるのが、やっぱりけっこうおもしろいなとおもってしばしば考えている。

リモートとローカルの状態差分、ローカルのほうが進んでいるときは一般に「未公開状態の下書きがある」と把握されるんだけど、リモートのほうがローカルより進んでいるとき、まだダウンロードしていない差分がある、ということになる。リモートとローカルが完全に一致する状態を基準に、可能な状態差に名前を付けることがおそらくできる。コンフリクトってなんですか。

個人でブログシステムを git 管理しているとき、「下書き」ってリモートとローカルの状態差分そのものなんですよね。コミット積んでいようと積んでなかろうと、リモートとのあいだに意図的な状態差分をもたせている期間が「下書き」として扱われていると言える。これは git で考えなくてもファイル共有プロトコルが ftp だの rsync でも同様で、抽象自体はこうした技術には依存していない。

認知上の問題としては、一つのページが下書き・公開・編集あり(リモートとの差分あり)・非公開・削除、などの状態をとるのだが、分散システム上でこれらの概念を考えると、以外と概念と技術の間に溝がある。というか、いくつかの仕方での実現が考えられ、概念と技術のあいだの溝を埋めたてておく必要がある。「公開」だけは、一つのウェブサーバーにたいする資材の配置であるわけで、「正しい状態」はある程度あるんだけど、情報のフローがローカル→リモート(下書きから公開へ)とリモート→ローカル(自分が遅れている場合にリモートを正とする)どっちもある。single source of truth が成立しないからややこしく「一つのページ」という認知と分散的状態の間に溝がある。サーバーソフトウェアだとこれがないのはあきらかなメリット。

自分用に作ったブログシステム、自分だけだしなとおもって git で markdown 管理して github に push したら github actions でビルドして展開する、みたいなことやってるけど、複数台あってコンフリクトあってもなんだかんだ対処はできる。というかそもそもコンフリクトが発生しないようなフローでだいたい作業をする。チーム開発でのなんとかフローとかも、競合を避けるやり方が基本にある。 CMSでもサーバーでソフトウェア動かさなくていいメリットがかなりあるなとおもんだけど、他方で、この仕組みで複数人が一つのレポジトリを編集するというのを考えると、コンフリクトどうすんのみたいなのがある。 とはいえ、まあなんだかんだ言って人間は分散システムにおける競合問題をワークフローによって避けることができるわけなので、解決できない問題ではない気がする。「複数台マシンにおける同期」という問題のたてかたが間違っているのであって。いやあるていど同期は必要なんだけど。

分散システムのアドバイス

1. やめとけ

みたいなやつ

正しさが分散してしまうわけで、一度分断が起きると何が正しいのかについて不完全な知識に基づいて投票みたいなことが必要になってしまうという雑なイメージ

これは鉄板で難問のやつ > 分散システムにおける同期の問題

分散システムでのCMSとか考えているというか、作ってたらそうなっているんだけど、分散システムにおける同期の問題って思ったより難解だな。慣れているとコンフリクトへの対処は理解できる(むしろコンフリクトを起こさないようなワークフローを構築する)けど、そうでなければ対処が困難になってしまう。サーバーサイドDBに単一ソースが存在することのメリットは同期の困難さが無くなることにあるけど、一方で認証が必要になってしまうという問題がある。

この記事おもしろかったんだけど、ARTnews Japan のニュースレターメールにこの記事の批判が書かれていて、その批判もまあまあおもしろかったんだけど、さすがに批判するんならちゃんとURLもった記事でやってほしいわ。引用できないんだと陰口になってしまう。 https://jp.artreview.com/2026/06/29/ron-mueck/

読むの大変だけど。いや、ほんとに読むの難儀だけどいちおう。。

https://takagi-hiromitsu.jp/diary/

自由な排便行為が許されない街のほうがおかしい