<![CDATA[subhajit bag]]>https://blog.subhajitbag.inRSS for NodeWed, 08 Apr 2026 14:41:14 GMT60<![CDATA[How a Browser Works: A Beginner-Friendly Guide to Browser Internals]]>https://blog.subhajitbag.in/how-a-browser-works-a-beginner-friendly-guide-to-browser-internalshttps://blog.subhajitbag.in/how-a-browser-works-a-beginner-friendly-guide-to-browser-internalsSun, 01 Feb 2026 17:32:39 GMTWe use browsers every day to access the world's information, but what exactly happens behind that colorful icon? Most people think of a browser as just a window to the internet, but under the hood, it is one of the most complex pieces of software ever built.

Think of a browser as a high-speed factory. It takes in raw materials (code) and transforms them into a finished product (the website you see).

What Happens When You Press Enter?

The moment you type a URL and hit Enter, a chain reaction begins. The browser doesn't "have" the website; it has to go out, find it, and build it from scratch every single time.

1. The Main Components

A browser isn't just one program; it’s a collection of specialized parts:

  • User Interface (UI): Everything you see around the webpage—the address bar, back button, bookmarks, and tabs.

  • Networking: The "delivery truck." It goes out to the internet to fetch the HTML, CSS, and JavaScript files from a server.

  • Browser Engine: The "manager." It coordinates actions between the UI and the rendering engine.

  • Rendering Engine: The "builder." This is the most important part—it takes the code and draws the pixels on your screen. (Examples include Blink in Chrome or Gecko in Firefox).

2. The Power of Parsing

Before the browser can build anything, it has to parse the code. Parsing is just a fancy word for "breaking something down to understand its meaning."

The Math Analogy: If you see 2 + 3 * 5, your brain "parses" it. You identify the numbers and the operators, and you know the order of operations. The browser does the same with code. It reads <div>Hello</div> and understands that <div> is a container and "Hello" is the text inside.

3. Building the Foundation: DOM and CSSOM

The rendering engine creates two "blueprints" to understand your website:

The DOM (Document Object Model)

As the browser reads your HTML, it builds a DOM Tree.

  • Analogy: Think of it as a family tree. The <html> is the grandparent, the <body> is the parent, and <p> or <img> are the children.

The CSSOM (CSS Object Model)

While building the DOM, the browser also reads your CSS to build a CSSOM. This tells the browser the styles (colors, fonts, sizes) for each part of the DOM tree.

4. The Render Tree: Putting it Together

The browser then combines the DOM and the CSSOM to create the Render Tree. The Render Tree only contains things that will actually be visible on the screen. (For example, if an element has display: none, it won't be in the Render Tree).

5. Layout, Painting, and Display

Now that the browser knows what to show and how it should look, it has to figure out where it goes.

  1. Layout (Reflow): The browser calculates the exact coordinates and size of every element on the page. If you resize your window, the browser has to do this again.

  2. Painting: The browser fills in the pixels. It draws the text, colors, images, borders, and shadows.

  3. Display: Finally, the finished "painting" is sent to your screen, and you see the website!

Summary: The Flow

  • Networking fetches the code.

  • Parsing turns code into the DOM and CSSOM.

  • The Render Tree combines structure and style.

  • Layout calculates positions.

  • Painting draws the visuals.

Don't worry if you don't remember every step! The key takeaway is that your browser is a master translator, turning text files into the interactive experiences we use every day.

]]><![CDATA[CSS Selectors 101: Targeting Elements with Precision]]>https://blog.subhajitbag.in/css-selectors-101-targeting-elements-with-precisionhttps://blog.subhajitbag.in/css-selectors-101-targeting-elements-with-precisionSun, 01 Feb 2026 17:22:39 GMTIf HTML is the skeleton of your website, then CSS is the wardrobe. But how do you tell your code, "Make this specific paragraph red, but leave the others alone"?

You use CSS Selectors. Think of selectors as a way to address specific parts of your HTML. It’s like a mailing system: you can send a message to everyone in a city, everyone on a specific street, or just one person at a specific house.

1. The Element Selector

This is the broadest way to style. It targets every single instance of a specific HTML tag.

  • Syntax: p { color: blue; }

  • What it does: Every <p> tag on your page will now have blue text.

  • Analogy: "Everyone wearing a blue shirt, please stand up."

2. The Class Selector

Classes are used when you want to style a specific group of elements, regardless of what tag they are. You can use the same class on many different elements.

  • Syntax: Use a dot . followed by the class name.

    • .highlight { background-color: yellow; }

  • HTML usage: <p class="highlight">Important text</p>

  • Analogy: "Everyone in the 'Photography Club' meet at the entrance."

3. The ID Selector

An ID is unique. You should only use a specific ID once per page. It is used to target one very specific element.

  • Syntax: Use a hash # followed by the ID name.

    • #main-title { font-size: 40px; }

  • HTML usage: <h1 id="main-title">Welcome</h1>

  • Analogy: "Calling Suhojit—please come to the office." (Targeting a specific individual by name).

4. Grouping Selectors

