Forem: Tahsin Abrar

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.

MySQL Connection Error 1130: Host '192.168.7.7' Is Not Allowed to Connect

Tahsin Abrar — Tue, 21 Oct 2025 20:30:44 +0000

As a developer, you’ve probably encountered various MySQL errors while working with databases. One common issue that can be quite frustrating is the ERROR 1130 (HY000): Host '192.168.7.7' is not allowed to connect to this MySQL server. This error typically occurs when trying to connect to a MySQL server from a remote machine using tools like TablePlus or MySQL Workbench.

In this post, I’ll walk you through the steps to troubleshoot and resolve this connection error, so you can get back to developing without any interruptions. Let’s dive in!

Understanding the ERROR 1130

The error ERROR 1130 (HY000): Host '192.168.7.7' is not allowed to connect to this MySQL server occurs when your MySQL server rejects connections from a remote host (in this case, 192.168.7.7). This happens because the MySQL server's settings don't allow connections from that specific host or IP address.

This issue usually stems from a combination of MySQL’s host-based access control and network settings. But don’t worry! Fixing it involves a few simple steps.

Step 1: Check the MySQL User Privileges

The first thing we need to do is ensure that the MySQL user you're trying to connect with has the correct privileges for remote connections.

1.1 Log into MySQL Server

On the machine where MySQL is running, log in as a root user or any other user with the necessary privileges:

mysql -u root -p

Enter your password when prompted.

1.2 Check Existing Privileges

Once logged in, check the privileges for the user trying to connect remotely:

SELECT user, host FROM mysql.user;

This will show a list of all MySQL users and their associated hosts. If the user you're trying to use is restricted to localhost, it will not be able to connect from a remote IP address.

1.3 Grant Remote Access

If the user does not have permissions for remote access, you can grant the required privileges. For example, to allow the user username to connect from any host, you would run:

GRANT ALL PRIVILEGES ON database_name.* TO 'username'@'%' IDENTIFIED BY 'your_password';

This will allow connections from any host (% is a wildcard for any IP address).

If you want to restrict it to a specific IP (e.g., 192.168.7.7), replace % with that IP:

GRANT ALL PRIVILEGES ON database_name.* TO 'username'@'192.168.7.7' IDENTIFIED BY 'your_password';

1.4 Flush Privileges

After granting the privileges, don’t forget to reload the privileges to ensure they take effect:

FLUSH PRIVILEGES;

Step 2: Configure MySQL to Listen on All IP Addresses

By default, MySQL may be configured to listen only on localhost (127.0.0.1), which means it won't accept connections from remote machines.

2.1 Edit the MySQL Configuration File

On the MySQL server, open the configuration file (my.cnf or my.ini, depending on your operating system). The location of the file varies, but it’s typically found at /etc/mysql/my.cnf or /etc/my.cnf.

Use your preferred text editor (like nano or vim):

sudo nano /etc/mysql/my.cnf

2.2 Modify the `bind-address`

Look for the bind-address directive. If it is set to 127.0.0.1, change it to 0.0.0.0 to allow MySQL to listen on all available IP addresses:

bind-address = 0.0.0.0

Save and close the file.

2.3 Restart MySQL

For the changes to take effect, restart MySQL:

sudo systemctl restart mysql

Step 3: Check Firewall and Security Group Settings

Even after granting the necessary privileges and configuring MySQL to listen on all IPs, your server’s firewall might still block the connection.

3.1 Open the MySQL Port (3306)

MySQL uses port 3306 for client connections. Ensure that this port is open on the server’s firewall. On Ubuntu, for example, you can allow traffic on port 3306 with the following command:

sudo ufw allow 3306

If you're using a cloud provider like AWS, make sure the Security Group attached to your MySQL instance allows inbound traffic on port 3306 from the remote host's IP address.

3.2 Verify the Connection

Finally, test the connection from the client machine (in this case, TablePlus). Try connecting again, and you should no longer see the ERROR 1130 (HY000) message.

Step 4: Double-Check TablePlus Settings

