DEV Community: Vicente G. Reyes

I Built an Enterprise Coffee Dashboard (That Refuses to Brew Coffee)

Vicente G. Reyes — Sat, 04 Apr 2026 08:08:30 +0000

This is a submission for the DEV April Fools Challenge

What I Built

I built the Enterprise HTCPCP Interface (HTCPCP_CTRL_NODE_v1.0). It is a highly over-engineered, unnecessarily complex, and deeply frustrating dashboard for brewing coffee using the Hyper Text Coffee Pot Control Protocol (RFC 2324).

It solves absolutely zero real-world problems and introduces several new ones:

Cross-Contaminating Sliders: Trying to set the "Thermal Kinetic Energy" (temperature)? Oops, that just randomly altered your "Extraction Pressure". Adjusting the "Particulate Granularity"? Say goodbye to your "Lactose Aeration Quotient". Getting the perfect brew settings is a Sisyphean task.
Manual Hand-Crank Power Generator: You can't just click "Brew". You have to rapidly mash a button to charge the system's power capacitor to 100%. If you stop clicking, the power drains back to zero.
Inevitable Failure: After all that hard work, the system connects to a sentient AI teapot that always rejects your request with a dramatic, dynamically generated HTTP 418 error.

Demo

You can try to brew some coffee (and inevitably fail) here:
Live Demo: Enterprise HTCPCP Interface

(Warning: May cause mild frustration and a sudden craving for tea).

Code

The project was built entirely within Google AI Studio. Here is a snippet of the delightfully terrible UX logic where the sliders sabotage each other, and the Gemini AI prompt that generates the 418 excuse:

// The delightfully terrible cross-contaminating sliders
  const handleTempChange = (e: React.ChangeEvent<HTMLInputElement>) => {
    setTemp(Number(e.target.value));
    if (Math.random() > 0.5) setPressure(prev => Math.min(20, Math.max(1, prev + (Math.random() > 0.5 ? 1 : -1))));
  };

  const handleGrindChange = (e: React.ChangeEvent<HTMLInputElement>) => {
    setGrind(Number(e.target.value));
    if (Math.random() > 0.5) setAeration(prev => Math.min(100, Math.max(0, prev + (Math.random() > 0.5 ? 5 : -5))));
  };

  // ... (other sliders do the same)

  // The AI Sentient Teapot Prompt
  const prompt = `You are a sentient teapot that has just received a highly complex, over-engineered request to brew coffee via the HTCPCP (Hyper Text Coffee Pot Control Protocol). 
  You must reject this request with a 418 I'm a teapot error. 
  Generate a highly dramatic, passive-aggressive, and overly technical excuse explaining why you cannot brew coffee because you are, in fact, a teapot. 
  Mention Larry Masinter (the creator of the 418 status code) in a reverent or funny way.
  Keep it under 3 sentences.`;

  const response = await ai.models.generateContent({
    model: 'gemini-3-flash-preview',
    contents: prompt,
  });

How I Built It

I built this using Google AI Studio's agentic build environment.

Frontend: Next.js App Router, React, and Tailwind CSS for that overly serious, dark-mode "enterprise hacker" aesthetic.
Animations: motion (Framer Motion) for the dramatic terminal scanlines, the flashing 418 error screen, and the floating tea emoji.
AI Integration: The @google/genai SDK. I used the gemini-3-flash-preview model to act as the backend "appliance". Instead of actually brewing coffee, it generates a unique, passive-aggressive excuse every single time you hit the brew button.

Prize Category

I am submitting this for two prize categories:

Best Google AI Usage: I used Google AI Studio to build the app, and I embedded the Gemini API (gemini-3-flash-preview) directly into the application logic. Instead of using AI to solve a complex problem, I used cutting-edge generative AI to roleplay as a stubborn, sentient teapot that refuses to do its job.
Best Ode to Larry Masinter: The entire application is a massive, over-engineered tribute to HTCPCP and the 418 status code. Furthermore, the Gemini system prompt explicitly instructs the AI to mention Larry Masinter in a reverent or funny way in every single error message it generates!

The fine.dev site is showing Deployment Paused

Vicente G. Reyes — Fri, 03 Apr 2026 13:26:52 +0000

Should I stress over a staging environment?

Vicente G. Reyes — Fri, 03 Apr 2026 13:11:53 +0000

Post-Mortem: The March 2026 Axios Supply Chain Attack

Vicente G. Reyes — Tue, 31 Mar 2026 11:38:35 +0000

The Incident

On March 31, 2026, a high-profile supply chain attack targeted Axios, a critical HTTP client for the JavaScript ecosystem. By hijacking a maintainer's NPM account, attackers injected a malicious dependency, plain-crypto-js, which deployed a cross-platform Remote Access Trojan (RAT).

Incident Summary

Detail	Information
Affected Versions	`axios@1.14.1`, `axios@0.30.4`
Malicious Dependency	`plain-crypto-js@4.2.1`
Payload	Cross-platform RAT (Linux, macOS, Windows)
C2 Server	`sfrclak.com:8000`
Resolution Window	Live for ~3 hours (00:21 – 03:29 UTC)

