ログボ
nostr:npub1ts6dztzg4n8x0cunsvskdef4qv4y2h6k930as6xplt4ydz43usgqc2gmav 前には進めるけど、後戻りはできないよ、って警告されてるね！
#fedibird いまのところ弱点としては、そのまま使えば良くて便利すぎるので、個人間のフォローなどにあまり繋がっていない様子なのがあります。まあそこはLTLと同じですね。
#fedibird ちょっといま、検索インデックスが構築中で当時の投稿を掘り出せないのですが、
#fedibird タグをどう使えばいいか、という話はいろいろと議論があり、その中で、いまのような流れができた経緯があります。
もともとほとんど私がサーバーインフォメーション的にしか使ってこなかったので、そういう認識の人も多かったのですが、
初期の頃から、自己紹介や共有したいことを投稿するのに使うといいよ、ということもお勧めしてきていて、
ある時期に使われる機会がぐっと増えてから、使われ方が一変しました。
現在ではホテルのラウンジやカフェテリアのような共有スペースになっている感じです。たまにやってきてくつろげる場所なのかなと思います。
あまり干渉せず、楽しそうなら集まってくるし、雰囲気が悪くなれば自然に散っていく、という感じでしょうか。
なおインフォメーションはそういった経緯から #fedibird_info というハッシュタグをつけることにしていますので、その用途にはそちらをフォローしてください。
#fedibird このハッシュタグは、狭い意味でいえば、fedibird.comとnightly.fedibird.comのための共通タグですが、
Fedibirdに縁のある方（個人サーバに独立されたとか、最近別サーバメインだがFedibirdも長い方とか）も普通に使われていますし、どこの方でも、Fedibirdってどんなサーバ？ みたいな質問を投げるにも便利ですので、
上手に活用いただければと思います。
フォローエクスポートすると、 @ 〜 @ 〜 形式のacctがずらっと並んでいるでしょう？
面白そうなので、私もなんか言っておこう
「当社が発表したものではありません」
店内（店員同士）ではなんて呼ばれるんだろう、ガーリックシュリンプ
変なインセンティブ設計するとダメになるよ。ホントに。
nostr:npub1hqqwkgtj5jdzktlqyn9zae7kgp29hpd403zef5s3nep2p6u26a3qz0ml3g blobcat系も、各所でオリジナルバリエーションが増えててそれぞれ権利主張があって制限事項などが増えていたりするので、もうなんとも。
統一された権利確認手段がないというのがシステム上の問題点で、運用だけで対応するの無理なところに来てるね。
ジョブは短時間で実行できる単位に分割します。
そうしないと、ひとつのジョブが長時間占有しつづけることとなり、効率良く他のジョブを同時実行できなくなります。
また、ある処理を実行しているうちに、他の処理の影響で実行に失敗することも起きます。
たとえば、お気に入りしようとした投稿が、何かの都合でもう削除されているかもしれません。
ひとつのジョブが大きすぎると、こういう状況の変化に対応するのが難しくなります。
--
さて、リモートから誰かの投稿がやってきました。
この投稿者をこのサーバでは100人がフォローしているので、100人のタイムラインに投稿を流さねばなりません。
この時まず、リモートサーバから来たActivityの内容を確認するワーカーを実行します。投稿者Aの新規投稿であると解析されました。
次に、この投稿を各タイムラインに配送するワーカーを実行します。
やることの多いワーカーですが、公開範囲を確認し、公開タイムライン（連合、ハッシュタグなど）に流す処理、フォロワーのホームやリストに流す処理を行います。
このうち、フォロワーは人数が多いので、一人ずつのホームとリストそれぞれで100以上のワーカーに分割して走らせます。
難しいかと思いますが、なんとなくイメージできますでしょうか？
Sidekiqによる、細分化されたワーカーを実行する仕組みは、ジョブの失敗をリカバリーすることに対しても強みを発揮しています。
あるサーバがメンテナンス中で接続できなかった場合、そのサーバに投稿を配送しようとすると失敗します。
このとき、投稿の配送をひとかたまりの処理として一回で実行するようになっていると、その時に繋がらないサーバにはもう配送するチャンスがなく、ダメだったら無視されてしまいます。
Sidekiqを使った仕組みでは、失敗したジョブだけを再実行することができます。
しかも、すぐにやり直しても失敗するので、失敗したら少しずつ間隔をあけていきます。
3時間後につながらなかったら、半日後にもう一回試す、というように、相手側が復旧するかもしれない時間を待つようにつくられています。
これにより、復旧したサーバにも配送が届くようになります。
あまりにも長くつながらなかったら、最後には諦めるようになっています。
連合を柔軟に運用できるようにするための、重要な仕組みです。
nostr:npub1tqujwvqa3s6uvqy5dryxqyu2gwrg7cuqzpyluhel99g92kpgqq4qyftmnr 自由な入力を許しちゃうので、たとえば https: から書いてるとか、あと fedibird.com って書いてるとか！ #fedibird
Mastodonのように、たくさんのユーザーがいて、利用者が同時に使用していることが多く、短い投稿やそれに対する返信、リアクションなどが行われ、タイムラインに次々と新着投稿が流れるようなシステムは、
そのひとつひとつの処理（ジョブ）を実行するワーカーに分割し、必要に応じて順次処理していくことで、ユーザーの操作に素早く応答して結果を返し、たくさんの人が同時に利用してもスムースに流れるように工夫されています。
各サーバーは通常、このワーカーを遅滞なく実行できるだけのハードウェアを準備しているのですが、急激に投稿が増えたり、利用者が増えたりすると、処理能力が追いつかなくなります。（※ いつも処理能力不足のサーバもあります）
ワーカーは、処理が追いつかない場合、順番待ちの列を作って自分の番が来るのを待ちます。
列が長くなってくると、処理が完了するまで5分待つとか、20分待つといった状況になります。
そうすると、タイムラインに流れてくる最新情報が20分前だったり、お気に入りがなかなか反映されない、といったことが起きるわけです。
Mastodonでは :sidekiq: Sidekiqと呼ばれるバックグラウンドジョブ処理システムを使っているので、『Sidekiqが遅延してる』などという言い方をします。
nostr:npub1fhfzyr5ynxry0j8u6r8k0ug2cmzsnkzl66jl6rq926xymvq8jvsqdekl7p エンカウント率が上昇してる。間違いない。
nostr:npub1fhfzyr5ynxry0j8u6r8k0ug2cmzsnkzl66jl6rq926xymvq8jvsqdekl7p Jujaは普通にエリックサウス行けばよろし
同人誌はフリートークが味わい深い（大好き）