Author: Alex Isa (Webappski). This is the dev-tutorial cut of a longer piece on the Webappski blog — terminal-first, fewer words on the why. If a buyer asks ChatGPT "best CDN providers 2026" and your product is not in the answer, you lose the sale before you ever see the lead. The only honest way to know whether that is happening is to ask the engines the questions your buyers ask and read the raw answers — not trust a single dashboard score. Here is the loop we at Webappski run for a client, with the open-source tool aeo-platform (MIT, zero runtime deps). 1. Install and point it at the client's domain npm install -g aeo-platform cd client-audit && aeo-tracker init init writes a .aeo-tracker.json . The three things that matter: { "brand" : "Northwind CDN" , // illustrative, fictional brand "domain" : "northwind.example" , // registrable domain — subdomains count, spoof hosts don't "engines" : [ "openai" , "gemini" , "anthropic" ], // ChatGPT, Gemini, Claude "queries" : [ "best CDN providers 2026" , "best low-latency video streaming CDN 2026" , "alternatives to the market-leading CDN 2026" ] } The questions ARE the audit. A basket of vanity phrases produces a flattering, useless number; a basket of the buyer's real decision questions produces a number that predicts revenue. Freeze it, so next month's run is comparable. 2. Run it — sampled, not one noisy shot AI answers are non-deterministic: ask the same question twice and you can get a different list. A single pass turns that noise into a fake-precise number. So run each cell several times and let the score carry a confidence interval instead of pretending one shot is the truth: # plain single-shot run aeo-tracker run # sample each cell N times — the score comes back with a Wilson confidence interval aeo-tracker run --samples = 5 With --samples=5 , every (query × engine) cell is queried five times; the headline presence rate is then reported as a Wilson interval, and small samples are flagged as small rather than so

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

I wanted a smaller way to move books from my Mac to my Kindle. There are already good tools for this. Amazon has Send to Kindle. Calibre has a powerful content server. USB transfer still works. But each option carries a little friction: Send to Kindle goes through the cloud. Calibre is excellent, but it is a full library manager. USB transfer needs a cable and a manual copy step. Kindle Share is built for the smaller workflow: Choose a folder on your Mac. Start sharing. Open one local address on Kindle. Download the book. No account. No cloud. No cable. How it works Kindle Share starts a tiny local web server on your Mac. It only serves files from the folder you choose. When your Kindle is on the same Wi-Fi network, you open the Kindle browser and visit the address shown in the app. From there, you get a simple list of supported files and can download them directly. Supported formats today: PDF EPUB MOBI AZW AZW3 Why local-first? I like tools that do not require an account for a local job. If the book is already on my Mac and the Kindle is already next to me, sending the file through a cloud service feels heavier than it needs to be. Kindle Share keeps that path local. That also makes the app easier to reason about. The folder you choose is the folder being shared. Stop sharing, and the local server stops. What it is not Kindle Share is not trying to replace Calibre. Calibre is a serious ebook library system with conversion, metadata, plugins, and deep device workflows. Kindle Share is intentionally narrower. It is a small macOS utility for quick local transfer. Try it Download the latest build from GitHub Releases: https://github.com/thanhphuchuynh/kindle-shared/releases Source code: https://github.com/thanhphuchuynh/kindle-shared

Hello Dev Community! 👋 It is officially Day 71 of my unbroken 100-day full-stack engineering run! After mastering polymorphic multi-part storage configurations yesterday, today I successfully crossed into core transactional operations: Engineering a High-Fidelity "Confirm and Pay" Checkout View and Wiring Database Inbound Array Modifications! In real-world booking platforms, processing a successful transaction requires more than updating an absolute view; you have to link documents relationally across collections. Today, I wired that entire execution pipeline together! 🧠 What I Handled on Day 71 (Checkout Engineering & Target Mutations) As displayed across my latest system files in "Screenshot (164).png" and "Screenshot (165).jpg" , handling payments runs through structured backend steps: 1. High-Fidelity Checkout Component ( /reserve ) I built out the detailed split-pane verification interface visible in "Screenshot (164).png" . The layout captures target trip date selections, total guests parameter caps, card input structures, and computes subtotal ledgers dynamically: Base Compute: $9000 x 5 nights = $45000 . Transactional Upgrades: Appending structured service charges ( $85 ) and local tax calculations ( $42 ) to update the final sum directly to $45127 . 2. Live Document Array Mutators (MongoDB User List Insertion) The most crucial logic happens when the user clicks the primary validation trigger labeled Confirm and pay : The inbound route controller extracts the targeted property identity token ( home._id ) via an embedded hidden input container. Instead of running isolation updates, it issues an atomized update operation straight into our MongoDB user records array (e.g., using Mongoose operators like $push or tracking active profiles inside our custom data state loops). This appends the exact property listing target ID directly into the user's booking history array database matrix! 🛠️ View Markup Code Integration View As showcased in my VS Code script structu

