Forem: Tejas

Under the Hood: Demystifying Database Internals (InnoDB vs. ARCHIVE)

Tejas — Sun, 24 May 2026 11:38:05 +0000

Most developers treat database engines as black boxes: you write a query, and data magically returns. But when data scales to millions of rows, understanding how that data sits on physical hardware changes how you build systems.

If you throw every single piece of data into your default database setup, your storage costs will eventually skyrocket and your queries will slow down.

To build systems that scale, you need to understand two completely opposing storage philosophies: Page-Based Transactional Storage (InnoDB) and Stream-Based Compressed Storage (ARCHIVE), and how they connect using Table Partitioning.

1. The InnoDB Hierarchy (From Bytes to Tablespaces)

MySQL’s default engine, InnoDB, is built for speed, multi-user accuracy, and heavy read/write traffic. It doesn't just append raw text strings to a file. It manages data through a highly structured, strict multi-tiered hierarchy.

The Storage Stack

Tablespaces: This is the highest logical container. When you turn on modern settings like innodb_file_per_table, every single database table gets its own physical .ibd file on your hard drive.
Extents: To prevent your operating system's filesystem from scattering your table across different physical sectors of your drive, InnoDB allocates space in chunks called Extents. Each extent is exactly 1 Megabyte in size and bundles multiple continuous pages together, ensuring that sequential data stays physically close on disk.
Pages: The Page is the core atomic unit where InnoDB does its actual work. By default, an InnoDB page is exactly 16 Kilobytes. Whenever InnoDB reads or writes data, it loads entire 16KB pages into your server's RAM (the Buffer Pool), even if you only requested a single row.
Rows: At the absolute base of this structure are individual rows, packed tightly inside Data Pages. Because InnoDB uses a Clustered Index B+Tree, your rows are physically sorted and stored on disk by their Primary Key.

2. The ARCHIVE Engine (The Anti-Page Approach)

What if you don’t need to update data? What if you are storing billions of system logs, clickstreams, or audit trails that you only look at when something breaks?

Throwing that into InnoDB is incredibly wasteful because index trees and 16KB page structures bloat your disk usage. The ARCHIVE engine completely flips InnoDB's design on its head to solve this exact problem:

No Fixed Pages: Rather than structuring data into strict 16KB blocks, ARCHIVE treats your data as a continuous, unbounded append-only binary byte stream saved inside an .arz file.
On-the-Fly Stream Compression: When data is inserted, it passes through an in-memory compression buffer. Trailing spaces are stripped out, and an optimized bit-header handles NULL values. The raw rows are then compressed on-the-fly using the zlib algorithm before hitting the disk.
The Index Trade-off: To maintain its tiny footprint, ARCHIVE allows zero secondary indexes. The only permissible index is an AUTO_INCREMENT column.

Because it acts as a raw compressed string of text rather than an indexed block structure, ARCHIVE routinely achieves 3:1 to 10:1 compression ratios compared to InnoDB.

3. Architecture Comparison Matrix

Architectural Feature	InnoDB Engine	ARCHIVE Engine
Storage Layout	Strict 16KB Pages / 1MB Extents	Continuous `zlib` Compressed Byte Stream
Primary File Format	`.ibd` (Data + Indexes combined)	`.arz` (Data) + `.frm` (Metadata)
Write Model	B+Tree Insertion, Page Splitting	Append-Only Stream via Memory Buffer
Supported Mutations	`INSERT`, `SELECT`, `UPDATE`, `DELETE`	`INSERT`, `SELECT` only (WORM model)
Locking Mechanism	Fine-grained Row Locks (MVCC)	Interlaced Row Stream Locking

4. Connecting the Worlds: Table Partitioning & Exchange

Now that you understand both engines, you can combine these mental models into a Hot/Cold Data Tiering System. The goal is simple: Keep recent data (Hot) in InnoDB so it can be updated and indexed quickly. Move older data (Cold) to alternative storage so it takes up less disk space.

Since MySQL doesn't allow you to mix storage engines inside a single partitioned table, we use a strategy called Partition Exchange. This is a metadata-only swap that transfers millions of rows in less than a second.

Step A: Create the Partitioned InnoDB Table

