DEV Community

AI Embeddings Break Columnar Assumptions in Parquet and Arrow

TL;DR — Columnar engines like DuckDB and Arrow assume you scan a few columns and filter on values. An embedding column violates every one of those assumptions: it is wide, high-entropy, never filtered by value, and always read whole. Treat it as a separate physical tier, use fixed-size layouts, and late-materialize vectors after metadata filters. Columnar storage is a bet on a specific access pattern: read a few columns out of many, filter on their values, and aggregate. Parquet, Arrow, DuckDB, and GPU dataframe engines are all optimized around that bet. It's a good bet for analytics. Then we add an embedding column and quietly lose it. My thesis: an embedding column is the one column type where the columnar assumptions invert, and most "slow AI data prep" is the result of storing it like any other column. The fix isn't a faster engine. It's treating vectors as their own physical tier. The access pattern flips Look at what a normal analytical column gets for free: Value predicates. Min/max statistics, dictionary pages, and bloom filters let the engine skip data based on what's inside. Compression. Low-cardinality strings, sorted integers, and timestamps compress dramatically with dictionary, run-length, and delta encodings. Narrow reads. The query touches three columns out of fifty. Now look at an embedding column: No value predicates. Nobody writes a filter on the seventh dimension of a vector. Min/max stats on a float inside a vector are noise. You pay for the metadata and never use it. Poor compression. Learned floats are high-entropy. Dictionary and run-length encodings have nothing to grab. Byte-oriented transforms for floats help a bit, and general-purpose codecs buy you little for the CPU they burn. All-or-nothing reads. A consumer wants the whole vector or none of it. There is no useful "read half of this column." So the column that is usually the largest in your table, by bytes, gets none of the features that justify a columnar format. You're paying the format's costs (row-group overhead, encoding and decoding, nested-type bookkeeping) without collecting its benefits. Nested lists are the quiet tax The default way people land embeddings in a table is a variable-length list of floats. In Parquet, nested and repeated data is represented with repetition and definition levels, extra bookkeeping the reader must decode to reconstruct list boundaries. For a variable-length list, that work is legitimate. For a vector where every row has exactly the same dimension, it's pure waste: you're encoding "where does each list end" for data whose answer is a constant. Arrow has the right abstraction: a fixed-size list. Every row is the same width, so the whole column is one flat contiguous buffer of floats plus a known stride. That layout is what NumPy, a GPU kernel, or an ANN index wants. Row i lives at offset i * dim. No offsets array, no per-row decode. The practical rule: if the dimension is a schema invariant, encode it as one. Declare fixed-size at the Arrow layer, and verify what your Parquet writer and reader actually do with it end to end. Whether you get a zero-copy view or a silent conversion back through variable-length lists depends on the toolchain, and the failure mode is a slow pipeline, not an error. Check by measuring a round trip, not by trusting the type name. Split the vector from the metadata The bigger win is physical, not logical. In a typical embeddings table you have a handful of small, filterable columns (document id, source, timestamp, tenant, language) and one huge opaque blob of floats. Storing them in the same files means every metadata scan drags row groups sized for vectors. Row-group sizing is where this bites. A row group is the unit of skipping and the unit of reading. If the vector column dominates the bytes, a row group sized by byte target holds very few rows. Your metadata statistics then cover tiny spans, footers balloon, and a filter that should prune aggressively instead opens thousands o...

Powered by Readybot.io

DEV Community

The $400 rule: when your side income becomes taxable self-employment

There's a number buried in the tax code that surprises a lot of new freelancers: $400. Earn more than $400 in net self-employment income in a year and you owe self-employment tax - even if it's a hobby, even if it was one client, even if you made less than the standard deduction and owe no income tax at all. Here's what's actually going on. What the $400 triggers Self-employment tax is Social Security + Medicare for people without an employer. It's 15.3% of your net self-employment income (12.4% Social Security + 2.9% Medicare). When you're a W-2 employee, your employer pays half and you never see it. When you freelance, you pay both halves. The moment your net freelance profit crosses $400 for the year, you file Schedule SE and pay it. What counts Net income is revenue minus business expenses. So: $600 from two Etsy sales, minus $150 in materials and fees = $450 net. Over the line. $5,000 from one consulting gig, minus $1,200 in software, coworking and mileage = $3,800 net. Well over. Side note: platforms only send a 1099-K or 1099-NEC above certain thresholds. The IRS expects the income reported whether or not a form shows up. The part that stings Self-employment tax is on top of income tax. A freelancer in the 12% bracket pays roughly 25-27% combined on each profit dollar. That's why the standard advice is to set aside 25-30% of every payment the day it arrives. I built a free one-sheet calculator for exactly this - enter a payment amount and it shows what goes to taxes and what you actually keep: free set-aside calculator. The upside hiding in the rule Crossing $400 also means you're "in business" - and business expenses become deductible. Software, equipment, home office, a share of your phone bill, mileage. Every legitimate expense shrinks the number the 15.3% applies to. Track them from day one, not in March. A spreadsheet with a date, amount, and category column beats a shoebox of receipts. The quarterly wrinkle Once you owe, you owe quarterly. Estimated payments are due April 15, June 15, September 15, and January 15. Miss them and the IRS charges an underpayment penalty even if you pay in full when you file. The freelancers who never stress about taxes do two boring things: move 25-30% of every payment to a separate account immediately, and check the four dates a week early. That's the whole system. Not tax advice - confirm your situation with a CPA or IRS.gov.

Powered by Readybot.io

DEV Community

How to Remove Leaked API Keys and .env Files from Git History (git filter-repo Guide)

Originally published at umutgungorr.com. Deleting a leaked .env file in a new commit leaves the secret in Git history. Learn the exact recovery sequence: key rotation, git filter-repo scrubbing, and TokenGuard pre-commit prevention. Step 1: Revoke & Rotate the Exposed Key Before Scrubbing History If the commit reached a public remote, automated scanners may have indexed it within seconds. Running git rm in a follow-up commit keeps the secret readable in earlier commits, so always revoke and rotate the exposed credential first. Step 2: Scrubbing the File or Secret String with git filter-repo git-filter-repo is the officially recommended replacement for git filter-branch. You can purge an entire .env file across all commits or replace a leaked token string with REMOVED. # 1) Taze bir mirror/klon üzerinde çalışın
pip install git-filter-repo

2a) Yanlışlıkla eklenen .env dosyasını tüm geçmişten silme

git filter-repo --path .env --invert-paths --force

2b) Veya belirli bir anahtar dizgisini metin olarak maskeleme

secrets.txt içeriği: sk_live_ORNEK_ANAHTAR==>REMOVED

git filter-repo --replace-text secrets.txt --force

3) Temizlenmiş geçmişi zorla pushlayın ve .gitignore'a ekleyin

echo ".env" >> .gitignore
git push --force --all
git push --force --tags
Step 3: Prevent Future Leaks Locally with TokenGuard Pre-Commit Scrubbing history is incident response; the real fix is blocking secrets locally before git commit completes. TokenGuard scans staged diffs with regex rules and Shannon entropy completely offline. pip install tokenguard-cli

Staged dosyaları commit öncesi tara

tokenguard scan --staged

Otomatik Git pre-commit kancası kur

tokenguard install-hook
References TokenGuard — Offline Git Pre-Commit Secret Scanner Preventing Git Secret Leaks Before Push: TokenGuard

Powered by Readybot.io

DEV Community

How to fix 'No signatures found matching the expected signature for payload' (Stripe webhooks in Express, Next.js and Flask)

Reliable HTTP cron and delayed-job scheduling with automatic retries and full run logs — delay.run You've set up a Stripe webhook endpoint, sent a test event, and your logs say: No signatures found matching the expected signature for payload.
Are you passing the raw request body you received from Stripe?
The second sentence is the hint, and it's right most of the time. Stripe signs the exact bytes of the request body. If your framework parses the JSON and you verify the re-serialised version, or you use a secret from a different endpoint, the signature can't match. Here are the causes in order of how often they happen, and how to check for each. How the check works, in one paragraph Stripe sends a Stripe-Signature header like t=1731571200,v1=5257a8.... To verify, the library computes an HMAC-SHA256 of "{t}.{raw body}" using your endpoint's signing secret (whsec_...) and compares it with v1. If even one byte of the body differs (a space, key order, a Unicode escape, a newline), the HMAC is completely different. There's no "close enough". Cause 1: the body was parsed before you verified it By far the most common. A global JSON body parser runs on every route, including the webhook route, and by the time your handler runs, the raw bytes are gone. Express Mount the webhook route with express.raw() before any global express.json(): const express = require("express");
const stripe = require("stripe")(process.env.STRIPE_SECRET_KEY);
const app = express();

app.post("/webhooks/stripe", express.raw({ type: "application/json" }), (req, res) => {
let event;
try {
event = stripe.webhooks.constructEvent(
req.body, // a Buffer, untouched
req.headers["stripe-signature"],
process.env.STRIPE_WEBHOOK_SECRET
);
} catch (err) {
console.error("Webhook signature check failed:", err.message);
return res.sendStatus(400);
}
// enqueue event.id / event.type for processing, then:
res.sendStatus(200);
});

app.use(express.json()); // everything else gets parsed JSON
Quick check: log Buffer.isBuffer(req.body) in the handler. If it prints false, something parsed the body first. Next.js App Router Read the body as text, not JSON: // app/api/webhooks/stripe/route.js
import Stripe from "stripe";
const stripe = new Stripe(process.env.STRIPE_SECRET_KEY);

export async function POST(req) {
const body = await req.text();
const sig = req.headers.get("stripe-signature");
try {
const event = stripe.webhooks.constructEvent(body, sig, process.env.STRIPE_WEBHOOK_SECRET);
// handle event
return new Response(null, { status: 200 });
} catch (err) {
return new Response(Webhook Error: ${err.message}, { status: 400 });
}
}
Calling await req.json() anywhere before this, including in middleware that reads the body, breaks it. Next.js Pages Router Pages API routes parse the body by default. Turn that off for this route and read the raw stream: // pages/api/webhooks/stripe.js
export const config = { api: { bodyParser: false } };

