Forem: Harsh

Getting Started with cURL

Harsh — Fri, 30 Jan 2026 19:29:53 +0000

If you’re learning programming, web development, or APIs, you’ll hear the word cURL a lot. At first, it might feel intimidating strange commands, terminal windows, and servers you can’t see.

Don’t worry. This guide will walk you through cURL step by step, using plain language and simple examples.

By the end, you’ll understand what cURL is, why programmers use it, and how to make your first request with confidence.

First Things First: What Is a Server?

Before we talk about cURL, let’s understand servers.

A server is just a computer that:

Stores data
Runs applications
Responds when someone asks it for information

Whenever you:

Open a website
Log into an app
Fetch data from an API

You are talking to a server.

Your browser sends a message like:

“Hey server, can you send me this webpage?”

The server replies with:

“Sure, here you go.”

That back-and-forth conversation is the foundation of the internet.

So Where Does cURL Fit In?

Normally, your browser talks to servers for you.

But what if you want to:

Test an API
Fetch data without a browser
Send requests directly from your terminal

That’s where cURL comes in.

In very simple terms:

cURL is a tool that lets you send messages to a server from the terminal.

Think of it like this:

Browser → sends requests automatically
cURL → lets you send those requests manually

Why Programmers Need cURL

Programmers use cURL because it helps them:

Test APIs quickly
Debug backend services
See raw server responses
Work without a browser
Automate requests

If you’re doing backend development, cURL becomes a daily companion.

Making Your First cURL Request

Let’s start with the simplest possible command.

Open your terminal and type:

curl https://example.com

You just:

Sent a request to a server
Asked for a webpage
Received a response

What Just Happened Behind the Scenes?

When you ran that command, cURL did three things:

Sent a request to the server
The server processed it
The server sent back a response

This is how almost all web communication works.

No flags. No complexity. Just confidence.

Understanding Request and Response

The Request

A request is simply:

What you want
Where you want it from

In our example:

You wanted a webpage
From example.com

This is called a GET request.

The Response

The response usually contains:

Status (Did it work?)
Data (The content returned)

For example:

200 OK → Success
404 Not Found → Page doesn’t exist
500 Server Error → Server had a problem

The text you see printed in the terminal is the data returned by the server.

GET and POST

Let’s keep things simple.

GET

Used to get data
You’ve already used it
Default method in cURL

Example:

curl https://api.example.com/users

POST

Used to send data to a server
Common when submitting forms or creating data

Simple example:

curl -X POST https://api.example.com/users

Don’t worry about the details yet, just remember:

GET = ask for data
POST = send data

That’s enough for now

Using cURL to Talk to APIs

APIs are just servers that speak in data instead of webpages.

When you use cURL with an API, you might:

Fetch user information
Create new records
Test endpoints before writing code

Example:

curl https://api.example.com/products

The server might respond with JSON instead of HTML and that’s totally normal.

Common Mistakes Beginners Make with cURL

You’re not alone if you hit these early on:

1. Overusing Flags Too Early

cURL has many options, but beginners don’t need most of them.
Start simple. Add complexity later.

2. Forgetting the URL

Yes, it happens
cURL always needs a destination.

3. Confusing GET and POST

GET → retrieve
POST → send

4. Panicking Over Ugly Output

Raw responses aren’t always pretty.
That doesn’t mean something is broken.

5. Expecting a Browser-Like Experience

cURL shows data, not design.
No colors, no layout just the truth.

Final Thoughts

cURL isn’t scary, it’s honest.

It shows you:

Exactly what you send
Exactly what the server returns

Start small. Stay curious.

DNS Record Types Explained

Harsh — Fri, 30 Jan 2026 18:33:44 +0000

How does a browser know where a website lives?

When you type:

www.google.com

into your browser, your computer somehow finds the exact machine in the world that runs Google’s website.

But computers don’t understand names like google.com.

They only understand IP addresses, such as:

142.250.195.78

So the real question becomes:

How does a human-friendly name turn into a machine-friendly address?

That’s where DNS comes in.

What is DNS?

DNS stands for Domain Name System.
DNS is basically the phonebook of the internet.

Similar as

You search a person’s name → get their phone number
The browser searches a domain name → gets an IP address

Without DNS, you would have to remember numbers instead of names:

142.250.195.78 instead of google.com

DNS makes the internet usable for humans.

Why are DNS records needed?

