标签：#Web

We moved a server-side SEO engine into a Chrome extension. Measuring the page was the easy half. Saying what we could not measure was the hard half. We had been running an on-page analysis engine on our own servers for years. You give it a URL, it fetches the page, it reports. Ordinary. Then we moved that engine into the browser, because a server cannot reach localhost , a staging box, an intranet, or anything behind a login. The browser can. Porting the analysis was mechanical work. What took the real time was a category of problem that barely exists on the server: in a live tab, half the things you want to measure are sometimes unavailable, and the honest answer is not a number. This post is about the decisions that came out of that, with the code that implements them. The One Rule: Null Is Not Zero Every derivation in the engine returns number | null , and the two mean different things. 0 means we measured it and it is zero. A page with no layout shift really does score zero. null means we could not measure it. No interaction happened yet, the browser does not support that entry type, or the document came from another origin and the size fields were zeroed out. A zero printed where a null belongs is a made-up number. It is worse than an empty cell, because the reader has no way to tell it apart from a real measurement. So the two never collapse: the derivation keeps them separate and the UI renders them differently. That sounds obvious written down. It is surprisingly easy to violate, and the next section is the most common way. PerformanceObserver Fails Silently, So Ask It First Here is the trap. Calling observe() with an entry type the browser does not support does not throw . It does not warn. It quietly does nothing, and your handler is simply never called. Which means an unsupported metric produces exactly the same result as a measured zero. The one thing the rule above forbids. The fix is to ask before you observe, and to record the refusal: js const SUPPOR

An object observed by the James Webb Space Telescope lends credence to a strange explanation for the mysterious red spots in the early universe.

This is a submission for Weekend Challenge: Dog Days Edition What I Built A game where...

In mid-July, my Google clicks in my home market (Israel) dropped by almost half. Buyer-intent queries that used to bring steady leads just evaporated from Search Console. While I was staring at GSC dashboards trying to figure out what broke, I finally did the thing I should have done months earlier: I stopped looking at dashboards and started reading raw server logs. What I found there was a parallel universe. Google Search was sending me less than ever — but AI systems were reading my site constantly . Not "someday this will matter" constantly. Right-now constantly: an AI assistant was fetching a page of mine roughly every 26 minutes, around the clock, because a real human had just asked it a question. So I built a small log analyzer and let it run. Here's what 34 days of complete Caddy logs from a small business site (about 70 real human visitors a day) actually look like. The numbers All counts are HTTP 200 responses only (more on why below), over 34 days: Bot Requests Per day What it is bingbot 5,444 158.2 Bing's index — which feeds ChatGPT ChatGPT-User 1,388 40.3 Live fetch while a human asks ChatGPT Googlebot 1,233 35.8 Classic Google crawl GPTBot 547 15.9 OpenAI training crawler Claude-User 519 15.1 Live fetch while a human asks Claude OAI-SearchBot 281 8.2 ChatGPT search indexing Applebot 268 7.8 Apple (Siri / Apple Intelligence) ClaudeBot 214 6.2 Anthropic training crawler Amazonbot 136 4.0 Amazon (Alexa & co.) PerplexityBot 103 3.0 Perplexity indexing Three things in that table genuinely surprised me. ChatGPT-User outreads Googlebot. 40.3 fetches a day versus 35.8. This isn't a crawler building an index for later — ChatGPT-User is the user-agent OpenAI sends when a human is mid-conversation and ChatGPT decides to pull a live page to answer them. On my site, that now happens more often than Googlebot visits. For a tiny business site in a niche market, I did not expect that. Bing crawls 4.4x harder than Google. 158 requests a day versus 36. Nobody optimizes

