Command Paletteとは?
you have access to all of the functionality of VS Code, including keyboard shortcuts for the most common operations.
→一般的な操作のショートカットを含むvscodeの機能にアクセスすることができる
Visual Studio Code User Interface
これでterminalでcode + 開きたいファイル名またはディレクトリパスを入力すれば開くことができる。
公式の導入部分で以下のように説明されている。
Use rbenv to pick a Ruby version for your application and guarantee that your development environment matches production. Put rbenv to work with Bundler for painless Ruby upgrades and bulletproof deployments.
rbenvを使うことによって、アプリケーションのバージョン選択や本番環境に開発環境がマッチすることを保証し、rbenvとbundlerを連携させることでrubyのアプグレードの面倒をなくし、開発環境を実現する。
また、以下のような記述から、rubyのバージョン管理のためのツールとわかる。
rbenv is concerned solely with switching Ruby versions.
オブジェクトを人間が読める形式に変換した文字列を返すメソッド。
railsガイドのarticles_controller.rbにinspectを使用すると以下のような表示になる。
inspectを使った場合
6] pry(main)> Article.first.inspect Article Load (0.2ms) SELECT "articles".* FROM "articles" ORDER BY "articles"."id" ASC LIMIT ? [["LIMIT", 1]] => "#<Article id: 1, title: \"タイトル\", text: \"テキスト\", created_at: \"2021-01-01 11:21:06\", updated_at: \"2021-01-01 11:21:06\">"
render plain: params[:article].inspectでブラウザに表示させると、
inspectを使わない場合
[7] pry(main)> Article.first Article Load (0.3ms) SELECT "articles".* FROM "articles" ORDER BY "articles"."id" ASC LIMIT ? [["LIMIT", 1]] => #<Article:0x00007fd778834d28 id: 1, title: "タイトル", text: "テキスト", created_at: Fri, 01 Jan 2021 11:21:06 UTC +00:00, updated_at: Fri, 01 Jan 2021 11:21:06 UTC +00:00>
render plain: params[:article].inspectでブラウザに表示させると、
とりあえずメモ。 後で他の投稿と合体するかも。
鋳型、雛型、定型書式などの意味を持つ英単語。文書などを作成する際の雛型となるデータやファイルなどのことをこのように呼ぶ。
参照→
テンプレート（雛型）とは - IT用語辞典 e-Words
コンテンツ部分を中に読み込んで使用するヘッダやフッタの部分を共通したもの。
参照→レイアウトの利用 - Ruby on Rails入門
<head> <%= csrf_meta_tags %> <%= csp_meta_tag %> <%= stylesheet_link_tag ... %> <%= javascript_pack_tag "application", ... %> </head>
スタイルシートとJavaScriptをページ内にインクルードする（=含める）。
クロスサイトスクリプティング攻撃を緩和するコンテンツセキュリティポリシー（Content Security Policy: CSP）を実装。
クロスサイトリクエストフォージェリー（Cross-Site Request Forgery: CSRF）攻撃を緩和
参考:
railstutorial.jp
shallowオプションとは、深いネスト(入れ子構造)を避けるためにcollectionだけを親のスコープ下で生成させるオプションのこと。
idを含めないアクション(collection)：index/new/create
idを含むアクション(member)：show/edit/update/destroy
以下の例だとネストが深くなっていることがわかる。
# routes.rb resources :articles do resources :comments end
これを踏まえて、ネストを浅くすると以下のような記載になる。
# routes.rb resources :articles do resources :comments, only: [:index, :new, :create] end resources :comments, only: [:show, :edit, :update, :destroy]
以上はshallowオプションを使用することによって、より簡潔な記載で実現できるようになる。
# routes.rb(:shallowオプションあり) resources :articles do resources :comments, shallow: true end
rails routes実行結果は以下のようになる。
contact_forで:titleに任意の語句を入れ、yield(:title)に渡す。
content_for(:title, ':titleに入れたい語句') # contact_forではなくprovideでも可
# application_helper.rb def page_title(page_title = '') #page_titleの''内には引数で渡された語句が入る base_title = 'APP TITLE' # 三項演算子 → 条件1 ? 正しいとき : 正しくないとき page_title.empty? ? base_title : page_title + ' | ' + base_title end
例えばページタイトルを設定したいviewに
content_for(:title, 'aaaa')
と記載すると、以下のようなデータが渡される。
page_title => "aaaa"
そのため、page_title.empty?がfalseになり、後半のpage_title + ' | ' + base_titleが適応され、page_titleにはcontent_for→yeildで渡された'aaaa'が入る。
# application.html.erb <head> <title><%= page_title(yield(:title)) %></title> ... </head>
実行されていないchangeアタはupメソッドを実行する。
マイグレーションの実行順序は日付に基づく。
# マイグレーションを実行するrailsコマンド。db:schema:dumpコマンドも同時に呼び出される $ rails db:migrate
db:schema:dumpコマンドは、db/schema.rbスキーマファイルを更新し、
スキーマ(DB構造の設計図)がデータベースの構造に一致するようにする。
articleモデル(title:string, text:text)をgenerateした場合、rails db:migrate実行で作成されるschema.rbは以下の通り。
# db/schema.rb create_table "articles", force: :cascade do |t| t.string "title" t.text "text" t.datetime "created_at", precision: 6, null: false t.datetime "updated_at", precision: 6, null: false end
migrationのupまたはdown状態を確認するには以下のコマンドを使用する。
$ rails db:migrate:status
例えば、userモデルを作成するとき、以下のようになる。
# rails g model user前 database: db/development.sqlite3(以降省略) Status Migration ID Migration Name -------------------------------------------------- up 20201106213850 Create articles up 20201107132603 Create comments # rails g model user後 Status Migration ID Migration Name -------------------------------------------------- up 20201106213850 Create articles up 20201107132603 Create comments down 20201123074249 Create users # rails db:migrate後 Status Migration ID Migration Name -------------------------------------------------- up 20201106213850 Create articles up 20201107132603 Create comments up 20201123074249 Create users
rails db:rollbackすると以下のようになる。
Status Migration ID Migration Name -------------------------------------------------- up 20201106213850 Create articles up 20201107132603 Create comments down 20201123074249 Create users
rails db:rollbackせずにmigrationを消してしまうと、migration nameの箇所がno fileという記載になり、
rails db:migrateやrollbackなどのコマンドが全てエラーになってしまう。
その時はtouchコマンドでno fileになっているmigration fileを新規作成し、
中にデフォルトの情報を入力して仮のfileを作成し、rollbackをさせてrails db:versionで表示される最新migration fileを合わせ、削除する等を行うことでエラーを回避できる。
$ rails db:version
この状態の時にコマンドを使用すると、以下のようになる。
# rails db:migrate:status Status Migration ID Migration Name -------------------------------------------------- up 20201106213850 Create articles up 20201107132603 Create comments down 20201123074249 Create users # rails db:version Current version: 20201107132603
railsガイドを参考に、関連付けについて記載する。
自分のための振り返りメモなので、随時変更する可能性あり。
参考：Active Record の関連付け - Railsガイド
1対1の繋がりが設定される。
この宣言を行ったモデルのインスタンスは他方のモデルのインスタンスに従属(=belongs to)する。
例えば掲示板の投稿(board)とユーザー(user)で、一つの投稿に対して一人のユーザーが存在するので1対1の関係となる。
class board < ApplicationRecord belongs_to :user end
belongs_toで指定するモデルは必ず単数形。
関連付けの名前から自動的にモデルのクラス名を推測するので、複数形にしてしまうと推測されるクラス名も誤ったものになり、uninitialized constant(名前が間違っている)エラーがでる。
また、belongs_toを記載したモデルは、従属するモデルに対応する外部キーを作成する必要がある(今回の場合はuser_idカラムををboardモデルに追加)。
rails g migrationを実行する時、'従属される側のモデル:references'を追記すると外部キーのforeign_key:trueが従属モデルのmigrationファイルに追加され、modelにはbelongs_toが追加される。(公式では:belongs_toでも可とある)
例：userモデルとboardモデルの関連付け
# userモデル作成 $ rails g model user # boardモデル作成 $ rails g model board user:references $ rails db:migrate
# app/models/user.rb class User < ApplicationRecord end # app/models/board.rb class Board < ApplicationRecord belongs_to :user end
# db/migrate/...create_users.rb class CreateUsers < ActiveRecord::Migration[6.0] def change create_table :users do |t| t.timestamps end end end # db/migrate/...create_boards.rb class CreateBoards < ActiveRecord::Migration[6.0] def change create_table :boards do |t| t.references :user, null: false, foreign_key: true t.timestamps end end end
ActiveRecord::Schema.define(version: 2020_11_22_120323) do create_table "boards", force: :cascade do |t| t.integer "user_id", null: false t.datetime "created_at", precision: 6, null: false t.datetime "updated_at", precision: 6, null: false t.index ["user_id"], name: "index_boards_on_user_id" end create_table "users", force: :cascade do |t| t.datetime "created_at", precision: 6, null: false t.datetime "updated_at", precision: 6, null: false end add_foreign_key "boards", "users" end
参考ページ： Active Record マイグレーション - Railsガイド
1対1の繋がりが設定される。
belongs_toとの違いは、宣言が行われているモデルのインスタンスが、他方のインスタンスを丸ごと含んでいる、または所有していること。
所有する側に従属するモデルのidがモデル名_idという形で関連付けられる。
例えば、一人の供給者(supplier)が一つのアカウント(account)を持つため、1対1の関係になる。
class Supplier < ApplicationRecord has_one :account end
宣言が行われているsupplierが一人につき、一つのaccountを所有しているため、has_oneを使用する。
この場合、accountモデルにはbelongs_toが設定される。
他方のモデルに対して「1対1」のつながりを設定する。
2つのモデルの間に「第3のモデル」(joinモデル)が介在する点が特徴。
相手モデルの1つのインスタンスとマッチする。
例えば1人の提供者(supplier)が1つのアカウントを持ち、アカウントが1つのアカウント履歴を持つ場合、
supplierはaccountを一つ所有(has_one)しており、accountを通して一つのaccount履歴を所有(has_one)していると言える。
class Supplier < ApplicationRecord has_one :account has_one :account_history, through: :account end class Account < ApplicationRecord belongs_to :supplier has_one :account_history end class AccountHistory < ApplicationRecord belongs_to :account end
他モデルとの間が1対多の繋がりがある。
belongs_toの例で使用したユーザー(user)と掲示板(board)の場合、ユーザー一人は複数の投稿ができるため、1対多の関係と言える。
Userモデルにはhas_manyを記載。
class User < ApplicationRecord has_many :boards end
has_manyで関連付けするモデルは必ず複数形。
他方のモデルと「多対多」のつながりを設定する。
2つのモデルの間に「第3のモデル」(joinモデル)が介在する点が特徴。
それによって、相手モデルの「0個以上」のインスタンスとマッチする。
例えば患者(patient)が医師(physician)との診察予約(appointment)を取る医療業務で考えると、
一人の患者が診察予約を一人の医師に対して行うことから、診察予約の視点だとpatientとphysicianにappointmentは従属している(belongs_to)、と言える。
一方、患者や医師の視点で見ると、複数の診察予約を持つことができるので、1対多となるhas_manyが設定される。
医師と患者を結びつけるために:throughオプションにappointmentsが記載される。
class Physician < ApplicationRecord has_many :appointments has_many :patients, through: :appointments end class Appointment < ApplicationRecord belongs_to :physician belongs_to :patient end class Patient < ApplicationRecord has_many :appointments has_many :physicians, through: :appointments end
絵にすると下図の通り。
他方のモデルと「多対多」のつながりを作成する。
through:オプションを使用する場合と異なり、第3のモデル(joinモデル)が介在しないが、結合テーブルは必須。
例えば、アプリケーションに完成品(assembly)と部品(part)があり、1つの完成品に多数の部品が対応し、逆に1つの部品にも多くの完成品が対応する場合は以下のようになる。
class Assembly < ApplicationRecord has_and_belongs_to_many :parts end class Part < ApplicationRecord has_and_belongs_to_many :assemblies end
Active Record の関連付け - Railsガイド
関連付けは基本的には双方向で定義される。
class User < ApplicationRecord has_many :boards end class Board < ApplicationRecord belongs_to :user end
Userモデル(ユーザー)とBoardモデル(掲示板)があり、上記のように関連付けされている場合、以下のようにデータの関連を共有していることがわかる。
a = User.first b = a.Boards.first a.first_name == b.user.first_name # => true a.first_name = 'David' a.first_name == b.user.first_name # => true
ただし、Active Recordでスコープやthroughオプションやforeign_keyを使った場合、双方向の関連付けは自動的に認識されないため、その時は:inverse_ofオプションを使用する。
詳しくはRailsガイドの'ActiveRecordの関連付け：双方関連付け'を参照。
・carrierwave ファイルをアップロードする機能 github.com
・mini-magick 画像加工する機能 github.com
#Gemfileに以下を追記し、bundle install gem 'carrierwave', '~> 2.0' gem 'mini_magick', '~> 4.8'
rails generate uploader 任意のファイル名
# class ファイル名+Uploader < CarrierWave::Uploader::Base # アップロードしたファイルはpublic/配下に保存 storage :file # public/配下のディレクトリの設定 def store_dir "uploads/#{model.class.to_s.underscore}/#{mounted_as}/#{model.id}" end # 画像がなかった時のdefault画像の設定 def default_url(*args) 'board_placeholder.png' end # アップロードするファイルの拡張子を指定 def extension_whitelist %w(jpg jpeg gif png) end
$ rails g migration add_ファイル名_to_テーブル名 カラム名:stirng $ rails db:migrate
データベースサーバーの要領が圧迫されるため、カラムには'DBに保存されている画像ファイル名'が保存される。
画像を表示する時は
'画像の保存してある場所を示すpath’
と
'DBに保存されている画像ファイル名'
を使用して表示させる。
参考：pikawaka.com
# <%= form_with model: モデル名, local: true do |f| %> <%= f.label :カラム名 %> <%= f.file_field :カラム名 %> <%= f.hidden_field :カラム名_cache %> # <%= f.submit %> # <% end %>
def 〇〇_params params.require(:モデル名).permit(:カラム名, :カラム名, :画像カラム名, :画像カラム名_cache) end
cacheとは？
Making uploads work across form redisplays
Often you'll notice that uploaded files disappear when a validation fails.
CarrierWave has a feature that makes it easy to remember the uploaded file even in that case.
Suppose your user model has an uploader mounted on avatar file, just add a hidden field called avatar_cache (don't forget to add it to the attr_accessible list as necessary).
- 公式documentより
検証が失敗すると、アップロードされたファイルが消えるため、
CarrierWaveにはその場合でもアップロードしたファイルを記録する機能があります。
カラム名_cacheという非表示フィールドを追加することで実装できます（必要に応じてattr_accessibleリストに追加すること）。
# 部分テンプレートの画像挿入部分 # render @インスタンスのコレクション(例：@インスタンス名+s)で呼び出されている前提 <%= image_tag ローカル変数.カラム名_url, size: '〇〇x〇〇' %>
.ignoreにpublic/uploadsを追記することで、ローカルでアップロードされたファイルをgit管理下から外すことができる。
# .gitignore public/uploads
詳しくはこちらを参照 【IT用語】.gitignoreの書き方を図解形式で理解しよう! | Pikawaka - ピカ1わかりやすいプログラミング用語サイト
# _form.html.erb(new.html.erbで # <%= render 'form', { a: @b} %>を定義した場合 # a = 部分テンプレート内で使用する変数 # b = 変数にいれる値(controllerやviewで定義した変数名) <%= f.file_field :カラム名, onchange: 'previewImage()', accept: 'image/*' %> <%= image_tag 変数a.カラム名.url, id: 'preview', size: '〇〇x〇〇' %>
・onchange：change イベントを処理する EventHandler 。入力欄や選択肢が変更された時に発生。
onchangeについて→GlobalEventHandlers.onchange - Web API | MDN
JavaScriptのonchangeの使い方を現役エンジニアが解説【初心者向け】 | TechAcademyマガジン
・acceptオプション:フォームで受付可能なMIMEタイプを指定
acceptオプションについて→フォーム(form) | Railsドキュメント
MIMEタイプについて→MIME タイプ (IANA メディアタイプ) - HTTP | MDN
function previewImage() { const target = this.event.target; const file = target.files[0]; const reader = new FileReader(); reader.onloadend = function () { const preview = document.querySelector("#preview") if(preview) { preview.src = reader.result; } } if (file) { reader.readAsDataURL(file); } }
FileReader オブジェクト：ユーザーのコンピュータに保存されているファイル (または生データ バッファ) の内容を非同期に読み取る。
FileまたはBlob オブジェクトを使用して、読み込むファイルまたはデータを指定します。
→FileReader - Web API | MDN
現在のブランチを調べるのにgit branchを毎回やることが面倒だと思ったので表示を変更。 以下の記事を参考にした。
流れを抜粋すると以下の通りになる。
以下のコマンドを入力し、oh-my-zshをインストール
$ sh -c "$(curl -fsSL https://raw.githubusercontent.com/robbyrussell/oh-my-zsh/master/tools/install.sh)"
on-my-zshをインストールすると、自動的に既存の.zshrcファイル名が変更されてしまい、oh-my-zshで作成されたファイル名.zshrcになる。
既存の.zshrcの設定が使えなくなってしまうため、名前を以下のように設定し直す。
#インストール後作成された.zshrcファイル $ mv ~/.zshrc ~/.oh-my-zshrc #既存のファイル名 $ mv ~/.zshrc.pre-oh-my-zsh ~/.zshrc
このままだとoh-my-zshrcが読み込まれないので以下のコマンドを~/.zshrcファイルに追記する。
$ source ~/.oh-my-zshrc
ZSH_THEME="robbyrussell"がデフォルトになっているので、好みのレイアウトを下記github内から選び、""内に入力する。 github.com
他にもプラグインによるエイリアス設定など便利な機能がある。 github.com
bundle execを毎回打ち込むのが面倒だったので、以下の設定で"b"という入力で実行できるようエイリアスを設定。
# .zshrcを開く(vimでもできる) open ~/.zshrc #.zshrcに以下を入力 alias b='bundle exec'
config/locales/activerecord/ja.ymlを作成
ja:
activerecord:
attributes:
user:
last_name: 姓
first_name: 名
email: メールアドレス
password: パスワード
password_confirmation: パスワード確認
form_withではmodelと関連付けしていないので、
activerecordで設定しているmodelのカラム名を参照するときは
明示的に関連付けする必要がある。
モデル名.human_attribute_name(ja.ymlで設定したキー)を使用する。
# user_sessions/new.html.erb・・・ログイン画面 <%= form_with url: login_path, local: true do |f| %> <%= f.label :email, User.human_attribute_name(:email) %> <%= f.email_field :email, class: 'form-control' %> <%= f.label :password, User.human_attribute_name(:password) %> <%= f.password_field :password, class: 'form-control' %><br/> <%= f.submit "ログイン", class: "btn btn-primary" %> <% end %>
新規登録画面はmodelに登録するため、modelと関連付けられる。
そのため、form_withでmodel: モデルのインスタンス(例：User.new)
を設定。
# users/new.html.erb・・・新規登録画面 <%= form_with model: @user, local: true do |form| %> <%= form.label :first_name %> <%= form.text_field :first_name, class: "form-control" %> <%= form.label :last_name %> <%= form.text_field :last_name, class: "form-control" %> <%= form.label :email %> <%= form.text_field :email, class: "form-control" %> <%= form.label :password %> <%= form.password_field :password, class: "form-control" %> <%= form.label :password_confirmation %> <%= form.password_field :password_confirmation, class: "form-control" %> <%= form.submit "登録" ,class: "btn btn-primary" %> <% end %>
git resetしてしまってもgit logと異なり、resetを含め全体の履歴を見ることができる。
左のハッシュ値をgit reset --hardの後ろに入力するとそこまで戻せる。
$ git reflog
git logで戻りたいcommitのハッシュ(commitの後の文字列)を取得し、
以下のように入力する。
$ git reset --hard ハッシュ値
commitのコメント部分を誤入力した時に使用した。
$ git commit --amend -m "#{コメント}"
$git remote set-url リポジトリ名(例:origin) 変更後リモートリポジトリURL
変更後は、git remote -vで確認。
$ git branch
generateなど新規ファイルを作成した後に、全部消したくなったらgit stash->git stash dropを使うと一括消去できる。
stashの後にsaveをつけるとその後にコメントをつけることができる。
$ git stash
$ git stash list
$ git stash pop
$ git stash drop
$ ruby -v
$ rbenv versions
$ rbenv install --list
$ rbenv install バージョン
$ rbenv local バージョン
$ rbenv global バージョン
$ rails -v
- インストール済みのRubyの確認
$ gem info -e rails
- Railsのインストール
$ gem install rails -v バージョン
$ rails _バージョン_ new アプリケーション名
$ brew install nodenv #$ vim ~/.zshrcに以下を追記 $ eval "$(nodenv init -)" #Nodenv-doctorで設定されていることを確認 $ curl -fsSL https://github.com/nodenv/nodenv-installer/raw/master/bin/nodenv-doctor | bash
$ nodenv install -l
$ nodenv versions
$ nodenv version
#これも使える
$ node -v
nodenv install
#グローバル $ nodenv grobal バージョン #ローカル $ nodenv local バージョン
nodebrewのインストールの際、以下のエラーが出ました。
Permission denied @ dir_s_mkdir - /private/tmp/homebrew20201025-17620-12ps03o permission deniedはアクセス拒否、後ろのdir_s_mkdirはちょっと意味がわからなかったが、 調べたところ、権限がユーザーになってないことが原因とのこと。
以下のコマンドで権限をユーザーに戻した。
$ sudo chown -R 'ユーザー名' /private/tmp/
sudoはrootユーザーの権限が必要なコマンドをsudoコマンド経由で実行させることができる、とのことで
ファイルやディレクトリの所有者を変更するコマンドであるchownと-Rオプションを使用することで、カレントディレクトリ配下のファイルやディレクトリの所有者を変更できるようになる、らしい。
この作業をやったところ、nodebrewのinstallが無事に成功しました。
YarnとはJavaScriptソフトウェアの依存関係を管理するプログラムのこと
- Yarnのバージョンを確認
$ yarn -v
$ yarn versions
#add_indexはrailsのメソッド $ rails generate migration add_index_to_テーブル名(モデル名)_カラム名 $ rails db:migrate