DEV Community: Arsalan Bardsiri

From Monolith to Modular (A basic simple example)

Arsalan Bardsiri — Tue, 09 Dec 2025 21:29:42 +0000

From Monolith to Modular

Subtitle: How I’m learning System Design by breaking my own code.

We often hear about "scaling to millions of users," but we rarely talk about the first critical step: moving from "it works on my machine" to "it works as a system."

As part of my deep dive into system design (following the(https://bytebytego.com/courses/system-design-interview)), I am building the infrastructure for a scalable web application from scratch. My goal is to move beyond theory and actually implement the architectural patterns that power the internet.

Here is what I learned moving from a Single Server architecture to a 3-Tier application.

Phase 1: The Simple Single Server (2-Tier)

Repository: arsalanbardsiri/simple-single-server-app

Every great system starts as a monolith. My first iteration was a classic "2-Tier" application. In this setup, the architecture is deceptively simple:

Client Tier: The user interface (browser).
Server Tier: A single machine handling both the business logic (Web Server) and the data persistence (Database).

The Architecture

Why start here?

It is the fastest way to ship. You have zero network latency between your application and your database because they live on the same hardware. Deployment is a single command. For a student project or a proof-of-concept, this is perfect.

The Wall

However, as I learned from the "Zero to Millions" chapter, this simplicity is a trap.

Vertical Scaling Limits: To handle more users, I have to upgrade the entire server (more RAM, better CPU). I cannot just upgrade the database; I have to upgrade the web server too.[1]
Single Point of Failure (SPOF): If my web server crashes due to a buggy script, my database goes down with it. The entire system is fragile.[2]
Security Risk: In this 2-tier setup, the database often shares the same environment as the public-facing web server, increasing the attack surface.[2]

Phase 2: The Evolution to 3-Tier Architecture

Repository: arsalanbardsiri/3tier-simple-app

To solve the fragility of the single server, I refactored the application into a 3-Tier Architecture. This is the industry standard for a reason. It physically and logically separates the system into three distinct layers.

The Architecture

Presentation Tier: The frontend (Client) that the user sees.
Application Tier: The backend API (Business Logic) that processes requests.
Data Tier: The dedicated database server that stores information.

The "Aha!" Moment

Moving to this architecture introduced complexity—I now have to manage connection strings, network latency, and multiple deployments. So, why do it?

1. Independent Scalability
This is the biggest unlock. If my application performs heavy calculations (CPU intensive), I can add more Application Servers without touching the database. If my application stores massive amounts of logs (Storage intensive), I can upgrade the Database Server without touching the application code.[3]

2. Improved Security
In my single-server app, the database lived on the public-facing server. In the 3-tier app, the Database Tier is hidden behind the Application Tier. It resides in a private network layer, accessible only by the Application Server, never by the public internet.[4]

3. Fault Tolerance
By decoupling the components, I have prepared the system for redundancy. If I need to restart the web server to deploy a patch, the database remains active.

What's Next?

I have successfully separated the concerns, but I still have a Single Point of Failure: I only have one Application Server and one Database Server.

My next step in the ByteByteGo roadmap is to implement a Load Balancer (likely NGINX) to distribute traffic across multiple application servers, ensuring that if one goes down, the users never notice.

Follow my GitHub to see the code evolve:

The Ruby & Sinatra Playbook from Core Concepts to Tiny Web Apps

Arsalan Bardsiri — Fri, 19 Sep 2025 03:20:26 +0000

A practical, copy-ready guide to core Ruby, Enumerable patterns, OOP, Sinatra (+ ERB), testing, and a few advanced peeks. Built around the same patterns you’ve likely used: inventories, small APIs, and simple routes/views.

Why this guide
1) Ruby fundamentals
2) Enumerable patterns (the 80/20)
3) OOP & modules in Ruby
4) Sinatra crash course (routes, params, views, helpers)
5) Mini testing intro (Minitest + Rack::Test)
6) Advanced peeks (procs, lambdas, meta, refinements, lazy)
7) Deployment notes (Render/Vercel-style providers)
8) Practice checklist
9) Tiny reference (copy/paste)

Why this guide

You don’t need a textbook to ship tiny apps. You need a tight toolkit:

Ruby basics (data types, blocks, keyword args)
Enumerable muscle memory (map, select, sum, group_by, tally)
OOP without overthinking (composition > inheritance, attr_reader)
Sinatra + ERB to wire routes → views, with a helper or two
A whiff of testing and deployment so you can share it

Let’s go.

1) Ruby fundamentals

Values & literals

num    = 42               # Integer
price  = 29.99            # Float
ok     = true             # Boolean
name   = "Ruby"           # String
sym    = :status          # Symbol (great as Hash keys)
list   = [1, 2, 3]        # Array
info   = {name: "Ada", lang: "Ruby"}  # Hash (keyword style)
range  = 1..3             # 1,2,3 (inclusive)

