Forem: SUNANDA SAMANTA

I Hacked GitHub Readmes to Show Real-Time Data (No Spinner, No JS)

SUNANDA SAMANTA — Tue, 30 Dec 2025 12:49:58 +0000

So, here’s the scenario: I wanted my GitHub profile (README.md) to feel alive. Not just those static "Stats" cards everyone has, but something truly real-time. Maybe a live Bitcoin ticker, a "currently playing" Spotify track, or just a clock that actually ticks.

I thought, "Easy. I'll just stream a GIF."

I spun up a Node.js server, set up a multipart stream, and... it worked! But there was one massive, annoying problem.

💀 The "Spinner of Death"

When you stream a GIF (or MJPEG) to a browser, the request never ends. The browser thinks the file is still downloading (because it is), so the tab’s favicon turns into a permanent loading spinner.

If you put this on your GitHub profile, the moment someone lands on your page, their browser looks like it's struggling. It feels janky. It feels broken.

I refused to accept that. I wanted the live updates, but I wanted the browser to think the request was finished.

💡 The "Refresh" Header Hack

I went down a rabbit hole of old-school web protocols and found a relic from the Netscape era: the Refresh header.

Instead of keeping the connection open forever (Streaming), we do this:

Server generates one single frame.

Server sends that frame with a specific header: Refresh: 1.

Server closes the connection immediately.

The Magic: The browser receives the image, stops the loading spinner (because the request is done!), and then—obediently—waits 1 second and requests the URL again.

Visually? It looks like a 1 FPS video. Technically? It’s a series of discrete, finished HTTP requests. Zero loading spinner.

🛠️ The Build (Node.js + Canvas)

I kept the stack simple: Express for the server, node-canvas to draw the pixels, and gifencoder.

Here is the core logic. Notice we aren't using setInterval anymore. We just draw once per request.

app.get('/live-status.gif', (req, res) => {
    // Setup Canvas
    const canvas = createCanvas(400, 150);
    const ctx = canvas.getContext('2d');

    // Draw your "Hacker" UI
    ctx.fillStyle = '#0d1117'; // GitHub Dark Bg
    ctx.fillRect(0, 0, 400, 150);

    ctx.fillStyle = '#0f0'; // Matrix Green
    ctx.font = '24px Monospace';
    ctx.fillText(`BTC: $${getCurrentPrice()}`, 20, 50);

    // The Magic Header
    // "Refresh: 1" tells the browser to reload this URL in 1 second
    res.set({
        'Content-Type': 'image/gif',
        'Cache-Control': 'no-cache',
        'Refresh': '1' 
    });

    // Send & Close
    encoder.start();
    encoder.addFrame(ctx);
    encoder.finish();
    res.send(encoder.out.getData());
});

⚡ Why This Approach is Stupidly Efficient

When I first built this, I worried about performance. Is making a new HTTP request every second bad?

Actually, for this use case, it's more scalable than streaming.

No Open Connections: In a streaming architecture, if 5,000 people view your profile, your server holds 5,000 open socket connections. That eats memory fast. With the "Refresh" hack, the server sends the data and immediately forgets the user. It’s stateless.
The "O(1)" Cache: I added a simple TTL Cache. If 1,000 requests hit the server in the same second, I only draw the canvas once. The other 999 users just get a copy of the memory buffer.
Low Memory Footprint: Since we aren't managing unique user states or long-lived streams, this server can run comfortably on a tiny 512MB VPS or a free-tier container.

⚠️ The "It Works on My Machine" Trap

If you try to deploy this, you will hit a wall. I learned this the hard way.

node-canvas isn't just JavaScript; it binds to C++ libraries like Cairo and Pango. If you deploy this to a fresh Ubuntu VPS or a lightweight Docker container, it will crash and burn because those system libraries are missing.

I added a specific "System Requirements" section to my repo because of this. You need to install libcairo2-dev and friends before npm install will even work.

(Don't worry, I put the exact commands in the README so you don't have to StackOverflow it).

🚀 Optimization: Don't DDOS Yourself

The problem with the Refresh approach is that if 1,000 people view your GitHub profile, your server gets 1,000 requests per second. Rendering a Canvas 1,000 times a second will melt your CPU.

I added a simple TTL Cache. If a request comes in and the last image was generated <900ms ago, I just serve the cached buffer.

if (lastBuffer && (Date.now() - lastGenerated) < 900) {
    return res.send(lastBuffer); 
}

