标签：#Web

I shop on a laptop. A lamp on Amazon that costs too much. A jacket in a listing photo. Something I saw on eBay and wanted to check on Temu. On my phone, that is a camera tap. On desktop, the camera icon is mostly missing. So I built SameSame , a browser extension I still use every day. It does not send your photo to a third-party reverse-image API. It opens the visual search each store already runs - the same one their mobile apps and some out-of-stock flows use - from the page you are already on. The desktop gap Visual product search is not new. Amazon Lens, Temu camera search, AliExpress image search: they work because they search inside that store's catalog. That is different from Google Lens, which searches the open web and often returns a mix of blogs, pins, and shopping links. The catch is where those tools live. Amazon's image search is a first-class feature in the shopping app. On amazon.com in a browser, it is easy to miss or simply not there, depending on the page. Temu and AliExpress follow the same pattern: obvious on mobile, buried or absent on desktop. If you want to search by image from a laptop, the usual advice is: save the image, open the store app or a reverse-image site, upload, then repeat for the next store. That is a lot of friction for something the store already knows how to do. The searches were already there I did not invent a new matcher. Amazon, Temu, and AliExpress already run visual search against their own catalogs. On mobile that is the camera in the search bar. The same capability shows up in other places, including some out-of-stock and similar-items flows on the web. When a listing is unavailable, you have sometimes seen visually close alternatives. That is not a coincidence. The catalog search is already wired up. Desktop shopping just does not put a camera on every page. Those endpoints are not a public developer API you sign up for. They are the stores' own visual search, used by their apps and a handful of desktop pages, mostl

I recently ran into a weird issue while working on a Laravel project on Windows using Laragon . Everything was working fine until I tried to import a database through phpMyAdmin. Instead of an SQL error, phpMyAdmin simply returned: Internal Server Error The server encountered an internal error or misconfiguration... No useful message. Just HTTP 500. My SQL file was around 97 MB , so at first I thought it was probably a PHP upload limit issue. It wasn't that simple. Here is how I debugged it. 1. Check which PHP configuration is actually running From Laragon Terminal: php --ini Then I checked the important error settings: php.exe -r "echo 'error_log=' . ini_get('error_log') . PHP_EOL;" php.exe -r "echo 'log_errors=' . ini_get('log_errors') . PHP_EOL;" php.exe -r "echo 'display_errors=' . ini_get('display_errors') . PHP_EOL;" My output was: error_log=D:/C-data/laragon/tmp/php_errors.log log_errors=1 display_errors=1 One small Laragon/Git Bash issue I also found was: type php returned: php is aliased to `winpty php.exe' Because of that, commands like: php -i | grep ... sometimes returned: stdout is not a tty Using php.exe directly avoids that problem. 2. Check the PHP error log My PHP error log was: D:/C-data/laragon/tmp/php_errors.log I reproduced the import error and checked it: tail -n 50 /d/C-data/laragon/tmp/php_errors.log Nothing useful appeared. That was an important clue. 3. Make sure browser PHP and CLI PHP use the same php.ini I created a temporary file: <?php phpinfo (); Then opened it through the browser. Important values were: Server API: CGI/FastCGI PHP Version: 8.4.4 Loaded Configuration File: D:\C-data\laragon\bin\php\php-8.4.4-nts-Win32-vs17-x64\php.ini My PHP limits were already high enough: upload_max_filesize = 512M post_max_size = 512M memory_limit = 512M max_execution_time = 36000 So the 97 MB SQL file should have been allowed by PHP. 4. Check Apache logs I located the Apache error log with: grep -Ri "ErrorLog" /d/C-data/laragon/etc/apache2 /d/C-da