A domain name doesn’t store information by itself.
DNS records are the instructions attached to a domain.
They answer questions like:

Who controls this domain?
Where is the website hosed?
Where should emails go?
Is this domain verified for some service?

Each DNS record solves one specific problem.
Instead of one giant setting, DNS uses different record types, each with a clear job.

What is an NS Record?

NS = Name Server

NS records tell the internet:

“These servers are responsible for this domain.”

Think of NS records like the main office of a society that knows where every house is.

Example:

example.com → ns1.cloudflare.com
               ns2.cloudflare.com

This means Cloudflare’s servers manage all DNS information for example.com.

Without NS records, no one would know where to even ask about your domain.

What is an A Record?

A = Address

An A record connects a domain name to an IPv4 address.

Example:

example.com → 93.184.216.34

This tells the browser:

“The website lives on this machine.”

Think of it like a house address.

Domain name = person
IP address = house location

What is an AAAA Record?

AAAA records do the same job as A records but for IPv6 addresses (the newer, longer IP format).

Example:

example.com → 2606:2800:220:1:248:1893:25c8:1946

Why both exist?

Because the internet is slowly moving from IPv4 → IPv6.

Many websites use both A and AAAA records so all networks can reach them.

What is a CNAME Record?

CNAME = Canonical Name

A CNAME record points one domain name to another domain name.

Example:

www.example.com → example.com

So instead of storing an IP address, it says:

“Go ask that domain instead.”

This is very useful when:

multiple names should lead to the same site
the main domain’s IP changes

Think of CNAME like a contact saved under another contact.

What is an MX Record?

MX = Mail Exchange

MX records tell the internet:

“Emails for this domain should go here.”

Example:

example.com → mail.google.com

When someone sends:

hello@example.com

MX records guide that email to the correct mail server.

Important:

Websites use A / CNAME
Emails use MX

They solve totally different problems.

What is a TXT Record?

TXT records store text-based information.
They are commonly used for:

Domain ownership verification
Email security (SPF, DKIM, DMARC)
Connecting domains to services (GitHub, Google, Cloudflare, etc.)

Example:

"google-site-verification=abc123"

Think of TXT records as note papers attached to your domain.
They don’t move traffic, they prove trust and provide info.

How all DNS records work together for one website

Let’s say you run a small website: myblog.com

Behind the scenes, DNS might look like:

NS → who manages the domain
A / AAAA → where the website lives
CNAME → connect subdomains
MX → where emails go
TXT → verification & security

All records work together like departments in a company.

Final Thoughts

A Record vs CNAME

A Record → points to an IP
CNAME → points to another name

A = final house
CNAME = redirect board

NS vs MX

NS → who controls the domain
MX → who handles emails

NS is about DNS authority
MX is about email delivery

DNS is not one thing.
It’s a collection of small instruction cards attached to your domain.

Each card answers one clear question:

Where is the site?
Who manages this domain?
Where should emails go?
Is this domain verified?

Once you understand that DNS stops feeling scary and starts feeling logical.

How DNS Resolution Works

Harsh — Thu, 29 Jan 2026 03:39:47 +0000

When you type google.com into your browser and press Enter, you’re not actually connecting to “google.com”.

You’re connecting to an IP address like 142.250.77.46.

So the real question is:

How does the internet convert human-friendly names into machine-friendly IPs?

That system is called DNS (Domain Name System) often described as the internet’s phonebook.

This article walks step-by-step through:

What DNS is and why it exists
How the dig command helps us inspect DNS
Root, TLD, and authoritative name servers
The full DNS resolution flow for google.com
How all of this connects to real browser requests

And we’ll build everything logically using real dig commands.

What is DNS and why name resolution exists

Computers don’t understand domain names.

They communicate using IP addresses.

But humans don’t want to remember this: 142.250.77.46

So DNS exists to answer one simple question:

“What is the IP address of this domain name?”

Example: google.com → 142.250.77.46

DNS provides:

Human-readable names
Decentralized global database
Scalable and fault-tolerant name resolution

Without DNS, the modern web wouldn’t be usable.

What is the `dig` command and when it is used

dig (Domain Information Groper) is a DNS diagnostic tool.

It allows you to:

Query DNS servers directly
Inspect DNS records (A, NS, MX, TXT, etc.)
Debug DNS issues
Understand how name resolution actually works

Example:

dig google.com

This doesn’t just give you an IP, it shows the entire DNS answer structure.

