00:42:36
icon

韓国がどうかなってると言うから軍事境界線を侵攻でもしたかと思った。そこまで重大ではなさそう。(よく見てない)

00:47:18
icon

ボンヤリした事を書くけど、敵対的な国と陸の国境を接しているのは、心配が絶えないだろうなあと韓国に対して思っています。

00:52:09
icon

@ksnk あたしアンテナを立ててないので、騒いでるかどうかは見に行かないと分かんないんですよね。基本的は国内政治の話だと理解しました。

01:26:45
2024-12-04 01:03:29 Masto.hostの投稿 mastohost@mastodon.social
icon

このアカウントは、notestockで公開設定になっていません。

01:35:35
icon

「もふけもの。」に Mastodon の更新 v4.3.2 が適用されました。気付きやすい変更点として、内容警告文の体裁が変わりました。

01:36:14
icon

内容警告文の、例の警告色の縞々が撤去された。カスタムスタイルシートで潰そうかと思っていたけど、モタモタしてるうちに終わった。これについての議論はここで行われていたみたい。
github.com/mastodon/mastodon/i

Web site image
Revert: #31365 · Issue #32352 · mastodon/mastodon
02:21:03
icon

新紙幣は今後珍しくないから、取っておく必要はないと思ったけど、常時手元に揃ってるとも限らないし、綺麗な状態とも限らない。まだ新品ばかりの今のうちに、くたびれてない物を観察用に採取しておく事にしました。それで財布を見ると、「AB714309WG」と「AB714311WG」というほぼ連番の千円札がある。つまり刷られて市中に出たばかりだ。いつも ATM で下ろすのは一万円札だから、どこかのお店がお釣りとして用意した束から貰ったんだろう。もしかすると私が気にしないで間を使っちゃったのかも知れない。

みんなが「A」で始まるのは今だけですからね。「AA」を見た時に確保しておいたらよかったかしら。まだ機会はあると思うけど。

Attach image
02:24:25
icon

製造された時は隣り合っていた連番のお札が、出回ると配列を崩されて、一度離れたら二度と出会わない。

02:39:29
icon

そんな所に珍しさが発生するならシャッフルしてから出荷されればよかった ! 何この「出会わなければよかった」みたいな :84_frog_hmm:

02:57:47
icon

ちょっと本当誰か Crowdin にアカウント作って和訳に投票して…。改善提案が機能してないぢゃん。

03:08:31
icon

何で「ねてない」の英訳が「light sleeper (species of sleeper goby, Odontobutis obscura)」になるのだ :bunhd_googly: DeepL による翻訳は大体まともそうな(少なくとも表面的に整った感じの)物が出力されていて、こんな露骨に壊れてるのは珍しい感じがする。

Attach image
07:32:27
icon

だなあ。

11:43:14
icon

概念的には、毎日何か書きたくなるような動機付けから、毎週、毎月、四半期毎ぐらいの周期を持つ催しまで考えられる。動機付けによる投稿が同じような物ばかりにならず、やってて飽きにくく、あまり尖った能力を求めず(画力次第とかではなく)、運営しやすい(私が常に頑張って維持する必要がない)のが理想的。一個で全部満たすのは難しい。

12:08:20
icon

通常の取り引きで、連番の紙幣は五千円札が最も手に入りにくそう。千円札と一万円札はまだある。五千円札が二枚あったら一万円だから、二枚同時に受け渡す事がほぼない。

12:38:50
icon

あまり邪魔にならないようなボットを設置するというのもある。もものと ふものがいるし…。しかし、開発しないと、ない。クラウドサーバーとかお金掛かるし :neko_roling_eyes:

icon

Mastodon で「前年の同時期にトレンド候補になったハッシュタグ」の情報が得られるといいんだけど。

docs.joinmastodon.org/methods/
「measures」の API をうまく使えば、特定のタグが特定の時期に何件使われたかは分かるのかな。それだと自前で統計を取るしかないけど…。これまでに当サーバーが観測したハッシュタグは 66 万種以上あって、絞り込む必要がある。

16:09:48
icon

Mastodon の現行版で使われている Snowflake‐形式の投稿識別子は、上の方の桁がミリ秒単位の UNIX‐時刻で、下の 16‐ビットが時刻以外の情報。時刻だけに注目するなら、一秒経過する毎に 65536000 だけ加算されてる。

「何時から何時まで」と範囲を指定してタイムラインを取得したい場合に、API の説明書を信じるなら「min_id」や「max_id」などのパラメーターは境界の値を区間に含まないのがずっと気になってる。厳密に考えるなら、境界となる識別子に 1 を足したり引いたりしないといけない。

それを気にしないなら簡単なんだけど。ミリ秒単位で区間を指定する需要はないので、秒が最小単位だとすれば区切りとなる値は常に千の倍数。倍精度の浮動小数点数で雑に扱ったとしても、表現し切れない末尾は問題にならない。精度が足りないので、数値のまま 1 を足す事はできない。

本当に境界の値を含まないのかしら。影響を受けるのは、投稿がミリ秒単位で指定時刻に一致し、しかも下位 16‐ビットのハッシュ値がたまたま 0 と算出された場合だけなので観察できない。

16:22:24
icon

ミリ秒単位の区切りも 65536 の倍数だから、精度が足りなくても取り扱えそうに思えるけど、JavaScript の toString が十進法の表示を作る時に「0」で丸めてしまうようなので、安易な処理では厳密に正しい値を API に渡せない…多分。

16:29:42
icon

例えば 2024/12/4(長さ 24 時間)の全ての投稿を取得したいという場合、min_id として「2024/12/4 の 0:00:00.000 でハッシュ値が 0 だった時の識別子」を指定し、max_id として「2024/12/5 の 0:00:00.000 でハッシュ値が 0 だった時の識別子」を指定するだけで済むなら簡単。しかし区間が境界を含まないんだったら この min_id は厳密には駄目で、「2024/12/3 の 23:59:59.999 でハッシュ値が 65535 だった時の識別子」を与えないと、すごい低確率で取りこぼす可能性がある。

17:04:59
icon

@noellabo 下位に 0 が出る事自体は、やっぱりあるんですね。

18:26:10
icon

「観察できない」って書いたけど、現に存在する投稿の識別子を境界として指定すれば確認できるわ。そして実際、指定した値自体は含まないという挙動を以前観察したような気がする。

ページ送りの目的では、既に受信した中での最古・最新の投稿を基準にして「これよりも前・後」を要求したいから、それ自体を含まないのが便利なんだよな。

18:42:55
icon

@tizerm 簡易ブラウザーを作った時も実際それを考慮する必要があったので…。「昨日の 0 時から 23 時 59 分まで」を取得したいといった用途では面倒な事になる。

18:52:19
icon

まあ、大人しく BigInt を使って数値を表し、1 を引くというのが正解かしら。でも BigInt が主要なブラウザーの最新版に載ったのって 2020 年か…あまり古い話ではないなあ。

19:12:44
icon

19:11:55 ぐらいから、弱い を感じました。