We partition an active InnoDB table by months using a timestamp or date:

CREATE TABLE system_logs (
    log_id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
    log_date DATE NOT NULL,
    subsystem VARCHAR(50) NOT NULL,
    message TEXT NOT NULL,
    PRIMARY KEY (log_id, log_date)
) ENGINE=InnoDB
PARTITION BY RANGE (TO_DAYS(log_date)) (
    PARTITION p_past_month VALUES LESS THAN (TO_DAYS('2026-05-01')),
    PARTITION p_current_month VALUES LESS THAN (TO_DAYS('2026-06-01')),
    PARTITION p_future VALUES LESS THAN MAXVALUE
);

Step B: The Instant Partition Exchange

When a month ends, you want to compress that older data. Running a massive DELETE statement would lock your tables and spike your CPU. Instead, you create an empty, identical InnoDB staging table, and instantly swap the old partition out:

-- 1. Create a temporary staging table matching the schema
CREATE TABLE system_logs_stage LIKE system_logs;
ALTER TABLE system_logs_stage REMOVE PARTITIONING;

-- 2. Instantly swap the old partition into the staging table (Takes < 1 second)
ALTER TABLE system_logs EXCHANGE PARTITION p_past_month WITH TABLE system_logs_stage;

-- 3. Drop the now empty partition from the active table
ALTER TABLE system_logs DROP PARTITION p_past_month;

From here, you can pipe the contents of system_logs_stage directly into an ARCHIVE-backed table to keep your cold logs compressed natively in the database.

5. Production Reality Check: Where the Industry is Today

Is Partition Exchange actually used in production? Yes, every single day. It is the gold standard for dropping or isolating historical data without locking your live tables.

However, while the ARCHIVE engine is an awesome architectural blueprint for stream compression, modern cloud infrastructure teams usually handle the "cold" tiering differently. Today, production database storage and IOPS (Input/Output Operations Per Second) are incredibly expensive. Engineers don't want cold, historical log data sitting on the same live production database instance, even if it is compressed.

Instead, companies use Partition Exchange to isolate old data into a staging table, stream it completely out of MySQL into a cloud data lake (like AWS S3) formatted as hyper-compressed columnar Apache Parquet files, and then drop the staging table entirely. This keeps the live production database lean, fast, and remarkably cheap to run.

Conclusion

When you are building side projects or working through software engineering courses, it is easy to just default to standard database configurations. But looking under the hood changes how you approach application performance.

Understanding the tension between InnoDB's rigid page allocations and ARCHIVE's fluid compression streams helps you think about data access patterns critically - matching the right storage strategy to the right workload is how you move from just writing standard CRUD apps to engineering optimized, production-ready systems.

B-Trees vs. LSM-Trees: Why your Database choice is actually a Trade-off

Tejas — Sun, 10 May 2026 15:12:48 +0000

Introduction
We often treat databases like black boxes. You throw data in, you get data out. But underneath the hood, how that data is physically stored on disk determines if your app scales or crawls. Today, we're looking at the two heavyweights of storage engines: B-Trees and LSM-Trees.

1. B-Trees: The Read Specialist
B-Trees are the backbone of most Relational Databases (RDBMS) like PostgreSQL and MySQL.

How it works: Data is stored in fixed-size "pages." When you update a record, the database finds the specific page and overwrites it in place.
The Big Win: Because the data is strictly ordered and balanced, looking up a specific key is incredibly fast.
The Catch: Writing is "heavy." The DB has to find the exact spot on disk, which leads to random I/O-a major bottleneck for high-velocity data.

2. LSM-Trees: The Write Powerhouse
Log-Structured Merge-Trees (LSM) power the world of NoSQL and Big Data (Cassandra, ScyllaDB, RocksDB).

How it works: Instead of finding a spot to "overwrite," an LSM-tree just appends the new data to a log in memory (MemTable). Periodically, these logs are flushed to disk as sorted files (SSTables).
The Big Win: Writing is nearly instantaneous because the system just appends data sequentially.
The Catch: "Read Penalty." To find a piece of data, the system might have to check multiple files on disk. It uses background "Compaction" to merge these files and keep things clean.

The Comparison Table

