toshi-ue / app_for_job_change Goto Github PK

概要

Railsのユーザー認証系のgem devise を導入する。

タスク

• gemをインストール
• 設定は後々でよい

概要

Procedure(手順)モデルのCRUDを作成する

タスク、変更点

• ProcudureのCRUDを作成
• Foodstuffのcreate, update後の遷移先をProcedureのnew, editアクションに変更する -> 今回は見送り

概要

料理手順画像テーブル(Procedureimage))を作成する

関連issue

全テーブルの作成 #19

概要

配色表などのツールを利用してデザインを検討、選定する

Why
デザインが類似サービスと酷似するのを避けるため

タスク

• デザインカラーの決定(他者と酷似していることを避けたデザインにする)
  • 配色ツールなどを参考にする
  • kurashiru、cookpad、delishkitchenのモバイルアプリと比較する

結論

Ronchi & Double Colonial Whiteをデザインカラーとする

概要

加工された状態モデル(Cookedstate)のCRUDを作成する
ただし管理者(Manager)側のみの機能とする。

タスク、変更点

• destroyは論理削除用gemを使用する

  「paranoia」は使用非推奨なので、論理削除に「discard」を使う（Rails） - ryotaku's Tech Blog

• 変更履歴を終えるように
• ログ追跡のためにpaper_trailを導入

  Railsで監査ログやバージョン管理機能を追加するPaperTrailの使い方をまとめてみた - Qiita

概要

デザインフレームワークBootStrap4を導入する

タスク

• BootStrap4をインストール
• BootStrap4の設定を追加

概要

users/cuisines/showページに追加する

概要

食材区分テーブルを作成する

タスク

• テーブルを作成 #19

概要

原材料モデル(Rawmaterial)のCRUDを作成。
ただし管理者(Manager)側のみの機能とする。

タスク、変更点

• destroyは論理削除用gemを使用する

  「paranoia」は使用非推奨なので、論理削除に「discard」を使う（Rails） - ryotaku's Tech Blog

概要

sass-railsが非推奨になったため、代替のsassc-railsに変更する

タスク

• sass-railsを削除
• sassc-railsをインストール
• sassc-railsに関する設定を行う

概要

料理食材(Foodstuff)のCRUDを作成する

概要

user情報、managerの情報が不足しているためタイトル通りのカラム名を追加する

タスク

• userモデルにnicknameカラムを追加 <- すでに存在
• userモデルにavatarカラムを追加
• managerモデルにnameカラムを追加

What
development、test用の設定などを追加する
Why

• パフォーマンスを落とさないため
• 開発スピードを上げるため

タスク

development

• bulletの設定を追加
• 【Rails】プロジェクトを作ったら追加したい設定やgemファイル - Qiita

test

• railsコマンド実行時のスペックファイル自動生成の設定を変更
  • modelspec
  • controllerspec
  • featurespec
  • requestspec
  • systemspec
  • jobspec
  • mailerspec

追記: 取り消し線が引かれたものは設定自体がありませんでした

概要

環境構築したが動作しない物を列挙、時間があれば解決に時間を割くこと

未解決の項目

• docker環境で gem better_errorsが動作しない
• systemspecがjs: trueの時にcapybaraのメソッドを認識しない
• jQueryが動作しない(もしかしたらjs関連全てが動作しない可能性あり)
• node_modulesに"@fortawesome/fontawesome-free"が追加されない
  • rails newで作成するときに(--skip-yarnオプションをつけてしまったことが原因?)
    • 関係なし、VSCodeとDockerによる反映が遅いことが原因と思われる
  • BootStrap4のCSSは適用できている

概要

単位テーブル(Unit)を作成する

Why
材料の単位は共通点が多いため

変更

とりあえずenumで対応してみる

関連issue

全テーブルの作成 #19
原材料テーブルの作成 #24
料理食材テーブルの作成 #27

概要

必要な設定などの取り込みが必要なためbranchをmergeする

概要

Foodcategoryのvalidationのテストを実行する

タスク

• 料理区分名(name)があれば有効(作成できる)
• 料理区分名(name)がuniqueであれば有効(作成できる)
• 料理区分名(name)が重複していれば無効(作成できない)
• 料理区分名(name)がuniqueでなければ無効(作成できない)

概要

冷蔵庫の食材を登録するためのモデルを作成する

Why
もここに書くと良いと思う

タスク、変更点

• Stockモデルを作成する
• 下記の登録ができるようにする
• 原材料
• 個数
• 登録日

