Forem: Ravgeet Dhillon

My First Electronics Project - Building a Real-Time Power Outage Monitor with ESP32 and Slack

Ravgeet Dhillon — Wed, 18 Mar 2026 11:53:05 +0000

The moment of realization happened in Singapore. I was thousands of miles away from home, enjoying a trip, when I went to check my home CCTV footage through my phone. The screen stayed black. "Connection Failed."

The internal monologue of a developer immediately goes to the worst-case scenario: Did the router die? Is there a break-in? Did the server crash?

The reality was much simpler, yet equally frustrating: a power cut. The cameras ran on their internal batteries until they hit 0%, leaving me in a complete information blackout. I didn't know if the power was out for ten minutes or ten hours.

I promised myself I wouldn't leave for another trip without a "Heartbeat" from my home in Amritsar.

The Solution

I needed a non-invasive system (no cutting 220V mains wires), resilient to inverter switchover gaps, and capable of sending instant notifications.

I chose the ESP32 for its built-in Wi-Fi and low power consumption. By pairing it with a Slack Webhook, I created a device that "shouts" the second the grid fails.

The Hardware Stack

To keep things modular and "plug-and-play," I went with:

ESP32 DevKit V1: The brain of the operation.
USB-TTL Converter: This acts as the sensor. It brings the 5V USB signal down to a safe 3.3V for the ESP32 to read.
1000µF Capacitor: Essential for bridging the 20ms gap during inverter switchover. This prevents the ESP32 from rebooting during the transition.
Female-to-Female jumper wires
Some USB data cables

Engineering the "Flicker Filter"

One of the biggest hurdles was electrical noise. GPIO 34 on the ESP32 is an input-only pin and can act like an antenna. Without a solid ground reference, the signal "flickered" between ON and OFF.

I solved this with a two-pronged approach:

Grounding Geometry: Moving the ground wires to the same side of the board to stabilize the reference voltage.
Software Debounce: I implemented a 3-second delay in the code. The system verifies that the power is actually out before sending a Slack alert, preventing false alarms from minor grid fluctuations.

Watch the Journey

I documented the entire process—from navigating the local electronics markets in my city to the final "Production" test where I manually tripped the MCB.

Watch the Documentary: YouTube - Making my first Electronics project

Get the Code: GitHub - esp32-power-alert

Closing Thoughts

Engineering isn't just about writing code for a Jira ticket; it's about solving the small, personal anxieties of life through technology. Now, when I’m on vacation, I’ll know exactly what’s happening at home. Not because I’m checking a camera, but because my home is talking to me.

If you're interested in building this yourself, feel free to reach out or check out the repository!

Debugging and Stopping Infinite Render Loops in React

Ravgeet Dhillon — Thu, 05 Feb 2026 11:22:28 +0000

Infinite renders are not magic bugs — they are deterministic feedback loops. Once you understand why a render retriggers itself, they become easy to reproduce, debug, and prevent.

This post walks through a step‑by‑step mental model to stop the “Maximum update depth reached“ errors for good.

What an Infinite Render Loop Really Is

At its core, an infinite render loop looks like this:

Component renders
Some reactive logic runs (effect, watcher, computed, subscription)
That logic updates the state
State update causes a re-render
Repeat forever

The key insight:

Renders don’t loop by accident — they loop because state changes on every render.

The Fastest Way to Reproduce the Bug

When debugging, your first goal is reproduction.

Minimal reproduction checklist

Comment out everything except one state value and one reactive hook (effect/watcher). Then add a log in both render and state update.

Example:

function Component() {
  console.log('render');

  const [count, setCount] = useState(0);

  useEffect(() => {
    console.log('effect');
    setCount(count + 1);
  }, [count]);
}

If you see:

render → effect → render → effect → ...

You’ve confirmed the loop.

The #1 Root Cause: Unstable References

Most infinite loops come from reference instability, not logic errors.

Identity vs Equality

{} !== {}
[] !== []
() => {} !== () => {}

Even if values look equal, their identity changes on every render.

Example: Object in dependencies

function Component({ userId }) {
  const filters = { active: true, userId };

  useEffect(() => {
    fetchData(filters);
  }, [filters]); // ❌ new object every render
}

This results in the effect that runs forever.

Stabilizing References with Memoization

Fix with memoization

const filters = useMemo(() => ({
  active: true,
  userId
}), [userId]);

Now, it has the same reference, but the effect runs only when userId changes. A rule of thumb is that if a variable goes into the dependency array, it must be referentially stable.

Choosing Correct Dependencies (Not Fewer)

A common anti-pattern:

useEffect(() => {
  if (status === 'loaded') return;
  setStatus('loaded');
}, [status]);

This effect updates its own dependency once, then converges to a stable state instead of looping forever.

Linting That Actually Helps

Linting is one of the cheapest ways to prevent infinite render loops before they reach runtime — especially in React and Next.js apps.

By specifying the correct React Hooks Rules, you can catch the most common causes of render loops. BY using correct linting rules, you can enable rules in your editor. For example:

react-hooks/rules-of-hooks
react-hooks/exhaustive-deps

This forces correct dependency lists, exposes unstable references early, and prevents stale closures disguised as "fixes".

But still, the warnings about missing dependencies are not always true. It makes sense to treat them as design bugs, not suggestions.

Debugging with `why-did-you-render` + LLMs

Although we are talking about this step at the very last, if time is crucial to you, then this could be the first resort.

Sometimes you know a component is re-rendering too much, but you don’t know what changed. Multiple states or effects might be responsible for an infinite render loop.

