Forem: Gaurav Dalvi

Git Hooks — The Developer's Silent Sidekick

Gaurav Dalvi — Fri, 18 Apr 2025 13:00:00 +0000

You know that gut-punch feeling when you push broken code, forget to run tests, or write a commit message so vague it could be the title of a Christopher Nolan film?

Yep. Been there, done that.

But what if I told you Git can automate that slap-on-the-wrist your tech lead usually gives you during code review?

Meet Git Hooks — your silent sidekick for clean commits, consistent messages, and fewer "oops" moments.

💡 What Are Git Hooks?

Git hooks are executable scripts that Git runs before or after certain events like commits, pushes, merges, rebases, and more. Think of them as little robot assistants standing guard over your version control flow.

They live in this path (by default):

.git/hooks/

...and are disabled until you make them executable and give them real jobs.

🦸‍♂️ Why Should You Care?

Let’s be honest: we're all human.

We forget to run tests.

We commit debug.log.

We write commit messages like fix stuff.

Git hooks automate the "are-you-sure" part of development — catching mistakes before they hit the repo.

Now, let me show you the ones you're actually likely to use in real life — the ones that save developers from daily embarrassment.

💡 `pre-commit` — Stop Bad Code Before It Happens

When it runs: Before a commit is finalized.

Why it's useful:
Block broken, unformatted, or careless code from entering your repo. Consider this your first line of defense.

Example: Lint your code before committing

#!/bin/sh
echo "Linting your code..."
npm run lint
if [ $? -ne 0 ]; then
  echo "❌ Linting failed! Fix errors before committing."
  exit 1
fi

📌 Save this in .git/hooks/pre-commit and make it executable:

chmod +x .git/hooks/pre-commit

💡 `commit-msg` — Enforce Commit Message Discipline

When it runs: After you write your commit message, before the commit is saved.

Why it's useful:
Protects your repo from cryptic, non-informative commit messages like:

misc changes

Example: Enforce Conventional Commits

#!/bin/sh

message=$(cat "$1")
pattern="^(feat|fix|chore|docs|style|refactor|test|perf|ci|build|revert)(\(.+\))?: .{1,50}"

if ! echo "$message" | grep -qE "$pattern"; then
  echo "❌ Invalid commit message!"
  echo "✅ Format should be: feat(scope): description"
  exit 1
fi

💡 `pre-push` — The Final Defense Line

When it runs: Before your code is pushed to the remote.

Why it's useful:
Ensure tests pass or builds are successful before anyone else gets your code.

Example: Run tests before push

#!/bin/sh

echo "Running tests before push..."
npm test
if [ $? -ne 0 ]; then
  echo "❌ Tests failed! Push aborted."
  exit 1
fi

💡 `post-merge` — Sync After Merging

When it runs: After a git merge completes.

Why it's useful:
Prevent those "works on my machine" moments after pulling changes that added new dependencies.

Example: Auto-install dependencies if package.json changed

#!/bin/sh

if git diff-tree -r --name-only --no-commit-id ORIG_HEAD HEAD | grep -q "package.json"; then
  echo "package.json changed — running npm install..."
  npm install
fi

💡 `post-checkout` — Welcome to Your New Branch

When it runs: Every time you checkout a branch or commit.

Why it's useful:
Automatically reset environment configs or remind yourself which branch you're on.

Example: Notify current branch

#!/bin/sh

branch=$(git rev-parse --abbrev-ref HEAD)
echo "✅ You're now on branch: $branch"

📚 Other Git Hooks You Should Know (But Use When Needed)

Hook Name	Purpose & When It Runs
`applypatch-msg`	Before applying a patch with `git am`. Validate commit messages in patches.
`pre-applypatch`	Before a patch is applied. Often used for prep steps.
`post-applypatch`	After a patch is applied. Good for notifications or rebuilds.
`prepare-commit-msg`	Modify auto-generated commit messages (e.g., squash, merge templates).
`post-commit`	After a commit completes. Log events or trigger notifications.
`pre-rebase`	Before a rebase starts. Block protected branches or warn users.
`pre-merge-commit`	Before a merge commit is created. Validate merge intentions.
`pre-auto-gc`	Before Git performs automatic garbage collection.
`post-rewrite`	After rewriting commits via rebase or amend. Useful for cleanup.

🔗 How to Share Hooks Across Teams?

Git doesn’t track .git/hooks (by design) — so if you want team-wide consistency, you have two main solutions:

1. Husky

Perfect for JavaScript/TypeScript projects.
Hooks are stored inside your version-controlled codebase.
Easy to set up with npx husky install.

2. Lefthook

Language-agnostic.
Great for teams working across different stacks.
Centralizes hooks under version control.

💡 Final Thoughts

Git Hooks won't write better code for you — but they will:

Save you from human error.
Make you look like the professional you pretend to be on LinkedIn.
Keep your team's history clean and consistent.

Start simple:

pre-commit for code quality.
commit-msg for consistent commit messages.
pre-push for last-minute sanity checks.

And watch how your workflow instantly levels up.

Essential Linux Commands Every Developer Should Master

Gaurav Dalvi — Thu, 17 Apr 2025 13:00:00 +0000

