Forem: Eapen Zacharias

Introduction to Ruby on Rails: Getting Started with Web Development

Eapen Zacharias — Fri, 04 Aug 2023 17:34:52 +0000

Introduction to Ruby on Rails: Getting Started with Web Development

Ruby on Rails, often simply referred to as Rails, is a powerful and popular open-source web application framework written in the Ruby programming language. It provides developers with a set of tools, conventions, and best practices to streamline the process of building robust and scalable web applications. In this tutorial, we'll dive into the basics of Ruby on Rails and explore key concepts that will help you embark on your web development journey.

Table of Contents:

What is Ruby on Rails?
Understanding MVC Architecture
Why Choose Ruby on Rails?
When to Use Ruby on Rails
Prerequisites
Setting Up Your Development Environment

What is Ruby on Rails?
Ruby on Rails is a framework designed to simplify and accelerate web application development. It follows the Model-View-Controller (MVC) architectural pattern, which divides the application's components into three main interconnected parts: Models, Views, and Controllers. This separation allows developers to manage different aspects of an application separately, promoting code organization, reusability, and maintainability.

Understanding MVC Architecture
MVC, or Model-View-Controller, is a fundamental concept in Rails. Here's a brief overview of each component:

Model: Represents the application's data and business logic. It interacts with the database and encapsulates the rules governing data manipulation.
View: Handles the presentation layer and displays data to users. It generates the user interface and often includes HTML templates.
Controller: Acts as an intermediary between the Model and View. It processes user requests, interacts with the Model to retrieve or modify data, and renders the appropriate View.

Why Choose Ruby on Rails?
Ruby on Rails offers several advantages that make it a preferred choice for web development:

