DEV Community: Shrouk Abozeid

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.

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.