DEV Community: Abd ElRahman Shawareb

Arel and Ruby on Rails

Abd ElRahman Shawareb — Sun, 05 Mar 2023 13:40:43 +0000

Hi RoR folks! Hope you are all doing well and celebrating Ruby's birthday!

Today in this post we are gonna talk about Arel and here is a list of what we are gonna discuss:

What is Arel?
History of Arel
Advantages of using Arel
Arel basic syntax
Conclusion

What is Arel?

Arel is a library that is being used to help us to write SQL queries in a much easier, more readable, and cleaner way. Also, it helps us to write both simple and complex queries.

History of Arel

Arel was introduced in Rails 3 but it is now bundled into the Active Record gem, and maintained in the rails/rails repository.

Advantages of using Arel

Readability

Since all SQL queries are strings, it may be hard to read, edit, or break down a complex query.
Reusability

It’s much easier to reuse Arel queries as they are made up of interlinking nodes – a safer alternative than string interpolation.
Reliability

If we join another table, our query will immediately break due to the ambiguity of the id column. Even if we qualify the columns with the table name, this will break as well if Rails decides to alias the table name.

Arel basic syntax

- Arel Table

TTo start creating queries, we need to decide which Model we are going to query on. Then, we need to interact with the Arel Table for that Model and this could be done by using the arel_table method

users = User.arel_table

Here there is an Arel::Table object created for that table we are going to work on. After that object is created for that data table, Arel converts each column of that Table into an Arel::Node that we can execute different methods that are supported by this library on it. The most common methods in Arel are:

Equal (eq)
Not Equal (not_eq)
Greater Than (gt)
Less Than (lt)
Greater Than Or Equal (gteq)
Less Than Or Equal (lteq)
Or (or)
And (and)

NOTE: To see all Arel predications you can run: Arel::Predications.instance_methods

- Where queries

We can say that more than 75% of all the queries are built using where method cause it's used to filter our data and select a specific part based on a specific true condition. Since where method can take different kinds of arguments, we can pass custom-built Arel queries to it and this could be so powerful.

NOTE: To break a query to use Arel, there's a good rule to break out a method anywhere the word AND or OR is used.

class UserMembershipQuery
  def members
    users = User.where(public_profile.and(group_member))
  end

  private

  def table
    User.arel_table
  end

  def public_profile
    table[:private].eq(false)
  end

  def group_member
    table[:group_member].eq(true)
  end
end

users[:id].in([1,2,3]).to_sql
=> "`users`.`id` IN (1, 2, 3)"

users[:id].gt(2).to_sql
=> "`users`.`id` > 2"

users[:id].eq(3).to_sql
=> "`users`.`id` = 3"

User.where(table[:id].in([1,2,3])).to_sql
# SELECT "users".* FROM "users"  WHERE "users"."id" IN (1, 2, 3)

- Projection queries

Projection queries are the same as the select queries, we use the project to specify the nodes we want to select or return. This would need to be executed directly as SQL and can not easily be combined with ActiveRecord queries.

User.where(table[:role].eq(:admin)).project(:email).to_sql
=> "SELECT email FROM `users` WHERE `users`.`role` = 2"

And to connect these queries with the Active Record is a little bit more complex:

ActiveRecord::Base.connection.exec_query User.where(users[:role].eq(:admin)).project(:email)

- Joins

Here where we can see that Arel is really useful, cause writing join queries using Arel is a lot more simple and readable than SQL.

subscriptions = Subscription.arel_table
table.join(subscriptions)

Yes! It's that simple! We can also determine the relationship

table.join(subscriptions, Arel::Nodes::OuterJoin).on(table[:id].eq(subscriptions[:user_id]))

And to write join with a condition

table.joins(:subscriptions).merge(Subscription.where(active: true))

There are other methods that we can use to scope different queries:
Like sum, average, count, min, and max that we can use to perform different operations on values

table.project(table[:rate].average)

Conclusion

In this article, we slightly discussed the basics of Arel like what's it and its history and its basic syntax but it has a lot more stuff that could be very helpful on, and there's a lot more to learn about it, so, I recommend you to go through Arel documentation and get your hand dirty and start using it.
If u have any comments or any feedback I will be happy to hear from your side.

