20220303のRailsに関する記事は12件です。

【Rails】any?メソッド

モデルにデータが存在するとtrue モデルにデータが存在しないとfalse ブロックで使用する場合はブロック内の条件が一つでもtrueであればtrueを返す。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

【Heroku】herokuでRailsアプリをデプロイする際の基本的な手順のまとめ

本記事の前提 使用環境 Rails 5.2.6.2 ruby 2.6.6 git 2.18.5 AWS Cloud9 省略作業 Herokuアカウントの登録 Gitのインストール デプロイするアプリの作成 デプロイする手順 1.Heroku CLIのインストール Herokuの操作をコマンドラインから行えるようにするために、Heroku CLIをインストールしていきます。 以下の公式サイトからご自身のOSに合ったものをインストールして下さい。 AWS Cloud9の場合 以下のコマンドを全てコピーし、ターミナルに貼り付けて実行して下さい。 terminar $ curl -OL https://cli-assets.heroku.com/heroku-linux-x64.tar.gz tar zxf heroku-linux-x64.tar.gz && rm -f heroku-linux-x64.tar.gz sudo mv heroku /usr/local echo 'PATH=/usr/local/heroku/bin:$PATH' >> $HOME/.bash_profile source $HOME/.bash_profile > /dev/null 2.デプロイするアプリのディレクトリに移動しherokuにログインする terminar $ cd アプリ名 $ heroku login --interactive //herokuにログインするためのコマンド メールアドレスとパスワードが求められるので、それぞれ入力しエンターを押して、無事にログインに成功すると、Logged in as Eメールアドレスと表示されますので確認して下さい。 3. Railsアプリをデプロイするための流れ 大きく以下のような項目に分けてRailsアプリの設定を変更していきます 3-1. rails_12factorの導入 静的アセットファイルをHeroku上でうまく動作するように調整してくれるGemになります。以下のようにGemfileに下記の記述を追加して下さい。 Gemfile group :production do gem 'rails_12factor' end 3-2. Gemfileの各項目の設定変更 次にGemfileの内容をデプロイできる状態に変更していきます。 まず、gem 'sqlite3'と記述がある部分をコメントアウトにします。 Gemfile # gem 'sqlite3' 次に、group :development, :test do - endの中にgem 'sqlite3'を追記します。 Gemfile group :development, :test do gem 'sqlite3' end そして本番環境でPostgreSQLを使っていくために、以下のような設定を追記します。 Gemfile group :production do gem 'pg' end 最後にGemfileの変更を適用するためbundle installを実行します。このとき本番環境に関係するproduction以外の部分を対象とするため、以下のようなオプションをつけてコマンドを実行していきます。 terminar $ bundle install --without production 3-3. config/datebase.ymlの設定変更 本番環境で実際にデータベースと接続するための設定を変更するためdatebase.ymlのproduction:以降を以下のように変更していきます。このときproduction:直下の記述が半角スペース2個分空いていることを確認して下さい。 config/datebase.yml production: <<: *default adapter: postgresql encoding: unicode pool: 5 3-4. config/environments/production.rbの設定 続いて本番環境でassets以下のフォルダから動的な画像の表示していくためにproduction.rbの次の記述をtrueに変更していきます。 config/environments/production.rb config.assets.compile = true 3-5. Heroku上にアプリを作成する ここからHeroku上にアプリを作成していきます。ここでHerokuではGitコマンドでアプリを登録していく関係で、ローカルリポジトリを作成されていない場合はgit initコマンドから作成しましょう。それからheroku createコマンドで新しいアプリを作成していきます。このときアプリ名を指定したい場合は、heroku create アプリ名とすると指定できますが、既に使用されている名前の場合は指定できないので注意して下さい。 terminar $ git init // ローカルリポジトリ作成後 $ heroku create ここで、ターミナルに表示されたアプリのURLにアクセスしてアプリが作成されていることを確認しましょう。 そして、Gitコマンドからファイルの管理が済んでいない方は以下のようにGitコマンドを実行して下さい。 terminar $ git add . $ git commit -m "upload to heroku" そしていよいよアプリのデプロイになります。git push heroku masterからアプリのプッシュを行い、それが終わったら本番環境でのデータベースの作成をheroku run rails db:migrateコマンドで実行します。 terminar $ git push heroku master // 終わり次第以下のコマンドでデータベースを作成する $ heroku run rails db:migrate 補足情報 デプロイしたアプリのURLや情報は以下はheroku apps:infoコマンドから確認できます。 terminar $ heroku apps:info 本番環境にdb/seeds.rbに記述した初期データを登録するためには、heroku run rake db:seedを実行して反映させていきます。 terminar $ heroku run rake db:seed デプロイ後のアプリの更新については、先程と同様にGitコマンドから変更したファイルを反映させます。 terminar $ git add . $ git commit -m "update to heroku" $ git push heroku master こんなエラーが発生したとき こちらの記事の内容を参考にしてみて下さい。 参考記事 【初心者向け】railsアプリをherokuを使って確実にデプロイする方法【決定版】 RailsアプリをHerokuにデプロイする手順 herokuで本番環境にデータ投入
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

