@abcang じゃあ対応しときますか…
@abcang
個人的には普段からkotlinでtextNullable?.isNotEmpty() == true とか textNullable?.isEmpty() != false とかが日常になってるので3値論理を回避する理由は特にないのですが、mastodonの人たちがどうなのかはよく知りません
@abcang まあ今回それを行う積極的な理由はないと思うのですよね…。migrationが重くなるだけ
@abcang change_column_default :mentions, :direct, false してもDBのカラムにはデフォルト値は設定されないですね。alter table mentions alter column direct set default false; みたいのが走るかと思ってたらそんなことはなかった。なので結局クエリを書く時は3値論理の考慮を強いられるみたいです。
@abcang PRを更新してみました。手元の環境でrollbackとmigrateを行って、直後にpsqlで select direct,count(0) from mentions group by direct; してdirectカラムの初期化が行われていることを確認済みです
@abcang 前提が違うみたいなんですが、あのupdateは全件に対して働く訳じゃなくて、visibility=3のstatusesに対応するmentionsだけをupdateするやつですよ
@abcang add_columnのタイミングでnull:falseしたり非nullなデフォルト値を設定したりするとstrong migrationになっちゃいますね。テーブル全体書き換える重い奴です。add_columnした後にデフォルト値を設定する程度なら書き換えずに済むみたい
野菜ジュースとノンアルコールビールのちゃんぽんうまー
https://github.com/tootsuite/mastodon/pull/7614 は落ち着いたので査収おねがいします…
arel_tableを使うことで定数のパラメータ化を防止できるようだ
PREPARED_STATEMENTS=false をせずにそのまま使ってるタンスって結構あるのかな。…あるんだろうなあ…
意味的にはズレがあるけど506あたりで返せば誰も困らないんじゃないかな
5xxなのは良いとして、503以外のエラーを返すようにすればいいのでは。あとは監視系で工夫すればよさそう
where() にただの文字列を渡せば定数のまま取り扱ってくれるかというと、そんなことはなかった…。
masterでlightテーマが復活してますが、ミュート確認ダイアログの色がひどいことになってます
というか即値部分まで勝手にbind parameter化するのはRailsの暗黒面だな…
コードから個別にprepared statement を無効化するには to_sql した後で unprepared_statement で囲む必要があるらしいが、今のコード構成だとやりづらい感じあるな…
postgresqlのlog_statementをいじって確認したんですけど、Railsってクエリ中の定数パラメータ(where visiblity=3 みたいなの) を prepared statement のためにbind parameter 化するんですよ。そしてPostgreSQLはbind parameterに関しては部分インデクスの利用を行ってくれないのです。.env.production に PREPARED_STATEMENTS=false って書いとけばこの現象は起きません。pgbouncer導入してる人は既にこうなってるはず。
@abcang migrationのアレのことなら、動くよ。ロック範囲の方は良いやり方があれば教えてください。
accounts_not_silenced on accounts (id) WHERE NOT silenced;
statuses_dm on statuses (id, account_id, updated_at) WHERE visibility = 3;
statuses_dm_account on statuses(account_id, id, updated_at) WHERE visibility = 3;
statuses_public_local on statuses (id) WHERE visibility = 0 AND reblog_of_id IS NULL AND (reply = false OR in_reply_to_account_id = account_id) AND (local = true OR uri IS NULL);
custom_emojis_domain on custom_emojis (domain, shortcode);
どれも有用だと思うけどゴリ押しはしない
さっきのPRのとこはrspec通ってたぽいし、細かいことは気にしなくていいか…
rspec動かすと uninitialized constant Rpam2 って怒られて、おま環だってのは分かるんだが何をどうしたらいいのか…
普段は寝てる時間なのだが、野暮用を片付けるためにまだ眠れないのだ
StrawberryというとStrawberry Perlの方が個人的にはなじみがある
の投稿
mayaeh@taruntarun.net
このアカウントは、notestockで公開設定になっていません。
テストまわりに手をつけてない関係で古い処理がのこってるのはアレだと思うけど、ウチには非dockerのテスト環境がまずありません（
細かい指摘を頂いてるのは帰宅したら直そう。インデクスの話はPR中の変更点と直接絡まないしコメントを保留したいです。
@yakitama 外部アプリ経由でデータを取得するインテントは数種類あって、Android 4までで主に使われてた形式と、Android 5以降で使われるようになったSAFとがある。STが対応してるのは後者。前者は色々問題があって対応が面倒くさい。フォトがSAFに対応してくれると一番よい
@yakitama 単純に、googleフォトがSAFのcontent providerに対応してないだけです。googleドライブは対応しており、端末内部にない画像を複数選択できたりします
@tacostea http://instances.tacostea.net/list をブラウザで開くとダウンロードになっちゃうのはなぜでしょう？ PCのChrome,firefoxとAndoidのchromeで確認しました
とりあえずウチのテスト鯖では動いてるような気がするな
https://github.com/tootsuite/mastodon/pull/7614 DMカラムのクエリを分けて後からマージするPRというのを描いてみたが、手元ですら動作確認していない雑なアレである。ページネーションとか面倒になるのでUNIONは使ってない
マストドンのアイコンとミクシィのアイコンは確かに似ている
通知カラムの「フォローされました」表示でカスタム絵文字のアニメーションが正しく表示されなかった問題を修正した。そのうちリリースする。 #SubwayTooter
まあ部分インデクスはディスクスペース的にも負荷的にも軽いので、多少多めに作っておいてもバチはあたらない
create index statuses_dm_account on statuses (account_id,id,updated_at) where visibility=3; というのは試してみたけど、ウチの規模だと数msしか変わらないので有効かどうかはコメントできないなー
あとウチで目立つスロークエリは SELECT COUNT(DISTINCT "accounts"."domain") FROM "accounts"; が600-800msかかってるんだけど、対策を思いつかないし無視していいかな…
ActiveRecordでコレを書くの面倒そうだなあ…という印象だがそもそもRuby分からんので識者によるPRが望まれる
index_statuses_20180106 のDM限定版インデクスを作った場合の実行計画も追記してみたけど、ウチの環境だと負荷が低すぎて有効なのかどうか分からなかった
https://gist.github.com/tateisu/a7de7a8ff816e83ea2894e599499849d unionの左辺と右辺にもlimitを入れた場合の実行計画を追記した
create index ではサブクエリを使えないので、mentionsテーブルのDM用部分インデクスを作るにはテーブルにカラムを追加してやる必要があるな…
@valerauko actualの方は別にそうではないので。
@fn_aki それはいらなくない？ https://gist.github.com/tateisu/a7de7a8ff816e83ea2894e599499849d みるとメンションみつけてそれにあわせたステータスを探すときにstatuses_dm 使われてるから。
https://gist.github.com/tateisu/a7de7a8ff816e83ea2894e599499849d union使うやつの実行計画。20件ずつ読んでるという訳ではないのだ。。
あと実行計画みると、limit 20 がかかるのは Append してSortして Unique してまたソートした最後の部分だけなんで、ソート対象の一時データは結構な件数がある。 アプリ側でマージする方をお勧めする
DMカラムにはmin_id使うようなクエリはなさそうなので、ページネーション書くの面倒そうだけど破綻はしないと思う。なお "statuses"."id" as status_id って書いてorder byの対象には名前つきの列名を指定しないとクエリできなかった
unionでやるやつexplainかけてみたら、自分あてのメンション集める部分ではstatuses_dm (DM用部分インデクス)も使われたし index_statuses_20180106 の部分インデクス版もあった方が速いだろう。ていうかウチの場合はないとunionじゃない奴の方が速い。DMとそれ以外の比率が結構激しい。ねこまんまさんが言ってるのはコレのことじゃないかと思う
index_statuses_20180106 がだいたいそうじゃん。公開範囲全部を含むだけで ＞account_id, idへのインデックスをvisibility = 3に対して
マストドンのWebPushってVAPIDキーを.env.productionに設定しないことで機能しないようにできるとかあるんですけど、プッシュ購読APIはその状態でも200 OKを返すというね…。(レスポンス中のサーバキーが空になるから判別不可能な訳ではない)
2.4以降のタンスだけに限定するんならプッシュ通知だけに割り切った設計もできるんですけど、まだ時期尚早
@osapon 今の通知取得はネットワークアクセス要求するし場合によっては10秒に収まらないので、なんらか通知をださないとバックグラウンド動作制限にひっかかるんですよね…
#SubwayTooter でプッシュ購読をご利用の方で1アカウントだけ、タンスにVAPID_PUBLIC_KEYが設定されておらずタンス側でWebPushが動作していないと思われる方が存在します。
Let's encryptの有効期限の短い鍵でHPKPするのが間違いなんだろうか…
証明書の更新でPublic-Key-Pinsにささった奴です…
@Dalk 証明書の更新したら Public-Key-Pins でささってる
もしかするとなんだけど、vapid public keyが設定されてないのにプッシュ購読APIつかえるタンスがあるような？ うちのアプリサーバのログ見てるとそんな気がする。空文字列にみえる。
マストドンのプッシュ購読API、コールバック呼ばれる時のUAはこんなです。
"Ruby"
ぱうーくらいDM多いとDMの部分インデクスだけでも相当あるだろうし、色々しないと厳しいだろなー
DMカラムって自分が書いたDMと宛先が自分のDM両方を混ぜたモノなんで、究極的にはDMカラム用にテーブル持たないとクエリをシンプルにできないはず。(account_id,status_id,updated_at)で、自分に関係してるDM全てのステータスIDを一度に取得できるようなの。
タンスによってはmentionsテーブルのインデクスも見直したくなるかもしれない＞DMカラム
こういう表示は余計なお世話かもしれないけど、サポートの手間を減らす効果はあると思うんだ
https://mastodon.juggler.jp/media/2Ksf3yfCXXvLLNamsI0 https://mastodon.juggler.jp/media/G4Ht7XNYCCY82gbHaSM
「つながりを隠す」の連合での挙動を改善するには、標準化を強化する必要があるらしい。
この件について私は意見を持っていないが、アプリのユーザには説明する責任がある。
「繋がりを隠す」は連合しない。タンス(A)のユーザのプロフィールを別のタンス(B)のWebUIやAPIから確認すると、(B)に存在するフォロワーやフォロイーはリストに表示される。
ここのアナウンスさんのフォロワー一覧も非公開にしとこうかね https://mastodon.juggler.jp/users/juggler/followers
(LTL)あと名前にもカスタム絵文字つかえるようになったんですが、絵文字ふやしたいとか要望はないかなあ
いままで完全公開だったのに比べたら、フォロー先に通知が届くだけになったのは十分こっそりなんじゃないかと、
公開プロフにフォロー関係が表示されないってのがメインで、おまけでWebUIやアプリでも自分以外はフォロー関係を取得できないようになってるだけですねー。フォロー先には通知が届きます
ためしにフォロー隠してるアカウントからフォロー送ってみましたよ
MTA用のリストだもんなあ…クライアントをこれで絞るのは厳しすぎる
@sakko2005 ああ、そういう…。そりゃ自分のは見れますよね…。
非表示でどうなるか見たいのなら @tateisu とかテストアカウントがあります
@sakko2005 自分のアカウントから自分のプロフを見てますか？もし古いタンスからこのタンスのプロフを見てるのであれば、そりゃ古いタンスには隠す設定がないので…
@sakko2005 チェック付けて「変更を保存」した後にプロフカラムをリロードすると見れない(サーバからはカラのフォロー/フォロワー リストが返る）状態になるはずですけど、なってません？
MTA用のリストだもんなあ…クライアントをこれで絞るのは厳しすぎる
spam系IPアドレスのリストらしいよ
https://mastodon.at/@pfigel/100074037885173243
https://hostux.social/@valere/100074476284834492
うちはメールサーバの方をいじったので使ってませんです
https://github.com/yuzulabo/Mastodon-Activity-Embed をウチでも表示する https://mastodon.juggler.jp/about/more ようにしてみたけど、最初の行って計測中の(現在の)週だから集計途中の数字が出ちゃうので１つ古い週のデータを表示するように変更したよ
DMカラムは結構重かったので、データベースに部分インデックスを追加した方がいいよ。DMトゥートだけが探索対象になるから、DMが少ないタンスほど効果が高いよ。 https://gist.github.com/tateisu/cc6bff006b898094262245491b631f2f
マストドン2.4.0からダイレクトメッセージのカラムを表示できるようになりました。通知から探すより便利なので使ってみてください。
@mazzo WebPush APIはかなり前からあったのですが公式WebUI専用のものでした。今回はサードアプリからもプッシュ購読APIを利用できるようになったのが改善点です。 Androidだと SubwayTooter 、iOSだと Toot! ( https://github.com/DagAgren/toot-relay ?? ) が対応済みです
https://gist.github.com/tateisu/cc6bff006b898094262245491b631f2f インデクス追加前後の実行時間の予測
DMカラムが遅いので雑に部分インデックスを貼る。 create index statuses_dm on statuses(id,account_id,updated_at) where visibility=3;
2.4.0、lightテーマは少し改造しないと見れなくなっちゃったんだね
Andoid 5が出てから4.5年が経過してるの。メーカーが古い端末をサポートする期間は1.5…3年程度が普通だし、4.4が滅びるのはまあ妥当だろうという感想
手動だろうと自動だろうとアカウント大量作成はダメよね
しかしまあいろんな亜種が発生しそうだしreCAPCHA的なのが欲しい感じはある
https://gist.github.com/tateisu/7158814ca15700808364e3b83f35d47a メールアドレスのリストから今回のアレなmxを探すperlスクリプト
カスタムROMでアプリ動かして不安定ですとか言われても困るかなあ。アプリの動作検証用の環境としてはまず避けるべきだし
うちは自前メールサーバなので iptables -t nat -A PREROUTING -d 167.99.210.22 -j DNAT --to 0.0.0.1 とかで問題のMXにメールが投げられないようにした
select users.email,accounts.username,users.last_sign_in_ip \
from users left join accounts on accounts.id=users.account_id order by users.created_at desc limit 50;
@Cutls gmailの拡張メールアドレス(+)使うやつ があれば自動化できるよ
仕事が色々とアレで逃避したい…。しかしこのジャンルを扱えそうな人は他にまず居ないだろうし、呻きつつも進めるしかない
lightテーマの公開ページ。…あちこちおかしいが、それより公開ページにテーマ適用しないようにしたほうがよくね…？
https://mastodon2.juggler.jp/@tateisu
https://mastodon2.juggler.jp/@tateisu/100029156306595878
本当に欲しいのは「画像つきトゥートだけ保持するリスト」なのかもしれないと思った
今はSTで割と無理矢理実現してるけど、要らないのを読み捨ててるから負荷が高いやで。
それより個人的にはHTLのメディア表示が欲しいやで。エロ絵BTアカウントの巡回が捗るやで。
今のmaster、LTLをpin留めしたのとしてないのと二つ並べてメディアボタン押すと、押してない方のカラムがメディア表示になる
@lin そのうち止めるって言ってたからてっきりもう止めたのかと
左の脇腹がぴくぴくする。乳酸菌か納豆菌をとらねば…
@unarist 非公開トゥートの場合は、既に受信タンスにデータがあるのでない限りは情報を取れないだろうし、情報があるのなら検索APIを呼べばいいのだからカードじゃなくてもよいかも。クライアント側でリンクを開いたときにまずタンスの検索APIに投げて、候補（複数かも）があればアプリ内でひらくかブラウザの別窓で開くか選べるような仕組みがあればよいのかも。
@unarist リモートの投稿から来たURLも、受け取ったタンス側でカードの作成はしてるでしょう？そこに情報があればよいんでは
トゥートURLを引用した時に、タンス側でHTML中のリンクの属性にステータスIDを埋め込んでくれるなどするとクライアント側での対応が捗って素敵だと思う
@unarist それspamの温床になりそうだからやらない方がいいと思うよ
非公開トゥートを他人からageたい場合、URL引用が最も適切だと思うんだよね…。リモートのタンスのURLをクライアントが適切に開ける必要があるけど、ウチのクライアントはできてるし不可能ではないはず
@unarist 他人のフォロワーに向けてメッセージを送るのはさすがに有り得ないし、それがブーストでも似たような悪影響がありそう。
@unarist 他人の非公開トゥートをブーストする人が直後に「(BT)なんとかかんとか」ってトゥートした時に、混乱を招きやすい。ユーザの理解を得られない機能になりそう
@unarist 非公開トゥートのブーストは2.4にあるけど、それじゃなくて？
@mot iOSもiPod とiPhoneとiPadがあるから機種シリーズとしては別に単一ではなくXperiaやGalaxyと同等なんでは？
VRゲームのBeat Saber で遊んでみた。シンプルに斬りまくるゲームで楽しい！
https://mastodon.juggler.jp/media/LFKon8wP-pfYNIcnJXA
APIからはフォローが存在しないか隠されているか分からないけど、それをそのままユーザに伝えるだけでも割と問題ないよね、って話をしてた
user_hides_network はAPIには露出していないらしい…？
(LTL)終わったことよりもできることについて考える方が楽しいと思いますよ。独身にだって良い部分もあると思うし、悪い側面ばかり見ても仕方がない
