DEV Community: Unathi Chonco

Ruby Method Lookup Demystified: Inheritance, Mixins, and Super

Unathi Chonco — Mon, 15 May 2023 08:37:10 +0000

If youve worked on Ruby projects for a while, you would have encountered times when you were digging to find out how and why a certain method behaved the way it did, because it didnt seem to use the code in the method definition youre looking at. And what happens when there are multiple methods with the same name?

This can seem confusing, but Ruby does have a specific way or path that is used to determine what methods to actually call. This process is called method lookup. In this guide we will delve into the details of method lookup, covering inheritance, mixins using include, prepend, and extend, as well as the super method. With clear examples and explanations, this article will help you build a strong foundation and understanding that enables you to write more maintainable code.

Inheritance and Method Lookup in Ruby

In Ruby, inheritance allows a class to inherit the methods and attributes of another class. The class that inherits is called a subclass, and the class that is inherited from is called a superclass. Method lookup in Ruby begins by searching the instance methods of the object's class, and if not found, it moves up the class hierarchy until it reaches the superclass. Let's consider an example:

class Animal
  def speak
    "I'm an animal!"
  end
end

class Dog < Animal
end

dog = Dog.new
puts dog.speak # Output: I'm an animal!

In the example above, the Dog class inherits from the Animal class. When we call the speak method on a Dog object, Ruby first looks for the method in the Dog class. Since it doesn't find it there, it searches the superclass Animal, finds the speak method, and executes it.

Mixins and Method Lookup

Ruby uses modules as a way to implement multiple inheritance through mixins. Mixins are used to share methods among different classes, making your code more modular and easier to maintain. There are three primary ways to include a module in your class: include, prepend, and extend.

Include

include adds the module's methods as instance methods in the class. When a method is called on an object, Ruby first searches the object's class, then the included module, and finally the superclass.

module Speak
  def speak
    "I'm a speaking mixin!"
  end
end

class Dog < Animal
  include Speak
end

dog = Dog.new
puts dog.speak # Output: I'm a speaking mixin!

In this example, we've included the Speak module in the Dog class. When we call the speak method on a Dog object, Ruby first looks for the method in the Dog class, then in the included Speak module, and finally in the superclass Animal. Since it finds the speak method in the Speak module, it executes that method.

Prepend

prepend is similar to include, but it inserts the module's methods before the class in the method lookup chain.

class Dog2 < Animal
  prepend Speak
end

dog = Dog2.new
puts dog.speak # Output: I'm a speaking mixin!

In this case, when we call the speak method on a Dog object, Ruby first looks in the prepended Speak module, then in the Dog class, and finally in the superclass Animal. Since it finds the speak method in the Speak module, it executes that method.

Extend

extend adds the module's methods as class methods, rather than instance methods. This means that the methods can be called directly on the class itself.

class Dog < Animal
  extend Speak
end

puts Dog.speak # Output: I'm a speaking mixin

In this example, by using extend instead of include or prepend, we've added the speak method as a class method of Dog. This allows us to call the speak method directly on the Dog class.

The `super` Method

The super method in Ruby allows a subclass to call a method from its superclass. This can be useful when you want to extend the behaviour of a superclass method in a subclass without completely overriding it. Let's see an example:

class Animal
  def speak
    "I'm an animal!"
  end
end

class Dog < Animal
  def speak
    "#{super} and I'm a dog!"
  end
end

dog = Dog.new
puts dog.speak # Output: I'm an animal! and I'm a dog!

In the Dog class, we've defined a speak method that calls the speak method from its superclass Animal using the super keyword. This allows us to extend the behaviour of the Animal#speak method in the Dog class.

The `super` Method with Mixins

The super methods can still be used when mixins are involved, and for the purposes of this post is a great showcase of the method lookup flow.

In this example, we'll demonstrate the use of super in an object that uses both prepend and include to mixin the same method. We'll have three modules with a greet method, and a Person class that will include and prepend those modules.

module GreetInEnglish
  def greet
    "Hello! #{super}"
  end
end

module GreetInSpanish
  def greet
    "Hola! #{super}"
  end
end

module GreetInFrench
  def greet
    "Bonjour! #{super}"
  end
end

class LivingBeing
  prepend GreetInEnglish

  def greet
    "I'm a living being."
  end
end

class Person < LivingBeing
  include GreetInFrench
  prepend GreetInSpanish

  def greet
    "I'm a person. #{super}"
  end
end

person = Person.new
puts person.greet

In this example, we've added a LivingBeing class that includes GreetInEnglish and has its own greet method. The Person class now inherits from LivingBeing, includes GreetInFrench, and prepends GreetInSpanish.

When we call person.greet, the method lookup order is as follows:

GreetInSpanish#greet (prepended in Person)
Person#greet (defined in the class)
GreetInFrench#greet (included in Person)
GreetInEnglish#greet (prepended in LivingBeing)
LivingBeing#greet (inherited from the superclass)

The output will be:

Hola! I'm a person. Bonjour! Hello! I'm a living being.

Now, the method lookup chain correctly includes all mixins and the inherited method from LivingBeing. The super keyword is used in each of the mixin methods and the Person#greet method to call the next method in the lookup chain.

Conclusion

Understanding Ruby's method lookup process helps you write more maintainable code and tackle complex Ruby projects and libraries. Use inheritance, mixins, and the super method to override and extend capabilities in Ruby when needed. Be mindful of code complexity and avoid hiding implementation details in too many places. Happy coding!

🧑🏾🚀🚀

Ruby Bang (!) Methods

Unathi Chonco — Thu, 04 May 2023 12:54:17 +0000

Ruby is a powerful and elegant programming language, known for its readability and expressiveness. Optimised for developer happiness. One of the more unique aspects of Ruby is its "bang"(!) methods. As a newcomer to Ruby, you might find yourself wondering about the purpose of these methods and how to use them. In this article, we will explore Ruby's bang methods, the naming convention, and their use in a Ruby on Rails project.

What are Bang Methods?

