メンタルが悪いのか体調が悪いのか分からんような状態になったので今日はお仕事はほぼお休み。刺激を減らす
このアカウントは、notestockで公開設定になっていません。
「SNSに投稿で一品サービス」が法律違反に!10月1日開始“ステマ規制”の重要点を解説 | DOL特別レポート║ダイヤモンド・オンライン
https://diamond.jp/articles/-/330140
・StableDiffusion…LAION 5B にDanbooruの画像URLがある
・WaifuDiffusion…Danbooru 2021 データセット使用を明言
・NovelAI…Danbooru利用を明言。
・ミッドジャーニー…WaifuLabsとコラボしてSafebooru由来のデータを使う(予定)
つまりみんなDanbooru使ってるやん! となります
鳥に書いたら無駄にバズったやつ
ATOK for Android(買い切り版)が2021年10月31日でサポート終了 https://www.orefolder.net/2021/10/atok-for-android-support-end/
年に数千円だしてATOKパスポートに移行したいほどでもないし、他のIMEに変えるかな…。
このアカウントは、notestockで公開設定になっていません。
へえ、楽天-KDDIローミング縮小の前倒し https://www.itmedia.co.jp/mobile/articles/2110/04/news048.html
周波数的に地下で弱いからメイン端末にするのはまだ難しいけど、競争激化のため励んでほしい
https://www.amazon.co.jp/dp/B09GKJHJYC/ ニューノーマル 11話を読んだよ
地下アイドルの恋愛禁止に関する訴訟 https://twitter.com/Anshar_hu/status/1311890713236262912 判決文が幸福を追求する自由にまで言及しててすごいな
α7Cは電子先幕シャッターをオフにできない https://tecstaff.jp/2020-09-18_ilce-7c_review.html
スチル撮るならこれは残念な仕様ですね…
(BT) iPhone SE 2, 3, 4 …と続いて10がXになるアメリカ人がよくやる命名になるのか…ダメなやつだ
iPhone SE2(仮)、2020年初頭発売?「8」デザインにA13とメモリ3GBか - Engadget 日本版
https://japanese.engadget.com/2019/10/03/iphone-se2-2020-8-a13-3gb/
純正インクに戻したら色は戻ったがノズルごとに互換インクが残ってるのか、帯状のムラが出てる。クリーニングとテスト印刷を繰り返す
このアカウントは、notestockで公開設定になっていません。
@orange_in_space config/sidekiq.yml から定時処理で MediaCleanupScheduler がやってる
@orange_in_space 投稿から使われてない添付メディアはたまに掃除されます。容量の心配はありません。
The 16 MB -> 67 MB ImageMagick RAM usage increase is tolerable. って書かれてるけど、ImageMagickの1ピクセルは何バイトだったかな…。3としても201MBのRAMを一時的に使うので、リソースの乏しいサーバでは変えるべき
今まで長辺だけ見てリサイズしてましたが、サーバに合わせて平方ピクセルを指定してリサイズする設定も追加しました。ただしサーバのバージョンが古すぎるとうまくいたないかも。その場合は長辺指定に戻さないとダメ
https://github.com/tootsuite/mastodon/pull/12069/files ではアップロード可能サイズが67_108_864 (8192x8192相当)になったが、リサイズの指定は1_638_400(1280x1280px相当)で変わらない。
app/models/concerns/attachmentable.rb の MAX_MATRIX_LIMIT = 16_777_216 がアップロード可能な限界で
app/models/media_attachment.rb のIMAGE_STYLES. original.pixels: 1_638_400 がリサイズの指定なのか…。
マストドン2.9.3では1_638_400 平方ピクセル(1280x1280相当)に収まるようにサーバ側でもリサイズされるらしい
Images are still downsized to 1280 sqpx in the end so this should not affect storage capacity ってあるから、少なくともWebUIは自動リサイズしてからサーバに送るのか
長辺1280じゃモバイルデバイスだと荒く感じるのも確かなんで、時代の流れだな。STの自動リサイズも選択肢増やすかなあ
@rinsuki C++はABIが不十分だから仕方ないね。extern "C" なラッパーを挟まないと別言語から扱うのはとても大変
管理画面に理由を表示する部分はまだないといったな!あれは嘘だ! アカウントリストの「PENDING(x)」ってとこを押すと出てくる
この機能のテストをする時に、のえるさんのopen_registrations_apiパッチを入れてたことを忘れてて数分ほど戸惑いました。なんで403?ってなった
#SubwayTooter のアカウント作成の画面にサイトの短い説明と、(管理者の承認が必要な場合のみ)アカウントを作りたい理由を書く欄(省略可能)が追加されます。サーバ側の関連コミットは18分前。なお管理画面に理由を表示する部分はまだありません #mastodev
@Clworld 他人ビルドが信用できない…となると、dockerをdockerなしでソースからビルドしようとして凄くツラくなるやつだ
ちくわ大明神ですね(違う)>過去のTLの印象操作
http://dic.nicovideo.jp/a/%E3%81%A1%E3%81%8F%E3%82%8F%E5%A4%A7%E6%98%8E%E7%A5%9E
このアカウントは、notestockで公開設定になっていません。
ところでSTは意識的に「TLをソートしない」つまりストリーミングAPI使用時も取得順にすることを意識してました。ストリーミングから来たトゥートがTLに挟まれると見た目上スクロールがずれた位置に飛んでしまうことが発生するからです。公式Webでもそんな挙動は起きてますが、私はコレが嫌で嫌で仕方ない。
snowflake IDの影響でこれがどう変わるかはまだよくわかっていません。since_idに影響しないならソートせずに今のまますませたいところです。
このアカウントは、notestockで公開設定になっていません。
リモートからきたトゥートを時間順に表示したいだけならやっぱり「未来のトゥートは表示しない」が最適解かな。ストリーミングで受信したときは数秒以内ならバッファに貯めればよし。
そもそもどんな目的でsnowflake IDを導入したんでしたっけ…? ああ、クライアントは常に現在時刻をmax_idに指定すればいいんですかね?
過去の方に数秒遅れましたとかならまだsince_idズラす設定を設ければユーザが調整できるけど、やっぱり取得漏れとクレームがでるのは避けられなさそう。
時間の偽装はサーバがトゥートをインポートする時にクリップしてもらわんとどうにもダメそう。クライアントがTLを取得したら最新40件の全部が未来の時刻でしたってなったら、差分取得でsince_idをどう指定するべきかクライアント側では決められなくなる
TLのpull to refreshするときにsince_idの指定も少し余裕を見てマージンつけるとかしないと、また取得漏れがどうとかいわれかねないかな。またタンスのバージョンみて挙動を変える部分が増えるかな。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。