Forem: Nimai Charan

HTTP ETag : I got sold by this 90s tech.

Nimai Charan — Thu, 22 Jan 2026 17:19:50 +0000

Back in 90s, when modems screamed and images loaded byte by byte, HTTP ETag was born.

Fast forward to 2026 and
ETags are still quietly making web faster.

No hype. No fancy frameworks. Just one tiny header doing real work.

In this AI era, where bandwidth feels unlimited and sloppy code ships daily, ETags are a beautiful piece of engineering that somehow still survives.

Fun Fact: I was unaware of it until I read it from one of the Zerodhas's tech blog fro 2020. I tried, I was sold.

What is an HTTP ETag?

ETag = Entity Tag - a fingerprint for a response.

Flow in one sentence:
Server sends data + ETag --> client sends it back later --> server replied "304 Not Modified"

No response body, no bandwidth just pure engineering. Simple.

What I was struggling with?

In one of my apps, the frontend polls the backend every 10 seconds to check device status.

Most of the time? Nothing changes.

Without caching:

Same JSON sent again and again
Same CPU Work, Same MySQL Query
Same bandwidth wasted

Naturally someone asked, "Why not websocket or SSE?"

Because... it overkills.

Data changes rarely
90% of response are identical
websocket = connection management, reconnection logic, scaling pain
SSE = long-lived connection, load balancer cries

In other word, I did not needed realtime, I needed Smarter Polling

Now the frontend sends:
If-None-Match: "abc123"

Backend answers:
304 Not Modified OR 200 OK + new JSON + New ETag

~90% of requests return 304
Almost zero bandwidth
No open sockets
Works everywhere

Same polling. Now polite.

You can find the implementation here.

Final thought

ETag isn’t legacy tech. Before adding realtime infra, try the header that’s been solving this problem since 1997.

Sometimes the best optimization… is already in HTTP.

NOTE: While inspecting request, please make sure Disble Cache in network panel is un-checked.

HTTP ETag : I got sold by this 90s tech.

Nimai Charan — Thu, 22 Jan 2026 17:19:50 +0000

Back in 90s, when modems screamed and images loaded byte by byte, HTTP ETag was born.

Fast forward to 2026 and
ETags are still quietly making web faster.

No hype. No fancy frameworks. Just one tiny header doing real work.

In this AI era, where bandwidth feels unlimited and sloppy code ships daily, ETags are a beautiful piece of engineering that somehow still survives.

Fun Fact: I was unaware of it until I read it from one of the Zerodhas's tech blog fro 2020. I tried, I was sold.

What is an HTTP ETag?

ETag = Entity Tag - a fingerprint for a response.

Flow in one sentence:
Server sends data + ETag --> client sends it back later --> server replied "304 Not Modified"

No response body, no bandwidth just pure engineering. Simple.

What I was struggling with?

In one of my apps, the frontend polls the backend every 10 seconds to check device status.

Most of the time? Nothing changes.

Without caching:

Same JSON sent again and again
Same CPU Work, Same MySQL Query
Same bandwidth wasted

Naturally someone asked, "Why not websocket or SSE?"

Because... it overkills.

Data changes rarely
90% of response are identical
websocket = connection management, reconnection logic, scaling pain
SSE = long-lived connection, load balancer cries

In other word, I did not needed realtime, I needed Smarter Polling

Now the frontend sends:
If-None-Match: "abc123"

Backend answers:
304 Not Modified OR 200 OK + new JSON + New ETag

~90% of requests return 304
Almost zero bandwidth
No open sockets
Works everywhere

Same polling. Now polite.

You can find the implementation here.

Final thought

ETag isn’t legacy tech. Before adding realtime infra, try the header that’s been solving this problem since 1997.

Sometimes the best optimization… is already in HTTP.

NOTE: While inspecting request, please make sure Disble Cache in network panel is un-checked.

Mining Git Internals to Build a Year-in-Review Dashboard

Nimai Charan — Mon, 05 Jan 2026 01:37:52 +0000

Every year-end, products like Spotify Wrapped or YouTube Music Wrapped present personalized retrospectives using user data. That idea led to a simple question:

Can we generate a similar “year-in-review” for engineers—purely from Git, without relying on GitHub or Bitbucket APIs?