If you want several different elements to share the same style, you don't have to write the same code three times. You can group them with a comma.

  • Syntax: h1, h2, p { font-family: Arial; }

  • What it does: Applies the font to all H1s, H2s, and paragraphs at once.

  • Analogy: "The soccer team, the basketball team, and the track team all need to sign this form."

5. Descendant Selectors

Sometimes you only want to style an element if it is inside another specific element.

  • Syntax: Space between selectors.

    • div p { color: green; }

  • What it does: Only targets paragraphs that are inside a <div>. If a paragraph is outside, it stays the default color.

  • Analogy: "Only the people inside the library must stay quiet."

Basic Priority: Who Wins? (Specificity)

What happens if you tell all <p> tags to be blue, but you tell .highlight paragraphs to be red? CSS has a "weight" system called Specificity.

A simple rule of thumb for beginners is:

  1. ID selectors are the strongest.

  2. Class selectors are medium.

  3. Element selectors are the weakest.

If there is a conflict, the "stronger" selector wins!

Summary

  • Tag: Targets everyone.

  • Class: Targets a specific group.

  • ID: Targets one unique item.

  • Comma (,): Targets multiple groups.

  • Space ( ): Targets items inside other items.

Mastering these five selectors is the foundation of everything you will build in CSS.

]]><![CDATA[Emmet for HTML: A Beginner’s Guide to Writing Faster Markup]]>

and
over and over again, you know that writing HTML can feel a bit slow. It’s like building a house by hand-carving every single brick. This is where Emmet comes in. Emmet is a powerful...]]>https://blog.subhajitbag.in/emmet-for-html-a-beginners-guide-to-writing-faster-markuphttps://blog.subhajitbag.in/emmet-for-html-a-beginners-guide-to-writing-faster-markupSun, 01 Feb 2026 17:18:20 GMTIf you’ve ever spent five minutes typing out <p></p> and <div></div> over and over again, you know that writing HTML can feel a bit slow. It’s like building a house by hand-carving every single brick.

This is where Emmet comes in. Emmet is a powerful "shorthand" language built into most modern code editors (like VS Code). It allows you to type short abbreviations that instantly expand into full blocks of HTML.

What is Emmet?

In simple terms, think of Emmet as Auto-correct for HTML on steroids. Instead of typing out all the brackets and closing tags, you type a simple word, hit the Tab key, and Emmet does the heavy lifting for you. It’s not a new language; it’s just a faster way to write the HTML you already know.

1. Generating the Boilerplate

Every HTML file needs a basic structure (the doctype, head, body, etc.).

  • The Manual Way: Type about 10–15 lines of code.

  • The Emmet Way: Type ! and press Tab.

The Result:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>Document</title>
</head>
<body>

</body>
</html>

2. Creating Elements with Classes and IDs

Emmet uses syntax similar to CSS selectors, making it very intuitive to learn.

  • For an ID: Use the # symbol.

    • div#header → <div id="header"></div>

  • For a Class: Use the . symbol.

    • p.intro → <p class="intro"></p>

3. Nesting: Creating Elements Inside Elements

You can build entire structures in one line using the > (child) symbol.

  • Abbreviation: div>ul>li

  • Expanded HTML:

<div>
    <ul>
        <li></li>
    </ul>
</div>

4. Multiplication: Creating Many Elements at Once

Need a list with five items? Don't copy-paste. Use the * symbol.

  • Abbreviation: ul>li*5

  • Expanded HTML:

<ul>
    <li></li>
    <li></li>
    <li></li>
    <li></li>
    <li></li>
</ul>

5. Adding Text and Attributes

You can even pre-fill your tags with text or specific attributes.

  • Text Content: Use curly braces { }.

    • button{Click Me} → <button>Click Me</button>

  • Attributes: Use square brackets [ ].

    • img[src="logo.png"] → <img src="logo.png" alt="">

Putting it All Together: A Pro Example

Imagine you need a navigation bar with three links inside a nav container.

The Emmet Shortcut: nav>ul>li*3>a

The Result:

<nav>
    <ul>
        <li><a href=""></a></li>
        <li><a href=""></a></li>
        <li><a href=""></a></li>
    </ul>
</nav>

Summary: Why Use Emmet?

  • Speed: You can write a whole page structure in seconds.

  • Accuracy: Emmet never forgets to close a tag or mistypes a bracket.

  • Focus: You spend less time fighting with your keyboard and more time thinking about your design.

Emmet is purely optional, but once you start using it, you’ll never want to go back to the "slow way."

]]><![CDATA[Understanding HTML Tags and Elements]]>https://blog.subhajitbag.in/understanding-html-tags-and-elementshttps://blog.subhajitbag.in/understanding-html-tags-and-elementsSun, 01 Feb 2026 17:06:30 GMTThink of a webpage like a human body. The CSS is the skin and clothes (the style), JavaScript is the muscles (the movement), and HTML (HyperText Markup Language) is the skeleton. It provides the structure and tells the browser exactly what kind of content it is looking at—whether it's a heading, a paragraph, or a button.

What is an HTML Tag?

A tag is like a label. It tells the browser, "Everything inside here should be treated as a specific type of content." Tags are wrapped in angle brackets < >.

