習慣の見直し(ダメになった生活の見直し)
生活の見直し。。
ここに至った経緯に関しては昨年プログラミング学習を頑張っていたのにその習慣が崩れ、毎日ダラダラ生産性のない生活をするようになってしまいました。
とりあえずこれを今年のうちに見直して再度別な目標を設定する必要性があると感じて習慣を身につけるための勉強をしていきます。
習慣の身につけ方
習慣を身につけるためには３ヶ月かかると言われているという事で３ヶ月のスパンで実行していく必要性がある。
下記に例を踏まえて何をするか決めていく
例) 英語のリスニングの勉強をする
- 方法を決める
- やる時間、場所を決める
- 何を使うか決める
2.最初の1分間を計画する
上記で決めたリスニングの勉強をする時に使うもの等を決められた場所に置き、
取り組む際にそれを阻む障壁を極限まで削る
3.習慣を壊す障壁を考える
自分の場合、仕事が3交代制の仕事をしており、不規則なためパターンを決めておかないとすぐに崩れて0になってしまいます。
4.すでにある習慣にくっつける
通勤中に英語を聞き流すというように既に今存在している習慣にくっつける事で生活に定着しやすくする
5.環境をコントロールする
勉強をする際に勉強をする場所として決めていたリビングでテレビやゲームが置いてあると習慣化されているテレビをとりあえずつける等の既にある習慣に惰性で流れてしまう傾向があります。
その為、今ある習慣で不要な習慣に関して環境によって実行しにくくする必要性があります。
6.カレンダーに実行できた、出来なかったを記録する
視覚的に自分の習慣が身についているかを確認する事で達成感を得られます。
7.1%の習慣を続ける方が0%より100%良い
脳科学的に習慣を作るプロセスにおいて重要らしいです。
ある場所で何かをするというときに何かをするという目的までせずともある場所に行く習慣がまず大事であるという事です。
あまり過剰な目標を設定しすぎると習慣化する事において逆効果になることが多いらしいです。自分も経験があります。
大事なのは楽にやり続けることです。
何日やれば身につくではなくある期間でどのくらい実施できたかが重要なのです。
上記のような形で習慣を身につけていきます。
mysql2のインストール時のエラー対処
しばらく学習進捗の関係でアウトプットをおろそかにしていたのでこちらの更新も順次行い、生活リズムを戻していきたいと思います。
早速表題の件ですが、bundle insatall時にmysqlインストール時に止まってしまうエラーが生じてしまったので下記のように単体でインストールした際のエラーを確認してみました。
.....$ gem install mysql2 -v '0.4.10'
Building native extensions. This could take a while...
ERROR: Error installing mysql2:
ERROR: Failed to build gem native extension.
current directory: /Users/user_name/.rbenv/versions/2.5.1/lib/ruby/gems/2.5.0/gems/mysql2-0.4.10/ext/mysql2
/Users/user_name/.rbenv/versions/2.5.1/bin/ruby -r ./siteconf20191120-19061-1x902ud.rb extconf.rb
checking for rb_absint_size()... yes
checking for rb_absint_singlebit_p()... yes
checking for ruby/thread.h... yes
checking for rb_thread_call_without_gvl() in ruby/thread.h... yes
checking for rb_thread_blocking_region()... no
checking for rb_wait_for_single_fd()... yes
checking for rb_hash_dup()... yes
checking for rb_intern3()... yes
checking for rb_big_cmp()... yes
-----
Using mysql_config at /usr/local/opt/mysql@5.6/bin/mysql_config
-----
checking for mysql.h... yes
checking for errmsg.h... yes
checking for SSL_MODE_DISABLED in mysql.h... no
checking for MYSQL_OPT_SSL_ENFORCE in mysql.h... no
checking for MYSQL.net.vio in mysql.h... yes
checking for MYSQL.net.pvio in mysql.h... no
checking for MYSQL_ENABLE_CLEARTEXT_PLUGIN in mysql.h... yes
-----
Don't know how to set rpath on your system, if MySQL libraries are not in path mysql2 may not load
-----
-----
Setting libpath to /usr/local/opt/mysql@5.6/lib
-----
creating Makefile
current directory: /Users/user_name/.rbenv/versions/2.5.1/lib/ruby/gems/2.5.0/gems/mysql2-0.4.10/ext/mysql2
make "DESTDIR=" clean
current directory: /Users/user_name/.rbenv/versions/2.5.1/lib/ruby/gems/2.5.0/gems/mysql2-0.4.10/ext/mysql2
make "DESTDIR="
compiling client.c
compiling infile.c
compiling mysql2_ext.c
compiling result.c
result.c:326:40: warning: incompatible pointer types assigning to 'my_bool *' (aka 'char *') from 'bool *' [-Wincompatible-pointer-types]
wrapper->result_buffers[i].is_null = &wrapper->is_null[i];
^ ~~~~~~~~~~~~~~~~~~~~
result.c:328:40: warning: incompatible pointer types assigning to 'my_bool *' (aka 'char *') from 'bool *' [-Wincompatible-pointer-types]
wrapper->result_buffers[i].error = &wrapper->error[i];
^ ~~~~~~~~~~~~~~~~~~
2 warnings generated.
compiling statement.c
linking shared-object mysql2/mysql2.bundle
ld: library not found for -lssl
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [mysql2.bundle] Error 1
make failed, exit code 2
Gem files will remain installed in /Users/kuriharatakumi/.rbenv/versions/2.5.1/lib/ruby/gems/2.5.0/gems/mysql2-0.4.10 for inspection.
Results logged to /Users/kuriharatakumi/.rbenv/versions/2.5.1/lib/ruby/gems/2.5.0/extensions/x86_64-darwin-18/2.5.0-static/mysql2-0.4.10/gem_make.out
ld: library not found for -lsslというような文面があったので調べてみると関連記事で
https://qiita.com/fukudakumi/items/463a39406ce713396403
https://qiita.com/HrsUed/items/ca2e0aee6a2402571cf6
https://qiita.com/paranishian/items/cb0a7bdef8ffa3880327
のようなものがあったのでこちらを参考にしてエラーの改善を行なっていきました。
まず、下記のようなコマンドを実施しました。
.....$ brew info openssl
openssl: stable 1.0.2t (bottled) [keg-only]
SSL/TLS cryptography library
https://openssl.org/
/usr/local/Cellar/openssl/1.0.2s (1,795 files, 12.0MB)
Poured from bottle on 2019-08-16 at 12:35:27
From: https://github.com/Homebrew/homebrew-core/blob/master/Formula/openssl.rb
==> Caveats
A CA file has been bootstrapped using certificates from the SystemRoots
keychain. To add additional certificates (e.g. the certificates added in
the System keychain), place .pem files in
/usr/local/etc/openssl/certs
and run
/usr/local/opt/openssl/bin/c_rehash
openssl is keg-only, which means it was not symlinked into /usr/local,
because Apple has deprecated use of OpenSSL in favor of its own TLS and crypto libraries.
==> Analytics
install: 135,887 (30 days), 641,887 (90 days), 5,802,055 (365 days)
install_on_request: 58,872 (30 days), 181,582 (90 days), 879,851 (365 days)
build_error: 0 (30 days)
しかし、こちらのコマンドでは特に記事にあるようなエラー対象となるような文面が表示されなかったので次に-lsslオプションを追加してみます。
.....$ bundle config --local build.mysql2 --with-mysql-config=/usr/local/opt/mysql@5.6/bin/mysql_config --with-ldflags=-L/usr/local/opt/openssl/lib --with-cppflags=-I/usr/local/opt/openssl/include
You are replacing the current local value of build.mysql2, which is currently nil
You are replacing the current local value of build.mysql2, which is currently nil
こちらのコマンドを実行後に再度インストール実行で問題なく実行することが出来ました。
以上、エラー改善報告でした。
学習[77]日目
本日の学習内容
テストとは？
プログラムが意図した通りに動くことを確かめることです。
railsnにおけるテストとは基本的にはモデルとコントローラのファイルに対してテストコードを作成します。その際はRSpecという独自の言語を利用します。
RSpecは、Rubyを元に作成されたテストに特化した言語です。 「rspec-rails」というGemをインストールすると、RSpecを利用できます。
テストコード無しで実装した場合、つまりプログラムが意図した通りに動くことを確かめずに記述していったコードには、思いもよらない原因で発生するバグが潜んでいる可能性があります。テストは、こういった事態を防ぐために必要です。
あらゆるケースを想定し、「バグがないことを確かめてから」本番に適用するようにするのがテストコードを書く意義です。
基本的に、ひとつのプロダクションコードに対してはひとつのテストコードが必要です。
例えばRuby on Railsにおいては、モデルクラスやコントローラークラスひとつにつきひとつのテストコードを書かなければいけません。
テストを書くメリット
仕様漏れを減らすことができる
テストをするにあたっては、対象のメソッドがどのような目的で作成されどんな挙動をしなければいけないのかということを全て洗い出します。結果的に仕様を良く確認することになり、バグを引き起こす仕様漏れを少なくすることができます。
リファクタリングや機能追加をしやすくなる
リファクタリングとは、コードをより綺麗なかたちに修正する作業のことです。一度テストを通過してしまえば、最終的な結果を維持しリファクタリングをするのが簡単になります。また、新たな機能を追加する際も、従来の箇所は間違いなく動いていることを確認できているので、その結果を崩さないようにするだけで安全に実装することができます。
楽しくコードを書ける
テストを通過するという快適な体験を重ねることで、コードを書く作業が楽しくなります。注意力が必要で神経をすり減らしやすいプログラミングという作業において、楽しくコードが書ける、ということは非常に重要です。
テストコードを書く際の心がけとしては、スピードは求めないことやDRYを意識し過ぎないことです。
テストの種類について
テストは、主に単体テストと統合テストという2種類に分類されます。単体テストとは、単体で動くプログラムが正常に動作するか確かめるテストのことです。統合テストとは、複数のプログラムが組み合わさった機能が正常に動作するか確かめるテストのことです。
また、テストを行うにあたって便利なジェムがあるので下記に記載します。
Rspec：Railsのテスト駆動開発で使われてきたTest::Unitを代替するフレームワーク
#rspec導入
#.rspecに --format documentationを記述すると表示を綺麗にしてくれる
factorybot：テストデータの作成を行う
faker：ダミーデータを生成する
#以下のように記述することでfactorybotをインスタンス生成時に記述を省略出来る
#また、fakerを使用する為には以下のように記述するが、様々なメソッドを用意されている
FactoryBot.define do
factory :user do
password = Faker::Internet.password(min_length: 8)
name {Faker::Name.last_name}
email {Faker::Internet.free_email}
password {password}
end
end
#通常のインスタンス生成
user = User.new(nickname: "aaa", email: "aaa@aaa", password: "00000000")
＃factorybotで作成する場合(createはデータベースにデータを保存するがbuildは一時的に作成する違いがある)
Factorybot.build(:user)
＃factorybotで作成する場合(factorybotの記述省略)
この場合には、rails_helper.rbに特定の記述をすることで省略可能
build(:user)
単体テスト
ひとつのプログラムのまとまりに関して、それ単体が正常に動くか確かめるテストのことです。Railsであれば、モデルクラスひとつ、コントローラークラスひとつにつきそれぞれテストコードを書きます。下記がその一つの例です。
describe User do
describe '#create' do
it "is invalid without a email" do
user = User.new(nickname: "aaa", email: "", password: "00000000"
, password_confirmation: "00000000")
user.valid?
expect(user.errors[:email]).to include("can't be blank")
end
end
end
1行目のrequire 'rails_helper'は、rails_helper.rb内の記述を読み込むことで共通の設定を有効にしています。この1行目の記述は、全てのspecファイルに書き込みます。
3, 4行目に連続してdescribeが登場しています。describeは、ネストにすることができます。この場合には、Userクラスにあるcreateメソッドをテストするまとまりであることを示しています。(describeとdoの間にメソッド名を書く際は#をつける)
5行目は「emailが空である場合登録できないこと」を確かめるテストコードを作成したいのでemailの値を空にし、それ以外は適当な値をセットした状態でuserクラスのインスタンスを作成しています。
6行目では新規作成したuserクラスのインスタンスがバリデーションに引っかかるかどうかを確かめるvalid?メソッドを利用します。
errorsではvalidによってtrueを返した場合にどうして生じたかを確認可能
また、上記の記述に関しては、以下の項目から成り立っています。
describe：do ~ endまでのテストのまとまりのことです。
it：exampleと呼ばれる実際に動作するテストコードのまとまりのことです。
expect(X).to マッチャ Y：エクスペクテーションと呼ばれる実際に評価される式です。
マッチャ：エクスペクテーションの中で、テストが成功する条件のことです。
統合テスト
複数のプログラムが連動して行われる処理が意図した通りに行われるかを確かめるテストのことです。Railsであれば、ユーザーの新規登録における一連の処理をテストすることが考えられます。ユーザーの新規登録用画面から値を入力、送信して、データベースにレコードが追加されるまでの一連の流れをシミュレートするテストコードを書きます。Rspecを用いて統合テストを書く手段として、フィーチャスペックを利用できます。
フィーチャスペックは、Rspecを使って統合テストを行うためのスペックです。テスト環境用の仮装ブラウザを操作して、「特定のa要素をクリックする」「ボタンと対応するコントローラのアクションが動く」といった複雑なテストを書くことができます。アプリケーションの肝となる動作を総合的にテストしたい場合に用いられます。
フィーチャスペックを書くためにCapybaraというgemを導入して、フィーチャスペックを書いていきます。
Capybaraは、ブラウザの操作を再現するのに必要なgemです。特定の要素をクリックしたり、フォームに値を入力したり、特定の要素が画面に表示されているかなど、様々なブラウザ上の動きをテストすることができます。Capybaraを導入すると、テストを記述するためのヘルパーメソッドが複数追加され、これらを活用してフィーチャスペックを記述していくことになります。
また、フィーチャスペックでは、単体テストとは異なる記述を行います。
例）
it→scenario before→background describe→feature let→given
調べた英語
fixtures：設備
replacement：交代
straightforward： わかりやすい
inheritance：継承
transitioning：変遷
alias：別名、通称
populate：(データを)入れる
usage：慣例
typo：打ち間違え
実際に記述と試行を繰り返さないとなれないと感じました。
以降、練習も実施していきたいと思います。
：https://qiita.com/jnchito/items/cdd9eef2ed193267c651
：https://blog.naichilab.com/entry/2016/01/19/011514
：https://kossy-web-engineer.hatenablog.com/entry/2018/11/30/083719
：https://github.com/faker-ruby/faker
学習[76]日目：メッセージ送信機能の実装
本日の学習内容
だいぶ期間が空いた更新となってしまいました。
メッセージ送信機能の実装
まず、メッセージモデルの作成を行い、マイグレーションファイルにてのカラムの編集や設定を行い、テーブルを作成します。
さらに、各モデルにアソシエーションの設定やバリデーションの設定を実施します。
メッセージコントローラーのルーティングに関しても編集を行いますが、今回は入力フォームをトップページにて行う仕様のため、newアクションの設定は行いません。(コントローラーではindexとcreateのみ定義、ルーティングもresourceでindexとcreateのみ)
上記に記載したようにmessagesコントローラで必要となるアクションはindexとcreateの2つです。
private以下にset_groupを定義し、before_actionを利用して呼び出すことで、messagesコントローラの全てのアクションで@groupを利用可能にします。
indexでは、Messageモデルの新しいインスタンスである@message、グループに所属する全てのメッセージである@messagesを定義して、n + 1 問題を避けるために、includes(:user)の記述します。
createでは、グループ作成機能を実装した際と同様に、保存に成功した場合、保存に失敗した場合で処理を分岐させます。
次いでメッセージのフォームを作成しますが、form_forの引数に@group, @messageの2つを渡している点に注目してみます。
今回の場合、messagesはgroupsにネストされているため、createアクションのパスはgroup_messages_pathに変化している為、「form_for @message」と記述したのみでは、messages_pathにリクエストを送ってしまうため、レコードを保存することができません。
「form_for [@group, @message]」と記述することで、group_messages_pathにリクエストを送ることができます。このように、ネストされたモデルに対してform_forを使用する場合、親モデルのインスタンス(もしくは親モデルのid)を第1引数、子モデルのインスタンスを第2引数に設定する必要があります。
実装するにあたり、調べたことをメモ代わりにまとめました。
Active Record コールバックとは
オブジェクトのライフサイクル期間における特定の瞬間に呼び出されるメソッドのことです。
Railsアプリケーションを普通に操作すると、その内部でオブジェクトが作成されたり、更新されたりします。Active Recordはこのオブジェクトライフサイクルへのフックを提供しており、これを用いてアプリケーションやデータを制御できます。
validate条件分岐
:if
validates :text, presence: true, if: :user_signed_in?
上記の条件式はifがtrue、すなわちユーザーがログイン状態の時のみに検証を実行するような場合の記述になります。
:unless
validates :content, presence: true, unless: :image?
上記の条件式のunlessはifとは反対にfalseの時、すなわちイメージが送信されていない場合に検証を実行するような場合でつまり送信した内容にイメージとテキストの両方が空の状態を避けるための検証を実行する為の記述になります。
render
ビューファイル内でテンプレートを呼び出す際には、下記のように_と拡張子除いた形で呼び出します。
<%= render partial: ‘message’ %>
部分テンプレート内で変数を使いたい時には、
<%= render partial: ‘messsage’, locals: { message: @message } %>
のように、localsオプションを用いて、
locals: { 部分テンプレート内で使いたい変数: 持っていきたい値 }と記述します。
部分テンプレート内で繰り返し処理を行いたい時には、
<%= render partial: ‘message’, collection: @messages %>
↓省略形
<%= render @message %>
とcollectionオプションにインスタンス変数の複数形を渡すと、部分テンプレートでインスタンス変数が個別で呼ばれ、さらにeach文を使用せずに繰り返し処理も行ってくれます。ただし、呼び出すファイル名がインスタンス変数の単数形である必要があります。
carrierwave
画僧のアップロード機能を実装出来るジェム
minimagick
画像のリサイズを行うことが出来るジェム
学んだ英語
cache キャッシュ
relevant extension 関連する拡張子
参照：https://github.com/carrierwaveuploader/carrierwave
：https://github.com/minimagick/minimagick
：https://railsguides.jp/active_record_callbacks.html
：https://qiita.com/yk-nakamura/items/acd071f16cda844579b9
：https://www.pikawaka.com/rails/validation
：https://www.pikawaka.com/rails/migration
：https://haayaaa.hatenablog.com/entry/2018/11/25/100707
学習[65,66,67,68,69]日目
ここ数日間の学習内容
夜勤に入ってからのここ数日間の学習があまり進まなかったのでまとめて記述していこうと思います。
仮眠とってタスク管理して学習しようと思っていたのですが、一向に学習効率が上がらず、結局夜勤最終日に慣れて眠気が取れてきたところで終了です。。
gitに関して
先日実装したグループ機能に関してcommit後にmergeしたのですが、その前に実装したグループ機能のビュー画面に関してmerge後にpullしていなかったためか親のブランチにgroupに関する機能が無い状態で次のブランチの作成を行なっていました。
その為、グループ機能を実装していたブランチが一番最新の状態であったのでそちらのの方を参照にしてmergeを行う為に、まず変更を行うブランチにgit check outにて移動してからgit merge [参照ブランチ名]を実行する。
これによってgitの状態が一度conflict状態になるのでそれは現行のブランチにcommitすることで実行することが出来ました。
これで通常通り実装を進めていくことが出来るようになりました。
renderと redirect_toの違い
redirect_toとはHTTPリクエストをサーバーに送り、ユーザーはそこから返ってくるHTMLが表示される。
renderとはAction内で、呼び出すViewを指定するメソッド。そのAction内で@〜〜(インスタンス変数)として格納されたものは、Viewからrubyの構文で呼び出せます。
呼び出すViewの形式は、RHTML形式です。
専門用語
また、今まで出てきた専門用語に関して少し下記にまとめました。
RESTとはREpresentational State Transferの略で、分散型システムにおける複数のソフトウェアを連携させるのに適した設計原則の集合、考え方のこと。
DRYとは"Don't Repeat Yourself"の略。
YAGNIとは"You ain't gonna need it"の略。
以上、短いですが学習内容のまとめとなります。
参照：https://www.slideshare.net/kotas/git-15276118
：https://www.sejuku.net/blog/71003
：https://qiita.com/NagaokaKenichi/items/0647c30ef596cedf4bf2
：https://qiita.com/muran001/items/dea2bbbaea1260098051
：https://kray.jp/blog/git-pull-rebase/
学習[62,63,64]日目
本日の学習内容
ビューの作成(form_forによるフォームの作成)
前回までの段階でモデルとコントローラーの作成まで行ったので、今回はビューの実装から入っていきます。
#hamlでのグループ新規作成画面のビューフォームの作成
= form_for @group do |f|
- if group.errors.any?
.group-form__errors
%h2= "#{group.errors.full_messages.count}件のエラーが発生しました。"
%ul
- group.errors.full_messages.each do |message|
%li= message
.group-form__field
.group-form__field--left
= f.label :name
.group-form__field--right
= f.text_field :name, placeholder: 'グループ名を入力してください'
.group-form__field.clearfix
.group-form__field--left
%label.group-form__label{:for => "group_メンバー"} メンバー
.group-form__field--right
= f.collection_check_boxes :user_ids, User.all, :id, :name
.chat-group-form__field.clearfix
.group-form__field--left
.group-form__field--right
= f.submit class: 'group-form__action-btn'
上記のようにform_forを使用して新規作成フォームの作成を行いましたが、現在ではform_withの方が一般的とのことなので次回からはそちらを使用していきたいと思います。
次いで、こちらを元に下記のようにコントローラーの編集を行っていきます。
#newアクションにてインスタンスを生成
#1モデルで設定したパラメーターの枠を持ったインスタンスが生成されるがパラメータは空
#2newアクションにて開いたビューにて作成したグループに必ずログインユーザーがチェックされるように設定
def new
@group = Group.new
@group.users << current_user
end
#newでのビューの作成ボタンを押すとルーティングからcreateアクションが呼び出される
#フォームで入力されたパラメーターを引数としてインスタンスを生成出来た場合=>root_pathのビューへ
出来なかった場合=>newアクションのビューへ
def create
@group = Group.new(group_params)
if @group.save
redirect_to root_path, notice: 'グループを作成しました'
else
render :new
end
end
#group_paramsによって呼び出されたメソッドから下記の処理を実施
#requireによって:groupが要求されている
peremitによって:name, { :user_ids => }が許可されている
private
def group_params
params.require(:group).permit(:name, { :user_ids => })
#上記と同じ意味？
params.require(:group).permit(:name, user_ids:[])
end
end
上記の実装にあたりStrongParameters及びparamsに関する理解やformからどのようにパラメーターがとんでいるかの理解が全くだったので復習にかなり時間を要していまいました。少し反省です。。
まず、ビューで作成したフォームの値がどのようにコントローラーに渡されているのかに関してですが、フォームで＠モデル名でモデルを指定します。
フォーム下で作成するフォームコントールに関しても同様にモデル内のカラムを指定することで格納先を指定することが可能となります。
これによりフォームからの値の行き先を指定してあげることでボタンを押した際に値を引き渡す準備ができるようになります。
しかし、これだけでは値が一方的に引き渡されることになるだけの為、不正な値等が送られてきたときに必要のない値まで受け取ってしまうことになります。
その為、createアクションにて定義したparmsのrequireとpermit メソッドによって、受け取るリクエストパラメータの制御を行います。
require はハッシュに指定したキーが存在することを検証し、キーが存在すればその値を返します。つまり、「params.require(:group)」とした場合、:group がキーとして存在すれば「params[:group]」の値が返されます。そして、指定したキーが存在しない場合は例外 ActionController::ParameterMissing を raise します。
permit はハッシュから指定したキーだけを取り出します。指定しなかったキーがハッシュに含まれていても、戻り値にそれらの値は含まれません。
そしてcreateされるタイミングでモデルにて設定したvalidationの検証も実行されるのでそちらの条件の検証が行われることも注意しなければなりません。
本日の英単語
abbreviation：略語
以上で、数日間の学習内容をまとめを終了します。
感じたことは完全にわからなことを調べるうちにわからないことに必要な文章にわからない単語がある状態がループしてこちらもまとめるだけで不要な時間と労力を要してしまったのが反省点です。
今度から注意していかなければと思いました。
わからないところのわからないものはそういうものだと認識して次に進む必要性を感じました。
参照：https://www.pikawaka.com/rails/form_for#form_for
：https://www.sejuku.net/blog/13163#html
：https://ruby-rails.hatenadiary.com/entry/20140727/1406448610
：https://www.sejuku.net/blog/29763#params
form_withを必死に使用しましたが、rails -vで確認したら5.0.7.2の為、今回使用出来なかったform_withに関して(5.1以降のverで使用可能)
参照：https://web-camp.io/magazine/archives/17665
：https://techracho.bpsinc.jp/hachi8833/2017_05_01/39502
学習[61]日目
本日の学習内容
group機能の実装
実装にあたり下記の順番で実装してきます。
コントローラとモデルを作成する
まず、前提として以前に作成したデータベースの設計書を元に構成を確認します。
## groupsテーブル
|Column|Type|Options|
|------|----|-------|
|name|string|null: false|
### Association
- has_many :users, through: :groups_users
- has_many :groups_users
- has_many :messages
#上記の構成なのでマイグレーションファイルにて下記のようにします
create_table :groups do |t|
t.string :name, null: false
t.index :name, unique: true
t.timestamps
end
t.indexに関しては、index(column_name, options = {})で定義できるらしい。
見たことのない形だったので、こちらを参照にしました。
次いで、
## groups_usersテーブル
|Column|Type|Options|
|------|----|-------|
|user_id|integer|null: false, foreign_key: true|
|group_id|integer|null: false, foreign_key: true|
### Association
- belongs_to :group
- belongs_to :user
#上記の構成なのでマイグレーションファイルにて下記のようにします
create_table :group_users do |t|
t.references :group, foreign_key: true
t.references :user, foreign_key: true
t.timestamps
end
それぞれのテーブルに関しては上記のようにマイグレーションファイルに追記して実装していきます。
reference型を使う場合の外部キー制約のついたカラムを作成するときにメリットがあります。
#通常の記述だと下記のようになる
create_table :group_users do |t|
t.string :user
end
add_foreign_key :group_users, :users
reference型を使用しない場合には、foreign_keyが使用できない点に注意する必要がある。また、reference型を使用していてもforeign_keyを使用していないと外部キー設定は出来ないのでこちらも注意です。
そして、設定後に下記を実行します。
rails db:migrate
してできたmigrationファイルの方にアソシエーションの記述を行なっていきます。
こちらに関しては、validateの設定も忘れずに行うようにします。
ルーティングを設定する
#変更前
devise_for :users
get 'messages' => 'messages#index'
resources :users, only: [:edit, :update]
root :to => "messages#index"
end
＃変更後
devise_for :users
root 'messages#index'
resources :users, only: [:index, :edit, :update]
resources :groups, only: [:new, :create, :edit, :update] do
resources :messages, only: [:index, :create]
end
end
routingが変更前が色々とごちゃごちゃしていたことに気づかなかったので見直しをしていきます。
変更後に関してroutingをネストしていますが、ネスト有無の違いで下記のような違いが生まれます。
ネスト有
group_messages GET /groups/:group_id/messages(.:format) messages#index
POST /groups/:group_id/messages(.:format) messages#create
ネスト無
messages GET /messages(.:format) messages#index
POST /messages(.:format) messages#create
あとは該当するアクションをコントローラに定義して、ビューを作成して割り当てます。
このあとで実際に機能を実施していくのでまた別途分けて記述していきます。
今日の英単語
●validate 検証
意味分かるまでなんだろうと思ってたけど分かったらオブジェクトを保存する前に検証するっていう簡単なこととして理解できた。
本日の学習内容は以上になります。
お読みいただきありがとうございます。
参照：https://qiita.com/ryouzi/items/2682e7e8a86fd2b1ae47
：https://api.rubyonrails.org/v5.1.7/classes/ActiveRecord/ConnectionAdapters/Table.html