The result was IQnext Wrapped: an internal tool that analyzes raw Git repositories to generate a visual, gamified summary of engineering activity across multiple years.

This post documents the architecture, core logic, and Git internals behind the project.

High-Level Architecture

The system is intentionally simple:

Git Repositories
      ↓
Go-based Git Miner
      ↓
Aggregated JSON Files
      ↓
Next.js Visualization Layer

There is no database, no backend service, and no scheduled jobs.

The entire pipeline runs locally and produces static artifacts.

Component Breakdown

1. Golang Data Miner

The core of the system is a Go program that analyzes repositories directly via the .git directory.

Key characteristics:

Uses go-git/v5
Clones and analyzes 12 internal repositories
Traverses all branches, not just main
Deduplicates commits across branches
Computes aggregate statistics:
- Total commits
- Lines added / deleted
- Activity by author
- Activity by weekday and month

This miner is effectively the warehouse of the system.

2. JSON as the Data Ledger

After analysis, all computed metrics are written to JSON files.

This design decision was deliberate:

Flat files simplify development
Zero operational overhead
Easy consumption by frontend
Immutable, auditable snapshots

The JSON files act as:

The database
The API
The single source of truth

3. Frontend: Next.js as the Storyteller

The UI is built using Next.js 14 + TypeScript and consumes the generated JSON directly.

Key features:

Year-over-year comparison
Team rankings and consistency scores
Achievement badges (e.g., Early Bird, Weekend Warrior)
Framer Motion for transitions and animations
Session-based authentication for internal access

The frontend does no computation—it purely visualizes precomputed data.

Core Insight: The `.git` Directory Is a Database

Most developers treat .git as an opaque implementation detail. For this project, it is the primary data source.

Understanding Git internals was critical.

Entry Points: `.git/HEAD` and `.git/refs`

Each branch reference ultimately points to a commit hash.

By iterating through references:

All branches become visible
All reachable commits can be collected

This ensures contributions are captured regardless of where they occurred.

Storage Layer: `.git/objects` and the Commit DAG

Git stores data as a content-addressable object graph.

Loose objects (.git/objects/??/)
Packfiles (.git/objects/pack/)
Objects are compressed using zlib

Using repo.CommitObjects(), go-git transparently:

Decompresses objects
Reconstructs commits, trees, and blobs
Exposes them as Go structs

This enables full traversal of the Directed Acyclic Graph (DAG) of commits.

Understanding Change: Parents, Trees, and Diffs

Each commit points to:

One or more parent commits
A tree representing a snapshot of the repository

To compute line statistics:

Compare a commit to its parent
Diff the parent tree against the current tree
Drill down to blob-level differences
Count additions and deletions

This is how metrics like “lines added” and “lines removed” are derived—without any external tooling.

The Commit Analyzer

All collected data funnels into a central structure:

type RepositoryStats struct {
    Name              string           `json:"name"`
    TotalCommits      int              `json:"total_commits"`
    TotalLinesAdded   int              `json:"total_lines_added"`
    TotalLinesDeleted int              `json:"total_lines_deleted"`
    CommitsByAuthor   map[string]int   `json:"commits_by_author"`
    CommitsByMonth    map[string]int   `json:"commits_by_month"`
    CommitsByWeekday  map[string]int   `json:"commits_by_weekday"`
}

To avoid double-counting commits across branches, the analyzer:

Iterates through all reachable commits
Tracks seen commit hashes
Aggregates metrics only once per unique commit

var allCommitHashes []plumbing.Hash

branchIter.ForEach(func(c *object.Commit) error {
    if !seenCommits[c.Hash.String()] {
        seenCommits[c.Hash.String()] = true
        allCommitHashes = append(allCommitHashes, c.Hash)
    }
    return nil
})

This guarantees a complete and accurate view of contribution history.

Design Constraint: One Core File

The entire backend logic lives in one file: main.go.

Everything else—frontend, animations, UI polish—is secondary.

This constraint forced:

Clear data flow
Minimal abstractions
Easier reasoning and debugging

Lessons Learned

