The art of simplicity

Welcome to the first post in my series on getting the most out of GitHub Copilot in the terminal. We'll kick things off with one of the most important things to understand: the different modes Copilot CLI operates in, and when to reach for each one. A quick intro to GitHub Copilot CLI GitHub Copilot CLI is a terminal-native coding agent — not just a chat wrapper. It can plan complex tasks, edit files, run tests, and iterate autonomously, all without leaving your terminal. But to get the most out of it, you need to understand how to control how much autonomy you give it at any point in time. That's exactly what the different modes are for. You cycle through the main modes using Shift+Tab . A mode indicator in the CLI's footer tells you which one you're currently in. The three main modes 1. Standard Mode — The default When you launch copilot , you start in standard (interactive) mode. This is the classic back-and-forth: you submit a prompt, Copilot responds o...

Between all this AI craziness, we often forget to appreciate the small tools and features that make our lives easier. Such  a feature is Central Management Servers (CMS) , a built-in SQL Server feature that lets you manage a whole fleet of instances from one place. Let's walk through what it is, how to set it up, and when it'll actually make your life easier. So, what is a Central Management server? At its core, CMS is a SQL Server instance that acts as your hub for organizing and talking to other SQL Server instances. You register your other servers under it, group them however makes sense (by environment, team, region — you name it), and then query all of them at once. The metadata about your registered servers gets stored in the msdb database on the CMS host. Nothing fancy — it's just a central directory that SSMS knows how to use. Setting it up in SSMS Here's how to get going in SQL Server Management Studio: Step 1: Open the Registered Servers panel ...

The timeout appeared without warning. A migration pipeline that had run fine in staging suddenly ground to a halt in production, throwing lock wait timeouts across multiple worker threads. The application was querying and writing to the same table, and somewhere in that dance of reads and writes, things had seized up entirely. Here is a walk through the investigation, from the first diagnostic query all the way to the fix — along with an explanation of why it worked. Find the blocker The first tool in any SQL Server lock investigation is sys.dm_exec_requests joined against sys.dm_exec_sessions . This query shows you every session that is currently blocked, who is blocking it, and what SQL both parties are running: A second query dug into the exact lock modes held on the specific table in question: The output told the story The results were unambiguous. Three sessions. One blocker. Two victims. Blocking Blocked Wait type ...

We recently discovered a bug in one of our legacy ASP.NET MVC applications — the kind that doesn't throw an exception, doesn't log a warning, and doesn't announce itself in any way. It simply silently drops a filter on the floor. Unfortunately, that filter happened to be a security control. Here's the story of what happened, why it happens, and what we're doing about it. Remark: If you don’t have any legacy .NET Full Framework ASP.NET MVC apps remaining (good for you), you can stop reading. What we were trying to do Our application uses action filters for authorization. We had a global filter registered for all controllers that enforced a baseline set of access rules. For certain controllers, we wanted a stricter policy, so we added a local filter attribute directly on those controllers. Both filters shared the same attribute type. The attribute was decorated like this: The intention was clear: the local, more restrictive filter on the controller would...

I only recently started using the ASP.NET Core's minimal API style, but an annoying thing I already encountered is the "long parameter list" problem. Route handlers that accept five, six, or seven parameters start to feel unwieldy fast. The good news is that a solution exists through the [AsParameters] attribute, introduced in .NET 7,  that gives you a clean way out. The problem it solves Minimal APIs are appealing precisely because they're lightweight — no controllers, no ceremony. But that simplicity starts to break down as your endpoints grow more complex. Consider this example endpoint: That's eight(!) parameters before you've written a single line of business logic. It's hard to read, hard to test, and grows more painful every time requirements change. Enter [AsParameters] [AsParameters] lets you group related parameters into a plain C# class or record and bind them all at once. ASP.NET Core inspects the type's constructor and public ...

Minimal APIs are the recommended approach for building fast HTTP APIs with ASP.NET Core. They allow you to build fully functioning REST endpoints with minimal code and configuration. You don't need a controller but can just declare your API using a fluent API approach: This makes it very convenient to build your APIs. However you need to be aware that a lot of magic is going behind the scenes when using this approach. And this magic can bite you in the foot. Exactly what happened to me while building an autonomous agent invoked through a web hook. The code In my application I created the following API endpoint using the minimal API approach: The minimal API injects an AzureDevOpsWebhookParser that looks like this: Nothing special… The problem The problem was when I called this endpoint, it failed with the following error message: InvalidOperationException: TryParse method found on AzureDevOpsWebhookParser with incorrect format. Must be a static method with for...