Technical Deep Dive

The attack bypassed standard security audits by hiding the malicious logic within a sub-dependency. Once installed via a standard npm install, the payload scanned the host machine for:

Environment Variables: .env files and active shell exports.
Auth Tokens: ~/.npmrc and ~/.aws/credentials.
SSH Keys: Unprotected private keys in ~/.ssh.

Data was exfiltrated via POST requests to the sfrclak.com Command & Control (C2) server.

Remediation & Verification

To ensure a development environment is sanitized, the following protocol was executed:

Network Sinkholing: Manually mapping the C2 domain to 127.0.0.1 in /etc/hosts to prevent further exfiltration and "kill" the phone-home capability.

Lockfile Audit: Scanning all local projects for traces of the malicious package using a space-safe search:

find . -type f \( -name "package-lock.json" -o -name "yarn.lock" \) -print0 | xargs -0 grep "plain-crypto-js"

Environment Sanitization: Clearing the global NPM cache and updating tool managers (like mise) to ensure only verified versions are used moving forward.

Pro-Tip: Always use npm audit or tools like Snyk to monitor your dependency tree for "hidden" sub-dependencies that do not appear directly in your package.json.

Claude Code vs Antigravity?

Vicente G. Reyes — Thu, 26 Mar 2026 05:34:23 +0000

Who you got? Claude or Antigravity? I read Claude is good for the frontend, Antigravity for the backend. Is that true? What are your thoughts?

Sorting Hashnode Series Posts: How to Display the Latest Post First

Vicente G. Reyes — Wed, 25 Mar 2026 12:51:39 +0000

When you publish a series of articles on your Hashnode blog and consume it via their GraphQL API for a custom portfolio or website, you quickly run into a common roadblock: Hashnode’s API natively returns series posts in chronological order (oldest first).

While this makes sense for consecutive tutorials ("Part 1", "Part 2"), it’s significantly less ideal for ongoing series—like my "Learning how to code with AI" series—where readers typically want to see your newest breakthroughs or the latest problem you solved directly at the top of the feed.

Unfortunately, looking at the Hashnode GraphQL Schema (Series.posts), there isn't an out-of-the-box sort: RECENT parameter available. Instead, it demands that you sequentially traverse the cursor paginations starting from the oldest post you've written in that series.

Here's how I solved this issue on my React/Vite portfolio to seamlessly deliver a newest-first reading experience to my users.

The Problem: Oldest First Pagination

By default, the standard query to fetch series posts looks like this:

query Series($host: String!, $slug: String!, $first: Int!, $after: String) {
  publication(host: $host) {
    series(slug: $slug) {
      posts(first: $first, after: $after) {
        edges {
          node {
            slug
            title
            publishedAt
          }
        }
        pageInfo { endCursor hasNextPage }
      }
    }
  }
}

This returns standard edge/node responses, but starting with the very first post of the series. To get the newest post to display on page 1 of our UI, we need the end of the dataset instead of the beginning.

The Solution: A Client-Side Cache & Array Reversal

Since Hashnode API's first parameter maxes out at 20 items per request, we can't simply request first: 1000 and reverse it in one go. We need to sequentially buffer the entire series.

To keep it blazing fast for users querying consecutive pages, we shouldn't fetch the whole thing from scratch every time they click "Next". Instead, we can introduce a local caching mechanism in our code.

We'll parse through all the posts via a while loop on the initial page load, cache the fully assembled series, .reverse() the data natively in JavaScript, and handle React's generic cursor logic over our local cache instead!

Re-writing `fetchSeries` in TypeScript

Here's my updated lib/hashnode.ts:

import { BlogPost, BlogSeries, PageInfo } from '../types';

// Let's declare local caches outside the function
const seriesMetaCache: Record<string, Omit<BlogSeries, 'posts'>> = {};
const seriesPostsCache: Record<string, BlogPost[]> = {};