Git already contains everything
- APIs are convenience layers, not requirements
Flat files are underrated
- JSON works extremely well for read-heavy analytics
Branch-aware analytics matter
- mainonly analysis hides real work
Understanding internals pays off
- Treating Git as a database unlocks new possibilities

Conclusion

IQnext Wrapped started as a side project inspired by year-end review products, but became a deep dive into Git internals, data modeling, and disciplined architecture.

The project reinforced a simple idea:

Many problems do not need more infrastructure—only better understanding of the systems we already use.

The Go-based Git analyzer is robust, the frontend is expressive, and most importantly, the system remains simple, inspectable, and dependency-free.

Designing a Lightweight Data Pipeline for Analysis Without Stressing Production Databases

Nimai Charan — Mon, 22 Dec 2025 15:05:47 +0000

Analytics should never compete with production workloads.

In many systems, analytics begin as a convenience query against the production database. Over time, these queries grow heavier, scan larger time ranges, and slowly degrade system reliability.

This post describes a lightweight, production-safe data pipeline for analytical workloads, built with:

Delta Lake on S3 for durable analytical storage
DuckDB as an embedded analytics engine
Tenant-isolated batch processing
Strict resource limits
Local caching to reduce cloud IO

This is not a streaming system and not an anomaly engine yet.

It is a clean analytical data pipeline designed to protect production databases.

The Problem With Analytics on Production Databases

Production databases are optimized for:

Fast point reads
High write concurrency
Transactional guarantees

Also they are not optimized for operation like large historical scans, aggregations over months or years, repeated analytical jobs or heavy read amplification.

Running analytics on production systems leads to:

Query latency spikes
Lock contention
CPU starvation
Unpredictable failures during peak hours

The primary architectural goal was simple:

Never run analytical queries on the production database.

Architectural Principles

This pipeline is built on four non-negotiable principles:

Production isolation – analytics never touch OLTP systems
Batch-first design – no streaming complexity
Bounded resources – strict memory and thread limits
Operational simplicity – no clusters to manage

High-Level Architecture

DuckDB runs inside the application process, not as a service.

Why Delta Lake on S3?

Delta Lake provides ACID transactions on object storage, schema enforcement, safe concurrent writes anf features like time-travel for reprocessing.

In the other hand Amazon S3 have low cost storage and high durability.

This combination creates a stable analytical backbone that is fully decoupled from production systems.

Why DuckDB?

DuckDB is an embedded OLAP engine, not a distributed system.

Why that matters:

No JVM
No cluster
No coordinator
No operational overhead

Apart from this DuckDB excels at columnar scans, vectorized execution. And also it is know for high Parquet / Delta reads and batch analytical workloads.

This makes it ideal for scheduled jobs and tenant-isolated analytics. Also we can make resource-constrained environments with it.

Explicit Resource Control

DuckDB is configured with hard limits:

SET memory_limit = '1GB'; // As per environment
SET threads = 2; // Based upon available CPU cores
SET enable_object_cache = true;

This guarantees no memory explosions and a predictable performance.

Each analytical run behaves like a bounded analytical task, not a long-running service.

Tenant-Isolated Data Layout

Data is stored per tenant:

s3://data-lake/
  tenant_id=tenant_123/
    energy_reading/
      year=2025/
        month=03/

Benefits:

Partition pruning
Reduced S3 reads
Strong tenant isolation
Linear horizontal scaling by tenant

Each job processes one tenant at a time.

Scheduler-Based Processing (Not Streaming)

This system intentionally avoids streaming frameworks.

Why:

Analytics are not latency-critical
Batch jobs are deterministic
Failures are easier to retry
Infrastructure cost is dramatically lower

Jobs:

Run on a scheduler
Read bounded time ranges
Exit cleanly after execution

Local Disk Cache to Reduce S3 Reads

Repeated S3 scans might be expensive and slow.

A local disk cache:

Stores tenant-scoped results
Uses TTL-based eviction
Eliminates redundant reads

This significantly improves latency, Cost efficiency and overall system stability.

Performance Benchmarks (DuckDB + Delta Lake on S3)

Environment

Instance: 4 vCPU / 8 GB RAM
DuckDB memory limit: 1 GB
DuckDB threads: 2
Storage: Amazon S3 (Delta Lake)
Cache: Local disk (result-level cache)

