DEV Community: Thomas Riboulet

An Introduction to Auth0 for Ruby on Rails

Thomas Riboulet — Wed, 31 Jul 2024 14:00:00 +0000

From custom-made to plug-and-play forms of authentication, Ruby developers have plenty to choose from these days. Yet, as you may know, building your own solution can be costly and dangerous. If Devise is the de facto standard for most teams, an alternative might simplify the lives of most.

This article will cover the setup and use of Auth0 in a Ruby on Rails application, including everything you need to get going properly, from handling roles to relying on multiple providers to authenticate users.

Getting Started

Here's what we need to get started:

An Auth0 account
A Ruby on Rails application (version 7.x onwards)

Auth0 is a third-party authentication service with a free tier that lets you handle up to 7,000 users. That is plenty to get you started, and its pricing is reasonable if you need more advanced features.

Configuring Our Ruby App in Auth0

Since your application will rely on Auth0 to authenticate users through redirects and calls, we must ensure it stays secure.

In our Auth0 account, let's create an application within a tenant. You can create multiple tenants in an account to separate:

Domain names.
Different environments (development, production, etc).
The country or region within which data will be stored.

Once you have created your first tenant, you can build an application. That's where we'll start.

Head to the "Settings" tab in the application panel. You need to copy and paste the following and save it to a safe place:

The domain name: app-name.[eu,us,..].auth0.com
The client's ID
The client's Secret

We must also fill in the following Application URIs. We'll use these values for our local development setup:

Allowed Callback URLs: http://localhost:3000/auth/auth0/callback (the URL Auth0 will redirect to after authentication).
Allowed Logout URLs: http://localhost:3000 (the URL Auth0 will redirect to after someone logs out).

Let's go ahead and configure our app.

Preparing Our Ruby on Rails Application

You can start with a vanilla Ruby on Rails application using the rails new command.

Let's generate one that relies on SQLite3 for the database and Tailwind for the CSS library. Skip the installation of mini-test and name the application "Auth0 article":

cd ~/my_projects
rails new -d sqlite3 -c tailwind -T auth0_article

Create a User model with just a few attributes:

cd auth0_article
bin/rails db:create
bin/rails generate model User email name
bin/rails db:migrate

This builds a simple but efficient base for our application.

Adding the Auth0 Gem to the App

You'll need omniauth-auth0 and omniauth-rails_csrf_protection to use Auth0 in your Ruby on Rails application.

gem 'omniauth-auth0', '~> 3.0'
gem 'omniauth-rails_csrf_protection', '~> 1.0'

Configuring Auth0

We need to create a tiny configuration file (config/auth0.yml) to store credentials in our development environment.

development:
  auth0_domain: <YOUR AUTH0 APPLICATION DOMAIN NAME>
  auth0_client_id: <YOUR AUTH0 APPLICATION CLIENT ID>
  auth0_client_secret: <YOUR AUTH0 APPLICATION CLIENT SECRET>

We can also rely on environment variables here by using some erb:

development:
  auth0_domain: <%= ENV['AUTH0_APPLICATION_DOMAIN'] %>
  auth0_client_id: <%= ENV['AUTH0_APPLICATION_CLIENT_ID'] %>
  auth0_client_secret: <%= ENV['AUTH0_APPLICATION_CLIENT_SECRET'] %>

Of course, relying on Ruby on Rails credentials ensures that things stay more up-to-date.

This file will be used in the Auth0 initializer (config/initializers/auth0.rb), which we will now create:

AUTH0_CONFIG = Rails.application.config_for(:auth0)

Rails.application.config.middleware.use OmniAuth::Builder do
  provider(
    :auth0,
    AUTH0_CONFIG['auth0_client_id'],
    AUTH0_CONFIG['auth0_client_secret'],
    AUTH0_CONFIG['auth0_domain'],
    callback_path: '/auth/auth0/callback',
    authorize_params: {
      scope: 'openid profile'
    }
  )
end

As you can see here, we are using Rails.application.config_for to load up the content of a YAML file as a convenient hash. We could replace this with any secret handling library, including Rails encrypted credentials storage.

Note the following:

The provider name (:auth0)
The three items from the YAML file, read and used through the AUTH0_CONFIG hash.
The callback_path key and value, matching the one we configured in the Auth0 interface.
The authorize_params and the scope key inside it; we will come back to that later.

We need to create the interface and routing elements to allow for authentication.

Setting Up Routes and UI with Tailwind

In this example, we will work with a Ruby on Rails application using version 7.1 of the framework with TailwindCSS.

Use the following command:

rails new -d sqlite3 -c tailwind -T myApp

We can then add two controllers with the index action, preparing to test the authentication process:

bin/rails g controller public index
bin/rails g controller private index

With those two commands, the following are created:

Both public_controller.rb and private_controller.rb controllers, with the index action ready to use
Both related routes
The related views

Let's add the Auth0 controller to handle the callbacks and failures. Create the controller file (bin/rails g controller auth0) and add the following:

# ./app/controllers/auth0_controller.rb
class Auth0Controller < ApplicationController

  # this will happen in case of success
  def callback
    auth_info = request.env['omniauth.auth']
    session[:userinfo] = auth_info['extra']['raw_info']

    redirect_to '/private/index'
  end

  # this will happen in case of failure
  def failure
    @error_msg = request.params['message']
    redirect_to '/public_index'
  end

  # logout route
  def logout
    reset_session
    redirect_to logout_url, allow_other_host: true
  end

  private

  def logout_url
    request_params = {
      returnTo: root_url,
      client_id: AUTH0_CONFIG['auth0_client_id']
    }

    URI::HTTPS.build(host: AUTH0_CONFIG['auth0_domain'], path: '/v2/logout', query: request_params.to_query).to_s
  end
end

Then update the routes to use those three actions:

./config/routes.rb
Rails.application.routes.draw do
  # ..
  get '/auth/auth0/callback' => 'auth0#callback'
  get '/auth/failure' => 'auth0#failure'
  get '/auth/logout' => 'auth0#logout'

  root "public#index"
end

And then we can add Login and Logout buttons in the public and private views, respectively:

# app/views/public/index.html.erb
<div>
  <h1 class="font-bold text-4xl">Public#index</h1>
  <p>Find me in app/views/public/index.html.erb</p>
  <%= button_to 'Login', '/auth/auth0', method: :post, data: { turbo: false }, class: "rounded bg-sky-500 px-2 py-1 text-sm font-semibold text-white shadow-sm hover:bg-sky-400 focus-visible:outline focus-visible:outline-2 focus-visible:outline-offset-2 focus-visible:outline-sky-500" %>
</div>

# app/views/private/index.html.erb
<div>
  <h1 class="font-bold text-4xl">Private#index</h1>
  <p>Find me in app/views/private/index.html.erb</p>
  <%= button_to 'Logout', '/auth0/logout', method: :get, data: { turbo: false }, class: "rounded bg-sky-500 px-2 py-1 text-sm font-semibold text-white shadow-sm hover:bg-sky-400 focus-visible:outline focus-visible:outline-2 focus-visible:outline-offset-2 focus-visible:outline-sky-500" %>
</div>

You can now go to 'http://localhost:3000'. Use the Login button and you'll be redirected to the private page. There, you will find a Logout button.

A couple of things are missing, though:

Data from a user's profile
Identifying a user and handling authorization

Working with Scopes and Data

Let's take a few steps back and bring back the initializer (config/initializers/auth0.rb):

AUTH0_CONFIG = Rails.application.config_for(:auth0)

Rails.application.config.middleware.use OmniAuth::Builder do
  provider(
    :auth0,
    AUTH0_CONFIG['auth0_client_id'],
    AUTH0_CONFIG['auth0_client_secret'],
    AUTH0_CONFIG['auth0_domain'],
    callback_path: '/auth/auth0/callback',
    authorize_params: {
      scope: 'openid profile'
    }
  )
end

The critical piece here is the scope: openid profile. This tells Auth0 we are interested in a few pieces of information, namely:

The provider name (Auth0)
A uid: A unique identifier to match a user
An info hash: Containing a name, URL to a profile picture, and an empty 'email' key
An extra_info hash: Again, with a name and profile picture, but also a pair of given and family names

Read more on the topic of scopes in Auth0's documentation.

The above information is valuable, and you should ensure that, at least upon first login, you copy that data into a table in your application.

To do so, we need to use the content of the request-response in the auth0_controller and, specifically, in the callback action:

def callback
  # all the data sent by auth0
  auth_info = request.env['omniauth.auth']

  # the data that really identifies the user
  session[:userinfo] = auth_info['extra']['raw_info']

  redirect_to '/private/index'
end

Use a breakpoint before the redirect to dig into the hash and experiment.

We usually want the email address too. To get it, you can update the scope:

scope: 'openid profile email'

After reloading the application server and going through the login steps, you will need to give the application access to additional information.

We can now do something like this in the callback action:

def callback
  # all the data sent by auth0
  auth_info = request.env['omniauth.auth']

  # the data that really identify the user
  session[:userinfo] = auth_info['extra']['raw_info']

  user = User.find_by(email: session[:userinfo]['email'] || User.new
  if user.new_record?
    user.name = session[:userinfo]['name']
    user.email = session[:userinfo]['email']
  end
  user.save

  redirect_to '/private/index'
end

This will ensure we have a local, up-to-date profile for the user.

A Word On Sessions

A session is a special hash in a Ruby on Rails application. It has limited storage that is accessible from the controllers and views and unique to each visitor.

We can "open" and "close" sessions. If we need a specific dataset, we can decide that a session is open. If it has no data, then it's closed.

Remember the following lines in our Auth0 controller:

# in the callback method
session[:userinfo] = auth_info['extra']['raw_info']

# in the logout method
reset_session

The first one writes the value in the raw_info key of the hash to the session hash, while the second one just clears up the session hash.

We can then define the following helper method in the ApplicationHelper:

# get the user
def current_user
  User.find_by(email: session[:userinfo]['email']) if session[:userinfo]
end

A Security Concern

Now let's use this as a concern for our controllers. The idea is to define a controller that requires users to be logged in to access it, such as our private_controller.

We can write the following concern file:

# ./app/controllers/concerns/secured.rb
module Secured
  extend ActiveSupport::Concern

  included do
    before_action :logged_in?
  end

  def logged_in?
    redirect_to '/' unless session[:userinfo].present?
  end
end

We can then use it in our controllers like so:

class PrivateController < ApplicationController
  include Secured

  def index
  end
end

If a visitor isn't logged in, but then tries to open up the /private/index page, they will automatically be redirected to the site's root.

Integrating with Other Providers

You can rely on multiple providers through Auth0. However, Google is defined as the default. For many companies, that's enough.

If you need more providers, head to the Authentication menu for the related tenant in Auth0, and then the Social submenu, where you can set up additional providers.

It's also worth noting that you can configure multi-factor authentication (MFA) with Auth0 too.

The process will remain the same except for those configuration steps. Our application will only return visitor data to prove that a visitor has been authenticated.

Opening Up Towards Authorization

Now we can authenticate users and send their information to our application through a callback. We have already seen how to get a user's email address out of a hash and find the relevant user in our database.

From there, we can define authorization policies.

Pundit is a great choice to define and use authorization policies, yet relies on checking a user's role.

Using a role attribute is, in fact, the easiest method. You can fill it in when creating a user in the Rails console or your application's back-end interface, before a user's first login attempt.

Or you can get a list of admins' emails and match a user's email against the list when creating the user.

ADMINS = ['johndoe@example.com']

def find_or_create_user(email:, name:)
  user = User.find_by(email: session[:userinfo]['email'] || User.new
  if user.new_record?
    user.name = session[:userinfo]['name']
    user.email = session[:userinfo]['email']
  end
  if ADMINS.include?(user.email)
    user.role = 'admin'
  else
    user.role = 'normal'
  end

  user.save
end

And that's it!

What We've Covered

In this article, we set up:

A tenant and application in Auth0
Auth0-related gems in a Ruby on Rails application
Routes and views in the application

We then:

Reviewed the concept of a session and saw how to use it
Created base tooling to check if a user is logged in
Added a controller concern to secure controllers behind a login requirement
Saw how to match users to their roles

Auth0 and other authentication providers can help you integrate state-of-the-art authentication in your Ruby on Rails application without writing much code. It's often a much better option than relying on your own implementation of the authentication layer or even using gems like Devise.

Happy coding!

P.S. If you'd like to read Ruby Magic posts as soon as they get off the press, subscribe to our Ruby Magic newsletter and never miss a single post!

Debugging in Ruby with Debug

Thomas Riboulet — Wed, 17 Jul 2024 10:42:46 +0000

Debugging is a valuable skill for any software engineer to have. Unfortunately, most software engineers are not trained in it. And that's not just specific to developers going through boot camps; even in universities, we are not often taught and trained to use a debugger.

My teachers and mentors were more interested in getting me to write programs rather than debugging them. If we are fortunate, debugging comes at the end of the semester, in a short, last session.

Luckily, we have tools that can help us with debugging. Since Ruby 3.1, Ruby ships with the debug gem, a powerful debugger.

In this article, we will go through a quick overview of the gem. We'll see how to use it for simple and more advanced cases.

Debugging Without A Debugger: What's the Issue?

Many of us rely on what you might call "printf debugging": we add puts (or its equivalent in the language we're using) to the standard output (STDOUT). We include the current state of an object, variable, or just a string so we know if our program is going into specific branches of its logic tree.

While helpful, this isn't the most optimal way to debug a program. It often leads to many back-and-forth trips between your logs and the code, as you forget to add a puts here and there, or leave in some debugging code.

That method also relies on your own preconceptions about how the code is running and what is going on that's different from what you might expect.

Using a debugger is a very different experience. You add one or more breakpoints in the code where you want to know what's happening. You then run the code and wait for it to hit the breakpoint.

Then, you get a debugging console to check a variable's values at the breakpoint location. You go back and forth in the execution steps.

As we will see later, we can even add conditional breakpoints directly from the debugging console. This makes it easier to avoid exiting the debugging console, so you can add breakpoints you've forgotten about.

Setup

Since Ruby 3.1, a version of the debug gem ships with Ruby. We recommend adding it to your Gemfile so you're using the latest version.

Add debug to your Gemfile and then run bundle install. I recommend adding it to development and test groups for debugging tests too.

Basic Debugging Techniques with Debug for Ruby

Now let's run through some simple debugging methods using debug: using breakpoints, stepping, other commands, moving in the stack, and using a map. We'll then examine the more advanced method of adding breakpoints on the fly.

Breakpoints

Breakpoints are calls that tell the debugger to stop. You can do this in modern IDEs that are integrated into a debugger with a simple click in the sidebar. The standard way is to add binding.break at the line we want to stop at.

require 'debug'

class Hornet
  def initialize
    @colors = [:yellow, :red, :black]
  end

  def show_up
    binding.break   # debugger will stop here
    puts "bzzz"
  end
end

Hornet.new.show_up

By running this little program, we will get the following console output:

[debug] ruby test.rb
[4, 13] in test.rb
     4|   def initialize
     5|     @colors = [:yellow, :red, :black]
     6|   end
     7|
     8|   def show_up
=>   9|     binding.break   # debugger will stop here
    10|     puts "bzzz"
    11|   end
    12| end
    13|
=>#0    Hornet#show_up at test.rb:9
  #1    <main> at test.rb:14
(ruby) @colors
[:yellow, :red, :black]
(rdgb)

As you can see, we can access the instance variable from the breakpoint.

Stepping

Let's dig into a more complex example using stepping.

class Book
  attr_accessor :title, :author, :price

  def initialize(title, author, price)
    @title = title
    @author = author
    @price = price
  end
end

class BookStore
  def initialize
    @books = []
  end

  def add_book(book)
    @books << book
  end

  def remove_book(title)
    @books.delete_if { |book| book.title == title }
  end

  def find_by_title(title)
    @books.find { |book| book.title.include?(title) }
  end
end

# Sample Usage:
store = BookStore.new
book1 = Book.new("Dune", "Frank Herbert", 20.0)
book2 = Book.new("The Hobbit", "J.R.R. Tolkien", 15.0)
book3 = Book.new("Hobbit's Journey", "Unknown", 10.0)

store.add_book(book1)
store.add_book(book2)
store.add_book(book3)

puts store.find_by_title("Hobbit").title

This example app manages books in a bookstore. But at the moment, we cannot be sure which book will be returned when we search titles containing 'Hobbit'. It might well be "The Hobbit", but it's not certain.

To help debug this, we'll jump into the find_by_title method.

Let's add a breakpoint to one of the methods:

def find_by_title(title)
  binding.break
  @books.find { |book| book.title.include?(title) }
end

Then launch the program and get to the breakpoint:

@box [debug] ruby library.rb                                                                                                                          20:25:07
[22, 31] in library.rb
    22|   def remove_book(title)
    23|     @books.delete_if { |book| book.title == title }
    24|   end
    25|
    26|   def find_by_title(title)
=>  27|     binding.break
    28|     @books.find { |book| book.title.include?(title) }
    29|   end
    30| end
    31|
=>#0    BookStore#find_by_title(title="Hobbit") at library.rb:27
  #1    <main> at library.rb:42
(rdbg)

The top part of the console tells us which line and file we are at. We can then query the value of the title variable.

(rdbg) title
"Hobbit"
(rdbg)

We can run the code right in that context to see what's happening:

(ruby) @books.find { |book| book.title.include?(title) }
#<Book:0x00007fd05e4d59f0 @author="J.R.R. Tolkien", @price=15.0, @title="The Hobbit">
(rdbg)

Here might be a good time to reflect on how you want the program you are building and this piece of code to behave. Expressing the code through RSpec tests might be an excellent way to clarify what it should do.

Let's now continue to the next breakpoint by using the continue command.

(rdbg) continue    # command
The Hobbit

In this case, it goes on until the end of the program.

More Commands to Assist Debugging

Of course, we can add more breakpoints to our code to stop at another place. But we can also use commands to move within the stack of our program without restarting it.

Let's add one more breakpoint to the add_book method, just after instantiating the bookstore.

def add_book(book)
  binding.break
  @books << book
end

# [ .. ]

store = BookStore.new
binding.break
book1 = Book.new("Dune", "Frank Herbert", 20.0)
book2 = Book.new("The Hobbit", "J.R.R. Tolkien", 15.0)
book3 = Book.new("Hobbit's Journey", "Unknown", 10.0)

Now, when we run the program, it will stop before the book1 variable is instantiated. The continue command will run the program until the next breakpoint or exit.

Using `next`

Instead of continue, we can use the next command, which will only run the next code line, so we can debug our app in smaller steps. We will need to run next twice to run the line where book1 is defined before we can inspect it.

[30, 39] in library.rb
    30|   end
    31| end
    32|
    33| # Sample Usage:
    34| store = BookStore.new
=>  35| binding.break
    36| book1 = Book.new("Dune", "Frank Herbert", 20.0)
    37| book2 = Book.new("The Hobbit", "J.R.R. Tolkien", 15.0)
    38| book3 = Book.new("Hobbit's Journey", "Unknown", 10.0)
    39|
=>#0    <main> at library.rb:35
(ruby) book1
nil
(rdbg) next    # command
[31, 40] in library.rb
    31| end
    32|
    33| # Sample Usage:
    34| store = BookStore.new
    35| binding.break
=>  36| book1 = Book.new("Dune", "Frank Herbert", 20.0)
    37| book2 = Book.new("The Hobbit", "J.R.R. Tolkien", 15.0)
    38| book3 = Book.new("Hobbit's Journey", "Unknown", 10.0)
    39|
    40| store.add_book(book1)
=>#0    <main> at library.rb:36
(ruby) book1
nil
(rdbg) next    # command
[32, 41] in library.rb
    32|
    33| # Sample Usage:
    34| store = BookStore.new
    35| binding.break
    36| book1 = Book.new("Dune", "Frank Herbert", 20.0)
=>  37| book2 = Book.new("The Hobbit", "J.R.R. Tolkien", 15.0)
    38| book3 = Book.new("Hobbit's Journey", "Unknown", 10.0)
    39|
    40| store.add_book(book1)
    41| store.add_book(book2)
=>#0    <main> at library.rb:37
(ruby) book1
#<Book:0x00007f50fb5f9da0 @author="Frank Herbert", @price=20.0, @title="Dune">

Each next call will run the next line. But it will not step into the code called by Book.new.

Using `step`

In some cases, we may know that an issue lies within a specific call. The step command is great for debugging this.

For example, when we are at line 37, we can use step to follow the execution of the Book object that fills the book2 variable.

(rdbg) step    # command
[2, 11] in library.rb
     2|
     3| class Book
     4|   attr_accessor :title, :author, :price
     5|
     6|   def initialize(title, author, price)
=>   7|     @title = title
     8|     @author = author
     9|     @price = price
    10|   end
    11| end
=>#0    Book#initialize(title="The Hobbit", author="J.R.R. Tolkien", price=15.0) at library.rb:7
  #1    [C] Class#new at library.rb:37
  # and 1 frames (use `bt' command for all frames)

The step command brings us directly to the first line of the initialize method in the Book class. (If you are new to Ruby, the new class method is called the initialize method after it does some internal work). Now we can use the next step from within that method and follow the trail.

next and step are crucial to get familiar with, as they allow us to move forward at different levels and speeds.

Moving In the Stack

We can move up and down (or backward and forwards) in the stack by using the up and down commands. Calling up twice will get us back to line 37:

[2, 11] in library.rb
     2|
     3| class Book
     4|   attr_accessor :title, :author, :price
     5|
     6|   def initialize(title, author, price)
=>   7|     @title = title
     8|     @author = author
     9|     @price = price
    10|   end
    11| end
=>#0    Book#initialize(title="The Hobbit", author="J.R.R. Tolkien", price=15.0) at library.rb:7
  #1    [C] Class#new at library.rb:37
  # and 1 frames (use `bt' command for all frames)
(rdbg) up    # command
# No sourcefile available for library.rb
=>#1    [C] Class#new at library.rb:37
(rdbg) up    # command
=>  37| book2 = Book.new("The Hobbit", "J.R.R. Tolkien", 15.0)

We need to call it twice as we skipped over one step, thanks to the next command: the call to the parent class of the Book class: Class itself (and the new method).

Using a Map

When we start to use up , down, next, and step, it's handy to know two more commands:

list: to show where we are in the code
bt (or backtrace): to show the trace of the steps we have followed

For example, when we are at line 37, the bt command displays the following:

(rdbg) bt    # backtrace command
  #0    Book#initialize(title="The Hobbit", author="J.R.R. Tolkien", price=15.0) at library.rb:7
  #1    [C] Class#new at library.rb:37
=>#2    <main> at library.rb:37

Calling down twice brings us to step #0. We can also pass an additional integer to both up and down to move through as many steps as we want to in one go.

Knowing What's Available

A very practical command to know is ls. It will list the variables and methods available to you at your current point in the stack.

For example, on line 37, we see the following:

(rdbg) ls    # outline command
Object.methods: inspect  to_s
locals: book1  book2  book3  store

Using `finish`

We can go to our next breakpoint using continue. However, the finish or fin command will also bring us to the next breakpoint, or to the end of our program.

You can exit more quickly with Ctrl-D or quit.

Adding Breakpoints On the Fly

A more advanced practice is to add breakpoints on the fly while running the debugger.

We have different ways to do that. Let's start with some more simple ways to add a breakpoint:

To a specific line — break <line number> — in the current file.
To the start of a specific method in a specific class: break ClassName#method_name.

(rdbg) break 38    # command
#0  BP - Line  /mnt/data/Code/clients/AppSignal/debug/library.rb:38 (line)
(rdbg) break BookStore#find_by_title    # command
#1  BP - Method  BookStore#find_by_title at library.rb:27

Called on its own, the break command will list the existing breakpoints (the ones added through the debug console):

(rdbg) break    # command
#0  BP - Line  /mnt/data/Code/clients/AppSignal/debug/library.rb:38 (line)
#1  BP - Method  BookStore#find_by_title at library.rb:27

You can also remove breakpoints that are added this way using the del or delete command:

del will remove all breakpoints in one go (confirmation is needed).
del X deletes breakpoints numbered X in the breakpoints list.

Adding Conditions

You can also add conditions when setting a breakpoint. Imagine a method that goes wrong when the book title is "Germinal", but that goes ok if it's "Notre Dame". In this case, we can add a breakpoint on the method, but only if the book title matches.

(rdbg) break BookStore#find_by_title if: book1.title == "Germinal"    # command
#1  BP - Method  BookStore#find_by_title at library.rb:27 if: book1.title == "Germinal"

Integration with IDEs

Many of us rely on modern IDEs and text editors that have support for direct debugging. A good choice is rdbg: it integrates well with many IDEs.

Check the debug README for more details on rdbg.

Recap and Wrapping Up

In this post, we covered the following:

Installing debug
Adding breakpoints from your favorite code editor with binding.break
Looking at the value of variables and objects from a debugger session
Navigating within execution frames from the debugger console (with up, down, and next)
Listing available variables and methods at any point in the console with ls
Adding breakpoints and conditional breakpoints on the fly from the debugger console
Listing and removing breakpoints (with break, delete <number>, and delete)
Ending a debugging session with finish, continue, or quit.

The help command also provides plenty of details on the commands we have seen here and more. You can run help break (for example) to learn more about the break command and its subcommands.

In conclusion, the debug tool will greatly help you with debugging over the years.

Most debuggers use similar commands, so don't hesitate to try others out too (check out our post on pry-byebug, for example).

Happy coding!

P.S. If you'd like to read Ruby Magic posts as soon as they get off the press, subscribe to our Ruby Magic newsletter and never miss a single post!

How to Use Tailwind CSS for Your Ruby On Rails Project

Thomas Riboulet — Wed, 19 Jun 2024 14:00:00 +0000

It's hard to overstate the importance of Cascading Style Sheets (CSS) for all websites. Since the first CSS standards were published in late 1996, we have come quite far regarding features and ecosystems.

Several frameworks have appeared and proved popular, one of the most recent being Tailwind CSS.

In this post, we'll first examine Tailwind's utility-first approach before diving into how to use it in a Ruby on Rails application. You will see how Tailwind helps you to build excellent websites without the need for custom CSS and long debugging sessions.

Let's get started!

Tailwind CSS: A Utility-First Approach

Most CSS frameworks (Foundation, Bootstrap, or Bulma, for example) provide ready-to-use components such as buttons and form fields, so you can quickly assemble blocks to shape an interface.

Typically, adding a button with Bootstrap looks like this:

<button class="btn btn-primary">My Button</button>

In this example, a simple button is defined and styled by applying the btn and btn-primary classes. btn-primary sets the right color for our use case. Yet, that interface can't fit our needs, so we add a custom CSS stylesheet to customize every component:

<button class="btn btn-primary admin-button">My Button</button>

Tailwind is a "utility-first" concept. Instead of providing ready-to-use components such as buttons, it has low-level utility classes that you can compose to build custom designs. As such, it encourages a more functional approach to styling, where you apply pre-defined classes directly in your HTML. It aims to minimize the need for custom CSS and promotes design consistency through the constraints of the utility classes.

"Utility-first" means that Tailwind provides atomic, single-purpose classes you can combine to construct complex designs.

Let's have a look at some code to compare Tailwind and Bootstrap. First, here is how Tailwind lets us style a simple button:

<button class="bg-blue-500 hover:bg-blue-600 text-white py-2 px-4 rounded">
  My Button
</button>

There are a series of button element classes to configure:

Background color bg-blue-500: While 'blue' is a pre-picked color, we can set the color shade with the number. The higher the number, the darker the color.
Background color on hover: hover:bg-blue-600.
Text color text-white: No need for a number here, as it's white; there is always a default shade if you don't specify a number, such as with text-red.
Vertical padding py-2: 'p' is padding, 'y' is for the vertical axis, '2' is the spacing value, not in pixels but a scale defined in Tailwind.
Horizontal padding px-4: Same as above, with 'x' for the horizontal axis.
Rounding corners: rounded.

This looks more verbose than the Bootstrap example, but by only adding classes, we can adjust each part of the style. We don't need to create a custom CSS class.

You might not be happy with these colors, but the good news is that you can add custom colors. We will cover that later.

A Word on Scales

CSS is mighty when it comes to spacing (such as margins and padding), and you can work with pixels and rems (root-em, a size relative to the size of the root element). This tends to be difficult, though. Tailwind comes with its own spacing scale that hides complexity while also helping with proportionality.

By default, Tailwind offers values between 0 and 96, with each step proportional to the others. For example, the value 16 has twice as much spacing as 8. Thanks to this, we don't have to do the math to work with rems or pixels. We can define our preferred values and reuse them throughout our design.

Setting Up Tailwind in a Ruby on Rails Environment

Ruby on Rails 7.x directly supports Tailwind in its application generator.

$> cd ~/workspace/ && mkdir tailwind-tryout && cd tailwind-tryout
$> rails new -d sqlite3 -c tailwind -T .

We'll skip the test configuration (-T) to avoid adding unnecessary complexity to this article.

Tailwind has a neat feature that generates the CSS file your application needs. Other frameworks require you to include a whole CSS file defining a framework (even the pieces you don't use). In contrast, Tailwind will scan your project and generate a CSS file that contains only the classes your project needs.

You do need to run a little utility to make that happen. In development mode, you can run a watcher daemon that will keep things up to date as you work: bin/rails tailwindcss:watch.

You can also add the watcher daemon to your Procfile, then use foreman or overmind to start the web and css processes:

web: bin/rails server
css: bin/rails tailwindcss:watch

Let's now use it within a simple landing page:

bin/rails generate controller Landing index

We can then head to http://localhost:3000/landing/index.

Dissecting Our Landing Page

Every landing page needs a title. The generator works since we configured our application to use Tailwind as its CSS framework.

# app/views/landing/index.html.erb
<div>
  <h1 class="font-bold text-4xl">Landing#index</h1>
  <p>Find me in app/views/landing/index.html.erb</p>
</div>

We find something that looks like standard HTML here. We have only two classes for the h1 tag:

font-bold: to control the font weight.
text-4xl: to control the font size.

If we change text-4xl to text-xl and reload the page, the new style will be automatically applied. Looking at the terminal where Foreman is running, you will see that Tailwind has generated a stylesheet in the background again.
That's how simple it is to integrate Tailwind into a Ruby on Rails application (this relies on the tailwindcss-rails gem).

Configuring Tailwind for Ruby on Rails

You can edit the config/tailwind.config.js file to adjust Tailwind's settings (e.g., to add additional colors, specify a font to use, adjust spacing, etc).

For example, we could add a "copper" color to our backgrounds and text:

module.exports = {
  content: ["./src/**/*.{html,js}"],
  theme: {
    colors: {
      copper: {
        100: "#FAD9C1",
        200: "#F6C8A4",
        300: "#F2B786",
        400: "#EEA669",
        500: "#E9944C",
        600: "#D17F3E",
        700: "#B96A31",
        800: "#A15524",
        900: "#8A4018",
        dark: "#8A4018",
      },
    },
    fontFamily: {
      serif: ["Times", "serif"],
    },
    extend: {
      spacing: {
        "8xl": "108rem",
      },
    },
  },
};

Note that the shades are helpful but can instead be named. If we only need three shades, for example, we can use 'light', 'medium', and 'dark' instead of numbers in our views.

We can then use the shades in our title:

<h1 class="font-bold text-4xl text-copper-200">Landing#index</h1>
<h2 class="font-bold text-xl text-copper-dark">Subtitle</h2>

You can find details about this in the tailwindcss-rails gem's README and also the Tailwind CSS documentation.

Asset Pipeline

We have seen how bin/rails tailwindcss:watch keeps our stylesheets updated in local development mode. If we need to build the stylesheets just once, we can use bin/rails tailwindcss:build instead.

For production use, you can rely on bin/rails assets:precompile to directly call bin/rails tailwindcss:build.

Learn more about the asset pipeline for Ruby on Rails applications.

Tailwind for Rails in Action

Let's check out a couple of practical uses of Tailwind in some views: a form and a responsive navigation bar.

A Simple Form

Using the Ruby on Rails generator, we create a user resource:

bin/rails g resource user email:string password:string
bin/rails db:migrate

We can then alter the users_controller.rb file and create a view for the form.

# app/controllers/users_controller.rb
class UsersController < ApplicationController
  def def new
    @user = User.new
  end
end

# app/views/users/new.html.erb
<div>
  <h1 class="font-bold text-4xl text-blue-500">Users#new</h1>

  <%= form_with model: @user, local: true do |form| %>
    <div class="mb-6">
      <%= form.label :email, class: "block mb-2 text-sm font-medium text-blue-900" %>
      <%= form.text_field :email, class: "bg-gray-50 border border-gray-300 text-gray-900 text-sm rounded-lg focus:ring-blue-500 focus:border-blue-500 block w-full p-2.5" %>
    </div>
    <div class="mb-6">
      <%= form.label :password, class: "block mb-2 text-sm font-medium text-gray-900" %>
      <%= form.password_field :password, class: "bg-gray-50 border border-gray-300 text-gray-900 text-sm rounded-lg focus:ring-blue-500 focus:border-blue-500 block w-full p-2.5" %>
    </div>
    <button type="submit" class="text-white bg-blue-700 hover:bg-blue-800 focus:ring-4 focus:outline-none focus:ring-blue-300 font-medium rounded-lg text-sm w-full sm:w-auto px-5 py-2.5 text-center">Submit</button>
  <% end %>
</div>

We style each piece individually, adjusting the text color, background color, borders, padding, margins, etc. There is nothing beyond standard Tailwind here, yet we customize the form to fit our needs.

A Responsive Navigation Bar

We can add conditional breakpoints based on a browser's minimum width using any utility class in Tailwind. For example, the following title will change color depending on the window size:

<h2
  class="text-base font-semibold text-gray-900 sm:text-teal-800 lg:text-purple-500"
>
  Additional information
</h2>

By default, the color is a dark shade of gray. When a browser window's width is between 640px and 1024px, it's a shade of teal. If a window's width is above 1024px, it's a shade of purple.

As Tailwind can also handle columns, here is an example to showcase how an element's column width can change based on window size:

<div class="sm:col-span-2 md:col-span-3">
  <label for="region" class="block text-sm font-medium leading-6 text-gray-900"
    >State</label
  >
</div>

The label "State" spans two or three columns in this case.

Here, using Tailwind's grid layout utilities, we define a grid that is:

One column wide by default (grid-cols-1)
Six columns wide above 640px width
Eight columns wide above 768px width

<div class="mt-10 grid grid-cols-1 gap-x-6 gap-y-8 sm:grid-cols-6 md:grid-cols-8">
</div

Breakpoints and their widths:

sm: 640px
md: 768px
lg: 1024px
xl: 1280px
2xl: 1536px

As we've seen, Tailwind simplifies page design and the styling of components.

Tailwind vs. Other Frameworks

Now that we understand how Tailwind can be used, let's review its key differences to other frameworks:

Utility-based: We compose the style of each element using specific CSS classes, each focusing on different parts of the style.
Get what we need: We only get the parts we need to ship our website, making for faster load times; that optimizes build time.
Extensible: We can extend or customize TailwindCSS' defaults through a simple configuration file.
Easy shading of colors: There's no need to figure out how to make lighter or darker shades of a color to handle hover situations, for example.
Simple spacing: The hidden and proportional scales simplify spacing.
Less custom CSS: Since we only assemble classes to style elements, we rely less on custom CSS and can share styles (including complete themes) using HTML files and snippets.
Ruby on Rails friendly: Thanks to the Tailwind gem, everything is integrated into the layouts and the assets pipeline.

Wrapping Up

As we've seen, Tailwind's utility-first approach is a great fit for Ruby on Rails. We don't need to spend time adjusting Tailwind to fit our needs by adding complex custom configurations or additional custom CSS. As we conceive our views and partials, we can use Tailwind utility classes to shape and style them.

If you want to learn more, you can access many ready-to-use templates and components thanks to Tailwind's vibrant community, and products such as TailwindUI (from Tailwind's creators).

Happy coding!

P.S. If you'd like to read Ruby Magic posts as soon as they get off the press, subscribe to our Ruby Magic newsletter and never miss a single post!

Creating Forms in Ruby on Rails with Simple Form

Thomas Riboulet — Wed, 29 May 2024 11:55:19 +0000

Ruby on Rails has changed how we build web applications. Early on, the framework came with some great features to help you get started and build robust applications.

However, it can still be tricky to build and handle forms. Simple Form is a great option. Let's examine what Simple Form is, why we might need it, and some real use cases.

Forms and Ruby on Rails

Ruby on Rails really simplifies building applications. Yet, it also requires your constant attention to keep your codebase streamlined and coherent. One strategy is to avoid writing code by using abstractions, for example. Code that isn't in your actual application is code you don't have to manage. That's why we like abstractions so much, right? Simple Form is just such an abstraction that simplifies building forms for web pages.

Forms are generally complex to build, even using Ruby on Rails. Each field requires attention to define the right type and attach it to the correct attribute. Simple Form eases that pain, as you don't need to find the exact type required for each field.

Let's take a form that gets a user's details, with name, username, and email fields. Consider that we have the User model with similar related attributes. With Simple Form, the form that fills in attributes looks like the following:

<%= simple_form_for @user do |f| %>
  <%= f.input :name, required: false %>
  <%= f.input :username %>
  <%= f.input :email %>
  <%= f.button :submit %>
<% end %>

Note that we are not specifying the types of each field. Simple Form will pick the correct input type for each field based on the column's type.

This saves us time and keeps the code readable and easier to maintain.

Installing Simple Form

To install Simple Form in your project, add the simple_form gem to the Gemfile. Once you have run bundle install, you can use the included generator to set it up correctly for your application.

rails generate simple_form:install

A note on Bootstrap and Zurb Foundation: Both Bootstrap and Zurb Foundation 5 are supported within Simple Form. So, if you are using one of them, you can use the --bootstrap or --foundation parameter with the generator to include additional configurations during the installation. In the case of Bootstrap, this would look like the following:

rails generate simple_form:install --bootstrap

Basic Usage of Simple Form

As we pointed out earlier, Simple Form will generate a complete form mainly based on the data related to your objects. Yet, it's also important to understand that Simple Form will not only generate the appropriate field for each attribute but also provide labels and display error hints above the input fields themselves!

Let's consider a fresh new Ruby on Rails 7.x application. We'll generate a User model and build a form for it using Simple Form.

rails g model User username:string password:string email:string remember_me:boolean
# and follow with running the migration of course
rails db:migrate

Now we can generate a controller with the new, create, and index actions. The aim is to have something we can play with in the form.

rails g controller users

# app/users_controller.rb
class UsersController < ApplicationController
  def new
    render :new, locals: { user: User.new }
  end

  def create
    user = User.create(user_params)
    redirect_to users_path
  end

  def index
    render :index, locals: { users: User.all }
  end

  private

  def user_params
    params.require(:user).permit(:username, :password, :email)
  end
end

# config/routes.rb
Rails.application.routes.draw do
  resources :users, only: [:new, :create, :index]
end

These actions require relevant views. Here is a form that handles a user signing up or being added:

<!-- app/views/users/new.html.erb -->
<%= simple_form_for user do |f| %>
  <%= f.input :username, label: 'Your username please', error: 'Username is mandatory, please specify one' %>
  <%= f.input :password, hint: 'No special characters.' %>
  <%= f.input :email, placeholder: 'user@domain.com' %>
  <%= f.input :remember_me, inline_label: 'Yes, remember me' %>
  <%= f.button :submit %>
<% end %>

In this case, we specify a custom label and error for the username input. If no such customization is passed, it will do its best to guess what the label needs to be based on the attribute's name.

We have set a custom hint for the password field and a custom placeholder for the email field. Notice, also, the ability to specify an "inline label" instead of one located above the field (the usual default in forms).

It's also possible to disable labels, hints, and errors by passing the false value for those attributes: <%= f.input :password_confirmation, label: false %>.

We need to complement this with one more view to make it usable.

<!-- app/views/users/index.html.erb -->
<ul>
<% users.each do |user| %>
  <li><%= user.username %> (<%= user.email %>)</li>
<% end %>
</ul>
<p>
<%= link_to 'New User', new_user_path %>
</p>

You can then start the application using rails s. Head to localhost:3000/users/new to see and use the form.
Let's focus on how the form differs from a classic Ruby on Rails form.

A note on validations: Simple Form can work with mandatory fields out of the box. For example, if we were to add the following presence validation in our User model:

class User < ApplicationRecord
  validates :username, presence:true

  # more code
end

This will be used by Simple Form to add a little '*' next to the username field, specifying that it's mandatory. This doesn't manage the errors automatically, so you still have to handle that in the controller action. Return to the appropriate field that has errors and act on them.

About Column Types and Form Fields

As mentioned earlier, we haven't specified a type for each field. The Simple Form README has a complete list of all available input types and the defaults for each column type. Here are the most used ones:

Column Type	Generated HTML element	Comment
`string`	`input[type=text]`
`boolean`	`input[type=checkbox]`
(passwords) `string`	`input[type=password]`	Any column with a name containing 'password'
`text`	`input[type=textarea]`
`integer`, `float`	`input[type=number]`
`datetime`	`datetime select`
`time`	`time select`
`country`	`select`

Booleans

As we can see in the above table, boolean attributes will be represented, by default, as checkboxes. In many cases, that's what we'll want. But if not, there is a way to customize this in Simple Form with the as attribute, which allows you to specify if you will show radio buttons or a dropdown instead.

Here is how to specify radio buttons instead:

<%= f.input :remember_me, input_html: { value: '1' }, as: :radio_buttons %>

This will generate the following HTML:

<div class="input radio_buttons optional user_remember_me">
  <label class="radio_buttons optional">Remember me</label>
  <input type="hidden" name="user[remember_me]" value="" autocomplete="off" />
  <span class="radio">
    <label for="user_remember_me_true">
      <input
        value="true"
        class="radio_buttons optional"
        type="radio"
        name="user[remember_me]"
        id="user_remember_me_true"
      />Yes
    </label>
  </span>
  <span class="radio">
    <label for="user_remember_me_false">
      <input
        value="false"
        class="radio_buttons optional"
        readonly="readonly"
        type="radio"
        name="user[remember_me]"
        id="user_remember_me_false"
      />No
    </label>
  </span>
</div>

It's impressive that such a small piece of Ruby code gets you such a complete piece of HTML!

HTML

From the previous example, we can see how Simple Form generates a lot of HTML for each field. That includes the HTML for the input field and a wrapper div around the label and input field. We can customize those by specifying a custom class and id using the input_html and wrapper_html attributes. Here is an example.

<%= simple_form_for @user do |f| %>
  <%= f.input :username, wrapper_html: { class: 'username' }, input_html { id: 'username' } %>
<% end %>

That's also a way to set attributes for the related HTML, such as maxlength or value. Let's take the password field from our user form. We can limit the size and length of the field with the maxlength attribute.

<%= f.input :password, input_html: { maxlength: 20 } %>

Custom Inputs and Additional Options

Simple Form is a Ruby library that prepares HTML nodes for you. It comes with a whole set of fields, but you can also add your own. To do so, you can create classes inheriting from Simple Form's classes. Let's consider defining a custom social network input field with a little '@' prefix in front of the actual field.

# app/inputs/social_handle_input.rb
class SocialHandleInput < SimpleForm::Inputs::Base
  def input(wrapper_options)
    merged_input_options = merge_wrapper_options(input_html_options, wrapper_options)

    "@ #{@builder.text_field(attribute_name, merged_input_options)}".html_safe
  end
end

Now we can use it in the following way:

<%= f.input :network_handle, as: :social_handle %>

Note that, if your User model doesn't have a network_handle attribute, you must add it through a migration or cheat with an attr_accessor in the model.

i18n Support

As we've mentioned, building forms is often a pain point. But things get even more painful when it comes to websites and applications that support multiple languages. Simple Form, thankfully, follows Ruby on Rails standards. You can use a simple_form key in the local files to define translations for all labels, hints, placeholders, prompts, etc.

Here is a little example:

en:
  simple_form:
    labels:
      user:
        username: 'User name'
        password: 'Password'
    hints:
      user:
        username: 'User name to sign in.'
        password: 'No special characters, please.'
    placeholders:
      user:
        username: 'Your username'
        password: '****'
    include_blanks:
      user:
        age: 'Rather not say'
    prompts:
      user:
        role: 'Select your role'

Value Objects

Sometimes, we might use custom, non-ActiveRecord classes to instantiate the main object a form relies upon. This can be done to compose data from multiple models into a synthetic one for either business logic reasons or to gather several attributes into a single object.

Whatever the reason, you can still rely on Simple Form to build forms for that kind of object. To do so, the object class needs to implement, in the best case, three methods: to_model, to_key, and persisted?.

The to_model method will point to the object itself:

def to_model
  self
end

The to_key allows us to point to the identifier attribute for the object — usually, that means an id attribute named:

def to_key
  id
end

Finally, the persisted? method is there to tell Simple Form if the object is directly persisted or not.

def persisted?
  false
end

If that method isn't present, the f.submit helper isn't usable.

There is a faster way, though — including the ActiveModel::Model module in the class:

# app/models/account.rb
class Account
  include ActiveModel::Model

  attr_accessor :id, :company_name
end

And let's use it through the User model.

# app/models/user.rb
class User < ApplicationRecord
  attr_accessor :network_handle

  def account
    @account ||= Account.new(id: 1, company_name: "Acme Inc.")
  end

  def company_name
    account.company_name
  end
end

We can then add a field for the company name within the user form:

<%= f.input :company_name %>

Of course, this attribute will not get saved in a table. However, the same concept can be applied to compose a value object with attributes pulled from several models.

Wrapping Up

In this post, we've seen that Simple Form is easy to install and integrate into your Ruby on Rails application. Simple Form not only takes care of the details of each field in your form, but also generates complex and complete HTML so your form can be styled and shaped with ease.

I encourage you to dive into Simple Form's documentation to see how powerful it can be.

Happy coding!

P.S. If you'd like to read Ruby Magic posts as soon as they get off the press, subscribe to our Ruby Magic newsletter and never miss a single post!

Debugging in Ruby with pry-byebug

Thomas Riboulet — Wed, 22 May 2024 09:00:22 +0000

For a software engineer, even the basic use of a debugger can save a lot of pain: adding breakpoints (places in the code the program will stop at and expose the current context) is very easy, and navigating from one breakpoint to another isn't difficult either.

And with just that, you can say goodbye to a program's many puts and runs. Just add one or more breakpoints and run your program. Then you're able to access not only the variables and objects you might have thought of, but also anything accessible from that point in the code.

In this article, we'll focus on pry-byebug, a gem that adds debugging and stack navigation to pry using byebug. We will see how to set up and use pry-byebug, how it integrates with Ruby programs, and a few advanced techniques.

Let's get started!

Set Up `pry-byebug` for Ruby

The setup is really simple. Just add the pry-byebug gem to your Gemfile, and then run bundle install. I'd advise you to add it to the development and test groups to debug tests as well.

Let's now cover some simple debugging using breakpoints.

Basic Debugging with Breakpoints

The whole principle of debuggers is to get rid of printf debugging by giving you direct access to a running program's stack. So, we need to add breakpoints to tell the interpreter where to stop.

Let's take the example of a simple bookstore with software that manages the titles it offers.

class Book
  attr_accessor :title, :author, :price

  def initialize(title, author, price)
    @title = title
    @author = author
    @price = price
  end
end

class BookStore
  def initialize
    @books = []
  end

  def add_book(book)
    @books << book
  end

  def remove_book(title)
    @books.delete_if { |book| book.title == title }
  end

  def find_by_title(title)
    @books.find { |book| book.title.include?(title) }
  end
end

# Sample Usage:
store = BookStore.new
book1 = Book.new("Dune", "Frank Herbert", 20.0)
book2 = Book.new("The Hobbit", "J.R.R. Tolkien", 15.0)
book3 = Book.new("Hobbit's Journey", "Unknown", 10.0)

store.add_book(book1)
store.add_book(book2)
store.add_book(book3)

puts store.find_by_title("Hobbit").title

This program is simple enough. Of course, there is no storage, but that's not needed to demonstrate what we want to do.

The last call will probably list "The Hobbit", but that's not certain and might not be the one we want. To debug this, it's best to "jump" into the find_by_title method.

So, add the following lines to the top of the file:

require 'pry'
require 'pry-byebug'

We will also add a breakpoint to the method using binding.pry:

def find_by_title(title)
  binding.pry
  @books.find { |book| book.title.include?(title) }
end

Let's then launch the program and get to the breakpoint:

From: test-pry-byebug/app.rb:29 BookStore#find_by_title:

    27: def find_by_title(title)
    28:   binding.pry
 => 29:   @books.find { |book| book.title.include?(title) }
    30: end

[1] pry(#<BookStore>)>

The first thing you should see is that we know exactly where we are: there's no need to guess which part of the program that line in STDOUT comes from. Of course, we have only one breakpoint here, but you can easily understand how useful this might be if many breakpoints are used.

We can then check the value of the title variable. There likely isn't much to be surprised by here. The issue is with the use of find (instead of select, or something more complex) to find and return a list of books instead of just one book.

By being right in the context, you can experiment with both find and select and decide on a course of action.

Here might be a good point to reflect on the expected behavior of the program you are building and this piece of code. It might be good to clarify what the code should do through RSpec tests.

Once you are ok with that step or want to see what's happening until the next breakpoint, type continue, and the program execution will start again.

Making Small Steps from Breakpoints

With pry-byebug, you can take smaller steps from breakpoints to see what happens after each line (particularly helpful for multiple calls using a method). Once you have stepped into the program and are at a breakpoint, use the next command to execute the next line.

Let's take the case of adding a breakpoint within the add_book method just before the first three books are created in the bookstore:

def add_book(book)
  binding.pry
  @books << book
end

store = BookStore.new
binding.pry
book1 = Book.new("Dune", "Frank Herbert", 20.0)
book2 = Book.new("The Hobbit", "J.R.R. Tolkien", 15.0)
book3 = Book.new("Hobbit's Journey", "Unknown", 10.0)

Upon execution, the program will first stop just before the book1 variable is instantiated. We might want to know the result of that call. To do so, we don't have to stop the program and add another breakpoint. We just have to type next in the pry console and hit Enter.

From: test-pry-byebug/app.rb:37 :

    32: end
    33:
    34: # Sample Usage:
    35: store = BookStore.new
    36: binding.pry
 => 37: book1 = Book.new("Dune", "Frank Herbert", 20.0)
    38: book2 = Book.new("The Hobbit", "J.R.R. Tolkien", 15.0)
    39: book3 = Book.new("Hobbit's Journey", "Unknown", 10.0)
    40:
[1] pry(main)> next
From: test-pry-byebug/app.rb:38 :

    33:
    34: # Sample Usage:
    35: store = BookStore.new
    36: binding.pry
    37: book1 = Book.new("Dune", "Frank Herbert", 20.0)
 => 38: book2 = Book.new("The Hobbit", "J.R.R. Tolkien", 15.0)
    39: book3 = Book.new("Hobbit's Journey", "Unknown", 10.0)

We then have access to book1.

[1] pry(main)> book1
=> #<Book:0x00007fad37f964d8 @author="Frank Herbert", @price=20.0, @title="Dune">

This beats a lot of back-and-forth insertion and tweaking puts calls.

Even Smaller Steps

We might want to step into the initialize method (called through new) to see more details. We can do so by using step instead of next.

From: test-pry-byebug/app.rb:8 Book#initialize:

     7: def initialize(title, author, price)
 =>  8:   @title = title
     9:   @author = author
    10:   @price = price
    11: end

[1] pry(#<Book>)> title
=> "The Hobbit"

This allows us to step into a method when it's called rather than skip over it as we do with next.

Free from `puts`

By now, you should see how this approach saves time and frees us from using puts or its equivalent to debug a program. Right from the debugger shell, we can look into the values of objects and variables to figure out why a program behaves like it does. Furthermore, you can save a lot of time from the shell by adding breakpoints on the fly, thus avoiding the "quit, move binding.pry, restart" loop.

Finishing a Debugging Session

You can call continue to go to the next breakpoint or the end of a program. finish executes and finishes the current step, returning just after that step. In the previous example, we end up at the following line:

[2] pry(#<Book>)> finish

From: test-pry-byebug/app.rb:39 :

    34: # Sample Usage:
    35: store = BookStore.new
    36: binding.pry
    37: book1 = Book.new("Dune", "Frank Herbert", 20.0)
    38: book2 = Book.new("The Hobbit", "J.R.R. Tolkien", 15.0)
 => 39: book3 = Book.new("Hobbit's Journey", "Unknown", 10.0)

Finally, !!! exits the debugger directly.

Advanced Use Cases of `pry-byebug` for Ruby

Now let's dive into a few more advanced use cases, including rewinding and replaying, adding breakpoints on the fly, and conditional breakpoints.

Rewinding and Replaying

Can we move back and forth between two points? Yes, totally. Given our previous case, we could move up and down from the initialize method to its call. Just use up and down commands after step to get into the method.

From: test-pry-byebug/app.rb:37 :

    34: # Sample Usage:
    35: store = BookStore.new
    36: binding.pry
 => 37: book1 = Book.new("Dune", "Frank Herbert", 20.0)
    38: book2 = Book.new("The Hobbit", "J.R.R. Tolkien", 15.0)
    39: book3 = Book.new("Hobbit's Journey", "Unknown", 10.0)


[1] pry(main)> step

From: test-pry-byebug/app.rb:8 Book#initialize:

     7: def initialize(title, author, price)
 =>  8:   @title = title
     9:   @author = author
    10:   @price = price
    11: end

[1] pry(#<Book>)> up

From: test-pry-byebug/app.rb:37 :

    35: store = BookStore.new
    36: binding.pry
 => 37: book1 = Book.new("Dune", "Frank Herbert", 20.0)
    38: book2 = Book.new("The Hobbit", "J.R.R. Tolkien", 15.0)
    39: book3 = Book.new("Hobbit's Journey", "Unknown", 10.0)


[1] pry(main)> down

From: test-pry-byebug/app.rb:8 Book#initialize:

     7: def initialize(title, author, price)
 =>  8:   @title = title
     9:   @author = author
    10:   @price = price
    11: end

If we need details about the stack we are in, we can call the backtrace method:

[1] pry(#<Book>)> backtrace
--> #0  Book.initialize(title#String, author#String, price#Float) at test-pry-byebug/app.rb:8
    ͱ-- #1  Class.new(*args) at test-pry-byebug/app.rb:37
    #2  <main> at test-pry-byebug/app.rb:37

From: /mnt/data/Code/Pier22/courses/raw-courses/rspec/git-repo/test-pry-byebug/app.rb:8 Book#initialize:

     7: def initialize(title, author, price)
 =>  8:   @title = title
     9:   @author = author
    10:   @price = price
    11: end

The list of frames is in the stack at the top, numbered from 0 to 2. A little cursor shows us which frame we are currently in.

Add Breakpoints On the Fly

To avoid additional debugger exits, we can add breakpoints on the fly from the debugger console, using the break command.

You can add breakpoints in the current file or another file, to a specific line or the start of a specific method.

For example, let's add a breakpoint to the start of the find_by_title method of the BookStore class:

[2] pry(main)> break BookStore#find_by_title

  Breakpoint 2: BookStore#find_by_title (Enabled)

  28: def find_by_title(title)
29:   @books.find { |book| book.title.include?(title) }
30: end

To add it to line 38 of the current file:

[1] pry(main)> break 38

  Breakpoint 1: /mnt/data/Code/Pier22/courses/raw-courses/rspec/git-repo/test-pry-byebug/app.rb @ 38 (Enabled)

      35: binding.pry
    36: book1 = Book.new("Dune", "Frank Herbert", 20.0)
    37: book2 = Book.new("The Hobbit", "J.R.R. Tolkien", 15.0)
 => 38: book3 = Book.new("Hobbit's Journey", "Unknown", 10.0)
    39:
    40: store.add_book(book1)

A call to break lists all the breakpoints in place:

[4] pry(main)> break

  # Enabled At
  -------------

  1 Yes     /mnt/data/Code/Pier22/courses/raw-courses/rspec/git-repo/test-pry-byebug/app.rb @ 38
  2 Yes     BookStore#find_by_title

Note that they are numbered, so you can actually delete them using the --delete argument to break:

[4] pry(main)> break --delete 1

Conditional Breakpoints

You might want conditional breakpoints, too.

Imagine that your code only misbehaves if a user object's role attribute is set to :admin.

Well, you might want to add the following breakpoint, and a condition to trigger it so that the debugger only stops if that condition is set:

[1] pry(main)> break BookStore#add_book if book.title.match /Dune/

  Breakpoint 1: BookStore#add_book (Enabled) Condition: book.title.match /Dune/

Using continue, the debugger executes the addition of Dune without stopping, until the next call to add_book.

This is a great feature that will save you a lot of time.

Wrapping Up

By now, you should have fewer reasons to rely on printf() debugging when facing issues with your Ruby code. You now know how to:

Install pry-byebug and some of its plugins
Add breakpoints from your favorite code editor with binding.pry
Start a debugger session (starting the app)
Look at the value of variables and objects from the debugger session (simply calling the object or variable from the debugger console)
Navigate within the execution frames from the debugger console (with up, down, next, and frame)
Add breakpoints on the fly from the debugger console
Add conditional breakpoints from the debugger console (with break ClassName#method_name if var.nil?, for example)
List and remove breakpoints (with break, break --delete <number>, and break --disable-all)
Conclude your debugging session with finish, continue, or !!!.

Finally, you can also configure pry-byebug through the ~/.pryrc file to add aliases and a few custom behaviors. See the main pry-byebug README for more details.

pry-byebug is a tool that will help you a lot over the years, saving you time and headaches. It's definitely worth practicing its use so that you can confidently open it the next time you're unsure how your code is behaving.

Happy coding!

P.S. If you'd like to read Ruby Magic posts as soon as they get off the press, subscribe to our Ruby Magic newsletter and never miss a single post!

P.P.S. Use AppSignal for Ruby for deeper debugging insights.

Good Database Migration Practices for Your Ruby on Rails App using Strong Migrations

Thomas Riboulet — Wed, 03 Apr 2024 11:37:49 +0000

One great feature that comes with modern web frameworks is the ability to manage database schema migrations. However, schema migrations are not 100% safe and remain a recurring cause of issues within projects I have encountered over the last 15 years.

This article will review the issues surrounding poorly managed schema migrations and then look into Strong Migrations, a gem that can help you avoid most problems. Finally, we will discuss a few good practices around database management.

Let's get started!

Issues with Schema Migrations in Ruby on Rails

Schema migrations are changes to a table or database schema within an RDBMS: adding, renaming, removing, and updating a table (or a column within another table), index, or view. Some schema migrations are inherently risky (such as removing a column or table). Generally, all carry a risk, especially alongside any related code changes.

Schema migrations are also made worse with larger tables. Some changes, like updating columns and altering indexes, take longer to apply and might imply database locks, causing performance issues.

We also have to talk about how migrations are brought to production via related code changes. Migrations that add, update, or remove a schema element (table or column) and are used in the code are the most problematic. This is because many developers don't build good practices into those cases early enough. The typical scenario is as follows:

A developer adds a Model and related table.
They merge the code change.
The code change gets deployed, but the migration hasn't run yet.
The application starts and crashes.

The reason for the crash is simple: as an application starts, Ruby on Rails will load the schema but won't find the new table in the database.

How Can We Fix Problems with Schema Migrations?

Looking at the above example, the solution is to run a database migration before an application starts. The deployment tooling should take care of that. However, in the case of a column or table removal, a migration must run after an application starts. So the easiest thing is to separate the change into two deployments in the correct order and make sure the tooling or team runs the migration when appropriate. Sometimes, we may have to split the change into more deployments.

Let's take the cases we listed before: adding, removing, or updating a column.

In the first case of adding a column, we need to deploy and run a migration before the code change that will start to use it.
In the second case (removing a column), it's the opposite: we need to remove code that's using the column before removing the column itself.
Updating a column is trickier. Such a change will enforce a lock. And it's even worse if you change the column type. This is the suitable strategy:

Create a new column.
Write to both old and new columns.
Backfill existing data from the old column into the new one.
Move the reads to the new column.
Stop writing to the old column.
Drop the old column.

These three strategies should be used for any project, especially once a database fills up and users rely on the product.

Yet, just like linters remove some cognitive load by taking care of this kind of toil, it's best to rely on a tool to automate this.

Here's where the Strong Migrations library comes into play. It adds a layer of protection around migrations to ensure you can avoid issues upon deployment in any environment.

Getting Help from Strong Migrations

The folks at Instacart have open-sourced many libraries. Among them sits Strong Migrations, aimed at "catching unsafe migrations in development". Once installed, it will:

Detect potentially dangerous operations.
Prevent them from running by default, and tell you why.
Provide instructions on safer ways to do things.

A migration will be deemed dangerous if it's likely to cause the issues we discussed earlier: locks and potential errors due to timing. Check out the Strong Migrations README on GitHub for more information.

We will now cover a few cases here.

Installation

This is straightforward: use bundle add strong_migrations, followed by bundle install, and rails generate strong_migrations:install. The last command will create an initializer to configure a few things when the application starts.

Adding a Column or a Table

There is no help from Strong Migrations on this one, but remember it's good practice to separate a table addition from the code using it. Please ensure a schema change happens before any code using it runs and expects to find it.

Renaming a Column

Here's where we start to see what Strong Migrations can do for us. Taking the example of a migration that renames a column from "address" to "location", we get the following message when we try to run it locally in our development environment:

== 20231116202001 RenameUserAddress: migrating ================================
rails aborted!
StandardError: An error has occurred; this and all later migrations have been canceled:

=== Dangerous operation detected #strong_migrations ===

Renaming a column that's in use will cause errors
in your application. A safer approach is to:

1. Create a new column
2. Write to both columns
3. Backfill data from the old column to new column
4. Move reads from the old column to the new column
5. Stop writing to the old column
6. Drop the old column

article/db/migrate/20231116202001_rename_user_address.rb:3:in `change'
Tasks: TOP => db:migrate
(See full trace by running task with --trace)

So, yes, the Strong Migrations gem does not replace you. Instead, it reminds you that what you are doing is dangerous and that you should not do it. It also tells you how you should do things instead.

Removing a Column

Now, let's say that we have gone through the first five steps of the list that Strong Migrations generated for us, and it's time to remove the old column.

Is it as simple as creating a migration and using the remove_column method? No, it's not.

Again, Strong Migrations will print the following text:

== 20231116202636 RemoveUserAddress: migrating ================================
rails aborted!
StandardError: An error has occurred; this and all later migrations have been canceled:

=== Dangerous operation detected #strong_migrations ===

Active Record caches attributes, which causes problems
when removing columns. Be sure to ignore the column:

class User < ApplicationRecord
  self.ignored_columns = ["address"]
end

Deploy the code, then wrap this step in a safety_assured { ... } block.

class RemoveUserAddress < ActiveRecord::Migration[7.0]
  def change
    safety_assured { remove_column :users, :address, :string }
  end
end

article/db/migrate/20231116202636_remove_user_address.rb:3:in `change'
Tasks: TOP => db:migrate
(See full trace by running task with --trace)

So we know what to add to the model and how to change our schema migration. It's tailored to your use case, including the table's name and column. Once that is done, the migration will go through without an issue.

Backfilling Data

The remaining piece on the database strategy side is backfilling data in new columns from old ones. While relying on the Data Migrate gem might be tempting, we can also backfill data in a regular migration. A safe backfilling migration will consider a table's size, the task's complexity, and avoid transactions.

By default, Ruby on Rails uses a transaction around each migration. If we include backfilling in the migration doing the schema change, this might take some time and potentially cancel our whole schema migration.

So, instead, let's use a separate migration, avoid using a transaction, batch the process, and throttle the work.

class BackfillCountryCodeColumn < ActiveRecord::Migration[7.1]
  disable_ddl_transaction!

  def up
    User.unscoped.in_batches do |relation|
      relation.update_all country_code: 'fr'
      sleep(0.01)
    end
  end
end

Notes:

unscoped ensures that we don't rely on the "default scope" defined in the model to work with all rows.
in_batches forces the block to run in batches of 1000 entries.
sleep gives some reprieve to the database in between batches.

An alternative method is to use a script or a rake task to handle this. Whatever solution you pick, remember that backfilling a column or table with data might be pretty intensive for the database. Estimate how much data will be handled and consider the techniques used in the above example, if needed.

Adding Strong Migrations to an Existing Ruby on Rails Project

Adding Strong Migrations to an existing project is a good idea. However, you might run into issues when setting up a new project instance on a workstation or within a new environment. A failsafe will kick in and prevent any prior migrations from running.

So, what shall we do? You don't have to go through all the migrations and alter them accordingly. Instead, you should follow the Ruby on Rails guide and clean up old migrations.

I've not seen many projects follow that advice, but it's the "good thing" to do: db/schema.rb or db/structure.sql holds a snapshot of the current database schema and can be used to load it. Tasks such as db:setup and db:prepare (and ones based on either of them) use that snapshot to load schema in a database. Only pending migrations are run; old ones are barely a line in one table, a mere memory.

You can remove old migration files if you need them: git (or Mercurial, or Svn) will keep a trace of them. Once a migration has been applied to all existing environments, it can be deleted as the schema.rb (or structure.sql) file will serve for new environments.

Here are the steps you should follow:

Before introducing Strong Migrations, ensure all environments are up to date in terms of migrations.
Remove old migration files.
Add and install the Strong Migrations gem.
Start to create new migrations.

Doing so will prevent you from going through years of migrations to set them in line with Strong Migrations. It will also lighten the burden of setting up a new environment.

You can then devise a periodic removal of migration files, keeping the last 5, 10, or any from the previous month, for example.

Some Additional Advice on Migrations

Let's finish up by sharing some general tips on migrations when it comes to:

Production environments and databases
Avoiding downtime
Backups

Production Environments and Databases

Considering your production environment and its database is key when creating and running any migration. A developer environment is rarely bursting at the seams when it comes to data. Consequently, most migrations will run smoothly with barely any waiting time. Production environments have a lot more data that's more diverse. This will tend to complicate things when it comes to writing and applying a migration.

You should follow strategies like backfilling. Batching and throttling are also good practices when handling large volumes of data. It's never too early to start using those to develop good habits. Once a migration is out there and running, we should monitor performance metrics: response time and slow queries. Compare these metrics with previous trends, and look into unexpected changes.

Avoiding Downtime

One reason that developers tend to be scared about making deployments around the end of the day or the week is the fear of the unknown.

By following the good practices pointed out by Strong Migrations, we can reduce the amount of risks and unknowns, thus giving us more confidence in our ability to deploy at any time.

Backups

If things go wrong, don't panic; you should have a backup ready. Most managed solutions available for PostgreSQL, MySQL, and similar RDBMS offer backups at regular intervals. Some also provide point-in-time recovery, allowing us to rewind to better times.

Wrapping Up

In this post, we first explored some potential issues related to schema migrations in Rails, before seeing how we can fix these issues ourselves. We then introduced Strong Migrations. As we have seen, Strong Migrations ensures that risky changes such as removals and changes to a schema element are done correctly to avoid risk.

Finally, we touched on a few additional tips regarding migrations.

Happy coding!

P.S. If you'd like to read Ruby Magic posts as soon as they get off the press, subscribe to our Ruby Magic newsletter and never miss a single post!

A Deep Dive Into RSpec Tests in Ruby on Rails

Thomas Riboulet — Wed, 21 Feb 2024 13:13:17 +0000

In our last post, we looked at the basics of RSpec and explored how well it works with Behavior Driven Development in Ruby.

Now, we will look at specific types of RSpec tests for different parts of a Ruby on Rails application.

Let's dive straight in!

Unit, Controller, and Integration Tests in Ruby on Rails

A Ruby on Rails application is composed of several layers. As the framework is built around Models, Views, and Controllers, we might think of those three as the only layers of an application. Yet, often, that's barely enough to describe a Ruby on Rails application.

Mailers, Jobs, and Helpers are secondary layers we don't want to miss. When it comes to testing, it's important to remember that these components are largely impacted by how our code has been designed. Using SOLID principles — particularly Single Responsibility — helps keep our code straightforward and more testable.

So, we usually aim to keep things simple in views, controllers, models, jobs, and mailers: we want to assemble and use the bricks of code we have designed and tested separately already. Once we enter the realm of views and controllers, testing becomes much more complex, and slower too.

Categories of Ruby Tests

Usually, we split tests into these categories:

Unit tests (models and other plain old Ruby objects — POROs): Ensure class methods are working as expected.
Controller tests: Test the expected outcome of controller actions (rendering the right template, redirections, and flash messages).
View tests: (Used rarely) to test specific elements or content in views.
Helper tests: For when you use a complex helper method.
Feature or system tests: Simulate user interactions in the browser — this is where Capybara will help.
Request tests: Test an application's response to various HTTP verbs without browser overhead. This is faster than feature tests.
Mailer and jobs tests: Specific tests are needed for this secondary layer to ensure emails are sent properly with the right content and jobs trigger the appropriate work.
Routing tests: Complex routing is a code smell. Testing routes will help you avoid trouble when you have too many routes or routes that are too complex.

What Kinds of Tests Should We Write?

Do we need to write all of these tests? It depends on your culture and team, but these might be good starting points:

Unit tests: Write focused and (as much as possible) database-dependent tests for your models' public methods and other POROs you craft into your application; they should run fast.
Controller tests: Write tests that help ensure controller actions are routable and respond as expected for each context they could be in. These should not aim to test the whole response or complex scenarios made of multiple requests.
Request tests: Test request scenarios from a machine client (think API controllers), typically: "for a given HTTP request context (HTTP verb, path, and parameters), what HTTP response should we get?"
System tests: Test scenarios of human user requests. Typically, this is where we want to test complex scenarios with multiple clicks.
Mailer and job tests: These should only test that a mailer and job are doing the specific "mailer" and "job" work properly. In particular, for jobs, most of the "work" should be done through classes and methods tested separately.

Controller tests are often replaced by a good layer of request and system tests, as they ultimately serve the same purpose. Too many tests will cause fatigue in your team or slow down your whole test suite for little benefit. It's up to you. The point is to test your controller layer: figure out which way is best in your case.

Let's see how unit, controller, and integration (both request and system) tests look.

Using RSpec and Ruby on Rails for Testing

As pointed out in our previous post, we can use the rspec-rails gem to integrate RSpec into a Ruby on Rails application's code base.

Unit Tests

Unit tests are at the base of the testing pyramid, so there will be numerous unit tests in a codebase. They need to be fast.

Remember: tests (with RSpec) are focused on testing code behavior, not implementation. That should help to write fast tests. In the case of Ruby on Rails projects, models are a big source of unit tests. As models are related to database access (either read or write access), those tests can have a performance impact. So be careful about reading and writing to the database for those tests. In some cases, you won't be able to avoid calling create, save, update, or find, but you can in most. You should be able to rely on new instead of create, for example.

Here is what an RSpec unit test for a Ruby on Rails model looks like:

# spec/models/user.rb
require 'rails_helper' # a file generated with rspec-rails containing configuration for rspec in a rails context

RSpec.describe User, type: :model do
  describe '#valid_email?' do
    subject(:user) { User.new(email: email) }

    context 'when email is valid' do
      let(:email) { Faker::Internet.email }

      it { expect(user.valid_email?).to be(true) }
    end

    context 'when email is not valid' do
      let(:email) { 'bob@example' }

      it 'returns false' do
        expect(user.valid_email?).to be(false) }
      end
    end
  end
end

While those two examples are written a bit differently, they basically do the same thing. One has no description and reads pretty nicely still; the other one has a description but carries a bit of a duplication, don't you think?

Note that we use User.new to instantiate a user. This call doesn't require a read or write to the database. Since our valid_email? method only works with the instance's attributes, it won't slow the test down either.

Those two are good unit tests: simple, focused, and fast.

Unit tests are not just for Ruby on Rails models. They are also good for any classes you build around models and the rest of an application's architecture. We have specified the test type in the first line (RSpec.describe User, type: :model), but we can totally avoid that if we write tests for a plain Ruby class.

Controller and Request Specs

Up until recently, controller tests were the main way to test controllers. Nowadays, we tend to rely on request specs instead. Similarly to controller tests, they are designed to test an application from a machine client. They allow us to test one, or multiple, controller action/s. They are tests, so we need to define a context, then our expectation. As they are functional tests, we have to define a context composed of a given HTTP verb (get, post, put, ...), a path (/, /users, ...), parameters, and (potentially) a body. The expectation is then focused on the response (HTTP status code, response/s header/s, and body).

With request specs, it's not a matter of UI or Javascript.

A simple request spec will look like this.

require "rails_helper"

RSpec.describe "User management", type: :request do
  it "does not render the incorrect template" do
    get "/users/new"
    expect(response).to_not render_template(:show)
  end
end

It's simple, but you can see the context in the part doing the request: get "/users/new". In turn, the expectation itself is centered on the response. We see a new matcher here, allowing us to test if a specific template is rendered. Another one (redirect_to) allows us to test that we are properly redirected.

Request specs can also be used to test more complex scenarios.

require "rails_helper"

RSpec.describe "User management", type: :request do

  it "creates a user and redirects to the user's page" do
    get "/users/new"
    expect(response).to render_template(:new)

    post "/users", params: { user: { first_name: "John", last_name: "Doe", email: "john@example.org" } }

    expect(response).to redirect_to(assigns(:user))
    follow_redirect!

    expect(response).to render_template(:show)
    expect(response.body).to include("User John Doe (john@example.org) created.")
  end
end

However, request specs are better adapted to test behavior from a machine client's perspective. So, request specs are best used to test an API backend's controller parts.

require "rails_helper"

RSpec.describe "User management", type: :request do

  it "creates a user and returns the user's details" do
    headers = { "CONTENT_TYPE" => "application/json" }
    post "/users", params: { user: { first_name: "John", last_name: "Doe", email: "john@example.org" } }

    expect(response.content_type).to eq("application/json; charset=utf-8")
    expect(response).to have_http_status(:created)
    expect(response.body).to include() # TODO
  end
end

While we haven't included any in this example, we can also express different contexts to test behaviors. The RSpec vocabulary and grammar still applies fully in that kind of spec. We merely use a bit more to handle the parts specific to making an HTTP request and its response.

System Specs

System specs are more complete integration tests than request ones. They are used to test an application in a real or headless browser, and require a driver for the browser (the default is Selenium; this can be changed).

System specs are similar to request specs in concept, but with improved grammar to focus on a user's actions in the browser rather than the requests being made. Here is an example.

require "rails_helper"

RSpec.describe "Account management", type: :system do
  it "enables me to create an account" do
    visit "/account/new"

    fill_in "Name", with: "Acm'e Ltd."
    fill_in "Address", with: "6 Av. Elysian fields"
    click_button "Create Account"

    expect(page).to have_text("Account successfully created.")
  end
end

Notice that here, the context (verb, path, parameters) is defined underneath but still there: we visit a page, fill out a form (which sets parameters), and then click a button (trigger a POST request). Finally, the expectation is defined as the content of the page rendered. Indirectly, it's still about testing the response's content, although the browser interprets that.

Because system specs use and drive the complete stack, they are a lot slower than other specs. As such, they should be limited in number and potentially run at particular times within the CI pipeline.

Complimentary Test Types in Ruby

As mentioned, Ruby on Rails applications are composed of a few more components with specific roles: mailers, jobs, serializers, and decorators. Those require tests as well — ones closer to unit than integration tests. It can be useful to test out specifics regarding mailers and jobs.

Mailer Specs

Thanks to ActiveMailer, Ruby on Rails has a simple way to abstract interactions with a third party that sends emails. Thus, instead of testing email sends, you can focus on testing what matters: behavior. In the case of emails, what matters is the subject, from and to addresses, and the body of the response.

require "rails_helper"

RSpec.describe Notifications, type: :mailer do
  describe "notify" do
    let(:mail) { Announcements.account_renewal }

    it "prepares the email headers properly" do
      expect(mail.subject).to eq("Renewal")
      expect(mail.to).to eq(["company@example.org"])
      expect(mail.from).to eq(["bot@example.com"])
    end

    it "renders the body" do
      expect(mail.body.encoded).to match("A customer has renewed their account.")
    end
  end
end

Job Specs

Similarly, job specs allow you to test specific behavior around jobs: if they have been enqueued, performed, etc. This includes testing arguments using Delayed Job.

We can be tempted to test ActiveJob's behavior. We do know that calling perform and perform_later bill queues a job; what we want to know is if, and when, that happens.

So, you should test if a job is queued in contexts requiring it. Then, test that a job properly calls upon code that has its own unit tests.

describe Building do
  subject(:building) { Building.new(name: 'Bank') }

  describe '#setup' do
    it 'triggers the preparation job' do
      ActiveJob::Base.queue_adapter = :test
      expect { building.setup }.to have_enqueued_job.with('setup').on_queue('low')
    end

   # alternative
   it 'triggers the preparation job' do
     ActiveJob::Base.queue_adapter = :test
     expect(Building::PreparationJob).to have_been_enqueued.with('setup').exactly(:once)
   end
  end
end

This expresses and tests a job's enqueued behavior with certain parameters when a specific method is called.

A Note on Concerns in Ruby on Rails

Ruby on Rails has a way to factorize code used in multiple models or controllers through a disguised Ruby module called a concern. Concerns are a great way to avoid duplication of code. Make sure you test the content of concerns. Proper unit tests should also cover models. In the case of controllers, those are tested through request and system tests.

Some Thoughts on Testing with RSpec for Ruby

It's worth reiterating that your first layer of testing should be unit tests. Tests for models and other POROs should represent the vast majority of your tests in a code base.

Tests should run fast and avoid database and external services access as much as possible. To test the controller layer, request and system specs are best, respectively, for machine or human-driven activity on controller actions. They are slower than unit tests due to their inherent complexity, so there should be less of them than unit tests.

Finally, components like mailers and jobs should be used wisely and in their specific context, not to test the behavior of the lower library (like ActiveMailer and ActiveJob).

Wrapping Up

As we saw in part one of this series, we can factorize a lot of code and avoid duplication by making use of RSpec's basics: before and after hooks, let, and a proper structure built with describe and context.

In this part, we took a deep dive into testing with RSpec for Ruby, focusing on unit, controller, and integration tests.

We have explored how it's usually easy to keep unit tests small, while minimizing request and system tests is more difficult. So, after you have written (and made green) system and request specs, don't hesitate to spend some time slimming them down. This will keep them readable and easier to maintain.

Happy testing!

P.S. If you'd like to read Ruby Magic posts as soon as they get off the press, subscribe to our Ruby Magic newsletter and never miss a single post!

Behaviour Driven Development in Ruby with RSpec

Thomas Riboulet — Wed, 07 Feb 2024 11:32:58 +0000

RSpec is a library for writing and running tests in Ruby applications. As its landing page states, RSpec is: "Behaviour Driven Development for Ruby. Making TDD productive and fun". We will return to that last part later.

This post, the first of a two-part series, will focus on introducing RSpec and exploring how RSpec especially helps with Behaviour Driven Development in Ruby.

Let's dive in!

The History of RSpec

RSpec started in 2005 and, through several iterations, reached version 3.0 in 2014. Version 3.12 has been available for almost a year. Its original author was Steven Baker, but the mantle has passed to several maintainers through the years: David Chelimsky, Myron Marston, Jon Rowe, and Penelope Phippen. Many contributors have also been part of the project.

When you read RSpec's good practices, you see this phrase early on: "focus on testing the behavior, not the implementation". That's not a strategy specific to RSpec; it's good advice for anyone writing tests.
In more practical terms, you should focus your tests on how the code you are testing behaves, not how it works.

For example, to test that a user's email address is valid, you should test that the validate_email method returns false when the email address is invalid. You are not testing a specific implementation but rather how that code reacts (i.e., behaves) when handling different strings that should be email addresses.

Behavior interests us: how the code acts and defines how our application will work. Furthermore, this approach simply lets us know whether things work (or not), and we can then be more relaxed to either fix or refactor the implementation. Our tests will tell us if the code's behavior has changed; we will know if our changes have been successful or not in the most direct way possible.

The inner workings of the code don't interest us so much. Of course, we don't want a bad implementation, but measuring a good implementation is much harder than knowing if the code does what it's expected to do or not.

Let's look at how to install RSpec next.

Installing RSpec for Ruby

RSpec comes as a gem, rspec-core, so you can add it to a test group in your Gemfile. It's probably best you also add rspec. It's a meta gem that includes rspec-core, rspec-expectations, and rspec-mocks. You can also add the rspec-rails one in a Ruby on Rails project.

Tests usually live in the spec/ folder at the root of your project, and you can launch them by providing a path to a file or a directory: rspec spec/models/*rb, for example.

Now let's turn to how the RSpec DSL is set up to help with behavior testing.

RSpec DSL: How it Helps with Testing Behavior

RSpec's whole Domain Specific Language (DSL) is completely worked around behavior testing, giving you a direct way to describe the behavior you expect from your code within different contexts. A few parts could be smoother, but overall, tests in RSpec read directly as English, much like a good piece of Ruby code.

Tests in RSpec are not written as classes, with methods taking center stage as tests. Instead, tests are written as Ruby blocks (ever used do .. end?), which, thanks to the method name we pass to the block as an argument, makes things very easy to read.

The primary method used in RSpec tests is describe. describe will contain one or more tests and can even contain more describe calls. The second method is it. The it blocks are called examples and contain the actual assumptions; they are where the testing happens. Finally, RSpec relies on "expectations" within the it blocks. Using the expect method, we define how the subject of our test is expected to behave.

Now we can start writing some simple tests.

Simplest Tests in RSpec for Ruby: `describe` and `it`

Let's imagine a User class. We want a name method that will output first and last names together if both are present (or just one, if one is missing). Those are the different behaviors we want to test.

Here is how the simplest of those contexts look expressed as an RSpec test.

# first call to describe, as topmost one, its description or title is used to tell what we are testing, here the User class.
# this title can be a string or a class name
describe User do

  # we are adding a second describe to regroup the tests focused on the `name` method
  describe '#name' do

    # our first example ! Note the description focusing on the behavior
    it 'returns the complete name' do

      # we define a user variable by instantiating a user
      user = User.new(first_name: 'John', last_name: 'Doe')

      # and here comes the expectation
      expect(user.name).to eq('John Doe')
    end
  end
end

Look at the general structure: we start by describing the focus of our test in the User class, the method we are testing (name), and then present an expected behavior.

Note how the expectation is written: we expect the value returned by user.name to equal 'John Doe'. The eq method is a matcher. It allows us to match the tested value (on the left) and the expected one (on the right). The expect part is always followed with to or not_to to dictate how the matcher that follows will be used.

Handling Multiple Contexts

While this first test shows us how it's done, it needs to catch up to what we want. It only handles one case if both first and last names are present. Let's see how we can test another case if the first name is absent.

describe User do

  describe '#name' do
    it 'returns the complete name when both first and last name are present' do
      user = User.new(first_name: 'John', last_name: 'Doe')
      expect(user.name).to eq('John Doe')
    end

    it 'returns only the last name when the first name is missing' do
      user = User.new(last_name: 'Doe')
      expect(user.name).to eq('Doe')
    end
  end
end

This looks more realistic, but we still need to test another case. The description is also relatively verbose and repetitive. We could add another layer of description between the describe '.name' call and the example for each one. Thankfully, though, RSpec gives us a more obvious synonym for describe to express what we need to express for different contexts: context.

describe User do

  describe '#name' do
    context 'when both first and last name are present' do
      it 'returns the complete name' do
        user = User.new(first_name: 'John', last_name: 'Doe')
        expect(user.name).to eq('John Doe')
      end
    end

    context 'when the first name is missing' do
      it 'returns only the last name' do
        user = User.new(last_name: 'Doe')
        expect(user.name).to eq('Doe')
      end
    end
  end
end

Thanks to this, the whole file reads even more quickly and gives us, without much thinking, an understanding of exactly which behavior we are testing within different contexts.

Defining the Subject of Tests

We can use the subject method to make the subject of our tests obvious.

describe User do

  describe '#name' do
    subject { user.name }
    context 'when both first and last name are present' do
      let(:user) { User.new(first_name: 'John', last_name: 'Doe') }

      it 'returns the complete name' do
        expect(subject).to eq('John Doe')
      end
    end

    context 'when only the first name is present' do
      let(:user) { User.new(first_name: 'John') }

      it 'returns the complete name' do
        expect(subject).to eq('John')
      end
    end
    # ... other contexts
  end
end

This is especially handy to avoid repetition and add clarity.

Handling Complex Setup (Before, After Hooks) in Ruby on Rails

In many cases, we need a bit more to prepare a context. Let's take, as an example, a class method on a Ruby on Rails model named latest_three. It's expected to return the last three users created in the database. If we have less than that, we should get whatever users we have. By omitting the topmost describe, here is how a test might look.

# note that we are using the '::method_name' here to refer to a class method, '#method_name' is reserved to refer to an instance method's name
describe '::latest_three' do
  context 'when more than three users are present' do
    it 'returns three users' do
      3.times { User.create(first_name: Faker::Name.first_name, last_name: Faker::Name.last_name) }

      expect(User.latest_three.size).to eq(3)
    end
  end

  context 'when no users are present' to
    it 'returns an empty collection' do
      expect(User.latest_three.empty?).to be(true)
    end
  end
end

If you are unfamiliar with Faker, it's a Ruby library used to generate fake data such as names and dates through handy methods.

These two tests look ok, but the creation of the data doesn't belong to the example. It's important for the specific context, though: we need that data created before the example is run. To do so, we can use a before block. Those blocks are run before the tests that follow them (in each block's context), thus giving us a perfect opportunity to set up our data.

describe '::latest_three' do
  context 'when more than three users are present' do
    before do
      4.times { User.create(first_name: Faker::Name.first_name, last_name: Faker::Name.last_name) }
    end

    it 'returns three users' do
      expect(User.latest_three.size).to eq(3)
    end
  end

  context 'when no users are present' to
    it 'returns an empty collection' do
      expect(User.latest_three.empty?).to be(true)
    end
  end
end

Once again, I hope this shows how well thought-through the RSpec DSL is. Doesn't it read nicely and give us a good understanding of each context and the behavior we expect?

If we were tempted to destroy data or execute some other form of cleanup after a context, we could do so through an after block. This is especially useful if you are writing tests using a database without the comfort of built-in automatic database cleanup between test runs.

Avoiding Repetition with `let` in RSpec for Ruby

We still lack a few more concepts to be able to write real-world tests. Let's take the case of email validation again.

describe '#valid_email?' do
  context 'when email does not contain an @' do
    subject(:user) { User.new(email: 'bob') }

    it { expect(user.valid_email?).to be(false) }
  end

  context 'when email does not have a tld' do
    subject(:user) { User.new(email: 'bob@appsignal') }

    it { expect(user.valid_email?).to be(false) }
  end

  context 'when email is valid' do
    subject(:user) { User.new(email: 'bob@example.org') }

    it { expect(user.valid_email?).to be(true) }
  end
end

There are several repetitions, to the point of blurring the actual tests. We notice that the only thing that changes, in the setup of each context, is the actual value of the email address. Couldn't we use a variable to do this?

We can use let blocks. They allow us to define a memoized helper method. The value is cached across multiple calls in the relative context. let's syntax is similar to the one we saw for the subject block: first, we pass a name for the helper, then a block to be evaluated. That block is lazy-evaluated. If we don't call it, it will never be evaluated.

describe '#valid_email?' do
  subject(:user) { User.new(email: email) }

  context 'when email does not contain an @' do
    let(:email) { 'bob' }

    it { expect(user.valid_email?).to be(false) }
  end

  context 'when email does not have a tld' do
    let(:email) { 'bob@appsignal' }

    it { expect(user.valid_email?).to be(false) }
  end

  context 'when email is valid' do
    let(:email) { 'bob@example.org' }

    it { expect(user.valid_email?).to be(true) }
  end
end

Note that the subject is moved up in the structure too: it will be evaluated within each context and thus use each context's email value. Here we can see the purpose of subject within a describe with multiple contexts: we define the subject of the test early to make it obvious. We can then focus on expressing each different context we want to check the subject behavior in.

A Note on `let`

let is lazily defined. In the above example, email won't be instantiated and set until it's called. Once it is invoked, though, it's set. In effect, it's just like a memoized helper method.

Yet, in some cases, you might want to set the value associated with a let before the examples run. To do so, you can use let!. With let!, the defined memoized helper method is called within an implicit before hook for each example. In other words, the value associated with the let! is eagerly defined before the example is run.

Let's create a user in our context before we run our example:

describe "#count_users" do
  let(:account) { Account.create(name: 'Acc Ltd') }
  let!(:user) { User.create(name: 'Jane', account: account) }

  it "counts the users in the account" do
    expect(account.count_users).to eq(1)
  end
end

This prevents us from additional setup or even a call to user within the before hook to get the value memoized.

`let` Vs Instance Variables in RSpec for Ruby

Some developers might be tempted to rely on instance variables through a describe or context and their before hooks:

describe "#count_users" do
  before do
    @account = Account.create(name: 'Acc Ltd')
    @user = User.create(name: 'Jane', account: @account)
  end

  it "counts the users in the account" do
    expect(@account.count_users).to eq(1)
  end
end

This is not very practical. It adds dependencies and state sharing between contexts, weakens isolation, and is more difficult to debug.

The additional issue is that, if you were to make a call to an instance variable that has not been initialized, you'd get a nil value in return. That's in contrast to the exception you'd get if you were to call a local variable that doesn't exist (raising a NameError exception).

So, when writing tests with RSpec, let is preferred, and let! is to be used when you need an eager evaluation. Other methods to handle variables are not recommended.

Matchers in RSpec for Ruby

If describe, context, and it are very important to the structure of RSpec tests, the key part to making actual tests is matchers.

We have only seen a few, mainly be() and eq(). Those two are the simplest ones and are very handy. Here is a list of the others you should know about as a start:

eq: test the equality of two objects (actually, their equivalence, the same as ==); expect(1).to eq(1.0) # is true
eql: test the equality of two objects (if they are identical, not just equivalent); expect(1).to eql(1.0) # is false
be: test for object identity; be(true), be(false) ...
be_nil: test if an object is nil
be <= X: test if a number is less or equal to a value (X); also works with <, >, >=, ==
be_instance_of: test if an object is an instance of a specific class; expect(user.name).to be_instance_of(String)
include: test if an object is part of a collection; expect(['a', 'b']).to include('a')
be_empty: test if a collection is empty; expect([]).to be_empty
start_with, end_with: test if a string or array starts (or ends) with the expected elements; expect('Brian is in the kitchen').to start_with('Brian'), expect([1, 2]).not_to start_with('0')
match: test if a string matches a regular expression; expect(user.name).to match(/[a-zA-Z0-9]*/)
respond_to: test if an object responds to a particular method; expect(user).to respond_to(:name)
have_attributes: test if an object has a specific attribute; expect(user).to have_attributes(age: 42)
have_key: test if a key is present within a hash; expect({ a: 1, b: 2 }).to have_key(:a)
raise_error: test if a block of code raises an error; expect { user.name }.to raise_error(ArgumentError)
change: test that a block of code changes the value of an object or one of its attributes; expect { User.create }.to change(User.count).by(1), expect { user.activate! }.to change(user, :is_active).from(false).to(true)
to_all: test that all items in a collection match a given matcher; expect([nil, nil, nil]).to all(be_nil)
match_array: test that one array has the same items as the expected one (the order isn't of importance); expect([1, 3, 2]).to match_array([2, 1, 3])

You can already write most of the tests you'll ever need with those matchers. To read more about matchers, you can check out RSpec's documentation.

A Few Thoughts

As you have seen, we have yet to write a line of actual code; we just wrote tests. That might be the most crucial point of this article: RSpec's DSL and structure allow you to write your test first from the behavior point of view. When you start to work on a new class, you can first express the behavior as an RSpec example within a given context. Then, simply rely on the guard rails to make your implementation a reality.

That's actually how TDD works. We are not writing tests just for the sake of tests. Instead, we write tests to express the behavior we want to see from the code. In effect, those tests are merely a transcription (through RSpec DSL) of the behavior expected for a feature.

Wrapping Up

To summarize what we have covered in this article:

RSpec is a library that gives us a powerful DSL to express and test the behavior of code
describe is the main element to structure tests in each file
context is equivalent to describe, but is used to separate different contexts for testing code behavior
it allows us to define examples: the blocks within which tests happen
expectations define the actual tests with matchers
let and let! allow us to define memoized helpers through custom-named blocks to avoid repetitions; let! is eagerly loaded
subject allows us to clearly define what is being tested and can be named

In the next post, we will look at specific types of tests for different parts of a Ruby on Rails application.

Until then, happy coding!

P.S. If you'd like to read Ruby Magic posts as soon as they get off the press, subscribe to our Ruby Magic newsletter and never miss a single post!

Keep your Ruby Code Maintainable with Draper

Thomas Riboulet — Wed, 24 Jan 2024 12:05:47 +0000

Design patterns can help to simplify your codebase so you don't need to reinvent the wheel.

In this post, we'll go into how to use Draper. But first, we will start with an overview of the decorator pattern and how to use it with Ruby's standard library.

Let's get started!

The Decorator Pattern for Ruby

According to Refactoring.Guru:

Decorator is a structural design pattern that lets you attach new behaviors to objects by placing these objects inside special wrapper objects that contain the behaviors.

Decorator can also be called a wrapper. The idea is that you initialize an instance of a decorator class by passing the object you want to decorate to that decorator class initializer.

The new returned object can expose the same methods the original object did, plus a few more, or alter the original ones. In most cases (and in Draper's case), we use this pattern to delegate calls to the embedded object.

Let's dig into the Ruby standard library to look at the SimpleDelegator class, itself a child of the Delegator class. It's a great way to see the decorator's side of the pattern.

class Company
  def founded_on
    Date.new(1981, 9, 10)
  end
end

class CompanyDecorator < SimpleDelegator
  def founding_year
    founded_on.year
  end
end

decorated_company = CompanyDecorator.new(Company.new)
decorated_company.founding_year  #=> 1981
decorated_company.__getobj__  #=> #<Company: ...>

One thing to note: the decorated_company object has direct access to the public methods of the object it decorates.

And here lies the principle behind the decorator: the founded_on method, which can be an attribute pulled from the database, provides a key value for the company.

To display the year the company was founded, we might be tempted to use company.founded_on.year. This can work, yet we will slowly riddle the codebase with such calls. That is not practical; if we were to change the math or presentation of that value, we would need to change every single instance of that piece of code.

This kind of presentation code doesn't belong in the Company class; in Ruby on Rails, it doesn't belong in models either. If you have seen a few Rails projects, you probably have seen views littered with such presentation code. Decorators, delegators, or presenters are a better place for such presentation logic.

Using Decorators in Ruby on Rails Views, Models, and Controllers

Most, if not all, web applications need to display attributes of objects in different ways: names, dates, times, prices, numerical values, and coordinates. These uses are all over the place. Sometimes, we copy this kind of code in every view, use helper methods, or fill the model with methods that are just presenting data. Delegators are handy in moving all this logic into focused places.

Helper methods are usually spread around in different places. They might be grouped, but only carry a little meaning beyond the simple method's name. While models sound more appropriate, adding presentation methods tends to fatten them for little purpose. Any business logic in models or ActiveRecord-related code (associations, scopes, etc.) will be muddied by the presence of those methods.

In short, in Ruby on Rails, decorators allow us to keep responsibilities limited in the model, the view, the decorator, and the controller. Here is how it could work (note that we have simplified the code a bit to stay concise):

# app/models/company.rb
class Company < ApplicationRecord
  def founded_on
    Date.new(1981, 9, 10)
  end
end

# app/decorators/company_decorator.rb
class CompanyDecorator < SimpleDelegator
  def founding_year
    founded_on.year
  end
end

# app/controllers/companies_controller.rb
class CompaniesController < ApplicationController
  def show
    company = Company.find(params[:id])
    decorated_company = CompanyDecorator.new(company)

    render :show, locals: { company: decorated_company }
  end
end

# app/views/companies/show.html.erb

<h1><%= company.name %></h1>
<h2>Founded in <%= company.founding_year %></h2>

Using Draper in Your Ruby App

Draper is a bit more advanced than SimpleDelegator. To install Draper, simply add the gem to the application's Gemfile:

gem 'draper'

And run bundle install.

Decorators are usually written in the app/decorators folder; you can also use namespaces within that folder. Namespaces and the decorator's name should mirror the related models for the best results.

Draper includes a couple of Ruby on Rails generators too. So when generating resources (rails generate resource company), the related decorator will be created automatically.

If you prefer to do it by hand, you can also call the decorator generator with the model's name: rails generate decorator Company. By following this, you can rely on a bit of magic within your code to call decorate on the Company class instance and get the CompanyDecorator instance for that company.

decorated_company = Company.find(params[:id]).decorate
# equivalent to
company = Company.find(params[:id])
decorated_company = CompanyDecorator.new(company)

Draper also works with collections through the decorator's decorate_collection class method or the decorate method on a collection of objects.

decorated_companies = CompanyDecorator.decorate_collection(filtered_companies)
# or
decorated_companies = Company.recent.decorate

The decorator is similar to the one we saw with SimpleDelegator; it relies on Draper::Decorator instead. Methods of the decorated object are not directly accessible. Instead, we must call them through the object or model alias.

class CompanyDecorator < Draper::Decorator
   def founding_year
    object.founded_on.year
  end
end

Then, if we want to directly call public methods of the decorated object with the decorator instance, we can define a list of such methods by using the delegate method.

class CompanyDecorator < Draper::Decorator
  delegate :name

  def founding_year
    object.founded_on.year
  end
end

That way, we can use decorated_company.name. This approach is also handy to limit the exposure of the object that's being decorated from the view.

Example Draper Use Case: Rails View, Controller, and Model

A classic Draper use case relates to a User, Account, or Post model: they are often part of the core domain. The sheer quantity of business logic and presentation logic in those models can cause senior developers to frown and grab a new cup of coffee.

Let's take a User model use case: always a good magnet for plenty of excess fat.

class User < ApplicationRecord
  # table would have the following columns
  #
  # first_name, String
  # last_name, String
  # date_of_birth, DateTime
  # company_id, Uuid
  # street_name, String
  # street_number, String
  # city, String
  # zipcode, String
  # country, String

  def age
    DateTime.current.years_ago(date_of_birth.year).year # Note: this is Ruby on Rails specific
  end

  def company_name
    company.name
  end
end

None of those methods add any value to the model. They are misplaced or purely related to the presentation of data.

The view might look something like the following.

# app/models/users/show.html.erb

<h1><%= "#{user.first_name} #{user.last_name}" %></h1>
<ul>
  <li>Born <%= user.age %> years ago</li>
  <li>Address: <%= "#{user.street_number} #{user.street_name}" %></li>
  <li>City: <%= "#{user.zipcode} #{user.city} - #{user.country}" %></li>
  <li>Company: <%= user.company_name %></li>
</ul>

The controller is something like this:

class UsersController < ApplicationController
  def show
    user = User.find(params[:id])

    render :show, locals: { user: user }
  end
end

Of course, another view, within the cart display (for example), would make use of an address partial:

# app/views/carts/_address.html.erb
<ul>
  <li><%= "#{user.street_number} #{user.street_name}" %>
  <li><%= "#{user.zipcode} #{user.city} - #{user.country}" %></li>
</ul>

A decorator can make things cleaner.

class UserDecorator < Draper::Decorator
  delegate :company_name

  def age
    ((Time.now - object.date_of_birth.to_i) / 60 / 60 / 24 / 365).to_i
  end

  def address_line
    "#{object.street_number} #{object.street_name}"
  end

  def city_line
    "#{object.zipcode} #{object.city} - #{object.country}"
  end

  def name
    "#{object.first_name} #{object.last_name}"
  end
end

The controller then looks like the following:

def show
  user = User.find(params[:id])

  render :show, locals: { user: user.decorate }
end

And the view is simpler.

# app/models/users/show.html.erb

<h1><%= user.name %></h1>
<ul>
  <li>Born <%= user.age %> years ago</li>
  <li>Address: <%= user.street_line %></li>
  <li>City: <%= user.city_line %></li>
  <li>Company: <%= user.company_name %></li>
</ul>

As you can see, it's not so different either.

Decorators: When Not to Use Them in Your Ruby on Rails App

Decorators can be overused and end up poisoning your code base. You might stuff too much in them, causing complex queries and an overhead. Decorators could also end up mixed in with helper methods and undecorated classes. All in all, you may overuse Draper.

Decorators, like any class, need to be focused and stick to one responsibility: presentation logic. If a method doesn't fit, maybe it belongs somewhere else. Complex queries might appear when the company_name method or something similar pulls data from a model and its associates.

A similar issue can emerge when you decorate too many objects at once. After all, you basically double the number of objects if you decorate a whole collection. So, be aware of this and decorate when needed.

Ruby on Rails developers tend to use a lot of helper methods. Some helper methods make sense but lack the object-oriented angle, in my opinion, and end up causing confusion. Relying on decorators will help limit the number of helper methods, but if you do use some, keep it light.

Testing Ruby code is almost a standard, it's definitely a good practice, and it also applies to Decorators. This will help, just like for any other class.

Preparing a Whole View with Decorator

There is a form of Decorator that is a bit more advanced: the view model, which can be done with Draper, SimpleDelegator, or even a plain old Ruby object (PORO). The concept is as follows: you create classes to prepare the data for a view from one or more objects. If we're talking just one object, we have something similar to what we have seen. If it's more than one, then it gets more crunchy.

The idea is to gather the whole responsibility of "data presentation" into one class, even for different objects at once. This is a case where we might cause complex queries, so don't hesitate to use includes and preload methods with queries to eager load associations as needed.

That way, instead of passing several objects to the view from the controller, you can prepare just one, and then access the data — ready to be used — from properly named methods.

Wrapping Up

In this post, we ran through the basics of Decorator and how to use it, before diving into how to use Decorators in Draper for a Ruby on Rails application. We finally touched on when to avoid using decorators and how to prepare a whole view with Decorator.

Draper is one of those gems you'll wish you had discovered before. It gives wings to Decorators. It's also the kind of nicely integrated library that will not only help you keep your code clean by setting clear limits between responsibilities, but also provide you with custom grammar and magic that fits the Ruby on Rails ecosystem like a glove.

Happy coding!

P.S. If you'd like to read Ruby Magic posts as soon as they get off the press, subscribe to our Ruby Magic newsletter and never miss a single post!

An Introduction to RuboCop for Ruby on Rails

Thomas Riboulet — Wed, 13 Sep 2023 12:00:00 +0000

Good code has a lot to do with how readable it is. As developers, we more often read code than write it. As my Perl teacher told us many times: the flexibility of Perl's syntax was its best and worst trait at the same time. Ruby's syntax was influenced partly by Perl and is also quite flexible.

Whatever language you pick, set some guidelines to avoid overusing a language's flexibility. Style guides for Ruby abound on the web, and it's not difficult to pick a style nowadays. But there is not much point in having copious debates on style and whether a proposed change follows a guide. Style enforcement is best left to a tool.

Such tools are called linters and static code analyzers. The de facto standard for Ruby in that category is RuboCop. Here follows an introduction to RuboCop: what it is, how it helps developers, how to use it, and some key practical use cases.

What Is RuboCop for Ruby?

First, RuboCop is a great tool to lint a code base and ensure a specific coding style is followed (such as indentation, spacing, naming conventions, etc.). It's heavily configurable on that level through many rules, called "cops". Each can be activated (or not) and tailored (for example, the number of characters per line).

Ensuring a specific coding style is followed helps reduce developers' cognitive load in writing and reading code. It's not a matter of code looking "nice"; it's rather a matter of code looking similar to the rest of the code base.

The second side of RuboCop is its ability to analyze code statically for quick insights into code complexity and potential code issues, such as the misuse of variables.

As RuboCop is a little utility, it's easily run within a CI pipeline and in any developer's IDE. Thus, RuboCop's feedback can be integrated into the key places where it matters: when code is being written and before it's merged into the code base.

How to Use RuboCop for Ruby

Style is a matter of taste, so it is entirely subjective. Remember the main point behind using a linter: it's just there to help follow a chosen style because it gives us more capacity to do what matters in any project.

By default, RuboCop will enforce the style defined in the Ruby Community Style Guide. We can tailor it to our specific tastes and context, but let's rely on this basic set of rules to learn how to use RuboCop.

Simple Use of RuboCop

Adding RuboCop to a project is as simple as adding the rubocop gem to the development and test group in the Gemfile.

group :development, :test do
  gem 'rubocop', require: false
end

There are also several complimentary gems you can use, including:

Those last two will be useful for many of you.

Once the gem, or gems, is installed, we can run rubocop from within the root folder of the Ruby application.

$> rubocop *

This will print out a report of all "offenses" and how many can be automatically fixed.

For example:

$> rubocop *
Inspecting 807 files
...CCC....................
Offenses:

app/controllers/api/messages_controller.rb:46:25: C: Naming/MethodParameterName: Method parameter must be at least 3 characters long.

80 files inspected, 20 offenses detected, 7 offenses autocorrectable

Let's dissect the only offense we have kept in this example.

RuboCop's documentation explains that this issue:

Checks method parameter names for how descriptive they are. It is highly configurable.

This is followed by an explanation of the configuration that can be made for this specific rule (we will cover that soon).

What will be of interest to most are the examples of good and bad styles, as checked by this rule:

# bad
def bar(varOne, varTwo)
  varOne + varTwo
end

# With `AllowNamesEndingInNumbers` set to false
def foo(num1, num2)
  num1 * num2
end

# With `MinNameLength` set to number greater than 1
def baz(a, b, c)
  do_stuff(a, b, c)
end

# good
def bar(thud, fred)
  thud + fred
end

def foo(speed, distance)
  speed * distance
end

def baz(age_a, height_b, gender_c)
  do_stuff(age_a, height_b, gender_c)
end

We can apply this advice and rewrite the code to match the required style. RuboCop can often fix the issue it has found (we will look at this a bit later).

Configuring Rules in RuboCop

By default, out of the box, RuboCop comes with a default set of pre-configured rules. The documentation will tell you Rubocop's default rules.

Configuring RuboCop for a project is done through the .rubocop.yml file at the project's root. This can be tailored further in sub-folders, but I wouldn't recommend it.
And, of course, it's also possible to have system-wide configuration files within the user's home folder: ~/.rubocop.yml or ~/.config/rubocop/config.yml.

Here is a simple example of such a configuration:

Layout/LineLength:
  Max: 99

Let's reuse the previous rule: Naming/MethodParameterName.

Naming/MethodParameterName:
  MinNameLength: 3
  AllowedNames:
    - as
    - at
    - in
    - ip
    - id
    - to

There are a lot of things that can be tailored in the RuboCop configuration file. The documentation can help you pick the rules you want to use, but a few other options are available to give you a starting point beyond the default rules.

The Ruby style guide matches RuboCop's default configuration, for example. But you can also find other guides like the Relaxed Ruby Style, and some companies - such as Shopify - share theirs.

Arguments in RuboCop

RuboCop can be run without arguments for a basic check, but we can add on a few arguments for different effects:

-a : to auto-correct offenses, but only when it's safe to do so.
-A: to auto-correct offenses, even when it's not safe to do so.
-E: to display extra details for each offense listed.
-S: to display style guide URLs in the offense messages.

Those are the main options we might be interested in. -E and -S are great to add whenever you run RuboCop to check the code base. They both give more details for developers to figure out what to do.
-a and -A are handy to quickly take care of the "small" issues, but beware of the automatic side. It might do well enough for minor style offenses, such as spaces, but other things might not be that simple.

Bending the Law

In some rare cases, you might want a RuboCop rule or rules to be disabled around one or several lines in a file. This is generally frowned upon, as it creates a precedent many developers won't hesitate to replicate. Yet it might still be useful to know how to do this hack for certain cases.

The way to disable a rule and then re-enable it is to use a pair of comments:

# rubocop:disable Layout/ClassStructure, Style/AndOr
[...]
# rubocop:enable Layout/ClassStructure, Style/AndOr

This will disable and enable two rules: Layout/ClassStructure, and Style/AndOr.

In the previous example, you can also disable whole sections (or departments) of rules by using the department name: Layout or Style.

Finally, you can also disable all the rules in one go.

# rubocop:disable all
[...]
# rubocop:enable all

RuboCop in Practice

Now that we have seen what it is and how to use it, let's review how we might use RuboCop in our day to day.

Local Uses

As discussed before, a linter's purpose is to ensure a standard style is used throughout a code base. Standards are how we help each other work together without putting up complex conversion and compensation schemes.
When building a house, standards are the way every carpenter knows how to work together. The actual details will be a bit different from one house to another, but, using the standard, the work different carpenters do will match.

RuboCop helps software engineers work together by keeping their code up to a certain standard style.

The simplest way to use RuboCop is to run it before making a commit or once in a while before pushing commits to a remote repository. As described in the first part of this post, using rubocop * will run a check of the code base and display any offenses for you to fix.

You can then use the -a or -A option on another run to get some or all offenses fixed by RuboCop.

$> rubocopo -a

You can also fix them yourself, of course.

Within an IDE

Some IDEs and text editors have RuboCop plugins, so you can get notices about style offenses while working directly on code.
The only issue with these is the configuration, which can be fiddly.

Integration with CI

It's important to run RuboCop within CI pipelines.

Usually, we run linters such as RuboCop as part of a pipeline's first steps to notify the author of code changes about any offense quickly. We also consider such infractions important, so they will block the Pull or Merge request in its tracks. A merge should not be possible if the style is not correct.

If your project relies on GitHub's Actions, you can find a RuboCop action. You can build similar steps for any CI/CD pipeline out there. The principle is simple: run RuboCop against the code base as an early block within the pipeline; if there is an infraction, it will return a non-zero code, and the CI will treat that as a failure. The output can be used more easily as an artifact.

The -f option will allow you to tailor the output format. This can be practical when running RuboCop in the CI pipeline: in markdown, HTML, or GitHub. I'd advise starting with markdown or HTML, but you should also consider the fairly readable default format.

Adopting RuboCop in a New Project

Many projects start without a coding style or diverge from one for some reason. Getting such code bases back in the fold is often challenging and hard work.

The first run of RuboCop in such a context will usually output a fairly long list. Trying to solve all offenses at once is foolish. Instead, RuboCop allows us to generate a to-do list.

Running RuboCop with the --auto-gen-config option will generate the todo file. This file will disable any rule that is not respected. It's located within the project folder .rubocop_todo.yml.

Disabling all the rules that are not respected rather than fixing them might seem counterproductive. But we don't stop here. This step ensures we don't face a mountain of work.
We can remove a rule from the ignore list and fix all offenses against it, working our way, one rule at a time, through the to-do list and the code base.

This approach — of ignoring infractions to one or more rules within multiple files and then fixing the infractions one by one in many files — is doable, but will require a lot of back and forth between files. You might end up changing several files and several lines multiple times over the course of the process.

Another method is to use a "per file" approach. Using the following syntax within the to-do list file, you will ignore infractions to all cops in the files listed.

AllCops:
  Exclude:
    - "app/models/user.rb"
    - "app/controllers/users_controller.rb"

You can work your way through those files one by one: removing the file from the list, running RuboCop against it, and then fixing all offenses.

Whichever approach you pick, you must remember this is a step towards improvement through continuous learning and effort. You need a strategy and vision that works well with that: include enough Slack time within the team schedule, or set specific times aside to work on this issue.

Making RuboCop Easier to Use with Standard Ruby

RuboCop and coding style guides have helped us determine standards for each project and team. We should only debate what code is doing, not how it looks.

Some Ruby developers have made the point that we can even forego adjusting RuboCop's configuration. The idea is simple: after so many years working with Ruby, we more or less know how Ruby code should look, so a style that works for most will be quite okay.

This approach is known as Standard Ruby. It can also be completed with plugins, including one for Ruby on Rails projects.

Wrapping Up

RuboCop is, alongside Bundler, a good friend to any Ruby developer. As we have seen, it's easy to run it locally to get a list of offenses against a project's style standard.

We have also seen how RuboCop can fix a lot of those offenses on its own, and how to work our way through a long list of offenses if we start from a large backlog.

RuboCop is a tool in your toolbox; code style is only meant to help a team work together and shouldn't be a perpetual topic of debate. Yet, we have also seen that if you find it tedious to figure out a style for your project, you should look into projects such as Standard Ruby.

Happy coding!

P.S. If you'd like to read Ruby Magic posts as soon as they get off the press, subscribe to our Ruby Magic newsletter and never miss a single post!

Keep Your Ruby App Secure with Bundler

Thomas Riboulet — Wed, 05 Jul 2023 13:12:52 +0000

This article covers the use of bundler features to secure Ruby applications. In this day and age, we have to be more and more careful about software supply chain security.

We'll show you how to start this journey by relying on a Gemfile and bundler to manage your project's dependencies.

By the end of the post, you will better understand how bundler audit and bundler outdated work. Both can help you monitor the security state of your project's dependency tree.

Let's dive in!

An Introduction to Bundler for Ruby

The history of Bundler is linked to RubyGems. RubyGems, first released in 2004 by Chad Fowler, is a package manager that makes it possible to distribute and manage Ruby libraries, applications, and their dependencies.

Bundler, on the other hand, is a dependency manager. It was first released in 2009 by Carl Lerche.

Bundler helps developers manage dependencies between different Ruby libraries and applications. It uses a Gemfile to define the libraries and versions that a project depends on, then installs and loads those libraries in the correct order. Bundler provides a simple way to manage dependencies and ensure that all the required libraries are installed and loaded correctly.

Supply Chain Security

RubyGems and Bundler can only solve some security issues. For example, in 2013, 2018, and 2020, several security issues emerged directly related to RubyGems. Each time, gems were compromised, potentially exposing thousands of projects and products to malicious actors.

Nowadays, the security of the software supply chain has become more high profile, due to major incidents like 2020's SolarWinds hack, EventStream in 2018, and Equifax, Maersk, Merck, and FedEx in 2017.

Let's see how Bundler can help us avoid some security issues.

Bundler's Security-Related Features for Ruby

Bundler comes with several features that allow us to secure a Ruby project:

Source validation: ensures gems are installed from a specific, trusted source.
With a dependency graph, we can see a whole list of dependencies for each gem, helping us to identify potential security risks.
A Gemfile.lock file records the specific versions of each gem used in the project. As it's packaged with the project, it ensures that the same versions of gems are used across different environments.
Vulnerability detection: Thanks to an integration with the Ruby Advisory Database (RDB), Bundler can detect known security vulnerabilities in gems.
An audit command lets you list known security vulnerabilities related to gems a project depends on.
Checksum verification: Bundler verifies the checksum of each gem before installing it.
Gem signing and signature verification: Gems can be signed cryptographically by a developer.

But, alas, signing gems is complicated and requires a lot of steps. As a consequence, not all gems are signed, thus putting many projects at risk.

Yet, in the meantime, we can rely on two features in particular to ensure that a project doesn't rely on packages that are too old or that have been identified as carrying a security risk.

These features are bundler audit and bundler outdated. Let's look at bundler audit first.

About Bundler-audit

bundle audit is a command-line tool that helps you identify security vulnerabilities in the Ruby libraries that your project depends on. It is a plugin for the Ruby dependency manager Bundler and is included with Bundler version 1.10 and above.

bundle audit works by analyzing your Gemfile.lock file, which lists all the dependencies for your project and their versions. It then compares this information with a database of known vulnerabilities in Ruby gems (maintained by Rubysec).

If a vulnerability is found, bundle audit will provide you with information about the vulnerability, including its severity level and which gem versions have been affected. It will also suggest actions you can take to address the vulnerability, such as upgrading to a patched version of the gem or removing it entirely.

bundle audit is a useful tool for ensuring the security of your Ruby projects, especially if you are using third-party libraries or dependencies. By regularly running bundle audit as part of your development workflow, you can stay up-to-date on any vulnerabilities that may affect your project and take proactive steps to address them.

Usage of Bundler-audit in Ruby

The basic use of Bundler-audit is through the bundle audit command:

$> bundle-audit

Name: actionpack
Version: 3.2.10
Advisory: OSVDB-91452
Criticality: Medium
URL: http://www.osvdb.org/show/osvdb/91452
Title: XSS vulnerability in sanitize_css in Action Pack
Solution: upgrade to ~> 2.3.18, ~> 3.1.12, >= 3.2.13

$>

As you can see, it outputs the name and version of a package used by the project we are testing, which contains a medium-level security issue. It also outputs the URL of the security advisory and a possible solution.

Keeping Bundler-audit's Database Up to Date

As the audit is basically comparing a list of gems used in the project with a list of known security issues in a local copy of the security advisory database, you need to keep that database up to date.

To do so, you just need to run the bundle audit update command. This will fetch the latest version of the database. You should only have to run the audit again to check for any new security risks.

Integration In a CI Pipeline

As with other tools aimed at keeping your project safe, it's best to ensure an audit runs automatically on a regular basis (if not after every commit and push to the Git repository).

You can rely on a git post commit hook to run the audit locally if the Gemfile.lock changes. Here is an example:

# .git/hooks/post-commit
if git diff --name-only HEAD~1 | grep -q Gemfile.lock; then
    echo "Gemfile.lock has changed, running audit..."
    bundle audit update && bundle audit
fi

This is a bit radical, but it works. You can rely on the same approach within the CI pipeline. As the bundle audit command will return a non-zero exit status, the CI pipeline will consider it to have failed. Unfortunately, we don't have a proper audit report out of the box. Instead, you have to direct the output of the bundle audit command towards a file and save it as an artifact of the build for the CI pipeline.

Here is how to direct the command's output to a file:

$> bundle audit update && bundle audit > /tmp/bundle-audit-report.txt

As each CI service handles artifacts differently, check the relevant documentation to see how to do this.

Bundler-audit in Summary

bundle audit is not a complete solution, yet it still lets your team know if your project relies on unsafe gems (without costing you an arm and a leg). Your team should put tools such as git hooks or CI tasks in place, and relevant integrations to make any issues visible.

All things considered, I'd say it's not too much trouble. It probably requires a few hours to get started and have the basic information spit out as a comment in your favorite git hosting solution, or as a notice in a Slack channel.

Yet bundle audit is only one part of what you can do. It only tells you if there is a security issue related to a gem relied on by a project. It does not tell you if a gem is outdated. To handle that, bundler outdated is the command to use.

Bundler Outdated for Ruby Gems

Auditing for security risks is very important, yet listing outdated gems is also a big issue. The longer you wait to update a dependency, the higher the risk that your code breaks.

You should aim to work in small iterations, deployed frequently, to limit the amount of change contained in each deployment. Equally, you should aim to update any gem you use as soon as it's updated, or as close to that as possible.

Usage of Bundler Outdated

Just like bundler audit, bundler outdated is very simple to use. Just call it at the root of your Ruby project. It will compare the Gemfile.lock content to the current gem releases listed in it.

$> bundle outdated
Fetching gem metadata from https://rubygems.org/.........
Resolving dependencies......

Gem           Current    Latest    Requested   Groups
addressable    2.8.1      2.8.4
capybara       3.38.0     3.39.0    >= 0        test
devise         4.9.0      4.9.2     >= 4.6.0    default

$>

As you can see, three gems are outdated in this project. Let's see how we should read this table:

The first column contains the name of the gem.
The second column shows the currently installed version.
The third column shows the latest version available.
The fourth column shows the request version (from the Gemfile).
The fifth column shows the group the gem is part of (in the Gemfile).

Here, we can see we don't have much to worry about for addressable and devise, as the difference in releases is within the patch versions (third part of the release number). The version of capybara is only behind one minor release, which implies a few more changes, but this rarely means breaking changes.

Still, the logical thing to do here is to update all three as soon as possible.

Usage In a CI Pipeline

As bundle outdated will return a non-zero exit status for outdated gems, a CI task it's based on is considered failed. So you can have a simple and direct flag in your CI pipeline in case of outdated dependencies.

Yet you might want to rely on a pair of flags to improve your use of bundle outdated. The command can filter its output to only list gems that have pending patch-level updates:

$> bundle outdated --filter-patch
...
Gem           Current    Latest    Requested   Groups
addressable    2.8.1      2.8.4
devise         4.9.0      4.9.2     >= 4.6.0    default

In the same manner, you can list only gems with pending minor version updates:

$> bundle outdated --filter-minor
Gem           Current    Latest    Requested   Groups
capybara       3.38.0     3.39.0    >= 0        test

And in the same way, you can list only gems with pending major release updates:

$> bundle outdated --filter-major
Gem                Current    Latest    Requested   Groups
sidekiq-scheduler   4.0.3      5.0.1      >= 0       default

Those three flags let you easily tailor a CI task to only warn you that a patch-level update is available but not block the build (or the reverse), for example.

A complimentary option allows you to only list outdated gems within the default group:

$> bundle outdated --group default
...
Gem                Current  Latest  Requested          Groups
devise             4.9.0    4.9.2   >= 4.6.0           default
faker              3.1.1    3.2.0   >= 0               default

As gems within test and development groups don't impact the production release, they could be considered less of a priority to keep up to date, for example. Thus you can use the flag only to raise a warning or block the CI pipeline if gems within the default group are outdated.

Wrapping Up

Maintaining the security of your Ruby application is not just the result of one action. Rather, it's a cumulative effect of several actions put together. As we've covered in this post, Bundler provides us with two commands that can help you to improve your application's security:

bundle audit quickly lets you know if any gem you add or use in your project could pose a security threat and what to do about it.
bundle outdated allows you to flag gems that should be updated. It complements bundle audit, and if you keep on top of it, you avoid having an update bundle that's too large.

These two commands are easy to use and integrate with local feedback loops and CI pipelines.

Happy coding!

P.S. If you'd like to read Ruby Magic posts as soon as they get off the press, subscribe to our Ruby Magic newsletter and never miss a single post!

DEV Community: Thomas Riboulet

An Introduction to Auth0 for Ruby on Rails

Getting Started

Configuring Our Ruby App in Auth0

Preparing Our Ruby on Rails Application

Adding the Auth0 Gem to the App

Configuring Auth0

Setting Up Routes and UI with Tailwind

Working with Scopes and Data

A Word On Sessions

A Security Concern

Integrating with Other Providers

Opening Up Towards Authorization

What We've Covered

Debugging in Ruby with Debug

Debugging Without A Debugger: What's the Issue?

Setup

Basic Debugging Techniques with Debug for Ruby

Breakpoints

Stepping

More Commands to Assist Debugging

Using next

Using step

Moving In the Stack

Using a Map

Knowing What's Available

Using finish

Adding Breakpoints On the Fly

Adding Conditions

Integration with IDEs

Recap and Wrapping Up

How to Use Tailwind CSS for Your Ruby On Rails Project

Tailwind CSS: A Utility-First Approach

A Word on Scales

Setting Up Tailwind in a Ruby on Rails Environment

Dissecting Our Landing Page

Configuring Tailwind for Ruby on Rails

Asset Pipeline

Tailwind for Rails in Action

A Simple Form

A Responsive Navigation Bar

Tailwind vs. Other Frameworks

Wrapping Up

Creating Forms in Ruby on Rails with Simple Form

Forms and Ruby on Rails

Installing Simple Form

Basic Usage of Simple Form

About Column Types and Form Fields

Booleans

HTML

Custom Inputs and Additional Options

i18n Support

Value Objects

Wrapping Up

Debugging in Ruby with pry-byebug

Set Up pry-byebug for Ruby

Basic Debugging with Breakpoints

Making Small Steps from Breakpoints

Even Smaller Steps

Free from puts

Finishing a Debugging Session

Advanced Use Cases of pry-byebug for Ruby

Rewinding and Replaying

Add Breakpoints On the Fly

Conditional Breakpoints

Wrapping Up

Good Database Migration Practices for Your Ruby on Rails App using Strong Migrations

Issues with Schema Migrations in Ruby on Rails

How Can We Fix Problems with Schema Migrations?

Getting Help from Strong Migrations

Installation

Adding a Column or a Table

Renaming a Column

Removing a Column

Backfilling Data

Adding Strong Migrations to an Existing Ruby on Rails Project

Some Additional Advice on Migrations

Production Environments and Databases

Avoiding Downtime

Backups

Using `next`

Using `step`

Using `finish`

Set Up `pry-byebug` for Ruby

Free from `puts`

Advanced Use Cases of `pry-byebug` for Ruby

Simplest Tests in RSpec for Ruby: `describe` and `it`

Avoiding Repetition with `let` in RSpec for Ruby

A Note on `let`

`let` Vs Instance Variables in RSpec for Ruby