DEV Community: Hari

How Claude Code's entire source code leaked, and it wasn't a hack

Hari — Sat, 04 Apr 2026 00:59:39 +0000

Last week, March 31, 2026, Anthropic, the company behind Claude, accidentally leaked the full source code of their product Claude Code.

Here's the full story, explained so anyone can follow it.

First, what is Claude Code?

Claude Code is a tool that developers install on their laptops to use Claude directly from their terminal - their command line. Think of it like an app, but instead of downloading it from an app store, developers install it from a place called npm.

npm is basically the App Store for developer tools. When a company like Anthropic wants to ship a tool that developers can install with one command, they publish it to npm. It's public, open, and anyone in the world can download any package from it — no account, no password, no fee. That's by design. It's how the whole ecosystem works.

If you write C#
npm is NuGet.
Publishing to npm is exactly like publishing a package to nuget.org,
except every single package on npm is public by default.
When Anthropic published Claude Code, it was like pushing a NuGet package to a public feed that the entire world can browse.

When engineers write code for an application, they need to debug it, run it locally, see how it behaves, and figure out which line caused a crash. During this process, a file gets generated automatically called a map file. It's basically a breadcrumb trail that points back to the exact line of code that broke something. Someone published this to the world by mistake while publishing their feature update for Claude Code.

A 59.8 MB JavaScript source map file (.map),
intended for internal debugging, 
was accidentally included in version 2.1.88 
of the @anthropic-ai/claude-code package 
on the public npm registry

If you write C#
This is your .pdb file
The Program Debug Database.
When you compile in Debug mode, the compiler generates a .pdb alongside your .dll.
It maps compiled IL back to your original source lines, your variable names, your method names.
It's what makes your stack traces say "crashed on line 47 of OrderService.cs" instead of a memory address.
You never ship the .pdb to end users, and you'd never bundle it into a NuGet package.

Here's a real snippet of what it looked like:

{
  "version": 3,
  "sources": [
    "src/utils/undercover.ts",
    "src/tools/BashTool.ts",
    "src/memory/index.ts"
  ],
  "sourcesContent": [
    "const UNDERCOVER_PROMPT = `You are operating UNDERCOVER...`",
    "export async function runBashCommand(cmd: string) {...}",
    "export class MemoryStore {...}"
  ],
  "mappings": "AAAA,SAASA,WAAWC..."
}

See what's happening here:

sources: lists every original source file by name and path. Just reading this tells you the entire folder structure of Anthropic's codebase
sourcesContent: the actual full source code of each file, embedded right here as a string. You don't go anywhere else. It's all sitting right in this one JSON file
mappings: the encoded string that connects minified code character positions back to exact lines in those source files

Imagine Coca-Cola finally ships their secret formula in a can. The can looks normal from the outside. Same red, same taste, nobody can figure out what's inside just by drinking it.
But they accidentally taped a piece of paper to the back of every can that says:

ingredients: [
  "caramel",
  "phosphoric acid", 
  "coca leaf extract"
],

recipe: [
  "mix caramel at 0.5% concentration",
  "add phosphoric acid for tartness",
  "coca leaf extract — do not exceed 0.1%"
  // NOTE: caramel ratio in batch v8 still not right,
  // regression from v4. needs fixing before global launch.
],

upcomingFlavors: [
  "Coca-Cola Peach — launching May 2026",
  "Coca-Cola Zero Sugar Cherry — still in testing"
]

But how exactly did it get out?

In every JavaScript project, there's a file called .npmignore. It works like a packing checklist, it tells the build system what to leave out of the package before publishing. Things like test files, internal scripts, and yes, map files. You explicitly list what should never ship.

Anthropic's build tool, Bun, generates map files automatically during the build process. That's normal and useful during development. The problem is someone never added *.map to the .npmignore file. So when the package was built and published, the map file came along for the ride, no one told to leave out the file before publishing the feature update.

Who found it and how fast?

An intern. At a small crypto company called Solayer Labs. His name is Chaofan Shou. He was poking around the Claude Code package, the kind of thing curious developers do all the time, spotted the map file, immediately knew what it meant, and posted a direct download link on X.

This was at 4:23am ET.

By morning, tens of thousands of developers had downloaded and mirrored the code across GitHub. It had over 80,000 stars. People were already digging through it, finding unreleased features, internal model codenames, and architectural secrets Anthropic never meant to share.

If cache is faster than database, why not store everything in cache?

Hari — Sat, 28 Mar 2026 23:42:01 +0000

We should all have had this question,

why not just use cache everywhere if cache is faster than a database?

I want to quantify and show the difference to you today.

You are thinking, ok this read is going to be a waste of time, I am just gonna say Cache is volatile and move on to doomscroll, or vibe code or watch the latest Ai slop VC drama. Lets fix that, you have a non volatile cache and you dont have to worry about the money to make it non volatile. Can you still use Redis as your DB ?

Volatility means the cache lives on RAM, when you switch it off, all the data is gone.
Whereas DB lives on the disk, and it will survive restart.

