新規Railsアプリケーション雛形作成 railsをPCにインストールしている前提で説明していきます。 今回、Railsのバージョンは6.0.0を使用。 データベース管理システムはmysqlを使用します。 ターミナル # アプリケーションを入れたいディレクトリに移動 % cd ~/〇〇〇〇(ディレクトリ名) # Railsアプリケーションで用いる仕組みの一部を設定するコマンドを実行 % bundle config --global build.mysql2 --with-opt-dir="$(brew --prefix openssl@1.1)" # Railsのバージョン6.0.0を用いて、新しいAppを作成(〇の箇所には好きなアプリ名を入れる % rails _6.0.0_ new 〇〇〇〇_app -d mysql # 「〇〇〇〇_app」ディレクトリに移動 % cd 〇〇〇〇_app 上記の操作を行って、 /Users/ユーザー名/指定したディレクトリ名/指定したアプリ名 と表示されれば作成完了です。 データベース作成 ターミナル # 先ほど作成した〇〇〇〇_appディレクトリにいることを確認 % pwd # データベースの作成 % rails db:create コマンドを実行すると、以下の2つのメッセージがターミナルに表示されます。 【例】ターミナル Created database '〇〇〇〇_app_development' Created database '〇〇〇〇_app_test' つまり、2つのデータベースが作成されたということです。 これらは、自分のPCで開発を進めるために必要なデータベースとなります。 今回は % rails _6.0.0_ new アプリケーション名 -d データベース管理システム名 とバージョンを6.0.0に指定しデータベース管理システムはmysqlとしましたが、 私が学習したものがバージョン6.0.0でmysqlを使用したものであったため これらを指定させていただきました。 もし他のバージョンなどで学習されていたらバージョンが変わるとプログラムの書き方が変わることがあるためご注意ください。 バージョンを指定しなかった場合、PCにインストールされている最新のRailsのバージョンが使われます。

環境 Ruby 3.0.2 Rails 6.1.4.1 routes.rbでformat: :json指定しておくと、 APIテストの方で省略できる。 config/routes.rb Rails.application.routes.draw do namespace :api, format: 'json' do resources :users end end spec.rb get api_v1_abc_path(format: :json) #↓ get '/api/v1/abc' 参考

doorkeeperのgemを使用していて、リクエストテストでアクセストークンが必要な場合のやり方 環境 Ruby 3.0.2 Rails 6.1.4.1 Factoryの作成 アクセストークンをFactoryで擬似的に作成。 factories下にapplications.rbとaccess_tokens.rbを作成 spec/factories/doorkeeper/applications.rb FactoryBot.define do factory :doorkeeper_application, class: 'Doorkeeper::Application' do sequence(:name) { |n| "Application #{n}" } redirect_uri { 'https://アプリのURI/callback' } end end spec/factories/doorkeeper/access_tokens.rb FactoryBot.define do factory :doorkeeper_access_token, class: 'Doorkeeper::AccessToken' do transient do user { build :user } end association :application, factory: :doorkeeper_application resource_owner_id { user.id } expires_in { 2.hours } scopes { 'read public' } end end RSpec.describe "Api::V1::Attendances", type: :request do let!(:user) { create(:user) } let!(:oauth_app) { create(:doorkeeper_application) } let!(:access_token) { create(:doorkeeper_access_token, application: oauth_app, user: user, scopes: 'read') } let!(:headers) { { 'Authorization': "Bearer #{access_token.token}" } } describe "GET /api/v1/abc" do subject { get '/api/v1/abc', headers: headers } it '200を返すこと' do subject expect(response).to have_http_status 200 end end end 注意 テスト環境でマイグレーションするのを忘れないこと！ 参考