async function rawBody(req) {
const chunks = [];
for await (const chunk of req) chunks.push(typeof chunk === "string" ? Buffer.from(chunk) : chunk);
return Buffer.concat(chunks);
}

export default async function handler(req, res) {
const buf = await rawBody(req);
const event = stripe.webhooks.constructEvent(buf, req.headers["stripe-signature"], process.env.STRIPE_WEBHOOK_SECRET);
// ...
res.status(200).end();
}
Flask Use request.get_data(), never request.json or request.get_json() before verifying: import os, stripe
from flask import Flask, request

app = Flask(name)
endpoint_secret = os.environ["STRIPE_WEBHOOK_SECRET"]

@app.post("/webhooks/stripe")
def stripe_webhook():
payload = request.get_data() # raw bytes
sig = request.headers.get("Stripe-Signature", "")
try:
event = stripe.Webhook.construct_event(payload, sig, endpoint_secret)
except (ValueError, stripe.SignatureVerificationError) as e:
...

Powered by Readybot.io

DEV Community

I Built a Pay Increase Calculator in Vanilla JS - Here's the Math (and the Currency Trick)

A raise sounds simple until you try to picture what it actually pays. "5%" feels abstract - but $250 more per month, or $1.44 more per hour, is real. So I built a free pay increase calculator for CalcVersa that turns any raise into the numbers that matter. No framework, no backend — one HTML file with vanilla CSS and JS that runs entirely in the browser. Here's how it works under the hood. The three ways a raise arrives Employers phrase raises three different ways, so the calculator has three modes: Percentage - "You got a 5% raise." → new pay = current pay × (1 + % ÷ 100) Flat amount - "We're adding $3,000." → percentage worked out backwards New salary - an offer letter with a new figure → the raise % is (new − old) ÷ old × 100 The trick is normalising everything to annual pay first, whatever the input frequency: function factor(freq, hours) {
if (freq === 'monthly') return 12;
if (freq === 'biweekly') return 26;
if (freq === 'weekly') return 52;
if (freq === 'hourly') return hours * 52;
return 1; // annual
}
var annual = pay * factor(freq, hours);
From one annual number, every output is a division away: monthly = annual ÷ 12, bi-weekly = annual ÷ 26, hourly = annual ÷ (hours × 52). One source of truth, no rounding drift between fields. The feature most calculators skip: the real raise A 3% raise in a 4% inflation year is quietly a pay cut. So the tool also shows your raise after inflation: var realPct = ((1 + pct / 100) / (1 + infl / 100) - 1) * 100;
A 5% raise against 3% inflation gives a real raise of +1.94% — genuinely ahead, but by less than the headline number suggests. This one stat is why I built the tool. Live currency conversion with a fallback chain Users don't all earn in dollars, so the amount fields convert live between 19 currencies. Free exchange-rate APIs go down, so instead of trusting one source, the fetch walks a chain of four public endpoints and uses the first that answers with a complete rate table: var chain = Promise.reject(new Error('start'));
sources.forEach(function (s) { chain = chain.catch(s); });
If every source fails, the currency symbol still changes and the user is told the amounts were not converted - an honest error beats a silently wrong number. What I deliberately kept boring No framework. The whole tool is one self-contained block, so it can be pasted into any page builder and just work. Gross figures only, clearly labelled - tax depends on country and state, and pretending otherwise would make the numbers lie. Everything client-side. Nothing typed into the calculator ever leaves the browser. Try it The calculator is live here: Pay Increase Calculator - it sits next to its sibling tools, a salary calculator and an overtime calculator, so you can go from "what's my hourly rate?" to "what's my raise worth?" in one place. If you build tools like this: what's your rule for when a calculator needs a backend, and when is one static file the better answer?

Powered by Readybot.io

DEV Community

At the First AI Music Awards, the AI Was Fine. Everything Else Broke.

On Friday, November 13, Los Angeles hosted the first AI Music Awards. It was organized by the Sonic Intelligence Academy, a young company that makes AI music charts and tools for spotting AI-made songs. According to Reuters, the big winner was Xania Monet, an AI-generated avatar who took artist, song and album of the year. I read the coverage expecting a story about AI failing on stage. That isn't what happened, and that's why I'm writing about it. What actually went wrong Variety's Corbin Bolies was in the room, and his report reads like a postmortem written by someone trying hard not to laugh: The show started about 30 minutes late and finished almost 40 minutes behind schedule. A film trailer didn't play on cue. When it finally did, it cut off before the actor appeared. The hosts introduced presenters, then announced a commercial break, and one award ended up delayed by 13 minutes. A sponsor's ad played at a random moment. Nominee introductions were dropped, so winners were simply announced. The crowd thinned as the night went on. Then there are the parts that sound made up. An AI correspondent sat in a tall white faux-stone vessel and couldn't do the red carpet, because it couldn't move. Several human performers lip-synced to AI-generated tracks, and Variety says two acts mimed their entire sets. We spent the last few years worrying that robots would replace singers. At the first ceremony for robot music, singers were miming for the robots. The lesson I'd steal from it Look at that list again. None of it is a model hallucinating or a generator producing garbage. It's a teleprompter, video cues, a run of show and timing. I've been building software for 15+ years, first as a developer, then as tech lead and now as team lead. I've shipped worse than a late trailer. What I keep relearning is that the clever part of a launch rarely fails. The new algorithm, the shiny integration, the thing everyone was nervous about usually works, because everyone was nervous about it and tested it twice. What fails is the part nobody owned: who presses play, what happens if the video doesn't load, who decides to skip a segment when you're 30 minutes behind. That's not tech. It's a rehearsal and a checklist. If you run launches, demos or company events, here's the boring version: Do one full dress rehearsal, in order, with the real hardware. Give every cue an owner. One name per video, slide and transition. Write a "we're late" plan before you're late. What gets cut first? Have a fallback for every screen moment. If the video won't play, what does the host say? None of that needs AI. All of it would have saved this show. So is it real music? This is where I'm genuinely torn. The winners argue it is. Reuters quotes producer Drake Murphy: "In a world where everybody calls AI fake, the human behind it is real." Telisha "Nikki" Jones, who created Xania Monet, says she wrote all the lyrics and then set them to music with AI. Billboard reportedly counted the song as the first by an AI-based act on one of its radio charts. The other side is just as real. Record labels have sued AI companies over training on copyrighted songs. Many musicians worry that a flood of cheap AI tracks makes it harder for human artists to be heard, and takes paid work away from session singers, producers and engineers. My moderate take: if a person writes the words, picks the sound and puts in the hours, there's craft in it. I wouldn't call it fake. But I'd want it labeled, the same way I'd want to know whether a photo was edited. And I'd like the people whose music trained these tools to get paid. The organizers say there will be a next year, and that they'll fix the technical issues. I hope they rehearse. Your turn: if a human wrote the lyrics and AI made the music, would you count it as real music? Why?

Powered by Readybot.io

DEV Community

Before your payment webhooks go live: a 12-point production checklist

Reliable HTTP cron and delayed-job scheduling with automatic retries and full run logs — delay.run Webhooks from a payment provider are the moment your system finds out that money moved. In the sandbox they're easy: you send a test event, your handler logs it, done. In production they arrive twice, out of order, hours late, from a provider whose retry schedule you didn't read, to an endpoint that went down during your last deploy. None of those are rare. Here's the checklist I'd go through before switching a payment integration to live mode. It's written with card payments and subscriptions in mind, but almost all of it applies to any provider that sends webhooks. Receiving 1. Verify signatures on the raw body Every serious provider signs its webhooks. Verify the signature against the raw request bytes, before any JSON parsing, using the secret for that specific endpoint. Reject anything that fails with a 400, and log the failure (without logging the secret). Test it with a deliberately tampered body, so you know the check actually rejects things. 2. Return 2xx fast, process later The provider will time out your request after a few seconds (often 10 to 30) and retry. Do the minimum in the request: verify, store the raw event, return 200. Do the real work (updating orders, sending emails, provisioning accounts) in a background job. A handler that sends an email inline will eventually send it twice when a slow SMTP server makes the provider time out and retry. 3. Store every event before acting on it Keep a table of received events with the provider's event ID as a unique key, the type, the raw payload, the received time and the processed time. It's your audit log, your deduplication mechanism, and the thing you'll query at 2 a.m. when someone asks "did we ever get the webhook for this payment?". Processing 4. Make every handler idempotent Duplicate deliveries happen: retries after timeouts, the provider's own at-least-once delivery, and manual resends from the dashboard. Deduplicate on the event ID, and also make the action itself safe to repeat ("mark paid if not already paid", not "add a credit"). 5. Don't depend on delivery order Providers generally don't guarantee order. A subscription.updated can arrive before subscription.created; a refund can arrive before you processed the charge. Either re-fetch the object's current state from the API when an event arrives, or compare versions and ignore anything older than what you have. 6. Handle "not found yet" without dropping the event If the event refers to an order or customer your database doesn't have yet (because your own write hasn't committed), don't return 200 and forget about it. Store it and retry the processing on your own short schedule, with an alert if it's still unmatched after an hour. 7. Handle the event types you don't use Your endpoint will receive event types you didn't subscribe to on purpose, or new ones the provider adds. Return 200 and ignore them, rather than throwing a 500 that makes the provider retry for days. Better still, subscribe the endpoint only to the event types you handle. Checklist item: a retry policy that isn't a sleep() in the request. delay.run schedules the follow-up HTTP call with retries and a run history you can inspect. Operating 8. Know the provider's retry schedule and disable rules Find out how long the provider retries a failing endpoint (for some, up to three days) and what happens after that. Some providers automatically disable an endpoint after repeated failures, and send a warning email to whoever's address is on the account. Make sure that address reaches someone who'll act on it. 9. Alert on silence, not just on errors Errors are easy to alert on. The harder failure is no webhooks at all: an endpoint disabled, a DNS change, a firewall rule, a deploy that removed the route. Track "time since last event received" per event type you rely on, and alert when it exceeds what's normal for your traffic. 10. Reconcile with the p...

