猫の下僕
|ω・`)チラッ
twitter 投稿で500か… そして status.twitter.com には何も変化がない。
マストドンはこのゴールデンウィークをどう乗り切るかによって今後の日本での立ち位置が変わってくるんじゃないか。連休で忘れ去られるか、この連休を使って研究した人たちが、一斉に面白いものを出してくるか。個人的には勝算は高いと思ってるが、問題はどこまで行くか。このままTwitterのパイを奪う存在になって欲しい。
君と夏の終わり 将来の夢大きな希望 忘れないhttps://mstdn.jp/media/YvOoGLeZfv0ESIRim9M
ヤヴェwww リアルでむせこんだ <鉄ヲタ長男の姿にダブる
技術の話はよくわからないけど、楽しそうに技術の話をしている江添さんは、鉄道の話をずっと楽しそうにする鉄ヲタ中学生長男の姿にダブる。 #マストドン会議
松尾さんだw
やっぱじっくり文章を書いたほうが良い人だなw
うーんw これは見てるのツライなw
やっぱsidekiqみたいなバックグラウンドジョブマネージャーをキューに流用していることがそもそもの問題ではなかろうか。クラウドでの利用を想定したkafkaやkinesisのようなキューをジョブマネージャーに流用すれば詰まる問題はそこそこいけそうな気がしてきた。
メッセージをまとめるのは、それとは独立して必要だとは思う。
即ふぁぼするお仕事です
なんかトゥートするたびにアンフォロー&フォローするボットがいるのか?
やっぱキューなんだから、最終的にkinesisとかkafkaみたいな構造にならざるを得ないんじゃないか? 1つのキューでやるんじゃなくて、送り先ごとのキューができて上限が決められ溢れたら古いのから消える。
インスタンス間で調停のためのメッセージをやり取りするようになると、それはインスタンスが増えた際の死に繋がるから取るべきではないだろうなぁ。
流量が多いとか、直近で不達が出たインスタンスのメッセージを貯めてまとめて、送りつける。不達に関しては遅らせるか、ほんとうなら向こうに取りに越させたいよなぁ。
送るメッセージをインスタンス毎にまとめるとして…そうかひとつには流量の多いインスタンスだけためる仕組みを別途用意するのかね。
キューをさばくところはsidekiqで別プロセスだから、nodejsかgolangに変わる分には管理の手間は大きくは変わらんだろう。問題は変えたところで今のpushのしかたでは、そう遠くないところで限界がくるってところだろう。
pawooのTLが非常に良いな。作家さんの絵が高頻度で流れて、キレイだし、エロ絵はほぼほぼNSFWになってるし。
マストドンの異なるインスタンスで同じ人をフォローする愚を、是正していくことにした。
PHPに限らんよなぁ。雰囲気で使ってる機能やライブラリ、フレームワークを詳細に知らないと、ホントの意味での保守性や安全性には繋がらないんだよなぁ。
「このフーレムワークに乗ってるから安全です」ってのは、対価を得るに値しない。というよりはそれ自体がリスクファクター。「このフレームワークはこういう手法で安全を担保してます」とまで言えれば良い。
Mastodon日本鯖です. よろしくお願いいたします。 (Maintained by Sujitech, LLC)