Forem: Himanshu Kumar

Getting Started with cURL

Himanshu Kumar — Fri, 13 Feb 2026 11:51:08 +0000

Imagine you're sending a quick message to a friend over the internet. Your browser (like Chrome or Firefox) does this automatically when you visit a website it asks the website for the page, and the website sends it back.
cURL is like a tiny messenger you control from your computer's terminal or command prompt. It stands for client URL basically a command-line tool that lets you send requests to servers and get replies, without needing a browser.
It's free, works on Windows, Mac, Linux and is already installed on most computers.
Think of it as your personal way to chat with web servers directly from the command line.
Here's a simple visual of how cURL talks to a server:

Why Do Programmers Need cURL?

As a beginner in web dev, you'll build or use APIs (Application Programming Interfaces) these are like doors that let your code talk to other services (like fetching weather data, user info or posting a tweet).
cURL is perfect because:

It's fast for testing: You can quickly check if an API works without writing full code.
It helps debug: See exactly what the server sends back.
No browser needed: Great for servers, scripts, or when you're learning backend stuff.
Builds confidence: Start simple in the terminal before using it in code (like JavaScript's fetch or Python's requests).

Making Your First Request Using cURL

Open your terminal (on Mac/Linux: Terminal app and on Windows: Command Prompt or PowerShell).
Type this super simple command and press Enter:

curl https://chaicode.com

What happens? cURL sends a message to chaicode.com asking for its homepage, and the server sends back the HTML code of the page you'll see a bunch of text in your terminal (that's the webpage's code!).

StatusCode        : 200
StatusDescription : OK
Content           : <!doctype html>
                    <html lang="en">
                      <head>
                        <meta charset="UTF-8" />
                        <link
                          rel="icon"
                          type="image/svg+xml"
                          href="/assets/favicon-light-B_XE0b_A.svg"
                          media="(prefers-color...