Metric	Cold Read (S3 + Delta Scan)	Warm Read (Local Cache)
Rows scanned	~2.1 million	0
Rows returned	~120,000	~120,000
Data read from S3	~180 MB	0
Query execution time	4.8 – 6.2 seconds	40 – 90 ms
Peak memory usage	~620 MB	~120 MB
CPU utilization	~1.5 – 1.8 cores	< 0.3 core
Network I/O	High (S3 reads)	None
Production DB load	0	0

Multi-Tenant Sequential Jobs

Number of Tenants	Total Processing Time
10 tenants	~45 seconds
25 tenants	~2 minutes
50 tenants	~4 minutes

Observation:

No cross-tenant interference was observed. Each tenant job executed in isolation with predictable and linear scaling characteristics.

Comparison With ClickHouse and Spark

Engine	Best For	Strengths	Tradeoffs / Downsides	Operational Complexity
DuckDB (This Approach)	Embedded, batch analytics	- Runs in-process - No cluster management - Strong S3 + Parquet support - Predictable resource usage	- Single-node execution - Not designed for high concurrent queries	Low
ClickHouse	Real-time analytical services	- Extremely fast OLAP queries - High query concurrency - Mature production deployments	- Requires dedicated servers - Stateful storage management - Higher ops overhead	Medium–High
Apache Spark	Large-scale data processing	- Horizontally scalable - Excellent for ETL and ML workloads - Rich ecosystem	- Heavy memory footprint - Slow startup time - Significant operational complexity	High

Takeaway:

For bounded, tenant-isolated analytical jobs running on a schedule, DuckDB provides the best balance of performance, cost, and operational simplicity.

What This Pipeline Is (and What It Is Not)

This pipeline is designed to solve a very specific problem: running analytical workloads without putting any pressure on production systems.

It acts as a production-safe analytical layer, allowing historical data to be scanned, aggregated, and analyzed in isolation. It also serves as a clean foundation for downstream logic such as anomaly detection or reporting, without forcing those concerns into the storage or query layer. Most importantly, it achieves this without requiring a dedicated analytics cluster, making it a cost-efficient alternative for teams operating under infrastructure constraints.

At the same time, this pipeline is intentionally narrow in scope.

It is not a streaming system, and it does not aim to deliver real-time insights. It is also not an OLTP replacement, nor does it embed anomaly detection logic directly. The analytical engine focuses purely on reliable, bounded data access — any anomaly detection or intelligence logic is built on top of it, not baked into it.

This separation keeps the system easier to reason about, test, and evolve over time.

Final Thoughts

Not every analytical problem requires a cluster, a streaming framework, or a heavyweight OLAP database.

In many cases, especially for scheduled or batch-driven analysis, those tools introduce more operational complexity than value. A simpler system — one that is bounded, predictable, and easy to operate — often performs better in practice.

By combining DuckDB with Delta Lake on S3, this pipeline behaves like an analytical sidecar: it stays out of the way of production workloads while still delivering fast, reliable analysis when needed.

The key takeaway is not about the tools themselves, but about architectural restraint. Choosing the simplest system that meets your requirements often leads to more stable, maintainable, and cost-effective outcomes.

Building a Meta-Logger: Tracking My Work Across GitHub, Codeberg, and Bitbucket Using Go

Nimai Charan — Thu, 18 Dec 2025 15:22:23 +0000

Modern development isn’t just fragmented across repositories — it’s fragmented across platforms.
On any given week, I might:

Fix a production bug in a Bitbucket repo at work
Push an open-source contribution to Codeberg
Ship a side-project feature on GitHub

Each platform has its own dashboards, contribution graphs, and activity feeds.

None of them talk to each other.

After a while, I noticed a real problem:

I had no reliable way to answer “What have I actually contributed, where, and how much?”

Not because the data didn’t exist — but because it was siloed.

The Problem: Contribution Blindness

This wasn’t about chasing green squares or streaks.
It was about:

Losing visibility into my own work
Forgetting entire weeks of meaningful contributions
Having no portable, platform-agnostic record of progress
Manually reconstructing timelines whenever I needed a summary

When someone asked:

“What did you work on last month?”