Convention over Configuration: Rails follows sensible conventions, reducing the need for extensive configuration. This speeds up development and encourages consistency.
DRY Principle (Don't Repeat Yourself): Rails promotes code reuse and modular design, minimizing redundancy and making maintenance easier.
Gems and Plugins: Rails provides a rich ecosystem of Gems (libraries) and Plugins that extend its functionality, allowing developers to add features without starting from scratch.
Rapid Development: With built-in tools for common tasks, such as database migrations and scaffolding, Rails accelerates the development process.

When to Use Ruby on Rails
Ruby on Rails is an excellent choice for various web application scenarios:

Prototyping: Quickly create prototypes to test ideas and concepts.
Startups: Build an MVP (Minimum Viable Product) rapidly and iterate based on user feedback.
Small to Medium-sized Projects: Rails is well-suited for projects with predefined requirements and budgets.
Developer Productivity: Developers can focus on application logic rather than low-level configurations.

Prerequisites
Before diving into Rails development, ensure you have a basic understanding of programming concepts, HTML, and CSS. Familiarity with the Ruby programming language is helpful but not mandatory.

Setting Up Your Development Environment
To begin coding with Ruby on Rails, you'll need to set up your development environment. This involves installing Ruby, Rails, and other necessary tools. The exact steps depend on your operating system. In the next tutorial, we'll guide you through the installation process for various platforms.

In this tutorial, we introduced you to Ruby on Rails, explored its MVC architecture, highlighted its advantages, and discussed scenarios where it's an optimal choice. As you continue through this series, you'll dive deeper into each aspect of Rails development, learning how to build full-fledged web applications from scratch.

Stay tuned for the next tutorial, where we'll walk you through the process of setting up your development environment and getting your first Ruby on Rails application up and running. Happy coding!

Ruby on Rails ActiveRecord Associations

Eapen Zacharias — Tue, 12 Jul 2022 18:31:20 +0000

Much of the power of Ruby on Rails lies in creating good associations to keep our data well organized, so that it can be used efficiently.

There are three main association types.

One-to-One Association: One object is related with one and only object.
Example: If there are two entities Person(Id, Name, Age, Address) and Passport(Passport_id, Passport_no). So, each person can have only one passport and each passport belongs to only one person.
One-to-Many Association: One object has many objects and many objects belongs to the One object.
Example: If there are two entity type Customer and Account then each Customer can have more than one Account but each Account is held by only one Customer. In this example, we can say that each Customer is associated with many Account. So, it is a one-to-many relationship. But, if we see it the other way i.e many Account is associated with one Customer then we can say that it is a many-to-one relationship.
Many-to-Many Association: Each object of the first class can be related to one or more than one object of the second class and a single object of the second class can be related to one or more than one object of the first class.
NOTE: For using Many-to-Many association we need a joint table as we can’t include many foreign keys to a table. A joint table serves as a way to make links between two different tables. The joint table will have foreign keys of each pair of related objects from the both tables.
Example: If there are two entity type Customer and Product then each customer can buy more than one product and a product can be bought by many different customers.

Association Method

One-to-One relationships: has_one, belongs_to, has_one :through
One-to-Many relationships: has_many, belongs_to
Many-to-Many relationships: has_and_belongs_to_many, has_many :through

`belongs_to` Association

A belongs_to association sets up a connection with another model, and declares model "belongs to" one instance of the other model.

Note: When you define belongs_to inside a model, the other object that that belongs_to is not optional. If it belongs to it, then that other object has to be assigned. This happens because Rails adds a validation that check if the referenced object is present. Please also note that order versions of Rails do not do that.
You can disable this validation by passing {:optional => true}

For example, if your application includes person and passport, and each passport can be assigned to exactly one person, you'd declare the passport model this way:

class Passport < ApplicationRecord
  belongs_to :person # this validates the presence of the person object
end

class Passport < ApplicationRecord
  belongs_to :person, optional: true # does not validates the presence of the person object
end

`has_one` Association

A has_one association shows that another model is referenced to this model. That model can be fetched through this association.

For example, if each person in your application has only one passport, you'd declare the person model like this:

class Person < ApplicationRecord
  has_one :passport
end

`has_many` Association

A has_manyassociation indicates a one-to-many connection with another model and often used with belongs_to on the other model. This association declares that each instance of the model has zero or more instances of another model.

For example, in an application containing customers and accounts, the customers model could be declared like this:

class Customer < ApplicationRecord
  has_many :accounts
end

`has_many :through` Association

A has_many :through association is used to set up a many-to-many connection with another model. This declares a model can be matched with zero or more instances of another model through a third model.
For example, consider a online shop where customers make purchases to get products. The association declarations could look like this:

class Customer < ApplicationRecord
  has_many :purchases
  has_many :products, through: :purchases
end

class Purchase < ApplicationRecord
  belongs_to :customer
  belongs_to :product
end

class Product < ApplicationRecord
  has_many :purchases
  has_many :customers, through: :purchases
end

`has_one :through` Association

A has_one :through association sets up a one-to-one connection with another model through a third model. This declares the model can be matched with one instance of another model through a third model.

For example, if each person has one passport, and each passport is associated with one passport_issue, then the models could look like this:

class Person < ApplicationRecord
  has_one :passport
  has_one :passport_issue, through: :passport
end

class Passport < ApplicationRecord
  belongs_to :person
  has_one :passport_issue
end

class PassportIssue < ApplicationRecord
  belongs_to :passport
end

`has_and_belongs_to_many` Association

A has_and_belongs_to_many association creates a direct many-to-many connection with another model, without the help of a third model and declares this model can be matched with zero or more instances of another model

For example, if your application includes assemblies and parts, with each assembly having many parts and each part appearing in many assemblies, you could declare the models this way:

class Assembly < ApplicationRecord
  has_and_belongs_to_many :parts
end

class Part < ApplicationRecord
  has_and_belongs_to_many :assemblies
end

Choosing Between has_many :through and has_and_belongs_to_many: The simplest rule of thumb is that you should set up a has_many :through relationship if you need to work with the relationship model as an independent entity. If you don't need to do anything with the relationship model, it may be simpler to set up a has_and_belongs_to_many relationship (though you'll need to remember to create the joining table in the database).

Polymorphic Associations

A polymorphic association allows a model to belong to multiple other models. In this case, we might create a Profile model and a Blog model, and both have many references to Images.

class Image < ApplicationRecord
  belongs_to :imageable, polymorphic: true
end

class Profile < ApplicationRecord
  has_many :images, as: :imageable
end

class Blog < ApplicationRecord
  has_many :images, as: :imageable
end

We can consider polymorphic belongs_to declares that any models can set up an interface with model and use it. In this case we can retrieve an image from a profile instance using @profile.image and a collection of images from a blog instance using @blog.images

Additional Features in ActiveRecords

`:dependent => :destroy`

When the object is destroyed, destroy will be called on its associated objects.

Example: In this case when a user is deleted all the comments created by the user also gets destroyed

