xanac🐱nere9 @[email protected]

ハナガサクラゲ（穴あいてないほう）のタテヨコ踊り
クラゲがタテヨコタテヨコ踊るのってべつに珍しくないけど

I wrote some thoughts about the first year of Masto.host https://masto.host/masto-host-year-one/

あーーー

形から入るなら難易度を地平に近づくほど下げて影響範囲を自分から半径1mに留めるのがぼくの考え。結局は続けられるか（＝マストドンで言えば保守、拡張ができるか）なので、難易度は少しずつ上げていくと良い

僕も今夏からマストドン立ち上げ作業に入る予定だけど、最初のうちは怖くてお客さん入れらんないよ。人のSNS人生殺すかもだもの。

必ずバックアップ取れと言っているのはそういうわけですね >BT

一回非エンジニア業な鯖缶の方々はやっていただけると安心できるのが、「DBのバックアップとって他のDBにまるごとinsertして正常に動くかやってみる」というものです。

言葉だけ見ると2ステップでいけそうですが罠があります。自動採番IDがぶつかって不完全なデータが起きたりするかもしれない。（トランザクションの概念を知っていればここでロールバックなどを適用できる）。カラムが不一致でデータが入らない、など。

とにかくDo it. Outputで優勝せえへん？

私は自分とこに fork したリポジトリに対し、手元で本家をマージしたものを上げ、サーバー側でのコードの書き換えはそれを git pull するだけにしています。

Dockerコンテナの持ってるデータ何か永続化したかったら、ホスト側のボリュームマウントするとかなんとかしないといけないのはその通り

Mastodon、デフォルトのdocker-compose.ymlが永続化しないやつなんで、わりと百戦錬磨な感じのエンジニアでもうっかりそのまま立ち上げて、うわ迂闊に落とせねえ！ ってなってるの見た。（そして百戦錬磨なひとはまずデータバックアップしてから落としてdocker-compose変更してた

Mastodon のリポジトリを GitHub の自分ところに fork して運用する人にもっと増えてほしいな、と思ったり。
変更箇所の開示請求された時焦らないためにも、変更点のバックアップのためにも、後から自身で見直すためにも。

サーバーが起きてる時の状況は誰でもイケイケドンドンできるのだけど、真価が問われるのは落ちたとき、あるいは落としたとき。

人と交流し招き入れる前にお家が保守可能であることはしっかり点検しなきゃね。当たり前だのクラッカーな話なんですけども。

（ITエンジニア、これに限らず保守フェーズを軽視してぶっちぎって開発が行き詰まることままあるのが、なんていうか人間の性なんでしょうかね。）