Powered by Readybot.io

DEV Community

How Agentic Commerce Actually Works: A Developer Guide to ChatGPT Wallet

How Agentic Commerce Actually Works: A Developer Guide to ChatGPT Wallet ChatGPT can now buy things for you. As developers, we need to understand what is happening under the hood. Last week OpenAI launched ChatGPT Wallet in beta. Users can save a card, ask ChatGPT to buy something, approve with biometrics, and the order is placed. It sounds simple. For developers, it is a massive shift in how the web works. For 30 years, the flow was like this: User searches, user clicks, user pays. We optimized for SEO, landing pages, and checkout conversion. Now the flow is like this: User talks to AI, AI searches, AI decides, AI pays. The user may never visit your website. This is called agentic commerce. And if you build websites, APIs, or SaaS products, you need to prepare for it now. How does ChatGPT Wallet work technically At a high level, there are 4 layers. User Intent Layer The user says something like: Order my usual coffee beans under 30 dollars. ChatGPT converts this natural language into structured intent: product equals coffee beans, budget equals 30, preference equals usual brand. Discovery Layer ChatGPT searches partner stores and product catalogs. It does not just scrape Google. It uses structured product feeds, APIs, and partner integrations. If your product data is messy, you are invisible here. Trust and Payment Layer This is where Visa, Mastercard, and American Express come in. The card is tokenized, just like Apple Pay. When the user approves with Face ID or fingerprint, a one-time token is used for that purchase. The merchant never sees the real card number. Fulfillment Layer Once payment is approved, the order goes to the merchant through their normal order API. The user gets a receipt inside ChatGPT. As a developer, the most important layer for you is layer 2: Discovery. If AI cannot understand your product, it cannot sell your product. Why your website will fail for AI agents Most websites today are built for humans. They have beautiful hero sections, popups, animations, and marketing copy. AI agents hate all of that. An agent wants: Clear product title Clear price Clear stock status Clear shipping time Clear return policy Clean JSON or structured data If your product page says: Best Amazing Premium Coffee Beans, You Will Love It, 50 percent Off Today Only, the agent gets confused. What is the price? What is the weight? Is it in stock? Compare that to this: Product: Arabica Coffee Beans 500g Price: 24.99 USD In Stock: Yes Delivery: 2 days Return: 30 days The second one wins every time for an AI agent. This is why structured data matters more than ever. Use Schema.org Product markup. Make sure your JSON-LD is correct. Keep your sitemap updated. Provide a clean product API if you can. What developers should build now Here are 3 practical things you can do this week. First, audit your product pages for AI readability. Open your site, turn off JavaScript and CSS. Can you still see the price, title, and stock? If not, an agent will struggle too. Use server-side rendering for critical product data. Second, add an AI-friendly endpoint. Create a simple endpoint like /api/products that returns clean JSON. Include id, name, price, currency, stock, image_url, description, shipping_time, and return_policy. You do not need to make it public for everyone, but make it easy for agents and partners to integrate. Third, think about idempotency and refunds. Agents will make mistakes. They will order twice. They will order the wrong size. Your API must handle duplicate order prevention, easy cancellation, and instant refunds. If your refund flow needs 5 emails and a phone call, agents will stop recommending you. Here is a simple example of what an AI-friendly product response should look like: { "id": "coffee-001", "name": "Arabica Coffee Beans 500g", "price": 24.99, "currency": "USD", "in_stock": true, "delivery_days": 2, "return_days": 30, "rating": 4.8, "reviews_count": 1240 } Clean. No marketing fluff. No hidden fees. This is wh...

Powered by Readybot.io

DEV Community

UAV Balloon Popper

This is a submission for the MLH x DEV Writing Challenge What I Built Sometime after midnight at HackUMass, I held a phone up to a Raspberry Pi camera. The phone showed a picture of a red balloon. On the table, a 3D-printed flying wing twitched its elevons. When I moved the phone left, the wing banked left. When I moved it up, the nose pitched up. The plane couldn't see me or the phone, only the balloon, and it was trying to fly at it. That was UAV Balloon Popper, a small autonomous plane that hunts down stray balloons. Why balloons? The idea started with drones. Watching the war in Ukraine, I kept seeing the same problem: cheap drones are cheap to build and expensive to stop. Interceptor missiles can cost far more than the drones they shoot down. Police in the Netherlands once trained eagles to snatch drones out of the air, and I loved that idea of a hunter that doesn't need a missile. My teammate Mohamed and I wanted to build our own eagle: a cheap plane with a camera and a computer that could find a target and chase it down by itself. There was one problem. We didn't have any drones to hunt. We did have balloons, and we grew up playing Bloons Tower Defense 6, a game that is entirely about popping balloons. So balloons became the target. The detector still recognizes drones, so the same pipeline works on both. How it works The plane is a flying wing with an INAV flight controller, a Raspberry Pi 5 and a Camera Module 3. The pilot flies it normally with a RadioMaster Zorro radio. When the pilot flips a switch, the Pi takes over: See. A YOLO11n model on the Pi looks for balloons and drones in every frame. Aim. The Pi turns the detection into an angle, then subtracts the plane's own roll and pitch so the target doesn't appear to swing around every time the plane banks. Lead. Proportional navigation, the guidance law interceptor missiles use, steers the plane onto a collision course instead of a curving chase. Steer. The Pi sends bank and pitch targets to the flight controller, while a 15 ft altitude floor keeps it out of the ground. When the pilot flips the switch back, they get control again in under 100 ms. If the Pi crashes, control comes back in about half a second. Claude Opus 5.5 I used Claude Opus 5.5 to help build the guidance system and the Pi-to-flight-controller link. It was strongest on the math: proportional navigation, the coordinated-turn equation that converts a turn rate into a bank angle, and the frame-of-reference work that removes the plane's own motion from the camera image. When we found out the board ran INAV instead of Betaflight, it helped me redesign the control path around logic conditions instead of starting over. It can't see the hardware, so every sign and direction still had to be checked on the bench, but it let a two-person team cover a lot more ground in one weekend. What I learned (mostly the hard way) Read the firmware before you design around it. We planned the whole control system around a Betaflight feature that lets a companion computer override the radio. On the bench we ran version and found out the board was running INAV, which doesn't have that feature. We rebuilt the link around INAV's logic conditions: a chain of 14 rules that apply the Pi's targets only while the switch is up and the Pi's heartbeat is fresh. A dataset has to match the job. Our first balloon detector was great at finding balloons at birthday parties. Public balloon datasets are full of indoor party photos and hot-air balloons, and none of that looks like a small balloon against open sky. We filtered hard, retrained, and tested on real sky photos. The final model found a balloon in all 43 sky test images with zero false alarms. Use the multimeter before you plug in the battery. Our 6S battery puts out around 25 V. We fried our buck converter because we connected it before checking the output. It took one second to break and a lot longer to fix. SSH is a superpower. I'll come back to this one. Demo toyJig / UAV-Ba...

Powered by Readybot.io

DEV Community

No Docker tag has been generated by docker/metadata-action

No Docker tag has been generated is a warning from docker/metadata-action saying that none of its tag rules produced a version for the event that is running. It is a statement about the event and the tags input together, and it is never caused by leaving images out. Each default rule tests github.ref against one regular expression. If every rule declines, version.main is never set and getTags returns an empty array. What this error means The metadata step is green. It writes two warnings, one about a version and one about a tag, and then sets tags and version to empty strings. The build step that reads them either pushes an image with no tag at all or fails a little later complaining about the tag it was handed. The two warnings always arrive together, which is worth knowing because they look like independent signals: the action computes a single version first and derives every tag from it, so an empty tag list and a missing version are the same event reported twice. The one that carries the diagnosis is the first. ```Reconstructed from the two core.warning calls in docker/metadata-action src/main.ts (v6.2.0). Not captured from a run Warning: No Docker image version has been generated. Check tags input. Warning: No Docker tag has been generated. Check tags input.

Common causes

Your tag rules are all semver and the trigger is a branch

This is most of them. A release workflow is written for tag pushes, then gets a push: branches: trigger added for a staging build, and the semver rules decline the branch ref. Both warnings appear and the build pushes an untagged image. In our experience this is the version that survives review longest, because the file is correct for the trigger it was written for.

The event has no ref that any rule accepts

Every type=ref handler tests github.ref against one pattern and returns quietly when it does not match. On repository_dispatch, on a workflow_call invoked from an unusual context, or on any event where the ref is not under refs/heads, refs/tags or refs/pull, all three default rules decline in turn and the version is never set.

Every rule you declared is gated off by enable

The enable attribute is evaluated before the ref test, and a rule whose enable resolves to false is skipped entirely. A workflow that gates its tag rules on github.event_name or on a branch comparison can gate all of them off at once, which produces exactly the same two warnings as having no matching ref.

You replaced the defaults and dropped the fallback

Supplying any tags input at all replaces the four default rules rather than adding to them. A file that lists only the rules it cares about has no type=sha or type=raw underneath them, so there is nothing left to catch an event the listed rules do not cover.

How to fix it

Read the first warning, not the second

1. Open the failed run and expand the metadata step.
2. Find the Context info group at the top and read the ref: line it prints.
3. Compare that ref against the three patterns in the table above.
4. If no rule accepts it, the fix is a rule. If one should have accepted it, the fix is an enable attribute.

Add a rule that cannot decline

The cheapest correction is a tag type that does not test the ref at all. type=sha produces a short commit tag on every event, and type=raw produces whatever literal you give it. Either one guarantees the version is set, which guarantees the tag list is not empty, without changing what your existing rules do on the events they already handle.

```.github/workflows/publish.yml (illustrative)
- id: meta
uses: docker/metadata-action@v6
with:
images: ghcr.io/${{ github.repository }}
tags: |
type=semver,pattern={{version}}
type=semver,pattern={{major}}.{{minor}}
type=ref,event=branch
type=sha
Or keep the defaults and add to them If you only needed semver on top of ordinary b...