DNS works in layers

DNS is hierarchical

Each layer doesn’t know the final answer.

It only knows who to ask next.

Understanding dig . NS → Root name servers

Let’s start at the very top.

dig . NS

This asks:

“Who are the name servers for the root of DNS?”

You’ll see servers like:

a.root-servers.net  
b.root-servers.net  
c.root-servers.net  
...

These are root name servers.

They do NOT know the IP of google.com.

They only know:

“Who manages .com?”

“Who manages .org?”

Their job is to point you to TLD name servers.

Understanding `dig com NS` → TLD name servers

Now let’s move one level down.

dig com NS

This asks:

“Who manages the .com domain?”

The response returns name servers operated by companies like Verisign.

These TLD servers don’t know Google’s IP either.

They only know:

“Who is authoritative for google.com?”

So they return the authoritative name servers for google.com.

Understanding `dig google.com NS` → Authoritative name servers

dig google.com NS

This returns servers like:

ns1.google.com  
ns2.google.com  
ns3.google.com  
ns4.google.com

These are authoritative name servers.

This is where truth lives.

They store the real DNS records:

A (IP address)
MX (mail servers)
TXT (verification, SPF, etc.)

If you want the actual IP of google.com, this is where it comes from.

Understanding `dig google.com` → Full DNS resolution

dig google.com

You’ll see something like:

google.com.   300   IN   A   142.250.77.46

Behind the scenes (if uncached), the resolver performed:

Ask root → who handles .com?
Ask TLD → who handles google.com?
Ask authoritative → what is the IP?

Your system’s recursive resolver did all this work for you.

What NS records really represent

NS records don’t map names to IPs.

They map names to name servers responsible for that zone.

Example:

google.com → ns1.google.com

They define ownership and delegation.

This is how DNS stays:

Decentralized
Scalable
Company-controlled

Google controls its DNS.
You control yours.

The root doesn’t control Google.

What your recursive resolver actually does

Your computer usually talks to:

ISP DNS
Router DNS
Public DNS (8.8.8.8, 1.1.1.1)

These are recursive resolvers.

They You ask one question:

Query root servers
Query TLD servers
Query authoritative servers
Cache results
Protect you from complexity

They perform the entire DNS walk.

How this connects to real browser requests

When you visit:

https://www.google.com

Your browser:

Asks OS for IP
OS asks recursive resolver
Resolver walks DNS
Gets IP
Browser opens TCP connection
TLS handshake starts
HTTP request is sent

No DNS = No website.
Every API call, cloud service, CDN, and microservice starts with DNS.

Mapping dig to DNS lookup stages

| Command           | What it represents    |
| ----------------- | --------------------- |
| dig . NS          | Root name servers     |
| dig com NS        | TLD name servers      |
| dig google.com NS | Authoritative servers |
| dig google.com    | Final resolution      |

Each command reveals one layer of the system.

Understanding Network Devices

Harsh — Mon, 26 Jan 2026 08:59:03 +0000

From cables and signals to scalable backend systems a beginner friendly, hardware focused guide for developers.

How does the Internet actually reach your laptop?

When you open a website, data travels across multiple networking devices before it reaches your system.
Your request doesn’t go straight to Google, GitHub, or your backend server.

It flows through devices like:

Modem
Router
Switch
Firewall
Load balancer

Each one has one clear responsibility, and together they build the foundation of the internet.

But before deep diving into these networking device we need to understand what is a network, what is the term networking actual mean, how it get started and what are it impacts.

What is a Network and How Does It Work?

A network is simply, Two or more devices connected to share some data.

Examples:

Home Wi-Fi
Office LAN
Data center network
The Internet (largest network in the world)

Basic working principle

Data is broken into small packets
Each packet has:
- Source address
- Destination address
Networking devices forward these packets
The destination device reassembles them

A quick history

1960s – ARPANET (military & universities)
1980s – TCP/IP standard
1990s – World Wide Web
2000s–now – Cloud, mobile internet, global data centers

Today’s internet is a massive collection of interconnected private networks.

Let me give you an analogy: think of this like a delivery system.

Internet = global highway
Modem = translator
Router = traffic police
Switch = local post office
Devices = houses

Now let’s break each one down.

What is a Modem?

A modem connects your private network to your Internet Service Provider (ISP).

Modem = MODulator + DEModulator

What it actually does