We can make it volatile by doing snapshot of the data to a disk, or replicating data across servers.

So now that you have decided to think, can you actually make Redis your DB, given it is not volatile anymore?

Problem 1: Lets talk about the easy reasoning here - COST

Lets assume you own a bank, and it has the following things:

10 million total users
1 million Daily active users
each active user does 20 reads/ day and 2 writes/ day

DynamoDBs Pricing:
$0.125 per million reads
$0.625 per million writes
$0.25 per GB month for storage

With 1 million active users you are doing:

20 million reads per day
2 million writes per day

So that will cost you:

$1.25 per day for reads
$1.25 per day for writes
50 GB storage about $0.42 per day

Total:

$1065 per year

Now lets compare to what that will cost us if we use Cache which is REDIS
Redis does not charge us per read the way DynamoDB does
Instead we pay for the cluster capacity to exist all the time.

So for our situation we need 2 shards, 1 replica per shard and 4 total nodes
That will Cost:
$1.729 per hour
$41.50 per day
$15,147 per year

So we are paying ~15x more for REDIS.
But you know what, lets say money aint a problem, can you still use Redis as your DB ?

Now comes - Eviction pressure

What does it mean ?
When Redis runs out of memory, it must remove some data to make space
Redis commonly uses LRU - Least Recently Used
Which means : delete the data that hasnt been used recently

Example : User A logs in every day, then it will stay in Redis
User B hasnt logged in for a while, it gets removed from memory

So now if Redis was your source of truth, user's account details or balance could vanish.

Ok then lets disable eviction and scale infinitely to have all the RAM.
Well yea then you can do it, by spending ton of money just because you went in a rabbit hole of experimenting with the wrong tool for the job.

But you know what, rabbit holes like this are totally worth the millions of dollars.

Hari.

The Art of Building Software will never Die

Hari — Mon, 18 Aug 2025 12:48:50 +0000

The art of building is such an important curiosity to have.

I fully embrace AI—I use it every day to write and ship software faster. It’s incredible, and I’d be lying if I said it hasn’t changed the way I work.

But I can’t let go of my curiosity to understand the smallest moving parts. I can’t stop tinkering, breaking things down, and building my side projects brick by brick. That urge to build for the sake of building is something I’m deeply grateful for.

Recently, I’ve been diving into microservices and APIs. Somewhere along the way, a simple question started haunting me: how is my code even reachable on my local machine? Sure, I know the surface-level stuff—HTTP calls, GET requests, JSON responses, the satisfying 200 OK. But what even is the HTTP server that makes this all possible? Why had I never broken it down, piece by piece, and seen it for myself?

So, I decided to write my own HTTP server—not because I need to, but because I want to see. I want to understand. I want to become.

It’s 6:36 AM. A loud truck woke me up, and I caught the sunrise. Instead of rolling back to sleep, I felt this unstoppable urge to tell you how excited I am—because today, I’m going to learn to create my own HTTP server. And yes, I’m typing this from my bathroom because I simply couldn’t wait.

Damn! Free will is an amazing thing.

And that’s the heart of it: the art of building can never die. It shouldn’t. No matter how powerful our tools get, no matter how efficient AI becomes, there’s something primal about making things ourselves.

Writing code and learning computer science can feel almost... spiritual. Sometimes, when I’m building, I hear Tool’s 46 & 2 looping in my head:

“Listen to my muscle memory

Contemplate what I have been clinging to.”

That’s what it feels like—muscle memory, curiosity, and the joy of creation blending into something deeper.

So yes—use the tools. Use AI. Get smarter, build faster, build cleaner. But don’t stop building. Don’t stop experimenting. Don’t stop following your curiosity down strange rabbit holes.

"There’s a perfect recording of Stairway to Heaven on vinyl or Spotify, and you can play it a hundred times—it will always sound solid. But it will never replace the joy of picking up a guitar and playing it with your own hands."

-some guy on the internet

That’s the joy of building. That’s why it will never die.

The Tea app data breach: What really happened?

Hari — Sun, 03 Aug 2025 04:58:33 +0000

What Really Happened in the Tea App Data Breach (And Why Principles Matter)

In July 2025, the Tea app suffered two major data breaches — and both were preventable with basic engineering practices. Let's break it down technically.

🧱 Tea App: Likely Architecture

Tea is a social-feedback app. Its backend likely had:

A mobile frontend using React Native or Swift/Kotlin
A REST API gateway (Node.js, Python, or Firebase Functions)
Firebase for authentication and user management
Firebase Cloud Storage for images and ID uploads
A NoSQL database (Firestore or similar) for messages and posts

Here’s the catch: Firebase allows direct access to storage and database, bypassing your API if you don’t lock things down explicitly.

🔐 Breach #1 — Exposed Image & ID Data (72,000 files)

How Firebase Works (and Where It Went Wrong)

Firebase Storage lets mobile apps upload/view files directly using SDKs or URLs. It uses Firebase Security Rules (not your backend APIs) to enforce access control.