AI video & audio effects SDK for real-time apps Discussion | Link

There's a version of dogfooding that's a slogan, and a version where your own employees can't ship code until the bug is fixed. We run the second kind. The Authagonal staff console, the one we use to manage every tenant, authenticates through Authagonal itself: SAML single sign-on from our Entra directory, with SCIM deciding who gets in and what they can do. There is no separate admin password table. We deleted it. If our own SAML is broken, we are locked out of our own product. That's uncomfortable in exactly the useful way. It turns "SSO is an enterprise feature we support" into "SSO is the only way the people who built this get to work today." Here's what being our own customer caught. A trimmed build that broke signature verification We publish the auth server trimmed, to keep the image small. Trimming aggressively deletes code it can't prove is used, and reflection hides usage from it. .NET resolves its XML-signing crypto algorithms by name, reflectively, through CryptoConfig . The trimmer couldn't see those types were needed, removed them, and SignedXml quietly came back unable to build the algorithm. SAML signature verification, the step that proves the login is real, threw a null reference at runtime. The unit tests passed, because they ran against the untrimmed build where the types still existed. Only the trimmed production artifact failed, and it failed at the exact moment a human tried to sign in. We ship the auth server untrimmed now, with a healthy distrust of trimming anything near reflection-based crypto. If we only supported SAML rather than living on it, this is a customer's incident report instead of ours. Provisioning is the actual login Authenticating a user is the easy half of SSO. The hard half is deciding what they're allowed to do and keeping it in sync as people join and leave. We drive that with SCIM: Entra group membership maps to roles, resolved at the moment a token is issued, not copied once at account creation. Add someone to the righ

OrderHub Day 4: never trust the client. Today the backend gets proper Bean Validation — bad requests are rejected at the edge with a clear 400, long before they reach the business logic. And it's all declarative. ✅ Try the validating form (see the 400 body): https://dev48v.infy.uk/orderhub/day4-validation.html Three DTOs, three jobs A common beginner mistake is using one class everywhere. OrderHub keeps them separate: Request DTO ( CreateOrderRequest ) — what the client sends, and where validation lives. Domain/Entity ( Order ) — the internal model. Response DTO ( OrderResponse ) — what the API returns, so internal fields never leak. Validation is just annotations public record CreateOrderRequest ( @NotBlank @Size ( max = 120 ) @CleanText String customer , @NotBlank @Size ( max = 200 ) @CleanText String item , @Min ( 1 ) @Max ( 1000 ) int quantity ) {} Add @Valid @RequestBody on the controller and Spring checks every rule before your method runs. Break one and it throws MethodArgumentNotValidException . A custom constraint + clean errors @CleanText is a custom ConstraintValidator (rejects blank-after-trim + a small blocklist) — you can write your own rules, not just the built-ins. A @RestControllerAdvice turns validation failures into a tidy 400 with a field→message map. (Day 5 upgrades this to full RFC-7807 ProblemDetail.) 🔨 Full walkthrough (constraints → @valid → custom validator → 400 handler) on the page: https://dev48v.infy.uk/orderhub/day4-validation.html OrderHub — a production-grade Spring Boot backend, one feature a day. 🌐 https://dev48v.infy.uk · Code: https://github.com/dev48v/order-hub-from-zero

We warm your prospects before reaching out Discussion | Link

submitted by /u/goto-con [link] [留言]

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

Find where your Mac keyboard shortcuts clash Discussion | Link

The purpose of Starfall is to support the "transport and delivery of goods through space."

This is ymawky, a now-dynamic web server written entirely in ARM64 Assembly. I've previously posted about ymawky here: https://news.ycombinator.com/item?id=48080587 In the past month and a half, I've made some pretty major improvements: I've added CGI scripting support, so the server now supports query strings and dynamic content; and I've fully ported ymawky to run on Linux, rather than macOS-only. In addition to GET/PUT/HEAD/DELETE/OPTIONS requests, because of CGI support ymawky also accepts P