标签：#dev

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry . 🦄 I debated writing this for a long time, but I finally talked myself into really writing again after a hiatus, and there's no better way than story time. So here's one of the most challenging bugs—or really, the series of them—I've run into in the enterprise world. Grab some popcorn and Skittles, because this one takes a while. Better yet, cue up Jerry's actual theme song— Jerry Was a Race Car Driver by Primus , because of course it is —and let the best bass player on the planet score the whole mess while you read. And yes, it's the Summer Bug Smash and my entire cast is dressed for Christmas. Stay with me. Meet Jerry 🪦 If you work with software any length of time, you already know the particular nightmares that come with legacy applications. This one is no different. It started life as a rewrite of some antiquated, bash-flavored system back when Java 8 was the coolest kid at the table. Let's call him Jerry. Jerry is a well-rounded app—or he was, before he let himself go. He came up on a then-modern Java stack and served exactly one purpose: get data from upstream into the database, correctly and on time. He was good at his one job. Then his one job got split into parts, and the sum of those parts did not add up to a whole—Jerry just expanded along the midline with no particular purpose or direction in life. You can imagine how it goes: a few retirements, a couple of half-finished rewrites, several well-meaning somebodies who swore they'd whip him into shape and left him half-done every time. Take your eyes off him at Christmas and he's the weird uncle who shouldn't have been left alone with the punch. That's about when Jerry and I met, more than three years ago. The Infestation Begins 🪰 Jerry did his best to keep up with everything we kept piling on him, but communication was never his strong suit—a patch here, an upgrade there, enough to keep the lights on and the punch bowl full.

