自分用に作ったブログシステム、自分だけだしなとおもって git で markdown 管理して github に push したら github actions でビルドして展開する、みたいなことやってるけど、複数台あってコンフリクトあってもなんだかんだ対処はできる。というかそもそもコンフリクトが発生しないようなフローでだいたい作業をする。チーム開発でのなんとかフローとかも、競合を避けるやり方が基本にある。 CMSでもサーバーでソフトウェア動かさなくていいメリットがかなりあるなとおもんだけど、他方で、この仕組みで複数人が一つのレポジトリを編集するというのを考えると、コンフリクトどうすんのみたいなのがある。 とはいえ、まあなんだかんだ言って人間は分散システムにおける競合問題をワークフローによって避けることができるわけなので、解決できない問題ではない気がする。「複数台マシンにおける同期」という問題のたてかたが間違っているのであって。いやあるていど同期は必要なんだけど。
@tenjuu99@hollo.tenjuu.net
1 reply
@tenjuu99@hollo.tenjuu.net · Reply to tenjuu99(天重誠二)
認知上の問題としては、一つのページが下書き・公開・編集あり(リモートとの差分あり)・非公開・削除、などの状態をとるのだが、分散システム上でこれらの概念を考えると、以外と概念と技術の間に溝がある。というか、いくつかの仕方での実現が考えられ、概念と技術のあいだの溝を埋めたてておく必要がある。「公開」だけは、一つのウェブサーバーにたいする資材の配置であるわけで、「正しい状態」はある程度あるんだけど、情報のフローがローカル→リモート(下書きから公開へ)とリモート→ローカル(自分が遅れている場合にリモートを正とする)どっちもある。single source of truth が成立しないからややこしく「一つのページ」という認知と分散的状態の間に溝がある。サーバーソフトウェアだとこれがないのはあきらかなメリット。