In Ruby, bang methods are simply methods that have an exclamation mark (!) at the end of their names. The bang is a naming convention to signify that the method has some potentially surprising or dangerous behaviour compared to its non-bang counterpart.

Mutating bang methods

Generally, bang methods mutate/modify the object they are called upon, while their non-bang counterparts return a new object with the desired changes.

Here are a few examples of bang and non-bang method pairs in Ruby:

String#upcase and String#upcase!
Array#sort and Array#sort!
Array#uniq and Array#uniq!

Let's take a closer look at these examples to understand the differences between bang and non-bang methods.

Example 1: String#upcase and String#upcase!

String#upcase returns a new string with all characters in uppercase, leaving the original string unchanged. In contrast, String#upcase! modifies the original string in-place, converting all characters to uppercase.

text = "hello, world!"

uppercase_text = text.upcase
puts uppercase_text # => "HELLO, WORLD!"
puts text # => "hello, world!"

text.upcase!
puts text # => "HELLO, WORLD!"

Example 2: Array#sort and Array#sort!

Array#sort returns a new array with its elements sorted, while Array#sort! sorts the original array in-place.

numbers = [5, 3, 1, 4, 2]

sorted_numbers = numbers.sort
puts sorted_numbers.inspect # => [1, 2, 3, 4, 5]
puts numbers.inspect # => [5, 3, 1, 4, 2]

numbers.sort!
puts numbers.inspect # => [1, 2, 3, 4, 5]

Example 3: Array#uniq and Array#uniq!

Array#uniq returns a new array with duplicate elements removed, while Array#uniq! removes duplicate elements from the original array in-place.

repeated_numbers = [1, 2, 2, 3, 3, 3]

unique_numbers = repeated_numbers.uniq
puts unique_numbers.inspect # => [1, 2, 3]
puts repeated_numbers.inspect # => [1, 2, 2, 3, 3, 3]

repeated_numbers.uniq!
puts repeated_numbers.inspect # => [1, 2, 3]

Error-raising bang methods

In a Ruby application, bang methods are also prevalent for denoting error-raising methods. You can find common use cases in a library such as ActiveRecord, the built-in Object-Relational Mapping (ORM) framework for Ruby on Rails that handles database operations. Some of the most common ActiveRecord bang methods include:

ActiveRecord::Base#save and ActiveRecord::Base#save!
ActiveRecord::Base#create and ActiveRecord::Base#create!
ActiveRecord::Base#update and ActiveRecord::Base#update!
ActiveRecord::Base#destroy and ActiveRecord::Base#destroy!

Let's examine these ActiveRecord examples to understand their usage and differences in a Ruby on Rails application.

Example 1: ActiveRecord::Base#save and ActiveRecord::Base#save!

save and save! are instance methods used to persist an ActiveRecord object to the database. The non-bang method, save, returns a boolean value indicating whether the record was saved successfully or not. If there are any validation errors, it returns false.

On the other hand, save! raises an ActiveRecord::RecordInvalid exception if the record is invalid, halting the execution flow. This method is useful when you want to ensure the record is valid and saved; otherwise, an exception should be raised.

class User < ActiveRecord::Base
  validates :email, presence: true
end

user = User.new(email: "")

# Using save
if user.save
  puts "User saved!"
else
  puts "User not saved. Errors: #{user.errors.full_messages.join(', ')}"
end

# Using save!
begin
  user.save!
  puts "User saved!"
rescue ActiveRecord::RecordInvalid => e
  puts "User not saved. Errors: #{e.record.errors.full_messages.join(', ')}"
end

Example 2: ActiveRecord::Base#create and ActiveRecord::Base#create!

create and create! are class methods used to create and save a new ActiveRecord object to the database in a single step. Similar to save, create returns the newly created object, whether it's valid or not. If the object is invalid, it won't be persisted to the database.

In contrast, create! raises an ActiveRecord::RecordInvalid exception if the object is invalid, making it suitable for situations where you want to ensure the record is valid and created; otherwise, an exception should be raised.

# Using create
user = User.create(email: "")
if user.persisted?
  puts "User created!"
else
  puts "User not created. Errors: #{user.errors.full_messages.join(', ')}"
end

# Using create!
begin
  user = User.create!(email: "")
  puts "User created!"
rescue ActiveRecord::RecordInvalid => e
  puts "User not created. Errors: #{e.record.errors.full_messages.join(', ')}"
end

Example 3: ActiveRecord::Base#update and ActiveRecord::Base#update!

update and update! are instance methods used to update the attributes of an ActiveRecord object and save it to the database. update returns a boolean value, indicating whether the record was updated successfully or not. If there are any validation errors, it returns false.

update!, like save! and create!, raises an ActiveRecord::RecordInvalid exception if the record is invalid, making it suitable for situations where you want to ensure the record is valid and updated; otherwise, an exception should be raised.

Example 4: ActiveRecord::Base#destroy and ActiveRecord::Base#destroy!

destroy and destroy! are instance methods used to delete an ActiveRecord object from the database. The non-bang method, destroy, returns the destroyed object if the deletion is successful. If the object has any before_destroy callbacks that halt the destruction process, it returns false.

In contrast, destroy! raises an ActiveRecord::RecordNotDestroyed exception if the object cannot be destroyed due to any before_destroy callbacks. This method is useful when you want to ensure the record is deleted; otherwise, an exception should be raised.

class User < ApplicationRecord
  before_destroy :check_admin

  private

  def check_admin
    throw :abort if email == "admin@example.com"
  end
end

user = User.create(email: "admin@example.com")

# Using destroy
if user.destroy
  puts "User destroyed!"
else
  puts "User not destroyed."
end

# Using destroy!
begin
  user.destroy!
  puts "User destroyed!"
rescue ActiveRecord::RecordNotDestroyed => e
  puts "User not destroyed."
end

In this example, the User model has a before_destroy callback that prevents the deletion of a user with the email "admin@example.com". When using destroy, the method returns false if the user cannot be deleted. However, when using destroy!, an ActiveRecord::RecordNotDestroyed exception is raised if the user cannot be deleted.

