标签：#webdev

We have all been riding the massive vibe coding wave lately. It feels like pure magic to sit back, tell an AI assistant what to build, and watch a full application appear out of thin air. But if you have ever tried to take that exact same web workflow and deploy a smooth, native app onto an iPhone or Android, you know exactly where the frustration sets in. Are you a vibecoder who loves to build applications and you have built many websites? You have built and deployed many websites. Now you really want to make a mobile application that could disrupt the market and go really viral. Have you heard of FlutterFlow ? Have you tried using it? If the answer is no, then I will tell you about FlutterFlow and then you can decide whether you want to check it out and vibe code mobile applications. I will share the app that I created as well. What is FlutterFlow anyway? Have you ever tried building mobile applications and heard of Flutter and Dart? If you haven't, you should definitely check them out. When I was in college looking for a path to choose whether to pursue app development or web development. I explored both options. While exploring app development, I used and built applications using Flutter, an open-source framework created by Google, which uses a programming language called Dart. While Flutter itself is built by Google, FlutterFlow is an independent, visual low-code platform founded by ex-Google engineers. Today, many of us are familiar with AI vibe-coding tools like Cursor and Claude, which allow us to generate code for websites using conversational prompts. FlutterFlow, however, operates differently than vibe-coding: instead of writing code through chat prompts, it provides a visual, drag-and-drop canvas where you can build and design native mobile applications visually while it automatically generates clean Flutter code in the background. I recently had the opportunity to attend a workshop held by the FlutterFlow team and there, I was blown away by the magic of

Why Our AI Agent Still Stumbles on Full-Stack Apps We've all been there. You're riding high on the AI hype, picturing your agent effortlessly spinning up features, leaving you free for higher-level architectural decisions. You feed it a prompt like, "Build me a simple user profile page with authentication, connected to a database, using Next.js and TypeScript." You hit enter, grab a coffee, and expect magic. More often than not, what you get back is… well, it's something . It might be syntactically correct, perhaps even impressive in parts. But when you try to integrate it, to make the pieces talk to each other harmoniously, it often feels like trying to connect a square peg to a round hole. The agent struggles, and frankly, so do we trying to fix its output. The Seams, Not Just the Parts: Why Full-Stack is More Than Sum of Its Halves In my experience, AI agents, especially Large Language Models, are fantastic at generating code for isolated problems. Need a React component? A SQL query? A utility function? They'll often nail it. But a full-stack application isn't just a collection of frontend, backend, and database parts. It's the intricate, often implicit, contracts between them. Think about a modern Next.js application. It’s a beautifully complex dance: Server Components vs. Client Components: This paradigm shift fundamentally changes where state lives, where data is fetched, and how interactivity is handled. An AI might generate a useState hook inside a Server Component, completely missing the architectural intent. Data Fetching Strategies: getServerSideProps , getStaticProps , route handlers , fetch directly in Server Components – each has specific implications for caching, performance, and where your data lives at runtime. An AI might pick an inefficient or incorrect strategy based on a simplified prompt. Type Safety Across Boundaries: TypeScript is a lifesaver, but defining types that perfectly mirror your database schema, API responses, and frontend state re

Stop Treating Databases Like Dumb Storage! A Modern Approach to Data Layer Optimization Introduction In the rapidly evolving landscape of cloud-native applications, the database often remains the last bastion of outdated architectural thinking. Too many development teams, even in 2026, treat their databases as little more than dumb storage – a simple receptacle for data. This oversight invariably leads to an insidious problem: what was once perceived as a cost-saving cloud server rapidly transforms into an expensive, resource-hungry bottleneck that devours compute cycles, memory, and, most critically, developer sanity. The knee-jerk reaction to performance woes—throwing more hardware at an unoptimized SQL database or poorly designed NoSQL schema—is not scalable backend design; it's procrastination. This approach might temporarily mask symptoms, but it fundamentally ignores the root cause, leading to spiraling costs and increasing technical debt. Modern backend design demands a paradigm shift: treating your data layer as a strategic, highly optimized component rather than a generic storage utility. The path to true scalability, resilience, and cost-efficiency begins with intelligent data management from day one. Architectural Walkthrough: Embracing Smart Data Strategies Instead of "sharding your problems" through reactive, unguided horizontal scaling, embrace smart data partitioning . This isn't just about distributing data; it's about strategically organizing it to align with your application's access patterns and business domains. 1. Smart Data Partitioning & Query Patterns: Imagine an e-commerce application. Instead of sharding all orders data uniformly, consider partitioning by a natural business key, like customer_id or product_category . This ensures that common queries (e.g., "get all orders for customer X") are localized to a single partition, minimizing cross-partition operations. // Conceptual Service for Order Management class OrderService { private final