概要

gem slim-rails を導入、設定する

Why
パフォーマンスを少しでも向上させるため

追加タスク、変更点

• slim-railsのインストール
• 設定の変更 <- gemをインストールするだけでokでした
• viewファイルの変換

概要

Cuisine(料理レシピ)モデルに公開、非公開機能を付加する

タスク、変更点

• ユーザー側の公開, 非公開を選択できるようにする
• Cuisine, foodstuff, procedureモデル全てに関連するレコードがなければ公開できないようにする

概要

部位名テーブル(Ingredients)を作成

参考サイト

• AdminLTE2をRails5.1/yarnで動かす - Qiita
• 保守性の高い管理画面のデザインを考える－AdminLTE3 | isystk's blog

概要

エラーメッセージがBootStrap4に未適応のため適応させる

タスク

• エラーメッセージを共通化
• BootStrap4に対応させる
• managers/foodcategoryの各formに適応
• managers/ingredientの各formに適応

備考

• 下記のままではBootStrap3の記法のままなのでBootStrap4用に守勢する

ref

• RubyonRails:deviseのエラーメッセージをカスタマイズする方法 - Madogiwa Blog
• devise専用エラーをbootstrap3のエラーと同様に表示する - Qiita

追加タスク、変更点

• userのサインイン
• userのサインアップ
• managerのサインイン
• managerのサインアップ

概要

料理履歴テーブル(Cookinghistory)を作成する

関連issue

全テーブルの作成 #19

概要

食材区分(FoodCategory)モデルのCRUDを作成。
ただし管理者(Manager)側のみの機能とする。

タスク、変更点

• destroyは論理削除用gemを使用する

  「paranoia」は使用非推奨なので、論理削除に「discard」を使う（Rails） - ryotaku's Tech Blog

概要

料理食材(Foodstuff)のCRUDを修正

追加タスク、変更点

• 食材ジャンルと原材料を連動させる -> 不要になった
• 食材ジャンルと部位名を連動させる -> 不要になった
• 原材料をインクリメント検索させる(値はセレクトボックスの中からし
  か選べない) -> 不要になった
• 単位カラム用にテーブルを作成するか、enumで実装するか検討する -> Unitモデルを作成する

概要

作成者に進捗を伝えるためのプログレスバーをつける

Why
もここに書くと良いと思う

追加タスク、変更点

• cuisineのcrudにつける
• foodstuffのcrudにつける
• procedureのcrudにつける

概要

料理食材テーブル(Foodstuff)を作成する

関連issue

全テーブルの作成 #19

概要

Deviseを利用して管理者ログイン機能を実装する。
ただし、作成済みの管理者を利用した「テスト管理者ログイン機能」も追加すること
Why
評価者の不要な労力を省くため

タスク

• Deviseによるログイン機能(メールアドレス、パスワードの実装)
• テストユーザーログイン昨日の実装

付加タスク

• メール確認・認証機能
• アカウントロック
• パスワードリセット機能

概要

ユーザーと管理者のモデルを作成する。

Why
テーブル作成時にユーザー、管理者のidがインデックスなどで多用されるため

追加タスク、変更点

• Deviseの設定再確認、修正
• ユーザー、管理者のMVCを作成(ジェネレータを使用する)
  • 下記を参考にするとわかりやすい
    • [Rails] deviseの使い方（rails5版） - Qiita
    • Railsでdeviseひとつで複数モデルを管理しよう - Qiita

概要

コーディング規約を守りながらコーディングするためのgem rubocopを導入する(ただし、場合によっては修正する場合あり)。

タスク

• rubocopの導入
  • .rubocop.yml
  • .rubocop_todo.yml

概要

フードロス機能の要件

• 料理したレシピをユーザーと紐づけて登録する
• 使用した食材をカウントする
• stockモデルで賞味期限が近いものを優先して料理レシピを自動生成する

概要

手順テーブル(Procudure)を作成する

概要

RailsとDockerの環境構築をする

Why

• Dockerを使用しているWeb系企業が多いらしいから
• AWSなどでスケールさせるときに相性が良い

タスク

• Dockerで作成したRails環境が動作できるようにする

  • Dockerfileの設定
  • docker-compose.ymlの設定
  • .gitignoreの作成

• プロジェクトをオプションを付与して作成する

  • DB:MySQL
  • yarnは使わない
  • coffeescriptは使わない
  • turbolinksは使わない
  • minitestは使わない
  • bundle install をスキップさせる