I'm building a programming language. Written like that, it sounds as if I had always dreamed about compilers, read the Dragon Book cover to cover, and spent years waiting for the day I could finally design my own language. Not even close. I was just writing ordinary web applications and constantly thinking things like: "Why do I have to write it this way here?" or: "Wouldn't this feel better if I could write it a little more directly?" I kept digging into those small annoyances instead of ignoring them, one by one, and somehow they turned into a programming language. It's called Seseragi . Seseragi (せせらぎ) is a Japanese word for the gentle sound or flow of a small stream. I wanted my programming language to have a Japanese name. https://github.com/KentaroMorishita/seseragi https://seseragi.vercel.app/ https://seseragi.vercel.app/tour/ It's still experimental and pre-release, but a Rust compiler, CLI, LSP, formatter, WASM Playground, Signal, and Web UI are already working to a surprising degree. Even I sometimes look at it and think, "How far is this thing going?" It started with being tired of if In 2024, I wrote this article on Qiita. https://qiita.com/KentaroMorishita/items/6329d20fbc6f98f72864 The title alone probably tells you I was already heading somewhere weird. I don't think I hated if itself. What bothered me was the feeling of tracing conditional branches as statements . That was also why I liked ternary expressions. Not just because they were short. They were expressions, so I could take the result directly as a value. const label = isLoading ? " Loading... " : hasError ? " Error " : " Ready " Of course, once these grow, they become painful too. So I started building my own match and when abstractions on top of TypeScript. Looking back, I was trying pretty hard to fight the language. But the underlying desire was already clear: I'd rather construct values than chase control flow. When I look at Seseragi now, the symptoms had started long before the languag

I spent a while building browser-based hardware diagnostics and came away with a much clearer sense of where the web platform is genuinely capable and where it quietly lies to you. Notes below, with live demos for each API so you can poke at them yourself. Refresh rate: requestAnimationFrame is the only signal you get There's no screen.refreshRate . The only approach is timing requestAnimationFrame callbacks and inferring the rate from the median frame delta: const deltas = []; let last = performance . now (); function tick ( now ) { deltas . push ( now - last ); last = now ; if ( deltas . length < 180 ) requestAnimationFrame ( tick ); else { const sorted = deltas . slice (). sort (( a , b ) => a - b ); console . log ( Math . round ( 1000 / sorted [ sorted . length >> 1 ])); } } requestAnimationFrame ( tick ); Two gotchas that cost me time. Use the median , not the mean — a single dropped frame wrecks an average. And browsers throttle rAF in background tabs, so the measurement is meaningless unless the tab is visible; gate it on document.visibilityState . ( live version ) Screen dimensions: four different answers, all "correct" screen.width , window.innerWidth , window.devicePixelRatio and screen.availWidth measure genuinely different things, and the one people usually want — actual native panel resolution — is screen.width * devicePixelRatio . Except that's still CSS-pixel derived, so on a scaled display it can disagree with what the panel physically is. The browser simply does not expose true hardware resolution. ( demo ) Keyboard: event.code vs event.key , and the keys you never receive event.key is layout-dependent, event.code is physical position — for a hardware tester you want code . The real limitation is that some keys never reach JS at all: PrintScreen often doesn't fire keydown , Meta combinations get swallowed by the OS, and Fn isn't a browser-visible key on most laptops. N-key rollover testing works surprisingly well though, since you just track the siz

Are you looking for a clean, efficient, and modern way to manage IT support requests? Stop dealing with messy manual reports via chat and start using a professional ticketing system! In this video, I’m showcasing "HelpdeskKu"—a powerful, custom-built IT ticketing system designed for efficiency and ease of use. It’s built using pure PHP Native (making it fast and easy to customize) and styled with a sleek Dark Obsidian theme using Tailwind CSS. This app features three user roles (Admin, IT Support, and User) with an automated workflow, real-time analytics, and secure session management.

This is a submission for Frontend Challenge - Comfort Food Edition, Perfect Landing What...

