Forem: Tahsin Abrar

DNS Made Simple: What Really Happens Before Your Browser Opens a Website

Tahsin Abrar — Thu, 23 Apr 2026 16:25:15 +0000

We use domain names every day.

We type google.com, facebook.com, or linkedin.com into a browser, press Enter, and the website opens in seconds. It feels simple. Almost boring.

But under the hood, something very important happens before your browser can even start talking to that website.

That thing is DNS.

And here is the part many developers miss early on: if you want to understand TLS/SSL, networking, deployment, or even why a request is slow, you need to understand DNS first.

Because before secure communication begins, your browser has to answer one basic question:

"Where is this website actually hosted?”

Let's break it down in the simplest possible way.

First, let's understand the URL

Take this URL:

https://blog.example.com

It has a few parts:

https → the scheme or protocol
blog → the subdomain
example → the main domain
.com → the top-level domain (TLD)

Another example:

https://engineering.linkedin.com

Here:

https is the protocol
engineering is the subdomain
linkedin is the domain
.com is the TLD

This structure matters because DNS works with these names.

Before we go into DNS, we need to understand one thing clearly:

a domain name is not the real machine address.

It is the human-friendly name for that machine.

Why domain names exist

Humans are good at remembering words.

Machines are good at working with numbers.

That is the heart of the whole idea.

You can easily remember:

facebook.com

But remembering something like this is much harder:

157.240.22.35

That number is an IP address.

An IP address is the real network address of a machine or server.

So when you type a domain name into a browser, your system has to find the IP address behind that name.

That translation is what DNS does.

A simple real-life example

Think about your home address.

If someone knows your address, they can find your house.

Computers work in a similar way.

Every machine connected to a network needs an address. On the internet, that address is the IP address.

Now imagine you built an app locally on your laptop. Maybe it runs on:

localhost:3000

That works on your own machine because your machine knows what localhost means.

But if you deploy that app to a server on AWS, DigitalOcean, or anywhere else, people cannot visit it using localhost.

They need the address of that server.

That real address is the IP address.

But asking users to remember IP addresses is a terrible experience.

So instead of telling people:

Visit 142.250.183.206

we give the server a domain name like:

myapp.com

Now people can remember the name, and machines can still connect using the IP.

That mapping between a human-friendly name and a machine-friendly IP is the whole point of DNS.

So what is DNS?

DNS stands for Domain Name System.

Let's keep it simple:

DNS is the system that converts a domain name into an IP address.

For example:

You type facebook.com
DNS finds the IP address behind facebook.com
Your browser uses that IP to contact the correct server

It is called a system because it is not just one thing.

It involves multiple parts working together:

your browser
your operating system
DNS caches
a DNS resolver
root name servers
TLD name servers
authoritative name servers

That is why it is not called just "domain name lookup.”

It is a system.

Before DNS goes to the internet, it checks cache

This is one of the most useful things to understand.

When you visit a website, your computer does not always start from scratch.

It first checks whether the answer is already stored somewhere.

This stored answer is called cache.

Think of cache like a shortcut memory.

If the system already knows the IP address for a domain, it can skip a lot of work.

That makes everything faster.

Usually, the lookup goes through these layers:

Browser cache
Operating system cache
DNS resolver cache
If not found, then the full DNS lookup starts

That is why websites often open very quickly the second time you visit them.

The full DNS journey, step by step

Now let's walk through what actually happens when you type:

facebook.com

into your browser.

1. The browser checks its own cache

Your browser first asks:

"Do I already know the IP for this domain?”

If yes, great. It uses that IP immediately.

If not, it moves to the next step.

2. The operating system checks its cache

If the browser does not have the answer, your operating system checks whether it has that domain-to-IP mapping stored.

If the OS already knows it, it returns the IP to the browser.

If not, the request continues.

3. The system asks a DNS resolver

Now the request goes to a DNS resolver.

In many cases, this resolver belongs to your ISP, though it could also be a public DNS service.

Its job is to find the answer for you.

And just like the browser and OS, the resolver also checks its own cache first.

If the resolver already knows the IP for facebook.com, it returns it immediately.

If not, now the real DNS lookup begins.

The resolver starts asking other DNS servers

This is where many learners get confused, but the logic is actually very clean.

The resolver does not magically know every IP address in the world.

Instead, it asks the right servers in the right order.

4. It asks a root name server

The resolver asks a root name server something like:

"I need information about .com. Where should I go next?”

Notice something important:

It is not asking for the final IP address yet.

It is asking where the .com information is managed.

The root server replies with the address of the TLD name server for .com.

5. It asks the TLD name server

Now the resolver goes to the .com TLD server and asks:

"Who is responsible for facebook.com?”

Again, this server usually does not return the final website IP directly.

Instead, it returns the address of the authoritative name server for that domain.

That server is the source of truth for the domain's DNS records.

6. It asks the authoritative name server

Now the resolver asks the authoritative name server:

"What is the IP address for facebook.com?”

This server returns the actual DNS record, such as the IP address.

Now the resolver finally has the answer it needs.

7. The answer comes back and gets cached

Once the resolver gets the IP address, it does two useful things:

it returns the answer to your operating system
it stores the answer in cache for future requests

Then the OS may cache it too.

Then the browser may cache it too.

That means the next lookup can be much faster.

8. The browser can finally contact the server

Now your browser has the IP address.

At this point, it can finally open a network connection to the actual server and send the real HTTP or HTTPS request.

That is the moment when the website request truly begins.

So yes, DNS happens before the browser can talk to the web server.

And that is exactly why DNS matters when learning TLS/SSL.

A simple mental model

If all the server names sound too abstract, use this mental model:

Root server → "I do not know the full answer, but I know who handles .com.”
TLD server → "I do not know the full answer, but I know who handles facebook.com.”
Authoritative server → "I am responsible for this domain. Here is the actual answer.”

That is the chain.

Why DNS is called "resolution”

You may hear the phrase:

DNS resolution

This simply means:

the process of resolving a domain name into an IP address

So if someone says:

"The DNS resolution failed”