Let’s face it: if you're writing code and not using Linux (or at least the terminal), you’re missing out on half the developer experience — the half where you actually feel like a hacker from a ‘90s movie.

Whether you’re deploying, debugging, or just flexing in front of your coworkers, these Linux commands are essential tools in your utility belt.

🧠 pwd — Print Working Directory

Translation: “Where the heck am I?”

pwd

This one tells you your current location in the filesystem jungle. Like GPS, but for your terminal.

📂 ls — List Directory Contents

Translation: “Show me what’s in this folder.”

ls
ls -la

Add -l for detailed info and -a to uncover hidden treasures (.env, .git, .Iforgotaboutthis).

🚪 cd — Change Directory

Translation: “Get me out of here.”

cd /path/to/destination
cd ~  # Go to home
cd -  # Go back

Essential for moving around like a pro instead of exiting the terminal and opening File Explorer like a peasant.

🔥 rm — Remove Files or Directories

Translation: “Delete like you mean it.”

rm file.txt
rm -r folder/
rm -rf /  # Don’t. Ever.

The -r flag removes folders recursively. -f makes it ruthless. Combining both is like giving your terminal a bazooka.

🧹 mkdir & rmdir — Make / Remove Directory

mkdir new_folder
rmdir old_folder

Simple yet essential. mkdir -p even creates nested directories like a boss:

mkdir -p projects/nextjs/my-awesome-app

📝 touch — Create an Empty File

touch newfile.txt

No need to open VS Code just to create a file. touch and go!

🔍 grep — Search Through Files

Translation: “Ctrl + F for the terminal.”

grep 'TODO' *.js

Search for specific text patterns. Super useful when your codebase has more bugs than features.

🪓 chmod — Change File Permissions

chmod +x script.sh

Grants execution rights. Because not all heroes wear capes; some just need the right permissions.

🏃 ./ — Run Executables

./myscript.sh

If you wrote a script but the terminal says “permission denied,” check your chmod (see above). Once executable, this is how you run it.

🦸 sudo — SuperUser Do

Translation: “I know what I’m doing... probably.”

sudo apt-get update

Gives you superpowers. Use wisely, or you might brick your OS and end up spending the weekend reinstalling Linux.

🌐 curl — Transfer Data from URLs

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

Download files, test APIs, or pretend you're working on your terminal when you're actually sending cat GIFs.

💣 kill & killall — Stop Processes

kill <PID>
killall node

When Ctrl + C just isn’t enough, kill is the polite way to ask processes to die. killall... well, does what the name says.

🧪 top / htop — Monitor Processes

top
htop

Real-time view of CPU and memory usage. htop is the cool, colorful cousin of top. Install it, thank me later.

📦 tar — Archive and Extract Files

tar -czvf archive.tar.gz folder/
tar -xzvf archive.tar.gz

Because zipping and unzipping files shouldn’t require dragging anything.

🧾 man — Manual Pages

man ls

Lost? Confused? Broken? Type man + command and let the terminal's ancient wisdom guide you.

💡 Final Thoughts

Learning Linux commands is like learning to cook. At first, you’ll burn a lot of files (rm -rf) and confuse cd with mkdir, but once you’re comfortable, you’ll be able to whip up deployments, debug servers, and automate tasks like a chef plating Michelin-star code.

So, stop Googling “How to delete file Linux” and start memorizing the essentials.

Write Code Like A Pro: Mastering The SOLID Principles

Gaurav Dalvi — Wed, 16 Apr 2025 13:00:00 +0000

If you're a developer, you've probably heard whispers of this ancient wisdom in code reviews, design docs, or the hushed conversations between two senior devs in the corner of your office:

"You should follow SOLID principles."

But what exactly are these? Some kind of secret cult? A new JavaScript framework? Fear not — SOLID is simply an acronym, and one of the best blueprints for writing maintainable, scalable, and... non-disaster-prone code.

Let’s break it down, with some real-world humor sprinkled in.

🧠 S — Single Responsibility Principle (SRP)

"One class, one reason to change."

Real-world analogy:
Imagine you hired a plumber to fix your sink, and halfway through the job, he starts giving you a lecture on tax planning. That’s what violating SRP feels like in code.

Code example:

Bad:

class UserManager {
    public void createUser() { /* ... */ }
    public void deleteUser() { /* ... */ }
    public void generateUserReport() { /* ... */ } // 🚨 Mixing concerns!
}

Good:

class UserManager {
    public void createUser() { /* ... */ }
    public void deleteUser() { /* ... */ }
}

class UserReportGenerator {
    public void generateUserReport() { /* ... */ }
}

Each class now does one job. Fewer surprise side effects, fewer headaches.

🧠 O — Open/Closed Principle (OCP)

"Software entities should be open for extension, but closed for modification."

Real-world analogy:
When your phone gets a new feature, you install an app. You don’t break out a screwdriver and start rewiring the motherboard. Your code should work the same way.

Code example:

Bad:

class NotificationService {
    public void send(String message, String type) {
        if (type.equals("Email")) { /* send email */ }
        else if (type.equals("SMS")) { /* send SMS */ }
    }
}

