DEV Community: Shrouk Abozeid

Learning Go as a Ruby Developer — Part 4: What can we do with a single "for"

Shrouk Abozeid — Fri, 07 Aug 2026 16:32:53 +0000

So loops in ruby has several ways to implement

10.times do |i|
  puts i
end
while condition
  # ...
end
users.each do |user|
  # ...
end
until finished
  # ...
end

Go looks at all of this and basically says:

We only need one loop.

That loop is for.

Before getting into loops, though, let's look at conditions.

Conditions in Go

Go has the familiar if, else if, and else.

if age >= 18 {
    fmt.Println("Adult")
} else {
    fmt.Println("Minor")
}

The syntax is pretty close to Ruby, but there is one important difference.

Go does not use end.

Ruby:

if age >= 18
  puts "Adult"
else
  puts "Minor"
end

Go uses curly braces to define the block:

if age >= 18 {
    fmt.Println("Adult")
} else {
    fmt.Println("Minor")
}

Coming from Ruby, I had to get used to seeing {} everywhere.

Boolean Operators

The familiar operators are there:

if !active {
    // not active
}

if age == 18 {
    // exactly 18
}

And for inequality:

if age != 18 {
    // not 18
}

So the basic logic isn't particularly difficult to transition to.

It's mostly the syntax that's different.

now going back to loops

The `for` Loop

Go has only one looping construct:

for

The traditional form looks like this:

for init; condition; post {
    // code
}

For example:

for i := 0; i < 10; i++ {
    fmt.Println(i)
}

There are three parts:

Initialization — runs before the first iteration
Condition — checked before every iteration
Post statement — runs after every iteration

This is very similar to the traditional C-style loop.

And this is where my C++ nostalgia started showing up.

Go doesn't have separate times, while, or until loops.

Instead, you use for.

for i := 0; i < 10; i++ {
    fmt.Println(i)
}

One keyword, several forms.

The While-Like `for`

What if we don't need the initialization and post statements?

No problem.

x := 1

for x < 10 {
    fmt.Println(x)
    x++
}

This behaves like a while loop.

In other words:

for condition {
    // ...
}

is Go's version of:

while condition
  # ...
end

This is one of those examples where Go's simplicity starts making more sense.

Instead of introducing another keyword for while, Go reuses for.

Infinite Loops

You can even remove the condition completely:

for {
    // keep going
}

This creates an infinite loop.

Of course, you'll usually want some way to escape it.

That's where break comes in.

x := 1

for {
    if x > 9 {
        break
    }

    fmt.Println(x)
    x++
}

The loop keeps running until the break statement is reached.

Ruby has a similar concept:

x = 1

loop do
  break if x > 9

  puts x
  x += 1
end

Again, Go doesn't need a separate loop construct.

for handles it.

`break` and `continue`

Go also provides the familiar break and continue keywords.

`break`

break exits the loop completely.

for i := 0; i < 10; i++ {
    if i == 5 {
        break
    }

    fmt.Println(i)
}

The loop stops when i reaches 5.

`continue`

continue skips the remaining code in the current iteration and moves to the next one.

for i := 0; i < 10; i++ {
    if i%2 == 0 {
        continue
    }

    fmt.Println(i)
}

This skips even numbers and prints the odd ones.

Ruby has the same concepts:

10.times do |i|
  next if i.even?

  puts i
end

Ruby uses next where Go uses continue.

`range`: The Go Way to Iterate Over Collections

The for loop becomes even more interesting when combined with range.

The range form allows you to iterate over collections such as:

arrays
slices
strings
maps
channels

For example:

names := []string{"Alice", "Bob", "Charlie"}

for index, name := range names {
    fmt.Println(index, name)
}

This gives us both the index and the value.

The output would look conceptually like:

0 Alice
1 Bob
2 Charlie

Comparing `range` with Ruby

In Ruby, I'd probably write:

names = ["Alice", "Bob", "Charlie"]

names.each_with_index do |name, index|
  puts "#{index} #{name}"
end

Or, if I don't need the index:

names.each do |name|
  puts name
end

In Go, range handles both cases.

for index, name := range names {
    fmt.Println(index, name)
}

And if I only care about the value, I can ignore the index:

for _, name := range names {
    fmt.Println(name)
}

The _ tells Go that I intentionally don't need that value.

Switch Statements

Go also has switch for conditional logic.

A simple switch looks like this:

switch name {
case "Moneypenny":
    fmt.Println("Miss Moneypenny")
case "Bond":
    fmt.Println("Bond, James Bond")
case "Q":
    fmt.Println("This is Q")
default:
    fmt.Println("Unknown")
}

Unlike Ruby's case, Go doesn't require an end.

Ruby:

case name
when "Moneypenny"
  puts "Miss Moneypenny"
when "Bond"
  puts "Bond, James Bond"
when "Q"
  puts "This is Q"
else
  puts "Unknown"
end

But there is another interesting form of Go's switch.

Switch Without an Expression

You can leave the value out completely:

switch {
case age < 18:
    fmt.Println("Minor")
case age >= 18:
    fmt.Println("Adult")
}

Each case is essentially a condition.

This can be useful when you have several related conditions.

Ruby's case can also be used for conditional expressions, although the syntax and matching behavior are different.

Multiple Values in a Case

A Go case can match multiple values:

switch name {
case "Moneypenny", "Bond", "Dr No":
    fmt.Println("Secret agent")
default:
    fmt.Println("Unknown")
}

This means we don't need separate cases for every value when they should produce the same result.

`fallthrough`

One thing that caught my attention was fallthrough.

Normally, once a Go switch finds a matching case, it stops.

switch {
case true:
    fmt.Println("first")
case true:
    fmt.Println("second")
}

Only the first case runs.

If you explicitly use fallthrough:

switch {
case true:
    fmt.Println("first")
    fallthrough

case true:
    fmt.Println("second")

case true:
    fmt.Println("third")
}

The first and second cases run, but the third does not.

This is different from the behavior many people might expect from C-style switch statements, where falling through can happen unless you explicitly stop it.

Go makes the behavior explicit with fallthrough.

Go vs Ruby: Control Flow

Here's how the two languages compare.

Concept	Go	Ruby
Condition	`if` / `else`	`if` / `else`
Not	`!`	`!`
Equality	`==`	`==`
Inequality	`!=`	`!=`
Main loop	`for`	Multiple constructs
While loop	`for condition`	`while condition`
Infinite loop	`for {}`	`loop do`
Iterate collection	`for ... range`	`.each`
Skip iteration	`continue`	`next`
Exit loop	`break`	`break`
Switch	`switch`	`case`
Multiple switch values	`case "a", "b"`	`when "a", "b"`

Neither approach is necessarily better.

They're just optimizing for different things.

Design Patterns in Ruby #5: Abstract Factory Pattern

Shrouk Abozeid — Wed, 05 Aug 2026 16:02:00 +0000

In the previous article, we explored the Factory Method pattern and saw how it delegates object creation to subclasses.

But what if your application doesn't need to create just one object?