Truthiness: nil and false are falsey; everything else is truthy.

Strings & symbols

greeting = "Hi, #{name}"  # interpolation
:ready == :ready          # symbols are interned

Methods, default & keyword args

def greet(name = "world", excited: false)
  msg = "Hello, #{name}"
  excited ? "#{msg}!" : msg
end

greet             # "Hello, world"
greet("Ada")      # "Hello, Ada"
greet("Ada", excited: true) # "Hello, Ada!"

Multiple assignment & splats

a, b = [10, 20]          # a=10, b=20
head, *rest = [1,2,3,4]  # head=1, rest=[2,3,4]

Blocks & `yield`

def with_timer
  t0 = Time.now
  result = yield
  puts "Took: #{Time.now - t0}s"
  result
end

with_timer { sleep 0.1; 123 } # prints time, returns 123

2) Enumerable patterns (the 80/20)

Most collections include Enumerable. These are the workhorses:

prices = [20, 50, 29.99, 65]

cheap      = prices.select { |p| p < 30 }        # filter in
not_cheap  = prices.reject { |p| p < 30 }        # filter out
doubled    = prices.map { |p| p * 2 }            # transform
total      = prices.sum                          # aggregate
min_price  = prices.min                           # 20
two_groups = prices.partition { |p| p < 30 }     # [[<30], [>=30]]

For arrays of objects (e.g., boutique items):

items = [
  {name: "Skirt", price: 29.99, quantity_by_size: {s: 1, xl: 4}},
  {name: "Coat",  price: 65.00, quantity_by_size: {}}
]

names       = items.map { |i| i[:name] }.sort
out_of_stock= items.select { |i| i[:quantity_by_size].empty? }
total_stock = items.sum { |i| i[:quantity_by_size].values.sum }

Hash helpers you’ll use constantly:

h.fetch(:key)           # raises if missing (great for required data)
h.fetch(:key, "N/A")    # default
h.dig(:a, :b, :c)       # safe deep lookup
{a:1,b:2}.transform_values { |v| v+1 }  # => {a:2,b:3}
"rock paper rock".split.tally           # => {"rock"=>2,"paper"=>1}

3) OOP & modules in Ruby

Minimal class, accessors, class vs instance methods

class Product
  attr_reader :name, :price
  attr_accessor :tags

  def initialize(name:, price:, tags: [])
    @name, @price, @tags = name, price, tags
  end

  def display
    "#{name} — $#{price}"
  end

  def self.from_hash(h) # class method
    new(**h)
  end
end

p = Product.new(name: "Socks", price: 20)
p.display                 # "Socks — $20"
Product.from_hash(name: "Skirt", price: 29.99)

Modules as mixins (behavior), namespaces (organization)

module Discountable
  def discounted(price: @price, by: 0.1)
    (price * (1 - by)).round(2)
  end
end

class CartItem
  include Discountable
  def initialize(price) ; @price = price ; end
end

CartItem.new(100).discounted(by: 0.2)  # 80.0

`Struct` and `OpenStruct`

Order = Struct.new(:id, :total, keyword_init: true)
o = Order.new(id: 1, total: 29.99)

require "ostruct"
row   = { name: "Skirt", price: 29.99, quantity_by_size: {s:1, xl:4} }
item  = OpenStruct.new(row)
item.name            # "Skirt"
item.quantity_by_size.values.sum  # 5

Rule of thumb: Struct for known fields (faster); OpenStruct when the shape varies (convenient).

4) Sinatra crash course (routes, params, views, helpers)

Minimal project layout

.
├─ app.rb
├─ views/
│  ├─ layout.erb
│  ├─ index.erb
│  └─ show.erb
└─ Gemfile

Gemfile

source "https://rubygems.org"

gem "sinatra"
gem "sinatra-contrib"   # for reloader
gem "http"              # simple HTTP client
gem "dotenv"            # env vars for API keys (optional)

bundle install

Routes & params

# app.rb
require "sinatra"
require "sinatra/reloader" if development?
require "http"
require "json"

helpers do
  def currencies
    raw = HTTP.get("https://api.exchangerate.host/list").to_s
    JSON.parse(raw).fetch("currencies") # => {"USD"=>"United States Dollar", ...}
  end
end

get "/" do
  @codes = currencies.keys.sort
  erb :index
end

get "/:from" do
  @from  = params[:from].upcase
  @codes = currencies.keys.sort
  erb :show
end

get "/:from/:to" do
  @from, @to = params.values_at("from", "to").map!(&:upcase)

  url  = "https://api.exchangerate.host/convert?from=#{@from}&to=#{@to}&amount=1"
  data = JSON.parse(HTTP.get(url).to_s)
  @rate = data["result"] || data.dig("info", "rate") || data.dig("info", "quote")

  erb :convert
end

Views (ERB)

