"The scheduled date must be in the future" の翻訳悩んでいるけど、不親切な状態だなーと思う。
サーバーの現在時刻 + 5 分だけど、それが書かれていない。
Conversation
Notices
-
Maya Minatsuki :neko_smiley: (mayaeh@taruntarun.net@taruntarun.net)'s status on Sunday, 20-Jan-2019 18:04:15 JST Maya Minatsuki :neko_smiley: -
tateisu :force::r_9a: (tateisu@mastodon.juggler.jp)'s status on Sunday, 20-Jan-2019 18:05:26 JST tateisu :force::r_9a: @mayaeh しかも時刻をあとから変更する時だけチェックして投稿時にはチェックされないよねそれ。不便だわー
-
Maya Minatsuki :neko_smiley: (mayaeh@taruntarun.net@taruntarun.net)'s status on Sunday, 20-Jan-2019 18:09:32 JST Maya Minatsuki :neko_smiley: @tateisu なんと…
-
のえる :cava_red: DTP鯖管 (noellabo@dtp-mstdn.jp)'s status on Sunday, 20-Jan-2019 18:10:25 JST のえる :cava_red: DTP鯖管 @mayaeh @tateisu 予約のつもりで投稿してるなら、いっそエラーにしちゃった方がいいんじゃないかなぁ。単なる指定ミスかもしれないから、確定して見えてしまうと困るかも。
-
tateisu :force::r_9a: (tateisu@mastodon.juggler.jp)'s status on Sunday, 20-Jan-2019 18:28:44 JST tateisu :force::r_9a: @noellabo @mayaeh 完全に同意。エラーにしてほしい…。
あと「5分きっかりで本当に大丈夫なの?sidekiqへの投入タイミングが5分なら、エラー判定は少しマージンをもたせるべきじゃないの?」というのもあります
-
Maya Minatsuki :neko_smiley: (mayaeh@taruntarun.net@taruntarun.net)'s status on Sunday, 20-Jan-2019 18:37:06 JST Maya Minatsuki :neko_smiley: "The scheduled date must be in the future" 、どれ以上先なのか原文から直すべき案件だけどとりあえず訳すとしたら
「予約投稿の日時は将来でなければなりません」
「より先の日時を指定してください」
とかだろうかうーーーーん -
のえる :cava_red: DTP鯖管 (noellabo@dtp-mstdn.jp)'s status on Sunday, 20-Jan-2019 18:37:49 JST のえる :cava_red: DTP鯖管 @tateisu @mayaeh 5分自体がマージンなので、本当は残り1分で投入しても支障ないんじゃないかな。
sidekiqに載せると指定時間ぴったりが狙えるけど、最初から載せっぱなしにしとくと負荷が高いから、5分切るまでは投入しない、という処理かと。
-
Maya Minatsuki :neko_smiley: (mayaeh@taruntarun.net@taruntarun.net)'s status on Sunday, 20-Jan-2019 18:37:52 JST Maya Minatsuki :neko_smiley: できれば否定形ではない方がいいのかな、とか思ったり。
-
ぽぷんじゃ? (popnja@popon.pptdn.jp)'s status on Sunday, 20-Jan-2019 18:40:31 JST ぽぷんじゃ? @mayaeh 「投稿日時は今日より未来にしてください」という感じ?未来が怪しいが「今日以降にしてください」かな?
-
Maya Minatsuki :neko_smiley: (mayaeh@taruntarun.net@taruntarun.net)'s status on Sunday, 20-Jan-2019 18:43:46 JST Maya Minatsuki :neko_smiley: @popn_ja ありがとうございます!実際には同日でも 5 分以上後なら指定可能なので、悩ましいところです。
-
ぽぷんじゃ? (popnja@popon.pptdn.jp)'s status on Sunday, 20-Jan-2019 18:46:55 JST ぽぷんじゃ? @mayaeh なるほど。「今より新しい日時」みたいな感じですかねー。単に「時間」でも良いかも
-
tateisu :force::r_9a: (tateisu@mastodon.juggler.jp)'s status on Sunday, 20-Jan-2019 18:47:35 JST tateisu :force::r_9a: @noellabo @mayaeh sidekiq投入インターバルは5分のまま変えないとして
- エラーチェックした時点できっちり5分未来が指定されていた
- ところがほぼ同時にsidekiqへの投入が走っていて、その投稿がDBに記録されたころには既に終わっていた。
- 次の投入タイミング(5分後)にsidekiqに乗り、結果として5分より少し後に投稿される…くらいは発生しそうだけど、まあどの程度の精度を求めるかによるかなあ…。所詮sidekiqだしキューが詰まってたらダメだし
-
Maya Minatsuki :neko_smiley: (mayaeh@taruntarun.net@taruntarun.net)'s status on Sunday, 20-Jan-2019 18:49:28 JST Maya Minatsuki :neko_smiley: @popn_ja ありがとうございます! ?
-
のえる :cava_red: DTP鯖管 (noellabo@dtp-mstdn.jp)'s status on Sunday, 20-Jan-2019 18:58:40 JST のえる :cava_red: DTP鯖管 @tateisu @mayaeh なんか、scheduled_statuses_schedulerのインターバルを'4m'ぐらいにしちゃうのが簡単かもしれませんね……。チェックするの、そんなに負荷の高い処理じゃないし。
-
tateisu :force::r_9a: (tateisu@mastodon.juggler.jp)'s status on Sunday, 20-Jan-2019 18:59:38 JST tateisu :force::r_9a: @noellabo @mayaeh インターバルって「1日に予約投稿DBをスキャンする回数」なので、そっちを変える方向にいくのは負荷的な影響があると思います…。
-
のえる :cava_red: DTP鯖管 (noellabo@dtp-mstdn.jp)'s status on Sunday, 20-Jan-2019 19:04:40 JST のえる :cava_red: DTP鯖管 @tateisu @mayaeh Mastodon側は何も変更せずに、
5分ギリギリを狙うのはやめた方がいいよ、ってUI上で説明するとか、勝手にマージンとって、10分未満を指定できないように実装しちゃうとか。10分未満はダメって方式なら、サーバの時計のずれとかも吸収できる。6分でもいいか。
-
tateisu :force::r_9a: (tateisu@mastodon.juggler.jp)'s status on Sunday, 20-Jan-2019 19:11:43 JST tateisu :force::r_9a: @noellabo @mayaeh
- 投稿時の予定日時のチェックはサーバ側で行うべき
- 指定可能な日時の下限はタンス側の現在+6分とかにするべき
- APIエラー文言も直す
…というのが妥当だと思います。クライアント側は肝心の数字を持ってないので、そっちでがんばるとカスタマイズされたタンスに対応できなくなるのです。
-
Maya Minatsuki :neko_smiley: (mayaeh@taruntarun.net@taruntarun.net)'s status on Sunday, 20-Jan-2019 19:13:09 JST Maya Minatsuki :neko_smiley: @tateisu @noellabo そのインスタンスが何分以降なら受け付けるのか、数字欲しいですよね。
あと予約できる上限の数字も stats とかで取れた方が良さそう? -
tateisu :force::r_9a: (tateisu@mastodon.juggler.jp)'s status on Sunday, 20-Jan-2019 19:14:12 JST tateisu :force::r_9a: @mayaeh @noellabo マストドン公式は「カスタマイズされたタンス」に冷たいので、そういうのを追加するなら誰かがフォーク上で用意して各クライアントに対応を求めるという形になるかと思います
-
tateisu :force::r_9a: (tateisu@mastodon.juggler.jp)'s status on Sunday, 20-Jan-2019 19:15:30 JST tateisu :force::r_9a: @mayaeh @noellabo 前例としては max_toot_chars が存在します。これは公式には存在しませんが、いくつかのクライアントは対応しています。
-