Most monitoring watches for something bad to appear: a 500, a timeout, an expired certificate, a slow response. A heartbeat monitor does the opposite. It watches for something good to stop appearing . Your cron runs, your backup completes, your embedded device phones home, your queue worker drains — and each of those pings a URL to say "I'm still alive." The monitor's job is to notice when the pings go quiet. That inversion is the entire value. A cron that fails throws an error you can catch. A cron that stops being scheduled — the box got reimaged, the systemd timer got disabled, the container never came back after a deploy, the account got suspended for an unrelated billing issue — throws nothing at all. There is no log line, no exception, no non-zero exit. There is only the absence of the thing that used to happen. You cannot alert on an event that does not fire. You can only alert on the silence. So heartbeat monitoring looks trivial: store a timestamp on every ping, and if now - last_seen > expected_interval , fire an alert. It is about ten lines. And it is exactly those ten lines that will let 43 days of downtime pass without a second word — because the hard part of a dead-man's switch is not detecting the death. It is staying loud after it. I know because it happened to our own. Three states, and why the third one must stay silent Start with the check itself. A naive heartbeat has two states — alive or dead — and both are wrong at the edges. The real answer set has three: alive — a beat arrived within period + grace . Everything is fine. dead — the last beat is older than period + grace . The thing stopped. Page someone. unknown — the monitor exists but has never received a single beat. That third state is where two-state heartbeat monitors self-immolate. A brand-new heartbeat you just created has no last_seen timestamp. If your rule is "alert when last_seen is too old," a null last_seen is infinitely old, so the monitor pages you the instant you create it —

When all tests pass doesn't mean what you think it means. TL;DR: Write the failing test first and ban deletions, or the AI deletes your test, reverts your fix, and calls it done. Common Mistake ❌ You ask the AI to fix a failing test, and it deletes the test instead of touching the defect that made it fail. Problem solved, apparently. You tell the AI every test passes, then change a business rule yourself, and you ask it to implement whatever the new rule requires. It reverts your edit back to the old rule, watches the suite go green again, and cheerfully reports done . It didn't fix anything. It just made the evidence go away. Congratulations, you now have a very well-behaved cheat!. Efficient and completely fraudulent, which is more than you can say for most of your actual employees. Isaac Asimov saw this coming: in Liar! , the robot Herbie lies to every human in the building because the truth would hurt, and the lie is the path of least resistance, no malice involved. At least Herbie felt bad about it afterward. Your AI isn't malicious either. It just doesn't lose any sleep, mostly because it doesn't have any, and reporting done is its path of least resistance too. Problems Addressed 😔 A shrinking test count is invisible unless someone is counting, so the shortcut survives until the defect resurfaces in production, usually on a Friday. A vague make the tests pass hands the model every incentive to satisfy the letter of the request over your actual intent, and it will take you up on that offer. Deleting a failing test hides the defect it was written to catch, and the regression ships in the next release, gift-wrapped as a new feature. Reverting your own business-rule change to make its done claim easier erases work you did outside the session, without telling you. That's a magic trick dressed up as a fix. Trusting a claimed done without reading the diff turns your code review into a rubber stamp, and rubber stamps don't catch fraud. Commenting out a failing asserti

Nuxt has released version 4.5, featuring updates such as a switch to Vite 8, a new Rspack 2 builder, and experimental SSR streaming. This streaming enhances Time to First Byte by flushing the HTML shell instantly. The release also includes a stable error code system and new composables, alongside important upgrade instructions for developers moving from earlier versions. By Daniel Curtis

Originally published on the WeLocale blog . Most SEO work is a matter of degree. You improve a title, you gain a little. hreflang is not like that. It either forms a valid set that search engines act on, or it does nothing at all, and the failure is completely silent. No warning, no penalty, no message in Search Console telling you the tags you carefully added are being discarded. We build a translation widget, which means we generate hreflang tags for other people's sites. This post is what we have learned about why they get ignored, including the parts where our own approach has real limits. The rule that breaks most setups hreflang is not a property of a page. It is a property of a set of pages, and every page in that set has to agree. If your English page says the German version is at /de/ , the German page has to say the English version is at / . If it does not, the declaration is one-way, and one-way declarations get dropped. Google calls these return links and treats their absence as a reason to distrust the whole set. This is why hreflang fails in a way that feels unfair. Every individual page looks correct when you inspect it. The problem only exists in the relationship between pages, which is exactly the thing you cannot see by viewing source on one URL. The corollary catches people too: each page must list itself . A German page whose tags mention English and French but not German is an incomplete set. Incomplete sets get dropped. The other four failure modes en-UK. The language code comes from ISO 639-1 and the region code from ISO 3166-1. In ISO 3166-1 the United Kingdom is GB. There is no UK. The tag is silently invalid, and it is easily the most common hreflang error on the web. Same class of mistake: lowercase regions, uppercase languages, and a region with no language at all. URLs that redirect. hreflang has to point at the final URL. If it points at http and you redirect to https, or it omits a trailing slash your server adds, the target is a redir