This is where why-did-you-render becomes extremely powerful — especially when paired with an LLM.

What `why-did-you-render` does

why-did-you-render monkey-patches React in development and logs exact reasons for re-renders:

Which props changed
Whether the change was by identity or value
Which hooks triggered the update

Instead of guessing, you get concrete evidence.

Basic setup

[why-did-you-render]
MyComponent re-rendered because of props changes:
  props.filters changed
    prev: { active: true, userId: 1 }
    next: { active: true, userId: 1 }
  reason: props.filters !== prev.props.filters

This immediately tells you:

The values are equal, but the reference is not
Memoization is missing

Feeding logs to an LLM (Copilot / ChatGPT)

Here’s where debugging gets much faster.

You can save the console logs as a .log file and feed them to the LLM agent along with the code context that you feel might be the reason for the infinite rendering. You can use the following prompt:

"I have attached the console logs from why-did-you-render along with the code in which the infinite loop is happening. Can you find what is causing this behaviour and how do I stabilize it?"

Because the logs already encode identity vs equality, the LLM can:

Identify unstable objects/functions
Suggest correct useMemo / useCallback placement
Detect unnecessary props drilling
Recommend architectural fixes (lifting state, memo boundaries)

This removes the guesswork that usually slows humans down.

Why this works so well with LLMs

LLMs struggle with implicit runtime behavior.

why-did-you-render turns runtime behavior into explicit text.

Once behavior is textual:

Debugging becomes a reasoning problem — which LLMs are good at.

Used together, they form a tight loop:

Reproduce the render issue
Capture why-did-you-render logs
Paste logs + code into an LLM
Apply fix
Verify render stability

Final Thought

Infinite render loops are not a framework flaw — they are a signal.

They tell you that:

Data flow is unstable
Identity is misunderstood
Or side effects are misplaced

Once you respect reference stability and dependency correctness, infinite loops disappear — permanently.

Rebuilding My Static Blog with Build-Time Data and Instant Search

Ravgeet Dhillon — Wed, 04 Feb 2026 17:51:24 +0000

Static sites are supposed to be fast, simple, and reliable. But over time, my personal blog started behaving like a dynamic app - runtime API calls, pagination logic everywhere, and fragmented view counts spread across platforms.

Last week, I rebuilt the blog section of ravgeet.in (Nuxt.js) to fix this properly. The end result is still a static site, but now it feels alive: aggregated view counts, instant search and sorting, and zero runtime dependencies on external APIs.

This post walks through the thinking, architecture, and trade-offs behind that rebuild.

The problem with my old setup

Originally, my blog worked like this:

Blog content lived on Hashnode (canonical source)
Some posts were also cross-posted to Dev.to
Pages fetched blog data at runtime using Hashnode’s GraphQL API
Pagination logic (hasNextPage, cursors) lived inside the UI

This had a few downsides:

A static site depending on live APIs felt wrong
Local development and builds were slower and flaky
Adding features like search or sorting would require more APIs

I wanted the blog to stay static - but smarter.

Build-time data as a contract

The core decision was simple:

Move all external data fetching to build time, and treat the result as immutable static data.

Instead of fetching blogs at runtime, I introduced a build step that:

Fetches blogs from Hashnode
Fetches articles from Dev.to
Matches the same article across platforms
Aggregates view counts
Writes everything into a single JSON file

At runtime, the site only reads from that JSON.

Hashnode + Dev.to
        ↓
Build-time fetch & normalize
        ↓
static/blogs.json
        ↓
Nuxt UI (search, sort, views)

This one decision simplified everything else.

Fetching and aggregating blog data

Hashnode: canonical content

Hashnode remains the source of truth for:

Title, slug, content, tags
Publish date
Cover image
Base view count

I fetch all posts using Hashnode’s GraphQL API with pagination handled inside a Node.js script.

Dev.to: distribution and extra reach

Dev.to is where additional readers come from, so ignoring those views felt wrong.

Using the Dev.to API (with a personal access token), I fetch all my articles and extract:

slug
canonical_url
page_views_count

Matching articles across platforms

This is the tricky part. Articles are matched using a layered strategy:

Slug match
Canonical URL match
Title match

Once matched, the final view count becomes:

combinedViews = hashnodeViews + devtoViews

The output for each blog includes:

Combined views
Platform-specific views (for debugging)
Dev.to URL (if matched)

Writing the static data contract

All processed data is written to the static/blogs.json file.

This file is:

Generated at build time
Git-ignored
Treated as read-only by the app

It also includes metadata like the last updated time and the total blog count.

This JSON file effectively replaces my entire blog API.

Replacing runtime APIs with static services

Previously, services/blogs.js made live GraphQL calls. After the refactor:

The service dynamically imports blogs.json
find, findOne, and search all operate locally
No Axios
No pagination state
No network failures

From the UI’s perspective, nothing changed - but under the hood, everything became predictable.

Instant search and sorting

Once all blog data is local, search becomes trivial.

I added:

Client-side text search (title, brief, tags)
Sorting by:
- Published date (recent / oldest)
- View count (most / least)

Because the dataset is small and static:

Search results are instant
No debouncing hacks
No loading states
Sorting is deterministic

This dramatically improves discoverability without introducing a search service.

Trade-offs and lessons learned

This approach isn’t perfect:

Build time increases slightly
The JSON file grows over time
It’s not suitable for real-time analytics

But for a personal blog, the trade-offs are worth it.

The key takeaways from the refactor that made me realize that:

Static doesn’t mean lifeless
Build-time data pipelines are underrated
One clean data contract simplifies UI, UX, and performance

