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:

1. Grounding Geometry: Moving the ground wires to the same side of the board to stabilize the reference voltage.

2. 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!

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:

1. Component renders

2. Some reactive logic runs (effect, watcher, computed, subscription)

3. That logic updates the state

4. State update causes a re-render

5. 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:

1. Reproduce the render issue

2. Capture why-did-you-render logs

3. Paste logs + code into an LLM

4. Apply fix

5. 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.

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:

1. Fetches blogs from Hashnode

2. Fetches articles from Dev.to

3. Matches the same article across platforms

4. Aggregates view counts

5. 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:

1. Slug match

2. Canonical URL match

3. 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.

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.

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.

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:

1. Creating a subdomain DNS record

2. Adding the domain to Vercel

3. 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.

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:

1. Quick to update - Adding new items shouldn't be a chore

2. Accessible anywhere - No app installations or complex logins

3. Physical integration - Must work with actual hardware, not just digital records

4. 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:

1. The system generates a unique ID

2. I write that ID on a physical label

3. 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:

1. Published the sheet as a web app through Apps Script

2. Set up a custom subdomain using Vercel

3. 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.

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:

1. Function Library: Atomic, reusable components

2. AI Planner: Intelligent request interpretation

3. Execution Engine: Safe, traceable function orchestration

4. Human Oversight: Approval and error handling

What's Next?

1. Add more function types (file ops, API calls)

2. Implement approval workflows (show plan before execution)

3. Add function validation (type checking, parameter validation)

4. Build a web interface (make it accessible to non-developers)

5. 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.

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.

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

However, because of the noise, it’s hard to set aside the time to figure out the necessary requirements: does it need an opt-in and opt-out feature? Audience segmentation? Personalization?

The work involved just keeps piling up.

The good news is that in-app notifications (the kind of notifications that give useful information on screen after a change or event), are easy to handle with a reliable rich text editor such as TinyMCE. The editor has a notifications API that can communicate vital information to the user, and is easy and quick to set up. In this article, you'll find a guide on how to set up and manage notifications in the TinyMCE rich text editor, with NotificationManager API.

Read the full blog on Tiny.

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

If you're nodding your head (and possibly rubbing your stiff neck), you're not alone. In our hyper-connected world, time has a sneaky way of slipping through our fingers like sand – or like that last slice of pizza when you're not paying attention.

That's why I built a session tracker that lives right in your Mac's menu bar. It's like having a gentle, persistent friend who reminds you to take breaks, tracks your work patterns, and occasionally judges your life choices (in the nicest possible way).

What Does This Digital Time Wizard Do?

Our session tracker is basically a sophisticated time-keeping ninja that:

1. Tracks Your Current Work Session - It knows when you start working and keeps a running timer

2. Detects Sleep/Wake Cycles - Smartly figures out when you've been away from your computer

3. Logs Daily Activity - Keeps a record of all your work sessions throughout the day

4. Sends Gentle Reminders - Politely suggests you take a break after an hour (because your eyes and back will thank you)

5. Shows Beautiful Stats - Displays your current session time and daily totals right in your menu bar

Think of it as a Fitbit for your productivity, but instead of counting steps, it's counting the minutes you spend glued to your screen.

The Magic Behind the Curtain

This isn't just any ordinary timer script – it's a surprisingly sophisticated piece of bash wizardry that handles all sorts of edge cases:

Smart Session Detection

The script doesn't just start counting from when you run it. It's smart enough to:

• Detect when your Mac has been rebooted

• Figure out when you've been away (sleeping, lunch break, or that inevitable YouTube rabbit hole)

• Resume tracking seamlessly when you return

Intelligent Time Gap Detection

Here's where it gets clever: the script monitors for gaps in activity longer than 2 minutes. If it detects you've been away, it logs your previous session and starts a new one. It's like having a personal assistant who's really good at reading between the lines.

Cross-Reboot Persistence

Even if you restart your Mac, the script remembers your previous session and can estimate when it ended. It's like having a time-tracking elephant – it never forgets.

Setting Up Your New Digital Productivity Buddy

Ready to get this bad boy running on your Mac? Here's how to set it up:

Prerequisites

First, you'll need xbar (formerly BitBar), which is a fantastic tool that lets you put the output of any script in your Mac's menu bar:

# Install xbar using Homebrew
brew install xbar

If you don't have Homebrew installed, grab it from brew.sh first.

Optional but Recommended: Better Notifications

For prettier notifications, install terminal-notifier:

brew install terminal-notifier