The answer involved:

Opening GitHub
Then Bitbucket
Then Codeberg
Searching commit histories
Mentally stitching together context

That’s a tooling failure.

The Insight: Git Is the Only Common Denominator

Platforms differ.

Git does not.
Whether a repo lives on GitHub, Codeberg, Bitbucket, or a self-hosted server, every commit has:

A hash
An author
A timestamp
A message
A repository context

So instead of trying to unify platforms, I decided to unify my commits.

That led to a simple idea:

What if every commit I make, anywhere, automatically logs itself into one central place?

What I Built: A Meta-Logger

I built a small Go-based CLI tool I call a Meta Logger.

It creates a meta-repository — not for code, but for context.

This repository becomes

A centralized journal of my work
A searchable, chronological history
A platform-independent “proof of work”

The tool works silently in the background and requires zero manual effort once set up.

Architecture Overview

The system has three moving parts:

1. The Log Repository

A dedicated Git repository (hosted anywhere — GitHub is just convenient) that stores:

A Markdown file (commit-log.md)
One entry per commit, across all projects

It does not store source code.

2. A Go CLI Tool

A single binary written in Go that:

Extracts commit metadata
Formats human-readable log entries
Commits and syncs them to the log repository

No runtime dependencies. No daemon. No background service.

3. Git Hooks

A post-commit hook installed into each working repository.

Every time I run:

git commit

The logger runs automatically.

No extra commands. No discipline required.

Why Go?

I chose Go for two very practical reasons:

Speed

This runs on every commit. If it’s slow or flaky, it’s dead. Go binaries start instantly.
Zero Dependencies

One compiled binary. No Node. No Python. No virtualenvs. No node_modules.

The commit workflow should be invisible.

How It Works in Practice

Setup

Running:

go run main.go setup

Does three things:

Initializes a central log repository
Creates a Markdown log file
Injects a post-commit hook into selected repositories

The hook is minimal:

#!/bin/bash
cd /path/to/workspace
go run main.go log-commit

From this point on, logging is automatic.

Automatic, Invisible Logging

On every commit, the tool captures:

Repository (service) name
Branch
Commit hash
Author
Original commit date
Full commit message

And appends a structured Markdown entry like this:

## [dummy-service] a1b2c3d - 2025-05-10 14:30:00

- **Service:** dummy-service
- **Branch:** main
- **Commit:** a1b2c3d
- **Author:** Nimai
- **Date:** 2025-05-10 14:29:58
- **Message:**

This lives in a single file that GitHub (or any Git host) makes instantly searchable.

Importing My Entire Past

Logging forward wasn’t enough.

I wanted my entire history reflected.

That’s what import-history does.

go run main.go import-history

It:

Iterates through all repositories
Filters commits by author
Reconstructs entries in chronological order
Preserves original commit dates

Preserving Time Correctly

Git normally assigns now as the commit time.

That would destroy historical accuracy.

So while committing to the log repo, I explicitly inject the original dates:

cmd.Env = append(os.Environ(),
    "GIT_AUTHOR_DATE="+commitDate,
    "GIT_COMMITTER_DATE="+commitDate,
)

The result: the log repository becomes a faithful mirror of my actual work timeline.

Silent Syncing by Design

One important design choice: never block the developer.

If GitHub (or any remote) is unreachable:

The log file is still updated locally
The push is attempted silently
Failures are ignored

The next successful push syncs everything naturally.
No broken workflows. No lost commits.

Why This Works Across Platforms

This system doesn’t care whether a repository lives on:

GitHub
Codeberg
Bitbucket
Or a local Git server

As long as it’s Git, it’s logged.

The log repository itself can live anywhere — GitHub just happens to give a great UI for browsing Markdown.

What This Gave Me

After a few weeks of usage, I had:

A single, chronological journal of my work
A platform-agnostic contribution record
A way to answer “What did I work on?” instantly
A clear signal of consistency and growth over time

No dashboards. No metrics. Just facts.

What This Is Not

Not a productivity tracker
Not a replacement for GitHub contributions
Not a SaaS product
Not something that spies on you

It’s just Git, documenting Git.

Closing Thoughts

This tool changed how I perceive my own output.

