Railsポートフォリオレビュー会を開催しました。
1ヶ月ぶりにポートフォリオレビュー会を行いました。
Railsオリジナルアプリの概要, 画面設計, テーブル設計, コントローラ設計のレビュー会 | TechEssentials
アプリの概要
テーブル・コントローラ設計
画面遷移図
https://www.figma.com/file/OaalsFwEVusbBih2VOQ0sJ/Untitled?node-id=0%3A1
レビュー・コメント
概要について
だいそん
少し辛辣かもですが
- 目標設定 & ご褒美というアイデア自体はあるあるで真新しさはない。
- ご褒美というのが本物なら課題解決にはなりそうだけど擬似的なものなのであればエセ課題解決で終わりそう。(インセンティブ設計（ユーザーが何でそのアプリを使うのか）がちょいと物足りないなと思いました)
- とはいえ面白いアイディアはなかなか思いつかないもの。アイデア出しで詰まって時間を浪費するくらいならとりあえず手を動かすべきなのでコーディングしちゃいましょう。
- 自分だったら...
- 「勉強が苦手な人」というターゲットが広すぎるので「プログラミング学習者」に絞る
- 短期的な目標は運営側が用意してしまう。（e.g. QAアプリが作れるようになっている, インスタクローンが作れるようになっている。）
- その目標達成のためにやるべきことを各ユーザーが決める
- 最後に「アイデアは移動距離に比例する」 by 高城剛(https://abroader.asia/2021/10/01/idea-idou/)
- 似たような話で良いアイデアはWebサービスをたくさん使わないと出てこない
todaka
- Slackでやり取りがあった通り、アプリの企画は難しいなと改めて感じました。
- 色々と盛り込むと機能が複雑になり、ユーザーが登録を面倒くさがりそうな気がします。ゆうすけさんが感じる課題を深掘りして、機能を限定するのが良いかなと思いました。
jin
上から目線で失礼します
- 「studyplusみたいに」とありますが、そことの差別化をどうするのか
- 「ポイント」がただの数字だったら、使う側はすぐに飽きてしまう（お金とかだったら別ですが笑）
- アウトプットとして作成するにはいいと思います！ポートフォリオには向かないかもです
Kei
- 「連続ログインボーナス」という名称ですが、毎日アプリにログインすればボーナスポイントがもらえるという印象を受けましたので別名にしても良いかもしれません（「毎日タスク達成ボーナス」とか？→センスなくてすいません、、、）。
maki
- 自分でご褒美を設定して、ポイントを獲得して達成していくのは面白いと思いました！ただ、アプリ内でももっとポイントを貯める楽しみがあってもよいのでは...?と思いました。(例：凡庸ですが、ポイントに合わせて応援メッセージがもらえるとか、アバター画像が強化されるとか。。。)
mori_ryo
- タスク実行時間は学習時間ということなんですね。期限があるタスクもあってもありかも。
- 目標達成で考えるなら、やらなければなにかをやらなければいけないという罰ゲームをTwitterとかにつぶやいて、期限が迫ってきてやらざるを得ないというのはどうでしょう。できるだけ恥ずかしいやつとかをランダムで決められてやらないといけない。
- あいつやってのか〜って監視の目があるとモチベーションも高く保てそう。。 勝手なこと言ってすいません。。。
テーブル・コントローラ設計について
todaka
- ポイントや時間のカラムはUserモデルから切り離しても良いかと思いましたが、時間数やポイントの合算値をどう扱うのが適切かわかりませんでした。
- Userモデルに
total_study_timeやtotal_pointを設けると、過去の履歴が追いづらくなりそうな印象。 - Userに従属するモデルを作って都度合算値を取得すると（ポイント台帳のようなイメージ）、合算値の内訳を把握しやすくなるので、信頼性は上がりそう。
- ご褒美を取得してポイントを減算するときの処理はマイナス値を登録するとか？
- Userモデルに
だいそん
- 即席で見ます
機能を追加する
POST /functions/1/registration
POST /functions/2/registration
POST /functions/3/registration
POST /functions/login_bonus/registration
yoshio
- ER図はデータ型があったほうが良いかなと思いました
- time関連のカラム名は「〇〇_at」とかの方がrailsっぽい。例：start_at
- 外部キーも記載しておいた方が良いかも
- ポイント関連は別テーブルを作成した方が管理しやすいと思いました
Kei
- 細かいことなのですが、Railsではテーブル名は複数形が基本のようです。
- 「ユーザーがどの機能を使っているか」のデータは、Usersテーブルとは別テーブルを用意して関連付けを行っても良いのかなと思いました。
- users -< user_functions >- functions
- functions(3レコードできるイメージ)
- id
- name(ログインボーナス機能 or ボーナスタイム機能 or 時間記録機能)
- user_funcitons
- id
- user_id
- function_id
- yoshioさんと同意見ですがポイント系や時間系のデータは別テーブルに分けた方が良いと思います。
- 質問になってしまって恐縮なのですが、「Usersテーブルの
finish_bonus_timeカラム」と「Tasksテーブルのfinish_timeカラム」のデフォルト値が「現在時刻 + 1」となっている理由を教えていただきたいです。
maki
検討違いの指摘でしたら申し訳ないです。
- User,Task,RewardテーブルはそれぞれIDのような一意になる項目(PK)はなくてよいのでしょうか？
- Task,RewardテーブルはUserと紐づくものでしょうか？どのカラムで紐づけているのでしょうか？
- 細かいですが、Taskのgetting_pointがデフォルト1なのが気になりました。0の方がよいのでは？
- Userのusing_functionで「ユーザーがどの機能を使っているか」とありますが、具体的にはどう判定するのでしょうか？機能に対応する文字列が入る？
- 連続ログインボーナス機能の「ユーザーがログインボーナス機能を使用しているて、その日に投稿したtaskのcreate_atの日数からマイナス１日したcreate_atカラムのあるtaskがあれば連続ログインなのでポイントがもらえる」ここが理解が追い付かず。。。口頭でフォローいただけると助かります。
たいしろう
users_contoroller
def calculate
if current_user.using_function.include?('login_bonus') || current_user.task.exist?(created_at: :今投稿した物の-1日)
User.total_point += Task.getting_point + User.login_bonus_point
else
User.total_point += User.getting_point
end
end User.total_point += Task.getting_point + User.login_bonus_point-
各ユーザーに対しての操作の場合は、インスタンスに対しての操作になるのでクラスメソッドは使わない方がわかりやすいかと思います！
-
User(集合)に対して操作を行うメソッドとcurrent_userとか(個別)に対しての操作を行うメソッドの使い分けできたらすごい良いと思うので、意識して見て下さい！
-
時間に関するものは ~atとかで名前を統一したらチームで開発する時にいいねってなりそうです！
-
画像のアップロードは、結構方法がたくさんあるので、色んな方法を調べて置いたら面接とかで深い話ができそうです!
- ダイレクトアップロード、S3署名付きURL, CloudFront署名付きURLとかのワードでググると良いかもです。完全に理解は難しいですが、調べてるだけでもとても勉強になります！
画面遷移図について
だいそん
- タスクの編集画面はない？
- 「タイトル」「本文」のようなダミーテキストよりリアルなテキストの方がわかりやすいです
- 貯めたポイントはどこで使う？
- 獲得したご褒美を閲覧できる画面がない？
- ログインボーナス機能, ボーナスタイム機能について、単純にポイントが多くもらえる可能性が高くなるならみんなオンにしない理由がない気がする
- ご褒美は問答無用で削除できちゃうとまずそう。
jin
- タイマー？ストップウォッチ？みたいなのがありますが、数字をブラウザ上で変化させるとなるとrubyだけでは厳しいので、jsが必要
- 同じ目標を掲げる人同士でグループを作れる機能があれば、孤独感は和らぐ？
maki
- ユーザ名、emailは編集できないのでしょうか？
こんな形でメンティーさん同士でフィードバックをしながら切磋琢磨していってます。
少しでも興味をお持ちであれば気軽にメッセージをいただければと思います。