The conversation around Agentic AI often focuses on one goal: making agents more autonomous. More tools. More reasoning. More planning. More independence. It sounds like progress. But is more autonomy always the right answer? As software engineers, we rarely optimize for "more." We don't build distributed systems when a monolith is sufficient. We don't introduce microservices because they're fashionable. We choose architectures that balance capability with complexity. The same principle applies to AI agents. The question isn't "How autonomous can my agent be?" It's "How autonomous should my agent be?" Autonomy Is a Design Decision When people talk about autonomy, they often think of it as a feature that an agent either has or doesn't have. In reality, autonomy is a design decision. Every time we allow an agent to make another decision on its own, we are increasing its responsibility. That responsibility comes with benefits, but it also introduces new engineering challenges. More autonomy means the agent can adapt to situations that weren't anticipated during development. It can make progress toward a goal without being guided through every step. At the same time, it becomes harder to predict, validate, debug, and trust. Autonomy isn't free. Thinking in Terms of an Autonomy Spectrum Instead of treating autonomy as a binary concept, it helps to think of it as a spectrum. At one end are systems that simply generate responses. They have no authority to take action. As autonomy increases, agents begin suggesting actions, invoking tools, planning multiple steps, and eventually deciding how to achieve a goal with minimal human involvement. The important observation is that every step along this spectrum increases both capability and complexity. That's why the objective shouldn't be to reach the highest level. It should be to stop at the level your problem actually requires. More Autonomy Isn't Always Better Imagine building an internal HR assistant. Its primary responsibil

Every blog post needs an OG image. Without one, your links look blank on Twitter, LinkedIn, and Slack — just a plain URL that nobody clicks. Most developers solve this by spinning up a headless browser, loading an HTML template, taking a screenshot, and uploading it somewhere. It works, but now you're maintaining a Puppeteer instance, dealing with font rendering quirks, and burning server resources on something that should be simple. There's a faster approach: design your OG images as HTML templates and let a screenshot API handle the rendering. The Idea: HTML Templates as OG Images Think of your OG image as a tiny webpage. You already know HTML and CSS. Build a 1200×630 template with your blog title, author name, maybe a gradient background — whatever fits your brand. Host it or pass it as raw HTML. Then call an API to screenshot it. Done. A basic template might look like this: <div style= "width:1200px;height:630px;display:flex;align-items:center; justify-content:center;background:linear-gradient(135deg,#1a1a2e,#16213e); font-family:Inter,sans-serif;padding:60px" > <div style= "color:#fff;text-align:center" > <h1 style= "font-size:48px;margin:0" > {{title}} </h1> <p style= "font-size:24px;color:#8892b0;margin-top:20px" > {{author}} · {{date}} </p> </div> </div> Replace the placeholders on your server, then send the resulting HTML (or a URL pointing to it) to the API. Calling the API With ScreenshotRun , a single curl request captures the rendered template as a PNG: curl -X POST "https://api.screenshotrun.com/v1/screenshot" \ -H "Authorization: Bearer YOUR_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "url": "https://yourblog.com/og-template?title=My+Post+Title", "viewport_width": 1200, "viewport_height": 630, "format": "png" }' The response gives you the image file. Save it to your CDN, set the og:image meta tag, and you're done. No browser to manage, no Chrome binary eating RAM on your CI server. Wiring It Into Your Build If you publish with a static sit

Hello, I'm Maneshwar. I'm building git-lrc, a Micro AI code reviewer that runs on every commit. It is...