<!-- views/layout.erb -->
<!doctype html>
<html>
  <head><meta charset="utf-8"><title>Exchange</title></head>
  <body><main class="container"><%= yield %></main></body>
</html>

<!-- views/index.erb -->
<h1>Currency pairs</h1>
<ul>
  <% @codes.each do |code| %>
    <li><a href="/<%= code %>">Convert 1 <%= code %> to...</a></li>
  <% end %>
</ul>

<!-- views/show.erb -->
<h1>Convert <%= @from %></h1>
<p>Go <a href="/">back</a>.</p>
<ul>
  <% @codes.each do |to| %>
    <li><a href="/<%= @from %>/<%= to %>">Convert 1 <%= @from %> to <%= to %>...</a></li>
  <% end %>
</ul>

<!-- views/convert.erb -->
<h1>Convert <%= @from %> to <%= @to %></h1>
<p>1 <%= @from %> equals <%= @rate %> <%= @to %>.</p>
<p>Go <a href="/<%= @from %>">back</a>.</p>

ASCII request flow

Browser ──▶ Sinatra Route ──▶ (optional) Helper/Service ──▶ HTTP API
   │             │                            │               │
   └─────────────┴────────── render(ERB) ◀────┴──── JSON ◀────┘

Tips

Put rendering data into instance vars (@foo) inside routes.
Extract repeated logic into helpers or POROs (plain Ruby objects).
Use params for both path (/:id) and query (?q=term) parameters.

5) Mini testing intro (Minitest + Rack::Test)

# test_app.rb
require "minitest/autorun"
require "rack/test"
require_relative "./app"

class AppTest < Minitest::Test
  include Rack::Test::Methods
  def app = Sinatra::Application

  def test_home_has_heading
    get "/"
    assert last_response.ok?
    assert_includes last_response.body, "Currency pairs"
  end
end

Run:

ruby test_app.rb

6) Advanced peeks (procs, lambdas, meta, refinements, lazy)

Procs vs lambdas

adder = ->(x, y) { x + y }   # lambda (strict arity, normal return)
adder.call(2, 3) # 5

def with_proc
  p = Proc.new { return :from_proc } # returns from method!
  p.call
  :after
end
with_proc  # => :from_proc

Metaprogramming (define readers on the fly)

class Settings
  def self.option(*names)
    names.each { |n| define_method(n) { @data[n] } }
  end

  option :host, :port

  def initialize(data) ; @data = data ; end
end

s = Settings.new(host: "localhost", port: 3000)
s.host  # "localhost"

Refinements (scoped monkey-patch)

module Titleize
  refine String do
    def titleize = split.map!(&:capitalize).join(" ")
  end
end

using Titleize
"hello world".titleize # "Hello World"

Lazy enumerators (streaming style)

(1..Float::INFINITY).lazy.select(&:odd?).map { |n| n*n }.first(5)
# => [1, 9, 25, 49, 81]

7) Deployment notes (Render/Vercel-style providers)

Ensure your app binds to 0.0.0.0 and respects PORT.
Add a Procfile:

web: bundle exec ruby app.rb -p $PORT -o 0.0.0.0

If using environment variables: add them in the provider’s dashboard (e.g., EXCHANGE_RATE_KEY) and use ENV.fetch(...) in Ruby.
On free tiers, outbound HTTP may be rate-limited; for demos, consider caching JSON to a file during development.

8) Practice checklist

[ ] Refactor a hash-based inventory to OpenStruct and implement:
- item_names (sorted)
- cheap (price < 30)
- total_stock (sum of nested values)
[ ] Build /FROM and /FROM/TO Sinatra routes that:
- render <h1> headings exactly as: Convert FROM and Convert FROM to TO
- have “back” links to / and /FROM respectively
[ ] Add a helper for API calls and unit test one route with Rack::Test.
[ ] Replace a nested loop with flat_map.
[ ] Write one define_method example (metaprogramming) just for fun.

9) Tiny reference (copy/paste)

# Enumerable
arr.select { |x| cond } ; arr.reject { |x| cond } ; arr.partition { |x| cond }
arr.map { |x| f(x) }    ; arr.flat_map { |x| many(x) }
arr.sum                 ; arr.count { |x| cond }  ; arr.min_by { |x| key }
arr.group_by { |x| key } ; arr.tally
h.fetch(:k, default)    ; h.dig(:a,:b,:c) ; h.transform_values { |v| g(v) }

# OOP
class C
  CONST = 1
  attr_reader :a ; attr_accessor :b
  def initialize(a:, b: 0) ; @a, @b = a, b ; end
  def self.build ; new(a: 1) ; end
end

# Sinatra skeleton
require "sinatra" ; require "http" ; require "json"
get("/") { @data = JSON.parse(HTTP.get(URL).to_s) ; erb :index }

Final words

