イントロ rails のモデルは自動で id というカラムを作ってくれますが、これは常に INT 型。 BIGINT 型にしようとしたら、結構ハマったのでメモする。 使っている database はmysql です。 (postgresql だとこの罠は回避できるのだろうか？) tl;dr 普通に頑張ると... db:migrate と db:setup の実行結果が異なる migration ファイルの内容が、schema.rb に(一部)反映されないため db:migrate と db:setup の実行結果が異なると、 db:rollback ができなくなるので、辛くなりそう。 db:migrate か db:setup どちらかを使わない、という運用方式もある だが、面倒くさいので、そういうことを意識したくない 解決方法は 2 つ format_schema = :sql kami

Ruby で DB を扱うちょっとしたスクリプトを書くとき、ActiveRecord で生SQLを使うと色々捗ることが多い。 そのためのメソッドをまとめてみた。 事前準備： establish_connection 作成・更新系： execute 検索系： select_all, select_one, select_rows, select_values, select_value プレースホルダ： sanitize_sql_array 事前準備 establish_connection DBとのコネクションを確立する。'mysql2', 'postgresql', 'redshift' など様々なアダプタが使える。 以下は接続設定の一例。 [MySQL] (要 mysql2 gem) require 'active_record' config = { adapter: 'mysql2

Rails 5から、migration versioingという機能が追加されました。 これは、generatorが生成するマイグレーションファイルに、Railsのどのバージョンで生成されたマイグレーションファイルなのかという情報を付与し、そのバージョン情報によりAPIの挙動を変える、というものです。 実際にRails 5.0.beta1でマイグレーションファイルを生成してみると、以下のような内容のファイルが生成されます。 $ ./bin/rails g model book name:string # db/migrate/20160124064808_create_books.rb class CreateBooks < ActiveRecord::Migration[5.0] def change create_table :books do |t| t.string :name t

db/schema.rbは何に使われるのか rake db:migrateなどをすると現在のスキーマが反映され、スキーマの確認などに便利なschema.rb。 ふと、1つのRailsアプリを分割して、複数のRailsアプリから同じDBを参照するようにしたくなったのだが、その際にどちらのRailsアプリにもdb/schema.rbを含める必要があるのか気になった。 db/schema.rbを削除してもアプリは動くのだが、 schema.rbには「It's strongly recommended that you check this file into your version control system.」と書いてあるので、本当に削除していいのか自信がない。 そこで、Rails4.1.5のソースを読んで、schema.rbがどんな用途に使われているのかを調査した。 schema.rbが

Railsへのコントリビューションに関する次のドキュメントを読んでみました。 (英語) Contributing to Ruby on Rails — Ruby on Rails Guides (日本語) Ruby on Rails に貢献する方法 | Rails ガイド この中で特に参考になった部分を中心に書いていきます。 😼 コントリビューションの基礎 Ruby on Railsのバグを見付け足ら「Issues · rails/rails - GitHub」で既存のものがないか探して、な、ればPOST 最新版(edge)はバグがある可能性があるし、バグが有った場合に取り込まれやすいのでコントリビュートのチャンスが多い。コントリビュートのチャンスが多い 🎂 セキュリティの問題が見つかった場合 GitHub ISSUEにあげてはダメ(悪用される可能性があるから) 「Ruby on Ra

まあ、タイトルは若干釣りで、特定のユースケースにおいて3割程度の高速化が見込める、というだけです。 joker1007/curl_escape: This gem provides fast URL escape by libcurl. 以下、実装経緯。 Railsのurl_forを辿っていくと、最終的にクエリパラメーターとして渡したハッシュやらArrayやらに対して、Object#to_queryを発行します。 このObject#to_queryの実装は、ほぼCGI.escapeの実行です。 やたらとlink_toの数が多くて、クエリパラメーターをそれなりに渡している、というページを表示しようとすると、割とこの処理時間が馬鹿にならない感じになってきます。 ということで、CGI.escapeを早くすれば、ちょっとはマシになるんじゃないかと思いました。 しかし、CGI.escapeの実装をR

ActiveRecordのコールバックが実行される順序、およびそれらのタイミングでのロールバックするためのやり方をまとめてみました。 Callback タイミングまずは順序について。下記のようになっています。 before_validationafter_validationbefore_savebefore_create or before_updateafter_create or after_updateafter_saveafter_commit実際にコードで試してみるそれぞれのコールバックをコードで試してみる。こんなコールバックを設定したUserモデルを作る。 class User < ActiveRecord::Base before_validation -> { puts "before_validation is called" } after_validation ->

12/09/05 監視対象のWebサービスのURLを間違えていたため修正しました RailsのAdvent Calendarを待ちわびていました． 今回は，WEB+DBの最新号のRails高速化記事で紹介されていたパフォーマンス監視サービスのNew Relicを使ってみた話です． New Relicは．newrelic_rpmというgemをインストールすることにより，レスポンスタイムやスロークエリなど，パフォーマンスに関するさまざまな統計情報をNew Relicのサイトでみることができます． Railsに限らずPythonやJavaなどいろいろな言語に対応しているようです． さらに，HerokuやDotCloudなどのPaaSにも対応していてやばい． HerokuのNew Relicプラグイン Herokuにホストしたアプリケーションを監視するためにはNew Relicプラグインを導入する

1. ベンチマーカー プロファイルすると、プロファイル自体に時間がかかるので正しく速度が測れない。そのためベンチマーカーも使うと良い。 ただし、ベンチマーカーはどこが遅いか等の解決の糸口は教えてくれない。 benchmark-ips 2. プロファイラ 実際に速度のボトルネックを見つける際に使う。 stackprof どのメソッドに多くの時間を費やしているかがわかる これを入れても速度にさほど影響がない rblineprof 行ごとにかかっている時間を出してくれる peek-rblineprofを使うとブラウザで結果が見れる ただしプロファイリングに結構時間がかかる (3. NewRelic) 実際、これらのことを手元でやらなくても、特にstackprof的なことや、どこのページやどのSQLクエリが特に遅いかなどは、 New Relic がやってくれます。お金を払うと結構詳細な部分も見れま

明けましておめでとうございます！ 正月中にswift覚えて、イケイケモバイルエンジニアに華麗な転身を遂げる予定でしたが結局swiftは1行も書きませんでした。 しかしswiftを代償に捧げた結果、Railsのrequest-specからレスポンスを抽出して、サーバのレスポンスをモックできるautomockというgemができました。 github.com automock is 何 WebAPIに対しては、極力中のロジックに関与せず(モックも極力使わずに)、特定のリクエストを投げたら決まったレスポンスが返ることをブラックボックスにテストするのがいいよね、というベストプラクティスがあり、この形式で書かれたものはrequest-specと呼ばれています。 これに関しては以下の記事が詳しいです。 RSpecでRequest Describer - Qiita このテストは実際にrequestを投げ

dependent: :restrict_with_error と :restrict_with_exception の違いRails はじめに：dependent オプションとは？ dependent オプションはRailsであるモデルが子のレコードを持っている場合、親レコードを削除するときに子レコードをどうするのかを決めるオプションです。実際の挙動はいくつかの選択肢の中から選ぶことができます。 オプションの種類 :destroy 親と一緒に子レコードも削除する。（無理心中パターン） :delete_all 親と一緒に子レコードも削除する。ただし、直接DBのレコードを削除するので、子レコードのコールバック処理は実行されない。 :nullify 子レコードの外部キーを NULL 更新する。（みなしごパターン） :restrict_with_exception 子レコードがある場合は Act

書き方 例として、micropostsテーブルにuser_idカラムを外部キーとして設定したいと思います。 （この例では、他にcontentカラムもテーブルに設定しています。） 普通に user_id カラムを作成 class CreateMicroposts < ActiveRecord::Migration def change create_table :microposts do |t| t.string :content t.integer :user_id t.timestamps end add_index :microposts, [:user_id, :created_at] end end references を使う references はuser_idカラムを作成します。 class CreateMicroposts < ActiveRecord::Migrati

投稿推進部の外村（@hokaccha）です。 クックパッドブログの開発でRails上にECMAScript6などのモダンなJavaScript開発環境を導入した経験を元にノウハウを紹介したいと思います。 RailsはSprocketsというgemでJavaScriptやCSSをコンパイルする仕組みが提供されています。Sprocketsによるasset管理の仕組みは非常によくできており、AltJSのトランスパイルやファイルの結合、minifyなど、assetのコンパイルに必要な機能を一通り備えています。 しかし、JavaScriptにおけるモジュールの依存関係の解決や、ライブラリの管理などについてはモダンなJavaScript開発と乖離してきているのが現状です。そこで、Railsでも以下のようなことを実現できることを目標に環境を作りました。 ECMAScript6のシンタックスを使う モジュ

Rails とかで例外が発生したときに Slack に通知するやつ作った。 exception_notification という便利 gem のプラグインとして動く。 GitHub - morygonzalez/exception_notification-slacky: Notify exception to slack channel Notify exception to slack channel. Contribute to morygonzalez/exception_notification-slacky development by creating an account on GitHub. github.com 実は ExceptionNotification 本体に SlackNotifier あるんだけど、通知内容があっさりしてて自分たちのユースケースには合わなかっ

ja: datetime: distance_in_words: half_a_minute: "30秒前後" less_than_x_seconds: one: "1秒" other: "%{count}秒" x_seconds: one: "1秒" other: "%{count}秒" less_than_x_minutes: one: "1分" other: "%{count}分" x_minutes: one: "約1分" other: "%{count}分" about_x_hours: one: "約1時間" other: "約%{count}時間" x_days: one: "1日" other: "%{count}日" about_x_months: one: "約1ヶ月" other: "約%{count}ヶ月" x_months: one: "1ヶ月" other: "

はじめに 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と共通もしくは拡張したクエリと永続化

前提 この記事では Ruby on Rails 3.2.x 系について話をする。 はじめに Ruby on Rails ではコントローラーごとにビューヘルパーが作成される。 例えば、次のようなジェネレーターを実行してみる。 $ bundle exec rails g controller hoge > create app/controllers/hoge_controller.rb > invoke erb > create app/views/hoge > invoke test_unit > create test/functional/hoge_controller_test.rb > invoke helper > create app/helpers/hoge_helper.rb > invoke test_unit > create test/unit/helpers/hog

2014/11/19追記 最近はrails_configに乗り換えました。 環境毎にファイルが分かれるので定数の数が増えてきた場合はrails_configの方が管理しやすいです。 Railsで定数を一元管理する(rails_config) Ruby2.0, Rails4で確認 railsで定数を一元管理したい時にsettingslogic gemをよく使っています。 gem追加

はじめに railsのsprocketsがキツイ。特にjsファイルが多くなると開発がとっってもキツイ。 layoutに こうやってるだけでも出力されたhtmlにはscriptタグが30個ぐらいならんでて、ページの読み込みに10sec以上かかる。 だけど、単にapp/assets/javascriptsをgulp watchとかはしたくない。 なぜならビルドはブラウザのリロード時に変更がある場合だけして欲しかった。 あとwindow.AppNamespace以下にモジュール追加していくのも辛い。 モジュール同士の依存関係もよくわかんないし、何よりwindow.AppNamespace.Modules.UserList.ItemViewとか長すぎ！ browserify-railsってやつ使ってみた browserifyがrailsの仕組みの中で動くようになる。 browserify-rail