Originally published on wp-nota.com . You installed an SSL certificate and moved your WordPress site to HTTPS — but the browser still shows "Not Secure" in the address bar, or a padlock with a warning. This is the classic mixed content problem: your pages load over secure HTTPS, but some resources on them — images, scripts, or stylesheets — are still being requested over insecure HTTP. Browsers flag the whole page as not fully secure until every resource is served over HTTPS. Here's how to fix it for good. What "Mixed Content" Actually Means When a single page mixes secure (HTTPS) and insecure (HTTP) resources, that's mixed content. The page itself may be secure, but if it pulls in an image or script over http:// , the browser can't guarantee the whole page is safe — so it drops the padlock or shows a warning. The cause is almost always old http:// URLs still saved in your database or hardcoded in your theme. Step 1: Confirm the Certificate and Site URLs First, make sure the foundation is right. Your host must have a valid SSL certificate installed (most offer free Let's Encrypt certificates). Then, in WordPress, go to Settings → General and confirm both WordPress Address (URL) and Site Address (URL) start with https:// . If they still say http:// , update them, save, and log back in. Step 2: Find What's Loading Over HTTP To see exactly which resources are insecure, open the problem page in your browser, right-click and choose Inspect , and look at the Console tab. Mixed content warnings list each http:// resource by URL — often images in old posts, a hardcoded logo, or an asset from a plugin or theme. This tells you precisely what needs fixing. Step 3: Update Old HTTP URLs in the Database The most common fix is a database search-and-replace that swaps every http://yourdomain.com for https://yourdomain.com . Two safe ways to do it: The easy way — the free Really Simple SSL plugin detects insecure URLs and rewrites them to HTTPS automatically, which resolves most mix

If you've spent any time exploring backend engineering, distributed systems, or system design, you've almost certainly seen one book recommended more than any other: Designing Data-Intensive Applications , or DDIA for short. For years, I've heard experienced engineers describe it as the book that completely changed the way they think about software architecture. When the second edition was released with updated content covering modern distributed systems and cloud-native architectures, I decided it was finally time to see whether it deserved the hype. After reading it from beginning to end, I understand why this book has become a classic. It isn't another programming book that teaches a framework, a database, or a cloud platform. Instead, it teaches something much more valuable: how to think about building systems that continue working when data grows, traffic increases, and failures become inevitable. If you're a backend engineer—or want to become one—this is probably one of the best technical books you can read. This Isn't Really a Database Book The title can be a little misleading. Before opening DDIA, I assumed it would spend hundreds of pages comparing databases or discussing storage engines. Databases are certainly a major part of the discussion, but they're really just one piece of a much larger picture. The book is about designing systems that process enormous amounts of data while remaining reliable, scalable, and maintainable. Those systems happen to rely on databases, but they also involve replication, partitioning, distributed communication, stream processing, fault tolerance, consistency, messaging, and dozens of other architectural concepts that appear in modern software systems. By the end of the first few chapters, it becomes clear that the authors aren't trying to teach products. They're teaching engineering principles that remain useful no matter which technologies you're using. It Explains Why , Not Just How One of my favorite things about DDIA is

Most backend engineers already know how to handle HTTP errors. 400 means the request is bad. 401 means auth failed. 429 means rate limited. 500 means something broke upstream. Retry a few times, add exponential backoff, log the response body, move on. That works fine for many APIs. It works badly for LLM APIs. LLM providers may use normal HTTP status codes, but the operational meaning behind those errors is different enough that treating them like ordinary REST failures can make your app slower, more expensive, and harder to debug. The mistake I kept making Early on, I handled LLM failures the same way I handled every other external API: if ( response . status === 429 || response . status >= 500 ) { retryWithBackoff (); } Simple. Familiar. Dangerous. That logic misses the actual question your app needs to answer: What kind of LLM failure happened, and what should the product do next? Because an LLM API failure is rarely just "one HTTP request failed." It can break: a user-facing chat response a background agent run a document generation job a tool-calling workflow a batch evaluation pipeline a structured JSON generation step And each one needs different handling. Not all 429s mean the same thing For a normal API, 429 Too Many Requests usually means: Slow down and retry later. With LLM APIs, 429 can mean several different things. It might be a temporary rate limit: { "error" : { "message" : "Rate limit reached" , "type" : "rate_limit_error" } } Retrying with backoff may help here. But it might also mean quota exhaustion: { "error" : { "message" : "You exceeded your current quota" , "type" : "insufficient_quota" } } Retrying this does not help. It just adds latency, noisy logs, and a worse user experience. It could also be model-specific pressure. One model may be overloaded while another model from the same provider, or a different provider, would work fine. So your handler should distinguish between: temporary rate limit hard quota exhaustion model-level capacity is