Good:

interface NotificationSender {
    void send(String message);
}

class EmailSender implements NotificationSender {
    public void send(String message) { /* send email */ }
}

class SMSSender implements NotificationSender {
    public void send(String message) { /* send SMS */ }
}

class NotificationService {
    private NotificationSender sender;

    public NotificationService(NotificationSender sender) {
        this.sender = sender;
    }

    public void notify(String message) {
        sender.send(message);
    }
}

New types? Just add a new class. Your core logic stays untouched, stress levels stay low.

🧠 L — Liskov Substitution Principle (LSP)

"Objects of a superclass should be replaceable with objects of its subclasses without affecting correctness."

Real-world analogy:
If you rent a car, you expect to drive it — whether it’s a sedan, SUV, or convertible. If the rental company handed you a boat with wheels, you'd be furious.

Code example:

Bad:

class Bird {
    public void fly() { /* flying logic */ }
}

class Penguin extends Bird {
    public void fly() { 
        throw new UnsupportedOperationException("Penguins can't fly!");
    }
}

Better:

interface Bird {
    void eat();
}

interface FlyingBird extends Bird {
    void fly();
}

class Sparrow implements FlyingBird {
    public void eat() { /* eat */ }
    public void fly() { /* fly */ }
}

class Penguin implements Bird {
    public void eat() { /* eat */ }
}

Now penguins aren’t pretending to be something they’re not. Less deception, fewer exceptions.

🧠 I — Interface Segregation Principle (ISP)

"No client should be forced to depend on methods it does not use."

Real-world analogy:
Ordering a coffee and getting a full 10-course meal, whether you asked for it or not.

Code example:

Bad:

interface Worker {
    void work();
    void eat();
}

class Robot implements Worker {
    public void work() { /* working... */ }
    public void eat() { /* ??? Robots don't eat! */ }
}

Better:

interface Workable {
    void work();
}

interface Eatable {
    void eat();
}

class Human implements Workable, Eatable {
    public void work() { /* work */ }
    public void eat() { /* eat */ }
}

class Robot implements Workable {
    public void work() { /* work */ }
}

Now each class only implements what it actually needs. Simple. Clean. Logical.

🧠 D — Dependency Inversion Principle (DIP)

"Depend on abstractions, not on concretions."

Real-world analogy:
If your smartphone was hard-wired to only work with one charger brand, you’d riot. Thankfully, it uses USB or wireless — an abstraction.

Code example:

Bad:

class MySQLDatabase {
    public void connect() { /* ... */ }
}

class UserRepository {
    private MySQLDatabase db = new MySQLDatabase();

    public void saveUser() { db.connect(); /* save logic */ }
}

Good:

interface Database {
    void connect();
}

class MySQLDatabase implements Database {
    public void connect() { /* ... */ }
}

class UserRepository {
    private Database db;

    public UserRepository(Database db) {
        this.db = db;
    }

    public void saveUser() { db.connect(); /* save logic */ }
}

Now you can swap databases like changing socks. Dependency injection = freedom.

💡 Wrapping Up

SOLID principles are like traffic rules for your code. They won’t stop you from writing spaghetti, but they’ll give you the map to a much safer, maintainable, and scalable design.

If you start noticing that:

your classes are doing too many things,
adding a new feature breaks four others,
or your code makes you want to fake your own death and start a new identity...

...chances are, you're breaking one (or more) SOLID principles.

Stick to them and your future self — and your teammates — will silently thank you.

Microservices: Because Monoliths Are So 2009

Gaurav Dalvi — Tue, 15 Apr 2025 13:00:00 +0000

If you’ve ever stared at a 10,000-line App.java file and whispered to yourself, “There has to be a better way…” — congratulations, you’ve unlocked the microservices chapter of your developer journey.

Welcome to the distributed spaghetti buffet 🍝 — where every service is its own restaurant, with its own chef, ingredients, and occasionally, its own plumbing problems.

Let’s dig into microservices: why they exist, how to not mess them up, and what they don’t tell you in the Netflix tech blog.

🧐 Why Microservices?

Because "it worked on my machine" doesn't scale.

Microservices break your application into independently deployable, loosely coupled services — each responsible for a specific piece of functionality. Think: auth service, order service, notification service, and maybe that one weird analytics service you inherited from an intern in 2018. Yes, it still works. No one knows how.

In theory, this means:

Smaller codebases = easier to understand and test.
Teams can work in parallel.
You can deploy just what changed.
Tech stack freedom per service.

In practice, this means:

You’ve got 15 Git repos, 17 CI/CD pipelines, and 25 different opinions on which API gateway to use.

🧩 Design Principles: Or How to Avoid a Distributed Disaster

1. Single Responsibility, Not Single Line of Code

Every microservice should have a single business capability. If your “user-service” also handles emails, payments, and the office coffee machine, you’re doing it wrong. That’s not a service — it’s a Frankenstein.

2. Data Isolation: No Peeking!

Each service should own its own data. Yes, it feels wasteful to duplicate some data. Yes, it leads to eventual consistency. But it also avoids the “why did deleting a user break inventory?” conversations.