Feature	B-Trees	LSM-Trees
Primary Strength	Fast Reads	Fast Writes
Storage Style	Update-in-place	Append-only
I/O Type	Random I/O	Sequential I/O
Common Use	SQL / General Purpose	NoSQL / Time-series / Logging

Which one should you choose?

Pick B-Trees if your application is "Read-Heavy" (e.g., a standard E-commerce site where users browse products more than they update profiles).
Pick LSM-Trees if your application is "Write-Heavy" (e.g., tracking billions of sensor metrics, chat logs, or high-frequency trading data).

Conclusion
System design is the art of choosing which "pain" you can live with. Do you want slower writes for faster reads? Or are you okay with a background cleanup process in exchange for lightning-fast ingestion?

What's your preferred storage engine? Let's discuss in the comments!

Stop Drowning in Vectors: How I Built a Graph-Powered RAG That Actually Scales

Tejas — Tue, 31 Mar 2026 16:19:55 +0000

The Problem with Traditional RAG

Let's be honest - vector-based RAG has a scaling problem. You chunk documents, embed everything, store it in a vector database, and hope semantic similarity finds the right context. But when you're dealing with:

Hundreds of technical documents
Cross-referenced content (citations, related sections)
Hierarchical information (chapters → sections → subsections)

Vector search starts to feel like finding a needle in a haystack of needles. You either blow up your context window or miss critical relationships between documents.

Enter Vectorless RAG

The PageIndex architecture introduced a brilliant alternative: parse documents into hierarchical JSON trees and let the LLM navigate the structure directly. No embeddings. No similarity search. Just pure structural reasoning.

But the original approach had a limitation - it kept everything in memory. Try loading hundreds of document trees simultaneously, and you'll watch your RAM wave goodbye.

Why I Put It on Neo4j

I took the vectorless RAG concept and gave it a persistent backbone: Neo4j Graph Database. Here's what changed:

1. Persistent Memory at Scale

Instead of loading JSON trees into memory, the hierarchical structure lives in Neo4j. Now you can query millions of documents without breaking a sweat. The LLM starts at document roots and walks down only the branches it needs.

2. Cross-Document Relationships

This is where it gets powerful. Want to link a citation in Document A to its source in Document B? Just create a [:REFERENCES] edge. The LLM can traverse these relationships during retrieval, giving you a true reasoning knowledge graph — something vector search simply cannot replicate.

3. Token-Efficient Retrieval

The LLM acts as an agentic navigator. Given a query, it:

Identifies relevant root sections
Queries Neo4j for children nodes
Drills down iteratively until it finds the answer
Ignores irrelevant branches entirely

This saves massive amounts of context tokens compared to dumping entire documents into the prompt.

How It Works

The Graph Structure

Every document becomes a tree in Neo4j:

(Document)-[:HAS_SECTION]->(Chapter)-[:HAS_SUBSECTION]->(Section)-[:HAS_SUBSECTION]->(Subsection)

The central Document node connects to top-level chapters, which recursively connect to sub-sections. Each node can store summaries, page references, and metadata.

Three-Step Workflow

Step 1: Parse Documents

uv run python main.py --pdf_path /path/to/document.pdf

This generates a _structure.json file containing the hierarchical tree. Markdown is supported too:

uv run python main.py --md_path /path/to/document.md

Step 2: Ingest into Neo4j

uv run python -m src.database.ingest --json_path ./results/document_structure.json

The JSON tree becomes nodes and relationships in your graph database.

Step 3: Query with Agentic Retrieval

uv run python -m src.agent.retriever \
  --doc_name document_structure.json \
  --query "What are the key findings in section 2?"

The LLM identifies relevant sections, traverses the graph, and returns precise answers with page references.

Under the Hood

Tech Stack

Neo4j — Graph database for persistent storage
LiteLLM — Unified LLM interface (defaults to llama-3.3-70b via Groq)
PyMuPDF / PyPDF2 — PDF parsing
uv — Lightning-fast Python package management

The Agentic Retrieval Loop

The retriever (src/agent/retriever.py) implements a multi-step reasoning process:

Root Analysis — LLM examines top-level sections to identify candidates
Iterative Drilling — For each candidate, fetch children from Neo4j
Relevance Filtering — LLM decides which branches to explore further
Answer Extraction — Once leaf nodes are reached, extract the answer