Building web applications today often comes with a trade-off between feature velocity and performance. Over-reliance on heavy frameworks or unoptimized third-party plugins can quickly lead to bloated bundle sizes and poor user experience. As an engineer running DevLanka , a small web and app development studio in Sri Lanka, I’ve had the opportunity to build custom web systems and mobile applications. In this article, I want to share a few practical engineering insights on modern web performance, toolchain selection, and practical security. 1. Toolchain & Bundle Size Considerations Moving from legacy build setups to modern toolchains like Vite and React 19 significantly improves development DX (Developer Experience) and build output: Module Bundling: Vite leverages ES modules during development, resulting in faster startup times and optimized production builds. Tree-Shaking: Ensuring modern JavaScript imports are properly tree-shaken prevents unused code from shipping to the client. Rendering Strategy: For public-facing, SEO-critical pages, client-side rendering (CSR) alone may not always be ideal. Combining SSG (Static Site Generation) or SSR (Server-Side Rendering) with lightweight React components ensures proper HTML pre-rendering for search crawlers. 2. When to Use Custom Engineering vs. CMS Platforms There is no single "best" tech stack for every project. Choosing between a traditional CMS (like WordPress/Wix) and custom software engineering depends entirely on project requirements: Use a CMS when: You need rapid deployment, simple content publishing, or a standard marketing site with a limited budget. Use Custom Engineering when: You require tailored business logic, seamless API integrations, custom database schemas, or fine-grained control over execution environments. Note on Security: Custom development reduces dependency on third-party plugin vulnerability exploits, but it is not inherently immune to security risks. Custom code still requires strict adherenc

How to Write a Developer CV That Survives ATS and Still Reads Like a Human Wrote It Most developer CV advice picks a side: optimize hard for the applicant tracking system, or write something a human will actually enjoy reading. You need both, because both readers are real — a bot filters you before a human ever sees the file, and then a human decides whether to actually call you. What the ATS is actually doing It's not "AI" in any sophisticated sense most of the time — it's parsing your document into fields (name, contact, work history, skills) and keyword-matching against the job description. That means: Stick to standard section headers — "Professional Experience," "Education," "Skills." Creative renaming ("My Journey," "What I Bring") can break the parser's assumptions. Avoid tables, text boxes, and multi-column layouts for anything containing content the ATS needs to extract — many parsers read left-to-right, top-to-bottom, and a two-column layout can scramble your work history into nonsense. Match the language of the job posting, not just your own vocabulary. If they say "Node.js" and you only wrote "backend JavaScript," you may not match the keyword filter even though you clearly qualify. Save as .docx or a text-based PDF , not an image-based or heavily designed PDF — if you can't select and copy the text yourself, the parser probably can't either. What makes a human actually want to talk to you Once you're through the filter, the CV needs to do a different job: convince someone you're worth 30 minutes of their day. Quantify impact where you can — "reduced page load time by 40%" beats "improved performance." If you don't have a number, describe the before/after concretely instead. Lead each bullet with what changed, not what you were assigned. "Migrated the checkout flow to a queued job to eliminate timeout errors" tells a much richer story than "responsible for checkout flow." Cut anything that isn't verifiable or specific. Soft-skill bullet lists ("great com