自己紹介 株式会社じげんの山本です。 賃貸情報サービス「賃貸スモッカ」をはじめとした不動産サービスを展開する住まいDiv.でサーバーサイドエンジニアを担当しています。 英語への苦手意識 エンジニアの皆さんは、言語や、フレームワークのドキュメントを英語で読んだり、GitHub の全て英語で記載された議論を読むことに苦手意識はあるでしょうか？ 僕は以前まで苦手意識がありました。これを読んでいるみなさんも、もしかしたら多かれ少なかれあるのではないでしょうか？ 普通は第二言語で技術を勉強するなんて辛いと思います。「ただでさえ技術がわからなくてググっているわけで、なんでさらに苦労をしないといけないんだ」と思う方もいるでしょう。ただそれでも「英語で技術について読めるようになった方が得ですよ!」という話をします。 「なんで英語で読むと良いのか？」「どうやったら読めるようになるのか？」ということについて書きます。 なんで英語で読むと良いの？ この質問には①量と、②質という方向から回答したいと思います。 ①量 単純な計算で、インターネットにある言語別の情報量を考えてみましょう。 次の表を見てください。 出典 -> https://www.statista.com/chart/4140/low-diversity-of-languages-on-the-web-hinders-accessability/ 左は普段話されている言語で（今回は関係ない）、右側が「インターネットでどれくらいの言語がどの割合で使われているか？」というグラフです。 インターネット上で使われている言語の中での英語のシェアは、実に五割を超えています。 日本語は5.0%なので、10倍以上ですね。 これらからわかるように、情報量が圧倒的に違います。 例えば、開発中に出たエラー文をコピペしてブラウザで検索した時に、最初に出てくるのは英語の stack overflow や GitHub のスレッドではないでしょうか？ 自分は今まで、英語に苦手意識があり、それを見ずに（みすみす正解をスルーして）、他の日本語ページをわざわざ探していました。 その結果、思った回答が見つからずにネットを彷徨っていて、膨大な時間を無駄にしていました。 ほとんどの場合、答えは目の前にあるのです。 ②質 ここまでは量の話でした。 「ただ量が多くても質が悪かったら意味がない」という指摘があるかもしれません。 しかし、英語は質でも勝っているのではないか、という話をしていきます。 例えば、日本では Ruby on Rails で開発を行う現場が多くあると思います。 そして開発中に以下のサイトを参考にしている人は多いと思います。 出典 -> Rails ガイド https://railsguides.jp/ 自分は先日このガイドを参考にしていて、ルーティングのコードを書いていました。 そこで、 defaults の使い方がいまいちわからなかったので該当箇所を日本語訳版で読んでいました。 以下読んでいた箇所の添付画像です↓↓ ここを読んだ時、あまりすんなり理解できなかったので英語の方（原文）も読んでみました。 以下原文版です↓↓ 英語版を読んだところ、急にすんなりと理解できたのですが、両者の違いは最後の一文です。 # 日本語版 上のルーティングはブラウザからの/photos/12パスにマッチし、 Photosコントローラのshowアクションに割り当てられます。 # 英語版 Rails would match photos/12 to the show action of PhotosController, and set params[:format] to "jpg". 皆さんはこの二文の違いに気づきましたか？ 日本語の方では、 path のマッチとアクションの割り当てについてしか書かれていません。 しかし、英語版では、このようにdefaults を書くと、params[:format] の中に "jpg" という値が入ってきますよ、ということが書かれてあります。 改めてですが、僕はルーティングに関してのdefaults についてわからなくて、このドキュメントの defaults の欄を読んでいます 。 その上で、コントローラとアクションについてのみしか書かれておらず、この最後の「 defaults を設定することで params に値が入る」という重要な部分に関する一文がないというのは、解説として不十分だと感じました。 自分が読みたいのはまさにここなのに、それが書かれていません。 ここで特筆すべきなのは、このドキュメントは、日本人の利用者が特に多いRailsのドキュメント だということです。 それなのに、原文の英語版と比べて、日本語ドキュメントは抜けている箇所が所々存在します。 Railsのドキュメントでこれならば、日本人利用者の少ない他の技術のドキュメントでは、もっと質が悪いかもしれません。 じゃあどうやったら英語読めるようなるの？ ここでは以下の2つを書きます - 勉強する - DeepLを使う ①勉強する ベースとして、高校レベルの基本的な英文法がわかっていないと読むのは難しいかと思われます。ここは勉強するしかありません。今後エンジニアとして、答えが見つからずにネットで彷徨う膨大な時間と、人生の一時期英語を勉強する時間を天秤にかけたら、どっちがコスパがいいかは明らかだと、個人的には思います。英語の勉強方法はたくさんネットに載っていますので、自分に合った方法を探してみてください。 基本がわかれば②を使えばできるようになっていくと思われるので、基本をサクッとおさらいするのがおすすめです。 ②DeepL を使う DeepL を使っている人は既にいると思いますが、これは英語のドキュメントを読むのにとても有用な翻訳ツールです。非常にナチュラルな日本語で世界のいろいろな言語を翻訳してくれます。自分は先ほどから、英語を読もうと言っていますが、これは本質的には英語で書いてあるものをよもう！という意味なので、DeepL で原文が綺麗に翻訳された日本語で読めるなら問題ないのです。 以下のリンクから Desktop アプリをダウンロードできますのでしてみてください。 DeepL はWeb でも利用できますが、web じゃなくてアプリをダウンロードしましょう！ より便利で普段使いするならアプリでダウンロードする方が断然便利です。 出典 -> https://www.deepl.com/en/app/ これ、アプリをダウンロードしたら早速使ってみましょう。 例えば、わからない英語記述箇所をカーソル選択して、 (出典 -> https://stackoverflow.com/questions/13906635/what-is-the-activemodel-method-attribute-was-used-for) (Macユーザーの方だったら) command + c を2回連打しましょう。 そうすると、自動で DeepL のウィンドウが前に出てきて翻訳を始めてくれます。 (ローカルでアプリを動かした時のスクリーンショットです) 綺麗に訳せました。 DeepL があったら、勉強は不要なのでは こう思われる方も多いと思います。しかし、一文一文DeepLを使うのは時間がかかり、最終的には使わないことがベストだと思います。 そこで自分は DeepL を補助輪として使うのがおすすめです。自分は最初、これを使うことによって「なるほど、こういうふうに英語の意味を捉えれば良いのね」と理解しながら使っていました。 いずれ慣れてきたら、徐々に使用頻度を落としていって、最後には英語を自分でスラスラ読めるようにしていくのが良いと思います。DeepL はもちろん便利で素早いですが、自分で読めるのがやはり最も早いです。 自分は最初は DeepL を多用して、徐々に使用頻度を減らしていくことで苦手意識を無くしていきました。 最後に 英語の勉強を面倒に感じておられる方も少なくないと思います。 しかし、英語ができる場合とできない場合、エンジニアとしてキャリアを積んでいく過程で大きな差が開いてくる可能性も否めません。 実際に、GitHub の人気レポジトリは、ほとんどが英語です。https://github.com/trending?since=monthly 勉強が苦手という方も、苦手意識の克服がご自身の成長につながると捉えて、英語で読む活動を始めてみませんか？ 長い目で見て必ず大きなリターンが返ってくるものだと思っています。 関連 以下の記事は自分の考えと似ているところがあり、自分の記事に賛同していただいた方には、とても良い記事だと思ったのでぜひ読んでみてください。 私たちはどうして公式ドキュメントが読めないのか？ https://qiita.com/hiraike32/items/f0a211cceb0ecc516b6c