Converts ISP signals (fiber/coax/DSL) into digital data
Converts your data back into ISP-compatible signals

Without a modem, your network is cut off from the internet.

Analogy

The modem is a language translator between your home and your ISP.

What is a Router?

A router directs traffic between networks.
It decides:

Where should this packet go next?

Responsibilities

Routes data between devices and the internet
Assigns local IP addresses (DHCP)
Separates private and public networks
Often provides Wi-Fi

Analogy

The router is traffic police at an intersection.

Switch vs Hub: How Local Networks Actually Work

Hub (old technology)

Sends incoming data to every port
No intelligence
Slow and insecure
Everyone hears everything.

Switch (modern networks)

Sends data only to the target device
Learns MAC addresses
Fast and secure
Delivers parcels to the correct house.

Key difference

Hub	Switch
Broadcasts to all	Sends to specific device
No memory	Maintains MAC table
Rarely used today	Used everywhere

What is a Firewall?

A firewall is a security device that monitors and filters traffic.

Responsibilities

Allow or block connections
Protect internal networks
Enforce security rules
Prevent unauthorized access
Firewalls sit at network boundaries.

Analogy

A firewall is a security gate with guards checking IDs.

What is a Load Balancer?

A load balancer distributes traffic across multiple servers.

Why it exists

Prevents server overload
Improves availability
Enables horizontal scaling
Enables zero-downtime deployments

What it does

User Requests
      |
      v
+----------------+
| Load Balancer  |
+----------------+
   /      |      \
  v       v       v
Server 1  Server 2  Server 3

Analogy

A load balancer is a toll booth system sending cars to different lanes.

How These Devices Work Together (Real-World Setup)

Home or small office

Internet
   |
   v
Modem
   |
   v
Router (NAT, WiFi, DHCP)
   |
   v
Switch
   |
   v
Laptop / Phone / TV

What happens when you open a website?

Modem receives ISP signal
Router forwards request
Firewall checks rules
Load balancer selects a server
Switch delivers packet
Server responds
Response flows back the same way

Where These Devices Sit in System Architecture

| Device        | Layer             |
| ------------- | ----------------- |
| Modem         | ISP boundary      |
| Router        | Network routing   |
| Switch        | Local delivery    |
| Firewall      | Security layer    |
| Load balancer | Scalability layer |

These devices create the physical foundation on which all software systems run.

Final Thoughts

Every HTTP request, API call, or database query travels across:

Modems
Routers
Switches
Firewalls
Load balancers

They are the silent workers behind every application.
Once you understand how packets move physically, system design becomes much clearer.

Inside Git: How It Works and the Role of the .git Folder

Harsh — Mon, 05 Jan 2026 18:25:38 +0000

Most beginners learn Git by memorizing commands like git add, git commit, and git push. But sooner or later, questions arise:

Where does Git actually store my code?
What is the mysterious .git folder?
How does Git know what changed?
Why does Git talk so much about hashes?

In this article, we'll open Git's black box and understand how Git works internally in simple terms. No advanced theory. No magic. Just a clear mental model.

How Git Works Internally (Big Picture)

At its core, Git is a content addressable database.

That sounds complicated, but here's the simple idea:

Git doesn't track files it tracks snapshots of content.

Every time you commit:

Git takes a snapshot of your project
Stores it safely
Links it to previous snapshots

All of this data lives inside one folder:

.git/

If you understand this folder, you understand Git.

What Is the `.git` Folder and Why Does It Exist?

When you run:

git init

Git creates a hidden folder called .git.

This folder is the repository.

If you delete .git, your project becomes a normal folder Git history is gone.

What does `.git` contain?

A simplified view:

.git/
├── objects/
├── refs/
├── HEAD
├── index
└── config

Don't panic we'll focus only on what matters.

Why does Git need this folder?

The .git folder stores:

Your entire commit history
All versions of every file
Branch information
Metadata about commits

Your working directory is just a checkout of what's inside .git.

Git Objects: Blob, Tree, Commit (The Building Blocks)

Git stores everything as objects. There are only three core object types you need to understand.

Blob: File Content

A blob stores the contents of a file.

Important:

Blob does not store the filename
Only the raw content

Example:

console.log("Hello Git");

If two files have the same content, Git stores only one blob. This is how Git saves space.

Tree: Folder Structure

A tree represents a directory.

It:

Maps filenames to blobs
Can point to other trees (subfolders)

Think of a tree like:

project/
├── index.js (blob)
└── src/
    └── app.js (blob)

Trees tell Git:

Which files exist
Their names
Their structure

Commit: A Snapshot

A commit is a snapshot of your project.

It contains:

A reference to a tree
A reference to the parent commit
Author info
Commit message
Timestamp

Visually:

Commit
  ↓
 Tree
  ↓
Blobs

Each commit links to the previous one, forming Git's history.

How Git Tracks Changes (Not Diffs!)

Many people think Git stores file differences.

It doesn't.

Git stores snapshots, not diffs.

When you commit:

Git checks each file
If content is unchanged → reuse old blob
If content changed → create new blob

That's why Git is fast and efficient.

What Happens Internally During `git add`

When you run:

git add file.txt

Git does NOT create a commit.

Instead, it:

Reads the file content
Creates a blob object
Stores it in .git/objects
Updates the index (staging area)

Mental model:

git add = "Prepare this snapshot for the next commit"

The index is a temporary holding area between:

Working directory
Repository history

What Happens Internally During `git commit`

When you run:

git commit -m "My commit"

Git:

Takes everything from the index
Builds a tree
Creates a commit object
Updates HEAD to point to the new commit

That's it.

Your history is now permanently recorded (unless you rewrite it).

How Git Uses Hashes to Ensure Integrity

Every Git object is identified by a SHA-1 hash (40 characters).

Example:

e83c5163316f89bfbde7d9ab23ca2e25604af290

Why hashes matter

Hashes ensure:

Integrity → content cannot be silently changed
Uniqueness → same content = same hash
Security → tampering breaks history

If even one character changes, the hash changes completely.

This is why Git history is trustworthy.

When you finally understand Git internals and realize commits are just pointers to trees

Building the Right Mental Model of Git

Instead of memorizing commands, remember this:

Git is a database of snapshots stored inside .git.

.git = brain of Git
Blob = file content
Tree = folder structure
Commit = snapshot + history
Hash = identity + integrity

Commands like add, commit, and checkout are just ways to move between snapshots.

Final Thoughts

Understanding Git internally:

Makes debugging easier
Removes fear of "breaking Git"
Helps you learn advanced topics faster

You don't need to remember everything just remember how the pieces fit together.

If you found this helpful, try exploring:

ls -la .git/objects/

You'll be surprised how much Git suddenly makes sense.

Git for Beginners: Basics and Essential Commands 🚀

Harsh — Thu, 01 Jan 2026 18:44:08 +0000

If you are starting your journey as a developer, you will hear the word Git everywhere.

Job descriptions mention it, open-source projects require it, and almost every team uses it daily.

But what exactly is Git? And why is it so important?

This article explains Git from scratch, in simple words, with beginner-friendly examples and commonly used commands.

📌 What is Git?

Git is a distributed version control system.

That sounds complex, so let's simplify it.

👉 Git helps you track changes in your code over time.

It remembers:

What changed
When it changed
Who changed it
And lets you go back to older versions if something breaks

Think of Git like a time machine for your code.

Instead of saving files like:

project_v1
project_v2
project_final
project_final_real

Git keeps everything organized and clean.

We've all been there! Git saves us from this chaos.

🤔 Why Git is Used?

Git is used because it solves many real problems developers face.

1️⃣ Track Code History

You can see what changed and why it changed.

2️⃣ Work Without Fear

Made a mistake? You can go back to a previous version easily.

3️⃣ Collaboration

Multiple developers can work on the same project without overwriting each other's code.

4️⃣ Industry Standard

Almost every company and open-source project uses Git with platforms like:

GitHub
GitLab
Bitbucket

👉 Learning Git is non-negotiable for developers.

🧠 Git Basics and Core Terminologies

Before commands, let's understand the basic concepts.

📁 Repository (Repo)

A repository is a folder that Git tracks.

It contains:

Your project files
Git's history and metadata

You create it using:

git init

📦 Commit

A commit is a snapshot of your code at a specific point in time.

Think of a commit as: "Save point with a message"

Each commit has:

A unique ID (hash)
Author
Date
Message explaining the change

🌿 Branch

A branch lets you work on features independently.

main (or master) → default branch
Feature branches → new ideas or fixes

Branches help you experiment without breaking main code.

📍 HEAD

HEAD points to your current position in Git history.

Simply put: HEAD = "Where you are right now"