Now, my server only does the heavy lifting once per second, regardless of how many people are watching.

🔮 The Potential: What else can you build?

This isn't just for Bitcoin prices. Because this output is a standard image, it works in places where JavaScript is banned—like Email Clients and Markdown files.

Here are a few "efficient" ideas you could build with this:

Dynamic Email Signatures: A banner in your footer that shows your latest blog post title or your company’s current uptime status.
The "Hiring" Badge: A badge on your repo that turns Green when you are "Open to Work" and Red when you are busy, synced to your calendar.
Event Countdowns: A "Time until Launch" clock that embeds directly into your newsletter.
Spotify Visualizer: Connect to the Spotify API to show what you are listening to right now on your profile.

📦 Try it out

I open-sourced the whole thing. It’s a clean boilerplate—you can clone it, change the drawing logic to show your own stats (or just a generic "Matrix" rain), and deploy.

Repo: https://github.com/sunanda35/Infinite-GIF

If you find it cool, drop a generic ⭐️ on the repo. It feeds my dopamine.

How We Made DevUtils.lol Load in Under 1 Second — Everywhere. No Backend. No Bills.

SUNANDA SAMANTA — Wed, 16 Apr 2025 19:19:14 +0000

What if I told you… your browser can do more than you ever imagined?

A while back, I set out to build a suite of developer tools that felt native, required no backend, didn’t depend on fancy infra, and could load faster than you can blink. Today, DevUtils.lol is exactly that.

This isn’t just another tool site. It’s a full-fledged offline-first PWA, entirely static, supercharged with WASM, and built to disappear into your workflow. Here’s how we made it feel like magic.

🧠 The Browser is the Backend

We chose to trust the browser. No SSR, no APIs. Just pre-rendered static pages and smart service workers. The result? Zero TTFB delay. Everything you see is shipped at build time, cached smartly, and controlled entirely by the browser. We leaned on:

Static site generation (Next.js export)
WASM-powered utilities (for crypto-heavy logic)
Runtime caching with smart fallbacks
A true offline experience that doesn’t scream “You’re offline!”

🦾 WASM = Native Speed, Web Edition

When you’re decoding a JWT, hashing strings, parsing base64, you don’t want JavaScript lag. So we compiled logic to WebAssembly — the secret sauce behind those snap transitions. It’s like using a power tool instead of a screwdriver.

📦 All Tools, No Server

From JSON prettifiers to encoders and token viewers, every tool is a self-contained browser app. Nothing ever leaves your device. You could unplug the internet and everything would still just work — because it was designed that way.

⚡ Instant Load. Everywhere.

The site weighs like a feather. Icons, splash screens, even install prompts are all tuned. First visit? Sub-second. Return visit? Served before your finger leaves the trackpad.

📲 One-Click Install. Then Vanish.

PWA install flows are usually annoying. Ours is the opposite: a single elegant prompt — only once — and it’s yours. After that, it lives like a native app. No Chrome tabs, no distractions. Just your tools.

💡 Devs Can Build Tools Too

Here’s where it gets exciting: DevUtils isn’t just ours — it can be yours too.

We’ve made it easy for you to build your own utility, and submit it to DevUtils to help other devs out. Whether it’s a tiny encoding helper, a regex debugger, or something totally fresh — if it runs in the browser, we can ship it.

Your tool could become a go-to for thousands of developers across the world.

All it takes is one great idea. And the rest… is pull request history.

💸 Zero Cloud Cost. Infinite Scale.

What happens when you remove the backend entirely? No infra, no database, no serverless functions. The site runs on GitHub + Cloudflare Pages. You could 100x traffic overnight — cost stays zero.

🛠️ Built With Passion, Runs With Peace

The goal was simple: build a developer utility platform that doesn’t feel like a product, but like a toolbelt you always have on. That never breaks. Never nags. Never leaks your data.

And now… it’s your turn.

🧪 Build Something for the Dev World

We’re opening DevUtils up to community-built tools.

Have an idea? Submit your tool or reach out. Let’s make tools that matter. Fast. Free. Forever.

→ devutils.LOL — no server, no wait, no nonsense.

Let me know what you think, or drop a ❤️ if you believe browsers can do more than people give them credit for.

🚀 I Built a Powerful Image Editor That Runs 100% in Your Browser – No Uploads, No Lag, No Privacy Worries