Conclusion

Understanding the differences between bang and non-bang methods in Ruby can empower you to write more efficient and maintainable code. Bang methods are more aggressive, often modifying objects in place or raising exceptions when operations fail. Non-bang methods are more lenient, returning modified copies of objects or allowing for flexible error handling. Knowing when to use each type of method can be useful in creating robust and reliable applications.

So, the next time you come across a bang method in Ruby, don't be afraid to use it but also be aware of its potential side effects. Happy coding!

🧑🏾🚀🚀

Next Level Ruby on Rails Application Monitoring with AppSignal

Unathi Chonco — Wed, 12 Jan 2022 13:09:58 +0000

In the first of this two-part series, we covered how to set up AppSignal in a Ruby on Rails application for many great insights out of the box. AppSignal can automatically track errors, monitor performance, and report metrics about some dependencies.

But, in many cases, each of our applications behaves in different ways, so we'll want more than just generic monitoring.

In this post, we will run through adding custom instrumentation and monitoring to a Ruby on Rails application. This will give you deeper insights into how your application is behaving.

Prerequisites if you want to follow along with the code:

An account on www.appsignal.com
Docker installed and running (to use docker-compose)

To follow along with this post, you will need to set up AppSignal in the sample application with your own AppSignal account.

Custom Instrumentation and Monitoring

When you need more than what AppSignal instruments out of the box, the AppSignal gem allows you to add custom instrumentation to your Rails application.

Instrumenting Parts of the Code

Let's say you want to add a new feature to an application. When a user visits /posts to view all posts, they should be able to filter for posts where the title begins with a specific letter (or something a lot more complex 🪄).

This new search functionality has already been implemented in the Post model with the method Post.where_title_starts_with. Let's update the PostsController#index to use the new method if a specific query parameter is present:

# app/controllers/posts_controller.rb
  def index
    starts_with = params[:starts_with]
    @posts = if starts_with.present?
               Post.where_title_starts_with(starts_with)
             else
               Post.all
             end
  end

This is such a core part of your application that you'll want to know how it performs and when that performance changes. AppSignal provides a few ways to do this.

First, we will instrument the contents of the Post.where_title_starts_with method. If you want to receive insights about any code blocks, you can use instrumentation blocks to wrap the code blocks. Update the method like this:

# app/models/post.rb
def self.where_title_starts_with(letter)
  Appsignal.instrument('Post.where_title_starts_with', "Fetch posts that start with letter") do
    Analytics.track_post_title_search(letter.downcase)
    select('*, pg_sleep(0.01)').where("title ILIKE :letter", letter: "#{letter.downcase}%").load
  end
end

Secondly, we also want to instrument the Analytics.track_post_title_search method being called because app/services/analytics.rb is doing some heavy processing. In this case, we will use method instrumentation to instrument the entire method more accurately:

# app/services/analytics.rb
require 'appsignal/integrations/object'

class Analytics
  def self.track_post_title_search(letter, sleep = sleep(1))
    # Some heavy processing
    sleep 1
  end
  appsignal_instrument_class_method :track_post_title_search
end

Insights