they mean:

"The system could not turn the domain name into an IP address”

No IP, no connection.
No connection, no website.

Where subdomains fit into this

Let's say you have a domain like:

example.com

You can create subdomains like:

blog.example.com
api.example.com
admin.example.com

This is useful because one domain can support multiple services.

For example:

blog.example.com → blog website
api.example.com → backend API
admin.example.com → internal admin dashboard

Same parent domain.
Different subdomains.
Different purposes.

That is why learning domain structure matters before learning DNS deeply.

Why websites feel fast after the first visit

A lot of developers notice this but do not always connect it to DNS.

The first request may take a bit longer because the system needs to find the IP.

Later requests are faster because the answer may already exist in:

browser cache
OS cache
resolver cache

That means the system can skip most of the lookup chain.

So if a website opens instantly the second time, caching is often part of the reason.

Does DNS use TCP or UDP?

In simple learning material, DNS is often explained with UDP, and that is a good starting point.

Why?

Because UDP is lightweight and fast. It does not need a full connection setup like TCP.

For many standard DNS queries, that makes it a great fit.

A simple way to think about it is:

DNS wants to ask a quick question
get a quick answer
and move on

That said, in real systems, DNS can also use TCP in some cases.

But when you are first learning how DNS feels fast and lightweight, starting with UDP gives you the right intuition.

Why DNS matters before TLS/SSL

This is the part many people skip.

They jump into HTTPS, SSL certificates, and TLS handshakes without asking a more basic question:

How did the browser even find the server in the first place?

Before secure communication starts, the browser needs to know where to connect.

That means:

resolve the domain name into an IP address
connect to the server
then begin TLS/SSL and HTTP communication

So if DNS is unclear, TLS/SSL will always feel a little foggy too.

Understanding DNS first makes the next networking topics much easier.

Why developers should care about this

It is easy to think:

"Do I really need to know all this? I can just build apps.”

You can. For a while.

But sooner or later, deeper understanding starts to matter.

Maybe:

your production request is slow
your domain is not pointing to the right server
your subdomain is broken
your SSL setup is failing
your infrastructure behaves differently across environments
a tool's official docs feel harder than they should

This is where fundamentals help.

When you understand DNS, you stop treating networking like magic.

You start seeing the path.

And once you can see the path, debugging becomes easier.

A small story every developer can relate to

Imagine this.

You deploy your app.
The code is fine.
The server is running.
But the site still does not open.

At first, you think:

is the backend broken?
is the port wrong?
is Nginx failing?
is HTTPS misconfigured?

But the real problem turns out to be simple:

the domain is not resolving correctly.

That one small DNS issue can make the whole app feel "down.”

This is why solid developers do not only learn frameworks.

They learn what happens around the request too.

The big lesson: do not skip the basics

A lot of hard topics become easier when your basics are strong.

Docker makes more sense.
Kubernetes makes more sense.
TLS/SSL makes more sense.
Load balancers, CDNs, proxies, reverse proxies, and hosting all make more sense.

Not because they are easy.

But because you already understand the ground they stand on.

Many developers struggle with official docs not because their English is bad, but because the underlying computer science concepts are still shaky.

That is normal.

And the fix is not shortcuts.

The fix is going back, learning the core ideas properly, and revisiting them again and again until they feel natural.

That is how real confidence is built.

Demystifying TCP: How the Internet Actually Sends Your Data (Without Losing It)

Tahsin Abrar — Mon, 13 Apr 2026 07:58:22 +0000

Let’s be honest for a second. When we write code to fetch data from a server, we usually don't think twice about how it gets there. We write a simple JavaScript fetch() call, hit save, and boom our frontend talks to our backend.

fetch('https://api.example.com/data', {
  method: 'POST',
  body: JSON.stringify({ message: "Hello World" })
});

To us, it feels like magic. We just say "send this," and it arrives. But the Application Layer (where our code lives) is blissfully unaware of the chaotic, noisy, and unpredictable journey that data takes across the internet.

The real unsung hero making sure your "Hello World" doesn't turn into a corrupted mess of random bytes is the Transport Layer specifically, the TCP (Transmission Control Protocol).

Today, we are going to look under the hood. No dry, boring textbook definitions. Just a practical, developer-friendly look at how TCP actually works, how it keeps our data safe, and why understanding it will make you a much better software engineer.

What is TCP, Really?

Imagine you are mailing a 1,000-page manuscript to a publisher, but the post office only allows you to send one page per envelope.

If you just dump 1,000 envelopes into the mailbox, what happens? Some might get lost. Some might arrive out of order. The publisher would be hopelessly confused.

TCP is the ultimate postal manager. It chops your big data into smaller pieces called segments, numbers them, sends them, and waits for a receipt. If a piece goes missing or gets corrupted, TCP demands that it be sent again.

That’s why the "C" in TCP stands for Control. It controls the transmission so you don't have to.

To do this, TCP breaks communication down into three distinct phases:

The Setup (Three-way Handshake)
The Data Transfer
The Teardown (Four-way Finishing)

Let’s walk through them.

Phase 1: The Three-Way Handshake 🤝

Before TCP sends a single byte of your actual data, it needs to make sure the server is awake, willing, and ready to talk. It does this using a process called the Three-Way Handshake.

Imagine calling a friend on the phone:

You: "Hey, are you there? Can you hear me?" (SYN)
Friend: "Yeah, I hear you! Can you hear me?" (SYN-ACK)
You: "Loud and clear. Let's talk." (ACK)

In TCP terms, it looks like this:

SYN (Synchronize): The Client sends a packet with the SYN flag turned on. It says, "I want to connect, and I'm starting my sequence at number 1000."
SYN-ACK (Synchronize-Acknowledge): The Server replies. "I got your request (ACK 1001), and I also want to connect. My sequence starts at 2000" (SYN).
ACK (Acknowledge): The Client sends one final confirmation. "Got it. I'm ready for your data starting at 2001."

Boom. The connection is established. Now, they can safely send data.

What’s Inside a TCP Segment? (The Anatomy of a Header)