Pro tip: Embrace the chaos. Eventual consistency is a feature, not a bug. Just like Kubernetes.

3. Communication: Choose Your Weapons Wisely

Synchronous (REST, gRPC): Easy, familiar, but brittle. Asynchronous (Kafka, RabbitMQ): Resilient, scalable, but welcome to the debugging dark forest.

Use sync when you need immediate response. Use async when you want to sleep at night.

🛠️ Tooling You’ll Actually Use

API Gateway – NGINX, Kong, or just a tired Node.js app pretending it’s not a monolith.
Service Discovery – Consul, Eureka, or writing service names on Post-its and hoping for the best.
Observability – Jaeger + Prometheus + Grafana. Or just a lot of console.log. No judgment.
CI/CD – GitHub Actions, Jenkins, or that one Bash script nobody wants to touch.

🔥 Common Pitfalls (and How to Avoid Them)

1. Too Many Services, Too Soon

Just because you can split everything into services doesn’t mean you should. Start with a modular monolith and break off services when needed. Otherwise, you’ll spend more time wiring things than building features.

2. Distributed Monolith

If your services can’t function independently and deployments must happen in lockstep — congrats, you just recreated a monolith with extra steps.

3. Ignoring Observability

If you don’t know what your services are doing, who they’re talking to, or how they’re failing — you’re driving blindfolded. At night. In production.

💬 Real Talk: Do You Even Need Microservices?

If your team is fewer than 5 devs, your product’s still pivoting, or your infra budget is “whatever’s free on Heroku,” then no — you probably don’t need microservices right now.

Start simple. Scale complexity only when you must. Complexity is a cost — not a badge of honor.

🧠 Final Thoughts: Herding Cats, One Service at a Time

Microservices are not a silver bullet. They’re more like a box of sharp knives — incredibly useful, but also capable of cutting you if you’re not careful.

If done right, they offer scalability, team autonomy, and faster iteration.

If done wrong, well… let’s just say I hope you enjoy reading 400-line stack traces that jump across five services.

Thanks for reading — may your services stay stateless, your queues stay unblocked, and your deployments stay drama-free. 💥

JavaScript’s Event Loop — Explained Like You're Five (But With More Sarcasm)

Gaurav Dalvi — Mon, 14 Apr 2025 13:00:00 +0000

🧠 First, a Little Brain Primer: JavaScript Is Single-Threaded

Imagine JavaScript as a cook in a small kitchen with one burner. That’s right, it can only cook one dish at a time. If you ask it to make toast, brew coffee, and flip pancakes, it has to queue those tasks. Multitasking? Pfft. JavaScript is more of a "brb, doing this one thing first" kinda guy.

But... JavaScript is weirdly fast, and can handle lots of tasks at once — or so it seems. The trick? It's all about asynchronous operations and the event loop.

🏗️ Stack, Queue, and Web APIs — The Cast of Characters

Before we talk about the Event Loop itself, let’s meet the team:

1. Call Stack (a.k.a. “The Do-Right-Now Zone”)

The Call Stack is where functions go to get executed. It’s LIFO (Last In, First Out) — think of it as a stack of pancakes, where the last one you put on is the first one you eat. Yum.

function sayHi() {
  console.log("Hi!");
}
sayHi(); // Goes on the stack, gets executed, gets popped off.

Easy peasy. But what if we add:

setTimeout(() => {
  console.log("Hello after 0ms");
}, 0);

Hold on... 0ms?! That should run immediately, right?

Wrong. This is where Web APIs and the Event Loop pull off their little magic trick.

2. Web APIs (a.k.a. “The Outsourcing Department”)

When you use setTimeout, fetch, or DOM events, you’re not dealing with core JavaScript anymore. These are browser-provided APIs (also available in Node.js through different means). JavaScript offloads tasks to them — like giving your assistant a to-do list and going back to binge Netflix (or run more code).

3. Callback Queue (Task Queue) (a.k.a. “The Waiting Room”)

Once the Web APIs finish their job — say, your timer is up — they dump the callback into the Callback Queue, where it patiently waits to be noticed by the Event Loop like an intern waving for coffee orders.

🔁 Enter the Event Loop

Imagine a tiny robot constantly checking:

“Is the Call Stack empty?”
- ✅ Yes: “Cool, I’ll grab the next thing from the Callback Queue.”
- ❌ No: “I’ll chill for a bit. Let the stack do its thing.”

That’s the Event Loop. It’s a bouncer at an exclusive club (the call stack), letting in callbacks only when there’s room.

🔬 Let’s Visualize It (in Code)

console.log("Start");

setTimeout(() => {
  console.log("Timeout callback");
}, 0);

Promise.resolve().then(() => {
  console.log("Promise microtask");
});

console.log("End");

Output?

Start
End
Promise microtask
Timeout callback

Wait, WHAT? Isn’t 0ms faster than a promise?

Ah, my young padawan, welcome to the dark arts of the Microtask Queue.

⚡ Microtasks vs. Macrotasks: The Plot Thickens

There’s another queue: the Microtask Queue.

Microtasks include: Promise.then, queueMicrotask, and MutationObserver.
Macrotasks (aka regular tasks) include: setTimeout, setInterval, I/O events.