If you’re curious, the full implementation lives in the ravgeet.in repository.

My 7 Aspirations as a Software Engineer in 2026

Ravgeet Dhillon — Tue, 27 Jan 2026 09:30:14 +0000

2026 feels like a genuine inflection point in my software engineering journey. By February 2026, I will have completed four years as a professional engineer, starting with my first full-time role at CloudAnswers in February 2022. At this stage, my aspirations are less about titles or rapid jumps and more about clarity — how I think, the kinds of problems I choose to solve, and the impact I want my work to have over time.

This post is not a checklist of goals. Instead, it’s a reflection on the direction I want my career to move in — as an engineer who values strong fundamentals, meaningful leverage, and sustainable, long-term growth.

1. Mastering the Fundamentals

By 2026, my primary aspiration is to be fundamentally strong.

Not just "good at React" or "familiar with backend systems" but genuinely comfortable explaining why things behave the way they do:

How JavaScript works under the hood
How browsers render, schedule, and optimize work
How React actually reconciles, schedules, and re-renders
How data flows through a system end-to-end

I want to be the engineer who can debug issues calmly because I understand the system — not because I’ve memorized fixes.

2. Thinking in Systems, Not Just Features

Another aspiration is to shift from feature-level thinking to system-level thinking.

Instead of asking:

“How do I implement this requirement?”

I want my default question to be:

“How does this decision affect the system six months from now?”

That means caring about:

Trade-offs
Maintainability
Operational complexity
Developer experience

Good engineers ship features. Great engineers design systems that survive change. This shift usually happens when you’re trusted to own a product end‑to‑end, responsible not just for fixing bugs or adding features, but for the long‑term health and evolution of the entire system.

3. Becoming a Strong Communicator, Not Just a Coder

By 2026, I want my value to extend beyond code.

This includes:

Explaining complex ideas clearly to other engineers
Writing thoughtful PR descriptions and design docs
Adding working evidence in the PRs in the form of videos and screenshots
Helping juniors build correct mental models
Disagreeing respectfully and productively

Software engineering is a team sport. Clear thinking is useless if it can’t be communicated.

4. Building Leverage Through Tools and Automation

One of my strongest aspirations is to build leverage.

Instead of solving the same problems repeatedly, I want to:

Automate workflows
Build internal tools
Create systems that scale my impact beyond my own output

Leverage is what separates engineers who work hard from engineers who work effectively.

5. Developing Taste and Judgment

Technical skills can be learned. Judgment takes time.

By 2026, I want to develop a strong engineering taste:

Knowing when not to over-engineer
Knowing when technical debt is acceptable
Choosing boring solutions when they’re the right ones

This kind of judgment only comes from reflection, mistakes, and intentional learning.

6. Staying Curious Without Burning Out

Finally, I aspire to stay curious — but sustainable.

Not chasing every new framework, but:

Learning deeply
Picking tools intentionally
Balancing ambition with health

Longevity matters. I want a career that compounds, not one that exhausts me early.

7. Launching at Least One Production-grade App

By the end of 2026, I want to have launched at least one app that real users can use — not just a side project living on GitHub.

This aspiration is less about building a startup and more about closing the loop as an engineer. From idea to execution to feedback, I want to experience the full lifecycle:

Identifying a real problem (even a small one)
Designing a simple, opinionated solution
Making trade-offs under real constraints
Shipping, maintaining, and iterating based on usage

Building a personal app forces a different level of ownership. There is no product manager, no deadline imposed by someone else, and no ambiguity about responsibility. If something is broken, unclear, or poorly designed — it’s on me.

More importantly, it sharpens judgment. You quickly learn what actually matters to users, which abstractions are worth the cost, and which technical decisions age poorly once real usage begins.

Closing Thoughts

My aspirations for 2026 are less about where I work and more about how I work and think.

If I can be a calmer problem-solver, a clearer thinker, and an engineer who builds systems that last — I’ll consider myself on the right path.

I plan to revisit this post at the end of the year to assess how closely my reality aligned with these intentions, honestly.

Realtime Deploy Notifications in Next.js with Toasts

Ravgeet Dhillon — Sun, 25 Jan 2026 05:30:48 +0000

Ever deployed a new version of your app and wished your users got notified instantly while they’re still using the old one? In this post, I'll show you how I built a live build checker in my Next.js app that detects when a new deployment is live and gently nudges users to refresh using a toast notification.

Use case: Helpful for apps deployed on Vercel where static pages and edge functions make it easy to serve outdated content across sessions.

The Stack

Next.js 15
React 19
React-Bootstrap
React-Toastify
Vercel Edge Functions
Supabase Auth (optional)

The Concept

When a new build is deployed, a unique timestamp (NEXT_PUBLIC_BUILD_TIMESTAMP) is injected into the environment. On the client, we poll an API endpoint every few minutes to check if the server's build timestamp has changed. If it has, we notify the user.

Step-by-Step Implementation

1. Add a build timestamp during build time

In next.config.ts:

const now = new Date().toISOString();

const nextConfig = {
  env: {
    NEXT_PUBLIC_BUILD_TIMESTAMP: now,
  },
};

export default nextConfig;

This ensures every build has a unique timestamp baked in at compile time.

2. Create a `/api/build` route

This edge function returns the current server build timestamp:

import { NextRequest } from "next/server";
export const runtime = "edge";

export async function GET(request: NextRequest) {
  return new Response(
    JSON.stringify({ build: process.env.NEXT_PUBLIC_BUILD_TIMESTAMP }),
    {
      headers: { "Content-Type": "application/json" },
    }
  );
}