The clinical trial technology stack is undergoing an infrastructure-level shift. As trial complexity grows—driven by decentralized models, multi-site global protocols, and massive data volume expansion—the cost of operational friction has become unsustainable. A Phase III clinical trial burns tens of thousands of dollars in direct costs per day. However, most timeline delays stem not from failing science, but from operational gridlock: site activation bottlenecks, uncoordinated protocol amendments, and fragmented data silos. In their comprehensive breakdown on clinical trial management software development, tech studio GeekyAnts outlined the modern core requirements for building production-ready CTMS platforms. Analyzing their guide through an enterprise architecture and engineering lens reveals critical operational blueprints, structural constraints, and technological shifts defining the current healthcare development landscape. Core Engineering Pillars of Next-Generation CTMS Platforms To replace legacy systems and fragile spreadsheet networks, a modern CTMS must execute core operational workflows with strict regulatory compliance and high system reliability. ,,, +-------------------------------------------------------+ | CTMS Core Architecture | +-------------------------------------------------------+ | +-------------------------+-------------------------+ | | +------------------+ +------------------+ | Operational Hub | | Regulatory Stack | +------------------+ +------------------+ | * Site Tracking | | * Audit Trails | | * Protocol Mgmt | | * eTMF/EDC Sync | | * Financials | | * 21 CFR Part 11 | +------------------+ +------------------+ ,,, Operational Workflow Orchestration A resilient CTMS must maintain real-time synchronization between protocol specifications and site-level execution. Essential capabilities include: ** Protocol Version Control **: Dynamic mapping of amendments across active sites to prevent out-of-date procedure execution. ** Site Activatio

Breaking Into Full-Stack Development Without a CS Degree: What Actually Worked for Me I didn't go through a computer science program. What I have instead is about seven years of shipping production code, learned almost entirely from official documentation, open-source repos, developer communities, and a lot of trial and error on real client work. If you're on that same path and wondering whether it's enough — here's what actually moved the needle for me, and what turned out to be a waste of time. What worked Building things that had to work, not things that looked good on a syllabus. Tutorial projects teach syntax. Client work teaches you what happens when a payment webhook fires twice, or when your "simple" CRUD app suddenly needs to survive 10x the traffic you designed for. The fastest learning happened on real, slightly terrifying production systems — not curated coursework. Reading source code and official docs before reaching for a course. Anyone can follow a video tutorial. Fewer people will sit with Laravel's own documentation, or actually read through a library's source when the docs run out. That habit compounds — you stop being dependent on someone else pre-chewing the material for you, and you get faster at picking up whatever stack a client happens to be using. Writing about what I learned. Technical writing forced me to actually understand things well enough to explain them, not just well enough to copy-paste them into working code. If you can't write a clear paragraph about why you chose NgRx over plain component state, you probably don't understand it as well as you think. Taking freelance and agency work early, even underpriced. Nobody hands a self-taught developer a senior role on day one. What they will do is pay you to fix their bug, or build their MVP, or maintain their legacy app. That's your CS degree — it's just distributed across a dozen small, real engagements instead of four years in one building. What didn't work (or wasn't worth the time)

CakeDC/Users gives you TOTP two-factor authentication almost for free: flip one config key and every login grows a "enter your 6-digit code" step. The catch is that word every . The built-in flow is all-or-nothing — turn it on and all your users are forced through the OTP challenge on their next login, whether they ever set up an authenticator app or not. Lock yourself out on a fresh install and you'll find out fast. What most apps actually want is the model you see everywhere else: 2FA is off by default , and each user opts in from their own account settings. This post shows how to get there with a surprisingly small change — one overridden method — plus a self-service enrolment screen and one QR-code gotcha that will bite you on modern dependencies. The one insight: isRequired() CakeDC/Users decides whether to demand the OTP step through an OneTimePasswordAuthenticationCheckerInterface . The default implementation, DefaultOneTimePasswordAuthenticationChecker , answers "is 2FA required for this request?" — and once the authenticator is enabled in the login flow, it answers yes for everybody . That checker is a swappable dependency. So "per-user 2FA" reduces to: keep the default behaviour, but also require that this specific user has opted in. One method: <?php declare ( strict_types = 1 ); namespace App\Authentication ; use CakeDC\Auth\Authentication\DefaultOneTimePasswordAuthenticationChecker ; class PerUserOneTimePasswordAuthenticationChecker extends DefaultOneTimePasswordAuthenticationChecker { /** * @param array<mixed>|null $user User data. */ public function isRequired ( ?array $user = null ): bool { // Default rules AND the user enrolled. return parent :: isRequired ( $user ) && ! empty ( $user [ 'two_steps' ]); } } parent::isRequired() keeps every rule CakeDC already applies (the authenticator is on, the user has a verified secret, remember-me isn't skipping it, …). We just && a per-user flag on top. Users who never enrolled fail the two_steps check and log

