"Another icon library? Bold strategy."

At some point every frontend engineer reaches the same spiritual checkpoint: your app needs one icon, then three, then forty, then suddenly you are debugging SVG stroke alignment at midnight while pretending this is normal adult behavior.

So yes, I made another icon package.

Because clearly what the JavaScript ecosystem was missing was one more icon library named @bhaumic/zenicons with 3,201 icons, strict typing, and a searchable catalogue. Totally unnecessary. Completely avoidable. And yet, deeply useful.

Why I built it (besides poor life decisions)

I wanted icons that were:

• Tree-shakeable by default
• Type-safe in React + TypeScript
• currentColor friendly for real theming
• Consistent to generate from raw SVGs
• Publish-safe for npm without shipping accidental chaos

In short: not a random folder of SVGs lovingly copy-pasted across repos for eternity.

What Zenicons gives you

Zenicons ships as a React-first npm package with:

• 3,201 typed icon components
• ESM + CJS + type declarations
• sideEffects: false for better bundler tree shaking
• Shared IconBase behavior
• A searchable live archive at mic-360.github.io/zenicons

And yes, it supports practical props:

• size (default 24)
• color (default currentColor)
• strokeWidth (default 1.5)
• title for accessibility labels
• variant (stroke or fill, per icon override)

Because if a component library cannot pass basic accessibility smell tests, it is just decorative debt with a README.

Install like a responsible engineer

npm install @bhaumic/zenicons

npm install @bhaumic/zenicons

If you like deterministic installs from source snapshots:

npm install github:Mic-360/zenicons#v0.1.0

npm install github:Mic-360/zenicons#v0.1.0

Usage (no blood sacrifices required)

import { IconAddressBookEmail, IconSigma } from '@bhaumic/zenicons'

export function Example() {
  return (
    <div style={{ color: 'tomato' }}>
      <IconAddressBookEmail />
      <IconAddressBookEmail size={32} color="royalblue" strokeWidth={2} />
      <IconSigma size={48} title="Sigma icon" />
    </div>
  )
}

import { IconAddressBookEmail, IconSigma } from '@bhaumic/zenicons'

export function Example() {
  return (
    <div style={{ color: 'tomato' }}>
      <IconAddressBookEmail />
      <IconAddressBookEmail size={32} color="royalblue" strokeWidth={2} />
      <IconSigma size={48} title="Sigma icon" />
    </div>
  )
}

The icon inherits your text color by default. This is how it should have been from day one, but history had other plans.

The boring engineering bits that actually matter

Most icon packs stop at "it renders." Zenicons also enforces release hygiene:

• Tarball verification before publish
• Controlled publish surface
• npm provenance through GitHub Actions
• Lockfiles committed for package and demo

In other words: fewer supply-chain surprises, fewer accidental file leaks, fewer Friday-night rollback adventures.

Live search, because scrolling 3,201 names manually is a cry for help

The live site exists for one reason: quickly find an icon and copy the import without memorizing naming gymnastics.

• Press Ctrl/⌘ + K or /
• Search by fragment
• Copy import instantly
• Move on with your life

Final thoughts

Could I have reused a giant existing icon set and called it a day? Yes.

Would I have learned as much about generation pipelines, packaging discipline, and release safety? Not even close.

Zenicons is for teams that want icons to be infrastructure, not drama.

• npm: @bhaumic/zenicons
• GitHub: Mic-360/zenicons
• Live catalogue: mic-360.github.io/zenicons

Thanks for reading. If this saved you one SVG alignment rage-session, my work here is done.

"Just put it on JustDial bro" — every uncle who saw the prototype.

So here's how it started. India has thousands of fabrication labs, 3D printing services, CNC shops, laser cutters, PCB houses, and assorted machine wizards tucked into back alleys from Pune to Coimbatore. Discovery is, professionally speaking, vibes. You ask a friend. Who asks a friend. Who sends you a 2017 PDF brochure on WhatsApp. The PDF has a phone number that doesn't work.

I thought: what if there was a website. What if the website had search. What if the search had filters.

Reader, that's where the discipline ended.

The Problem Nobody Was Specifically Begging Me To Solve

Two real users exist in this market and they hate each other in a beautiful, codependent way:

1. Makers and small manufacturers who need a 5-axis CNC for one (1) prototype next Tuesday and have no idea who in their state can actually do it.
2. Lab owners who would love more inbound leads but currently rely on the eternal mercy of Google ranking their Wix site above someone's cousin's Wix site.

The obvious solution was a directory. A simple directory. A list. The kind of project you finish over a long weekend, deploy to Vercel, and forget about.

I did not build that.

What I Actually Built (Brace Yourself)

I built LabsInIndia — a full two-sided marketplace with:

• A claims pipeline where lab owners prove they own a listing with uploaded documents that an admin then moderates
• Location-gated reviews where you can only review a lab if your profile city/state matches, with optional real-location verification for a fancier trust badge
• A comparison tray that works for guests via local storage and upgrades to a saved, shareable board the moment you log in
• Three Razorpay subscription tiers with signed-webhook-only entitlement granting, because I do not trust the frontend and frankly neither should you
• Analytics dashboards for paid owners showing demand, visitors, machine interest, and leads
• ZeptoMail transactional emails for moderation, claims, reviews, billing, and lead alerts, with delivery logging and idempotency keys
• Typesense-powered search across labs, machines, and profiles, with a reindexing cron and a Docker compose just for local dev
• Twelve Supabase migrations with Row-Level Security on basically every table because the threat model is "people will absolutely try"
• A social graph where you can follow labs, makers, and admins, and a feed shows you marketplace-safe activity
• A /x402 payments route because I read a spec and decided it was personally my problem now

For a directory. Of workshops. In India.

The "Just Use Algolia" Conversation I Had With Myself

I needed search. Postgres full-text search would have been fine. ILIKE '%cnc%' would have been fine. A <select> element would have been spiritually fine.

I deployed Typesense.

In Docker. With a docker-compose.typesense.yml. With a typesense:setup script. With a typesense:reindex script. With a typesense:health script. With a cron job that processes search index update queues.

For ~50 listings I had at the time. That's roughly one container per lab. Excellent ratio. Very normal.

bun run typesense:start
bun run typesense:setup
bun run typesense:reindex
bun run typesense:health

bun run typesense:start
bun run typesense:setup
bun run typesense:reindex
bun run typesense:health

Look at all those bun runs. That's craftsmanship.

RLS Tables Will Find You In Your Sleep

Supabase Row-Level Security is genuinely great until you have:

• labs (public read if approved, owner write, admin override)
• machines (inherits lab visibility)
• claims (only the claimant + admins; documents in a private bucket)
• reviews (public read if approved, write only if location matches, edit only if you're the author and we're inside an edit window)
• follows (public read, write only if you're not following yourself, please)
• subscriptions (read your own, write only via webhook with service role)
• email_logs (admin only — these contain things)
• analytics_events (insert anywhere, read scoped by entitlement tier)
• comparison_boards (public if marked shareable, otherwise owner-scoped)

I have a docs/ folder with twelve markdown files just for the RLS notes. Each one ends with "and a short local smoke check." I have written enough smoke check scripts to start a small wildfire.

The Webhook That Made Me A Better Person

The Razorpay webhook is the only part of the platform where I genuinely could not be lazy. Lazy here means: a user pays you money and your app forgets.

So the flow is:

1. Razorpay subscription event fires.
2. Webhook verifies the signature with the secret.
3. Idempotency key is checked against a processed_webhook_events table.
4. If new, the event is logged, the subscription row is updated, and entitlements are granted.
5. If duplicate, we shrug atomically and return 200 so Razorpay stops re-delivering.

The frontend has no role in any of this. The frontend's job is to look pretty and redirect to checkout. Anything the frontend says about your subscription status is a polite suggestion, not a fact. The fact lives in the database, written by the webhook, gated by RLS, and triggers a ZeptoMail receipt.

For directory listings. Of labs. That make brackets.

The Comparison Tray That Required A Spec

You know that Amazon "compare products" feature you've never used? I built it. For lab capabilities. With a guest mode using localStorage. With a sign-in upgrade path where the local tray merges into the server-side board. With shareable URLs. With permissions on who can view a shared board. With a max-items limit because someone, somewhere, will try to compare 47 labs.

The doc for this feature alone is longer than my last three blog posts combined.

Location-Verified Reviews, Because Yelp Wasn't Enough

You cannot review a lab unless one of:

• Your profile city matches the lab's city, or
• Your profile state matches and you've consented to current-location verification at the time of writing the review

The second path stamps the review with a "verified visit nearby" badge. The first path gives you a normal review. Anyone outside both paths gets a polite "you can't review this" notice and a suggestion to update their profile location.

Why? Because the moment you let anyone review anything from anywhere, you get a Bangalore lab whose 1-star reviews are all from someone in Delhi who's never been within 2000 km of a lathe.

The privacy boundary is the part I'm proud of: we store the verification result and a coarse city-level signal, not the user's actual coordinates. The map UI knows. The database does not.

Stack, Because People Ask

Yes, Tailwind v4. Yes, React Compiler. Yes, Bun. I am one of those people now. I'm sorry.

Was It Worth It?

The site is live. It loads. It has labs. It has machines. It has reviews. People are claiming listings. Lab owners are getting actual leads they can actually act on. A small subset of them are paying real money for analytics dashboards that show them actual visitor patterns.

A directory of workshops in India is now powered by Typesense, Razorpay webhooks, RLS, three-tier subscriptions, location-verified reviews, and a comparison tray with shareable boards. Each one of these features was, at some point, "maybe overkill."

None of them are overkill once a real owner emails you with a real claim about a real lab they want to manage, and the right thing happens automatically.

That, weirdly, is the whole point. The over-engineering wasn't the bug. The over-engineering was the only way the boring outcome — trust — ever shows up.

If you run a fab lab, machine shop, PCB house, or anything that turns CAD into atoms in India, list it on LabsInIndia. If you're a maker, find the people who can build the thing for you. If you're a developer reading this thinking "this is too many features for one project," you are correct, and also welcome.

You're welcome. And, again, I'm sorry.

"If it doesn't go clack, was it even thinking?"

Somewhere between my third cup of coffee and my second existential crisis of the week, I decided the biggest unsolved problem in software engineering was that Claude Code is too quiet. Not too slow. Not too expensive. Too. Quiet.

Yes. That was the gap. That was the thing holding back civilization.

The Problem Nobody Asked Me To Solve

Here's the thing about watching Claude write your code for you: it just… does it. Silently. Like a ghost with a CS degree. One moment the file is empty, the next there are 300 lines of Rust that you definitely didn't write and now sort of have to understand. There's no drama. No sense of effort. No visceral feedback loop that says "yes, something is happening and you should feel good about it."

Keyboards go clack. That's the deal. When humans type, things clack. When Claude types, you get nothing but a blinking cursor and the quiet shame of knowing it's faster than you.

Unacceptable.

The Solution: A Rust Daemon That Makes Sounds At A Machine That Cannot Hear

Enter Chappie — a Claude Code plugin I built that solves this non-problem with a frankly disproportionate amount of engineering.

The architecture is, genuinely, something:

• A Rust binary polls a nonce-tagged signal file
• Claude's lifecycle hooks fire that binary on every tool call, every prompt submission, every pause for your permission
• Six WAV files — live-recorded Blue Switch mechanical key clicks, a spacebar, an alert ding — get downloaded on first run and cached in ~/.claude/sounds/
• A flow-state rhythm engine models sprinting, cruising, and deliberate typing patterns so the sounds feel like a workaholic, not a metronome

A workaholic. The sounds model a workaholic. I did this.

// Real code I wrote so an AI could sound like it cares
fn roll_burst(rng: &mut impl Rng, n: u8) {
    for _ in 0..n {
        play_key(rng);
        sleep_ms(rng.gen_range(25..40));
    }
}

// Real code I wrote so an AI could sound like it cares
fn roll_burst(rng: &mut impl Rng, n: u8) {
    for _ in 0..n {
        play_key(rng);
        sleep_ms(rng.gen_range(25..40));
    }
}

The Feature That Broke Me

There is a TYPO_CHANCE constant set to 0.06.

Six percent of the time, Chappie plays a fast backspace rattle followed by a retype — to simulate Claude making and correcting a typo.

Claude does not make typos. Claude is a language model. It outputs tokens. It has no fingers, no fatigue, no distracted thought that leads to hitting r instead of t. And yet here I am, at my desk, having engineered the impression of fallibility into a machine that is, statistically, less mistake-prone than I am.

I'm going to sit with that for a moment.

The Part Where I Justified It With System Performance

To be clear, I did not just write a script that plays sounds. That would be beneath me apparently.

I wrote a single-instance daemon with a nonce-based signalling system so concurrent hook invocations can never clobber each other. I opted the daemon into Windows EcoQoS — efficiency mode, below-normal CPU priority — because if you're going to waste battery on keyboard sounds, you should at least waste it efficiently.

The hooks invoke a compiled binary, not a shell script, so the behavior is identical on Windows, macOS, and Linux. It's cross-platform clacking. For a non-problem. I am very normal.

The Tuning Table (Yes, There Is A Tuning Table)

The daemon models fatigue. I added an idle timeout so it shuts itself down after fifteen seconds of silence, presumably to rest. I gave the sound daemon a concept of rest. It now has a better work-life balance than me.

Was It Worth It?

Absolutely. Unequivocally. I now sit here, watching Claude blast through file system refactors, and I hear every single keystroke. It sounds like a developer is working. It sounds like effort. It sounds like someone cares deeply about my codebase.

None of those things are true. But they sound true. And in this economy, vibes are load-bearing.

The first time Claude paused for my tool approval and a soft ding played — the typing stopping mid-word, just like a real human would — I felt something. I don't want to talk about what I felt. But I felt it.

If you want your AI assistant to have the acoustic presence of a 1990s IBM Model M, Chappie is open source and MIT licensed. Install it, build the daemon, and join me in the frontier of problems I created and then solved.

You're welcome. And I'm sorry.

"Streaming services rent films the way restaurants rent forks. HikariPlay is just the dining room you already had — with the lights done right."

That quote is from my own app's landing page. I wrote it. About my own app. While the app was being built. This is the level of delusion we are operating at.

Let me be very clear about what happened here.

I had a Google Drive folder. It contained some video files. These files played fine in VLC. They played fine in the browser via a direct link. The problem — the devastating, sleep-depriving, week-consuming problem — was that they did not play in a bespoke private cinema interface with cinematic serif typography, an automatically-fetched poster from AniList, and a scrolling ticker tape of catalogue numbers.

A tragedy. I had no choice.

The Threat Model

Let's establish who HikariPlay is for: me, and three other people in my household who are emphatically not going to configure a Plex server, memorize a port number, or hear the words "transcoding queue" ever again.

Netflix costs money every month for content I mostly don't want. Plex requires a server, media scanning, a library daemon that occasionally decides everything is the wrong show, and a paid Pass for features that should not be paywalled. Jellyfin is Plex's open-source twin and shares all the same complexity at a 40% discount in stability.

The actual problem I was solving: I own some video files. I want to watch them from the couch without dragging a cable across the room. I want posters. I want "resume where I left off."

The actual solution I built: a full SvelteKit application with a Google Drive indexer, two external poster APIs, an IndexedDB resume-position tracker, a VLC handoff mechanism, and a landing page that would not look out of place at a film festival.

I am a reasonable person.

How the Indexing Works (It's Embarrassingly Simple)

Here is the entire secret behind HikariPlay's "catalogue":

You give it a public Google Drive folder ID. That's it. That's the setup process. The SvelteKit server walks the Drive folder tree recursively — up to six concurrent page-fetches via a hand-rolled pLimit(6) concurrency limiter because apparently adding a tiny npm package was too easy — reads every filename, and parses them into titles, years, seasons, and episodes using a filename parser that handles SxxExx, NxNN, (Year), and a kill-list of 30+ scene release tags like WEB-DL, DDP5.1, and HEVC. Because real media filenames look like Zootopia.2.2025.2160p.WEB-DL.DDP5.1.x265.mkv and the app is going to show a tasteful serif title card regardless.

This is either elegant minimalism or structural laziness dressed in a trench coat. The line is thin.

Content types are exactly two: anime and movie. Not anime | film | series | short | documentary | director-cut-extended-imax. Two. The type controls which poster API gets tried first. That's the entire purpose of the type field. The catalogue is sorted by folder path then filename — which is also either elegant or lazy, and which also does not matter, because the gallery has a Fuse.js fuzzy search with a 0.35 threshold that means you can typo the title and still find it.

The Poster Pipeline, or: "Why Are You Calling Two Different APIs?"

AniList has better anime metadata and higher-quality poster images than OMDb. OMDb has better film and TV metadata. Neither covers everything.

The resolution strategy: try AniList first (if type is anime). If the title matches and a poster URL comes back, use it. If AniList returns nothing, try OMDb. If OMDb returns nothing, fall back to the Drive file thumbnail. If that also fails, render the kanji placeholder.

This is a four-step fallback chain for what is fundamentally a JPEG. I am not sorry. The alternative is showing a blank grey square for "Dune: Part Two" and that is not acceptable.

The poster resolution result is cached in two places simultaneously: the server holds an in-memory Map with a 24-hour TTL so hot requests don't re-hit the external APIs. The client stores the result in IndexedDB with a 30-day TTL via the idb library so posters survive a server cold start without flickering. The client tries IndexedDB first, calls /api/poster on a miss, writes the result back. The server responds with a cache-control: public, max-age=86400, stale-while-revalidate=604800 header. Everyone is caching this JPEG. Nobody will ever see a loading state twice.

The Player, Which Is Just a <video> Tag Talking to a Proxy

The video player is a standard HTML5 <video> element. There is no custom media engine. There is no transcoding. There is no adaptive bitrate streaming.

However — and here is the detail that cost me a day — the browser cannot hit the Drive URL directly. Google Drive's short-lived download tokens are bound to the server session that fetched the confirmation HTML. If you redirect the browser straight to the resolved URL with its own cookies and session, Drive returns a 403. So all video traffic is proxied byte-for-byte through the SvelteKit server, which pipes the upstream response while forwarding content-type, content-length, content-range, accept-ranges, and Range request headers for seek support.

The stream resolver has two strategies: first it tries the authenticated Drive API endpoint (alt=media with the API key), which has a much higher quota and doesn't trigger the antivirus interstitial. If that fails, it falls back to the public /uc?export=download URL, parses the HTML confirmation page for the uuid/at tokens, and uses those. This is the kind of implementation detail you only understand by encountering a 403 at 1am.

If your browser can play the codec, it plays. If it can't — welcome to the VLC handoff.

The right panel shows "Programme Notes" because I am a deeply committed person. It displays the reel type (Feature Film, Anime, etc.), the source (Drive), the folder path within Drive, and the filename. The back button says "← BACK TO GALLERY." The floating vertical text on the right reads "上映中" — "Now Showing" in Japanese.

I did this for an app that at time of launch had exactly three entries in the catalogue. Zootopia 2, something with "V2 Hdhub4u" in the filename that should probably not be discussed further, and a short film I made.

The VLC Handoff: Engineering a Solution to a Problem Every Decent Video Player Already Solves

Some files refuse to play in a browser. H.265 main profile. DTS audio. Anything encoded with flags that Chrome politely declines. For these, HikariPlay offers the "External Projection" panel.

The panel presents:

• A PLAY IN VLC button that constructs a vlc:// protocol URL and clicks it
• A COPY STREAM URL button that copies the raw Drive stream URL to clipboard
• The raw URL displayed in a monospace input field with a copy icon

You open VLC. You paste the URL into Open Network Stream. You watch your movie at full quality with the correct codec. The instructions helpfully say "L PASTE INTO VLC · OPEN NETWORK STREAM." The capital L is not a typo. It is a design choice.

Is this equivalent to just copying a Google Drive link and opening VLC? Yes. Does having it inside a bespoke cinema interface make it feel significantly more intentional? Also yes. This is the entire premise of HikariPlay.

The "Resume Where You Left Off" Feature, Which Has No Server

Here is where the architecture gets genuinely interesting rather than just typographically ambitious.

"Continue Watching" is powered entirely by localStorage in the browser under the key hp:cw. No accounts. No server writes. No backend tracking. Playback position is serialised to a JSON record on pause, visibilitychange, and beforeunload. When you return to a film, the player reads the stored offset and seeks to it before playback begins.

The resumable threshold: more than 5 seconds in, less than 95% complete. Hit 95% and the entry is still there but the gallery won't show a "resume" indicator — you've seen the film, no need to resume the credits.

The implementation is a plain TypeScript module (continueWatching.ts) with getAllEntries, saveProgress, clearEntry, and isResumable — each reading and writing the same localStorage key. A Svelte 5 $state class (cwStore) wraps it so the gallery reactively updates its "Continue Watching" row without any subscriptions or observables.

This means:

• Resume works completely offline
• Resume requires no login
• Resume is isolated per device and browser, by design
• Resume data cannot be subpoenaed because it does not exist on a server

The feature sheet on the landing page calls this "no telemetry — just a bookmark in time." That sentence is doing a lot of work. I am proud of it.

The Features Section Has More Design Than My Previous Four Projects Combined

Let me talk about the landing page, because the landing page deserves to be talked about.

It is black. The typography is a serif/sans-serif editorial split that I spent an embarrassing amount of time calibrating. The hero headline reads "A private cinema for the films you actually own." The word cinema is in italic. The word films is in red italic. "You actually own" is the implied critique of Netflix.

There is a scrolling ticker tape at approximately 30% viewport height that runs cinema-adjacent words in uppercase spaced tracking: HIKARI, TOKYO REEL, MIDNIGHT SCREENING, SAISEI, ARCHIVE, 24 FPS, DRIVE STREAM, NO LOGIN. It scrolls left continuously. It serves no functional purpose. I added it at 11pm and have felt nothing but satisfaction since.

The landing page runs GSAP 3 with ScrollTrigger for all its entrance animations: feature cards stagger in, the manifesto section scrub-reveals word by word as you scroll, the spec sheet rows slide in from the left with 80ms stagger, the final CTA scales up from 0.92. The hero device element has a parallax offset of 0.15. These are not lazy CSS animation: fadeIn. They are carefully tuned gsap.from() calls with power3.out easing, wrapped in gsap.context() and cleaned up on onDestroy. This is the appropriate amount of effort for a video player for four people.

The features section has four cards in a grid. Each card has:

• A number in red (N°01, N°02, etc.)
• A title in serif
• A kanji word in the upper right corner in a lighter weight
• A description
• A short horizontal rule at the bottom

The kanji words are: 索引 (Index), 映写 (Projection), 装丁 (Binding/Design), 記録 (Record). None of these are visible to users who don't read Japanese. This is not a problem. It is a vibe.

The Manifesto Section, Because Every Private Video Player Needs a Manifesto

Section three of the landing page is a manifesto. I wrote a manifesto. For a video player.

"Streaming services rent films the way restaurants rent forks. HikariPlay is just the dining room you already had — with the lights done right."

On the right side of the manifesto section is a tech sheet formatted as a table with labels in spaced uppercase: RUNTIME, STORAGE, AUTH, CAPACITY, POSTERS, PLAYER. The values are: SvelteKit · Node 20 · Cloud Run, In-memory + IndexedDB, None — single household, 10–50 titles · 1–4 viewers, AniList · OMDb · Drive, HTML5 video · VLC handoff.

"None — single household" for AUTH is my favorite line in any documentation I have ever written.

The Capacity Field Says "1–4 Viewers" and I Stand By This

"10–50 titles · 1–4 viewers."

Not because SvelteKit can't handle more. Not because Google Drive has a hard cap. Because this is genuinely a household cinema tool. It is not Plex. It is not Jellyfin. It is not meant to be used by fifty people concurrently streaming different content.

It is meant for one person on the couch, or two people deciding what to watch, or four people for movie night. Beyond that you're running a screening room and you should probably have a server rack.

Designing software with an honest capacity model is something I find more interesting than designing software that claims to scale to infinity and then fails at twelve.

What I Actually Learned

The Drive API's public folder access is straightforward for read operations but requires careful URL construction for streaming — particularly the &confirm=t bypass for large files that trigger Google's antivirus warning page. Getting that right the first time saves a day.

In-memory catalogue state on a stateless Cloud Run instance means every cold start re-fetches the Drive tree. For a 10–50 title catalogue this is fast enough to not matter. For a 500-title catalogue it would be noticeably slow. The architecture is honest about its intended scale.

The VLC protocol URL (vlc://) requires VLC to be registered as a URL handler on the OS. On macOS this works automatically with a VLC install. On Windows it requires enabling it during install. This is documented in the UI with exactly zero user-facing warnings, which is consistent with the overall philosophy that the audience of this app knows what VLC is.

The Numbers

• 1 Google Drive folder ID required to run the entire application
• 2 external poster APIs with a 4-step fallback chain
• 2 cache layers per poster: 24h server in-memory Map + 30-day client IndexedDB
• 10 minutes — server-side video list cache TTL before a Drive re-walk
• 0 accounts, 0 tracking, 0 backend database writes for playback state
• localStorage — where your continue-watching data lives, not the cloud
• 30 scene release tags the filename parser knows to strip before showing you a title
• 6 concurrent Drive API page-fetches from the hand-rolled concurrency limiter
• 3 films in the catalogue at time of first public screenshot
• 1 of those films has "Hdhub4u" in the filename
• Infinite scrolling ticker tape that serves no purpose except being correct

HikariPlay is what happens when you have a Google Drive folder, strong typography opinions, and the knowledge that the default browser video player has no sense of occasion.

View on GitHub

View Live

"Every short link is just a tracking pixel wearing a trench coat."

It started, as all questionable life decisions do, with a LinkedIn share.

I went to paste an article link into a message and watched the URL balloon to 400 characters. utm_source=newsletter&utm_medium=email&utm_campaign=q1_2026_march_week3_segment_b_resend_v2_final_FINAL. Beautiful. Poetic. A complete dossier on exactly where I came from, what newsletter I read, and which A/B test variant I was deemed worthy of.

I thought: surely there's a good link shortener that strips this garbage. Something clean. Something that doesn't also sell my click data to seventeen ad networks.

Reader, there wasn't.

So naturally I built one.

The Audacity of Building a Link Shortener

Let me be upfront: link shorteners are a solved problem. bit.ly exists. TinyURL exists. There are approximately four hundred other services doing this. The correct answer here was to pick one and move on with my life.

I did not pick one and move on with my life.

The problem isn't shortening. The problem is that every major shortener is in the business of analytics, which is a polite word for surveillance. You don't get a short link — you get a tracking pixel with a redirect stapled to it. Your clicks are a product being sold before you've finished clicking.

The pitch for Shortlinks is boring on purpose: strip the tracking parameters, make a short link, count the clicks as a single integer on the link document, and stop there. No cohort analysis. No funnel attribution. No "users who clicked this also clicked..." sidebar.

The URL Cleaning Pipeline (Or: Knowing Your Enemy)

The fun part was cataloguing every tracking parameter I could find. You think utm_source is the whole list? Adorable.

utm_*       — Google's gift to marketers everywhere
fbclid      — Facebook wants to know you clicked
gclid       — Google Ads, watching from the shadows
msclkid     — Microsoft decided they wanted some too
igshid      — Instagram's secret handshake
igsh        — Instagram's even more secret handshake (yes, both)
mc_cid      — Mailchimp, tracking your email opens with links now
twclid      — Twitter/X, forever lurking
yclid       — Yandex, making a surprise appearance
spm         — Alibaba's contribution to the surveillance economy
_ga, _gl    — Google Analytics, haunting your query strings

utm_*       — Google's gift to marketers everywhere
fbclid      — Facebook wants to know you clicked
gclid       — Google Ads, watching from the shadows
msclkid     — Microsoft decided they wanted some too
igshid      — Instagram's secret handshake
igsh        — Instagram's even more secret handshake (yes, both)
mc_cid      — Mailchimp, tracking your email opens with links now
twclid      — Twitter/X, forever lurking
yclid       — Yandex, making a surprise appearance
spm         — Alibaba's contribution to the surveillance economy
_ga, _gl    — Google Analytics, haunting your query strings

The cleaner runs through the URL's query params and drops anything that matches. Platform-specific params — YouTube's v= and list=, Google Drive's file IDs, document anchors — are preserved. Cleaning should never break a link. That's the one invariant that matters.

What's left after cleaning is what gets stored. The original URL is also preserved for auditability. You can verify the receipt.

Platform Detection: The Feature Nobody Asked For That Turned Out to Be Useful

I added platform detection because redirect metadata seemed useful to have. Twenty-three platforms — LinkedIn, YouTube, Instagram, X, Google Drive, Docs, Sheets, Forms, Maps, GitHub, Notion, Figma, Spotify, Discord, Telegram, Notion, Pinterest, Reddit, TikTok, Amazon, Medium, WhatsApp — matched by host regex. Everything else falls through to web.

The platform is metadata only. Every short link still redirects from a flat path. But when you're scanning a list of shortened links and trying to remember which YouTube video you shared two weeks ago, having youtube stamped on it is genuinely useful.

It also routes the redirect through a platform path segment — /youtube/abc123 instead of just /abc123 — which has the side effect of being faintly readable by human beings, a property link shorteners have historically not prioritized.

Three Doors Into the Same Engine

This is the part I'm actually proud of.

The same URL cleaning and link creation logic ships in three interfaces from one codebase:

Website. Paste a URL, get a short link, copy it. The whole flow is a single form. Nothing else on the page does anything clever. That's the point.

REST API. POST /api/v1/links with a JSON body. Returns the slug, the short URL, the cleaned URL, and the detected platform. Rate-limited to two creations per second per identity — same limit as the website, applied consistently.

MCP server. This is where it gets slightly absurd in a good way. The same engine ships as a Model Context Protocol server that AI agents can connect to. Three tools: create_short_link, clean_url (strip tracking params and get metadata without creating a link), and get_link_info (look up an existing slug). Drop the endpoint into Claude Desktop and your AI assistant can shorten links.

I built a link shortener that AI agents can use. In 2026, this is apparently a reasonable thing to do. I've made peace with it.

Rate Limiting Without Storing Your IP Address

The rate limiter does two creations per second per identity. The implementation detail I'm pleased with: rate limit identifiers are SHA-256 hashes of the IP or API key, stored in Appwrite as the window key. The raw IP never hits the database. A record that says sha256:a3f9... can't be reverse-engineered to identify anyone. It's still a useful rate limit. It just doesn't double as a surveillance database.

The window logic creates a document per identity per second. On conflict, it increments an attribute with a ceiling. If the ceiling is exceeded, Appwrite returns an error that the rate limiter catches and translates to a 429. The rate limit document expires sixty seconds after the window closes. No cron jobs, no cleanup workers.

Was It Worth Building?

Probably not from a pure time-to-value calculation. bit.ly is free. I could have just used that.

But bit.ly would have tracked me. And building this took one weekend, left me with a codebase I can actually read, and gave me an MCP server I can wire into my AI tooling for link operations.

The tracking parameter list alone was worth researching. Turns out the surveillance economy has done tremendous work on naming conventions. At least they're thorough.

Try it at shortlinks.bhaumicsingh.tech. Paste something long, get something short, notice the utm_ junk is gone, move on with your day.

Source is on GitHub if you'd like to audit the list of things being stripped from your URLs.

"Some people read books on trains. Some stare out the window. I fork repos and send AI agents into battle."

Picture this: you're on a train, the WiFi is barely legal, the person next to you is watching a cooking reel at full volume without headphones, and you — you absolute menace — decide this is the perfect time to contribute to open source.

Not just one commit. Nine pull requests. Security patches. Performance optimizations. A full Termux deployment pipeline. Deployed to your own Android phone. From. A. Train.

Welcome to what happens when you combine a GitHub repo, Google Jules, spotty 4G, and a complete disregard for the concept of "downtime."

The Discovery

I was doom-scrolling through GitHub — because apparently I can't even scroll through feeds like a normal person, I have to do it on a developer platform — when I stumbled across ReClip. A self-hosted media downloader. Python + Flask. ~150 lines of backend code. Clean vanilla HTML/CSS/JS frontend. Supports YouTube, TikTok, Instagram, Twitter/X, and about 1,000 other sites via yt-dlp.

The project was clean, minimal, functional. Naturally, my first thought was: "I can make this run on my phone."

My second thought was: "I should not be doing this right now."

Guess which thought won.

Enter Google Jules

For the uninitiated, Google Jules is an AI coding agent that lives inside your GitHub workflow. You describe a task, point it at a repo, and it opens a PR with the changes. It reads code. It writes code. It responds to review comments. It's basically that one coworker who actually reads the PR description before approving.

The workflow went something like this:

1. Fork the repo
2. Open Jules on my phone
3. Describe what I want
4. Jules opens a PR
5. GitHub Copilot auto-reviews the PR
6. I tell Jules to fix the review comments
7. Jules fixes them
8. Merge
9. Repeat from step 3 until the train reaches my stop

I was essentially orchestrating an AI code fight club from my pocket. Jules writes the code. Copilot reviews it. Jules fixes the feedback. I sit there watching two AIs argue about port numbers while the countryside blurs past my window.

This is peak 2026 developer experience.

The Nine PRs

Here's every improvement that shipped, in order. Every single one was authored by Google Jules, reviewed by either Copilot or myself, and merged before I finished my commute.

PR #1 — Termux Deployment & Android Optimization

The original repo ran great on macOS and Linux. On Android? Not so much. Jules added:

• Waitress WSGI server replacing Flask's dev server — because running a development server in production is a choice, but not a good one
• aria2c integration as an external downloader for yt-dlp, enabling multi-threaded downloads
• Suppressed yt-dlp console spam to reduce CPU and memory pressure on mobile
• DEPLOYMENT.md with full Termux + Cloudflare Tunnel documentation
• reclip.sh enhancements — Termux detection via $PREFIX, pkg install hints, automatic termux-wake-lock

Copilot flagged that --quiet would suppress the JSON output from yt-dlp's -j flag. Jules fixed it. Copilot noted the hardcoded threads=8 in Waitress. Jules made it configurable via WAITRESS_THREADS env var. The TERMUX_VERSION detection was unreliable — Jules switched to $PREFIX only.

145 additions, 10 deletions. The app could now run on a phone.

PR #2 — One-Click Termux Installer

Because apparently running four commands is too many:

• install.sh — automated Termux dependency installation (Python, FFmpeg, Git, Aria2, Cloudflared)
• start-background.sh — persistent background execution via nohup with log output and PID tracking
• Cloudflare Tunnel made explicit opt-in via ENABLE_CLOUDFLARED_TUNNEL=1 (Copilot correctly flagged the security risk of auto-exposing to the internet)
• Dynamic ${PORT:-8899} everywhere instead of hardcoded values
• Removed unused wget from the install list

One curl command. That's it. curl -O ... && bash install.sh and you're running a media downloader on your phone.

166 additions, 35 deletions.

PR #3 — Filename Sanitization Performance

Jules replaced a Python generator expression with re.sub() for stripping unsafe characters from filenames.

• Short titles: 32% faster
• Long titles: 90% faster (over 100K operations)

Two lines changed. An entire performance class unlocked.

PR #4 — PEP 8 Import Cleanup

Moved inline imports (shutil, waitress) to the top of app.py like civilized people. Added a HAS_WAITRESS flag for graceful optional dependency handling.

This is the PR equivalent of making your bed in the morning. Small. Satisfying. Suspiciously impactful on your mental state.

PR #5 — Security Fix: Argument Injection

This one actually mattered.

The yt-dlp command was being constructed by appending user-supplied URLs directly to the argument list. A malicious URL starting with a hyphen (e.g., --version, --exec) would be interpreted as a command-line flag. That's a textbook argument injection vulnerability.

Jules added -- before the URL in both get_info and run_download, forcing everything after it to be treated as a positional argument.

2 lines. The kind of 2-line change that prevents your self-hosted app from becoming someone else's self-hosted app.

PR #6 — Test Suite for /api/download

Added a pytest test suite covering:

• Missing URL → 400
• Empty/whitespace URL → 400
• Missing JSON body → 400 (previously crashed with a 500)
• Valid request → returns job_id, starts download thread

Jules also hardened the start_download function with request.json or {} to handle the missing body case. The kind of fix you write after the first time your phone crashes at 1 AM because someone sent an empty POST.

PR #7 — Reduced Cyclomatic Complexity

run_download was doing too many things. Jules extracted _build_download_command and _finalize_download as helpers. The function went from "monolithic wall of logic" to "three readable units."

More modules. Less cognitive load. More maintainable by future-me who will have forgotten everything about this codebase by next week.

PR #8 — Pre-Compiled Regex Sanitization

Doubled down on PR #3's approach. Replaced character-by-character string filtering with a pre-compiled RE_UNSAFE regex pattern.

• Baseline: 6.71s for 1M iterations
• Optimized: 3.53s for 1M iterations
• ~47% faster

Jules even wrote a verification script to confirm bit-for-bit output compatibility. On a phone, this kind of micro-optimization is the difference between "responsive" and "is this thing frozen?"

PR #9 — Apple-Style UI Redesign (Closed)

Jules went full designer mode. Complete visual redesign with:

• Custom CSS variable design system
• Automatic light/dark mode via system preference
• Zero-dependency inline SVGs
• Sage green accent color
• Skeleton loaders and smooth transitions

588 additions, 292 deletions. I closed this one without merging — it was too opinionated for a fork — but the output was genuinely impressive. Jules can ship frontend.

Deploying to My Phone

The whole point of PRs #1 and #2 was to make this stupid-easy:

pkg update && pkg upgrade
curl -O https://raw.githubusercontent.com/Mic-360/reclip/main/install.sh && bash install.sh

pkg update && pkg upgrade
curl -O https://raw.githubusercontent.com/Mic-360/reclip/main/install.sh && bash install.sh

That's it. The script installs Python, FFmpeg, Git, Aria2, Termux-API, and Cloudflared. It clones the repo, sets up a virtual environment, installs requirements, and starts the server.

Open http://localhost:8899 in your phone's browser and you're downloading media from 1,000+ platforms. On your phone. Running a Python Flask server. In Termux. Like a completely normal person.

Want to access it from another device? ENABLE_CLOUDFLARED_TUNNEL=1 ./start-background.sh gives you a public .trycloudflare.com URL. Your phone is now a server. Congratulations, you've peaked.

The Jules Workflow — What Actually Worked

Here's the honest assessment:

What went well:

• Jules understood the codebase fast. The context window handled the entire app.py (~150 lines) without breaking a sweat
• The Copilot → Jules feedback loop was surprisingly effective. Copilot flagged real issues (security, port consistency, output suppression), and Jules fixed them correctly
• Every PR description was detailed, well-structured, and included verification steps. Better than most humans write
• The security fix (PR #5) was a legitimate catch that Jules identified and patched proactively

What was weird:

• Jules tried to use --quiet with -j in yt-dlp, which would have broken JSON output. Copilot caught it
• The UI redesign PR was ambitious but I didn't ask for sage green. Jules just... chose sage green
• The commit messages had emoji. Every. Single. One

What I learned:

• AI agents are absurdly effective for "improve this codebase" style tasks on small-to-medium repos
• The fork → Jules → Copilot review → Jules fix → merge pipeline is a real workflow now
• You can do meaningful open source contribution from a train with a phone and zero IDE access
• The bar for "I don't have time to contribute" just got obliterated

The Scoreboard

Final Thoughts

I found a repo, forked it, shipped 9 PRs across security, performance, testing, deployment, code quality, and UI — and deployed the result to my own Android phone. All using Google Jules from a train.

The future of open source isn't sitting at a desk with three monitors. It's an AI agent in your pocket, a review bot on GitHub, and whatever signal strength the universe decides to grant you between stations.

Now if you'll excuse me, my stop is coming up and I need to merge one more thing.

ReClip on GitHub · Live Demo

"Why pay $3/month for Google One when you can spend 3 weeks building a private photo gallery instead?"

It started with Google Photos.

Specifically, it started with Google Photos deciding that my perfectly functional 2016 Pixel — a phone Google themselves promised unlimited original-quality storage to forever — no longer deserved unlimited original-quality storage. Forever, apparently, was a marketing term.

Fifteen gigabytes. Shared with Gmail. For a family photo archive.

Fine. I'll build my own.

The Architecture That Got Out of Hand

Here is the pitch: old Pixel devices already have Google Photos running locally. Google Photos backs up whatever it finds in a watched folder. So the plan was to run the backend on the Pixel itself, dump uploads into a sync folder, let Google Photos do the backup, then purge the originals after 12 hours. Previews stay forever. Gallery reads from Firestore metadata and preview files.

Reader, I drew a flowchart. It had six boxes. By the time I shipped, it had 14.

The actual pipeline:

1. Flutter app authenticates via Firebase OAuth
2. Upload goes to the Fastify API using the tus protocol — resumable uploads, because uploads die midway and life is pain
3. A BullMQ job fires off the upload worker
4. Worker moves the original to /sdcard/ShashinMori/<uid>/... (Google Photos picks it up automatically)
5. Worker runs Jimp to generate an optimized preview
6. Worker writes metadata to Firestore
7. A 12-hour cleanup job purges the original from the sync folder after backup
8. Gallery endpoints serve from Firestore metadata + the retained preview

This is what "simple photo backup app" looks like at 2 AM.

The Tech Stack, Annotated

Flutter + Riverpod + GoRouter on the frontend. Riverpod is the state management solution that makes you feel vaguely competent until BuildContext eats your soul. GoRouter is fine. Dart is fine. Writing Dart is like TypeScript with training wheels, which is either reassuring or insulting depending on your perspective.

Fastify + TypeScript on the backend. Faster than Express, more opinionated than I expected, very happy with it once the plugin system clicked.

tus protocol for uploads. The resumable upload standard that nobody talks about until you're dealing with spotty mobile connections and 50MB RAW files. @tus/server handles the chunked upload dance. The client-side tus_client_dart package does the same on Flutter. When it works, it's magic. Getting there was not magic.

BullMQ + Upstash Redis for the job queue. Fire and forget. The worker processes asynchronously so the upload endpoint returns fast and the heavy Jimp processing doesn't block anything.

Jimp for image processing. Pure JavaScript, no native binaries, runs on the Pixel without drama. Slower than Sharp. Doesn't require compiling native modules on ARM. Trade-offs.

The Design Decisions I Will Defend

This is an append-only archive. No delete. No download. Intentionally.

The point is preservation, not management. Photos go in. They stay in. Google Photos has a copy. The preview is always there. Nothing accidentally disappears because someone's toddler tapped delete.

Multi-user isolation is enforced at the Firestore level — every record is scoped to a UID, so family members sharing the backend can't see each other's photos.

Is it overkill for a family gallery? Absolutely. Is every architectural decision technically justified? Yes, actually. That's the worst kind of overkill.

What I Actually Learned

File uploads are a protocol, not a feature. If you're doing anything beyond a single-chunk POST, just use tus from the start.

BullMQ with Redis makes async job queues embarrassingly easy. The worker model — receive upload, enqueue job, return 200, process later — is the correct mental model for anything involving I/O you don't control.

Running a backend on a Pixel device is completely viable and deeply unhinged. Termux + PM2 + Docker-compatible deployment targets. I have regrets about the path I took to learn this.

The Numbers

• 6 npm packages that actually matter, surrounded by 30 that exist
• 1 old Pixel phone running a production API server in my living room
• 0 delete endpoints, on purpose
• 12 hours before originals get purged from the sync folder
• Indefinite preview retention, because that's the whole point

ShashinMori is open source. The architecture diagram alone is worth cloning it.

Grab it on GitHub. Your old Pixel deserves a second life.

Normal people: pays $20/month for hobby project hosting. Me: roots phone, installs Termux, rewrites deployment infrastructure from scratch at midnight.

Both are valid approaches to the problem. I'm not here to judge. I'm here to explain the sequence of decisions that led to me configuring Nginx on a Snapdragon 660 while the phone was also playing a lo-fi playlist.

The Inciting Incident

I had a rooted Android phone sitting in a drawer. I wanted to host some side projects. Vercel exists. Railway exists. Render exists.

I chose the drawer phone.

What Is MiniShinobi

It's a self-hosted, Vercel-like deployment platform that runs entirely inside Termux on a rooted Android device. You connect a GitHub repo, hit Deploy, and your project goes live on a real subdomain over HTTPS via Cloudflare Tunnel — all from a device that charges next to your bed at night.

The stack: Node.js backend, Vite/React dashboard, Nginx reverse proxy, PM2 for process management, sql.js for the database, and cloudflared for tunnels. All of it supervised by PM2 on a phone.

"We'll Just Use sql.js"

The first design constraint: you cannot compile better-sqlite3 on ARM Termux. Native Node addon compilation on ARM is a special kind of unpleasant that I don't recommend.

So the database runs on sql.js — SQLite compiled to WebAssembly. Zero native compilation, zero segfaults. Every write flushes the entire database buffer to disk. The database is small. The phone has 4 GB of RAM. This is fine.

It's cursed in a way that is technically completely fine.

"We'll Just Use child_process"

Similarly, node-pty needs native compilation. You know how that story ends.

So the entire deployment engine — git clone, npm install, npm run build, framework detection, process spawn — runs through Node's built-in child_process.spawn. Every byte of stdout and stderr is line-buffered and streamed live to the browser via Server-Sent Events. You watch your build happen in real-time from the dashboard, which is serving you that stream from a phone in your drawer.

Does it feel like it should work? No. Does it work? The phone is serving things to the open internet right now.

"We'll Just Use PM2"

pm2 start ecosystem.config.js and everything wakes up: the Express backend, Nginx, and cloudflared. Three supervised processes, one config file. If anything crashes, PM2 restarts it. On a phone.

This is the part where I discovered PM2 is genuinely great and I should have been using it everywhere.

The Build Queue (The Unsexy Correct Decision)

4 GB of RAM sounds fine until npm run build on a React app invites the OOM killer to the party.

There's a serialized build queue. One build at a time. If you deploy two projects simultaneously, one waits. It's not exciting. It's the right call for a device with less RAM than most laptops have VRAM.

I also added 1 GB of swap. Don't look at me like that.

Cloudflare Tunnels Are Legitimately Magic

cloudflared is the part that makes all of this actually work. You run one daemon, write a YAML config, and localhost:3000 is suddenly reachable at your-project.yourdomain.com over HTTPS with a valid certificate.

No port forwarding. No public IP. No router config. No DynDNS prayers. Every deployment gets its own named tunnel. Every project gets its own subdomain. The phone sitting in a drawer is serving real traffic on the real internet.

Does It Actually Work?

Build logs stream live. Deployments go live. GitHub OAuth works. Static sites and Node apps both deploy. The framework detector auto-detects Next.js, Vite, and plain static sites. SSL certificates are valid.

Running on a Snapdragon 660, 4 GB RAM, PixelExperience Android 13. The phone is also charging. The lo-fi playlist is still going.

Did I need to build this? No. Do I have a full deployment dashboard running on a rooted Android phone for exactly $0/month? Yes.

That's just engineering.

MiniShinobi is open source. If you have a rooted Android phone gathering dust and a questionable relationship with free time, the README has every command. I already did the part where you discover why you shouldn't do this. You get to skip straight to the part where it works.

"Throughout the filesystem and the disk, I alone am the honored one."

It started, as all terrible ideas do, with a minor inconvenience.

I ran npkill on my projects folder -- five years of side projects, abandoned tutorials, and repos I swore I'd finish. It found 50,000+ directories. Twelve seconds just to scan. Sequential size calculation. And when I hit delete on a 5GB node_modules? The UI froze while Node.js heroically attempted thousands of blocking I/O calls.

Unacceptable.

So naturally, I chose the hardest possible approach.

The Architecture Nobody Asked For

I call it hakai (破壊) -- "destruction" in Japanese -- because naming things is the second hardest problem in computer science, and for once, this one was easy.

The core insight: JavaScript is not built for high-performance filesystem work. Rust is. So the engine -- scanning, size calculation, deletion, risk analysis -- is compiled Rust. rayon gives me a work-stealing thread pool that distributes directory traversal across every CPU core. It's embarrassingly parallel and I'm not embarrassed at all.

But here's where the yak-shaving gets beautiful.

Building TUIs in Rust is... an experience. So the frontend -- keybinds, diff-based rendering, regex search, multi-select -- runs in Bun. Sub-50ms startup, 60fps rendering, and I already knew TypeScript.

The two halves talk over a newline-delimited JSON IPC protocol on stdin/stdout pipes. Rust fires scan results, sizes, and deletion progress down stdout. Bun catches it on stdin, parses each line, renders without blocking. One JSON object per line, trivially debuggable with jq.

A chaotic marriage that infuriates purists on both sides. Perfect.

The Benchmarks of Spite

Here's what happens when you massively over-engineer a file deletion tool:

When you multi-select 100 folders and hit enter, hakai fires up to 8 concurrent deletion tasks via tokio. The UI never blocks. The scan never pauses. Folders just vanish. It finishes before your hand reaches the mouse.

The Weekend That Kept Growing

Let me be transparent about the scope creep.

What started as "make npkill but faster" turned into: cross-platform path handling for Windows' 260-character MAX_PATH limit (solved with \\?\ UNC prefixes). Fixing TTY detection for Windows Git Bash, which is somehow still broken in 2026. Adding risk analysis that flags orphaned node_modules missing a package.json so you don't nuke a monorepo root. Building a headless mode with --json output for CI pipelines because scope creep doesn't stop until the PR is merged.

"It works on my machine" wasn't good enough. It had to work on everyone's machine.

Was It Worth It?

I spent a full weekend configuring Rust cross-compilation targets, debugging IPC buffer edge cases, and fighting tokio task cancellation semantics -- all to save roughly 10 seconds of my day once a month.

Let's do the math. If I use hakai twice a month and save 12 seconds each time, I'll break even on development time in approximately... 47 years.

But that benchmark table looks really good in a README.

So yes. Obviously worth it.

Grab hakai on GitHub. Your node_modules had it coming.

Windows built-in disk cleanup: freed 2MB. My hidden AppData caches: 40GB. The math here is upsetting.

My C: drive bar turned red.

You know the one. That international symbol for "everything is about to break and it is entirely your fault." Standard protocol: download a third-party cleaner. So I went looking.

Option A: "free" cleaners bundled with three toolbars that want to be my default browser and cap you at 500MB of deletion before demanding a $40 annual subscription.

Option B: Actually pay $40 a year for something the OS should natively do, wrapped in an interface that looks like a 2004 Vegas slot machine.

I looked at macOS. CleanMyMac. DaisyDisk. Beautiful, fast, honest about what they're deleting.

I looked back at my red C: drive bar.

"Fine. I'll do it myself."

The WiMo Architecture: PowerShell Does the Work, Go Makes It Look Good

Windows PowerShell is basically the native language of the Windows API. It can touch the registry, query WMI, talk to Winget, manage services. It's deeply powerful and its TUI capabilities are, charitably, equivalent to arranging rocks in mud.

Go, with the Bubble Tea and Lip Gloss frameworks, renders genuinely slick real-time terminal UIs.

So: PowerShell handles the heavy lifting. Compiled Go binaries handle the visuals. The two halves cooperate.

The command surface:

28+ cleanup targets across user caches, browser data, package managers, and dev tool leftovers.

The 4-Layer Safe Delete System

I gave this thing admin rights. That is not a decision to make lightly.

Every deletion goes through four checks before anything touches disk:

1. Protected path check — C:\Windows, C:\Program Files, and other system-critical directories are hardcoded off-limits
2. User data pattern check — Documents, Desktop, Downloads, Pictures are always preserved
3. Recycle bin fallback — files go to Recycle Bin when possible, not permanent deletion
4. Dry-run preview — wimo clean --dry-run shows exactly what would be removed before committing

You can run it with admin rights and not lose your Documents folder. That felt important to test thoroughly.

The Purge Command: Born of Pure Developer Spite

wimo purge was written specifically because I discovered my D: drive had 15GB of node_modules from projects I haven't touched since 2023. Plus Rust target directories. Plus Python __pycache__ scattered across everything.

PowerShell runspace pools run up to 16 concurrent threads for size calculation and deletion. System.IO.Directory.EnumerateFiles() replaces Get-ChildItem -Recurse for scanning that is actually fast. It finds the artifacts, calculates their sizes in parallel, and removes them concurrently.

The --paths and --depth flags let you scope it. wimo purge --paths "C:\Projects" --depth 5 stays in your lane.

The Go TUI: Because Staring at Plain Output Is Suffering

wimo analyze hands off to a compiled Go binary that renders a live-updating directory tree as it scans. Alt-screen mode. Goroutine-per-directory concurrency. The sizes appear in real time as the scan progresses.

wimo status renders a 6-card dashboard — CPU, Memory, Disk, Network, Processes, System — with a health score badge, a Catppuccin-inspired sage green palette, and 2-second auto-refresh via gopsutil. Responsive layout: stacks to a single column below 70 terminal columns.

These are optional binaries. If you haven't built them, the PowerShell wrapper tells you the build command. It doesn't just fail silently.

The Admin-Awareness Detail I'm Proud Of

WiMo badges admin-required tasks in the UI. If you're running as a standard user, it skips those tasks gracefully and tells you why. It doesn't crash, doesn't silently fail, doesn't demand elevation and then complain.

That's not a flashy feature. It's just correct behavior that most tools in this space don't bother with.

Did I Need To Build This?

Could I have right-clicked and deleted the folders manually? Yes.

Could I have bought a larger SSD for cheaper than the time this took? Probably.

But now I have a tool that doesn't try to install a search toolbar, doesn't cap deletion behind a paywall, and actually tells me what it's about to do before it does it.

I consider that a win. Check out Winmole on GitHub. Your C: drive bar doesn't have to be red.

My right hand is 4cm from the back button. I built an entire Chrome extension instead of moving it.

It started with a reasonable thought.

"I wish I could just swipe to go back."

That's it. No technical problem. No user pain. Just a fleeting preference about mouse navigation that a normal person would think once and immediately forget. I, instead, spent a weekend building a gesture recognition engine, a canvas-based trail renderer, a Manifest V3 service worker, and a full design system for a 400px popup.

The back button is still 4cm away. I've just stopped using it.

Manifest V3: Google's Gift to Extension Developers Who Thought Life Was Too Easy

You know what Manifest V3 took away? The ability to run persistent background pages. Fine, that's a service worker now. You know what else it took? Inline scripts in the popup HTML, because Content Security Policy says no.

That second one meant I needed a build step that extracts inline scripts into separate files at compile time. Not a workaround. That's just the job now. I wrote a custom extract-inline.ts script — 74 lines — that exists entirely because Chrome's CSP decided my popup was suspicious.

I'm fine. The script is fine. We're all fine.

"I'll Just Write a Quick Content Script"

Famous last words.

The content script injects into every page on the internet. It listens for right-click drag events. It detects direction. It sends a message to the background service worker. Done.

What actually ended up in the content script:

A canvas element gets injected into every page. High-DPI support, because gesture trails on a retina display need to be crisp. Quadratic curve smoothing so the trail looks fluid instead of jagged. Real-time cardinal direction labels rendered mid-gesture with arrow symbols. A gesture.ts module with direction detection via accumulated angle deltas.

For going back. And forward. And switching tabs. And scrolling to the top.

The Circle Gesture Problem

I need to talk about circle detection for a moment.

The naive approach: did the mouse path close on itself? Easy. Done. Ship it.

What I actually implemented: accumulated signed angle changes using atan2 cross-products across consecutive path points, checked whether the total exceeds 300 degrees of arc, verified path closure within 80 pixels of the starting point.

This is for refreshing the page. The keyboard shortcut is F5. It has been F5 for thirty years. My circle detection algorithm is more sophisticated than my first three jobs combined.

I have no regrets.

The Gesture Map

Seven gestures. Seven actions.

All triggered by right-click drag. No accidental fires on normal right-click. The direction detection only commits once you've moved enough to make intent clear.

The Build Pipeline That Grew a Pipeline

It's a Chrome extension. You write JS, load it unpacked, test it. Simple.

My build pipeline:

1. Astro compiles the popup
2. Bun bundles the content and background scripts
3. Custom CSP extraction script extracts inline scripts
4. Sharp generates four icon sizes from source
5. Pack script ZIPs everything for distribution

Five tools. For seven features. I wrote more build infrastructure than I wrote browser logic. That's my brand.

The Popup Design System

The popup is 400px wide. It shows a gesture reference table. It will never need server-side rendering. It has no dynamic data whatsoever.

I gave it a full design system. Custom CSS variables. A sage-green palette with named tokens like sage-300 and sage-600. Named shadow tokens. A cubic-bezier easing curve. In Astro.

--shadow-soft: 0 4px 16px rgba(46, 47, 44, 0.04);

--shadow-soft: 0 4px 16px rgba(46, 47, 44, 0.04);

For a popup.

Does It Actually Work?

Yes. Surprisingly well.

The gesture trail is smooth. The direction detection is accurate. Switching tabs with a two-direction swipe is genuinely faster than Ctrl+Tab once you've muscle-memorized it. The circle-to-refresh has completely replaced F5 in my daily workflow.

I created a problem, solved it more thoroughly than necessary, and now can't imagine browsing without it. Standard engineering outcome.

TabiNeko is open source. You can use the back button instead. Both are valid. I won't judge you. I'm too busy drawing circles on web pages to have opinions about other people's navigation choices.

Grab it on GitHub.

"It's broken." — an actual Jira ticket, assigned to you, with no further context, a screenshot of the wrong screen, and the energy of someone who has never once thought about what a developer needs to fix a bug.

Bug reporting in 2026. Still a game of telephone. Still completely broken.

We're in a timeline where AI writes production code, but the standard bug report is still a screenshot cropped to a vague red box, pasted into Slack, followed by four words and the silent prayer that you're also a psychic. By the time that reaches an AI coding agent, the context has fully decayed. The agent writes the wrong fix. You spend 20 minutes explaining what was actually broken. Classic.

AI Feedbacks exists specifically because I got tired of receiving "it doesn't work" as actionable development context.

The Problem Has a Name: Context Decay

When a bug fires on the client side, useful information exists for exactly a few seconds: the DOM state at the moment of failure, the console errors, the failed network requests, the exact UI configuration. Then the user closes the tab, writes "the button did something weird," and submits.

By the time that reaches Cursor or Windsurf, the prompt is so thin it's basically a riddle. Agents hallucinate. Developers reconstruct the crash scene manually before they can even ask the agent to start fixing it.

The technical term is "context decay." The honest term is "why does this happen every single sprint."

The Fix: Capture Everything at the Moment It Exists

The Chrome Extension runs silently in the background. When the user crops and submits a bug report, it automatically:

• Grabs the exact area of the screen they flagged
• Captures every console.error and console.warn from the session (yes, including the ones you've been ignoring)
• Packages all failed network requests (4xx/5xx) from the last 60 seconds
• Captures the DOM state at the time of failure
• Sends the whole bundle to the backend — without the user doing anything else

The developer doesn't receive a blurry screenshot. They receive a structured, agent-ready prompt.

Google Gemini Does the Heavy Lifting

The backend is built with Next.js 15 and powered by Google Gemini 3 Flash Preview for multimodal analysis. Gemini sees the screenshot, reads the error logs, cross-references the network failures, and synthesizes everything into a prompt that actually gives your coding agent something to work with on the first pass.

const result = streamText({
  model: google('gemini-3-flash-preview'),
  messages: [
    {
      role: 'user',
      content: [
        { type: 'text', text: `Analyze this bug: ${description}` },
        { type: 'image', image: screenshotBuffer },
      ],
    },
  ],
})

const result = streamText({
  model: google('gemini-3-flash-preview'),
  messages: [
    {
      role: 'user',
      content: [
        { type: 'text', text: `Analyze this bug: ${description}` },
        { type: 'image', image: screenshotBuffer },
      ],
    },
  ],
})

Feed it a screenshot and a vague description. Get back a prompt that Cursor can actually use. Wild concept.

The Dashboard: Because You'll Forget About Last Tuesday's Bug

The web dashboard has natural language semantic search because nobody remembers the exact tag they used two weeks ago.

Search for:

• "that auth error"
• "the white flash on mobile"
• "whatever was broken with the chart last week"

It just finds it. Not because you tagged correctly in a 14-step triage process. Because you described it like a human.

The UI is monochrome, high-contrast, deliberately no-frills. No decorative gradients competing for attention while you're just trying to ship a fix. The #87ae73 accent color is the most exciting thing in the design system, and that's intentional.

Who This Is For

If you use Cursor, Windsurf, GitHub Copilot, or any agentic coding tool — you already know the dirty secret: output quality is 100% constrained by prompt quality. AI Feedbacks automates the hardest part of a good bug prompt: capturing and structuring all the context at the exact moment it exists, before the user closes the tab and forgets everything.

Better context in. First-pass fixes out. Feed your agents better.

github.com/Mic-360/ai-feedbacks

Narrator: The bots were already scanning it.

Hot take: the same sqlmap script hammering Fortune 500 APIs is also currently probing your portfolio project with 50 daily active users. The bots do not care that you're "just a hobby project." They are not reading your README.

The WAF market's solution for this is extremely helpful: $200/month for Cloudflare WAF, or AWS WAF where you pay per rule, per request, and probably per time you think about security. ModSecurity is technically free if you enjoy reading 300 pages of Apache documentation at midnight.

Nobody built a WAF for the person who just wants their side project to stop getting SQL-injected.

So I did.

Introducing Mamoru-WAF

Single Go binary. Zero external dependencies. No Redis cluster. No Postgres spanning three Availability Zones just to store block logs. Just:

go build -o mamoru ./cmd/server
./mamoru --tui

go build -o mamoru ./cmd/server
./mamoru --tui

You're protected. That's the whole pitch.

The Part Where It Does Real Security

Mamoru covers the OWASP Top 10 staples that are most likely to ruin your week:

Regex pattern matching catches SQLi (union, select, drop, sleep), XSS (<script>, onerror=), and path traversal (../) before the request reaches your backend. Your backend doesn't even know it happened.

Token-bucket rate limiting runs per-IP, per-path, configurable. That /api/login endpoint you never hardened? It now has a bouncer.

Request body inspection means your contact form also can't be an attack vector anymore. Yes, POST bodies are checked too.

The rule engine uses a dead-simple Go interface: Name() and Evaluate(). Two methods. You can write a custom rule in 5 lines of Go. Try doing that in AWS WAF without a certification.

Hot Reload: Because Downtime Is For Enterprises

The AtomicEngine handles live rule reloading. Edit rules.yaml, save it, and the new rules are live in 2 seconds — no restarts, no dropped connections, no maintenance windows.

You can toggle between BLOCK mode (hard blocks) and DETECT mode (logs only, nothing blocked) with a keypress. Useful for when you want to watch what's happening before you commit to blocking it.

The TUI Nobody Asked For

I built a Catppuccin sage-green terminal dashboard because WAF logs are otherwise a wall of unreadable JSON and I couldn't live with that.

🛡 MAMORU-WAF                     Mode: BLOCK  │  Backend: ● UP
 Total: 1250    Blocked: 23    Rate: 2    Detected: 0
─────────────────────────────────────────────────────────────────
 Live Events
  12:30:01 [OK]    192.168.1.5  GET    /
  12:30:03 [BLOCK] 10.0.0.50    POST   /login  pattern_filter:pattern_match
  12:30:05 [RATE]  10.0.0.50    GET    /api    rate_limiter:rate_limit
─────────────────────────────────────────────────────────────────
 q quit  │  r reload  │  m mode  │  c clear  │  h help

🛡 MAMORU-WAF                     Mode: BLOCK  │  Backend: ● UP
 Total: 1250    Blocked: 23    Rate: 2    Detected: 0
─────────────────────────────────────────────────────────────────
 Live Events
  12:30:01 [OK]    192.168.1.5  GET    /
  12:30:03 [BLOCK] 10.0.0.50    POST   /login  pattern_filter:pattern_match
  12:30:05 [RATE]  10.0.0.50    GET    /api    rate_limiter:rate_limit
─────────────────────────────────────────────────────────────────
 q quit  │  r reload  │  m mode  │  c clear  │  h help

Built with Bubble Tea. Real-time event log. Backend health panel. Interactive hotkeys. r reloads rules live. d toggles detect mode. q when you've seen enough and need to go to bed.

Nobody asked for a WAF with a terminal dashboard this nice. I built it anyway. It slaps.

The Honest Assessment

Your side project is getting bot-scanned. "I don't have anything worth stealing" is not a threat model. Neither is "I'll add security later."

Mamoru is a 15MB Docker image, a YAML file you can read while half-asleep, and a Go binary that takes 60 seconds to get running.

go build -o mamoru ./cmd/server

go build -o mamoru ./cmd/server

That's it. Mamoru-kun is now watching your traffic so you don't have to.

GitHub — the CONTRIBUTING.md has a guide. The rule interface is two methods. There is no valid excuse.

Spotify: twenty years of existence, billions in revenue, zero A-B loop implementations. I handled it.

Let me tell you what Spotify gives you.

Play. Pause. Skip. Shuffle (broken in a new way every year). Repeat song — meaning the entire track, including the 90-second spoken intro you hate. A seek bar that is functionally useless at precise scrubbing speeds. That's it. That is the complete feature set for a company worth $50 billion.

No loop region. No segment markers. No "skip this intro automatically every single time forever" feature.

It's while (position >= end) { seek(start); }. A junior dev could ship this on a Tuesday. They haven't shipped it in twenty years.

So: Pulse Loop.

What It Actually Does

Two modes. Online and offline.

Online mode connects to your Spotify account via OAuth 2.0. You browse your top tracks, recently played, or search. You set a millisecond-accurate start point and end point. You toggle loop on. The app monitors playback position and seeks back to start the moment it hits your end marker. Sub-120ms seek latency via spotify_sdk. The loop is seamless.

Three playback modes:

• Normal — loops the full track
• Loop — repeats your selected start-to-end segment continuously
• Skip — skips your selected segment and keeps playing the rest

That last one is the feature I didn't know I needed. Set it on every song with a terrible bridge. Gone forever.

Offline mode doesn't need Spotify at all. Upload local audio files — MP3, WAV, M4A, OGG, FLAC, AAC — and get the same loop controls powered by just_audio. Files persist to app cache on Android and IndexedDB on web, so they survive restarts. Automatic metadata extraction from Artist - Title filename format. Full offline, full loop, no account required.

The Tech, Because It Matters

Flutter + Riverpod with code generation. Riverpod's @riverpod annotations generate the boilerplate you'd otherwise write by hand. It's the state management solution that actually scales beyond three providers without turning into a BuildContext archaeology dig.

spotify_sdk for Spotify playback control and flutter_web_auth_2 for the OAuth 2.0 flow. The auth flow is the part that will make you briefly consider quitting software development. Then it works and you forget.

just_audio for offline playback. Rock solid, cross-platform, handles every audio format I threw at it. The seek precision on local files is significantly better than Spotify's remote playback latency, which is either satisfying or depressing depending on how you look at it.

Material 3 Expressive theming with dynamic colors. The UI pulls palette colors from album art. Your loop controller matches your album. It's completely unnecessary and I spent more time on it than I should have.

The Part Where I Justify This Whole Thing

I play guitar. Learning from recordings means looping the same passage repeatedly. Standard workflow: play the section, miss the end, seek back manually, miss the start, give up, play the whole song again.

With Pulse Loop: set start marker, set end marker, play. The 8-bar passage repeats until your fingers get it right. No seeking. No distraction. The loop is just there, waiting, patient, accurate to the millisecond.

This is the entire reason the project exists. Everything else — the Skip mode, the offline support, the dynamic theming — is scope creep that turned out to be genuinely useful.

Is This Worth It Over Just Scrubbing Manually?

The seek bar on a phone screen, at the precision needed for a 4-second riff inside a 4-minute track, is basically a game of chance. You will miss. Repeatedly.

Pulse Loop sets the markers once. They stay. Every time that track plays, the loop is already there.

Spotify won't build this. They've had twenty years and chose not to. That feature gap is the entire reason this exists, and honestly, I'm fine with that.

Open source. Free. Works right now.

• Source on GitHub
• Try it live

Go loop the good part. The 8 bars that actually hit. Because Spotify certainly isn't going to help you find them.

"If your app doesn't morph, bounce, or use 15 different shades of mauve, are you even designing in 2026?"

Let's be honest: most Flutter apps look exactly like someone ran flutter create, added a few Center widgets, picked a primary color, and shipped it. Standard pill buttons. Standard app bar. Standard "I copied this directly from a 2021 tutorial and never looked back" energy.

It's everywhere. Your users notice. They just haven't uninstalled you yet.

Google's answer arrived in May 2025: Material 3 Expressive (M3E). The most research-backed update to Material Design ever shipped. Specifically engineered for the crime of playing it safe. If your buttons don't have spring physics and your containers are still hardcoded to BorderRadius.circular(8), M3E is here to make that feel embarrassing.

The "I'm Not Reading 80 Pages of Design Spec" Summary

M3E — announced May 2025, still dodging mainstream adoption in 2026 because change is hard and CircularProgressIndicator technically works — is not a theme change. It's a fundamental shift in how interfaces feel. Four-point cheat sheet:

1. Color with purpose: Not "make the button blue." Using bold container colors to actively guide the user's eye instead of hoping they find the CTA themselves.
2. Shape flexibility: Buttons that morph. Containers that aren't just rectangles. Expressive active indicators. BorderRadius.circular(8) is retired. Let it go.
3. Springy physics: Spatial Springs for movement, Effects Springs for color transitions. Real objects bounce when you tap them. Linear easeInOut curves make your UI feel like a PowerPoint. Choose accordingly.
4. New components: Button groups, split buttons, wavy loading indicators. Yes, the wavy loader. It makes waiting for a network response feel almost deliberate.

My Buttons, Before and After

Before M3E: ElevatedButton with default styling. Technically a button. Communicates nothing about the emotional investment required to tap it.

After M3E: The same action, but the button has a physical presence. It responds. It has opinions about being pressed. Users notice this without being able to articulate why.

The research backs this up — M3E components tested higher for perceived quality, trustworthiness, and "this app was made by someone who cared." You can argue about whether spring physics are necessary. You cannot argue with conversion metrics.

The Components You're Still Not Using

The Wavy Loader (Upgrade From the Circle of Shame)

The standard CircularProgressIndicator says: "something is happening, probably, we'll see."

M3E's wavy loader says: "we are actively working on this and the app has not frozen."

These are meaningfully different messages. The wavy one looks alive. Ship the wavy one.

Button Groups and Split Buttons

Finally, grouped actions that don't look like you threw four individual buttons into a Row and called it done. Split buttons give you a primary action with an overflow option that stays in visual context. No more "wait, where's the secondary action" UX archaeology.

Spatial Springs and Effects Springs

Curves.easeInOut is retired. We are doing physics now.

Spatial Springs handle movement — the kind of bounce when an element enters or responds to a tap that makes the interaction feel physical rather than programmatic. Effects Springs handle color transitions — fades that feel organic rather than linear.

The math is non-trivial. The result is that your app feels premium without anyone being able to explain why. That's the goal.

The Workflow: Skip the Spec, Use an Agent

You could spend three days in the Material spec. Or you could point the material3-expressive-flutter skill at your AI coding agent and start shipping while it handles the implementation.

I've been using this skill to bridge the gap while official Flutter SDK support finishes catching up to the spec. It gives your agent the exact context needed to implement components correctly — not hallucinated approximations, not components that look close but break on the fourth interaction.

How to Get Started (Four Real Steps)

1. Enable Material 3: useMaterial3: true in your ThemeData. Non-negotiable table stakes.
2. Use ColorScheme.fromSeed: Stop manually typing hex codes. Dynamic palettes exist. Let them work.
3. Point your agent at the skill: The material3-expressive-flutter reference files cover the components that aren't in the SDK yet. Force it to read the spec so you don't have to.
4. Embrace shape morphing: Use the shape packages. BorderRadius.circular(8) has had a good run. It's done now.

The Result

When you combine M3E principles with proper motion physics, you get an app that feels like it was made on purpose. No more "this looks like a template" feedback. No more "did you build this yourself?" in a tone that implies doubt.

Conclusion

M3E is the difference between a utility tool and an actual experience. Your users don't know what spring physics are. They just know your app feels better than the other one.

Install the skill. Let the agent handle the physics math. Stop shipping gray-on-white list views.

Or don't. It is genuinely your call. The CircularProgressIndicator will still be there.

Next Steps:

• Check out the M3E Agent Skills repo for more details.

Written while my AI agent refactored 50 buttons to use springy animations because I refused to do it manually.

Or: How I Spent a Week Learning That Python Was Already Good At Everything Except This

So there I was with a perfectly functional React + Vite dashboard. Clean TypeScript. 260 lines. Fast builds. It worked. Users were happy. Life was good.

Then I had the worst kind of idea: "Let's rewrite it in Python."

I was the one who said it. I have no one else to blame. I went in voluntarily. The retrospective was not kind.

"It'll Be Easy," The Docs Lied

"Reflex is just Python." That's what the GitHub readme said. "You won't even need to touch JavaScript," tech Twitter added, with the confidence of someone who has never actually shipped this.

Narrator: It was not just Python. The JavaScript simply hid in the shadows and waited.

What I Expected

# Beautiful, Pythonic code that definitely just works
def dashboard():
    return render_my_beautiful_ui()

# Beautiful, Pythonic code that definitely just works
def dashboard():
    return render_my_beautiful_ui()

What I Got

# This is React with extra steps, worse autocomplete, and a confused IDE
def business_row(business: dict) -> rx.Component:
    return rx.table.row(
        rx.table.cell(
            rx.hstack(
                rx.box(
                    rx.icon("building-2", size=18, style={"color": COLORS["mauve"]}),
                    style={"background": COLORS["surface0"]},
                    class_name="w-10 h-10 rounded-full flex items-center justify-center",
                ),
                # ... 50 more lines of this

# This is React with extra steps, worse autocomplete, and a confused IDE
def business_row(business: dict) -> rx.Component:
    return rx.table.row(
        rx.table.cell(
            rx.hstack(
                rx.box(
                    rx.icon("building-2", size=18, style={"color": COLORS["mauve"]}),
                    style={"background": COLORS["surface0"]},
                    class_name="w-10 h-10 rounded-full flex items-center justify-center",
                ),
                # ... 50 more lines of this

class_name. style. rx.hstack. Bro. This is JSX wearing a Python trench coat. I rewrote React. In Python. The React is still there. It's just hiding.

The "Python Experience" I Was Promised vs. What I Received

String Concatenation? That's a Legacy Feature Now.

Remember simple string concatenation? Gone.

Before (React):

<img src={`https://s3.amazonaws.com/${image}`} />

<img src={`https://s3.amazonaws.com/${image}`} />

After (Reflex):

rx.image(
    src="https://s3.amazonaws.com/" + log["personImage"].to(str),
    # Because log["personImage"] isn't a string.
    # It's a Var. A special Reflex type.
    # That you need to explicitly cast to a string.
    # In Python.
    # The language literally famous for duck typing.
    # We are doing explicit string casting in duck typing Python. Let that sink in.
)

rx.image(
    src="https://s3.amazonaws.com/" + log["personImage"].to(str),
    # Because log["personImage"] isn't a string.
    # It's a Var. A special Reflex type.
    # That you need to explicitly cast to a string.
    # In Python.
    # The language literally famous for duck typing.
    # We are doing explicit string casting in duck typing Python. Let that sink in.
)

Empty Strings: Straight to Jail.

My favorite error message of the entire ordeal:

Error: A <Select.Item /> must have a value prop that is not an empty string.

Error: A <Select.Item /> must have a value prop that is not an empty string.

The underlying React component — which I am not supposed to be thinking about because this is Python now — was offended by an empty string. So I had to create a __all__ sentinel value and convert it back to an empty string in the state handler. In Python. Where "" is a perfectly valid falsy value that the entire language ecosystem accepts without complaint.

Beautiful architecture. Truly.

Styling: Tailwind Strings in a Python File That Compiles to React

"Use Tailwind," they said. So I did.

class_name="rounded-xl border p-5 hover:border-[#45475a] transition-colors duration-200"

class_name="rounded-xl border p-5 hover:border-[#45475a] transition-colors duration-200"

This is HTML. With extra steps. I am writing Tailwind class strings in Python, which Reflex compiles to React, which renders to HTML. Three layers of indirection to write what a .tsx file would give me directly — with syntax highlighting, autocomplete, and type checking via the Tailwind VS Code extension.

Instead, my IDE thinks I'm writing a very long, very sad novel.

The Build Process Comparison Nobody Asked For

React + Vite:

• npm run dev — 200ms. I sneeze and it's running.
• Hot reload — instant.
• Build — 2 seconds.

Reflex:

• reflex run — wait for Python to initialize.
• Wait for Reflex to compile the AST.
• Wait for the frontend to build. (It spins up Node anyway. We're running Node. In the Python framework. Outstanding.)
• Wait for the backend to start.
• Changed a component's padding? Full recompile. See you in 30 seconds.
• Port 8000 in use? Cool, we'll use 8001. Now your API calls all fail silently.
• Please enjoy these Pydantic v1 deprecation warnings as a complimentary side dish.

The Definitive List of Benefits of Reflex Over React

Here it is. Complete and unabridged.

1. You write "Python" instead of JavaScript.
2. ...
3. That's it. That's the full value proposition.

Except you're not actually writing Python. You're writing React component trees using Python syntax. You still think in components. You still manage state like hooks. You still write Tailwind strings. The only real change is the language — and that language is demonstrably worse at this specific task because it wasn't designed for the DOM.

The actual differences you get:

• Worse error messages (stack traces that cross a language barrier are a special kind of chaos)
• Slower build times (you run Python AND Node)
• A massive abstraction layer you cannot debug when it breaks
• Documentation described as "rapidly evolving," which is documentation-speak for "incomplete"

The Final Tally

Before (React): 260 lines of TypeScript. Fast dev loop. Immediate feedback.

After (Reflex): 456 lines of Python. Var types pretending to be Python while outputting JS strings. Slower everything.

Both versions: Still compile to React. Still need Node. Still run JavaScript in the browser.

We added Python as a middleman to a pipeline that begins and ends with JavaScript. Python, the language, is acting as a transpiler for React. We played ourselves at championship level.

Why Does This Framework Exist?

Honest question. The pitch is "write web apps in Python." The reality is "write React in Python syntax while fighting type systems that make no sense and watching builds measured in geological time."

If you want Python: use FastAPI. Use Django. Use HTMX if you need interactivity without touching JS. These are proven tools designed for the exact tasks they perform.

If you want a modern SPA: write React. Or Svelte. Or Vue. Anything where the tooling was built for the DOM.

Don't use a framework trying to be both that ends up failing at both.

Hot Take Conclusion

Would I recommend Reflex? Only if you:

• Actively enjoy debugging type systems that shouldn't exist.
• Need a legitimate reason to get up and make coffee while your frontend "compiles."
• Believe "it's Python so it must be simpler" is a valid architectural decision and not just a coping mechanism.

For everyone else: learn React. One weekend. You'll be infinitely more productive, your tooling will work, and you won't find yourself casting duck-typed variables to strings before a string concatenation.

If you enjoy staring at code that shouldn't exist, here's the project I migrated:

Written while waiting for Reflex to recompile for the 47th time today.

"If you aren't shipping features while your friends are paying $20 for a mid drink at the club, are you even a dev?"

Nobody: Me at 2 AM in an Uber: opens Termux

Welcome to Doom Coding — doom scrolling except instead of passively destroying your attention span, you're actively destroying your work-life balance. More productive. Same outcome.

While normal people "go outside" and "exist in the physical world," we're SSH-ing into production from the back of a ride-share. Is it healthy? Incredible question, we're moving on.

After this 5-minute setup, you'll be able to code anywhere you have cell service. Even in the air. Even on a run. Even at the club. These are all real options you will have. Whether you should use them is a completely separate conversation.

Literally higher than your server's uptime. Zone 2 heart rate. Production logs open. Living the dream.

The Stack (Minimalism Is for People Who've Never Had Scope Creep)

The Holy Quadrinity of mobile dev enlightenment:

1. Termux: Your new home. A terminal emulator that turns your $1,200 TikTok consumption device into an actual power tool.
2. Node.js/Bun: Because of course we're using JavaScript environments. It's 2026.
3. Claude Code: The paid AI deity for people with budget lines.
4. OpenCode + Antigravity Auth: The "I have principles" AI deity for everyone aggressively dodging API metering.

Step 1: The Sacrifice (Termux Setup)

Download Termux. Not from the Play Store. That version is archaeological. Get it from F-Droid or GitHub like someone who reads changelogs.

Open it up and run the ritual:

pkg update && pkg upgrade

pkg update && pkg upgrade

Install Ubuntu (no, I don't care about your Alpine evangelism, I want apt-get to work):

pkg install proot-distro
proot-distro install ubuntu
proot-distro login ubuntu

pkg install proot-distro
proot-distro install ubuntu
proot-distro login ubuntu

Update your brand new chroot:

apt update && apt upgrade -y
apt install curl git nodejs npm -y

apt update && apt upgrade -y
apt install curl git nodejs npm -y

Congratulations. Your phone is now a development machine. You can tell people you "work entirely in the terminal" while waiting for your cold brew. They won't know what that means. It'll feel good anyway.

Step 2: Choose Your AI Deity

Two paths. One has a monthly billing cycle. The other has character.

Path A: The "I Have a Budget Line for This" Option (Claude Code)

If you're fine with paying Anthropic to technically do your job while you drink coffee:

curl -fsSL https://claude.ai/install.sh | bash
claude --remote

curl -fsSL https://claude.ai/install.sh | bash
claude --remote

Done. Go back to your avocado toast.

Path B: The "I Have Principles" Option (OpenCode + Antigravity Auth)

For those of us who prefer to keep money for important things — RAM, mechanical switches, that one keyboard you've been eyeing for six months.

We use OpenCode.

I found the Antigravity plugin while responsibly not doom-scrolling, and it genuinely simplified my life. No monthly AI subscription just to get an LLM to tell me why my regex is objectively wrong.

Install OpenCode:

curl -fsSL https://opencode.ai/install | bash

curl -fsSL https://opencode.ai/install | bash

Now add the Antigravity Auth plugin. This lets you tap Google's Gemini and Claude quotas via OAuth like someone who knows how OAuth works.

Edit your config at ~/.config/opencode/opencode.json (yes, with nano on your phone screen, you can do it, I believe in you):

{
  "$schema": "https://opencode.ai/config.json",
  "plugin": ["opencode-antigravity-auth@latest"],
  "provider": {
    "google": {
      "models": {
        // Paste the Antigravity auth schema here for all the free-tier models.
        // I'm not pasting all 60 lines. Figure it out.
      }
    }
  }
}

{
  "$schema": "https://opencode.ai/config.json",
  "plugin": ["opencode-antigravity-auth@latest"],
  "provider": {
    "google": {
      "models": {
        // Paste the Antigravity auth schema here for all the free-tier models.
        // I'm not pasting all 60 lines. Figure it out.
      }
    }
  }
}

Now login:

opencode auth login

opencode auth login

CRITICAL NOTE: Android Termux does not support the full OpenCode TUI natively unless you have the patience of someone who has never experienced latency. You're a terminal purist now. Use the --web flag or your screen will look like it's having a medical event.

opencode web --hostname [YOUR_TAILSCALE_IP] --port 4096

opencode web --hostname [YOUR_TAILSCALE_IP] --port 4096

Step 3: Tailscale (The Packet Wormhole)

Running opencode web means your browser needs to reach that proot-distro Ubuntu instance without Android's sandbox filing a complaint. Enter Tailscale.

1. Install the app. It's in the Play Store. This one you can get from there.
2. Login. Use the same account you use everywhere else.
3. Turn it on. You're now part of the mesh.

Find your phone's Tailscale IP — the one that looks like 100.x.y.z. That is your new identity. Use it in the opencode web command so you can hit your dev environment from Chrome, or from your laptop if you're feeling spectacularly lazy.

Step 4: Ascend to Godhood

You are now coding from something that fits in your pocket.

You can push to production at a farmers market. Fix a bug during a movie. Ship features between sets at the gym. All of these are real actions you can now take. None of them are actions you should take without thinking carefully about your life choices first.

Pro Tips for the Committed

• Document everything: Always ask your AI to update CLAUDE.md or SHIPPING.md. Your future coherent self will be grateful that your 2 AM self left notes.
• The Club Protocol: If you're coding at the club, crank the brightness to max. Everyone should know you are categorically more important than whatever the DJ is doing right now.

Me when the drop hits but the prod logs are showing 500s.

Troubleshooting (Otherwise Known As Skill Issues)

If it doesn't work:

1. Termux Sleep: Android loves murdering background processes. Enable "Keep CPU awake" in the Termux notification tray or your session dies faster than a startup with no runway.
2. Node version drama: If npm acts up, pkg reinstall nodejs-lts. Do not negotiate with it.
3. OpenCode TUI: I told you. Use --web. If you forgot: classic skill issue. Noted for the retrospective.

Happy Doom Coding. Go ship something before the concept of "healthy work-life balance" accidentally enters your mind and ruins everything.

Writing code is easy. Reviewing your own code is functionally impossible because you already convinced yourself it was fine an hour ago.

You know that moment. Cursor hovering over the commit button. The cold creep of dread. Did you leave a console.log("here") in? Did you break a type in a file you only vaguely remember touching? Did you rename that variable to something embarrassing?

You have two options:

1. Scroll through the diff, lie to yourself, and push to master.
2. Manually open Copilot Chat, paste the diff, ask it to review, wait, context-switch back, forget what you were doing.

Option 1 leads to PR comments that age poorly. Option 2 is a full flow-killing chore that requires so much ceremony you never actually do it.

What if the AI just... watched?

Making Staging Aggressively Judgemental

I built a VS Code extension that hooks into the Git API. Every time you stage a file — git add, the little + button, however you do it — Auto Copilot Review wakes up, grabs the diff of everything staged, and fires it straight into GitHub Copilot Chat with a review request.

Zero clicks. Zero context-switching. You stage a file, you glance right, and there's already a breakdown of your logic problems waiting for you like a very patient disappointed parent.

It happens entirely in the background. The extension doesn't ask. It doesn't warn you. It just starts judging.

The "God, Slow Down" Problem

My first build was too eager. Embarrassingly eager.

I stage files by rapidly clicking + on five different files in a row, which in V1 meant five simultaneous Copilot API requests firing within one second. The Chat panel had a complete breakdown — five competing reviews flashing at once, each overwriting the last. It looked like a merge conflict with extra steps.

Turns out teaching a machine to review your code also means teaching it patience.

I added a configurable debounce timer — default 5 seconds. Now you can stage as frantically as you want. Once you stop moving for 5 seconds, everything gets bundled into a single review request. One clean response. No chaos.

It's a small thing. It's the thing that made it actually usable.

The Part Where It Actually Works

Within seconds of staging: a clean breakdown of your logic flaws, typos, forgotten debug statements, and edge cases you were hoping nobody would notice.

It feels like having an extremely pedantic code reviewer permanently installed on your shoulder, waiting for exactly the moment you're about to commit something embarrassing so they can quietly intervene.

The best part is it requires genuinely nothing from you after install. No commands. No shortcuts. No workflow changes. It just exists, watching, reviewing, and silently saving you from the PR comments that would have aged very badly.

Is it humbling? Yes. Does it catch things you'd have shipped? Also yes.

If you have a Copilot subscription and a realistic assessment of your late-night coding judgment, install the extension. Your future self — the one reading PR comments — will thank you.

The fashion industry loses $400 billion a year to returns. Me: I'll fix it. With PHP. Everyone: ... Me: And a modal.

Look, I could have built a custom vision transformer. Trained it on proprietary fashion datasets. Deployed it on a GPU cluster. Applied for Series A funding and put "AI/ML Engineer" in my LinkedIn bio.

Instead I wrote a WordPress plugin.

The fitting room still works. The VC funding was unnecessary.

The Problem Is Embarrassingly Real

You can't try clothes on through a screen. So you buy three sizes, keep one, return two. The warehouse restocks it. The planet suffers. Customer service handles the complaints. Everyone loses except the shipping company.

This problem has an obvious solution that somehow costs $99/month if you want the branded SaaS version of it.

So I built the unbranded version. It's called tryon-modal. It's open source. It takes longer to read this post than to get it running.

"It's Just a WordPress Plugin" — Yes. And?

WooCommerce runs on 30% of all e-commerce sites. If you're targeting fashion stores, you're targeting WordPress. That's not a compromise — that's a distribution strategy.

Also, PHP 8 has named arguments, enums, fibers, union types, and a JIT compiler. If you're still dunking on PHP in 2025, that tweet isn't landing the way you think it is.

The AI Part (Which Is Embarrassingly Simple)

Everyone imagines "AI virtual try-on" means a six-month research sprint and a team of computer vision PhDs.

What it actually means in 2025: Google Gemini's multimodal API already understands images, garments, and human figures. So instead of training anything, you send it three things:

1. The user's photo
2. The garment image
3. A prompt that is genuinely just English sentences

And it gives you back a try-on composite. The "AI research" was writing a good prompt and a clean PHP API handler.

// This is the entire AI integration. Don't overthink it.
$response = $this->gemini->generateContent([
  'parts' => [
    ['text' => $this->buildTryOnPrompt($garmentCategory)],
    ['inline_data' => ['mime_type' => 'image/jpeg', 'data' => $userPhotoBase64]],
    ['inline_data' => ['mime_type' => 'image/jpeg', 'data' => $garmentImageBase64]],
  ]
]);

That's it. That's the model call. The rest is plumbing.

The Garment Mapper: My Favorite Feature Nobody Will Tweet About

Here's the thing about Gemini: the prompt needs context. "Is this a top or a dress?" changes the output quality significantly. Wildly, visibly significantly.

So I built a Garment Mapper — an admin UI where store owners bulk-tag their product images as Tops, Bottoms, Dresses, Outerwear, etc. The tagging feeds into buildTryOnPrompt(). The prompt changes. The results get noticeably better.

It's the most impactful feature in the plugin and the least glamorous one to explain. That is the software development experience in a single sentence.

Security: The Part Nobody Claps For

A plugin that accepts user-uploaded photos and routes them to an external API has real attack surfaces. So we do the boring-but-correct stuff:

• Nonces on every AJAX action (CSRF protection, WordPress-style)
• esc_html() and sanitize_* everywhere user data touches the DOM
• $wpdb->prepare() on every database query — no raw SQL, ever
• MIME type validation on uploaded photos before they go anywhere near Gemini
• HTTPS enforcement on all API calls

Nobody writes blog posts about not having CVEs. The alternative is worse.

The Modal: Invisible Until Needed

The worst thing a plugin can do is slow down a product page. So the modal loads nothing — zero CSS, zero JS overhead — until the user clicks Virtual Try-On. Then it bootstraps the whole UI on demand.

Once open, it supports:

• Drag-and-drop photo upload with live preview
• A results pane that fades in when Gemini responds
• A download button for the try-on image
• An Add to Cart button inside the modal — no page navigation required

The whole thing is namespaced under nano-tryon-* CSS classes so theme overrides work without touching plugin files. Because !important-ing your plugin styles into the host theme is a war crime.

Session History: Two SQL Queries, Actually Useful

Try-on sessions get stored in wp_tryon_sessions — image paths, garment used, timestamp, user ID. Users can revisit what looked good before buying.

Could I have skipped it? Yes. Did I? No. Users who come back and check what they tried on last week convert better than users who don't. It cost two SQL queries and a loop. The ROI math is straightforward.

Does It Work?

Yes. Upload a photo, pick a product, wait a few seconds, see yourself wearing it — without leaving the product page, without an account on a third-party app, without a $99/month subscription.

A WooCommerce store. A Gemini API key. A five-minute install.

Sometimes the unsexy tool for the unsexy platform solves the real problem better than the venture-backed alternative. Sometimes the fitting room is a PHP modal.

The code is open source on GitHub. Your Gemini API key is free up to a quota that will absolutely cover your first thousand try-ons.