标签：#showdev

I was trying to tell someone something real in her first language — not "I missed you" from a dropdown, but the version that sounds like a person said it. Google Translate gave me one answer. No indication whether it was what you'd text at midnight or what you'd write in a letter to someone's grandmother. That's the failure mode of literal translators: one output, no register, no sense of what you're actually choosing between. konid returns 3 options per query, ordered casual to formal, with the register explained and a cultural note on the difference between them. For Mandarin or Japanese, audio plays through your speakers via node-edge-tts — no API key, no browser tab — because reading a pinyin romanization and actually hearing the tone contour are two different things. The vowel length in Korean, the pitch drop in Japanese, the stress pattern in Arabic: you don't internalize those from text. You internalize them from hearing them repeated back while you're still in the context of trying to say something. The setup for Claude Code is one line: claude mcp add konid-ai -- npx -y konid-ai It runs as an MCP server, so it works in Cursor, VS Code Copilot, Windsurf, Zed, JetBrains, and Claude Cowork. Also installs as a ChatGPT app via Developer mode using the endpoint https://konid.fly.dev/mcp . Supports 13+ languages: Mandarin, Japanese, Korean, Spanish, French, German, Portuguese, Italian, Russian, Arabic, Hindi, and more. The name is Farsi — konid (کنید) means "do." MIT licensed. https://github.com/robertnowell/konid-language-learning

I was working on a project and needed to convert some Markdown to HTML. Searched for it online, found a site, done. Next day I needed HTML back to Markdown. Searched again, different site. Then JSON to CSV. Then something else. Different site every time, half of them slow. At some point I just thought — why not build one site that handles all of this? So I did. That's QuickConvert . What It Is Just a collection of the conversions I kept searching for: JSON → CSV and back Markdown → HTML and back JSON → YAML XML → JSON CSV → JSON HTML → PDF Nothing fancy. No account needed. Everything runs directly in your browser — no data is sent anywhere, nothing is saved on a server. Why Astro I also wanted to try Astro for a while. I kept hearing it was great for content-heavy sites because of how little JavaScript it ships by default. A converter site felt like the perfect use case — mostly static pages with one interactive tool on each. Since Astro works with React components, it wasn't a big adjustment once I got the basics down. You write your page layout in .astro files and drop in React components where you need interactivity. Clicked pretty quickly. The result — 100 on Lighthouse across the board. The pages load instantly because there's barely anything to load. Hosting Deployed on Cloudflare Pages (now cloudflare workers). Free tier. The only thing this site costs me is the domain name. Try It quickconvert.dev Runs in your browser, no account, no data saved anywhere. I'm planning to keep adding more conversions — the everyday ones that developers reach for and end up Googling every single time. Maybe we can make something that becomes a tab that just stays open. Feedback welcome — especially if a conversion you need isn't there yet.

If you use Claude daily, you've probably hit a wall mid-task. The reason it's so easy: Claude doesn't have one limit. It has several. A rolling 5-hour session window A weekly pool shared by all models Separate weekly caps per model (Opus, Sonnet, Claude Design) And the weekly pool is sneaky: Fable has no cap of its own and draws that shared pool down ~2× faster than Opus . So you can burn the week without realizing it. I wanted that state visible at a glance instead of digging through settings, so I built Claude Usage Monitor — a small browser extension for Chrome and Firefox. What it does It puts a color-coded % badge in your toolbar , and one click shows the full breakdown: Current 5-hour session + live countdown to reset Weekly all-models pool (with the Fable draw-down flagged on the card) Per-model weekly caps: Opus, Sonnet, Claude Design Daily Claude Code routine runs Extra-usage credits + prepaid balance for pay-as-you-go Auto-detects your plan (Pro / Max 5x / Max 20x / Team), so every number matches your subscription Six themes The privacy part (the part I cared about most) It's open source (MIT) and runs 100% locally — no backend, no analytics, no servers. A design decision I'm happy with: the host permissions are scoped to exactly four claude.ai endpoints (org list, usage stats, routine-run budget, prepaid balance). It physically can't read your chats, projects or files. Narrow permissions = less to trust, and less to exploit. One honest caveat: it reads claude.ai's own usage endpoints, so it can break if Anthropic changes them. Not affiliated with Anthropic. Try it It's free, no account needed (desktop Chrome & Firefox): 🔗 claude-monitor.com Chrome Web Store Firefox Add-ons Happy to hear what else you'd want tracked — drop a comment.