If you master: (1) the core Ruby syntax, (2) half a dozen Enumerable moves, (3) small classes/modules, and (4) Sinatra’s three files (routes, layout, view), you can build a lot. Keep this playbook close, and iterate.

From Functions to OOP: Building a Rock–Paper–Scissors CLI in Ruby

Arsalan Bardsiri — Thu, 21 Aug 2025 04:23:17 +0000

A beginner‑friendly, step‑by‑step guide that retraces a real learning journey—from a single file of functions to a clean, object‑oriented, tested command‑line app. Use it to rebuild the project from scratch and review key Ruby concepts any time.

What you’ll build

A terminal Rock–Paper–Scissors game with:

Two modes: Player vs Player, Player vs Computer
Object‑oriented design: a small Game class for player state and actions
Clean game logic: a single hash controls the win rules
Friendly CLI: ASCII art banner + robust input validation
Unit tests (MiniTest): pure logic tested without waiting for gets

Prereqs

Ruby (>= 3.x recommended)
Terminal basics (ruby file.rb)

ruby -v

Final project structure

rock-paper-scissors/
├── app.rb            # Main CLI game loop (entry)
├── game_play.rb      # Winner logic + round runner (functions)
├── select.rb         # Game class (player: choice + score) and ASCII
└── test/
    └── test_game.rb  # MiniTest (optional)

Note: the code below uses the same beginner‑friendly syntax as the repo (no keyword args, no heredocs, no advanced operators), so learners can cross‑check one‑to‑one.

Step 1 — Start the project

Create a folder and the files.

mkdir rock-paper-scissors && cd rock-paper-scissors
mkdir test
:> app.rb :> game_play.rb :> select.rb :> test/test_game.rb

Step 2 — The Player class (`select.rb`)

This class will:

hold a player’s score and latest choice
prompt and validate input (shoot)
generate a random choice for the computer (shoot_computer)

Add ASCII constants, then the class.

# select.rb
# ASCII art (simple multiline strings)
THE_ROCK = "
    _______
---'   ____)
      (_____)
      (_____)
      (____)
---.__(___)
"

THE_PAPER = "
    _______
---'   ____)____
          ______)
          _______)
         _______)
---.__________)
"

THE_SCISSORS = "
    _______
---'   ____)____
          ______)
       __________)
      (____)
---.__(___)
"

# Map of symbol -> ASCII art
OPTIONS = { :rock => THE_ROCK, :paper => THE_PAPER, :scissors => THE_SCISSORS }

# Player object (choice + score) and input methods
class Game
  attr_accessor :choice, :score

  def initialize
    self.choice = ""
    self.score  = 0
  end

  def shoot
    options = OPTIONS.keys.map { |k| k.to_s }
    @choice = ""
    while !options.include?(@choice)
      puts "Please choose from: Rock, Paper, or Scissors"
      @choice = gets.chomp.downcase
    end
    @choice
  end

  def shoot_computer
    options  = OPTIONS.keys.map { |k| k.to_s }
    @choice  = options.sample
    puts "Computer chose: #{@choice.capitalize}"
    @choice
  end

  def win
    @score += 1
  end
end

Concepts introduced:

Constants (THE_ROCK, OPTIONS)
Symbols vs strings: :rock keys but we compare with lowercase strings from input (.to_s)
Encapsulation: player state (@score, @choice) lives inside the object
Loops & I/O: a while + gets.chomp for robust input

Step 3 — Core game logic (`game_play.rb`)

We’ll keep winner logic data‑driven with a single hash. If POSSIBILITIES[p1] == p2, then player 1 wins.

# game_play.rb
require "./select.rb"

# Win rules (strings to match input)
POSSIBILITIES = {
  "rock"     => "scissors",
  "scissors" => "paper",
  "paper"    => "rock"
}

VS = "
 _   _  ___  
( ) ( )(  _`\\
| | | || (_(_)
| | | |`\\__ \\
| \\_/ |( )_) |
`\\___/'`\\____)
"

# Pure helper that returns :tie, :p1, or :p2
def winner_result(choice1, choice2)
  return :tie if choice1 == choice2
  return :p1  if POSSIBILITIES[choice1] == choice2
  :p2
end

# One round. If vs_computer is true, second player is the CPU.
# Prints hands, result, and updates scores.
# Returns :tie, :p1, or :p2

def play_round(player_1, player_2, vs_computer)
  puts "Player 1:"
  player_1_choice = player_1.shoot

  if vs_computer
    puts "Computer:"
    player_2_choice = player_2.shoot_computer
  else
    puts "Player 2:"
    player_2_choice = player_2.shoot
  end

  result = winner_result(player_1_choice, player_2_choice)

  if result == :p1
    player_1.win
  elsif result == :p2
    player_2.win
  end

  puts "\nPlayer 1:\n#{OPTIONS[player_1_choice.to_sym]}"
  puts VS
  puts "Player 2:\n#{OPTIONS[player_2_choice.to_sym]}"

  if result == :tie
    puts "\nTie!"
  elsif result == :p1
    puts "\nPlayer 1 wins"
  else
    puts vs_computer ? "\nComputer wins" : "\nPlayer 2 wins"
  end

  puts "\nPlayer 1 Score: #{player_1.score}, Player 2 Score: #{player_2.score}\n"

  result