I audit catalog migrations for a living. Every disaster I've seen was preventable — not by hiring better, but by agreeing in writing what "done" means before work starts. Copy this list. Send it to whoever is doing your migration. Ask them to commit to each line — and note the italics: every promise comes with a way you can check it yourself in about two minutes, no tools, no trust required. Every product made it across — none lost, none duplicated. Compare row counts in both files. Every variant made it across. Pick any product, count its rows in both files. No handle silently renamed ( -1 , -2 suffixes). Search the new file for -1 , -2 . SKUs unchanged and unique. Pick 5 SKUs from your export, find them in the new file. Prices and compare-at prices identical. Pick any product, compare both price fields. Inventory identical. Same spot-check. No missing titles, vendors, types, or prices. Sort each column, look for blanks at the top. Images attached to the right variant , not dumped at product level. Open a product with colors; each color shows its own image. Every image link loads. Click any 5 image URLs. Collections intact. Pick a collection, compare its product count. Custom fields (metafields) survived. Open a product that had them. Every old URL redirects. Try 5 URLs from your old sitemap. No garbled characters. Search the file for †. No description empty or cut short. Read 5 descriptions in both files. Description formatting survived (bullets, tables). Same 5 products. Option names still meaningful ("Size", not "Option1"). Open any product with options. Option values mean what they meant. Compare the value lists. Two more things worth writing down: What happens if a check fails — fix at no charge? partial refund? Agree now, not later. Anything already broken in your source data — list it upfront so nobody argues about whose fault it was. If your provider hesitates to commit to a list like this, that hesitation is information. (I keep a pre-filled version of t

Every Flutter developer has run into the Sticky State Dilemma . You build a login screen. When authentication fails, your state container emits an error. You catch it in your UI and show a SnackBar . Everything works—until the user rotates their phone, pulls down the notification shade, or types on the virtual keyboard. Suddenly, the widget tree rebuilds. The state container is still holding AuthErrorState("Invalid password") . The UI listener fires again. And a duplicate snackbar appears out of nowhere. In this article, we’ll explore why domain state machines struggle with transient UI events, how the classic BLoC community worked around this with package:bloc_presentation , and how BlocSignal lets you handle one-shot side effects cleanly with zero additional package dependencies . 1. The Root Problem: Persistent State vs. Ephemeral Actions State management in Flutter is designed to model persistent truth over time: Is the user logged in? AuthState.authenticated(user) Is data loading? TodoState.loading What is the cart total? $49.99 Persistent state answers: "What is the system's current condition?" In contrast, UI presentation actions are ephemeral pulses : Show a brief SnackBar toast. Pop up an alert confirmation dialog. Push a new route on the Navigator stack. Vibrate the haptic motor. These actions answer: "What just happened that requires a one-time reaction?" ┌────────────────────────────────────────────────────────┐ │ State vs. Effects │ ├────────────────────────────┬───────────────────────────┤ │ Persistent State │ Ephemeral Side-Effect │ ├────────────────────────────┼───────────────────────────┤ │ • Survived by UI rebuilds │ • Consumed once & gone │ │ • Represented in signals │ • Triggered by an event │ │ • Backed by equality diffs │ • Zero domain state footprint │ └────────────────────────────┴───────────────────────────┘ 2. The Legacy Workarounds (And Their Hidden Costs) Historically in package:bloc and package:flutter_bloc , developers used one of three

Start from the mismatch, because every bug in this integration comes out of it. Email hands you a MIME tree, an SMTP envelope, and a Message-ID chain that defines the conversation. Slack hands you a channel, a message of at most 50 blocks, and a ts that defines the conversation. The whole job is mapping one onto the other without dropping information — the reply chain, the authentication verdicts, the attachments — on the floor. Here's the whole inbound half, as a Cloudflare Worker. It runs as pasted with one KV namespace bound as SEEN and one dependency ( npm install mailkite ): // worker.js — inbound email → Slack. wrangler secret put SLACK_BOT_TOKEN / MAILKITE_WEBHOOK_SECRET import { MailKite } from " mailkite " ; const clamp = ( s , n ) => ( s . length > n ? s . slice ( 0 , n - 1 ) + " … " : s ); function blocksFor ( email ) { const subject = email . subject || " (no subject) " ; const trusted = email . auth . dmarc === " pass " ; const sender = trusted && email . from . name ? ` ${ email . from . name } < ${ email . from . address } >` : email . from . address ; return [ { type : " header " , text : { type : " plain_text " , text : clamp ( `📧 ${ subject } ` , 150 ) } }, { type : " section " , fields : [ { type : " mrkdwn " , text : `*From:*\n ${ clamp ( sender , 2000 )}${ trusted ? "" : " ⚠️ " } ` }, { type : " mrkdwn " , text : `*To:*\n ${ email . to [ 0 ]. address } ` }, ] }, { type : " section " , text : { type : " mrkdwn " , text : clamp ( email . text || " _no text part_ " , 3000 ) } }, { type : " context " , elements : [ { type : " mrkdwn " , text : `spf \` ${ email . auth . spf ?? " unknown " } \` · dkim \` ${ email . auth . dkim ?? " unknown " } \` · dmarc \` ${ email . auth . dmarc ?? " unknown " } \` ` }, ] }, ]; } export default { async fetch ( req , env ) { const raw = await req . text (); const sig = req . headers . get ( " x-mailkite-signature " ); // HMAC recompute, constant-time compare, ±5-minute replay window: one call if ( ! MailKite . verify