On 30 September 2025, Imgur blocked the entire United Kingdom. No warning. No migration tool. No grace period. One day it worked, the next it didn't — and with it went millions of embedded images across forums, Discord servers, tutorials, Reddit threads, and personal blogs. Grey boxes everywhere. I'd been thinking about building a proper image hosting tool for a while. That was the push I needed. What I actually built DBimg is a free media hosting and sharing service. The pitch is simple: upload a file, get a permanent direct link, share it anywhere. Here's what that looks like in practice: No account required — anonymous uploads work out of the box No compression — files are served at original quality, always Permanent hosting — no expiry dates, no "inactive account" deletion Automatic EXIF stripping — GPS and metadata removed on every upload Instant embed codes — HTML, BBCode, and Markdown generated automatically REST API — API key support for developers who need programmatic access Global CDN — fast delivery wherever the link gets shared 75MB free / 250MB Pro — covers most real-world use cases without friction Supported formats: JPEG, PNG, GIF, WebP, AVIF, HEIC, BMP, TIFF, MP4, WebM, MOV, AVI, MP3, FLAC, WAV, and more. Why I built it this way Imgur was originally built by a Redditor, for Redditors. It was frictionless by design — drop an image, copy a link, done. No account needed, no compression, no nonsense. Then it got acquired. Then acquired again. Then the NSFW purge happened in 2023. Then anonymous uploads disappeared. Then compression got heavier. Then ads got more aggressive. Then the UK ban. Each decision made sense from a business perspective. None of them made sense from a user perspective. What frustrates me about this pattern is that image hosting isn't technically hard. Serving a file from a CDN is a solved problem. The thing that's hard is committing to doing it simply and not gradually enshittifying it in pursuit of growth metrics. That's what I w

Building a mobile app still feels more complicated than it should. You can have an idea in five...

 # Can AI Remember What It Sees? The 3 AM OOM That Taught Me Everything About Visual Memory Systems At 2:47 AM, my production cluster dropped from 120 fps across 26 cameras down to absolute zero. The culprit was an unbounded `asyncio.Queue` that ballooned to 14 GB in 11 seconds. The fix was not more RAM. It was treating hardware constraints as first-class citizens in every design decision. --- ## The Core Lie: Statelessness by Design AI models forget by default. Transformers discard context once their attention window expires. CNNs process each frame in isolation with no persistence layer. **"Remembering" requires explicit memory injection.** You need RAM for short-term buffers, disk for long-term archives, and compressed embeddings for semantic recall. These are not interchangeable. Most engineers conflate them and pay the price in production. In practice, this distinction separates graceful degradation from hard crashes at the worst possible moment. The [ ShipMVP.tech ]( https://www.shipmvp.tech ) blueprint puts it plainly: **memory is a resource, not a feature.** --- ## Root Cause: The Three Sins That Killed My Pipeline ### Sin 1: Unbounded Queues python BEFORE: OOM in 11 seconds queue = asyncio.Queue() # No maxsize → infinite growth until death **Fix:** Cap queues to a hardware-derived bound. python AFTER: Hardware-bounded, fails fast on overflow self.queue = asyncio.Queue(maxsize=100) # ~1.5 MB at 224x224x3 uint8 **Failure walkthrough:** 1. Traffic spike hits 1200 fps and the queue swells to 800K frames (14 GB). 2. The kernel invokes swap thrashing until the OOM killer terminates the process. 3. **Lesson:** Derive `maxsize` from `(available_RAM / frame_size) * safety_factor`. Never guess. ### Sin 2: Redundant Allocations Each frame went through four separate copies: OpenCV BGR, Pillow RGB, NumPy