This is fundamentally different from vector search. Instead of "find similar chunks," it's "navigate to the right place."

When to Use This Approach

Scenario	Vector RAG	Graph-Powered Vectorless RAG
Simple Q&A over single doc	✅	✅
Cross-document reasoning	❌	✅
Hierarchical content (manuals, specs)	⚠️	✅
Citation/reference tracking	❌	✅
Token-efficient retrieval	⚠️	✅
Massive document collections	❌	✅

What's Next

This is just the foundation. Here's where I'm taking it:

Multi-hop reasoning across document collections
Dynamic reference extraction to auto-build [:REFERENCES] edges
Hybrid search combining graph traversal with optional vector fallback
Streaming responses for real-time navigation feedback

Final Thoughts

Vector embeddings aren't going away, but they're not the only tool in the box. For structured, hierarchical, or cross-referenced content, graph-powered vectorless RAG gives you:

Scalability — millions of documents, zero memory issues
Reasoning — traverse relationships, not just similarities
Efficiency — precise context retrieval, minimal token waste

Sometimes the best way forward is to go back to structure.

🔗 Project Repository: https://github.com/TejasS1233/vectorless_RAG

💬 Questions or ideas? Drop them in the comments - I'd love to hear how you're approaching RAG at scale.

If you found this useful, follow me for more deep dives into practical AI architecture. Next up: building multi-hop reasoning across document graphs.

The "Prompt Doom Loop": Why your AI output gets worse the more you try to fix it

Tejas — Sat, 10 Jan 2026 10:14:25 +0000

The "Prompt Doom Loop" is real. It starts innocently enough. You just need a simple React component or a quick Python script.

You: "Create a responsive navbar with a dark mode toggle."
AI: Generates code.

It’s decent, but it uses float: left for some reason.

You: "Don't use float, use Flexbox."
AI: Refactors to Flexbox, but breaks the toggle logic.

You: "Keep the Flexbox, fix the toggle."
AI: Fixes the toggle, but now the mobile menu is gone.

You: "YOU DELETED THE MOBILE MENU. PUT IT BACK BUT KEEP FLEXBOX."
AI: Apologizes profusely, hallucinates a library that doesn't exist, and reverts to float: left.

You: (30 minutes later): "Forget it." Cmd+Z, Cmd+Z, Cmd+Z... back to the first result.

We have all been there. We treat prompt engineering like a slot machine. We keep pulling the handle (tweaking the wording), hoping the next output is the jackpot. But usually, we’re just increasing entropy.

The "Vibes-Based" Engineering Trap

The problem isn't the AI. The problem is that we treat prompts like casual conversation instead of production code.

When we code, we have:

Git (Version Control)
Unit Tests (Verification)
Diffs (Comparison)

When we prompt, we have:

"Make it better pls"
"No not like that"
Copy-pasting wildly into VS Code

We are operating on "vibes." And when you operate on vibes, you inevitably end up in the Circle of Doom:

The Drift: You add constraints that conflict with each other.
The Over-Correction: The AI fixates on your latest angry instruction and forgets the original context.
The Sunk Cost: You refuse to write the code manually because "I've already spent 20 minutes on this prompt."
The Revert: You realize your prompt from 40 versions ago was actually the best one, but you lost it in the chat history.

Stop Guessing. Start Engineering.

I got so sick of this cycle-losing good prompts, forgetting which tweak actually improved the output, and blindly guessing—that I decided to build a tool to force myself to stop being an idiot.

It’s called PromptZerk.

The philosophy is simple: Treat prompts like code.

"Every AI prompt workflow is the same: write → pray → fail → tweak → pray again."

Instead of spamming "try again," I built a workflow that actually tracks what's happening:

1. Version Control & Rollback

Every time you tweak a prompt, PromptZerk saves a version (v1.0, v1.1). If your new "optimization" makes the AI hallucinate, instantly hit Rollback and return to the stable state. Think of it like Git, but for your prompts.

2. A/B Testing (The Reality Check)

Stop guessing if "be concise" is better than "limit to 50 words." Run them both. See which one actually follows instructions. Spoiler: it's rarely what you'd guess.