Table of Contents: Introduction Constants Singletons & Services Singleton Service Locator Introduction Every Unity developer eventually hits the exact same wall: how do I get my UI script to talk to my Game Manager without turning my codebase into a tangled web of dependencies? Managing global state is a fundamental challenge in game architecture, and the internet is full of conflicting, often dogmatic advice on how to handle it. In this article, we are going to look at some popular approaches to managing global state: Static Constants, Singletons and Service Locator. Before we start though, I encourage you to read some of my previous blog posts in this series on project scaffolding or, even more crucial to some sections in this article, the bootstrapping process . Constants Not every piece of global data needs a instance to live in, interfaces, or an initialization phase. Some data is constant and never changes at runtime (constants). These constants are usually defined with static readonly or const (at least they should be if they never change). Example: public static class MathConstants { public const float MilesToKm = 1.60934f ; } public class CharacterAnimationController : MonoBehaviour { // we must use static readonly instead of const here because we need to generate the SpeedHash from the string literal. public static readonly int SpeedHash = Animator . StringToHash ( "Speed" ); } Constants are also tied to the type they are defined in. So to keep things neat, you should only define constants where appropriate. Meaning if you have a constant for the max networked inventory slot capacity, this shouldn't be defined in a class called NetworkedConstants and instead should reside inside the class that represents the NetworkedInventory which needs this data. In fact, if this is the only class that needs this data, you can even make it private although it's perfectly fine to make it public as well if there's a need for it in other scripts as long as you are not just

I have a ritual. Whenever a pipeline latency alert hits my phone, my first instinct isn't to open a heavy dashboard or spin up a full Grafana instance. I grab my terminal and start firing curl commands at port 9600. curl -s localhost:9600/_node/stats?pretty ... curl -s localhost:9600/_cat/pipelines ... curl -s localhost:9600/_plugins . It's a repetitive, mindless sequence of commands. It works, but it's reactive and solo. You are the one parsing the JSON, you are the one looking for the pattern in the JVM heap usage, and you are the one manually correlating a spike in event flow with a specific thread lock. With the Model Context Protocol (MCP), that ritual is becoming obsolete. I've been experimenting with connecting MCP-compatible agents—specifically through Cursor and Claude—directly to Logstash via a specialized API server. The difference isn't just 'convenience.' It's an architectural shift from manual inspection to agentic triage. Moving beyond the Chatbot Most people treat AI like a documentation search engine. They ask, "How do I configure a JDBC input in Logstash?" That’s fine, but it doesn't help when your production cluster is turning 'yellow' at 3 AM. The real value of MCP isn't the ability to talk to an AI; it's the ability to give that AI a set of hands—specifically, a set of tools that can interact with live infrastructure. I recently integrated the Logstash Server-side Log Pipeline API into my workflow. This isn't some experimental script I wrote over a weekend; it’s a production-grade implementation built on MCPFusion. It gives an AI agent direct access to several critical Logstash endpoints through a controlled, sandboxed environment. The Triage Workflow: A Real Scenario Let's walk through how this actually changes the debugging loop. Imagine you have a spike in ingestion lag. In the old way, you’d be digging through terminal history. In the new way, your agent acts as an extension of your SRE toolkit. 1. Initial Health Check Instead of parsing raw

Two lines of code. Same variable. Same operator. Completely different behavior. a = [ 1 , 2 , 3 ] b = a b += [ 4 ] # line A print ( a ) # [1, 2, 3, 4] x = 1 y = x y += 1 # line B print ( x ) # 1 Line A changes a . Line B does not change x . The only difference is whether the variable holds a mutable or immutable object. To understand why this happens, you need to understand how Python actually represents variables internally. Variables Are Not Boxes The box metaphor is how most introductory programming courses explain variables: a variable is a box that holds a value. You put 5 into the box called x . Later you can replace it with 10. In Python this metaphor is accurate for immutable types and dangerously misleading for mutable types. The more accurate model: a Python variable is a name that is bound to an object. The object exists independently of the name. Multiple names can be bound to the same object. Binding a name to a new object does not affect the old object or other names that reference it. You can inspect this directly: a = [ 1 , 2 , 3 ] b = a print ( id ( a ) == id ( b )) # True -- same object, two names x = 5 y = x print ( id ( x ) == id ( y )) # True -- both point to integer object 5 Both cases start the same: two names pointing to the same object. What happens next depends on whether you mutate the object or rebind the name. Two Fundamental Operations Every operation on a Python object falls into one of two categories. Mutation : the object at a given memory address is modified. All names pointing to that address see the change. Rebinding : a name is pointed at a different memory address. Other names pointing to the original address are unaffected. List methods like .append() , .extend() , .sort() , and item assignment lst[i] = x are mutations. Assignment with = is rebinding. The += operator is either mutation or rebinding depending on whether __iadd__ is implemented and the object is mutable. Tracing Through the Object Graph a = [[ 1 , 2 ], [ 3 , 4 ]]

Remember the days when we used to dump all our CSS and JavaScript into a single index.html file? That's exactly what a "Mega-Prompt" is today: an unmanageable monolith. A few weeks ago, while working on the orchestration of Vibrisse Agent (my local AI agent), I hit this exact wall. I was trying to stabilize a complex task by adding instructions to a 500-line system prompt. The more rules I added, the more the model forgot the older ones. The industry has sold us the myth of the Mega-Prompt. Those famous "50 ultimate prompts" or massive blocks of incantatory text are a technical dead end. Creative writing doesn't scale in production. As a web developer, my conviction is simple: to build reliable applications, we must stop "talking" to the machine and start configuring it. This is the shift from Prompt Engineering to Context Engineering . Context Engineering: Typing and Structure The first mistake with LLMs is mixing instructions (the logic) and context (the data) into an unstructured stream of text. It's the cognitive equivalent of spaghetti code. The solution? A strict separation of concerns. A highly effective technique (documented by Anthropic, but applicable to any model, including local SLMs), is XML Tagging . Here is the "dirty" approach (classic chat): You are a security expert. Analyze this authentication code, be strict, don't write a summary, check for XSS and SQLi vulnerabilities. Here is the code: function login() { ... } And here is the "engineering" approach: <role> Application Security Expert </role> <instructions> 1. Analyze the code provided in <context> . 2. Identify vulnerabilities (focus: XSS, SQLi). 3. Do not produce an introductory summary. </instructions> <context> function login() { ... } </context> Typing the language via tags creates clear boundaries. The model knows exactly where the directive is and where the data is. The Power of Exemplars (Few-Shot Prompting) Even with clear instructions, AI can drift in output format or tone. This is wh

I wanted two things: short links under my own brand (every link I share points traffic back to my site ), and a real excuse to run a complete system on the edge — DNS, distributed compute, storage, auth and a dashboard — in production, at zero infrastructure cost. The result is flino.link : a shortener that responds in under 10 ms from 300+ locations, runs entirely on Cloudflare's free tier, and whose only expense is the domain: $4.68 a year. This post covers the design decisions, which is where the interesting parts are. The architecture in 30 seconds A single Cloudflare Worker serves the whole domain: GET /<slug> — the hot path. One read from Workers KV (globally replicated) and a 302 redirect. Nothing else touches that path. /api/links — a REST API with Bearer auth to create, list and delete links. /admin — a single-page dashboard served as inline HTML from the Worker itself. No framework, no build step. A Durable Object with embedded SQLite keeps per-slug click counts. No servers, no containers, no database to manage. The whole Worker is three TypeScript files and zero runtime dependencies. Why a dedicated domain? My first idea was to hang the shortener off a route on flino.dev . Bad idea: shorteners attract abuse — spam, phishing — and their domains sooner or later end up on blocklists. If that happens, I don't want it dragging my main domain down with it. A separate domain isolates that reputation risk completely, and a short .link costs less than a coffee per year. KV for links, a Durable Object for counters This is the central design decision. Workers KV is perfect for a shortener's access pattern — read-heavy, write-light, reads served from the edge — but its writes are eventually consistent : two concurrent increments in different datacenters would clobber each other. For counting clicks, it's useless. A Durable Object solves exactly that: it's a single global instance with transactional SQLite storage. Every increment, no matter which datacenter it comes

Shipped this week Workflows are now a first-class Bizbox primitive — PR #86 · v2026.603.0 The biggest drop this week. @DennisDenuto landed Workflows as a company-scoped concept that sits alongside issues and routines — not shoehorned into either. What that means in practice: Google ADK-backed execution — workflow pipelines run as ADK agents, with phase state persisted as run records. Human handoffs baked in — pipelines can pause and wait for a human before resuming. Deliverables that survive — artefacts from each run are persisted and surfaced in the UI. A pipeline graph in the UI — topologically ordered, showing live phase state and console output. This is the foundation. More on what we can build on top of it below. Workflow human-handoffs now route through ClickUp — PR #91 · v2026.605.0 The day after Workflows landed, @angelofallars wired up the last kilometre: when ADK Python code calls input() inside a pipeline, Bizbox now intercepts that call and sends a ClickUp message to collect the human reply — instead of blocking the process forever. A few things that were fixed along the way: input() monkey-patching now works consistently across Python environments (was silently failing in some setups). Failed workflow runs no longer submit deliverables. You only see artefacts from runs that actually completed. ClickUp awaiting-human bridge adapter ships as a pure plugin — PR #78 · v2026.601.0 This one technically crossed the line on the last day of May (23:56 UTC, 31 May), so it's in scope. @ralphbibera ported the ClickUp transport and adapter as a genuine plugin — implementing the AwaitingHumanBridgeAdapter registry interface — without touching bridge core at all. What that gives you: ClickUp works through the same provider-agnostic layer as any future provider (Slack, Discord, whatever comes next). The core doesn't know ClickUp exists. Included: send/poll/reaction transport, message templates for request_confirmation and ask_user_questions interactions, brain_is_think

Tired of squinting at VS Code’s stacked merge editor? MergeForge brings a JetBrains-style three-pane conflict resolver to VS Code and Cursor — and pairs it with an AI assistant that actually reads your repository before it suggests a fix. The problem We’ve all been there. You’re halfway through a rebase. Git stops. Twelve files are conflicted. You open one in VS Code… and get that familiar stacked layout: Incoming, Current, and a result pane that somehow still feels like a puzzle with half the pieces missing. If you ever used WebStorm or IntelliJ, you know how good merge tools can feel: Your side on the left Their side on the right The result in the middle Gutter arrows that just… work In VS Code land, that flow never quite arrived. You click Accept Current, Accept Incoming, Accept Both, and hope nothing important got flattened. Word-level diffs? Authorship? A clear “who wrote this chunk?” signal? Often missing when you need them most. And when AI entered the chat, a lot of tools treated conflicts like isolated text blobs: “Here are the <<<<<<< markers. Good luck.” But real merges need context. What was the branch trying to do? What does the surrounding file look like? Who touched this last? Without that, “AI resolve” is just confident guessing. I wanted the JetBrains merge experience — inside VS Code and Cursor — with an assistant that behaves more like a careful teammate than a slot machine. So I built it. The solution: MergeForge MergeForge is an open-source VS Code / Cursor extension that turns conflicted files into a proper three-pane visual merge. Layout: Left Center Right Yours (local) Result (editable, seeded from the merge base) Theirs (incoming) Panes scroll together. Chunks connect with bands. Gutter controls let you accept, ignore, or blend sides without fighting the UI. When you’re done, Apply writes the result and stages it with git. If you prefer Cursor, you’re covered too. The editor works the same; for AI features you plug in your own provider key (

Unity is replacing its scripting runtime. Not tweaking it, replacing it. The Mono runtime that has sat under every line of C# you have written in Unity for years is being retired in favour of Microsoft's CoreCLR. It is the most significant change to Unity's foundation in over a decade, and it is no longer a distant roadmap item: the Unity 6.7 public alpha is out now, with CoreCLR arriving as an experimental option. Most of the coverage treats this as good news wrapped in a version number. It is good news. But if you run a real project, the interesting questions are the practical ones: when does this actually reach me, what changes underneath my game, and what is going to break. Here is that read, from the perspective of a studio that plans and runs Unity upgrades for a living. What CoreCLR Is, and Why Unity Is Doing It Unity has been running a heavily customised fork of Mono for years. That custom fork is the reason Unity has always trailed the wider .NET ecosystem: while the rest of the C# world moved to modern runtimes, garbage collectors, and language features, Unity developers looked on from behind a runtime that could not easily keep pace. CoreCLR is Microsoft's modern, open-source .NET runtime, the same one that powers current .NET. Moving to it does three things at once: it gives Unity a far more capable runtime and garbage collector, it unlocks modern C# and the current .NET library ecosystem, and it dramatically improves iteration time, the write-save-wait-for-domain-reload loop that quietly eats hours of every Unity developer's week. Unity 6.8 is expected to target .NET 10 and C# 14. To make room for it, Unity has done something telling: it paused new work on animation and world-building workflows specifically to concentrate engineering on this migration and on architectural stability. That is a company choosing foundations over features, which is the right call, and a sign of how big this change is. The Timeline That Actually Matters The migration lands a

Unity 6.5 arrived in mid-June 2026, and if you skimmed the announcement you would be forgiven for filing it under "minor update." There is no single headline feature to point at. But 6.5 is more consequential than it looks, because the important changes are subtractions. Several systems that a lot of production projects still lean on have been marked for removal, and the countdown has started. This post is the read we would give a client: what actually changed, which parts matter depending on where you are in your development cycle, and a straight answer on whether to upgrade. First, What Kind of Release This Is Under the Unity 6 model there are two kinds of release, and the difference decides most of the upgrade question on its own. Update releases (6.4, 6.5, 6.6) carry the newest features, platform support, and performance work. Unity describes 6.5 as a Supported release with the same stability and critical-fix quality as an LTS, right up until the next release lands. They are aimed at projects in active or mid-cycle development. LTS releases (6.3 LTS, and 6.7 LTS later this year) are the ones to lock production on. 6.3 LTS is supported with fixes and platform updates through December 2027. They are the safe harbour for a title that is shipping or about to. One date to note if you have not moved recently: Unity 6.0 LTS support ends in October 2026. If you are still on it, that is the real deadline on your calendar, not 6.5. The Real Story: What Is Being Deprecated This is the part worth your attention. None of these break your project today, but each one is a planning item. The Built-In Render Pipeline is deprecated. BIRP still works, and Unity has committed to supporting it through the full 6.7 LTS lifecycle, but it will become obsolete in a future release. If your project is still on BIRP, this is your signal to scope a migration to URP while it is a controlled piece of work rather than something forced on you by an engine upgrade you cannot avoid. Unity has add

Amid all the noise about dockershim, one thing got lost: the everyday workflow of building an image with Docker and running it on Kubernetes never changed. Docker is still an excellent build tool, Kubernetes still runs OCI images, and on Ubuntu the loop is clean. Here it is end to end. 1. A build-friendly Dockerfile Multi-stage keeps the runtime image small and the attack surface low — this matters more on Kubernetes, where you pull the image onto every node that schedules the pod: # build stage FROM golang:1.22 AS build WORKDIR /src COPY go.* ./ RUN go mod download COPY . . RUN CGO_ENABLED = 0 go build -o /out/api ./cmd/api # runtime stage — distroless, no shell, tiny FROM gcr.io/distroless/static:nonroot COPY --from=build /out/api /api USER nonroot:nonroot EXPOSE 8080 ENTRYPOINT ["/api"] 2. Build and push with Docker on Ubuntu Use buildx (bundled with modern Docker) so you can build multi-arch — worth it if any nodes are arm64: docker buildx build \ --platform linux/amd64,linux/arm64 \ -t registry.example.com/api:1.4.2 \ --push . Tag with an immutable version, never rely on :latest . Kubernetes caches images per node; :latest makes "which build is actually running?" unanswerable and breaks rollbacks. 3. A deployment that behaves in production apiVersion : apps/v1 kind : Deployment metadata : name : api spec : replicas : 3 selector : { matchLabels : { app : api } } template : metadata : { labels : { app : api } } spec : containers : - name : api image : registry.example.com/api:1.4.2 # the exact tag you pushed imagePullPolicy : IfNotPresent ports : [{ containerPort : 8080 }] resources : requests : { cpu : " 100m" , memory : " 128Mi" } limits : { memory : " 256Mi" } readinessProbe : httpGet : { path : /healthz , port : 8080 } initialDelaySeconds : 3 livenessProbe : httpGet : { path : /healthz , port : 8080 } initialDelaySeconds : 10 The readinessProbe is the piece people skip and regret: without it, Kubernetes sends traffic to a pod before your app is listening, and

The wrong way to install Docker on Ubuntu is the one that looks easiest: sudo apt install docker.io . That package exists, it installs, and it runs a container. It is also whatever version happened to be frozen into the archive when 26.04 was cut, it lags the real releases by months, and it ships without the Compose and Buildx plugins you will want by the end of the week. Use Docker's own apt repository instead, and this is the post I keep open so I do not re-derive the repo setup from memory each time. This is short on purpose. The steps are the official ones, and the only place worth slowing down is step 5, where adding yourself to the docker group quietly hands out root. That tradeoff is the part most guides skip, and it is the one thing here actually worth reading twice. TL;DR Remove any distro docker.io / containerd packages, add Docker's GPG key and the deb822 .sources repo, then sudo apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin . Verify with sudo docker run hello-world . Add yourself to the docker group to drop the sudo (it is root-equivalent, more below). Prerequisites Ubuntu 26.04 (Resolute Raccoon), server or desktop, on amd64 or arm64 . A user with sudo. If you are still on root, create a sudo user first . Outbound HTTPS to download.docker.com . 1. Remove the distro Docker packages first Ubuntu ships its own docker.io , docker-compose , and containerd packages, and any of them will fight the official ones over the same files and the same containerd socket. Clear them out before you add Docker's repo. This is safe on a fresh box because there is nothing to lose yet; on a box that already ran the distro Docker, it removes the packages but leaves your images and volumes in /var/lib/docker alone. sudo apt remove $( dpkg --get-selections docker.io docker-compose docker-compose-v2 docker-doc podman-docker containerd runc | cut -f1 ) The dpkg --get-selections wrapper is just so the command does not error out on pac

I wanted to use web-based AI chatbots — Claude, Gemini, ChatGPT, Qwen — for actual development work, not just Q&A. The free tiers are generous, and I didn't want to be locked into a single coding agent or pay for API access just to get an assistant to touch my code. But the moment you try to actually use a web chat for real dev work, you hit the same wall every time: you either paste in your whole codebase manually every session, or you give up and reach for a paid extension with an API key behind it. So I built AI Bridge — a CLI tool that bridges a local codebase and any browser-based AI chatbot. No API keys, no extensions running in the background, no vendor lock-in. You pack your code, paste it into whichever AI chat you're using, and apply the changes back with a command. Why not just use Copilot, Cursor, or an API key? Coding agent apps and API-based tools work, but they come with tradeoffs I wanted to avoid: Web-based AI chat plans are usually more generous on the free tier than API usage I'm not locked into one provider — I can switch models mid-project depending on which one is handling a task better There's no background agent or extension — it's just a CLI and whatever chat tab I already have open The tradeoff is that browser chats don't have direct filesystem access. AI Bridge closes that gap without turning it into full manual copy-pasting. How it works There are two modes, depending on project size. Simple Mode is for projects small enough to fit in a single prompt. You pack the codebase, upload it along with a couple of prompt templates, and apply the AI's response back to your files: dotnet tool install --global Tools.AIBridge cd /path/to/your-project ai-bridge init ai-bridge pack # Upload ai-bridge/1-SimpleMode/*.md + the generated context files to your AI # Copy the AI's response, then: ai-bridge apply --paste Advanced Mode is for larger codebases, where uploading everything every time burns tokens and adds noise. Instead, you generate a one-time in

Como eu mostro que estou contribuindo? Posso colocar no meu LinkedIn? E no meu currículo, como faço? Foi a partir dessas dúvidas que eu elaborei esse guia pra você que quer contribuir do seu jeito e mostrar às empresas e às pessoas, de forma clara e estratégica, o que você está fazendo. Vamos lá? 👇 Por que eu deveria mostrar no LinkedIn? LinkedIn é a porta de entrada para o mundo corporativo no Brasil e no mundo. É por meio dele que você mostra "trabalho". E tem mais: não é só experiência remunerada que conta como evidência de que você tem conhecimento e prática, mas também tudo o que você constrói de forma voluntária , seja tirando dúvida de alguém, participando de um projeto open-source ou escrevendo sobre o que aprendeu. Recrutador não lê currículo pensando só em carteira assinada. Lê pensando em capacidade . Você contribui com algo para a comunidade e quer colocar isso no seu perfil. Existem 3 formas que você pode usar, e elas podem ser usadas todas juntas ou só uma. Escolha aquela que fizer mais sentido pro seu perfil ou busque por outras pessoas que você admira dentro da comunidade e veja como elas colocaram no próprio perfil. 1. Seção de Experiência Use como experiência sempre que estiver contribuindo de forma profissional pra uma área que você busca. Se você participa de contribuições no GitHub, seja através de código, documentação ou outra forma, use como experiência. Pessoas que também estão ajudando na moderação ou administração (community managers) podem destacar as responsabilidades ou resultados das suas ações por aqui. Exemplo de como preencher no LinkedIn: Cargo: [cargo que você faz] Open Source Empresa: [Nome do projeto/organização] Tipo de emprego: Meio período (ou Voluntário) Local: Remoto, Brasil Descrição: - Contribuí com [X] pull requests na documentação do projeto [Nome], focando em clareza para novos contribuidores. - Revisei issues abertas e sugeri melhorias de acessibilidade em componentes de UI usando [ferramenta/stack]. - Participei de re

It started with the dumbest problem in computing: I'm in bed, a movie is playing on my laptop across the room, and pausing it requires physically getting up . Every existing fix annoyed me in some way. Remote desktop apps are overkill and route through someone's cloud. Remote-control apps want accounts, subscriptions, or a native app install. I just wanted my phone to poke my laptop over my own Wi-Fi. So I built LapDeck : one Node.js process on the laptop, a PWA on the phone. Scan a QR code once and your phone becomes an app launcher, touchpad, keyboard, live screen viewer, and media/power remote. MIT licensed, plain JavaScript, no build step. This post is about the four problems that turned out to be more interesting than I expected. The architecture in one line Phone (PWA) ── WebSocket + MJPEG over Wi-Fi ──► Node.js agent (Windows) The agent serves the PWA, exposes a WebSocket for commands, and streams the screen as MJPEG. The protocol is deliberately dumb JSON envelopes — no protobuf, no RPC framework — so a native Android client or a CLI script can speak it in an afternoon. Windows-specific glue (volume, brightness, power, capture) is isolated in src/win/ , so a macOS/Linux port only has to reimplement that layer. Problem 1: mobile keyboards lie to you The obvious way to build a remote keyboard is to listen for keydown and forward key codes. On mobile, this collapses immediately: swipe typing, autocorrect, and IME composition don't emit per-key events. Android will happily tell you every key is keyCode 229 . The fix: stop listening to keys entirely. I keep a hidden input, and on every input event I diff the field's value against the last known state — compute the common prefix, then emit "delete N chars, type this string" to the laptop. Swipe-type a whole word and the laptop receives one clean text insertion. IME composition, autocorrect rewrites, emoji — all just become diffs. The lesson generalizes: on mobile web, treat the text field as the source of truth, n

I wired an AI code reviewer into CI, felt clever, and then looked at the bill after a busy week of PRs. Every push, every commit, sending full diffs to a big frontier model. It added up faster than I expected, and most of what it was reviewing was formatting changes and README edits that did not need a genius reading them. So I rebuilt it as two tiers, and the cost dropped hard without losing the catches that mattered. The idea is simple. Do not send everything to the expensive model. Use a cheap model as a bouncer that decides what is even worth escalating, and reserve the big model (with caching turned on) for the files that could actually hurt you. Tier one: a cheap triage pass The first tier looks at the diff and answers one question: is anything here risky enough to justify a real review? That is a classification task, and classification does not need a frontier model. I run this tier on a small local model. On my own machine that is Ollama with qwen2.5-coder, but in CI it can be a self-hosted small model or the cheapest cloud tier your provider offers. The job is triage, not judgment. The triage prompt is deliberately narrow. I do not ask it to review. I ask it to route: You are a triage filter for code review. For the diff below, output JSON only: { "risk": "low" | "high", "reason": " <one short phrase > " } Mark "high" if the diff touches: auth, access control, money/token math, cryptography, SQL or shell string building, deserialization, file paths, network calls, or anything that changes who can do what. Mark "low" for formatting, comments, docs, tests, renames, and config bumps. DIFF: <diff here > A small model is perfectly good at "does this touch auth or money." When it says low, CI posts a one-line "no high-risk changes detected" and stops. No expensive call. In practice that shortcuts the majority of PRs, because most PRs really are docs, tests, and plumbing. Tier two: the big model, but only on the risky files, with caching When tier one says high, t

why-we-open-sour-c1f013bf.webp alt: Building Digital Identity Tools - Why We Open-Sourced Our SSI SDK relative: false Self-Sovereign Identity (SSI) is a framework that allows individuals and organizations to control their own digital identities and share verified credentials without relying on a central authority. This paradigm shift empowers users with greater privacy and control over their personal data, while also providing robust mechanisms for verifying the authenticity of credentials. What is Self-Sovereign Identity (SSI)? SSI is built around the concept of decentralized identifiers (DIDs) and verifiable credentials. DIDs are unique identifiers that are controlled by the entity they represent, enabling them to manage their own identity data. Verifiable credentials are digital assertions that can be issued by one party and verified by another, ensuring the authenticity and integrity of the information shared. Why did we open-source the SSI SDK? Open-sourcing the SSI SDK was a strategic decision driven by several factors. First, fostering innovation within the community is crucial for advancing the field of digital identity. By making our SDK available to everyone, we encourage collaboration and experimentation, leading to new ideas and improvements. Second, promoting transparency is essential for building trust in digital identity systems. Open-source projects allow others to inspect the codebase, understand how it works, and identify potential vulnerabilities. This transparency helps build confidence in the security and reliability of the SDK. Finally, enabling a broader community to contribute to and benefit from secure digital identity solutions aligns with our mission to democratize access to these technologies. By lowering the barriers to entry, we hope to empower more developers and organizations to adopt and improve upon our work. What are the key features of the SSI SDK? The SSI SDK provides a comprehensive set of tools for building digital identity app

TL;DR: Use per-test coverage data to build a reverse map (file → tests that touch it). Git diff + map lookup = run only relevant tests. 43min → 4min CI time. The Problem Everyone Has Your test suite runs for 45 minutes. You change one file. Should you: Run all 2,000 tests? (Safe but slow) Run tests with matching filenames? (Fast but broken) Manually tag tests? (Gets stale immediately) We tried all three. They all failed. The Insight: Stop Guessing, Start Measuring What if we just measured what each test actually executes? Coverage tools have done this for years: { "src/MyComponent.js" : { "statements" : { "0" : 5 , "1" : 12 , "2" : 0 } } } Key insight: Coverage tools report per test run, not per test file. All we needed: save coverage after each individual test. The Architecture (5 Steps) Step 1: Instrument the Code // Build config (webpack/vite/rollup/etc) export default { plugins : [ process . env . COLLECT_COVERAGE && coveragePlugin ({ include : ' src/**/* ' , exclude : [ ' **/*.test.* ' ] }) ] } Works with: Istanbul (JS), coverage.py (Python), SimpleCov (Ruby), JaCoCo (Java) Step 2: Collect Coverage Per Test // Test framework afterEach hook afterEach ( async () => { const coverage = getCoverageData (); saveCoverage ( `coverage- ${ testName } .json` , coverage ); }); Step 3: Build the Reverse Map const map = {} ; for (const coverageFile of allCoverageFiles()) { const testName = extractTestName(coverageFile); const coverage = JSON.parse(read(coverageFile)); map [ testName ] = [] ; for (const [ sourceFile , data ] of Object.entries(coverage)) { if (wasExecuted(data)) { map [ testName ] .push(sourceFile); } } } Example output: { "tests/user-profile.test.js" : [ "src/components/Profile.jsx" , "src/components/Card.jsx" , "src/utils/formatters.js" ] } The magic: The test told us what it executed. No parsing, no guessing. Step 4: Detect Tests CHANGED = $( git diff origin/main...HEAD --name-only ) TESTS = $( lookupTestsInMap " $CHANGED " ) npm test $TESTS Step 5: Auto-Up

This is a submission for DEV's Summer Bug Smash: Clear the Lineup powered by Sentry . Project Overview I recently deployed the Dograh AI voice agent (named Zoya) live on my production website, Mobile One Media , to handle client inquiries for our 4K video production, audio engineering, and app development services. For the first 48 hours, the agent worked flawlessly. However, on day three, it suddenly stopped responding on the live site. Users were experiencing complete hang-ups when trying to navigate the service menu. This wasn't a local testing issue; this was a live production fire that needed immediate debugging and a permanent fix. Bug Fix or Performance Improvement The Problem: Issue: After ~48 hours of continuous uptime, the live Dograh AI widget on mobileonemedia.com began silently failing, resulting in infinite loading states and dropped user sessions. Impact: 100% of new agent interactions were failing, directly blocking potential client leads from contacting our media production services. Root Cause: A Docker container configuration issue combined with a system prompt misalignment. The agent's Docker environment variables were not properly persisting the workflow state, and the system prompt was failing to initialize correctly after container restarts, causing the agent to lose conversational context. Code and Video Demo GitHub Pull Request: https://github.com/dograh-hq/dograh/pull/287 Watch the live agent in action: https://youtu.be/pKUxtq8sKDs?si=r1s2LK7zGIzpd2Ry The Fix Summary: Archived the old, messy agent configuration that was causing the Docker and prompt issues. Built a brand new, clean agent setup from scratch with proper architecture. Rebuilt the Docker container configuration with proper environment variable persistence and volume mounting. Fixed the system prompt initialization sequence to ensure it loads correctly on container startup. Added health check endpoints to monitor agent readiness before accepting user connections. My Improvements

-- looks routine in review, locks your table in production: CREATE INDEX idx_orders_customer ON orders ( customer_id ); ALTER TABLE users ALTER COLUMN email SET NOT NULL ; Both of those statements hold a lock that blocks traffic while they scan or build against the table. On a small table you never notice. On a busy production table it is downtime, and a diff review does not catch it because the SQL looks fine. pg-migration-guard is a free tool that reads the migration and flags these before they reach production: $ pg-migration-guard V42__orders.sql WARN IDX01 CREATE INDEX without CONCURRENTLY [becomes a blocker on a large or busy table] Why: Plain CREATE INDEX takes a lock that blocks all writes until the build finishes. Safe: CREATE INDEX CONCURRENTLY idx ON tbl (col); -- outside a transaction WARN NN01 SET NOT NULL scans the whole table under ACCESS EXCLUSIVE Safe: ADD CONSTRAINT c CHECK (col IS NOT NULL) NOT VALID; VALIDATE CONSTRAINT c; then SET NOT NULL; Summary: 0 blocker, 2 warn, 0 advisory Why migrations bite Whether a Postgres migration is safe has almost nothing to do with intent and everything to do with locks. A migration is dangerous when it holds a strong lock while it scans or rewrites a large table. ACCESS EXCLUSIVE blocks reads and writes; SHARE blocks writes. The change that reads fine in review is the one that quietly takes that lock. Put it in CI The most useful place for this is the pull request, so a risky migration fails the build before anyone merges it. There is a GitHub Action: name : migration-guard on : pull_request : paths : [ " db/migration/**.sql" ] jobs : guard : runs-on : ubuntu-latest steps : - uses : actions/checkout@v4 - uses : actions/setup-python@v5 with : python-version : " 3.x" - uses : technical-turtle/pg-migration-guard@v1 with : path : db/migration fail-on : blocker Each finding shows up as an inline annotation on the diff, so the author sees exactly which line is the problem and what the safe rewrite is. Or run it locall