end

Concepts introduced:

Hash as rule table (smallest DSA that solves the problem cleanly)
Pure function winner_result (great for tests)
Separation of concerns: printing/UI is in play_round; rule is in winner_result

Step 4 — The main game loop (`app.rb`)

A banner, choose a mode, and a replay loop with input validation.

# app.rb
require "./select.rb"
require "./game_play.rb"

puts "WELCOME To The Game of
    _______             _______             _______
---'   ____)       ---'    ____)____   ---'    ____)____
      (_____)             ______)             ______)
      (_____)             _______)          __________)
      (____)              _______)          (____)
---.__(___)         ---.__________)         ---.__(___)
Rock                  Paper                   Scissors"

# Choose mode
mode = ""
until ["1","2"].include?(mode)
  puts "Choose a mode: 1) Player vs Player  2) Player vs Computer"
  mode = gets.chomp
end

vs_computer = (mode == "2")

player_1 = Game.new
player_2 = Game.new

# Replay loop
loop do
  play_round(player_1, player_2, vs_computer)

  puts "Play again? (P to play, Q to quit)"
  replay = gets.chomp.downcase
  break if replay == "q"
end

puts "Thanks for playing!"

Concepts introduced:

Top‑level orchestration lives in one file
Guarded input: until ["1","2"].include?(mode) and P/Q replay prompt
Keep require at the top (don’t reload code each round)

Step 5 — Unit tests with MiniTest (`test/test_game.rb`)

We test the pure logic and the computer chooser—no hanging tests waiting for gets.

# test/test_game.rb
require "minitest/autorun"
require_relative "../select"
require_relative "../game_play"

class RpsTest < Minitest::Test
  def test_winner_result_all_pairs
    assert_equal :tie, winner_result("rock", "rock")
    assert_equal :p1,  winner_result("rock", "scissors")
    assert_equal :p2,  winner_result("rock", "paper")

    assert_equal :p1,  winner_result("paper", "rock")
    assert_equal :p2,  winner_result("paper", "scissors")

    assert_equal :p1,  winner_result("scissors", "paper")
    assert_equal :p2,  winner_result("scissors", "rock")
  end

  def test_computer_choice_is_valid
    cpu = Game.new
    50.times do
      choice = cpu.shoot_computer
      assert_includes ["rock","paper","scissors"], choice
    end
  end

  def test_scoring_when_p1_wins
    p1 = Game.new
    p2 = Game.new
    result = winner_result("rock","scissors")
    p1.win if result == :p1

    assert_equal 1, p1.score
    assert_equal 0, p2.score
  end
end

Run tests:

ruby -Itest test/test_game.rb

Concepts introduced:

Testing I/O‑heavy code by isolating logic into pure helpers
Assertions: assert_equal, assert_includes

Refactor Showcases — from procedural X ➜ clean OOP Y

All examples use the same beginner syntax as the repo (no keyword args, no heredocs, no &.). Use these as quick diffs when you’re cleaning up code.

1) Input validation loop

Before (leaks invalid values):

OPTIONS = ["rock","paper","scissors"]

def shoot
  puts "Choose Rock, Paper, or Scissors:"
  choice = gets.chomp.downcase
  unless OPTIONS.include?(choice)
    puts "Invalid choice"
  end
  choice # may be invalid
end

After (clean loop; returns only valid):

OPTIONS = { :rock=>nil, :paper=>nil, :scissors=>nil }

def shoot
  options = OPTIONS.keys.map { |k| k.to_s }
  choice = ""
  while !options.include?(choice)
    puts "Choose Rock, Paper, or Scissors:"
    choice = gets.chomp.downcase
  end
  choice
end

2) Winner logic

Before (branch soup):

def check_winner(c1, c2)
  if c1=="rock" && c2=="scissors"
    :p1
  elsif c1=="scissors" && c2=="paper"
    :p1
  elsif c1=="paper" && c2=="rock"
    :p1
  elsif c1==c2
    :tie
  else
    :p2
  end
end

After (tiny rule table):

POSSIBILITIES = { "rock"=>"scissors", "scissors"=>"paper", "paper"=>"rock" }

def winner_result(c1, c2)
  return :tie if c1 == c2
  return :p1  if POSSIBILITIES[c1] == c2
  :p2
end

3) Score handling

Before (globals):

$p1_score = 0
$p2_score = 0

def win!(who)
  if who == :p1 then $p1_score += 1 else $p2_score += 1 end
end

After (on the player object):