Sometimes, the issue may not be on the MySQL server side, but rather with how TablePlus is configured.

4.1 Verify Host and Port

Make sure you’re connecting to the correct IP address and port. Double-check the following in TablePlus:

Host: Should be the IP address of your MySQL server (e.g., 192.168.7.7 or the external IP if connecting remotely).
Port: The default MySQL port is 3306.
User: The MySQL username.
Password: The correct password for the MySQL user.

4.2 Test Connection

Click on the Test button in TablePlus to verify the connection. If everything is set up correctly, you should be able to connect without issues.

Fixing CSS not updating in production (Laravel + Blade)

Tahsin Abrar — Mon, 06 Oct 2025 20:59:35 +0000

If you change a CSS file but users (often on mobile) still see the old styles, it’s almost always a caching problem. This post shows simple, practical fixes for Laravel/Blade projects from quick hacks to proper production setups with real examples you can copy.

The problem short story

Last month I deployed a tiny CSS change: a button color and spacing. On my desktop it looked fine. But several users (mostly on mobile) complained the site still showed the old look. I ran php artisan optimize:clear, redeployed, even asked one user to refresh nothing. The cause? Browser (or CDN) still serving the old static file from cache.

Browsers, CDNs, and sometimes reverse proxies hold static files (CSS/JS) for speed. If the filename or URL does not change, they assume it’s the same file and keep using the cached copy.

Why `php artisan optimize:clear` didn’t fix it

php artisan optimize:clear clears Laravel’s server-side caches (views, routes, configs). It does not change the static asset file name or force browsers/CDNs to fetch a new style.css. So browser cache still wins.

Practical fixes (from quick to best practice)

1) Best: Use versioned assets (Vite or Mix)

If you use Vite (Laravel 9+ default) or Laravel Mix, they produce versioned/hashed builds so each build has new filenames.

Vite (Blade):

@vite(['resources/css/app.css', 'resources/js/app.js'])

Build for production:

npm run build

Laravel Mix (webpack.mix.js):

mix
  .js('resources/js/app.js', 'public/js')
  .sass('resources/sass/app.scss', 'public/css')
  .version(); // <-- generate hashed filenames

Then in Blade:

<link rel="stylesheet" href="{{ mix('css/app.css') }}">

Build for production:

npm run prod

Why this works: the filenames include a hash (e.g. app.abc123.css) so when content changes, filename changes, forcing browsers & CDNs to fetch the new file.

2) Good quick fix: Use file modification time (`filemtime`) better than `time()`

If you don't use Mix/Vite yet, avoid ?v={{ time() }}. time() changes every request and breaks caching (bad for performance). Use the file’s last-modified timestamp so version only changes when file changes:

<link rel="stylesheet" href="{{ asset('css/style.css') }}?v={{ filemtime(public_path('css/style.css')) }}">

This way the query string changes only when the file actually changes.

3) Quick (but temporary) hack: `?v={{ time() }}`

This forces a fresh download every time. It fixes the "old CSS" problem immediately but kills browser caching and hurts load time. Use only for debugging or one-time hotfix.

<link rel="stylesheet" href="{{ asset('css/style.css') }}?v={{ time() }}">

4) CDN / Cloudflare purge cache or configure properly

If you use Cloudflare or any CDN, it may serve cached CSS even after you update files.

For a quick fix: Purge Cache → Purge Everything (Cloudflare) or purge specific URLs.
Better: configure your CDN to respect file-hash/versioning. If you use hashed filenames, leave CDN cache long (1 year) safe because filename changes with content.

5) Set proper headers (server-side)

For static assets, set far-future Cache-Control and use hashed filenames. Example nginx snippet:

location ~* \.(css|js|jpg|jpeg|png|gif|ico|svg)$ {
    expires 365d;
    add_header Cache-Control "public, max-age=31536000, immutable";
}

immutable means the browser can trust the cached file until the URL changes.

6) Laravel cache commands (still useful)

These clear Laravel caches (won’t force browser to fetch new CSS but good for general deploy):

