Railsでイベントの処理時間を計測したりログを出力する - QiitaDeleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
Railsアプリに秩序をもたらすGem、Trailblazerとは？ - Qiita
ここ1年で、Trailblazerの認知度は急速に上がってますよね。 BestGemsで見てみるとここ1年でめっちゃ伸びてます。 1月時点で6万4千DLだったのが、9月現在で既に15万を突破しているので、今年だけで倍以上のダウンロードですね…！ 今回はそんな要チェックなGem、Trailblazerについて簡単に見ていきたいと思います。 Trailblazerとは Trailblazerは、RailsやSinatraなどで綺麗にビジネスロジックを書くためのGemです。 ModelやControllerが肥大化してカオスになっているアプリケーションに秩序をもたらしてくれます。 …なのですが、「具体的に何をするGemなの？？？」ってことですよね。 Trailblazerは複数のGemから構成されています。今回は代表的なGemである Operation 、 Reform 、 Cells、 Rep
既存プロジェクトでkakurenbo-putiを使うときのtips - Qiita
この頃、論理削除に関する論争があったと思いますが、Railsではacts_as_paranoid, paranoia, kakurenboなど様々な論理削除用gemが登場しており、私もこれらのgemを利用していました。しかし、ActiveRecordのメソッドをオーバーライドするこれらのgemは、Railsのバージョンアップで壊れる可能性があり、メンテナンスされなくなってしまうとこれらのgemの影響でRailsのアップグレードができないということになりかねないため、paranoidを使うのをやめて、kakurenbo-putiを使うように修正中です。 kakurenbo-putiは、ActiveRecordのメソッドを上書きすることなく、機能追加という形で論理削除用のメソッドを入れるという方式のため、安全です。 しかし、既にparanoiaを使っているプロジェクトを修正していく際に、結構ハ
RailsでHTTP APIのエラーレスポンスを "problem detail" 形式で返却する - Qiita
Web API開発において、エラーをどういう形式で返却するか、というのは設計する際の悩みポイントかもしれません。エラーレスポンスの仕様の1つとして RFC7807 Problem Details for HTTP APIs があります。 この形式をサポートしつつ Rails や Sinatra でも使える Ruby ライブラリをこの度作りましたのでそのご紹介。その名も ProblemDetails. 本記事では Rails での使い方について。 ProblemDetailsの機能概要 gem では以下の機能をサポートしています。 RFC7807形式を実装したオブジェクトクラス Railsサポート: problem detail 形式でレスポンスする problem renderer Sinatraサポート: problem render function problem details 形
dependent: :restrict_with_error と :restrict_with_exception の違い - Qiita
はじめに：dependent オプションとは？ dependent オプションはRailsであるモデルが子のレコードを持っている場合、親レコードを削除するときに子レコードをどうするのかを決めるオプションです。実際の挙動はいくつかの選択肢の中から選ぶことができます。 オプションの種類 :destroy 親と一緒に子レコードも削除する。（無理心中パターン） :delete_all 親と一緒に子レコードも削除する。ただし、直接DBのレコードを削除するので、子レコードのコールバック処理は実行されない。 :nullify 子レコードの外部キーを NULL 更新する。（みなしごパターン） :restrict_with_exception 子レコードがある場合は ActiveRecord::DeleteRestrictionError が発生する。（引き留めパターン） :restrict_with_er
Rails5: production環境でのAutoloadの廃止 - Qiita
下記のように自前でautoload_pathsに追加したパスはproduction環境では自動読み込みされません。 # ./config/application.rb config.autoload_paths += %W(#{config.root}/lib)
これはMUST！ActiveSupport の Class#class_attribute を使おう！ - Qiita
この記事は Ruby on Rails の Advent Calendar 2015 の11日目です。 この記事では ActiveSupport の Class#class_attribute を紹介します。 Class#class_attribute を使うと、親クラスの設定値をデフォルト値にしつつ、子クラスでその動作をカスタマイズするということがカンタンにできます。 はじめに クックパッド社の Ruby styleguide はご覧になったことはありますでしょうか？ その中で下記のような記述があります。 [MUST] クラス変数 (@@foo) を使用してはならない。代わりに class_attribute を使用すること。 なぜクラス変数を使用してはいけないのでしょうか？ この class_attribute とはなんでしょうか？ なぜ class_attribute の使用が MU
データベースにindexを張る方法 - Qiita
データの読み込み速度を改善する上で、indexを張ることは非常に大切です。 ただし、張り方や張る箇所によっては、目に見えた改善が見られなかったり、むしろ速度が遅くなってしまうケースもあります。 そこで、indexへの理解を深めるべくindexの基礎的な内容を記します。 1.indexってなんぞや 特定のカラムからデータを取得する際に、テーブルの中の特定のカラムのデータを複製し検索が行いやすいようにしたものです。 例えば、あるユーザーをバイネームで検索したい！となった際に、Usersテーブルのnameカラムにインデックスを張ってないと、プログラムは、Userテーブルのnameカラムを上から順にみて、そのユーザーのデータを取得します。もし、これが1万人もしくはそれ以上の大量のデータを含むカラムだったらどうでしょう。すごく時間がかかりますね。 Usersテーブルのnameカラムにindexを張る
Railsのポリモーフィック関連とはなんなのか - Qiita
はじめに Railsのポリモーフィック（polymorphic、多態性）関連について、実装方法を説明している記事は見かけるのですが、実際これがどんなものでどんな時に便利なのかを説明している記事があまりなく、よくわからないで使っている人もいるようなので本記事を書きました。 実装方法そのものについては詳細には説明しませんので、Railsのポリモーフィック関連をどう書くのかを知らない方はまずは公式ドキュメントを読んでいただけると理解が早いかと思います。 ボリュームは少ないので、2分もかからないかと思います。 Rails Guides: 2.9 ポリモーフィック関連付け "どんなものか"について、先に結論 ポリモーフィックとはダックタイピングの一種であり、 別の言い方をするとGoFのデザインパターンで言うところの「プログラムは実装に対してではなく、インターフェースに対して行う（Program to
Ruby on Rails with Grape: JSONシリアライザの比較 - Qiita
概要 携わっている案件で作成しているRailsアプリケーションでは、JSONシリアライザとしてRablを採用していました。しかしどうもRablが遅い。 そこで、さまざまなシリアライザを比較してみることにしました。 世間では"ActiveModel Serializerが圧倒的に早いぞ！"というのをよく見るが、だいたいの検証記事はひとつのモデルのインスタンスをそのままシリアライズするような場合。 関連するモデルの情報を含めたり、モデルの属性から算出する値を含めたりする場合の性能比較は見つかりません。 そこで、より現実に即した状況で性能を比較検討してみましたというものです。。 全選手入場！！ 比較対象は次のよっつ。 ActiveModel::Serializer Grape::Entity Jbuilder (個人的には一番書きやすくて好き) Rabl バージョンはそれぞれ active_mo
Rails における内部結合、外部結合まとめ - Qiita
0. はじめに Qiitawはじめ、さまざまなところでRailsのActiveRecordの内部結合や外部結合に関する記事がありますが、それらがまとまって存在していると良いリファレンスとなるのではないかと思い本記事を作成しました。 また、Rails5で動作確認しておきながら、Rails5から追加されたleft_outer_joinsなどは載せてません。今後、載せていきたいと思います。 group byやサブクエリ（副問い合わせ）に関しては下記もご参照ください。 ActiveRecordにおけるGROUP BYの使い方 ActiveRecordでサブクエリ（副問い合わせ）と内部結合 0-1. RubyとRailsとPostgreSQLのバージョン $ ruby -v ruby 2.2.4p230 (2015-12-16 revision 53155) [x86_64-darwin15] $
ActiveModel::Attributes が最高すぎるんだよな。 - Qiita
Ruby on Rails 5.2.0.beta2が出て久しい。 僕はRails大好きっ子なので 社内の新規事業や、社外のお手伝いしているベンチャー企業では もちろん、Rails5.2を使って開発をしている。 すでに、新しいRailsに関する記事はいくつか挙がっているが 個人的に、一番インパクトが大きかったのはActiveModel::Attributesが導入されたことである。 待望のActiveModel::Attributes ActiveModel::Attributesでなにが変わったの？というと、 いままでActiveRecordでしか使えなかった一部の機能が、ActiveModelでも使えるようになっただけである。 いや、しかし！ 今までのActiveModelの最大の弱点は まさにこの ActiveModel::Attributes が無かったことだと思う。 それが、Rai
grapeバリデーションのエラーハンドリングの仕方 - Qiita
params :sample_params do optional :locale, type: String, desc: 'locale' requires :auth_token, type: String, desc: 'auth_token' requires :age, type: Integer, desc: 'age' requires :data, type: Array[String], desc: 'data' end しかし、このバリデーションには意外な欠点があって、 例えば値が空な時に発火するよう自作した俺俺エラーがあったとしても、 それがraiseする前にgrape validationのエラーがraiseしてしまう。 その為、grapeが発火させるエラーをいい感じで整形してレスポンスを返したい。 そんな時は、resque_fromを使ってあげよう。 modul
Railsでやってしまいがちな保守性を下げてしまうコードとその解決策 - Qiita
こんにちは。COUNTERWORKSアドベントカレンダー13日目担当の疋田です。 先月からエンジニアとしてJOINしました。現在、業務ではshopcounterというサービスのRailsアプリケーション開発や日々の運用、データ集計や分析を元にしたプロダクトの改善などをメインで行っています。 スタートアップのエンジニアを経験していく中で、常に素早くPDCA回してユーザからのフィードバックをプロダクトに反映することが重要になってくるため、エンジニアとしてはコードの変更のしやすさとか捨てやすさ、読みやすさってかなり重要だなーと改めて強く思ってます。 今回は3年くらいRailsやってきた中でちょっとずつ溜まってきたメンテするときこういうコード辛かったなって部分を共有できたらなと思います。 ちなみに、これらはすべて今までの自分自身もやっていた時期があるコードであり、反省の意味も込めて書いてみます。
Rails❤️SQLのサンプルコード #railsdm - Qiita
Rails Developers Meetup 2017で発表した「Rails❤️SQL」のサンプルコードです。 スライド スライドはこちらにあります。この記事とあわせてどうぞ。 Rails❤️SQL #railsdm // Speaker Deck 1. ちょっと凝った検索条件 Formモデル target_none?やxxx_selected?は独自のprivateメソッドです（コード例は省略）。 class ProjectSearchForm include ActiveModel::Model attr_accessor :keyword, :project, :customer, :member def result scope = Project.all if keyword.present? conditions = [] if target_none? || project
先人達から学ぶRailsのテーブル設計 - Qiita
はじめに Ruby on Rails Advent Calendar 2017 - Qiita の4日目の記事です。 背景 Railsのテーブル設計について、社内で議論することは多いのですが、サービスの要となる部分であるが故、社外にER図を公開するケースは少なく、自分達のサービス開発時以外にテーブル設計を学ぶ機会が少ないです。 目的 OSSで公開されているRailsアプリケーションのソースコードから、テーブル設計に関するデータをまとめることで、テーブル設計時の議論に活かすことを目的とします。 具体的には、「1テーブルが持つ情報量として、どれくらいのカラム数が妥当なんだろう…？」や「テーブル名やカラム名を命名する時にどちらの単語の方が一般的に使われているんだろう…？」といった疑問点の解消を目指します。 方法 OSSで公開されているRailsアプリケーションの見つけ方 AwesomeRails
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Railsのdefault_scopeは悪だ！(default_scope is evil) ということらしい - Qiita
railsのdefaultでは用意されていない考え方や設計、リファクタリングについてのリンク集 - Qiita
Rails consoleでreload!する場合の注意点 - Qiita
Active Storage + S3 による添付ファイル機能を試してみる - Qiita