You can also add authentication here if needed, e.g., for private dashboards.

3. Build a custom hook: `useLiveBuildChecker`

This hook polls the /api/build endpoint periodically and triggers a toast if it detects a new version:

import { useEffect, useRef } from "react";
import { toast } from "react-toastify";
import axios from "axios";

export function useLiveBuildChecker(intervalMin = 5) {
  const currentBuild = useRef(
    process.env.NEXT_PUBLIC_BUILD_TIMESTAMP
  );

  useEffect(() => {
    const checkForUpdate = async () => {
      try {
        const res = await axios.get("/api/build");
        const { build } = res.data;

        if (build && build !== currentBuild.current) {
          toast.info("A new version of this page is available. Refresh to see the latest changes.", {
            autoClose: false,
            position: "bottom-right",
          });
          clearInterval(interval); // stop further polling
        }
      } catch (e) {
        console.error("Update check failed:", e);
      }
    };

    const interval = setInterval(
      checkForUpdate,
      process.env.NODE_ENV === "development" ? 5 * 1000 : intervalMin * 60 * 1000
    );

    return () => clearInterval(interval);
  }, [intervalMin]);
}

4. Add Toast UI + Hook in Layout

Update your app layout to include the ToastContainer and run the hook:

"use client";

import { ReactNode } from "react";
import { ToastContainer } from "react-toastify";
import { useLiveBuildChecker } from "@/hooks/useLiveBuildChecker";

import "react-toastify/dist/ReactToastify.css";

interface Props {
  children: ReactNode;
}

export default function AppLayout({ children }: Props) {
  useLiveBuildChecker(); // default 5-min interval

  return (
    <>
      {children}
      <ToastContainer />
    </>
  );
}

Result

Whenever a new version of your app is deployed, users still active in the browser will get this neat toast:

"A new version of this page is available. Refresh to see the latest changes."

Why This Works

This approach is fully edge-friendly, stateless, and easy to scale. And unlike service worker-based update detection, it works great for SSR/ISR setups and custom dashboards.

Bonus Ideas

You can trigger a background update via service workers.
You can track how long users stay on an outdated version.

Final Thoughts

Keeping users on the latest version of your app improves stability, security, and experience. With just a few lines of code, you can achieve this kind of real-time deploy awareness in any Next.js app.

If you're building a dashboard, personal tool, or even a SaaS product, this is one of those delightfully simple yet powerful improvements.

How I Built a Unified Calendar Dashboard with Next.js, Vercel Edge Functions & No Database

Ravgeet Dhillon — Wed, 05 Nov 2025 04:43:54 +0000

Problem

I was juggling tasks across:

Company ClickUp (for team collaboration)
Notion (for personal to-dos and planning)
Google Calendar (from both company & personal emails)

The chaos was real. I was missing due dates, spending too much time jumping between apps, and lacked a single place to glance at all my tasks.

The Solution

I built a read-only personal dashboard that:

Aggregates tasks/events from ClickUp, Notion, and Google Calendar
Groups tasks as Overdue, Due Today, Upcoming by Date, and No Due Date
Runs entirely on Next.js + Edge Functions
Uses no database, just live API reads
Stores my daily tasks that I need to do
Is password protected and deployed on a Vercel subdomain

Here’s how it looks after multiple polishes:

Tech Stack

Frontend: Next.js App Router + React Bootstrap + TanStack Query
API Layer: Vercel Edge Functions
Auth: Cookie-based with middleware protection
Hosting: Vercel subdomain

Core Features

Unified Task View

Each task is grouped into:

Overdue
Due Today / Tomorrow
Upcoming
No Due Date

It pulls data from these 3 APIs:

const [clickup, notion, calendar] = await Promise.all([
  fetchClickupTasks(),
  fetchNotionTasks(),
  fetchCalendarEvents(),
]);

Auth with Middleware

I implemented simple cookie-based authentication to protect my dashboard. The middleware runs on every request and checks for a valid auth cookie before allowing access to protected routes.

// middleware.ts
import { NextRequest, NextResponse } from "next/server";

export function middleware(request: NextRequest) {
  const auth = request.cookies.get("auth");
  const pathname = request.nextUrl.pathname;

  const publicPaths = ["/login", "/api/login", "/api/logout"];
  if (publicPaths.includes(pathname)) return NextResponse.next();
  if (auth?.value === "1") return NextResponse.next();

  if (pathname.startsWith("/api/")) {
    return NextResponse.json({ error: "Unauthorized" }, { status: 401 });
  }

  return NextResponse.redirect(new URL("/login", request.url));
}

export const config = {
  matcher: [
    "/",
    "/dashboard",
    "/api/events",
    "/api/clickup",
    "/api/notion",
    "/api/calendar",
  ],
};

Modular API Fetchers

I kept the codebase clean by separating each API integration into its own module. This makes it easier to maintain and test each data source independently.

// lib/sources/clickup.ts
export async function fetchClickupTasks() {
  const res = await fetch("https://api.clickup.com/api/v2/...");
  return await res.json();
}

The same goes for Notion & Google Calendar.

Server API Route Example

The backend API routes handle data aggregation from all sources. This route fetches tasks from all three platforms simultaneously and returns them as a unified JSON response.

// app/api/events/route.ts
import { getAllEvents } from "@/lib/getAllEvents";

export async function GET() {
  const { clickup, notion, calendar } = await getAllEvents();
  return Response.json({ clickup, notion, calendar });
}

Frontend UI

The frontend uses TanStack Query for efficient data fetching with automatic caching and background updates. This ensures the dashboard stays responsive while keeping data fresh.