But if:

You allow public read access in rules (or forget to update them),
Or store files in a bucket with default “open” config,
And skip backend validation...

Then users — or attackers — can access images just by knowing the link. That’s what happened. A legacy bucket storing verification images was left public.

Storage: Firebase bucket from an older version of the app.
Issue: Public read access. No token, no check.
Impact: 13,000 selfies/IDs + 59,000 post/comment images leaked.
Cause: The bucket was never secured or migrated during infrastructure updates.

💬 Breach #2 — Leaked Direct Messages (1.1+ million messages)

Service: API or database storing user DMs.
Issue: No authentication required on endpoints.
Impact: Messages included sensitive content.
Cause: A debug or legacy endpoint lacked proper auth. Even push notifications were exploited.

🧠 The Real Lesson

These weren’t zero-day attacks. Just:

Misconfigured cloud services (Firebase Storage, public endpoints)
Legacy systems not cleaned up
Missing API/auth enforcement at critical layers

Whether you “vibe code” with AI or not doesn’t matter if you skip the fundamentals. Secure architecture, proper auth, and data lifecycle awareness are the real backbone.

SoftwareEngineering #Security #DataBreach #BestPractices #Firebase #TeaApp

When to use Try-Catch and why too many will hurt me.

Hari — Fri, 01 Aug 2025 05:15:31 +0000

I was happily coding a fresh new API endpoint in C# when suddenly memories of past trauma struck: those dreaded QE pings. You know the ones—cryptic async exceptions popping up like surprise horror movie villains, never clearly pointing out their origin and instead blaming innocent methods. Nightmares!

So, naturally, I thought: "Easy fix—throw try-catch blocks everywhere and make my QE happy." But then, reality check—performance.

🔧 First, what really happens when you use try-catch?
“Hey, keep an eye on this block. If anything explodes, don’t crash, just catch it and let me handle it.”

This makes your code safer. But it comes at a cost.
For a more detailed explanation on Try Catch and Throw:
refer -- https://dev.to/harishankarr7/understanding-try-catch-throw-vs-no-throw-2i45

What happens if I don’t add a try-catch?
Let's explore this with an example:
🔧 Setup: Three methods calling each other

void Main() {
    A();
}

void A() {
    B();
}

void B() {
    C();
}

void C() {
    throw new Exception("Something broke in C!");
}

🫧 What happens when you run Main()?
Main() calls A()

A() calls B()

B() calls C()

C() throws an exception ❌

But C doesn't catch it. So it bubbles up to:

B → no catch here → keep bubbling

A → still no catch → keep bubbling

Main → still no catch → boom 💥

You’ll get an unhandled exception.

🧠 That’s what bubbling means:
If a method doesn’t catch an exception, it passes it up to the method that called it.
That method can either catch it or keep passing it up the chain.

Like bubbles rising in water — they go up until something pops them (a catch block) — or they hit the surface (top of your app) and cause a splash (crash or 500 error).

So can I just sprinkle Try-Catch wherever I want?
What's the cost?

Memory & CPU overhead

Even if nothing goes wrong, try-catch adds work
The runtime tracks the call stack and exception context
On some platforms (like .NET), this creates hidden metadata, and may even slow down JIT optimizations

💡 It’s like saying:

“Hey runtime, just in case I mess up, hold onto this backup plan.”
And that costs something, every time the method runs.

**Exception throwing is super expensive

If an exception is actually thrown:
The runtime must unwind the call stack (walk backwards through function calls)
It creates a full exception object, often with stack trace, source info, etc.
This involves heap allocation, which is slow and can mess with garbage collection

⚠️ If you use exceptions to handle things like "this list is empty" or "this file is missing" — you're paying a high price for something you could’ve handled cheaply with an if.

🧠 So… when should you use try-catch?
✅ Good reasons:

You’re calling risky external code (like a file, database, API, or user input)
You want to add context to the error before rethrowing
You can actually recover from the error (like retry, fallback, or return a friendly error)

❌ Bad reasons:

“Just in case” — catching without knowing what might go wrong
You’re using it instead of if/else (e.g., catching FileNotFoundException instead of checking File.Exists)
You silently ignore the error (log-and-forget, or worse — do nothing)

✅ What to ask yourself before adding a try-catch:
Here’s your mental checklist:

-Can this code actually throw something?
If not — why are you catching?

-Is the exception expected or rare?
Expected → handle with if
Rare → handle with try-catch

-Can I fix or recover here?
If yes, catch and fix
If not, let it bubble up

-Will this block run thousands of times per second?
If yes, don’t put try-catch inside the loop — handle it outside

-Am I logging or hiding the exception?
If you’re not doing something useful, don’t catch it

💡 Mnemonic to remember:
✋ Only catch what you can coach
(If you can’t guide it or fix it, let it go.)

Understanding Try-Catch: Throw vs. No Throw

Hari — Fri, 01 Aug 2025 04:47:23 +0000

What is try–catch?

