Ruby

You might have heard that using blocking, waiting code, e.g., sleep in many languages, is discouraged. Why? Introduction to Sleep Sleep is a blocking, waiting function present in some languages. Here’s sleep in Ruby. # task.rb print "Starting task... " sleep 10 # Simulating some activity... puts "done." The user experiences a printed output, with ten seconds of time between the ellipses and “done.” $ ruby task.rb Starting task... done. It’s used when we want to wait for a task to be finished. Pretty cool, right? ...

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

In this post, I’ll explain what factories are and why you want them, using Ruby. The FactoryBot gem 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 build objects myself? An Example Let’s say we’re unit testing a full_name method on a User class. full_name takes two pieces of data, first_name and last_name, and combines them with a space. Let’s also assume that we’ve tried to ensure data integrity by requiring the presence of these two fields. ...

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. I’d recommend Ruby because it is optimized for developer happiness, it’s an exceptional scripting language, it grants access to Ruby on Rails, it has a fantastic community, and it provides stable work. ...

Conditional logic has its place, but often there’s a better alternative. Today, we’ll look at a Ruby solution: a hash with .fetch. My thanks to Brian Dunn, who showed me the value of this technique. Imagine you have a method that translates some data, a symbol for a role, into a presentation. A conditional is a popular solution here: def display_name(role) if role == :customer 'angler' elsif role == :employee 'guide' else name.to_s end end I think this method is much improved as a hash: ...

Ruby’s RSpec describe block has two common syntaxes. Which should you use? # With `RSpec` module name RSpec.describe TestedClass do end # Without module name describe TestedClass do end Disclaimer: they both work. But I’m assuming since you’re here, you’re curious about the distinction, or want to make a reasoned choice. TL;DR: I suggest using the RSpec module name. The Options The global availability of describe is called the Global Namespace DSL. RSpec made describe available on Object, the default root of all Ruby objects. The intent was to let us write specs without explicitly specifying the RSpec module. ...

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. YAGNI— You Aren’t Going to Need It. Why? I believe it: Is a relic of the past Doesn’t do what people think Isn’t Ruby-ish Is associated with unproven performance claims I’d like to see it deleted from the code I work on, and I don’t think we should be enforcing its presence most of the time. ...

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.