3. Diff View (Prompt Forensics)

Actually see what changed between two prompts. Did adding that persona improve readability? Or did it just waste tokens? Now you'll know before burning 10 more API calls.

4. The "Fix My Mess" Button (Prompt Enhancer)

Too tired to structure things properly? The 4-stage analysis engine takes your lazy "fix code" prompt and injects the necessary context, constraints, and formatting rules to get it right the first time. It's like having a senior prompt engineer on call at 2am.

5. Image-to-Prompt (Reverse Engineering)

Found an AI-generated image you love but have no idea what prompt made it? Upload it. Get a detailed prompt that captures the style, composition, lighting-everything. Now replicate it.

6. Expert Prompt Library

Stop starting from scratch. Access a curated library of battle-tested prompts for coding, content, analysis, and more. Customize as needed. Skip the experimentation phase entirely.

7. Presentation Builder

Describe your topic, get a structured slide outline with talking points. Export to Gamma. Go from "I have a meeting in 2 hours" to "slides are done" in minutes.

8. Collections & Folders

Prompts pile up fast. Organize them like code repos—by project, use case, or AI model. Star your best performers. Actually find things when you need them.

9. Analytics Dashboard

See what's actually working. Track your enhancement scores, credit usage, and patterns over time. Data-driven prompting > vibes-based prompting.

10. Chrome Extension

Bring the workflow everywhere. Enhance prompts directly in ChatGPT, Claude, or any text field. One-click optimization without tab-switching.

The Way Out

If you find yourself yelling at an LLM today, stop. You are in the Doom Loop.

You don't need to "prompt harder." You need to prompt smarter.

I’m opening up the PromptZerk beta. If you want to stop the prompt spam and actually ship AI features (or just get your code snippet generated correctly), give it a spin.

It has saved me from throwing my laptop out the window at least twice this week.

Check it out here: promptzerk.tech

Solving the UI Customization Nightmare in Flutter Enterprise Apps

Tejas — Fri, 02 Jan 2026 07:12:31 +0000

The "Cookie-Cutter" Trap

We’ve all been there. You build a robust B2B application. The logic is solid, the state management is clean, and the backend is scalable. Then, you sign your second big client.

Client A loves the app but wants their specific shade of navy blue and “sharper corners.”
Client B needs the dashboard widgets rearranged because their operations team prioritizes different metrics.
Client C needs a completely different font hierarchy for accessibility compliance.

Suddenly, your clean codebase is littered with if (client == 'A') statements. You aren't building an app anymore; you're maintaining a conditional spaghetti monster.

Standard Material Design is great for speed, but enterprise apps demand identity and flexibility. Here’s how we solve the UI customization problem without losing our minds.

Level 1: The Power of `ThemeExtension`

Most developers stop at ThemeData.primaryColor. But enterprise design systems rarely map 1:1 to the Material spec. You might have things like:

Brand Gradient
Success Muted
Sidebar Background

Stop abusing colorScheme.surface for things it wasn’t meant for. Use ThemeExtension.

@immutable
class BrandColors extends ThemeExtension<BrandColors> {
  final Color? successMuted;
  final Color? sidebarBackground;

  const BrandColors({this.successMuted, this.sidebarBackground});

  @override
  BrandColors copyWith({
    Color? successMuted,
    Color? sidebarBackground,
  }) {
    return BrandColors(
      successMuted: successMuted ?? this.successMuted,
      sidebarBackground: sidebarBackground ?? this.sidebarBackground,
    );
  }

  @override
  ThemeExtension<BrandColors> lerp(
    ThemeExtension<BrandColors>? other,
    double t,
  ) {
    if (other is! BrandColors) return this;
    return BrandColors(
      successMuted: Color.lerp(successMuted, other.successMuted, t),
      sidebarBackground:
          Color.lerp(sidebarBackground, other.sidebarBackground, t),
    );
  }
}

Usage in UI:

final brandColors = Theme.of(context).extension<BrandColors>();

Container(
  color: brandColors?.sidebarBackground,
);

The Win:
You can now swap entire semantic palettes per client without touching a single widget file.

Level 2: The "Widget Factory" Pattern