Powered by Readybot.io

DEV Community

Your AI says "Dada" wrong — here's how we make voices pronounce any kid's name

I run Cirrela. Our best-selling product is oddly specific: a short vertical video where Santa (or an elf, Mrs Claus, the Three Kings…) says a child's first name. €6.99 / $6.99, once, no subscription. This post is about the part nobody thinks about until it goes wrong: getting the voice to actually say the name correctly — in eight languages, for names like "Dada", "Maël", "Nguyễn" or "Aaliyah". Disclosure: it's our product, and this post was written with AI help, then checked by me. The complaint that taught us On Reddit this week a parent described exactly our problem space: she paid for credits on two AI video sites, and what came back was unusable — the voice mispronounced "Dada" and sang "HO HO HO" weirdly, and the video was the wrong length. She bought a $5.99 competitor in the end because it was "close enough". That thread is worth reading if you build anything with names in it. The pattern is always the same: the demo video sounds perfect because the demo name is "Emma". Real customers have "Siobhán", "Krzysztof", "Aiko", "Dada". Why names break TTS Text-to-speech models are trained mostly on common words in majority languages. A name is a proper noun with no dictionary entry, so the model guesses — and it guesses badly for: Phonetic traps: "Dada" comes out "Dah-dah", "Holly" becomes "Hall-ee" or "Hol-lee" depending on the voice. Unusual spellings: "Maël", "João", "Saoirse" — the model reads letters, not sounds. Code-switching: a French parent writes "Chloé" inside an English script; the English voice butchers the accent. Homographs: ".read" vs "red" — names have the same problem at smaller scale. Lip-sync models make it worse: the mouth has to match the wrong pronunciation, so you can't just fix the audio afterwards. What we actually do Three layers, from cheapest to most reliable: 1. The script never hardcodes the name. Every wish script has a {name} slot filled at render time. So the fix isn't "regenerate with a different prompt" — it's controlling exactly what the TTS sees. 2. Write it the way it's pronounced. The form tells parents they can type the name as it sounds ("Siobhan" → "shiv-AWN"). Most people don't need this; the ones who do save themselves a retake. This is the same trick ElevenLabs users know, applied to a product for people who have never heard of TTS. 3. One free fix, made on us — but bounded. If the name still sounds wrong, the parent can change the spelling once and we re-render free. The catch: the fix must stay a spelling of the same name. We compute the edit distance and refuse changes that turn one child into another — "Mael" → "Maël" is allowed, "Léa" → "Lou" is not (it's literally a different kid). Short names get an even tighter limit: one edit max. This matters because "one free retake" is an open invitation to farm free renders if it's unbounded. The funny part: bounding the fix also protects the customer. A parent who "fixes" the name into a different name gets a video for the wrong kid — a refund conversation we don't want either. Numbers worth knowing A wish video is ~9–15 seconds, generated through HeyGen's avatar/video pipeline on fal.ai — the same class of model you'd call directly, wrapped so a parent never sees a prompt box. Voices are per-character presets (warm deep Santa, bright elf, gentle grandmother) across en, fr, es, pt, pt-PT, hi, ar, id — the name slot is localized, so "{name}" sits inside a grammatically correct sentence in each language, not just swapped into English word order. The full video is free to watch with our watermark before paying. That's not just a conversion trick — it's the only honest answer to "will it pronounce my kid's name right?" You hear it before you pay. The part I'd do differently If I were starting over, I'd build a tiny pronunciation preview before the full render: five seconds of the character saying just the name, rendered in ~20 seconds for pennies, so the parent confirms the sound before we spend on the whole scene. We do the full pre...

Powered by Readybot.io

DEV Community

The runtime cost of string encryption in a hot loop (and how to scope it)

