Why

• このアプリケーションの規模が小さい / そこまで複雑でないという認識をしていた
  • 実際にはそこそこエンドポイントがある
  • ドメインロジックが複雑なので、ひとつのエンドポイントに対しても考慮すべきことが多い
• そもそもドキュメントが不足しており、 @kyontan 以外が全くコードの挙動を理解できていない
  • 困る (引き継げない)
  • エンドポイントに対するリクエスト / レスポンス をテストケースとして用意することで、ドキュメンテーションの役割も兼ねたい
    • ドメインや動かし方に関するドキュメントは #65

Tasks:

• 必要な Factory を定義する
• 必要な spec_helper 等を準備する
• テストを書く
  • /api/answers
  • /api/attachments
  • /api/:commentables/:commentable_id/comments
  • /api/contests
  • /api/issues
  • /api/members
  • /api/notices
  • /api/notifications
  • /api/problems
  • /api/problem_groups
  • /api/scores
  • /api/scoreboard
  • /api/teams

• 新規作成
  • 問題
  • 問題グループ
  • メンバー
  • チーム
  • 問題補足
• 編集
  • 問題
  • メンバー
  • 問題グループ
  • チーム
• 削除
  • 問題
  • 問題グループ
  • 運営Issue
• 機能
  • 質問ステータス表示
  • 質問種別絞込
  • スコアボードがNullな時の挙動確認
  • 得点版へのFirstBrad表示
  • 問題画面での、点数表示機能
  • 問題一覧画面での、問題ステータス
  • 解答不可時間
  • Adminで problems?with=answers-score を使わない(性能対策)
  • 時計
• その他
  • 注意事項
  • 権限で表示ボタンを変える
  • ロゴ差し替え

大会全体に関するお知らせ等を保持するモデル, API の作成

Notice

持つ属性は以下の通り (DB)

id: integer
title: string
text: string
pinned: boolean
created_at: datetime
updated_at: datetime

GET 時のエンティティの埋め込みについて、現状ではパラメータ無しで一定のエンティティが埋め込まれているが、with パラメータを付けることで制御できるようにする

また、 with パラメータが無い場合は、ICTSC6 と同様に何も埋め込まないようにする

• 複数ついているもの: カンマ区切り
• ネストするパラメータは - で繋ぐ
• 例:
  • GET /api/answers?with=comments,score
  • GET /api/session?with=member,member-team

• 問題は複数の問題グループに属することがある
• 問題グループに付加される幾つかの属性, UIの変更
• ファーストブラッドボーナスの廃止

以下のような文章を事前にプレースホルダに入れておくことで、参加者により良い体裁の質問 / 解答の提出を促す

• 問題は業務メールのような感じ
• 質問はある程度丁寧でラフな感じの文

解答状況を色分けして表示する機能が正常に動いていない。
チームと解答に対する得点は正常に表示されているので、値の取得に問題がある。

現在、解答 (answers) には複数のコメント (comments) を付加することができ、それらをまとめて1つの解答として送信することができる。
しかし、有用性に掛けることやUI上分かりづらい, 実際に使われなかった等の事柄を勘案した上で、解答に対するコメントは1つのみとし、即座に採点待ち状態になるようにする。

contest.yml に従った動作をするようにする

現状では管理ユーザは新規グループを追加できるが、登録済みのグループが編集できない。
グループの説明やボーナスの点数変更などができないのは問題では？

MarkingRequest モデルを追加, 1 Answer : 0 or 1 MarkingRequest

POST /api/answers/:id/marking_request で採点依頼を出すようにする

問題詳細ページにおいて、UX向上のために質問を状態ごとにソートしたい

• 質問の状態順 (上から、未解決の問題, 対応中の問題, 解決済みの問題)
  • 状態の中では新しい順に

PUT Request for endpoints needs parameter *_id doesn't work properly.

For example:

• /api/answers has fields: member_id and team_id
  • these are relations to Member and Team in Answer class
• /api/answers requires fields member and team but these parameters are filtered
  • only fields member_id and team_id are passed through attribute_values_of_class