devise サインアウトのリダイレクト先設定時にエラーのが起きてしまう原因について 初めに こんにちは。DMM WEBCAMP Advent Calendar 2021 ８日目を担当します@Hbk__17です! 普段受講生さんに教えていた際に、よく受講生さんがつまづいていた箇所で「deviseを使用した際のログアウトの条件分岐でエラーが出てしまい直せません」といったような質問をよく頂いていたのですが、しっかり解説をしている記事を見かけなかったので、今回私の記事ではなぜこのようなエラーが出現するのかについてと、どのように直せばいいのかを解説していければと思っております！先に早くエラーを治したいという方はこちらをご参照ください。 エラーについて 今回主に解説を行うエラー文は、deviseを使用した際のログアウトを設定した際に起こるこのエラー↓について解説したいと思います！ エラーの和訳 そうしましたら、cannot redirect_to nil!というエラー文の和訳から始めていきたいと思います! cannotはできませんという意味になり、redirect_toは画面の遷移をするメソッドになります、そして最後のnilに関してはよくエラー文で見かけることが多いかなと思いますが空であったり、何もないと説明されることが多いですね。 つまり今回のエラー分の意味としては、リダイレクト先が設定されていませんよ！と怒られていることがわかりますね！ エラーの原因の解説 それではエラー（文）の意味が理解できたところで、application_controllerでサインアウト先を設定しているのにcannot redirect_to nil!と怒られてしまうのかを見ていきましょう！ 実際のコード↓ class ApplicationController < ActionController::Base before_action :configure_permitted_parameters, if: :devise_controller? def after_sign_in_path_for(resource) case resource when Admin admin_items_path when EndUser mypage_customers_path end end def after_sign_out_path_for(resource) case resource when Admin admin_items_path when EndUser mypage_customers_path end end protected def configure_permitted_parameters devise_parameter_sanitizer.permit(:sign_up, keys: [:last_name, :first_name, :last_name_kana, :first_name_kana, :postal_code, :adress, :phone_number, :email]) end end 実際にコードを見ていくと、after_sign_out_pathという設定がありますね！設定があるのにも関わらずなぜ反応しないのでしょうか？実際にエラーを解消する際に便利なのがデバックツールでしたね。 今回は、サインアウトをした際にresourceという引数を受け取りその値を条件分岐をして管理者と会員でサインアウト先を変更しているので、resourceの値をデバックツールを使用して中身を見てあげましょう！ 今回デバックツールとしてgem 'pry-rails'を使用したいと思います！ def after_sign_out_path_for(resource) binding.pry case resource when Admin admin_items_path when EndUser mypage_customers_path end end 上記のように、case文の上にbinding.pryを挿入してあげましょう！ デバックツールも設置できたところで、実際にresourceの中身を見てあげましょう。 デバックツールで、resourceを出力してみると:end_userという値が出力されました。 そこで、疑問に思うのがサインインの時はうまく行っていたのがなぜサインアウトだとうまくいかないのだろうという疑問が生まれると思います。そこでサインインの場合も、デバックツールで止めて中身を見てあげましょう！ すると、先頭にモデル名、そしてモデルの中身のレコードが出力されているのが確認できるかと思います！ここで、サインインの際には、resourceとしてモデル名と中身が受け取れていて、サインアウトの際には:がついたモデル名が返ってきているのがわかるかと思います。ここでわかるのは、そもそものresourceとして受け取っているものが違うためアプリケーションコントローラーで記述している条件分岐がうまくいかないのだとわかります。 :←これは何？ 今回の、サインアウトした時に渡されている:モデル名は普通のモデル名と何が違うの？という疑問が出てくるのではないかなと思います！実際に、:モデル名は普通のモデルとは違うものになります。では、：←これは何かというとシンボルと呼ばれるものになります。シンボルとは、モデルなどを整数として管理を行うものになります。見た目上は、文字列ですが、rubyの裏側では整数として管理をされているらしいです。笑 シンボルを使用する理由としては、メモリとして軽いため処理の速度が速くなるらしいです。 こちらの記事がかなりシンボルの理解をするのに理解が深まったので参考にしてみるのもいいかもしれないです！ シンボルのついた:end_userはモデルとは別物になり、モデルの中身を参照することはできないものとなります。そのため、上記のアプリケーションコントローラーは、モデルに対して条件分岐をしていたため、どの条件にも当てはまらずリダイレクト先が設定されていませんよ！と怒られてしまったというわけです。 なぜシンボルの値が返ってきてしまう？ ではなぜ、シンボルのついたモデル名がサインアウトした際に返されるのでしょう？ 今回は、デバイスの仕様書であるdeviseDocumentを見てみましょう。 devise document↓ このスクリーンショットの、コメントアウト部分に記述があるようにサインアウトの際にはシンボルを返すという仕様にしているようです。 今回のエラーの解決方法 解説が長くなりましたが、ここからはどのようにエラーを解消すればいいのかを解説します！ 先ほどの解説で、サインインの際はresourceとしてモデルが返却されますが、サインアウトの際はモデル名のシンボルが帰ってくるということをお話ししました。つまり、エラーが出ている状態のコードではresourceの中身がモデルであると考えコードを記述していたので、resourceの中身がシンボルであることを念頭において条件分岐を記述してあげればコードのエラーが治るのではないかなと思います！具体的には、 def after_sign_out_path_for(resource) case resource when :admin 　　　　　admin_items_path when :end_user mypage_customers_path end end このように変更をしてあげることによって、resourceの中身と条件分岐をしているものが一致をするのでエラーなくサインアウト先を状況に応じて変更することができるようになると思います。 if分で書くとするならば、このようになるかなと思います！↓ def after_sign_out_path_for(resource) if resource == :admin 　　　　　admin_items_path elsif resource == :end_user mypage_customers_path end end 最後に ここまで、railsのdeviseのサインアウトについて解説を行ってきましたがいかがでしたか？ 少しでもこの記事を読んでくださった方の理解が深まれば幸いです！ 今回この記事を書いてみて、コードを書く際の些細ななぜという疑問を大切に勉強していこうと思いました！ 最後まで読んでくださってありがとうございました〜〜〜！

環境 Rails 6.1.4 やりたいこと ローカルで正常に表示されていた背景画像が本番環境で表示されなかったことの解消 結論 SCSSファイル内の記述を次のように書き換えデプロイすることで正常に表示。 app/assets/stylesheets/〇〇.scss //修正前 background-image: url('bg-image.jpg'); //修正後 background-image: image-url('bg-image.jpg'); なぜ起こったのか？ アセットパイプラインのキャッシュの高速化と『digest』という仕組みが関係している。 上記によって、デプロイ後のapp/assets以下のファイルは全てpublic/assetsに上記のdigest付きになって移動され、参照できなくなったことにより発生したもの。 参考記事

【エラー内容】 パスワード暗号化のため、Gemfileにコメントアウトされていたbcryptを導入したところ、以下のエラーが発生しました。 cannot load such file -- bcrypt 「bundle install」も実行しており、Userモデル内に「has_secure_password」を記述してもエラーが解消しませんでした。 【対処法】 Railsサーバーを一度停止し、再起動(rails s)する事でbcryptの内容が反映されました。 困ったらサーバーの再起動も試してみるべきですね。