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

今回のアップグレードはmigrationが2段階なのね

マストドン2.7からはサーバー運営からの警告などのメッセージをメールで送れるようになったので、これでユーザは躊躇いなく運営アカウントをミュート、ブロックできますね？

https://blog.joinmastodon.org/2019/01/mastodon-2.7/

ゴミだけじゃなくて情報セキュリティ上の問題も https://wired.jp/2019/01/19/government-shutdown-cybersecurity-impact/ ああ、こないだアメリカ政府のWebサイトで証明書の期限切れがでたのはコレのせいだったのか

政府機関閉鎖で公園はゴミだらけ https://www.businessinsider.jp/post-182664 自主的に掃除する人はそんなに多くなかったらしい。家が近いとかならともかく、山の中の自然公園とかじゃなあ…

アメリカでは政府機関の一部が閉鎖したので職員たちは副業を増やしたり寄付を募ったりしている https://www.businessinsider.jp/post-183074 これが日本なら「公務員が副業なんてとんでもない」とか老害が言い出す事案だろうなあ…

結局時計のズレがあるのでクライアント側では判断しないほいがいいよね。クライアント側で下手にマージンをとると「公式だと5分以内なら指定できるのにあるアプリだと6分以内になるのはなんで？」とかクレームになる

@mayaeh @noellabo 前例としては max_toot_chars が存在します。これは公式には存在しませんが、いくつかのクライアントは対応しています。

@mayaeh @noellabo マストドン公式は「カスタマイズされたタンス」に冷たいので、そういうのを追加するなら誰かがフォーク上で用意して各クライアントに対応を求めるという形になるかと思います

@noellabo @mayaeh
- 投稿時の予定日時のチェックはサーバ側で行うべき
- 指定可能な日時の下限はタンス側の現在＋6分とかにするべき
- APIエラー文言も直す
…というのが妥当だと思います。

クライアント側は肝心の数字を持ってないので、そっちでがんばるとカスタマイズされたタンスに対応できなくなるのです。

@noellabo @mayaeh インターバルって「１日に予約投稿DBをスキャンする回数」なので、そっちを変える方向にいくのは負荷的な影響があると思います…。

@noellabo @mayaeh sidekiq投入インターバルは5分のまま変えないとして
- エラーチェックした時点できっちり5分未来が指定されていた
- ところがほぼ同時にsidekiqへの投入が走っていて、その投稿がDBに記録されたころには既に終わっていた。
- 次の投入タイミング(5分後)にsidekiqに乗り、結果として5分より少し後に投稿される

…くらいは発生しそうだけど、まあどの程度の精度を求めるかによるかなあ…。所詮sidekiqだしキューが詰まってたらダメだし

@noellabo @mayaeh 完全に同意。エラーにしてほしい…。

あと「５分きっかりで本当に大丈夫なの？sidekiqへの投入タイミングが5分なら、エラー判定は少しマージンをもたせるべきじゃないの？」というのもあります

@vando ごめん直す

クライアント側はタンスの時計のズレなんて知らんのや

予約投稿、タンス側時刻で５分以内の日時を指定するとその場で投稿されます。あとから時刻を変更しようとした場合に限り５分以内ならエラーになります。困る

@mayaeh しかも時刻をあとから変更する時だけチェックして投稿時にはチェックされないよねそれ。不便だわー

@rinsuki えらい！

@ahiru 既存の予約投稿の削除で対応する場合は個数ほしいですよね

あと個人的な希望としては、新バージョンの開発に入ったら 2.7.0alpha とかバージョン番号を上げてほしい。バージョン番号によって機能が提供されてるかどうか異なるので、開発初期でも異なるバージョン番号がほしい。

@rinsuki もうないよ

トレンドタグやおすすめユーザもそうだけど、先にAPIだけ用意してアプリが対応おわってから公式WebUIにのせるという流れは割と好きです。影響を受けるユーザの数が減るので、混乱するユーザが減ります。

予約投稿委一覧の項目の、予定日時を書いてるとこをタップで「削除して再編集」まである

予約した投稿の一覧はSTなら表示できるよ。サイドメニューの下の方

ちなみに予約投稿一覧にはページングがないのに、予約投稿自体は数百個まで作れます。古いのから削除することはできません

予約投稿の削除であのカウントって減らせましたっけ。。。？

どっちにしろユーザにできる対応を書いてないのだから、理由を述べるだけならどっちでもよさげ

そもそもSTが予約投稿を実装するまでまともに正常系ユースケースを通してなかったみたいだしな。これもDiscordでゴネてなんとか通せるようになった

開発版の機能まで積極的に取り込むアプリはiOSどころかPCにもAndroidにもほぼ皆無だよ。STが異常なだけ

「スケジュールされたトゥート」ってルー大柴みたいな言葉遣いだなあ…

@mayaeh 「スケジュールされた投稿」は個人的には長すぎる。「このスケジュールされた投稿を削除しますか？」はスマホの画面では見たくない字面

@nacika 便利だと感じてるのなら、むしろ片方買う側なんでは

なので、インスタンスによってはアンケート項目が追加される可能性などもあるかもしれません。

予約投稿のAPIからparamsを取得できるようになったのは俺がDiscordでゴネたからだよ。それまではIDと時刻しか分からんかった。
paramsは基本的には投稿APIに渡すパラメータそのものです。

@mayaeh サイドメニューの一覧では微妙に表記を変えてたりします。他の項目との兼ね合い。

@Lgyhx_Lambda サイドメニューの「全てのカラムを閉じる」で保護してないカラムをまとめて閉じることができます。常用カラムを保護してから使うと便利

@nacika 片方だけオークションで売られたりしてる

@Eai あれ、逆か…？

@Eai EUC_JPって書くのが正しい表記だと思う。EUC-JPだとブラウザによってはcharsetを理解しないかも

リリースノートを英訳する手間すら惜しんでるので、ストア用の新機能紹介を毎回真面目に自分で書くなんてムリ。すまぬ。俺の限界なんだ…。誰か書いてくれたりしないかなあ…。

今夜から低気圧らしいし冷え込みと頭痛に注意だね

件のボタンサイズは基本的には設定で変えられるようにしたので前進したはずなのですが、問題はそれに気がつかない人が結構いることなのでした