class User < ApplicationRecord
    has_many :comments, dependent: :destroy
end

class Comment < ApplicationRecord
    belongs_to :user
end

`:dependent => :delete_all`

The difference here is that :delete_all, like the delete_all method, is skipping the callbacks that are in that comment object. It just goes straight to the database, and writes SQL to delete them. Destroy is a safer choice, because comment may have callbacks as well.

class User < ApplicationRecord
    has_many :comments, dependent: :delete_all
end

class Comment < ApplicationRecord
    belongs_to :user
end

Joining Tables

Once we have associations between our models, we can start to work with them in interesting ways. And one of those ways is by joining tables during our queries. If you're familiar with working with databases, you'll know that there are times when we want to be able to join two different tables together during a query. So we can query columns on more than one table.

We can use SQL joins to query columns on several tables.

Example: The given code will return Products for which its category is active

Product.joins(:category).where('categories.active = 1')
# or you can use a hash format
Product.joins(:category).where(categories: {active: true})

Here are the few ways we can join a table:

Using a String SQL Fragment: We can provide the raw SQL specifying the JOIN clause Author.joins("INNER JOIN books ON books.author_id = authors.id AND books.out_of_print = FALSE")
Joining a Single Association: Product.joins(:category)
Joining Multiple Associations: Product.joins(:category, :inventory)

By joining tables together with the joins method, you have the ability to start working with your associations in interesting ways.

Thanks For Reading, Follow Me For More
Share your suggestions, doubts and feedback in the comments section!

Ruby on Rails ActiveRecord Callbacks

Eapen Zacharias — Tue, 05 Jul 2022 23:54:48 +0000

Callbacks are a way that ActiveRecord gives us to intervene in an object's life cycle.
It's almost like it pauses before or after key moments in its internal processes, to check in with you to see if you have code customization that you'd like to run before it continues. It allows you then to run code automatically before or after an Active Record object is created, saved, updated, deleted, validated, or loaded from the database.

We could use this callbacks to perform various tasks:

Set values for the current record
Create, update or destroy other records
Perform cleanup and housekeeping tasks
Log information
Send an email or make an API call

The order of callbacks is before, around, after.

before: happens before the action happens

around: can have logic before and after the action being run. The code before yield is invoked before the action and the code after is called after the action

example:

around_create :method_name

def method_name
  logger.info('Before action code')
  yield
  logger.info('After action this will run')
end

after : runs after an action is complete

Here is a list of Rails inbuilt Active Record Callback methods:

Creating an Object

before_validation Defines a callback that will get called right before validation.
after_validation Defines a callback that will get called right after validation.
before_save Registers a callback to be called before a record is saved.
around_save Registers a callback to be called around the save of a record.
before_create Registers a callback to be called before a record is created.
around_create Registers a callback to be called around the creation of a record.
after_create Registers a callback to be called after a record is created.
after_save Registers a callback to be called after a record is saved.
after_commit This callback is called after a record has been created, updated, or destroyed. Example: after_commit :do_baz, on: :destroy after_commit :do_bar_baz, on: [:update, :destroy]
- after_create_commit: Shortcut for after_commit :hook, on: :create
- after_destroy_commit: Shortcut for after_commit :hook, on: :destroy
- after_save_commit: Shortcut for after_commit :hook, on: [ :create, :update ]
- after_update_commit: Shortcut for after_commit :hook, on: :update
after_rollback This callback is called after a create, update, or destroy are rolled back. Note that all options of after_commit works for after_rollback too.

Updating an Object

before_validation
after_validation
before_save
around_save
before_update Registers a callback to be called before a record is updated.
around_update Registers a callback to be called around the update of a record.
after_update Registers a callback to be called after a record is updated.
after_save
after_commit / after_rollback

Destroying an Object

before_destroy Registers a callback to be called before a record is destroyed.
around_destroy Registers a callback to be called around the destruction of a record.
after_destroy Registers a callback to be called after a record is destroyed.
after_commit / after_rollback

Use Callbacks to Automate Actions

In order to use the available callbacks, you need to register them. You can implement the callbacks as ordinary methods and use a macro-style class method to register them as callbacks:

class User < ApplicationRecord
  validates :login, :email, presence: true

  before_validation :ensure_login_has_a_value

  private
    def ensure_login_has_a_value
      if login.nil?
        self.login = email unless email.blank?
      end
    end