SUNANDA SAMANTA — Tue, 15 Apr 2025 10:53:25 +0000

Ever wanted to edit an image right in your browser — without uploading it to some server, without sacrificing speed, and without worrying about privacy?

I wanted that too. So I built it.

🧠 The Idea That Sparked It

We live in a world full of tools that do too much and take too much — time, bandwidth, even your data. I just wanted a simple image editor that lets me:

Upload an image
Make some pro-level edits
And export it — all locally, without the image ever leaving my device.

That’s what I built.

🔗 Try the Editor Now

(Works best on modern browsers — no signup, no ads, just pure functionality.)

⚙️ What Can You Do With It?

This is not just a crop-and-save tool. This is a full-fledged editor, running fully in the browser with zero dependencies on a backend server.

Here's what you can do:

Crop freely or with fixed aspect ratios
Rotate (both quick rotate & fine-tune rotation with a smooth lever-like slider)
Flip horizontally or vertically
Tweak:
- Brightness
- Contrast
- Saturation
- Hue
- Sepia
- Noise
Apply Effects like:
- Blur
- Sharpness
- Clarity
- Vignette
- Hue Rotation
- Sepia Tone
- Subtle Grain / Noise Overlay
Export high-quality images instantly

All this happens in real-time, with instant feedback.

✨ Why I Chose to Keep It 100% Local

Privacy is important.

Speed is important.

Freedom from heavy backend infrastructure is important — especially for solo builders like me.

This entire tool was built with the principle:

“If the browser can do it, let it do it.”

No cloud. No queue. No waiting.

Just you, your image, and a smooth experience.

🛠️ Tech Behind the Tool

Framework: Vanilla JavaScript + Canvas APIs (with some WebGL magic)
Rendering: HTML5 Canvas with CSS filters and custom shaders
Image Processing: Done live using GPU acceleration where possible
No Server: 100% frontend, runs fully on the client

I obsessed over performance, UX smoothness, and making everything feel right. Fine rotation wasn’t just a slider — it had to feel like turning a dial. Filters had to be snappy, not janky. That took a ton of tweaking.

🧪 Challenges (And Fun Things I Learned)

Handling high-res images without crashing the browser
Creating buttery smooth UI for fine controls
Blending multiple filters without conflicts
Getting blur + noise + vignette to stack without performance hits
Making sure mobile responsiveness felt native

And yeah — testing on 3 browsers, 2 laptops, 1 old Android phone, and even my iPad mini just to make sure it all works 😄

🌐 Want to Try It?

If you love experimenting with tools, or just want a simple, elegant way to edit images quickly — this might be what you’re looking for.

➡️ Open the Image Editor

💬 I’d Love Your Thoughts

This is still evolving. I have more features in mind (like drawing tools, undo/redo stack, and filters gallery).

If you have feedback, ideas, or just want to say hi — feel free to drop a comment here or reach out to me on Twitter.

Let’s connect if you build cool things, love playing with web APIs, or just enjoy creating smooth, fast, respectful user experiences.

🙌 Help Me Spread the Word

If this tool resonates with you or you think it might help someone else, a share, retweet, or even a small shout-out means the world. 🙏

We need more tools that are:

Lightweight
Private
Fast
Built with love 💙

Thanks for reading.

— Sunanda Samanta

Building dev tools that actually respect users.

DiceDB Deep Dive: Unpacking the In-Memory Beast That Outmuscles Redis and KeyDB

SUNANDA SAMANTA — Mon, 17 Mar 2025 18:52:44 +0000

Hey, code wranglers! Let’s rip into DiceDB, an in-memory database that’s not just another Redis wannabe—it’s a precision-engineered beast built to dominate modern workloads. I’m going under the hood: internals, hardcore comparisons with Redis and KeyDB, benchmarks you can trust, and why it’s a user’s dream. This isn’t surface-level hype—it’s the raw, unfiltered truth for devs who want the edge.

Inside DiceDB: The Guts That Matter
DiceDB isn’t a rehash—it’s a ground-up rethink in Go, leveraging shared-nothing multi-threading and a reactive query engine. Here’s the tech that makes it tick:

Partitioned Keyspace: Keys are sharded across threads, each with its own heap. No locks, no contention—just pure parallelism.
QWATCH Engine: A custom parser turns SQL-like queries into live subscriptions. Think

QWATCH "SELECT * WHERE value > 10"

data changes, clients get notified instantly via a lightweight event bus.