Enterprise apps often need to render dynamic forms or dashboards where the layout isn’t known until runtime (e.g., user permissions or backend configuration).

Instead of hardcoding screens, build a Widget Factory. Your app reads a configuration (JSON) and renders the UI accordingly.

class WidgetFactory {
  static Widget build(Map<String, dynamic> config) {
    switch (config['type']) {
      case 'info_card':
        return InfoCard(
          title: config['title'],
          value: config['value'],
          isTrendUp: config['trend'] == 'up',
        );
      case 'chart_bar':
        return RevenueChart(data: config['data']);
      default:
        return const SizedBox.shrink();
    }
  }
}

Now your Dashboard page is just a ListView iterating over a list of configs.

If Client A wants the chart at the top and the info card at the bottom, you update the JSON, not the Flutter code.

Level 3: White-Labeling with Abstract Component Libraries

If you’re maintaining a white-label solution, stop using ElevatedButton directly in your pages.

Create a semantic wrapper layer.
Your app should consume AppPrimaryButton, not ElevatedButton.

class AppPrimaryButton extends StatelessWidget {
  final String label;
  final VoidCallback onPressed;

  const AppPrimaryButton({
    required this.label,
    required this.onPressed,
  });

  @override
  Widget build(BuildContext context) {
    final config = AppConfig.of(context);

    if (config.style == AppStyle.minimal) {
      return TextButton(
        onPressed: onPressed,
        child: Text(
          label,
          style: const TextStyle(fontWeight: FontWeight.bold),
        ),
      );
    }

    return ElevatedButton(
      style: ElevatedButton.styleFrom(
        shape: config.borderRadius,
        backgroundColor: config.brandColor,
      ),
      onPressed: onPressed,
      child: Text(label),
    );
  }
}

This ensures that when a design requirement changes across the enterprise suite, you update one file, and it propagates everywhere.

Conclusion: Configuration > Hardcoding

The secret to scalable enterprise UI in Flutter isn’t about being a wizard with CustomPainter.
It’s about architecture.

Decouple semantic colors from Material defaults using ThemeExtension
Abstract base components to swap implementations easily
Drive layouts via configuration (JSON) instead of rigid widget trees

By treating your UI as a data-driven rendering engine, you turn:

“Can we move that button?”

from a 4-hour deployment into a 4-second config change.

See It In Action

Writing about architecture is one thing, seeing it run is another.
I’ve built a reference implementation of this pattern.

It includes:

40+ pre-built Flutter UI components with real-time preview and customization
Complete theme system with 40+ color properties and popular app presets (Netflix, Spotify, etc.)
5 preset UI layouts with mobile device frame preview
Export functionality generating ready-to-use Flutter code and theme files

Full code:
https://github.com/TejasS1233/flutter-studio

If you found this useful—or have a better approach to white-labeling—drop a ⭐ on the repo or let me know in the comments!

The Context-Switching Problem: Why I Built a Tracker That Lives in My Terminal.

Tejas — Wed, 03 Dec 2025 07:04:39 +0000

The Problem with Productivity Apps

When my semester wrapped up, I knew exactly what came next: a focused stretch of interview prep and personal learning. I wanted to set clear goals and track my progress properly, not in a vague “I think I did something today” way but with real structure and accountability.

Naturally, I turned to productivity and habit-tracking apps.
And very quickly, I realized they were fighting against my workflow instead of supporting it. They were:

Too Slow: Switching contexts to a separate app and clicking through menus just to log a task felt cumbersome and killed my flow.
Too Distracting: Notifications, overly complex UIs, and features I didn't need turned "checking a box" into a time-sink.

I realized what I needed wasn't another habit tracker; it was a system built for speed and duality. I needed to be able to log a quick win in the terminal without leaving my coding environment, but also switch to a visual dashboard for deep, retrospective analysis.
That's why I built Resync.

The Solution: Two Interfaces, One System

Resync is built around two specialized components:
I] Resync CLI: When I started, I assumed building a CLI tool meant diving into C++ wrappers or even assembly; only to realize it could simply be a fast, origin-less client focused purely on speed.
The CLI ensures logging tasks is instant, frictionless, and never breaks your focus.

