Railsポートフォリオレビュー会を開催しました
スパルタコースでの取り組みの紹介です。
先週に続きポートフォリオレビュー会を行いました。
オリジナルアプリポートフォリオレビュー会 | TechEssentials
ジャータンのアプリポートフォリオレビュー会
サービス概要
https://github.com/katonaoya/netatyou_app/blob/develop/学んだこと/サービス概要.md
テーブル設計
https://github.com/katonaoya/netatyou_app/blob/develop/学んだこと/テーブル設計.md
heroku
https://netatyou-app.herokuapp.com/users/new
現状の問題点と今後の改善点
- UIがしょぼく、見づらい部分が多い。
- お笑いライブを開催するというニッチなサービスであるため、ライブの知識等がないと分かりづらいかもしれない。
- 知り合いレベルの狭いコミュニティで利用することを目的として作成したため、
レビュー・コメント
サービス面
だいそん
- 原体験からくる課題解決はとても良いアプローチだと思います
- 誰かに使ってもらったりしましたか？
- 「チーム」とか「組織」とか「サークル」的な概念は不要でしょうか？
todaka
- 自分の感じた課題をサービスに落とし込んでいて凄いなってと思いました。
- お笑いは詳しくないですが（しかも作り手側は特に！）、同様の課題を感じている芸人さんはいそう。
- 「ネタ帳 アプリ」でググってみましたが、既存のサービスはあまりなさそうな印象（リサーチ不足ならすみません）。
- ネタ作りの記事を少しだけ読んだ範囲では、①日常の思いついたメモをひたすらメモする、②マインドマップを作成する、の記事を見かけました。
- 上記①は、追加機能としては比較的簡単そう。②は難しそうですね💦
- ネタ作りに直接関係ないものは省いた方が、開発も利用もしやすい気がします。
- （個人的な好みですが）趣味など、この場での交流を前提とする情報は省いても良さそう。
Shun
- 身近に感じた課題を解決するアプリになっており素晴らしいなと感じました。
- エラーで登録できず中身を確認できなかったので、設計から思ったことを綴ります。
- ユーザー登録で芸人かスタッフかを選択していましたが、どちらも兼任する場合はアカウントが2つ必要になるんですか?
- そのような意図がなかったなら余計な指摘となってしまいます...
- 上のtodakaさんの意見の不随になるのですが、
- 個人の趣味などの情報があってもいいと思いますが、アプリ作成の目的で「スタッフの方が出演者の情報をまとめたり」と書いてあったのでunitテーブルにも紹介文が必要だなと感じました。
carolina
- 「お笑いライブ管理アプリ」という題材が珍しくてとても心惹かれました！面接時の会話のネタになりそう
- アプリをクローンして動かしてみたんですが、seedデータにこだわっててネタまで入っててすごかったです（本物のネタ？）
jin
- ToDoアプリ？をお笑いのネタ帳に特化して作っている点がおもしろい！
- パスワード確認のフォームがあってもいい気がします
- ルートページにアクセスすると、ログイン状態だとユーザーの詳細画面が表示されますが、サービスの内容が一目で分かるページの方がよかった
- UIに悩まれているようでしたらTailwind CSSをおすすめします（布教）
https://github.com/aniftyco/awesome-tailwindcss - 「所属」とは事務所のこと？ 必要な情報なのかどうか
みけた
- 芸人愛を感じました。テレ東が好きそうだなと思いました！
- seedデータにこだわっており、そういう姿勢がいいなと思いました！
- ログインしていないユーザーが、出演者やライブ情報を閲覧できるとよりよくなりそう
- パスワードを忘れたら、人生が終わるのが辛かったです・・・
みやいち
- プロフィール編集する際にパスワードを変更しない場合でもパスワードのバリデーションがかかってしまう？
- 生年月日を登録する場所が見当たりませんでした（スタッフだから？）
技術面
だいそん
テーブル設計について
- テーブル設計のマークダウンについてですが、データ型が一番左にあるのがちょっと違和感感じました。絡む名が一番左にあった方が見やすいと思いました。
- ネタテーブルにminuteとsecondがありますが、分ける必要はありますか？
- Liveテーブルに「会場」や「会場にある道具」カラムがありますがこれは「会場」テーブルに切り出した方が良い？
- 「コメディアン」テーブルはおそらく「出演」テーブルという命名の方が適切かと思いました。
- 「スタッフ」テーブルの「position」カラムは「role」の方が適切かと思いました
- 「ユーザ」テーブルに「main_unit_id」とありますがメインじゃないunit_idもあるんでしょうか？
- 「ユーザ」と「ユニット」は多対多の関係にした方がunit_idのNULL許可を防げるのでおすすめ
- 「ユーザ」テーブルの「role」はstringじゃなくintegerが良いかと思います。enumなら。
- 「Relationship」テーブルの「勧誘」と「参加」ってどういう意味でしたっけ？
UIについて
- ご自身でも書かれている通り見た目の改善は必須かなと思いました
- 有料テーマを買っちゃうことをおすすめします...
- 無料でもたくさんテーマはあるっちゃあります
その他
- メール送信元をgmailにするのはやめた方が良さそう。
- rubocop入れましょう
- RSpec書きましょう
- REAME書きましょう
- 独自ドメイン取りましょう
- 外部キー作るときにinteger使っちゃってる。なので外部キー制約がついてない&インデックスも貼られてない
- 404画面や500画面がデフォルトのままになってるのでサービス感を出すならちゃんと作った方がよいです
- https://netatyou-app.herokuapp.com/units/2/edit で他の人のunitが編集できてしまう
- 芸人 かつ スタッフという状況がありえるならRoleテーブルとして別だしした方が良いかも？
- いろんなアカウントでログインしたい場合はany_loginというgemを入れると良いですね
todaka
- netaというモデル名は再考の余地がありそうです。
- 該当する英単語はいくつかありますが、「scienario」「material」あたりが候補になりそうです。（materialは個人的にはあまりしっくりきませんが笑）
- https://jp.quora.com/%E3%83%8D%E3%82%BF-%E3%81%AF%E8%8B%B1%E8%AA%9E%E3%81%A7%E4%BD%95%E3%81%A6%E8%A8%80%E3%81%86%E3%81%AE
- ルートパスを
users#newと設定したのはどのような意図でしょうか？ネタ作りのアプリであれば、一般的なのはnetas#indexかなと思いました。
carolina
- users_controllerのindexアクションが２つある...？
- メアドのドメイン、自分で取得しているものでなければ、誰かが使ってるかもです（user登録したら認証メール送信する仕様みたいなので気になりました）
- 思わぬ事故防止！開発時やテスト時に使用するメアドのドメインは example.com に統一しよう - Qiita
netatyou_app/db/seed.rb 〜省略 email: "matumoto@mail.com" 〜 - DB側にはユニーク制約が付いてますが、アプリ側には一意性のバリデーションがないのが気になりました
- application_controller.rbの
geinin_requiredメソッドは、comedianと表記を統一したほうが見やすいかも？
Kei
色々と間違いがあるかも知れませんがよろしくお願いします。
- Userテーブルのmain_unit_idですが、メインではないunit_idもあるのでしょうか？一人がいくつかのコンビを組むこともできるという想定ですかね？
- カナ検索できるように想定してUnitテーブルににkanaカラムを作ったのはユーザに優しいと思います（難し読み方をするコンビ名とかありそう）。
- 「Neteテーブルのitemカラム」と「Liveテーブルのitemカラム」は道具が複数ある場合も想定したほうが良いのではないかと思いました。それぞれ別テーブルが必要？
- Staffテーブルのroleカラムも同様で、1人が複数の役割をもつ場合があるのではないかと思います。
- コードのところどころに無駄な改行があるのが気になりました。細かいことですいません・・・
- ログインしていればURL直打ちで他ユーザーの情報更新もできてしまう？
- 見落としていたら申し訳なのですが、ユーザのメールアドレスを一度登録してしまうと変更できない気がします。
- relationshipが中間テーブルであれば
has_many: throughを使うとモデルのインスタンスを扱いやすくなると思います！Userから直接Unitを参照したり、Unitから直接Userを参照できたりできますし、以下のコードもmapメソッドを使わなくても良くなるのかなと思います。
# app/views/users/edit.html.slim
- @user.participations.map(&:solicitation).each do |unit|
= f.radio_button :main_unit_id, unit.id, class: 'form_control'
= f.label :main_unit_id, unit.namejin
- メール認証が本番環境で実装されていてすごいと思いました！（自分はやったことないので...）
- neta(ネタ)よりideaとかdraftの方が分かりやすい気がしました（実務では英語で統一？）
- herokuは画像が一定時間で消えるのでs3など外部ストレージに
- コントローラーにある
@neta = Neta.find(params[:id])のような複数回登場する記述は、before_actionでDRYにするのがいい
https://pikawaka.com/rails/before_action
みけた
- 乗っ取りに成功しました！
- これはありがちなミスなので注意しましょう
- ただ、user1のまっちゃんを乗っ取ってしまったのは配慮にかけていました
- 大変申し訳なかったです。スープレックスの刑を受けます。
- メール認証部分ですが、update_attributeをなぜ使っているのか気になりました
- validationやcallbackを避けたい？
class AccountActivationsController < ApplicationController
skip_before_action :login_required
def edit
user = User.find_by(email: params[:email])
if user && !user.activated? && user.authenticated?(params[:id])
user.update_attribute(:activated, true)
user.update_attribute(:activated_at, Time.zone.now)
session[:user_id] = user.id
redirect_to user, notice: "アカウントを認証しました！"
else
flash[:danger] = "アカウントを認証できませんでした。"
redirect_to login_path
end
end
endhttps://netatyou-app.herokuapp.com/account_activations/WkUybYWAPlT47SMTCZDJPw/edit?email=hrkedz%40gmail.comスパルタコースではこんな形でメンティーさん同士でフィードバックをしながら切磋琢磨していってます。
少しでも興味をお持ちであれば気軽にメッセージをいただければと思います。