What if it needs an entire family of related objects that are designed to work together?

That's exactly the problem the Abstract Factory pattern solves.

The Problem

Imagine you're building an e-commerce application that supports multiple payment providers.

Your application currently integrates with:

Stripe
PayPal

For each payment provider, you need several related objects:

A Payment processor
A Refund processor
A Customer service

For Stripe, those objects might be:

StripePayment
StripeRefund
StripeCustomer

For PayPal:

PayPalPayment
PayPalRefund
PayPalCustomer

If you instantiate each object manually, your code quickly becomes filled with conditionals:

if provider == :stripe
  payment = StripePayment.new
  refund  = StripeRefund.new
  customer = StripeCustomer.new
else
  payment = PayPalPayment.new
  refund  = PayPalRefund.new
  customer = PayPalCustomer.new
end

The problem isn't creating a single object anymore.

It's ensuring that all related objects come from the same payment provider.

The client shouldn't accidentally create a StripePayment with a PayPalRefund.

Abstract Factory

The Gang of Four defines Abstract Factory as:

Provide an interface for creating families of related or dependent objects without specifying their concrete classes.

Instead of asking for individual objects, the client asks a factory to provide an entire family.

StripeFactory
 ├── Payment
 ├── Refund
 └── Customer

PayPalFactory
 ├── Payment
 ├── Refund
 └── Customer

The client never knows which concrete classes it's using.

It only communicates with the factory interface.

Structure

The pattern consists of five participants.

Abstract Factory

Defines the interface for creating every product in the family.

create_payment
create_refund
create_customer

Concrete Factory

Implements the Abstract Factory.

Each concrete factory creates one complete product family.

Examples:

StripeFactory
PayPalFactory

Abstract Product

Defines the common interface shared by each product.

Examples:

Payment
Refund
Customer

Concrete Products

The concrete implementations belonging to a specific family.

StripePayment
StripeRefund
StripeCustomer

PayPalPayment
PayPalRefund
PayPalCustomer

Client

The client depends only on the Abstract Factory.

At runtime, it receives whichever concrete factory is needed.

This completely decouples the client from concrete implementations.

Ruby Example

Products

class StripePayment
  def process(amount)
    puts "Charging $#{amount} with Stripe"
  end
end

class StripeRefund
  def process(transaction_id)
    puts "Refunding #{transaction_id} through Stripe"
  end
end

class StripeCustomer
  def create(name)
    puts "Creating Stripe customer: #{name}"
  end
end

class PayPalPayment
  def process(amount)
    puts "Charging $#{amount} with PayPal"
  end
end

class PayPalRefund
  def process(transaction_id)
    puts "Refunding #{transaction_id} through PayPal"
  end
end

class PayPalCustomer
  def create(name)
    puts "Creating PayPal customer: #{name}"
  end
end

Abstract Factory

class PaymentProviderFactory
  def create_payment
    raise NotImplementedError
  end

  def create_refund
    raise NotImplementedError
  end

  def create_customer
    raise NotImplementedError
  end
end

Concrete Factories

class StripeFactory < PaymentProviderFactory
  def create_payment
    StripePayment.new
  end

  def create_refund
    StripeRefund.new
  end

  def create_customer
    StripeCustomer.new
  end
end

class PayPalFactory < PaymentProviderFactory
  def create_payment
    PayPalPayment.new
  end

  def create_refund
    PayPalRefund.new
  end

  def create_customer
    PayPalCustomer.new
  end
end

Client

class CheckoutService
  def initialize(factory)
    @factory = factory
  end

  def checkout(customer_name, amount)
    customer = @factory.create_customer
    payment = @factory.create_payment

    customer.create(customer_name)
    payment.process(amount)
  end

  def refund(transaction_id)
    refund = @factory.create_refund
    refund.process(transaction_id)
  end
end

Using the client:

factory = StripeFactory.new
checkout = CheckoutService.new(factory)

checkout.checkout("Alice", 100)
checkout.refund("txn_123")

Switching to PayPal requires changing only one line:

factory = PayPalFactory.new
checkout = CheckoutService.new(factory)

The rest of the application remains unchanged.

Notice that CheckoutService never references StripePayment, PayPalPayment, or any other concrete implementation.

It only communicates with the Abstract Factory.

Factory Method vs Abstract Factory

Although both patterns deal with object creation, they solve different problems.

Factory Method	Abstract Factory
Creates one product	Creates a family of related products
Uses inheritance	Uses object composition
Subclasses decide what to create	A factory object decides which family to create
Best when object creation varies	Best when entire product families vary

Another way to think about it:

Factory Method asks:

Which object should I create?

Abstract Factory asks:

Which family of objects should I create?

Adding New Products vs New Families

Suppose our payment providers now support webhooks.

We need another product:

create_webhook

With Abstract Factory, the abstract factory interface must change.

class PaymentProviderFactory
  def create_payment; end
  def create_refund; end
  def create_customer; end
  def create_webhook; end
end

Every concrete factory (StripeFactory, PayPalFactory, etc.) must also implement create_webhook.

On the other hand, if you add a completely new payment provider—say Adyen—you simply introduce a new concrete factory:

AdyenFactory
 ├── AdyenPayment
 ├── AdyenRefund
 ├── AdyenCustomer

The existing factories remain unchanged.

That's why people often say:

Factory Method is open to new creators.
Abstract Factory is open to new product families.

Where You'll See It in Rails

Although Rails doesn't explicitly label it as the Abstract Factory pattern, the idea appears in several places.

Active Storage

Depending on your configuration, Rails creates a family of storage-related objects for:

Local Disk
Amazon S3
Google Cloud Storage
Azure Blob Storage

Your application interacts with a common interface while Rails supplies the correct implementation behind the scenes.

When Should You Use It?

Use Abstract Factory when:

Your application works with multiple product families.
Objects within a family should always be used together.
You want to switch implementations through configuration.
You want to isolate your application from concrete classes.

Avoid it when you only need to create a single object. In that case, Factory Method or even a Simple Factory is usually a better fit.

Key Takeaways

The Factory Method pattern creates one object and relies on inheritance to determine which concrete product to instantiate.

The Abstract Factory pattern creates families of related objects and relies on composition to swap entire implementations at runtime.

A simple rule to remember is:

Factory Method answers: Which object should I create?

Abstract Factory answers: Which family of objects should I create?

for a full example in ruby check this https://github.com/ShroukAbozeid/design-pattern/tree/main/factory/abstract_factory

Design Patterns in Ruby #4: Simple Factory vs Factory Method

Shrouk Abozeid — Tue, 04 Aug 2026 15:00:00 +0000

When building applications, creating an object is rarely as simple as calling User.new.

Different objects may require different initialization logic, validation, external API calls, or configuration. If every class is responsible for deciding what object to create, this logic quickly becomes scattered throughout the codebase.

Factory patterns solve this problem by separating object creation from object usage, making the code easier to maintain and extend.

Let's look at the two most common approaches: Simple Factory and Factory Method.

Simple Factory

it is not actually a design pattern by the book but it is commonly used.