class Game
  attr_accessor :score
  def initialize; self.score = 0; end
  def win; self.score += 1; end
end

4) Replay structure

Before (requires inside loop):

while true
  require "./pvp.rb"
  puts "Play again? q to quit"
  break if gets.chomp == "q"
end

After (single entry file + clean call):

require "./select.rb"
require "./game_play.rb"

loop do
  play_round(player_1, player_2, vs_computer)
  puts "Play again? (q to quit)"
  break if gets.chomp.downcale == "q"
end

Run the game

ruby app.rb

Follow the prompts:

1 = Player vs Player
2 = Player vs Computer
After each round: P to play again, Q to quit

What you learned (Ruby & design)

OOP essentials: classes, instance variables, encapsulation, methods
CLI I/O: gets.chomp, printing, ASCII fun
Control flow: loops, input validation
Data structures: arrays & a hash as a rule table (DRY and scalable)
Separation of concerns: tiny files with single responsibilities
Testing mindset: factor logic into pure functions and test them

Stretch ideas

“Best of N” series
Score persistence across runs (save to a file)
Add Lizard/Spock—just extend the POSSIBILITIES hash
Colorized output (gems like colorize)

rock-paper-scissors

Could AI Truly Feel?

Arsalan Bardsiri — Sun, 17 Aug 2025 23:41:24 +0000

Bridging the Binary: Could AI Truly Feel? 🤔

Hey everyone! I had a fascinating conversation recently that really got me thinking about the future of AI, specifically the elusive goal of imbuing these incredible models with genuine emotions.

The Spark of an Idea 💡

The discussion started with a question about the foundational languages of the web, and it naturally evolved into the vastness of our current binary-driven digital world. This then led to pondering the even more complex realm of quantum computing and its potential to break free from the constraints of 0s and 1s.

It was at this point that an interesting analogy struck me (or rather, was shared with me!): human emotions can be seen as a kind of superposition.

Think about it. How often do we experience a purely singular emotion? Joy can be tinged with sadness, excitement with anxiety. We hold multiple, sometimes contradictory, feelings simultaneously. This isn't a simple "either/or" state like a bit in a computer; it's a "both/and," much like a qubit existing in multiple states at once.

The Challenge of Defining and Replicating Emotion 🧠❤️

As our conversation explored, the challenge of emotional AI isn't just about programming a machine to say it feels something. True emotion involves a complex interplay of:

Physiological responses: Changes in heart rate, hormones, etc.
Cognitive appraisal: Our interpretation of events.
Behavioral expressions: Facial cues, body language.

Current AI models excel at pattern matching. They can analyze vast amounts of text and data to understand and even generate text that mimics emotional expression. But are they feeling it? Probably not in the way we do. They're simulating, not experiencing.

Superposition as a Metaphor for Emotional Complexity ⚛️

The superposition analogy really highlights the limitations of our current binary approaches when it comes to emotions. We're trying to model something inherently complex and nuanced with systems built on rigid 0s and 1s.

To move towards AI with genuine emotional intelligence, we might need to consider:

Contextual Understanding: AI that can truly grasp the multifaceted nature of human situations.
Synthesis of Mixed States: Models capable of processing and holding multiple emotional states without simplifying them.
A Form of Subjectivity: This is the big one. Could AI develop an internal "self" capable of experiencing and reacting to the world in a subjective way?

A Human-to-Human Future? 🤔🤝🤖

The idea that one day we might be able to have a truly human-to-human experience – a face-to-face conversation filled with genuine understanding and empathy – with an AI is both exciting and a little mind-bending.

Perhaps insights from fields like quantum computing, with its inherent acceptance of multiple states, could offer new frameworks for designing AI architectures that can move beyond the binary and embrace the beautiful, messy complexity of human emotion.

Let's Discuss! 👇

What are your thoughts on emotional AI? Is it a pipe dream, or a logical next step in the evolution of artificial intelligence? Could concepts from quantum computing inspire new approaches? Share your ideas and let's get a discussion going!

Ruby basics cheat sheet

Arsalan Bardsiri — Sun, 17 Aug 2025 18:05:23 +0000

My Ruby Learning Journey: From `while` Loops to a Cheat Sheet

Learning to code can feel like you're constantly collecting a mountain of notes and code snippets. Recently, I was struggling to nail down Ruby's basic control flow, especially with while loops. The syntax seemed simple, but keeping track of the loop condition and the iterator was a challenge.

After working through it, I realized a lot of my frustration came from managing too many moving parts. A while loop requires you to declare an iterator, set a condition, and manually increment the iterator inside the loop.

I was surprised to discover how much cleaner a for loop is for this exact task. The syntax for i in 1..5 handles everything—the starting value, the ending value, and the incrementing—all in one line. This simple change made me appreciate how different loops are designed for different tasks.