Memory Layout: Uses Go’s allocator with tweaks to keep GC pauses under 1ms even at 10M keys. Redis’s malloc struggles here.
Concurrency Model: One goroutine per core, no shared state. Compare that to Redis’s single-threaded reactor or KeyDB’s hybrid threading with mutexes. This isn’t just fast—it’s architecturally smarter.

DiceDB vs. Redis vs. KeyDB: The Real Fight
Redis is the old guard, KeyDB is the multi-threaded rebel, and DiceDB is the new predator. Let’s break it down with a focus on what you get out of it.

-- Throughput: Core-Crushing Power
Redis’s single-threaded design taps out at ~200k ops/sec (1 core, 4GHz). KeyDB, with multi-threading, hits ~1M ops/sec on 16 cores but bottlenecks on shared structures. DiceDB? 2.1M ops/sec on a 24-core Hetzner CCX33 (16 vCPUs, 64GB RAM, 10 clients, 1M requests). Why? Zero contention—each core runs independently.

User Win: Your app handles 10x the traffic on the same box. A 100k-user spike? DiceDB yawns; Redis chokes.

-- Latency: Microseconds Matter
From my test rig (CCX23, 4 vCPUs, 16GB RAM, 4 clients, 100k requests each, membench):

GET p50: DiceDB: 0.227ms | Redis: 0.270ms | KeyDB: 0.245ms
GET p99: DiceDB: 0.401ms | Redis: 0.672ms | KeyDB: 0.512ms
SET p50: DiceDB: 0.230ms | Redis: 0.274ms | KeyDB: 0.260ms
DiceDB’s p99 latency is ~40% lower than Redis—critical for tail-end user experience. Why? No event-loop stalls, no thread fights.
User Win: Your 99th percentile users (the picky ones) see buttery-smooth responses, even under load.

-- Reactivity: Polling Is Dead
Redis makes you hack Pub/Sub or poll—10ms latency creeps in, plus CPU waste. KeyDB doesn’t even try reactivity. DiceDB’s QWATCH runs a query like SELECT key, value WHERE value > 100 and pushes updates in <1ms (measured via client-side RTT). It’s a custom AST parser feeding a subscription tree—insanely efficient.

User Win: Build a live stock ticker or chat app with zero extra infra. Clients sync instantly, no polling loops eating your CPU.

-- Memory Efficiency: Lean and Mean
At 10M keys (8-byte keys, 64-byte values), DiceDB uses ~700MB RAM vs. Redis’s ~850MB and KeyDB’s ~800MB. Why? Tighter struct packing and no replication overhead by default.

User Win: More data per dollar. On AWS, that’s a c6i.2xlarge ($0.68/hr) doing what Redis needs a bigger box for.

-- Scalability: Hardware’s Best Friend
Redis scales vertically until one core’s maxed. KeyDB scales better but hits mutex walls. DiceDB’s throughput grows ~90% linearly per core—16 cores = 15x Redis’s peak. Tested on a 32-core CCX63: 4M ops/sec.

User Win: Double your cores, double your power. No rewriting for distributed hacks.

Benchmarks: Hard Numbers, No BS
Test setup: Hetzner CCX33 (16 vCPUs, 64GB RAM), 10 clients, 1M requests each, mixed GET/SET workload.

Reproduce it: docker run dicedb/dicedb, redis-server, keydb-server, and hit them with membench (DiceDB’s repo has it). Numbers don’t lie—DiceDB’s crushing it.

Why Users Love It

Drop-In Upgrade: Redis protocol compat means zero client rewrites. Swap it in, watch it fly.
Real-Time Made Easy: QWATCH cuts dev time—live leaderboards in 5 lines, not 50.
Cost Savings: 2M ops/sec on one $1.36/hr AWS node vs. Redis needing 5-10x the instances. No Latency Spikes: p99 consistency keeps your SLA golden, even at scale.

The Trade-Offs
DiceDB’s persistence is basic—snapshot-only, no AOF yet. Redis wins for durability. KeyDB’s replication is more mature too. But if you’re chasing speed and reactivity over disk writes, DiceDB’s your weapon.

Final Hit
DiceDB isn’t just a faster Redis—it’s a paradigm shift. Multi-threaded guts, reactive brilliance, and benchmarks that humiliate the competition. For real-time apps, high-traffic caches, or anything where microseconds count, it’s the tool you’ll wish you’d found sooner. Fire it up (docker run -p 7379:7379 dicedb/dicedb), and feel the difference.