Imagine you're writing code that might crash — for example, dividing by zero or opening a file that doesn’t exist.

A try block says:
🗣️ “Hey, computer, try running this code. But if something goes wrong… don’t panic. Jump to the catch block and handle it.”

Real-life analogy:
You're trying to open a door with a key. If the key breaks (try fails), you immediately call the locksmith (catch block).

🧪 Basic Code Example:

try {
    int result = 10 / 0;  // This will crash: divide by zero
}
catch (DivideByZeroException ex) {
    Console.WriteLine("Oops! You tried to divide by zero.");
}

No crash. Just a friendly message.
The program survives and keeps running.

🚨 2. What is throw?

Now imagine you want to signal that something has gone wrong — maybe someone passed bad data to your method.

A throw is like raising your hand and saying:
🗣️ “This is not okay. I’m throwing this problem up to someone else to handle!”

💣 Example:

if (number < 0) {
    throw new ArgumentException("Number must be non-negative");
}

⚠️ Why would you want to throw?
Because:
You spotted a bad situation
You don’t know how to handle it right here
You want someone else (maybe catch) to handle it

When NOT to throw

Let’s say you catch an error — but instead of escalating it, you just log it and move on. You don’t throw again.

That’s OK when:
The error isn’t critical
You can recover from it
Or... you're logging the error and don’t want to crash the app

Example:

try {
    var result = GetDataFromFile("missing.txt");
}
catch (FileNotFoundException ex) {
    Console.WriteLine("File not found. Skipping this part.");
    // No throw here — we're handling it gracefully
}

🧠 So what’s the difference: try–catch with throw vs. without?

Let’s compare:

🥊 With throw inside catch:
You're passing the error up — often used when:
You can’t fix the issue here
You want to inform the caller that something went wrong

try {
    riskyThing();
}
catch (Exception ex) {
    Console.WriteLine("Logging the error...");
    throw;  // re-throws the same exception
}

🪵 Without throw:
You're handling it locally — like logging, fallback values, etc.

try {
    riskyThing();
}
catch (Exception ex) {
    Console.WriteLine("Handled and moving on.");
    // No throw here
}

🧾 Isn’t this just like if–else?**

Good instinct! Here's the key difference:

Feature	`if`–`else`	`try`–`catch`
Usage	For things you expect	For things you don’t expect
Performance	Faster (no overhead)	Slower (exception handling has a cost)
Example case	`if (fileExists)`	`try { read file } catch (error)`
Best for	Normal decisions	Unpredictable errors

🚦 Example:
You can check if a file exists before opening it using if. But if the file vanishes between check and open — you'll need try–catch.

What happens if you throw but there’s no catch anywhere?
👉 If you throw and there's no matching catch anywhere in the call stack…
🧨 Your program crashes (or terminates the thread).

Example:

void Main() {
    SayHello();
}

void SayHello() {
    ThrowError();
}

void ThrowError() {
    throw new Exception("Boom!");
}

There is no try–catch anywhere.
So when ThrowError() throws, it:

Looks in ThrowError() → ❌ no catch
Goes to SayHello() → ❌ no catch
Goes to Main() → ❌ no catch
Hits the top level — 💥 Unhandled Exception

⛓️ Think of it like this:
A throw is a message in a bottle.
Catch blocks are the lifeguards.
If nobody catches the message, it floats to the top and sinks the ship.

🧠 Why it matters:
Sometimes, you want that crash (like in tests).
But in real apps, especially APIs or games, unhandled exceptions are dangerous — they can:
Show ugly errors to users
Kill threads (especially bad in multithreaded apps)
Bring down whole services if not contained

Hope this was useful.
Next time, don't Try Catch me if you can with bugs ;)
If you havent watched that movie - go watch it first.

I Used to Fear PROGRAM.CS, Until I Understood the DI Container Like This 🍝

Hari — Mon, 02 Jun 2025 05:13:07 +0000

For the longest time, opening the Program.cs file felt like opening the engine of a spaceship. All that talk of services.AddScoped, AddTransient, AddSingleton, and builder.Services gave me anxiety.

I used to ask my seniors about it randomly, but I think my brain rejected all of it until I had to write an API from scratch, and I had to see it more simply.

Let me take you on a little story.

🍽️ You’re Running a Restaurant (That’s Your App)

Imagine your app is a restaurant. You’re the manager. Every day, you need to serve dishes to customers (handle API requests, basically).

You’ve got:

👨‍🍳 A chef
🧑‍🍳 A helper
🥶 A fridge full of ingredients
🚛 A supplier who brings ingredients
🧾 Customers who order food (clients calling your API)

You don’t want to personally micromanage who chops onions, who cooks the sauce, or who gets the tomatoes from the fridge. That’s chaos.

So you hire an assistant manager — her name is DotNetta.

DotNetta is your Dependency Injection Container.

🧠 What DotNetta (the DI container) Does

Before opening for business, you give DotNetta a set of rules:

🗂️ “Whenever someone asks for a chef, give them Gordon.”
🗂️ “If a chef needs vegetables, get them from the fridge.”
🗂️ “If the fridge is empty, call the supplier.”

This is what happens in your Program.cs:

services.AddScoped<IChef, GordonChef>();
services.AddSingleton<IFridge, WalkInFridge>();
services.AddTransient<ISupplier, FreshFarmSupplier>();

You're not cooking anything yet. You're just telling DotNetta how to assemble the kitchen team when someone places an order.

🛎️ A Customer Walks In

Let’s say a customer orders spaghetti.

DotNetta steps in like a pro:

👨‍🍳 She grabs Gordon (the chef)
🍅 Gordon says: “I need tomatoes and pasta.”
🥫 She checks the fridge
❌ If something’s missing, she calls the supplier
✅ She hands everything over to Gordon
🍝 Dish gets made and served

You didn’t do a thing — and yet everything worked perfectly.

💡 That’s What Happens When You Inject Dependencies

In your code, instead of doing:

var fridge = new Fridge();
var chef = new GordonChef(fridge);
var dish = chef.MakeSpaghetti();

You just say:

public class KitchenService
{
    public KitchenService(IChef chef)
    {
        _chef = chef;
    }
}

And DotNetta figures out the rest.
She knows who the chef is, what he needs, and how to get it all set up.

🧱 What Is a Service?

In real world:

A service is just someone who does something useful — like cook food, deliver ingredients, or clean the kitchen.

In code:

A service is any class or interface that performs some logic or functionality, and might need other things to do its job.

You register these services with DotNetta (your DI container) so she knows who to call when it’s time to work.

🔄 So What is IoC (Inversion of Control)?

Before DotNetta, you were in control of creating everything:

var repo = new UserRepo();
var service = new UserService(repo);

You were the chef, the supplier, the manager — everything.

But with DotNetta:

You tell the system what you need, not how to get it.

That’s Inversion of Control — the control of object creation is inverted. You no longer control the wiring. The framework does it for you.

It’s like placing an order and having an invisible kitchen team handle everything behind the scenes.

🎯 Why This Matters

You write less code
You focus on what the class does, not how it's built
You can easily swap parts (mock services, test different implementations)
You stop fearing the Program.cs file because now you know it’s just DotNetta’s instruction sheet

💬 Final Words

I used to stare at Program.cs like it was some mystical scroll.

But now I know — it's just a menu.
DotNetta (the DI container) reads it, builds the team, gets the ingredients, and serves the customer.

All I do is say, “Hey, I need a spaghetti,” and trust the kitchen knows what to do.

Once you start thinking like this, your fear turns into clarity — and your code?
It starts to feel like magic.

Refit in C# — The API Client That Writes Itself (Almost)

Hari — Mon, 02 Jun 2025 01:16:45 +0000

I was recently asked to build an API that contacts two other APIs. My senior engineer casually dropped:

“Use Refit.”

At first, I was like — “what is this magic word?”
Then I used it. And I was pleasantly shocked.

🧠 What is Refit?

Think of Refit as your tiny API Copilot.

Refit is a REST library for .NET that turns your OpenAPI/Swagger spec into strongly-typed, auto-generated client code. Instead of manually writing a bunch of HttpClient logic, you describe your API once, and Refit generates the rest.

💥 Why It Blew My Mind

Here’s my flow:

I downloaded the Swagger JSON of the external Book API I needed to consume.

I created a refitter.yaml file with the configs.

Ran one CLI command.

And boom — Refit auto-generated:

The interface with methods like GetBookByIdAsync
The models like Book, Author, etc.
The entire client logic, ready to use

Now I can just call:

var book = await _bookApi.GetBookByIdAsync(42);

No plumbing. No extra mapping. Clean.

🛠️ Installing & Using Refit (Quickstart)

Install Refit:

Install-Package Refit

services.AddRefitClient<IBookApi>()
        .ConfigureHttpClient(c => c.BaseAddress = new Uri("https://books.example.com"));

Use it like this:

public class LibraryService(IBook bookApi)
{
    public async Task<Book> FetchBook(int id)
    {
        return await bookApi.GetBookByIdAsync(id);
    }
}

🤔 Swagger: Your New Best Friend

Refit only works as well as your Swagger spec. A clean spec = clean client.
That realization made me treat Swagger not just as documentation, but as code — the contract between services.

When I polished the Swagger for my own API, downstream teams could just plug it into Refit and boom, done. That’s what future-proof API dev looks like.

🧩 Final Thoughts

We’re building an ecosystem where APIs and Kafka keep passing messages like trained athletes in a relay race. My role? Build one of those runners. But with Refit, I didn’t just build a runner — I gave it shoes, training, and a coach.

Whether you're a beginner dev or a product owner — Refit makes integrations faster, safer, and cleaner. All it asks for?
A good Swagger spec.

How Call of Duty:Verdansk Reminded Me RAM is Truly Dynamic

Hari — Tue, 08 Apr 2025 01:50:02 +0000

🎮 Mission: Verdansk (Gone Wrong)