I build a web service that preserves evidence of harassment on social platforms. The core feature is a single thing: automatically capture a real screenshot of the offending post. There was no substitute for it. I built an alternative that pulled the text through an API and rendered a tidy "evidence card" image, and threw it away. An image you can author freely afterwards proves nothing. Here's the conclusion first. Third-party wrappers eventually die, and when they do, the failure comes back as a plausible-looking image rather than an error. The first approach was refused by the other side I started with Cloudflare Browser Rendering. The wiring worked. The capture didn't. X blocks headless browsers. The request times out YouTube refuses script injection under a Trusted Types CSP. There's no way to make it render the comment Neither is a bug in my implementation — that is how they are built. So I declared Cloudflare alone impossible for this and moved to a service with a real browser and bot avoidance behind it. Both captures started working. For X, open the post page and clip the tweet element. For YouTube, open the URL with &lc= and screenshot just that comment element. Element screenshots have one trap worth knowing: selector_algorithm=clip returns a blank image when the element sits below the fold. The selector matches, the capture "succeeds," and the file is empty. That took a while to see. ytd-comment-thread-renderer :has ( a [ href *= "lc=ID" ]) A parameter that had worked started returning 400 I wanted timestamps rendered in Japan time, so I passed time_zone: Asia/Tokyo . One day every request started coming back 400. Every capture failed. The provider had narrowed which timezones they accept. Nothing changed on my side. I could diagnose it immediately only because I was storing the raw error body in the database. The response went into rawPayload.screenshotError , so opening one row told me why. Without that, this starts as "captures stopped working, no ide

This is a submission for Frontend Challenge - Comfort Food Edition, Perfect Landing What I Built For the Perfect Landing prompt, I built Masala Dosa House , a warm and modern landing page inspired by one of my favorite comfort foods — South Indian Masala Dosa . 🇮🇳 The idea was to create a fictional restaurant website that feels like stepping into a familiar neighborhood dosa spot. The landing page focuses on: 🍽️ Hero section featuring Masala Dosa 🥞 Signature dishes 🥥 Chutneys and sambar 🌿 Traditional South Indian food experience ❤️ A warm, welcoming visual design 📱 Responsive layout for desktop and mobile ✨ Smooth interactions and animations 🎨 Food-inspired colors, typography, and visual elements 📍 Restaurant-style call-to-action sections Rather than creating a generic restaurant landing page, I wanted the entire experience to communicate the feeling behind comfort food — warmth, familiarity, and home . Demo 🍽️ Live Project: Masala Dosa House — A Taste of Home View the Masala Dosa House project on CodePen Journey I started by thinking about what makes a food website feel different from a regular landing page. For me, comfort food isn't only about the food itself. It's about the experience around it — the aroma, the warmth, the familiar presentation, and the feeling of sitting down for a meal that you already know you'll enjoy. That became the design direction for Masala Dosa House . I used a warm visual palette inspired by dosa, banana leaves, spices, chutneys, and traditional South Indian dining. The layout was designed to keep the food as the main focus while making the page easy to navigate. Building the experience I structured the landing page around a simple restaurant journey: Discover → Explore → Choose → Visit The hero section introduces the restaurant and immediately establishes the comfort-food theme. The menu section highlights signature dishes, while supporting sections provide more context about the restaurant and its food. I also focused on making the