Offline Robustness: Features an Offline SQLite Mode that automatically syncs goal updates to the MongoDB backend once connectivity is restored.
TUI Mode: Includes an interactive, text-based dashboard for quick terminal navigation.
Automation: Designed to be automation-friendly, letting users integrate goal tracking into custom scripts or cron jobs. It also features a Background Daemon: A lightweight process that runs in the background and sends scheduled reminders without keeping the CLI open.

Here’s a simplified example of how the daemon works:

schedule.scheduleJob("0 9 * * *", async () => {
  const goals = (await api.getGoals()).data;
  const pending = goals.filter(g => g.currentProgress.percentage < 100);
  notify(`Resync Reminder`, `You have ${pending.length} goal(s) pending today `);
});

function notify(title, message) {
  const os = platform();
  if (os === "darwin") exec(`osascript -e 'display notification "${message}" with title "${title}"'`);
  else if (os === "win32") exec(`powershell -Command "...Windows notification snippet..."`);
  else exec(`notify-send "${title}" "${message}"`);
}

Note: This is simplified — the full implementation includes multiple reminder types, offline handling, and process management to keep it robust and cross-platform.

The daemon allows the CLI to act like a self-running assistant, sending reminders automatically and helping you stay on track without ever leaving your terminal.

II] Web App (PWA): This is the visual dashboard, built with React/Vite and focused on deep reflection. Key features include:

Keyboard-First Navigation: Features a Command Palette (⌘K) for quick search and navigation, backed by over 18 keyboard shortcuts for power users (like ⌘N and Ctrl+Enter).
Distraction-Free Focus: Dedicated Zen Mode with Pomodoro timer.
Analysis: Activity heatmaps and trend charts for visualizing long-term progress.

Tech Stack:

Built on the MERN stack (Node.js/Express API, MongoDB Database) with a React/Vite frontend.
CLI: A Node.js application leveraging commander for command structure and inquirer for interactive prompts.

What's Next?

My focus is now shifting to scaling the experience and enhancing user control. I'm currently focused on the following areas:

Ubiquitous Sync: Enhancing real-time sync to ensure a seamless experience across multiple devices.
Data Control: Implementing data export functionality (CSV, JSON) to give users full ownership of their progress data.
CLI Extensibility: Developing a plugin system for the CLI to allow for custom commands and community contributions.
Deeper Insights: Working on enhanced data visualization options for the web app to unlock new analysis possibilities.

As a newer user of dedicated goal tracking tools—having built this primarily for my interview prep—I know I've likely overlooked features essential to long-time power users. If you have any suggestions for necessary or cool additions, please share!

It’s completely open-source—any stars, feedback, or contributions would mean a lot!

GitHub Repository: https://github.com/TejasS1233/Resync

and yes to those of you wondering, this isn't a way for me to distract myself from LeetCode (TRUST). Goal is to do at least have basic pattern rec knowledge by end of December! XD

I Built a Tool to Stalk GitHub Profiles (Legally)

Tejas — Tue, 28 Oct 2025 08:17:28 +0000

Let's be honest - we've all done it. You see a cool project, check out the developer's profile, scroll through their repos, mentally calculate how many stars they have, wonder what languages they use most...

I got tired of doing this manually, so I built en-git - a GitHub profile analyzer that does all the stalking for you.

Live Demo: https://en-git.vercel.app

GitHub: https://github.com/TejasS1233/en-git

What It Does

Profile Analysis

Type in any GitHub username and get:

Top programming languages (with percentages!)
Total stars, forks, repos
Contribution patterns
Profile completeness score
A judgment-free assessment of their GitHub game

Compare Developers

Ever wonder how you stack up against that developer you admire? Now you can compare:

Language usage
Repository stats
Follower counts
Activity levels
Side-by-side, no judgment (okay, maybe a little)

Repository Deep Dive

Analyze any repo to see:

Language breakdown
Star/fork metrics
Recent activity
Whether it's actually maintained or abandoned

Chrome Extension

Beyond the web app, I also built a companion Chrome extension to bring these insights directly into your GitHub workflow.

Inline Code Quality: Get a real-time quality score (0-100), complexity level, and issue detection (e.g., long functions, nesting) directly inside any GitHub file. It's a game-changer for PR reviews.
Instant Profile Insights: See a user's profile score and top languages just by visiting their GitHub profile page.
Private Bookmarking: "Star" a repo to a personal, private list without notifying the owner.