it has a very basic idea of encapsulating the objects creation from it’s usage

it has a class ‘Simple Factory’ that contains the logic of creating objects , that factory is used in a “client” to create the objects then use it

Instead of allowing clients to instantiate objects directly, a single factory class becomes responsible for deciding which object should be created.

Structure

A Simple Factory consists of:

A factory class that contains all the object creation logic.
A single factory method that returns different objects based on some condition.
A client that uses the factory instead of creating objects directly.

a naive implementation of simple factory in ruby

class UserSimpleFactory
  def self.create_user(type, user_args)
    case type
    when 'admin'
      Admin.create(name: user_args[:name], email: user_args[:email], password: user_args[:password])
    when 'customer'
      Customer.create(name: user_args[:name], email: user_args[:email], password: user_args[:password])
    when 'guest'
      Guest.create(name: user_args[:name], country: user_args[:country])
   else
     raise 'INVALID_TYPE'
   end
  end
end

class RegisterHandler
  def create_user(params)
    user = UserSimpleFactory.create_user(params[:type], params[:user])
  end

  def register(params)
    user = create_user(params)
    "Hello #{user.name}"
  end
end

Advantages

Centralizes object creation.
Keeps clients from depending on concrete classes.
Easy to understand and implement.

The Problem

This works well while you only have a few product types.

However, every time a new user type is introduced, the factory needs another when branch.

Eventually the factory becomes a large conditional statement responsible for creating every possible object.

This violates the Open/Closed Principle because adding a new product requires modifying an existing class.

at that time you might think to extract parts of this method into different classes and voilà you get a factory method pattern

Factory Method

The Gang of Four defines Factory Method as:

Define an interface for creating an object, but let subclasses decide which class to instantiate.

this pattern lets a class defer instantiation to subclass. and encapsulates the instantation of concrete types

The parent class defines the workflow, while each subclass decides which concrete object should be created.

This removes the need for long case statements and replaces them with polymorphism.

Structure

Abstract creator : it gives you an interface with method(THE factory method) to create object(product), any other method on this class operates on the object returned by the factory method
Concrete creator : is a subclass that implement the factory method
Abstract product; interface(parent) of all products that different concrete creators return
Concrete product must implement the same interface so that the factories can refere to the interface not the concrete classes

this pattern decouples the implementation of the product from its use

class RegisterHandler
  def create_user(user_args)
    raise NotImplementedError
  end

  def register(params)
    user = create_user(params)
    "Hello #{user.name}"
  end
end

class AdminRegister < RegisterHandler
  def create_user(user_args)
    Admin.create(name: user_args[:name], email: user_args[:email], password: user_args[:password])
  end
end

class CustomerRegister < RegisterHandler
  def create_user(user_args)
    Customer.create(name: user_args[:name], email: user_args[:email], password: user_args[:password])
  end
end

class GuestRegister < RegisterHandler
  def create_user(user_args)
    Guest.create(name: user_args[:name], country: user_args[:country])
  end
end

Notice that the register method is implemented only once.

The only thing subclasses customize is how the user is created.

The registration workflow remains unchanged regardless of the user type.

Advantages

Eliminates large conditional statements.
Follows the Open/Closed Principle.
Makes it easy to introduce new product types.
Uses polymorphism instead of branching logic.
Keeps creation logic isolated inside dedicated creator classes.

The trade-off is that it introduces more classes, which can feel unnecessary for small applications.

Did you know that Rails framework is full of Factory patterns? 👀

Example: Action Mailer

Every mailer inherits from ApplicationMailer

When you define

class UserMailer < ApplicationMailer
  def welcome(user)
    mail(to:user.email)
  end
end

The framework handles the workflow of building and delivering an email.

Your subclass supplies the message-specific details.

Example: Active Job adapters

You write:

class SendEmailJob < ApplicationJob
end

Then configure:

config.active_job.queue_adapter = :solid_queue

config.active_job.queue_adapter = :sidekiq

Each adapter creates its own queue implementation.

Rails defines the workflow.

The adapter subclasses provide the implementation

Key Takeaways

A Simple Factory centralizes object creation using conditional logic. It's a pragmatic solution for smaller applications but becomes harder to maintain as the number of products grows.

Factory Method takes a different approach by replacing those conditionals with polymorphism. Instead of modifying one factory every time a new product is added, you create a new creator class that knows how to build that product.

A good rule of thumb is this:

If your factory keeps getting longer every time you introduce a new product, it's probably time to replace it with Factory Method.

for a full example in ruby check this https://github.com/ShroukAbozeid/design-pattern/tree/main/factory

Snehal Ahire - Rails Under a Microscope: Summarized with AI

Shrouk Abozeid — Wed, 29 Jul 2026 13:12:23 +0000

Sometimes I'm lazy to talk notes myself(which ofcourse is better) but instead of not talking notes at all i let ai summarize what i just watched to make sure i didn't drop anything.

in this video Snehal Talks about performance problems that developers can face in large scale application and what could be some of the causes.

So here is her talk in points :D

Rails Performance Challenges

Performance issues in Rails applications, such as slow listing pages, delayed search queries, and long-running Sidekiq batches, cause significant frustration for both users and developers.
Persistent performance bottlenecks lead to increased infrastructure costs and delays in feature development, making performance optimization a necessity for application survival.
While developers may be tempted to rewrite slow Rails applications in languages like Rust or Go, such rewrites are often risky and costly; instead, applications should be analyzed to identify specific bottlenecks.

Data Retrieval Optimization

Code that appears innocent in the early stages of an application can evolve into a performance bottleneck as the system scales over many years.
Common performance issues in mature applications include memory bloat, memory leaks, and inefficient database queries.
Fetching unnecessary data, such as loading all columns when only a few are needed, is inefficient and becomes increasingly problematic as the number of rows grows into the millions.
Developers should optimize data retrieval by selecting only the specific columns required for the task.

Pagination Strategies

Standard pagination using offset is suitable for small datasets but becomes inefficient for large databases because the system must scan and discard all preceding records to reach the requested page.
Keyset pagination is a more efficient alternative for large datasets because it fetches only the required data without scanning and discarding previous records.
Keyset pagination is index-friendly, leveraging indexed columns like ID or created_at to provide consistent performance regardless of how deep into the dataset the user navigates.
Keyset pagination is an effective strategy for features like "Load More" or infinite scrolls because it uses pointers from the last row of a previous page to start the next query, though it prevents direct navigation to specific page numbers.

Query and Caching Best Practices

To prevent N+1 queries, Rails 7 and later versions offer strict loading features that can be used during development to avoid accidental performance issues.
Caching should only be implemented when the value of recomputing data exceeds the costs associated with cache maintenance and invalidation, as improper caching can negatively impact performance.

Memory Management and Heap Fragmentation