Reviewed by Farha Zane ❤︎

Adding Markdown to your Rails application

Abd ElRahman Shawareb — Tue, 08 Jun 2021 15:33:10 +0000

In this guide I will show you how to add markdown to your rails application. We will use redcarpet gem and I assume that you have created your rails application that we will work on.

Install redcarpet

To install redcarpet gem go to your Gemfile and add:

# Gemfile 
gem "redcarpet"

then run the following command:

$ bundle install

Generating a resource

After we successfully installed our gem, we need a recourse to work with and test our work, so we will create Post scaffold to work with.

To create the Post scaffold run the following commands:

$ rails generate scaffold Post title:string body:text

$ rails db:migrate

Extracting logic to a helper

After we successfully installed redcarpet gem and created our scaffold it's the time to add markdown to our application.

In order to be DRY (don't repeat yourself) we will create a helper method to use whenever we want to add markdown. So in our application_helper.rb we will add the following code:

def markdown(text)
    options = %i[
      hard_wrap autolink no_intra_emphasis tables fenced_code_blocks
      disable_indented_code_blocks strikethrough lax_spacing space_after_headers
      quote footnotes highlight underline
    ]
    Markdown.new(text, *options).to_html.html_safe
  end

This method titled markdown will take a text as an argument and will be the output of Post body field. Notice the options variable defined with an array of settings you can pass to Redcarpet. These dictate what you do and don't want when it comes to rendering markdown within your app.

Now let's use this helper in our views

<p id="notice"><%= notice %></p>

<p>
  <strong>Title:</strong>
  <%= @post.title %>
</p>

<p>
  <strong>Body:</strong>
  <%= markdown(@post.body) %>
</p>

<%= link_to 'Edit', edit_post_path(@post) %> |
<%= link_to 'Back', posts_path %>

And congratulation you have added markdown to your application.

1. Introduction to Design Patterns

Abd ElRahman Shawareb — Sat, 20 Mar 2021 14:26:43 +0000

Hi everyone, it is the first article of my Design Patterns series. In this series, we will understand almost everything related to Design Patterns. So let's start with an introduction.

Introduction

In Software Engineering you may face the same design problems again and again and of course, there are many ways to solve these problems, but to avoid more problems in the future when you try to maintain your code, we need to use flexible and reusable solutions. One of these preferred solutions is that of design patterns.

What is Design Pattern?

A design pattern is a practical proven solution to a common design problem. It is like the best practices used by expert software engineers to solve this problem and these solutions help us to speed the process of development because you don't have to think, create and build a solution every time you face these problems. Also, a design pattern is not a standard piece of code that you just put in your code and the problem is solved, it is more like a model that you can modify to be suitable to use in your problem.

Gang of Four (GoF)

Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides are the authors of the famous book Design Patterns: Elements of Reusable Object-Oriented Software. They introduced 23 patterns of design in this book based on their experience as developers. Those patterns -which were introduced by GoF- are considered the foundation for all other patterns.

Categories of Design Patterns

Gang of Four patterns can be categorized into three groups:

1. Creational Patterns

Creational Patterns help us to deal with creating or cloning new objects. Creational Patterns are:

Factory Method
Abstract Factory
Builder
Singleton
Object Pool
Prototype

2. Structural Patterns

Structural Patterns help us to describe the connections between objects. These patterns relate to design principles of decomposition and generalization. Structural Patterns are:

Adapter
Bridge
Composite
Decorator
Facade
Flyweight
Private Class Data
Proxy

3. Behavioral Patterns

Behavioral Patterns help us to describe how each object performs a single cohesive function and describe how independent objects work towards a common goal. Behavioral Patterns are:

Chain of Responsibility
Command
Interpreter
Iterator
Mediator
Memento
Null Object
Observer
State
Strategy
Template method
Visitor

Elements of a Design Pattern

The Gang of Four's book tells us that each pattern has four essential elements:

The Name - Used to describe a design problem, its solutions, and consequences in a word or two.
The Problem - describes when to apply the pattern and explains the problem and its context.
The Solution - that describes the elements that make up the design, the relationships, the responsibilities, and collaborations. The solutions do not describe a concrete implementation, because a pattern is like a template that can be applied in many different situations, but provides an abstract description of a design problem and how a general arrangement of elements (classes and objects) solves it.
The consequences - the results of applying the pattern.

Reasons to use Design Patterns

There are many reasons to use design patterns. As we said before it makes the process of implementation faster because we don't have to think and build a solution for a problem every time we face it. It also defines a common language to make it easier to communicate between team members.

Conclusion

In this article, we give a quick introduction to design patterns and discussed categories of design patterns, elements of each pattern, and why we should use design patterns. In the following articles, we will talk in detail about each pattern and how to use design patterns.

SOLID Principles: For maintainable, flexible, and extensible code

Abd ElRahman Shawareb — Tue, 09 Feb 2021 04:50:40 +0000

Hi everyone, in this article, we will talk about SOLID principles.

Introduction

The SOLID principles were introduced by Robert C. Martin (Uncle Bob). The intention of these principles is to help us write maintainable, flexible, and extensible code. and by applying these principles in our design we can also avoid code smells and refactor our code.

SOLD Stands for:

S - Single-responsiblity Principle
O - Open-closed Principle
L - Liskov Substitution Principle
I - Interface Segregation Principle
D - Dependency Inversion Principle

Examples will be given in Ruby, but these principles can be applied to any OOP language.

Single-responsibility Principle (SRP)

Single-responsibility Principle (SRP) states that "A class should have only a single responsibility."
let's simplify this definition together, What does single responsibility mean? simply it means that our class should only have one reason to change and will happen if our class only has one job.

The concept behind (SRP) sounds simple and clear but to apply this principle in your design you have to spend some time since a class’s responsibility isn’t always clear.

The following example of code does not follow the SRP

FinancialReportMailer handles two tasks (generate_report!) and (send_report) as shown above, So why this class does not apply the SRP principle? let's answer this question by asking one more question, What is the main responsibility of this class? is it to generate the financial report or send it? So according to this principle, we should divide the FinancialReportMailer class into two classes.

Now let's refactor our class and apply SRP

After refactoring, we have two classes that each perform exactly one task. So if we wanted to expand the class responsible for report generation in the future, we could simply make the necessary changes without having to touch the FinancialReportMailer class.

Open-closed Principle (OCP)

Open-closed Principle (OCP) states that "Objects or entities should be open for extension but closed for modification"
That means we need to design our classes to be extendable without modifying the class itself.

This principle is important to follow to design a system that is easy to modify and extend in the future

Now let's take an example that does not follow the OCP.

The Logger class formats and sends logs. But the OCP principle is not followed, since we will have to modify the logger every time we need to add additional senders or formatters:

Now let's refactor this code

In the example above, we have segregated senders and formatters to separate classes and enabled the addition of new senders and formatters without having to modify the base code.

Liskov Substitution Principle (LSP)

Liskov Substitution Principle (LSP) states that "If S is a subtype of T, then objects of type T may be replaced with objects of type S"
It sounds confusing, but do not worry, we will simplify it together. Let's break down the definition into small manageable pieces, from the definition of the principle we know that we are going to be working with parent and child classes, this tells us that the principle revolves around the object-oriented inheritance. Also from the definition, it sounds like programs have to be able to allow for child classes to seamlessly replace parent classes, and to make this happen we should ensure that our parent and child classes cannot have requirements that would cause conflicts.

Now that we know what the LSP principle is getting at, let's look at an example that violates LSP.

In the example above, we are implementing user statistics. There are two classes: a base class (UserStatistic) and its child class (AdminStatistic). The child class violates the LSP principle since it completely redefines the base class by returning a string with filtered data, whereas the base class returns an array of posts.

Now let's refactor this code

To apply LSP, we can segregate the filtration logic and the statistics string generation logic into two methods: “posts“ and “formatted_posts“. Therefore, we refactored the method posts that filtrate user posts, so the method returns the same type of data as the base class.

Interface Segregation Principle (ISP)

Interface Segregation Principle states that "Clients should not be forced to depend upon interfaces that they don't use."
More simply: Do not add additional functionality to an existing interface by adding new methods. we should get the interfaces segregated according to their purpose, so we avoid “fat” classes and code that’s hard to maintain. In our design, we should not force our classes to implement unneeded methods (Dummy implementation).

"Several client-specific interfaces are better than one generalized interface."

Now let's take an example that does not apply ISP.

In the example above, we have a piece of code that represents a coffee vending machine interface. As you can see, the interface is used by two types of users: a Person and a Staff. Each uses only a few interface abilities, however. For example, the class Person uses only the following methods: “select_drink_type“, “select_portion“, “select_sugar_amount“, and “brew_coffee“. The ISP principle tells that one class should contain only the method it uses.

To refactor this code, we created two interfaces: a separate user interface and a separate staff interface. In the “CoffeeMachineUserInterface,” a user will be able to choose a drink type (method “select_drink_type“), choose a portion size (method “select_portion“), select the amount of sugar they would like added to the drink (method “select_sugar_amount“), and start brewing the coffee (method “brew_coffee“). A staff member, using the “CoffeeMachineSeviceInterface,” will be able to choose among the following operations: clean the machine (method “clean_coffee_machine“), fill sugar (method “fill_sugar_supply“), fill coffee beans (method “fill_coffee_beans“), and fill water supply (method “fill_water_supply“).

With this design segregated in two interfaces, we’ve avoided unused methods and now have two smaller interfaces with methods that perform specific tasks.

Dependency Inversion Principle (DIP)

Dependency Inversion Principle states that "High-level modules should not depend on low-level modules. Both should depend on abstractions. Abstractions should not depend on details. Details should depend on abstractions."

High-level modules = interfaces and abstract classes
Low-level = concrete classes

Uncle Bob claims that the DIP principle is simply the result of strictly following the LSP and OCP. According to Uncle Bob, the code that follows the LSP and OCP should also be extendable, and child classes should be easily replaceable by other instances of a base class without breaking the system.

By using DIP we will be able to increase the reusability of higher-level modules by making them independent of lower-level modules.

In the code below, we have implemented logic for a printer (the Printer class has the method print which performs data output).

The class Printer depends on classes PdfFormatter and HtmlFormatter instead of abstractions, which indicates the violation of the DIP principle since the classes PdfFormatter and HtmlFormatter may contain the logic that refers to other classes. Thus, we may impact all the related classes when modifying the class Printer.

Now let's refactor the code above and apply DIP. Implementation of low-level details (outputting formats like PDF and HTML) is done in separate classes (PDF Formatter and HTML Formatter).

In the code above, the printer ‒ a high-level object ‒ doesn’t depend directly on the implementation of low-level objects ‒ the PDF and HTML formatters. In addition, all modules depend on abstraction. Our high-level functionality is separated from all low-level details, so we’re able to easily change the low-level logic without system-wide implications.

Conclusion

In this article, we discussed the 5 SOLID principles, the benefits of using these principles, and we tried to understand each principle and refactored some examples in each one of the principles.

I wish this article was helpful for you, and thanks for taking the time to read the whole article.

DEV Community: Abd ElRahman Shawareb

Arel and Ruby on Rails

What is Arel?

History of Arel

Advantages of using Arel

Readability

Reusability

Reliability

Arel basic syntax

- Arel Table

- Where queries

- Projection queries

- Joins

Conclusion

Adding Markdown to your Rails application

Install redcarpet

Generating a resource

Extracting logic to a helper

1. Introduction to Design Patterns

Introduction

What is Design Pattern?

Gang of Four (GoF)

Categories of Design Patterns

1. Creational Patterns

2. Structural Patterns

3. Behavioral Patterns

Elements of a Design Pattern

Reasons to use Design Patterns

Conclusion

SOLID Principles: For maintainable, flexible, and extensible code

Introduction

SOLD Stands for:

Single-responsibility Principle (SRP)

Open-closed Principle (OCP)

Liskov Substitution Principle (LSP)

Interface Segregation Principle (ISP)

Dependency Inversion Principle (DIP)

Conclusion