I used to spend ten hours every week doing content research manually. Checking competitor blogs. Scanning Reddit threads. Copying and pasting search results into a spreadsheet. Trying to spot patterns in an ocean of unstructured text. It was exhausting, slow, and completely unnecessary. Once I learned to automate this with Python and a few affordable APIs, I cut that ten-hour grind down to under thirty minutes. Here is the exact system I built, what it costs, and how you can replicate it yourself. The Quick Answer To automate content research with Python, combine a search API like Serper to pull structured Google search data, BeautifulSoup or requests-html to parse page content, and an LLM API like Gemini to synthesize insights into actionable content briefs. Connect these three components in a sequential Python pipeline and you have a fully automated research agent that runs in minutes instead of hours. What I Actually Built I needed a system that could do three things automatically: First, find what real people are asking about any topic across Reddit, Quora, and Google search. Second, identify what my top competitors have written about that topic and where the gaps are. Third, summarize everything into a clean content brief I can use to write or generate an article. I built this using Python with three core components: the Serper API for search data, BeautifulSoup for page parsing, and the Google Gemini API for synthesis. Total monthly cost: about twelve dollars. I document the full working version of this system — including the Flask web interface and WordPress publishing integration — at https://zerofilterdiary.com Step-by-Step Build Guide Step 1: Install the Required Libraries pip install requests beautifulsoup4 python-dotenv google-generativeai Step 2: Set Up Your API Keys Create a .env file in your project root: SERPER_API_KEY=your_serper_key_here GEMINI_API_KEY=your_gemini_key_here Step 3: Search for Real Discussions Using Serper API import requests import

co-written with UnitBuilds, who built most of this out loud in the comments of my last piece. I...

Introducing GlintCode ✨ I've been building GlintCode , a lightweight scripting language for the browser that runs on top of JavaScript. The goal is simple: make building browser apps easier with a clean, beginner-friendly API while still using the power of JavaScript under the hood. Features 🚀 Runs directly in the browser 📝 Uses <script type="glint"> 🌐 Built-in DOM helpers 🎨 Simple UI creation functions 🔁 Built-in loop helpers 📦 Optional module system ⚡ No build tools or compilation required Hello, World <script src= "https://fast4word.github.io/glintcode/glint.js" ></script> <script type= "glint" > page ( " Hello " ) heading ( " Welcome to GlintCode " , 1 ) paragraph ( " Your first Glint app! " ) button ( " Click Me " , () => { print ( " Hello from Glint! " ) }) </script> Why GlintCode? JavaScript is incredibly powerful, but for beginners or small browser projects it can sometimes feel more verbose than necessary. GlintCode provides a set of simple, readable functions that make creating interfaces and interacting with the page easier, while still letting you use JavaScript features whenever you need them. Because GlintCode runs on top of JavaScript, you can gradually learn the underlying language without giving up access to the browser's APIs. What's next? I'm continuing to expand GlintCode with new functions, modules, examples, and documentation. Future plans include additional built-in libraries, a richer module ecosystem, and more developer tools. I'd love to hear your feedback, suggestions, or ideas for features you'd like to see! GitHub: https://github.com/Fast4word/glintcode