【Heroku】Rubyバージョンの差異によるエラーの解決

発生したエラー git commitしたの後にgit push heroku masterを実行し、アプリをデプロイしようとしたところ、Rubyバージョンが2.6.3のためにheroku-20にデプロイできないという旨のエラー発生した。。 解決方法 解決策としてherokuのstackを20から18に下げる方法もあるが、今回はRubyのバージョンをheroku-20に対応している2.6.6に変更することで解決していく。Rubyのバージョンを2.6.6に変更する際の作業の流れは以下のようになる。 1.Rubyバージョンの確認し、Ruby2.6.6をインストール terminal $ rvm -v //rvmのバージョンとインストールされていることを確認 $ rvm list //インストール済みのRubyバージョンを確認 $ rvm install 2.6.6 //Rubyのバージョン2.6.6をインストール 2.Rubyの使用バージョンを2.6.6に変更し、デフォルトのバージョンも変更 terminal $ rvm use 2.6.6 //使用するRubyバージョンを2.6.6に切り替える $ rvm --default use 2.6.6 //デフォルトで使用するRubyバージョンを2.6.6に切り替える $ rvm list //念のためRubyバージョンを確認し、2.6.6がcurrent && defaultなのを確認する 3.GemfileのRubyのバージョンを2.6.6に変更 Gemfile ruby '2.6.6' 4.Gemfile.lockを削除し、再度bundle installを実行 terminal $ rm Gemfile.lock //Gemfile.lockファイルを削除する $ bundle install 5.変更したファイルの差分を反映するためGitコマンドを実行 terminal $ git add . $ git commit -m 'change ruby version' $ git push heroku master 終わりに heroku-20に対応していないRubyバージョンを使用してデプロイしようとするとエラーが発生し、stackのバージョンを下げるよう提案される。 herokuのstackバージョンを下げることで解決しようとすると、アプリのパフォーマンスが低下したり、stackのサポート終了日が早くやってきてしまうといったデメリットがある。そのためHerokuも推奨しているようになるべく最新のサポートバージョンのRubyを使用するのが無難みたいですね。。 参考記事 【解決】heroku-20 You are trying to install ruby-2.6.5 on heroku-20. The Ruby version you are trying to install does not exist on this stack. AWS Cloud9でRubyのバージョンをアップデートする方法 AWS Cloud9 でRuby on Rails の開発環境を構築する
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

【Rails】ページネーション機能の導入

#gem kaminariによるページネーション機能の実装 実装の流れ Gemfileにgem 'kaminari'を追加する。 bundle installを実行してkaminariをインストールする。 rails g kaminari:configを実行してkaminariの設定ファイルを作成する。 rails g kaminari:views defaultを実行してページャで利用するテンプレートを作成する。 該当するコントローラー,ビューにページャを実装していく。 1.Gemfileにgem 'kaminari'を追加する。 Gemfile gem 'kaminari' 2.bundle installを実行してkaminariをインストールする。 terminal $ bundle install 3.rails g kaminari:configを実行してkaminariの設定ファイルを作成する。 terminal $ rails g kaminari:config 4.rails g kaminari:views defaultを実行してページャで利用するテンプレートを作成する。 terminal $ rails g kaminari:views default 5.該当するビューにヘルパーでページャを実装していく。 app/views/posts/index.html.erb <%= paginate @posts %>
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

【Heroku】Rubyバージョンの差異によるエラーの解決

発生したエラー
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Ruby問題 特定の数字を検知するプログラムの実装