Memory bloat occurs when there is a significant discrepancy between the actual size of live objects in an application and the Resident Set Size (RSS) reported by the system.
The Memory Profiler gem is a tool used to diagnose memory issues by identifying memory allocations and retained objects, categorized by gem, location, class, or specific line of code.
Memory consumption in Ruby is often driven by arrays, strings, and hashes, which are dynamic allocations stored in the heap, while static functions are managed in the stack.
Ruby manages heap memory by dividing pages into multiple slots; when a new object is created, Ruby searches for a free slot within these pages.
When a page is full, Ruby requests additional pages from the system allocator—such as Malloc or Jemalloc—rather than communicating directly with the operating system.
Heap fragmentation occurs when the garbage collector frees objects, leaving non-adjacent holes in memory that are too small or poorly positioned to accommodate new object allocations.
Because Ruby cannot utilize these non-adjacent free slots, it is forced to request more pages from the system allocator, leading to an increase in total memory usage despite the presence of free space.

Allocator and Garbage Collection Dynamics

Allocator fragmentation also occurs when the system allocator cannot merge non-adjacent memory blocks, a problem that can be mitigated in multi-threaded environments like Sidekiq by configuring Malloc Arena Max to two or four.
Increased numbers of arenas contribute to higher levels of memory fragmentation.
Locators retain memory and maintain caches of different block sizes to facilitate instant future allocations.
Garbage collectors do not immediately return memory to the system, instead retaining it for future use, which keeps process memory usage high even when objects are no longer needed.
Configuring the heap growth factor can help manage fragmentation, as a higher factor results in less fragmentation.
Ruby 3.2 introduced variable width allocation, which manages slots through size pools rather than statically to reduce memory bloat and fragmentation, though its effectiveness depends on code support.
Memory bloat is primarily caused by heap fragmentation, allocator fragmentation, allocators reserving extra memory, and the garbage collector holding onto memory.
Resident Set Size (RSS) refers to the amount of RAM a specific process uses.

Memory Optimization Techniques

Loading large datasets into an array can be optimized by using batches with configurable batch sizes instead of loading all records at once.
Converting large datasets to JSON within Ruby consumes significant memory; offloading this process to the database using functions like row_to_json or json_agg is more efficient.
Reading large CSV files should be done line-by-line or using foreach rather than loading millions of rows into memory at once.
Creating temporary objects inside loops, such as date objects, leads to excessive memory usage over millions of iterations; these objects should be created once before the loop and reused, ideally using freeze.
Using include? on arrays inside loops creates new arrays in every iteration, which can be avoided by using a Set for faster retrieval and freezing the collection.

Bulk Operations and Database Efficiency

The destroy method loads all associations into memory, whereas delete_all performs a single operation without callbacks or associations, though it requires manual handling of child records to avoid orphaned objects.
Per-record updates can trigger N+1 query issues and high memory usage; bulk operations like upsert, update_all, or upsert_all are more efficient alternatives.
Inserting rows one by one for associations, such as orders and line items, creates memory overhead when processing multiple rows.
Bulk queries can be optimized by using insert or upsert operations instead of individual queries.
Memory bloat issues can be addressed by utilizing batches, reusing data, and freezing objects to prevent redundant object creation.

Identifying and Resolving Memory Leaks

A gradual, steady increase in memory usage over time often indicates a memory leak, even if restarting the process temporarily resolves the symptoms.
Symptoms of a memory leak include a steadily growing Resident Set Size (RSS) that does not decrease after Sidekiq jobs, a heap of objects that are never deallocated, and frequent garbage collection (GC) pauses as the system struggles to clean up unreleased objects.
Unbounded in-memory objects, such as those stored in class or global variables, can cause memory leaks because the garbage collector cannot release them as long as they remain referenced.
Replacing class or global variables with local methods allows the garbage collector to automatically free memory after the data is used.
Closures can lead to memory leaks if they capture large objects rather than specific values, as the captured variables are not released.
Passing only the specific data required, such as a calculated size rather than an entire array, prevents unnecessary memory retention.
Implementing these memory optimizations resulted in a 42% reduction in memory usage (from 788 MB to 459 MB) and an 80% reduction in the number of objects (from 11 million to 2 million), while performance time improved from 2 minutes to between 10 and 20 seconds.

Database Query Tuning and Indexing

Database query performance can be analyzed and tuned using the EXPLAIN ANALYZE command in PostgreSQL.
Adding specific conditions to a query can shift the execution plan from a slow parallel sequential scan to a significantly faster index scan, as demonstrated by a reduction in execution time from 2,800 milliseconds to 0.7 milliseconds.
Partial indexes are effective only when queries include the specific index conditions, and neglecting these details can lead to high execution times.
Small, neglected features or individual application problems can cause significant performance degradation across an entire system.
Materialized views in Postgres serve as physical tables that store computed data, offering an alternative to complex joins across multiple tables or the complications of using read replicas.
Postgres features such as TS vectors combined with GIN indexes allow for efficient searching across multiple columns by creating a vector for direct querying.

Scaling and Infrastructure Management

Sidekiq can be autoscaled using latency-based queuing, which organizes tasks into multiple queues based on their latency requirements.
Specialized GIN indexes, which support various operators, can be utilized to achieve faster retrieval speeds for JSON columns.

Performance Culture and Workflow Integration

Performance optimization should begin with **profiling and measurement **rather than relying on intuition to identify bottlenecks.
Database capabilities, including indexes, aggregations, and bulk operations, should be leveraged for heavy tasks rather than attempting to reinvent these processes.
Identifying data patterns and understanding how data is derived and processed is essential, as even minor inefficiencies accumulate at scale.
Performance management is a collaborative responsibility that should be shared across the entire team.
P*erformance should be integrated into the development workflow* by setting budgets and monitoring metrics throughout the design, build, and shipping phases, rather than treating it as an afterthought.
Addressing performance issues requires a continuous, multi-faceted approach rather than a one-time fix or a complete rewrite of the application in a different language.

Thanks Snehal for an interesting talk and a great presentation, if you know her profile tag her for credits

Learning Go as a Ruby Developer #3: Functions, Methods, and Why Go Doesn't Have Classes

Shrouk Abozeid — Mon, 27 Jul 2026 14:59:31 +0000

One of the biggest mindset shifts I've had while learning Go came when I reached functions and methods.

As a Ruby developer, almost everything revolves around objects. Every piece of behavior belongs to a class, and every function is really just a method attached to an object.

Go takes a different approach.

Functions exist independently, and methods are simply functions with a receiver. There are no classes, no inheritance, but still writing object-oriented code.

Let's see how Go approaches behavior compared to Ruby.

Why This Felt Strange Coming from Ruby

In Ruby, we rarely think about standalone functions because they don't really exist.

Everything is an object.

class Calculator
  def add(a, b)
    a + b
  end
end

calculator = Calculator.new
calculator.add(2, 3)

Want behavior?

Create a class.

Need reusable logic?

Another class or a module.

Go starts from a much simpler place.

Most behavior begins as just... a function.

Functions in Go

Functions are declared using the func keyword.

func add(a int, b int) int {
    return a + b
}

The syntax may look unusual at first, especially if you've spent years writing Ruby.

Instead of writing the return type first, Go places it after the parameter list.

