标签：#webdev

Your health data is probably the most sensitive information you own. Yet, most "AI Health Assistants" today require you to ship your symptoms, moods, and medical history to a cloud server. In the era of Edge AI and Privacy-preserving machine learning , this is no longer a trade-off we have to make. By leveraging the MLX Framework and Apple Silicon's unified memory, we can now run on-device LLMs like Llama-3-8B directly on an iPhone. This tutorial explores how to build a 100% offline, local health journal that summarizes your daily wellness without a single byte leaving your device. If you're looking for more production-ready patterns for secure AI, definitely check out the advanced guides over at Wellally Tech Blog . Why MLX-Swift? 🍏 Apple's MLX is a NumPy-like array framework designed specifically for Apple Silicon. When brought into the Swift ecosystem via mlx-swift , it allows us to tap into the GPU and Neural Engine with incredible efficiency. The Architecture: 100% Offline Inference Unlike traditional CoreML conversions that can be rigid, MLX allows for dynamic graph execution. Here is how the data flows from your typed notes to a structured health summary: graph TD A[User Input: Health Notes] --> B[SwiftUI View] B --> C{Privacy Layer} C -->|Local Only| D[MLX-Swift Engine] D --> E[Llama-3-8B Quantized Model] E --> F[Unified Memory / GPU] F --> G[Local Inference] G --> H[Markdown Health Summary] H --> B style C fill:#f9f,stroke:#333,stroke-width:4px style E fill:#00ff0022,stroke:#333 Prerequisites 🛠️ Device : iPhone 15 Pro or later (8GB RAM is highly recommended for Llama-3-8B). Software : Xcode 15.3+, iOS 17.4+. Tech Stack : MLX Framework, SwiftUI, Llama-3-8B (4-bit quantized). Step 1: Setting Up the MLX Engine First, we need to integrate the mlx-swift package. In your Package.swift , add: . package ( url : "https://github.com/ml-explore/mlx-swift-chat" , branch : "main" ) Now, let's initialize the model. Because we are on a mobile device, we must use a quantiz

Webflow's code export has two problems. It is only available on paid Workspace plans, and even when you pay, it does not include your CMS content: collection lists export as empty states, collection pages export with nothing in them. If your site has a blog, the export gives you a site without a blog. Forms and search are disabled in exported code too, per Webflow's own docs. Meanwhile, the published site is sitting on a CDN, fully rendered. Every CMS page is real HTML. wget --mirror will happily fetch all of it. What wget gives you, though, is not deployable. I migrated a production Webflow site this way and hit the same five breakages everyone hits, so I turned the fixes into a Claude Code skill that runs the whole workflow. This post is the five breakages, because they are useful whether or not you use the skill, and they apply to Framer, Squarespace, and friends with different domain names. Setup: the mirror itself The one wget incantation that matters, because Webflow serves assets from a separate CDN domain and you have to tell wget to follow it: wget --mirror --convert-links --adjust-extension \ --page-requisites --span-hosts \ --domains = yourdomain.com,cdn.prod.website-files.com \ --no-parent https://yourdomain.com/ This downloads every page plus the CSS, JS, images, and fonts they reference, and rewrites URLs to relative paths. It looks complete. It is about 90% complete, and the missing 10% is invisible until the page renders blank. Breakage 1: the page renders blank, console says "integrity" The symptom: your mirrored page shows raw unstyled text or nothing at all, and the console says Failed to find a valid digest in the 'integrity' attribute . The cause is subtle. Webflow ships its <link> and <script> tags with SHA-384 SRI hashes. wget's --convert-links rewrites URLs inside the downloaded CSS files, which changes their bytes, which means the SRI hash no longer matches, which means the browser silently refuses to apply the stylesheet. The file is right

I recently tackled the "AI memory" rabbit hole on other subreddits and this sub and I found out that people have different way of tackling this problem. Most notably being: - Notes - Git trees So my question is: How do you manage AI memory and how would you make it better? submitted by /u/Haunting-Bother7723 [link] [留言]

