https://www.satofull.jp/products/detail.php?product_id=1093829 神奈川県藤沢市はふるさと納税で1/6ドールがもらえるらしい

ねーむーい

@highemerly 画像アップロード時のリクエストボディのエンコーディングが multipart なんですけど、バイナリのママじゃないので変換効率の問題があります。

https://twitter.com/matsuya_foods/status/1199681028106801152
松屋がカレーやめるのか。あのカレーはスパイシーというより薬臭い感じだったなあ…

Twitterがこの画像をこうトリミングするの、わかりみが深い #白銀ノエル

@KAZU34 「imgur画像上げるプラグイン」それ作ったの多分俺…

@KAZU34 簡易投稿じゃなくて投稿画面ならマッシュルームプラグインでどうにでもなるやろという考え

@weep @Cutls いえ、検証して分かった事も他にあったのでこちらとしては結果オーライです。ありがとうごさいました。

@ayo add IzzyOnDroid repo to get ST via F-Droid

PHPはこんなのばっかりだな…>BT

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

@Cutls WebUI英語版には単位の記載がなかったんだけど、「n投票」だけにするとすごくおさまりが悪くて悩んだ奴だ。後からああこれ単に票数の合計なんだと分かったけど放置してる

普通のアプリのUXは使いやすさをある程度重視しつつも見せたい機能や広告やイベントやキャンペーンを強調しやすい構造を意識して作る、御馳走の料理の盛り付けみたいな考え方で作るのが正解なんですが、STの場合はイベントもキャンペーンも無縁だし赤字前提なのでご馳走というよりは炊き出しや妖神グルメのような考え方で作られてます。嘘です。

階層を上下に辿るだけじゃなくて、同じ階層の隣接したところに移動出来るようにするのがUXの流行だと思うかな。まあ古くはスーファミのLRボタンからあるやつだけど

@Otakan951 ブラウザでも動画プレイヤーでもダメじゃない？

SVG対応の是非はHi-DPI環境での表示をどうしたいかによる。#InstanceTicker の場合は元がローレゾ志向すぎて、どうしたいのか外部からはよく分からない。

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

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

Misskeyタンスで絵文字にSVGが使われることがあるのですが、その時にSVG1.1互換ではないCSSプロパティが使われていて対応できなかったりとかはありましたね

@weep @Cutls SVGの互換性。STで使ってるAndroidSVGライブラリは SVG 1.1 と SVG 1.2 Tiny specifications に対応してます。SVG2にはまだ対応していないようです。たとえば `isolation` や `mix-blend-mode` 等のCSSプロパティを含むSVG画像は正しくレンダリングできません。まあ「SVG2だとSTで一部表示が乱れる場合があります」くらいの取り扱いでよいんじゃないでしょうか。

DigitalOcean の障害情報 https://status.digitalocean.com/incidents/0ftrmj4l3z1m は23分前に更新されてました。引き続き監視するそうです。なお現時点ではウチのサーバでは問題は起きてません。

pixelfed のインスタンスを追加しようとしたときにアカウント作成画面が出る時点でダメだったな

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

WebというかUIに特化してる感じはある。カラープロファイルは一応埋め込めるけども、まあ使わない

一方でWebPが弱いのは最大ピクセルサイズ。268MPしかない。10年後のデジカメ画像は保存できなさそう。

WebPの良いところは非可逆で透過できるとこだよね。PNGじゃ無理なやつ

1800ほど溜まった再試行を消化し終わりました。復旧完了？

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

@weep ありがとうございます。試しにロード部分でURLを変更してみます。

@weep 表示にWeb技術を使ってないクライアントだとSVGサポートは割とハードルが高いので、テストできるタンスがあると助かります。

@weep いまSVG画像を使ってるインスタンスは何がありますか？

Web技術なしでSVG表示は割とめんどくさいやつだ

@mayaeh paperclipだけでなくオブジェクトストレージの制限もあるだろうから、分割は出来た方がいいでしょうね。app/model/backup.rb が複数のファイルを持てるようにして関連部分を全部ガッツリ書き換える重いやつになりそうですけど。

@mayaeh むしろ1ファイルのアーカイブにしてしまうのが問題なので、アーカイブを分割した複数のファイルをやりとりできるようにするべきでは。

「メディアサーバが落ちててもマストドンの応答性が下がらないようにする」だけなら手動対応で別にいいか、と思ったので突飛なことは言わない。これを自動化するためだけに色々やるのは手間に見合わない。

素の状態でも待機した上で必ず失敗するのなら、即座に失敗させた方がマシ

根本的には、IDを発行してからファイルアップロードが終わるまでDBトランザクションを握りっぱなしのpaperclipが悪いと思う。「IDに合わせたファイル名を持つ」必然性が全く感じられない。

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

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

@mayaeh 私の今回のは不安定じゃなくて全く接続できないので、connect()を即座に失敗させるようにしてストレージ側が復旧したら元の設定に戻す方が負荷が少ないと思います。タイムアウト値を設定可能にするPRも書いてみましたが https://github.com/tootsuite/mastodon/pull/12459/files そもそもRubyのnet/httpのopen_timeoutは DNS名前解決の待ち時間には効かないのですよね…。

@mayaeh 情報ありがとうございます。

@hanage999 情報ありがとうございます。 ただ、私の今回のは不安定ではなく全く接続できないので、connect()を即座に失敗させる対応の方が適切なのでした。

残念ながら焼け石に水だった。defaultキューが詰まるだけでなくDBのトランザクションを開きっぱなしにするのでpgbouncerのバックエンドコネクションを使い切りサービス全体が応答しなくなる。仕方ないので .env.production を変更してS3_ENDPOINT=https://nonexistent.uso など存在しないホストを指定した。メディアサーバへの書き込みが即座にエラーとなり、他の部分には影響しなくなる。

マストドン側のエラーログ。 https://gist.github.com/tateisu/0286a760e0f1ece355acb11d041b53d9 defaultキューが詰まるのヤバイ。タイムアウトは https://github.com/tootsuite/mastodon/blob/master/config/initializers/paperclip.rb で http_open_timeout: 5 とハードコードされている。 とりあえずdefaultキューを捌くsidekiqを増やす。 docker-compose up -d --scale sidekiq_default=2

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

DigitalOcean Spaces のインシデントがあった https://status.digitalocean.com/incidents/0ftrmj4l3z1m

LinkCrawlWorkerがSeahorse::Client::NetworkingError: execution expired を出してて、スタックとレース見るとメディアサーバへのデータ保存でconnectがタイムアウトしてるぽい

朝7時ごろからこのサーバの負荷が上がってますね。