Arel.sqlを付けるだけじゃダメ!? Railsで"Dangerous query method …”の警告が出たときの対応方法 - Qiita
Arel.sqlを付けるだけじゃダメ!? Railsで"Dangerous query method …”の警告が出たときの対応方法RailsSecurity TL; DR（長いので最初に結論） この記事で言いたいことはこちらです ↓ Rails 5.2で"Dangerous query method ..."の警告が出たからといって、機械的にArel.sqlを適用してはいけません。 警告が出たらまず、該当したコードにSQLインジェクションの危険性がないか見極めることが大事です。 もしその危険性がある場合は、入力値を検証するなどして危険性を取り除いてから、Arel.sqlを適用してください。 「え？何を言ってるのかさっぱりわかりません」という人は、この続きを読んでください。 はじめに Rails 5.1で開発していたRailsアプリをRails 5.2にアップグレードすると、以下のような警
config.load_defaultsとnew_framework_defaults_x_x.rbの関係を詳しく調べてみた - Qiita
config.load_defaultsとnew_framework_defaults_x_x.rbの関係を詳しく調べてみたRubyRails TL; DR（はじめに結論） 以下はRails 5.1から5.2にアップグレードしたケースを想定しています。 必要に応じてバージョン番号を読み替えてください。 Rails 5.2アップグレード後にconfig.load_defaults 5.2と書くと、Rails 5.2のデフォルトの挙動になる 一部にRails 5.1の挙動に戻したい項目があれば、new_framework_defaults_5_2.rbの該当項目のコメントを外し、そのうえで設定値を論理反転させる（trueはfalseへ、falseはtrueへ修正する） Rails 5.1の挙動に戻す必要がなければ、new_framework_defaults_5_2.rbは削除しても構わない
【翻訳】Bundler 3アップグレードガイド - Qiita
はじめに Rubyのパッケージ管理ツールであるBundlerはバージョン 3で後方互換性が失われる様々な変更点が導入される予定になっています。 そして、バージョン 3への移行を容易にするため、バージョン 2.1ではバージョン 3で使えなくなる機能を使うと警告が出ます。 これらの内容については公式リポジトリのアップグレードガイドで詳細が説明されています。 この記事は上記のアップグレードガイドの日本語訳です。 翻訳したアップグレードガイドの版について この記事で翻訳したのは2019年10月3日に更新された以下の版です。 （翻訳時点のBundlerの最新バージョンは2.1.4） 今後更新される可能性もあるため、必要に応じて最新の版を参照するようにしてください。 2020.1.15追記 2020年1月14日更新の版に追従しました。 この版における主な変更点は以下のとおりです。cf. rubygem
bundle install時に--path vendor/bundleを付ける必要性は本当にあるのか、もう一度よく考えてみよう - Qiita
bundle install時に--path vendor/bundleを付ける必要性は本当にあるのか、もう一度よく考えてみようRubyRailsBundler TL; DR（最初に結論） bundle installをする場合は--path vendor/bundleを付けてプロジェクトごとにgemを管理しろ、という意見をよく見かける。 しかし、pathを指定しないと問題が起きる可能性があるのは、かなり特殊な条件下に限られる（100人いたら100人全員が遭遇するような問題ではない）。 よって、--path vendor/bundleのオプションは、付けたい人が付ければよいだけで、開発者全員に強制するようなルールではない、と筆者は考える。 はじめに bundle installコマンドを実行するとき、Ruby界に大きく分けて2つの流派があります。それは「--path vendor/bund
Railsアプリケーションにおけるエラー処理（例外処理）の考え方 - Qiita
はじめに Railsアプリケーションを本格的に作り込んでいくと、「エラー」とは無縁ではいられません。 しょうもないバグでエラーが発生することもありますし、ほとんど不可抗力ともいえるような大規模なネットワーク障害でエラーが発生することもあります。 エラーの種類がなんであれ、エラーが起きた場合は「原因を素早く特定し、速やかに復旧させること」と「あるエラーが引き金になって、さらに大きなエラーに引き起こさないようにすること」が重要です。 エラー処理を適切に実装していれば、原因の特定や復旧もすばやくできますし、さらに大きなエラーを引き起こす可能性も少ないです。 また、ソースコードも比較的シンプルに保てます。 逆にエラー処理が不適切だと原因の特定に時間がかかったり、異常なデータがどんどん増えてさらに大きなエラーを引き起こしたりします。 ソースコードにも無駄に複雑な処理フローや条件分岐がたくさん出てきて
【アンチパターン】Arrange、Act、Assert（AAA）を意識できていないRSpecのコード例とその対処法 - Qiita
【アンチパターン】Arrange、Act、Assert（AAA）を意識できていないRSpecのコード例とその対処法RubyRailsRSpec # トレーニングジムの予約システムを開発していると仮定してください describe 'キャンセル処理' do let(:user) { create :user } let(:reservation) { create :reservation, user: user, start_at: '2017-08-10 10:00'.in_time_zone } context '24時間前をすぎるとキャンセル料が発生する' do before do travel_to '2017-08-09 10:00'.in_time_zone reservation.cancel! end after { travel_back } let(:billing)
サポートが終了したchromedriver-helperからwebdrivers gemに移行する手順 - Qiita
group :test do # chromedriver-helperをインストールすると、必要に応じてChromeDriverをインストールしてくれる gem 'chromedriver-helper' end しかし、このgemは2019年3月31日にサポートが終了します。 NOTICE: Ending support for this gem · Issue #83 · flavorjones/chromedriver-helper chromedriver-helper gemの作者はwebdriversというgemへの移行を推奨しています。 titusfortner/webdrivers: Keep your Selenium WebDrivers updated automatically ちなみに、chromedriver-helperのインストール完了時にも次のようなメッ
【Rails】idでソートするか？created_atでソートするか？ 〜 Re: idの順番に依存しないコードを書こう - Qiita
【Rails】idでソートするか？created_atでソートするか？ 〜 Re: idの順番に依存しないコードを書こうRailsSQL TL; DR（長いので最初に結論） Railsアプリケーションでデータを作成時間順にソートする場合、idでソートする場合も、created_atでソートする場合も、それぞれメリットとデメリットがある。 特に、ソート列をidからcreated_atに単純に切り替えると、場合によっては重大なパフォーマンスの悪化を招く恐れがある 一概に「こっちを選んでおけば安心」という明快な回答はないので、それぞれのメリットとデメリットを理解した上で、要件にあったカラムを選ぼう。 適切な判断を下すためにはSQLやRDBMSに関する知識が必要。詳しくない人はしっかり勉強しよう。 はじめに フィヨルドのkomagataさんが書いたこちらのブログ記事を拝見しました。 idの順番に依
dependent: :restrict_with_error と :restrict_with_exception の違い - Qiita
dependent: :restrict_with_error と :restrict_with_exception の違いRails はじめに：dependent オプションとは？ dependent オプションはRailsであるモデルが子のレコードを持っている場合、親レコードを削除するときに子レコードをどうするのかを決めるオプションです。実際の挙動はいくつかの選択肢の中から選ぶことができます。 オプションの種類 :destroy 親と一緒に子レコードも削除する。（無理心中パターン） :delete_all 親と一緒に子レコードも削除する。ただし、直接DBのレコードを削除するので、子レコードのコールバック処理は実行されない。 :nullify 子レコードの外部キーを NULL 更新する。（みなしごパターン） :restrict_with_exception 子レコードがある場合は Act
RubyとRailsにおけるTime, Date, DateTime, TimeWithZoneの違い - Qiita
RubyとRailsにおけるTime, Date, DateTime, TimeWithZoneの違いRubyRails 2021.2.11追記：DateTimeクラスは非推奨なクラスになりました DateTimeクラスは非推奨なクラスとなり、DateTimeクラスではなくTimeクラスを使うよう、公式にアナウンスされました。 参考1 But we consider use of DateTime should be discouraged. - matz (Yukihiro Matsumoto) https://bugs.ruby-lang.org/issues/15712#note-4 参考2 DateTime は deprecated とされているため、 Timeを使うことを推奨します。 https://docs.ruby-lang.org/ja/latest/class/DateT
Boolean型のカラムを追加するときは必ずデフォルト値を設定しよう - Qiita
tl;dr (最初に結論) Railsのモデルに新しくboolean型のカラムを追加するときは必ずデフォルト値を設定しておいた方がいいです。 すなわち、 のように書きましょう、ということです。 default: false はデフォルト値を false に設定することを示しています。 なので既存のレコードは notification_allowed カラムの値が false になります。 null: false は NULL (Rubyでいうところの nil)が設定されることを禁止するオプションです。 必須ではありませんが、NULL が入ると面倒な問題を引き起こしやすいので基本的に付けておくことをオススメします。 それではこの件に関する詳しい内容を以下で説明していきます。 データベースとRubyで異なる NULL / nil の扱い デフォルト値を明示的に設定しなかった場合、新しいカラムに
使えるRSpec入門・その4「どんなブラウザ操作も自由自在！逆引きCapybara大辞典」 - Qiita
はじめに みなさんこんにちは！ この記事は「必要最小限の努力で最大限実戦で使える知識を提供するRSpec入門記事」、略して「使えるRSpec入門」の第4回です。 今回はCapybaraを使ったフィーチャスペックについて説明します。 ただし、今までの記事とは異なり、フィーチャスペックのイロハよりも「Capybaraの使い方」に重点を置きます。 なぜなら、僕個人の経験からいって、フィーチャスペックで困るのは「このブラウザの操作って、どうやってコードで表現するの？？」というケースが大半だからです。 それ以外は第1回～第3回の内容をそのまま応用できるので、特に「フィーチャスペックだから困る」ということはないと思います。 今回は説明する主な項目は以下の通りです。 フィーチャスペックの基本 ページの移動や画面のクリック、フォームの操作など 画面やフォームの検証 画面の操作や検証の応用テクニック その他
使えるRSpec入門・その3「ゼロからわかるモック（mock）を使ったテストの書き方」 - Qiita
はじめに みなさんこんにちは！ この記事は「必要最小限の努力で最大限実戦で使える知識を提供するRSpec入門記事」、略して「使えるRSpec入門」の第3回です。 今回はRSpecのモックを使ったテストについて説明します。 これまでモックを全く使ったことがない人でもわかるように丁寧に説明していくつもりです。 また、これまでの回と同様、個人的に使用頻度が低いと思っている内容についてはバッサリ説明を省きます。 ただし、第1回や第2回に比べるとテストコードが少し複雑になって、仕組みや動きを想像するのがちょっと難しいかもしれません。 ぱっと頭に入ってこない場合はじっくり本文を読んだり、実際に自分で写経しながらコードを動かしたりするなどして、少し時間をかけながら理解するようにしてください。 今回は以下のような内容を説明します。 モックの基本的な使い方 モックを使った検証 モックでわざとエラーを発生させ
Ajaxでセレクトボックスの中身が動的に変わるRailsアプリの作り方
はじめに 親のカテゴリを変更すると、子のカテゴリの中身が動的に変わるセレクトボックスってよくありますよね。 たとえばこんなやつです↓ この動きを実現するごく簡単なサンプルアプリを作ってみたので、今回はそれを紹介します。 対象となるRubyとRailsのバージョン 今回のサンプルアプリは以下の環境で動作します。 Rails 4.2.1 Ruby 2.2.1 サンプルアプリのソースコード 今回作ったサンプルアプリはGitHubに置いています。 READMEにセットアップ方法も載せているので、ご自身のローカル環境で動かしてみてください。 ざっくりとした処理の流れ この動きを実現するためにはこういう処理の流れになります。 ユーザーが親カテゴリが変更する JavaScriptのchangeイベントが呼ばれる JavaScriptがサーバーに子カテゴリの一覧を問い合わせる サーバーが子カテゴリの一覧を
Rails 5.1の変更点まとめ - Qiita
はじめに 去る2017年2月23日、Rails 5.1.0.beta1が公開されました。 Rails 5.1.0.beta1: Loving JavaScript, System Tests, Encrypted Secrets, and more - Riding Rails Rails 5.1ではマイナーバージョンアップと言えど、かなり大きな変更点が多数入っているようです。 そこで上記公式ブログの内容を僕なりにまとめてみます。 おことわり この記事は公式ブログやpull requestの内容を読んで、筆者が個人的にまとめたものです。 実際に動かして試したりはしていないので、おかしな内容や誤解している内容が含まれている可能性もあります。 もし、「これは明らかにおかしい！」という内容を見つけた場合は、コメントや編集リクエストで優しく指摘してやってください。 サンプルコードについて この記事
実用的な新機能が盛りだくさん！RSpec 3.3 完全ガイド - Qiita
はじめに 2015年6月12日にRSpec 3.3がリリースされました。 APIが大きく変更されたり、派手な新機能が追加されたりはしていませんが、うまく活用するとテストを効率よく書いていけそうな実践的な新機能がたくさん導入されています。 この記事ではそんなRSpec 3.3の新機能を紹介していきます。 新機能一覧 RSpec 3.3で追加された主な新機能は以下の11個です。 これから各新機能の内容を紹介していきます。 特定のエクスペクテーション群をまとめて検証できる（aggregate_failures メソッド） グループやexampleをID指定して実行できる 失敗したテストだけを再実行できる（--only-failures オプション） 失敗したテストを1件ずつ修正できる（--next-failure オプション） テストが増減しても seed を指定したランダム実行が同じ順序で実行
【動画付き】Rails 5.1で作るVue.jsアプリケーション ～Herokuデプロイからシステムテストまで～ - Qiita
はじめに Rails 5.1ではJavaScript/index.html.erb周りのサポートが大きく改善されました。 これにより、Vue.jsやReactといったモダンなJSフレームワークをRails内で非常に扱いやすくなっています。 僕も実際に試してみましたが、本当にびっくりするぐらい簡単にVue.jsやReactを動かすことができました。 そこでこの記事ではRails 5.1とVue.jsを組み合わせたサンプルアプリケーションの作成方法をチュートリアル形式で、できるだけ詳しく説明します。 また、ローカルで動かしておしまい、ではなく、Herokuにデプロイしたり、テストコードを書いたりするところまでカバーします。 この記事自体は長いですが、実際に手を動かすと（スムーズに進んだ場合）30分以内で終わらせることができるはずです！ 今回作成するサンプルアプリケーション 今回は以下のリンク先
Kobitoのサポートが終了してしまったので、Quiverに移行するスクリプトを書いた - Qiita
はじめに すでにご存じの方も多いかもしれませんが、Qiita投稿にも使えるMarkdownエディタのKobitoが突然サポートを終了しました。 Kobito for Mac / Windowsの提供及びユーザーサポートを終了します - Qiita Blog 個人的にはKobitoのヘビーユーザーだったので、この発表は大変驚いただけでなく、慌てて次の移行先を探すはめになりました。 いろいろ検討した結果、僕はQuiverというツールに移行することに決めました。 この記事ではKobitoからQuiverに移行するために作成したRubyスクリプトを紹介します。 イントロダクション 僕のKobitoの利用目的 僕は以下のような目的でKobitoを利用していました。 Qiitaに投稿する記事の執筆、および投稿 外部に公開しない個人的な技術メモや備忘録の保存 前者のQiitaの投稿については最悪Webか
Rails開発におけるwebサーバーとアプリケーションサーバーの違い（翻訳） - Qiita
はじめに 先日スタック・オーバーフローでこんな質問に回答しました。 webサーバー、アプリケーションサーバー、Rackといった仕様や概念と、WEBrick、Unicorn、Pumaといった実装の関係が頭の中で結びつきません 質問者の方はwebサーバー、アプリケーションサーバー、Rack、Unicorn、Pumaと言った用語や概念の理解がこんがらかっているように見えたので、このあたりをきれいに説明している記事を探していたところ、以下の記事を見つけました。 A web server vs. an app server - Justin Weiss スタック・オーバーフローでは記事の一部を抜粋して「ざっくり翻訳」したのですが、それだけで終わらせるのはもったいない気がしたので、Qiitaには全文を翻訳して載せておこうと思います。 これを読むと、あなたもwebサーバーとアプリケーションサーバーの違い
Arelでクエリを書くのはやめた方が良い5つの理由
はじめに：Arelって何？ みなさん、Arel（アレル）ってご存知ですか？ ArelはActive Recordの内部で使用されるSQL生成ライブラリです。 Railsのクエリの書き方をググると、ときどきArelを使った実装例が見つかるので、見たことがある、もしくは何度か使ったことがある、という人もいると思います。 Arelをよく知らない人のために、Arelの利用例をちょっと見てみましょう。 たとえば「コメント文中に、"ruby"が含まれるユーザープロフィールを検索したい」という場合、Rails標準のクエリインターフェースを使うと条件部分のSQLを文字列で書く必要があります。（PostgreSQL環境を想定） Profile.where( "profiles.comment ILIKE ?", "%ruby%" ).to_sql #=> SELECT "profiles".* # FROM
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