はじめに プログラミングスクールでRubyの問題を毎日解いています。 これから平日は毎日何かしらアウトプットのため投稿を続ける予定です。 今回は特定の数字が存在するかどうかを判定するプログラムをinclude?メソッドを使用して実装していきます。 問題 以下の要件を満たすarray123メソッドを実装。 ・配列内に1,2,3が全て入っている場合は、「True」と出力する ・配列内に1,2,3の全てが入っていない場合は、「False」と出力する 雛形 def array123(nums) # 処理を記述 end # 呼び出し例 array123([1, 1, 2, 3, 1]) include?メソッドについて Ruby 3.1 リファレンスマニュアルinstance method String#include? Ruby 3.1 リファレンスマニュアルinstance method Array#include? まずはif文で1,2,3が全て入っている場合は、「True」、1,2,3の全てが入っていない場合は、「False」を記述しました。 def array123(nums) if #条件式 puts "True" else puts "False" end end 条件式は公式マニュアルを参考にし、下記のように記述しました。 &&で1かつ、2かつ、3という記述をしています。(とっても単純ですね) if nums.include?(1) && nums.include?(2) && nums.include?(3) あとはこれをガッチャンコしてこう def array123(nums) if nums.include?(1) && nums.include?(2) && nums.include?(3) puts "True" else puts "False" end end これで1,2,3全てが含まれているかを判別することが出来ました
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Rubyで特定の数字を検知するプログラムを実装する

はじめに プログラミングスクールでRubyについて学習しています。 これから平日は毎日何かしらアウトプットのため投稿を続ける予定です。 今回は特定の数字が存在するかどうかを判定するプログラムをinclude?メソッドを使用して実装していきます。 問題 以下の要件を満たすarray123メソッドを実装します。 ・配列内に1,2,3が全て入っている場合は、「True」と出力する ・配列内に1,2,3の全てが入っていない場合は、「False」と出力する 雛形 def array123(nums) # 処理を記述 end # 呼び出し例 array123([1, 1, 2, 3, 1]) include?メソッドについて Ruby 3.1 リファレンスマニュアルinstance method String#include? Ruby 3.1 リファレンスマニュアルinstance method Array#include? まずはif文で1,2,3が全て入っている場合は、「True」、1,2,3の全てが入っていない場合は、「False」を記述しました。 def array123(nums) if #条件式 puts "True" else puts "False" end end 条件式は公式マニュアルを参考にし、下記のように記述しました。 &&で1かつ、2かつ、3という記述をしています。(とっても単純ですね) if nums.include?(1) && nums.include?(2) && nums.include?(3) あとはこれをガッチャンコしてこう def array123(nums) if nums.include?(1) && nums.include?(2) && nums.include?(3) puts "True" else puts "False" end end これで1,2,3全てが含まれているかを判別することが出来ました
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

rubyにおけるcount,size,lengthメソッドの違い

結論からいうと、配列、ハッシュ、文字列によって異なります。 配列のとき ある条件を満たす要素数を知りたいとき→count 単に配列の要素数を知りたいとき→length, sizecountも使える ハッシュのとき ある条件を満たすkeyとvalueの要素数を知りたいとき→count 単にKeyとvalueの要素数を知りたいとき→length, sizecountも使える 文字列のとき ある条件を満たす要素数を知りたいとき→count 単に文字数をしりたいとき→length, sizecountは使えないです この結論をもとに話を進めていきます。 lengthとsize 先ほどの説明からも分かる通り、同じメソッドなんです。やってることが同じです。 実際にコードを打っても同じ結果が返ってきます。 count countは文字列以外を除いては、lengthとsizeと同じ働きをします。書き方に多少の差はありますが、同じ動きをしてくれます。 では何が違うのか?length/sizeとcountだと処理速度が違ってきます 実際に見ていきましょう 今回は、benchmark_driver という gem を使って処理速度を測ってみます ※以下は@scivola様のコードと結果を拝借しております。 gem "benchmark_driver" require "benchmark_driver" Benchmark.driver do |r| r.prelude "a = Array.new(1000){ rand }" r.report "a.count" r.report "a.length" end すると結果は、 Comparison: a.length: 161043915.9 i/s a.count: 33329644.2 i/s - 4.83x slower lengthは1秒間で1B回処理なされ、countだと1秒間に10M回の処理がなされている。 なぜこのような結果が生まれてしまうのか。countというメソッドについて深堀りしていきたいとおもいます arrayやhashでのcountというメソッドは、 Enumerableというモジュールのメソッドなのです。参考資料 そして、Enumeriableはeachを使ってメソッドが定義されているんです。 eachはN+1問題からもわかるように、不必要な値を取得してしまうことが多々あるんですね。 そのため、countはlength/sizeメソッドに比べて処理が遅いんです。 今回は、length/sizeメソッドとcountメソッドの違い、そしてcountメソッドはなぜ処理が遅いのかという部分を解説させていただきました 以上です。何か間違いがございましたら、ご教示いただけますと幸いです。 【参考文献】
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