I Had 6 Side Projects Open in One Browser Window. Here's What That Was Costing Me. I counted once, on a normal Tuesday. 41 tabs, one window, six different side projects. A repo here, a localhost there, a Stripe dashboard, two Notion pages, a half-read Stack Overflow thread I was scared to close. I was using a tab manager to hold it all together. Save the session, restore it later, feel organized. It worked, in the sense that nothing got lost. But something was off, and it took me a while to name it. The tab manager was keeping my tabs. It was not keeping my projects. And the gap between those two things was quietly costing me. The number that bothered me I did a rough audit of one week. Every time I sat down to work on a project, I had to reconstruct where I was. Which task was next? When was that thing due? Where did I save that reference last month? The tabs were there, but the answers were not in the tabs. I timed it loosely. Five to ten minutes of "wait, where was I" at the start of every session, multiplied across six projects, multiplied across a week. Call it an hour, maybe more, spent just getting back to the surface before any real work started. An hour a week is not a catastrophe. But it was an hour spent doing something a tool should do for me, and the friction was enough that I started avoiding the projects with the most tabs. The cost was not really the time. It was that the heaviest projects felt the worst to open, so I opened them least. Why the tab manager could not fix this Here is the thing I had to admit. A tab manager is excellent at one job: saving and restoring tabs. It is not built to know anything about the project those tabs belong to. A tab is a URL. A project is a URL plus: A task that is due Friday A reference I saved three weeks ago and need again now A subscription renewing on the 14th A sense of what I actually shipped last time I worked on it When all of that lives outside the tab manager, in a to-do app, a notes file, my memory, rest

If you had a local business and wanted to move away from building your business' website with Wordpress, what route would you take, what software would you use to build the new website? That is if your web host on a shared server is Cloudways. submitted by /u/innomind [link] [留言]

Been building EventInbox for a while — webhook delivery infrastructure for developers. Finally got the landing page live today: https://eventinbox.pro It's the layer that sits between your app and your customers' endpoints — durable delivery, automatic retries, HMAC-signed payloads, full observability, and replay. SDKs for TypeScript, Python, and Go. Still early but the API is live and signup works end to end. Would love honest feedback on the page and the product direction. submitted by /u/eventinbox [link] [留言]

Every hand-tracking demo shows you 21 dots. The interesting part is what nobody shows: turning dots into numbers someone can act on. Dots are a capability, not a product Run any modern hand-tracking model and you get 21 beautifully stable landmarks per hand at 30 FPS. Impressive — and by itself, worthless. No client has ever paid for dots. They pay for measurements : is this clearance compliant, is this part aligned, did this patient's range of motion improve. I learned this on utility infrastructure work, where the deliverable was never "we detected the wire" — it was the attachment height of that wire, and whether it violates clearance rules . Keypoints were step one of three. The demo: live metrics, not just a skeleton My portfolio's keypoint demo derives three measurements per hand, every frame: const wrist = lm [ 0 ]; const palm = distance ( wrist , lm [ 9 ]); // scale reference const pinch = distance ( lm [ 4 ], lm [ 8 ]) / palm ; // thumb tip ↔ index tip The crucial line is the scale reference . Pixel distances are meaningless — they change as you move toward the camera. Dividing by palm length (wrist to middle knuckle) gives a relative measurement that's stable under distance, and multiplying by the average adult palm length (~8.5 cm) converts it into an approximate real-world gap — the demo shows "≈ 3.2 cm" floating on the pinch line. In infrastructure work the same role is played by a known object dimension — a standard crossarm, a pole class height. Every measurement-from-pixels system needs its ruler. Finger counting is a geometric test (is each fingertip farther from the wrist than its middle joint?), and "hand openness" averages fingertip extension — three lines of geometry each, but they convert a model output into a readout a human understands instantly. Honest layering The landmarks come from MediaPipe's pretrained pipeline (palm detector → landmark regressor → gesture classifier, float16, WASM + GPU delegate) — Google's models, credited on the page