This is a submission for Frontend Challenge - Comfort Food Edition, Perfect Landing What I Built Karachi Ki Raatein ("Karachi's Nights") — a single-page love letter to the street food that keeps my city awake after dark. Instead of a restaurant or a recipe box, I built it around a real pattern from home: Karachi basically runs on an unofficial food schedule. Maghrib means chai and something fried. Bun kabab happens standing up, mid-errand. Nihari is what you sit down for after Isha. Seekh kabab shows up wherever there's smoke. And halwa puri at 3am is for the people who never went to sleep in the first place. The whole page is built around that rhythm instead of a menu. A few things I'm happy with on the frontend side: A signboard hero with a flickering neon-style headline and hand-drawn CSS/SVG steam rising from a cup — no stock photography anywhere on the page, everything is drawn. A canvas-based particle steam system that replaces the static SVG once JS is available — real particles with drift, turbulence and upward acceleration, and they physically scatter when you move your cursor through them, like waving your hand through actual steam. A live "Night Clock" that reads your real local time ( Date , your timezone, nothing hardcoded) and marks whichever stall is "in season" right now with a pulsing "you are here" badge — so the page behaves differently depending on when you actually open it. A theme built for the medium : dark ink background, ember/turmeric accent colors, a hand-lettered chalk font for the "voice" of the thela-wala mixed with a bold display face for the signage, instead of the usual cream-and-terracotta food-site look. Respects prefers-reduced-motion everywhere (falls back to a static SVG steam loop and skips the canvas sim), keyboard-focusable throughout, fully responsive. Demo Journey I wanted to avoid the obvious comfort-food landing page — cream background, terracotta accents, a hero photo of a steaming bowl. It's a solid look but I see it ev

If you've only ever shipped linear-gradient(to right, blue, red) , you're using about one-third of what CSS gradients can do. There are only three functions, and the mental model for each is small. Here's the whole thing in one read. The one fact that makes everything click A gradient is not an image file. Per MDN , a <gradient> is a special kind of <image> that the browser generates at render time . So it: scales to any size without blurring (it's drawn, not sampled) weighs zero bytes (no file, no HTTP request) edits with one hex value instead of a re-export That's why gradients exist. Everything below is just how to steer them. Three functions, three shapes Function Shape Reach for it when linear-gradient() straight line along an axis backgrounds, buttons, overlays radial-gradient() outward from a center point spotlights, glows, vignettes conic-gradient() rotational sweep around a center pie charts, color wheels, spinners Linear - the workhorse background : linear-gradient ( to right , #ff7e5f , #feb47b ); /* orange→peach */ background : linear-gradient ( 135 deg , #6366 f1 0 %, #ec4899 100 %); /* indigo→pink */ Direction is an angle ( 45deg ) or a keyword ( to right , to top right ). Stops are a color plus an optional position. Radial - when the fade should read as light background : radial-gradient ( circle , #fff , #000 ); Shape ( circle vs ellipse ), center position, and sizing keywords ( closest-side , farthest-corner ) do the work. Because the fade tracks distance from a point, radial reads as depth - perfect for glows, vignettes, and spotlight effects. Conic - the one most people skip background : conic-gradient ( #f00 0 25 %, #0 f0 25 % 50 %, #00 f 50 % 75 %, #ff0 75 %); Conic sweeps by angle , not distance. That single difference makes it the right tool for pie charts and color wheels - effects that were hacky before conic-gradient() shipped. The rule that surprises everyone Two color stops at the same position don't fade - they make a hard edge: backgrou