Calling the function is exactly what you'd expect.

result := add(2, 3)

Grouping Parameters

Go lets you group parameters that share the same type.

Instead of writing:

func add(a int, b int) int

you can write:

func add(a, b int) int {
    return a + b
}

It's a small feature, but it keeps function declarations much cleaner.

Returning Multiple Values

func divide(a, b int) (int, int) {
    return a / b, a % b
}

Then you can capture both results.

quotient, remainder := divide(10, 3)

Coming from Ruby, this felt familiar because Ruby also supports multiple assignment.

def divide(a, b)
  [a / b, a % b]
end

quotient, remainder = divide(10, 3)

The difference is that in Ruby we're really returning an array, while in Go multiple return values are part of the language itself.

Named Return Values

One feature I wasn't expecting was named return values.

Instead of writing:

func sum(a, b int) int {
    return a + b
}

you can write:

func sum(a, b int) (result int) {
    result = a + b
    return
}

Notice the bare return.

Because result was named in the function signature, Go automatically returns it.

This is called a naked return.

Anonymous Functions

Go also supports anonymous functions.

You can assign them to variables.

greet := func(name string) {
    fmt.Println("Hello", name)
}

Or execute them immediately.

func() {
    fmt.Println("Running immediately")
}()

This reminded me a lot of Ruby blocks and lambdas.

greet = ->(name) { puts "Hello #{name}" }

greet.call("Alice")

Although the syntax is different, the concept feels familiar.

Variadic Functions

Sometimes you don't know how many arguments a function should accept.

Go solves this using variadic parameters.

func printNumbers(numbers ...int) {
}

The ... tells Go to collect all arguments into a slice.

Ruby has something very similar.

def print_numbers(*numbers)
end

This was one of the easiest concepts for me to understand because the two languages approach it almost the same way.

So Where Are the Classes?

This was the question I kept asking while reading through the documentation.

If Go doesn't have classes...

Where do methods live?

The answer surprised me.

Methods belong to types, not classes.

Methods in Go

A method is simply a function with a receiver.

type Person struct {
    Name string
}

func (p Person) SayHello() {
    fmt.Println("Hello,", p.Name)
}

Now we can call it like this.

person := Person{Name: "Alice"}
person.SayHello()

The syntax felt unusual at first.

Instead of defining the method inside the type like Ruby does, the receiver appears before the method name.

func (receiver Type) MethodName() {
}

Value Receivers

By default, methods receive a copy of the value.

func (p Person) Rename(name string) {
    p.Name = name
}

Changing p.Name only changes the copy.

The original object stays exactly the same.

This is called a value receiver.

Pointer Receivers

If you want to modify the original value, you use a pointer receiver.

func (p *Person) Rename(name string) {
    p.Name = name
}

Now changes affect the original struct.

This distinction between value and pointer receivers was one of the first places where Go reminded me of C++.

Ruby developers usually don't think about this because objects are already passed around by reference-like semantics.

Go asks you to decide whether you're working with a copy or the original value.

Side-by-Side Comparison

Go	Ruby
Standalone functions	Everything is a method
`func` keyword	`def` keyword
Multiple return values	Usually arrays or multiple assignment
Anonymous functions	Lambdas and Procs
Variadic parameters (`...`)	Splat operator (`*`)
Methods attached to types	Methods defined inside classes
Value receivers	Objects usually mutated directly
Pointer receivers	Reference-like object semantics

Thoughts

Ruby's object model is incredibly elegant.

Everything feels consistent because everything is an object.

Go takes a more lightweight approach.

Instead of encouraging you to wrap every behavior inside a class, it asks a simple question:

Does this really need to belong to a type?

Sometimes the answer is yes—a method makes sense.

Other times, a standalone function is perfectly fine.

Go is trying to remove the parts it considers unnecessary while keeping the parts that are genuinely useful.

This has been one of the most interesting lessons so far in my Go journey, what about you?

Learning Go as a Ruby Developer # 2: Variables, Constants, and Why Go Doesn't Trust You

Shrouk Abozeid — Sat, 25 Jul 2026 14:20:50 +0000

One of the first differences I noticed when learning Go was how seriously it takes types.

Coming from Ruby. I rarely think about their types because Ruby figures everything out at runtime.

Go has a very different philosophy.

It wants to know exactly what every variable is, and if it doesn't know, it'll ask you to be explicit.

Why This Felt Strange Coming from Ruby

In Ruby, creating variables couldn't be easier.

name = "Alice"
age = 30
admin = true

Ruby decides the type at runtime.

Later I can even do something like this:

value = 10
value = "hello"
value = [1, 2, 3]

The same variable can hold completely different kinds of objects throughout the program.

Go doesn't allow that.

Once a variable has a type, that type is fixed.

Declaring Variables in Go

The most explicit way to declare a variable is by specifying its type.

var age int = 30
var name string = "Alice"
var admin bool = true

This is checked during compilation, long before your program ever runs.

If you later try to assign a different type, the compiler will stop you immediately.

This felt a bit strict—but it also means many bugs are caught before the program starts.

Type Inference

Fortunately, Go doesn't always require you to write the type yourself.

It can often infer it.

var admin = false

Go knows this is a bool.

Likewise:

var message = "Hello World"

becomes a string.

Short Variable Declaration

Inside functions, Go provides an even shorter syntax.

message := "Hello World"
count := 10

The := operator both declares the variable and lets Go infer its type.

If you're writing local variables, you'll probably use this style most of the time.

One thing I learned from my notes is that this syntax can only be used inside functions.

Declaring Multiple Variables

Go also makes it easy to declare multiple variables.

var x, y, z int = 12, 15, 10

or with inferred types:

var a, b, c = "hi", 30, true

For larger groups, Go encourages this style:

var (
    host string = "localhost"
    port int = 8080
    debug bool = true
)

Constants

Constants are declared using const.

const MaxUsers = 100

You can also group them.

const (
    Enabled = true
    Pi = 3.14
)

Unlike variables, constants cannot be changed after they're declared.

Ruby has constants too:

MAX_USERS = 100

But every Ruby developer knows the truth...

Ruby will happily let you change it.

MAX_USERS = 200

You'll get a warning, not an error.

Go, on the other hand, simply refuses.

Zero Values

If you declare a variable without assigning anything, Go automatically initializes it.

var age int
var active bool
var name string

The values become:

Type	Zero Value
int	0
float64	0.0
bool	false
string	""

Coming from Ruby, I expected something similar to nil.

Instead, Go gives every type a sensible default.

That design avoids a lot of unnecessary initialization code.

Type Conversion

Another thing that immediately stood out was that Go doesn't automatically convert between types.

Suppose we have:

var i int = 45

Converting it to a floating-point number requires an explicit conversion.

var f float64 = float64(i)

Likewise:

var u uint = uint(f)

Every conversion must be intentional.

Ruby is much more forgiving.

number = "45"

number.to_i
number.to_f

And in many cases Ruby performs conversions automatically for you.

Go deliberately avoids this.

Creating Values with `make`

One line in my notes that initially confused me was this:

numbers := make([]int, 3)

Unlike arrays in many languages, make creates and initializes certain built-in data structures.

In this example, it creates a slice with a length of three.

I'll dive much deeper into slices later in the series, but for now it's enough to know that make is commonly used when creating slices, maps, and channels.

So to conclude:

Changing a type?

Be explicit.

Creating a variable?

Be explicit—or let the compiler infer it.

Converting numbers?

Be explicit.

At first it felt like the language didn't trust me :D

Now I think it's more accurate to say Go doesn't trust assumptions.

Instead of guessing what I meant, it asks me to say exactly what I want.

Ruby optimizes for flexibility.
Go optimizes for correctness.

Learning Go as a Ruby Developer # 1: How Go Programs Actually Run

Shrouk Abozeid — Tue, 14 Jul 2026 15:00:00 +0000

Recently I started learning Go, and one of the first things I noticed was how much it reminded me of C++.
I haven't touched C++ since college, so Go gives me a weird sense of nostalgia :D

As a Ruby developer, I'm used to writing code and simply executing it.
Go, however, has a much stronger notion of what a program actually is and how it starts running.

In this article, I want to explore how a Go program is structured and compare it with how we typically think about programs in Ruby

Why This Felt Strange Coming from Ruby

In Ruby, writing a program is straightforward:

puts "Hello World"

Save it as hello.rb and run:

ruby hello.rb

There's no special package declaration, no imports required for basic programs, and no designated entry point function.

Go takes a very different approach.

Every executable Go program follows a specific structure, and understanding this structure is one of the first steps to becoming comfortable with the language.

How Go Programs Are Structured

A typical Go file looks like this:

package main
import (
 "fmt" 
) 

func main() {
 fmt.Println("Hello World")
}

There are three important pieces here:

1. Package Declaration

Every Go file begins with a package declaration:

package main
Packages are Go's mechanism for organizing code.

If you want to build an executable application, the package must be named main.

2. Imports

Go requires explicit imports:

import (
    "fmt"
)

The compiler will actually complain if you import something you don't use.

As a Ruby developer, this felt unusual because Ruby happily allows unused
requires:

require 'json'
require 'csv'

puts "Hello"

Go prefers keeping dependencies explicit and clean.

3. The main Function

Every executable Go program starts execution in:

func main() {
}

The mainfunction:

accepts no arguments
returns no values
acts as the application's entry point

When main() finishes, the program exits.

How Program Execution Works

According to the Go specification, a complete program consists of:

one package named main
all packages imported by main
all transitive dependencies

Program execution happens in two stages:

Initialize packages
Execute main()

Once main()returns, the program terminates.

Running vs Building Programs

Go provides two common ways to execute code.

Run directly

go run hello.go

This compiles and runs the program immediately.

Build an executable

go build hello.go
./hello

This creates a standalone binary.

In Ruby: applications are distributed as source code and interpreted at runtime.

Coming from Rails, where so much setup happens automatically, Go feels so explicit.

At the same time, that explicitness means you have to think about things that Ruby usually hides from you.

while Ruby optimizes for developer happiness and speed of iteration, Go forces me to understand what's actually happening.

What about you? do you use Ruby or Go, or both ? and how was the transition for you ?

Design Patterns in Ruby #3: Decorator Pattern

Shrouk Abozeid — Mon, 13 Jul 2026 15:11:23 +0000

Inheritance is powerful but doesn’t always lead to flexible designs and Decorator Pattern is one of the solutions to balance between inheritance and flexibility

Decorators work like object wrappers that add functionality/behavior to the object during run time instead of compile time.

we said wrapper*S* with an S because you can wrap as many as your object need, adding layers to your Main object.

Structure of the Decorator Pattern

The Decorator Pattern consists of four main parts:

Component – the main abstraction that can be used directly or wrapped by decorators.
Concrete Component – the actual object whose behavior we want to extend dynamically.
Decorator – implements the same interface as the component and has a component object that it wraps.
Concrete Decorators – extend the decorator and add new behavior before or after delegating to the wrapped object.

At first, this may sound a bit abstract, so let's look at a practical example.

Example: Rack Middleware

If you've worked with Ruby on Rails, you've already used one of the best real-world examples of the Decorator Pattern: Rack middleware.

Each middleware wraps another application object, adds its own behavior, and then delegates the request to the wrapped object.

# Component
class App
  def call(env)
    raise NotImplementedError
  end
end

# Concrete Component
class Application < App
  def call(env)
    puts "Processing request: #{env[:path]}"
    [200, {}, ["OK"]]
  end
end

# Decorator
class Middleware < App
  def initialize(app)
    @app = app
  end

  def call(env)
    @app.call(env)
  end
end

# Concrete Decorators
class LoggingMiddleware < Middleware
  def call(env)
    puts "[LOG] Received request for #{env[:path]}"
    response = @app.call(env)
    puts "[LOG] Response status: #{response[0]}"
    response
  end
end

class AuthenticationMiddleware < Middleware
  def call(env)
    puts "[AUTH] Authenticating user"

    if env[:authenticated]
      @app.call(env)
    else
      [401, {}, ["Unauthorized"]]
    end
  end
end

class TimingMiddleware < Middleware
  def call(env)
    start = Time.now

    response = @app.call(env)

    elapsed = ((Time.now - start) * 1000).round(2)
    puts "[TIMING] Request took #{elapsed}ms"

    response
  end
end

# Usage
app = Application.new
app = LoggingMiddleware.new(app)
app = AuthenticationMiddleware.new(app)
app = TimingMiddleware.new(app)

env = {
  path: "/articles",
  authenticated: true
}

response = app.call(env)

p response

Output:

[AUTH] Authenticating user
[LOG] Received request for /articles
Processing request: /articles
[LOG] Response status: 200
[TIMING] Request took 0.12ms

[200, {}, ["OK"]]

In this example:

Application is our Concrete Component.
Middleware is the Decorator that wraps another component.
LoggingMiddleware, AuthenticationMiddleware, and TimingMiddleware are Concrete Decorators.
Each middleware adds behavior before, after, or around the original call method.
We can add, remove, or reorder middleware without modifying the original Application class.

What's particularly interesting is that this is almost exactly how Rack itself builds a web application stack:

app = Rails.application
app = Rack::Runtime.new(app)
app = Rack::MethodOverride.new(app)
app = Rack::Session::Cookie.new(app)

Each middleware wraps the previous object, creating a chain of decorators that process requests and responses.

In real Rack applications there isn't a common App base class because Ruby relies on duck typing. As long as an object responds to call, it can participate in the middleware stack.

The example above introduces an explicit App class only to make the Decorator Pattern structure easier to see.

Takeaways

Decorators use inheritance mainly for type compatibility, not for behavior reuse.
New behavior is acquired through composition rather than deep inheritance hierarchies.
The Decorator Pattern involves a family of decorator classes that wrap concrete components.
A component can be wrapped by any number of decorators.
Decorators share the same interface as the objects they decorate.
The pattern follows the principle of favoring composition over inheritance.