Most tags come in pairs:

  1. Opening Tag (<p>): Tells the browser where the content starts.

  2. Closing Tag (</p>): Tells the browser where the content ends (notice the forward slash /).

Tag vs. Element: What’s the Difference?

These terms are often used interchangeably, but there is a subtle difference:

  • Tag: Just the markers (<h1> or </h1>).

  • Content: The actual text or data inside.

  • Element: The whole package—the opening tag, the content, and the closing tag combined.

Self-Closing (Void) Elements

Some elements don't have "content" in the traditional sense, so they don't need a closing tag. These are called Void Elements.

  • <img>: Used to show an image.

  • <br>: Used for a single line break.

  • <hr>: Creates a horizontal line across the page.

Block-level vs. Inline Elements

This is one of the most important concepts for building layouts. Think of these as "The Box" vs. "The Text."

1. Block-level Elements

These elements always start on a new line and take up the full width available (like a block).

  • Common tags: <div>, <h1> through <h6>, <p>, <ul>.

  • Analogy: A brick in a wall.

2. Inline Elements

These elements do not start on a new line. They only take up as much width as necessary.

  • Common tags: <span>, <a> (links), <strong> (bold).

  • Analogy: A word inside a sentence.

Commonly Used Tags to Get Started

TagPurposeType
<h1> to <h6>Headings (1 is biggest, 6 is smallest)Block
<p>Paragraphs of textBlock
<a>Hyperlinks to other pagesInline
<div>A container used to group other elementsBlock
<span>A container used for small parts of textInline
<ul> & <li>Unordered (bulleted) listsBlock
]]><![CDATA[TCP Working: 3-Way Handshake & Reliable Communication]]>https://blog.subhajitbag.in/tcp-working-3-way-handshake-and-reliable-communicationhttps://blog.subhajitbag.in/tcp-working-3-way-handshake-and-reliable-communicationSun, 01 Feb 2026 14:33:13 GMTImagine sending a 1,000-piece jigsaw puzzle through the mail, but instead of a box, you send each piece in its own tiny envelope. Without rules, some pieces might arrive late, some might get lost, and the receiver would have no idea how to put them together.

In the digital world, TCP (Transmission Control Protocol) is the set of rules that solves this. It ensures that data isn't just sent, but is received completely, in order, and without errors.

Why We Need TCP: Solving the Chaos

If we sent data without a protocol like TCP, we would face three major problems:

  1. Lost Data: A packet might disappear in transit, leaving you with a broken file.

  2. Out-of-Order Delivery: Packet #5 might arrive before Packet #1, making a mess of the information.

  3. Corruption: Data might get "flipped" or damaged during the journey.

TCP is designed to solve these by creating a stable "virtual circuit" between two computers.

The TCP 3-Way Handshake: The "Digital Greeting"

Before TCP sends a single byte of real data (like a photo or a message), it must establish a connection. It does this through a process called the 3-Way Handshake.

Think of it like a formal phone conversation:

  1. Step 1: SYN (Synchronize)

    • Computer A says: "Hey, I want to talk to you. Here is my starting sequence number so we can keep track of our messages."

  2. Step 2: SYN-ACK (Synchronize-Acknowledgment)

    • Computer B says: "I hear you! I'm ready to talk too. I received your request, and here is my starting sequence number so you can track my messages."

  3. Step 3: ACK (Acknowledgment)

    • Computer A says: "Got it! We are both ready. Let's start sending data."

Once this "handshake" is complete, the connection is established, and the actual data transfer begins.

How TCP Ensures Reliability

Once the conversation starts, TCP uses a system of Sequence Numbers and Acknowledgments to stay organized.

  • Ordering: Every packet is numbered (e.g., 1, 2, 3). If they arrive as 1, 3, 2, TCP waits and reorders them correctly before showing them to the application.

  • Reliability (Retransmission): If Computer A sends Packet #2 but never receives an "Acknowledgment" (ACK) back from Computer B, it assumes the packet was lost and sends it again.

  • Correctness: TCP uses a "checksum" to verify the data hasn't been corrupted. If the math doesn't add up, it asks for a fresh copy.

Closing the Connection: The 4-Way Terminate

When the data transfer is finished, TCP doesn't just "hang up." It follows a polite closing procedure using FIN (Finish) and ACK flags.

  1. A sends a FIN: "I'm done sending data."

  2. B sends an ACK: "I hear you, I'm just finishing up my last few tasks."

  3. B sends a FIN: "Okay, I'm done now too."

  4. A sends an ACK: "Goodbye!"

This ensures that both sides have finished their work and no data is cut off prematurely.

Summary

  • Handshake: Establishes trust and synchronizes numbers.

  • Sequencing: Keeps data in the right order.

  • Retransmission: Fixes lost data by sending it again.

  • Termination: Closes the connection gracefully.

TCP is the backbone of the web because it turns an unreliable internet into a reliable stream of information.

]]><![CDATA[TCP vs UDP: When to Use What, and How TCP Relates to HTTP]]>https://blog.subhajitbag.in/tcp-vs-udp-when-to-use-what-and-how-tcp-relates-to-httphttps://blog.subhajitbag.in/tcp-vs-udp-when-to-use-what-and-how-tcp-relates-to-httpSun, 01 Feb 2026 14:09:52 GMTTCP vs UDP: The Rules of the Internet Road