end

The macro-style class methods can also receive a block. Consider using this style if the code inside your block is so short that it fits in a single line:

class User < ApplicationRecord
  validates :login, :email, presence: true

  before_create do
    self.name = login.capitalize if name.blank?
  end
end

Callbacks can also be registered to only fire on certain life cycle events:

class User < ApplicationRecord
  before_validation :normalize_name, on: :create

  # :on takes an array as well
  after_validation :set_location, on: [ :create, :update ]

  private
    def normalize_name
      self.name = name.downcase.titleize
    end

    def set_location
      self.location = LocationService.query(self)
    end
end

Conditional Callbacks

By default callbacks will run all the time at the point at which you've registered them to execute. But we can also execute callbacks conditionally. You can tell your model to execute callback methods only when a particular condition is met.

We can do this by using the following options:

:if
:unless

Here are few examples:

class User < ApplicationRecord
  validates :name, presence: true, if: :admin?

  def admin?
    conditional here that returns boolean value
  end
end

# For negative conditional you can use unless
class User < ApplicationRecord
  validates :first_name, presence: true, unless: Proc.new { |user| user.last_name.present? }
end

# You can also pass a string, which will be executed via instance_eval
class User < ApplicationRecord
  validates :first_name, presence: true, if: 'last_name.blank?'
end

Skipping Callbacks

Every now and then it's useful to be able to skip callbacks specially when we just have to update .

The first way is that if you have an instance of an object and you want to update it, you can call update_column or update_columns, or if you want to get rid of an object without having any callbacks, you can call delete. Normally the method we use is destroy. Destroy does activate our callbacks, but delete does not. The reason these three methods skip our callbacks is because all three of them, construct SQL to submit directly to the database.
Usage:

instance.update_column(name, value)
instance.update_columns(name => value, name => value)
instance.delete

The other way we skip callback is if we have an ActiveRecord relation. We can either call update_all or delete_all on those relations.

Usage:

relation.update_all
# example:
Product.where("modified_at < ?", 2.years.ago).update_all(active: false)

relation.delete_all
# example:
Product.where("created_at < ?", 5.years.ago).delete_all

Note: You can also use conditional callbacks to skip a callback for part of the business logic of your application.

Thanks For Reading, Follow Me For More
Share your suggestions, doubts and feedback in the comments section!

Ruby on Rails ActiveRecord Validations

Eapen Zacharias — Tue, 05 Jul 2022 20:29:29 +0000

Validations allow us to make sure that data meets a set of requirements before it's saved to the database. You can think of them as rules that our data must follow. It is always a good practice to check the validations from the models to make our models smarter by telling them about what should be considered valid data in the database and also regardless of where we're submitting data from the application, it'll still follow the rules.

Built in Validation Methods

Rails provided many inbuilt validation helpers which covers most use cases when you are building an app. Here are the most important ones:

# validates_presence_of validates the attribute is not blank

validates_presence_of :atrr_name

# Validates_length_of check length requirements of the attribute

validates_length_of :attr_name, :within => 3..40
validates_length_of :attr_name, :is => 40
validates_length_of :attr_name, :minimum => 10, :maximum => 50

:minimum - The attribute cannot have less than the specified length.
:maximum - The attribute cannot have more than the specified length.
:in (or :within) - The attribute length must be included in a given interval. The value for this option must be a range.
:is - The attribute length must be equal to the given value.

# Validates_numecality_of check if the attribute is a number or not

validates_numericality_of :height, :greater_than => 3.0
validates_numericality_of :height, :less_than => 100
validates_numericality_of :height, :equal_to => 3.0
validates_numericality_of :height, :greater_than_or_equal_to => 3.0
validates_numericality_of :height, :less_than_or_equal_to => 100

:greater_than - Specifies the value must be greater than the supplied value. The default error message for this option is "must be greater than %{count}".
:greater_than_or_equal_to - Specifies the value must be greater than or equal to the supplied value. The default error message for this option is "must be greater than or equal to %{count}".
:equal_to - Specifies the value must be equal to the supplied value. The default error message for this option is "must be equal to %{count}".
:less_than - Specifies the value must be less than the supplied value. The default error message for this option is "must be less than %{count}".
:less_than_or_equal_to - Specifies the value must be less than or equal to the supplied value. The default error message for this option is "must be less than or equal to %{count}".
:other_than - Specifies the value must be other than the supplied value. The default error message for this option is "must be other than %{count}".
:in - Specifies the value must be in the supplied range. The default error message for this option is "must be in %{count}".
:odd - Specifies the value must be an odd number if set to true. The default error message for this option is "must be odd".
:even - Specifies the value must be an even number if set to true. The default error message for this option is "must be even".