タスク

• app/assets/sample_logo_image.pngの置き換え

概要

現在下記はそれぞれ独立したcrudになっているがそれを一通りのフローにする

• cuisine
  • foodstuff
    • procedure

追加タスク、変更点

• Cuisineのcreate, update後の遷移先をFoodstuffのnew, editアクションに変更する
• FoodStuffのcreate, update後の遷移先をProcedureのnew, editアクションに変更する

注意点

• 食材の登録がないと公開できないようにする
• 手順の登録がないと公開できないようにする

概要

肉などの部位名を登録するためのフォームを作成する。
ただし管理者(Manager)側のみの機能とする。

タスク、変更点

• destroyは論理削除を使用する

  「paranoia」は使用非推奨なので、論理削除に「discard」を使う（Rails） - ryotaku's Tech Blog

概要

N+1問題をほぼ検知してくれるgem bulletを導入してSQLパフォーマンスの低下を防止する

タスク

• gem bulletの追加
• bulletの設定をする

ref

• 開発者のタスク管理をGitHubで行ったらうまくいった話 | Developers.IO
• GitHub の Issue 運用が助かるラベル 26 個 #Zaim｜watura

概要

料理テーブルモデル(Cuisine)のCRUDを作成する

概要

Deviseを利用してユーザーログイン機能を実装する。
ただし、作成済みのユーザーを利用した「テストユーザーログイン機能」も追加すること
Why
評価者の不要な労力を省くため

タスク

• Deviseによるログイン機能(メールアドレス、パスワードの実装)
• テストユーザーログイン昨日の実装

付加タスク

• メール確認・認証機能
• アカウントロック
• パスワードリセット機能

タスク

• gem ranked_modelを使用すること

概要

全体の起点になるMVCを作成する

追加タスク

• scaffoldを使わない
• indexアクションのみでよし
• デザインはあとで

概要

deviseのconfirmable, lockableを一時的に無効にする

タスク

• user
• manager

概要

原材料テーブル(Rawmaterial)の作成する。

• 栄養素テーブルとひもづけること
• 単位テーブルとひもづけること

調査リスト

• jQueryでのeslint, prettierの設定

• enumのvalidationはどうすれば良いのか 該当箇所

  • ここ から ここ �へとんで読んでみたが結局どれがbetterなのか?

• modelのvalidation, enum, associationの順番について 該当箇所

  • どの順番が良いのか?

• Bulletの警告を修正する方法 (該当箇所)

  • このshowアクションでは@cuisineインスタンスだけでなく、@foodstuffs, @proceduresなどインスタンスを複数利用した方がよいのか

RequestSpecの書き方について - 該当箇所

• RequestSpecの管理者アカウントの初期作成について(必要ないのか、あるのか?)
• RequestSpec-インスタンスが存在しない場合のテストについて(必要ないのか?)
• なぜ管理者としてログインしていないのにテストをパスするのか?
• updateアクションの異常系のテストは必要ないのか?

Why
だれが何をどのように変更したか確認できるようになるため

タスク

• 使いかたを調べる
  • ref: Railsで監査ログやバージョン管理機能を追加するPaperTrailの使い方をまとめてみた - Qiita
• 論理削除をするかしないか決める(discardの削除を検討)

概要

現在考えられる限りのテーブルを作成する

Why

• ユーザー、管理者テーブルができたので全テーブルを作成できる下準備ができた
• テーブルが完成していないと機能の実装に遅れが出そう

タスク(テーブルの作成)

• 料理テーブル(Cuisine) #29
• 料理食材テーブル(Foodstuff) #27
• 原材料テーブル(Rawmaterial) #24
• 食材区分テーブル(FoodCategory)
• 栄養素テーブル(Nutrient)
• 部位名テーブル(Ingredients) #25
• 加工された状態テーブル(Cookedstate)
• 手順テーブル(Procudure) #26
• 料理手順画像テーブル(Subimage) #28
• 料理履歴テーブル(Cookinghistory) #30

追加タスク

• 食材区分テーブル(FoodCategory)のカラム名を
  • manager_id -> applicant_idに変更する

概要

Rails全体を日本語化する
他のタスクを最優先にし、時間がある時に修正する
時間がない時はタスクに追加していくこと

タスク

• [ ]
• [ ]
• [ ]

概要

料理テーブル(Cuisine)を作成する

関連issue

全テーブルの作成 #19