Why favoring composition ?

inheritance becomes difficult to manage when you're trying to mix and match behaviors.

The number of subclasses grows quickly because every new feature creates more combinations.

With the Decorator Pattern, each behavior becomes its own object that can be composed dynamically.

The next time you find yourself creating subclasses for every possible combination of features, it may be worth asking whether a decorator would provide a more flexible solution.

for a full example in ruby check this https://github.com/ShroukAbozeid/design-pattern/tree/main/decorator

Design Patterns in Ruby #2: Observer Pattern

Shrouk Abozeid — Wed, 08 Jul 2026 16:17:55 +0000

Applications often need to react when something changes.

When a user signs up, you might want to:

Send a welcome email
Create a user profile
Log the activity
Notify an analytics service

One approach is to put all of this logic inside the signup code. While it works initially, the code quickly becomes difficult to maintain as more responsibilities are added.

This is exactly the kind of problem the Observer Pattern solves.

The Observer Pattern is one of the most commonly used behavioral design patterns.

It defines a one-to-many relationship between objects so that when one object (the Subject) changes state, all of its dependent objects (the Observers) are notified automatically.

Instead of tightly coupling objects together, the subject simply announces that "something happened," and any interested observers can react.

How It Works

The pattern consists of two main participants.

Subject (Publisher)

The subject owns the state and keeps track of all registered observers.

Whenever its state changes, it notifies every observer.

Observer (Subscriber)

Observers register themselves with the subject.

When they receive a notification, they perform whatever action they're responsible for.

A classic real-world example is a UI button.

The button is the Subject, while event listeners are the Observers. When the button is clicked, every registered listener is notified.

Why Use the Observer Pattern?

Without the Observer Pattern, your code often grows into something like this:

class User
  def signup
    save

    WelcomeMailer.send_email(self)
    Analytics.track_signup(self)
    ActivityLogger.log_signup(self)
    UserProfile.create(self)
  end
end

Every new action requires modifying the signup method.

This makes the class responsible for many unrelated tasks and violates the Single Responsibility Principle.

With the Observer Pattern, the signup process only needs to announce that a user has signed up. Each observer decides how to respond.

Loose Coupling

One of the biggest benefits of the Observer Pattern is loose coupling.

The subject only knows that its observers respond to a common interface (for example, an update method).

This means:

New observers can be added without changing the subject.
Observers can be removed at runtime.
The subject doesn't know or care what each observer does.
Subjects and observers can evolve independently.
Each observer has a single, focused responsibility.

Ruby Example

Let's build a simple weather station.

Whenever the temperature changes, every registered display should update automatically.

class WeatherStation
  def initialize
    @observers = []
  end

  def add_observer(observer)
    @observers << observer
  end

  def remove_observer(observer)
    @observers.delete(observer)
  end

  def temperature=(value)
    @temperature = value
    notify_observers
  end

  private

  def notify_observers
    @observers.each do |observer|
      observer.update(@temperature)
    end
  end
end

class PhoneDisplay
  def update(temperature)
    puts "Phone Display: #{temperature}°C"
  end
end

class DashboardDisplay
  def update(temperature)
    puts "Dashboard Display: #{temperature}°C"
  end
end

station = WeatherStation.new

station.add_observer(PhoneDisplay.new)
station.add_observer(DashboardDisplay.new)

station.temperature = 25

Output:

Phone Display: 25°C
Dashboard Display: 25°C

When the temperature changes, the weather station automatically notifies every registered display.

Notice that WeatherStation doesn't know anything about phones or dashboards. It only knows that each observer responds to update.

Observer Pattern in Rails

Even if you've never implemented the Observer Pattern yourself, you've probably used it in Rails.

Some common examples include:

Active Record callbacks (after_create, after_commit, before_save)
ActiveSupport::Notifications
Action Cable broadcasting events to connected clients

For example:

class User < ApplicationRecord
  after_create :send_welcome_email

  private

  def send_welcome_email
    WelcomeMailer.welcome(self).deliver_later
  end
end

When a User is created, Rails automatically invokes the callback.

Although callbacks aren't a textbook implementation of the Observer Pattern, they follow the same fundamental idea: responding automatically when an object's state changes.

When Should You Use the Observer Pattern?

The Observer Pattern is a good choice when:

Multiple objects need to react to the same event.
You want to avoid tightly coupling classes together.
New behaviors should be be added without modifying existing code.
Different parts of the application should respond independently to state changes.
You want to follow the Open/Closed Principle and the Single Responsibility Principle.

Final Thoughts

The Observer Pattern is all about communication without tight coupling.

Instead of asking every object to perform additional work, the subject simply announces that something has changed.

Any interested observer can react in its own way.

In Ruby, where objects communicate through simple interfaces and duck typing, the Observer Pattern is straightforward to implement and can significantly improve the flexibility and maintainability of your applications.

As your applications grow, you'll find this pattern everywhere—from GUI frameworks to Rails callbacks to event-driven architectures.

for a full example in ruby check this https://github.com/ShroukAbozeid/design-pattern/tree/main/observer

Design Patterns in Ruby #1: Strategy Pattern

Shrouk Abozeid — Mon, 06 Jul 2026 14:21:52 +0000

When building applications, one of the most common challenges is managing behaviors that can vary over time.

Behavioral Design Patterns helps us design how objects interact with each other in an effective way
One of the most useful behavioral patterns is the Strategy Pattern

Strategy pattern defines a family of algorithms encapsulate each one and make them interchangeable

it provides a way to change the behavior of a class without extending it

Instead of hardcoding behavior inside a class, the behavior is delegated to a separate object called a strategy.

The Problem

Imagine you're building an e-commerce application.

Customers can pay using:

PayPal
Credit Card
Bank Transfer

An initial implementation might look like this:

class Checkout
  def pay(method, amount)
    case method
    when :paypal
      puts "Processing PayPal payment of $#{amount}"
    when :credit_card
      puts "Processing Credit Card payment of $#{amount}"
    when :bank_transfer
      puts "Processing Bank Transfer payment of $#{amount}"
    end
  end
end

# Usage
checkout = Checkout.new
checkout.pay(:paypal, 100)

Problems

Every time you add a new payment method:

You modify Checkout
The class becomes larger
Testing becomes harder
You violate the Open/Closed Principle (open for extension, closed for modification)

Applying the Strategy Pattern

Instead of putting all payment logic inside Checkout, we'll create separate strategy classes.

Step 1: Define the Strategies

class PaymentStrategy
  # or make as module and use include instead of <
  def pay(amount)
    raise NotImplementedError
  end
end

class PayPalStrategy < PaymentStrategy
  def pay(amount)
    puts "Processing PayPal payment of $#{amount}"
  end
end

class VisaStrategy < PaymentStrategy
  def pay(amount)
    puts "Processing Visa payment of $#{amount}"
  end
end

class BankTransferStrategy < PaymentStrategy
  def pay(amount)
    puts "Processing Bank Transfer payment of $#{amount}"
  end
end

Step 2: Create the Context

The Context is the class that uses a strategy.