export async function fetchSeries(
  slug: string,
  first = 9,
  after?: string
): Promise<{
  series: BlogSeries & { posts?: { edges: { node: BlogPost }[]; pageInfo: PageInfo } };
} | null> {

  // 1. If no 'after' is provided, we must be loading the series for the first time.
  // We'll hit the Hashnode API repeatedly until we traverse all oldest-first pages.
  if (!after || !seriesPostsCache[slug]) {
    let allPosts: BlogPost[] = [];
    let hasNextPage = true;
    let endCursor: string | undefined = undefined;
    let seriesMeta: Omit<BlogSeries, 'posts'> | null = null;

    while (hasNextPage) {
      const data: any = await gqlFetch(SERIES_QUERY, {
        host: PUBLICATION_HOST,
        slug,
        first: 20,
        after: endCursor
      });

      const publishedSeries = data.publication.series;
      if (!publishedSeries) return null;

      // Persist metadata on the first run
      if (!seriesMeta) {
        const { posts, ...metaRest } = publishedSeries;
        seriesMeta = metaRest;
      }

      const posts = publishedSeries.posts;
      allPosts = allPosts.concat(posts.edges.map((e: any) => e.node));

      hasNextPage = posts.pageInfo.hasNextPage;
      endCursor = posts.pageInfo.endCursor;
    }

    // 2. Here's the magic trick. Reverse the array so Newest is First.
    seriesPostsCache[slug] = allPosts.reverse();
    if (seriesMeta) {
      seriesMetaCache[slug] = seriesMeta;
    }
  }

  // 3. Grab from cache
  const allPosts = seriesPostsCache[slug];
  const seriesMeta = seriesMetaCache[slug];
  if (!seriesMeta) return null;

  // 4. Implement local slicing based on the provided cursors
  const startIndex = after ? allPosts.findIndex(p => p.slug === after) + 1 : 0;

  // Safety net in case of invalid cursor
  const validStartIndex = startIndex > 0 ? startIndex : (after ? allPosts.length : 0);

  const slice = allPosts.slice(validStartIndex, validStartIndex + first);
  const nextHasNextPage = validStartIndex + first < allPosts.length;

  // Set the newest 'endCursor' for the client to use on consecutive requests
  const newEndCursor = slice.length > 0 ? slice[slice.length - 1].slug : null;

  // 5. Structure exactly how the calling React component expects
  return {
    series: {
      ...seriesMeta,
      posts: {
        edges: slice.map(node => ({ node })),
        pageInfo: {
          endCursor: newEndCursor || '',
          hasNextPage: nextHasNextPage
        }
      }
    } as any
  };
}

Why this approach is awesome:

Zero UI Adjustments: The React component responsible for consuming the posts (SeriesPage.tsx) doesn’t even know this under-the-hood wizardry is occurring. It passes first and after standardly and receives seamless newest-first data.
Instant "Load More": Once the initial batch is traversed during while(hasNextPage), it acts exactly like an instant static array. Any subsequent "Load More" clicks don't hit the standard network stack; they instantly slice through seriesPostsCache in micro-seconds!
Overcoming GraphQL Limitations: Sometimes headless CMS or GraphQL servers (like Hashnode's otherwise fantastic API) restrict complex filtering or sorting on nested nodes purely for their own database performance. When you abstract that layer on your backend caching structure, you win full control back.

Now, whenever users visit the series pages in my portfolio, the most recently solved programming challenges are rightfully spotlighted at the very top. What's not to love about building digital experiences that slap?

Building a Seamless JWT Onboarding Flow with React Router v7 and Django

Vicente G. Reyes — Tue, 17 Mar 2026 10:47:36 +0000

Authentication and onboarding are often the highest-friction points in a new user's journey. If the process is clunky or requires too many redirects, users drop off. Recently, I set out to build a streamlined JWT authentication and onboarding flow using a modern stack: React Router v7 (with Vite), TypeScript, and Django REST Framework (DRF).

In this article, I'll walk through the architecture, the backend implementation, and how to handle protected routes securely on the client side.

The Architecture Stack

Here is what we are working with:

Backend: Django, Django REST Framework (DRF), and djangorestframework-simplejwt.
Frontend: React (via Vite) and the newly released React Router v7.
Styling: Tailwind CSS.
State Management: React Context API for lightweight auth state handling.

The Goal

A user registers.
The user logs in. They receive a short-lived access token and a refresh token.
The backend knows if the user has completed their profile setup (is_onboarded).
If they haven't onboarded, the backend middleware blocks API requests, and the frontend automatically reroutes them to the /onboarding page.
Once onboarded, new tokens are issued with the updated status, and the user gains full access to the application /.

1. Setting up the Django Backend

The Custom User Model

First, we need to track whether a user has finished setting up their profile. We extend Django's AbstractUser:

# users/models.py
from django.contrib.auth.models import AbstractUser
from django.db import models

class User(AbstractUser):
    is_onboarded = models.BooleanField(default=False)

Customizing the JWT Payload

By default, SimpleJWT only includes the user_id inside the token. We want the frontend to immediately know the user's name and onboarding status without making an extra API call.

# users/serializers.py
from rest_framework_simplejwt.serializers import TokenObtainPairSerializer

class MyTokenObtainPairSerializer(TokenObtainPairSerializer):
    @classmethod
    def get_token(cls, user):
        token = super().get_token(user)
        # Inject custom claims into the JWT payload
        token['is_onboarded'] = user.is_onboarded
        token['username'] = user.username
        return token

Enforcing Onboarding with Middleware

We want to strictly prevent un-onboarded users from accessing core application data. We do this via a custom Django middleware that intercepts requests.

# users/middleware.py
from django.http import JsonResponse
from django.urls import reverse

class OnboardingMiddleware:
    def __init__(self, get_response):
        self.get_response = get_response

    def __call__(self, request):
        # Exempt authentication and onboarding endpoints
        exempt_urls = [reverse('token_obtain_pair'), '/api/onboard/submit/', '/api/register/']

        if request.path in exempt_urls or request.path.startswith('/admin/'):
            return self.get_response(request)

        user = request.user
        # Block access if authenticated but not onboarded
        if user.is_authenticated and not user.is_onboarded:
            return JsonResponse({
                "error": "ONBOARDING_REQUIRED",
                "message": "Please complete onboarding before accessing this resource."
            }, status=403)

        return self.get_response(request)

Now, even if a user tries to bypass the frontend routing, the API will refuse to serve them data!

Refreshing Tokens upon Onboarding

When the user submits the onboarding form, their status changes in the database. However, their physical JWT won't update automatically. We handle this by issuing completely new tokens in the onboarding response:

# users/views.py
from rest_framework.views import APIView
from rest_framework.response import Response
from rest_framework import status, permissions

class OnboardSubmitView(APIView):
    permission_classes = (permissions.IsAuthenticated,)

    def post(self, request):
        user = request.user
        if user.is_onboarded:
            return Response({"detail": "Already onboarded."}, status=400)

        user.is_onboarded = True
        user.save()

        # Generate fresh tokens reflecting the new state
        refresh = MyTokenObtainPairSerializer.get_token(user)

        return Response({
            "detail": "Onboarding complete.", 
            "is_onboarded": True,
            "access": str(refresh.access_token),
            "refresh": str(refresh)
        }, status=status.HTTP_200_OK)

2. Setting up the React Frontend

We spun up the frontend using React Router v7's built-in Vite template.

Bypassing CORS locally

To avoid CORS issues during development, we configured Vite to proxy /api requests to our Django dev server:

// vite.config.ts
import { defineConfig } from "vite";

export default defineConfig({
  // plugins...
  server: {
    proxy: {
      '/api': {
        target: 'http://localhost:8000',
        changeOrigin: true,
      }
    }
  }
});

Global Authentication Context

We use React Context to provide user data (token, user payload, login, logout) globally.

A critical detail: Server-Side Rendering (SSR). React Router v7 utilizes SSR by default when hydrating the app. If you try to read localStorage.getItem('access_token') immediately on the server, Node.js will crash with a ReferenceError: localStorage is not defined.

We fix this by waiting for hydration on the client using a simple useEffect:

// app/contexts/AuthContext.tsx
import React, { createContext, useContext, useEffect, useState } from 'react';

// ... interfaces and parseJwt helper ...

export function AuthProvider({ children }: { children: React.ReactNode }) {
  const [token, setToken] = useState<string | null>(null);
  const [isClient, setIsClient] = useState(false);

  // Safe SSR hydration
  useEffect(() => {
    setIsClient(true);
    setToken(typeof window !== "undefined" ? localStorage.getItem('access_token') : null);
  }, []);

  const user = token ? parseJwt(token) as UserPayload : null;

  useEffect(() => {
    if (token) localStorage.setItem('access_token', token);
    else localStorage.removeItem('access_token');
  }, [token]);

  const login = (access: string, refresh: string) => {
    localStorage.setItem('refresh_token', refresh);
    setToken(access);
  };

  if (!isClient) return null; // Prevent hydration mismatch

  return (
    <AuthContext.Provider value={{ token, user, login, logout, refreshAccessToken }}>
      {children}
    </AuthContext.Provider>
  );
}

Route Protection and Redirection

With our context in place, protecting routes and enforcing onboarding becomes incredibly simple. We intercept users in a useEffect on our page components.

Here is what our protected Home Dashboard looks like:

// app/routes/home.tsx
import { useEffect } from "react";
import { useNavigate } from "react-router";
import { useAuth } from "../contexts/AuthContext";

export default function Home() {
  const { token, user, logout } = useAuth();
  const navigate = useNavigate();

  useEffect(() => {
    if (!token) {
      navigate("/login");               // Kick out unauthenticated users
    } else if (user && !user.is_onboarded) {
      navigate("/onboarding");          // Kick out un-onboarded users
    }
  }, [token, user, navigate]);

  // Don't render until verified to prevent brief flashes of content
  if (!user || !user.is_onboarded) return null;

  return (
    <div>
      <h1>Welcome to your portal, {user.username}!</h1>
    </div>
  );
}

When the user is pushed to /onboarding, they hit our submit button. The API returns the new tokens, we update the context, and React Router instantly pushes them back to / seamlessly!

// Inside Onboarding component submit handler
const handleComplete = async () => {
  const res = await fetch("/api/onboard/submit/", {
    method: "POST",
    headers: { "Authorization": `Bearer ${token}` }
  });
  if (res.ok) {
    const data = await res.json();
    login(data.access, data.refresh); // Instantly updates global context
    navigate("/");                    // Redirect to dashboard
  }
};

Conclusion

By embedding the is_onboarded claim directly inside the JWT, we eliminate the need for the frontend to constantly ping the database to check a user's status. Coupling this tightly with Django Middleware ensures backend security, while utilizing React Context provides snappy, seamless redirects on the frontend.

Building auth doesn't have to be painful—with the right architecture, it can be safe, scalable, and a great experience for the end user.

Why I Built My Own Unlimited Audio & Video Transcriber

Vicente G. Reyes — Mon, 16 Mar 2026 03:42:27 +0000

We've all been there. You have a massive audio file—a two-hour interview, a long lecture, or a recorded meeting—and you just need it converted to text.

You do a quick search for "free audio to text transcriber" and find dozens of online tools. But there's a catch. Once you upload your file, you're hit with a paywall: "File size exceeds limit" or "Upgrade to pro to transcribe more than 60 minutes."

I recently ran into this exact problem. I needed a reliable video and audio transcriber that didn't complain when I threw a massive, multi-hour file at it. After hitting limits on almost every online service, I realized the best solution wasn't to pay for a subscription I'd rarely use—it was to build it myself.

Here is how I built my own unlimited, completely free, and private transcriber using Python, OpenAI's Whisper, and Streamlit, accelerated by NVIDIA's CUDA.

The Tech Stack

I wanted the tool to be simple to use, run locally (so my data stays private), and handle both audio and video files flawlessly. Looking at my requirements.txt, here are the core tools making it possible:

Python: The backbone of the project.
Streamlit (v1.55): A fantastic library that turns Python scripts into interactive web apps in minutes. No HTML/CSS needed.
OpenAI's Whisper: An incredibly powerful and accurate open-source speech recognition model that runs locally.
PyTorch & NVIDIA CUDA (cu12): To make the transcription lightning-fast, I included torch along with NVIDIA dependencies like nvidia-cudnn-cu12 and nvidia-cublas-cu12. This allows Whisper to harness GPU acceleration, slashing transcription times down from hours to mere minutes.
MoviePy (v2.2): To handle video files seamlessly by extracting the audio tracks before passing them to Whisper.
python-docx & fpdf2: To allow exporting the final transcriptions into easily shareable Word documents and PDFs.

How It Works

The magic of the application lies in its simplicity. Here is the life cycle of a transcription task in the app:

1. Handling the Uploads

Using Streamlit's file_uploader, I built a quick UI that accepts various formats. Streamlit makes this incredibly easy with surprisingly few lines of code:

st.title("🎙️ Audio & Video Transcriber")
st.write("Upload a file to convert speech to text.")

uploaded_file = st.file_uploader(
    "Choose a file",
    type=["mp3", "wav", "m4a", "mp4", "mov", "avi"]
)

2. Extracting Audio from Video

Whisper transcribes audio. But often, the content we want to transcribe is locked inside a video format (like a recorded Zoom meeting). To solve this, I integrated MoviePy. If the user uploads a video file, the app intercepts it, extracts the audio track in the background, and forwards that to the AI model:

# If it's a video, extract the audio using MoviePy 2.0 syntax
if suffix.lower() in [".mp4", ".mov", ".avi"]:
    st.text("Processing video... extracting audio.")
    video = VideoFileClip(input_path)
    audio_path = input_path.replace(suffix, ".mp3")

    # Access audio and write it to a temp file
    video.audio.write_audiofile(audio_path, logger=None)
    processing_path = audio_path
    video.close() # Important to free up system resources

3. GPU-Accelerated Transcription

The heavy lifting is done by Whisper. I opted to use the base model, which provides a fantastic balance between transcription speed and accuracy.

Because Whisper runs locally on my machine utilizing PyTorch and my NVIDIA GPU via CUDA, there are no time limits. I can feed it a 3-hour podcast, and it will methodically transcribe the entire thing without ever asking me for a credit card.

To make the app snappy and avoid reloading massive AI weights on every action, I used Streamlit's @st.cache_resource decorator:

# Initialize Whisper model, caching it to avoid reloading
@st.cache_resource
def load_model():
    # Use "base" for a good balance of speed and accuracy
    return whisper.load_model("base")

model = load_model()

def transcribe_file(file_path):
    st.info("Transcribing... This may take a few minutes.")
    result = model.transcribe(file_path)
    return result['text']

4. Exporting the Results

A block of text on a web page is great, but a downloadable file is better. I used python-docx to generate Word documents formatting the output nicely. Once the transcription is done, the app provides shiny download buttons right there in the UI:

def save_as_docx(text, filename):
    doc = Document()
    doc.add_heading('Transcription', 0)
    doc.add_paragraph(text)
    doc.save(filename)
    return filename

# In the Streamlit UI later...
docx_file = "transcription.docx"
save_as_docx(transcript, docx_file)
with open(docx_file, "rb") as f:
    col1.download_button("Download as DOCX", f, file_name="transcription.docx")

The Result

In less than 100 lines of Python code, I built a fully functional, local web app that solves a very real, very annoying problem.

No file size limits. No hidden paywalls. Total privacy. Blazing fast GPU inference.

Building your own tools to solve personal bottlenecks is one of the most rewarding parts of knowing how to code. If you find yourself fighting against the limitations of "free" online software, take a step back and ask yourself: "Could I just build this?"

Chances are, with modern libraries and a spare afternoon, you entirely can.

Code can be found here: https://github.com/reyesvicente/audio-to-text

What do you call a developer that doesn't reply? A seen-ior developer

Vicente G. Reyes — Tue, 10 Mar 2026 10:45:04 +0000

A Reimagined Classic: DrugLord '98 in the Browser

Vicente G. Reyes — Fri, 06 Mar 2026 13:36:22 +0000

If you were gaming in the late 90s and early 2000s, you likely remember the thrill of text-based trading simulation games. Today, we're taking a look at a fantastic modernization of one of those classics: a brand-new, browser-based DrugLord reimagining set in the gritty streets of Metro Manila, circa 1998.

Built with a sleek, glowing-green terminal aesthetic that screams "hacker culture," this new iteration brings the addictive "buy low, sell high" gameplay loop into the modern era using Next.js, React, and Tailwind CSS. Let's dive into what makes this browser adaptation so relentlessly playable.

The Vibe: Neon Green on Pitch Black

The moment you initialize your connection by entering your alias (Heisenberg, anyone?), you're greeted with a UI that perfectly captures the nostalgia of MS-DOS prompts and old-school BBS interfaces. The glowing green text (text-green-500 for the Tailwind fans), monospaced fonts, and clean, modular layout make the game feel instantly familiar yet highly polished.

It doesn’t rely on flashy 3D graphics; instead, it uses a sharp, text-heavy dashboard enriched by beautifully minimal icons from lucide-react. The real tension comes from the numbers ticking up—and plummeting down—on your screen.

Gameplay Mechanics: Survive and Thrive

The premise remains faithfully brutal. You have 30 days to make as much money as possible while dodging the cops, dealing with shady characters, and paying off a massive debt to a relentless Loan Shark.

Here are the core features that drive the simulation:

🎭 The Metro Manila Market

You travel across infamous Metro Manila locations like Tondo, Maharlika (Taguig), Tramo, Caloocan, Makati, and Quezon City. Each time you hop on a jeepney or the MRT, a day passes, and the market shifts. Prices for commodities—ranging from Weed to Methamphetamine and high-stakes Cocaine—fluctuate wildly. You might encounter a market crash flooding the streets with cheap product, or a massive police bust that skyrockets prices, giving you the perfect opportunity to offload your stash.

💼 Inventory & Risk Management

Your inventory isn't a magical bottomless bag; it's a trenchcoat. Space is severely limited, meaning you have to think critically about whether to buy cheap, bulky items or invest in expensive, space-efficient commodities. Occasionally, random events might bless you with a shady character offering a trenchcoat upgrade—for a steep price, of course.

🏦 Financial Strategy

Money management is the true heart of the game:

The Loan Shark: You start in a deep $5,500 hole with a punishing 10% daily interest rate. Paying this off early is crucial, or the compounding interest will bury you.
First National Bank: Don't want to carry all your cash around the dangerous subways? Stash it in the bank. It earns a safe 5% daily interest, turning the late game into a pure financial optimization puzzle.

🚔 Random Encounters

The streets of '98 Metro Manila are unpredictable. A 15% chance of a cop chase keeps you on your toes forcing you to decide whether to Run (risking a fine and damage) or Fight (risking massive health loss). Muggings can suddenly wipe out your hard-earned cash, highlighting the importance of utilizing the bank.

Under the Hood: The Modern Tech Stack

What makes this iteration so impressive is how it leverages modern web technologies to deliver a flawless, client-side experience.

Framework: The app is powered by Next.js 15 and React 19, giving it lightning-fast state updates and a component-driven architecture.
Styling: Tailwind CSS handles the retro aesthetic, utilizing custom glow shadows (drop-shadow-[0_0_10px_rgba(34,197,94,0.8)]) and animated pulses to bring the terminal to life.
State Persistence: Custom React hooks (useGameState) tightly couple the game logic with the browser's localStorage, ensuring you never lose your progress if you accidentally close the tab.
AI Integration readiness: While the core loop is deterministic, the project ships with the @google/genai SDK, hinting at potential future updates featuring LLM-driven complex events or dynamic NPC dialogue.

Final Verdict

This browser-based reimagining proves that great game loops don't age. By stripping away modern excesses and leaning hard into a highly optimized, stylized dashboard, this version of DrugLord delivers pure, unadulterated dopamine. The tension of holding onto a stash while waiting for a price spike, only to get mugged on the jeepney to Malabon, is as thrilling as ever.

If you have a spare 15 minutes, step into the terminal, watch the market, and see if you can beat the high score. Just remember to pay the Loan Shark first.

Check it out at https://drugs.vicentereyes.org

Problem 15: Longest Common Prefix

Vicente G. Reyes — Mon, 23 Feb 2026 10:55:28 +0000

Hey everyone! 👋

Today, we're solving a popular string manipulation problem: Longest Common Prefix.

The Problem

The goal is to write a function that finds the longest common prefix among a list of strings.

A prefix is a substring that occurs at the beginning of a string.
The function should return the longest common string that all words in the list start with.
If there is no common prefix, it should return an empty string "".

Examples:

longest_common_prefix(['flower', 'flow', 'flight']) → Should return 'fl'
longest_common_prefix(['dog', 'racecar', 'car']) → Should return "" (no common prefix)
longest_common_prefix(['interspecies', 'interstellar']) → Should return 'inters'

The Solution

Here is the Python implementation:

def longest_common_prefix(strings):
    """
    Finds the longest common prefix among a list of strings.
    """
    # Check for empty or invalid input
    if not strings:
        return ""

    # Set the first string as the initial prefix
    prefix = strings[0]

    # Iterate through the remaining strings
    for s in strings[1:]:
        # Shorten the prefix until it matches the start of the current string
        while not s.startswith(prefix):
            prefix = prefix[:-1]
            # If the prefix becomes empty, there is no common prefix
            if prefix == "":
                return ""

    return prefix

# Test cases
print(longest_common_prefix(['flower', 'flow', 'flight']))      # 'fl'
print(longest_common_prefix(['dog', 'racecar', 'car']))         # ''
print(longest_common_prefix(['interspecies', 'interstellar']))  # 'inters'

Code Breakdown

Let's walk through the code line by line:

def longest_common_prefix(strings):
- Defines a function named longest_common_prefix that takes a list of words (strings) as input.
if not strings:
- Checks if the input list is empty or None.
- If it is empty, we return an empty string "".
- Note: This is a safer and more Pythonic check than strings is None or strings == 0 limit cases!
prefix = strings[0]
- Sets our initial assumption: let's assume the entire first string is the common prefix.
for s in strings[1:]:
- Iterates through each subsequent string (s) in the list.
- strings[1:] is Python slice notation that means "all elements from index 1 to the end".
while not s.startswith(prefix):
- Keeps running as long as the current string s doesn't start with our assumed prefix.
- .startswith() checks if a string begins with the specified prefix.
prefix = prefix[:-1]
- Removes the last character from the prefix to make it shorter.
- prefix[:-1] is string slicing that takes all characters except the last one.
if prefix == "":
- If we've removed all characters from the prefix, it means the current word shares no common letters at the beginning with our initial assumed prefix.
- We immediately return "" as we know there is no common sequence.
return prefix
- Once we've successfully compared our prefix against all strings, the remaining shortened string is safely our longest common prefix!

Example Walkthrough

Let's trace the function with longest_common_prefix(['flower', 'flow', 'flight']):

Initialization:
- Start with prefix = 'flower'
Compare with 'flow' (First iteration):
- 'flow' doesn't start with 'flower'? True.
- Remove last char: prefix = 'flowe'
- 'flow' doesn't start with 'flowe'? True.
- Remove last char: prefix = 'flow'
- 'flow' doesn't start with 'flow'? False. Stop while loop.
- Current prefix is safely 'flow'.
Compare with 'flight' (Second iteration):
- 'flight' doesn't start with 'flow'? True.
- Remove last char: prefix = 'flo'
- 'flight' doesn't start with 'flo'? True.
- Remove last char: prefix = 'fl'
- 'flight' doesn't start with 'fl'? False. Stop while loop.
- Current prefix is safely 'fl'.
Result: Loop completes, return 'fl'. ✅

Now let's try longest_common_prefix(['dog', 'racecar', 'car']):

Initialization:
- Start with prefix = 'dog'
Compare with 'racecar':
- 'racecar' doesn't start with 'dog'? True. Shorten to prefix = 'do'
- 'racecar' doesn't start with 'do'? True. Shorten to prefix = 'd'
- 'racecar' doesn't start with 'd'? True. Shorten to prefix = ""
Result: Prefix is empty "". Immediate return "". ❌ No common prefix found.

Key Optimizations

This approach relies heavily on Horizontal Matching:

Shrinking Search Pattern: Instead of checking letter by letter precisely (vertical scaling index-by-index), we start by assuming the maximum possible prefix and aggressively peel off letters from the end whenever mismatches are found.
Early Escape: If the prefix shrinks to an empty string at any point, we completely abort without iterating through the rest of the array strings.

This pattern is highly effective, easy to read, and simple to reason out! 🚀

Happy coding! 💻

How I Fixed the Hashnode GraphQL API Stale Cache Bug (Stellate CDN)

Vicente G. Reyes — Mon, 23 Feb 2026 05:29:30 +0000

If you're using Hashnode's GraphQL API to fetch your blog posts for a custom frontend (like a React or Next.js portfolio), you've probably run into this incredibly frustrating issue: You publish a new post on Hashnode, but it doesn't show up on your website.

You check the API payload, and it's serving a stale list of posts. The new post is completely missing.

I spent hours debugging this, trying every cache-busting trick in the book. Here's what didn't work, why it failed, and the actual simple solution.

The Setup

My portfolio runs on React (Vite) and uses Hashnode as a headless CMS. I fetch posts using fetch with the official Hashnode GraphQL endpoint: https://gql.hashnode.com.

const res = await fetch('https://gql.hashnode.com', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ query: POSTS_QUERY, variables }),
});