This experience inspired me to collect all the core Ruby concepts I've been learning into a single, clean reference guide. I wanted something I could look at quickly to remember a method or its syntax.

Here's the cheat sheet I put together, covering the fundamentals that every Ruby developer should know.

The Ruby Fundamentals

1. Core Data Types

Topic	Key Methods & Concepts	Example
Strings	`length`, `count`, `upcase`, `capitalize`, `gsub`	`"Hello".length` => `5`
Integers & Floats	Division behavior, `.odd?`/`.even?`, `.to_f`	`10 / 3` => `3` <br>`10 / 3.0` => `3.333...`

2. Collections

Topic	Key Methods & Concepts	Example
Arrays	`push` (`<<`), `pop`, `delete`, `delete_at`	`[1, 2].push(3)` => `[1, 2, 3]`
Hashes	Keys & Values, `[]` for access, `fetch`	`h = {:a => 1}; h[:a]` => `1`

3. Control Flow

Topic	Key Methods & Concepts	Example
Conditionals	`if`, `unless`	`if x > 0`<br>`unless x <= 0`
Loops	`each`, `select`, `reject`, `while`, `for`	`[1,2,3].each {..}`<br>`for i in 1..5`

I found that going back to these basics and creating my own reference was incredibly helpful. It reinforces the concepts in a way that just reading a tutorial can't.

If you're interested in an even more dynamic version of this, I built an interactive web app that lets you search and copy code examples instantly. You can check out the full code in a previous post here.

I hope this helps you on your own Ruby journey!

TIL - CSS Media Queries

Arsalan Bardsiri — Mon, 04 Aug 2025 04:46:50 +0000

Mastering the Viewport: An Intro to CSS Media Queries

When we create a website, we want it to look good on every device, from a large desktop monitor to a small smartphone screen. This is the core principle of responsive web design, and the key tool for achieving it is the CSS media query.

A media query allows us to apply specific styles only when certain conditions are met, such as the screen width. This means we can serve a different, optimized layout to a user on a mobile device without building a completely separate website. It's how a website can "respond" to its environment.

Let's look at a simple example. We'll start with a basic layout that works on desktop, and then use a media query to change it for mobile.

Our Default (Desktop) Layout

/* Styles for screens larger than 768px (the default) */
.container {
  display: flex;
  justify-content: space-between;
  padding: 20px;
  background-color: #f0f0f0;
}

.box {
  width: 30%;
  padding: 20px;
  background-color: #007bff;
  color: white;
  text-align: center;
  border-radius: 8px;
}

This CSS creates a horizontal row of three boxes, perfect for a desktop screen.

The Mobile View: Using a Media Query
Now, let's use a media query to stack these boxes vertically when the screen is too narrow to hold them side-by-side. We'll set a "breakpoint" at 768 pixels, a common width for tablets.

@media (max-width: 768px) {
  .container {
    flex-direction: column; /* Stack the boxes vertically */
    align-items: center;    /* Center the stacked boxes */
  }

  .box {
    width: 90%;             /* Make the boxes wider to fill the screen */
    margin-bottom: 15px;    /* Add some space between them */
  }
}

This code tells the browser: "When the screen is 768 pixels wide or less, apply these new styles." The flex-direction: column property is the magic that changes our layout from a row to a stack, and we adjust the box width and margin to make it look great on a phone.

By using media queries, you can ensure your web applications are not only functional but also provide a great user experience, no matter how a user is viewing them. It's a fundamental step in building modern, accessible websites.

TIL - Html and CSS

Arsalan Bardsiri — Sun, 03 Aug 2025 02:35:07 +0000

Why HTML and CSS Are Still the Building Blocks of the Web

It's easy to get caught up in the excitement of powerful back-end languages like Ruby, Python, and Node.js (JavaScript). With so much focus on frameworks like Ruby on Rails or React, it can be tempting to overlook the foundational languages of the web: HTML and CSS. However, regardless of whether you're working with the LAMP stack or the modern MERN stack, a strong understanding of these two is non-negotiable. Without them, even the most sophisticated back-end logic would have no face for users to interact with.

Think of it this way: HTML provides the structure, the skeleton of your web page. It defines the content, headings, paragraphs, and buttons. On its own, a web page is functional but visually plain and unengaging.

A Simple HTML Structure

<div class="card">
  <h3>My Post Title</h3>
  <p>This is the content of my amazing blog post.</p>
  <button>Read More</button>
</div>

Here's what that code looks like with just raw HTML:

This is where CSS comes in. It's the style, the design, the personality of your website. CSS takes that raw HTML structure and transforms it from a simple document into a visually appealing and intuitive user interface. By adding a few lines of CSS, we can completely change the look and feel, making the same HTML content feel polished and professional.

Adding CSS to Bring it to Life

.card {
  border-radius: 12px;
  box-shadow: 0 4px 8px rgba(0, 0, 0, 0.1);
  padding: 24px;
  background-color: #ffffff;
  max-width: 300px;
  margin: 20px;
  transition: transform 0.3s ease-in-out;
}