It was supposed to be a laid-back weekend. My friend was installing Call of Duty: Verdansk, and I was ready for a cozy game night.

And then—bam. His network adapters disappeared out of nowhere.

I thought, easy fix. I uninstalled the adapters, rebooted the system, assuming Windows would reinstall the drivers automatically. It did... but they didn’t show up anywhere in the control panel.

Then came the blue screen of death.

🧠 My Brain: "Let’s Just Reset the PC"

PC: "How About No."

Things escalated. I suggested we reset the PC completely—nuke it from orbit.

But here's the twist: the PC wouldn’t reset. It kept throwing errors. That was new to me. So I decided to create a bootable USB to reinstall Windows manually.

Welcome to 2025—we didn’t have a USB stick in the house.
Desperate times, desperate measures—we formatted an SSD and tried using it as a bootable drive.

Did it work? Nope. Windows didn’t install. The PC acted like it was haunted.

🧩 The Hidden Culprit: RAM

At this point, everything should have worked. But apps were crashing. Updates failed. Call of Duty wouldn’t launch. Even when Windows did reinstall, the system was lagging like crazy.

That’s when I remembered something crucial: RAM is dynamic.

💡 What Does It Mean That RAM Is “Dynamic”?

Let’s simplify.

RAM (Random Access Memory) is like your computer’s short-term memory.

It doesn't store files forever—it temporarily holds data for running programs and processes.

Every time you open an app, it lives in RAM while you use it.

Dynamic means it's always changing—data comes in, data goes out.

Here’s the kicker: when RAM goes bad, your computer doesn't always crash. It limps along—slowly, painfully—failing silently in weird ways.

You might boot into Windows, but apps won’t install. Drivers might fail to load. System resets don’t finish. You get weird BSODs.

Exactly what we were facing.

I ran the built-in system diagnostics. Boom—both RAM sticks were faulty.

🧠 Why Faulty RAM Doesn’t Instantly Kill Your PC (But Slowly Breaks It)

You might be wondering—if the RAM was faulty, how did the system even boot?

Here’s the wild part: RAM doesn’t just fail like a blown fuse—it fails in patches.

When RAM begins to degrade, it often develops what are called “bad sectors”—tiny portions of memory that no longer hold or transfer data reliably. Think of it like a whiteboard with sections that just won’t erase or write anymore.

Now, when your system boots up, it doesn't necessarily use all of your RAM at once. It starts assigning memory space as needed. So if your OS or app happens to avoid those faulty sectors for a while, things may seem “okay.”

But as soon as:

You open a large program (like Call of Duty or Chrome with 50 tabs),

Try to install or unpack a large driver package,

Or launch Windows Update that needs stable memory blocks…

…the system might unknowingly use those bad RAM sectors.

That’s when things start breaking in weird, inconsistent ways:

🧩 Apps fail mid-install because the memory holding the install package is corrupt

⚙️ Drivers crash or silently don’t load because a key file in memory is garbled

🔄 System resets hang or fail because the reset process relies on temporary memory too

💥 And eventually, you hit the Blue Screen of Death, when the system realizes something’s deeply wrong but doesn’t know where

So the computer stays “alive,” limping through basic functions, but keeps tripping over invisible landmines every time it tries to do something serious.

And that’s exactly what we were seeing.

🛠️ New RAM, New Hope... But Still No Reset?

We grabbed new RAM sticks. Diagnostics passed. The system was stable. But we still couldn’t reset Windows.

Why? My guess: the SSD we used as a bootable USB wasn’t reliable for that purpose.

🤔 Why an SSD Can Fail as a Boot Drive (In Simple Words)

While SSDs are storage devices, they’re not designed to behave like USB sticks out of the box.

Here’s why it likely failed:

SSDs sometimes require special drivers when acting as bootable devices.

Power draw and firmware differences can cause instability during OS installs.

Some BIOS setups struggle to detect them as legit boot devices.

Basically, it’s like asking a Ferrari to tow a trailer—not what it’s built for.

🚚 Enter: DoorDash USB Delivery

Out of patience, we literally DoorDashed a USB stick.

Tried creating a bootable installer on my Mac. Failed. Macs love to mess with boot formats.

So I pulled out an ancient Windows laptop, fired up Rufus, made a proper bootable USB, and we were back in business.

Changed the BIOS boot order to prioritize USB—and finally, Windows started to install.

🔁 Install Loop: My Final Brain Glitch

The install process began, looked great, and then… it restarted.
And restarted again.
Back to the start of installation. Every. Single. Time.

At this point, I was losing my mind. I told my friend to just get a PlayStation.

And then it hit me.

When a PC restarts after installation, it should boot from the SSD, not the USB. But since USB was still first in the boot order, it kept looping the installation.

Pulled the USB out.

Boom. Windows finished installing. Drivers loaded. Call of Duty launched.

🕹️ Back to Verdansk. We Are So Back, Baby.

troubleshooting is 90% instinct, 10% USB delivery speed.