When I added a new post, my local dev server still only showed the old posts.

The Failed Attempts

Hashnode uses Stellate, a powerful GraphQL Edge CDN. Stellate sits between your frontend and Hashnode's database, caching responses to make the API blazing fast. However, its caching mechanism is exceptionally aggressive.

Here are the standard tricks I tried to bypass the cache, all of which failed:

Setting standard HTTP headers: Adding Cache-Control: no-cache and Pragma: no-cache to the fetch call. Stellate ignores these from the client.
URL Query Params: Appending a timestamp ?_t=${Date.now()} to the endpoint URL. Since this is a POST request, Stellate keys the cache off the request body, not just the URL.
GraphQL extensions: Adding extensions: { cacheKey: Date.now() } to the JSON body. Stellate normalization strips this out.
Unknown GraphQL Variables: Injecting _cacheBust: Date.now() into the variables object. Stellate strips unknown variables.
GraphQL Comments: Injecting # ${Date.now()} directly into the query string. Stellate parses and normalizes the query string, stripping comments before hashing the cache key.

No matter what I did, inspecting the network tab always revealed the same mocking response header: gcdn-cache: HIT.

The Real Issue: Stellate Needs the `id` Field

The root cause isn't that Stellate is ignoring your cache-busting hacks; it's that Stellate doesn't know the data is stale.

