1. Extending ActiveRecord with custom types

    Wood letters acting as an analogy for custom types in ActiveRecord.

    In the last article, we saw how to use the ActiveRecord Attributes API to make Ruby on Rails models more communicative. The two explicit benefits of doing so from that article were a more discoverable data model and a uniform way of defining different types of attributes. The article also hinted at using richer data types to model attributes. That is the topic of this article.

  2. Use the Attributes API to make your Rails models more communicative

    The Ruby on Rails logo.

    ActiveRecord is the powerful object-relational mapper at the heart of Ruby on Rails. By default, it gives you tools to quickly and easily create new database tables and map them to domain models. It follows the ethos of “convention over configuration” that David Heinemeier Hansson coined with the release of Rails. As such, with little application code, you get a powerful, database-backed model that Just Works™.

  3. 3 Ways to Make Arel a Joy

    Many question mark cut-outs laying on a table with a few highlighted, representing SQL queries.

    Arel, the SQL syntax tree constructor library backing ActiveRecord, allows you to express your SQL queries without the use of fragments. ActiveRecord uses it internally to represent a variety of queries. It does this transparently using the traditional where(key: value) syntax that we’ve seen since the early days of Rails.

  4. Null-based ordering in ActiveRecord

    A digital clock showing a zero to symbolize a null value and how to order it.

    When designing your domain model for an application, the natural solution might end up using a nil to model the absence of a value. In these cases, you might need to reach for null-based ordering within your database. When you’re writing a Ruby on Rails application, you’re most likely going to use ActiveRecord as the interface to your database. While ActiveRecord supports most queries out-of-the-box, sometimes you have to go off the beaten path.

  5. A checklist for reviewing Rails database migrations

    A joking todo-list for the day saying: 1. Wake up, 2. Coffee, 3. The rest.

    Software teams often cite code reviews as a primary means for ensuring quality and reducing bugs in their code. However, without high quality reviews, the efficacy of this practice is questionable. In most places that I’ve worked, a change requires only one code review (either through necessity due to team size or through informal norms). When this is the case, the code review becomes a taxing process where, if you’re not on your game, bugs or maintainability issues can start to leak into production. This means that it often falls to the senior engineers to do code reviews. However, relying entirely on the seniors means that they become a bottleneck in the process. When it comes to “dangerous” changes like Rails database migrations, the bottleneck of relying on a small subset of the team can mean that velocity drops. Or, to keep up velocity, you make code reviews less stringent and quality drops.

  6. Grouped pagination in ActiveRecord

    Sometimes, designers will mock-up an extremely usable page that they’ve thought about and tested. Once they’re done and they bring it to you to implement, you look at it and think, “how on Earth can I do that efficiently?” One such case happened at work recently.

Hi, I'm Michael Herold. I am a husband, father of two, and a staff engineer at Shopify working on the Shop Search team.

I'm a Rubyist by trade and maintain Hashie and KSUID for Ruby. I am working to better the IndieWeb experience in Ruby, in particular for the Bridgetown static site generator, which I use to host this website.