[1] pry(#<AnswerRoutes>)> params
=> {"problem_id"=>"10", "team_id"=>"1", "splat"=>[], "captures"=>["5005"], "id"=>"5005"}
[2] pry(#<AnswerRoutes>)> attribute_names_of_class(Answer)
=> [:problem_id, :team_id]
[3] pry(#<AnswerRoutes>)> attribute_values_of_class(Answer)
=> {:problem_id=>"10", :team_id=>"1"}
[4] pry(#<AnswerRoutes>)> Answer.required_fields
=> [:problem, :team]
[5] pry(#<AnswerRoutes>)> satisfied_required_fields?(Answer)
=> false

answer.comments == [] な answer を completed: true にすることは意味がないので、禁止するべき

answer.updated_at + contest.answer_reply_delay_sec が解答の開示時刻

フロントエンドの実装上、API そのものを N+1 のように叩くことが避けられていなかったので対処する

対処法: /problems や /issues などのエンドポイントに関連するエンティティを埋め込む

• 最低限、 @kyontan 不在でも運用ができるようにする
• コードを書く人間の引き継ぎ
  • UI
  • API

できるといいですね……

https://github.com/kyontan/ictsc-score-server/blob/d644dde76c5077c6f8add17ebd6198e4346f9293/ui2/src/pages/Issues.vue#L35

新デザインに合わせて修正

1000文字なのでもう少し増やした方がよさそう

得点と解答ページ経由で問題ページへ移動した際に、解答欄が表示される。
実際に送信することはできないが、送信を試行することができるため非表示にする。

採点待ち時間が経過した後は、Participants による

• GET /api/answers
• GET /api/answers/:id

に score を含める必要がある。

contest.yml に従って表示時間を制御できるようにする

現状では /api/notification をたたくことで幾つかの通知は得られるが、これではポーリングによるフロントエンド実装しかできない。
結果として、ユーザ数x(1/更新頻度)/sec のリクエストが飛ぶことになるため、望ましくない。

理想としては、SSEやWebSocket を使用して通知を行うようにするべき

現状では、 config/contest.yml に設定を書いている。
そのため、コンテナで動かす場合やテストの際にファイルを上書きする必要がある。

これを環境変数で渡すようにすることで、容易にパラメータの変更が行えるようにする。

参加者は、 answer: completed な Answer に対し、新たに Comment を作成できてはならない

ログイン画面でUI側のパラメータが正常に設定されないために、ログイン後に不必要な項目が表示されている場合がある（一般ユーザでログインした場合に、解答一覧のリンクが表示される等）。

/api/notifications を ICTSC7 仕様に修正する

• score にファーストブラッドの属性を付加する
• /api/scoreboard にファーストブラッドを反映した点数を返す

主にリファクタリング

公開するチーム

• 上位Nチーム #145

それぞれの公開情報

• チーム名
• スコア

🤔

GET /api/scoreboard

自チームの1つ上の順位のチームが複数あるとき、自チーム順位とそれらのチームの順位は2以上開くため、それに対応する。

• 完答ボーナスは固定値でよいため、 contest.yml にて定義するようにする
• ProblemGroup に属した問題へすべて基準点を越す解答をした場合に対象のボーナスを与える
• ボーナス点は、その問題グループ内の問題全ての基準点を越すことになる最初の問題に与えられる
• 他チームには影響を及ぼさない

現時点ではメンバー登録において、チームIDは必須でない

この操作を、ログインしてない状態で行う際には、チームIDを必須にすべき

• 会社の概念
  • API
  • フロントエンド
• 採点結果の公開遅延
  • API
  • フロントエンド
• スコアボード
  • API
  • フロントエンド

http://localhost:3000/api/teams/:team_id?with=answers-score にアクセスすると全チームの回答状況を閲覧可能

各種設定(仕様)をAPIで変更できるようにする

• スコアボード #133
• 問題の公開設定 #136
• UI #134 cliからやればよさそう
• 設定をDBに保存する #135

problems?with=answers,score で情報は取れるはず

http://www.atmarkit.co.jp/fsecurity/special/167ctf/zu01l.jpg

こういうのあったらいいですね 🙏

問題 / 質問等のコメント等に対して画像等のファイルを添付できるようにする

/comments/:id/attachments
/problems/:id/attachments```

ICTSC8 のルール にそって用語を変更する

contest.yml を参照して、/problems を制御する

競技時間終了後には、採点依頼のあるなしにかかわらず、一切のスコアを表示できなくする

現状では、それぞれの問題で満点が決まっているにもかかわらず、満点以上の点数をつけることができる。
そのため、採点者側のミスで満点以上の点を与えてしまう可能性がある。

なので、uiとapiの両方（またはどちらか）で満点以上の点数をつけられないよう、チェックを追加する必要がある。