A few minutes after saving the above to the application, take a look at whatever new information is available on your AppSignal dashboard (if you don't see the information, you may need to restart the docker containers again). You can verify that the new feature works by visiting the posts index page with a search param:
http://localhost:3000/posts?starts_with=f

Depending on the number of posts created in the database, the
/posts endpoint will have become a lot slower.

If you open up performance issues on AppSignal ('Performance' -> 'Issue list') and view the PostsController#index action, lower down on the page, you should be able to see an 'Event Timeline'. This gives you a breakdown of how much time is spent running specific code:

This timeline exists for all performance events, but here, we can also see the custom instrumentation events. It shows us that calling Post.where_title_starts_with took 8.84 seconds to run, with 2.01 seconds used up by the Analytics.track_post_title_search method, and the remaining time used up by an active record query. You can also click into individual events for further investigation and see more information about their performance — e.g. the sql.active_record event.

AppSignal's instrumentation helpers give you a more detailed breakdown of the application code, so it's easier to gain insights into particular pieces of code that you think could impact an application's performance. You can learn more about this in AppSignal's instrumentation guide.

Exception Handling

Besides monitoring the performance of your code, you also need to know when the application doesn't behave as expected and where things go wrong. We've already seen how AppSignal reports exceptions that have not been handled by our code. But there's always a bit more than what comes out of the box.

You can start by removing existing code that causes an intermittent error. We see where this error occurs in the backtrace when viewing the error on the dashboard. Inside of app/controllers/pages_controller.rb remove the if statement:

class PagesController < ApplicationController
  def home
    CreateRandomPostsJob.perform_later
  end
end

Now, in the overview dashboard, the application's error rate will drop significantly.

Currently, when a user tries to view a post that doesn't exist, the application crashes — e.g, http://localhost:3000/posts/doesnotexist.
Instead, you might want to show them a message. Add a rescue to where this could happen inside the PostsController. Update the #set_post method:

# app/controllers/posts_controller.rb
class PostsController < ApplicationController
    .
    .
    .
    private
    def set_post
      @post = Post.find(params[:id])
    rescue ActiveRecord::RecordNotFound => e
      render json: { error: "Oops. That post isn't here" } , status: :not_found
    end
    .
    .
end

Because we are manually handling the exception, it won't automatically be reported to AppSignal. You can still track errors manually by using Appsignal.set_error.

The easiest way to track an error is to simply add it as the function's only argument like Appsignal.set_error(e). We also want to take advantage of the ability to add more context to the request. AppSignal allows you to tag events with your own arbitrary information using Appsignal.tag_request:

def set_post
  Appsignal.tag_request(user_id: 'user-from-params', post_id: params[:id])
  @post = Post.find(params[:id])
rescue ActiveRecord::RecordNotFound => e
  Appsignal.set_error(e)
  render json: { error: "Oops. That post isn't here" }, status: :not_found
end

Now visit http://localhost:3000/posts/doesnotexist to verify that you get back the JSON response as expected, instead of having the application crash.

Insights

After you try to view a post that does not exist, the added updates ensure that the errors are reported to AppSignal.
On the AppSignal dashboard, in 'Errors -> Issue list', find and view the new reported error (ActiveRecord::RecordNotFound).

The error detail page gives us useful context about the error, which by default, includes information about the request such as the HTTP method, parameters, and session data. You can see that the custom tags are also included, which gives you the ability to filter for all of the errors with a matching tag.

Because we tagged the request, it adds this information to errors and other instrumented events. If you view an individual post a few times, e.g., http://localhost:3000/posts/1, you will notice that the tags are also included when you look at the performance measurement ('Performance' -> 'Issue list' -> 'PostsController#show'). You can read more about tagging transactions in the guides.

This ability to add custom metadata to the transaction opens up many opportunities to help diagnose issues in production. A great example of this is adding Kubernetes metadata to your errors.

Metrics

Now that there is some custom instrumentation and error monitoring in place, you might realize that sometimes, there are large spikes in posts searches. Whenever a user searches, Analytics#track_post_title_search is called, which does some calculations and makes an API call to a third-party service. This third party has rate limits on the API. We want to track how often it is called to keep an eye on how close the application is to its limits.

AppSignal allows you to track custom metrics throughout the application as you wish.

First, we will track how often we're calling our analytics service and with what data, using a counter and tags:

#app/services/analytics.rb
require 'appsignal/integrations/object'

class Analytics
  def self.track_post_title_search(letter, sleep = sleep(1))
    Appsignal.increment_counter("track_post_search", 1, { letter: letter })
    # Some heavy processing
    sleep 1
  end
  appsignal_instrument_class_method :track_post_title_search
end

Secondly, we will also track the number of posts being returned in the PostsController#index, because this is a core part of the application's behavior, and we know it keeps growing:

#app/controllers/posts_controller.rb
class PostsController < ApplicationController
    .
    .
  def index
    .
        .
    Appsignal.set_gauge("posts_index", @posts.size, starts_with: params[:starts_with])
  end
end

The fake traffic script still running on the application will generate some data, but to add more variety, let's also search for posts starting with f, l, and v.

Insights

To view the custom metrics, you will need to create a dashboard with custom graphs on AppSignal. This can be done through the UI, but we will just import one for this example. Under the 'Dashboard' section, click on 'Add dashboard' and import a dashboard with the following:

{
  "title": "Post Search",
  "description": "Sample dashboard about posts search activity",
  "visuals": [
    {
      "title": "Analytics",
      "line_label": "%name% %letter%",
      "display": "LINE",
      "format": "number",
      "draw_null_as_zero": true,
      "metrics": [
        {
          "name": "track_post_search",
          "fields": [
            {
              "field": "COUNTER"
            }
          ],
          "tags": [
            {
              "key": "letter",
              "value": "*"
            }
          ]
        }
      ],
      "type": "timeseries"
    },
    {
      "title": "Search",
      "line_label": "%name% %starts_with%",
      "display": "LINE",
      "format": "number",
      "draw_null_as_zero": true,
      "metrics": [
        {
          "name": "posts_index",
          "fields": [
            {
              "field": "GAUGE"
            }
          ],
          "tags": [
            {
              "key": "starts_with",
              "value": "*"
            }
          ]
        }
      ],
      "type": "timeseries"
    }
  ]
}

You should see data on your graphs within a few minutes. Hovering over the lines shows you a legend of the metrics collected within the timeframe you're viewing.

Notice that this shows different lines for each tag value. Currently, our fake traffic is only searching for the letter e, but because we manually searched for other letters, you will see a new line on the graph for each one to indicate another data point.

Thought that was enough? AppSignal has more custom instrumentation solutions to offer that we won't be covering here. One that's worth a quick mention is breadcrumbs. Breadcrumbs allow you to track a list of actions in your application, which will then be reported in an error. You'll have even more specific and ordered information about what led up to an error.

Read all about custom instrumentation in the guides.

Wrap-up: Custom Instrumentation and Monitoring for Ruby Apps with AppSignal

Part 1 of this series covered the basic setup and use of AppSignal for your Ruby applications.

In this part, we've taken an application that already has great out-of-the-box monitoring and made it even better using the AppSignal gem.

AppSignal's custom instrumentation, error tracking, and performance monitoring features give you the insights you need into how your applications are behaving. It gives your application a lot out of the box while letting you take control when needed.

It's time to let your code run free in the wild, as long as you keep an eye on how it's doing. 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!

Ruby on Rails Application Monitoring with AppSignal

Unathi Chonco — Tue, 14 Dec 2021 14:50:36 +0000

When running and maintaining an application in a production environment, we want to feel confident about the behavior of the application and know when it isn't working as expected. At the least, we want to track errors, monitor performance, and collect specific metrics throughout the application.

Because we're developers and love maintainable solutions (right?), we also don't want to end up in a jumble of tools, integrations, and dependencies that make it harder for us to keep track of everything.

In this post, we will add AppSignal to a Ruby on Rails application to help give clear insights into application behavior.

Prerequisites if you want to follow along with the code:

An account on www.appsignal.com
Docker installed and running (to use docker-compose). *only required if using the sample application in this post

Setting up AppSignal

Note: You can skip this section if you're adding AppSignal to your own Rails application. In that case, you can also ignore the instructions related to Docker or how to restart your Rails server throughout the post — you instead restart/redeploy your application as you usually would.

We will use a sample application to get us started and run it on our machine using Docker.

Run the following commands to clone the repository, install dependencies, and run the application:

$ git clone --branch appsignal-setup/start-docker --single-branch https://github.com/choncou/sample_rails_app appsignal-setup
$ cd appsignal-setup
$ yarn start:compose

When you run this for the first time, it may take a while to build the docker images and download all the dependencies. Once it is complete, it will start the Rails server, PostgreSQL database, and Redis. You should see requests in the logs and view the running application on http://localhost:3000/.

About Our Sample Application

The application we're working with is very minimal, so there are only a few things to note.

We have a Post model, PostsController, and all CRUD actions exposed via the /posts route.

We also have a home page rendered by the PagesController, which enqueues a background job CreateRandomPostsJob to generate random posts asynchronously.

Lastly, we're using Sidekiq for background job processing.

Our small blogging platform also already has some active users. There is a script (./bin/traffic) running in the background together with the server that regularly makes a few requests to imitate traffic on the applications.

That's it. We've just released a product, and everything works perfectly...

Or at least that's what we think until we start seeing user reports about the application's performance and users running into errors.

So how do we figure out what's going on? When we're working in a development environment, it's easier to look into errors. But when our application is running in production, this becomes harder. There must be a better way to find errors than to search through those server logs.

AppSignal to the rescue!

Getting Started with AppSignal

Let's begin our monitoring journey by adding AppSignal to our application.

You'll need to log into your account at www.appsignal.com.

If you're a new AppSignal user, you will see the page below to add an application (whereas existing users need to click on 'Add app').

Select "Install for Ruby", which will then give us a few simple steps to follow:

Add the gem to your Gemfile
```
# Gemfile
gem 'appsignal'
```

Install the gem by running bundle install inside of the docker container, which you can access with yarn compose:sh

$ yarn compose:sh
# We are now in a bash console within a docker container
$ bundle install
# Stay in this console for the next command

Install AppSignal

During the installation, you'll need to respond to two prompts:

- `Do you want to change how this is displayed in AppSignal? (y/n): n`
- `How do you want to configure AppSignal?` : Input `1` because we will use a config file instead of just environment variables

Use the API key shown on the AppSignal setup page:

```bash
$ bundle exec appsignal install <your-api-key>
...
...
#####################################
## AppSignal installation complete ##
#####################################

  Sending example data to AppSignal...
  Example data sent!
  It may take about a minute for the data to appear on https://appsignal.com/accounts

  Please return to your browser and follow the instructions.
```

After you run the install script, you'll notice when the AppSignal setup is complete in your browser. You can then 'Go to app' to view your AppSignal dashboard for your development environment:

The installation command creates a config/appsignal.yml which allows you to configure AppSignal settings for different environments. You can learn more in the AppSignal Ruby configuration docs.

In the config/appsignal.yml is your push API key. You would usually remove it from this file and use an environment variable instead. For this post, that won't be necessary.

We need to restart the application to ensure that our changes take effect because we have installed a new gem. The simplest way is to stop the docker containers with ctrl-c inside of the terminal window running the server and start docker-compose again with:

$ yarn start:compose

This can take a while because it rebuilds the docker image when the dependencies change.

AppSignal Main Dashboard

Now that we have the application running with AppSignal installed, we can view the dashboard. To view all the applications and environments you have running on AppSignal, you can go to appsignal.com/accounts:

Click on the application name, and you can explore what AppSignal monitors out-of-the-box.

Within a few minutes, some data will already be collected because of your traffic generation script.

From the main dashboard, you can get a good high-level overview of a few essential application metrics. We're now going to dig into some of the more specific areas within AppSignal.

Errors Dashboard in AppSignal

On the errors page, you find a list of all errors reported
by your application. When we ran the install script, a test error was sent to AppSignal. You can see that we also have an error that seems to be occurring pretty regularly. Clicking on the error will open up a page with more details, which can be useful to debug the issue.

In this case, we can see from the backtrace section that on the homepage of the application (/) there is a validation error occurring on app/controllers/pages_controller.rb:7 home.

Other AppSignal Dashboards

Under 'Dashboard' in the sidebar, you can see that AppSignal has provided us with a few different dashboards already.

The 'Overview' dashboard is available for every application and provides:

Your application error rate
Throughput
Response times
Other recent activity that you can dig into for more details

You also have two magic dashboards — one for Active Job and another for Sidekiq. AppSignal has built-in integrations for many popular frameworks and gems that work automatically with your Rails application.

When viewing these dashboards, you can see information relevant to the activity of that integration. In the Active Job dashboard, you'll see graphs for the number of jobs in each queue, the recorded duration of each job, and more. Give it a look!

Performance of Your App

Inside of Performance → Issue list, you can view a list of actions that AppSignal measures. These measurements can provide some valuable insights into what parts of your application consume a lot of performance.

For example, by clicking into the issue for the action PostsController#index, we can dive deeper into the controller's performance. You can quickly see a breakdown of where the most time is spent, or the most object allocations happen.

Quick Wins and Hidden Gems from AppSignal: Using Puma

There are a few hidden gems (not the Ruby kind) that you can get from AppSignal without much effort. Let's see how easily we can get these up and running with an example.

Inside of config/puma.rb, add the following line:

# config/puma.rb
plugin :appsignal

Before we restart the application, add the following environment variable after line 12 in the docker-compose.yml:

# docker-compose.yml
APP_REVISION: "latest_version_tag"

Because we've updated the Puma server config and our docker-compose config, we will need to restart the docker containers with ctrl-c and start-up docker-compose again with yarn start:compose.

Tracking Your New Insights

After the server restarts, allow it to run for about a minute, then head back to the AppSignal dashboard and refresh the page. There are two main areas with new information now:

The first is the new automatically generated Puma metrics magic dashboard. Because of AppSignal's built-in integration with Puma, we now have information about the application server's activity. Specifying the plugin in the config file has activated a minutely probe that reports metrics about the Puma server.

Lastly, across the entire AppSignal dashboard, there are now deployment markers. You can set the APP_REVISION environment variable to any value that helps you determine the current version of your application, such as a git commit SHA.

You can also see a history of your deployments by viewing the 'Deploys' section in the AppSignal dashboard and filter insights (such as Errors/Performance issue lists) by deploy. View how performance or reliability has changed between deploys, making it a bit easier to dig into which changes could have introduced a new bug.

Next Up: Custom Instrumentation and Monitoring for Ruby Apps

This post has shown how you can set up and use AppSignal in your applications to help increase your code's visibility in the wild.

We've demonstrated how AppSignal automatically integrates into Rails and some of the application's dependencies, such as Sidekiq and Puma. AppSignal works with many more Ruby frameworks and gems out-of-the-box. You can find a complete list of AppSignal's Ruby integrations here.

Part 2 of this series will cover how to add custom instrumentation and monitoring to your Ruby on Rails application for deeper insights.

Until next time!

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!

Unathi Chonco is a Full-Stack Engineer at WeTransfer and Ruby on Rails contributor. He enjoys working across the Rails stack and sharing what he learns when solving day-to-day engineering challenges. You can find more content from Unathi on his blog or reach out via Twitter.

ActiveRecord Optimistic Locking

Unathi Chonco — Wed, 09 Jun 2021 18:53:24 +0000

ActiveRecord Optimistic Locking and Counter Caching

In this post, we will discuss optimistic locking and how it can help us when building applications. This guide is targeted at Ruby on Rails developers, but similar strategies can be applied in other frameworks.

What is Optimistic Locking

Optimistic locking is a strategy used to verify that a database record has not been changed since the last time you read/fetched it. Locking gives you some certainty that any updates you are making are based on the most recent version.

So how do we use this, and how could it help ?

TL;DR: A Quick Practical Guide

Documentation: https://api.rubyonrails.org/classes/ActiveRecord/Locking/Optimistic.html
Add lock_version column to your model
Include lock_version as hidden input in form
Handle ActiveRecord::StaleObjectError for when an update is attempted on an old version
Short example: https://gist.github.com/choncou/ed77efabdea92e38833839c974b35eee

The Longer Guide

Let's introduce our scenario.

We have a simple e-commerce application, with an assortment of products that are managed by different teams throughout the company. A common workflow in the company looks like this:

The Inventory team adds new a product to the system as soon as they've received the stock. While they quickly import a lot of products, they prefer to only fill in the name and description.
The Marketing team is notified of new products and starts working on better product descriptions, and setting the prices
The Inventory team goes through all the new stock they’ve added, and update the packaged weight of each product.

Problem

The marketing team has started reporting that sometimes their updates to products are lost a while after saving and confirming the new information. How could this happen?

After some digging, we find out that when the inventory team adds a new product, they keep a tab open with the edit page for each product. When they press save on those old tabs, it will replace any other information for the product with what is on their form. Here’s how it that looks in the application:

Our real problem is that we have no way of knowing if the information that somebody is submitting in the form contains outdated values which we don't actually want to override the existing data about a product.

The Solution

Optimistic locking was created to handle this kind of problem: allowing multiple users to access the same record for edits while assuming minimum conflict with the data.

Optimistic Locking achieves this by tracking a version number for a record. Every time that record is updated, the version number increases. If we try to update a record with a version number that doesn't match the current version in the database, Rails will throw an ActiveRecord::StaleObjectError exception.

To add this to our existing application we need to:

1) Add a lock_version integer column to our products table

