『Ruby on Railsパフォーマンスアポクリファ』 - snoozer05's blog
翻訳を担当した電子書籍『Ruby on Rails パフォーマンスアポクリファ』が発売となりました。 書籍は以下から購入できます。 Ruby on Rails パフォーマンスアポクリファ 本書は、2020年に出版されたNate Berkopec著『The Ruby on Rails Performance Apocrypha』の全訳です。原書は訳書と同様、著者の販売サイトで自主出版の電子書籍として出版され、現在はKindleストアでも販売されています。 The Ruby on Rails Performance Apocrypha The Ruby on Rails Performance Apocrypha: A starter guide to making Rails apps faster and more scalable (English Edition) 作者:Berkope
#Rails + #rspec でハッシュに対して一部のkey/valueの型だけを検証する、ゆるいテストをするには include と b
expect(a: 1, b: Time.now, c: 'wow').to include({a: be_a(Integer)}) # => true expect(a: 1, b: Time.now, c: 'wow').to include({b: be_a(Time)}) # => true expect(a: 1, b: Time.now, c: 'wow').to include({c: be_a(String)}) # => true expect(a: 1, b: Time.now, c: 'wow').to include({c: be_a(Integer)}) # => [#<RSpec::Expectations::ExpectationNotMetError: expected {:a => 1, :b => 2019-12-13 02:08:55.28392210
危険なCookieのキャッシュとRailsの脆弱性CVE-2024-26144 | セキュリティブログ | 脆弱性診断（セキュリティ診断）のGMOサイバーセキュリティ byイエラエ
高度診断部アプリケーションセキュリティ課の山崎です。 弊社エンジニアの名古屋と山崎がRuby on RailsのActive Storageの脆弱性CVE-2024-26144を報告しました。 本脆弱性はRailsの5.2.0から7.1.0のバージョンに影響するもので、お使いのRailsのバージョンが最新でない場合にはアップデートを推奨します。 本記事では本脆弱性の注意点と、関連してCookieのキャッシュに関する調査内容を紹介します。 TL;DR ・ Set-Cookieヘッダがキャッシュされると別人ログイン問題が発生する ・ RailsのActive StorageでSet-Cookieヘッダがキャッシュ可能な設定であった(CVE-2024-26144) ・ Nginx(+ Passenger), Apache(+ mod_cache)等のキャッシュ機構と合わせて利用すると実際に事故が
Rails: ビューをきれいに書くのに便利な知られざるヘルパー10種（翻訳）｜TechRacho by BPS株式会社
概要 元サイトの許諾を得て翻訳・公開いたします。 英語記事: Lesser Known Rails Helpers to Write Cleaner View Code | Rails Designer 原文公開日: 2024/05/30 原著者: Rails Designer -- Railsフロントエンド関連記事に加えて、ViewComponentとTailwind CSSを用いた美しいUIコンポーネントを販売しています 日本語タイトルは内容に即したものにしました。 Rails（厳密にはActive SupportとAction View）には、クリーンなコードを書くのに役立つ非常に優秀なヘルパーがいくつも備わっています。その中から、あまり知られていないが知っておくと重宝するヘルパーをいくつか紹介します。 本記事ではビューレイヤのコードを重視するヘルパーのみを取り上げます。Rails
テストコードでループを使うことの是非について考える | 働くひとと組織の健康を創る iCARE
こんにちは、いっせいです。 先日レビューをしているとテストコード内でループをつかっているものがありました。 頭の片隅に「テストコードではループは使わないほうがよい」という記憶があったのですが、その出典を示すことができずもやもやしていました。 そこで自分のためにも整理のために考えてみたいと思います。 対象のサンプルコード 宛先を指定してインスタンスを生成する案内クラスを考えてみます class Notice def initialize(send_for) @send_for = send_for end def title case @send_for when 'employee' then '従業員のみなさまへ' when 'personnel' then '人事のみなさまへ' when 'doctor' then '産業医のみなさまへ' else 'みなさまへ' end end en
[Rails]カスタムバリデータを実装する
複数間のモデルで同じ条件で検証したい属性がある時、カスタムバリデータを作成することで 同じロジックを各モデルに実装する必要がなくなります。 カスタムバリデータには2種類ありますので、目的に合わせてどちらを使うか選択してください。 validatorクラスを自作する まず、 validators ディレクトリを作ってそこに hoge_validator.rb を作成します。 Railsは、自動で hoge_validator を読み取ってくれます。 個別の属性を検証する場合 1つの属性を検証したい時はEachValidatorが役に立ちます。 class DateValidator < ActiveModel::EachValidator def validate_each(record, attribute, value) return if value.blank? record.err
![[Rails]カスタムバリデータを実装する](https://cdn-ak-scissors.b.st-hatena.com/image/square/f4ffd6ea7eee4889ee334c3fa70eff3f1504683d/height=288;version=1;width=512/https%3A%2F%2Fres.cloudinary.com%2Fzenn%2Fimage%2Fupload%2Fs--3G6CeDYI--%2Fc_fit%252Cg_north_west%252Cl_text%3Anotosansjp-medium.otf_55%3A%25255BRails%25255D%2525E3%252582%2525AB%2525E3%252582%2525B9%2525E3%252582%2525BF%2525E3%252583%2525A0%2525E3%252583%252590%2525E3%252583%2525AA%2525E3%252583%252587%2525E3%252583%2525BC%2525E3%252582%2525BF%2525E3%252582%252592%2525E5%2525AE%25259F%2525E8%2525A3%252585%2525E3%252581%252599%2525E3%252582%25258B%252Cw_1010%252Cx_90%252Cy_100%2Fg_south_west%252Cl_text%3Anotosansjp-medium.otf_37%3Amachamp%252Cx_203%252Cy_121%2Fg_south_west%252Ch_90%252Cl_fetch%3AaHR0cHM6Ly9saDMuZ29vZ2xldXNlcmNvbnRlbnQuY29tL2EtL0FPaDE0R2lZdERDZEtPMDI3bU5DYVpIVl9WckdncUptaXlCbnJrUjc2bm1JM0E9czI1MC1j%252Cr_max%252Cw_90%252Cx_87%252Cy_95%2Fv1627283836%2Fdefault%2Fog-base-w1200-v2.png)
Ruby on Railsでバッチ書く時どうするか問題
別に問題じゃなさそうなことに問題って名前をつけたのは公式で用意してくれているバッチインターフェースが二つあって、いつも迷っちゃうからだ。 $ rails foo:bar:baz のようにコマンドを作れるのがrake taskです。 これは普通にrails db:migrateやrails g scaffold Fooのようにいろいろなところで開発者が使うからおなじみのコマンドです。 もう一つのインターフェースが、rails runnerと呼ばれるやつで、こちらは引数に自由にruby(しかもrailsの資産をつかった)のコードを書くことができる。 普通にバッチを書くならどっちでも問題ない 基本的にどっちを使っても問題はありません。しかしrails runnerを作るときはインターフェースを自分で考える必要があります。以前言及した記事としては app/batches 配下にバッチフレームワーク
ActiveRecord の insert_all で発行されるSQLに ON DUPLICATE KEY UPDATE がある理由
タイトルに書きたいことが長いとタイトル付けに困りますね。 今日は、「Ruby on Rails の ActiveRecord の insert_all で MySQL向けに発行されるSQLに ON DUPLICATE KEY UPDATE foo = foo が含まれている理由」について、知っておこう。（調べました） TL;DR Ruby on Rails の insert_all で発行されるSQLには ON DUPLICATE KEY UPDATE foo = foo が末尾に指定されている foo はどうやら INSERT INTO で登録先として指定している列の1番目 upsert_all に ON DUPLICATE KEY UPDATE が指定されているならまだしも、insert_all にこの指定があるのは感覚的に気持ち悪い 該当の実装部分はここ https://github
Active Job の基礎 - Railsガイド
本ガイドでは、バックグラウンドで実行するジョブの作成、キュー登録 (エンキュー: enqueue)、実行方法について解説します。 このガイドの内容: ジョブの作成方法 ジョブの登録方法 バックグラウンドでのジョブ実行方法 アプリケーションから非同期にメールを送信する方法 1 はじめに Active Jobは、ジョブを宣言し、それによってバックエンドでさまざまな方法によるキュー操作を実行するためのフレームワークです。ジョブには、定期的なクリーンアップを始めとして、請求書発行やメール配信など、あらゆる処理がジョブになります。これらのジョブをより細かな作業単位に分割して並列実行することもできます。 2 Active Jobの目的 Active Jobの主要な目的は、あらゆるRailsアプリケーションにジョブ管理インフラを配置することです。これにより、Delayed JobとResqueなどのよう
Active Jobについて知る - Qiita
なぜ書くのか？ ユーザー登録時にslackに通知する機能を実装した際に、他の実装を真似てApplicationJobを継承した。実装自体はできたが、Active Jobの役割は非同期処理をするくらいの認識で、その仕組みについてしらないことだらけ。なので、Railsガイドに参考に分からない単語を調べたり、実際に実装してみて確かめながら理解を深めていくことにする。 Active Jobの目的 Active Jobの主要な目的は、あらゆるRailsアプリケーションにジョブ管理インフラを配置することです。これにより、Delayed JobとResqueなどのように、さまざまなジョブ実行機能のAPIの違いを気にせずにジョブフレームワーク機能やその他のgemを搭載することができるようになります。バックエンドでのキューイング作業では、操作方法以外のことを気にせずに済みます。さらに、ジョブ管理フレームワー
ActiveJobのperform_laterとperform_nowの違い - Qiita
はじめに ActiveJobのperformメソッドは、perform_laterとperform_nowの2通りで呼び出すことができます（以下のコード例はRailsのAPIドキュメントから引用しました）。 class ProcessPhotoJob < ActiveJob::Base def perform(photo) photo.watermark!('Rails') photo.rotate!(90.degrees) photo.resize_to_fit!(300, 300) photo.upload! end end # perform_laterで呼び出す ProcessPhotoJob.perform_later(photo) # perform_nowで呼び出す ProcessPhotoJob.perform_now(photo) では、perform_laterとper
Ruby on Rails バッチ処理概要｜Offers Tech Blog
はじめに こんにちは。 プロダクト開発人材の副業転職プラットフォーム Offers を運営する株式会社 overflow のエンジニアばばです。 2023 年 1 月に中途入社としてジョインいたしました。 前職では不動産テックのエンジニアとして、データの各種エンジニアリング（クローリング、取り込み、集計処理）や機械学習ロジックのサービスへの組み込みを行っておりました。 overflow では、先日オープンβ版を発表いたしましたプロダクト開発支援組織の生産性最大化を支援するサービスである「Offers MGR」の開発を担当しております。 一見まったく別のプロダクトに見えますが、やっていることは案外共通点があり興味深く毎日開発をしています。 ただ、いまだジョインしたて業務に直結したことを書くネタはないので、Ruby on Rails(以下 Rails)のバッチ処理の概要をまとめてようとおもいま
Active Record バリデーション - Railsガイド
irb> Person.create(name: "John Doe").valid? => true irb> Person.create(name: nil).valid? => false 上でわかるように、このバリデーションはPersonにname属性がない場合に無効であることを知らせます。2つ目のPersonはデータベースに保存されません。 バリデーションの詳細を説明する前に、アプリケーション全体においてバリデーションがいかに重要であるかについて説明します。 1.1 バリデーションを行なう理由 バリデーションは、正しいデータだけをデータベースに保存するために行われます。たとえば、自分のアプリケーションで、すべてのユーザーには必ず電子メールアドレスと住所が必要だとします。正しいデータだけをデータベースに保存するのであれば、モデルレベルでバリデーションを実行するのが最適です。モデルレ
FormクラスでラップしたActiveRecordのエラー内容をマージする
Formオブジェクトを使って、ActiveRecord経由でDBにレコードを保存する場合、エラー内容を適切にマージする必要があるよーということの備忘録。 例えば、以下のようなActiveRecordのUserクラスとFormオブジェクトであるUserRegisterFormクラスがあるとする。 class UserRegisterForm include ::ActiveModel::Model attr_accessor :email def save return false if invalid? # snip... user = User.new(email: email) return false if user.invalid? # snip... end end class User < ActiveRecord::Base # snip... validates :emai
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Hello from RSpec 公式ドキュメント | RSpec 公式ドキュメント
「もうやめて！レビュワーのライフは0よ！」と言いたくなるRSpecの書き方
Rails の便利なメソッド（Array 編） - Qiita
Rails 7 の便利な ComparisonValidator でちとハマった - Qiita
rakeタスクでクエリのログを標準出力に出す | このコードわからん
Rakeタスクの実装 - Qiita