I take a lot of screenshots. The article I'll read later. The recipe I'll cook on Sunday. The movie name from someone's Instagram story. A job post, a product, a tender. Most of them die in my camera roll. So I built Chista — an iOS app that auto-imports every screenshot, classifies it with AI (Article, Product, Event, Reference, Media), and surfaces a one-tap action: Buy on Amazon , Add to Calendar , Reserve on OpenTable , etc. It shipped on the App Store thirty days after I started, for about $300 in total cost. The interesting part wasn't the app. It was what the build revealed. What I built Chista is a native iOS app + Python backend. iOS reads new screenshots in the background via PHPhotoLibraryChangeObserver , scoped to PHAssetMediaSubtype.photoScreenshot (so it literally can't see your other photos). Each new screenshot gets OCR'd on-device with Apple Vision , then the image + OCR text get POSTed to the backend. Backend sends the pair to OpenAI GPT-4o with a structured prompt that returns a CategorizationResult JSON: category, subtype, title, suggested action, extracted data (price, deadline, URL, etc.). Result gets persisted and pushed back to the inbox via Supabase real-time. That's the whole thing. The "magic moment" is just: you screenshot something, switch to Chista a few seconds later, it's already sorted with a contextual action button. Stack Layer Tool Why iOS app Swift 5.10, SwiftUI, StoreKit 2 iOS 17+, modern surface Backend FastAPI on Railway One-file ergonomics, fast cold starts Database + Auth Supabase Postgres + JWT auth out of the box AI OpenAI GPT-4o (Pro), gpt-4o-mini (Free) Tier-routed at categorization time Push APNs via aioapns Direct, no Firebase middleman Subscriptions StoreKit 2 + app-store-server-library Server-side JWS verification Affiliate routing Custom matrix in Supabase tables Amazon Associates wired, more pending Hosting (web) Cloudflare Pages Free, fast, never goes down No frameworks I wouldn't reach for again. What it cost Lin

Every time you use an online PDF converter, your file travels to a server somewhere — processed by a company you don't know, stored temporarily on hardware you don't control. For a random meme? Fine. For a payslip, a contract, or a medical document? That's a real privacy problem. What I built ConvertiZen is a document converter that runs 100% in the browser using WebAssembly and modern JS APIs. Your file never leaves your device. Ever. Verify it yourself: open DevTools > Network tab > run a conversion. Zero outgoing requests containing your file data. What it supports 40+ format pairs: PDF ↔ Word, JPG, PNG, Text, HTML, Markdown Excel ↔ CSV, JSON, HTML Images: JPG ↔ PNG ↔ WebP, GIF/BMP → PDF JSON ↔ CSV, Markdown ↔ HTML, XML → JSON How it works PDF.js for PDF parsing docx library for Word generation SheetJS for Excel/CSV Canvas API for image conversions Everything client-side — no server required Pricing 3 free conversions/day, no account needed. Beyond that: €0.69/conversion, €4.99 for a pack of 10, or €4.99/month for unlimited Premium. Feedback welcome What formats are missing? What would make you trust a browser-based tool over a server-based one? 👉 https://convertizen.netlify.app

Show HN: NeuralBridge — We Built a Self-Healing SDK for LLM-Powered Agents After months of production experience running LLM calls at scale, we realized something uncomfortable: every AI agent eventually crashes . Not because the code is wrong, but because LLM APIs fail in ways you can't predict. Timeouts. Rate limits. Empty responses. Schema violations. Drift. These aren't edge cases — they're the norm. So we built NeuralBridge: an embedded SDK that makes LLM calls self-healing. The Problem Try running 100,000 LLM calls through any single provider. You'll see: 2-5% failure rate from timeouts and 5xx errors Rate limits that cascade through your pipeline Schema violations when models change behavior Provider-specific quirks that require custom error handling 30-200ms of unnecessary latency from gateway proxies Most teams solve this by building their own retry logic, circuit breakers, and fallback chains. It works — until it doesn't. Because the next failure is always the one you didn't anticipate. Our Approach: Embedded Self-Healing Instead of a gateway (which adds latency and infrastructure), we embedded the reliability logic directly into the SDK: from neuralbridge import SelfHealingEngine engine = SelfHealingEngine () result = engine . call ( " Write a Python function for binary search " ) if result . recovered : print ( f " Fault: { result . diagnosis } " ) print ( f " Recovery: { result . recovery_action } " ) When a call fails, the engine: Diagnoses the fault type in ~19us (P50) Escalates through 4 layers: retry -> degrade -> failover -> learned rule Validates the output across 5 dimensions Learns from the experience for next time Production Results Metric Value Auto-recovery rate 84.1% of faults Fault patterns recognized 280+ Recovery strategies 30+ Learned rules (flywheel) 88+ Diagnosis latency 19us P50 Install size 375 KB Why Open Source? We went Apache 2.0 because reliability infrastructure should be a commodity. The SDK is free and open. Pro features (ente

I was now done with the basic setup. However, during my time working at my startup, I have learnt to think about a project wearing multiple caps. One such aspect was - With Dhrishti running on a server that was already loaded, I did NOT want the tracking application itself to be heavy. I had to set some benchmarks to ensure that Dhrishti did not consume a tonne of space while tracking the metrics. I also had a problem with unresolved requests - in my mock_services, I had a client that was continuously hitting the API Gateway service. I had to fine-tune all the requests so that I could run tests under different loads, but the advantage was that my project was easily able to discern where the client request was coming from. However, in a production scenario, you can never know where a request is coming from - obviously, we cannot resolve different customer IPs to their respective customer names. This was the first problem. I had to specify what a customer was, and what an unknown request was. I came up with the following solution - Any unresolved IPs are going to be added to a table in the UI called unresolved IP table. This would help me with debugging later. Now, any unresolved IPs which also made requests to an ENTRY-POINT into my application could be added as the customers. For this, I very simply had to filter out the unknown IPs, and keep a configurable entry-point in dhrishti.json in which I would add a bunch of entry-points (in the case of my mock micro-service architecture, only 1) Now, I could differentiate between 2 types of unknown IPs - one which was potentially a customer, one which was a background network call, not important to the working system. The next problem was with the client service itself. It was difficult to simulate, say - a million users in my system. I had essentially built a service which was only being used by 1 customer, but how would Dhrishti behave if I added multiple client IPs? Using K6 k6 is a Grafana based application that helps

What I built A small business owner needed an automated customer support system that works 24/7, answering questions based only on their internal policies – no hallucinations, no outside internet knowledge. They also wanted multilingual support (English, French, Spanish) and a natural AI voice introduction. I built the AI Customer Service Suite to solve this exactly. Key features Answers questions strictly from uploaded documents (PDF, DOCX, TXT) – no generic AI guessing Multilingual chat interface (English, French, Spanish) Female AI voice introduction that explains the software and pricing Security badge and Stripe payment link for licensing Optional Twilio integration for WhatsApp and voice calls Full source code delivered Tech stack Python Streamlit Groq Llama 3.1 (RAG) edge‑tts for voice Twilio API (optional) Live demo https://ai-customer-service-suite-bemey6yywchvkz7yrghufc.streamlit.app/ What we do at GlobalInternet.py We provide tailored software solutions that connect the global market with local expertise. We build custom AI‑powered applications, business tools, and automation systems – delivered fast with full source code. Contact us Phone: (509) 4738 5663 Email: deslandes78@gmail.com Website: https://globalinternetsitepy-abh7v6tnmskxxnuplrdcgk.streamlit.app/ What's next I am adding more language options and a live dashboard for businesses to track support questions and user satisfaction. Feedback welcome Try the live demo, break it, ask it questions. I would love to hear your suggestions or feature requests. Comment below or reach out via my website. #python, #streamlit, #chatbot, #ai, #customercare

A few days ago I finished benchmarking something I've been building - a cache-aware, stable, histogram-based sorting algorithm I'm calling BusSort . The results surprised even me. At 100 million elements, it runs ~2x faster than Java's Dual-Pivot Quicksort on random data - while being stable . Dual-Pivot QS is not. The Problem With Quicksort at Scale Quicksort-based algorithms partition elements with random writes across the entire array. At large scales this causes cache thrashing - elements are being written to memory locations all over the place, constantly missing L1 and L2 cache. The larger the array, the worse it gets. The Core Idea Instead of scattering elements globally, BusSort processes data in L1 cache-sized chunks - 4096 integers (~16KB). For each chunk, it does 4 passes: PASS 1 - Scan left-to-right, compute bucket for each element, build a local histogram PASS 2 - Compute local prefix sums (bucket positions within the chunk) PASS 3 - Scatter into a local grouped buffer - because this buffer is L1-sized, all random writes stay in cache ✅ PASS 4 - Copy each bucket's portion to its correct global position With 128-way splitting , recursion depth stays at just ~4 levels even for 100M elements. Base case: Insertion Sort for ≤ 1024 elements. On the benchmark machine (i5-1135G7, 48KB L1 data cache): 4096 × 3 × 4 bytes = 49,152 bytes ≈ 48KB The three working arrays fit exactly in L1. Not a coincidence. Benchmark Results Tested against Arrays.sort(int[]) - Java's Dual-Pivot Quicksort . n = 100,000,000 | Java 17 | i5-1135G7 @ 2.40GHz Input Type BusSort Dual-Pivot QS Ratio Random 3991ms 8604ms ~2x Sorted 57ms 104ms ~2x Reverse 280ms 166ms 0.6x Nearly Sorted 2452ms 2789ms ~1.1x Duplicates 712ms 2242ms ~2.4x Few Duplicates 1295ms 3185ms ~2.3x All Same 51ms 32ms 0.6x Clustered 1419ms 2242ms ~1.6x Consistently faster on most input types. Stable. Zero comparison overhead. The two losses (Reverse, All Same) are where Dual-Pivot QS has structural advantages - run detecti

Liquid syntax error: Unknown tag 'lineage'

Computer-based assessments have a quiet accessibility problem. Most platforms assume the user can read text on a screen, click through options, and type their responses. For visually impaired students — particularly in India — this assumption effectively shuts them out entirely. I wanted to fix that. Not with a workaround, but with an experience that feels native to voice from the ground up. The Problem Screen readers exist, but they're clunky, require separate setup, and often mispronounce Indian names, words, and sentence structures in ways that feel jarring and unnatural. The experience breaks down fast. What visually impaired Indian students actually need is a system that speaks to them the way people around them speak — in a familiar accent, at a natural pace, without sounding like a robot reading out a manual. That's what led me to Sarvam AI. Why Sarvam I had tried other TTS APIs before. They worked, technically. But there was always something off — a flatness to the voice, a slightly Western lilt, a pronunciation of common Hindi-origin words that made it obvious the model had never really heard Indian English spoken naturally. Sarvam's TTS was different. The first time I ran a test question through it, the output sounded like something a real person would say. The accent was warm and familiar — the kind of voice an Indian student would actually trust and follow without friction. That moment changed how I thought about the project. This wasn't just a convenience feature anymore. It was the core of the experience. What I Built The platform is a full-stack web app built with React and Tailwind on the frontend, Express.js on the backend, and PostgreSQL for storing user data and scores. The interaction model is deliberately simple. A single click anywhere on the screen triggers Sarvam TTS to read the current question aloud. A double click starts listening and transcribes the user's spoken answer using Sarvam STT. No keyboard required. No mouse precision required.

For years, whenever I needed to merge two PDFs or compress a file to upload to a government portal, I would Google "compress PDF", click the first result, and inevitably hit a paywall. "You have reached your 2 free files per day limit." Worse, I was uploading sensitive documents—tax returns, medical records, and NDAs—to random servers in God-knows-where just to strip out some heavy images. I decided to build an alternative. I wanted it to be 100% free, have absolutely no daily limits, and most importantly: zero server uploads . Here is how we built PDF Pro using Next.js and WebAssembly to process PDFs entirely natively inside the user's browser. The Architecture: Why WebAssembly? Traditional PDF tools (like Smallpdf or iLovePDF) use a monolithic server architecture. You upload your file to their AWS bucket, their backend runs a Python or C++ script (usually using Ghostscript or a proprietary library) to manipulate the PDF, and then you download the processed file. This architecture is expensive (high bandwidth and compute costs) and creates a massive privacy liability. By compiling a C++ PDF manipulation library down to WebAssembly (WASM) , we inverted the architecture. 1. The Build Process We took pdf-lib and custom C++ compression algorithms and compiled them to a lightweight .wasm binary. When a user visits PDF Pro Compress , their browser downloads the ~2MB WASM file once and caches it. 2. Client-Side Processing When you drag and drop a 50MB PDF into the UI, it never hits our server. Instead, the browser's JavaScript engine passes a Pointer to the file data directly into the WebAssembly memory buffer. The WASM module executes native C++ speeds directly on your local CPU to compress or merge the document. Performance Benchmarks Because there is zero upload and zero download time, the performance metrics are staggering: 10MB PDF Compression (Cloud): ~15 seconds (Upload) + 4 seconds (Process) + 5 seconds (Download) = 24 seconds . 10MB PDF Compression (PDF Pro WASM)

My CV is a PDF, and PDFs do not answer questions. So I built ask.hiten.dev : a streaming chat grounded in my actual career history, where a recruiter can ask "why should I hire you over another senior frontend engineer?" and get a real answer. The constraint that made it interesting: the total inference budget is zero. No OpenAI bill, no hosted vector DB, nothing. Here is what that actually took. Four free providers and a failover chain No single free tier is reliable enough to put in front of strangers. Groq's free tier caps at 100k tokens/day, and I hit that cap on day one. OpenRouter's free models come and go. Cerebras occasionally queues you out at busy times. The fix is boring and effective: an ordered provider chain, all OpenAI-compatible, walked per-request until one answers. Groq (llama-3.3-70b) -> OpenRouter (gpt-oss-120b:free) -> NVIDIA (llama-3.3-70b) -> Cerebras (gpt-oss-120b) Each provider is just a base URL, a key and a model name. The API route tries each in order; the first 2xx with a body wins, and the response streams straight through. The client gets an X-Provider header so I can see who served what in the logs. Two details that mattered: Empty env vars are not unset. Docker Compose's ${VAR:-} yields an empty string, which defeats ?? defaults in Node. Every key goes through a helper that coerces "" to undefined , otherwise a provider with no key "exists" and fails every request. You cannot cheaply probe a token-per-day cap. My health check hits GET /models on each provider (auth check, 60s cache). It tells you "key works, service up", not "you have tokens left". The failover chain covers the gap: a TPD-capped provider fails fast and the next one picks up. If every provider is down, the page itself says so. The health check runs server-side at render time, and instead of a broken chat you get a short maintenance note. Never ship a chat UI that can fail after the user has typed. Open-weight models do not follow formatting orders My site's voice avoi

https://dsa-life-simulator-frontend.vercel.app"I made a free tool to make DSA practice feel like an RPG — would like feedback from this community"Been grinding DSA for months and it never felt fun. So I built something. What it does: 🏟️ Real-time 1v1 Arena battles against other devs 🧪 Lab to create and publish your own challenges 🏘️ Community Hub to attempt others' challenges 📖 AI writes your weekly coding journey as a life story 🎮 XP, credits, levels, leaderboards Stack: React + Tailwind + Firebase + Node.js + Socket.IO + Groq AI Still early — would genuinely love feedback from people who've felt the pain of traditional DSA prep.

Audit thousands of passwords against data breaches — completely in your browser with zero-knowledge privacy. Published: June 9, 2026 TL;DR Most bulk password checkers require you to upload your entire vault. Utilora’s Bulk Password Breach Checker uses HIBP’s k-anonymity + local hashing so your passwords never leave your device . The Hidden Risk Most People Ignore Using a password manager is excellent, but it’s not enough. Many users unknowingly reuse or slightly modify passwords that have already been leaked in massive breaches (LinkedIn, Adobe, Yahoo, etc.). Manually checking hundreds or thousands of passwords is impractical — which is why people turn to bulk checkers. The problem? Most bulk checkers ask you to upload your password list . That creates a massive new privacy risk. How Utilora’s Zero-Knowledge Breach Checker Works We built this tool using a privacy-preserving technique called k-anonymity (popularized by Troy Hunt of Have I Been Pwned). Step-by-Step Technical Process: Local Hashing — Your browser uses the WebCrypto API to create a SHA-1 hash of each password locally. Prefix Only — Only the first 5 characters of the hash are sent to HIBP’s Range API. Server Response — HIBP returns hundreds of matching hashes that start with the same prefix. Local Comparison — Your browser checks if your full hash exists in the returned list. Result: HIBP knows someone checked a password starting with ABC12 , but has no idea which specific password it was. Why You Should Audit Your Entire Vault Regularly Discover weak or compromised passwords you forgot about Clean up old reused passwords Respond quickly after major breaches Maintain good password hygiene across all accounts Real-World Scenarios You exported your Bitwarden / 1Password / KeePass vault You want to check 500+ passwords before a security audit You just heard about a new major breach and want to verify impact You’re helping a family member or client secure their accounts How to Use the Tool Go to the Bulk Pas

zxcvbn is the most widely used password strength estimator with 1M npm downloads a week. It's also 389KB gzipped and hasn't shipped a commit since 2017. Most sign-up forms are hauling that around just to block password123 . Poor password UX is a real conversion problem. A strength meter that adds 389KB to your bundle delays page load — on mobile, measurably so. Users who hit a slow registration page don't wait. They leave. The irony is that most of that weight goes toward catching passwords nobody is actually using to register on your site. So I built passcore - 3.0KB gzipped and 98.4% detection rate on real breach data - same as zxcvbn, benchmarked against a deduped list of passwords pulled live from RockYou, Adobe, HIBP, and other major leak lists. zxcvbn takes ~9.7ms to load — it's parsing 389KB of dictionary into memory on every cold start. passcore loads in ~0.2ms. It evaluates a password in ~2,600 nanoseconds. For a registration form, it's effectively invisible — no jank, no layout shift, no contribution to your Core Web Vitals score. The strength meter shows up before the user finishes typing their first character. How it works: passcore runs five detection layers on every password: Dictionary - All entries sourced directly from breach data, not a generic word list Keyboard patterns - qwerty , asdf , 1234 , numpad walks Repeats - aaaa , ababab Sequences - abcdef , 123456 L33t speak - decodes p@ssw0rd → password , m0nk3y → monkey , then dictionary lookup The dictionary is small by design. Every entry was chosen because it appears in real breach data - not because it's a common English word. Password1! is caught not by a 40k word list but by stripping the suffix and checking if the core word is in the breach list. It is. The scoring model: passcore returns a score from 0 to 4 - same scale as zxcvbn. The detection layers run first. A dictionary match, keyboard pattern, repeat, sequence, or l33t substitution scores 0 or 1 immediately - no further calculation. If

I built a distributed compute grid where your idle laptop runs ML jobs — the orchestrator behind it The pitch: a single FastAPI hub takes compute jobs from ML researchers, and a fleet of home PCs and gaming rigs (RTX 4090s, M2 MacBooks, anything with a GPU and a Python interpreter) polls in, picks up work, and ships results back. A 20% platform fee funds the hub. An interactive dashboard shows the mesh in real time. I have been living inside this codebase for a few weeks. This post is about the part that actually determines whether the thing works or does not — the orchestrator . No frontend, no marketing — just the brain. Live dashboard: man44.zo.space/compute-pool Repo: github.com/AmSach/ComputePool-Grid The problem with "dumb" schedulers The first version of ComputeOrchestrator had a one-line bug that took down a 12-node stress test. Two jobs hit the hub at the same millisecond. Both saw the same node as idle . Both wrote busy to the same row. One node ended up double-allocated, the other starved, and the test logs looked like a hostage negotiation. The fix had to be three things at once: A scoring function that picks the right node, not just the first idle one. An async lock so concurrent submissions cannot race on a single node. A heartbeat monitor that reclaims nodes that ghosted. Here is what it looks like now. The scoring algorithm def _calculate_score ( self , capacity : Dict [ str , Any ], requirements : Dict [ str , Any ]) -> float : """ Heuristic for node-task matching. """ score = 0.0 if capacity . get ( " gpu_vram " , 0 ) >= requirements . get ( " min_vram " , 0 ): score += 10.0 if capacity . get ( " cpu_cores " , 0 ) >= requirements . get ( " min_cores " , 0 ): score += 5.0 return score The weights are deliberately lopsided. A node that satisfies a job's VRAM requirement gets a 2x bonus over a node that just barely has enough cores. The intuition: GPU work is the long pole. If you cannot fit the model in VRAM, nothing else matters, no matter how many

I got tired of paying for form services or spinning up a backend just to handle contact form submissions. So I built RG Forms — a contact form endpoint backed entirely by a Google Sheet you own. No server, no monthly fee, no third-party storing your data. The idea Most form tools store your submissions on their servers. You pay monthly, you depend on their uptime, and your data lives in their database. RG Forms does the opposite: every submission goes straight into a Google Sheet in your own Google Drive, sent by an Apps Script that you own and control. RG Forms provisions that sheet and script for you in about 90 seconds. After that, your endpoint runs forever at no cost — completely independent of any RG Forms server. Built for static sites If you host on GitHub Pages, Netlify, Vercel, Cloudflare Pages, or just plain HTML on a CDN, you've hit this wall: there's no backend to receive a form POST. The usual workarounds are a paid form service, a serverless function you have to write and maintain, or standing up a whole backend just for a contact form. RG Forms is built exactly for this. Your endpoint is a plain HTTPS URL you POST to straight from client-side JavaScript — no build step, no serverless function, no server of any kind. Drop the fetch call into your page and you're done. It pairs naturally with any static-site generator (Hugo, Jekyll, Astro, Eleventy, Next export) and any no-code builder that lets you add a snippet of JS. Your static site stays static; the form just works. How it's built RG Forms is a fully static web app. There's no RG Forms server, no database, no backend. Every API call during setup goes directly from your browser to Google using your own OAuth token. Setup (one time, in your browser): Your Browser ├─── Google OAuth ──▶ Short-lived token (memory only) ├─── Google Drive API ──▶ Creates Sheet + Drive folder └─── Apps Script API ──▶ Creates & deploys form handler Live endpoint (after provisioning): Your Website / App └─── POST to script

🚀 What I Built I created a collaborative AI Multi-Agent system using Google's new Agent Development Kit (ADK). The system functions as an automated Hollywood Production Team designed to streamline creative brainstorming. The user submits a simple movie prompt (e.g., "A movie about a time-traveling chef"), and the specialized agents work sequentially to refine the idea into a viable film concept. 🧠 My Agent Architecture My multi-agent team uses a sequential workflow tracking architecture consisting of two specialized agents running on gemini-2.5-flash : movie_writer : Takes the raw user input concept and expands it into a high-stakes, descriptive three-sentence movie plot. movie_critic : Automatically intercepts the writer's completed story context to deliver constructive structural improvements. These agents are orchestrated via a SequentialAgent pipeline configuration that manages data handoffs automatically. 🛠️ Key Learnings & Challenges Framework Evolution: I learned how to structure project modules using ADK 2.0's directory scanning conventions ( __init__.py mapping definitions). Overcoming Roadblocks: I originally ran into layout separation issues on Windows where the backend command runner could not discover the python modules. Resolving this taught me how the google.adk.cli maps working directory environments ( ./app ). Handling API Constraints: Dealing with transient API capacity limits (like standard 503 backend service spikes) taught me how crucial error handling and session resets are when building live AI tools.

There is a file in almost every backend I have worked on. It generates PDFs. Invoices, mostly. Sometimes reports or certificates. It was written years ago by someone who left, it runs a headless browser nobody fully understands, and it falls over on the last day of the month when finance needs the invoices out. I have rebuilt this same haunted corner enough times that I decided to fix it once, properly, for everyone. It is called PDFPipe. The actual problem Generating a PDF from HTML sounds trivial until you run it in production at any scale. The usual path is a headless Chromium (Puppeteer, Playwright, wkhtmltopdf, or Gotenberg). Then you discover: Chromium wants 0.5 to 1 GB of RAM per instance and falls over under load. Cold starts add seconds to every request after a deploy. Custom fonts do not load, or load inconsistently. Tables split across page breaks in ugly ways. You now own a service that needs health checks, retries, and monitoring. None of this is your product. It is undifferentiated infrastructure that breaks at the worst possible time. What PDFPipe does One endpoint. You send HTML or a template plus JSON data, you get back a PDF. curl https://api.pdfpipe.xyz/v1/pdf \ -H "Authorization: Bearer pp_live_..." \ -d '{"html":"<h1>Invoice #4012</h1>","options":{"format":"A4"}}' \ --output invoice.pdf That is the whole integration. No browser in your infra, no queue to babysit. Three decisions I made on purpose Flat pricing. A lot of PDF APIs price in credits where one large document burns several. I find that hostile. A document is a document. A real free tier. The industry standard free tier is around 50 documents a month, which is not enough to ship anything. PDFPipe gives 500. Security as a feature, not an afterthought. HTML-to-PDF services are a textbook SSRF target. Rendered markup can embed an iframe pointing at file:///etc/passwd or the cloud metadata endpoint at 169.254.169.254 and leak credentials straight into the returned PDF. There are CVEs for ex