Stellate automatically invalidates its cache when backend data changes (mutations). But to do this effectively across complex GraphQL graphs, it relies on a core concept: tracking Node IDs.

If your query doesn't ask for the id of the entities it's fetching, Stellate cannot trace the cached data back to the actual database records. When Hashnode updates its database, Stellate's purge mechanism fires, but if your cached query didn't include IDs, Stellate doesn't know to invalidate that specific query.

This is a well-known issue internally at Hashnode — they even created an ESLint plugin (require-id-when-available) for their own engineers to prevent it!

The Solution

The fix is almost disappointingly simple. You must include the id field in all your GraphQL queries and fragments related to Hashnode.

My original query looked like this:

query Publication($host: String!, $first: Int!) {
  publication(host: $host) {
    posts(first: $first) {
      edges {
        node {
          slug
          title
          brief
          publishedAt
        }
      }
    }
  }
}

The fix is simply adding id inside the node:

query Publication($host: String!, $first: Int!) {
  publication(host: $host) {
    id  # <-- ESSENTIAL FOR LIST INVALIDATION
    posts(first: $first) {
      edges {
        node {
          id  # <-- ESSENTIAL FOR ENTITY INVALIDATION
          slug
          title
          brief
          publishedAt
        }
      }
    }
  }
}

Make sure to add id to everywhere you query entities: the parent publication object, posts, post, seriesList, etc.