Stop memorizing ANSI escape sequences. I built a browser tool to generate them visually — pick colors, styles, and get the code ready to paste. Try it 🔗 ANSI Color Code Generator — DevNestio Features 3 color modes : 8-color, 256-color palette, RGB truecolor (24-bit) 8 text styles : Bold, Dim, Italic, Underline, Blink, Reverse, Hidden, Strikethrough Separate FG/BG : Set foreground and background colors independently 3 output formats : Shell ( echo -e ), Python ( print ), Raw escape sequence Live preview in a simulated terminal box How ANSI sequences work ESC [ <codes> m Multiple codes are separated by ; . Reset is ESC[0m . 8-color : codes 30-37 (FG), 40-47 (BG), 90-97 (bright FG) 256-color : ESC[38;5;<0-255>m for FG, ESC[48;5;<0-255>m for BG RGB truecolor : ESC[38;2;<R>;<G>;<B>m 256-color palette calculation function get256Color ( i ) { if ( i < 16 ) return standardColors [ i ]. hex ; if ( i < 232 ) { const n = i - 16 ; const r = Math . floor ( n / 36 ) * 51 ; // 255/5 = 51 const g = Math . floor (( n % 36 ) / 6 ) * 51 ; const b = ( n % 6 ) * 51 ; return `rgb( ${ r } , ${ g } , ${ b } )` ; } const v = ( i - 232 ) * 10 + 8 ; // 24 grayscale steps return `rgb( ${ v } , ${ v } , ${ v } )` ; } Output examples # Bold red text on black echo -e " \e [1;31mHello, Terminal! \e [0m" # RGB orange (Python) print ( " \0 33[38;2;255;128;0mOrange text \0 33[0m" ) Tested with 128 assertions covering code generation, color math, and format strings. Part of DevNestio — 115 free browser-only developer tools.

I built a browser-based bitwise calculator that performs AND, OR, XOR, NOT, NAND, NOR, XNOR, arithmetic/logical shifts, and rotate operations on 32-bit integers — with a live clickable bit grid. Try it 🔗 Bitwise Calculator — DevNestio Features 13 operations : AND, OR, XOR, NOT A/B, NAND, NOR, XNOR, SHL, SHR, SHRA, ROTL, ROTR Visual 32-bit grid : Click any bit to toggle Operand A on the fly Multi-base input : Auto-detect 0xFF , 0b1010 , 0o17 , or decimal 4 output formats : Hex, decimal, binary (grouped), octal — all with copy buttons No server, no upload — everything runs in-browser The JavaScript integer trap Bitwise ops in JS coerce values to signed 32-bit integers. To get unsigned results you need >>> 0 : case NOT_A : return ( ~ a ) >>> 0 ; // without >>> 0, ~0 shows as -1 case XNOR : return ( ~ ( a ^ b )) >>> 0 ; case ROTL : return (( a << s ) | ( a >>> ( 32 - s ))) >>> 0 ; Rotate without a dedicated instruction JavaScript has no ROL/ROR, so combine two shifts: // Rotate left by s bits (( a << s ) | ( a >>> ( 32 - s ))) >>> 0 Tested with 99 assertions All core logic — parsing, computing, edge cases like XNOR with ~0xFF = 0xFFFFFF00 — covered in a Node.js test file using assert . Part of DevNestio — a growing collection of 115 free browser-only developer tools.

Last time I wrote about using glasp, a Go-based, npm-free CLI for Google Apps Script (GAS), in GitHub Actions. Previous post: Lean, Fast, Simple — npm-free GAS Deployment on GitHub Actions with glasp This time, a quick rundown of what landed in v0.3.0 and v0.4.0 . v0.3.0: PKCE support glasp login now supports PKCE (RFC 7636) as an opt-in. glasp login --pkce # or GLASP_USE_PKCE = 1 glasp login Each login generates a code_verifier and sends an S256 code_challenge to Google. It's a defense against authorization code interception, and it coexists fine with the existing client_secret flow. It only applies to the interactive login — --auth / GLASP_AUTH for CI is untouched. Off by default. Worth turning on if you're in a stricter security environment. v0.4.0: Timeouts and retries The focus here is basically "can this run unattended in CI/CD without falling over." Timeouts Script API requests previously had no timeout — a stuck request could hang the job indefinitely. v0.4.0 adds a 180s default. glasp push --timeout 60 # set to 60s glasp push --no-timeout # disable Also configurable via GLASP_TIMEOUT / GLASP_NO_TIMEOUT env vars or timeoutSeconds in .glasp/config.json . Priority: --no-timeout > flag/env > config > default. If the config file is broken, it warns instead of silently falling back. Retries Transient failures (5xx, 429) now get retried automatically. glasp push --max-retries 5 glasp push --no-retries 3 retries by default (up to 4 attempts total) Only applies to idempotent commands: push , pull , clone , list-deployments Commands with side effects ( create-script , run-function , etc.) are never retried Exponential backoff with jitter, respecting Retry-After It's implemented as a single http.RoundTripper wrapper, so the Google SDK itself isn't touched — same pattern as the timeout implementation. retryTransport → oauth2.Transport → http.DefaultTransport Some refactoring, too Internal packages got reorganized ( #107 ), and the hand-rolled retry transport was swappe

I built GameDeck — a gaming platform where you pick a badge, type a name, and play. That's it. No accounts, no launcher downloads, no tracking. Here's how I built it and what I learned. The stack Frontend : Pure browser-based, vanilla JS Deployment : Google Cloud Run i18n : 3 languages (EN, 简体中文, 繁體中文) with instant switching Identity : Emoji badge system — no usernames, no passwords The architecture The entire app is a single-page browser app. No backend for user auth (because there is no auth). Sessions are ephemeral — nothing is stored. Multi-language i18n Adding 3 languages was the #1 feature request within 24 hours of launch. Simple key-value translation maps, no framework needed. The badge identity system Instead of usernames, users pick an emoji badge (🎮 ⚡ 🦊 🐉 🐼 🚀 🐱 🐯 🌟 🍿). This turned out to be the most talked-about feature. It's fun, zero-friction, and surprisingly expressive. Privacy by default No data collected. No cookies. No analytics. Just the game. Privacy isn't a feature — it's the absence of features that invade privacy. What I'd do differently Multi-language from day 1 More game variety before launch Better mobile responsiveness Try it : https://gamedeck-804028808308.us-west2.run.app Source : Built solo, open to questions! Would love feedback from the dev community — especially on the browser game architecture and i18n approach.

Your portfolio is often the first impression a recruiter, client, or fellow developer gets of you. If it loads slowly, ranks nowhere on Google, or is a pain to update, it's working against you instead of for you. Here's how I approached optimizing mine — covering performance, SEO, and everyday usability. 1. Start With a Lightweight Foundation The biggest performance wins come before you write a single line of custom code. Pick a lean stack. Static site generators (Astro, Next.js with static export, Hugo, or even plain HTML/CSS/JS) ship far less JavaScript than a full SPA framework for a mostly-static portfolio. Avoid unnecessary UI libraries. A heavy component library for a five-page site adds kilobytes you don't need. Hand-roll simple components instead. Use system fonts or self-host web fonts. Pulling fonts from a third-party CDN adds an extra DNS lookup and render-blocking request. Self-hosting with font-display: swap avoids layout shift and speeds up first paint. 2. Optimize Images (This Is Usually the Biggest Win) Images are almost always the heaviest assets on a portfolio site. Convert images to WebP or AVIF — typically 30–50% smaller than JPEG/PNG at the same visual quality. Resize before upload. Don't serve a 4000px-wide photo in a 600px container. Use loading="lazy" on below-the-fold images so the browser doesn't fetch them until needed. Add explicit width and height attributes to prevent layout shift (this also helps your Cumulative Layout Shift score). <img src= "/project-thumb.webp" alt= "Project screenshot" width= "600" height= "400" loading= "lazy" /> 3. Minimize and Defer JavaScript Ship only the JS a page actually needs — code-split per route if your framework supports it. Defer non-critical scripts (analytics, chat widgets) with defer or load them after the page is interactive. Audit your bundle with a tool like source-map-explorer or your framework's built-in bundle analyzer to catch unexpectedly large dependencies. 4. Nail the SEO Basics Good perf

When I checked Google Search Console after a month, only 2 of my 8 sites were indexed. The other 6 had zero pages in Google's eyes. No penalty, no error banner. Just silence. The bug My build script generated the sitemap by mapping over page objects. Somewhere a URL field was an object, not a string. So the sitemap shipped lines like: <url><loc> https://example.com/[object Object] </loc></url> Google fetched the sitemap, saw garbage URLs, and quietly skipped the whole file. No crawl, no index. How I caught it GSC > Sitemaps > it said "Success" but "Discovered pages: 0". That mismatch is the tell. I opened the raw sitemap.xml in the browser and searched for [object . There it was. Root cause: url: page.url where page.url was itself { path, params } , not a string. The fix // before loc : page . url // -> [object Object] // after loc : `https://livephotokit.com ${ page . path } ` Redeployed, resubmitted the sitemap, and requested indexing on the core pages. Pages started landing in the index within a couple of days. Takeaway A "Success" status on your sitemap does not mean Google read your URLs. Always open the raw XML and eyeball it. One bad [object Object] can silently sink an entire site. I'm building LivePhotoKit and a handful of other small tools solo with AI. Sharing the real bugs as I hit them.

Every developer has that one project. The passion build that sits in the back of your mind for months—or even years—before you finally sit down, crack your knuckles, and make it a reality. For me, that project was building a modern, open-access bilingual digital lexicon bridging English and Assamese: AssameseDictionary.org . While it started as a personal milestone dream, it quickly turned into a massive data engineering and architecture challenge. Here is how I tackled parsing a massive vocabulary database and serving it globally with near-zero latency. 🏗️ The Core Challenge: Scale vs. Speed A dictionary isn't like a standard SaaS app or landing page. It lives and dies by its database depth. To make this a truly definitive tool, I compiled, cleaned, and programmatically validated an extensive vocabulary index mapping over 293,000 words . The dataset doesn't just hold simple translations; it maps complex bidirectional lookups, phonetic transliterations, advanced English definitions, context usage examples, and cross-linked synonym tokens. If I threw this massive dataset into a traditional relational database hooked up to a standard server setup, I ran into immediate roadblocks: Latency: Heavy search queries on a dataset this size can cause noticeable lag. Cost/Overhead: Maintaining and scaling database servers for unpredictable public traffic gets expensive fast. I wanted the search utility to snap back instantly. To achieve that, I had to ditch traditional server paradigms entirely. ⚡ The Architecture: Serverless Edge Caching To keep things ultra-lightweight, highly cost-effective, and blazing fast, I built the platform around an edge-computing topology: The Runtime: I offloaded the backend logic entirely to Cloudflare Workers . Instead of routing traffic to a centralized origin server, queries are intercepted and executed at serverless edge locations physically closest to the user. The Data Layer: Instead of an active SQL database bottleneck, I mapped the data mat

Using AI to find authorization bugs — and to prove the ones that aren't real Draft flagship post. Safe to publish now (no undisclosed vulnerabilities). The production case study referenced at the end is withheld pending coordinated disclosure. In 2026, bug bounty programs started closing their doors. Nextcloud suspended paid rewards, citing a flood of AI-generated, low-quality reports. Mattermost ended its program. The Internet Bug Bounty cut payouts by roughly 80%. The common thread isn't that AI can't find bugs — it's that most AI-assisted "findings" are plausible but wrong , and triage teams are drowning in them. That reframes the problem. The scarce skill in 2026 isn't generating candidate vulnerabilities — a language model will hand you fifty before lunch. It's refuting the forty-nine that don't hold . The differentiator is a method whose primary output is correct negatives . Here's the method I use for source-available targets, and a worked example where the honest result was "there's no bug here." The method: fan out to find, converge to refute Two stages, two different cost tiers: Fan-out (cheap models). Split the target's authorization surface into subsystems and read each in parallel. Each reader's only job is to surface candidate broken invariants — places where an object is loaded by ID without an owner check, where a protected action might skip a re-auth gate, where two code paths authorize the same thing differently. Optimize for recall. Expect mostly false positives. Adversarial verification (an expensive, high-reasoning model). Take each candidate and try to kill it. Default to REFUTED. A candidate survives only if you can cite the specific source lines proving the guard is absent and the dangerous path is reachable and nothing upstream already blocks it. Frame every survivor as a broken invariant — a one-sentence statement of the rule the system must never violate — and classify it as core versus config-dependent. The output that matters most is the