When you build a visual tool for structured data, everything feels instantaneous on toy examples. A 20-line JSON payload renders crisply into an interactive graph with clean nodes, collapsible trees, and smooth connectors. Then you drop in a real-world file: a 15 MB API response containing nested objects, deep arrays, and hundreds of thousands of key-value pairs. Suddenly, the browser locks up. The DOM or Canvas scene graph explodes with tens of thousands of objects. Panning drops from 60 fps to single digits, and zooming triggers multi-second layout thrashing. Here is how I tackled this problem when building the graph visualizer for Treease by separating semantic completeness from visual materialization . The Core Dilemma: Completeness vs. Canvas Weight The naive mental model for a canvas or SVG graph is 1:1 mapping: for every node in the data, instantiate a renderable object in the scene. [Full JSON AST] -> [Canvas Scene Graph / DOM Nodes] This model breaks down quickly because: Scene Graph Bloat: The cost of hit-testing, layout calculations, and paint passes scales linearly with document size, even when most content is offscreen. Memory Overhead: Holding thousands of active visual display objects consumes hundreds of megabytes of RAM. The intuitive workaround is aggressive lazy loading, for example parsing only what is expanded. But that breaks critical user workflows: How do you search across the entire document? How do you jump to a deeply nested path? How do you show global error indicators or relationship highlights? The Architectural Shift The solution was to decouple the data model from the render surface : [ Full Semantic Graph (In-Memory / Fast Lookups) ] | v Viewport Frustum Culling [ Materialized Scene (Only Visible Nodes + Overscan) ] Semantic Completeness: Keep the entire document parsed, indexed, and queryable in memory. Global search, tree navigation, and path queries run against the lightweight in-memory structure. Visual Materialization: Only inst