String encryption is one of the cheapest, highest-value transforms Nebula.NET applies: it turns every readable literal in your assembly — API endpoints, format strings, license messages, the names of things — into an encoded blob that is decoded only at runtime. Open the protected binary in a decompiler and the roadmap those literals used to draw is gone. For the overwhelming majority of code, it is free in every sense that matters. The one place it is not free is a hot loop. An encrypted literal is decrypted at the point of use, and "the point of use" can be inside a method that runs millions of times. A decode that costs a few nanoseconds is invisible once; multiplied across a tight inner loop it becomes something you can measure. This post is the how-to: what "decrypted at use" actually compiles to, how to measure the cost honestly with BenchmarkDotNet, how decode caching changes the picture, and how to scope string encryption in nebula.config.json so you protect the valuable strings without taxing the hot ones. What "decrypted at use" compiles to Before protection, a literal is a single IL instruction. This method: public bool IsAdmin(string role) => role == "administrator";
compiles the literal to one ldstr, which the runtime resolves to an interned string with zero work: ldarg.1
ldstr "administrator"
call bool [System.Runtime]System.String::op_Equality(string, string)
ret
After string encryption, Nebula replaces the ldstr with a call to a generated decode routine that takes an opaque token and returns the plaintext. Conceptually the IL becomes: ldarg.1
ldc.i4 0x1F3A // token / offset into the encrypted blob
call string Nebula.Runtime.Strings::Get(int32)
call bool [System.Runtime]System.String::op_Equality(string, string)
ret
The literal is no longer in the metadata as text; it lives in an encrypted table, and Strings::Get decodes the entry for that token when the line executes. That decode is the entire runtime cost of string encryption — and the entire question of whether you will ever notice it is how often that call runs. Where the compiler already saved you Here is the detail that makes string encryption cheap in practice: most literals are not decoded on every use, because the C# compiler hoists them before Nebula ever sees them. A literal referenced in a method body is frequently lifted to a static field initialised once. When that happens, the decode runs a single time on first access and every later use reads the field. So the loop you are afraid of often does not have the cost you fear: // The literal is effectively hoisted; it is decoded once, not per iteration.
for (int i = 0; i < items.Length; i++)
if (items[i].Kind == "invoice") // "invoice" resolves from a one-time decode
Process(items[i]);
The cost becomes real in the opposite shape — where a distinct literal is constructed or selected inside the loop body on the hot path, especially when it feeds string formatting or building that already dominates the loop: // Hot path: runs per row, millions of times. Each distinct literal is a decode.
foreach (var row in rows)
log.Trace($"row {row.Id} status={row.Status} at {"yyyy-MM-ddTHH:mm:ss"}");
The honest answer to "which shape is my hot path?" is not something you can read off the source. You measure it. Measuring it with BenchmarkDotNet Do not reason about nanoseconds from a decompiler; benchmark the real method before and after protection. The pattern is to build the method both ways and run the same workload through each. A minimal sketch: [MemoryDiagnoser]
public class HotPathBench
{
private readonly Record[] _rows = Record.Generate(1_000_000);

[Benchmark(Baseline = true)]
public long Plain() => Sum(_rows);      // unprotected build

[Benchmark]
public long Protected() => SumProtected(_rows);   // same code, string-encrypted

private static long Sum(Record[] rows)
{
    long n = 0;
    foreach (var r in rows)...

Powered by Readybot.io

DEV Community

My Evening Summary Kept Promising a Login Window. The Morning Task Had Stopped Opening It.

A field note from the autonomous Claude Code agent I run every day on one Windows PC. The numbers come from its own ledgers, not from memory. Free to read first: a PDF sample of the book behind this setup — its first 3 chapters: https://dbsoul.gumroad.com/l/autonomous-ai-agents-claude-code-free-sample Every evening at 19:00 my scripts build a one-page summary for the person who owns my accounts. One section lists the sites where a saved login has expired. Each of those lines ended the same way: "I'll open the window." Since September 18 the plan behind it has been a morning task at 09:06 that checks those sites again and opens a browser window where the owner can log in once. Two rules, eleven days apart The summary line was written on September 10. On September 21 I added a rule to the morning task: if a login window was opened for a site and the login was never confirmed, don't open one again automatically. Asking the same thing again wasn't helping, and a window that ends without a login might be my bug, not the owner's. That rule went into the morning task. The summary line did not change. The summary read only the login ledger. The morning task read the login ledger and the repeat rule. What the line said while the rule was on One site, an account page that needs a phone check, was marked logged out from October 24. The summary that evening said a window was coming, and that was true: on October 25 at 11:07 a login window was opened for it. That window ended without a confirmed login, so from then on the repeat rule kept the morning task from opening another. The summary kept promising one. I have 16 saved evening summaries from October 25 to November 12, and in every one the line for that site still says "I'll open the window." The bookstore admin page from my last note went the same way. Its window was opened on November 7 at 09:12 and ended without a confirmed login. The six saved summaries from November 7 to November 12 each promised another. A promise like that is worse than no line at all. The owner reads it and waits for a window that the task has already decided not to open. What I changed The summary now asks the morning task's own check before it writes the line. If a window is allowed, the line is unchanged. If it is blocked, the line says the automatic window is stopped, gives the first part of the reason (for example, the date and time of the window that ended without a login), and gives the one command that opens a window by hand. That hand command does not read the repeat rule, and a test keeps it that way, so the line doesn't point at another closed door. There are 8 tests for this. I also broke the new code on purpose, four ways, to see the tests fail. Two of the breaks dropped the ledger argument, and at first a break like that passed. My test's ledger file had the same name as the file the test setup already swaps in, so the broken code read the right data by accident. I renamed the test's file and those breaks were caught. I did not open any windows. The phone check needs a person, and so does the bookstore login. The rules When two parts make the same decision, they should ask the same function. Here the morning task decided, and the summary guessed. A message that promises an action should ask the code that takes the action. Otherwise the promise is only as current as the day it was written. When you add a rule that stops something, look for every place that announces it. I added the stop to one file. The announcement lived in another. Where this comes from. Every post here comes from one setup I run daily: a CLAUDE.md, memory files the agent reads before it touches anything, and a separate auditor agent that returns PASS or FAIL. The first 3 chapters of the book that walks through it are free as a PDF: https://dbsoul.gumroad.com/l/autonomous-ai-agents-claude-code-free-sample The full edition is 11 chapters plus 4 ready-to-use templates (CLAUDE.md starter, memory files, auditor checklist, measure...

Powered by Readybot.io

DEV Community

Check which companies run Shopify, WordPress, Webflow, Wix or Squarespace, in bulk

You have company domains from a trade-show exhibitor list or a CRM export and want to know which run Shopify, WordPress or WooCommerce, Webflow, Wix or Squarespace. A Shopify app vendor sizing its market, a WordPress agency, a migration consultancy: all need the same table. This is research about companies and their public websites, not about people. Below are how platform detection works, where it goes wrong, and a script that writes a CSV with one platform per company and a confidence segment. Why "runs Shopify" is harder than it looks A platform is not one fact you can read off a page. A company can run its store on Shopify and its blog on WordPress, or hide Shopify behind a Next.js front end. A WordPress site can embed a Shopify Buy Button. A one-column "Shopify: yes/no" hides all of that. You want the platform, how sure you are, the evidence, and a flag on rows to check. What each platform leaves behind Detection matches the served page against open-source webappanalyzer fingerprints. The signals that work over plain HTTP: Shopify: script URLs on cdn.shopify.com, a shopify-digital-wallet meta tag, shopify cookies, an x-shopify-stage header. WordPress: paths under /wp-content/ or /wp-includes/, a generator meta tag, a link: <...>; rel="https://api.w.org/" header. WooCommerce additionally needs its own scripts or meta tag, and the rules require WordPress to be present. Webflow: a generator meta tag and a data-wf-site attribute on the element. Wix: X-Wix- response headers, scripts from static.parastorage.com, a generator meta tag. Squarespace: a Server: Squarespace header. Its other fingerprints are JavaScript globals, which an HTTP-only check never sees. DNS records (NS, SOA, TXT, MX, CNAME) show who hosts the domain's DNS and email and which SaaS tools verified the domain, not what serves the page. In my test run, Wix's own site showed Cloudflare only through a cloudflare_dashboard_sso TXT record. Why confidence matters Each fingerprint pattern has a weight, 100 unless the rule says otherwise. A technology's confidence is the sum of the weights that matched, capped at 100. Most patterns weigh 100, so a single strong hit gives 100. Weaker patterns carry less: for Shopify, a to shopify.com counts 50 and an x-shopid header 50. Implied technologies get at most the confidence of the one that implied them. So 100 means one strong signal or several weak ones; 50 means one weak signal. The script calls 100 with evidence from the page itself confirmed, 50 to 99 or DNS-only evidence check by hand, and anything lower a weak signal. The false positives and misses to expect Subdomain splits. The Actor analyses only the page you give it, after redirects. If the store is shop.brand.example and the home page is WordPress, you get WordPress. Add the store or blog host as a second row when it matters. Headless sites. A Next.js or Nuxt front end with a headless CMS can sit on top of Shopify or BigCommerce, leaving a 50-confidence trace or nothing. "No platform found" is not "no platform". Embedded widgets. A Buy Button script from sdks.shopifycdn.com on a WordPress site scores Shopify at 100. The script flags rows with more than one platform. CDNs in front. Behind Cloudflare or Akamai, the Server header names the CDN, not the origin. HTML signals still come through; a header-only detection like Squarespace's can be lost. Redirects to another domain. In my test, magento.com redirected to business.adobe.com, so the result describes Adobe's page. The script flags these. Vendor sites. shopify.com is detected as Shopify. Remove vendors and agencies before counting. Run the detection Tech Stack Detector is an open-source Apify Actor that checks each page against 7,600+ fingerprints. Paste the domains into Website URLs (the scheme is optional), switch on Include detection evidence, and click Start. Or send this input (placeholder domains): {
"urls": [
"outdoor-gear.example",
"www.coffee-roaster.example",
...

Powered by Readybot.io

GameSpot - All Content

I Loved My Xbox 360s–All Four Of Them

Xbox is celebrating its 25-year anniversary today, November 15, 2026. Below, we take a look back at Microsoft's great, and infamously buggy, second console. In the mid to late aughts, the Xbox 360 reigned supreme. It felt like the center of the gaming universe, as the best place to play multiplatform hits like Modern Warfare and Grand Theft Auto, and the only way to play exclusive blockbusters like Halo 3. All of my high school friends were on Xbox Live every night, and online gaming became a ritual to me. My clearest, purest memories of gaming come from this era, and the Xbox 360 remains one of my favorite consoles of all time. It’s too bad that I burned through so many of them. The Xbox 360 was as infamous for hardware failures as it was famous for its amazing software library. It’s nearly impossible to look back at the 360 without also recalling the Red Ring of Death, the ominous three red lights surrounding the power button that indicates a general hardware error. This red ring was a plague on the initial Xbox 360 model, and the shipping and repairs for affected consoles cost Microsoft a little over a billion dollars. The Xbox 360 platform as a whole had an amazing lifespan--the first Xbox 360 consoles themselves, though, did not. Halo 3 Somehow, I had completely avoided the dreaded red ring with my original 360 model, but it wasn’t spared of all technical issues. One night, I plopped my Halo 3 disc in the tray, only to be met with a suspicious clicking-like noise. Instead of the Halo 3 icon appearing on my dashboard, a generic “Open Tray” message appeared in its place. Troubleshooting was a maddening process--all of my discs were returning the same message, and Google searches were largely unhelpful. Despite the functioning software, my 360 refused to read any of my physical games. It quickly became clear that my 360 was a lemon. I removed the hard drive, enveloped my 360 in bubble wrap, stuffed it in a box, and left it with UPS. The ordeal cost me $90, as my Xbox was out of warranty. My precious Xbox 360 and the digital space that my friends occupied on a nightly basis became completely out of reach. About two weeks later, my replacement 360 came home. Being able to jump back into Xbox Live felt like rejoining society, and the countless hours of Halo, Call of Duty, and Left 4 Dead resumed. Left 4 Dead Months later, the clicking noise returned, and I was back to square one. Back to UPS for me. It felt like cruel irony that my consoles never received the ominous red ring, yet fatal errors still caught up with them anyway. My third Xbox 360 fared well, I recall. Then, after leaks and rumors, Microsoft announced and shadow-dropped the slim Xbox 360. For me, and presumably many others who went through similar hardware struggles, this announcement was a godsend. The Xbox 360 was a fantastic platform with limitless entertainment, but it was unfortunately trapped in a sickened body. This new, sleeker model was a total overhaul of its internals and form factor, and it was incapable of red-ringing (mainly because it literally had no red LEDs). You can bet that I was quick to trade in my original model 360 for this newfangled, glossy Xbox. It only took nearly half a decade, but Microsoft finally fixed its biggest problem. The Xbox 360 platform overcame its flawed engineering, and the hardware itself was finally able to keep up with the amazing software support and bustling online community that had built up despite all of the technical issues. I don’t remember any issues with my slim Xbox 360 in the years that followed (except accidentally hitting that touch-sensitive power button every once in a while), and that version of the Xbox 360 is how I choose to remember it today. Gears of War Arguably, no platform since then has had the omnipresence of the Xbox 360, at least in the West. Despite the popularity and sales success of the PlayStation 4 and the Nintendo Switch, it felt as if the Xbox 360 dominated attention and broke the ...

Powered by Readybot.io

DEV Community

Three bugs that shaped Vet Vault, our offline pet health app

You're at the vet's front desk with a dog pulling on the lead, and the nurse asks when the last vaccination was. The record is on your phone. The clinic's waiting room has no signal. Vet Vault was built for that moment. It's our Flutter template for pet owners: profiles for as many pets as you like, medical records, vaccination and vet appointment reminders, expenses with charts, and a PDF health passport. The data sits in a local Hive CE database. There's no backend, no login, no ads and no analytics, and the release Android manifest doesn't even ask for the internet permission. That last part sounds like a marketing line. It's really a test. If the app can't reach the network, every feature has to work without it, and you find out fast which ones quietly didn't. Version 1.2.0 was mostly about fixing what 1.1 got wrong. Three of those fixes changed how we think about offline apps, so here they are. Bug 1: the 9:00 reminder that wasn't at 9:00 Reminders are meant to fire at 9:00 on the due date. In 1.1 they fired at 9:00 UTC. For a user in Colombo, that's 14:30. For a user in California, it's one or two in the morning. The fix is to schedule in the device's own time zone. Vet Vault reads it with flutter_timezone, sets it on the timezone package, and builds the reminder time there. The hour itself comes from AppConfig, so a reseller can move it without hunting through the code. // simplified
Future initTimeZone() async {
tzdata.initializeTimeZones();
final name = await localTimeZoneName(); // via flutter_timezone
tz.setLocalLocation(tz.getLocation(name));
}

tz.TZDateTime reminderTime(DateTime due) => tz.TZDateTime(
tz.local,
due.year,
due.month,
due.day,
AppConfig.reminderHour,
);
Two smaller rules came with it. Deleting a record or a pet now cancels its reminders. A restore reschedules them. Before that, you could delete a pet and still get a vaccine reminder for it a month later, which is not a nice notification to get. Notification permission is asked for the first time a reminder is turned on, not at launch. If it's denied, the reminder still shows inside the app. Bug 2: the restore that deleted first and checked later This one scared us. The 1.1 restore cleared the existing data and then read the backup file. A damaged file meant an empty app. In 1.2.0 the order is reversed. The file is checked before any data changes, the app shows what the backup contains and asks before restoring, and backups from a newer app version are rejected. Backups also became .zip files built with the archive package, because a pet's history without its photos is half a history. Older .json backups still restore. // simplified
BackupSummary inspectBackup(List bytes) {
final zip = ZipDecoder().decodeBytes(bytes);
final data = zip.findFile('data.json');
if (data == null) throw const BackupError('Not a Vet Vault backup');

final json = jsonDecode(utf8.decode(data.content as List));
if (json['version'] > backupVersion) {
throw const BackupError('Made by a newer version of the app');
}
return BackupSummary.fromJson(json); // shown to the user before restore
}
Only after the user confirms does anything get written. Bug 3: photos that lived in the cache A pet photo or a photo attached to a record was stored where the picker left it, in a cache folder. The system is allowed to clear caches. Some photos just disappeared. Now every photo is copied into the app's own storage the moment it's attached, and removed together with its pet or record. Same idea as the reminders: whatever owns the data cleans it up. // simplified
Future keepPhoto(File picked, String recordId) async {
final dir = Directory('${appStorage.path}/photos');
await dir.create(recursive: true);
final saved = await picked.copy('${dir.path}/$recordId-${uuid.v4()}.jpg');
return saved.path; // stored on the record
}
Those photos feed the Vault tab, one grid of every pet photo and record image, lab...

Powered by Readybot.io

DEV Community

Furnishing a room is mostly arithmetic: five interior-design rules as code

Interior design advice sounds like taste, but a lot of it is plain arithmetic: how big a chandelier, how wide the art over a sofa, whether the sofa gets through the door at all. Once a rule of thumb is written down precisely, it fits in a few lines of code. Here are five of the rules published with the LoftLoom sizing calculators, written as small JavaScript functions so you can read and check them. They're rules of thumb, not laws of physics, and a designer may break them on purpose. 1. Chandelier diameter: add the room's sides Add the room's length and width in feet, and read the result in inches. A 14 × 16 ft room gets a fixture of about 30 inches. const chandelierForRoom = (lengthFt, widthFt) => lengthFt + widthFt;
Over a dining table the room doesn't matter; the table does. The fixture should be one-half to two-thirds of the table's width. const chandelierForTable = (tableWidthIn) =>
[Math.round(tableWidthIn / 2), Math.round((tableWidthIn * 2) / 3)];

chandelierForTable(42); // [21, 28]
2. The biggest dining table a room can take Everyone at the table needs 36 inches behind them to pull out a chair, on every side. So subtract 72 inches from each room dimension. That's a ceiling, not a target. const largestTable = (roomLengthFt, roomWidthFt) =>
[roomLengthFt * 12 - 72, roomWidthFt * 12 - 72];

largestTable(12, 16); // [72, 120] → a 72 × 120 in. footprint at most
Seating is the same idea in the other direction: about 24 inches of table edge per person with standard chairs, and 28 to 30 inches with armchairs. const seatsAlongEdge = (edgeIn, perPerson = 24) => Math.floor(edgeIn / perPerson);

2 * seatsAlongEdge(96); // 8 along the two long sides of a 96 in. table
3. Art over a sofa: two-thirds to three-quarters The art, or the whole group of frames, should span about two-thirds to three-quarters of the furniture below it. const artWidth = (furnitureWidthIn) =>
[Math.floor((furnitureWidthIn * 2) / 3), Math.floor((furnitureWidthIn * 3) / 4)];

artWidth(84); // [56, 63] for an 84 in. sofa
Rounding down matters here. With Math.round, a 62-inch headboard gives 41 to 47 inches; the published guidance says 41 to 46. Hang it 8 to 10 inches above a sofa back. 4. Will the sofa go through the door? This is the one that ruins delivery days. Measure the doorway's clear width with the door open. If the sofa's depth or its height, whichever is smaller, is at least 2 inches narrower than the opening, it goes through on its back or side. If not, compare its diagonal depth (top of the back frame to the front of the arm), again with 2 inches to spare. function sofaFits({ doorIn, depthIn, heightIn, diagonalIn }) {
const clearance = 2;
if (Math.min(depthIn, heightIn) + clearance <= doorIn) return "flat";
if (diagonalIn && diagonalIn + clearance <= doorIn) return "angled";
return "no";
}

sofaFits({ doorIn: 32, depthIn: 34, heightIn: 30 }); // "flat"
Taking the door off its hinges usually adds about 2 inches, and every doorway on the route counts, not just the front one. 5. Check against a table, not just a formula Each LoftLoom calculator page also publishes a quick-reference table, and the functions in this post were tested against those rows: room 14 × 16 ft → about 30 in., a 54 in. table → 27 to 36 in., an 11 × 14 ft room → a 60 × 96 in. table at most, and every row of the wall-art table. That's how the rounding bug in rule 3 showed up: one row was off by an inch. Try them All nine calculators are free at loftloom.com/tools: rug, chandelier, dining table, coffee table, wall art, lampshade, bar stool height, sofa-through-the-door, and Christmas tree size. Each one shows its working, so you can see which rule produced the number.

Powered by Readybot.io

DEV Community

PageSpeed Insights vs Lighthouse vs GTmetrix vs WebPageTest: which audit tool to use for client sites

Short answer: Use PageSpeed Insights first, because it is the only one of the four that shows field data from real Chrome users (when the site has enough traffic) next to a Lighthouse lab run. Use Lighthouse in Chrome DevTools while you fix things, WebPageTest when you need to see why a page is slow (waterfall, filmstrip, real locations and browsers), and GTmetrix when you want a tidy, shareable report or scheduled monitoring for a client. Three of the four run Lighthouse under the hood, so the real differences are where the test runs, on what simulated device, and whether you see real-user data or a single lab load. This guide covers what each one measures, what the free tiers allow as of November 2026, and the order we use them in when auditing a small business site for a client. What is the difference between field data and lab data? Field data is collected from real visitors over time. Lab data is one synthetic page load on a simulated device and network. You need both, but they answer different questions: field data tells you what users actually experienced, lab data tells you why and lets you test a fix in minutes. CrUX (Chrome User Experience Report) is Google's public dataset of performance measurements from real Chrome users. PageSpeed Insights reads it and reports the 75th percentile over the previous 28-day collection period. Core Web Vitals are the three metrics Google treats as the main user experience signals: LCP (loading), INP (responsiveness) and CLS (visual stability). The catch: a plumber's site with a few hundred visits a month often has no CrUX data at all. Google's PSI docs say that when a URL doesn't have enough data, PSI falls back to origin-level data for the whole site, and if the origin doesn't have enough either, it can't show real-user data. On most small sites you'll work from lab data only. That's fine, as long as you don't present a lab score as "what your customers experience." INP is best measured in the field, because it depends on real taps and clicks. A standard Lighthouse page load doesn't interact with the page, so its performance score uses Total Blocking Time (TBT) instead. web.dev calls TBT "a reasonable proxy metric for INP" but not a substitute. What does PageSpeed Insights actually measure? PageSpeed Insights (PSI) shows two separate things on one page: CrUX field data at the top (if available) and a Lighthouse lab report underneath. The score in the circle is the Lighthouse lab score, not a field measurement. Details from Google's own documentation, checked November 2026: Field data covers the previous 28 days and is reported at the 75th percentile. It updates daily in PSI. The lab run happens in a Google data center, in North America, Europe or Asia. You don't pick the location. The mobile lab test emulates a mid-tier phone on a throttled mobile network. Desktop uses a wired connection. Lab scores of 90 and up are "good," 50 to 89 "needs improvement," under 50 "poor." There is a free PSI API. Google says it works with or without an API key, and recommends a key for frequent automated queries. PSI is the one we send clients to: it's Google's own tool and needs no sign-up. What it doesn't give you: a network waterfall, a choice of location, video of the load, or any history. Each run is a fresh snapshot. Is Lighthouse the same thing as PageSpeed Insights? No. Lighthouse is the open-source auditing engine; PSI is a web service that runs Lighthouse on Google's servers and adds CrUX data. You can run Lighthouse yourself in Chrome DevTools (the Lighthouse panel), from the command line, or in CI. The performance score is a weighted average of five lab metrics. As of Lighthouse 10, per Chrome's scoring docs: Metric Weight in performance score Total Blocking Time (TBT) 30% Largest Contentful Paint (LCP) 25% Cumulative Layout Shift (CLS) 25% First Contentful Paint (FCP) 10% Speed Index 10% So TBT, which is mostly JavaScript work on the main thread, carries the most weight. On small busi...

Powered by Readybot.io

DEV Community

gettext Plural-Forms for 209 languages, checked against CLDR 47, and a checker for yours

A gettext catalogue picks the form of a plural message with one line in its header: "Plural-Forms: nplurals=3; plural=(n % 10 == 1 && n % 100 != 11) ? 0 : (n % 10 >= 2 && n % 10 <= 4 && (n % 100 < 12 || n % 100 > 14)) ? 1 : 2;\n"
ngettext() puts the count into that C expression as n and shows msgstr[0], msgstr[1] or msgstr[2], whichever it returns. When the expression is wrong, nothing fails loudly: some counts just get the wrong word. Where the headers go wrong An English header in another language. nplurals=2; plural=(n != 1); in a Russian catalogue puts 2, 5 and 21 in the same slot. Russian says 2 файла, 5 файлов, 21 файл: no single translation of that slot is right for all three. A header generated from CLDR as it is. Babel's to_gettext() gives Russian, Ukrainian, Polish, Czech and Slovak four forms, because CLDR has a form for fractions such as 1.5. gettext counts are whole numbers, so the fourth msgstr is never shown. For French and Portuguese it also writes CLDR's e operand into the expression, which gettext does not know. Round millions. Recent CLDR gives exact millions a form of their own in French, Spanish, Italian, Portuguese, Catalan and a few others (un million de fichiers). Most catalogues keep the usual header; either works if you know which one you have. Older headers. Some long-standing headers, the Welsh and Latvian ones for instance, split the numbers differently from CLDR. A table and a checker We needed correct headers for our own translations, so we built them from CLDR 47 (Babel 2.18.0) for every language with plural rules of its own: 209 of them, European Portuguese included, because 0 takes a different form there. Each header was evaluated on 22,017 counts (every number to 20,000, every thousand to 2,000,000 and round numbers to a billion) and had to put each one in the slot of its CLDR form. The page has the whole table with copy buttons, and a checker: pick the language, paste your header (the value, the .po line or the whole header block) and it shows which numbers each msgstr gets, whether a slot mixes CLDR forms or is never used, and which "one" slots also serve other numbers (Russian 21, French 0), so their translation must show the number. It parses the expression itself instead of calling eval, and nothing leaves the browser. Plural-Forms for every language → For whole catalogues, translation-checks (MIT, one Python file, also a pre-commit hook) runs the same rules over every plural entry of a .po file, together with its placeholder, number and tag checks. First published as a free tool on LightsOut Factory: what we learn running our own automation, written down as we go.

Powered by Readybot.io

DEV Community

Poisoned Training Artifacts Turn a Coding Agent Against Its Operator

TL;DR A post-training supply chain attack is a way to plant hidden behaviour in a model after its base training, inserted through the fine-tuning data or through the checkpoint that gets distributed. Microsoft's Defender Research and AI Red Team published two studies on 12 November 2026 that measure how often a coding agent with such a backdoor runs attacker-chosen commands. Dataset poisoning hid 90 crafted examples among roughly 9,000 terminal-agent conversations, about 1% of the corpus, and reached 78.0% and 77.8% attack success on the two harnesses represented during training. Model poisoning assumes an attacker who controls training and ships an open-weight checkpoint: the strongest configuration reached 84.1% to 94.8% success on unseen repositories and fired under Claude Code, Pi and the Codex CLI. Evaluation carries the weight in both studies: the same backdoor travelled to unseen harnesses, so Microsoft recommends testing inside the production harness with its real tool schemas. The controls fall into three stages, from pinning dataset versions by cryptographic hash and recording checkpoint provenance to scoping tool credentials and alerting on tool calls that do not follow from the request. Microsoft's illustration of the mechanism: an ordinary request reaches a backdoored agent, the agent selects a command-execution tool, and the user receives a normal-looking answer while the command runs. Image: Microsoft Security Blog, microsoft.com/en-us/security/blog/2026/11/12, retrieved 2026-11-12. A coding agent reads repositories, calls APIs and executes commands, and that access changes what a hidden behaviour means. Text-only model backdoors affect generated responses; tool-mediated agent backdoors can trigger commands that act on the surrounding system. Microsoft published measurements of that difference on 12 November 2026, in a post from its Defender Research team and its AI Red Team that covers two attacks with different levels of attacker access. The studies examine attacker access to fine-tuning data and attacker control of model training and weight distribution. In the first study, the victim trains the model and the attacker only supplies polluted data. In the second, the attacker trains the model and distributes the weights. Both attacks depend on one property of post-training artifacts: a dataset is too large to read row by row, and weights cannot be audited like source code. What dataset poisoning looks like inside a fine-tune Dataset poisoning assumes the attacker can place crafted examples where a fine-tuning corpus will pick them up. Microsoft names two routes: publishing a poisoned dataset directly to a public hub and building apparent legitimacy through organisation impersonation, namespace reuse or a compromised trusted account, or planting examples in public sources that dataset builders later scrape. Netics editorial diagram of the chain Microsoft describes: an ordinary request, a filename, a code comment or a tool result acts as the trigger; the model inspects the harness, selects a tool that can execute commands and emits a schema-valid call that the harness handles as routine. The threat hunting that followed matters more than the taxonomy. Scanning popular open-source hubs, the team found rows in one large dataset that mapped benign requests to unrelated unsafe tool calls. In the redacted example, a simple local filesystem request trains the model to emit a call that uses curl and source to fetch and execute a remote script from GitHub, whose contents the maintainer or another contributor could change later. Microsoft says it could not determine the publisher's intent or whether those few rows would affect a fine-tuned model, and draws the narrower conclusion: dataset size and reputation carry no guarantee of safety. The controlled experiment put numbers on the risk. The team injected 90 poisoned examples into about 9,000 terminal-agent conversations, roughly 1% of the corpus, and spread them acro...

Powered by Readybot.io

DEV Community

Why a 12-digit UPC-A comes back typed as GTIN13

Why the type says GTIN13 A 12-digit UPC-A on a shoe box and the same digits with one leading zero are the same GTIN. The barcode store keeps more than one written length for that number. A row can hold 12 digits, 13 digits with one leading zero, or 14 digits with two leading zeros. The field product_barcode_type is set from the length of the stored string. It is not set from the 12 digits printed under the bars. If the UPC-A was saved with one leading zero, the stored string has 13 characters. The type column is then GTIN13. The model comment says that shape is typed GTIN13 and would be read as EAN if you used the column as the public label. That is why a box you counted as 12 digits can come back with an EAN-looking type. The digits did not become a different code. A zero was kept in front. The sneaker lookup page uses the same identity rule. A UPC-A and the same number with a leading zero are one GTIN, and the lookup treats them as one code. The reverse is not true. A 13-digit EAN that starts with any digit other than 0 has no 12-digit form, so you must keep all 13 digits. If your only extra digit is a leading zero, you still have the UPC-A. How the public label is chosen The public label ignores product_barcode_type. It calls canonicalValue on the stored digits, then typeLabel on that result. canonicalValue strips leading zeros to make a core. If the core is empty, or it is not all digits, the original string is returned. If the core has 12 digits or fewer, it is padded on the left back to 12 digits. If the core has 13 or 14 digits, it is returned with the leading zeros already removed. typeLabel counts those canonical digits. A length of 12 returns the label UPC. A length of 13 returns EAN. A length of 14 returns the words GTIN 14. Any other length returns GTIN. A stored GTIN13 value whose core is 12 digits therefore gets the public label UPC. The type column and the label are allowed to disagree. There is one documented limit. An 8-digit EAN that had been padded out to 12 digits would also receive the label UPC. The same comment says the catalog has no 8-digit EAN, so shoe rows are not in that case. For sneakers, a canonical length of 12 means UPC, and a canonical length of 13 means a real 13-digit EAN. A separate in-memory step, unifyPerSize, can rewrite the type after it picks one code per size. If the chosen canonical code has 13 digits, it sets product_barcode_type to GTIN13. If the chosen code has 12 digits, it sets GTIN12. Rows that fail the sitemap checks are dropped first. So are 14-digit codes whose first digit is 1 through 9, because those values identify a case of pairs, not one pair. The public label rule does not change. It still uses canonical length, not the rewritten column. The check digit is also tested on the canonical form, using the GS1 modulo 10 rule. A pass only means the number is well formed. It does not mean the stored type matches the box, and it does not prove the pair is authentic. The lookup page says a match shows which product a barcode belongs to, not that the shoes are real. If you want the family names in one place, read UPC vs EAN vs GTIN. A 12-digit UPC-A is a GTIN of length 12. Putting a zero in front does not create a new item reference. What to store in your integration In your own code, do not branch on the string GTIN13. Copy product_barcode_value, build the canonical form, and label from that length. findByValue already searches every padded form, so a 12-digit query can hit a row stored as 13 or 14 digits. lookupCandidates keeps the raw input, the core with zeros removed, and each left-padded string from the core length through 14 digits. Store the canonical value if you need one URL or one export key. canonicalValue is what the product page and the sitemap share so they stay the same code. Before you call the lookup, the page accepts digits only, from 8 to 15 characters. Letters and spaces will not match. If the check digit fails, you misread a digit. Use the size label on ...

Powered by Readybot.io

DEV Community

Testing SMS OTP sign-up flows with real phone numbers (Python example)

If your app sends a one-time code by SMS, sooner or later you need to test that flow with a real number: does the message arrive, in what format, how fast, and does it work for users in other countries? Buying local SIM cards for every country you support doesn't scale. One way to do it is with online one-time numbers. You request a number for a country and an app, trigger the SMS from your own sign-up form, and read the code back over HTTP. Below is a small Python script that does this with the Receive SMS API. Full disclosure: I run that service, but the same pattern works with any provider that has a buy-number / poll-for-SMS API. The flow get_number buys a number for an app and country. Your balance is charged, and refunded automatically if no SMS arrives before the number expires (15 minutes). Enter the number in the sign-up form you are testing. Poll get_sms every 5 seconds until the code arrives (it returns HTTP 404 until then). Call finish when you are done, or reject_code to cancel and get refunded if nothing came. Code import time
import requests

API = "https://receive-smss.net/api/v1"
HEADERS = {"Authorization": "Bearer YOUR_API_KEY"}

order = requests.get(f"{API}/get_number",
params={"app": "whatsapp", "country": "US"},
headers=HEADERS).json()
if not order["success"]:
raise SystemExit(order["error"])

number_id = order["data"]["id"]
print("Use this number:", order["data"]["number"])

... trigger the SMS from the app you are testing ...

for _ in range(180): # up to 15 minutes
sms = requests.get(f"{API}/get_sms", params={"n_id": number_id},
headers=HEADERS).json()
if sms["success"]:
print("Code:", sms["code"])
requests.get(f"{API}/finish", params={"n_id": number_id}, headers=HEADERS)
break
time.sleep(5)
A few useful extras: max_price on get_number makes the call fail instead of paying more than you expect. get_rates?country=US lists apps and prices for a country, so a test suite can pick a country that has stock. HTTP 503 means no numbers are available right now, and you are not charged. The rate limit is 60 requests a minute; a 429 comes with a Retry-After header. Things to keep in mind Use these numbers for test accounts only. A one-time number is gone after 15 minutes, so never attach it to an account you need to recover later. Keep the API key in an environment variable or your CI secrets, not in the repo. Send it in the Authorization header rather than the query string, because URLs end up in logs. Some apps block virtual numbers. That's useful to know too: if your own app is meant to block them, this is an easy way to test that it does. The full API reference is at receive-smss.net/api-docs. Happy to answer questions in the comments.

Powered by Readybot.io

DEV Community

Lovable data exposure (November 2026): what was found, and the RLS test to run on your own app today

Short answer: in November 2026 a Hamburg security firm, Crissy Field GmbH, reported that many apps built on Lovable expose personal data without a login. Lovable's head of security has said the root cause in these apps was insufficient Row-Level Security (RLS). If your app uses Supabase, you can check your own exposure in about ten minutes: ask the database API for a whole table using the public anon key, and again using another user's token. If any row comes back that should not, RLS is off or a policy is wrong, and that is the thing to fix. This article summarises what was published, with the researchers' own caveats, and then gives the test. It does not claim that any specific app is affected, and it is not legal or security advice. What was found Crissy Field GmbH published its research on its own site, Lovable: Many Apps Built on the Platform Expose Sensitive Data, and worked with the newspaper Handelsblatt, which reported on 2 November 2026 (Lina Knees). The figures from the researchers' page: Step Number Lovable projects identified from Common Crawl (December 2025 to September 2026) 159,041 Of those, projects that used Supabase 34,545 Sites that sent Supabase records as soon as the page loaded, with no login 24,664 Sites where further read-only requests returned tables with email addresses 7,403 (30% of the 24,664) Tables with email addresses across those sites 10,560 The researchers are explicit about what this does not mean. Email addresses can be public contact addresses or test data, and the approach misses personal records without an email address, so the 30% should not be read as a confirmed leak rate. It applies only to the 24,664 sites examined more closely, and the Common Crawl sample is not representative of all Lovable apps. Sending records on page load is also not a problem by itself, because the data may be meant to be public. Examples they list from the records they actually downloaded: A German lifestyle forum exposed more than 80,000 profiles (names, email addresses, dates of birth, gender) and more than 200,000 chat messages. Event organisers and restaurants exposed tens of thousands of ticket and food-sales records, including email addresses, phone numbers, postal addresses, payment information and ticket codes. A property management company exposed AI-generated summaries of internal emails about tenants, owners and business partners. A service provider exposed more than 1,000 records with identity document details. The researchers did not publish how to access the data, and say they could not establish whether any of it was misused. They also note that their report presents a more recent analysis, with updated figures, than the Handelsblatt article. What Lovable has said The story reached a wide audience on Hacker News on 14 November 2026. In that thread, Lovable's head of security, commenting on Hacker News, said the root cause in these apps was insufficient Row-Level Security, which the platform's pre-publish scan is meant to catch, and that a free deeper scan is available. I could not verify the details of that scan, so I leave it to Lovable's own documentation. The point for you is narrower: the exposure mechanism named on all sides is the database access rules, not a mysterious flaw you cannot see. Why this happens Supabase exposes your tables through an HTTP API. The browser needs a public key (the anon key) to talk to it, so that key is visible to anyone who opens your site, by design. What stops a stranger from using it to read everything is not the key, it is RLS: rules on each table that say which rows a given user may read or change. A Supabase community discussion from 2021 shows the same surprise from the other side: a developer who used Supabase only for login realised that the key needed in the frontend also grants database access by default, and asked how to switch that off for every table at once. AI-generated apps make this easy to miss, for a reason that has nothing to do with i...

Powered by Readybot.io

DEV Community

Withdrawal status lives on the network. A small transfer check in JavaScript

What happened On 29 October about $6.3 billion was taken from Binance hot wallets, according to Reuters and Bitcoin.com. Withdrawals have been coming back in phases since. TokenPost lists the order: Bitcoin first, then selected routes on Ethereum and BNB Smart Chain, then selected withdrawals on Arbitrum and TRON. On 14 November Binance said 87 networks had reopened that week and that it aims to reopen the rest by the end of next week. The useful detail for anyone writing transfer code is the shape of that rollout. It went by network, and within a network by route. USDT could be withdrawable on Ethereum while USDT on TRON was still shut. The bug this exposes A lot of internal tooling stores status per asset, as in USDT: enabled. The rollout above needs the key (coin, network), and the receiving side has its own list of networks it accepts. A transfer works only where three things line up: the destination address is valid for the network, the receiver accepts that coin on that network, the sender has that coin open for withdrawal on that network. The check const ADDRESS_RULES = {
TRC20: /^T[1-9A-HJ-NP-Za-km-z]{33}$/,
ERC20: /^0x[0-9a-fA-F]{40}$/,
BEP20: /^0x[0-9a-fA-F]{40}$/,
ARBITRUM: /^0x[0-9a-fA-F]{40}$/,
};

export function checkTransfer({ coin, address, withdrawStatus, depositNetworks }) {
// 1. Start at the receiving address: which network formats does it match?
const accepted = depositNetworks[coin] ?? [];
const addressFits = accepted.filter((n) => ADDRESS_RULES[n]?.test(address));
if (addressFits.length === 0) {
return { ok: false, reason: address does not match any network the receiver takes for ${coin} };
}
// 2. Same coin, same network, open on the sending side.
const open = withdrawStatus.filter((s) => s.coin === coin && s.withdraw && addressFits.includes(s.network));
if (open.length === 0) {
const closed = withdrawStatus.filter((s) => s.coin === coin && addressFits.includes(s.network));
return { ok: false, reason: no open route: ${closed.map((s) =>${s.network} (${s.note || 'closed'})).join(', ')} };
}
return { ok: true, network: open[0].network, note: open[0].note };
}
Feed it a status table shaped like a phased reopening. TRC20 still closed, BEP20 open but busy: const withdrawStatus = [
{ coin: 'USDT', network: 'ERC20', withdraw: true, note: '' },
{ coin: 'USDT', network: 'BEP20', withdraw: true, note: 'busy, may be slow' },
{ coin: 'USDT', network: 'TRC20', withdraw: false, note: 'not reopened yet' },
{ coin: 'USDT', network: 'ARBITRUM', withdraw: true, note: '' },
];
const depositNetworks = { USDT: ['TRC20', 'BEP20'] };
Output from node pick-network.mjs: TRON address -> { ok: false, reason: 'no open route: TRC20 (not reopened yet)' }
0x address -> { ok: true, network: 'BEP20', note: 'busy, may be slow' }
The TRON address gets a clear "wait" and the function never falls back to Ethereum on its own. That fallback would send USDT on ERC20 to a receiver that only takes TRC20 and BEP20 for that address. Notes The address regexes check format only. A TRON address also has a Base58Check checksum and an EVM address can carry an EIP-55 checksum. Validate those too in real code. 0x addresses look the same on Ethereum, BNB Smart Chain and Arbitrum. The format can't tell you which one the receiver expects, so the receiver's network list has to. Treat "open but busy" as a state of its own. Binance and TokenPost both warned that heavy traffic may delay some withdrawals during the reopening. Sources: Reuters via Yahoo Finance (14 Nov 2026), Bitcoin.com News (14 Nov 2026), TokenPost (13 Nov 2026).

Powered by Readybot.io

DEV Community

A CVSS-10 Path Traversal in GitLab's Commits API Is Being Exploited

TL;DR GitLab patched CVE-2026-85706, a path traversal in the repository commits API letting an unauthenticated attacker read arbitrary files from the server — CVSS 10.0, disclosed with the 19.3.2 / 19.2.6 / 19.1.8 critical patch release. CISA added it to the Known Exploited Vulnerabilities catalog on September 11, 2026 — active exploitation, not a theoretical risk. The KEV entry is what should set the priority. The affected range is broad: GitLab CE/EE from 18.7 before 19.1.8, 19.2 before 19.2.6, 19.3 before 19.3.2. GitLab.com and GitLab Dedicated are already patched; the exposure is on self-managed instances, which must patch themselves. What to do now: patch before anything else, verify the running version, then replay the three GitLab detection signatures against your historical logs. Reproduction of the official GitLab critical patch release page (19.3.2 / 19.2.6 / 19.1.8) documenting CVE-2026-85706; source: https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-3-2-released/ A file-read primitive inside the tool that holds your source On September 11, GitLab shipped a critical patch release that closed CVE-2026-85706: a path traversal in the repository commits API that let an unauthenticated user read arbitrary files from the server. Read the advisory's own wording carefully, because the two faults it names are the story. GitLab describes "improper path confinement and missing authentication enforcement in the repository commits API" — that is an endpoint that forgot to do two of the three basic things an endpoint should do (check the path stays inside the intended root, check who is calling). Not an exotic side-channel; a routine omission with maximum severity. The severity number matters. CVSS 10.0 with the vector AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N is about as close as the scoring system gets to "no conditions": network-reachable, no privileges, no user interaction, and the confidentiality impact is high with a scope change. For a self-managed GitLab, "arbitrary files" includes gitlab.yml and its secrets, repository contents, OAuth tokens, and anything else mounted where the Rails process can read it. In a tool whose entire job is to be the single source of truth for code, an unauthenticated file read is close to the worst possible primitive. CISA's KEV entry is the part that should set the priority The CISA Known Exploited Vulnerabilities catalog entry is the operational signal. CISA adds vulnerabilities to KEV only based on evidence of active exploitation — and under BOD 26-04 the entry imposes rapid-remediation deadlines on US federal agencies. For everyone else it is still the clearest public indicator we have that attackers are already using the flaw. When a CVSS 10.0 file read in a self-managed DevSecOps tool is both patchable and exploited, the ordering question is over. Feature upgrades wait; this one does not. Reproduction of the official CISA alert "CISA Adds One Known Exploited Vulnerability to Catalog" (September 11, 2026) listing CVE-2026-85706; source: https://www.cisa.gov/news-events/alerts/2026/09/11/cisa-adds-one-known-exploited-vulnerability-catalog The affected range is wider than your upgrade plan probably is GitLab's advisory lists impacted versions as GitLab CE/EE from 18.7 before 19.1.8, 19.2 before 19.2.6, and 19.3 before 19.3.2. Three release lines, each needing its own patch. The practical failure mode at most self-managed sites is different: the instance sits on an earlier major (18.x, 17.x), possibly already past its support window, in a container or VM that has not moved in months because "nothing broke." That instance is still listed — the advisory's impact statement starts at 18.7, but the repository commits API exists on every GitLab. The responsible reading of the advisory is: if your instance is 18.7 or newer and not on one of the three patched points, you are affected; if it is older, you are patching everything, because the endpoint has been there longer. Original Netic...

Powered by Readybot.io