Introduction For the past 10 days, I took part in the 10 Days of AI Voice Agents — #VoiceForBharat Edition challenge. During this challenge, I built an AI voice agent named Sadie. My goal was not just to make an AI that could talk. I wanted to build a voice agent that could understand users, remember conversations, use tools, make phone calls, connect users to humans, and hand conversations to specialist agents. This journey helped me understand that building a voice agent is much more than connecting an LLM with a text-to-speech API. The Problem Many people find it easier to speak than type. This can be especially useful for people who want to: Ask questions using their voice Learn through conversation Get quick information Speak in Hindi or English Use Hindi and English together Get help without using complicated interfaces I wanted to build a voice assistant that could make learning and getting information feel more natural. Instead of typing a question, users can simply speak to Sadie. What I Built Sadie is an AI voice agent that can: Have real-time voice conversations Understand Hindi-English code-mixed conversations Follow personality and safety rules Remember information with user permission Use external tools Make outbound phone calls Escalate conversations to humans Track call information Hand conversations to specialist agents The specialist agents I built are: Grammar Specialist Maths Specialist Full Stack Development Specialist How the System Works The basic architecture of my project is: User | | Voice ↓ LiveKit | ↓ Deepgram STT | ↓ Google Gemini / | \ / | \ Memory Tools Specialists \ | / \ | / ↓ Murf Falcon | ↓ User Voice Main Components Deepgram handles Speech-to-Text. Google Gemini acts as the brain of the agent and understands the user's request. Murf Falcon converts the AI's response into natural speech. LiveKit handles real-time audio communication. I also added memory, external tools, telephony, human escalation, analytics, and specialist agents

🌀 MOKSHA Devlog — August 15, 2026 Overview Today's session focused on implementing and refining the Shareera Gatee (body-motion) mechanic as a companion to Samaya Gatee (time-flow). Major work included UI/UX polish, physics integration, and karmic carry-over mechanics for praarabdha (accumulated karma from past lives). Commits & Changes 1. UI: Added HUD Element for Shareera Gati Commit: 8874bcc | 06:33 UTC Scope: HTML/JS refactoring of HUD elements Changes: Added new shareera-gatee HUD indicator (cyan, #67e8f9 ) Renamed ui-gatee → samaya-gatee for clarity Updated engine state tracking: _oldStats and _uiScales now include both samayaGatee and shareeraGatee _uiGlows state expanded for dual-gatee animations Files Modified: index.html — HUD markup src/engine.js — State initialization src/main.js — UI element references src/state.js — Animation loop updates Status: ✅ Foundational UI structure ready 2. UI:UX: Implemented Shareera Gatee Commit: 387e488 | 09:30 UTC Scope: Physics integration + dynamic speed modulation Changes: Karma-speed coupling: Punya/Paapa/Praarabdha now reduce player movement speed Base speed modifier: _sMod = 0.7^ashuvhaKarma × 0.8^shuvhaKarma × 0.7^praarabdha Body-motion indicators: 🐌 = slowed (< 100%) 🚶 = normal (100%) 🏃 = accelerated (> 100%) Samaya Gatee now represents relative time flow: Inverted modifier: karmaSpeedMul = (1/0.7)^ashuvhaKarma × (1/0.8)^shuvhaKarma Time accelerates under karma-debt, slows under merit Dynamic emojis: 🧊 (slow) / ⌛ (normal) / ⚡ (fast) Praarabdha snapshot on death: Speed multiplier carries forward to next rebirth Stored in _praarabdhaSpeedMul for persistent karma-weight Game Feel: Karma now directly affects both movement speed and time progression , creating dual gameplay feedback Files Modified: src/engine.js — Physics + HUD animation src/karma.js ��� Rebirth speed carry-over index.html — Icon symbols Status: ✅ Core mechanic implemented 3. praarabdha: No Reset of Samaya Gatee on Punarjanma Commit: 4305106 | 10:25 UTC

The Agentic Coding Revolution: How I Learned to Stop Typing and Start Delegating Or: what happens when your IDE becomes less of a text editor and more of a teammate. Remember when "AI-assisted coding" meant autocomplete suggestions that guessed your variable names? Those days are gone. Somewhere along the way, the tools stopped suggesting and started doing . They read your repo, run your tests, open pull requests, and sometimes fix bugs you didn't even know existed. Welcome to the era of agentic coding — and if you haven't restructured your workflow around it yet, this post is your crash course. What Actually Changed? The shift from code assistant to coding agent comes down to one capability: autonomy . A traditional assistant waits for your keystrokes. An agent receives a goal and figures out the rest. Dimension Code Assistant Coding Agent Trigger Your keystroke A stated objective Scope Single line or block Entire task, across files Feedback loop None Reads test output, retries, iterates Tool use Suggestion only Shell, browser, git, package managers Ownership You write, it suggests It drafts, you review The mental model that helped me most: stop thinking of the agent as an autocomplete and start thinking of it as a junior developer with access to your codebase. You wouldn't hand a junior engineer an undocumented task with no acceptance criteria. So why hand it to an agent? The Prompting Gap Is the New Debugging Here's the uncomfortable truth I discovered after a few months of daily agentic workflows: agents don't fail because they're dumb. They fail because our instructions are vague. Consider these two requests: ❌ Bad: "Make the app faster" ✅ Good: "Reduce p95 latency of the /search endpoint (currently 1.2s) to under 300ms. Focus on the database query layer first. Keep existing API contracts unchanged. Add a benchmark comparing before/after." The second version has a measurable goal, a constraint boundary, a starting hypothesis, and a definition of done. Agents th