By default, rails will use optimistic locking on your model when it finds the lock_version column. It is also possible to specify a custom locking column name for a specific model by setting self.locking_column = :my_custom_column (see documentation).

Our database schema now looks like this:

create_table "products", force: :cascade do |t|
  t.string "name"
  t.string "description"
  t.integer "weight_grams"
  t.integer "price_cents"
  t.datetime "created_at", null: false
  t.datetime "updated_at", null: false
  t.integer "lock_version"
end

2) Include lock_version in our form submission

In the view where we render the form, we want to include a hidden form field with the version

<%= form.hidden_field :lock_version %>

In our controller, we need to permit the version column so that it is included in the params used to update the product.

# Only allow a list of trusted parameters through.
def product_params
  params.require(:product).permit(:name, :description, :weight_grams, :price_cents, :lock_version)
end

—

This is all we need to prevent the updates from happening. Now we get an exception when we try to make an update with the outdated form.

Handling ActiveRecord::StaleObjectError

The application crashing because the form is outdated isn't a great user experience, so the least we can do is let the user know what went wrong.

This isn't a post about error handling, so we'll go with the simplest solution of catching this error in the controller right where we are making the update. Right now, this is what our controllers #update action looks like:

# PATCH/PUT /products/1 or /products/1.json
def update
  respond_to do |format|
    if @product.update(product_params)
      format.html { redirect_to @product, notice: "Product was successfully updated." }
      format.json { render :show, status: :ok, location: @product }
    else
      format.html { render :edit, status: :unprocessable_entity }
      format.json { render json: @product.errors, status: :unprocessable_entity }
    end
  end