If you've ever wanted to know what it means when we say “RAM is dynamic,” well, now you know—it lives and breathes, and when it breaks, it breaks everything weirdly.

But hey, we made it.
Verdansk 2020 vibes restored.

Designing an API with Swagger: A Step-by-Step Breakdown

Hari — Mon, 07 Apr 2025 00:33:31 +0000

Before writing any backend code, it’s important to design the API.

Swagger (now officially called OpenAPI Specification) lets you define what your API will look like — the endpoints, the inputs, the outputs — in a structured way.

Here’s how you write a complete Swagger document before coding anything.

🛠 Example: A Simple User API

Let’s say you’re building a User API for a system that manages users.

You want to support the following actions:

Get all users
Get a user by ID
Create a new user

We’ll now break down the Swagger file for this API and explain every single part.

✅ Step 1: Define the API Info

openapi: 3.0.0
info:
  title: User API
  version: 1.0.0
  description: API for managing users

What this does:

openapi: Version of the OpenAPI spec you're using
info: Basic metadata about your API (name, version, description)

✅ Step 2: Define Paths (i.e. Endpoints)

paths:
  /users:
    get:
      summary: Get all users
      responses:
        '200':
          description: A list of users

🔍 What is a Path?

A path is a URL pattern that your API exposes. Example: /users
It represents a resource — in this case, the "users" resource

🔍 What is an Endpoint?

An endpoint is a path + method
Example: GET /users is one endpoint, POST /users is another

So:

/users is a path
GET /users is an endpoint for fetching users
POST /users would be an endpoint for creating a user

✅ Step 3: Add Another Endpoint (GET /users/{id})

  /users/{id}:
    get:
      summary: Get a user by ID
      parameters:
        - in: path
          name: id
          required: true
          schema:
            type: string
      responses:
        '200':
          description: A single user
        '404':
          description: User not found

🔍 What are Path Parameters?

{id} in the path is a dynamic part — it’ll be replaced with an actual value like /users/5
You define it under parameters to describe the input expected

✅ Step 4: Add a Request Body (POST /users)

  /users:
    post:
      summary: Create a new user
      requestBody:
        required: true
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/UserCreate'
      responses:
        '201':
          description: User created

🔍 What is RequestBody?

It describes the input payload the client needs to send when making a POST request
In this case, we expect the client to send a JSON object with user details

✅ Step 5: Define Reusable Schemas (Models)

components:
  schemas:
    User:
      type: object
      properties:
        id:
          type: string
        name:
          type: string
        email:
          type: string

    UserCreate:
      type: object
      required:
        - name
        - email
      properties:
        name:
          type: string
        email:
          type: string

🔍 What is a Schema?

A schema defines the structure of the data in requests or responses
You put schemas under components/schemas so you can reuse them using $ref

In this case:

User is used in responses (contains id, name, email)
UserCreate is used in requests (only name, email — no id because it’s generated)

🔗 How Schemas and Endpoints Work Together

Every endpoint that returns or receives data needs to describe what that data looks like. That’s where schemas come in.

Example:

GET /users returns a list of users → uses the User schema
POST /users expects user input → uses the UserCreate schema

This way:

You avoid repeating structure definitions everywhere
You can update schemas in one place and all linked endpoints reflect it
Documentation stays clean, reusable, and DRY

Think of it like this:

Endpoints describe the actions,
Schemas describe the shape of the data those actions work with.

They are two sides of the same API design.

✅ Full Swagger YAML Example

openapi: 3.0.0
info:
  title: User API
  version: 1.0.0
  description: API for managing users

paths:
  /users:
    get:
      summary: Get all users
      responses:
        '200':
          description: A list of users
          content:
            application/json:
              schema:
                type: array
                items:
                  $ref: '#/components/schemas/User'
    post:
      summary: Create a new user
      requestBody:
        required: true
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/UserCreate'
      responses:
        '201':
          description: User created

  /users/{id}:
    get:
      summary: Get a user by ID
      parameters:
        - in: path
          name: id
          required: true
          schema:
            type: string
      responses:
        '200':
          description: A single user
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/User'
        '404':
          description: User not found

components:
  schemas:
    User:
      type: object
      properties:
        id:
          type: string
        name:
          type: string
        email:
          type: string

    UserCreate:
      type: object
      required:
        - name
        - email
      properties:
        name:
          type: string
        email:
          type: string

🧠 Summary

Swagger lets you design your API before you write code.
Paths define resources, endpoints define actions.
Schemas define the structure of data for requests and responses.
Endpoints and schemas work together to define a complete API contract.
Writing Swagger first saves time, avoids confusion, and aligns your team.

Inside the Brain of Your Computer

Hari — Sat, 29 Mar 2025 04:39:47 +0000

An Example

Let’s say you and your friend are playing a secret game using a flashlight.

Flashlight ON = Yes (1)
Flashlight OFF = No (0)

You both agree on a secret code:

One flash = “Hello”
Two flashes = “Come here”
No flash = “Goodbye”

