The art of simplicity

Git submodules wasn't a feature I used that often. Until we started to use it as a way to share context( agent.md ) and skills between our projects. That's the moment we discovered that Git submodule support was missing in Visual Studio and we had to fall back to the terminal typing git submodule update --init --recursive With Visual Studio 18.9, that finally changes. Submodules are now a first-class part of the Git experience in the IDE. What was missing Submodules are genuinely useful. They let you pull a shared library, an SDK, or a set of build scripts into your repository without copy-pasting code around. You could fall back to the command line, but the tooling was missing. Visual Studio would show you a submodule as a plain folder, with no indication of its state, no way to add or remove one from the UI, and no understanding of how it related to the parent repository. Every actual submodule operation meant tabbing out to the command line. What you get now Open a...

After our fix yesterday, we got our Renovate pipeline up-and-running. However the next hurdle showed up quickly. Right after the SSL certificate fix, I got the pipeline green, but the log showed this warning: WARN: Azure: work item type does not exist in project (or the token lacks permission to it); skipping issue. The Dependency Dashboard needs a process that defines this work item type. Set one your project defines via the `azureWorkItemType` repo config option. (repository=Framework en Tooling/SOFACore) "workItemType": "Issue", "availableTypes": [ "Bug", "Task", "Quality of Service Requirement", "Scenario", "Risk", "Code Review Request", "Code Review Response", "Feedback Request", "Feedback Response", "User Story", "Test Case", ...

Recently I ran into a failing Renovate pipeline right after configuring it against our internal Azure DevOps server: "err": { "code": "UNABLE_TO_VERIFY_LEAF_SIGNATURE", "message": "unable to verify the first certificate; if the root CA is installed locally, try running Node.js with --use-system-ca" } Error: unable to verify the first certificate; if the root CA is installed locally, try running Node.js with --use-system-ca at TLSSocket.onConnectSecure (node:internal/tls/wrap:1748:34) at TLSSocket.emit (node:events:509:28) at TLSSocket.emit (node:domain:489:12) at TLSSocket._finishInit (node:internal/tls/wrap:1185:8) at TLSWrap.ssl.onhandshakedone (node:internal/tls/wrap:966:12) The root cause: Renovate runs on Node.js, and Node doesn't use the Windows certificate store by default. Our internal Azure DevOps server presents a certificate signed by our internal CA, and Node has no idea that CA exist...

Recently I ran into a nasty startup error after registering both AddDbContext and AddDbContextFactory for the same DbContext in an ASP.NET Core project: System.AggregateException: 'Some services are not able to be constructed' System.InvalidOperationException: 'Error while validating the service descriptor 'ServiceType: Microsoft.EntityFrameworkCore.IDbContextFactory`1[StartStopLijsten.ApiService.Data.StartStopDbContext] Lifetime: Singleton ImplementationType: Microsoft.EntityFrameworkCore.Internal.DbContextFactory`1[StartStopLijsten.ApiService.Data.StartStopDbContext]': Cannot consume scoped service 'Microsoft.EntityFrameworkCore.DbContextOptions`1[StartStopLijsten.ApiService.Data.StartStopDbContext]' from singleton 'Microsoft.EntityFrameworkCore.IDbContextFactory`1[StartStopLijsten.ApiService.Data.StartStopDbContext]'.' The app refuses to start, and although the message is clear why it refuses to start, it doesn't make it obvious how...

Recently I lost a good chunk of a day chasing an issue in our OWASP Dependency-Track container setup. The strange part: the problem had nothing to do with Dependency-Track itself. It was how I had configured it.   What went wrong I had pinned our docker-compose.yml to a snapshot tag, something like dependencytrack/apiserver:4-snapshot . In my head, a tag like that behaves like a version number: you pull it once, it stays what it is, and you move on. That assumption is wrong. Snapshot tags on Docker Hub are not static. They get overwritten every time a new build lands upstream. The 4-snapshot and 5-snapshot tags on the dependencytrack/apiserver and dependencytrack/frontend repositories are pushed regularly, sometimes daily. So the image I "pinned" last month is not the image I got today, even though the tag in my compose file never changed. Remark: The Dependency-Track docs are actually explicit about this: the latest tag always points to the latest stable ...

There's a moment when you're deep into an agentic coding session and you have to leave your desk (time to catch my train!). Normally that means the session just sits there, waiting, until you're back at your keyboard. Both Claude Code and GitHub Copilot CLI recently shipped a feature that fixes exactly this: you keep the session running locally, but you can check in, approve tool calls, and keep steering it from your phone or any browser. Let's look at how each one works. Claude Code: /remote-control In Claude Code, you enable this with a slash command inside a running session: /remote-control or the short form: /rc You can also start a session already remote-enabled: claude --remote-control or run a dedicated server process that can host multiple concurrent sessions: claude remote-control Whichever way you start it, Claude Code prints a session URL (and lets you press spacebar to show a QR code) that connects to claude.ai/code or the Claude app. ...