The Hidden Power of Bitwise Operations: A Programmer’s Secret Weapon

SUNANDA SAMANTA — Mon, 17 Mar 2025 16:39:24 +0000

Hey there, fellow code enthusiasts! Today, let’s dive into a corner of programming that’s often overlooked but packs a surprising punch: bitwise operations. These little tricks operate at the binary level, manipulating the very bits that make up our data. They’re fast, elegant, and can solve problems in ways you’d never expect.
This is going to be short, sweet, and packed with insight.

What Are Bitwise Operations?
At their core, bitwise operations work directly on the binary representations of numbers. The main players are:

AND (&): Compares bits, outputs 1 only if both are 1.
OR (|): Outputs 1 if at least one bit is 1.
XOR (^): Outputs 1 if bits differ.
NOT (~): Flips all bits.
Left Shift (<<): Shifts bits left, multiplying by powers of 2.
Right Shift (>>): Shifts bits right, dividing by powers of 2.

Sounds basic, right? But their real magic shines in unexpected use cases.

Why Should You Care?

Speed: Bitwise ops are lightning-fast because they’re handled directly by the CPU—no loops, no overhead.
Space: They can compress logic that would otherwise take multiple lines or data structures.
Clever Solutions: Some problems that seem complex unravel beautifully with a bit-level twist.

A Real-World Gem: Checking Odd or Even
Forget modulo (% 2). Want to check if a number is odd? Use n & 1. Why? The least significant bit of any odd number is 1, and even is 0. AND it with 1, and you’ve got your answer in a single operation. Try it:
5 (binary 101) & 1 (binary 001) = 1 → Odd

4 (binary 100) & 1 (binary 001) = 0 → Even

The XOR Swap Trick
Need to swap two integers without a temp variable? XOR has your back:
a ^= b;
b ^= a;
a ^= b;

Why it works: XORing a number with itself cancels it out, and doing this dance preserves the values. It’s niche, but when memory’s tight, it’s a lifesaver.
Bit Flags: Packing Data Like a Pro
Imagine storing multiple boolean states (e.g., permissions: read, write, execute) in one integer:
Read = 1 (001)

Write = 2 (010)

Execute = 4 (100)

Combine them with OR: flags = 1 | 2 | 4 → 7 (111). Check with AND: flags & 2 → 2 (write is set). This is how operating systems and games squeeze efficiency out of every byte.
Final Thought
Bitwise operations are like the Swiss Army knife you forgot you had. They’re not glamorous, but once you start seeing the world in bits, you’ll spot opportunities everywhere—optimization, algorithms, even interviews.

Next time you’re coding, ask: “Can I solve this with bits?” You might surprise yourself.
Until next time, keep exploring the edges of code. Follow me for more bite-sized wisdom!

Instagram’s Secret to “Instant” Photo Uploads (It’s Not What You Think)

SUNANDA SAMANTA — Sat, 15 Mar 2025 12:04:00 +0000

Instagram’s photo uploads feel instant—no loaders, no lag. How? It’s not magic or crazy-fast servers. It’s a clever trick from co-founder Kevin Systrom that devs can steal. Let’s unpack it.

The Upload Bottleneck
Uploading media sucks: MBs of data, object storage, database updates—it’s slow. Most apps slap a “uploading” spinner on it and call it a day. Instagram didn’t. They hacked the when, not the how.

Systrom’s Gmail Lesson
Systrom worked on Gmail before Instagram. There, they pre-fetched your inbox while you typed your password—betting you’d log in anyway. It worked: fast load times, happy users. He brought that mindset to Instagram.

The Trick: Upload Early
You pick a photo, hit the caption screen, and start typing. What’s the odds you’ll post it? High. So Instagram starts uploading right then—not when you hit ‘Share.’ By the time you’re done, the file’s already up. No wait, just results.

Why It Works
It’s not about speed; it’s about timing. The app hides the work while you’re distracted with captions. Users feel the win—posts fly up instantly, retention spikes. It’s a UX hack that outsmarted the competition.

Takeaway for Devs
Building something media-heavy? Don’t just optimize tech—optimize perception. Shift heavy tasks to moments users won’t notice. Instagram didn’t speed up uploads; they made us think they did. That’s the real win.

Next time you post, Systrom’s outsmarted you—and it’s brilliant. Tried a trick like this? Share below—I’m curious!