shu22203 commented 3 years ago

1

https://github.com/shu22203/internet_ranking/issues/1#issuecomment-670821602

あたりから話が膨らんできたのでissue切った

hidollara commented 3 years ago

ありがとうございます

とりあえず画像 or スコアだけ先に登録しておいて、後でまとめてやろうーという人がいるらしい(過去に画像一括登録機能の要望があった) 人々がどんな風に登録作業をしているかいまいち分かってない部分がある

画像未登録パターンはUNREGISTEREDみたいな状態を増やして、画像が追加登録されたら通知を投げてPENDINGにするとかで対応できる気がします。スコア未登録パターンはちょっと想定外なんですが、そもそも運用上スコア入れないとランキングに表示もされないのでとりあえず考えなくてもいいんじゃないかな？とか思ってます。

他の人から推測されないURLにする毎回のIRでの画像サイズはだいたい50~100MBくらい

保存容量はまあ無視出来そうなくらいなんですね、でも画像のURLの複雑化だいぶ面倒臭さ感じますね…

shu22203 commented 3 years ago

画像未登録パターンはUNREGISTEREDみたいな状態を増やして、画像が追加登録されたら通知を投げてPENDINGにするとかで対応できる気がします。

これは確かにー状態遷移が煩雑にならないようには意識したい。

未登録はそうね、結構エッジケースっぽいし無視でもよさそう。

画像容量は上限サイズ決めてでかいのはリサイズして保存するとかやってたはず。この辺も頑張りたくはないのでなおさら永続化せずに済ませられると嬉しいところ。

hidollara commented 3 years ago

状態遷移が煩雑にならないように

これは自分も強く思うので気をつけたいですね。とはいえ、画像未登録を許しても UNREGISTERED -> PENDING -> (APPROVED <-> REJECTED) くらいなので、これくらいは全然許容できるかなぁと思います。

画像周りごっそりなくなれば、フロントはFirebase/バックエンドは単一VPSでAPI+RDS、とかで見通しも良くなりますし良いと思います。

junk0612 commented 3 years ago

横槍だけど、状態遷移はそんなに簡単じゃないと思う。再登録を含まない形で書いても↓みたいになるし、再登録を許すとここから Rejected → Pending に更に矢印が伸びるんじゃないかな YzQALT3LjLC8pIjAJSyiBaajIarHi59utBJpSTFcnqsBdi_S_R9d4rSqL5b0QbvAPbuwKCNpARkVDlS_Rbm1L_guQTBJ2JtFPZP1zQ0OYKqpL1rC6AJ4iQ2WAByCrGdFElU_MDMBeYmeDIirkGHLsTFUBKzsT7F1JG2f0pgR2wuMAW00

hidollara commented 3 years ago

Pending -> Approved は承認権者の承認 Pending -> Rejected は承認権者の却下 Approved -> Rejected は承認権者の却下（誤った承認の取り消し） Approved -> Pending はなし Rejected -> Approved は承認権者の承認（誤った却下の取り消し） Rejected -> Pending は証拠の再登録（再登録を許した場合のみ）

という感じで、この3状態の状態遷移はほぼ完全グラフを構成しているのは理解しています。ですが、Pending/Approved/Rejectedの3状態で提出を管理する場合、これは必ず必要になると思っています。（これを楽にするには2状態のtrue/false管理以外にない？気がするので、true/falseで管理しようみたいな話だったりしますか？）

で、Unregisteredを追加した場合はたしかに状態が増えるのは間違いないですが、UnregisteredからApproved/Rejectedへの遷移ルートはないので、状態遷移の複雑性はそこまで問題ないかなと思ってます。あと、画像とスコアの同時登録って確かにユースケースとしては独立してるんですが、状態遷移としてはまとめたPending直通ルートは取らないかなと思ってます。

junk0612 commented 3 years ago

いや、

画像未登録を許しても UNREGISTERED -> PENDING -> (APPROVED <-> REJECTED) くらい

からそれが読み取れなかっただけでした 🙏 ちゃんと考えると結構複雑だけど考慮できてるんだろうかと。あと、今更考えたら Rejected -> Unregistered はあるのではという気持ちになったので、Pending からはあらゆる状態に移行可能な感じですかね。

hidollara commented 3 years ago

Rejected -> Unregistered は無い気がするんですけどどうなんでしょう…？画像の永続化があるなら、画像の削除があり得るのでRejected -> Unregistered もありえますけど、Rejectedからの再登録は別の画像を証拠に添付するだけなので、Rejected -> Pending な気がしてました。

hidollara commented 3 years ago

あ、入力スコアの修正があるか……

junk0612 commented 3 years ago

画像が合ってるけど数値を誤って登録したスコア修正したくないですか？ > Rejected -> Unregistered その場合は画像が合っていようが数値が合っていようが Pending になる……？たしかにそれでも大丈夫か。

hidollara commented 3 years ago

2通りの解決法？が思いついてて、

ちゃんとRejected -> Unregisteredのフローを考慮に入れる
内部的にはRejectedのデータを削除して新しい提出を作成する
- これやるならRejected -> Pendingのフローも削除と再生成にしたほうが~~フローがDAGになるので~~よさそう
  - DAGではない（なぜならApproved <-> Rejected のループがあるため）

とかで出来るかな～って感じです

junk0612 commented 3 years ago

ちなみに、(ちゃんと考慮できてないけど) 「提出」と「登録済みスコア」を別テーブルとして考える方法もありかも、って気がしている。具体的には

画像かスコアが登録されると「提出」が作られる
画像とスコアが揃うと審査できる
審査で承認されると「登録済みスコア」が作られる
審査の却下は何もしなくて済む。再提出も「提出」のアップデートでよい