Using TanStack Query for live fetching and caching:

const { data, isLoading } = useQuery({
  queryKey: ["events"],
  queryFn: () => fetch("/api/events").then((res) => res.json()),
});

Then we categorize tasks by due date:

const overdue = allTasks.filter(task => isBefore(task.dueDate, today));
const dueToday = allTasks.filter(task => isToday(task.dueDate));
const upcoming = groupByDate(allTasks.filter(...));
const noDueDate = allTasks.filter(task => !task.dueDate);

The dashboard also includes a "Today's Work List" feature where I can curate specific tasks from across all platforms. This has become my morning ritual - selecting what I want to focus on for the day creates clarity and intention around my daily goals.

Deployment

I deployed the app to Vercel and created a subdomain via Hostinger by:

Creating a subdomain DNS record
Adding the domain to Vercel
Setting env variables and password via the Vercel dashboard

No secrets or tasks are stored — it's 100% live.

What’s Next?

I'm happy with the current version, but I could add the following features in the future:

Month View toggle
Desktop notifications for overdue tasks
Auto-refresh every 10 mins
Tauri or Expo wrapper for mobile

Final Thoughts

This project helped me regain clarity over my weekly tasks. I have pinned this dashboard in my browser and open it every morning to immediately see what matters. It's fast, reliable, and mine.

If you're tired of hopping between 5 apps, build something simple that fits your brain.

Building a Smart Hardware Inventory System That Actually Works

Ravgeet Dhillon — Mon, 13 Oct 2025 18:14:12 +0000

We've all been there. You're rushing to meet a deadline and desperately need that specific USB drive—the one with the 32GB capacity that has your client's backup files. But as you stare at the drawer full of identical-looking pendrives, cables, and chargers, you realize you have no idea which one is which.

Last month, I finally got tired of this digital scavenger hunt and decided to build something better. Not an enterprise-grade asset management system (who has time for that?), but a lightweight, practical solution that would actually solve my real-world problem.

Here's how I built a hardware inventory system that's simple enough to maintain and smart enough to find anything instantly.

The Problem: Hardware Chaos

My desk drawer looked like a tech graveyard. Multiple USB drives, various charging cables, adapters, and dongles—all visually identical but functionally different. The 8GB drive with personal photos looked exactly like the 64GB one with work projects. The USB-C cable that supports fast charging was indistinguishable from the data-only one.

Every time I needed something specific, I'd end up:

Plugging in random drives to check their contents
Testing cables to see what they actually do
Wasting 10-15 minutes on something that should take 30 seconds

There had to be a better way.

The Solution: Smart Simplicity

Instead of over-engineering this, I decided to build something that would work with tools I already use daily. My requirements were simple:

Quick to update - Adding new items shouldn't be a chore
Accessible anywhere - No app installations or complex logins
Physical integration - Must work with actual hardware, not just digital records
Intelligent search - Find items by description, not just exact matches

Building the System: A Step-by-Step Breakdown

Step 1: The Foundation - Google Sheets as a Database

I started with a clean Google Sheet with these columns:

ID: Auto-generated unique identifier
Type: Category like "USB Drive", "Cable", "Charger"
Description: The magic field where I describe each item in plain English
Date Added: Automatic timestamp
Status: Available, In Use, Lost

Nothing revolutionary here, but the key was keeping it simple enough that I'd actually maintain it.

Step 2: Smart ID Generation with Apps Script

Manual ID assignment? No thanks. I wrote a Google Apps Script function that generates short, unique IDs automatically:

function generateUniqueID() {
  const sheet = SpreadsheetApp.getActiveSheet();
  const existingIDs = sheet.getRange('A:A').getValues().flat();

  let newID;
  do {
    newID = Math.random().toString(36).substring(2, 5).toUpperCase();
  } while (existingIDs.includes(newID));

  return newID;
}

This creates memorable 3-character IDs like XR7 or K2M. Short enough to write on tiny labels, unique enough to avoid conflicts.

Step 3: Bridging Digital and Physical Worlds

Here's where it gets practical. I ordered a pack of small adhesive labels and a fine-tip permanent marker. Every time I add a new item to the sheet:

The system generates a unique ID
I write that ID on a physical label
I stick the label directly on the hardware

Now every pendrive, cable, and charger has its own "name tag." When I need something, I just check the physical tag and look it up instantly.

Pro tip: For items too small for labels (like tiny dongles), I use small zip-lock bags with labeled sticky notes.

Step 4: Web Access Without the Hassle

Opening Google Sheets every time felt clunky. Instead, I:

Published the sheet as a web app through Apps Script
Set up a custom subdomain using Vercel
Created a clean, mobile-friendly interface

Now I can check my inventory from my phone while standing in front of my hardware drawer. Game-changer.

Step 5: AI-Powered Search That Actually Understands

This is where the system gets genuinely smart. Instead of remembering exact product names or scrolling through rows, I integrated OpenAI search that understands natural language queries:

"Find the Kingston drive with project files"
"Which cable charges my laptop?"
"Show me USB drives over 16GB"

The AI reads through all my descriptions and instantly returns the matching items with their IDs. It's like having a personal assistant for my hardware drawer.

Real-World Impact: Why This Actually Works

Before: "I need that specific USB drive... proceeds to test 6 different drives"

After: "I need that specific USB drive" → Check AI search → "It's the one labeled K2M" → Done in 30 seconds.

The system works because it addresses the actual problem, not the theoretical one. I don't need enterprise features like check-out workflows or depreciation tracking. I just need to find my stuff quickly.

The Numbers