Usually, HEAD points to the latest commit of the current branch.

📊 Understanding Git Workflow

Here's how Git organizes your work:

Three main areas:

Working Directory - Where you make changes
Staging Area - Where you prepare changes for commit
Repository - Where Git permanently stores commits

🗂️ Git Repository Structure

Your local repository consists of:

Working Directory: Your actual project files
.git folder: All Git metadata and history
Remote Repository: GitHub/GitLab (optional)

🛠 Common Git Commands (With Examples)

Let's learn Git commands by actually using them.

🔹 git init

Initializes Git in your project folder.

git init

📌 Creates a hidden .git folder that Git uses to track everything.

🔹 git status

Shows the current state of your repository.

git status

It tells you:

Which files are new
Which files are modified
What is staged for commit

👉 This is the most used Git command.

🔹 git add

Adds files to the staging area.

git add filename.txt

Add everything:

git add .

📌 Staging means "I want to include this in the next commit".

🔹 git commit

Creates a snapshot of staged changes.

git commit -m "Add initial project files"

✔️ Always write clear and meaningful messages.

❌ Bad:

git commit -m "changes"

✅ Good:

git commit -m "Add login page UI"

🔹 git log

Shows commit history.

git log

You'll see:

Commit hash
Author
Date
Commit message

This helps you understand project history.

🔹 git branch

List all branches:

git branch

Create a new branch:

git branch feature-login

Switch branch:

git checkout feature-login

(or modern way)

git switch feature-login

🔹 git merge

Merge one branch into another.

git merge feature-login

📌 Combines work from different branches.

🔄 A Simple Git Workflow (From Scratch)

Let's see a real beginner workflow.

Step 1: Create a project

mkdir my-project
cd my-project

Step 2: Initialize Git

git init

Step 3: Create a file

touch index.html

Step 4: Check status

git status

Step 5: Stage the file

git add index.html

Step 6: Commit changes

git commit -m "Add initial HTML file"

🎉 Congratulations! You just created your first Git commit.

😄 Git Reality Check

💡 Tips for Beginners

✅ Run git status often

✅ Commit small, meaningful changes

✅ Write clear commit messages

✅ Don't fear breaking things — Git has your back

✅ Practice with small projects

🎯 Conclusion

Git might seem intimidating at first, but once you understand the basics, it becomes second nature.

Start with these commands, practice regularly, and soon you'll be managing complex projects with confidence!

What's your biggest Git challenge? Drop a comment below! 👇

Why Version Control Exists: The Pendrive Problem Every Developer Faced

Harsh — Tue, 30 Dec 2025 18:29:49 +0000

Why Version Control Exists: From Pendrives to Git

If you're new to programming, you've probably heard developers say things like "Just push it to GitHub" or "Check the commit history." At first, it might feel unnecessary or confusing.

So let's answer a simple question:

Why does version control exist at all?

To understand that, we need to go back to how developers worked before tools like Git existed and the answer starts with pendrives, emails, and folders named final_final.

Why Version Control Exists

Version control is a system that keeps track of changes in your code over time.

It helps developers:

Save their work safely
Work together without breaking things
Go back to older versions when something goes wrong

But version control wasn't created because developers wanted fancy tools. It was created because the old ways of sharing code were painful and risky.

The Pendrive Analogy in Software Development

Before version control systems, many developers followed a workflow like this:

Write code on your computer
Copy the project to a pendrive
Give it to a teammate or email it
Hope nothing breaks

Soon, the project folder looked like this:

📁 project
📁 project_final
📁 project_final_v2
📁 project_latest
📁 project_latest_final

No one knew:

Which version was correct
Which changes were new
What had been overwritten

This method worked only when one person was working. The moment a team got involved, things started falling apart.

Problems Developers Faced Before Version Control Systems

1. Multiple Developers Overwriting Each Other's Code

Imagine two developers working on the same file.

Developer A edits the file and saves it
Developer B edits the same file and saves it later

Whoever saves last wins.

The other person's work is completely lost.

This was a nightmare for collaboration.

2. File Versions Getting Lost Over Time

When something broke, developers had no easy way to:

Go back to a working version
See what changed
Fix the issue quickly

Instead, they relied on file names and memory.

Day 1 → project
Day 3 → project_final
Day 5 → project_final_v2
Day 7 → project_latest
❓ Which one actually works?

There was no real history, just guesses.

3. No Record of Who Changed What (or Why)

