概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: Rails Form Objects With dry-rb 原文公開日: 2016/09/06 著者: Michał Gutowski サイト: http://cucumbersome.net/ 現代のRailsでは、Form Objectを作るのは珍しくありません。多くのRuby開発者はVirtusやActiveModel::ValidationsをincludeしてForm Objectを作成することに慣れています。本記事では、dry-typeとdry-validationを使ってForm Objectを作成する方法をご紹介したいと思います。 絵ハガキ（postcard）を作成する簡単なForm Objectを作ってみましょう。このアプリには次の3つのモデルがあります。 Country: フィールドはnameとis_stat
(注：2017/10/16、いただいたフィードバックを元に翻訳を修正いたしました。) (注：2017/10/11、いただいたフィードバックを元に翻訳を修正いたしました。) データベースのドキュメントで分離レベルを目にして、軽く不安を感じつつ、あまり考えないようにしたことはないでしょうか。トランザクションの日常の使用例できちんと分離について言及しているものはほとんどありません。多くはデータベースの初期設定の分離レベルを利用しており、後は運頼みです。しかし、本来、理解しておくべき基本的なトピックであり、いくらか時間を投入してこのガイドの内容を学習すれば、もっと快適に作業できるようになるでしょう。 私はこの記事の情報を学術論文、PostgreSQLドキュメンテーションから集めました。分離レベルの 何たる かだけでなく、適用の正確さを保持しつつ最大速度で使うにはいつ使うべきか、という疑問に答えるべ
ActiveRecord で、has_many で定義した関連があるとき、その関連の件数を取得するのには、count, size, length の３つのメソッドがあります。さらに、0件かどうかを調べるためには、empty? や exists? といった問い合わせメソッドもあります。 これらの使い分けについて、なるべく分かりやすくなるように解説してみたいと思います。 はじめに、has_many関連とは、次のようなコード例における、company.users のことを指します。 class Company < ActiveRecord::Base has_many :users end class CompanyUsersController < ApplictaionController def index company = Company.find(params[:company_id
Rails Developers Meetup 2018で「ActiveRecordデータ処理アンチパターン」というタイトルで発表してきました。 発表資料発表概要ActiveRecordはWebエンジニア達が嫌う（？）SQLを書かずとも、Rubyオブジェクトで気軽にデータベースへアクセスできる魔法のようなツールです。しかし便利な反面、何も考えずにゴリゴリActiveRecordを使ってDBアクセスしていると、劇的に重たいクエリが発行されたり非効率的なクエリが量産されたりします。 本発表ではそれらActiveRecordで陥りがちな罠をパターン化し、ActiveRecordデータ処理アンチパターンとして発表します。 ※発表では実際のサンプルコードとともにパフォーマンスの計測結果も紹介します。 事前に公開したエントリ発表資料に出てくる最初の事例はこちらがベースの事例となっています。 今月末のR
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: Refactor your Ruby on Rails application with policy object pattern 原文公開日: 2018/01/29 著者: Paweł Dąbrowsk Policy Objectは操作の分離に用いられる素朴なRubyオブジェクトのことです。個人的にこのパターンが好きですが、オブジェクトにPolicy Objectとしてふさわしい名前をつけるために従っておくべきルールがいくつかあります。 Policy Objectの規則 メソッド名の末尾は常に?にする メソッドはtrueかfalseのいずれかだけを返す 渡された属性は変更しない コードはシンプルな読み出しロジックだけを行う: データベース呼び出しなどは行わない デモ サンプルのクラスを作ってみましょう。後ほどPolicy Ob
仕事やらなんやらでMySQLのクエリの良し悪しを判断する必要があるとき、EXPLAINの内容だけだとどのぐらい良くなったり悪くなったのか分からないので SET long_query_time = 0; してrows_examined (そのクエリでrows_sent行の結果を返すために何行に触ったのか)も一緒に提示するようにしている(少なくともMySQL 5.7時点ではrows_examinedはslow_query_logでしか確認できないはずperformance_schemaが有効ならevents_statements_historyやその仲間たちで確認できるとのこと*1 MySQL :: MySQL 5.6 リファレンスマニュアル :: 22.9.6 パフォーマンススキーマステートメントイベントテーブル)。 例: 上の例のBeforeは、もともとDBAが書いた温かみのあるSQLでO
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: Refactor your Ruby on Rails app with null object pattern 原文公開日: 2018/01/22 著者: Paweł Dąbrowsk Null Objectパターンによるリファクタリングは、指定されたオブジェクトが存在するかどうかをチェックして、存在しなかった場合に指定の属性やメソッドのデフォルト値を返す操作に適用できます。このような操作ではif条件が必要になることが多く、そのままではコードが少々読みづらいうえにテストも少しばかりやりにくくなります。Null Objectパターンを使うことでコードが非常にシンプルになり、テストも簡単になります。 Null Objectパターンを使うメリットをわかりやすく示すため、次のような事例を考えてみましょう。UserとPostという2つのク
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く