Arel cheatsheet
About Arel is an SQL abstraction library built into Ruby on Rails. https://github.com/rails/arel Tables users = Arel::Table.new(:users) users = User.arel_table # ActiveRecord model Fields users[:name] users[:id] where (restriction) users.where(users[:name].eq('amy')) # SELECT * FROM users WHERE users.name = 'amy' select (projection) users.project(users[:id]) # SELECT users.id FROM users join basic
shibaraku gem をリリースしました - onk.ninja
shibaraku gem をリリースしました これは何？ ActiveRecord で期間を持つ model を扱う gem です。期間限定公開や、予約公開したいときなんかに使います。 作ったのは 1 年前なんですが、ずっと社内 gem として使用していたものを rubygems.org / github.com に上げました。 https://rubygems.org/gems/shibaraku https://github.com/onk/shibaraku USAGE 基本的な使い方 start_at, end_at のあるモデルを用意します。 create_table :campaigns do |t| t.datetime :start_at t.datetime :end_at end shibaraku と 1 行書くと class Campaign < ActiveRe
Big Sky :: Re: Ruby 製バッチ処理を省メモリ化した
Ruby 製バッチ処理を省メモリ化した - 彼女からは、おいちゃんと呼ばれています 少し前に Ruby 製の バッチ処理 を省メモリ化したときの話をメモしておきます。 どのような バッチ処理 だったか 動画共有サイト にアップされた動画がオトナの事情によって削除されることがしばしばあ... http://blog.inouetakuya.info/entry/2015/07/26/204320 ActiveRecord の each は全件、find_each はデフォルトで1000件をインスタンス化するので、HTML をパースしたDOMツリーが1000件もメモリに乗ったらそりゃ OOM Killer で殺されても文句は言えないかもしれない。 ActiveRecord::Batches The find_each method uses find_in_batches with a bat
GitHub - octehren/Glasses: Search gem for ruby web apps.
Glasses is a micro search framework to be used within Ruby web applications which utilize Active Record as a part of the middleware between the app's logic and database. The gem's methods are based upon ActiveRecord's querying methods, so you can consider them to be Database agnostic, at least in an environment using a relational system such as SQLite, PostgreSQL or MySQL; the gem have not been te
そろそろポリモーフィック関連について一言いっとくか - Qiita
class Notification < ActiveRecord::Base belongs_to :notifiable, polymorphic: true end class Message < ActiveRecord::Base has_one :notification, as: :notifiable end class Like < ActiveRecord::Base has_one :notification, as: :notifiable end 一行で色んなクラスに対する関連が指定できて便利感がある。 だからって、これを安易に使う前にちゃんと考えよう。 ポリモーフィック関連は単に関連の定義を省力化するためのものじゃない。 ポリモーフィックという名前が示す様に、これは多態性を持ったものに対する関連を定義する事であって、インターフェースに対する関連の定義だということ
静的データやマスターデータの為だけにtableを持つのを止めよう。 active_hash が便利そうだ - Qiita
zilkey/active_hash HashデータをActiveRecordのように扱う事の出来るgem。 少し使った感じはかなり便利そう。 Qiitaにactive_hashだけの記事が無かったので書いてみる。 用途 例えば、カテゴリデータや都道府県など、プルダウンに使うような静的データは、色々な持ち方ができます。 単純に定数で扱ってもいいですし、
RailsでActiveRecordの代わりにMongoidを使う - Qiita
はじめに Ruby on Rails(以下Rails)でMongoDBを使う際のORマッパーとして現在はMongoidが標準的に使用されるようになりました。MongoidはActive Recordに似たAPIを備え、かつMongoDBのスキーマレス、ドキュメント指向、ダイナミッククエリ、アトミック操作といった特徴をRubyから容易に扱えるように設計されています。 本記事ではMongoid 4.0.0、Rails 4.1.8をベースに、RailsでMongoidを使う利点を述べ、実際にサンプルアプリケーションを動かして紹介したいと思います。 Mongoidを使う利点 これまでのプロジェクトではActive Recordを介して主にMySQLを使用していましたが、Mongoidを使用するようになって、以下の利点を実感しています。 Active Recordと共通もしくは拡張したクエリと永続化
Railsアプリのパフォーマンスをデータベースリファクタリングとキャッシングで向上する [和訳] - Engine Yard Blog
本記事は英語版ブログで公開された記事の翻訳版です。 パフォーマンスはどんなアプリケーション開発者にとっても大きな懸念です。問題なのは、人は往々にして、実際にパフォーマンスが下がりはじめ懸念すべき事態になるまで問題を放置しがちだという点です。パフォーマンス対策は前もって講じておくべきもので、ほころびが出はじめてから取りかかるのでは遅すぎます。たまのレビューで済ませるのではなく、プロセスの一環に組み込むことが必要です。この記事では、パフォーマンス向上のために開発者が自分でできるいくつかの対策について見ていきます。まずはデータベースです。 データベースのパフォーマンス Railsを使う場合、ActiveRecordやDataMapperといったORMを使えばアプリケーションからのデータ取得を楽にできますが、それだけにデータベースとのやりとりを改善する最適化やリファクタリングの重要性をおろそかにし
Railsプロジェクトの初期開発フェーズでのDBスキーマ管理を見直す | Webシステム開発／教育ソリューションのタイムインターメディア
DBのスキーマ、皆様どのように管理されているでしょうか。 Railsを利用されている方の多くは、ActiveRecordのマイグレーションを利用して管理をされているかと思います。 私もいままでいくつかのRailsプロジェクトに関わってきましたが、 ほぼ全てのプロジェクトでActiveRecordのDBマイグレーションを利用してきました。 (一部のプロジェクトはActiveRecordを使っていないため、マイグレーションも独自のものを利用しています) ActiveRecordのマイグレーションでは、DBスキーマ変更の差分情報をマイグレーションスクリプトとして保存しておきます。例えば、新しいテーブル「users」を作成する場合は、下記のようなマイグレーションスクリプトを作成します。 class AddUsers < ActiveRecord::Migration def up # ここにマイグ
3: Fluentd, Rails, ActiveRecord - Admins Bar
DeNA の @sonots さんと @ryopeko さんに、 Fluentd や Rails 、特に ActiveRecord まわりの運用ノウハウについてお聞きしました。Perl ヘビーユーザーとして有名な DeNA さんですが、 Perl エコシステムの知見が Ruby でのサービス開発・運用に生かされているお話はとても興味深かったです。 Show Notes “2万行の conf” うちの fluentd.conf は２万行あるぞ — そのっつ (SEO Naotoshi) (@sonots) September 27, 2013 Shadow Server on Fluentd at Fluentd Casual Talks #3 DeNA での Fluentd の運用規模、クラスタ構成についての記述がある sonots/haikanko HaikankoというFluentdク
ActiveRecordのjoinsとpreloadとincludesとeager_loadの違い - Qiita
ActiveRecordでN+1クエリを潰すためにeager loadingを行う場合、preloadやincludesやeager_loadが役に立つ。 Preload, Eagerload, Includes and Joinsという記事にそれらの違いがよくまとめられているんだけど、includesが挙動を変える条件があまり正確に書かれていなくて自信が持てなかったし、そもそも記事が古いのでRails4.1.5のソースを読んで調べた。 せっかく調べたので、全体を通して日本語でまとめてみようと思う。 User.joins(:posts).where(posts: { id: 1 }) # SELECT `users`.* FROM `users` INNER JOIN `posts` ON `posts`.`user_id` = `users`.`id` WHERE `posts`.`id
クックパッドにおける最近のActiveRecord運用事情 - クックパッド開発者ブログ
インフラストラクチャー部の成田（@mirakui）です。 Rails の OR マッパーである ActiveRecord ですが、みなさんどのように運用していますか？ ActiveRecord を使うと、 SQL を直接扱うことなく、抽象化された表現で RDB にアクセスできるので、アプリケーションの開発効率という観点ではメリットが大きいです。 一方で、 ActiveRecord が駆使されているアプリケーションをサーバに配置してプロダクションとして運用する立場からすると、いくつかの問題に突き当たります。 まずはクックパッド本体アプリケーションにおける、最新の rake stats をご覧ください。 +----------------------+-------+-------+---------+---------+-----+-------+ | Name | Lines | LOC
ActiveRecordで集計関数の結果を複数selectしたいんです - なんでや。。
select sum(min_salary), sum(max_salary) from jobs; これをActiveRecordで書きたい。 ベタに書くと rec = Job.select(<<-SELECT).all[0] SUM(MIN_SALARY) AS MIN_SALARY ,SUM(MAX_SALARY) AS MAX_SALARY SELECT # => SELECT SUM(MIN_SALARY) AS MIN_SALARY # ,SUM(MAX_SALARY) AS MAX_SALARY # FROM "JOBS" p rec.min_salary # => 124888 p rec.max_salary # => 251088 こうなる。 関係ないけど、仕事中にActiveRecordの書き方で詰まったら、諦めて直接SQL書いた方が早いよね。閑話休題。 こう書けそう
非Rails AppでActiveRecord::Migrationを使う + Rakeでバージョン管理する - Qiita
便利ですよね。Railsプロジェクトに関係ない場合も使いたいです。 Migrationを直接走らせる シンプルなrubyスクリプトを書くことで直接migrationを行うことが出来ます。 require 'active_record' ActiveRecord::Base.establish_connection( :adapter => 'sqlite3', :database => 'db.sqlite3' ) ActiveRecord::Migration.create_table :samples do |t| t.string :body t.timestamps end あとはruby create_samples.rbを実行すればmigrationが実行されます。 Rake Taskで実行する railsの場合rake db:migrateでバージョンの管理とか出来ますよね。
中規模Web開発のためのMVC分割とレイヤアーキテクチャ - Qiita
TL;DR MVCもレイヤで捉えて関係性の設計をするといいのでは 普通のRubyオブジェクトを積極的に使いたいですね 「パーフェクト Rails」に期待しましょう 長くなって面倒くさくなり、途中から手抜き感が半端ないですが許してください この記事の位置付けなど 7 Patterns to Refactor Fat ActiveRecord Models - Code Climate Blog [翻訳] エリック・エヴァンスのドメイン駆動設計 エンタープライズ アプリケーションアーキテクチャパターン これらの参考文献を踏まえてRailsアプリケーションのリファクタリングをしていて、だいぶ方向性や考え方がまとまってきたので、これからチームに合流する人を想定読者に、Qiitaがどんな感じで作られているのかを文書化したものです。（参考文献の一覧は記事の最後にあります） 内容的には文献[2,3]を踏
Railsアプリつくった - ✘╹◡╹✘
最近APIサーバ用途でRailsアプリを1個つくったので振り返る。 概要 接続元はiOSやAndroidアプリとか、Webブラウザとか、別のWebアプリケーションとか。1ホストあたり秒間数百リクエスト、平均応答時間10msぐらい。Rails 4.1.0.rc2、Unicorn、Nginxを使ってる。正直Railsは全部入りで重いイメージがあったので何となく平均50ms以内程度であれば良いところだろうと思ってたけど、意外と速い。多分そもそもサーバの性能が良いんだと思う。実装時に気を付けたことは普段の開発と特に変わりない。いつもは大勢でワイワイ開発するものに少し手を加えるということが多いんだけど、今回は珍しく自分一人でつくったから目が行き届いてたのかもしれない。DBへの問合せの効率に気を配るとか、Rubyでの処理の無駄を省くとか、アプリケーションのプロセスに無駄なコードを読み込ませないとか、計
プライマリキーを使った1:1関連でカラム数の多いテーブルを分割する - Hidden in Plain Sight
おそらく多くのソーシャル系アプリにあてはまるRailsのプチ・デザインパターン的な話。 ぼくが今やっているEast Meet Eastには、ユーザごとに数多くのプロフィール属性があります。名前、性別、生年月日、郵便番号、職業などなど、カラム数にしてざっと25個。これを、全部ひとつのusersテーブルに詰め込むのは、コードの見通しという観点からも性能の観点からも、あまりよろしくありません。 なぜならば、ユーザ関連の情報を扱う局面としては主に メールアドレスとパスワードなどを使ってログインする（アカウント情報） プロフィール情報で条件を指定してユーザを検索・推薦する（プロフィール情報） という２つの独立性の高いユースケースにわかれるため、ログイン処理をやってるときにはプロフィール情報はいらないし、プロフィールを検索してるときにはメールアドレスやパスワードをロードするのは無駄です。また、開発やデ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ActiveRecordで日付ごとにgroup byしたい - 機略戦記
MySQLとActiveRecord
Ruby on Rails on MySQL チューニング入門
