目的 Rails で GraphQL を使うときはどんな感じに書くのかを確認する 必要なもの Docker(今回使用バージョン: Docker version 20.10.12, build e91ed57) VSCode(Remote Develpment 拡張機能を使用, 今回使用バージョン: Version: 1.64.1) ブラウザ(今回は Chrome バージョン: 98.0.4758.80（Official Build） を使用) 開発環境構築 VSCode を起動して Dockerfile を作成し仮想環境を起動する VSCode で開発用の空フォルダを開く（ここでは /dev/rails_graphql とする) Ruby 環境の Dokerfile を作成する
スタメン エンジニアの松谷(@uuushiro)です。Railsアプリケーションにおいて認証機能にDeviseが利用されるケースは多いと思いますが、サービスの特性次第で メールアドレスをIDとした認証だけでなく、携帯電話番号をIDとした SMS認証、外部ソーシャルID連携やSAML認証、MFA設定など多様な認証機能に対応する必要があります。その際にDeviseにモジュールを追加したりカスタマイズするなど、アプリケーション側で対応することも1つの手ですが、クリティカルな作業で工数がかかる割にはサービスの本質的な競争力の向上には繋がることは少ないです。できれば自前で実装するのは避けたいなと考えていたときに、Amazon Cognito というアプリケーションで必要とする一連の認証機能を提供してくれるサービスを思い出しました。Deviseを利用した認証を Amazon Cognitoに委譲するこ
Railsアプリでデータベースに接続する設定はconfig/database.ymlに書いたり、DATABASE_URL環境変数を設定したりして、与える。database.ymlに書ける内容についての情報がいまいちまとまっていない感じで、調べるのに苦労したのでまとめておく。 設定の例 Rails Guidesに書かれたMySQL設定の例を見ると、こんな感じ。 実用上は、大体ここに書いてあることを設定すればそれで良い。 他にありがちな設定としては、socketではなくhostとportを使うこともあったり、sslcaのようなオプションを渡したりすることだと思う。 設定の分類 ActiveRecordの設定は、 Connection poolに関するもの MySQLの接続に関するもの の二つがある。 Connection poolの設定 Connection poolの設定には、pool、id
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: Managing db schema changes without downtime 原文公開日: 2018/03/22 著者: Sam Saffron -- Discourseの共同創業者であり、Stack Overflowでの開発経験もあります。 後半で紹介されているgemについては先週のRailsウォッチもどうぞ。 2018/04/09: 初版公開 2022/10/25: 細部を更新 Discourseのメンバーはいつも継続的開発の大ファンであり、コミットのたびにCIのテストスイートと対決しています。すべてのテスト（UI、単体、結合、スモーク）にパスすれば、自動的にコードの最新バージョンがhttps://meta.discourse.orgにデプロイされるようになっています。 私たちが継続的開発というパターンに沿って実践し
先日、Rails で開発しているときに意図しない InvalidAuthenticityToken エラーが発生して、すごくハマってしまいました。そのときに Rails のCSRF対策の仕組みについて調べてみましたので、ブログに残しておきます。 Rails のCSRF対策 Rails が生成した ApplicationController には以下の記述があります。 class ApplicationController < ActionController::Base # Prevent CSRF attacks by raising an exception. # For APIs, you may want to use :null_session instead. protect_from_forgery with: :exception end protect_from_forg
前提知識 Rails アプリにおいて、テーブルの追加やカラムの追加は簡単なものの、カラムの削除やリネームは慎重に行う必要がある。たとえアプリからそのカラムを参照してないとしても、いきなりカラムを削除するとエラーになる可能性が大いにある。 というのも Rails にはスキーマキャッシュというものがあり、テーブルのカラム情報をモデルがキャッシュしているからだ。このキャッシュはたとえばいわゆる N+1 クエリ問題を避けるために includes (eager_load) するときに参照される。 SELECT 句で t0_r0 のような機械的に別名が振られるようなクエリを見たことがある Rails エンジニアは多いと思う。 機械的に全カラムを取得するためにスキーマキャッシュを利用しているため、このようなクエリが実行されてる中でカラムを削除したりリネームしたりすると、スキーマキャッシュをもとに並べら
Rails 5.1 以降で attribute_was, attribute_change, attribute_changed?, changed?, changed 等が DEPRECATION WARNINGRails 何が起きたか? Rails 5.1 へアップデートして大量に DEPRECATION WARNING や spec エラーが起きたので、調べてみると Rails 5.1 で ActiveRecord::AttributeMethods::Dirty の attribute_was attribute_change attribute_changed? changed? changed 辺りが非推奨になった。 参考: https://github.com/rails/rails/blob/ce93740a5e4437dfc1cf9b0b13da1bad06a2a598/
待望されたYarnサポートの入ったRails5.1が2017年4月にリリースされました。 Ruby on Rails 5.1 Release Notes — Ruby on Rails Guides 他にもjQueryがデフォルトdependencyから外されたり、Optionalでwebpackサポートが入ったりしており、Railsのフロントエンドは大きな転換点を迎えたと言ってよいでしょう。本エントリではRailsのフロントエンド技術の今を振り返り、今後どうなっていくかをまとめてみたいと思います。 DisられてきたRailsフロントエンド Railsのフロントエンド技術スタックは、フロントエンドを専業とするエンジニアにDisられるものでした。具体的には下記の技術要素です。 jQueryCoffeeScriptAssets Pipeline (sprockets)gemのエコシステムに乗っ
Navigating the world of software engineering or developer productivity insights can feel like trying to solve a complex puzzle, especially for large-scale organizations. It's one of those areas where having a cohesive strategy can make all the difference between success and frustration. Over the years, as I’ve worked with enterprise-level organizations, I’ve seen countless instances where a lack o
はじめに ここ一年くらいずっと Rails の何がダメでどうすれば良くなるのかを考えていました。 Rails を使ってそれなりの規模のアプリケーションを作ったことがある人なら、メンテナンスのしづらさを感じたことがあるのではないでしょうか。 メンテナンスの問題は Rails 以外の開発でも発生することですが、実のところメンテナンスしやすいアプリケーションはどうすれば作れるのでしょうか？ この難問に対して私も答えを持っていませんが、考え続けています。 少なくとも、 Rails Way や Rails Tutorial をベースにしたアプリケーション開発は、業務で用いるには簡単すぎるように思います。 「レールに乗る」という言葉がありますが、私は考え方を変えました。 Rails は規模の大きいフレームワークですが、土台に過ぎません。 Rails Way の設計方針は小規模な開発では有効ですが、規模
こんにちは、技術推進室の篠崎（前回より5ヶ月ぶり）です。 Ruby on Rails（以下Rails）にはイベント（SQLを実行する、テンプレートを描画するなど）に対してフック（計測）できる仕組みがあるのはご存じですか？ おなじみのログもこのフックの仕組みを利用して出力されています。（1行目除く） Started GET "/samples/1.json" for 127.0.0.1 at 2014-12-10 12:35:30 +0900 Processing by SamplesController#show as JSON Parameters: {"id"=>"1"} Sample Load (0.5ms) SELECT `samples`.* FROM `samples` WHERE `samples`.`id` = 1 LIMIT 1 Sample Load (0.5ms) S
Help us understand the problem. What is going on with this article? Rails3.2からRails4.2に上げたらActiveRecordが遅くなったので、どうやって調査して、どのように対処したかを語ってみたい。 とても長いので、ダルい人は最初と最後だけ読めばよいです。 TL;DR 環境: Ruby 2.1.5 ARオブジェクトを大量に(ざっくり750kくらい)loadするバッチ処理 3.2系での実行時間は約480sec、 4.2系では約2900sec 約6倍の性能劣化 原因: preloadで性能劣化してた CollectionProxyの生成周りで遅くなってた Rails4からARオブジェクトの1attribute毎にObject生成するので遅い GCの時間も増えた 調査方法: Githubのcommit、Issueを
Railsのモデル間のリレーションのメソッドには、多くのオプションがある。 今日は、それらを使ってできることをまとめていきたい。 リレーションのオプションでできること一覧 1. ポリモーフィック関連の定義 2. ポリモーフィック関連が定義されたモデルと他のモデルの関連の定義 3. 親モデルに子モデルが依存するようにする 4. 親モデルのプライマリーキーを設定する 5. 外部キーのカラム名を設定する 6. 紐づくモデルのインスタンスを取得するメソッドの名前を設定する 7. 紐づくモデルのobjectに対してvalidationを実行しない 8. ２階層以上離れているモデルのインスタンスを取得する 9. 親モデルのオブジェクトがsaveされたとしても、loadされている子モデルのオブジェクトの変更はsaveされないようにする 10. ひとつのモデル(A)から他のモデルを通して、もう一度モデル(
目次 TL;DRテーブル構成 Railsモデル構成has_many, through の定義 belongs_to, through は使えない？1. delegate を使う方法2. has_one, through を使う方法 includes も使うことができるどちらの方法が良いか？参考TL;DRhas_many+throughの逆の関連の定義には: belongs_to+throughは使えないdelegate or has_one+through が使えるhas_one+through の方が効率もよく、 includes も使えてオススメテーブル構成とあるRailsアプリケーションでこんなテーブル構成があったとします。 Railsモデル構成ユーザー（User）は複数の記事（Post）をもっていて、その記事は複数のコメント（Comment）を持っている、という状態です。 clas
追記: 2017/09/06 少しAPIが冗長なもののActiveRecordへのモンキーパッチが少ないバージョン activerecord-precounter というのを作りました。こちらの方がバグりにくいはずなので、現在はactiverecord-precounterの方を使うことが推奨されます。 github.com 概要 N+1 countクエリを最大11.7倍速くできるactiverecord-precountというgemを作った。 *1 k0kubun/activerecord-precount N+1 countクエリ Tweet.all.each do |tweet| p tweet.favorites.count end # SELECT `tweets`.* FROM `tweets` # SELECT COUNT(*) FROM `favorites` WHERE
昨日、行われた クラウドｘスマフォ時代のRuby on Rails入門 セミナーで使ったコードをGitHubに置きました。 簡単な Ruby on Rails で作ったサーバーと連携できる iOSアプリです。 コード、セミナー資料 GitHub Rails側 GitHub iOSアプリ セミナー発表資料 コードの特徴 Rails側は CarrierWaveを使った画像アップロート・サムネール付き Deviseを使った認証 デザインはTwitter Bootstrap iOSアプリの認証(basic認証) JSONでの画像受け取り Herokuへデプロイ出来ます モデルにRSpecが書いてあります iOS側は UICollectionView UIImagePickerController NSRailsを使ったRailsとの通信 などです。
ActiveRecordを支える技術 – Arelとは何者なのか? (全5回) その1 #activerecord#Arel#rails#ruby#sql 2014年 05月 04日 nishio Rails3, ActiveRecordからは、内部でArelと呼ばれるSQL生成用のライブラリが利用されています。 今回、Arelが内部でどのようにSQLを生成しているのかを調査したので、当ブログにて公開いたします。 ちょっと長くなってしまったため、全5回に分割しました。 以下、目次となります。 ActiveRecordを支える技術 – Arelとは何者なのか?(全5回) その1 [この記事]Arelについてなぜ調査しようと思ったのか、その背景と今後利用するサンプルコードを掲載しています。ActiveRecordを支える技術 – Arelとは何者なのか?(全5回) その2シンプルなSQL文、「
2013.08.12 [Rails 4.0] 巨大なテーブルやserializeを使うときのActiveRecordオーバーヘッドを測定してみた Railsは遅い！とよく言われますが、高速化ポイントのうち最有力候補の1つがDB/モデル周りです。 N+1問題を修正するだけでも、体感できるレベルの高速化が期待できます。 しかし、RubyKaigiでCookPadの方も言っていたように、RDBMSがSQLを実行する時間だけでなく、ActiveRecordオブジェクトの処理は非常に重いです。 モデル周りの最適化と聞いて、一生懸命SQLをEXPLAINするのも大事ですが、ログに出力される「Prefecture Load (0.5ms)」のような数値にはActiveRecordオブジェクト部分のオーバーヘッドが含まれていないため、全体でどの部分が遅いのかを理解しないと徒労に終わってしまう可能性がありま
![[Rails 4.0] 巨大なテーブルやserializeを使うときのActiveRecordオーバーヘッドを測定してみた｜TechRacho by BPS株式会社](https://cdn-ak-scissors.b.st-hatena.com/image/square/462f535f93b9e3c20b95b265234a8d29d49b7112/backend=imagemagick;height=288;version=1;width=512/https%3A%2F%2Fproxy.goincop1.workers.dev%3A443%2Fhttps%2Ftechracho.bpsinc.jp%2Fwp-content%2Fuploads%2F2013%2F04%2Frails.png)
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