ridgepoleを導入したのに、" Migrations are pendding "とはドユコト? のときに見る記事

はじめに 今更ながらrailsアプリケーションにridgepoleを導入してみました。 その際にrails migrateとは別れたはずなのですが、railsのエラー画面で"Migrations are pendding"というmigrationファイルと付き合っていたころの見慣れたエラーに出くわしてしまいました。 別れた次の日にばったりいつもの公園で出会ってしまったカップルのように・・・ どうやら復縁を迫られているみたいです。 そこで、そんな人がそんなときに見る用の記事(migrationと未練を残さずお別れする方法)として、やったことをまとめました。 「そもそもridgepoleとはなんぞ?」 という方は、偉大な先人たちがたくさん知恵を残してくれているのでそちらをご参照ください! (導入まで簡単にできます) 原因調査 1. railsの見ているDBと実際のDBが異なるのではと疑う これまではmigrationファイルでの管理だったため、railsの参照先としているDBが古い方のDBを参照したままなのではないかという、憶測を立てたので確認。 まずは、ActiveRecordで使用しているDBの接続情報を調べてみる。 [1] pry(main)> ActiveRecord::Base.connection_config # => 接続しているDBの情報 {:adapter=>"XXX", :encoding=>"XXX", :charset=>"XXX", :collation=>"XXX", :reconnect=>false, :pool=>5, :database=>"XXX", :username=>"XXX", :password=>"XXX", :host=>"XXX" 次に、環境ごとに設定している、railsのDB情報は、アプリ名/config/database.ymlに記載されているので、確認。 config/database.yml development: <<: *default database: <%= XXX %> username: <%= XXX %> password: <%= XXX %> host: <%= XXX %> socket: <%= XXX %> staging: ~~~ production: ~~~ ちゃんと同じDBを参照していた。 結論: これではない 2. migrationファイル消してなくない? 当たり前のことだったが、migrationファイルを消し忘れていた? (正確には消さなくてもいけるんじゃないかという、migrationに対する未練があった) ridgepoleはアプリ名/db/Schemafileを参照しているので、当たり前だが、ここにmigrationファイルが残っていたらそれはお別れできないですな! # 未練残さずきっぱりと削除 $ rm -rf db/migrate $ rm db/schema.rb これで無事エラーは解決! だがこれで終わってしまうのも、情けないので追加情報 おまけ ridgepoleコマンドをrakeタスク化 通常ridgepoleは以下のようなコマンドで流す -cはconfigファイルの指定。(※ただしコマンドを打つ場所からの相対パスで指定) -Eはdatabase.ymlに記載のどの環境のDB情報か。 ridgepoleコマンド $ bundle exec ridgepole -c ./config/database.yml -E development --apply --file ./db/Schemafile たが長いし、覚えられないし、ということでrakeタスクファイルを作成し、アプリ内(/lib/tasks)に配置。 ridgepole.rake namespace :ridgepole do schema = Rails.root.join('db', 'Schemafile') config = Rails.root.join('config', 'database.yml') environment = ENV['RAILS_ENV'] || 'development' desc 'apply schema migration' task apply: :environment do result = `bundle exec ridgepole --apply --env #{environment} --file #{schema} --config #{config}` puts result end desc 'dry run' task dry_run: :environment do result = `bundle exec ridgepole --apply --env #{environment} --file #{schema} --config #{config} --dry-run` puts result end end これで次回以降は、↓だけで済む! $ bundle exec rake ridgepole:apply メリットでもありデメリットでもあるが、 ridgepoleではSchemafileを直接編集するので、CREATE TABLE ~の文を削除するだけで、DBを簡単にDROPできてしまう。 そんな時のためにも、テーブルDROPのリスク管理を行うようなrakeタスクを作成しておくとより安心だと思う。(↓参考記事) 運用方法 今回のようなことがまた起きないためにも確認してみる。 例えば、rails g コマンドでモデルを新規作成したときを見ると・・・ $ rails c $ rails g model Test => db/migrate ファイルが作られてしまう なのでrails g modelを使用する際にはオプションで --skip-migration を指定 $ rails g model Test --skip-migration ちなみに・・・↓で rails g model で作られてしまったファイルを全て削除できる $ rails d model Test おそらくrailsコマンドの使用した際には、migrationファイルが自動で作られるようになっている。 なので、モデルを作成するときには、--skip-migrationをつけるか、手動でモデルファイルを作成しましょう! という結論も一つあるが、 もしくは↓記事にあるように、application.rbに書くことによって解決できそうです。 さいごに ridgepoleに変えてみて、migrationファイルの管理(束縛)から解放されすごく楽になりました。 男ならいさぎよく未練なくきっぱりとお別れすることが大事だと学びました。 「今までありがとうmigration、これからよろしくrigepole!」
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

