文脈の続き方が三種類ある。
(1) スクリプト実行環境が継続的に動いてる間
(2) 実行環境を止めてはいないが、計算機本体のスリープなどで処理がお預けになった時
(3) 実行環境を止めてから再び起動するまで
項目 (3) における状態の引き継ぎは、サーバーに情報を保存するようにしたい。「ここまで読んだ」という情報は、非公開投稿にメモするのがいいかも。ブックマークで表そうかとも思ったけど、対象が削除された場合などを考えると複雑だし。
文脈の続き方が三種類ある。
(1) スクリプト実行環境が継続的に動いてる間
(2) 実行環境を止めてはいないが、計算機本体のスリープなどで処理がお預けになった時
(3) 実行環境を止めてから再び起動するまで
項目 (3) における状態の引き継ぎは、サーバーに情報を保存するようにしたい。「ここまで読んだ」という情報は、非公開投稿にメモするのがいいかも。ブックマークで表そうかとも思ったけど、対象が削除された場合などを考えると複雑だし。
稼働している間、つまり (1) は、例えば五分などの間隔で情報を取得して、次の処理を行う。
・ フォロー一覧をフォロワー一覧に一致させる
・ ホームタイムラインなどを読んでブーストすべき投稿を抽出し、ブーストする
・ どこまで済んだか記録する
これを一度に一斉に行いたくないので、実行環境において「このあと送信する要求のリスト」に積み上げる。順に完了を確認しながら五秒間隔とかで送信する。仮に (2) の中断があった場合は再開後に続きが送信される。
リスト上の要求が片付いてから、状態のメモを更新する。リストの途中で項目 (3) の中断があった場合に巻き戻るけど、再開後に同じ処理をしようとして、ブースト済みならスキップする事にすればいいだろう。多分。
必要な要求は…この辺りか。
フォロワー一覧を見る
GET /api/v1/accounts/[ID]/followers
フォロー一覧を見る
GET /api/v1/accounts/[ID]/following
フォローを解除する
POST /api/v1/accounts/[ID]/unfollow
フォローする
POST /api/v1/accounts/[ID]/follow
タイムラインを見る
GET /api/v1/timelines/home
GET /api/v1/timelines/tag/[タグ]
ブーストする
POST /api/v1/statuses/[ID]/reblog
投稿する
POST /api/v1/statuses
投稿を削除する
DELETE /api/v1/statuses/[ID]
加筆編集の方がいいかしら
PUT /api/v1/statuses/[ID]
昨夜は JavaScript の Promise と async・await について大体学びました。
フォロー一覧とフォロワー一覧を並列に要求する事もできるだろうけど、どうせ同じサーバーに問い合わせるんだし、直列的な書き方でいいやと思った。
非公開投稿に状態のメモを書く件は、加筆編集を使えば参照が楽そうだけど、無駄に編集履歴が残ってしまうのが気になる。仮に五分間隔で書き替えたら、24 時間で 288 件の履歴になる。それに対して毎回消す方法ならデータベースの中身は定期的に掃除されるだろう。まあ大したデータ量ではないし、動くだろうけど…。
自己紹介の領域を使おうかしら。自己紹介の本文に書き込むのはあまり美しくない。補足情報欄を使うのはマシ。ウエブ画面だと他人に対しては非公開のメモ欄があるけど、あれって自分自身にも使えるのかしら。後で試そうか。
仮に任天堂が ap.nintendo.com というサーバーを立てて、ゲーム関係の公式情報を日本語と英語で #Fediverse に流し始めたら、それは世界中のサーバーから一気にリモートフォローされて、大量の配信を捌〔さば〕かないといけない。それをうまく処理できる方法は定着してる ? 私はよく知らない。
そういった場合、配信先リモートサーバーが極めて多いけど、自社の公式アカウントだけなら投稿数は僅かなので、掛け算したら大した事なかったりするかしら。
マスコどんに予備アカウントを作ってみました(@sayunu@mascodon.jp)。互いに独立したサーバーでありつつ「協力関係」なら、片方が落ちた時にもう片方に退避するという使い方をすると合理的なので。
普段は多分使わないから、そこにアカウントがあると覚えてればフォローしなくていいと思います。してもいいです。
一般利用者としてマスコどんの中を覗く目的もあり。
もふけものが落ちた場合を想定するなら、もふけもの利用者は各自 好きなサーバーに予備アカウントを確保し、そっちから @sayunu@mascodon.jp をフォローしておくと筋が通る。緊急時連絡網。
Masto.host の公式アカウントも https://mastodon.social に在って、自己ホストではないというのが障害発生時に意味を持つよね。
「予備アカウントを確保するといい」というのは、もふけものだけでなく全てのサーバーの利用者について言っています。あらゆるサーバーは一時的に止まるから、止まった時を想定して予め退避先を決めておくといいです。勿論、もふけものでも受け入れます。
まあ「あれー、なんか繋がらないなー」と思って首をかしげながら応答を待つのが嫌でなければ、避難所は別に要らないけど。
どっちかというと、利用者が予備アカウントを持つ事より、サーバー管理者が緊急時の発信経路を(自己ホストの外に)持つのが大事だよな。
少しカビたカレーを食べてる。油断した。おいしい。お腹痛くならないといいけど。
カビたカレーを食べた人は、無事でした。
@noellabo 「Fedibird でやってみた」ってできるの面白いですね !
@noellabo 加筆編集された投稿は画面上で再表示されるから、同じ形で通知できないんですかね…。中身の事情は知らないけど、半端な状態で表示されたままなのは「自分が何を投稿したのか見えない」という事で かなり体験が悪く、最終的に改善されてほしい。
#Mastodon v4.1.2 が新規投稿に含まれる URL のカードを即座にリモートに取りに行かない件は、それ自体の問題ではなくて、取って来たのを画面にすぐ反映してくれないのがいけないのかも。何か別の理由で当該投稿の情報が再取得された時にカードが表示される。
例えば、ツイートの URL を含む投稿をして、ホームタイムラインに挿入されたのをずっと見ていると、何分経ってもカードは出ない。そのあと多カラム構成の別カラムでローカルタイムラインを表示すると、取得済みのカードが両方のカラムに表示される(そこでようやくホームの内容が更新される)。
@noellabo @cojohne 登録日時は管理画面では多分 分からないなあ。この鯛焼きは今年三月頃に登録されたという事かしら ? 意外と新しいですね。
@noellabo @cojohne その投稿はもふけものにはキャッシュされていないみたい…Fedibird にフォロワーがいるから受け取ったようですね。全検索して初出を探せるんです ?
言葉と文字とヨッシーアイランドが好き。#たまごっち や #ここたま のアニメを見ます。たまに #絵 を描きます。#フォント(#書体)を作ったりします。2023 年 1 月から、https://mofu.kemo.no の副管理人です。(いきなり権限を付与されたけど受け入れました。)よろしくお願いします :mastodance:日本語の研究で博士号を持ってるらしいけど、離れて長いし、自信ない。キーボードは新 JIS‐配列(#JISX6004)微改変版です。ソーシャルメディアのアカウントのうち、ここが常駐場所です。さゆぬの活動は大体ここに集約されます。今のプロフィール画像は『ヒミツのここたま』のミシルの絵です(二次創作)。全ての絵を見るにはこちら :https://mofu.kemo.no/@sayunu/tagged/%E7%B5%B5ここたまに興味がある人は、ここたまアンテナ(@cocotama_antenna)をフォローして
076萌SNS is a social network, courtesy of 076. It runs on GNU social, version 2.0.2-beta0, available under the GNU Affero General Public License.
All 076萌SNS content and data are available under the Creative Commons Attribution 3.0 license.