class Checkout
  def initialize(payment_strategy)
    @payment_strategy = payment_strategy
  end

  def pay(amount)
    @payment_strategy.pay(amount)
  end
end

Step 3: Use Different Strategies

checkout = Checkout.new(PayPalStrategy.new)
checkout.pay(100)
checkout = Checkout.new(VisaStrategy.new)
checkout.pay(100)

Runtime Strategy Switching

You can even change strategies while the application is running.

checkout = Checkout.new(PayPalStrategy.new)
checkout.pay(100)
checkout.payment_strategy = BankTransferStrategy.new
checkout.pay(200)

When Should You Use the Strategy Pattern?

The Strategy Pattern is a good choice when:

You have multiple implementations of the same behavior.
You find yourself writing large case or if/else statements.
You want to follow the Open/Closed Principle.
You need to switch behavior dynamically at runtime.
You want to isolate and test algorithms independently.

In Ruby, where objects are lightweight and composition is encouraged, the Strategy Pattern often feels natural and can significantly improve the design of your applications.

for a full example in ruby check this https://github.com/ShroukAbozeid/design-pattern/tree/main/strategy

Understanding Rack #2 : Notes from Rebuilding Rails by Noah Gibbs

Shrouk Abozeid — Thu, 02 Jul 2026 15:00:00 +0000

A Rack application is typically configured through a config.ru (RackUp) file. This file defines the stack of middleware that will handle incoming requests before they reach the application itself.

One of Rack's core ideas is that applications are built from multiple layers. Each layer, called middleware, can inspect, modify, or respond to a request before passing it to the next layer in the stack.

When Rack builds the middleware stack, it passes each middleware instance the next layer through its initialize method. The last layer in the chain is the actual application.

Here's a simple example:

# config.ru
use Rack::Auth::Basic, "app" do |_, pass|
  pass == "secret"
end

run proc {
  [200, { "Content-Type" => "text/html" },
   ["Hello, world!"]]
}

The use keyword tells Rack which middleware class to instantiate and what arguments to pass to its constructor.
The run keyword specifies the final application that will handle the request.

Rack includes several built-in middleware components, such as:

Rack::Auth::Basic — HTTP Basic Authentication
Rack::ContentType — Automatically sets the response content type
Rack::ShowExceptions — Displays a helpful error page when an exception occurs

There are also many third-party middleware libraries available:

Rack::GoogleAnalytics — Injects Google Analytics tracking code
Rack::Throttle — Adds request rate limiting
Warden — A flexible authentication framework used by libraries such as Devise

One of Rack's strengths is that you can easily create your own custom middleware and insert it into the stack, allowing you to add application-specific behavior in a clean and reusable way.

Since Rails is built on top of Rack, every Rails application includes a config.ru file and uses Rack middleware internally.

For a deeper look at how Rails integrates with Rack, see the "Rails on Rack" guide in the Rails documentation.

Understanding Rack #1 : Notes from Rebuilding Rails by Noah Gibbs

Shrouk Abozeid — Tue, 30 Jun 2026 15:00:00 +0000

What is Rack?

Rack is a Ruby gem that acts as a middleman between your Ruby framework (like Rails or Sinatra) and the web server/application server that runs your code.

Think of it like a translator:

Browser <--> Web Server/App Server <--> Rack <--> Rails App

When a browser sends a request:

The server receives it.
Rack converts the request into a format Rails understands.
Rails processes the request and generates a response.
Rack converts the response back into a format the server can send to the browser.

What is an application server?

An application server is a program that actually runs your Ruby application.

Examples:

Puma
Thin
Passenger
WEBrick
Unicorn

These servers execute your Rails code and return the result to users.

Development vs Production

Development (your local machine)

Usually you run only one application server:

rails server

Rails starts Puma by default.

Browser <--> Puma <--> Rails

This is simple and works well for development.

Production (real website)

In production, there is often a dedicated web server in front of the application server:

Browser <--> Nginx/Apache <--> Puma <--> Rails

Why?

Nginx/Apache can serve static files efficiently.
They can handle SSL/HTTPS.
They can distribute traffic to multiple Puma processes.
They provide better performance and security.

Real-world analogy

Imagine a restaurant:

Browser = customer
Nginx/Apache = receptionist
Rack = waiter translating orders
Rails app = chef
Puma = kitchen where the chef works

The customer doesn't talk directly to the chef. The request passes through several layers, and Rack helps them communicate using a common language.

So in one sentence we can say

Rack is the standard interface that allows Ruby web servers (Puma, Unicorn, etc.) and Ruby web frameworks (Rails, Sinatra, etc.) to communicate with each other.

DEV Community: Shrouk Abozeid

Learning Go as a Ruby Developer — Part 4: What can we do with a single "for"

Conditions in Go

Boolean Operators

The for Loop

The While-Like for

Infinite Loops

break and continue

break

continue

range: The Go Way to Iterate Over Collections

Comparing range with Ruby

Switch Statements

Switch Without an Expression

Multiple Values in a Case

fallthrough

Go vs Ruby: Control Flow

Design Patterns in Ruby #5: Abstract Factory Pattern

The Problem

Abstract Factory

Structure

Abstract Factory

Concrete Factory

Abstract Product

Concrete Products

Client

Ruby Example

Products

Abstract Factory

Concrete Factories

Client

Factory Method vs Abstract Factory

Adding New Products vs New Families

Where You'll See It in Rails

Active Storage

When Should You Use It?

Key Takeaways

Design Patterns in Ruby #4: Simple Factory vs Factory Method

Simple Factory

Structure

Advantages

The Problem

Factory Method

Structure

Advantages

Did you know that Rails framework is full of Factory patterns? 👀

Example: Action Mailer

Example: Active Job adapters

Key Takeaways

Snehal Ahire - Rails Under a Microscope: Summarized with AI

Rails Performance Challenges

Data Retrieval Optimization

Pagination Strategies

Query and Caching Best Practices

Memory Management and Heap Fragmentation

Allocator and Garbage Collection Dynamics

Memory Optimization Techniques

Bulk Operations and Database Efficiency

Identifying and Resolving Memory Leaks

Database Query Tuning and Indexing

Scaling and Infrastructure Management

Performance Culture and Workflow Integration

Learning Go as a Ruby Developer #3: Functions, Methods, and Why Go Doesn't Have Classes

Why This Felt Strange Coming from Ruby

Functions in Go

Grouping Parameters

Returning Multiple Values

Named Return Values

Anonymous Functions

Variadic Functions

So Where Are the Classes?

Methods in Go

Value Receivers

Pointer Receivers

Side-by-Side Comparison

Thoughts

Learning Go as a Ruby Developer # 2: Variables, Constants, and Why Go Doesn't Trust You

Why This Felt Strange Coming from Ruby

Declaring Variables in Go

Type Inference

The `for` Loop

The While-Like `for`

`break` and `continue`

`break`

`continue`

`range`: The Go Way to Iterate Over Collections

Comparing `range` with Ruby

`fallthrough`

Creating Values with `make`