Instead of fragmented activity scattered across platforms, I now have a unified narrative of my work — one that I own completely.

Sometimes the most useful tools aren’t new abstractions.

They’re just honest layers on top of systems that already work.

EP-1: WTF is Spring Boot?

Nimai Charan — Sat, 01 Jun 2024 19:43:50 +0000

The Man, The Myth, Not Thala, But Spring Boot

What make a java developer powerful? Obviously knowing how to write REST API. Having ability to talk to server by writing mere alphabets in your code editor is not less than having any superpower. In the world of Java, Its not the REDBULL which gives you wing, Its Spring Boot which gives you wings and let you fly high.

How to have super power

No individual born with power, people have to acquire it. If you want to have the super power of talking to server you need to go to a place in internet start.spring.io. The virtual pornhub ** for java developers.
**What it gives

Boilerplate starter code for creating a basic spring boot application.
Standard project structure, Ensures your code can suck but not your project structure
Nothing else

If you hit on the GENERATE button one zip folder will magically get downloaded.
Unzip It, Open it with some of the world class IDE like Intellij Idea or VS code and hit on the Play button.

DONE, You have created your first Spring boot project.

Lets DIVE Deep on next Episode.

Happy Booting.

Danni, Johny and the Java Feature Flag Problem

Nimai Charan — Mon, 31 Jul 2023 08:34:29 +0000

What is Feature Toggle

Imagine you are building a new feature for your Java application. You want to test the feature with a small group of users before you roll it out to everyone. You could do this by creating two versions of your application, one with the new feature enabled and one with the new feature disabled. But this would require you to deploy two different versions of your application to production, which could be time-consuming and difficult.

Instead, you could use a feature toggle. A feature toggle is a variable that you can use to enable or disable a feature in your application at runtime. This means that you can deploy a single version of your application to production, and then use the feature toggle to control whether the new feature is enabled for different users.

The Danny and Johny Problem

Imagine a situation Danny is the only daughter of Big-B for which Danny's father
is too protective of her. He never allowed Danny for party or any outing. He works in an hospital as a doctor on shift basis and its not certain when he will go to hospital and come back. Danny has a boyfriend Johny who is too much partyholic and he never gots time to chill-out with danny. So, together they found out a solution. They bribed a Ramu Kaka who runs tea stall in front of hospital, who will inform wheather Big-B is in hospital or left for hoe, so that in that time both Johny and Danny can party together.

Let's Understand chronology

PAPA_HOME is the feature that Johny and Danny are dependent

Johny will call Danny for party

Danny will be keep looking for Ramu Kaka's message.

They will decide if they will go for party or not based on Ramu Kaka's message.

Solution

For the solution we have several libraries available, I went with FF4J(Feature Flag for java). Below are the Code Snippet with Explanation.

1. Head to Spring Intializer and create a starter spring boot project.

I don't give a sh*t about which version you are using, But if you are using Spring Boot 3.x you have to use Java 17 or above. Gradle or Maven? I don't care. I went with Gradle.

2. Inject the following line to your dependency for gradle.

implementation 'org.ff4j:ff4j-core:2.0.0'.
If you are using maven, go to Maven Central Repository and find your own dependency,

3. Create A Java configuration something like FF4JConfig or whatever the f*ck you want.

Where to create? This piece of sh*t is not for you.

4. Add the following lines.

@Configuration //This piece of shit will tell spring boot that this is a configuration class
public class FF4jConfig {
    //Feature Name Definition
    public static final String PAPA_FEATURE = "PAPA_FEATURE";

    /*
    * FF4J Configuration
    * Create one bean of type FF4J. Why? Because concept of overriding is dying
    * Create of instance of FF4j. Obviously to use it further
    * Register your Feature
    * Enable or disable according to you
    * You are done, Thank me later (Code Below ⬇️)_
    */
    @Bean
    public FF4j ff4j(){
        FF4j ff4j = new FF4j();
        Feature papaFeature = new Feature(PAPA_FEATURE);
        papaFeature.disable(); //Default we will disable this feature later we will be enable
        ff4j.createFeature(papaFeature);
        return ff4j;
    }
}