.card:hover {
  transform: translateY(-5px);
  box-shadow: 0 8px 16px rgba(0, 0, 0, 0.2);
}

.card h3 {
  color: #333;
}

.card p {
  color: #666;
}

.card button {
  background-color: #007bff;
  color: white;
  border: none;
  padding: 10px 15px;
  border-radius: 5px;
  cursor: pointer;
  transition: background-color 0.3s;
}

And here's the dramatic difference that a little bit of CSS makes:

The simple HTML div is now a visually appealing "card" with a subtle shadow, rounded corners, and a hover effect that makes it feel interactive. The button has a clean style and a smooth color transition. This small example demonstrates how CSS empowers us to create a rich and engaging experience for the user, turning a functional component into a delightful one. No matter what your back-end stack is, mastering HTML and CSS is the key to building a front-end that people love to use.

TIL - My First Dive into Ruby!

Arsalan Bardsiri — Thu, 31 Jul 2025 02:59:52 +0000

puts "hello world"

Today marks the beginning of my journey into the world of Ruby! My first discovery was the straightforward way to print output using puts.

One of the most interesting things I've learned already is about Ruby's indentation. Unlike Python, where indentation is syntactically enforced and crucial for code execution, Ruby uses it primarily for readability. The interpreter doesn't rely on it; instead, Ruby uses keywords like end to explicitly close code blocks. This is a neat difference!

What I truly love about coding is how diverse it is. The choice of programming language often depends on the ecosystem you're working in and the product you're building. While core programming concepts remain consistent across languages, each one offers unique approaches and philosophies. It's fascinating to see how individual developers adapt and express their ideas within these different frameworks. I'm really excited about this learning journey!

DEV Community: Arsalan Bardsiri

From Monolith to Modular (A basic simple example)

From Monolith to Modular

Phase 1: The Simple Single Server (2-Tier)

The Architecture

Why start here?

The Wall

Phase 2: The Evolution to 3-Tier Architecture

The Architecture

The "Aha!" Moment

What's Next?

The Ruby & Sinatra Playbook from Core Concepts to Tiny Web Apps

Table of contents

Why this guide

1) Ruby fundamentals

Values & literals

Strings & symbols

Methods, default & keyword args

Multiple assignment & splats

Blocks & yield

2) Enumerable patterns (the 80/20)

3) OOP & modules in Ruby

Minimal class, accessors, class vs instance methods

Modules as mixins (behavior), namespaces (organization)

Struct and OpenStruct

4) Sinatra crash course (routes, params, views, helpers)

Minimal project layout

Gemfile

Routes & params

Views (ERB)

ASCII request flow

5) Mini testing intro (Minitest + Rack::Test)

6) Advanced peeks (procs, lambdas, meta, refinements, lazy)

Procs vs lambdas

Metaprogramming (define readers on the fly)

Refinements (scoped monkey-patch)

Lazy enumerators (streaming style)

7) Deployment notes (Render/Vercel-style providers)

8) Practice checklist

9) Tiny reference (copy/paste)

Final words

From Functions to OOP: Building a Rock–Paper–Scissors CLI in Ruby

What you’ll build

Prereqs

Final project structure

Step 1 — Start the project

Step 2 — The Player class (select.rb)

Step 3 — Core game logic (game_play.rb)

Step 4 — The main game loop (app.rb)

Step 5 — Unit tests with MiniTest (test/test_game.rb)

Refactor Showcases — from procedural X ➜ clean OOP Y

1) Input validation loop

2) Winner logic

3) Score handling

4) Replay structure

Run the game

What you learned (Ruby & design)

Stretch ideas

Could AI Truly Feel?

Bridging the Binary: Could AI Truly Feel? 🤔

The Spark of an Idea 💡

The Challenge of Defining and Replicating Emotion 🧠❤️

Superposition as a Metaphor for Emotional Complexity ⚛️

A Human-to-Human Future? 🤔🤝🤖

Let's Discuss! 👇

Ruby basics cheat sheet

My Ruby Learning Journey: From while Loops to a Cheat Sheet

The Ruby Fundamentals

1. Core Data Types

2. Collections

3. Control Flow

TIL - CSS Media Queries

Mastering the Viewport: An Intro to CSS Media Queries

TIL - Html and CSS

Why HTML and CSS Are Still the Building Blocks of the Web

TIL - My First Dive into Ruby!

Blocks & `yield`

`Struct` and `OpenStruct`

Step 2 — The Player class (`select.rb`)

Step 3 — Core game logic (`game_play.rb`)

Step 4 — The main game loop (`app.rb`)

Step 5 — Unit tests with MiniTest (`test/test_game.rb`)

My Ruby Learning Journey: From `while` Loops to a Cheat Sheet