Whenever you use the internet, your data is being sent using specific rules called protocols. Think of these as the "shipping methods" for your digital packages. The two most common methods are TCP and UDP.

While they both move data, they do it in completely different ways. One is built for safety, while the other is built for speed.

What are TCP and UDP?

  • TCP (Transmission Control Protocol): This is the Reliable Courier. It ensures that every single piece of data arrives at the destination, in the correct order, without any errors. If a piece goes missing, TCP goes back and gets it.

  • UDP (User Datagram Protocol): This is the Live Broadcaster. It fires data at the destination as fast as possible. It doesn't check if the data arrived, and it doesn't care if things show up out of order. It just keeps moving.

Key Differences: Reliability vs. Speed

FeatureTCP (Reliable)UDP (Fast)
ConnectionMust "shake hands" before talking.Just starts sending.
ReliabilityGuarantees delivery.No guarantee; data can be lost.
OrderingData arrives in order (1, 2, 3).Data arrives whenever (3, 1, 2).
SpeedSlower (due to error checking).Much faster (no overhead).

When to Use What (With Real-World Examples)

Use TCP when accuracy is everything

You use TCP when losing even a tiny bit of data would break the entire thing.

  • Web Browsing (HTTP/HTTPS): You don't want half an image or missing text on a page.

  • Email (SMTP/IMAP): An email with missing words is useless.

  • File Downloads (FTP): If one "bit" is missing, the file is corrupted and won't open.

Use UDP when speed is everything

You use UDP when "real-time" is more important than "perfect quality."

  • Video Calls (Zoom/Teams): If the internet glitches, it's better to have a tiny skip in the video than to pause the whole call to "re-download" a frame from three seconds ago.

  • Online Gaming: You need to know where the enemy is now, not where they were half a second ago.

  • Live Streaming: Speed is king to keep the broadcast live.

What is HTTP and Where Does It Fit?

A common point of confusion for beginners is: "Is HTTP the same as TCP?" The answer is No. They live on different "layers" of the internet.

  • TCP is the Transport Layer: It handles the physical movement of data and ensures it gets there safely.

  • HTTP is the Application Layer: It defines what the message says (e.g., "Give me the homepage of Google").

The Layering Relationship

HTTP doesn't replace TCP; it runs on top of it. Imagine HTTP is the letter you wrote, and TCP is the envelope and the postal service. The letter (HTTP) relies on the postal service (TCP) to be delivered correctly.

Why does HTTP use TCP?

Websites are complex. To load a page, your browser needs every line of code and every pixel of the logo to be perfect. Because HTTP requires 100% accuracy, it almost always chooses TCP as its "shipping method."

Summary

  • TCP is for when you need it done right.

  • UDP is for when you need it done fast.

  • HTTP is the language your browser speaks, and it uses TCP to make sure that language is heard clearly without any missing words.

]]><![CDATA[Getting Started with cURL]]>https://blog.subhajitbag.in/getting-started-with-curlhttps://blog.subhajitbag.in/getting-started-with-curlSat, 31 Jan 2026 17:56:30 GMTImagine you want to order a pizza. You don't just walk into the kitchen; you send a message (your order) to the restaurant's server (the person taking orders). In the digital world, a server is just a powerful computer that "serves" information—like websites, images, or data—when a client (like your browser) asks for it.

Usually, your browser handles this talking for you. But as a programmer, you often need to talk to these servers directly. That is where cURL comes in.

What is cURL? (In Simple Terms)

cURL (which stands for "Client URL") is a command-line tool that lets you send and receive data to and from a server.

Think of it as a browser without the window. Instead of clicking buttons and seeing images, you type a "message" into your terminal, and the server sends a "message" back.

Why Programmers Need cURL

While browsers are great for humans, cURL is great for developers because:

  • It’s fast: You can test a server's response in seconds without loading a whole website.

  • It’s precise: You can see exactly what the server is saying "under the hood."

  • It’s automatable: You can write scripts that use cURL to check if a website is down or to upload files automatically.

Making Your First Request

Open your terminal (Command Prompt on Windows or Terminal on Mac/Linux) and type this simple command:

curl https://www.google.com

What happened? You just told cURL to go to Google's server and ask for the contents of their homepage. The "wall of text" you see appearing is the HTML code that makes up the website. Your browser usually turns that code into a pretty page; cURL shows it to you in its raw form.

Image of client server communication model

Shutterstock

Understanding the Request and Response

Every time you use cURL, a two-way conversation happens:

  1. The Request: This is your message to the server. It includes the URL and the "Method" (how you are asking).

  2. The Response: This is the server's reply. It usually contains:

    • The Data: The HTML, image, or JSON data you asked for.

    • The Status Code: A number that tells you if the request worked. For example, 200 means "OK," while the famous 404 means "Not Found."

Talking to APIs (GET and POST)

When programmers talk to servers to get data (like weather info or stock prices), they use APIs. There are two main ways to send these messages:

1. GET (The "Give Me" Request)

This is the default. You are asking the server to give you information.

curl https://api.github.com/users/octocat

This fetches public data about a specific GitHub user.