Don't worry if you skip this – the script will fall back to macOS's built-in notification system.

Installing the Script

1. Create the xbar plugins directory (if it doesn't exist):

mkdir -p "~/Library/ApplicationSupport/xbar/plugins"

2. Create the script file:

nano "~/Library/Application Support/xbar/plugins/current-session.1m.sh"

3. Copy and paste the following code:

#!/bin/bash

# Set PATH to include common locations
export PATH="/usr/local/bin:/opt/homebrew/bin:$PATH"

# File to store the session start time
SESSION_FILE="/tmp/current_session_start"
# File to store daily activity log
DAILY_LOG_FILE="/tmp/daily_activity_$(date +%Y%m%d)"

# Get current time
CURRENT_TIME=$(date +%s)

# Check if system was recently awakened by looking at uptime vs session file age
UPTIME_SECONDS=$(sysctl -n kern.boottime | awk '{print $4}' | sed 's/,//')
BOOT_TIME=$(date -r "$UPTIME_SECONDS" +%s 2>/dev/null || echo "$CURRENT_TIME")

# If session file doesn't exist or is older than boot time, create new session
if [ ! -f "$SESSION_FILE" ]; then
  SESSION_START="$CURRENT_TIME"
  SESSION_FILE_NEEDS_UPDATE=true
else
  STORED_TIME=$(cat "$SESSION_FILE")

  # Check if the stored time is valid (numeric and reasonable)
  if ! [[ "$STORED_TIME" =~ ^[0-9]+$ ]] || [ "$STORED_TIME" -lt 1000000000 ] || [ "$STORED_TIME" -gt $((CURRENT_TIME + 86400)) ]; then
    # Invalid timestamp, start new session
    SESSION_START="$CURRENT_TIME"
    SESSION_FILE_NEEDS_UPDATE=true
  elif [ "$STORED_TIME" -lt "$BOOT_TIME" ]; then
    # Session file is from before last boot, start new session
    SESSION_START="$CURRENT_TIME"
    SESSION_FILE_NEEDS_UPDATE=true
  else
    # Check if we've been asleep (gap in timestamps)
    LAST_CHECK_FILE="/tmp/last_session_check"
    if [ -f "$LAST_CHECK_FILE" ]; then
      LAST_CHECK=$(cat "$LAST_CHECK_FILE")
      TIME_GAP=$((CURRENT_TIME - LAST_CHECK))

      # If gap is more than 2 minutes, assume we were asleep and start new session
      if [ "$TIME_GAP" -gt 120 ]; then
        SESSION_START="$CURRENT_TIME"
        SESSION_FILE_NEEDS_UPDATE=true
      else
        SESSION_START="$STORED_TIME"
        SESSION_FILE_NEEDS_UPDATE=false
      fi
    else
      SESSION_START="$STORED_TIME"
      SESSION_FILE_NEEDS_UPDATE=false
    fi
  fi
fi

# Track daily activity - check if we need to log previous session before updating files
LAST_CHECK_FILE="/tmp/last_session_check"
NEW_SESSION_STARTED=false

# Check if we're about to start a new session and need to log the previous one
if [ -f "$LAST_CHECK_FILE" ] && [ -f "$SESSION_FILE" ]; then
  LAST_CHECK=$(cat "$LAST_CHECK_FILE")
  PREV_SESSION_START=$(cat "$SESSION_FILE")
  TIME_GAP=$((CURRENT_TIME - LAST_CHECK))

  # If gap detected and we have a valid previous session, log it before starting new session
  if [ "$TIME_GAP" -gt 120 ] && [ "$PREV_SESSION_START" -lt "$LAST_CHECK" ]; then
    PREV_SESSION_DURATION=$((LAST_CHECK - PREV_SESSION_START))
    # Only log sessions longer than 1 minute
    if [ "$PREV_SESSION_DURATION" -gt 60 ]; then
      echo "$PREV_SESSION_START $LAST_CHECK $PREV_SESSION_DURATION" >> "$DAILY_LOG_FILE"
    fi
    NEW_SESSION_STARTED=true
  fi
elif [ ! -f "$LAST_CHECK_FILE" ] && [ -f "$SESSION_FILE" ]; then
  # First run after boot - check if we should log a session from before reboot
  PREV_SESSION_START=$(cat "$SESSION_FILE")
  if [ "$PREV_SESSION_START" -lt "$BOOT_TIME" ]; then
    # Session was from before boot, try to estimate when it ended (use boot time)
    PREV_SESSION_DURATION=$((BOOT_TIME - PREV_SESSION_START))
    if [ "$PREV_SESSION_DURATION" -gt 60 ] && [ "$PREV_SESSION_DURATION" -lt 86400 ]; then
      # Only log if duration seems reasonable (between 1 minute and 24 hours)
      echo "$PREV_SESSION_START $BOOT_TIME $PREV_SESSION_DURATION" >> "$DAILY_LOG_FILE"
    fi
  fi
fi

# Update session file if we're starting a new session
if [ "$SESSION_FILE_NEEDS_UPDATE" = true ]; then
  echo "$SESSION_START" > "$SESSION_FILE"
  # Reset notification tracking for new session
  rm -f "/tmp/last_rest_notification"
fi

# Update the last check time
echo "$CURRENT_TIME" > "/tmp/last_session_check"

# Calculate the session duration in seconds
SESSION_DURATION=$((CURRENT_TIME - SESSION_START))

# Check if we need to show a rest notification (every hour)
NOTIFICATION_FILE="/tmp/last_rest_notification"
if [ "$SESSION_DURATION" -gt 3600 ]; then
  # Check if we've already shown a notification for this hour
  CURRENT_HOUR=$((SESSION_DURATION / 3600))
  if [ -f "$NOTIFICATION_FILE" ]; then
    LAST_NOTIFICATION_HOUR=$(cat "$NOTIFICATION_FILE")
  else
    LAST_NOTIFICATION_HOUR=0
  fi

  # Show notification if we haven't shown one for this hour yet
  if [ "$CURRENT_HOUR" -gt "$LAST_NOTIFICATION_HOUR" ]; then
    # Check if terminal-notifier is available
    if command -v terminal-notifier >/dev/null 2>&1; then
      terminal-notifier -title "Session Tracker" -subtitle "Time for a rest" -message "You've been working for ${CURRENT_HOUR} hour(s). Consider taking a break!" -sound funk -group "session-tracker"
    else
      # Fallback to osascript if terminal-notifier is not available
      osascript -e "display notification \"You've been working for ${CURRENT_HOUR} hour(s). Consider taking a break!\" with title \"Session Tracker\" subtitle \"Time for a rest\" sound name \"Glass\""
    fi
    echo "$CURRENT_HOUR" > "$NOTIFICATION_FILE"
  fi
fi

# Calculate total daily activity
TOTAL_TODAY=0
if [ -f "$DAILY_LOG_FILE" ]; then
  while read -r start_time end_time duration; do
    if [ -n "$duration" ] && [ "$duration" -gt 0 ]; then
      TOTAL_TODAY=$((TOTAL_TODAY + duration))
    fi
  done < "$DAILY_LOG_FILE"
fi

# Add current session to today's total
TOTAL_TODAY=$((TOTAL_TODAY + SESSION_DURATION))

# Convert duration to human-readable format
DURATION_HOURS=$((SESSION_DURATION / 3600))
DURATION_MINUTES=$(( (SESSION_DURATION % 3600) / 60 ))
DURATION_SECONDS=$((SESSION_DURATION % 60))

# Convert total daily time to human-readable format
TOTAL_HOURS=$((TOTAL_TODAY / 3600))
TOTAL_MINUTES=$(( (TOTAL_TODAY % 3600) / 60 ))

# Format the session output
if [ $DURATION_HOURS -gt 0 ]; then
  DURATION_STRING="${DURATION_HOURS}h ${DURATION_MINUTES}m"
else
  DURATION_STRING="${DURATION_MINUTES}m"
fi

# Format the daily total output
if [ $TOTAL_HOURS -gt 0 ]; then
  TOTAL_STRING="${TOTAL_HOURS}h ${TOTAL_MINUTES}m"
else
  TOTAL_STRING="${TOTAL_MINUTES}m"
fi

# Output the session duration and daily total
# Add warning indicator if session is over 1 hour
if [ "$SESSION_DURATION" -gt 3600 ]; then
  echo "⚠️ $DURATION_STRING | size=10"
else
  echo "🕒 $DURATION_STRING | size=10"
fi
echo "---"
echo "📊 Current Session: $DURATION_STRING"
echo "📅 Today Total: $TOTAL_STRING"

# Show session breakdown if there are previous sessions
if [ -f "$DAILY_LOG_FILE" ] && [ -s "$DAILY_LOG_FILE" ]; then
  SESSION_COUNT=$(wc -l < "$DAILY_LOG_FILE")
  echo "🔢 Sessions Today: $((SESSION_COUNT + 1))"
fi

# Add rest reminder in dropdown if session is over 1 hour
if [ "$SESSION_DURATION" -gt 3600 ]; then
  echo "---"
  echo "⏰ Take a break! You've been working for over an hour | color=orange"
fi

4. Make it executable:

chmod +x "~/Library/Application Support/xbar/plugins/current-session.1m.sh"

5. Start xbar and refresh:

   • Launch xbar from your Applications folder

   • Click the xbar icon in your menu bar and select "Refresh all"

Understanding the Code: A Gentle Journey Through Bash Land

Let's break down what this script does, step by step:

The Setup Phase

SESSION_FILE="/tmp/current_session_start"
DAILY_LOG_FILE="/tmp/daily_activity_$(date +%Y%m%d)"

We store our session data in temporary files. The daily log file includes the date, so each day gets its own log file. It's like having a new diary page for each day!

The Detective Work

UPTIME_SECONDS=$(sysctl -n kern.boottime | awk '{print $4}' | sed 's/,//')
BOOT_TIME=$(date -r "$UPTIME_SECONDS" +%s 2>/dev/null || echo "$CURRENT_TIME")

This is where we get all CSI about when your Mac was last booted. We use this to figure out if your session file is from before a reboot.

The Smart Session Logic

The script has several scenarios it handles:

1. First run ever: Creates a new session

2. File exists but invalid: Starts fresh (protects against corrupted data)

3. File is from before reboot: Starts a new session post-reboot

4. Checking for sleep gaps: If there's a gap > 2 minutes, it assumes you were away

The Notification System

if [ "$SESSION_DURATION" -gt 3600 ]; then
  # Time for a break notification logic
fi

After an hour of work, the script gently reminds you to take a break. It's like having a caring friend who's also really good at math.

What You'll See in Action

Once everything is running, you'll see:

• 🕒 45m in your menu bar (showing your current session time)

• ⚠️ 1h 23m when you've been working for over an hour (subtle hint to take a break)

• A dropdown menu showing:

  • 📊 Current Session: 1h 23m

  • 📅 Today Total: 3h 45m

  • 🔢 Sessions Today: 4

  • ⏰ Take a break! reminder (if you've been working too long)

The Beauty of Simplicity

What I love about this solution is that it's:

• Lightweight: Uses minimal system resources

• Unobtrusive: Sits quietly in your menu bar

• Smart: Handles edge cases you didn't even think about

• Customizable: Easy to modify for your specific needs

Customization Ideas

Want to make it your own? Here are some ideas:

1. Change the break reminder interval: Modify the 3600 seconds (1 hour) to whatever works for you

2. Add different notification sounds: Change the sound funk to sound glass, sound ping, etc.

3. Modify the time gap detection: Change the 120 seconds gap threshold

4. Add more detailed logging: Include timestamps, session names, or project tags

The Philosophical Side: Why This Matters

In our always-on world, this simple script serves a deeper purpose. It's not just about tracking time – it's about being mindful of how we spend our most precious resource. By making our work patterns visible, we can:

• Recognize unhealthy patterns (like those 4-hour coding binges)

• Celebrate productivity (look at all those completed sessions!)

• Build better habits (those break reminders really do help)

• Understand our rhythms (maybe you're most productive in the morning?)

Wrapping Up

Building this session tracker was a fun exercise in bash scripting and practical problem-solving. It started as a simple "how long have I been working?" question and evolved into a surprisingly sophisticated time-tracking system.

The best part? It's taught me to actually take breaks. Turns out, when your computer politely suggests you step away from the screen, you're more likely to listen than when your back is screaming at you.

So go ahead, give it a try! Your future self (and your neck) will thank you. And who knows? You might just discover that you're either more or less productive than you thought. Either way, at least you'll know for sure.

As a developer who uses Visual Studio Code daily, I rely heavily on its rich ecosystem of extensions to boost my productivity. But over time, I started noticing my MacBook Air heating up, the fans spinning loudly, and my system becoming sluggish — all while I was just editing code. When I opened the Activity Monitor, I saw one or more mysterious "Code Helper (Plugin)" processes consuming 90–100% CPU, but there was no clear indication of which extension was responsible.

VS Code spawns multiple helper processes, and most of them are generically named, making it incredibly difficult to trace high CPU usage back to a specific extension. This left me guessing — was it Copilot? ESLint? Live Server? I needed a way to monitor these extensions intelligently, without sacrificing performance or productivity.

That's what led me to build a solution — a lightweight tool that monitors CPU usage in real time, maps it to the responsible extension, and alerts me before things spiral out of control. Today, I'll walk you through building a lightweight, real-time CPU monitoring tool that lives in your macOS menu bar and sends notifications when processes exceed your defined thresholds.

What We're Building

Our CPU monitor will:

• Display CPU status directly in the menu bar

• Alert you when any process exceeds 80% CPU usage

• Send native macOS notifications for high CPU processes

• Provide special handling for VS Code extensions and helpers

• Show detailed process information (PID, name, command)

• Indicate when all processes are running normally

Prerequisites

Before we start, you'll need:

• macOS (this guide is macOS-specific)

• xbar installed (formerly BitBar)

• Basic familiarity with shell scripting

The Architecture

Our solution uses a simple but effective approach:

1. xbar Integration: The script runs every 5 minutes (indicated by the .5m. in the filename)

2. Process Monitoring: We use ps to capture all running processes with their CPU usage

3. Threshold Detection: Any process using more than 80% CPU triggers an alert

4. Native Notifications: We leverage macOS's osascript for system notifications

5. Fallback Support: Includes support for terminal-notifier as a backup

The Complete Script

Here's the full vscode-ext-monitor.5m.sh script:

#!/bin/bash

CPU_THRESHOLD=80.0
HIGH_CPU_FOUND=0

# Menu Bar Title
echo "🖥️ CPU Monitor"

# Store process information in a temporary file to avoid subshell issues
TEMP_FILE=$(mktemp)
ps -Ao pid,%cpu,command | grep -v "ps -Ao" | grep -v grep > "$TEMP_FILE"

# Read from the temporary file
while IFS= read -r line; do
  if [ -z "$line" ]; then
    continue
  fi

  cpu=$(echo "$line" | awk '{print $2}')
  pid=$(echo "$line" | awk '{print $1}')
  command=$(echo "$line" | cut -d ' ' -f3-)

  # Skip if CPU is not a valid number or is 0.0
  if ! echo "$cpu" | grep -q '^[0-9]*\.[0-9]*$' || [ "$cpu" = "0.0" ]; then
    continue
  fi

  is_high=$(echo "$cpu > $CPU_THRESHOLD" | bc)

  if [ "$is_high" -eq 1 ]; then
    HIGH_CPU_FOUND=1
    echo "---"
    echo "⚠️ High CPU ($cpu%)"
    echo "PID: $pid"

    # Get process name from command
    process_name=$(echo "$command" | awk '{print $1}' | xargs basename 2>/dev/null || echo "Unknown")
    echo "📱 Process: $process_name"

    # Show truncated command
    echo "💻 ${command:0:60}..."

    notification_title="From CPU Monitor"

    # Special handling for different process types
    if echo "$command" | grep -q ".vscode/extensions"; then
      ext=$(echo "$command" | grep -o "/Users/[^ ]*\.vscode/extensions/[^ ]*")
      echo "🧩 VS Code Extension: $(basename "$ext")"
      notification_message="High CPU: ${cpu}% by VS Code extension $(basename "$ext")"
    elif echo "$command" | grep -q "Code Helper"; then
      echo "🔧 VS Code Helper Process"
      notification_message="High CPU: ${cpu}% by VS Code Helper"
    else
      notification_message="High CPU: ${cpu}% by $process_name"
    fi

    # Desktop notification (macOS only) - with error handling
    if command -v osascript >/dev/null 2>&1; then
      osascript -e "display notification \"$notification_message\" with title \"$notification_title\"" 2>/dev/null || {
        # Fallback: try using terminal-notifier if available
        if command -v terminal-notifier >/dev/null 2>&1; then
          terminal-notifier -title "$notification_title" -message "$notification_message" 2>/dev/null
        fi
      }
    fi
  fi
done < "$TEMP_FILE"

# Clean up temporary file
rm -f "$TEMP_FILE"

if [ "$HIGH_CPU_FOUND" -eq 0 ]; then
  echo "---"
  echo "✅ All processes under ${CPU_THRESHOLD}%"
fi

Key Technical Decisions

1. Avoiding Subshell Issues

Initially, we faced a common bash pitfall where notifications wouldn't work because the while loop was running in a subshell:

# This doesn't work for GUI operations
ps ... | while read line; do
  osascript -e "display notification ..."
done

Solution: We use a temporary file approach to avoid the subshell:

TEMP_FILE=$(mktemp)
ps -Ao pid,%cpu,command > "$TEMP_FILE"
while read line; do
  # Process data and send notifications
done < "$TEMP_FILE"
rm -f "$TEMP_FILE"

2. Robust CPU Validation

We validate CPU values to ensure we're working with actual numeric data:

if ! echo "$cpu" | grep -q '^[0-9]*\.[0-9]*$' || [ "$cpu" = "0.0" ]; then
  continue
fi

This prevents errors from malformed process data.

3. Smart Process Classification

The script intelligently categorizes processes:

• VS Code Extensions: Detected by .vscode/extensions in the command path

• VS Code Helpers: Identified by "Code Helper" in the command

• General Processes: Everything else gets generic handling

4. Notification Reliability

We implement a two-tier notification system:

osascript -e "display notification ..." 2>/dev/null || {
  # Fallback to terminal-notifier if available
  if command -v terminal-notifier >/dev/null 2>&1; then
    terminal-notifier -title "..." -message "..."
  fi
}

Installation and Setup

1. Install xbar if you haven't already:

    brew install --cask xbar
   

2. Create the plugin directory:

    mkdir -p "$HOME/Library/Application Support/xbar/plugins"
   

3. Save the script as vscode-ext-monitor.5m.sh in the plugins directory

4. Make it executable:

    chmod +x "$HOME/Library/Application Support/xbar/plugins/vscode-ext-monitor.5m.sh"
   

5. Launch xbar and refresh to see your new CPU monitor

Customization Options

Adjust the CPU Threshold

Change the threshold by modifying this line:

CPU_THRESHOLD=80.0  # Change to your preferred percentage

Modify the Update Frequency

Rename the file to change how often it runs:

• .1m.sh = Every minute

• .30s.sh = Every 30 seconds

• .10m.sh = Every 10 minutes

Add More Process Types

Extend the classification logic:

elif echo "$command" | grep -q "chrome"; then
  echo "🌐 Chrome Process"
  notification_message="High CPU: ${cpu}% by Chrome"

Troubleshooting

Notifications Not Appearing?

1. Check System Preferences: Ensure notifications are enabled for Terminal in System Preferences > Notifications & Focus

2. Test manually:

    osascript -e 'display notification "Test" with title "Test"'
   

3. Install terminal-notifier as backup:

    brew install terminal-notifier
   

Script Not Running?

1. Verify file permissions:

    ls -la "$HOME/Library/Application Support/xbar/plugins/"
   

2. Check xbar is running and refresh the menu

3. Test the script manually:

    cd "$HOME/Library/Application Support/xbar/plugins/"
    ./vscode-ext-monitor.5m.sh
   

What's Next?

This CPU monitor provides a solid foundation that you can extend further:

• Memory Monitoring: Add RAM usage alerts

• Network Activity: Monitor processes with high network usage

• Historical Tracking: Log high CPU events to a file

• Kill Process Feature: Add menu options to terminate problematic processes

• Custom Thresholds: Different thresholds for different process types

Conclusion

Building system monitoring tools doesn't require complex frameworks or heavy applications. With a simple bash script and xbar, we've created a lightweight, effective CPU monitor that:

• Provides real-time visibility into system performance

• Sends proactive notifications before problems escalate

• Offers detailed process information for quick troubleshooting

• Runs efficiently with minimal system overhead

The beauty of this approach is its simplicity and customizability. You have full control over the monitoring logic, notification behavior, and display format. Plus, since it's just a bash script, you can easily modify it to suit your specific needs.

This CPU monitor has been tested on macOS Sequoia and later. The script should work on earlier versions but may require minor adjustments for notification handling.

Why not make the life of the release team easier by automating the creation of release notes? You can, using a combination of GitHub API and a CI/CD tool like CircleCI. Automate the task of fetching issues and pull requests, and put them in a single place where they can be accessed easily by the release notes team.

In this tutorial, you’ll learn to use the GitHub API and CircleCI to create weekly stats for your GitHub repositories. The plan is to build an automated workflow using CircleCI scheduled pipelines. The pipeline will fetch all the issues and pull requests made during a specified interval, save these stats in a file, and commit this file back to the repository.

Read the full blog on CircleCI.

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

In this post, you’ll walk through:

• How to use Copilot Chat in VS Code

• What it’s best at

• Real-world prompts you can use right away

What Is GitHub Copilot Chat?

Copilot Chat brings the power of ChatGPT directly into VS Code, allowing you to ask natural language questions about your code, request explanations, generate tests, fix bugs, refactor logic, and more — without ever leaving your editor.

It’s like having an AI pair programmer that:

• Understands your code context

• Works inline or in a chat panel

• Helps you learn, debug, and ship faster

What Can You Use Copilot Chat For?

Here are some powerful use cases:

Code Understanding & Explanation

You can highlight any block of code and ask:

• “Explain what this code does”

• “What is the time complexity here?”

• “Why am I getting this TypeError?”

Code Improvement & Refactoring

Ask it to:

• “Refactor this function to be cleaner”

• “Optimize this loop”

• “Suggest better variable names”

Test Generation

Save hours writing boilerplate with prompts like:

• “Write unit tests for this function using Jest”

• “Generate test cases for edge inputs”

Code Conversion & Migration

Let it help with transitions like:

• “Convert this JS code to TypeScript”

• “Rewrite this to use async/await”

• “Switch from useEffect to React Query”

General Cleanup

Ask it to:

• “Remove unused imports”

• “Simplify this logic”

• “Make this more readable”

Some Example Prompts You Can Use Right Now

✅ Tip: You can highlight a code block and then open Copilot Chat to get smarter, context-aware answers.

How to Enable Copilot Chat in VS Code

1. Install the GitHub Copilot Chat extension from the VS Code Marketplace

2. Make sure you’re signed in to GitHub with an active Copilot plan

3. Open the Copilot Chat panel or use Cmd/Ctrl + I to start inline chat

4. Highlight code and right-click → Ask Copilot

Final Thoughts

Copilot Chat takes the promise of AI-assisted development to the next level. It’s not just about writing code faster — it’s about thinking through problems, debugging more efficiently, and learning as you go, all inside your editor.

Dropbox Sign allows you to create and send bulk templates, as well as generate dynamic documents such as sales quotes. In this tutorial, you’ll create a command-line utility for generating sales quote documents using the Dropbox Sign API. You’ll pass input data as command line arguments, creating emailed sales quote documents that customers can sign digitally.

Read the full blog on Dropbox.

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

TL;DR: I implemented a Web Worker–powered filtering system in a React data table component to eliminate UI lag and improve responsiveness when working with large datasets. Here's how and why.

The Problem: Filtering Slows the UI

Our application relies heavily on a custom <NewTable /> component that supports:

• Nested (hierarchical) rows

• Column-based filtering

• Custom filters

• Server-side pagination

As datasets grew into the thousands of rows, filtering became noticeably sluggish. The culprit? All filtering logic ran on the main UI thread, blocking React’s render cycle and causing the interface to freeze temporarily.

Goal

Move heavy data-filtering logic off the main thread using Web Workers, without breaking existing functionality or developer experience.

The Solution: Asynchronous Filtering with Web Workers

We built a pipeline that:

1. Serializes hierarchical data into a flat structure

2. Sends that data to a dedicated Web Worker

3. Worker filters based on column & custom filters

4. Sends back the result

5. Updates the UI reactively and shows a loader while waiting

Implementation Breakdown

1. Set up search.worker.js

We created a Web Worker dynamically using a blob:

const searchWorker = () => {
  onmessage = async (e) => {
    importScripts("https://cdnjs.cloudflare.com/ajax/libs/lodash.js/4.17.21/lodash.min.js");
    importScripts("https://cdnjs.cloudflare.com/ajax/libs/dayjs/1.10.7/dayjs.min.js");

    // ... logic for deep filtering, date handling, and custom filters ...

    postMessage({ success, result });
  };
};

let code = searchWorker.toString();
code = code.substring(code.indexOf("{") + 1, code.lastIndexOf("}"));
const blob = new Blob([code], { type: "application/javascript" });
const workerScript = URL.createObjectURL(blob);

export default workerScript;

2. New Utility Function

A new async utility offloads data filtering:

const asyncFilterDataWithColumnAndCustomFilters = async (
  data,
  columns,
  columnFilters,
  customFilters,
  setData,
  setIsSearching,
) => {
  const searchWorker = new window.Worker(searchWorkerScript);

  const convertedData = data.map(row => ({
    id: row.id,
    values: columns.map(col => col.selector?.(row) ?? row[col.id]),
    items: (row.items || []).map(item => ({
      id: item.id,
      values: columns.map(col => col.selector?.(item) ?? item[col.id]),
    })),
  }));

  searchWorker.postMessage({ data, convertedData, columns, columnFilters, customFilters });

  searchWorker.onmessage = (e) => {
    setData(e.data.result);
    setIsSearching(false);
    searchWorker.terminate();
  };

  searchWorker.onerror = (err) => {
    console.error("Worker error", err.message);
    setIsSearching(false);
    searchWorker.terminate();
  };
};

3. Hook Update

We extended the existing table filter hook:

export const useFilterDataWithColumnAndCustomFilters = ({
  data,
  columns,
  columnFilters,
  customFilters,
  setIsSearching,
}) => {
  const [filteredData, setFilteredData] = useState({ data: [], diff: 0 });

  useEffect(() => {
    asyncFilterDataWithColumnAndCustomFilters(
      data,
      columns,
      columnFilters,
      customFilters,
      setIsSearching,
      setFilteredData
    );
  }, [data, columnFilters, customFilters]);

  return { filteredData: filteredData.data, diff: filteredData.diff };
};

4. Loading Indicator

We updated the table’s loading prop:

<NewTable
  isLoading={isLoading || isSearching}
  // ...
/>

Bonus: What the Worker Can Handle

• BOOLEAN, DATE, DATETIME, and NUMBER types

• Interval filters (e.g. date ranges)

• Null checks: eq: "null" and ne: "null"

• Multi-select picklists

• Filters nested rows and their parents

Benefits

• UI never freezes during filtering

• Filters run faster, even on large datasets

• Code is modular and easy to maintain

• Great user experience with real-time filtering feedback

Key Takeaways

• Use Web Workers to offload expensive tasks in the browser.

• Normalize complex data structures before sending to the worker.

• Gracefully handle worker errors and show meaningful UI states.

• It's surprisingly easy to integrate with React.

Final Thoughts

Offloading filtering to a Web Worker has been one of the most impactful performance wins for our frontend in recent times. If you're working with large tables or slow filters, give workers a shot — your users (and frame rate) will thank you.

Want help integrating something similar into your React app?
Feel free to connect with me.

I wrote this blog post for my company, CloudAnswers.

Here’s how I personally use Copilot + ChatGPT in my daily workflow.

TL;DR: My Quick Comparison

I see Copilot as my coding sidekick inside the editor, and ChatGPT as my thinking partner outside of it.

Real Workflow: Building a React Component

Step 1: I Ask ChatGPT to Help Plan It

When I need something like a responsive navbar with Tailwind CSS, I type:

"Create a responsive navbar with logo, links, and hamburger menu using React and Tailwind."

ChatGPT usually gives me a great starting point with code, accessibility notes, and even file structure suggestions.

Step 2: I Paste That Into VS Code and Let Copilot Take Over

As I begin typing:

function Navbar() {
  return (

Copilot fills in:

<nav className="bg-white shadow-md p-4 flex justify-between items-center">
  <div className="text-xl font-bold">Logo</div>
  ...
</nav>

It handles the obvious stuff—repetitive patterns, responsive classes, even conditional rendering—while I focus on logic.

How I Use Them Together Every Day

1. Rapid Prototyping

• ChatGPT helps me quickly draft UI layouts.

• Copilot finishes JSX, props, and common logic on the fly.

2. Debugging

• When I hit an error, I paste it into ChatGPT and ask:

  "What’s wrong with this error?"

• Then I fix the bug in VS Code with Copilot suggesting inline changes.

3. Writing Tests

• I ask ChatGPT to generate tests for my React components.

• I then use Copilot to autocomplete the repetitive test setup or assertions.

4. Refactoring

• I send messy functions to ChatGPT to break them down and improve naming.

• Back in VS Code, Copilot speeds up implementing the improved version.

5. Explaining My Code

• When I want to document my code or explain it to my team, I ask ChatGPT:

  "Explain this hook and why the useEffect dependency array matters."

My Favorite Productivity Tips

Tip 1: Comment-Driven Prompts for Copilot

// Create a responsive card component with image and title

Copilot often gives me a complete JSX block instantly.

Tip 2: ChatGPT for Documentation

I paste a tricky function into ChatGPT and say:

"Write a JSDoc for this and suggest better variable names."

Tip 3: Code Reviews Get Easier

I now use GitHub Copilot to explain my PRs or generate commit messages. Copilot helps me fix minor issues before I even push.

Bonus Tools I Like

My Final Thoughts

Using both GitHub Copilot and ChatGPT hasn’t just saved me time—it’s leveled up how I think and build.

Copilot gives me instant coding speed in the editor, while ChatGPT helps me think clearly, plan ahead, and document better. Whether I’m building a component, squashing bugs, or writing docs, these two tools make the process smoother.

So if you're a frontend dev like me, give this duo a try. You might never want to code alone again. ✨