A 1990s Nobel-adjacent therapy, a webcam, and 21 hand keypoints — recreating the mirror-box illusion for phantom limb pain, no hardware required. A therapy built on an illusion In the 1990s, neuroscientist V.S. Ramachandran discovered something remarkable: amputees suffering phantom limb pain often felt relief just by seeing their missing limb move again. His apparatus was almost comically simple — a box with a mirror. Put your intact hand in, look at its reflection where the missing hand would be, and move. The brain, watching the "missing" hand obey commands again, often dials the pain down. The limitation was never the science. It was the box: a physical apparatus, used in clinics, hard to scale, impossible to measure. Replacing glass with keypoints A webcam plus real-time hand tracking can produce the same illusion with better properties: webcam frame → hand landmark model (21 keypoints, on-device) → reflect: phantom[i] = { x: 1 − x, y, z } → render real hand (solid) + phantom twin (ghost) on canvas The reflection is one line of math. Everything around it is what makes the illusion land: const phantom = real . map ( p => ({ x : 1 - p . x , y : p . y , z : p . z })); The visual treatment matters more than I expected. The phantom hand is rendered as a ghostly cyan skeleton with a translucent palm fill, a "breathing" glow that pulses on a ~3 second cycle, and a fading afterimage trail of its last few frames — it reads as present but ethereal , which is exactly the perceptual story mirror therapy needs to tell. A dashed mirror plane down the center of the frame makes the reflection relationship legible at a glance. The engineering details that matter Tracking : MediaPipe HandLandmarker (Google's pretrained model — credit where due), running via WebAssembly with GPU delegate. ~30 FPS on a laptop. Privacy by architecture : every frame is processed on-device. For a medical-adjacent application, "video never leaves your browser" isn't a feature, it's a requirement. Lazy

Originally published on clintech.me If you've integrated Google Maps into a React app and seen Autocomplete randomly stop working, Directions silently fail, or the API throw google is not defined on second render — you've hit the duplicate loading bug. Here's exactly what caused it in my case and how I fixed it. The setup that broke things While building delivery address flows at POLOM — a production e-commerce platform — I integrated Google Places Autocomplete across 20+ screens. I had the Maps JavaScript API loading in two places: A provider.tsx for global script loading across the app A useLoadGoogleMaps hook inside a shared component This caused race conditions. The Autocomplete and Directions APIs were initialising before the script fully resolved in some renders, silently failing in others. The failure wasn't consistent, which made it harder to catch. The fix Step 1 — Remove the global load Delete the script tag or next/script call in provider.tsx . There should be exactly one place the Maps API loads. Step 2 — Centralise in a hook Move all loading logic into a single useLoadGoogleMaps hook using dynamic loading. If you're on Next.js, next/script with strategy="afterInteractive" inside the hook is the right approach. Step 3 — Guard before initialising if ( ! window . google ?. maps ) return ; Check that the API is fully available before attempting to attach Autocomplete or Directions . Don't assume the script load event means every namespace is ready. Step 4 — Scope your ref correctly Bind the autocomplete instance to inputRef.current explicitly. If the component remounts, re-initialise the binding — don't assume the previous instance is still attached. The result One load, one source of truth, no race conditions. Autocomplete and Directions worked consistently across all 20+ screens without reinitialising on every render. Security — the step most developers skip Restrict your API key at the Google Cloud Console level: HTTP referrers: whitelist your domain onl

One of the most frustrating parts of using AI coding tools is what happens when you have to switch between them. Every time I move to a different tool, I end up re-explaining the project, architecture, requirements, previous decisions, and all the context I’ve already built up elsewhere. It feels inefficient having to repeatedly provide the same context every time I switch tools or start a new session. Is anyone else running into this? How are you handling it today? submitted by /u/Bar_David [link] [留言]

As developers, we often lose hours to repetitive tasks - formatting data, debugging auth tokens, or wrestling with encoding issues. The right set of utility tools can cut that overhead significantly. Here is a curated breakdown of the categories and tools worth keeping in your daily workflow in 2026. JSON and Data Formatting Tools Working with raw, minified API responses is a real productivity killer. A browser-based JSON formatter with real-time validation and proper indentation helps you parse and debug responses in seconds - without sending your data to third-party servers. Similarly, XML is far from dead; SOAP APIs and enterprise integrations still rely on it, so a solid XML formatter with XPath support is worth having around. On the frontend, a CSS minifier that handles dead code removal and selector optimization can meaningfully reduce your page load times. Data Conversion Utilities Modern stacks often have to bridge the gap between formats. A JSON-to-XML converter is critical when integrating with legacy systems, but look for one that handles arrays and special characters correctly. CSV-to-JSON converters help structure flat export data from spreadsheets or databases into something your application can consume. And if your deployment pipeline involves YAML config files, a formatter that catches indentation errors before they break your CI/CD run is essential. Encoding and Security Helpers Base64 encoding comes up constantly - from embedding images in CSS to building HTTP Basic Auth headers. A reliable encoder/decoder handles all these cases without fuss. URL encoding matters too; unencoded special characters in query strings cause subtle API bugs that are surprisingly hard to track down. For authentication debugging, a JWT decoder lets you inspect token payloads without needing to verify the signature - ideal for local development and troubleshooting. Code Generation and Color Utilities Distributed systems need collision-resistant unique IDs - a UUID generato

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

As part of Apple's worldwide developers conference (WWDC) they announced some of the new stuff coming to WebKit and Safari 27. Among them is a feature that Google Chrome got in April of last year: fully customizable select elements. As an accessibility professional, I am absolutely thrilled. I am disappointed, though, that Firefox doesn't have it yet. You can find the session for what's new here: https://developer.apple.com/videos/play/wwdc2026/204 submitted by /u/ThatBlindSwiftDevGuy [link] [留言]

I don’t want to stereotype all devs, but a lot of them seem to have difficult personalities. Things I’ve noticed are smugness/arrogance/elitism, gatekeeping/knowledge hoarding, favoritism/cliques, ostracism and mobbing. You have ppl who are just downright mean and carry bad attitudes who constantly need to remind you how smart they are. So they use every opportunity to show off and one up you in front to management. A lot of ppl don’t take this as a job, it’s like their entire personality. And then you have these lone wolf or extremely socially awkward types that you can barely talk to. I think it’s kinda rare to find just a normal group of chill friendly engineers to work with. Thoughts? submitted by /u/throwaway0134hdj [link] [留言]

When building a personal finance tracker, data integrity and system reliability are non-negotiable. One missing try/catch block can crash your whole server, and weak types can let invalid financial payloads corrupt your database. While building the backend for my personal finance tracker, I decided to move past generic tutorials and build a bulletproof, production-grade API core using Express, TypeScript, and Zod. In this post, I’ll show you how I implemented a type-safe middleware ecosystem, leveraged TypeScript declaration merging to extend the native Request object, and eliminated repetitive try/catch boilerplate across the entire codebase. 1. The Weapon Against Boilerplate: The asyncHandler HOC Writing try/catch blocks in every single controller handler clutters code and introduces human error—it’s easy to forget to pass an error to next() . To solve this, I engineered a Higher-Order Function (HOC) factory that wraps asynchronous request handlers and automatically catches rejected promises, safely routing them into the global error handler. import { Request , Response , NextFunction , RequestHandler } from ' express ' ; export const asyncHandler = ( fn : RequestHandler ): RequestHandler => { return ( req : Request , res : Response , next : NextFunction ) => { Promise . resolve ( fn ( req , res , next )). catch ( next ); }; }; Why this matters: Reliability: Async errors always reach the centralized error middleware. Readability: Route controllers stay beautifully clean, focusing only on business logic rather than async control flow wiring. 2. TypeScript Magic: Declaration Merging & Type Augmentation When dealing with authentication tokens, request tracing ( requestId ), or custom validated payloads, developers frequently resort to casting the request as any (e.g., (req as any).userId ). This completely destroys Type Safety. Instead of fighting the compiler, I leveraged TypeScript Declaration Merging to reopen Express's internal Request interface and merge my cust

In my last post I complained — a lot — about product managers and how they made my life hell with vibe code. PS: apologies, manager, if you're reading this — but it's true. Now, I'm not here just to complain. There were a lot of learning opportunities too, like how to handle legacy / vibe code. Because at the end of the day, both are the same: no one knows how they work, but somehow they keep working. Touching them is like defusing a bomb — you never know how your change might cascade and break the core logic. The good news is that vibe code is much simpler than legacy. AI, in all its glory, tries to write perfect-looking code — proper function names, comments, the works — not like legacy code where a single function runs 500 lines, with spaghetti names all over that make no sense and comments that are out of date. And that makes it something I can actually handle. I still don't have a perfect, step-by-step playbook — but I've got pieces. The first one. The cheapest and the oldest one. The one the industry solved decades ago and the whole "AI built my app in a day" crowd somehow forgot exists. A linter. Yes, you heard me right. A linter. ESLint. Most people who've been in this industry already know it. It's the most boring, reliable tool in the box. But in an era where the answer to every problem is "add another AI," it's worth saying out loud why the boring tool still wins. What a linter actually is If you vibe-coded your way into this world, or you're new to web dev in general and have never heard the word "lint", here's the honest version. A linter is a set of rules you add to your repo. It reads your code without running it, checks it against those rules, and flags everything that's broken, sloppy, or about to bite you in production. The detail people get wrong: it's not a grep for bad words. A real linter parses your code into a syntax tree and actually reasons about its structure — what's imported, what's called, what's reachable, what types flow where. That's

Serverless functions have a time limit. Vercel gives you 60 seconds on Pro. None of that is enough to send a welcome email sequence, process an uploaded CSV, or run any workflow with multiple external API calls. Inngest solves this by turning your Next.js API routes into reliable, retryable, observable background jobs — without Redis, without a worker process, without any separate queue infrastructure. Read the full guide with all code examples at stacknotice.com How It Works You define functions that run in response to events . When an event fires, Inngest calls your function via HTTP. If the function fails, Inngest retries it. If the function has multiple steps, Inngest checkpoints each step so a failure halfway through doesn't restart from scratch. Setup npm install inngest // lib/inngest/client.ts import { Inngest } from ' inngest ' export const inngest = new Inngest ({ id : ' my-app ' }) // app/api/inngest/route.ts import { serve } from ' inngest/next ' import { inngest } from ' @/lib/inngest/client ' import { welcomeSequence } from ' @/lib/inngest/functions/welcome ' export const { GET , POST , PUT } = serve ({ client : inngest , functions : [ welcomeSequence ], }) Welcome Email Sequence export const welcomeSequence = inngest . createFunction ( { id : ' welcome-email-sequence ' , retries : 3 }, { event : ' user/signed-up ' }, async ({ event , step }) => { const { userId , email , name } = event . data // Each step is independently retried await step . run ( ' send-welcome-email ' , async () => { await resend . emails . send ({ from : ' hello@yourapp.com ' , to : email , subject : `Welcome, ${ name } !` , html : `<p>Thanks for signing up...</p>` , }) }) await step . sleep ( ' wait-2-days ' , ' 2 days ' ) await step . run ( ' send-tips-email ' , async () => { await resend . emails . send ({ from : ' hello@yourapp.com ' , to : email , subject : ' Top 5 tips to get the most out of the app ' , html : `<p>Here are the tips...</p>` , }) }) await step . sleep ( ' wait

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

A complete walkthrough of publishing Cartlify — a React e-commerce UI kit — to npm for the first time. The Milestone Yesterday I published Cartlify to npm. npm install cartlify It sounds simple. But getting to that one line took more decisions, more configuration, and more trial and error than I expected. This article covers everything — from setting up the build config to the actual publish command — so you don't have to figure it out the hard way. What Is Cartlify? Cartlify is a production-ready React + TypeScript + Tailwind CSS component library focused on e-commerce UI. 4 components that every e-commerce project needs: ProductCard — 3 layout variants, image gallery, wishlist, sale badges, skeleton loading CartDrawer — animated slide-in, focus trap, ESC dismiss, quantity stepper CheckoutStepper — horizontal/vertical, animated connectors, keyboard navigation PageLoader — 4 animation styles, 3 position modes Plus 3 utility hooks, 11 tree-shakeable icons, 40+ CSS design tokens, full dark mode, and 141 Jest + React Testing Library tests. Built so freelance developers and indie makers can skip the painful e-commerce UI layer and ship faster. Why Publish to npm? Before npm, Cartlify was only available on Gumroad as a paid download. That's fine — but npm adds something Gumroad can't: Developer sees Cartlify → runs npm install cartlify → evaluates the compiled output → trusts the quality → buys the full source on Gumroad npm is a credibility and discovery channel — not just a distribution method. A package on npm signals that something is real, maintained, and production-ready. Also: npmjs.com gets millions of developer searches every month. That's free traffic you can't get from Gumroad alone. The Build Setup — tsup The most important decision before publishing is how you bundle your library. I chose tsup — a zero-config TypeScript bundler built on esbuild. Here's why: Tool Config needed Speed Output Rollup Lots Medium ESM + CJS Webpack Heavy Slow CJS only Vite lib mode

submitted by /u/fagnerbrack [link] [留言]