How to get it: The extension is finished and currently the process of publishing. For now, you can load it manually from the Github repo!

Tech Stack

React + Vite - Because life's too short for slow builds
Tailwind CSS - For when you want things to look good without writing CSS
shadcn/ui - Copy-paste components that actually look professional
GitHub API - The source of all stalking data
Vercel - Deploy and forget

The Fun Parts

GitHub API Rate Limits Are Real
60 requests/hour for unauthenticated users. I learned this the hard way.
Solution: Aggressive caching and making users feel bad about refreshing too much.
Some Developers Are Insane
I tested this on profiles with 50+ repos. Turns out, fetching and processing that much data is... not instant.
Had to implement pagination, lazy loading, and a lot of "please wait" messages.
Scoring Profiles Is Subjective
How do you score a GitHub profile? Stars? Repos? Followers? Commit frequency?
I made up an algorithm. It's probably wrong. But it's consistently wrong, which is what matters.

What I Learned

The GitHub API is actually really well-designed
Vite is stupid fast compared to Create React App
People care way more about their GitHub stats than they admit
Rate limits will humble you

Try It Out

Go to en-git and:
Analyze your own profile (be brave)
Compare yourself to someone you admire (or fear)
Stalk your coworkers (they'll never know)

What's Next

Ideas I'm considering:

Team analytics (stalk entire organizations)
More AI features (currently have one, need more buzzwords)

It's open source and I'd love your help! But more importantly, what do you think? And what features am I missing?

Forem: Tejas

Under the Hood: Demystifying Database Internals (InnoDB vs. ARCHIVE)

1. The InnoDB Hierarchy (From Bytes to Tablespaces)

The Storage Stack

2. The ARCHIVE Engine (The Anti-Page Approach)

3. Architecture Comparison Matrix

4. Connecting the Worlds: Table Partitioning & Exchange

Step A: Create the Partitioned InnoDB Table

Step B: The Instant Partition Exchange

5. Production Reality Check: Where the Industry is Today

Conclusion

B-Trees vs. LSM-Trees: Why your Database choice is actually a Trade-off

Stop Drowning in Vectors: How I Built a Graph-Powered RAG That Actually Scales

The Problem with Traditional RAG

Enter Vectorless RAG

Why I Put It on Neo4j

1. Persistent Memory at Scale

2. Cross-Document Relationships

3. Token-Efficient Retrieval

How It Works

The Graph Structure

Three-Step Workflow

Step 1: Parse Documents

Step 2: Ingest into Neo4j

Step 3: Query with Agentic Retrieval

Under the Hood

Tech Stack

The Agentic Retrieval Loop

When to Use This Approach

What's Next

Final Thoughts

The "Prompt Doom Loop": Why your AI output gets worse the more you try to fix it

The "Vibes-Based" Engineering Trap

Stop Guessing. Start Engineering.

1. Version Control & Rollback

2. A/B Testing (The Reality Check)

3. Diff View (Prompt Forensics)

4. The "Fix My Mess" Button (Prompt Enhancer)

5. Image-to-Prompt (Reverse Engineering)

6. Expert Prompt Library

7. Presentation Builder

8. Collections & Folders

9. Analytics Dashboard

10. Chrome Extension

The Way Out

Solving the UI Customization Nightmare in Flutter Enterprise Apps

The "Cookie-Cutter" Trap

Level 1: The Power of ThemeExtension

Level 2: The "Widget Factory" Pattern

Level 3: White-Labeling with Abstract Component Libraries

Conclusion: Configuration > Hardcoding

See It In Action

The Context-Switching Problem: Why I Built a Tracker That Lives in My Terminal.

The Problem with Productivity Apps

The Solution: Two Interfaces, One System

Tech Stack:

What's Next?

I Built a Tool to Stalk GitHub Profiles (Legally)

What It Does

Profile Analysis

Compare Developers

Repository Deep Dive

Chrome Extension

Tech Stack

The Fun Parts

What I Learned

Try It Out

What's Next

Level 1: The Power of `ThemeExtension`