# Validates_inclusion_of checks to see if an attribute is in a list of choices, and you need to provide it an array or a range for it to look in.
# Validates_exclusion_of checks to see if it is not present in the list of choices

validates_inclusion_of :status, :in => ['new', 'created', 'approved', 'deleted']
validates_exclusion_of :status, :in => [55, 66, 77]

# Validates_format_of check if it matches regex

validates_format_of :zipcode, :with => /\d{6}/

# Validates_uniqueness_of is going to make sure that an attribute is not already in the database.

validates_uniqueness_of :user_name, :case_sensitive => false
validates_uniqueness_of :teacher_id, scope: [:semester_id, :class_id]
 # Making sure that a teacher can only be on the schedule once per semester for a particular class.

# Validates_confirmation_of Encapsulates the pattern of wanting to validate a password or email address field with a confirmation


 validates_confirmation_of :user_name, :password
 validates_confirmation_of :email_address,
                              message: 'should match confirmation'
# The added password_confirmation attribute is virtual; it exists only as an in-memory attribute for validating the password. To achieve this, the validation adds accessors to the model for the confirmation attribute.
# NOTE: This check is performed only if password_confirmation is not nil. To require confirmation, make sure to add a presence check for the confirmation attribute:

# Validates_associated is used to check associations with other models, so it check the validity of the associated model

class Library < ApplicationRecord
    has_many :books
    validates_associated :books
end

# Validates_acceptance_of is typically used when the user needs to agree to your application's terms of service, confirm that some text is read, or any similar concept. This method creates a virtual attribute and it is not saved to the database.

validates_acceptance_of :terms_of_service

# Validate multiple parameters in one go

validates :attr_name,
    :presence => boolean,
    :numericality => boolean,
    :length => option_hash,
    :format => {:with => regex},
    :inclusion => {:in => range_or_array},
    :exclusion => {:in => range_or_array},
    :acceptance => boolean,
    :uniqueness => boolean,
    :confirmation => boolean

Custom Validations

Most of the time, the built-in validations that Ruby on Rails gives you, are going to be enough to help you keep your data under control. But every now and then there's some special cases that come up where they're not enough and we'd like to be able to write our own custom validations. Well, Ruby on Rails lets us do that too.

validate :custom_method

private

def custom_method
    if test_case
        error.add(:attribute, "error message")
        # You can use :base as attribute name if the error is not specific to an attribute 
    end
end

Skipping Validation

Skipping validations bypasses the data rules that you've established for the application and it should be done with extreme caution because you could actually introduce invalid data into the database and that could have severe consequences to the application.
Here are few ways to do that.

record.save(validate: false)
record.update_columns(:name => value) # This directly updates the database
record.update_column(:name, value)

When you have an active record relation, you've built up like a relation defined using where clauses to find the record you want, then you can call, update all and provide a hash of values and it will go and do update columns ****on all of those records without actually finding them.

relation.update_all(:name => value)

Thanks For Reading, Follow Me For More
Share your suggestions, doubts and feedback in the comments section!

Forem: Eapen Zacharias

Introduction to Ruby on Rails: Getting Started with Web Development

Ruby on Rails ActiveRecord Associations

Association Method

belongs_to Association

has_one Association

has_many Association

has_many :through Association

has_one :through Association

has_and_belongs_to_many Association

Polymorphic Associations

Additional Features in ActiveRecords

:dependent => :destroy

:dependent => :delete_all

Joining Tables

Ruby on Rails ActiveRecord Callbacks

Creating an Object

Updating an Object

Destroying an Object

Use Callbacks to Automate Actions

Conditional Callbacks

Skipping Callbacks

Ruby on Rails ActiveRecord Validations

Built in Validation Methods

Custom Validations

Skipping Validation

`belongs_to` Association

`has_one` Association

`has_many` Association

`has_many :through` Association

`has_one :through` Association

`has_and_belongs_to_many` Association

`:dependent => :destroy`

`:dependent => :delete_all`