2. POST (The "Take This" Request)

This is used when you want to send or create something on the server, like submitting a form or a comment.

curl -X POST https://example.com/login -d "username=user1&password=123"

Note: The -X POST tells cURL the method, and -d stands for the "data" you are sending.

Common Mistakes Beginners Make

  • Forgetting the Protocol: If you type curl google.com instead of curl https://google.com, it might fail or behave unexpectedly. Always include the http:// or https://.

  • Ignoring Status Codes: Beginners often think if they see any text, it worked. Always check if you got a 200 OK or an error code.

  • Getting Overwhelmed by "Flags": cURL has hundreds of options (like -v, -L, -H). Don't try to learn them all at once! Stick to the basics until you're comfortable.

Conclusion

cURL is the universal language for talking to the internet. By mastering just a few simple commands, you gain the power to interact with almost any web service on the planet.

]]><![CDATA[Understanding Network Devices]]>https://blog.subhajitbag.in/understanding-network-deviceshttps://blog.subhajitbag.in/understanding-network-devicesSat, 31 Jan 2026 17:47:45 GMTWhen we are talking about browsing and sending data packets through the internet, we should have knowledge about Networking Devices and how they work. These devices are the silent workers that ensure your "click" reaches a server halfway across the world and returns as a webpage on your screen.

What is a Modem?

A Modem is a networking device that connects your home network to your Internet Service Provider (ISP) by translating signals. The name comes from combining MOdulator and DEModulator.

  • Modulator: When you send data from your computer (like an email), that data is a digital series of 1s and 0s. However, long-distance transmission lines (like cable or phone lines) use analog waves to carry information. The modulator converts digital data into analog signals to travel across the copper or fiber lines to the ISP.

  • Demodulator: When your ISP sends data back to you, it arrives as an analog wave. The demodulator takes that incoming signal and converts it back into digital 1s and 0s that your devices can process.

What is a Router?

While the modem connects you to the outside world, the Router is the "Traffic Police" for your internal network.

  • Responsibility: The modem gives you one single public IP address. The router creates a private network and assigns unique local IP addresses to every device in your house.

  • How it works: When a packet arrives from the modem, the router looks at the destination address and ensures the "Netflix data" goes to your TV and the "Work email" goes to your laptop. It directs traffic between your local network and the internet.

Switch vs. Hub: The Local Network Workers

If you have many wired devices (like a gaming console, a PC, and a smart home hub), you need a way to connect them all.

  • Hub (The Loudspeaker): A hub is an "unintelligent" device. When it receives a data packet, it doesn't know where it's supposed to go, so it broadcasts that packet to every single device connected to it. This creates unnecessary traffic and slows things down.

  • Switch (The Post Office): A switch is smart. It learns the unique ID (MAC address) of every connected device. When a packet comes in, it sends it only to the specific device that needs it, keeping the network fast and efficient.

Firewall: The Security Gate

A Firewall is your network's first line of defense. It sits between your internal network and the public internet to monitor and filter traffic.

  • Why it exists: It follows a set of security rules. If it sees an unauthorized person trying to access your computer or a suspicious program trying to send data out, it blocks the connection.

  • Analogy: It’s like a security guard at a gated community who only lets in people on the "approved guest list."

Load Balancer: The Scaling Specialist

For professional websites with millions of users, a single server would crash under the weight. This is where a Load Balancer comes in.

  • How it works: It acts as a "Reverse Traffic Controller." It sits in front of a group of servers and distributes incoming requests evenly across them.

  • Why it's needed: It ensures no single server gets overwhelmed. If one server fails, the load balancer intelligently redirects traffic to the healthy ones, keeping the website online.

Conclusion: The Grand Workflow

In a real-world scenario, your data follows this path:

  1. Modem translates the signal from the ISP.

  2. Firewall checks if the data is safe to enter.

  3. Router decides which specific device gets the data.

  4. Switch sends it through the specific wire to your device.

  5. (On the server-side) A Load Balancer ensures your request is handled by an available server.

]]><![CDATA[Tracing the Path: How DNS Resolution Works Under the Hood]]>https://blog.subhajitbag.in/tracing-the-path-how-dns-resolution-works-under-the-hoodhttps://blog.subhajitbag.in/tracing-the-path-how-dns-resolution-works-under-the-hoodFri, 30 Jan 2026 13:57:47 GMTWhen you type google.com into your browser, a complex chain of events happens in milliseconds. This process is called DNS Name Resolution. Because humans prefer names and computers prefer numbers (IP addresses), we need a "phonebook" to translate them.

While your browser does this automatically, engineers use a powerful command-line tool called dig (Domain Information Groper) to inspect exactly how this lookup happens at every layer.

What is the dig Command?

dig is a network administration tool used for querying DNS name servers. It is the gold standard for troubleshooting DNS issues because it provides detailed information about how a domain is being resolved. Unlike simpler tools, dig shows you the raw answers directly from the name servers.

To understand the full flow, we can use dig to mimic the "recursive" lookup process that happens behind the scenes.

Layer 1: The Root Name Servers (dig . NS)

The resolution process always starts at the very top of the hierarchy: the Root. There are 13 logical root servers worldwide.