end

We can add an error message to the product and display it in the view. Our controller would then include a rescue block to add the error to the product and display the edit page again.

# PATCH/PUT /products/1 or /products/1.json
def update
  respond_to do |format|
    if @product.update(product_params)
      format.html { redirect_to @product, notice: "Product was successfully updated." }
      format.json { render :show, status: :ok, location: @product }
    else
      format.html { render :edit, status: :unprocessable_entity }
      format.json { render json: @product.errors, status: :unprocessable_entity }
    end
  rescue ActiveRecord::StaleObjectError => _error
    @product.errors.add(:base, "Oops. Looks like the product has changed since you last opened it. Please refresh the page")
    format.html { render :edit, status: :unprocessable_entity }
    format.json { render json: @product.errors, status: :unprocessable_entity }
  end
end

Now when we submit an outdated form, we are shown a regular error message. In your application, you could provide more context on the page, by showing the user both the new and old information.

Conclusion

Using optimistic locking in rails can give us a lot of value out of the box, but it is important to note that this doesn't solve all cases that could look the same. Optimistic locking should be used when there isn't a high chance of conflicts and race conditions. If you really need to prevent other users from editing a record until the first user is done, you should consider pessimistic locking or implementing something similar in your application.

Find the example application and implementation from this post here on GitHub:

https://github.com/choncou/blog-post-optimistic-locking/pull/1