After each turn of the event loop, the engine:

Executes all microtasks 🧠
Then checks the callback queue 🧾

So in our code above:

Stack runs console.log("Start") and "End".
Then microtasks run: "Promise microtask".
THEN the timeout callback: "Timeout callback".

The event loop is like: “Okay, before I do anything else, let me finish these tiny tasks. Then I’ll get to the big stuff.”

💡 So Why Does Any of This Matter?

Because understanding the event loop saves lives (okay, maybe just your sanity). Here’s when it’s crucial:

Preventing UI freezing (e.g. when you block the main thread).
Writing efficient async code.
Debugging weird issues where code doesn’t run in the order you expect.
Avoiding 3 AM existential crises caused by setTimeout(..., 0) not running “immediately.”

🧪 Bonus: Block the Stack and See the Chaos

setTimeout(() => console.log("I'm late!"), 0);

for (let i = 0; i < 1e9; i++) {} // Block the stack

console.log("Done blocking");

Even though the timer says "0ms", it runs after the big loop finishes. Why? Because the call stack was busy — the Event Loop couldn't slip anything in.

🎯 TL;DR (Too Long; Debugged Recently)

JavaScript runs in a single-threaded event loop model.
The Call Stack runs code line by line.
Async tasks go to Web APIs, then to the Callback Queue.
The Event Loop adds them to the stack only when it's empty.
Microtasks (like Promises) get priority over normal tasks.
Blocking the main thread blocks everything — avoid it like pineapple on pizza (unless you're into that).

🧠 Final Thoughts

Understanding the Event Loop is like knowing how the magician pulls off the trick. It doesn’t make the show any less fun — but it does make you better at building the show.

Now go forth and write better asynchronous code — and maybe tell setTimeout to chill once in a while.

How Does the Internet Work? (A.k.a. The Most Epic Game of Digital Hide and Seek)

Gaurav Dalvi — Sun, 13 Apr 2025 15:00:00 +0000

Let’s be honest: the internet feels like magic. You type in “how to cook Maggi in 2 minutes” (even though we all know it takes at least 5), and boom — millions of answers appear instantly. But have you ever stopped mid-scroll and wondered:

How does this wizardry even work?

Don’t worry, I’ve got you covered. By the end of this post, you’ll know how your memes travel across the globe and what’s really happening behind those cat videos buffering.

🧠 Step 1: It All Starts With a Thought

Let’s say you want to visit a website — like blog.gauravdalvi.com. You open your browser and type it in.

You just initiated an epic digital quest.

But your computer doesn’t actually know what "blog.gauravdalvi.com" is. Computers don’t speak human; they speak IP addresses, which are like phone numbers for websites (but less likely to be saved in your contacts).

🧭 Step 2: DNS – The Internet’s Phone Book (Only Nerdier)

Here’s where the DNS (Domain Name System) jumps in. Think of it like the bouncer outside a club:

“You said blog.gauravdalvi.com? Lemme check the list... Yep! Its IP address is 185.199.108.153. You’re good to go.”

Your browser uses this IP address to find the real server where the blog lives. Without DNS, you'd have to remember numbers like it’s 1998 again. No thanks.

🚀 Step 3: HTTP – The Messenger on a Mission

Once your browser knows the IP, it sends a request — like a digital letter — using a protocol called HTTP or the newer, shinier HTTPS (the 'S' stands for "Secure", or "Stop snooping, Karen").

It’s like saying:

“Hey blog.gauravdalvi.com, can you send me your homepage? kthxbye.”

This request zooms through multiple servers, routers, and switches, crossing cities and sometimes oceans — all in milliseconds.

🖥️ Step 4: Servers – The Internet’s Kitchens

Now imagine the website you’re trying to access is a fancy restaurant. The server is the kitchen.

When your request hits the server, it fires up the backend (code, databases, CMSes, and maybe even some tears), processes your request, and sends back the webpage — HTML, CSS, JavaScript, images, and all.

Yes, it’s basically DoorDash, but for data.

🛣️ Step 5: The Internet Highway – How the Data Travels

This part is wild.

Your request and the server’s response travel through a global network of cables — including undersea fiber-optic cables stretching across continents. Think about it:

That dog meme you liked this morning probably swam through the Atlantic Ocean to get to your phone.

(Okay, not literally, but close enough.)

Routers act like traffic cops, guiding each data packet to its destination via the fastest route. Sometimes, your data takes detours. Sometimes it gets stuck in traffic. Yes, the internet has lag too.

📦 Step 6: Packets – The Data Burritos

Here’s a fun one: the web page isn’t sent all at once. It’s chopped into tiny data packets — like digital burritos wrapped with labels saying, “This is part 4 of 72, don’t lose it.”

These packets fly through the internet and get reassembled on your device faster than you can say “buffering.”

🔄 Step 7: Rendering – Your Browser Gets to Work

Now your browser rolls up its sleeves and gets to work. It takes all those packets, reads the HTML, grabs the CSS to make it look pretty, runs the JavaScript to add interactivity, and voilà:

Your blog loads. 🎉

Unless it doesn't. Then you hit refresh. Or start blaming your Wi-Fi. Or your ISP. Or your router. Or Mercury retrograde. All valid options.

🔐 Bonus: Encryption – Because Privacy Is Kinda Important

If the website uses HTTPS (and it should), all of the above communication is encrypted. Meaning, even if someone tries to eavesdrop mid-journey, all they see is gibberish.

So when you send a password or payment details, it's scrambled like eggs — only the server knows how to unscramble it.

🧩 TL;DR – A Dramatic Recap

You type a URL.
DNS finds the IP address.
Your browser sends a request to that address using HTTP(S).
The server receives it, processes it, and sends back the data.
Data travels through routers, undersea cables, and satellites (sometimes).
Your device gets the data in chunks (packets) and renders the page.
You enjoy your content while occasionally cursing slow internet speeds.

⚡ The Internet Is a Miracle of Coordination

It’s a wild combo of code, hardware, physics, and caffeine that keeps it all running. And now that you know how it works, you’ll appreciate it the next time a video loads without buffering.

Or at least you’ll know who to blame when it doesn’t. 😄

Unlocking the Power of the Console Object: Beyond console.log()

Gaurav Dalvi — Sat, 12 Apr 2025 15:00:00 +0000

The console object is like the Swiss Army knife of debugging—except most developers only use one tool: console.log(). But what if I told you there’s an entire world of powerful methods hidden inside console, waiting to make your debugging experience 10x better? In this guide, we’ll explore the underrated and often ignored features of the console object that will boost your JavaScript debugging skills.

1. `console.table()` – Pretty Print Your Data 📊

Tired of messy arrays and objects cluttering your console? console.table() makes them readable!

const users = [
    { id: 1, name: 'Alice', role: 'Admin' },
    { id: 2, name: 'Bob', role: 'User' },
    { id: 3, name: 'Charlie', role: 'Editor' }
];

console.table(users);

This outputs a neat table instead of an unreadable object dump. Perfect for debugging API responses!

2. `console.warn()` & `console.error()` – Color Code Your Logs ⚠️

If all your logs look the same, debugging becomes a nightmare. Use console.warn() for warnings and console.error() for errors to make important messages stand out.

console.warn('This is a warning!'); // Yellow text
console.error('Something went wrong!'); // Red text

Errors even include a stack trace, helping you track down issues faster!

3. `console.group()` – Organize Logs Like a Pro 📂

Ever wanted to categorize logs into collapsible sections? console.group() and console.groupEnd() let you do just that!

console.group('User Info');
console.log('Name: Alice');
console.log('Role: Admin');
console.groupEnd();

Now, your console stays clean and structured. Nested groups? Also possible! 😎

4. `console.count()` – Track Function Calls 🔢

Need to track how many times a function is executed? console.count() keeps count for you.

function fetchData() {
    console.count('fetchData called');
    // API call simulation
}

fetchData();
fetchData();
fetchData();

This prints:

fetchData called: 1
fetchData called: 2
fetchData called: 3

Super useful for debugging loops and recursive functions!

5. `console.time()` – Measure Performance ⏱️

Performance optimization starts with measuring execution time. console.time() and console.timeEnd() make it easy.

console.time('Loop Timer');

for (let i = 0; i < 1000000; i++) {
    // Some heavy computation
}

console.timeEnd('Loop Timer');

Now you’ll know exactly how long your functions take to run. 🚀

6. `console.trace()` – See the Call Stack 🔍

Need to debug function calls? console.trace() prints a full call stack.

function first() {
    second();
}
function second() {
    third();
}
function third() {
    console.trace('Trace log');
}

first();

Now you can see exactly where your function was called from!

7. `console.assert()` – Conditional Debugging ✅

Instead of manually checking conditions, let console.assert() do the work.

const age = 15;
console.assert(age >= 18, 'User is not an adult!');

If the condition is false, an error message appears. Great for debugging validation logic!

8. `console.dir()` – Inspect Objects in Depth 🔎

When console.log() isn’t enough, console.dir() provides a deeper look at object properties and methods.

console.dir(document.body);

This is especially useful for exploring DOM elements!

9. `console.clear()` – Declutter Your Console 🧹

Want to start fresh? console.clear() wipes your console clean.

console.clear();

Perfect when debugging gets messy!

Final Thoughts 🏁

The console object is far more powerful than just console.log(). By mastering these advanced methods, you can debug faster, write cleaner code, and look like a JavaScript genius in front of your teammates.

Mastering Minikube: A Deep Dive Beyond the Basics

Gaurav Dalvi — Fri, 11 Apr 2025 15:11:46 +0000

Minikube is an awesome tool for running Kubernetes locally, but let's be real—most people just minikube start and call it a day. But there's so much more you can do! In this post, I'm diving into some intermediate-level features and optimizations to help you squeeze every last drop of power out of Minikube.

Advanced Minikube Features You Should Know

1. Choosing the Right Driver for Performance

Minikube supports multiple drivers, and picking the right one can make a huge difference in speed and resource usage.

Docker Driver: The fastest and most efficient choice if you already use Docker.
VirtualBox: Works when Docker isn’t an option, but it’s a bit heavier.
KVM2 (Linux only): Great for speed and isolation.
HyperKit (macOS only): A solid, lightweight option for Mac users.

To set your preferred driver permanently:

minikube config set driver docker

Or just specify it when starting Minikube:

minikube start --driver=docker

2. Running Multiple Clusters Like a Pro

Sometimes, one Minikube instance isn't enough. Need different environments for testing? No problem.

minikube start -p dev-cluster
minikube start -p staging-cluster

Switch between them easily:

kubectl config use-context minikube-dev-cluster

Shut down or delete specific clusters:

minikube stop -p dev-cluster
minikube delete -p staging-cluster

3. Give It More Juice: Resource Allocation

Minikube starts with minimal resources, which is fine for small tests but not great for serious work. Bump it up with:

minikube start --memory=4g --cpus=2

Check if it's struggling:

minikube status

4. Supercharging Minikube with Addons

Minikube comes with built-in addons that can make your life easier.

metrics-server: Enables Kubernetes Metrics API (handy for kubectl top commands).
ingress: Enables Ingress Controller for routing (because nobody wants to keep using kubectl port-forward).
dashboard: Gives you a web UI to manage your cluster.

To enable an addon:

minikube addons enable metrics-server

List all available addons:

minikube addons list

5. Keeping Data Persistent (So It Doesn't Vanish on Restart)

By default, Minikube wipes everything when restarted. If you need persistent storage:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

Apply it:

kubectl apply -f pvc.yaml

Check if it's working:

kubectl get pvc

6. Making LoadBalancers Work Locally

Minikube doesn’t support external LoadBalancers like a cloud provider would, but there's a hack for that:

kubectl expose deployment my-app --type=LoadBalancer --port=80
minikube tunnel

Now, it assigns an external IP, making it act like a real LoadBalancer!

7. Using Profiles for Different Configurations

Profiles let you create different Minikube setups for different projects.

minikube start -p dev --cpus=2 --memory=4g
minikube start -p staging --cpus=4 --memory=8g

Switch between them with:

minikube profile list
minikube profile use dev

8. Building Docker Images Inside Minikube

Minikube doesn't use your local Docker daemon by default. If you don’t want to push images to Docker Hub just to test them, use this trick:

eval $(minikube docker-env)
docker build -t my-app:v1 .
kubectl apply -f deployment.yaml

Now your image is available inside Minikube without any extra hassle!

Wrapping Up

Minikube is more than just a local Kubernetes playground—it can be a powerful testing and development tool if used right. By leveraging multi-cluster management, persistent storage, optimized resource allocation, and built-in addons, you can make Minikube feel almost like a production cluster (well, almost).

What is Webpack?

Gaurav Dalvi — Fri, 11 Apr 2025 15:09:30 +0000

Alright, let’s talk about Webpack—because chances are, you’ve heard of it but might still be wondering what exactly it does. Simply put, Webpack is a tool that takes all your JavaScript, CSS, images, and other assets and bundles them together so your website loads faster and runs smoother.

Imagine you’re packing for a trip. Instead of carrying 10 different bags, wouldn’t it be easier to fit everything into one organized suitcase? That’s exactly what Webpack does for your code!

Why Do We Need Webpack?

The Problem Before Webpack

Back in the day, websites loaded multiple JavaScript files and CSS stylesheets separately. This led to:

Slow load times (more files = more requests = longer waiting).
Messy dependency management (files relying on each other could break easily).
Bloated, unoptimized code (unnecessary scripts and styles slowing things down).

The Webpack Solution

Webpack makes life easier by:

Combining all files into a single, optimized bundle.
Minimizing and compressing code to improve performance.
Handling modern JavaScript (ES6+), TypeScript, and CSS preprocessors effortlessly.
Improving page speed by eliminating unused code (tree shaking) and loading only what's needed (lazy loading).
Providing a development server that auto-refreshes when changes are made. Basically, it takes all the annoying, repetitive parts of frontend development and automates them.

How Does Webpack Work?

At its core, Webpack follows a simple process: Find, Process, Bundle.

1. Entry Point

Webpack starts by looking at the main JavaScript file—the entry point—to figure out what the project needs.

module.exports = {
  entry: './src/index.js',
};

2. Output

Once Webpack processes everything, it spits out the final bundled file.

module.exports = {
  output: {
    filename: 'bundle.js',
    path: __dirname + '/dist',
  },
};

3. Loaders

Loaders help Webpack understand files beyond JavaScript, like CSS and images.

module.exports = {
  module: {
    rules: [
      {
        test: /\.css$/,
        use: ['style-loader', 'css-loader'],
      },
    ],
  },
};

4. Plugins

Plugins supercharge Webpack by adding extra features, like generating an HTML file automatically.

const HtmlWebpackPlugin = require('html-webpack-plugin');

module.exports = {
  plugins: [
    new HtmlWebpackPlugin({ template: './src/index.html' }),
  ],
};

5. Development vs. Production Mode

Webpack has different modes for development and production. Development mode gives fast builds, while production mode optimizes everything for the best performance.

module.exports = {
  mode: 'development', // or 'production'
};

Wrapping Up

Webpack is like that friend who organizes everything so I don’t have to. It takes multiple files, optimizes them, and ensures the site loads fast. Whether you’re working with JavaScript, CSS, images, or even TypeScript, Webpack has your back.

Forem: Gaurav Dalvi

Git Hooks — The Developer's Silent Sidekick

💡 What Are Git Hooks?

🦸‍♂️ Why Should You Care?

💡 pre-commit — Stop Bad Code Before It Happens

💡 commit-msg — Enforce Commit Message Discipline

💡 pre-push — The Final Defense Line

💡 post-merge — Sync After Merging

💡 post-checkout — Welcome to Your New Branch

📚 Other Git Hooks You Should Know (But Use When Needed)

🔗 How to Share Hooks Across Teams?

💡 Final Thoughts

Essential Linux Commands Every Developer Should Master

🧠 pwd — Print Working Directory

📂 ls — List Directory Contents

🚪 cd — Change Directory

🔥 rm — Remove Files or Directories

🧹 mkdir & rmdir — Make / Remove Directory

📝 touch — Create an Empty File

🔍 grep — Search Through Files

🪓 chmod — Change File Permissions

🏃 ./ — Run Executables

🦸 sudo — SuperUser Do

🌐 curl — Transfer Data from URLs

💣 kill & killall — Stop Processes

🧪 top / htop — Monitor Processes

📦 tar — Archive and Extract Files

🧾 man — Manual Pages

💡 Final Thoughts

Write Code Like A Pro: Mastering The SOLID Principles

🧠 S — Single Responsibility Principle (SRP)

🧠 O — Open/Closed Principle (OCP)

🧠 L — Liskov Substitution Principle (LSP)

🧠 I — Interface Segregation Principle (ISP)

🧠 D — Dependency Inversion Principle (DIP)

💡 Wrapping Up

Microservices: Because Monoliths Are So 2009

🧐 Why Microservices?

🧩 Design Principles: Or How to Avoid a Distributed Disaster

1. Single Responsibility, Not Single Line of Code

2. Data Isolation: No Peeking!

3. Communication: Choose Your Weapons Wisely

🛠️ Tooling You’ll Actually Use

🔥 Common Pitfalls (and How to Avoid Them)

1. Too Many Services, Too Soon

2. Distributed Monolith

3. Ignoring Observability

💬 Real Talk: Do You Even Need Microservices?

🧠 Final Thoughts: Herding Cats, One Service at a Time

JavaScript’s Event Loop — Explained Like You're Five (But With More Sarcasm)

🧠 First, a Little Brain Primer: JavaScript Is Single-Threaded

🏗️ Stack, Queue, and Web APIs — The Cast of Characters

1. Call Stack (a.k.a. “The Do-Right-Now Zone”)

2. Web APIs (a.k.a. “The Outsourcing Department”)

3. Callback Queue (Task Queue) (a.k.a. “The Waiting Room”)

🔁 Enter the Event Loop

🔬 Let’s Visualize It (in Code)

⚡ Microtasks vs. Macrotasks: The Plot Thickens

💡 So Why Does Any of This Matter?

🧪 Bonus: Block the Stack and See the Chaos

🎯 TL;DR (Too Long; Debugged Recently)

🧠 Final Thoughts

How Does the Internet Work? (A.k.a. The Most Epic Game of Digital Hide and Seek)

🧠 Step 1: It All Starts With a Thought

🧭 Step 2: DNS – The Internet’s Phone Book (Only Nerdier)

🚀 Step 3: HTTP – The Messenger on a Mission

🖥️ Step 4: Servers – The Internet’s Kitchens

🛣️ Step 5: The Internet Highway – How the Data Travels

📦 Step 6: Packets – The Data Burritos

🔄 Step 7: Rendering – Your Browser Gets to Work

🔐 Bonus: Encryption – Because Privacy Is Kinda Important

🧩 TL;DR – A Dramatic Recap

⚡ The Internet Is a Miracle of Coordination

Unlocking the Power of the Console Object: Beyond console.log()

1. console.table() – Pretty Print Your Data 📊

2. console.warn() & console.error() – Color Code Your Logs ⚠️

3. console.group() – Organize Logs Like a Pro 📂

4. console.count() – Track Function Calls 🔢

5. console.time() – Measure Performance ⏱️

6. console.trace() – See the Call Stack 🔍

💡 `pre-commit` — Stop Bad Code Before It Happens

💡 `commit-msg` — Enforce Commit Message Discipline

💡 `pre-push` — The Final Defense Line

💡 `post-merge` — Sync After Merging

💡 `post-checkout` — Welcome to Your New Branch

1. `console.table()` – Pretty Print Your Data 📊

2. `console.warn()` & `console.error()` – Color Code Your Logs ⚠️

3. `console.group()` – Organize Logs Like a Pro 📂

4. `console.count()` – Track Function Calls 🔢

5. `console.time()` – Measure Performance ⏱️

6. `console.trace()` – See the Call Stack 🔍

7. `console.assert()` – Conditional Debugging ✅

8. `console.dir()` – Inspect Objects in Depth 🔎

9. `console.clear()` – Declutter Your Console 🧹