To see who they are, run:

dig . NS

  • What this does: It asks for the NS (Name Server) records of the root (represented by a single dot .).

  • The Result: You get a list of servers (like a.root-servers.net). These servers don't know where google.com is, but they know exactly where to find the servers for .com.

Layer 2: The TLD Name Servers (dig com NS)

Once the root server points us in the right direction, we move to the Top-Level Domain (TLD) layer. This is where domains like .com, .org, and .net are managed.

To find the managers of the .com registry, run:

dig com NS

  • What this does: It queries the root servers for the name servers responsible for all .com addresses.

  • The Result: You’ll see names like a.gtld-servers.net. These servers still don't have Google’s IP address, but they know who owns the specific record for google.com.

Layer 3: The Authoritative Name Servers (dig google.com NS)

Now we reach the final "source of truth." These are the Authoritative Name Servers. They are owned by the domain owner (Google) or their DNS provider.

To see Google's own servers, run:

dig google.com NS

  • What this does: It finds the specific servers that have the master record for Google.

  • The Result: You get servers like ns1.google.com. These are the only servers that can give you the "Authoritative Answer."

Layer 4: The Final IP Address (dig google.com)

Finally, we ask the authoritative server for the actual address where the website lives.

Run the standard query:

dig google.com
  • The Answer Section: This is the most important part of the output. It returns the A record (e.g., 142.250.190.46).

Putting it Together: The Recursive Resolver

In the real world, your computer doesn't run these four commands. Instead, it asks a Recursive Resolver (like your ISP or 8.8.8.8).

The resolver does the heavy lifting: it talks to the Root, then the TLD, then the Authoritative server on your behalf, caches the result, and hands your browser the final IP. Using dig allows you to "see" these invisible steps.

Summary

  • dig . NS: Finds the Root.

  • dig com NS: Finds the TLD (registry).

  • dig google.com NS: Finds the Authoritative source.

  • dig google.com: Gets the final IP address.

By understanding this layered approach, you can pinpoint exactly where a DNS failure is happening—whether it's a domain registration issue (TLD) or a server configuration error (Authoritative).

]]><![CDATA[DNS Record Types Explained]]>https://blog.subhajitbag.in/dns-record-types-explainedhttps://blog.subhajitbag.in/dns-record-types-explainedFri, 30 Jan 2026 13:03:24 GMTDNS (Domain Name System) is the internet’s phonebook, translating human-readable names (example.com) into machine-readable IP addresses (192.0.2.1192.0 .2 .1192.0.2.1). DNS records are essential instructions stored in zone files that tell browsers where to find websites, direct email traffic, and verify ownership.Key records include NS (who controls the domain), A/AAAA (domain-to-IP mapping), CNAME (aliases), and TXT (verification).

Why DNS Records Are Needed

Without these records, you would have to memorize complex strings of numbers for every site you visit. DNS records provide a structured way to map your domain to various services like web hosting, email, and security verification.

1. NS Record (Name Server)

The Responsibility Pointer: An NS Record tells the internet which DNS server is "in charge" of your domain.

  • Analogy: If you want to find someone in a large building, the NS record is the receptionist who tells you which directory to look at.

2. A and AAAA Records

The Home Address: These records map your domain directly to a server's IP address.

  • A Record: Maps a domain to an IPv4 address (e.g., 192.0.2.1).

  • AAAA Record: Maps a domain to the newer, longer IPv6 address.

  • Analogy: This is the physical street address of your website's "house."

3. CNAME Record (Canonical Name)

The Alias: A CNAME points one domain name to another instead of an IP.

4. MX Record (Mail Exchanger)

The Post Office: The MX Record tells the internet where to send your emails.

  • Problem it solves: Without this, emails sent to hello@mysite.com wouldn't know which mail server to enter.

  • Analogy: This is like the postal service's delivery instructions for your business's mailroom.

5. TXT Record (Text)

The Note: A TXT Record holds text information for outside services.

  • Use Case: It’s commonly used to verify you own the domain (for Google or Microsoft) or to set up email security (SPF/DKIM) to prevent spam.

  • Analogy: A note taped to your door providing a verification code for a delivery driver.

How They All Work Together

Imagine setting up a small business website. Your DNS setup might look like this:

  • NS: Points to your provider (e.g., Cloudflare or GoDaddy).

  • A: Points mysite.com to your web host's IP.

  • CNAME: Points www.mysite.com to mysite.com.

  • MX: Points to your email provider (e.g., Gmail).

  • TXT: A code to verify you own the site for search engines.

Summary

DNS records are the unsung heroes of your online presence. Each record handles a specific "department"—A for the website, MX for email, and TXT for security. Once they are all set, your domain becomes a fully functional digital hub.

]]><![CDATA[Inside Git: How It Works and the Role of the .git Folder]]>https://blog.subhajitbag.in/inside-git-how-it-works-and-the-role-of-the-git-folderhttps://blog.subhajitbag.in/inside-git-how-it-works-and-the-role-of-the-git-folderFri, 30 Jan 2026 12:39:57 GMTYou've learned the essential Git commands like git add and git commit, but have you ever wondered what magic happens when you type them? Git isn't just a clever file copier; it's a sophisticated content tracker.