limitとoffsetについて

activerecordはrailsを使う際にはよく使われるとおもいますが、コマンドを打ったりコードを書いたりする際にlimitとoffsetをちゃんと知らんかったのでまとめようとおもいます。 limit これは名前から分かるかもしれませんね。 引数に数値を渡すことで、指定したレコード数を取得できます。 例えば、 User.limit(2) # 最初のレコードから2件レコードを獲得される offset これは、特定の位置からそれ以降のレコード数を取得できるメソッドです。 User.offset(3) # 最初から3件目のレコードから最後までのレコードを獲得する 最後にこの2つを合わせた書き方があるんです。 途中から指定した件数を取得 以下のようなコードになります。 User.limit(3).offset(7) # 最初から7番目のレコードから3件値を取得する 次回は、link_toのソースコードをアウトプットしようと思っていますので重めの内容になるかと思います 以上です。何か間違いがございましたら、ご教示いただけますと幸いです。 【参考資料】
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

【Rails】references型

references型って? 自動的にインデックスと外部キー参照付きのカラムが追加され既存のモデルと生成したモデルを関連付けする下準備をしてくれる。 つまり、既存のテーブルを参照して必要なカラムを自動的に追加して新しいテーブルを作成すること。 *すべてのデータベースで使えるわけではない。 例) Micropostモデルを作成 # userテーブルに紐付けて、Micropostテーブルを作成 $ rails generate model Micropost content:text user:references 自動生成されたMicropostモデル micropost.rb class Micropost < ApplicationRecord # belongs_toメソッドでuserモデルに紐付いている(自動的に記述してくれてある) belongs_to :user end Micropostのマイグレーション [timestamp]_create_microposts.rb class CreateMicroposts < ActiveRecord::Migration[6.0] def change create_table :microposts do |t| # contentというstringカラム t.text :content # user参照で外部キー有効 t.references :user, foreign_key: true # imestampsカラム(created_at, update_at) t.timestamps end # user_idとcreated_atカラムにインデックス付与のため記述 add_index :microposts, [:user_id, :created_at] end end user_idに関連付けられたすべてのマイクロポストを作成時刻の逆順で取り出しやすくなる。 下記のように配列を書くことによってActive Recordが、両方のキーを同時に扱う複合キーインデックスを作成する。 add_index :microposts, [:user_id, :created_at] UserモデルにMicropostモデルを紐付ける user.rb class User < ApplicationRecord # has_manyメソッドでmicropostsモデルに紐付いている(自動で追加されないので手動で追加) has_many :microposts . . end
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

references型

references型って? 自動的にインデックスと外部キー参照付きのカラムが追加され既存のモデルと生成したモデルを関連付けする下準備をしてくれる。 つまり、既存のテーブルを参照して必要なカラムを自動的に追加して新しいテーブルを作成すること。 *すべてのデータベースで使えるわけではない。 例) Micropostモデルを作成 # userテーブルに紐付けて、Micropostテーブルを作成 $ rails generate model Micropost content:text user:references 自動生成されたMicropostモデル micropost.rb class Micropost < ApplicationRecord # belongs_toメソッドでuserモデルに紐付いている(自動的に記述してくれてある) belongs_to :user end Micropostのマイグレーション [timestamp]_create_microposts.rb class CreateMicroposts < ActiveRecord::Migration[6.0] def change create_table :microposts do |t| # contentというstringカラム t.text :content # user参照で外部キー有効 t.references :user, foreign_key: true # imestampsカラム(created_at, update_at) t.timestamps end # user_idとcreated_atカラムにインデックス付与のため記述 add_index :microposts, [:user_id, :created_at] end end user_idに関連付けられたすべてのマイクロポストを作成時刻の逆順で取り出しやすくなる。 下記のように配列を書くことによってActive Recordが、両方のキーを同時に扱う複合キーインデックスを作成する。 add_index :microposts, [:user_id, :created_at] UserモデルにMicropostモデルを紐付ける user.rb class User < ApplicationRecord # has_manyメソッドでmicropostsモデルに紐付いている(自動で追加されないので手動で追加) has_many :microposts . . end
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む