When TCP chops up your data, it doesn't just send raw text. It wraps your data in a Header a block of metadata that contains all the instructions for delivery.

A TCP header is usually between 20 and 60 bytes. Let's break down the coolest parts of this header.

1. The Ports (Source & Destination)

You probably know that an HTTP server runs on port 80, HTTPS on 443, and your local React app maybe on 3000. But have you ever wondered what port the client (your browser) uses to make the request?

The TCP header reserves 16 bits each for the Source Port and the Destination Port. 16 bits means $2^{16} - 1$, which gives us a maximum of 65,535 possible ports.

Well-known ports (0 - 1023): Reserved for big stuff. (80 for HTTP, 443 for HTTPS, 22 for SSH).
Registered ports (1024 - 49151): Used by specific apps (like MySQL on 3306).
Ephemeral / Dynamic ports (49152 - 65535): This is the secret sauce!

When your browser makes a request to Facebook (port 443), your Operating System randomly grabs an unused Ephemeral port (let's say 50153) and assigns it to your browser. So the request goes from Your_IP:50153 to Facebook_IP:443. When Facebook replies, it knows exactly to send the data back to port 50153, so it reaches your exact browser tab!

2. Sequence & Acknowledgment Numbers

These are the page numbers of our manuscript analogy.

Sequence Number: "This is byte number 1001 of my data."
ACK Number: "I successfully received up to byte 1005. Please send byte 1006 next."

3. Window Size (Flow Control)

Imagine trying to drink from a firehose. You'd drown. Servers can experience the same thing if a client sends data too fast.

The Window Size is the server politely saying: "Listen, I can only handle 10,000 bytes at a time right now. Don't send me more than that until I acknowledge receipt, or I'll crash." This prevents overwhelming the receiver.

4. The Checksum (Error Detection)

As data travels across the ocean through fiber optic cables, routers, and Wi-Fi signals, electrical interference can flip a bit (turn a 0 into a 1). Your "I love you" might suddenly turn into "I hate you".

To fix this, TCP uses a Checksum. Before sending, the sender takes all the data, adds it up in a specific binary way, flips the bits (One's Complement), and puts that value in the Checksum field.

When the receiver gets it, they do the exact same math. If their result doesn't perfectly match, they know the data got corrupted in transit. They silently drop the corrupted segment, forcing the sender to re-transmit it.

5. Flags

These are tiny 1-bit switches that tell the receiver what kind of segment this is. Is it a setup request (SYN)? Is it an acknowledgment (ACK)? Or is it time to close the connection (FIN)?

Phase 2: Sending the Data

Once the handshake is done, the actual data transfer begins.

Let's say we are sending the string "Hello World". Based on the Maximum Segment Size (MSS) agreed upon during the handshake, TCP might split this into multiple segments.

The client sends "Hell", the server ACKs it. The client sends "o Wo", the server ACKs it.

Because of the Window Size, the client doesn't actually have to wait for an ACK after every single segment. If the window is large enough, it can blast 10 segments at once, and the server can send a single ACK saying, "Yep, got all 10!"

If an ACK never arrives, the sender's internal timer runs out, and it assumes the data was lost in the void. It then resends the data. That's the beauty of it it guarantees delivery.

Phase 3: The Four-Way Teardown 👋

When the client is done sending data, it doesn't just hang up the phone. It's polite. It initiates a Four-Way Teardown.

Client: Sends a FIN (Finish) flag. "I'm done sending data."
Server: Sends an ACK. "Understood, you're done." (At this point, the server might still have a little bit of its own data left to send back to the client. The client will wait and listen).
Server: Sends its own FIN. "Okay, I'm done sending data too."
Client: Sends a final ACK. "Got it. Goodbye forever."

The connection is closed, and the OS frees up the ephemeral port to be used by another application later.

Why Should You Care as a Developer?

You might be thinking, "This is cool, but my framework handles this. Why do I need to know it?"

Because things break.

When your API requests start timing out, understanding the Three-way Handshake helps you debug if a firewall is blocking your SYN packets.
When you wonder why you can't run two node servers on port 3000, you now understand how Ports bind to processes.
When you design high-traffic systems, understanding Window Size helps you realize why servers get overwhelmed and drop connections.

Understanding TCP is like moving from driving an automatic car to a manual transmission. You don't have to think about the gears every day, but when you're stuck in the mud, knowing exactly how the engine connects to the wheels is what gets you out.

Why We Talk OSI but Live in a TCP/IP World (A Developer’s Guide)

Tahsin Abrar — Sun, 12 Apr 2026 10:55:37 +0000

If you’ve ever sat in a tech meeting and nodded along while another engineer threw around terms like "Layer 7 load balancing" or "L4 routing," you aren't alone.

We talk about networking a lot in software development, but there’s a funny quirk in our industry: the model we learn in textbooks isn't exactly the model that runs the internet.

In our last deep dive, we talked about the OSI model a beautiful, theoretical 7-layer philosophy. But out in the wild? The entire world runs on the TCP/IP model.

Today, let's bridge the gap between theory and reality, figure out how data actually moves across the internet, and look at the only layers you actually need to care about as a software engineer.

The Reality Check: 7 Layers vs. 5 Layers

The OSI model breaks networking down into 7 distinct layers. But the TCP/IP model, which is what actually powers the internet today, condenses things down to just 5 layers:

Application Layer
Transport Layer
Network Layer
Data Link Layer
Physical Layer

Wait, what happened to the Presentation and Session layers from the OSI model?

In the real world, they didn't disappear; they just got absorbed. When you are building a modern web app say, a Nuxt.js frontend communicating with a Laravel backend your browser and framework handle everything at once.

When you type "Hello" in a chat app, the Application Layer formats that text into JSON (what the Presentation layer used to do), compresses it, converts it to binary, and even checks if the other person is online with that little green dot (what the Session layer used to do). Because the Application Layer handles all of this heavy lifting, the TCP/IP model just groups them together.

A Crucial Developer Rule: Even though the TCP/IP model condensed the top layers, we still use OSI numbering in our everyday developer conversations! We still call the Application Layer L7. We call the Transport layer L4, Network is L3, and Data Link is L2. If you ever call the Application layer "L5," other engineers will look at you funny. Always stick to the L7 terminology!

Layer 4: The Transport Layer (TCP vs. UDP)

Once your application has prepped the data, it hits the Transport Layer. This is where we decide how the data is going to travel, and you have two main choices: TCP or UDP.

TCP (Transmission Control Protocol)

Think of TCP as the highly reliable, slightly slower courier who requires a signature on delivery. It is 100% controlled.

Imagine you are sending a text message that says "I LOVE YOU." If the data gets scrambled and arrives as "O I V E U Y," you're going to have a bad time. For text, JSON payloads, important API requests, or critical database transactions, we use TCP. It ensures every single piece of data arrives in the exact right order. When using TCP, your data is broken down into chunks called Segments.

UDP (User Datagram Protocol)

UDP is the fast, reckless delivery driver throwing newspapers onto your porch without stopping. It doesn't care if a few get lost in the bushes.

We use UDP for things like live video streaming. If a stream contains 10 million frames and a couple of them drop out, your screen might glitch for a fraction of a second, but the video keeps playing. You wouldn't want the whole live stream to pause just to retrieve one missing frame. When using UDP, your data is broken down into chunks called Datagrams.

Moving Down the Stack: L3 to L1

After the Transport Layer, the data keeps moving down the chain:

Network Layer (L3): This is where IP addresses come in. Your data (the Segment or Datagram) gets tagged with the Sender's IP and the Receiver's IP. Once those are attached, the whole package is now called a Packet.
Data Link Layer (L2): Here, we attach MAC addresses to figure out the physical hardware hops the packet needs to take.
Physical Layer (L1): Finally, everything is converted into 1s and 0s raw electrical signals or light pulses shooting through cables.

A quick note for my fellow software engineers: You really only need to master L7, L4, L3, and L2. Unless you have a burning desire to become an electrical engineer, you can safely let the hardware folks worry about the Physical Layer!

A Quick Trip Back to 1969

You might be wondering: if OSI is the standard, why is TCP/IP so different?

It actually comes down to the Cold War. In 1969, the US Defense Department created an organization called ARPANET. They needed a decentralized network where data could survive even if computers or physical locations were destroyed in a war. Over the next decade, they actively developed the TCP/IP model.

It was messy, organic, and random. In fact, TCP was being used to send data long before IP addresses were even a standard! The beautifully organized, perfectly logical OSI model didn't actually come along until 1984 to try and make sense of it all. We teach OSI first because it's fundamentally easier to understand, but TCP/IP is the battle-tested system that won the internet.

Demystifying Linux: How GNU, Shells, and Terminals Actually Work Together

Tahsin Abrar — Tue, 07 Apr 2026 10:09:39 +0000

If you've been working with Linux for a while, you probably know that "Linux" technically just refers to the kernel. But a kernel alone is not enough to give you a working computer. To get a complete Operating System (what we call a Linux Distribution, like Ubuntu or Fedora), you need a lot of other moving parts.

Today, we're going to peel back the layers of a Linux operating system. We'll look at where the tools we use every day actually come from, the difference between a terminal and a shell, and what happens behind the scenes when you type a simple command.

Let's dive in!

The Origin Story: Enter Richard Stallman and GNU

To understand how Linux works today, we have to travel back to 1983. Back then, an operating system called Unix was highly popular among universities and large companies. The problem? Unix was proprietary and expensive.

A programmer named Richard Stallman didn't like this. He believed software, especially operating systems, should be free and accessible to everyone. So, he started the Free Software Foundation (FSF) and launched the GNU Project.

Fun fact: GNU is a recursive acronym that stands for "GNU's Not Unix!"

Stallman's team began building free, open-source replacements for all the essential pieces of Unix. Their plan was to build everything needed for an OS, so that anyone students, devs, or companies could piece together a free operating system.

If you use open-source tools today, you owe a huge "thank you" to Stallman and the FSF.

The Essential GNU Toolkit

So, what exactly did the GNU project build? They created a massive bundle of tools that bridge the gap between human developers and the kernel. Here are the heavy hitters:

1. GCC (GNU Compiler Collection)

If you've ever written a C program, you know you can't just run the raw text. You need to compile it into binary machine code that the computer understands. GCC is the legendary compiler that makes this happen. Without it, the open-source world as we know it wouldn't exist.

2. glibc (GNU C Library)

This one is fascinating. When you write a simple printf("Hello World"); in C, did you know that printf isn't actually a native part of the C language?

Native C handles things like if/else' statements andfor' loops. But interacting with hardware (like printing to a screen, allocating memory, or reading files) requires talking to the kernel. glibc is the massive library that provides functions like printf, scanf, and malloc. It acts as a translator, taking your code and making the complex "system calls" to the kernel on your behalf.

3. GNU Coreutils

This is the toolbox you use every single day. Have you ever typed ls, cd, cat, grep, cp, or rm?
These aren't just random words; they are individual, standalone programs bundled together in what we call the GNU Core Utilities (or Coreutils). They run in the "user space" and allow you to interact with your system.

The Visual Layer: Desktop Environments (DE)

Okay, so we have the kernel (the engine) and the GNU utilities (the steering wheel and pedals). But how do we actually see what we are doing?

That's where Desktop Environments (DE) come in. When you install an OS and see a taskbar, window frames, a file explorer, and icons, you are looking at the DE.

Here are a few popular ones:

GNOME: The default for Ubuntu, Fedora, and Debian. It's modern and beginner-friendly.
KDE Plasma: Popular on Arch and openSUSE. It's incredibly customizable.
Aqua: The proprietary desktop environment used by Apple for macOS (which includes the Finder and the Dock).

The Desktop Environment is also responsible for giving you a Terminal. On Ubuntu (GNOME), it's called GNOME Terminal. On KDE, it's called Konsole. The terminal is just a graphical window an interface that lets you type things. But it doesn't process the commands itself. For that, it needs a Shell.

The Brains of the Operation: The Shell

If the Terminal is just a blank window, the Shell is the smart program running inside it.

The Shell takes the text you type, interprets it, figures out what program you want to run (like an ls command from the Coreutils), and hands that request over to the kernel. When the kernel is done, the Shell takes the output and prints it on your Terminal screen.

A Quick History of Shells:

sh (Bourne Shell): Created by Stephen Bourne at Bell Labs in 1977. The OG.
ksh (KornShell): Created by David Korn in 1983, adding more features.
bash (Bourne Again Shell): The GNU project's free answer to the original Bourne shell. It became the default for almost all Linux distributions for decades.
zsh (Z Shell): A modern, highly customizable shell. If you use a modern Mac, zsh is now the default

Stop Calling Docker a Tool: The Real Story Behind 'docker run hello-world'

Tahsin Abrar — Mon, 06 Apr 2026 10:57:28 +0000

Let’s get one thing straight right out of the gate: Docker is not just a tool. It’s not just a simple application, and it’s certainly not just a piece of standalone software.

If someone tells you Docker is just a software tool, you can confidently tell them they’ve been misled.

So, what is it? Docker is a platform. It is an ecosystem.

To truly master Docker, you have to stop looking at it as a black box that magically runs your code, and start looking at it as a living, breathing ecosystem. Today, we are going to dive deep into how this ecosystem actually works.

The Ecosystem Analogy

Think about a biological ecosystem a food chain. An earthworm is eaten by a duck, the duck is caught by a snake, the snake is hunted by a mongoose, and the mongoose is swooped up by an eagle.

For the ecosystem to function, every single piece of that chain has to exist and interact. Docker works exactly the same way. It is a chain of distinct technologies working together to create what we call the "Docker Platform."

Before we look at the chain in action, let’s meet the main characters:

Docker Client (CLI): The interface where you type your commands.
Docker Engine (dockerd): The background daemon (the brain) that listens for API requests and manages Docker objects.
Docker Desktop: The unsung hero for Mac and Windows users. It quietly creates a Linux Virtual Machine in the background so the Docker Engine has a Linux kernel to work with.
Docker Images: Think of an image as a "screenshot" or a frozen snapshot of a container.
Docker Hub: The massive, cloud-based database where all these images (like Ubuntu, Redis, Postgres, or Node) live.
Docker Compose: (We’ll save this one for a future post, but just know it’s the orchestrator for multi-container setups!)

The Deep Dive: What actually happens when you hit Enter?

Most developers know how to type docker run hello-world. But what happens in the milliseconds after you hit enter? Let’s connect the dots.

Step 1: The Request

You type docker run hello-world into your terminal. The Docker Client catches this command and translates it into a REST API request. It sends this request to the Docker Engine (specifically, the dockerd daemon).

Step 2: Passing the Baton

dockerd is a busy manager. It receives your request and says, "Hey, **containerd* (the high-level container runtime), handle this for me."*

Step 3: The Cache Check

containerd acts like a smart librarian. First, it checks its local cache. It asks: "Do we already have the hello-world image downloaded on this computer?" If this is your first time running it, the answer is no.

Step 4: The Download (Pulling)

Because the image isn't stored locally, containerd reaches out to Docker Hub. It requests the hello-world image, pulls it down, and caches it locally so it won't have to download it again next time.

Step 5: The Build

Now that it has the image, containerd hands it over to runc (the low-level runtime) and says, "Execute this." ### Step 6: The Kernel Magic
Here is where the real magic happens. runc talks directly to the Linux Kernel (which, if you are on Mac/Windows, is provided by Docker Desktop).

It asks the kernel for two very specific things:

Namespaces: To create an isolated "alternate reality" for the container so it can't see what else is running on your machine.
Control Groups (cgroups): To set strict limits on how much RAM, CPU, and Hard Drive space this specific container is allowed to use.

The kernel agrees, builds this isolated little world, and the container is born!

Step 7: The Response

A new process starts inside that container, executes the hello-world script, and sends a success message all the way back up the chain from the daemon, to the CLI, and finally onto your screen.

What happens if you run it a second time?
Try running docker run hello-world again. Notice how much faster it is? It completely skips Docker Hub. containerd finds the image in the local cache, hands it straight to runc, and the container spins up instantly.

The "Just Make it Work" Trap

You might be wondering: Why do I need to know all of this? Here is a hard truth: there are software engineers out there with 5 to 10 years of experience who couldn't explain what you just read. They never dive deep. They treat Docker as a magical black box because their only goal is to "just make it work."

It’s easy to be lazy. It's easy to just copy-paste terminal commands. But taking the easy route puts a hard ceiling on your career.

Think of your brain like a massive library. If you just throw random facts into it without organizing them, you'll never be able to find the information when a server crashes at 2 AM. But if you take the time to connect the dots if you organize your knowledge logically, understanding how dockerd talks to containerd you create a mental index.

When you learn this way, you never forget.

The 3-Second Trap: Why Your HTML to Laravel Blade Conversions Are Loading So Slowly

Tahsin Abrar — Sat, 04 Apr 2026 07:48:18 +0000

You’re working on a shiny new admin dashboard. You found a gorgeous, lightning-fast static HTML template online. You download it, open the index.html file in your browser, and it loads instantly. Perfect.

You copy that HTML into your Laravel project, paste it into a fresh Blade view, fire up your local server, and hit refresh.

...One second.
...Two seconds.
...Three seconds.

Suddenly, the layout snaps into place, and the icons finally pop onto the screen.

What just happened? How did a blazing-fast HTML file turn into a sluggish mess the moment it touched Laravel?

If you’ve ever spent hours debugging this frustrating delay, you are not alone. As a software architect who has spent years building and scaling Laravel applications, I've seen countless developers fall into this exact trap. Today, we’re going to look at why this "delay dilemma" happens and exactly how to fix it.

The Root Cause: The Asset Linking Trap

When converting a static HTML template to a Laravel Blade file, the most common mistake is treating the Blade file exactly like a plain HTML file.

Because Blade fully supports standard HTML syntax, it’s incredibly tempting to just drag and drop your CSS, JS, and image folders into your project and leave the <link> and <script> tags exactly as they were.

It usually looks something like this:

<link rel="stylesheet" href="css/style.css">
<link rel="stylesheet" href="vendors/fontawesome/all.min.css">
<script src="js/main.js"></script>

In a standard HTML environment, the browser looks for those files relative to where the HTML file sits in the folder structure. But in Laravel, your application is routed through the public directory, and your URLs are dynamic.

The Delay Dilemma Explained

When you leave those relative links in your Blade file, the browser gets confused. It tries to load the CSS or the web fonts for your icons asynchronously. But because the file path doesn't align with Laravel's routing structure, the server can't easily find the assets.

Behind the scenes, the browser is hanging. It is desperately searching for prerequisite files especially icon web fonts and core stylesheets. This creates a massive bottleneck. The browser essentially pauses the visual rendering for 2 to 3 seconds while it figures out what to do with the missing or misaligned assets. Finally, it gives up or falls back, and your page abruptly snaps into view.

You might look at your code and think, "My CSS is there, why is it slow?" The truth is, your CSS might be trying to load, but the broken asset links are holding the rest of the page hostage.

The Fix: Do It the Laravel Way

To solve this, we need to stop relying on generic HTML relative paths and start using Laravel's built-in helper functions. Specifically, the asset() helper.

The asset() function generates a full, absolute URL for your application based on your current request scheme (HTTP or HTTPS). It tells the browser exactly where to look inside the public directory, completely eliminating the guesswork and the load delay.

1. Move your assets
First, ensure all your template's css, js, images, and fonts folders are placed directly inside your Laravel project's public directory.

2. Wrap your links
Next, go through your Blade file and update every single static asset link using the {{ asset() }} syntax.

<link rel="stylesheet" href="{{ asset('css/style.css') }}">
<link rel="stylesheet" href="{{ asset('vendors/fontawesome/all.min.css') }}">

3. Don't forget your scripts and images!
This rule applies to everything. If it's a static file, it needs the asset() helper.

<script src="{{ asset('js/main.js') }}"></script>

<img src="{{ asset('images/logo.png') }}" alt="Dashboard Logo">

A Real-Life Game Changer

I remember mentoring a junior developer a few years ago who was completely stuck on this. They were building a massive admin portal and had spent an entire afternoon profiling database queries, thinking their backend code was making the page slow.

I took one look at their app.blade.php layout file and saw dozens of hardcoded <link href="assets/..."> tags. We spent five minutes wrapping them in the asset() helper. When we hit refresh, that painful 3-second delay was completely gone. The icons loaded instantly, and the page felt native and snappy again.

It was a total game-changer for them.

Fixing Git 'Repository Not Found' & Multiple SSH Key Issues

Tahsin Abrar — Sun, 22 Mar 2026 16:16:50 +0000

If you’ve ever worked with multiple GitHub accounts and suddenly hit errors like:

Repository not found
Can’t clone or push to a private repo
Git showing a weird name like "Pagol98" in commits

…you’re not alone. This is one of those problems that looks confusing at first, but once you understand it, it becomes super easy to fix.

In this post, I’ll walk you through the exact issues, why they happen, and a clean, real-world solution you can reuse in any project.

The Real Problem (What’s Going Wrong?)

Let’s break it down into 3 common issues that often get mixed together:

1. Repository Not Found

git clone https://github.com/username/tailadmin-blade-dashboard.git

Error:

remote: Repository not found.
fatal: repository not found

👉 This usually means:

The repo name is wrong (typo)
The repo is private and you don’t have access
You’re using the wrong account

2. Multiple SSH Keys Confusion

You created:

id_ed25519 (personal)
id_work (work)

👉 But Git doesn’t know which key to use for which repo.

So sometimes:

One repo works ✅
Another repo fails ❌

3. 😅 Random Commit Name (like “Pagol98”)

Git uses:

user.name
user.email

If not set correctly → it uses old/default values.

Real-Life Scenario (Why This Happens)

Let’s say:

You have 2 GitHub accounts → Personal + Work
Both have different SSH keys
You clone using HTTPS or default SSH

👉 Git gets confused:

“Which identity should I use?”

And that’s where things break.

Step-by-Step Fix (Clean & Professional Setup)

Step 1: Create SSH Config File

Path:

C:\Users\Asus\.ssh\config

If not exists → create it.

Now add this:

# Personal GitHub
Host github-personal
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_ed25519

# Work GitHub
Host github-work
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_work

👉 This is the magic step.

Step 2: Use SSH Instead of HTTPS

❌ Don’t use:

https://github.com/username/repo.git

✅ Use SSH:

git@github.com:username/repo.git

Now modify it using your config:

👉 Personal repo:

git clone git@github-personal:username/repo.git

👉 Work repo:

git clone git@github-work:username/repo.git

Step 3: Test SSH Connection

ssh -T git@github-personal
ssh -T git@github-work

✅ Expected:

Hi username! You've successfully authenticated

Step 4: Fix Git Commit Name

Check current config:

git config --global user.name
git config --global user.email

Set correct values:

git config --global user.name "Your Name"
git config --global user.email "your-email@gmail.com"

Per-Repository Config (Best Practice)

If you use multiple accounts, don’t rely only on global config.

Inside a specific repo:

git config user.name "Work Name"
git config user.email "work-email@gmail.com"

👉 This avoids mixing identities.

Step 5: Verify Remote URL

git remote -v

Make sure it shows:

git@github-work:username/repo.git

git@github-personal:username/repo.git

This is one of those issues every developer faces at some point—especially when juggling personal and work GitHub accounts.

The key takeaway is simple:

Git doesn’t “understand accounts” — it only understands configuration.

Once you properly configure:

SSH keys
SSH config
Git user info

👉 Everything becomes predictable and smooth.

How to Set Up Passwordless SSH Login with PuTTY.

Tahsin Abrar — Sun, 22 Mar 2026 01:48:29 +0000

If you’ve ever logged into your VPS again and again using a password, you already know how repetitive and risky it can be.

There’s a better way.

In professional server environments, developers almost always use SSH key-based authentication instead of passwords. It’s faster, more secure, and honestly… once you set it up, you won’t want to go back.

In this guide, I’ll walk you through how to set up passwordless SSH login using PuTTY in a simple, practical way.

What Is Passwordless SSH Login?

In simple terms:

Instead of typing a password every time
You use a private key file stored on your computer
The server verifies it using a public key

Think of it like this:

Your server has a lock (public key), and your computer has the only matching key (private key)

No password needed. Just instant access.

Step 1: Generate SSH Key Pair Using PuTTYgen

First, we need to create two keys:

Private Key (.ppk) → stays on your PC
Public Key → goes to your server

Steps:

Open PuTTYgen (comes with PuTTY)
Under Parameters, select:

Ed25519 (modern, faster, more secure than RSA)

Click Generate
Move your mouse randomly (this generates randomness)
Once done:

Click Save private key
Save it somewhere safe (very important ⚠️)

Copy the public key from:

   Public key for pasting into OpenSSH authorized_keys file

Step 2: Add Public Key to Your VPS

Now we tell the server: “This key is allowed to access you.”

Login to your VPS (last time using password)

Then run:

mkdir -p ~/.ssh
chmod 700 ~/.ssh

Open authorized_keys file:

nano ~/.ssh/authorized_keys

Paste your public key

Right-click in PuTTY → it will paste automatically
Then save:

Ctrl + O → Enter → Ctrl + X

Secure the file:

chmod 600 ~/.ssh/authorized_keys

Step 3: Configure PuTTY for One-Click Login

Now comes the fun part no more typing anything 😄

Steps:

Open PuTTY
Go to:

   Connection → Data

Set:

 Auto-login username: your_username (e.g., root / ubuntu)

Go to:

   Connection → SSH → Auth → Credentials

Select your .ppk file

Go back to:

   Session

Enter:
- Host Name (IP)
- Saved Session name (e.g., My Production VPS)

Click Save

Result: One Click Login

From now on:

Open PuTTY
Double-click your saved session

You’re instantly logged in. No password. No hassle.

Real-Life Scenario

Let’s say you’re deploying a Laravel project from GitHub to your VPS.

Before:

Login with password every time
Risk of brute-force attacks
Slower CI/CD setup

After:

Instant login using SSH key
Easy automation (GitHub Actions, scripts)
Much more secure

This is exactly how most production servers are managed in real-world teams.

Setting up SSH key-based login might feel a bit technical at first but it’s one of those upgrades that pays off immediately.

You get:

Better security
Faster access
Easier automation

And honestly… once you start using it, typing passwords will feel outdated.

Why Port 8000 Suddenly Stopped Working on My Local Machine (and How I Fixed It)

Tahsin Abrar — Sat, 10 Jan 2026 09:23:29 +0000

A few days ago, I faced one of those annoying local development issues that waste hours and make you question your sanity.

I started my local server like I always do:

http://127.0.0.1:8000

And suddenly…

Failed to listen on 127.0.0.1:8000
An attempt was made to access a socket in a way forbidden by its access permissions

I tried ports 8001, 8002, 8003… all the way to 8010.
Same error. Every. Single. Time.

If this sounds familiar, this post is for you.

The Confusing Part

The first thing any developer does is check if the port is already in use:

netstat -ano | findstr :8000

👉 Nothing. Empty.

So the port is free… right?

Wrong.

This is where Windows tricks you.

The Real Problem (The Part No One Tells You)

On Windows, some ports are reserved by the OS itself.

This usually happens because of:

Hyper-V
WSL2
Docker Desktop
Windows NAT (WinNAT)
VPN software

Even if no app is using the port, Windows blocks it internally.

That’s why:

netstat shows nothing
Your app still fails to start
You lose time debugging the wrong thing

How I Found the Truth

Run this command as Administrator:

netsh int ipv4 show excludedportrange protocol=tcp

On my machine, I saw this:

Start Port    End Port
7943          8042

Boom.

Port 8000 is inside that range.

That means:

Windows owns the port
Your app is not allowed to bind to it
No process will show up in netstat

Why This Error Is So Frustrating

The error message is unclear
Nothing shows in port checks
Reinstalling frameworks won’t help
Killing processes won’t help

I wasted time restarting apps when the problem was the OS itself.

The Fixes (Pick What Fits You)

Option 1: Use a Different Port (Fastest & Safest)

If you just want to move on:

Example (Django):

python manage.py runserver 127.0.0.1:8080

This works without admin access.

Option 2: Disable Hyper-V (Best for Dev Machines)

If you don’t need Hyper-V:

dism.exe /Online /Disable-Feature:Microsoft-Hyper-V

Restart your PC

This permanently frees ports like 8000.

Option 3: Shutdown WSL (Temporary)

wsl --shutdown

Good if you only need a quick fix.

Option 4: Restart WinNAT

net stop winnat
net start winnat

⚠️ Requires Administrator access
⚠️ May be temporary

What NOT to Do

❌ Don’t reinstall Python / Node / Django
❌ Don’t keep killing random processes
❌ Don’t fight the firewall first
❌ Don’t assume netstat tells the full story

This is not your app’s fault.

If this post saved you time, feel free to share it with another developer who’s stuck staring at port 8000 right now 😄
Happy coding! 🚀

A Small PHP Tip That Saves Time (and Lines of Code)

Tahsin Abrar — Fri, 02 Jan 2026 20:09:59 +0000

I was recently reviewing a PHP project. The code worked fine. Tests were passing. No bugs.

But something caught my eye.

The same pattern was repeated again and again in almost every class constructor. It’s not wrong, but since PHP 8.0, we don’t need to write it this way anymore.

This post is a quick, practical PHP tip about classes and constructors that can make your code cleaner, shorter, and easier to read.

The Old Habit We Still Write

This is something I still see in many real projects:

class UserService
{
    private string $name;
    private int $age;

    public function __construct(string $name, int $age)
    {
        $this->name = $name;
        $this->age = $age;
    }
}

Nothing is technically wrong here.

But when a project has:

50+ classes
Each class has 5–10 properties

You end up writing the same lines again and again.

It’s boring, repetitive, and easy to mess up when refactoring.

PHP 8.0 Changed This Forever

Since PHP 8.0, we have a feature called:

Constructor Property Promotion

It lets you declare and assign class properties directly inside the constructor.

Let’s rewrite the same class.

The Modern Way (Cleaner & Shorter)

class UserService
{
    public function __construct(
        private string $name,
        private int $age
    ) {
    }
}

That’s it.

What Just Happened?

No separate property declaration
No $this->name = $name;
Same behavior
Less code
Easier to read

Your brain now focuses on what the class needs, not boilerplate code.

Public, Protected, or Private? Your Choice

You’re not limited to private. You can use any visibility.

class Post
{
    public function __construct(
        public string $title,
        public string $content,
        private int $authorId
    ) {
    }
}

This works exactly as expected.

A Real-Life Refactor Story

While reviewing a Laravel project, I found a service class with 12 properties.

The constructor alone was almost 30 lines long.

I did this:

Selected the constructor
Used VS Code Quick Edit / Multi-cursor
Converted all properties to constructor promotion

The result:

Constructor went from 30 lines to 6 lines
No logic changed
Code became easier to scan during reviews

This refactor took less than 2 minutes.

When You Should Use This

Constructor property promotion is perfect when:

Properties are only set in the constructor
You don’t need extra logic during assignment
You want clean, modern PHP code

When You Should NOT Use It

Avoid it if:

You need validation before assignment
You modify values before storing them
You want to keep constructor logic very explicit

Example where the old way is still better:

public function __construct(string $email)
{
    $this->email = strtolower($email);
}

Stop Hacking Your .htaccess: A Better Way to Switch Laravel Versions

Tahsin Abrar — Fri, 02 Jan 2026 15:04:02 +0000

We’ve all been there. It’s 10:00 PM, you just finished a major update for your Laravel site, and it’s time to go live.

In the past, I used to do what many of us try first: The .htaccess Trick. I would upload the new version to a subfolder and try to "point" the website to it using some clever Apache rules.

It felt smart at the time. But then came the bugs. Broken CSS paths, session errors, and the scariest part accidentally making my .env file public.

Today, I want to show you a much better, "pro" way to do this. It’s called a Symbolic Link (Symlink). It sounds technical, but it’s actually as simple as creating a shortcut on your desktop.

The "Bakery" Analogy

Imagine you run a bakery. You have a display case (your website) where you show your cakes.

The .htaccess way: You try to move the entire display case every time you bake a new cake. It’s heavy, slow, and you might drop something.
The Symlink way: You keep the display case where it is. You just swap the tray inside. The customers always look at the same spot, but the cake is fresh.

Why the .htaccess method is risky

Before we dive into the "how," here is why you should avoid switching versions via .htaccess:

Security: You risk exposing your sensitive files (like .env) if the redirect isn't perfect.
Path Issues: Laravel functions like public_path() can get confused when the project is buried in subfolders.
Downtime: If you make a typo in the .htaccess file, your whole site goes down with a "500 Internal Server Error."

The Better Way: The "Current" Folder Strategy

Instead of moving files around, we are going to create a structure like this on your server:

/my-project/
├── releases/
│   ├── v1_old/   (Your old code)
│   └── v2_new/   (Your new code)
└── current/      (The "Magic" Shortcut)

Your web server (Apache or Nginx) will always look at the current/public folder. To switch versions, we just tell the current shortcut to point to a different folder.

Step-by-Step Guide

1. Prepare your folders

Upload your new version into a folder inside releases/. Let's call it v2_new.

2. The Magic Command

Open your terminal (SSH). Instead of copying files, run this command:

ln -sfn /home/username/releases/v2_new/public /home/username/public_html

What does this do? It tells the server: "Hey, whenever someone visits public_html, actually show them the files inside v2_new/public." It happens instantly. No loading bars, no waiting.

3. The "Oops" Button (Rollback)

This is my favorite part. If you realize v2_new has a massive bug, you don't need to panic. You can switch back to the old version in one second:

ln -sfn /home/username/releases/v1_old/public /home/username/public_html

The Empty Box Problem in Laravel Migrations (And why I stopped using default strings)

Tahsin Abrar — Thu, 18 Dec 2025 19:38:09 +0000

🛑 Stop me if you’ve faced this decision before.

You are writing a Laravel migration.
You need to add an optional column, like unit_type.
Not every product needs a unit.

So, you have two choices:

$table->string('unit_type')->default('');
$table->string('unit_type')->nullable();

I almost always chose Option 1.

Why? Fear.

I was afraid of the dreaded Trying to access property on null error in my frontend.
I just wanted to output the value without writing if statements everywhere.
Using default('') felt "safe."

But after 10 years of database design, I realized I was doing it wrong.

Here is a simple way to look at it:

Imagine a warehouse shelf. 📦

Using `nullable()` is like having no box on the shelf.
It means: "This item does not apply here." (e.g., A digital download has no weight).

Using `default('')` is like putting an empty box on the shelf.
It means: "There is a box here, but we forgot to put something inside."

When you use empty strings, you are technically "lying" to your database. You are saying there is a value (text of length 0), even when there isn’t.

Why does this matter?

❌ Queries get messy: searching for WHERE column IS NULL is standard. Searching for WHERE column = '' feels amateur.
❌ Foreign Keys: You can’t make an empty string a foreign key later.
❌ Analytics: Reports get confused between "missing data" and "empty text."

The Best Practice Solution?

Keep the database clean, and handle the "safety" in your Model.

In your migration, use nullable(). Let the database be accurate.
In your Laravel Model, use an Accessor:

public function getUnitTypeAttribute($value)
{
    return $value ?? '';
}

This gives you the best of both worlds.
Your database stores clean NULL values.
Your frontend gets a safe empty string.

👇 What’s your preference? Do you strictly enforce NULLs, or do you sneak in defaults to save time? Let’s argue in the comments.