Ruby

As a long-time Ruby on Rails programmer, I thought that the name ActiveRecord –the model layer of Rails’ MVC– was branding. I didn’t know that it’s an architectural pattern, described by Martin Fowler in the 2003 book Patterns of Enterprise Application Architecture. An object that wraps a row in a database table or view, encapsulates the database access, and adds domain logic on that data. https://www.martinfowler.com/eaaCatalog/activeRecord.html

The FactoryBot gem, previously known as FactoryGirl, is ubiquitous in Ruby and Ruby on Rails testing. If you aren’t familiar with it, you might be wondering, what’s the point? Wouldn’t it be simpler to just build objects myself? ...

Why should someone learn Ruby in 2022? Ruby was my first programming language, and although I’ve drifted elsewhere, I write Ruby every day. Many people in my network are Ruby diehards. As a result, it’s been a long time since I’ve gotten the chance to sell someone on Ruby. ...

Conditional logic has its place, but often there’s a better alternative. Today, we’ll look at a Ruby solution: a hash with .fetch. ...

Ruby’s RSpec describe block has two common syntaxes. Which should you use? ...

Open a production Ruby file, and you’ll often see this magic comment at the top. # frozen_string_literal: true Today I’d like to argue that most Ruby files do not need this comment. You aren’t going to need it. ...

Unused dependencies are bad: they increase the size of your project, slow down processes, require maintenance, and send incorrect messages to fellow developers about what’s important. To get find unused dependencies in Ruby, I’ve been using gem stale: gem stale gem stale list gems along with most recent access times. If the last access time was the day you set up the app, that gem is a candidate for removal.

Linters are great, except when they aren’t. One example is Rubocop’s BlockLength lint. For example, I don’t care if my RSpec describe and context blocks are too long. Nontrivial test blocks will never be short enough to match a reasonable rule about blocks. I’ve disabled this lint for these blocks with Rubocop’s configuration file: # .rubocop.yml Metrics/BlockLength: IgnoredMethods: ['context', 'describe'] Opting out of just these blocks lets me enforce this rule everywhere else.

Today I learned about the method __id__, aliased object_id, in Ruby. It returns a unique integer identifier for any Ruby object. A few examples: > Object.new.object_id => 7024702983434 > name = "jake" => "jake" > name.object_id == name.object_id => true > "thawed".object_id == "thawed".object_id => false > "frozen".freeze.object_id == "frozen".freeze.object_id => true I’ve never used this method in practice, but I hope to someday.

Here’s some code that made me do a double take. something = items[nil] It’s that [nil]. What’s going on here? It turns out that items is the return of a call to Ruby’s group_by. group_by groups by whatever the block evaluates to, including nil. [ { shipping: 'fedex', id: 1 }, { shipping: 'fedex', id: 2 }, { id: 3 } ].group_by { |item| item[:shipping] } => { 'fedex' => [{ shipping: 'fedex', id: 1 }, { shipping: 'fedex', id: 2 }], nil => [{ id: 3 }] } Hence the key nil. ...