みたいな。これだと状態管理をする必要がなくなるんだけど、未承認のスコアをランキングに表示するのにちょっと難儀しそうなので難しい。

junk0612 commented 3 years ago

そういえば、今のシステムで承認済みスコアがある状態で再提出すると、ランキングの表示ってどうなるんだっけ？

shu22203 commented 3 years ago

今は承認ステータスは特に無いです。曲 x 難易度 x ユーザーでユニーク(厳密には少し違うけど)なレコードをずっと更新していく感じです。

junk0612 commented 3 years ago

いやむしろ「登録済みスコア」をランキングに表示する必要がもしかしてないのか……？期間中はいつも「提出」をランキング表示しといて、いつでも承認すれば「提出済みスコア」が作られ、期間後には「提出済みスコア」でランキングが作られるとすると、↑のモデルで一通りうまく行きそうな気がしますな。

hidollara commented 3 years ago

状態遷移の難しさのしわ寄せをコードで吸収するかDBで吸収するかの違いな気がしてます。これ実装する時の状況に応じて考えるべきだったりする気がしてきました…（実装の設計が好きすぎてずっとこの話してしまう気がする）

リザルト画像を永続化する・しないの判断にあたって、とりあえず一番の問題は「永続化しないとできないこと」を洗い出すことで、とりあえず自分が思いついたとこだと

ユーザーが自分の提出した画像を再利用して提出することができない
ユーザーが自分の提出した画像を確認できない
承認権者が管理者画面から提出された画像を確認できない

というあたりが課題になるかなぁと思います。

ユーザーが自分の提出した画像を再利用して提出することができない提出の度に画像を上げ直してもらう必要が出てきます。スコアの入力を間違えて再度登録し直すときでも、毎回画像を新規に上げ直す必要があります。今までのUXから考えたら一番の課題はこれかなと思います。
ユーザーが自分の提出した画像を確認できない提出の時に上げた画像がどう間違っていたのかをreject後に確認できません。つまり、rejectの理由を自分で確認することが出来なくなります。とはいえ、現状approve/rejectはIR後にやっていましたし、逐次承認の形を取ったときの課題って感じですかね。
承認権者が管理者画面から提出された画像を確認できない Slackなどから送られてくる通知から提出画像を確認することは出来ますが、後で修正依頼を受けた時に管理者画面から画像を確認することができなくなります。逐次処理でいいのではと思っていますが、承認が溜まってしまうと面倒なことになるのはありうるな…と今思ってしまいました。

その他自分が見逃してる課題があればそれも検討した上で、画像の永続化をするかしないか決めて、実装の話は別のIssueに移動したほうがいいかな、と思ったんですがいかがでしょう？（ちなみに今自分で画像を永続化しない場合のデメリットを考えたら思ったより深刻だな…となりました）

hidollara commented 3 years ago

URL難読化してた部分、Firebase Authenticationと連携させて権限つけるみたいなこと出来はするみたいですけど案外面倒なんですかね？ https://firebase.google.com/docs/storage/security/user-security?hl=ja

junk0612 commented 3 years ago

たしかに、だいぶ実装の話にとらわれてしまった。ちょっと問題点は他に思いつくところがないですね。上げてもらった点は↓なふうに思いますが、どうですかね？

提出に画像を再利用するのは、それほど大きな問題なのだろうか？今まで自分が IR をやっていて、同一画像でスコアを再送信したいことがなかったもので、いまいち需要にピンときていない。誤送信が起きうるのはわかるものの、起きる可能性も起きたときの被害もそれほど大きいとは思えないので、簡単に再利用できるようにする必要はなさそう。
確かにユーザーが提出した画像を確認することはできないけど、オリジナルの画像はユーザーが持っているものなので特に気にする必要はなさそう。誤った画像をアップロードするという問題は↑の誤送信と同じ気がする。
管理者画面で提出のチェックが完結しないのはたしかに面倒かも。例えば、送信した Slack のメッセージ URL を出したりできればだいぶ緩和できそうだけど、連携するサービスを広げるとなると難しそう？

shu22203 commented 3 years ago

@hidollara

firebase側で権限管理させるようにすればそこまで大変じゃない雰囲気ありますね。 IRごとの管理者(群)とfirebase側のグループを同期するのがやや面倒かも(よく見てない) 当時(2014年？)は自分にクラウドサービスの知識(というか発想)が無かったのでRailsだけで頑張っていた感じですね。

@junk0612

いまいち需要にピンときていない

再利用というか、画像を正としたスコアのみの修正ですよね。入力ミスはスコアの桁数が多いゲームでは特に多発しそうな気がするのですが(特に多く登録する人は途中から疲れて注意力が欠けることにより) 皆さん意外と正確に入力できているものなのでしょうか？最大の被害は正しく登録出来ているものと思ってしまいもと画像を削除してしまい、そもそも再登録不可能になってしまう状況ですね。 (基本的にslackなどにログとして残っているであろうとはいえ)

オリジナルの画像はユーザーが持っているもの

提出したら消してしまう人がいる可能性については考慮しなくても大丈夫そうでしょうか

送信した Slack のメッセージ URL を出したり

をするのであれば、submissionテーブルに画像パスを保存するのと本質的に変わらない(ストレージコストの問題はありますが十分無視できるほど小さい) ので、だったら永続化すればいいじゃんに倒せそうだと思いました。

hidollara commented 3 years ago

IRごとの管理者(群)とfirebase側のグループを同期するのがやや面倒かも(よく見てない)

僕もちょっとここが不安ですね（あんま調べてない）

shu22203 / internet_ranking

リザルト画像の永続化の必要性について #2

1