今まで学んだことを書いていこうかなと思いまして、アウトプット用に記事を書かせていただきます。
1ヶ月目では、html,css,ruby,railsで、基礎を学んできました。
html/cssでは、メディアクエリ、bootstrapを学び、
アプリケーションの作成から、gemの導入、bootstrapの導入などを学びました。
railsで投稿アプリの作成が主でした。
deviseというgemを導入し、新規登録、ログイン、ログアウト機能を実装し、
そこから、投稿、編集、削除といった機能を学んできました。
今月2ヶ月目では、4人でのチーム開発を体験しました。railsで、ECサイトの制作なのですが難しかったです。何が難しかったかと言いますと、githubですね。
コミュニケーションでお互いの進捗を確認し、コンフリクトが起きないようにしていました。
それと、マージ先。作業ブランチなど。
チーム開発においての、gitを理解するまで1日を費やしました。今もまだ完全な理解は遠く及んでいませんけど。
メンバー同士で話し合い、プルリクからマージをするように決めました(慣れていないので)
mainブランチから、developブランチを作り、そこから各作業ブランチを作ってプッシュして、プルリクをするようにしていました。
プルリクを送ってマージをすることでコンフリクトしてもgithub側でその場で直せますので。
長くなってしまいましたね。なぜ急に記事を投稿しはじめたのか。
それは来月からはポートフォリオの作成なので、本格的にアウトプットをしていこうと思ったからです。
まずはメモ代わりに流れと基本的なコマンドを書いていこうと思います。
ちなみに、qiitaで記事にスタイルを適用するにはどうすればいいのだろうか・・・。
アプリケーションの作成
$rails new アプリケーション名
アプリケーションの削除
$rm -rf アプリケーション名
rm .. リムーブの略。
-rf 強制的に実行。
$cd アプリケーション名
cd .. カレントディレクトリの略。ディレクトリを移動できる。
ディレクトリ = フォルダ
作ったディレクトリに移動しないとね。
コントローラの作成
$rails g controller コントローラ名
g .. generateの略
コントローラ名は小文字で複数形
例 rails g controller users
コントローラの削除
$rails destroy controller コントローラ名
ちなみに、ビューも一緒に作れちゃう
rails g controller users index show edit
index show editのビューファイルが自動生成。
モデルの作成
$rails g model モデル名
モデル名は、単数形で頭が大文字。
例 rails g model User
モデルの削除
$rails destroy モデル名
ちなみに、一緒にカラムも登録できちゃう
$rails g model User name:string
カラム名:データ型
データ型
string : 255文字まで
text : 無制限
integer : 整数
float : 浮動小数
decimal : 精度の高い小数
datetime : 日時
timestamp : タイムスタンプ
time : 時間
date : 日付
binary : バイナリデータ
boolean : Boolean(真偽)
ビューは、コントローラと一緒に作るか、手動で作る。
$touch top.html.erb
もしくは、右クリックして新規ファイル作成して名前を打ち込む。
.html.erbは、rubyとhtmlが記述できる特殊なファイル。
データベースにマイグレート(up)
$rails db:migrate
マイグレートをロールバック(down)
$rails db:rollback
マイグレートのup/downの確認
$rails db:migrate:status
マイグレートファイルの削除
$rails destroy migration クラス名
ファイル名ではなく、クラス名を指定する。
データベースは繊細なので、up中は変更しちゃダメ。
必ずロールバックしてから弄ること。弄ると不具合でるよ(経験済み)
チーム開発だと不用意にロールバックすると不具合が出るかも(経験済み)
なぜ不具合出たのか原因がよくわかってないけど、チーム開発時はもうロールバックしたくない。
なので、カラム名が間違えていたり、追加したい場合は、新たにマイグレーションファイルを作る。
テーブルに追加したい場合。
$ rails g migration わかりやすい名前
例 rails g migration AddColumnToUserIntroduction
ユーザーテーブルにintroductionカラムを追加したいんだなーと名前でわかる。
別に、rails g migration gogotea
でも構わない。午後の紅茶好きで、最近はストレート飲んでます。分かりにくいからやめておこう。
(自分は最初勘違いしていて、どこの記事でも書いてあったので、絶対Add~~みたいに書かないとダメだと思ってた(*ﾉｪﾉ)ｷｬｰﾊｽﾞｶﾁ)
作成したマイグレーションファイルに記述する。
def chenge
#追加カラム :テーブル名, カラム名, データ型
add_column :Users, :introduction, :text, null: false
#カラム名を変えたい :テーブル名, :変更前カラム名, :変更後カラム名
rename_column :Users, :name, :nickname
#制約を変更、付与したい場合。
chenge_column_default :Users, :introduction, from: nil, to: false #無制約からfalse(無記入ダメ)に変えたい。
chenge_column_default :Users, :introduction, from: true, to: false #trueからfalseに変えたい(無記入でいいよ(true)→無記入ダメ！(false))
end
チーム開発の時に、上記のような記述をしたんだけど、問題は無かった、が。
今、railsのドキュメントを見て調べたらNULL制約の追加は
change_column_null(:users, :nickname, false)
こんなでした。_defaultは、デフォルト値を追加するものだった。
でも問題なくschemaにも反映されていたから間違いではないみたいだ。
それと、他の人の記事に書いてあったので気になったけど、
migrationで、upメソッドとdownメソッドは特に使わなかったけど、問題は出なかった。
def up def downで、コマンドではなく、記述でロールバックする？
up状態のテーブルをdownにするってことで合ってるのかな
・・・だとしても、ダウンせずにそのままchenge_columnでうまくいったんだよね。
余談ですが、チーム開発で、仲間が上記のmigrationファイル追加したあと、プルリクを送ったところ、schemaがコンフリクト起こして焦った。
しかし、カラムではなく、version日付がコンフリクトしていただけだったので、そこは修正しても問題なかった。
しかし、データベース関連ファイルについて、その時はわかっていなかったので、
schemaはやばいだろ！と思い、メンターさんに質問したら、カラムだったら問題だけど、
そこなら修正しても問題ないよ～と言われた。
正直、コレがなかったら今でもわかっていなかったと思う。
データベース＝繊細なもの と思っているし、Github = 繊細で複雑なものと認識していたので。
今もまだその意識はあるけど、少しはわかってきたかなと思う。
gitのコマンド。
これは、githubに書いてあって、
*git init
git add .
git commit -m "コメント"
*git branch -M main
*git remote origin git@github:~~~~~~
git push origin カレントブランチ(作業ブランチ)
からのdevelopへプルリク
みたいな流れでやってました。
*初回のみ実行コマンド。
githubからダウンロードするにはclone。
git clone リポジトリurl
githubからurlをコピペ！
main
develop
作業ブランチ(feature-customerIndexShow)
git checkout -b 命名規則 (に則った名前が好ましい)
ブランチ作成と同時にブランチ移動する。
add-
feature-
fix-
など命名規則があって、作業にあった名前にする。
仲間がdevelopにマージしたら、
git pull origin develop
git fetch
コマンドはよくわかりませんでした。
リポジトリからコンテンツをダウンロード
pullはfetchとmergeを一緒にやるコマンドみたいなんですが、よくわかってません。
リモートリポジトリの中身を確認したいだけの時ってどんな時なんですか！！
※サル先生参照
なにかアクションする前に確認。
git status
誰かが同じファイルをマージしてコンフリクトしててpullできない！！
そんなときは強制的に最新のリポジトリを取ってくるコマンド
git reset HEAD
※ただし自分の記述した内容が些細な場合のみ。
なんならメモ帳にコピペして避けとけば問題なし。
操作履歴を見る
git reflog
gitコマンドも勉強中です。
あまり詳しくは説明できません。
git reset -soft
-mixed -hard
などありますが、一度hardを使ってgitに怒られまくって(この時、やらかしたのかもわかっていなかった)散々だったので、怖くて使ってないですｗｗ
作業ブランチと、マージ先を間違えなければ、とくに問題は起きませんでした。
あと、コンフリクトしないようにファイルを弄る時は仲間に確認を取ったり。
今日の所は以上にします。
来月からはポートフォリオ制作なんですが、オリジナルアプリって全然思いつかないんですよね。
何がいいのやら・・・。著作権に引っかからず、既存の物と差別化できて、痒い所に手が届く。
・・・いや、浮かばないっすね。自分の感性と想像力が足りていないので、アドバイス欲しいです。