5. Define your API End point for Ramu Kaka and Johny to communicate.

    @GetMapping(path = "/should-we-party")
    public String shouldWeParty(){
        if(ff4j.check(FF4jConfig.PAPA_FEATURE))
            return "Yeah Johny Lets Go for party";
        else
            return "Sorry Johny, Papa is at Home";
    }

    /*
     * End-point will change the status of the feature
     * In our case it will notify johny about status of papa
     */
    @PostMapping(path = "/papa-at-hospital/{isAtHospital}")
    public String papaAtHospital(@PathVariable boolean isAtHospital){
        if(isAtHospital){
            ff4j.enable(FF4jConfig.PAPA_FEATURE);
            return ("Message deliverd to danny: PAPA IS AT HOSPITAL, GO PARTY");
        }
        else {
            ff4j.disable(FF4jConfig.PAPA_FEATURE);
            return ("Message deliverd to danny: PAPA LEFT HOSPITAL, COME BACK");
        }
    }

Don't forget to autowire the FF4j to instantiate before using

@Autowired
    FF4j ff4j;

Results

Following is the endpoint for Johny to ask Danny out.

Following is the endpoint for Ramu Kaka to ask Danny out.

Once Ramu Kaka informed Danny that Big-B is in hospital, Johny will get the following response on calling Danny.

After getting this response, Johny and Danny went for party. And the rest of the story cleared from browser history

Get the full Code at Github/0x4E43

Forem: Nimai Charan

HTTP ETag : I got sold by this 90s tech.

What is an HTTP ETag?

What I was struggling with?

Naturally someone asked, "Why not websocket or SSE?"

Final thought

Further Reading

HTTP ETag : I got sold by this 90s tech.

What is an HTTP ETag?

What I was struggling with?

Naturally someone asked, "Why not websocket or SSE?"

Final thought

Further Reading

Mining Git Internals to Build a Year-in-Review Dashboard

High-Level Architecture

Component Breakdown

1. Golang Data Miner

2. JSON as the Data Ledger

3. Frontend: Next.js as the Storyteller

Core Insight: The .git Directory Is a Database

Entry Points: .git/HEAD and .git/refs

Storage Layer: .git/objects and the Commit DAG

Understanding Change: Parents, Trees, and Diffs

The Commit Analyzer

Design Constraint: One Core File

Lessons Learned

Conclusion

Designing a Lightweight Data Pipeline for Analysis Without Stressing Production Databases

The Problem With Analytics on Production Databases

Architectural Principles

High-Level Architecture

Why Delta Lake on S3?

Why DuckDB?

Why that matters:

Explicit Resource Control

Tenant-Isolated Data Layout

Scheduler-Based Processing (Not Streaming)

Local Disk Cache to Reduce S3 Reads

Performance Benchmarks (DuckDB + Delta Lake on S3)

Multi-Tenant Sequential Jobs

Comparison With ClickHouse and Spark

What This Pipeline Is (and What It Is Not)

Final Thoughts

Building a Meta-Logger: Tracking My Work Across GitHub, Codeberg, and Bitbucket Using Go

The Problem: Contribution Blindness

The Insight: Git Is the Only Common Denominator

What I Built: A Meta-Logger

Architecture Overview

1. The Log Repository

2. A Go CLI Tool

3. Git Hooks

Why Go?

How It Works in Practice

Setup

Automatic, Invisible Logging

Importing My Entire Past

Preserving Time Correctly

Silent Syncing by Design

Why This Works Across Platforms

What This Gave Me

What This Is Not

Closing Thoughts

EP-1: WTF is Spring Boot?

The Man, The Myth, Not Thala, But Spring Boot

How to have super power

Danni, Johny and the Java Feature Flag Problem

What is Feature Toggle

The Danny and Johny Problem

Solution

1. Head to Spring Intializer and create a starter spring boot project.

2. Inject the following line to your dependency for gradle.

3. Create A Java configuration something like FF4JConfig or whatever the f*ck you want.

4. Add the following lines.

5. Define your API End point for Ramu Kaka and Johny to communicate.

Results

Thank you

Core Insight: The `.git` Directory Is a Database

Entry Points: `.git/HEAD` and `.git/refs`

Storage Layer: `.git/objects` and the Commit DAG