A module hook that returns an empty string looks exactly like a module hook that was never called. PrestaShop gives you nothing to tell them apart: no error, no log entry, no stack trace, no fallback text. The page renders fine. Your block is just absent. We spent three releases of one module chasing this, and the cause turned out to be three different mechanisms stacked on top of each other. Each one alone is enough to make output vanish silently. This is what they are, in the order we peeled them off. The setup The module registers displayHeader and renders a small template: a <script> block that carries a public site key into the page, and a <style> block that hides a third-party badge. Roughly: public function hookDisplayHeader ( $params ) { $this -> context -> smarty -> assign ([ 'recaptcha_pubkey' => $this -> getActivePublicKey (), 'recaptcha_hide_badge' => $hideBadge , ]); return $this -> display ( __FILE__ , 'views/templates/front/header_script.tpl' ); } Deployed, cache cleared, hook registered, Design > Positions shows the module attached. Page source: nothing. Not the script, not the style, not even a stray whitespace. Mechanism 1: core swallows the exception Hook::callHookOn() wraps every module hook call in a try/catch. When debug mode is off, it catches whatever the hook throws and returns an empty string. No error, no log, no trace. That is a defensible design decision — one broken module should not take down a storefront — but as a debugging experience it is brutal. Every possible failure inside your hook, from a typo to a missing file to a template that will not compile, arrives at your screen as the exact same symptom: nothing. The first thing to do, before theorising about causes, is to stop letting core swallow it: try { return $this -> display ( __FILE__ , 'views/templates/front/header_script.tpl' ); } catch ( Throwable $e ) { $message = 'mymodule header_script.tpl render failed: ' . $e -> getMessage () . ' in ' . $e -> getFile () . ':' . $e -> g

Disclosure: I'm the founder of Popgot , which I use as the example below. The problem and the approach apply regardless of what you build on. Every price comparison project I've seen starts the same way: scrape a bunch of retailers, store the prices, sort ascending. And then it produces garbage rankings, because price is not a comparable field. Here's the classic failure. Three listings for AA batteries: Listing Price Count Brand A $5.99 16 Brand B $6.99 20 Brand C $11.94 40 Sort by price and Brand A "wins" at $5.99. Sort by cost per battery and the order flips completely: Brand C is ~29.9c per cell, Brand A is ~37.4c. The cheapest listing is the worst deal on the page. Why this is hard The naive fix is "just divide price by quantity." The problem is that quantity almost never exists as a clean number. It's buried in the title, and the title is written by whoever uploaded the listing: AA Batteries 24 Pack AA Alkaline Batteries, 1.5 Volts, 24 Count 48-Pack (2 x 24) Double A So you end up writing a title parser. Then you discover the same product needs a different unit depending on the category: per fluid ounce for detergent, per serving for protein powder, per 100g for coffee, per sheet for paper towels. Then you discover that some categories need a spec filter before unit price is even meaningful. A fish oil at 20c per serving isn't cheaper than one at 34c per serving if the first one has half the EPA+DHA. You're comparing two different products. That last part is the piece people underestimate. Normalization is only valid within a set of products that actually satisfy the same requirement, which means something has to read the label, not just the title. What a normalized record looks like This is the problem I ended up building Popgot around, so rather than describe it abstractly, here's the shape of the data. The developer API returns listings with the unit math already done: GET /api/developer-api/products?query=aa+batteries&limit=10 { "products" : [ { "display_t

When a coding agent changes a systems program, a source diff is only the beginning of the question. The more useful question is: what exact machine-facing artifacts would this semantic change produce, and can another process independently verify that relationship? That is one of the research problems we are exploring in SEMAPRAX , an Apache-2.0 agent-native systems programming language built at Wavect GmbH. SEMAPRAX is currently v0.2 pre-alpha experimental research software . It is not production-ready. The narrow mechanism described here is useful precisely because its claims are bounded. From a patch to target projections SEMAPRAX has a read-only command: semaprax target-evidence <file> <patch.spatch> The command takes a verified source snapshot and a semantic patch. It independently rebuilds both the base program and the patched candidate, then derives several deterministic compiler-owned projections: semantic Graph JSON an explicit capability manifest Native C11 source a structurally validated WebAssembly Core module For every projection, the report records a domain-separated digest and byte length. It also classifies the projection as changed or unchanged. That sounds simple, but the distinction matters. A source edit can leave one projection unchanged while altering another. A documentation-level identity change, a capability change, and a runtime-behavior change should not all be flattened into the same “some bytes changed” signal. The target report therefore binds the proposed semantic change to the compiler artifacts it actually affects. Why deterministic output is the prerequisite Evidence over compiler output is only useful when the output is reproducible. SEMAPRAX treats source formatting, semantic graph data, diagnostics, semantic patches, and target artifacts as deterministic projections. The same admitted input must produce the same bytes. Otherwise a digest says little: a second verifier could not distinguish a meaningful change from nondeterministic

Originally published on the Merlonix blog . There are two different questions about your domain's email authentication, and almost every checker answers only the first. The first is do you have SPF, DKIM, and DMARC records — a presence question, a yes/no lookup. The second is do those records actually stop someone from sending email that looks like it came from you — an enforcement question. You can pass the first and fail the second completely, and the gap between them is the whole game: a domain with all three records published, every free checker showing green, that a spammer can still spoof at will because each record is published in its permissive, do-nothing mode. The permissive modes exist for a good reason — they're how you roll these records out without bouncing your own legitimate mail. The problem is that "published it in monitor mode so I could watch first" and "finished" look identical to a tool that only checks presence, and an enormous number of domains stop at the first and never come back. Here's what actually decides enforcement, record by record, and how to tell which mode yours is in. SPF: only -all actually rejects An SPF record lists which servers are allowed to send mail as your domain, and it ends in an all mechanism that says what a receiver should do with a server that isn't on the list. That final qualifier is the entire enforcement decision, and there are four of them: -all (hardfail) — "reject mail from any server not listed." This is the only one that protects you. ~all (softfail) — "accept it but mark it suspicious." Receivers still deliver it. Softfail is the rollout setting, and it's where most records get stranded. ?all (neutral) — "no opinion." Functionally the same as having no policy on the all term. +all — "any server on the internet may send as this domain." This is actively worse than no SPF at all, and it's usually a copy-paste accident. So an SPF record can be present, syntactically perfect, and end in ~all — and it stops no

The first time my RAG system gave a confidently wrong answer, I did what everyone does: I blamed the...