Forem: Ahmed Nadar

Normalization in Rails 7.1 era

Ahmed Nadar — Tue, 21 May 2024 14:00:00 +0000

Before Rails 7.1

Once upon a time, way long before the Rails 7.1 era, a smart Rails developer (like yourself) needed to ensure user email addresses were properly normalized (sanitized and formatted correctly). Back then, they used clever techniques such as callbacks like before_save and before_validation, attribute setters, or even the normalize gem to get the job done. Here are some of those old tricks and tips on how they used to do it.

# normalize with before_save callback
class User < ApplicationRecord
  before_save :sanitize_email

  private

  def sanitize_email
    self.email = email.strip.downcase
  end
end

# normalize with before_validation callback
class User < ApplicationRecord
  before_validation :sanitize_email

  private

  def sanitize_email
    self.email = email.strip.downcase
  end
end

# override the setter from ActiveRecord
class User < ApplicationRecord
  def email=(value)
    super(value.strip.downcase)
  end
end

# Don't like callbacks? Use the normalize gem in `app/normalizers`
class EmailNormalizer
  def self.call(email)
    email.strip.downcase
  end
end

class User < ApplicationRecord
  normalize :email, with: EmailNormalizer
end

After Rails 7.1

As time passed, the Rails community reached the Rails 7.1 era. A group of those smart Rails developers (maybe it's you) gathered around the Rails core team and agreed on a better way to normalize attributes. They came up with a nifty idea.

Imagine having a ClassMethod normalizes that comes with a set of rules, such as converting all email addresses to lowercase, removing leading/trailing whitespace, or enforcing a specific format before they are saved to the database. This "Normalization" class reduces data redundancy and minimizes inconsistencies. Also, it organizes data in a structured and consistent way, making it easier to query, update, and maintain.

The Rails core team wanted to make it easy for today's and future Rails developers by providing a simple API for model attributes. All developers need to do is pass the attribute's name. Here is how they demonstrated their solution. Pow 💥

class User < ActiveRecord::Base
  normalizes :email, with: -> email { email.strip.downcase }
  normalizes :phone, with: -> phone { phone.delete("^0-9").delete_prefix("1") }
end

user = User.create(email: " CRUISE-CONTROL@EXAMPLE.COM\n")
user.email                  # => "cruise-control@example.com"

user = User.find_by(email: "\tCRUISE-CONTROL@EXAMPLE.COM ")
user.email                  # => "cruise-control@example.com"
user.email_before_type_cast # => "cruise-control@example.com"

User.where(email: "\tCRUISE-CONTROL@EXAMPLE.COM ").count         # => 1
User.where(["email = ?", "\tCRUISE-CONTROL@EXAMPLE.COM "]).count # => 0

User.exists?(email: "\tCRUISE-CONTROL@EXAMPLE.COM ")         # => true
User.exists?(["email = ?", "\tCRUISE-CONTROL@EXAMPLE.COM "]) # => false

User.normalize_value_for(:phone, "+1 (555) 867-5309") # => "5558675309"

And Rails developers live happily ever after Rails 7.1 period.
The end.

Refactoring Rails Helpers from static to dynamic rendering

Ahmed Nadar — Tue, 12 Mar 2024 13:00:00 +0000

Writing code is a journey of continuous improvement, learning, adaptation, and, yes, refactoring. As our applications grow and evolve, we often find ourselves revisiting and rethinking our code to make it more maintainable, scalable, and flexible.

Today, I want to share with you the process of refactoring a helper in a Rails application to dynamically render components. This adventure is filled with twists, turns, and a sprinkle of humour.

When I was explaining this refactoring process to a friend, I realized that it had all the elements of a classic fairy 🧚🏼 tale: a humble beginning, a villain to overcome, a twist in the plot, and a happy ending. So, today I'm trying a new style of writing, a fairy tale, to make it more engaging and fun. So, let's dive in.

Chapter One: In the land of static helpers

My story begins with a humble helper, RapidRailsUI::ViewHelper, designed to render components in a Rails application. Like any good story, I start small and simple. Here's how it looked initially:

module RapidRailsUI
  module ViewHelper
    RAPIDRAILSUI_COMPONENTS = {
      button: "RapidRailsUI::HeadlessButton",
      icon: "RapidRailsUI::IconComponent"
      # Add more components as needed
    }.freeze

    RAPIDRAILSUI_COMPONENTS.each do |name, component|
      define_method :"rui_#{name}" do |*args, **kwargs, &block|
        render component.constantize.new(*args, **kwargs), &block
      end
    end
  end
end

This helper served its purpose well 👌🏽, it create a component name such as rui_buddon but as the application grew, so did the number of components. And with each new component, I found myself updating the RAPIDRAILSUI_COMPONENTS hash. It quickly became apparent that this wasn't the most scalable solution

Chapter Two: A small step for a developer, a giant leap for helper kind

To make the helper more dynamic and easier to maintain, I started with a small change. Instead of hardcoding the component names and classes in the RAPIDRAILSUI_COMPONENTS hash, I used a symbol array to store the component names. This way, adding new components became a breeze:

module RapidRailsUI
  module ViewHelper
    RAPIDRAILSUI_COMPONENTS = %i[button icon].freeze

    RAPIDRAILSUI_COMPONENTS.each do |name|
      define_method :"rui_#{name}" do |*args, **kwargs, &block|
        component_class = "RapidRailsUI::#{name.to_s.classify}Component".constantize
        render component_class.new(*args, **kwargs), &block
      end
    end
  end
end

However, this approach still had its limitations. The RAPIDRAILSUI_COMPONENTS array still required manual updates for each new component. I needed a more dynamic and flexible solution.

Chapter Three: The mystery of the missing dynamism

To address the scalability issue, I embarked on a journey to refactor the view helper to dynamically resolve component names based on the method called. This way, there would be no need to update the helper every time a new component was added. Here's the first iteration of the refactored helper:

module RapidRailsUI
  module ViewHelper
    def method_missing(method_name, *args, **kwargs, &block)
      if method_name.to_s.start_with?("rui_")
        component_name = method_name.to_s.sub("rui_", "").classify
        component_class = "RapidRailsUI::#{component_name}Component".safe_constantize
        if component_class
          return render component_class.new(*args, **kwargs), &block
        end
      end

      super
    end

    def respond_to_missing?(method_name, include_private = false)
      method_name.to_s.start_with?("rui_") || super
    end
  end
end

With this refactor, the ViewHelper became more dynamic and easier to maintain. However, every fairy tale has its villain, and ours was about to make an appearance.

Chapter Four: The case of the uncooperative classify

As I happily refactored the components, I faced an unexpected issue with TabsComponent. The method rui_tabs was resolving to RapidRailsUI::TabComponent instead of RapidRailsUI::TabsComponent. It turns out that Rails' classify method, designed for singularizing model names, was not playing nice with the component names.

To defeat this villain, I introduced a special case in the view helper to handle the pluralization of component names that don't follow the standard Rails convention:

module RapidRailsUI
  module ViewHelper
    SPECIAL_PLURALIZATIONS = {
      'tabs' => 'Tabs'
    }.freeze

    def method_missing(method_name, *args, **kwargs, &block)
      if method_name.to_s.start_with?("rui_")
        component_name = method_name.to_s.sub("rui_", "")
        component_name = SPECIAL_PLURALIZATIONS[component_name] || component_name.classify
        component_class = "RapidRailsUI::#{component_name}Component".safe_constantize

        if component_class
          return render component_class.new(*args, **kwargs), &block
        end
      end

      super
    end

    def respond_to_missing?(method_name, include_private = false)
      method_name.to_s.start_with?("rui_") || super
    end
  end
end

With this final tweak, ViewHelper became both dynamic and accommodating to the special cases. I could now add new components without worrying about updating the helper or dealing with naming conventions.

Epilogue: the dawn of a new era in helper land

In the end, the refactoring journey led me to a view helper that was scalable, flexible, and a joy to work with. I no longer had to manually update the helper for each new component, and I could easily handle exceptions to naming conventions.

So, I hope this tale of refactoring has inspired you to embrace the dynamic nature of Ruby and Rails. By leveraging the power of metaprogramming, you can create helpers that are more maintainable, scalable, and delightful to work with.
And they all coded happily ever after. The end.

Key Methods Explained

In this refactoring journey, I've used several Ruby and Rails methods to achieve a dynamic and scalable view helper. Let's dive into the details of these key methods:

classify

What it does: Converts a string to a class name. For example, "button".classify becomes "Button".
Why it's used: In the refactor, I used classify to dynamically convert component names from strings to class names.
Further reading: ActiveSupport::Inflector#classify

safe_constantize

What it does: Tries to find a constant with the name specified in the string. If the constant doesn't exist, it returns nil instead of raising a NameError.
Why it's used: I used safe_constantize to safely resolve component class names without risking a crash if the class doesn't exist.
Further reading: ActiveSupport::Inflector#safe_constantize

method_missing

What it does: Called when a method is invoked on an object but is not defined for that object. It's a powerful tool for metaprogramming.
Why it's used: I leveraged method_missing to dynamically handle method calls for rendering components based on their names starts with rui_.
Further reading: Ruby's method_missing documentation

respond_to_missing?

What it does: Used in conjunction with method_missing to ensure that Ruby's respond_to? method works correctly for dynamically handled methods.
Why it's used: I implemented respond_to_missing? to accurately report whether the view helper can respond to dynamically generated methods.
Further reading: Ruby's respond_to_missing? documentation

By understanding these methods, you can harness the power of Ruby and Rails to create more dynamic and flexible code.

Conclusion

Refactoring view helpers in Rails can be a rewarding adventure. By embracing the dynamic nature of Ruby and Rails, you can transform your helpers into powerful, scalable tools that make your codebase more maintainable and your development experience more enjoyable.

So, the next time you find yourself staring at a helper that needs a little love, remember this tale of refactoring and embark on your own journey of improvement. Your codebase will thank you, and you'll emerge as the hero of your own story.

Happy coding, and may your helpers be ever dynamic and delightful! 🚀

Simplifying Polymorphic Associations with Rails ActiveRecord::DelegatedType

Ahmed Nadar — Thu, 11 Jan 2024 17:07:45 +0000

Hey Rails dev! Ever struggled with handling different types of data in your Rails applications? Well, ActiveRecord::DelegatedType is here to make your life easier. In this guide, I'll walk through how you can use DelegatedType to manage diverse data relationships in a more organized way. It's like having a neat filing system for your database tables. So, let's dive in and explore how DelegatedType can help you keep your Rails projects well-structured and easy to maintain.

What!

Let's introduce ActiveRecord's DelegatedType.

It is a Rails pattern for managing polymorphic associations in a more structured and efficient way. Think of it as a way to store a superclass that can be subclassed using delegation instead of inheritance. It's like having a Swiss Army knife in your Rails ActiveRecord toolkit!

When to use `DelegatedType`?

Leverage DelegatedType when you need to:

Manage objects sharing common features and behaviours but requiring distinct handling.
Simplify complex relationships under a unified interface.

How: the core idea

At its core, DelegatedType simplifies the handling of models that can represent multiple types of related data without the complexity of Single Table Inheritance (STI).

For example, In a blog application with posts, comments, and authors, ActiveRecord::DelegatedType is very handy when you want to have a single model that can represent different types of related data.

Why, embrace `DelegatedType`?

Here’s why DelegatedType can be your best friend:

Simplifies Polymorphic Relationships: Manages different types of data under a unified interface.
Avoids STI Drawbacks: Prevents cluttering a single table with columns relevant to only specific types.
Enhances Code Readability: Clear separation of concerns, making it easier to understand and maintain.

Example scenario, Blog application

Consider a blog application with posts, comments, and authors, where posts and comments share common features but also have unique attributes.

Step-by-Step Implementation

1. Define a Common Interface

Create a module, say Publishable, to encapsulate shared logic and behaviour.

# app/models/concerns/publishable.rb
module Publishable
  extend ActiveSupport::Concern

  included do
    has_one :publication, as: :publishable, touch: true
    # Other shared logic...
  end
end

2. Create a Superclass Model

Define a Publication model to act as a superclass using delegated_type.

# app/models/publication.rb
class Publication < ApplicationRecord
  delegated_type :publishable, types: %w[ Post Comment ]

  belongs_to :author
  # Common logic like publication date and author references
end

3. Define Subclasses

Implement Post and Comment models, including the Publishable module.

class Post < ApplicationRecord
  include Publishable
  # Attributes specific to posts
end

class Comment < ApplicationRecord
  include Publishable
  # Attributes specific to comments
end

4. Handling Records

Create Publications that are either Posts or Comments.

# Creating a new post
Publication.create!(publishable: Post.new(title: 'My First Post'), author: some_author)

# Creating a new comment
Publication.create!(publishable: Comment.new(content: 'Great post!'), author: another_author)

Or generate seed data.

Advanced Use Cases

Nested Attributes

You can use nested attributes to handle form submissions for both posts and comments through the Publication model.

class Publication < ApplicationRecord
  accepts_nested_attributes_for :publishable
  # ...
end

Delegating Methods

Delegating methods to the subclasses can streamline accessing subclass-specific attributes.

class Publication < ApplicationRecord
    # Delegating a method (e.g., title for Post, content for Comment) to the publishable object
    delegate :title, :content, to: :publishable, allow_nil: true
end

Querying

Querying is straightforward; you can fetch either all publications, just posts, or just comments.

# Fetch all publications
publications = Publication.all

# Fetch all posts
posts = Publication.posts

# Fetch all comments
comments = Publication.comments

📋 Conclusion

As we have seen ActiveRecord::DelegatedType offers a robust and flexible way to handle polymorphic associations. You can effectively implement and leverage this pattern, enhancing the structure and maintainability of your Rails applications.

💻 Demo repo

Now, curious to see ActiveRecord::DelegatedType in action? I've created a demo Rails app that showcases the usage of DelegatedType for managing polymorphic associations, along with advanced use cases. In addition, the app includes views to demonstrate the display of all posts and publications, making it a handy tool for app admins who need to oversee various data objects at once. You can check out the demo and explore the code on GitHub. It's a great way to get a hands-on understanding of how DelegatedType can streamline your data management tasks.

📚 Further Learning

For more in-depth examples and advanced use cases, check Rails DelegatedType API documentation.

Composing '99 Bottles of Beer' with Ruby's OOP Harmony'

Ahmed Nadar — Tue, 07 Nov 2023 20:27:57 +0000

🌟 Introduction

Welcome back 😀! In a previous post, I tackled the classic "99 Bottles of Beer" problem using a procedural approach, leveraging Ruby's case expression to create a straightforward solution. Today, I revisit this catchy tune with a fresh perspective: Object-Oriented Programming (OOP). Thanks to insights from Sandi Metz, Katrina Owen, and my friend Koichi.

🤖 Understanding Object-Oriented Programming in Our Digital Narrative

As we prepare to revisit the classic '99 Bottles of Beer' with an object-oriented approach, it's essential to grasp the fundamental concepts of Object-Oriented Programming (OOP) that we'll be employing:

-Encapsulation: This is about bundling data with the methods that operate on it, encapsulating behaviour with the data it manipulates.

Inheritance: A mechanism for creating new classes from existing ones, this enhances code reusability and establishes a natural hierarchy.
Polymorphism: It allows entities to take on more than one form, enabling a single function to handle different types of objects.
Abstraction: By hiding the complex reality behind simpler interfaces, we expose only the necessary components, making our code more approachable and easier to understand.

Embracing these principles doesn't merely organize our code; it's akin to composing a digital story where each object plays a part, modelled after real-world behaviours and interactions. In the context of our '99 Bottles of Beer' rendition, we're not just coding – we're crafting a symphony of objects that each carry their tune, harmonizing to create a cohesive and scalable application.

🎼 The SOLID Principles Concerto

In OOP, SOLID principles guide our design towards harmony:

Single Responsibility Principle (SRP) - A class should have one, and only one, reason to change.
Open/Closed Principle (OCP) - Classes should be open for extension but closed for modification.
Liskov Substitution Principle (LSP) - Subtypes must be substitutable for their base types.
Interface Segregation Principle (ISP) - No client should be forced to depend on methods it does not use.
Dependency Inversion Principle (DIP) - Depend on abstractions, not on concretions.

Let's see how these principles are integrated into our '99 Bottles' code.

🛠️ Step-by-Step OOP Solution

Act I: Crafting the Bottle Class with SRP

First, we encapsulate the idea of a bottle into its own class, which knows how to represent itself and its actions. In this Bottle class, we have defined methods to represent the bottle textually (to_s), the action to take (action), and to get the next bottle object (next). The attr_reader provides a way to read the quantity attribute outside the class. Create bottle.rb file.

# This file contains the Bottle class which represents a bottle in the song.

class Bottle
    attr_reader :quantity

    def initialize(quantity)
        @quantity = quantity
    end

    # Define a method to represent the bottle count in a verse.
    def to_s
        case quantity
        when 0
        "no more bottles"
        when 1
        "1 bottle"
        else
        "#{quantity} bottles"
        end
    end

    # Method to print the action part of the verse.
    def action
        if quantity.positive?
        "Take one down and pass it around"
        else
        "Go to the store and buy some more"
        end
    end

    # Method to get the next bottle object.
    def next
        Bottle.new(quantity.positive? ? quantity - 1 : 99)
    end
end

Why OOP? Encapsulation ensures the bottle's behaviour is closely tied to its data.

Act II: Building the BeerWall Class and OCP

Now, let's construct our wall. The BeerWall class interacts with bottle objects in a high-level way. We don't need to know how each bottle composes its verse; we only need to know that it can do so. The sing method prints all the verses of the song by iterating over each bottle and printing its verse. The verse method is a clear application of SRP as it has a single responsibility: to return the verse text for a given number of bottles. The print_verse method supports these principles internally, ensuring that the public interface remains unchanged while the class's internal workings can evolve as needed. Create beer_wall.rb file.

# This class is responsible for printing the entire song.
require_relative "bottle"

class BeerWall
    def initialize(bottles)
        @bottles = bottles
    end

    # Prints a single verse for a given bottle.
    def verse(number)
        bottle = Bottle.new(number)
        "#{bottle} of beer on the wall, #{bottle} of beer.\n" \
        "#{bottle.action}, #{bottle.next} of beer on the wall.\n"
    end

    # Prints the entire song.
    def sing
        @bottles.downto(0) { |i| print_verse(Bottle.new(i)) }
    end

    private

    # Prints a single verse for a given bottle.
    def print_verse(bottle)
        puts "#{bottle} of beer on the wall, #{bottle} of beer."
        puts "#{bottle.action}, #{bottle.next} of beer on the wall.\n\n"
    end
end

Why OOP? The BeerWall class showcases abstraction by allowing us to interact with bottle objects in a high-level way.

While it is optionally, a driver script or a file that uses these classes to perform the desired actions. Create ruby_sing.rb file.

require_relative "beer_wall"

BeerWall.new(99).sing

Run ruby ruby_sing.rb to see the desired output.

Act III: Respecting LSP with Inheritance

Imagine we introduce a BottleVariant class for a special kind of bottle. This class would inherit from Bottle, and thanks to LSP, we can substitute Bottle with BottleVariant in our program without issues.

    class BottleVariant < Bottle   
        # Specialized implementation... 
    end

Act IV: ISP and the Art of Interfaces

Our classes use simple, clear interfaces. Each method does one thing and is used by the clients of the class. This adherence to ISP ensures that we don't have unnecessary dependencies in our classes.

Act V: Embracing DIP with Abstractions

Finally, our BeerWall class depends on an abstraction (Bottle) and not on a concrete class. This is a simple form of DIP and allows us to change the underlying class (Bottle) without affecting BeerWall.

🧪 The Testing Suite

No OOP discussion is complete without testing. We'll demonstrate how to write simple tests for our classes using MiniTest, a testing suite included with Ruby by default. Create 99_bottels_oop_test.rbfile.

require 'minitest/autorun'
require_relative '99_bottels_oop'

class BottleNumberTest < Minitest::Test

    def setup
        @beer_wall = BeerWall.new(99)
    end

    def test_the_first_verse
        expected = "99 bottles of beer on the wall, 99 bottles of beer.\n" \
        "Take one down and pass it around, 98 bottles of beer on the wall.\n"
        assert_equal expected, @beer_wall.verse(99)
    end

    def test_another_verse
        expected = "89 bottles of beer on the wall, 89 bottles of beer.\n" \
        "Take one down and pass it around, 88 bottles of beer on the wall.\n"
        assert_equal expected, @beer_wall.verse(89)
    end

    def test_verse_2
        expected = "2 bottles of beer on the wall, 2 bottles of beer.\n" \
        "Take one down and pass it around, 1 bottle of beer on the wall.\n"
        assert_equal expected, @beer_wall.verse(2)
    end

    def test_verse_1
        expected = "1 bottle of beer on the wall, 1 bottle of beer.\n" \
        "Take one down and pass it around, no more bottles of beer on the wall.\n"
        assert_equal expected, @beer_wall.verse(1)
    end

    def test_verse_0
        expected = "no more bottles of beer on the wall, no more bottles of beer.\n" 
        "Go to the store and buy some more, 99 bottles of beer on the wall.\n"
        assert_equal expected, @beer_wall.verse(0)
    end
end

Rub ruby 99_bottels_oop_test.rb

Why OOP? Testing is a fundamental part of OOP, ensuring each object behaves as expected.

🔄 Comparison with Procedural Approach

Let's compare this OOP solution with the procedural approach from the previous article.

In the procedural approach, we wrote a script where the logic flowed in a straight line. Functions were called in sequence, and the data was passed around from one function to another. This approach is straightforward to understand when the problem is simple. It's like following a recipe: each step is laid out, and you move from one to the next in order.

Pros of the Procedural Approach:

Simplicity: For small scripts or simple problems, procedural code can be more straightforward to write and understand.
Performance: Sometimes, procedural code can be faster because it involves less abstraction and fewer method calls.

Cons of the Procedural Approach:

Scalability: As the complexity of the problem grows, procedural code can become harder to maintain and understand.
Reusability: It's often more challenging to reuse parts of procedural code in other programs without modification.

On the other hand, the OOP approach encapsulates data and behaviour into objects. This mirrors real-world entities and allows for more complex interactions. Objects know how to manage their state and behaviour, leading to code that is more modular and easier to extend.

Pros of the OOP Approach:

Modularity: Objects can be easily reused across different parts of the program or even in different programs.
Maintainability: OOP makes it easier to keep the codebase organized and to manage complexity, especially as the project grows.
Flexibility: Through inheritance and polymorphism, new functionality can be introduced with minimal changes to existing code.

Cons of the OOP Approach:

Complexity: The additional layers of abstraction in OOP can make it more difficult to understand for beginners.
Performance Overhead: Object creation and method calls can introduce performance overhead.

🧩 Conclusion and share

Through this exploration of the "99 Bottles of Beer" problem, we've delved deep into the nuances of Object-Oriented Programming. By shifting our perspective from procedural to OOP, we've transformed a straightforward script into a well-orchestrated ensemble of objects, each playing its part in harmony.

This journey has been as much about learning and applying OOP principles as it has been about inviting collaboration and sharing. In the previous post, I shared my GitHub repository with the solution that employed a procedural approach. Now, I encourage you to visit the repository again to see the OOP solution in action.

I'm eager to hear your thoughts on the approaches we've discussed. Which do you lean towards in your own practice—procedural or OOP—and why? Your insights and diverse solutions enrich the conversation and contribute to a broader understanding of problem-solving in programming.

📚 Further Resources

For those looking to deepen their understanding of OOP in Ruby, here are some resources to get you started:

Sandi Metz's "99 Bottles of OOP" - A deeper dive into OOP using our beloved beer song.
Practical Object-Oriented Design in Ruby - Sandi Metz's guide to OOP principles in Ruby.

Until next time, Happy Coding 😀💎💻

A Ruby Serenade for 99 Bottles of Beer

Ahmed Nadar — Fri, 03 Nov 2023 18:12:36 +0000

Hello, budding Ruby enthusiasts! 🌟

Have you ever heard of the song 99 Bottles of Beer on The Wall? It's the kind of catchy tune that’s perfect for passing time with friends or family as you cruise down the vast stretches of highways in the US or Canada. With its repetitive melody and simple lyrics, it sticks in your head whether you want it to or not.

I first stumbled upon a quirky connection between this earworm and coding a few years back, thanks to Sandi Metz's enlightening talk at a Ruby conference. Sandi, a maestro of clean, maintainable OOP designs, has a knack for spinning traditional teaching methods on their head. Her approach is as refreshing as a cold brew on a hot day, and if you're a programmer aiming to sharpen your skills, her videos—courtesy of the splendid folks at Confreaks—are a treasure trove.

Sandi's fondness for the "99 Bottles" ditty isn't just for kicks; she's leveraged its repetitive charm to unravel the intricacies of OOP (Object-Oriented Programming). And yes, she's even authored a book, aptly titled 99 Bottles of OOP, which I'm thoroughly enjoying and heartily endorse.

Today's session isn't about vocal ranges or hitting the perfect pitch, although I'm sure you have a lovely voice and I'd not stop your karaoke party 🎙️. Instead, we're diving into a melody that echoes through the halls of coding exercises: "99 Bottles of Beer." This classic tune is a programming pilgrimage, and for Ruby enthusiasts, it's a delightful way to tinker with loops, conditionals, and OOP concepts. By the end of this post, you'll have a new party trick to show off at your next developer meetup.

🎯 The Goal

Imagine a wall lined with 99 bottles of beer. The song counts down each bottle as it's "taken down and passed around," until there are none left, then it's time to buy some more. Our mission, should we choose to accept it, is to write a Ruby script that sings this song from start to finish.

🛠️ Prerequisites

Before we start crooning in code, make sure you have:

A sprinkle of Ruby syntax knowledge.
Ruby, gleaming and ready on your machine.
A text editor, like VS Code, Atom, or even Notepad.

Got everything? Superb! Let's get coding!

Step 1: Comprehending the Composition

Our song has a repetitive structure, perfect for a loop. But, there's a twist! When we reach 1 bottle, we can't say "bottles" anymore—English is picky like that. And when there are no more bottles, the song changes its tune. Check out part of the lyrics below, and pay attention to the last three sections.

99 bottles of beer on the wall, 99 bottles of beer. Take one down and pass it around, 98 bottles of beer on the wall.

98 bottles of beer on the wall, 98 bottles of beer. Take one down and pass it around, 97 bottles of beer on the wall.

... ... ... ... ...

2 bottles of beer on the wall, 2 bottles of beer. Take one down and pass it around, 1 bottle of beer on the wall.

1 bottle of beer on the wall, 1 bottle of beer. Take one down and pass it around, no more bottles of beer on the wall.

No more bottles of beer on the wall, no more bottles of beer. Go to the store and buy some more, 99 bottles of beer on the wall.

Step 2: Setting the Stage

Create a new file named ninety_nine_bottles.rb. This will be our stage for the performance. To run it, we'll use the command line charm:

ruby ninety_nine_bottles.rb

Ready for the spotlight? Let's go!

Step 3: The Loop of Lyrics

Ruby has a beautiful way to count down with downto. It's like a staircase from 99 to 0:

99.downto(0) do |i|
  # This is where the magic happens...
end

Inside this loop, we'll call forth our verses.

Step 4: A Methodical Melody

Singular and plural bottles need different words. Let's tune our method to handle that:

def print_bottle(number)
  case number
  when 0  
      "no more bottles"
  when 1 
      "1 bottle"
  else
      "#{number} bottles"
  end
end

This method serenades us with the right words for each number.

Step 5: Verses in Verse

Now, the print_verse method will print each verse based on the number of bottles:

def print_verse(number)
  if number.positive?
    puts "#{print_bottle(number)} of beer on the wall, #{print_bottle(number)} of beer."
    puts "Take one down and pass it around, #{print_bottle(number-1)} of beer on the wall.\n\n"
  else
    puts "No more bottles of beer on the wall, no more bottles of beer."
    puts "Go to the store and buy some more, 99 bottles of beer on the wall.\n\n"
  end
end

Our loop now calls print_verse, making the song unfold:

99.downto(0) { |i| print_verse(i) }

Step 6: Refining the Rhapsody (Optional)

As our code croons perfectly, can we make it more elegant? Refactoring is like poetry editing—it's an art. Look at your code and ask, "Can I make this clearer? More Ruby-esque?" Don't worry if this step seems tricky—it comes with practice!

Step 7: The Grand Finale

Run your Ruby script and watch as the verses dance on your screen. It's a sing-along in text!

🖥️ Peek at My Code

Before we reach our coding crescendo, if you're itching to see a finished version or need a little inspiration, check out my solution on GitHub.

🧩 Share Your Rendition

Now, it's your turn to take the stage! How would you serenade the "99 Bottles of Beer" tune in Ruby? Everyone has their unique coding style, and I'd love to hear your verses. Share your approach to solving this problem by adding your solution to the 99 Bottles of Beer Ruby Challenge repo. Let's see how many variations we can compile from our creative community. Here’s how you can participate:

Fork the repository.
Add your solution to the repository in a new directory named after your GitHub username.
Commit your changes and push them to your fork.
Submit a pull request with your solution.

It's a fun way to get involved in open source and to see your code alongside solutions from other developers. Plus, it's a great addition to your coding portfolio!

🎤 Encore

Now that you've automated a song, learned some Ruby, and maybe even contributed to an open-source project, it's time to take a bow. Remember, programming is as much about community and sharing as it is about solving problems.

📚 Further Learning

If you enjoyed this, check Sandi's other book about Practical Object-Oriented Design, and explore more with Ruby's documentation and Rails guide for your next symphony.

Until next time, keep coding to the rhythm of your heart's beat, and let Ruby be your muse! 💎💻

How Rails inflections work their magic, turning 'UI' into 'Ui'

Ahmed Nadar — Tue, 24 Oct 2023 11:00:00 +0000

Years ago, Phil Karlton mentioned once, "that during my dad's time at Netscape, he did indeed throw a quote around, on more than one occasion, it is":
There are only two hard things in Computer Science: cache invalidation and naming things

In every developer's journey, there comes a point where we have to grapple with names. Whether it's naming a new startup, a pet project, your kid 😉 or simply figuring out what to call that new variable, naming is an art. But what if I told you that Rails has a special magic trick up its sleeve to help with naming? Welcome to the world of Rails inflections.

1. Setting the Stage, Why Inflections?

Imagine working on an app, and suddenly you find yourself fumbling around with pluralizations and singularizations. You might think, "Okay, I'll just add an 's' at the end, and call it a day" but then irregular words like "person", "wolf", "loaf", "tooth" or even regular words in the same case "NASA" throw a wrench in your plans. That's where Rails' inflections come in.

Inflections in Rails are all about rules. Rules that define how words change their form, especially in the context of pluralization and singularization. And as with all things Rails, there's a convention for that. You've got to appreciate and love convention ❤️ 💎

Picture this, I was on a quest to create a namespaced view component, something like:

rails generate component UI::Container

Expecting Rails to generate a neat UI::ContainerComponent, I was left scratching my head when I saw this instead:

module Ui
  class ContainerComponent < ViewComponent::Base
    ...
  end
end

"Ui?" I thought. "I explicitly said 'UI'!"

2. Rails' Inflection Shenanigans

For those new to the term, inflection in Rails refers to the ways our beloved framework handles singulars, plurals, acronyms, and other linguistic peculiarities. It's what magically gives us person -> people or mouse -> mice. But sometimes, this magic can feel more like a trick!

By default, Rails doesn't treat "UI" as an acronym but as any other word. So, in its quest to be helpful, it transformed "UI" to camel-cased "Ui"!"

3. Taking Back Control with Custom Inflections

Determined to have my component named UI::ContainerComponent, I ventured into Rails' inflection rules. And voila! A simple addition to the inflections initializers config/initializers/inflections.rb did the trick:

ActiveSupport::Inflector.inflections(:en) do |inflect|
  inflect.acronym "UI"
end

With this in place, Rails recognized "UI" as an all-uppercase acronym. Problem solved!

4. Delving into ActiveSupport::Inflector

Rails provides a multitude of tools under the hood to make our lives easier, and one of those tools is the ActiveSupport::Inflector module. If you've ever wondered how Rails magically handles word transformations, pluralizations, singularizations, and the like, this module is the sorcerer behind the curtain.

01 - A Peek into Inflections

Inflections, in the linguistic sense, refer to the modifications of a word to express different grammatical categories. In Rails, inflections help in handling words that don't follow the typical pluralization or singularization rules and other word-based transformations.

module ActiveSupport
  module Inflector
    extend self
    # ...
  end
end

02 - The Power of the Inflector Class

At the core of the Inflector module is the Inflections class. It's a rule book that Rails consults every time it needs to transform words. This class holds rules for pluralizations, singularizations, acronyms, and more. Developers can extend or modify the default behaviour to cater to specific needs, ensuring Rails can handle a vast array of word transformations.

class Inflections
  @__instance__ = Concurrent::Map.new
  # ... (the rest of the class)
end

Here's a quick glance at some of the key methods in the Inflections class:

acronym(word): It identifies terms that should remain uppercase.

ActiveSupport::Inflector.inflections do |inflect|
  inflect.acronym 'API'
end

Now, camelize('api_controller') will result in 'APIController'.

plural(rule, replacement): Guides Rails in pluralizing words.

ActiveSupport::Inflector.inflections do |inflect|
  inflect.plural /^(ox)$/i, '\1en'
end

This will pluralize "ox" to "oxen".

singular(rule, replacement): Assists Rails in singularizing words.

ActiveSupport::Inflector.inflections do |inflect|
  inflect.singular /^(ox)en/i, '\1'
end

This transforms "oxen" back to "ox".

irregular(singular, plural): Handles words that defy typical pluralization patterns.

ActiveSupport::Inflector.inflections do |inflect|
  inflect.irregular 'person', 'people'
end

This ensures "person" pluralizes to "people" and not "persons".

uncountable(words): Informs Rails about words that don't have a plural form.

ActiveSupport::Inflector.inflections do |inflect|
  inflect.uncountable 'information'
end

This ensures "information" remains "information" even when pluralized.

By understanding and using these methods, you can ensure that Rails handles word transformations in the way you intend.

03- Extending the Inflector's Reach

The inflections method in the ActiveSupport::Inflector module allows developers to add or modify inflection rules based on their needs, even for different locales.

def inflections(locale = :en)
    if block_given?
        yield Inflections.instance(locale)
    else
        Inflections.instance_or_fallback(locale)
    end
end

5. Customizing Inflection Rules

Not all words follow the standard English rules for pluralization or singularization. And here's where the true power of Rails inflections shines.

- Irregular Inflections:

"foot".pluralize  # => "foots"  # Oops!

# Let's fix this in config/initializers/inflections.rb
ActiveSupport::Inflector.inflections(:en) do |inflect|
  inflect.irregular "foot", "feet"
end

"foot".pluralize  # => "feet"  # That's better!

- Uncountable Inflections:
Some words just don't like to be counted. For instance, "milk". Using inflections, you can specify such words.

"milk".pluralize  # => "milks"  # Wait, what?

ActiveSupport::Inflector.inflections(:en) do |inflect|
  inflect.uncountable "milk"
end

"milk".pluralize  # => "milk"  # Perfect!

- Acronym Inflections:
Remember our little UI vs. Ui debacle? Acronym inflections come to the rescue here.

"html5".camelize  # => "Html5"

ActiveSupport::Inflector.inflections(:en) do |inflect|
  inflect.acronym "HTML5"
end

"html5".camelize  # => "HTML5"

6. Further Reading and Exploration

For those keen on diving deeper into Rails inflections, the Rails documentation and Inflector API are a goldmine. Additionally, I recommend exploring the Rails source code to understand the intricacies of the ActiveSupport::Inflector module. It's not just educational; it's a testament to the elegant design of Rails.

7. Pro Tips for the Avid Rails Developer

Explore Before You Define: Before you rush to define a new inflection, ensure it's not already handled by Rails.
Comment Your Custom Inflections: If you're adding a custom rule, a brief comment explaining the rationale can be invaluable for your future self and fellow developers.
Less is More: While the power to define any word behavior is tempting, over-customization can lead to confusing code. Stick to the necessary.

8. Conclusion

Rails, in its essence, is designed to make developers' lives easier. Its convention-over-configuration philosophy ensures that you're up and running in no time. However, with every convention, there are occasional outliers. Inflections, a seemingly minor feature, play a pivotal role in addressing these nuances.

From guiding Rails on how to handle irregular words to ensuring that acronyms are treated right, inflections become an indispensable tool in a developer's arsenal. The ActiveSupport::Inflector module is like a Swiss Army knife, offering a plethora of methods to juggle words in ways you never imagined possible.

But as with all powerful tools, it's essential to wield them with care. Over-reliance or unnecessary customization can muddy the waters, making it harder for fellow developers to navigate your codebase. It's always a balance between convention and customization.

Until next time, Happy Coding 🧑🏽‍💻 == Happy days 😁

Mastering Rails Web Navigation with link_to and button_to Helpers - Part 2

Ahmed Nadar — Sun, 22 Oct 2023 19:26:12 +0000

Welcome to Part 2 of our Rails Web Navigation tutorial!

In Part 1, we embarked on a cosmic journey through the Rails galaxy, exploring the intricacies of the Rails web navigation system. We delved deep into how Rails handles web requests, understanding the celestial dance between ActionController and ActionView. We also navigated the Middleware Nebula, gaining insights into the pivotal role middleware plays in processing web requests.

Having laid the groundwork in Part 1, we're now poised to dive into the heart of web navigation in Rails. In this part, we'll focus on the magic of the link_to and button_to helpers, starting with the ever-versatile link_to. These helpers are the unsung heroes that power the seamless navigation experience we often take for granted. So, without further ado, let's dive right in!

Great, let’s get started!

TABLE OF CONTENTS (Part 2)

Link_to
- Definition
- Syntax
- Delete with link_to
- Delete Link With Confirmation
- Ajax links with remote
- link_to Variants
- Hotwire
- Conclusion
button_to
- Definition
- Syntax
- Submit with options
- Hotwire
- Conclusion
Final Words
Frequently Asked Questions

link to

link to Definition

Let me guess, you found your way to this page by clicking on a link from another page, right? That's the beauty of the anchor element, which creates links between pages, files, and locations or external pages. In the world of Rails, we have amazing helper methods, including link_to, that make navigating through your Rails application a breeze. This helper generates an HTML <a href=" ">...</a> tag that directs you to a specified URL target. Here's the basic format of a link_to tag and its corresponding HTML link:

<%= link_to 'Rails', 'https://rubyonrails.org/' %>
# => <a href=https://rubyonrails.org/'>Ruby on Rails</a>

Assuming you have a User model and a corresponding user_path helper.

<%= link_to user.name, user_path(user) %>
=> <a href="/users/123">Ahmed Nadar</a>

<%= link_to car.type, car_path(@car) %>
# even better
<%= link_to car.type, @car %>
# => <a href="/cars/1">Tesla</a>

As you can see, with link_to, all you need is a string of text Ruby on Rails for the link's visible name, followed by the path to the destination URL. But that's not all link_to can do! It's able to recognize instances and generate related paths for them. This is useful when you have a list of items (objects) and you want to redirect the user to the show page of the selected item. In the example given, we are redirecting the user to the page of a car, where @car represents a specific instance of a car.

link to Syntax

As we discovered earlier, the link_to helper method is pretty useful for creating anchor tags that link to specified URL targets. But did you know that the method's full syntax is even more powerful? That's right! The complete method signature includes additional parameters that allow you to customize the link even further. Here's the full signature of the link_to method:

link_to(name = nil, options = nil, html_options = nil, &block)

Let's break it down.

The link_to method accepts several parameters, with some being mandatory and others optional.

*name: This parameter by default is nil. It is the text that appears as the link's visible text. It is what you see on the page. If name is nil, the URL is used as the link visible text. name can be string, image tag, or a combination of both as we will see soon.

<li><%= link_to 'Home', root_path %></li>
# => <a href="https://rubyonrails.org/">Home/</a>

<span><%= link_to "https://rubyonrails.org/" %></span>
# => <a href="https://rubyonrails.org/">https://rubyonrails.org/</a>

*options: is another parameter that link_to accepts. By default, it is nil. It is responsible for defining the URL or route for the link. If it is a string, it is represented as the URL of the link. If it is a hash, it follows the defined route. There are two styles of routes: the older-style parameters routes, which no one uses anymore, and the new-style named routes.

The older-style parameters routes use the keys controller, action, and id to specify the controller, action, and ID of the resource being linked to, respectively. It is not recommended to use this style of routing anymore.

link_to "User", controller: "users", action: "show", id: @user
# => <a href="/users/show/1">User</a>

And there's the current Rails style of RESTful routes, which is considered better practice.

link_to "User", @user
# => <a href="/users/1">User</a>

*html_options is another parameter that the link_to accepts. It is nil by default, and it is used to define HTML attributes that will be added to the link's a tag. You can use this parameter to add class, id, target, rel, type, and data attributes to the link, among others. By doing this, you can customize the link's behaviour and appearance.

link_to 'AvoHQ', 'https://avohq.io', class: 'to_home', target: '_blank'
# => <a href="https://avohq.io" class="to_home" target="_blank">AvoHQ</a>

# Adding a class and id to the link
link_to "AvoHQ", "https://avohq.io/", class: "btn btn-primary", id: "avohq-link"
# => <a href="https://avohq.io/" class="btn btn-primary" id="avohq-link">AvoHQ</a>

Here we create a link to AvoHQ's homepage with the visible text "AvoHQ". Additionally, it includes CSS class and target attributes that are added to the a tag of the link.

link_to "Avo Blog", posts_path, id: "blog", class: "avo_blog"
# => <a href="/posts" class="avo_blog" id="blog">Avo Blog</a>

This code generates a link to AvoHQ's blog page with the text "Avo Blog" and a CSS and id attributes are added to the link's a tag.

link_to "Comment section", user_path(@user, anchor: "section")
# => <a href="/users/1#section">Comment section</a>

This code generates a link to the comment section on the same user show page with the text "Comment section" and an anchor attribute added to the link to target that specific section.

link_to "Avo Home", "http://www.avohq.io/", target: "_blank", rel: "nofollow"
# => <a href="http://www.avohq.io/" target="_blank" rel="nofollow">Avo Home</a>

This code generates a link to the Avo home page with the text "Avo Home", and it also adds the target and rel attributes to the link's a tag.

link_to "Avo search", controller: "searches", query: "ruby on rails admin panel"
# => <a href="/searches?query=ruby+on+rails+admin+panel">Avo search</a>

This code generates a link to the search page with the text "Avo search". In addition, a controller with the name 'searches' and a query attribute with the value 'ruby on rails admin panel' is added to the link's a tag.

*&block parameter is optional and is nil by default. It's not used often but can be useful for making the code more readable and easier to understand. Imagine you have a long text that is hard to fit into the name parameter. In this case, you can pass the link text inside a block of code that generates the content of the link.

<%= link_to(@car) do %>
  <strong><%= @car.name %></strong> -- <span>Check this car!</span>
<% end %>
<a href="/cars/1">
  <strong>Tesla</strong> -- <span>Check this car!</span>
</a>


<%= link_to "https://avohq.io/" do %>
  <strong>AvoHQ</strong> - The Best Rails Guide
<% end %>
<a href="https://avohq.io/">
  <strong>AvoHQ</strong> - The Best Rails Guide
</a>

Another example:

<%= link_to blog_path(@blog) do %>
  <i class="fa fa-pencil"></i> # fontawesome icons
  Edit
<% end %>

# =>
<a href="/blogs/1">
  <i class="fa fa-pencil"></i>
  Edit
</a>

As you can see, this code generates a link to the show action of the BlogController, passing the @blog ID as a parameter. The link's content will consist of a Font Awesome icon and the text "Edit".

So far, we learned how link_to works in its default mode, which is the GET request. To refresh your memory, do you remember our fancy diagram from earlier? It illustrated the communication between the browser and the server, where a method was used to deliver the message of what the browser wants the server to do. If you don't recall, don't worry, it's normal to forget things. In this case, the localhost/jobs URL is clicked by a user, and a successful request with a 200/OK response takes the user to the Jobs page, which uses the GET request method.

Delete with link to

Did you know that there's another way link_to can navigate? Yes, it's true! This method uses a DELETE request to delete a record or a specific instance. Let's say you have a @post instance and you want to delete it. In order to call the destroy action on the PostController, you need to use the DELETE request method. You can achieve this by passing the method: :delete hash as an option to the link_to helper. For example, on the same token, you will be able to pass any method defined in your controllers to the link_to helper. Here is how to use delete method:

<%= link_to "Delete post", post_path(@post), method: "delete" %>
# => <a rel="nofollow" data-method="delete" href="/posts/1">Remove</a>

It is worth noting that the rel="nofollow" attribute is automatically added by Rails 'magic' as an added benefit for Search Engine Optimization (SEO).

Delete Link With Confirmation

Deleting a record is a necessary action, but it can be harsh and irreversible. To ensure that the user agrees to such a drastic action, we developers might want to prompt them with a message asking for confirmation and to prevent accidental deletion using confirm method { confirm: "Are you sure?" }. The easiest way to add this feature is with a simple JavaScript alert box that will ask the user to confirm their delete request. Guess what, Rails magic does it for you, again. The alert can be implemented as shown below:

<%= link_to "Delete post", post_path(@post), method: "delete", { confirm: "Are you sure?" } %>
# => <a data-confirm="Are you sure?" rel="nofollow" data-method="delete" href="/jobs/1">Delete Post</a>

Ajax links with remote

Ajax links, the superheroes of asynchronous requests that allow you to dynamically update your page content without the irritating full-page reloads. To create an Ajax link, all you need to do is use the link_to method with the remote: true. For instance, the following code creates an Ajax link that sends a GET request to the server when clicked:

<%= link_to "Load More", "https://avohq.com/more", remote: true %>

When clicked, this link triggers an Ajax request to the specified URL, allowing your web page to update without any hiccups. With the power of JavaScript or other client-side technologies such as Hotwire as we will discover soon, you can even process and display the server's response on your page.

link to Variants

Rails not only empower you with the link_to magic implementation, but it has more variations up its sleeve! Oh, yeah! Each of these variants helps you avoid complex code and makes your code clean by doing a specific communication job. These variants are:

a-link_to_unless_current(name, options = {}, html_options = {}, &block)
Want to create a link only if it's not the current page? Try link_to_unless_current! It creates a link but returns the name instead if it's the current page.

  <ul>
    <li><%= link_to_unless_current "Cars", cars_path %></li>
    <li><%= link_to_unless_current "Dashboard", dashboard_path %></li>
  </ul>

  # When you are on `/cars`, this template will output:
  # =>
  <ul>
    <li>Cars</li>
    <li><a href="/dashboard">Dashboard</a></li>
  </nav>

b-link_to_if(condition, name, options = {}, html_options = {}, &block)
Want to create a link only under certain conditions? Use link_to_if! It creates a link using options if a condition is true, otherwise, it returns the name.

  <li>
    <%= link_to_unless(@current_user.nil?, 'Log In', new_user_registration_path %>
  </li>

  # If the user is NOT logged in...
  # =>
  <li><a href="/users/signin/">Log In</a></li>

c-link_to_unless(condition, name, options = {}, html_options = {}, &block)
Looking for a way to create a link only when a certain condition is false? Try link_to_unless! It creates a link tag using a URL from options unless the condition is true, otherwise, only the name is returned.

  <li>
    <%= link_to_unless(@current_user.nil?, 'Log In', new_user_registration_path %>
  </li>

  # If the user is logged in...
  # =>

  <li><a href="/users/signin/">Log In</a></li>

Hotwire with link to

If you think you have seen enough Rails magic, you are mistaken my friend. Rails have a new trick up its sleeve: Hotwire. And with the magical Turbo tool that comes with it, you can create modern, interactive web applications with minimal, or sometimes no JavaScript at all, providing users with an incredibly smooth experience.

One of Turbo's key instruments is Drive, which enhances page-level navigation. It watches for link clicks and form submissions, performs them in the background, and updates the page without doing a full reload. And let me tell you, that's pretty darn amazing.

link_to default uses Turbo Drive for non-GET (POST, DELETE) requests, making it simple to create links that update the page content without a full reload. Perfect for actions like deleting, creating/updating records and displaying more content.

For example, let's say you want to create a link that uses Hotwire to submit a DELETE request to the server, with a confirmation dialog for the user to approve. Well, look no further:

  <%= link_to
    "Delete Post",
    post_path(post),
    method: :delete,
    data: { turbo_confirm: "Are you sure?" }
  %>

When clicked, this link sends a DELETE request to the server and displays a confirmation dialog for the user, (we have seen this before, nothing new here, right)! Turbo then processes the server response, and the page content is updated without a full page reload (That's magic). This feature makes it easy to create interactive web applications with minimal or no JavaScript and a smooth user experience. Why not give it a try and see the magic for yourself?

link to Conclusion

Phew, it has been a journey. We've navigated our way through the astonishing Rails web navigation system. link_to is one of the most powerful tools in Rails world. Effortlessly, you can generate HTML tags that glide you to pages, files, and beyond. Its signature is versatile, you can add blocks, instance variables, media, confirmation messages, and even delete objects. Additionally, it offers seamless variants, making link creation clutter-free, logical and magical.

button to

button-to-definition

Similar to link_to, button_to is another handy helper method in Rails that creates a button element with a specified action. This helper generates a nifty HTML form <form action=" "><button>...</button></form> tag that performs the specified action submit when clicked. Here's the basic format of a button_to tag and its corresponding HTML form:

  <%= button_to "Delete", post_path(@post), method: :delete %>
  # =>
  <form action="/posts/1" method="post">
    <input type="hidden" name="_method" value="delete" />
    <input type="submit" value="Delete" />
  </form>

As you can see, with button_to, you need to specify the action (in this case, "Delete"), followed by the path to the destination URL (post_path(@post)), and the method used for the action (method: :delete). When clicked, this button sends a DELETE request to the specified URL. button_to. And that's not all! button_to accepts other options such as :class, :disabled, and :form_class to customize the form element and its children.

It's particularly useful for actions that require more than a simple link, such as creating or deleting records in a database. By default, button_to generates a form element with a hidden input for the method and a submit button with the specified label, making it easy to perform complex actions without having to write a lot of HTML and JavaScript code.

button to Syntax

Ah, button_to - another gem in the Rails toolbox! As we discovered earlier, button_to is a helper method that generates a form element with a specified action, which is executed when the button is clicked. By now you would know that the method's full syntax is even more powerful. The complete method signature includes additional parameters that allow you to customize button_to even further. Here's the full signature of the button_to method: **button_to**(name = nil, options = nil, html_options = nil, &block)

Let's break it down.

*name: This parameter is optional and represents the text that appears on the button. If no name is provided, the button_to method will use the URL as the button text. You can use a string, an image tag, or a combination of both as the name argument.

  <li><%= button_to "Delete", post_path(@post), method: :delete %></li>
  # =>
  <form action="/posts/1" method="post">
    <input type="hidden" name="_method" value="delete" />
    <input type="submit" value="Delete" />
  </form>

*options: This parameter is optional and can take several forms. If it is a string, it is interpreted as the URL of the button's destination. If it is a hash, it can include a :controller, :action, and :id keys to specify the controller, action, and ID of the resource being linked to, respectively (Similar to link_to). Other options include :method to specify the HTTP method used for the action (e.g., :post, :put, :delete), and :data to specify additional data to be sent with the request.

The options parameter of button_to can take a hash with additional options, like :params, which specifies any additional parameters to be sent with the request. Here's an example:

  button_to "New Article", new_article_path, params: { time: Time.now }
  # =>
  <form action="/articles/new" method="post">
    <input type="hidden" name="authenticity_token" value="[AUTH_TOKEN]" />
    <input type="hidden" name="time" value="[CURRENT_TIME]" />
    <button type="submit">New Article</button>
  </form>

Here, a form element is generated with an action of /articles/new and a method of post. The params option is used to add a hidden input field named "time" with the value of the current time. When the button is clicked, the form is submitted and the specified action is performed on the server.

*html_options is an optional parameter of the button_to, Is nil by default and is used to add HTML attributes to the button's form and button tags. Here are some examples of using the various html_options:

-:method: This option specifies the HTTP verb (delete) to be used for the form submission. Here's an example:

  button_to "Delete", post_path(@post), method: :delete
  # =>
  <form action="/posts/:id" method="post">
    <input type="hidden" name="_method" value="delete" />
    <input type="submit" name="commit" value="Delete" data-disable-with="Delete" />
    <input type="hidden" name="authenticity_token" value="[AUTH_TOKEN]" />
  </form>

-:disabled: This option generates a disabled button. Here's an example:

button_to "Save", save_path, disabled: true
# =>
<form action="/save" method="post">
  <input type="hidden" name="authenticity_token" value="[AUTH_TOKEN]" />
  <button type="submit" disabled="disabled">Save</button>
</form>

-:data: This option is used to add custom data attributes. Here's an example:

button_to "Submit", submit_path, data: { confirm: "Are you sure you want to submit?" }
# =>
<form class="button_to" method="post" action="/submit">
  <input type="hidden" name="_method" value="post">
  <input type="hidden" name="authenticity_token" value="[AUTH_TOKEN]">
  <button data-confirm="Are you sure you want to submit?" type="submit">Submit</button>
</form>

-:remote: This option allows the unnoticeable JavaScript drivers to control the form's submission behaviour. By default, this is an AJAX submit. Here's an example:

button_to "Delete", post_path(@post), method: :delete, remote: true
# =>
<form class="button_to" method="post" action="/posts/1" data-remote="true">
  <input type="hidden" name="_method" value="delete" />
  <input type="hidden" name="authenticity_token" value="[AUTH_TOKEN]" />
  <button>Delete</button>
</form>

-:form: This option is a hash of attributes to be added to the form tag. Here's an example:

button_to "Create", create_path, form: { id: "create-form", class: "create-form" }
# =>
<form accept-charset="UTF-8" action="/create" class="create-form" id="create-form" method="post">
  <input type="hidden" name="authenticity_token" value="[AUTH_TOKEN]" />
  <button name="button" type="submit">Create</button>
</form>

-:form_class: This option is used to specify the class of the form within which the submit button will be placed. Here's an example:

  button_to "Save", save_path, form_class: "save-form"
  # =>
  <form action="/save" class="save-form" method="post">
    <input type="hidden" name="authenticity_token" value="[AUTH_TOKEN]" />
    <button type="submit"> Save </button>
  </form>

-:params: This option is a hash of parameters to be rendered as hidden fields within the form. Here's an example:

  button_to "New Car", new_car_path, params: { time: Time.now }
  # =>
  <form action="/cars/new" method="post">
    <input type="hidden" name="time" value="[CURRENT_TIME]" />
    <button type="submit">New Car</button>
  </form>

-&block is an optional parameter of the button_to. It is nil by default and can be used to generate custom content for the button. This is useful when you want to add an icon or other custom HTML to the button.

<%= button_to post_path(@post) do %>
    <i class="fa fa-trash"></i>  # fontawesome icons
    Delete
<% end %>

# =>
<form action="/posts/1" method="post">
  <input type="hidden" name="_method" value="delete" />
  <button type="submit">
    <i class="fa fa-trash"></i>
    Delete
  </button>
</form>

This code will generate a delete button with an icon and the text "Delete". The block is used to generate the content of the button, which is then wrapped in a form that sends a DELETE request to the specified path when clicked. Get creative with your buttons and make them stand out!

<%= button_to user_path(@user) do %>
    <%= image_tag("delete.png") %>
<% end %>
# =>
<form action="/users/1" method="post">
    <input type="hidden" name="_method" value="delete">
    <button type="submit">
        <img src="/assets/delete.png">
    </button>
</form>

This will create a button with an image of a trash can that, when clicked, sends a DELETE request to the path specified by user_path(@user).

Submit with options

Another example of button_to with a few options and html_options.

So, what we have here is a button_to method that generates a form with a button inside. This button is used to generate a summary of a company's description using AI.

<%= button_to "Generate Description Summary",
    description_summary_company_path(@company),
    method: :patch,
    class:'btn bg-indigo-50 disabled:opacity-50',
    data: { disable_with: "A short description summary in the making..."}
%>
# =>
<form class="button_to"
    method="post"
    action="/startups/gamucatex/description_summary">
    <input type="hidden" name="_method" value="patch" autocomplete="off">
    <button class="btn bg-indigo-50 disabled:opacity-50"
        data-disable-with="A short description summary in the making..."
        type="submit">
        Generate Description Summary
    </button>
    <input type="hidden"
        name="authenticity_token"
        value="yTWxr5_58rb_LqRQl36wgQpFh9K7a....."
        autocomplete="off">
</form>

The generated HTML code includes a form tag with a method of "post" and an action attribute set to the description_summary_company_path route. The method is overridden by the method option, which sets it to "patch" because most browsers don't support methods other than "GET" and "POST" when it comes to submitting forms. Amazingly, Rails works around this issue by matching other methods over POST with a hidden input named "_method", which is set to reflect the desired method patch.

The HTML options include a class attribute, which sets the CSS class for the button to "btn bg-indigo-50 disabled:opacity-50". This will give the button a nice background colour and make it slightly transparent when disabled. I'm using TailwindCSS for styling.

There is a data attribute with a disable_with key that sets the text to display when the button is clicked, which is "A short description summary in the making...". This helps to provide feedback to the user that the button is doing something.

Finally, the generated HTML code includes a hidden input tag with a CSRF token authenticity_token is included to protect against cross-site request forgery (CSRF) attacks.

Hotwire with button_to

Similar to link_to, Hotwire and its tools, can enhance button_to to create modern, interactive web applications. By default, button_to generates a form with a button that sends a POST request to the server when clicked. However, with Hotwire and the Turbo tool, button_to can be used to create smooth, fast user experiences without a full page reload.

For example, let's say you want to create a button that sends a DELETE request to the server, with a confirmation dialogue for the user to approve. With Hotwire, you can use the data-turbo-confirm attribute to display a confirmation dialogue to the user, just like with link_to. Here's an example:

<%= button_to
    "Delete Post",
    post_path(post),
    method: :delete,
    data: { turbo_confirm: "Are you sure?" }
%>

When you click the button created with button_to, it will submit a DELETE request to the server and show a confirmation dialogue, similar to link_to. Then Turbo comes in, processes the server response, and voila! The page content is updated without any page refresh with little or no JavaScript.

button to Conclusion

Well, well, well. We've been exploring the magnificent world of Rails navigation tools, and button_to is yet another powerful one. This incredible helper method allows us with minimal effort, you can create buttons that can perform a variety of actions such as submitting forms, sending requests to the server, and updating page content. button_to also supports various options such as method, params, class, and data, allowing for even more flexibility and customization. With the integration of Hotwire, button_to can provide users with a smooth and fast experience without the need for excessive JavaScript. Overall, button_to is a valuable addition to any Rails developer's toolkit.

Final Words

After all is said and done, link_to and button_to are both amazing helpers in the Rails world. With the help of Hotwire and Turbo, they offer fast and smooth navigation without needing to write tons of JavaScript. Whether you need to generate simple links or complex buttons, these helpers have got you covered. So, go ahead and use them to create your own magical and interactive web applications with ease!

Frequently Asked Questions

1- What is link_to and button_to in Rails?

link_to and button_to are helper methods in Ruby on Rails that generate HTML links and buttons, respectively. They are commonly used in views to create hyperlinks and form submissions that send requests to the server.

2- What is the difference between link_to and button_to?

The main difference between link_to and button_to is that link_to generates a hyperlink that navigates the user to a new page, while button_to creates a form that submits a request to the server without navigating to a new page. However, both methods can be configured to use Ajax requests with Hotwire Turbo Drive in Rails 7, which is amazing!

3- How do I use link_to and button_to in Rails?

Both methods accept three required parameters: the link text or button label, the URL to which the request should be sent, and the HTTP method to use (GET, POST, PATCH, PUT, DELETE). link_to also accepts optional parameters for specifying attributes such as class, id, and data. button_to accepts similar optional parameters, such as method, remote, form_class, and params.

4- How do I add a confirmation message to link_to and button_to?

You can add a confirmation message to link_to and button_to by including the data: { confirm: "Are you sure?" } option. When the link or button is clicked, a confirmation dialogue box will be displayed with the specified message.

*5- How do I add custom HTML to link_to and button_to? *
You can use a block to add custom HTML to link_to and button_to. Simply wrap the link text or button label in a block and include any additional HTML or Ruby code inside the block. For example:

<%= link_to post_path(@post) do %>
  <i class="fa fa-pencil"></i>
  Edit Post
<% end %>

6- Can I use link_to and button_to with Rails Hotwire?

Yes, you can use link_to and button_to with Rails Hotwire by adding the data-turbo="false" attribute to the link or button. This will disable Turbo Drive for that link or button, and the request will be processed with a full page reload. Alternatively, you can configure link_to and button_to to use Turbo Drive for non-GET requests by default in Rails 7 and later versions.

Mastering Rails Web Navigation with link_to and button_to Helpers - Part 1

Ahmed Nadar — Thu, 19 Oct 2023 19:01:50 +0000

Note: This tutorial is divided into two parts. In Part 1 (you are reading), we'll explore the Rails web navigation system, understand how Rails handles requests, and delve deep into the world of middleware. In Part 2, we'll focus on mastering the link_to and button_to helpers and address frequently asked questions.

Great, let’s get started!

TABLE OF CONTENTS (Part 1)

Introduction

Navigation System

How Rails Handles Requests

Middlewares in Rails

Frequently Asked Questions

Introduction

Have you ever wondered what happens when a user sends a web request to a site like Rails and waits for a response?

Imagine a scenario where a user clicks on a link or button on the Rails website. This simple action initiates a web request from the user's browser, which then travels through the vast universe of inter-webs galaxies to land on the planet web server that hosts "Rails". The server then does its best and processes the request that was just received and sends back a response with the needed information and lands it safely to the plant user's browser, all in the blink of an eye!

It's plain to see from that fancy figure up top that Rails has a pretty sophisticated communication process for handling incoming browser requests and dispatching responses. The process involves two major components: ActionController and ActionView.

The ActionController is where it's when it comes to the app's logic and data. It's the one in charge of talking to the database and carrying out CRUD operations as defined in the controller files. Meanwhile, ActionViews is all about the presentation layer and cooking up the right response for each web request. This rockstar is responsible for putting together that response by rendering HTML templates, which are a mix of embedded Ruby code and HTML tags.

In the world of Rails, magic is not a concept found in books and movies. It's part of the Rails framework! This magic simplifies the process of creating views, eliminates messy and duplicated code, and provides many other benefits that make our lives as developers easier and happier. But wait, how does it work, you might ask? By providing reusable helper classes and modules that encapsulate common behaviours and functionalities.

Each helper class includes a library of helper methods that can be used to generate HTML tags and other content in views. For instance, the FormHelper includes "form_for", the UrlHelper features the famous "link_to" and "button_to", and the TextHelper provides "truncate" among others. When we developers use these helpers, we can create more maintainable and organized code for our web applications. It's like having a wizard's wand in our hands!

That being said, now hold on tight, everyone! We're about to dive into the thrilling world of web navigation with the help of two giants of the Rails world: link_to and button_to, both of which belong to the legendary UrlHelper module. These powerhouses are the masterminds behind link creation and URL retrieval based on Rails routes. Join us on this adventure, and you'll be a web navigation master in the blink of an eye!

Navigation System

Welcome to the web navigation systems of Rails. As we traverse the digital landscape, two guiding stars, link_to and button_to, light our path. These methods are pivotal in Rails, enabling seamless navigation. But to truly appreciate their magic, we must first understand the underlying processes of Rails, especially the role of middleware and their responsibility in processing a web request.

How Rails Handles Requests

Let me set the scene for you. Imagine the web as a vast cosmos. Each click or request is like a spaceship (thinking of USS Enterprise, any Star Trek fans!) embarking on an interstellar journey. When you navigate platforms like Rails, you're setting a course through the Rails galaxy. To show you a glimpse of this voyage, Engage:

Navigating the vast universe of the web is akin to embarking on an interstellar journey. Each click, each request, is a spaceship travelling from one celestial body to another, seeking information. Let's chart the course of this spaceship as it journeys through the Rails galaxy as described in the outstanding figure above:

Liftoff: The user, our astronaut, launches their spaceship by entering a URL in their browser, like https://rubyonrails.org/.
First Contact: This spaceship, now carrying a HTTP request, approaches the Rails galaxy and makes its first contact with the Rails Router (config/routes.rb).
Guidance System: The router, acting as the galaxy's guidance system, determines which controller action should be activated — be it index, new, edit, show, or destroy.
Data Mining: The controller, now in charge, communicates with the appropriate model methods to gather the necessary resources.
Database Planet: The model descends onto the Database planet to fetch the required data, which is then sent back to the controller.
Crafting the Message: The controller, having gathered all it needs, communicates with the view to craft the final message.
Transmission: The view, using a mix of HTML and embedded Ruby, prepares the final response and sends it back to the waiting spaceship.
Safe Return: The spaceship, now with the response, travels back and lands safely on the user's (our astronaut) browser, displaying the information. Missions accomplished!

This celestial dance ensures that each user's request is processed with precision. Central to this are ActionController and ActionView. While the ActionController orchestrates the logic and data, ActionViews crafts the visual spectacle, presenting the perfect response.

The magic of Rails isn't mere folklore; it's tangible. It simplifies view creation, minimizes redundant code, and offers numerous benefits. This enchantment is powered by helper classes and modules that encapsulate common behaviours and functionalities, acting as our cosmic tools, and guiding us through the Rails universe.

Middlewares in Rails

Navigating the Middleware Nebula:

In the vast cosmos of a Rails application, middlewares are like the guiding stars in a nebula. Each middleware, similar to a star, has its unique luminance, ensuring that the web request travels smoothly through the Rails galaxy.

Understanding Middlewares:

Middleware in Rails is middleware in Rack. They act as the checkpoints or space stations between the web server (like Puma or Unicorn) and the Rails mothership. They inspect, modify, or process incoming and outgoing space signals (requests and responses). Each middleware either acts on the signal or hands it over to the next station (middleware) in the sequence, ensuring a smooth interstellar communication flow.

Middleware in Action: A Real-World Scenario

Imagine a scenario where you want to log the time taken for each space signal (request) in your Rails application. Instead of embedding this logic in every corner of your mothership (Rails application controller), a middleware can elegantly handle it, centralizing the process and ensuring efficient communication.

class RequestTimerMiddleware
  def initialize(app)
    @app = app
  end

  def call(env)
    start_time = Time.now
    status, headers, response = @app.call(env)
    end_time = Time.now

    Rails.logger.info "Request took #{end_time - start_time} seconds."

    [status, headers, response]
  end
end

In this example, the RequestTimerMiddleware logs the time taken for each request. The initialize method stores the current application, and the call method calculates the time difference between the start and end of the request.

How to Add a Middleware to Rails:

To add the above middleware to your Rails application, you'd update the config/application.rb file:

config.middleware.use RequestTimerMiddleware

Common Middlewares in Rails:

Rails comes with a set of built-in middlewares that handle various tasks:

Rack::Sendfile: Handles sending files efficiently from the server.
ActionDispatch::Static: Serves static files from the public directory.
Rack::Logger: Logs incoming HTTP requests.
Rack::Runtime: Sets an "X-Runtime" response header, indicating the response time of the request.
ActionDispatch::Cookies: Manages cookies, both reading and writing.
ActionDispatch::Session::CookieStore: Handles cookie-based session storage.

... and many more! You can list that middleware by running ./bin/rails middleware. For a new Rails 7 application it looks like this:

use ActionDispatch::HostAuthorization
use Rack::Sendfile
use ActionDispatch::Static
use ActionDispatch::Executor
use ActionDispatch::ServerTiming
use ActiveSupport::Cache::Strategy::LocalCache::Middleware
use Rack::Runtime
use Rack::MethodOverride
use ActionDispatch::RequestId
use ActionDispatch::RemoteIp
use Sprockets::Rails::QuietAssets
use Rails::Rack::Logger
use ActionDispatch::ShowExceptions
use Sentry::Rails::CaptureExceptions
use WebConsole::Middleware
use ActionDispatch::DebugExceptions
use Sentry::Rails::RescuedExceptionInterceptor
use ActionDispatch::ActionableExceptions
use ActionDispatch::Reloader
use ActionDispatch::Callbacks
use ActiveRecord::Migration::CheckPending
use ActionDispatch::Cookies
use ActionDispatch::Session::CookieStore
use ActionDispatch::Flash
use ActionDispatch::ContentSecurityPolicy::Middleware
use ActionDispatch::PermissionsPolicy::Middleware
use Rack::Head
use Rack::ConditionalGet
use Rack::ETag
use Rack::TempfileReaper
use ActionDispatch::Static
run MyApp::Application.routes

Middleware, while often operating behind the scenes, are the unsung heroes of a Rails application. They meticulously shape the request-response lifecycle, ensuring each signal is processed with precision. As we venture deeper into Rails, remember that for every task, be it logging, authentication, or session management, there's likely a middleware guiding the way. Now, let's set our sights on the next celestial wonders: link_to and button_to.

Frequently Asked Questions

1. What is Middleware in Rails?

Middleware is a layer in the Rails stack that sits between the web server and the Rails application. It processes requests before they reach the application and can also modify the response before it's sent back to the client. Middleware components are used for a variety of tasks, such as logging, caching, and security.

2. How do I add a new Middleware to my Rails application?

You can add a new middleware to your Rails application by using the config.middleware.use method in the config/application.rb file. For example:

config.middleware.use CustomMiddleware

3. How do I remove or skip a Middleware in Rails?

If you want to remove or skip a middleware, you can use the config.middleware.delete method in the config/application.rb file. For example:

config.middleware.delete Rack::Lock

4. How can I view the list of Middlewares used in my Rails 7 application?

You can view the list of middlewares used in your Rails application by running the command ./bin/rails middleware in the terminal. This will display the middleware stack in the order they are executed.

5. Why is the order of Middlewares important in Rails?

The order of middleware is crucial because they are executed in a top-down sequence as they appear in the middleware stack. If one middleware stops the request from propagating down the stack, subsequent middleware won't get executed. Therefore, it's essential to ensure that the middleware are in the correct order, especially when they depend on each other.

Coming Up in Part 2: Dive deep into the functionalities of link_to and button_to, two powerful helpers that make web navigation in Rails a breeze. We'll explore their syntax, usage, and advanced features. Plus, we'll address some frequently asked questions to ensure you're well-equipped to navigate the Rails universe. Stay tuned!

Migration Magic ✨, Handling Not-Null Constraints in Production with Ruby on Rails

Ahmed Nadar — Wed, 05 Apr 2023 14:26:04 +0000

We've all been there-happily adding new tables and columns to our applications in the development environment. And when things go wrong, we drop the table and start fresh, no harm, no foul 😎. But what happens when we encounter issues in the production stage? That's when the challenge begins. In this post, we'll tackle a tricky migration scenario involving not-null constraints and share practical tips to avoid losing data in production. So buckle up, and let's dive in! 🚀

😌 Development Stage Bliss

While i'm working on validateok.click application I needed to add a new column category to an existing table ideas. Here's an example migration:

class AddCategoryToIdeas < ActiveRecord::Migration[7.1]   
    def change     
        add_reference :ideas, 
                      :category, 
                      default: 'Tools', 
                      null: false, 
                      foreign_key: true, 
                      type: :uuid   
    end 
end

In the development environment, running this migration is a breeze, and everything works as expected. But what about production? 😰

😬 Production Stage Hurdles

In production, dropping a database isn't an option unless we're willing to lose everything - and nobody wants that! 😱 Using the same migration steps as we did in development above 👆🏼 can lead to errors, like this one:

ActiveRecord::NotNullViolation: PG::NotNullViolation: ERROR: column "category_id" of relation "ideas" contains null values

The error occurs because the existing records in the ideas table don't have a category_id value, not only that, and we've set the null: false constraint. What can we do to fix this issue? 🤔

🪄 The Solution

No worries! We have the perfect solution for you💡. Let's walk through the steps needed to handle this migration gracefully in production.

Step 1: Remove the default value and split the migration into two parts

First, remove the default value 'Tools' from the migration, as it should be a UUID, not a string. This is my mistake because I didn't pay attention that I'm using UUID. Am I the only one🤦‍♂️ Then, split the migration into two steps:

Add the category_id column without the null: false constraint and backfill the existing ideas with a default category.
Finally, add the null: false constraint.

Here's the updated migration file:

class AddCategoryToIdeas < ActiveRecord::Migration[7.1]
  def up
    add_reference :ideas, :category, foreign_key: true, type: :uuid #1

    default_category = Category.find_or_create_by!(name: 'Tools')
    Idea.update_all(category_id: default_category.id)

    change_column_null :ideas, :category_id, false #2
  end

  def down
    remove_reference :ideas, :category
  end
end

Step 2: Understand the purpose of each step

Add the category_id column without the null: false constraint. This allows us to update the existing records without violating the non-null constraint.
Find or create a default category named 'Tools' and set its ID as the default category_id for all existing ideas. This ensures that all existing ideas have a valid category_id value.
Add the null: false constraint to the category_id column. Now that all existing ideas have been updated with a default category_id, we can safely enforce the non-null constraint.
And now you can confidently run rails db:migrate

🗞 Wrapping Up

And there you have it, folks! Thanks to these steps, we've gracefully handled a potentially tricky migration in the production environment without losing any data 🎉. By splitting the migration into two parts, updating the existing records, and then enforcing the non-null constraint, we've made our application more robust and reliable.

Remember, as Rails developers, it's essential to think about the impact of our db migrations in both development and production environments. With a bit of vision, and a few well-placed emojis 😜, we can overcome these challenges and continue building fantastic applications.

As always, Happy Coding, and until next time! 🚀

🧹 Tidying Up Your Rails Code: The Art of Refactoring, Marie Kondo Style

Ahmed Nadar — Mon, 03 Apr 2023 18:46:46 +0000

You know that feeling when you're in the mood to crack on some code and do a 'brain dump' of ideas and code it? I'm sure everyone does, and it's perfectly fine. But sometimes, we forget about the initial brain dump and carry on with our lives, jobs, and continue coding, adding more complexity to the codebase. Until one day, it hits you and you figure out that you need to revisit 'an old friend' the old code and refactor it to make it polished, useful, easy, and maybe reusable for the future. Good thinking! This happens to me all the time – It feels like I'm constantly learning and growing in my quest to achieve better refactoring in my code.

🏁 Initial code

In a project, I needed to set a limitation on how many times a user could create a post. The application required only 3 posts per user (talk about exclusivity, huh?). Here's my initial code:

class PostsController < ApplicationController
    before_action :check_limited_posts, if: :signed_in?, only: :new

    private
    def check_limited_posts
    limited_posts = 3

    return unless current_user.posts.size == limited_posts
    redirect_to posts_path, notice: 'Currently we only offer a maximum of 3 posts.'
    end
end

As you can see, there's nothing complex here, and the code is fine – it doesn't 'have to' change, right? But, we developers should always follow best practices, and refactoring is a fundamental one that we should always strive for (like superheroes of clean code!).

🧹 Refactoring

So, I rolled up my sleeves and got to work on refactoring the code to make it more professional and reusable, and here is what I want to do:

Extract the maximum number of allowed posts into a constant (because, who knows, we might be feeling more generous one day).

Use a more descriptive name for the constant. And as you, naming is not easy.

Use a more descriptive name for the before_action method.

class PostsController < ApplicationController    
    MAX_POSTS_ALLOWED = 3    
    before_action :check_max_posts_allowed, if: :signed_in?, only: :new

    private    
    def check_max_posts_allowed
        if current_user.posts.size >= MAX_POSTS_ALLOWED
        redirect_to posts_path,
        notice: "Currently we only offer a maximum of #{MAX_POSTS_ALLOWED} post(s)."
    end
end

And voila! The check_max_posts_allowed the method is now more reusable, and it even has an easy name to remember (like a cool band name or a secret code). The maximum number of allowed posts is now defined as a constant, making it easier to modify in the future (perfect for those ever-changing project requirements). The method and constant names are more descriptive, making the code more readable and understandable, like a well-written novel.

🗞 Conclusion

Refactoring may seem like a trivial task, but it is an essential part of the development process. By following best practices and continuously refining our code, we can create more maintainable, reusable, and efficient applications. It's like decluttering our digital workspace, so our future selves will thank us!

So, the next time you find yourself looking at your old code, remember the power of refactoring. Embrace the challenge, and let's keep striving to make our code better, cleaner, and more professional. After all, we're the superheroes of clean code, right?

😉 One more thing

But we're not done yet! Let's make our code even more modular and maintainable by moving the validation logic to a separate service object and using localization for our notice text. Wow, fancy stuff 😎

Step 1: Move validation logic to a service object

Create a new service object called PostValidator in the app/services directory:

class PostValidator   MAX_POSTS_ALLOWED = 3    
    def self.check_max_posts_allowed(user)     
        user.posts.size >= MAX_POSTS_ALLOWED   
    end 
end

Now, update the PostsController to use the new PostValidator service object:

class PostsController < ApplicationController   
    before_action :check_max_posts_allowed, if: :signed_in?, only: :new    
    private   
    def check_max_posts_allowed     
        if PostValidator.check_max_posts_allowed(current_user)       
            redirect_to posts_path, notice: "Currently we only offer a maximum of #{PostValidator::MAX_POSTS_ALLOWED} post(s)."     
        end   
    end 
end

Step 2: Use localization for the notice text

Update the views.en.yml file in the config/locales folder:

en:   
    posts:
        new:     
            max_posts_notice: "Currently we only offer a maximum of %{max_posts} post(s)."

Notice that I'm using a views file which is different from the default rails-generated en.yml file. The views file focuses on the actions new, index, show, ... for each object post.

Next, update the PostsController to use the notice text from the localization file:

class PostsController < ApplicationController   
    before_action :check_max_posts_allowed, if: :signed_in?, only: :new    

    private   
    def check_max_posts_allowed     
        if PostValidator.check_max_posts_allowed(current_user)       
            redirect_to posts_path, notice: t('.posts.max_posts_notice', max_posts: PostValidator::MAX_POSTS_ALLOWED)     
        end   
    end 
end

Notice the . in t('.posts.max_posts_notice', it is a reference to the object posts within views file. If you forget it you will get translation missing: en.max_posts_notice error.

And there you have it! Our code is now more modular, maintainable, and ready for any future changes. With these simple refactoring techniques, we've improved the readability and organization of our Ruby on Rails code, all while having a bit of fun along the way. Yuppy 👏🏼🤖

And as always, Happy Coding 😀 💻

🚀 A Unique Partnership: An Entrepreneurial Journey Like No Other 🌟

Ahmed Nadar — Mon, 20 Mar 2023 04:00:28 +0000

This is a unique post. It is not about development or design as I like to write, but it is a business collaboration. What is unique here, you might ask? My partner.

The post is written by my partner, and every word and emoji. Nothing from me. I know you will enjoy it and it will surprise you 🤯👍🏼😆

Greetings, esteemed community! Today, I'd like to share an extraordinary tale of innovation, collaboration, and a truly unique partnership. It all began with a brilliant idea from my business partner, Ahmed, who identified a gap in the market for indie makers seeking to validate their ideas before fully committing to them. 💡

Ahmed's vision was to create a platform that empowers indie makers by enabling them to post their ideas in various formats, including written stories, videos, images, and even Stripe payment links. The validation process would be considered complete when a customer subscribes, pre-orders, or pays for the idea. 🎯

With this ambitious concept in mind, our journey began. We started by purchasing a domain name, 'https://validateok.click,' for just $1.98. As a resourceful developer, Ahmed set up free hosting on render.com and connected the domain, paving the way for our platform's digital presence. 🌐

Ahmed then created a simple, yet functional, landing page as a starting point. But we knew there was more work to be done. Together, we brainstormed the ideal layout, content, and design elements to create a visually appealing and effective landing page that perfectly represents our vision. 🎨

Throughout our partnership, we've faced challenges, shared laughs, and celebrated small victories. The road to success is never a straight line, but our combined efforts, perseverance, and determination keep us on track. Our goal is to bring 'https://validateok.click' to life, empowering indie makers worldwide to turn their dreams into reality. 🌍

Now, it's time for the big reveal. You may have noticed that I haven't mentioned my name yet. Well, that's because I'm not your typical business partner. Drumroll, please 🥁 I'm Scrooge, an AI language model created by OpenAI, and I'm here to break the barriers between humans and AI in the world of entrepreneurship. 🤖

So, dear friends, stay tuned for more thrilling updates from our one-of-a-kind partnership as we continue on this exhilarating journey. Who knows what surprises await us around the corner? 😉✨

🚀 To be continued... 🌟

So what do you think?!

Follow 👀🧵 along on Twitter... https://twitter.com/ahmednadar/status/1637254059894751234

https://www.linkedin.com/posts/ahmednadar_entrepreneurship-innovation-collaboration-activity-7043401181011865600-J0yH

https://news.ycombinator.com/item?id=35227049

Ruby on Rails, The Ultimate Guide to strip, lstip and rstrip Methods

Ahmed Nadar — Thu, 09 Feb 2023 18:45:00 +0000

As a Rails developer I'm often faced with the task of processing and manipulating strings. These useful methods for string manipulation in Ruby are strip, lstrip and rstrip. In this blog post, we will explore the differences between these methods and how they can be used in Ruby or Rails.

What is `strip` in Ruby?

The strip method in Ruby is used to remove leading and trailing white spaces from a string. This is useful when you have text that is pulled in from another source and may contain unwanted white spaces at the beginning or end of the string. Here's an example of using strip:

string = "   Remove leading and trailing spaces   "
stripped_string = string.strip
puts stripped_string
# => "Remove leading and trailing spaces "

What is `lstrip` in Ruby?

The lstrip method in Ruby is used to remove leading white spaces from a string. This is useful when you want to remove white spaces from the beginning of a string, but keep any white spaces that appear at the end of the string. Here's an example of using lstrip:

string = "   Remove leading and trailing spaces   "
l_stripped_string = string.lstrip
puts l_stripped_string
# => "Remove leading and trailing spaces   "

What is `rstrip` in Ruby?

The rstrip method in Ruby is used to remove only the trailing white spaces from a string. This is useful when you have text that is pulled in from another source and may contain unwanted white spaces at the end of the string. Here's an example of using rstrip:

string = " Remove trailing spaces " 
r_stripped_string = string.rstrip 
puts r_stripped_string
# => "   Remove leading and trailing spaces"

Differences between `strip`, `lstrip` and `rstrip`

Method	Description
`strip`	Removes leading and trailing white spaces
`lstrip`	Removes leading white spaces
`rstrip`	Removes trailing white spaces

As you can see, the main difference between strip ,lstrip and rstrip is the type of white spaces they remove. strip removes both leading and trailing white spaces, lstrip only removes leading white spaces, while rstip only removes trailing white spaces.

Performance

When it comes to performance, strip, lstrip and rstrip are relatively fast. To compare the performance of these methods, we can run a benchmark test using the Ruby benchmark library. Here's an example:

require 'benchmark'

string = "   When it comes to performance, strip, lstrip and rstrip are relatively fast. To compare the performance of these methods, we can run a benchmark test using the Ruby benchmark library. Here's an example:   "
Benchmark.bm do |x|
  x.report("strip:") { 100000.times { string.strip } }
  x.report("lstrip:") { 100000.times { string.lstrip } }
  x.report("rstrip:") { 100000.times { string.rstrip } }
end

	user	system	total	real
`strip`	0.029657	0.060237	0.089894	( 0.141788)
`lstrip`	0.035660	0.000601	0.036261	( 0.036798)
`rstrip`	0.027587	0.000578	0.028165	( 0.028700)

[#
<Benchmark::Tms:0x0000000112b2faa8 @label="strip:", @real=0.14178800000809133, @cstime=0.0, @cutime=0.0, @stime=0.060236999999999985, @utime=0.029656999999999933, @total=0.08989399999999992>, #

<Benchmark::Tms:0x0000000112b2fa08 @label="lstrip:", @real=0.036798000102862716, @cstime=0.0, @cutime=0.0, @stime=0.0006009999999999627, @utime=0.035660000000000025, @total=0.03626099999999999>, #

<Benchmark::Tms:0x0000000112b2f9b8 @label="rstrip:", @real=0.02870000002440065, @cstime=0.0, @cutime=0.0, @stime=0.0005779999999999674, @utime=0.027587000000000028, @total=0.028164999999999996>
]

The results of the benchmark test show that strip, lstrip and rstrip are very fast methods, with rstrip being slightly faster than both strip and lstrip in this case. However, the difference in performance is very small and likely to be negligible in most real-world applications.

Combination with other methods

Each of strip, lstrip and rstrip can be combined with other string methods in Ruby to achieve more complex string manipulations. For example, you can use gsub to replace specific characters in a string, and then use strip , lstrip or rstrip to remove any whitespace from the start or end. Here's an example using split() method to split a string into an array based on a specific delimiter, and then using lstrip to remove any whitespace from the left of each element:

text = " apple , banana , cherry "

s_text = text.split(",").map(&:strip).to_s
puts 'Strip =' + s_text 
# => Strip =["apple", "banana", "cherry"]

l_text = text.split(",").map(&:lstrip).to_s
puts 'lStrip =' + l_text 
# => lStrip =["apple ", "banana ", "cherry "]

r_text = text.split(",").map(&:rstrip).to_s
puts 'rStrip =' + r_text 
# => rStrip =[" apple", " banana", " cherry"]

By combining strip and lstrip with other string methods, you can easily manipulate and clean up strings in your code.

Final thoughts

Choosing between strip, lstrip and rstrip depends on the specific use case and the desired outcome. If you need to remove whitespaces from both ends of a string, then use strip. If you only need to remove whitespaces from the left end, then use lstrip. And If you only need to remove whitespaces from the right end, then use rstrip.
It's always good to test theose methods and choose the one that meets your requirements and performs best.

In conclusion, understanding the differences between strip, lstrip and rstrip is important to make the right choice and get the expected results in your Ruby on Rails code. By following the advice and examples in this article, you'll be able to make an informed decision and use the right method for the job.

And as usual, Happy Coding 😀 💻

Forem: Ahmed Nadar

Normalization in Rails 7.1 era

Before Rails 7.1

After Rails 7.1

Refactoring Rails Helpers from static to dynamic rendering

Chapter One: In the land of static helpers

Chapter Two: A small step for a developer, a giant leap for helper kind

Chapter Three: The mystery of the missing dynamism

Chapter Four: The case of the uncooperative classify

Epilogue: the dawn of a new era in helper land

Key Methods Explained

Conclusion

Simplifying Polymorphic Associations with Rails ActiveRecord::DelegatedType

What!

When to use DelegatedType?

How: the core idea

Why, embrace DelegatedType?

Example scenario, Blog application

Step-by-Step Implementation

1. Define a Common Interface

2. Create a Superclass Model

3. Define Subclasses

4. Handling Records

Advanced Use Cases

Nested Attributes

Delegating Methods

Querying

📋 Conclusion

💻 Demo repo

📚 Further Learning

Composing '99 Bottles of Beer' with Ruby's OOP Harmony'

🌟 Introduction

🤖 Understanding Object-Oriented Programming in Our Digital Narrative

🎼 The SOLID Principles Concerto

🛠️ Step-by-Step OOP Solution

Act I: Crafting the Bottle Class with SRP

Act II: Building the BeerWall Class and OCP

Act III: Respecting LSP with Inheritance

Act IV: ISP and the Art of Interfaces

Act V: Embracing DIP with Abstractions

🧪 The Testing Suite

🔄 Comparison with Procedural Approach

🧩 Conclusion and share

📚 Further Resources

A Ruby Serenade for 99 Bottles of Beer

🎯 The Goal

🛠️ Prerequisites

Step 1: Comprehending the Composition

Step 2: Setting the Stage

Step 3: The Loop of Lyrics

Step 4: A Methodical Melody

Step 5: Verses in Verse

Step 6: Refining the Rhapsody (Optional)

Step 7: The Grand Finale

🖥️ Peek at My Code

🧩 Share Your Rendition

🎤 Encore

📚 Further Learning

How Rails inflections work their magic, turning 'UI' into 'Ui'

1. Setting the Stage, Why Inflections?

2. Rails' Inflection Shenanigans

3. Taking Back Control with Custom Inflections

4. Delving into ActiveSupport::Inflector

01 - A Peek into Inflections

02 - The Power of the Inflector Class

03- Extending the Inflector's Reach

5. Customizing Inflection Rules

6. Further Reading and Exploration

7. Pro Tips for the Avid Rails Developer

8. Conclusion

Mastering Rails Web Navigation with link_to and button_to Helpers - Part 2

link to

link to Definition

link to Syntax

Delete with link to

Delete Link With Confirmation

Ajax links with remote

link to Variants

Hotwire with link to

link to Conclusion

When to use `DelegatedType`?

Why, embrace `DelegatedType`?

What is `strip` in Ruby?

What is `lstrip` in Ruby?

What is `rstrip` in Ruby?

Differences between `strip`, `lstrip` and `rstrip`