Understanding Git's internal mechanics will transform your understanding from simply using Git to truly mastering it. Let's dive into the .git folder and explore the core components that make version control possible.

Understanding the .git Folder: The Heart of Your Repository

When you run git init in a directory, Git creates a hidden .git folder. This isn't just some metadata; it's the entire Git repository. It contains every piece of information Git needs to track your project's history, perform operations, and maintain its integrity. Without this folder, your project is just a regular directory of files.

Inside .git, you'll find several crucial subdirectories and files:

  • objects/: This is where Git stores all your content—your files, directories, and commit history—in a highly efficient and unique format.

  • refs/: Contains pointers (references) to commits, such as branches (heads) and tags.

  • HEAD: A special pointer that indicates which branch you are currently on.

  • index: Also known as the "staging area," this file records the content of your working directory that will go into the next commit.

Git Objects: The Building Blocks of Your Project

Git stores everything as one of four core "objects," each identified by a unique SHA-1 hash (a 40-character hexadecimal string). These hashes are crucial for Git's integrity; if even one bit of content changes, its hash changes, meaning Git knows it's a different object.

  1. Blob (Binary Large OBject):

    • What it is: A blob object simply stores the content of a file. It doesn't contain the filename or any directory structure. If two files have identical content, Git stores only one blob and points to it twice.

    • Analogy: Think of it as the raw data of your text file, image, or any other file.

  2. Tree:

    • What it is: A tree object represents a directory. It contains a list of other tree objects (subdirectories) and blob objects (files), along with their filenames, permissions, and hashes.

    • Analogy: This is like a snapshot of a folder's contents, showing which files are inside and which subfolders exist.

  3. Commit:

    • What it is: A commit object holds metadata about a specific point in your project's history. It includes:

      • A pointer to the top-level tree object for that commit (the entire project state).

      • Pointers to its parent commit(s) (showing its history).

      • Author and committer information.

      • Timestamp.

      • The commit message.

    • Analogy: A commit is the complete "snapshot" of your project at a moment in time, along with who took the picture and why.

How Git Tracks Changes: git add and git commit Internally

Let's trace the journey of your code when you use the two most common Git commands:

1. git add <file>: Preparing Your Snapshot

When you run git add index.html:

  1. Git takes the current content of index.html.

  2. It calculates a SHA-1 hash for this content.

  3. If a blob object with this content/hash doesn't already exist, Git compresses the content and stores it as a blob object in the .git/objects/ directory.

  4. Git updates the staging area (the index file in .git) to record that index.html (with its specific blob hash) is ready for the next commit.

2. git commit -m "My commit message": Saving Your History

When you run git commit:

  1. Git looks at the staging area (.git/index) to see which file contents (blob hashes) are prepared.

  2. It then constructs tree objects:

    • It creates a tree object for each subdirectory, linking to their respective blobs and subtrees.

    • Finally, it creates a top-level tree object that represents the entire project's directory structure and file contents as they are in the staging area. All these tree objects are stored in .git/objects/.

  3. Git creates a commit object:

    • It points to the top-level tree object.

    • It records the previous commit's hash as its parent.

    • It adds your author, timestamp, and commit message.

    • This commit object is also stored in .git/objects/.

  4. Finally, Git updates the branch pointer (e.g., HEAD or refs/heads/main) to point to this new commit object.

This meticulous process ensures that every commit is a complete, immutable snapshot of your project, linked to its parents to form a continuous history.

The Power of Hashes: Integrity and Immutability

Git's reliance on SHA-1 hashes for every object is fundamental to its robustness:

  • Content Addressable: Git doesn't store files by name; it stores them by their content's hash. This means if you have the hash, you can retrieve the exact content.

  • Data Integrity: Because the hash is derived from the content, any accidental or malicious alteration of a file or commit would immediately change its hash. Git would detect this discrepancy, guaranteeing the integrity of your history.

  • Efficiency: If you commit the same file content multiple times, Git only stores the blob once, saving space.

By understanding these internal mechanisms, you gain a powerful mental model of how Git works, helping you troubleshoot issues, understand branching, and appreciate the genius behind this essential tool.

]]><![CDATA[Why Version Control Exists: The Pendrive Era of Software Development]]>https://blog.subhajitbag.in/why-version-control-exists-the-pendrive-era-of-software-developmenthttps://blog.subhajitbag.in/why-version-control-exists-the-pendrive-era-of-software-developmentFri, 30 Jan 2026 12:16:05 GMTBefore Git, GitHub, and modern collaboration tools, software development looked very different. If you’ve ever seen folders named final, final_v2, or latest_final_really_this_time, congratulations—you’ve already lived through a version-control nightmare.

Let’s rewind a bit and understand why version control exists, using a very real and painful analogy: the pendrive era.

The "Pendrive Analogy" in Software Development

Imagine a small team of developers working on the same project. In the not-so-distant past, their "version control system" might have looked something like this:

  • The Shared Pendrive: One developer codes for a few hours, saves the work to a pendrive, then physically hands it to another. The next person copies the files, adds their code, and passes it back.

  • The "Final" Folder Dilemma: On their local machines, they'd create nested folders like Project/, Project_final/, and Project_final_v2_NEW/.

  • Emailing Code: If they weren't in the same room, they would email .zip files back and forth, praying they were looking at the most "latest" version.