After 3 months of use:

45 items tracked (drives, cables, adapters, dongles)
Average search time: 15 seconds (down from 10+ minutes)
Time to add new item: 90 seconds

Lessons Learned

What Works Really Well

Physical labels are non-negotiable - Digital-only systems fail in the real world
AI search is a multiplier - Turns a simple spreadsheet into something genuinely intelligent
Simplicity scales - Started with pendrives, now tracks everything

What's Next: Future Improvements

The foundation is solid, so I'm adding features that solve real pain points:

QR Code Integration: Generate QR codes for each item that link directly to their details. Scan with phone → instant access.

Capacity Analytics: Total up storage capacity across all drives, and identify gaps in my hardware collection.

The Bigger Picture

This tiny project reminded me why I love building solutions to real problems. Not every system needs machine learning, microservices, or a dedicated mobile app. Sometimes, Google Sheets, a bit of scripting, and some creativity are exactly the right tools.

The best productivity systems are the ones you actually use. And for keeping track of my ever-growing collection of tech accessories, this simple approach has been perfect.

Building a Basic AI Agent

Ravgeet Dhillon — Sat, 11 Oct 2025 13:35:15 +0000

As developers, we constantly face a dilemma: how do we make our code flexible enough to handle natural human requests without hardcoding every possible scenario?

While working on various automation projects, I kept running into the same pattern—users would ask for something in plain English, like "Can you calculate 2+25-4^2? or "Process these files and send me a summary", but my code was rigid, expecting specific formats and predefined workflows.

The breakthrough came when I realized: What if AI handled the planning, and I just focused on building solid, reusable functions? Instead of trying to anticipate every user request, let AI interpret the intent and dynamically orchestrate my functions.

This post walks through building a mini AI agent framework that separates what you can do (functions) from how to do it (AI planning). The result? Code that adapts to human intent rather than forcing humans to adapt to your interface.

The Problem: Traditional Code vs. Human Intent

How many times have you written code that looks like this?

def complex_math_solver(expression):
    # Parse expression
    # Apply PEMDAS rules
    # Handle edge cases
    # Return result
    pass

The problem? You're cramming parsing logic, mathematical rules, and execution into one monolithic function. What if we could separate these concerns entirely?

The Solution: AI as a Function Orchestrator

Instead of hardcoding business logic, what if we let AI handle the planning while we focus on building atomic, reusable functions?

Here's the architecture:

Step 1: Define Atomic Functions

First, we create simple, single-purpose functions that do one thing well. Think of these as your building blocks—each function is pure, testable, and completely independent. The key is keeping them atomic so AI can combine them in any order to solve complex problems.

def sum(a, b):
    return a + b

def multiply(a, b):
    return a * b

def power(a, b):
    return a ** b

# Function registry for dynamic execution
FUNCTIONS = {
    "sum": sum,
    "multiply": multiply,
    "power": power,
}

Step 2: Document Your Functions (For AI)

Next, we create clear documentation for each function. This isn't just good practice — it's essential for AI to understand what each function does and how to use it. Think of this as your function's "instruction manual" that AI reads to make smart planning decisions.

DOCS = {
    "sum": {
        "description": "Add two numbers",
        "args": {
            "a": {
                "type": "number",
                "description": "a float or int number",
            },
            "b": {
                "type": "number",
                "description": "a float or int number",
            },
        },
    },
    "multiply": {
        "description": "Multiply two numbers",
        "args": {
            "a": {
                "type": "number",
                "description": "a float or int number",
            },
            "b": {
                "type": "number",
                "description": "a float or int number",
            },
        },
    },
    "power": {
        "description": "Raise a to the power of b",
        "args": {
            "a": {
                "type": "number",
                "description": "a float or int number",
            },
            "b": {
                "type": "number",
                "description": "a float or int number",
            },
        },
    },
}

Step 3: Let AI Generate Execution Plans

Finally, we let AI do the heavy lifting — interpreting natural language requests and creating step-by-step execution plans. The AI uses your function documentation to understand what's possible, then figures out the optimal sequence to achieve the user's goal.

def get_action_plan(user_query):
    prompt = f"""
    You are an AI planner. Convert the user's request into a step-by-step plan.

    Available functions:
    {json.dumps(DOCS, indent=2)}

    User's query: "{user_query}"

    Return a JSON plan with ordered steps.
    """

    response = openai.chat.completions.create(
        model="gpt-4o-mini",
        messages=[{"role": "user", "content": prompt}],
        temperature=0
    )
    return json.loads(response.choices[0].message.content)

Real Example: "Solve 2+2*5+4^2"

When a user sends this request to the system, it gets passed to OpenAI along with the function documentation. The AI analyzes the mathematical expression, applies PEMDAS rules, and returns a structured JSON plan that breaks down the calculation into atomic steps using the available functions.

Input: Natural language request

AI Output: Structured execution plan

{
  "steps": [
    { "function": "power", "args": { "a": 4, "b": 2 } },
    { "function": "multiply", "args": { "a": 2, "b": 5 } },
    { "function": "sum", "args": { "a": 2, "b": "<result_of_step_2>" } },
    {
      "function": "sum",
      "args": { "a": "<result_of_step_3>", "b": "<result_of_step_1>" }
    }
  ]
}

Execution Output:

Step 1: power(4, 2) → 16
Step 2: multiply(2, 5) → 10
Step 3: sum(2, 10) → 12
Step 4: sum(12, 16) → 28

Final Result: 28

The Magic: Dynamic Plan Execution

