bootcamp
bootcamp copied to clipboard
[ペアプロ]ペアプロ募集をアプリ側でサポートする
現状、ペアプロ募集と立候補はDiscordで運用しているが、募集が重なるとどの募集が完了して、どの募集が未完了なのか把握しづらくなる。
なのでアプリ側でペアプロ募集と立候補を管理できるといいかもしれない。
設計としてはQ&Aのようなイメージ?
- 募集する
- 立候補する
- 立候補してくれた人にお願いする(完了)
- 募集をキャンセルする(完了)
設計については実際にペアプロを活用してる人に聞くのがいいと思います。
このissue|PRは60日間更新がないため7日後にcloseします。closeしたくない場合はstaleラベルを外してください。
これ、あった方がいいかも。
このissue|PRは60日間更新がないため7日後にcloseします。closeしたくない場合はstaleラベルを外してください。
このissue|PRは60日間更新がないため7日後にcloseします。closeしたくない場合はstaleラベルを外してください。
このissue|PRは60日間更新がないため7日後にcloseします。closeしたくない場合はstaleラベルを外してください。
このissue|PRは60日間更新がないため7日後にcloseします。closeしたくない場合はstaleラベルを外してください。
このissue|PRは60日間更新がないため7日後にcloseします。closeしたくない場合はstaleラベルを外してください。
@wata00913
https://esa-pages.io/p/sharing/79/posts/3378/b7503f2978a6c50d2dfa.html ざーっと仕様をまとめました。
wataさんには、
- DB設計
- ペアワーク相手募集を投稿する機能
- new、edit で投稿が追加、編集できる
- 一覧ページに投稿が表示される
- 個別ページに投稿が表示される
までをお願いしたいと思います。
募集に対しての応募や、ペアが決まったときの通知などは別 Issue にします。 細かいところは GitHub でやりとりしながら進めていきましょう。なので、質問や確認事項があった際は連絡をお願いしますー
@wata00913 すいません、少し仕様が変更になります。仕様を書き直したら連絡しますー
@wata00913 修正しました!! 大きな変更は、コメント機能を使って相手を希望するのではなく、カレンダーをクリックして相手を希望する形に変えました。
コメント機能は、他のコメント機能と同じように、単なるコメントのやりとりにだけ使います。
@komagata
お疲れ様です。 こちらのIssueでDB設計が必要なため、ペアワーク関連のリソース設計とDB設計を考えてみました。 レビューの方をよろしくお願いします🙇♂️
今回のIssueの対応範囲は以下となります。
- ペアワーク相手募集を投稿する機能
- new、edit で投稿が追加、編集できる
- 一覧ページに投稿が表示される
- 個別ページに投稿が表示される
リソース
ペアワーク作成ページ | /pair_works/new |
---|---|
ペアワーク一覧ページ | /pair_works |
ペアワーク編集ページ | /pair_works/{id}/edit |
ペアワーク個別ページ | /pair_works/{id} |
DB
追加したテーブルとカラムは以下となります。
-
PairWorkテーブル:ペアワークを格納するテーブル
カラム名 概要 title タイトル description 内容 reserved_at ペアワークの確定日時 user_id ペアワークの依頼ユーザID buddy_id ペアワークの相手ユーザーID -
Scheduleテーブル:ペアワークの希望日時を格納するテーブル
追加したテーブルに関連するER図は下図となります。
erDiagram
PairWork ||..|| User : "user"
PairWork ||..o| User : "buddy"
PairWork ||--o{ Schedule : ""
PairWork ||--o{ Comment : ""
Practice ||--o{ PairWork : ""
PairWork {
title varchar
description text
reserved_at timestamp
user_id bigint FK
practice_id bigint FK
buddy_id bigint FK
published_at timestamp
wip boolean
}
Schedule {
pair_work_id bigint FK
proposed_at timestamp
}
@wata00913 railsの慣例で時間はxxxx_at
、日付はxxxx_on
というカラム名になるのでそれに合わせた方がわかりやすいかなと思います。
@komagata railsの慣例に従って、時間のカラム名を変更しました!
- PairWorkテーブル
- ペアワークの確定日時:reserved_at
- Scheduleテーブル
- ペアワークの候補日時:proposed_at
@wata00913 プラクティスは必要ですかね?(ちょっと仕様がわかってないですが) 他はいい感じだと思います〜!
@komagata
プラクティスは必要ですかね?(ちょっと仕様がわかってないですが)
こちらの仕様書には記載があったのですが、念のため町田さんに確認してみます!
他はいい感じだと思います〜!
ご確認ありがとうございます😄
@machida お疲れ様です!
仕様について質問があります。
ペアワーク作成ページ
の入力項目は、Q&Aページ
と同様に「プラクティスの選択」もあるのでしょうか?
📝 https://github.com/fjordllc/bootcamp/issues/4267#issuecomment-1620816909 について。 町田さんにチーム開発MTGで確認 今後追加される機能を考慮してペアワークページにも「プラクティスの選択」を含めておく。
@wata00913 (CC: @machida )
今後追加される機能を考慮してペアワークページにも「プラクティスの選択」を含めておく。
「今後追加される機能」はどういうものでしょう?
@komagata
「今後追加される機能」はどういうものでしょう?
一覧ページでプラクティスによる絞り込み機能がありますが、他にもあったと思います。。。
@machida すみませんが、ご回答いただけますと幸いです🙇♂️
@machida お疲れ様です!仕様について質問があります。
概要
作成日の翌日以降にペアワークを参照・編集する場合、希望日時の表示ルール(現在の翌日から7日間表示)を適用するかどうかの検討が必要になりそうです。
表示ルールを適用するか否かで考えられるケースをまとめてみました。
- 具体例
- 作成日:「2023-07-25」
- 現在:「2023-07-26」
表示ルールを適用する | 表示ルールを適用しない | |
---|---|---|
参照(開始日) | ケースA:現在の翌日(2023-07-27)から表示 | ケース1:作成日の翌日(2023-07-26)から表示 ※ 開始日以前の候補日をクリックした場合、エラーダイアログを表示する |
参照(最終日) | ケースB:現在の翌日から6日後(2023-08-01)まで表示 ※ 作成日の翌日から6日後以降の候補日はデフォルトで「✗」にする? | ケース2:作成日から6日後(2023-07-31)まで表示 |
編集(開始日) | ケースC:現在の翌日(2023-07-27)から編集可能 ケースD:現在の当日(2023-07-26)から編集可能 | ケース3:現在の翌日(2023-07-27)から編集可能 ケース4:現在の当日(2023-07-26)から編集可能※ 開始日以前の候補日にチェックを入れてる場合、チェックから外す? |
編集(最終日) | ケースE:現在の翌日から6日後(2023-08-01)まで編集可能 | ケース5:作成日から6日後(2023-07-31)まで編集可能 |
質問
案としては、表示ルールを適用したが良いと思いましたが、いかがでしょうか。 ルールを適用しない場合、日を跨いでスケジュールを編集すると候補日が7日以内に限定されてしまい、使い勝手が悪いかなと感じました。
また、別案があればご教示のほどよろしくお願いします。🙇♂️
@wata00913 質問ありがとうございます!!現在の日を基準とした、表示ルールを適用する方でお願いします🙏
@komagata @wata
返信遅れてすいません!!
「今後追加される機能」はどういうものでしょう?
ペアワークに関連プラクティスを紐付ける理由ですが、今後メンターだけでなく、先輩受講生もペアワーク対応ができるようにしたいと考えています。メンターじゃなくても可能みたいなフラグを持たせることを考えています。
その際、
- その関連プラクティスはすでに修了している受講生だけが対応できるようにしたい。
- ペアワーク希望が投稿された際に、そのペアワークの関連プラクティスを修了している他の受講生に通知が飛ぶようにしたい。
@machida (CC: @wata00913 )
なるほどですね。ご説明ありがとうございます。
最初のリリースからその機能をサポートするのであればDB設計に加えて、そうでないとすれば最初はDB設計に含めない方がいいかと思います。その部分を後からDBに追加するのは容易なので。
@komagata
なるほど、そういった大きな機能の計画はあるのですが、今回のリリースの時点でも、ペアワーク募集の一覧が並んだときに、どのプラクティスに関連する作業を行いたいのかをすぐにわかるようにしたいです。例えば、「XXXXで困っています」みたいなタイトルだけだと、それが Ruby に関するプラクティスなのか、JS に関するプラクティスなのかを把握するのに、詳細を読んだりなど時間がかかってしまいます。そのために、今回のリリースの時点でも、関連プラクティスを紐付けるようにしたいと思います。
@machida なるほどです。 どのプラクティスにも関係しないペアワークもあると思うので必須ではないって感じでしょうか?
@komagata 現状では、モブプロ会の参加者募集は別として(モブプロ会参加者募集はこの機能には含めなくていいかと思います)、ペアワークを募集しているのは、自作サービスかチーム開発、あとはRubyのlsかGit関係かJSだと思うのですが、プラクティスに関係ないペアワークって何がありますでしょうか?就活対策については、相談部屋から管理者がメンターに依頼するので、それもこの機能には含めない予定です。
@machida よく考えたら関係ないペアワークはほとんどないかもですね。
@wata00913 DB設計、現状でOKです〜
このissue|PRは60日間更新がないため7日後にcloseします。closeしたくない場合はstaleラベルを外してください。
このissue|PRは60日間更新がないため7日後にcloseします。closeしたくない場合はstaleラベルを外してください。