MURAOKA Taro✅ @koron@mstdn.jp

|ω・`）ﾁﾗｯ

twitter 投稿で500か… そして status.twitter.com には何も変化がない。

ヤヴェwww リアルでむせこんだ ＜鉄ヲタ長男の姿にダブる

松尾さんだw

やっぱじっくり文章を書いたほうが良い人だなw

うーんw これは見てるのツライなw

やっぱsidekiqみたいなバックグラウンドジョブマネージャーをキューに流用していることがそもそもの問題ではなかろうか。クラウドでの利用を想定したkafkaやkinesisのようなキューをジョブマネージャーに流用すれば詰まる問題はそこそこいけそうな気がしてきた。

メッセージをまとめるのは、それとは独立して必要だとは思う。

なんかトゥートするたびにアンフォロー&フォローするボットがいるのか?

やっぱキューなんだから、最終的にkinesisとかkafkaみたいな構造にならざるを得ないんじゃないか? 1つのキューでやるんじゃなくて、送り先ごとのキューができて上限が決められ溢れたら古いのから消える。

インスタンス間で調停のためのメッセージをやり取りするようになると、それはインスタンスが増えた際の死に繋がるから取るべきではないだろうなぁ。

流量が多いとか、直近で不達が出たインスタンスのメッセージを貯めてまとめて、送りつける。不達に関しては遅らせるか、ほんとうなら向こうに取りに越させたいよなぁ。

送るメッセージをインスタンス毎にまとめるとして…そうかひとつには流量の多いインスタンスだけためる仕組みを別途用意するのかね。

キューをさばくところはsidekiqで別プロセスだから、nodejsかgolangに変わる分には管理の手間は大きくは変わらんだろう。問題は変えたところで今のpushのしかたでは、そう遠くないところで限界がくるってところだろう。

pawooのTLが非常に良いな。作家さんの絵が高頻度で流れて、キレイだし、エロ絵はほぼほぼNSFWになってるし。

マストドンの異なるインスタンスで同じ人をフォローする愚を、是正していくことにした。

PHPに限らんよなぁ。雰囲気で使ってる機能やライブラリ、フレームワークを詳細に知らないと、ホントの意味での保守性や安全性には繋がらないんだよなぁ。

「このフーレムワークに乗ってるから安全です」ってのは、対価を得るに値しない。というよりはそれ自体がリスクファクター。「このフレームワークはこういう手法で安全を担保してます」とまで言えれば良い。