I hope this has given you some insight and inspiration into how you could use locking in your code.

🚀

Verifying JWTs with JWKS in Ruby

Unathi Chonco — Sun, 28 Mar 2021 06:11:14 +0000

In this post, we will discuss a few issues, and their solutions, when working with asymmetrically signed JWTs (JSON Web Tokens).

The post assumes you have a basic working knowledge of JWTs.

The Lowdown (Intro)

When working with JWTs (JSON Web Tokens), it is common to sign them using asymmetric encryption. Asymmetric encryption involves using a public/private key pair, where:

the issuer signs the JWT with the private key
the receiver verifies the JWT's origin & contents with the public key

This ability for a receiver to verify the JWT means that the receiver can trust the contents of the JWT, without the need to make an additional API call for that information.

A JWKS (JSON Web Key Set) is a representation of the cryptographic key pairs mentioned above. The JWKS contains the public keys that can be used to verify a JWT. The JWT would contain a claim(kid) that specifies which key was used to sign it. The issuer of the JWT provides the JWKS.

Working with a JWKS can introduce a few problems if not dealt with correctly. To discuss these problems, let us introduce an example use case as a starting point.

Use Case

Auth0 is a service that provides an authentication and authorization platform. We want to use Auth0 for our application's user authentication needs. Similar to a regular OAuth2 flow, we get the user to authenticate themselves off of our application (on Auth0), and once they return and we complete the flow, we receive an access token for the user. The access token is a JWT which we can use for making authenticated API calls to our application's backend.

Verification: How our backend authenticates a user

When the backend receives an API call it will:

confirm that a JWT is present
verify the JWT signature using the relevant public key
verify other claims in the JWT (expiry, scopes, etc)
use the contents of the JWT to identify the user and process the rest of the request

Auth0 provides a JWKS endpoint, at https://TENANT_DOMAIN/.well-known/jwks.json, which we will use in step #2 to fetch the public keys to verify the received.

In a Ruby application, steps 2 & 3 could look like this:

module Auth
  module VerifyJwt
    extend self

    JWKS_URL = "https://#{Rails.configuration.auth0[:auth_domain]}/.well-known/jwks.json".freeze

    def call(token, audience: :web)
      JWT.decode(
        token,
        nil,
        true, # Verify the signature of this token
        algorithms: ["RS256"],
        iss: "https://#{Rails.configuration.auth0[:auth_domain]}/",
        verify_iss: true,
        aud: Rails.configuration.auth0[:web_audience],
        verify_aud: true,
        jwks: fetch_jwks,
      )
    end

    private

    def fetch_jwks
      response = HTTP.get(JWKS_URL)
      if response.code == 200
        JSON.parse(response.body.to_s)
      end
    end
  end
end

With the above, we have a working solution. But we have also introduced a few potentials problems that are worth resolving before deploying the application to production.

The Problems

Problem 1: External API call on every request

For every authenticated request that comes into our application, we will also be making an API call to the /jwks.json endpoint. This introduces a few concerns:

there is additional overhead on every request, increasing the response time
a spike in traffic, or an attack, can result in rate limits being crossed and all our authentication processes being unavailable for a period of time

Solution: Caching

External calls like the /jwks.json endpoint are a perfect opportunity for caching. The key pair used for signing our JWTs won't change unless they are rotated.

In code, we would:

cache the response of the API call
return the cached value, if it exists, for future calls

module Auth
  module VerifyJwt
    extend self
    JWKS_CACHE_KEY = "auth/jwks-json".freeze
    ...

    def call(token)
      JWT.decode(
        ...
        jwks: jwks,
      )
    end

    private

    def fetch_jwks
      ...
    end

    def jwks
      Rails.cache.fetch(JWKS_CACHE_KEY) do
        fetch_jwks
      end.deep_symbolize_keys
    end
  end
end

Problem 2: Delayed Cache invalidation for rotated keys

The solution to Problem 1 introduces a new issue.

What happens when our key pairs are rotated? Leaked private keys, routine security processes, or other circumstances, are possible reasons for key rotation. Rotating key pairs means that all new JWTs will be signed by those new keys.

After a key rotation, our application will always fail to verify new JWTS because our cache would still be returning the previous JWKS.

Solution: Cache Invalidation

We can solve this issue by fetching from the /jwks.json endpoint again if we recognise a JWT that was signed by a different key than those we know about. We can identify this by:

extracting the kid from the JWT header
looking for a key, in the keys of the JWKS, with the matching kid
fetching the JWKS again (not from cache), if no key is found

Fortunately, the ruby JWT gem has done the heavy lifting. When we pass through a function, instead of the raw JWKS, the library will call that function with options if it expects us to try to return a new set of JWKS. (gem implementation)

module Auth
  module VerifyJwt
    extend self
        ...

    def call(token)
      JWT.decode(
        ...
        jwks: jwk_loader,
      )
    end

    private

    def jwk_loader
      ->(options) do
        # options[:invalidate] will be `true` if a matching `kid` was not found
        # https://github.com/jwt/ruby-jwt/blob/master/lib/jwt/jwk/key_finder.rb#L31
        jwks(force: options[:invalidate])
      end
    end

    def fetch_jwks
      ...
    end

    def jwks(force: false)
      Rails.cache.fetch(JWKS_CACHE_KEY, force: force) do
        fetch_jwks
      end.deep_symbolize_keys
    end
  end
end

Problem 3: Attacker-triggered cache invalidation

The current solution to Problem 2 reintroduces Problem 1. An attacker could flood our API with calls using a random invalid JWT that will always fail verification.

Because the invalid JWT would have a different kid, we would invalidate our cache every time, forcing us to do an API call.

In theory, this could be acceptable because we are fetching the latest JWKS. But if the call to the .../jwks.json endpoint fails, maybe due to rate-limiting, we won't have a value to cache and could be caching nil. This will mean that verifying any JWTs will not be possible until our application can get a successful response from the .../jwks.json endpoint again.

Solution: Ignore nil for cache invalidation

