タグ

Railsに関するd_animal141のブックマーク (799)

  • ActiveHashを使ってRailsで区分値を扱う方法 | Webシステム開発/教育ソリューションのタイムインターメディア

    Railsでの区分値の扱いについて考える の続きです。 区分値情報をDBに保存しておくか、アプリにのみ保存しておくのか、悩ましい所です。 DBに区分値を保存しておくと、ActiveRecordなオブジェクトになって扱いやすいという利点があります。 しかし、DBにもアプリにも区分値の情報(ProductTypeの1はLADIESであるといった情報)を持つ事になり、二重管理の状態となる可能性があります。 一カ所変えたら対になるもう一方の修正もしないといけない、という状態は、システム保守の観点からはよろしくありません。 私は過去にアプリ側に区分値情報を更新したのに、DB側に区分値情報を入れ忘れていた! という失敗を体験しました。 区分値情報をアプリ、DB両方に持ってるのはやめたい。でもActiveRecordライクなオブジェクトで区分値を扱いたい。 ActiveRecordのデータソースがcla

    ActiveHashを使ってRailsで区分値を扱う方法 | Webシステム開発/教育ソリューションのタイムインターメディア
  • graphql-batch でバックエンドへのクエリを減らす - ESM アジャイル事業部 開発者ブログ

    こんにちは、hibariya です。最近 ミートアップ が開催されるなど、GraphQL が静かに注目を集めていますね。GraphQL は Web API で使えるクエリ言語です。GraphQL 自体は特定のデータベースに依存しないため、RDBMS を使ったアプリケーションで採用することも可能です。PostgreSQL を使う Idobata でも GraphQL の Public API を公開しました。GraphQL 自体がどういうものかについては、graphql.org や以下の資料が参考になるのではないかと思います。 GraphQL APIRailsアプリに実装した時のメモ GraphQL勉強会 2017.6.7 (補足) Building a Web API with GraphQL GraphQL でサーバ側を実装するときに起こりがちな問題として、クライアントから投げられるク

    graphql-batch でバックエンドへのクエリを減らす - ESM アジャイル事業部 開発者ブログ
  • RSpec で安全に Timecop する - Qiita

    タイトルは釣りで、実はTimecopは不要という話をします。てへぺろ Rails 4.1 以降、 ActiveSupport に travel/travel_to メソッドが実装されたのでこれを使おう。 https://api.rubyonrails.org/classes/ActiveSupport/Testing/TimeHelpers.html travel には相対時間(1日前、とか)、 travel_to には時刻(2000年1月1日とか) を指定して使う。 いずれも Timecop の freeze 相当で時間の流れは止まる。 使用するには include が必要。 rails_helper.rb に1行追加する RSpec.configure do |config| #... config.include ActiveSupport::Testing::TimeHelpers

    RSpec で安全に Timecop する - Qiita
  • Rails6で追加されたinsert_allとimport(とその他)のパフォーマンス検証 - Qiita

    前回書いた記事で、activerecord-importとRails6で追加されたinsert_allのパフォーマンスを比べたところ、importの方が速そうだったのでもう少しちゃんと検証してみました。 検証方法 速度検証 1,000件のユーザーを様々な方法でバルクインサートします。 1回のバルクインサートだと数msで終わってしまうので、上記を100回実行したときの合計時間で比較します。 計測はbenchmarkを使用します。 メモリ使用量検証 こちらも同様に1,000件のユーザーを様々な方法でバルクインサートします。 計測はmemory_profilerを使用します。 環境 Ruby: 2.6.5 Rails: 6.0.0 rspec-rails: 3.9 factory_bot_rails: 5.1.1 対象 activerecord-import Railsでバルクインサートできるよ

    Rails6で追加されたinsert_allとimport(とその他)のパフォーマンス検証 - Qiita
  • Rails の自動読み込みについて - Qiita

    背景 Rails ではファイルを require しなくても自然と動作するので、不思議にも感じなかったのですが、同じ名前のファイルが有る時の挙動がよくわからなかったので Rails の自動読み込みについて調べました。まとまった情報は http://railsguides.jp/constant_autoloading_and_reloading.html にあるのですが、非常に読みにくく感じたので自分なりにまとめました。 Rails は require を使わなくても、ファイルを読み込みます。たとえば Rails がプログラム実行中に未定義の定数 X と遭遇した時、どのように振る舞うのかを下に書きます。 Rails は定数と同じ名前のファイルを探す。定数 X なら x.rb を探す。 全ての config.autoload_paths パスを順に調べる。 たとえば .../assets/x

    Rails の自動読み込みについて - Qiita
  • 【Rails】レプリケーション対応によりDB負荷を半分に減らした - Qiita

    こんちは freee K.K. という会計・給与などの クラウドサービスを提供している会社にて会社員をやっとります @futoase です。 今日は弊社サービスで利用しているDB(RDS)の負荷を半分に減らしてみた、 ということで軽く書いていきたいと思います。お付き合いください。 今期ずっと見続けられてるアニメは、 ゆるゆりとおそ松さんです。 ここで話すRuby/Ruby on Railsの世界とは Ruby 2.1系 Rails 4.2系 以上の世界観となってます。 Ruby 2.1系なのは今月中に2.2にします...(2.3が出てしまう前に...) ベンチマーク方法 について予め言っておきますと、 nginxで収集したaccess.log(staging環境なので開発者がアクセスしたログしかないですよ)を元に 特定のController#Actionへの負荷計測をsiegeにわしてシ

    【Rails】レプリケーション対応によりDB負荷を半分に減らした - Qiita
  • springとbootsnapの違い - ohbarye

  • graphql-rubyのAuthorizationに関する学習メモ - fv17の日記

    Authorization https://graphql-ruby.org/guides#authorization-guides 概要 Authorization: GraphQL vs REST REST APIはリクエストされたアクションの直前に、クライアントがそのアクションに対して権限を持っているかを判断する。 この考え方はGraphQLではマッチしない。その理由は、GraphQLの場合はコントローラが一つしかないため。 class GraphqlController < ApplicationController def execute # すべてのqueries、mutationsがここを通るため、この段階でどのような権限が必要か判断できない if current_user.can?(:"???") MySchema.execute(query_str, context: c

    graphql-rubyのAuthorizationに関する学習メモ - fv17の日記
  • active_hashまとめ - Qiita

    active_hashってなに? gemの一種。 ハッシュのデータを、ActiveRecordと同じ感覚で使えるようにしてくれる。 どういうときにつかうの? 以下の条件2つにあてはまるとき。 ◆これから扱うデータがDBにデータとして保存しておくほど重要ではない、かつ、基的に変更されない。 ◆ActiveRecordと同じ感覚でデータを操作したい。 具体的に言うと? 例えば都道府県名一覧やカテゴリなど「基的に変更されないデータ」があったとする。 そういったデータをDBに保存しておけば取り扱いは楽だけど、データの価値としてはDBに保持しておくほど重要ではない。 じゃあ ↓ の例のように定数でやるか?というとそれも微妙。 コード全体の見通しが悪くなるし、Activerecordを通して使えないので扱いづらくなってしまう。 TODOHUKEN = [ 1: {name: :北海道, locat

    active_hashまとめ - Qiita
  • Rails.composed_of - Qiita

    はじめに 調べ物をしていたら、複数カラムをバリューオブジェクトに構成することで仮想的に一つのカラムとして扱う、composed_ofなるものを見つけたので備忘録します。 住所-よくあるパターン class User attr_accessor :city_address, :town_address, :building_address def address city_address + town_address + building_address end end attr_accessorの部分は実際にはカラムになってると思ってください。 上のパターンにはいくつかの問題があります。 addressのような整形用メソッドがモデルを汚してしまう 来意味を持つのはaddressなのに、メソッドで返ってくるのは単なる文字列 一旦addressを取得しても、そこからcity_addressを

    Rails.composed_of - Qiita
  • GraphQL APIをスキーマファースト開発するためのモックサーバをRailsとApolloで作る - kymmt

    GMOペパボ Advent Calendar 2017の23日目の記事です。 今回はJavaScriptGraphQLのサーバ/クライアントや関連ツールを提供しているApolloのツールセットでRailsプロジェクトGraphQLのモックサーバを立ち上げるところまでを試してみます。 業務でRails製の(RESTishな)Web APIVue.js製のSPAからなるアプリケーションを開発していて、スキーマファースト開発を取り入れています。また、GraphQLで通信するAPIを実験的に導入しはじめていますが、こちらは明示的な開発フローを決めず導入しようとしているため、なかなかサクサクと開発が進まないのが現状です。そこで、GraphQLでも先にインタフェースだけを決めてから、モックサーバを使ってフロントエンドとバックエンドで並行開発していけばよいのでは、という発想になります。 しかし、そ

    GraphQL APIをスキーマファースト開発するためのモックサーバをRailsとApolloで作る - kymmt
  • GraphQL と N+1 SQL 問題と dataloader - Qiita

    この記事ではハイパフォーマンスな GraphQL サーバを実装するのに避けて通れない N+1 SQL 問題について解説します。 TL;DR GraphQL は resolver を個別にかつ再帰的に実行していくため、 RDB のリレーションを効率的に先読みすることができません。そのため一般的に遅延読み込みを行います。 Facebook 社は GraphQL で遅延読み込みするために dataloader という npm パッケージを公開しており、各種言語にその移植版のライブラリが存在しているので、それを使って N+1 SQL 問題を抑制しましょう。 (復習)N+1 SQL 問題とは N+1 問題は「1 つの SQL で N 件のレコードをフェッチしたあと、それぞれ対して関連するレコードを個別にフェッチするのに N つの SQL を発行している」状態を指す言葉です。言葉で書いてもよく分からな

    GraphQL と N+1 SQL 問題と dataloader - Qiita
  • Docker + Rails開発環境Tips - upinetree's memo

    普段なんとなくで設定していたのですが、今の所こんな感じでやるのがいいんじゃない?というのをそろそろまとめたくなったので書いてみました。 もっといい方法があれば教えてください〜。 bundle install の実行のたびにDockerイメージのビルドし直しになるのを回避する bundle install をコンテナで行い、そのディレクトリをホストと共有する gem 用の volume を用意し、そこに格納する デバッガによる対話コンソールを有効にする Railsサーバのコンテナに attach する Railsサーバのコンテナだけ docker-compose up とは別に起動する 対話コンソールで利用されるページャ Springサーバーを有効にする bundle install の実行のたびにDockerイメージのビルドし直しになるのを回避する Quickstart にあるような構成で

    Docker + Rails開発環境Tips - upinetree's memo
  • Railsで考えるドメイン駆動設計のコアドメイン

    銀座Rails#26の登壇資料です https://ginza-rails.connpass.com/event/189892/

    Railsで考えるドメイン駆動設計のコアドメイン
  • Rails:Service層を運用して良かったところ、悪かったところ - Qiita

    1年前くらいにRailsの設計にDDD(ドメイン駆動設計)のService層を導入し、Modelの肥大化対策をしました。 この記事では、まずどのようなルールでService層が組み込まれているかと、1年間運用してみて良かったところ、悪かったところの感想を書きます。 [2018/05追記] 最近ではサービス層の導入は賛否両論あるようなので、導入する際は自分のプロジェクトに合っているかどうかを十分にご検討ください! Service層を導入するきっかけになった問題点 Modelの肥大化 Model間の複雑な依存関係 多数のミドルウェアの導入による複雑さの倍増 これらにより.. メンテナンスやテストがしにくい コードが整理されていないのでとにかく読みづらい Model複雑化の例 <ユーザがECサイトの商品をお気に入り(like)にするメソッドを書く場合> 処理に関連するテーブル my_itemsテ

    Rails:Service層を運用して良かったところ、悪かったところ - Qiita
  • ドメイン駆動設計の比類なきパワーでRailsレガシーコードなど大爆殺したるわあああ!!! - Qiita

    この記事は クラウドワークスアドベントカレンダー2019 12日目の記事です。 概要 こんにちは、怒り駆動リファクタリングを生業としている @MinoDriven です。 弊社リファクタリング専門チーム「バグハンター」で現在実施中のリファクタリング設計について紹介致します。 ドメイン駆動設計 を用い、Railsレガシーコードに対しViewとControllerを ActiveRecord非依存 に変更する設計です。 状況 弊社ブログの過去エントリにあるように、弊社サービスcrowdworks.jpはサービスインから8年経過し、 30万行 を超えるモノリシックRailsアプリになっています。 開発生産性が低下してきています 。 生産性低下の課題を解決しようにも、大規模な上に複雑かつ密結合な構造になっており、 マイクロサービスへの移行も、リプレイスも困難な制約 があります。 そこで半年前にリフ

    ドメイン駆動設計の比類なきパワーでRailsレガシーコードなど大爆殺したるわあああ!!! - Qiita
  • Railsのデザインパターン: Formオブジェクト

    Formオブジェクトとはまず、この記事におけるFormオブジェクトについて定義します。Formオブジェクトはモデル層に属するクラス群で、コントローラ層からユーザーの入力を受けとり整形・検証し永続化する責務をもちます。またビュー層に表示するためのデータを提供する、という役割もあります。 FormオブジェクトはActiveRecordモデルと1対1の場合もありますが、そうでなくてもかまいません。複数のActiveRecordモデルの場合もあれば、対応するActiveRecordモデルがない場合にも採用できます。 Formオブジェクトの必要性Formオブジェクトはフォームの責務をカプセル化し、コントローラやビューを疎結合に保つために必要なデザインパターンです。 ユーザーの入力の整形や永続化をコントローラだけで行うと、コントローラが肥大化してしまいます。この原因はコントローラがモデル層の知識をもち

    Railsのデザインパターン: Formオブジェクト
  • 【翻訳】ActiveRecordにおける、ネストしたトランザクションの落とし穴 - Qiita

    🙅‍♂️この記事の内容は実際のコードに適用しないでください!! (2022-10-5追記) この記事の文でトランザクションに joinable: false というオプションを付けることが推奨されていますが、 joinable: false は内部APIなので指定してはいけない、というのがRails開発チームの見解のようです。 https://github.com/rails/rails/issues/39912#issuecomment-665483779 https://github.com/rails/rails/issues/46182#issuecomment-1266550987 joinable: false を付けるとコミット実行前にafter_create_commitコールバックが呼ばれるなど(参考)、思いがけない別の問題を引き起こすことがあります。 というわけで、

    【翻訳】ActiveRecordにおける、ネストしたトランザクションの落とし穴 - Qiita
  • Ridgepole で主キーを変更する方法(「id」カラムを作らないようにする方法) - 約束の地

    Ridgepole Active Record ほぼ準拠のマイグレーションツールです。 「id」カラムの除去 Ridgepole でごく普通にマイグレーションをすると、「id」というインクリメンタルな主キーのカラムが生成されます。新たにデータベースを生成する際には問題ないとは思うのですが、既存のデータベースのマイグレーションをする場合には不要なことも少なくありません。 「id」カラムを除去するには、create_tableのオプションにid: falseを付与すればよいです。具体的には以下のとおりです。 create_table "テーブル名", force: :cascade, id: false,... do |t|... 新しい主キーの設定 「id」カラムを除去しただけですと主キーが見失われますので、主キーを設定してやります。主キーの設定をするためには3つの記述を行う必要があります。

    Ridgepole で主キーを変更する方法(「id」カラムを作らないようにする方法) - 約束の地
  • Rails5.1の主キーbigint移行

    RailsのPRIMARY KEY(id)はデフォルトでAUTOINCREMENT付きINTEGERですが、Rails5.1でより大きなレコード数を扱えるようBIGINTに拡張されました。 この影響で、ridgepoleでRails5.0以前に作成したアプリケーションにスキーマを適用すると以下のような警告が表示されます。 [WARNING] Primary key definition of `versions` differ but `allow_pk_change` option is false from: {:id=&gt;:serial} to: {} Primary keyを変更するには、以下のようにridgepole 0.7.1で追加された--allow-pk-change(主キー変更を明示許可)を追加する必要があります。 $ ridgepole -c config/data