This function takes the AI-generated plan and executes it step by step. The key insight is result chaining—each step can reference outputs from previous steps using placeholders like <result_of_step_1>. The system automatically resolves these references, creating a dynamic pipeline where complex calculations emerge from simple function compositions.

def execute_plan(plan):
    results = {}
    for idx, step in enumerate(plan["steps"], start=1):
        func_name = step["function"]
        args = step["args"]

        # Replace placeholders with previous results
        for k, v in args.items():
            if isinstance(v, str) and v.startswith("<result_of_step_"):
                step_idx = int(v.split("_")[-1].replace(">", ""))
                args[k] = results[step_idx]

        # Execute function dynamically
        func = FUNCTIONS[func_name]
        result = func(**args)
        results[idx] = result

        print(f"Step {idx}: {func_name}({args}) → {result}")

    return results[len(results)]

Why This Architecture Wins

Separation of Concerns

You write: Pure, testable functions
AI handles: Complex planning and orchestration
System manages: Execution flow and state

Human-in-the-Loop Safety

if "error" in plan:
    print("❌ Error in plan generation:")
    print(plan["error"]["message"])
    sys.exit(1)  # Safe exit on planning failures

For example, if a user asks "Divide 10 by 0 and add 5", the AI can detect this is mathematically impossible and return an error response like:

{
  "error": {
    "message": "Cannot divide by zero - this operation is undefined in mathematics"
  }
}

This prevents dangerous operations from executing and provides clear feedback to users.

Infinite Extensibility

Today, it's math functions:

FUNCTIONS = {
    "sum": sum,
    "multiply": multiply,
    "divide": divide
}

Tomorrow it could be anything:

FUNCTIONS = {
    "read_file": read_file,
    "send_email": send_email,
    "query_database": query_db,
    "fetch_weather": weather_api,
    "analyze_sentiment": sentiment,
}

Real-World Applications

File Operations

"Take all .txt files in /docs, extract headings, and create a summary document"

Required Functions: list_files(), read_file(), extract_headings(), create_document(), write_file()

API Orchestration

"Get weather for New York, if it's raining, send a Slack message to #general"

Required Functions: fetch_weather(), check_condition(), send_slack_message()

Data Pipeline

"Load sales.csv, calculate monthly averages, generate a chart, and email it to the team"

Required Functions: load_csv(), calculate_average(), group_by_month(), generate_chart(), send_email()

MCP Server Integration

"Query our customer database, analyze sentiment of recent feedback, and create a dashboard"

Required Functions: query_database(), analyze_sentiment(), aggregate_data(), create_dashboard(), save_report()

The Bigger Picture

This isn't just a math solver — it's a mini AI agent framework. The system provides:

Function Library: Atomic, reusable components
AI Planner: Intelligent request interpretation
Execution Engine: Safe, traceable function orchestration
Human Oversight: Approval and error handling

What's Next?

Add more function types (file ops, API calls)
Implement approval workflows (show plan before execution)
Add function validation (type checking, parameter validation)
Build a web interface (make it accessible to non-developers)
Integrate with MCP servers (extend to complex business logic)

The bottom line: Stop hardcoding business logic. Let AI handle the planning, you handle the implementation. The result? More flexible, maintainable, and extensible code that adapts to user intent rather than forcing users to adapt to your interface.

The ultimate guide to Python logging

Ravgeet Dhillon — Wed, 27 Aug 2025 04:30:31 +0000

When an application runs, it performs a tremendous number of tasks, with many happening behind the scenes. Even a simple to-do application has more than you'd expect. The app will at a bare minimum have tons of tasks like user logins, creating to-dos, updating to-dos, deleting to-dos, and duplicating to-dos. The tasks an application performs can result in success or potentially result in some errors.

For anything you're running that has users, you'll need to at least consider monitoring events happening so that they can be analyzed to identify bottlenecks in the performance of the application. This is where logging is useful. Without logging, it's impossible to have insight or observability into what your application is actually doing.

In this article, you'll learn how to create logs in a Python application using the Python logging module. Logging can help Python developers of all experience levels develop and analyze an application's performance more quickly. Let's dig in!

Read the full blog on Honeybadger.

The ultimate guide to Python logging - Honeybadger Developer Blog

Logging is a valuable tool for performance, monitoring, and debugging. Jump into this article to learn best practices for practical Python logging.

honeybadger.io

Thanks for reading 💜

I publish a monthly newsletter in which I share personal stories, things that I am working on, what is happening in the world of tech, and some interesting dev-related posts which I come across while surfing the web.

Connect with me through Twitter • LinkedIn • Github or send me an Email.

— Ravgeet, Full Stack Developer and Technical Content Writer

Working with Markdown in Python

Ravgeet Dhillon — Wed, 27 Aug 2025 04:28:57 +0000

If you use the Internet, you have surely come across the term Markdown. Markdown is a lightweight markup language that makes it very easy to write formatted content. It was created by John Gruber and Aaron Swartz in 2004. It uses very easy-to-remember syntax and is therefore used by many bloggers and content writers around the world. Even this blog that you are reading is written and formatted using Markdown.

Markdown is one of the most widely used formats for storing formatted data. It easily integrates with Web technologies, as it can be converted to HTML or vice versa using Markdown compilers. It allows you to write HTML entities, such as headings, lists, images, links, tables, and more without much effort or code. It is used in blogs, content management systems, Wikis, documentation, and many more places.

In this article, you'll learn how to work with Markdown in a Python application using different Python packages, including markdown, front matter, and markdownify.

Read the full blog on Honeybadger.

Working with Markdown in Python - Honeybadger Developer Blog