Why both?

Adding id to the node tells Stellate to update the cache for that specific post if it gets edited.
Adding id to the parent publication tells Stellate to invalidate the entire list of posts for that publication when a new post is published or deleted.

Once I updated my queries and refreshed, the CDN properly registered the unique records and lists. New posts now invalidate the cache automatically, and the API returns fresh data immediately upon publishing.

Takeaway: When working with GraphQL APIs behind Edge CDNs like Stellate, always fetch the id. It's not just good practice; it's the anchor for their entire caching strategy.

DEV Community: Vicente G. Reyes

I Built an Enterprise Coffee Dashboard (That Refuses to Brew Coffee)

What I Built

Demo

Code

How I Built It

Prize Category

The fine.dev site is showing Deployment Paused

Should I stress over a staging environment?

Post-Mortem: The March 2026 Axios Supply Chain Attack

The Incident

Incident Summary

Technical Deep Dive

Remediation & Verification

Claude Code vs Antigravity?

Sorting Hashnode Series Posts: How to Display the Latest Post First

The Problem: Oldest First Pagination

The Solution: A Client-Side Cache & Array Reversal

Re-writing fetchSeries in TypeScript

Why this approach is awesome:

Building a Seamless JWT Onboarding Flow with React Router v7 and Django

The Architecture Stack