php artisan view:clear
php artisan route:clear
php artisan config:clear
php artisan cache:clear
php artisan optimize:clear

How I fixed my real issue (short walkthrough)

I had linked public/css/style.css directly.
I built assets with Mix and enabled mix.version() in webpack.mix.js.
Replaced <link href="{{ asset('css/style.css') }}"> with <link href="{{ mix('css/style.css') }}"> in Blade.
Ran npm run prod, deployed new public/mix-manifest.json and hashed files.
Purged Cloudflare cache for the CSS URL.
Tested on mobile (incognito) new styles were visible immediately.

That flow solved the problem forever no more users complaining.

How an Email Travels Across the Network

Tahsin Abrar — Sat, 13 Sep 2025 13:38:50 +0000

You (the sender) want to email Sakib (the receiver). Think of your email as a parcel. The internet is the postal system. We’ll walk through the 5-layer TCP/IP model and watch this parcel travel.

Layers:

Application
Transport
Network
Data Link
Physical

1) Application Layer “Write & Prepare the Parcel”

What happens:

You type the email and attach files.
The email client (MUA) prepares an SMTP message.
Attachments are wrapped using MIME (and often compressed or base64-encoded).
TLS (encryption) is planned so nobody can read the email on the wire.

Standard practices

Keep attachments small; many providers limit to ~20–25 MB. Prefer cloud links for big files.
Use UTF-8 for text.
Turn on TLS (STARTTLS or implicit TLS) so the path is encrypted.

Quick mental hook: “Write it, wrap it, lock it (TLS).”

2) Transport Layer “Cut Into Chunks & Number Them”

What happens:

The SMTP message may be bigger than what the network can send at once.
TCP splits it into segments (chunks), numbers each, and ensures delivery with ACKs.
A 3-way handshake (SYN, SYN-ACK, ACK) sets up the session.
Client uses an ephemeral port; server listens on a well-known port.

Ports (common)

Submission: 587 (SMTP with STARTTLS)
SMTP server to server: 25
IMAP over TLS: 993, POP3 over TLS: 995

Standard practices

Submit mail on 587 with authentication and STARTTLS.
Don’t disable Nagle/algorithms etc. without reason; defaults are usually fine.
If sending very large data often, consider links instead of huge attachments.

Quick mental hook: “Cut, number, handshake.”

3) Network Layer “Put IP Addresses On Every Chunk”

What happens:

Each TCP segment is wrapped in an IP packet with source IP and destination IP.
Routers use the destination IP to forward packets hop by hop to Sakib’s mail server.
TTL (time to live) prevents endless looping.

Standard practices

Make sure DNS and MX records for your domain are correct (delivery depends on it).
Your client is often behind NAT; your router translates private IP → public IP.

Quick mental hook: “Address every page with IP.”

4) Data Link Layer “Wrap For The Local Hop (MAC & Frame)”

What happens:

On each local link (your Wi-Fi/Ethernet, your ISP’s next hop), IP packets are wrapped into frames with MAC addresses.
ARP resolves “which MAC is next?” for local delivery.
Each hop unwraps/re-wraps frames as the packet moves through.

Standard practices

On unstable Wi-Fi, expect retries. For important sends, prefer a stable link (Ethernet).
Keep drivers/firmware updated for fewer link-level drops.

Quick mental hook: “Local delivery uses MAC.”

5) Physical Layer “Turn Frames Into Signals”

What happens:

Frames become electrical/optical/radio signals (Ethernet, fiber, Wi-Fi).
Bits travel over cables/air between devices.

Standard practices

Use good cables/APs. Poor cables and congested Wi-Fi = packet loss → TCP retransmissions → slow email sends.
For offices, wire critical machines.

Quick mental hook: “Bits ride wires or waves.”

On Sakib’s Side “Unwrap & Reassemble”

Reverse happens:

Physical → Data Link → Network → Transport → Application.
TCP reorders segments, fills gaps, and hands the complete message to SMTP on the server.
The Mail Delivery Agent stores it in Sakib’s mailbox.
Sakib opens her client (IMAP/POP3) and reads it.