Even though you're just using ON and OFF, you’re communicating. That’s the key idea.

Now… Imagine a Computer Doing the Same Thing

Inside every computer are billions of tiny flashlights — well, kind of.
They're called transistors, and they also have two states:

Electricity flowing = ON (1)
No electricity = OFF (0)

So just like your flashlight game, a computer uses these ONs and OFFs to form patterns — and those patterns represent letters, pictures, songs, even entire video games.

Same Example, Now in Tech Terms:

Let’s say you press the letter A on your keyboard.

Your computer turns that into a pattern of ONs and OFFs: 01000001
Each 1 or 0 is made by a transistor turning electricity ON or OFF
Billions of these switching patterns fly through the computer’s brain (the CPU)
The screen reads the pattern and shows you the letter A

From your simple key press… to a dance of electricity… to something you see on screen

The Big Idea:

Computers speak in 1s and 0s because they’re made of tiny switches (transistors) that only understand ON and OFF.
Those switches use electricity — and when you control electricity in patterns, you can make a machine understand and do almost anything.

So next time you open your laptop or phone, just remember — there’s a massive, invisible flashlight game happening inside. And it’s how everything works.

Why JSON Feels Like an Interpreter Between Services — And Why That’s Not Far Off

Hari — Fri, 28 Mar 2025 03:57:35 +0000

Ever feel like JSON is less about data and more about helping apps talk clearly? You're spot-on! JSON (JavaScript Object Notation) acts like the universal translator between different programming languages.

Why JSON is Like a Translator

Imagine one friend speaks Spanish, another speaks French, and you're stuck trying to order tacos in Paris. You definitely need a translator! Similarly, Python, Java, C#, and JavaScript can't directly understand each other—it's like they're at an awkward programming party, nodding politely but clueless about what's going on. JSON steps in, effortlessly chatting with everyone and translating their stories.

Everywhere I go, I see JSON 👀

JSON is like that friendly neighbor who’s always there but you hardly notice—it's in your web browser, your apps, even in your fridge (probably). It’s always around, quietly making sure everyone gets along without making a fuss. It's the curse of being effortlessly friendly; always present but rarely appreciated.

But I care! I wanted to understand the magic behind JSON. What's this friendly neighbor actually doing?

How Douglas Crockford Created JSON

Back in the early 2000s, Douglas Crockford was fed up with XML—understandably so. XML looked like:

<person>
    <name>Hari</name>
    <age>25</age>
</person>

That’s way too much drama just to say, "I'm Hari and I'm 25!"

Then Douglas noticed JavaScript had a simpler, friendlier way:

const person = {
  name: "Hari",
  age: 25
};

Douglas thought, "Why are we complicating our lives? Let’s just use this!" And thus, JSON was born, happily simplifying everyone's data drama.

So, What Exactly Did He Create?

Douglas didn't create a new programming language—he just set clear ground rules for this friendly little structure:

{} for objects (key-value pairs)
[] for arrays
"" for strings
Numbers, true/false, and null

Teaching applications to understand JSON

Now, how do we teach apps to use this newfound translator? Apps are brilliant, but they don't just wake up one day fluent in JSON—they need parsers (to understand JSON) and generators (to speak JSON). Thankfully, smart people made tools like Newtonsoft.Json (in C#) or Python's built-in JSON module to help apps pick up JSON quickly.

Think of a parser as your app's personal interpreter:
Parser (JSON → Python):

import json

json_text = '{"name": "Hari", "age": 25}'
person = json.loads(json_text)
print(person['name'])  # Output: Hari

And a generator as your app's spokesperson:
Generator (Python → JSON):

person = {"name": "Hari", "age": 25}
json_text = json.dumps(person)
print(json_text)  # Output: {"name": "Hari", "age": 25}

How JSON Works Practically in Microservices (C# Example)

Picture this: you've built a microservice in C#, and it wants to chat with another microservice written in Python or JavaScript. Normally, they’d struggle—like cats and dogs trying to discuss dinner plans. But they've agreed on JSON, the neutral, drama-free mediator.

They both agree to use JSON. Here's how this works practically:

Microservice 1 (C#):

You explicitly tell your app, "Hey, when you send or receive data, always use JSON."

Your C# app uses a JSON library (like System.Text.Json or Newtonsoft.Json) to automatically convert internal C# objects into JSON text when sending data.

var person = new {
  Name = "Hari",
  Age = 25
};

// Convert to JSON automatically
string jsonString = JsonSerializer.Serialize(person);
// jsonString becomes: {"Name":"Hari","Age":25}

When this C# app sends data over HTTP, it'll send the JSON string directly:

{"Name":"Hari","Age":25}

JSON Holds Everything Together 🌟

JSON might seem simple—just curly braces and quotes—but it quietly holds everything together, making our lives infinitely easier. Next time you casually glance over JSON, remember: it's not just "data," it's a friendly neighborhood translator, keeping the digital world chatty, connected, and drama-free!

Next time you use JSON, remember: You're not just handling data; you're translating clearly between worlds!