Markdown makes it easy to add syntax to your plain text documents for readability and machine parsing. In this article, learn how to work with markdown in Python using the _python-markdown_ package.

honeybadger.io

Thanks for reading 💜

Connect with me through Twitter • LinkedIn • Github or send me an Email.

— Ravgeet, Full Stack Developer and Technical Content Writer

Handling undo functions in rich text editors

Ravgeet Dhillon — Fri, 01 Aug 2025 12:38:55 +0000

Undo and redo operations are a must-have feature in any rich text editor – they’re a user's safety net. For a great user experience (UX), users need to solve their editing problems in a rich text editor.

An undo/redo button makes your users more confident, because it’s a clear signal that if they make a mistake, they can easily undo and restore changes. For example, if a user accidentally deletes a paragraph, the undo function can restore their work – and spare them a lot of frustration.

However, implementing the undo/redo functionality is complicated. It requires an understanding of data structures like Stack.

You need to know which actions need to be pushed onto the stack, as well as when to push them, and the same goes for the pop operation.

In this article, you'll find out about the complexity of creating and maintaining the undo/redo functionality, and see how the TinyMCE rich text editor makes it easy.

Read the full blog on Tiny.

Handling undo function in rich text editors | TinyMCE

Undo redo function implementation in a rich text editor can be complicated. Learn how to implement undo in TinyMCE with Undo Manager API

tiny.cloud

Thanks for reading 💜

Connect with me through Twitter • LinkedIn • Github or send me an Email.

— Ravgeet, Full Stack Developer and Technical Content Writer

🎬 Introducing Ravgeek: Dev Concepts in 60 Seconds

Ravgeet Dhillon — Sat, 19 Jul 2025 02:41:33 +0000

After years of writing code, debugging endlessly, and explaining APIs to teammates over coffee, I’ve finally taken the plunge into something new — bite-sized developer explainers on YouTube.

📺 My new channel is called Ravgeek (“t” dropped from my name)— and it's built around a simple idea:

Make technical concepts simple, fun, and fast.

Whether it’s understanding what a REST API is, how Git works, or when to use GraphQL, each video is designed to explain core ideas in under 60 seconds — in a way that’s accessible to beginners and still fun for experienced devs.

Here’s a video in which I explain - “What is prompt engineering”:

You’ll see:

⚡️ Rapid, to-the-point explanations
🎙️ Conversational storytelling (think devs talking over chai)
🎨 Animations, avatars, and a touch of humor

This has been a passion project for me — combining my love for coding, storytelling, and design — and I’m excited to finally share it with the world.

👉 Check out the channel: youtube.com/@ravgeek

💬 And if you like what you see, hit that subscribe button and let me know what topic you'd like me to cover next.

Let’s learn, laugh, and geek out together.

Forem: Ravgeet Dhillon

My First Electronics Project - Building a Real-Time Power Outage Monitor with ESP32 and Slack

The Solution

The Hardware Stack

Engineering the "Flicker Filter"

Watch the Journey

Closing Thoughts

Debugging and Stopping Infinite Render Loops in React

What an Infinite Render Loop Really Is

The Fastest Way to Reproduce the Bug

Minimal reproduction checklist

The #1 Root Cause: Unstable References

Identity vs Equality

Example: Object in dependencies

Stabilizing References with Memoization

Fix with memoization

Choosing Correct Dependencies (Not Fewer)

Linting That Actually Helps

Debugging with why-did-you-render + LLMs

What why-did-you-render does

Basic setup

Feeding logs to an LLM (Copilot / ChatGPT)

Why this works so well with LLMs

Final Thought

Rebuilding My Static Blog with Build-Time Data and Instant Search

The problem with my old setup

Build-time data as a contract

Fetching and aggregating blog data

Hashnode: canonical content

Dev.to: distribution and extra reach

Matching articles across platforms

Writing the static data contract

Replacing runtime APIs with static services

Instant search and sorting

Trade-offs and lessons learned

My 7 Aspirations as a Software Engineer in 2026

1. Mastering the Fundamentals

2. Thinking in Systems, Not Just Features

3. Becoming a Strong Communicator, Not Just a Coder

4. Building Leverage Through Tools and Automation

5. Developing Taste and Judgment

6. Staying Curious Without Burning Out

7. Launching at Least One Production-grade App

Closing Thoughts

Realtime Deploy Notifications in Next.js with Toasts

The Stack

The Concept

Step-by-Step Implementation

1. Add a build timestamp during build time

2. Create a /api/build route

3. Build a custom hook: useLiveBuildChecker

4. Add Toast UI + Hook in Layout

Result

Why This Works

Bonus Ideas

Final Thoughts

How I Built a Unified Calendar Dashboard with Next.js, Vercel Edge Functions & No Database

Problem

The Solution

Tech Stack

Core Features

Unified Task View

Auth with Middleware

Modular API Fetchers

Server API Route Example

Frontend UI

Deployment

What’s Next?

Final Thoughts

Building a Smart Hardware Inventory System That Actually Works

The Problem: Hardware Chaos

The Solution: Smart Simplicity

Building the System: A Step-by-Step Breakdown

Step 1: The Foundation - Google Sheets as a Database

Step 2: Smart ID Generation with Apps Script

Step 3: Bridging Digital and Physical Worlds

Step 4: Web Access Without the Hassle

Step 5: AI-Powered Search That Actually Understands

Real-World Impact: Why This Actually Works

The Numbers

Debugging with `why-did-you-render` + LLMs

What `why-did-you-render` does

2. Create a `/api/build` route

3. Build a custom hook: `useLiveBuildChecker`