RawContent        : HTTP/1.1 200 OK
                    Transfer-Encoding: chunked
                    Connection: keep-alive
                    Age: 4316
                    cache-status: "Netlify Edge"; hit
                    Report-To: {"group":"cf-nel","max_age":604800,"endpoints":[{"url":"https://a.nel.clou...
Forms             : {}
Headers           : {[Transfer-Encoding, chunked], [Connection, keep-alive], [Age, 4316], [cache-status, "Netlify
                    Edge"; hit]...}
Images            : {}
InputFields       : {}
Links             : {}
ParsedHtml        : mshtml.HTMLDocumentClass
RawContentLength  : 2143

That's it your first reques.
To make it cleaner, try this public test API:
text

curl https://jsonplaceholder.typicode.com/todos/1

You'll get back some JSON data like:

StatusCode        : 200
StatusDescription : OK
Content           : {
                      "userId": 1,
                      "id": 1,
                      "title": "delectus aut autem",
                      "completed": false
                    }
RawContent        : HTTP/1.1 200 OK
                    Connection: keep-alive
                    access-control-allow-credentials: true
                    nel: {"report_to":"heroku-nel","response_headers":["Via"],"max_age":3600,"success_fraction":0.01,"f
                    ailure_fraction":0.1...
Forms             : {}
Headers           : {[Connection, keep-alive], [access-control-allow-credentials, true], [nel, {"report_to":"heroku-nel
                    ","response_headers":["Via"],"max_age":3600,"success_fraction":0.01,"failure_fraction":0.1}],
                    [pragma, no-cache]...}
Images            : {}
InputFields       : {}
Links             : {}
ParsedHtml        : mshtml.HTMLDocumentClass
RawContentLength  : 83

Understanding Request and Response

Every time you talk to a server (with browser or cURL), it's a request to response conversation.

Request: What you send (like "Hey server, give me this page!").
Response: What comes back (the page content & some info).

A basic response has:

Status code like 200 OK (good!), 404 Not Found (oops, page missing), 500 (server error).
Headers give extra info (like content type: "this is JSON").
Body is the actual data (HTML, JSON, etc.).

Try this to see headers too:

curl -i https://chaicode.com

Here's a simple diagram of a basic HTTP request and response:

Browser or cURL sends request with method, headers, etc and Server replies with status, headers & content.
Browser does the same thing behind the scenes, but cURL lets you see it directly.

Using cURL to Talk to APIs (Just GET and POST)

Most beginner APIs use two main methods:

GET: Ask for data (like reading a list of posts). Default in cURL.
POST: Send data (like creating a new user or submitting a form).

GET example (fetch a post):

curl https://jsonplaceholder.typicode.com/posts/1

POST example (send fake data to create a post):

curl -X POST \
  -H "Content-Type: application/json" \
  -d '{"title": "My First Post", "body": "Hello world!", "userId": 1}' \
  https://jsonplaceholder.typicode.com/posts

-X POST: Tells cURL to use POST method.
-H: Add a header (here, saying data is JSON).
-d: The data you're sending (in quotes).

The server replies with your new post (fake API echoes it back). Try it!
This is how you test APIs before coding them in your app.

Common Mistakes Beginners Make with cURL

Forgetting quotes around URLs with ? or & (special characters break things). Fix: Use "quotes" like "https://api.com?key=value".
Ignoring status codes — if you get error data but don't notice 404 or 401, it confuses you. Always use -i to see status.
Overloading with too many flags too soon — start simple! Add one option at a time.
Not using verbose mode for debugging: Add -v (or -vv for more) to see full details when something fails.
Forgetting the method: For POST/PUT, you need -X POST or it defaults to GET.
Sending wrong data format: Always match -H "Content-Type: application/json" if sending JSON.

Pro tip: When stuck add -v and read what cURL prints as it tells you a lot.

Connect with Me
Follow me on LinkedIn: https://www.linkedin.com/in/himazing

DNS Record Types

Himanshu Kumar — Fri, 30 Jan 2026 17:22:47 +0000

Have you ever thought: How does a browser know where a website lives?

When you type google.comin your browser, you are not really connecting to a name. You are connecting to a server computer somewhere in the world. As computers do not understand names.They understand numbers (IP addresses).

So how does the internet convert a name into a number?
The answer is DNS.

What is DNS?

DNS (Domain Name System) is like the phonebook of the internet. Back in the day, if you wanted to call your teacher Hitesh Sir, you had to look up his name in a physical phonebook to find his number: 97565XXXXX. DNS does the exact same thing for the web. It takes a human friendly name likeexample.comand translates it into a machine-friendly number like 191.19.13.1

You type a website name
DNS finds the IP address
Browser connects to that IP
Website loads

Why DNS Records Are Needed

A domain name is like a business. That business can have:

Website
Email service
Subdomains
Verification data

DNS records are instructions that tell the internet:

Where the website lives
Where emails should go
Which company controls this domain

Each record solves a different problem.

NS Record (Who Controls the Domain)

NS is Name Server and NS record tells Which DNS servers are responsible for this domain. It tells DNS resolvers which servers to contact when it's looking for DNS records for that domain name.

Real-life analogy

You buy a domain from GoDaddy and you host your website on vercel then your NS record will say "This domain is managed by vercel’s DNS servers".

Understanding Network Devices

Himanshu Kumar — Fri, 30 Jan 2026 06:20:01 +0000

How Data Travels in a Network

Imagine you want to send a letter to a friend. The letter travels from your house to the post office, then through roads and sorting centers, and finally reaches your friend's house. Computer networks work in a similar way means your device sends data that travels through many devices before reaching its destination.

Computer networks work in a similar way:

Your device sends data that travels through many devices before reaching its destination.

Common Types of Network Devices

There are many network devices available, but we will focus on the most commonly used ones:

Modem
Router
Switch
Hub
Repeater
Load Balancer

Modem

A modem (Modulator–Demodulator) connects your home or office network to your Internet Service Provider (ISP). A modem converts signals between your Internet Service Provider line and your digital devices.The working of a modem is simple that it converts digital signals from our devices into a form suitable for transmission over the ISP’s physical medium and converts incoming signals back into digital form.

Why is it needed?

ISP sends internet signals in a special format
Your computer understands only digital data
Modem translates between these two

Real-life Analogy

Modem is like a language translator between you and the internet company.

What is a Router?

A router connects multiple devices and decides where data should go.

What Router Does

Assigns local IP addresses to devices
Sends data to the correct device
Connects your network to the modem

Real-life Analogy

Router is like a traffic police officer at a junction.

Car (data) arrives
Police checks address
Sends it on correct road

Hub

Hub sends data to everyone.

How Hub Works

One device sends data
Hub broadcasts to all ports
Only correct device accepts

Real-life Analogy

It is like a loudspeaker in a classroom that's everyone hears.

Problems

Slow
Wastes bandwidth
No security

Switch

Switch sends data only to the target device.

How Switch Works

Learns MAC addresses
Stores them in a table
Sends data only to matched port

Analogy

Like a telephone operator connecting your call only to the person you dial.

What is a Firewall?

Firewall protects your network from dangerous traffic.

What Firewall Does

Checks every incoming & outgoing packet
Allows safe traffic
Blocks suspicious traffic

Why Your Code Needs a Time Machine: A Git Guide for Beginners

Himanshu Kumar — Thu, 29 Jan 2026 16:06:39 +0000

Git for Beginners: The Essential Guide to Version Control

What is Git?

Imagine you're writing a book and you save each chapter as "Chapter1_final.docx", then "Chapter1_really_final.docx", and eventually "Chapter1_NO_REALLY_FINAL.docx". We've all been there! Git is the solution to this madness.

Git is a distributed version control system that helps developers track changes in their code over time. Think of it as a super-powered "undo" button with memory - it remembers every change you've ever made, who made it, and when.

Why Use Git?

Collaboration Made Easy

Multiple developers can work on the same project simultaneously without stepping on each other's toes. Git manages the merging of changes seamlessly.

Safety Net

Made a mistake? Git lets you revert to any previous version of your code. No more "final_final_v2" files!

Experiment Freely

Create separate branches to try new features without affecting the main project. If it doesn't work out, simply discard the branch.

Track Changes

See exactly what changed, who changed it, and why they made those changes through commit messages.

Core Git Concepts in Simple Terms

Repository (Repo)

Your project's folder that Git tracks. It contains all your files and their complete history.

my_project/
├── .git/          # Git's magic folder (hidden)
├── index.html
├── style.css
└── script.js

Commit

A snapshot of your project at a specific point in time. Like taking a photo of your code that you can return to later.

Branch

A parallel version of your repository. The main branch is usually called main or master. You create new branches to develop features independently.

Head

A pointer to the latest commit in your current branch. Think of it as "you are here" marker on your commit map.

The Three Areas of Git

Understanding these three areas is crucial to mastering Git:

graph LR
    A[Working Directory<br>Your actual files] --> B[Staging Area<br>Preparing changes] --> C[Repository<br>Saved snapshots]

    C -.-> A

Working Directory - Where you edit your files
Staging Area - Where you prepare changes for saving
Repository - Where Git permanently stores your commits

Essential Git Commands

Getting Started

# Initialize a new Git repository
git init

# Check the status of your repository
git status

# See your commit history
git log

The Basic Workflow

Let's walk through a typical development session:

# 1. Create a new project folder
mkdir my-project
cd my-project

# 2. Initialize Git
git init

# 3. Create a file
echo "# My Awesome Project" > README.md

# 4. Check what Git sees
git status
# Output: README.md is "untracked"

# 5. Stage the file (prepare it for commit)
git add README.md

# 6. Commit with a descriptive message
git commit -m "Add project README file"

# 7. Check your commit history
git log

Branching Basics

# Create a new branch for a feature
git branch feature-login

# Switch to that branch
git checkout feature-login
# Or use the shortcut:
git switch feature-login

# Make changes, then merge back to main
git checkout main
git merge feature-login

Practical Git Workflow Example

Let's build a simple website together using Git:

# Start a new project
mkdir my-website
cd my-website
git init

# Create initial files
echo "<!DOCTYPE html>" > index.html
echo "body { color: blue; }" > style.css

# First commit
git add .
git commit -m "Initial project setup with HTML and CSS"

# Create a branch for navigation
git checkout -b add-navigation

# Add navigation to index.html
# (You would edit the file here)
echo "<nav>Home | About | Contact</nav>" >> index.html

# Commit the navigation
git add index.html
git commit -m "Add navigation bar"

# Switch back to main and merge
git checkout main
git merge add-navigation

# View your project history
git log --oneline --graph

Common Git Commands Cheat Sheet

Command	What It Does	Example
`git init`	Starts tracking a folder	`git init`
`git add`	Stages changes	`git add file.txt`
`git commit`	Saves staged changes	`git commit -m "Message"`
`git status`	Shows repository status	`git status`
`git log`	Shows commit history	`git log --oneline`
`git branch`	Lists/manages branches	`git branch feature-x`
`git checkout`	Switches branches	`git checkout main`
`git merge`	Combines branches	`git merge feature-x`
`git clone`	Copies a remote repository	`git clone url`
`git push`	Uploads commits to remote	`git push origin main`
`git pull`	Downloads remote changes	`git pull origin main`

Local Repository Structure

graph TD
    A[Local Repository] --> B[main branch]
    A --> C[feature-1 branch]
    A --> D[feature-2 branch]

    B --> E[Commit C3<br/>Latest on main]
    E --> F[Commit C2]
    F --> G[Commit C1<br/>Initial commit]

    C --> H[Commit F1<br/>Feature work]
    H --> G

    D --> I[Commit F2<br/>Other feature]
    I --> G

Pro Tips for Git Beginners

Commit Often, Commit Early

Small, frequent commits are better than huge, infrequent ones. Each commit should represent one logical change.
Write Meaningful Commit Messages

Bad: git commit -m "fixed stuff"

Good: git commit -m "Fix login button alignment on mobile"
Use .gitignore

Create a .gitignore file to exclude temporary files, logs, and dependencies:
```
node_modules/
.env
*.log
.DS_Store
```
Learn to Undo

* `git restore --staged file.txt` (unstage a file)

* `git restore file.txt` (discard uncommitted changes)

* `git reset --soft HEAD~1` (undo last commit but keep changes)

Start with the Basics Master add, commit, status, log, and branch before moving to advanced topics.

Remember: Everyone was a Git beginner once. The key is to start using it in your projects, make mistakes, and learn from them. Happy coding!

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

Himanshu Kumar — Fri, 16 Jan 2026 18:22:43 +0000

You already type git add, git commit, and git push. They do the job. But do you know what actually happens when you press Enter? This article opens the black box and shows what Git stores inside the hidden .git folder.

Start a repo

mkdir my-app
cd my-app
git init

git init creates the .git folder. That folder is the repository keep it safe. Delete it and your project forgets its history.

Think of Git like a parcel system

Imagine you’re sending parcels by train across India. Each parcel has a unique receipt number. If two parcels contain the same book, the railway uses the same packaging and receipt to save space. Git works similarly:

Files are parcels (content).
Receipts (hashes) identify parcels by content, not by name.
The depot (.git) stores parcels and receipts, and keeps track of which receipts belong to which shipment (commit).

This idea storing content by its fingerprint is the heart of Git.

What is inside .git (the control room)
You don’t usually open .git, but it contains everything Git needs:

objects/ — where all actual data lives (file contents, folders, commits).
refs/ — pointers to commits (branches, tags).
HEAD — which branch you’re on right now.
index — the staging area (what will go into the next commit).
config, hooks/, info/ — settings and helper scripts. Think: .git is not a spare folder. It is the repository. The rest of your project is just the working copy.

The three building blocks
Git stores everything using only three object types:

Blob- the raw file content. No name, no path. Just bytes. Analogy: the book inside the parcel.
Tree- a directory listing that maps names → blobs or subtrees. Analogy: the list of parcel labels inside a crate.
Commit- a snapshot of the whole project at one moment. It points to a top-level tree and to previous commit(s). It includes author, date, and message. Analogy: a train manifest that points to the crate (tree) and previous manifests.

All these objects live under objects/ and are named by a hash (their fingerprint).

What git add actually does

You may say “I staged the file.” Internally:

Git reads the file content from your working folder.
It creates a blob object from that content (unless an identical blob already exists).
It stores the blob under .git/objects/ using a name derived from a hash.
It updates the index with a mapping: filename → blob-hash.

So staging is preparing a list of exact content objects to include in the next snapshot.

What git commit actually does

When you commit:

Git reads the index (the staged blueprint).
It creates tree objects that represent directory structure and map filenames to blob hashes.
It creates a commit object that points to the top tree and to parent commits; commit stores message, author, time.
It updates a branch ref (like refs/heads/main) to point to the new commit and leaves HEAD pointing there.

Result: a new snapshot is saved. Git only writes new objects for changed content unchanged blobs are reused.

The Pendrive Problem: Why Version Control Was Born

Himanshu Kumar — Fri, 16 Jan 2026 17:40:55 +0000

Back in the day, developers literally carried code around on USB sticks (pendrives). Imagine Alice finishing a feature and walking over to Bob's desk with a thumb drive of code. As one blogger quipped, "Whoever pastes last wins" - meaning the last copy overwrote everyone else's work. Saving code felt like surgery without anesthesia: every commit was a gamble. Without any automated backup or history, one dev's bug fix could vanish the moment a colleague pushed their version over it. This chaos meant code would disappear without warning - nobody knew why or when the latest change was lost.

Even sharing by email wasn't much better. Teams ended up with dozens of zipped files named project_code_final.zip, project_code_final_updated.zip, project_code_final_updated_NEW.zip, etc.. Now someone always had to ask, "Which one is latest?" It was madness: the more times you saw the word "final" in a filename, the less final it usually was.

The Nightmare of No Version Control
Before Git and modern systems, these problems were normal: developers accepted that manual file copying would cause pain. The core issues included:

Code Overwrites: When two people edited the same file manually, one person's changes would silently delete the other's work. There was no merge tool - the "last copy" simply won.
No History: Every change left no permanent record. If a bug crept in, the team had no timeline to inspect. They couldn't easily answer "who changed this line?" or "when did the issue start?".
Collaboration Chaos: Two devs working in parallel was guaranteed chaos. You couldn't safely branch out. Teams often had to serialize work (one person at a time) or painfully merge by hand.
No Rollback: If yesterday's code was better… too bad. There was no easy undo. Unless someone kept an old backup, a bad change was permanent.
These were real obstacles, not just hypothetical risks. Developers spent more time chasing files and lost patches than writing new features. Every "final_final_v2_FINAL" folder was a Band-Aid over a broken process.

All that manual copying led to total chaos. In the illustration above, one panel shows a developer juggling multiple "final" folders - a classic folder-naming Olympiad. Rather than progress, teams ended up with dozens of almost-identical copies. Nobody could tell which folder was the true latest version. The graphic also hints at crashes and overwritten files: without version control, the last save wins, and everything else is lost. In short, this era was a recipe for confusion and lost work.

Why We Needed Version Control

This messy method was fine for tiny projects, but it fell apart at scale. The true tipping point came with the Linux kernel. By the early 2000s, thousands of developers worldwide were collaborating on Linux. They initially used a tool called BitKeeper, but in 2005 its free license was revoked for Linux development. Suddenly the community had no suitable tool to manage their massive codebase.
Linus Torvalds solved the problem by building Git from scratch in 2005. He designed Git with clear goals: lightning-fast operations, a simple but powerful architecture, strong support for thousands of parallel branches, fully distributed repositories, and efficiency with large projects. In other words, Git was tailored to handle exactly the issues that pendrives and shared folders couldn't. It was built not for convenience, but for reliability under real-world pressure.

Version Control to the Rescue
With version control (like Git), everything changed. Instead of physically passing files around, each developer clones the full repository to their own machine. They work locally, then "push" changes to a shared repo or server. The image below shows this modern workflow: multiple devs push and pull to a central Git server with a continuous commit history.

Now every change is a recorded commit (think of it as a snapshot) stamped with the author and timestamp. No one can accidentally overwrite another's work without Git noticing - conflicts get flagged up immediately. If a bug appears, you can time-travel back to any previous commit and undo the mistake. As one summary table (below) highlights, version control drops the risk of data loss to very low and gives a complete history of every change. In practice, this means developers can confidently experiment (new branches), track down who changed what, and recover any lost code. Mistakes become reversible rather than catastrophic.

Life After Version Control

Today, using version control is the norm. Tools like Git and platforms like GitHub/GitLab/WebSVN host billions of lines of code and coordinate teams everywhere. For perspective, GitHub reports over 150 million developers and 420 million repositories on its platform. Surveys show Git is now used by nearly 95% of developers as their primary VCS. In this new world:
Developers push code fearlessly, knowing they can always git revert or git checkout an old commit if needed.
Open-source projects scale to thousands of contributors because every merge and branch is tracked automatically.
Teams sleep better: they trust that "oops" moments are just a few commands away from being fixed.
(Side note: Git is just the underlying tool; platforms like GitHub are online hubs that make collaboration social and cloud-based. But whether you use GitHub, GitLab or another service, the power comes from Git itself.)

Embracing the Peace of Mind

In the end, version control isn't about loving the commands - it's about trust. Trust that your code won't vanish, that teammates won't unknowingly overwrite your work, and that every change is recorded in a fail-safe timeline. Version control was born not because developers were gadget-hungry, but because old habits had become unworkable. Passing files around on pendrives simply couldn't support growing teams and complex software. Git (and its peers) fundamentally replaced that chaos with an unbroken history of the code.
So next time you hesitate to hit Save or Push, remember: you're not committing code - you're committing peace of mind. Version control means nothing is truly final until you say so, and even then, you can always rewind. It's what lets us write code confidently together, knowing there's always a safety net.