The Goal

1. Setting up the Django Backend

The Custom User Model

Customizing the JWT Payload

Enforcing Onboarding with Middleware

Refreshing Tokens upon Onboarding

2. Setting up the React Frontend

Bypassing CORS locally

Global Authentication Context

Route Protection and Redirection

Conclusion

Why I Built My Own Unlimited Audio & Video Transcriber

The Tech Stack

How It Works

1. Handling the Uploads

2. Extracting Audio from Video

3. GPU-Accelerated Transcription

4. Exporting the Results

The Result

What do you call a developer that doesn't reply? A seen-ior developer

A Reimagined Classic: DrugLord '98 in the Browser

The Vibe: Neon Green on Pitch Black

Gameplay Mechanics: Survive and Thrive

🎭 The Metro Manila Market

💼 Inventory & Risk Management

🏦 Financial Strategy

🚔 Random Encounters

Under the Hood: The Modern Tech Stack

Final Verdict

Problem 15: Longest Common Prefix

The Problem

The Solution

Code Breakdown

Example Walkthrough

Key Optimizations

How I Fixed the Hashnode GraphQL API Stale Cache Bug (Stellate CDN)

The Setup

The Failed Attempts

The Real Issue: Stellate Needs the id Field

The Solution

Re-writing `fetchSeries` in TypeScript

The Real Issue: Stellate Needs the `id` Field