标签：#dev

If you ship anything that touches AI-generated images — a thumbnail pipeline, a user-upload feature, a design tool — you've probably noticed something: the images your model spits out are heavier than they should be, and they carry baggage you never asked for. That baggage is provenance metadata. Modern generators (GPT Image / DALL·E, Google's Nano Banana / Gemini, Midjourney, many hosted Stable Diffusion endpoints) stamp each output with tags that mark it as machine-made. Some of it is harmless. Some of it survives a Photoshop round-trip. And most developers have no idea it's even there until a downstream platform flags an image or a QA person asks "why does this PNG have a certificate chain in it?" This is a hands-on guide to seeing that metadata and removing it — from the CLI, from Node, from Python, and (when you just want it gone) from the browser. What actually gets embedded There are four layers worth knowing about, because they don't all come off the same way: EXIF fields — the classic camera-metadata block. Generators repurpose fields like Software , ImageDescription , or a custom Make / Model to identify themselves. Trivial to read, trivial to strip. XMP packets — an XML blob (Adobe's format) holding richer provenance: model name, generation timestamp, sometimes a prompt hash. Lives in its own segment of the file. C2PA manifests — the interesting one. The Coalition for Content Provenance and Authenticity standard embeds a cryptographically signed manifest (stored in a JUMBF box) that records the asset's origin. Because it's signed, it's designed to be tamper-evident — which also means naive metadata strippers often miss it. Pixel-level watermarks — e.g. SynthID-style signals baked into the pixels themselves. These are not metadata at all; no EXIF tool touches them. (More on the limits below.) The mistake I see repeatedly: someone runs a one-liner that clears EXIF, sees "no EXIF" in their viewer, and assumes the image is clean. The C2PA manifest and XMP pac

Our tool transcribes audio in the browser — Whisper running locally via transformers.js , no upload. It worked fine, until analytics showed something too clean to be a coincidence: .mov uploads on mobile failed 100% of the time. Not 90%. Every single one. Desktop had never reported a single .mov failure. This is what I found, and how it got fixed without pulling in ffmpeg.wasm or WebCodecs. The 30-second reproduction I took one AAC audio track and put it in two containers — same encoder, same bytes for the audio itself, only the wrapper differs: const buf = await file . arrayBuffer (); await new AudioContext (). decodeAudioData ( buf ); On an iPhone 17 Pro simulator (iOS 18.7 / Safari 26.5): File iOS Safari Chromium sample.mov (ftyp qt ) EncodingError: Decoding failed OK sample.mp4 (ftyp isom ) OK OK So it isn't the codec. It's the container. The obvious fix that doesn't work First instinct: it's the brand in the ftyp box. Patch qt → isom , four bytes, done. It still fails. I'm writing this down so nobody else burns an afternoon on it. The ftyp brand is not what Safari looks at. The difference lives inside moov . The actual root cause Dig down to moov → trak → mdia → minf → stbl → stsd — the sample description that tells the decoder how the audio is encoded. Both files carry an mp4a entry. They are not the same mp4a entry: QuickTime writes: MP4 expects: version = 1 <— version = 0 compressionID = -2 (fffe) <— compressionID = 0 + 16 bytes of v1 extension <— (absent) esds wrapped in a 'wave' box <— esds is a direct child extra 'chan' channel layout (absent) iOS Safari's decodeAudioData only accepts a version 0 audio sample entry. Chromium accepts both — which is exactly why desktop never saw this and mobile never survived it. That version field is a uint16 . Two bytes decide whether the file plays. The fix: rebuild the container, don't touch the codec Since the audio bitstream is already valid AAC, nothing needs to be re-encoded. The job is pure byte plumbing: extract

Creating a repeating pattern sounds simple: place the same image side by side and export it. In practice, the edges rarely match. Visible seams appear, previews become difficult to inspect, and exporting large repeated layouts can quickly become tedious. That’s why I built Seamlessify, a browser-based tool for turning ordinary images into seamless, tileable patterns. What it can do The free direct-stitching workspace lets you: Upload PNG, JPG, or WebP images Use direct stitching or blend visible edges Preview the result as a 3×3 repeating pattern Zoom in to inspect boundaries Control repeat count and output dimensions Process multiple images in batches Export PNG, JPG, or ZIP files The direct-stitching workflow runs in the browser and doesn’t require an account. Optional AI pattern generation I also added an AI workspace for creating new seamless images from: A text prompt A reference image A reference image combined with written instructions Generated images can be downloaded directly or sent into the stitching workspace for additional processing, cropping, and batch export. The goal was to keep the workflow simple: generate or upload an image, inspect the repetition, make adjustments, and export—all without jumping between several different tools. Why I built it Many existing pattern tools are either too limited for batch work or include complicated controls that make a small task feel much bigger than it should. Seamlessify is designed to stay approachable for designers, print-on-demand creators, textile projects, wallpapers, backgrounds, packaging, and game assets. You can try it here: 👉 https://seamlessify.com I’d love to hear what formats, controls, or workflows would make it more useful for your projects.

It takes me 2 hours. I am not joking. Usually, I don't have it "planned" before I started to...

Opening four coding-agent sessions feels like scaling. On a shared machine, it is closer to giving four fast contributors the same repository, shell, credentials, ports, caches, and merge queue without deciding who owns any of them. The first failure probably will not come from model quality. One task will restart a dev server while another is testing it. Two workers will touch the same lockfile. A branch will pass its own checks and still conflict with a migration waiting in the merge queue. Four chat windows create concurrency. Four owned workspaces plus one deliberate merge queue create a system. Parallelism multiplies shared state Tasks that sound independent in a prompt can overlap in the environment. A frontend change and an API change may both edit generated types. Two test runs may expect the same database or browser profile. Separate worktrees can still launch services on the same port, read the same environment variables, and write to shared caches. The agents do not collide in the prompt. They collide in everything the prompt lets them touch. This is why adding a second agent changes the job. With one worker, the operator can keep a surprising amount of state in their head. With four, every unstated assumption becomes a race condition or a review problem. The fix is to make ownership visible before execution starts. A worktree is the start, not the boundary Git worktrees are a sensible first step. Each task gets its own branch and working files, so one agent is less likely to overwrite another agent's edits by accident. That is useful isolation, but it is narrow isolation. A worktree does not reserve a port. It does not separate process trees, temporary directories, credentials, network access, browser state, or external services. Treating it as a sandbox gives the workflow more confidence than the boundary deserves. Proliferate is an instructive project example because its documented design pairs isolated task worktrees with visible review state. The imp

Publora is in the Zapier app directory now. I didn't do it to tick a box on some distribution list. My job is making our product easy to live with, and if a user has an agent that can wire us in deeper so they don't have to build the plumbing themselves, I'll go make that happen. Zapier is exactly that case: it connects Publora to thousands of other apps, so nobody has to hand-roll the integration. Worth it. I'd just add that "a no-code platform" and "publishing your own app on a no-code platform" turn out to be two very different Zapiers. Prove it works for users who don't exist yet Here's the requirement I reread three times, sure I'd misunderstood. To submit an app for review, every trigger, every action, and every search has to be tested inside a live Zap, turned on, with at least one successful run in the history. You can't delete those Zaps; the reviewer can ask to see them. So the logic goes like this. You want to publish an app so people can start using it. But to publish it, you first have to prove it's already being used. Run every component for real, as if you had the users you're publishing it to attract. The app isn't in the directory yet, and a history of real use already has to exist. You end up standing in for your own users who aren't there yet. You build the Zaps, run each one, make sure every one has a green run, and don't touch them afterward. A routine task you run like a rocket launch The second surprise. My tasks here are the plain ones: schedule a post, publish a post, delete a post. This isn't a satellite launch. It's what our API does a thousand times a day over one line of code. As a Zapier app, each of those ordinary tasks has to be wrapped, configured, and run live on its own. Create Post, Update Post, Delete Post, two triggers, two searches, each with its own test run under the validator's eye. Scheduling a post is something I can describe in one sentence. Here it became a component with a run history. Then the small surprises a "no-cod

Almost every codebase I've inherited sends email the same way: somewhere inside a POST handler, between the database write and the response, there's an await on the mail provider's SDK. It works, for months. Then one afternoon your signup endpoint starts timing out, and it takes an hour to work out that the cause is your email provider having a bad day three thousand kilometres away. I build Pulsenote , a transactional email API, so I've spent an unreasonable amount of time in the space between "your API call returned 200" and "the message is in the inbox". This post is what lives in that gap, why a try/catch doesn't cover it, and where the line sits between "you need a pipeline" and "you're overengineering a side project". The naive version Here's the code. You've written this. // users.controller.ts @ Post ( ' signup ' ) async signup (@ Body () dto : SignupDto ) { const user = await this . users . create ( dto ); await this . mailer . send ({ to : user . email , subject : ' Confirm your email ' , html : renderConfirmation ( user ), }); return { id : user . id }; } Nine lines, obvious intent, no infrastructure. For a lot of applications this is genuinely the right answer, and I'll come back to that at the end. But let's be precise about what it costs, because "it's fine" and "I haven't measured it" are different statements. It puts a third party in your request path. Your p99 for POST /signup is now your p99 plus the provider's p99. Not their median — their tail. A slow provider becomes a slow endpoint, then no endpoint. This is the failure mode that actually takes services down. If the provider degrades to five seconds per call, every signup request holds a connection and an event-loop continuation for five seconds. Your connection pool fills, your load balancer queues, health checks fail, the pod gets restarted, and now you're down — because of email. The blast radius of a non-critical dependency became the whole endpoint. A provider 5xx loses the mail entirely.

A modular monolith without enforcement is not an architecture — it is a monolith with good intentions. The Problem Most teams skip the modular monolith and jump straight to microservices. The ones that do attempt a modular monolith rely on convention — "don't cross module boundaries" — which fails the moment deadlines hit. The difference between a well-structured modular monolith and a mess is whether boundaries are maintained by tooling or by convention. The Solution Structure Each module is a pair of .NET projects: src/Modules/ Orders/ YourApp.Orders/ ← internal: domain, application, infrastructure YourApp.Orders.Contracts/ ← public: DTOs, interfaces, events Payments/ YourApp.Payments/ YourApp.Payments.Contracts/ The rule : modules may only reference each other's *.Contracts projects. The compiler enforces this physically — no project reference means no type access. Four Layers of Enforcement Compiler — project references prevent cross-module type access NetArchTest — architecture tests fail the build on namespace-level violations NDepend CQLinq — catches dependency cycles and coupling the compiler can't see Quality Gates — block PRs that introduce new boundary violations Module-Scoped Data Each module owns a dedicated DbContext with a schema prefix ( orders.* , payments.* ). No module queries another module's tables. Cross-Module Communication Modules communicate via MediatR in-process events. Orders publishes OrderPlaced ; Payments subscribes — without Orders knowing Payments exists. This is also the extraction seam: when you eventually extract a module into a service, MediatR becomes a message broker. The event contract stays the same. Parallel CI strategy : matrix : module : [ Orders , Payments , Inventory ] fail-fast : false Each module's tests run in parallel. CI time scales with the slowest module, not the total count. The Extraction Path When a module genuinely needs independence: Add outbox table → publish to real broker Replace MediatR handlers with brok

Hi everyone! 👋 I just published v1.0.0 of my very first web project: an installable Progressive Web App (PWA) built from scratch using HTML, CSS, and Vanilla JavaScript. I designed it to be extra accessible and versatile, especially for older adults, shopkeepers, students, and everyday users. ✨ Key Features Multiple Modes: Standard, Scientific, Sales, Interest (Simple & Compound), Unit Conversions, BMI, Age, and Adjustable Percentage. Customization: Adjustable button sizes and custom background themes (including Dark and Light modes). Offline PWA Support: Service worker caching allows full offline functionality and direct installation on mobile or desktop devices. 🔗 Try It Out & Explore Code 🚀 Live Demo: mdalif027-tech.github.io/easy-calculator 💻 GitHub Repository: github.com/mdalif027-tech/easy-calculator 💬 Looking for Feedback Since this is my first app, I would really appreciate any thoughts on: Mobile touch layout and responsiveness across screen sizes. UI/UX design or theme improvements. Recommendations for features to add in future releases. Thank you so much for checking it out!

The follower counter on my phone says 1,946. I check it more often than my homework diary. 54 to go...

Dirk Lemmerman has released FlexGanttFX as an open-source resource-scheduling framework under the AGPL license. This JavaFX library enables Gantt chart creation for various industries, optimizing performance with a Canvas rendering method. The framework includes features for task dependency modeling and direct editing, accommodating diverse project planning needs. By Erik Costlow

I'm a backend engineer mainly working on game servers, with Java as my primary language. Over the years, I've spent a lot of time building and debugging backend systems, and recently I've been digging deeper into concurrency, I/O, logging, and performance. Working on game servers has taught me that many problems look simple at first, but become surprisingly complicated once the system gets busy. I'll be sharing some of the things I've learned from real-world systems, including experiments, benchmarks, design decisions, and a few open-source projects I'm working on. Glad to be here. Looking forward to learning from everyone on DEV!

Google's developer verification requirement starts enforcing in about a month, and Brazil is one of the four countries it lands in first. If you work here, this is not a 2027 problem you get to read about later. Most of the coverage I've seen frames this as a sideloading story, or an F-Droid story, or an "Android is losing its freedom" story. Those are real arguments, but they're not the thing that's going to interrupt my week. The thing that's going to interrupt my week is much smaller and much more annoying: how a build gets onto a QA engineer's physical phone. The rule, in one paragraph From September 30, 2026, apps installed on certified Android devices in Brazil, Indonesia, Singapore and Thailand must be registered to a verified developer. Certified devices are roughly 95% of Android outside China. The requirement applies whether the app came from Play, from an alternative store, or from an APK you downloaded off a link. Verification means an identity check plus registering each package name against the SHA-256 fingerprint of its signing key. Global rollout follows in 2027. Two things matter for how you read that. It's the package name that gets registered, not the app in some abstract sense. And it's tied to a specific signing key. What does not break Before the panic, the exemptions are wide, and if you only skim one section, skim this one. ADB installs are unaffected. Local development and testing over adb install keep working exactly as they do today. Google has been explicit about this. Enterprise deployment is exempt. Apps installed through an EMM Device Policy Controller, or published as private apps in Managed Google Play, are exempt indefinitely. If your organization ships to managed clinic devices through an MDM, that path is fine. If you're already on Play, you're probably already done. In March 2026, Google auto-registered package names and signing keys for the large majority of existing Play apps under the accounts that own them. Worth confirming i

Building a website still involves a lot of repetitive work: planning the layout, writing content, generating code, connecting forms, and finally deploying everything. I built Waspes to automate as much of this workflow as possible. A user describes the website they want, and the platform generates the structure, content, visual elements, and functional components. The interesting part is that Waspes doesn't only generate a visual mockup. Generated websites can include working contact forms and can be published directly to a waspes.com subdomain with HTTPS. Waspes can also generate detailed prompts for tools like Claude, Cursor, v0, and Lovable, making it possible to use the generated specification as a starting point for further development. The goal is simple: turn an idea into a working website with as little friction as possible.

Sometimes software development reaches a point where the tools designed to make your job easier start becoming part of the job. I ran into that with browser debugging. I wanted something that should have been simple: Set a breakpoint. Press F5. Debug my JavaScript. Instead, I found myself spending too much time thinking about development servers, browser launch configuration, debugger connections, ports, profiles, and the debugging environment itself. That led to a simple question: What if browser debugging could go back to convention over configuration? So I built CloudIDEaaS JavaScript Debugger . ⚡ The Goal: Press F5 and Debug The philosophy behind CloudIDEaaS is straightforward: Spend your time debugging your application instead of debugging your debugging environment. For a straightforward JavaScript or HTML project, I wanted the workflow to look like this: Set a breakpoint. Press F5 . Start debugging. Behind those three steps, CloudIDEaaS can start the local web server, launch Chrome, establish the debugging connection, configure your breakpoints, and then load the application. The important part is that you don't have to think about most of that. 🔴 Real Debugging Inside VS Code This isn't intended to replace Chrome DevTools or compete feature-for-feature with every large JavaScript debugging platform. It's focused on providing the debugging features I use most often directly inside Visual Studio Code: 🔴 Source and conditional breakpoints 👣 Step over, step into, and step out ▶️ Continue and pause 🔍 Local variables and object inspection 📚 Scopes and call stacks 🧮 Expression evaluation ⚠️ Exception breakpoint configuration 🌐 A built-in local web server One feature that was particularly important to me was startup breakpoints . The debugger establishes the connection and configures your breakpoints before loading the application, making it possible to catch JavaScript that executes during startup. 🧠 What's Actually Happening Under the Hood? Building the debugger a

I kept hitting the same wall with coding agents. One Claude Code or Codex session in a repo works great. The moment I wanted two tasks moving at once - login in one terminal, payments in another - they started stepping on each other. Same working directory, same checked-out branch, two processes editing the same files. Chaos. The fix turned out to be a Git feature that has been sitting there for years: git worktree . It gives you several working directories backed by the same repository . Each folder has its own checked-out branch, but all of them share the same objects, commits and branch list. The setup From your main checkout: git worktree add ../integration -b integration main git worktree add ../feature-login -b feature/login main git worktree add ../feature-payments -b feature/payments main Which leaves you with something like: project/ ├── main/ → branch main ├── integration/ → branch integration ├── feature-login/ → branch feature/login └── feature-payments/ → branch feature/payments Now every agent gets its own folder. One terminal per worktree, one agent per terminal, and nobody touches anybody else's files: cd feature-login # agent 1 works here cd feature-payments # agent 2 works here, at the same time The part that surprised me: no push, no pull My first instinct was: agent finishes login, pushes the branch, then I pull it into integration. That's the muscle memory from working in a team. It's unnecessary here. All the worktrees belong to the same repository on the same machine, so Git already knows every branch locally. When agent 1 finishes: cd feature-login git add . git commit -m "feat: implement login" ...the integration worktree can merge it directly: cd ../integration git merge feature/login git merge feature/payments npm test No git push , no git pull . The directories are different, but feature/login and integration are branches of the same repo. When integration is green: cd ../main git merge integration You don't even have to wait for a worktr

NoRespawn — Gaming Community Forum Join No Respawn — a community built for gamers to share their best clips, swap strategies, get help, discover new tricks, and talk about the games they love across every genre. norespawn.space

Retries are one of those things that look harmless until the first time they duplicate a real business operation. A request times out, so the client retries it. Reasonable. But what if the first request actually reached the server? What if the application already created the order, reserved the stock, sent the message, or called a payment provider — and only the response was lost? From the client's point of view, the request failed. From the application's point of view, it may already be finished. Send the same request again and you can get the worst kind of bug: one that is technically understandable, difficult to reproduce, and very expensive in production. This is the problem that pushed me to build HttpIdempotencyBundle , a small Symfony bundle for explicit HTTP request idempotency. But the interesting part is not the bundle itself. The interesting part is everything that has to be true before we can safely say: "This request is a retry of the same operation, so we should not execute it again." And just as importantly, what we cannot guarantee. A timeout does not mean the operation failed Consider a simple endpoint: #[Route('/orders', methods: ['POST'])] public function createOrder (): JsonResponse { $order = $this -> orderService -> create (); return new JsonResponse ([ 'id' => $order -> getId (), ], 201 ); } Now imagine this sequence: Client -> POST /orders Server -> creates order #742 Server -> sends 201 response Network -> connection dies Client -> sees timeout Client -> retries POST /orders Nothing unusual happened. The client did exactly what clients often do after a timeout. The server did exactly what it was asked to do. And yet, unless we have another mechanism in place, we may now create order #743 as well. The key idea is simple: transport failure and business-operation failure are not the same thing. HTTP cannot always tell the client whether the operation happened. Give the operation an identity A common solution is an Idempotency-Key . The client g

Your agent passed its tests. It ran clean in the demo. You shipped it. Two days later it's...

Hello, I'm Shrijith Venkatramana, and I'm building LiveReview — a blast-radius aware AI code review built for your business-critical systems. Star us to help devs discover the project, give it a try, and share your feedback to help improve the product. Most people learn neural networks by staring at the model. Weights. Attention. MLPs. LayerNorm. Tokenizers. Context windows. But when you actually train an LLM, there is another piece of machinery making billions of decisions every second: the optimizer. A 70-billion-parameter model does not "learn" because gradient descent tells it which direction is better. It learns because an optimizer turns an enormous, noisy stream of gradients into parameter updates that are small enough not to explode, large enough to make progress, and adaptive enough that different parameters can move at radically different effective rates. For the last decade, the dominant answer has largely been some form of Adam , and increasingly AdamW . The interesting part is that Adam is not some mysterious LLM-specific invention. The original Adam paper was submitted in December 2014 by Diederik Kingma and Jimmy Ba, before the Transformer, before GPT, and before the modern LLM era. Kingma was working on scalable machine learning and generative models; Ba was then a PhD student working with Geoffrey Hinton at Toronto. Three years later, the Transformer paper used Adam directly in its training recipe. Then came AdamW, which fixed a subtle but important problem in how regularization interacted with adaptive optimization. By 2025, Adam was sufficiently influential to receive an ICLR Test of Time award. So what exactly is Adam doing? And why is AdamW usually what you actually want when training a Transformer? 1. First, forget Adam: what problem is the optimizer solving? Suppose your neural network has parameters theta = [theta_1, theta_2, ..., theta_N] and your training batch produces a loss L . Backpropagation gives you g = dL/dtheta The simplest possibl