Problems Faced Before Version Control Systems

The "pendrive" approach led to a nightmare of inefficiencies. Without a central system to manage code, teams faced three major, project-killing issues:

  1. Overwriting Code: This was the "silent killer." If two developers worked on the same index.html file at the same time, whoever saved their version to the pendrive last would completely wipe out the other person's work. There was no way to "merge" the two different sets of changes automatically.

  2. Losing Changes: A corrupt pendrive, a crashed hard drive, or accidentally deleting the wrong final_v2 folder meant hours or weeks of work vanishing forever. Without a remote backup or history, there was no way to recover what was lost.

  3. No Collaboration History: If a bug appeared, it was impossible to know who introduced it, when it happened, or why. There was no record just a collection of files with no context.

Why Version Control Became Mandatory

The chaos of the "pendrive era" made two things clear: software development needed a system that offered collaboration, history, and safety.

Version control systems provide:

  • A Single Source of Truth: A central repository (like GitHub) stores the definitive history of the codebase.

  • History and Accountability: Every change is tracked, allowing teams to roll back errors, debug issues efficiently, and understand the context behind decisions.

  • Seamless Collaboration: Developers can work in parallel on different features without fear of overwriting each other's work, thanks to branching and merging capabilities.

Conclusion: Moving Forward

The "pendrive era" wasn't just slow—it was risky. Every hour spent manually merging files was an hour taken away from actual coding.

By using Version Control, you replace that chaos with a safety net. You gain the freedom to experiment, the security of a full history, and the ability to collaborate without fear. If you haven't yet, now is the perfect time to leave the "final_v2" folders behind and embrace the power of Git.

]]><![CDATA[Git for Beginners: Basics and Essential Commands]]>https://blog.subhajitbag.in/git-for-beginners-basics-and-essential-commandshttps://blog.subhajitbag.in/git-for-beginners-basics-and-essential-commandsFri, 30 Jan 2026 11:40:52 GMTToday, Git is one of the most essential tools for developers. Git helps you track changes, manage code, and collaborate efficiently, whether you are working alone or in a team. This blog will walk you through what Git is, why it’s used, its core concepts, and the most common commands—step by step.

What is Git?

Git is an open-source version control system that acts like a "Time Machine" for your project.

In simple terms, it tracks every change you make to your source code, allowing you to revert to previous versions if something breaks. Unlike older systems that rely on a central server, Git is distributed—meaning every developer has a complete copy of the project's entire history on their local computer. This makes it incredibly fast, reliable for offline work, and ensures that multiple people can collaborate on the same files simultaneously without accidentally overwriting each other's work.

Why Git is Used

Git is the industry standard for three major reasons:

  • Tracking Changes: Git keeps a granular history of every line of code you modify. If a bug appears, you can "travel back in time" to see exactly when and where the logic changed.

  • Seamless Collaboration: Git allows multiple developers to work on the same codebase simultaneously. It uses a "merge" system to combine everyone's work, ensuring that your teammate's new feature doesn't accidentally overwrite your bug fix.

  • Experimentation: You can create "branches" to try out risky new ideas. If the experiment fails, you simply delete the branch; your main project remains untouched and "clean."

Git Basics and Core Terminologies

Before jumping into commands, you need to understand the "Big Four" concepts:

  • Repository (Repo): A folder where Git tracks all the changes. It’s the "project container."

  • Commit: A snapshot of your files at a specific point in time. Think of it as a permanent record in the project's history.

  • Branch: A parallel version of your repository. It allows you to develop features without affecting the main code.

  • HEAD: A pointer that tells Git which branch or commit you are currently looking at.

The Three Stages of Git

Understanding how Git moves files is crucial. Files exist in one of three states:

  1. Working Directory: Where you are currently editing files.

  2. Staging Area (Index): A "prep zone" where you pick which changes you want to include in your next snapshot.

  3. Local Repository: Where Git permanently stores the snapshots (commits).

Common Git Commands and

Let's put these concepts into practice with essential commands.

Initialization and Setup

  1. git init: Initializes a new Git repository in your current directory. A hidden .git folder is created to store all history.

     git init

The Basic Workflow

  1. git status: Checks the state of your working directory and staging area. It tells you which files are modified, which are staged, and which are untracked. Run this frequently!

     git status

  2. git add <file>: Adds a specific file (or use git add . for all files) from your working directory to the staging area.bash

     git add index.html
 # or to add all changes:
 git add .

  3. git commit -m "message": Records the staged changes as a new commit in the local repository. The -m flag lets you attach a descriptive message.bash

     git commit -m "Add initial HTML structure for homepage"

Viewing History

  1. git log: Displays a log of all previous commits in the current branch. You can see who committed what, when, and their message.

     git log

Wrapping Up: Your Journey with Git

Git is more than just a tool; it’s a safety net that gives you the confidence to experiment and build complex projects. While the command line might feel intimidating at first, these five basic commands—init, status, add, commit, and log—will handle 90% of your daily work.

]]>