Every glassmorphism snippet I've seen is backdrop-filter: blur() plus a white overlay. That's a blurred rectangle. Real glass bends what's behind it, hardest at the edge — and that part is missing everywhere. Built it for a production Angular app, pulled it out as a Claude Code plugin: https://github.com/stormaref/LiquidGlassSkill /plugin marketplace add stormaref/LiquidGlassSkill /plugin install liquid-glass@stormaref-skills The refraction: bake a displacement map into a canvas, wire up feImage → feDisplacementMap → feGaussianBlur , point the element at it with backdrop-filter: url(#filter) . Since it's a backdrop filter, the input is the live page behind the element — so it tracks scroll, theme and content changes with nothing to invalidate. Field ported from liquid-glass-js (MIT, credited), minus its html2canvas snapshot. Why it's a skill and not a gist — four rules, each of which fails as plausible-looking output: Glass needs a backdrop. Over a flat page it reads as a gray box, which sends you reaching for more blur — the exact move that kills it. The tint is colorless. Hue in the tint fights the hue coming through; the surface goes muddy. Children of a glass panel paint no surface. An opaque fill covers the refracted backdrop, which is the whole effect. You can't feature-query it. Safari parses backdrop-filter: url(#…) and paints nothing, so @supports says yes and your panel is blank. Gate on engine. The CSS is 200 lines. Knowing that #1 is why your glass looks nths of things looking subtly wrong. MIT. Happy to talk displacement math — the 128/255 ≠ 0.5 decly long to find.

From COD fraud nightmares to automated intelligence: the story of building a business platform for Bangladesh's e-commerce market. 🎯 The Problem That Started Everything Picture this. A small shop owner is managing their online business. They've got WooCommerce for the website, Excel sheets for stock tracking, Pathao open on one phone, Steadfast on another, and Facebook Page orders coming in through DMs. They have a physical notebook for customer history, and absolutely no way to know if a new customer is a fraudster who'll refuse the delivery. Every morning starts with copy-pasting order details from three different places. Every afternoon is spent manually messaging courier agents. Every evening is reconciling which orders got delivered, which got returned, and how much money actually came in. This isn't a unique story. This is the daily reality of thousands of SME owners, retailers, and e-commerce merchants. I built Vendzoo to end this chaos. Vendzoo is an all-in-one SaaS Business OS: POS, Inventory, Courier, Fraud Detection, Customer Intelligence, Marketing, and Analytics, all in one dashboard. 🌐 vendzoo.com This is the story of how it was built, the real problems we solved, and the decisions that shaped the product. 🏗️ The System at a Glance Vendzoo is built on Laravel 13 with PHP 8.3 , backed by MySQL, with a Tailwind CSS v4 and Vite 8 frontend. Nothing exotic, just a solid, modern stack chosen for reliability and developer ergonomics. What makes it interesting isn't the stack. It's the three layers sitting on top of it. The core layer handles POS, orders, inventory, invoicing, and multi-user access with role-based permissions. The integration layer connects to everything a merchant already uses: WooCommerce, Shopify, Facebook Commerce, Pathao, Steadfast, RedX, Carrybee, Firebase, Telegram, SMS, WhatsApp, and Email. The intelligence layer is where Vendzoo earns its "Business OS" label: a fraud risk engine, customer segmentation, churn prediction, courier perfor