データベースとマイグレーションについて(マインドマップ有)
データベースとマイグレーションまとめ
railsでアプリを作成していく中で、データベースに関する知識が不足していると感じたので、パパッとマインドマップでまとめてみました。今後忘れたら何度も見返そうと思います。
[http://]
データベースとは
データベースは、簡単に言うとデータを保存しておく場所。
複数のデータを整理して管理しておくことで、後から扱いやすい状態になっています。
テーブルと呼ばれる表でデータを管理しており、縦の列のことを「カラム」、1行ずつのデータのことを「レコード」と呼ぶ。
railsでデータベースを作成する際のコマンドはrails db:create
マイグレーションとは
マイグレーションとは、Rubyの記述（= マイグレーションファイル）でテーブル操作ができる仕組みで、データベースごとに適用します。
マイグレーションファイルは、モデルを作ったタイミングで生成されます。
マイグレーションの手順は以下の通り。
1.以下のコマンドでマイグレーションファイル(モデル)を作成
2.マイグレーションファイルをデータベースに適用
→rails db:migrate
※マイグレーションファイルを作成しただけではデータベースは変更されないため、必ずdb:migrateでマイグレーションを適用します。一度migrateしたものは基本的に変更できないため、作り直しが必要な場合は以下のようなコマンドで取り消しを行う必要があります。
rails db:rollback ・・・適用中のマイグレーションのバージョンを一つ前の状態に戻す
rails db:imgrate:reset ・・・データベースの削除、作成、マイグレーション実行まで行う(ただし実際の現場では顧客情報も全てリセットされるため要注意)
まとめ
データベースはデータを保存しておく場所で、そこに指示を出すための言語がSQL。（マインドマップ参照）
railsでは、マイグレーションというrubyの言語でテーブルを操作できる仕組みを利用してデータを管理している。
マイグレーションに失敗したら、データベース管理システムは立ち上がってるか、アプリのデータベースは作られているか確認する！
Gitメモ
昨日は共同開発のGit課題を提出しました。
Gitに触れるのが久しぶりすぎて色々と忘れていたので、動画で復習をしながら取り組みました(汗)
外国語を学ぶときもそうですが、ある程度慣れて初心者レベルを脱するまでは、定期的に触れておかないとダメですね。忘却曲線に従ってしっかり忘れてしまいました・・。
せっかく復習をしたので備忘録としてメモを残しておきます。
Gitとは
Gitとは、バージョン管理システムの一つで、「コミット」と呼ばれるセーブポイントをいくつも設定することで、以前の状態に戻ることができたり、誰でも変更点を確認することができる。
問題に直面したときに遡って原因を追求することができるため、共同開発時にはもちろん、一人で作業するときにも役に立つ。
（この機能、日常生活の全てにおいて欲しい・・ログ、ダイジ。）
コミットとは
作業者が、変更の履歴を保存すること。
コミットをすることで、いつ誰が何の目的で変更を加えたのかを誰でも確認することができる。
●コミットで確認できること
・コミットされた時刻
・作業者の名前
・ファイルの変更箇所
・コミットの目的
コミットをする際は、「コミットメッセージ」というメモのようなものを書き、どんな変更を加えたのか、他の人にも分かりやすいようにしておく。
Gitファイルを管理するためには
Gitでバージョンを管理するためには、
①まず「リポジトリ」と呼ばれるファイルを自分のマシン上に作成。(ローカルリポジトリ) 【git init】
②完成したリポジトリのファイルに、実際に変更を加える。
③変更を加えてコミットしたいファイルをインデックスにステージ。【git add】
④コミットメッセージとともにコミット【git commit】
の順で行う。
✳︎コメントは【git commit -m "実際のコメント"】で残す。コメントは日本語でも英語でもどちらでもOK。ひとつのリポジトリの中で言語は統一する。
ブランチの作成
ブランチとは、複数人で複数の開発を同時並行して行うことを可能とする仕組み。
変更履歴の管理を分岐させることによって、それぞれの作業に影響を与えることなく別々の機能を実装する事ができる。
デフォルトで作られる「masterブランチ」を軸に、それぞれのブランチを作成して各々が作業を行い、最終的にそれらをmasterブランチに統合(マージ)する。
決断
この1週間、今後の働き方・生活について色々悩んでいました。
今の会社では、ベンチャー企業で変化の激しい中毎日全力で仕事をし、大きなやりがいも感じていましたが、コロナをきっかけにこの業界自体の脆さを知り、そろそろ本気で次に進まなきゃまずいという危機感を強く感じるようになりました。
もちろんそれだけじゃなくて、会社の問題や働き方、収入や生活スタイルなどを総合的に考えて、今動くべきなのかどうかを真剣に考えました。
そして、悩みに悩んだ結果、今のお仕事を辞めることにしました。
正直、不安。。
でも自分の決断を信じて、前を向いて進みます＾＾
そういえば、時間をかけて作っていた記念すべきアプリ第一号も完成し、嬉しくて家族やお友達にもリンクを送って使ってもらったのですが、出来上がったときには本当に感動というかなんというか嬉しくて、ここまでの苦労が一瞬でふっとびました。
あの感動をもう一度、いやあと10回は味わいたいので、早速また新しいものにチャレンジします。
最近、仕事ではこんな気持ちになれていなかったなー。
よし、もう迷いも振り切ったことだし、あとはがしがしコードを書いて、アプリ作ってポートフォリオ作ってさっさと転職しよう！
この決断がいいものになるようがんばろう。
イメージ力を鍛えたい
「私にはイメージ力が足りない！」
最近、これをめちゃくちゃ痛感しています。
progateをクリアしても、アプリ制作の教材を説明にしたがって進めていても、何となくいつもどこかモヤモヤ。
言葉としては理解できる。言いたいことも何となくわかる。言われている通りにやってはいる。
でも、頭の中に図が浮かんでいるかというと、浮かんでいないんですよね。
これって、つまり全然理解できていないっていうこと。
元々、私は言葉を図や絵のようにイメージするということをあまりやってこなかったので、苦手だなーとは思っていましたが、プログラミングをやっていくなら、これは超必須のスキルですよね。
目に見えない複雑なものを動かすわけだから、それなりに何がどうなっているのか、全体像や関係性、少なくとも自分が今書いているコードがどういう役割を担っているのかということが分からないと仕事にならないと思います。
とはいえ何となく今まで、ディレクトリ構造とかMVCとか、色々とふわふわ・モヤモヤしている部分があったものの、図に関しては、ググれば出てくるから、その都度調べればいいよね、と思っていました。
でも、さすがに今のままじゃまずいなと気付き、今日は色々とググって出てきた図を印刷して、そこに自分でいつも分からなくなる部分をどんどん書き込んでいって、その紙を手元におきながらコードを書いてみました。
すると、不思議なくらい、今までと比べ物にならないほど、すんなり頭に入ってきました。
なんで今までやらなかったんだ・・。
なんとなく、せっかくプログラミングをやっているのに、メモをわざわざ手書きでまとめるのってどうなんだろう。ネットでググった方が効率的だよね、みたいな考えがあったのかもしれません。
でも、少なくとも図解に関しては、苦手なら、絶対に書いてみた方がいい！
ネットに落ちてるものを活用して、そこに必要な情報を書き込むだけでも全然違いました。イメージするってこんなに大事だったんだ。。
いつも頭の中で、今はアプリ全体のどの部分を作っている、ということはもちろん分かるけど、それが、コードというものの分類になると、ディレクトリ構造が初心者にとっては複雑すぎて、あれ、どこに何を書くんだっけ。とごちゃごちゃになっていましたが、図を見ながらだと、すぐ「routes.rbでルーティングの設定をしよう」みたいなことが頭の中で整理できるようになりました。
本当に当たり前すぎる話かもしれませんが、プログラミングをする上でイメージ力がいかに大事かということを思い知ったので、これからはそこを意識しながらやっていこうと思います。
＜追記＞
自分で書いていて気付きました。
これってつまりロジックの部分じゃないのか。
教材をやるとき、最初にどういう流れになるかをイメージせず、ロジックなんて考えずにただ上から順に進めてきてしまっていました。
そりゃ、手打ちのコピペみたいな結果になるよね・・。
もちろん今の私に最初から正解を出せるわけはないけど、これじゃ、何のためにアプリ制作を練習しているのか分からない。
アプリの完成が目的じゃないのに、いつの間にか、考えているつもりで全然考えていなかったのかもしれないです。今更猛省・・。
この気付きと反省を活かし、次にアプリを作るときには、分からないなりにも、必ず最初にどういう流れになるのかイメージしてから取り組もう。
イメージ力とロジック。
机に大きく書いて貼っておこう。
findメソッドとfind_byメソッド(とwhereメソッド)の違い
アプリ作成中に出会ったfindメソッドとfind_byメソッドについて、何が違うのか、どうやって使えばいいのかを調べたので記録しておきます。
●findメソッドとfind_byメソッド(とwhereメソッド)の違い
・findメソッド・・・idを検索キーとしてデータを取得するメソッド。id以外の条件では検索不可。idの値がわかっていてそのデータを取得したい場合に使う。
＜例＞
Client.find(1)
・find_byメソッド・・・与えられた条件にマッチする値のうち最初の値だけを取得する。条件は複数指定できるが、取得できる値は1つだけ。
＜例＞
Client.find_by first_name: ‘Elly’
✳︎条件に一致した値を複数取得したい場合→whereメソッドを使う。
・whereメソッド・・・条件を文字列、配列、ハッシュのいずれかの方法で与えると、条件に一致したすべての値を取得することができるメソッド。検索機能を実装するときにも使用。
＜例＞
Client.where(first_name: ‘Elly’)
◉結論
・違いは大きく分けて２つ。一つ目は、指定できる条件がidのみかそれ以外も複数指定できるかどうか。２つ目は取得したい結果がひとつか複数か。
・findメソッドはidが分かっていて、複数の値を取得したい時に使用し、find_byメソッドはidが分からない、もしくは複数の条件で検索したい時に使用。条件も複数で指定したいし検索結果の値も複数ほしいという場合はwhereメソッドを使用。
参照：Railsガイド
エンジニアじゃなきゃいけない理由を考える
これって結構難しい。
私の場合は、エンジニアになりたいというよりも、プログラミングの勉強をしていること自体が楽しい。これだけは分かっている。
はじめてprogateの無料版をやったときに、めちゃくちゃハマって、仕事の30分しかない休憩中にもずっとやっていました。普段ゲームとかあんまりやったことないけど、多分ゲームにハマる人の感覚ってこんな感じなんだと思う。
一番最初はスマホ版からだったけど、「パズルみたいで面白い！」っていうのが最初の感想で、単純に止まらなくなりました。
そこからしばらくたって、身近な友達がweb系の仕事を楽しそうにやっていたこともあって、なんとなくブログ運用とか、ライターとか、プログラミングとかweb全般に興味を持ちました。
でも正直に言うと、ブログ（wordpress）は一回プチ挫折しています。
まず、wordpressって、なんかちゃんとした記事を書かないといけない雰囲気がありませんか？笑
本当は書きたいこといっぱいあるのに、なんかエビデンスとか用意して、ちゃんと順序立てて書かないといけないような・・。ペルソナ設定をしたりSEOを意識したりとなってくると、結構、書くまでの心理的ハードルが高いというか、文章を書くことは好きなはずなのに、好きなことが書けなくなって、苦痛になってやめてしまいました。
もう少しハードルの低いライターの仕事はどうかというと、ライターって、割とかけた労力の割にはコスパが悪いというところが引っかかっていました。
クラウドソーシングとかで求人を見ても、１文字10円未満とか。もちろん、経験を積めば単価はあがるだろうけど、「何年かかるんだろう」「本当に生活できるのか」っていう疑問をぬぐいきれず、選択肢からは自然と外れていきました。
そしてプログラミング。
プログラミング自体は学生時代からちょいちょい気になる存在でした。
実は今では有名なドットインストールの第一期生だったりします。登録だけは・・。
（今見たら2011年11月に登録されてましたが、あの頃は意味不明すぎてたった3分の動画を１本見るのも辛くて、PCも開かずほぼBGMがわりでした。笑
あの頃からちゃんとやってれば今頃・・）
ちょいちょい思い出してはググったりしていたものの、超PC音痴だった私には無縁の世界だろうと決め付けていました。
でもprogateと出会って、プログラミングって何ができるのかよく分からないけど、ただただ楽しい！っていう快感が忘れられず、今年の3月に有料会員になりました。
そこから今日まで（寝落ちした日以外）ほぼ毎日学習を続けています。
かみざとさんのこの動画を見て、エンジニアじゃなきゃいけない理由ってなんだろうと改めて考えてみると、何か運命的な出会いがあったとか、これが私の使命だ！みたいなものはないのですが、強いて言うならば、「私の中の”楽しい”の琴線に触れている」っていうところなのかなー。
飽きっぽく、未知の分野が大好きな私にとって、良くも悪くも移り変わりの早い世界なので、一生勉強していられる分野かもしれません。
あと、転職を考えた理由としては以下のような理由があります。
・今まで結婚、出産、子育て、夫の転勤にともなう引越などライフイベントの変化に合わせて仕事を変える必要があり、女性としてキャリアを築くことの難しさを感じた。
・上の理由により、キャリアアップや収入面でも満足いくものは得られず、常に、ある種、劣等感のようなものと漠然とした不安・不満を抱えていた。
・これまでは子供が小さく手がかかっていて、何よりも育児、家庭を優先しなければいけなかったが、少し手が離れてきたことで、自分のやりたい事を考えるようになった。
・夫が協力的で、私がやりたい仕事で且つ世帯収入が今より上がるなら、自分が仕事をやめて、家庭に入ってもいいと言ってくれている。(つまり私が一家の大黒柱となる）
・沖縄へのUターン移住を考えたときに、仕事の面が１番ネックで、労働条件の悪い求人ばかりで絶望した。
・沖縄で働く知人はみんな当然一生懸命働いているものの、稼げている人はごく一部で、それは努力の量ではなく、業界や分野に大きく依存していると感じる。
・この歳から、全く未経験の状態で1から挑戦できる分野には限りがある。
→上2つの理由から、IT業界など将来的にも需要が高く、且つ現時点で相対的に人手が足りていない分野を目指すきっかけに。
ざっとこんな感じ。
これだけだと「エンジニア」じゃなければいけない理由というものはないのかとしれません。
でも、現時点では
「自分が好きで楽しいと思えること」、
「ある程度家庭を守っていける程度に稼げる」、
「需要と供給のバランスから、この年からでもまだ参入チャンスがある」
という３つの条件を満たしている（ように思える）のは、今思いつく限りだと、エンジニアなのかなーという感じです。
こうやって1度立ち止まって改めて考えてみると、結構難しいものですね！
他の人達の「エンジニアを目指している理由」にも興味があるなー。聞いてみたい。
今度また、改めてじっくりと自己分析をして、面接でも話せるようにしっかりと落とし込んでみようと思います。
信頼できるドキュメントを読もう！
プログラミングの独学を始めたばかりの頃はやっていなくて、最近よくやっていること。それは、「信頼できるドキュメントを探して読む」ということ。
ちょっと前までは、エラーが出たり、そもそもどういう物なのかが分からなくて調べるときは、大抵Qiitaを読んでいました。
でも、更新日が古かったり、バージョンやOSなど自分の環境と異なっていたりと、結局そのまま使えるものってなかなかないんですよね。
それで最近ようやく気づいたのが、結局、公式ドキュメントやリファレンスを読むのが一番安心かも！ということ。
もちろん、ちょっとした事だったらQiitaでパパッと調べちゃいますが、わたしは概要を知りたいときや、細かい使い方が知りたい時などは、信頼できるドキュメントを探して読むようにしています。
ちょうど、わかりやすく丁寧にまとめてくれている記事（これ自体はQiitaです笑）を発見したので、よかったら参考にしてください。
https://qiita.com/hanachin_/items/76a24bcef889edb59d19
ブックマーク必須です！