When bugs appeared, developers asked questions like:

Who changed this file?
Why was this logic added?
When did this break?

And most of the time "there were no answers".

4. Fear of Breaking the Project

Because there was no safety net:

Developers avoided experimenting
New ideas felt risky
One mistake could ruin everything

This slowed down learning and innovation.

Why the Pendrive Model Failed for Teams

Now imagine:

5–10 developers
Working from different places
Changing the same code every day

Pendrives, emails, and "final" folders simply couldn't scale.

Teams needed:

A single source of truth
A complete history of changes
A way to work together without conflict

This is where version control changed everything.

How Version Control Solved These Problems

Version control systems introduced a better way:

✅ Every change is saved as a version

✅ You can see who made a change and why

✅ You can go back in time if something breaks

✅ Multiple developers can work at the same time

✅ Experimenting becomes safe

Instead of guessing, developers gained clarity and confidence.

Why Version Control Is Mandatory Today

Today, tools like Git and GitHub are basic skills for developers.

Without version control:

Team collaboration would be chaotic
Bugs would be harder to fix
Modern software development wouldn't be possible

Version control exists because humans forget, overwrite, and make mistakes and software needed a system that doesn't.

Final Thoughts

The pendrive problem wasn't really about storage. It was about:

Lost work
Broken collaboration
No history
No trust in the process

Version control solved all of that.

So when you learn Git, remember: you're not just learning a tool.

You're learning the solution to a problem every developer once struggled with.

Remember This?

📁 project
📁 project_final
📁 project_final_v2
📁 project_latest
📁 project_latest_final

Those days are over. Welcome to version control. 🚀

Forem: Harsh

Getting Started with cURL

First Things First: What Is a Server?

So Where Does cURL Fit In?

Why Programmers Need cURL

Making Your First cURL Request

What Just Happened Behind the Scenes?

Understanding Request and Response

GET and POST

Using cURL to Talk to APIs

Common Mistakes Beginners Make with cURL

1. Overusing Flags Too Early

2. Forgetting the URL

3. Confusing GET and POST

4. Panicking Over Ugly Output

5. Expecting a Browser-Like Experience

Final Thoughts

DNS Record Types Explained

How does a browser know where a website lives?

What is DNS?

Why are DNS records needed?

What is an NS Record?

What is an A Record?

What is an AAAA Record?

What is a CNAME Record?

What is an MX Record?

What is a TXT Record?

How all DNS records work together for one website

Final Thoughts

How DNS Resolution Works

What is DNS and why name resolution exists

What is the dig command and when it is used

DNS works in layers

Understanding dig . NS → Root name servers

Understanding dig com NS → TLD name servers

Understanding dig google.com NS → Authoritative name servers

Understanding dig google.com → Full DNS resolution

What NS records really represent

How this connects to real browser requests

Mapping dig to DNS lookup stages

Understanding Network Devices

How does the Internet actually reach your laptop?

What is a Network and How Does It Work?

Basic working principle

A quick history

What is a Modem?

What it actually does

Analogy

What is a Router?

Analogy

Switch vs Hub: How Local Networks Actually Work

Hub (old technology)

Switch (modern networks)

Key difference

What is a Firewall?

Responsibilities

Analogy

What is a Load Balancer?

Why it exists

What it does

Analogy

How These Devices Work Together (Real-World Setup)

What happens when you open a website?

Where These Devices Sit in System Architecture

Final Thoughts

Inside Git: How It Works and the Role of the .git Folder

In this article, we'll open Git's black box and understand how Git works internally in simple terms. No advanced theory. No magic. Just a clear mental model.

How Git Works Internally (Big Picture)

What Is the .git Folder and Why Does It Exist?

What does .git contain?

Why does Git need this folder?

Git Objects: Blob, Tree, Commit (The Building Blocks)

Blob: File Content

Tree: Folder Structure

Commit: A Snapshot

How Git Tracks Changes (Not Diffs!)

What Happens Internally During git add

Mental model:

What Happens Internally During git commit

How Git Uses Hashes to Ensure Integrity

What is the `dig` command and when it is used

Understanding `dig com NS` → TLD name servers

Understanding `dig google.com NS` → Authoritative name servers

Understanding `dig google.com` → Full DNS resolution

What Is the `.git` Folder and Why Does It Exist?

What does `.git` contain?

What Happens Internally During `git add`

What Happens Internally During `git commit`