Our #fetch_jwks method only returns the JSON response if the request was successful, and nil otherwise. Meaning we can cater for any failed response by leaving the current value in the cache, so we always have the latest successful response we've received.

The Rails cache store already provides a simple helper for this use case. We need to add skip_nil: true to our fetch

module Auth
  module VerifyJwt
    extend self
        ...

    def jwk_loader
      ->(options) do
        jwks(force: options[:invalidate]) || {}
      end
    end

    def jwks(force: false)
      Rails.cache.fetch(JWKS_CACHE_KEY, force: force, skip_nil: true) do
        fetch_jwks
      end&.deep_symbolize_keys
    end
  end
end

We also handle the possibility of receiving nil by defaulting to an empty hash ({}), because the JWT gem expects a hash and not nil.

Conclusion

Looking back, we now know how to protect our application from basic performance and security concerns. We have:

implemented caching of the JWKS required for verifying JWTs
accounted for the possibility of keys being rotated
protected our application from an attacker disrupting functionality for all users

This is final code for our JWT verification implementation here:

This is not an exhaustive reference to all security-related concerns that you could encounter when working with JWTs, but I hope you find it helpful as a good starting point to get up and running.

🚀

TIL: HTML elements, what are they `for`?

Unathi Chonco — Mon, 06 Jul 2020 18:54:50 +0000

TIL: HTML <label> elements, what are they `for`?

Today I learnt that <label> elements aren’t just semantic html tags used to make your code a bit more understandable, or “well structured”.

Besides just representing the caption for a specific piece of your interface, labels can give you a few benefits when used correctly to associate the label with an input (or any other labelable element).

There are 2 methods of associating a label to an input

1. Using the `for` attribute

To get this working you need to:

give the <input> an id attribute
give the <label> a for attribute that is the same value as the input’s id

<div class="form__group">
  <input class="form__input" type="text" id="name">
  <label class="form__label" for="name">Full name</label>
</div>

2. Having a contained control element

All this requires is placing the input inside of the label, and it will be associated implicitly.

<div class="form__group">
  <label class="form__label">
    <input class="form__input" type="text">
    Full name
  </label>
</div>

Benefits

Accessibility

Assistive tech, such as screen readers, will be able to read out the label when the user is focused on the input. This is a small use-case, but accessibility is always important. A small win that could go a long way.

User Experience

A user, on desktop or mobile, can click on either the input or the label to focus/activate the specific input.

TL;DR and Examples

Labels can be used to activate/focus on an associated input.

Opinionated Tips for Maintainable Rails Applications?

Unathi Chonco — Thu, 02 Jul 2020 06:07:43 +0000

What opinionated tips do you have when it comes to creating maintainable web applications?

Just over a year ago I wrote a post on medium which covered the following 5 core points.

Creating & maintaining a living style guide
Enforcing consistency in stylesheets
Keeping your models skinny
Keeping your controllers skinny
Keeping your JavaScript simple

The full post for a deeper look into each point:

5 Opinionated Tips for Creating a Maintainable Rails Application | by Unathi Chonco | Medium

Unathi Chonco ・ Mar 13, 2019 ・
Medium

I would like to hear from other experienced web developers on maintainability tips that they think are evergreen.

DEV Community: Unathi Chonco

Ruby Method Lookup Demystified: Inheritance, Mixins, and Super

Inheritance and Method Lookup in Ruby

Mixins and Method Lookup

Include

Prepend

Extend

The super Method

The super Method with Mixins

Conclusion

Ruby Bang (!) Methods

What are Bang Methods?

Mutating bang methods

Example 1: String#upcase and String#upcase!

Example 2: Array#sort and Array#sort!

Example 3: Array#uniq and Array#uniq!

Error-raising bang methods

Example 1: ActiveRecord::Base#save and ActiveRecord::Base#save!

Example 2: ActiveRecord::Base#create and ActiveRecord::Base#create!

Example 3: ActiveRecord::Base#update and ActiveRecord::Base#update!

Example 4: ActiveRecord::Base#destroy and ActiveRecord::Base#destroy!

Conclusion

Next Level Ruby on Rails Application Monitoring with AppSignal

Custom Instrumentation and Monitoring

Instrumenting Parts of the Code

Insights

Exception Handling

Insights

Metrics

Insights

Wrap-up: Custom Instrumentation and Monitoring for Ruby Apps with AppSignal

Ruby on Rails Application Monitoring with AppSignal

Setting up AppSignal

About Our Sample Application

Getting Started with AppSignal

AppSignal Main Dashboard

Errors Dashboard in AppSignal

Other AppSignal Dashboards

Performance of Your App

Quick Wins and Hidden Gems from AppSignal: Using Puma

Tracking Your New Insights

Next Up: Custom Instrumentation and Monitoring for Ruby Apps

ActiveRecord Optimistic Locking

ActiveRecord Optimistic Locking and Counter Caching

What is Optimistic Locking

TL;DR: A Quick Practical Guide

The Longer Guide

Problem

The Solution

Handling ActiveRecord::StaleObjectError

Conclusion

Verifying JWTs with JWKS in Ruby

The Lowdown (Intro)

Use Case

Verification: How our backend authenticates a user

The Problems

Problem 1: External API call on every request

Problem 2: Delayed Cache invalidation for rotated keys

Problem 3: Attacker-triggered cache invalidation

Conclusion

TIL: HTML elements, what are they `for`?

TIL: HTML <label> elements, what are they for?

1. Using the for attribute

2. Having a contained control element

Benefits

Accessibility

User Experience

TL;DR and Examples

Opinionated Tips for Maintainable Rails Applications?

5 Opinionated Tips for Creating a Maintainable Rails Application | by Unathi Chonco | Medium

Unathi Chonco ・ Mar 13, 2019 ・ Medium

The `super` Method

The `super` Method with Mixins

TIL: HTML <label> elements, what are they `for`?

1. Using the `for` attribute

Unathi Chonco ・ Mar 13, 2019 ・
Medium