Posts

My newest best friend “Microsoft Copilot CLI”

-
Image
  The command line has always been the fastest way to work— if you already know exactly what to type. Microsoft Copilot CLI changes that equation completely. It brings Generative AI directly into your terminal , turning the shell into an intelligent collaborator instead of a memory test. This isn’t autocomplete. This isn’t docs-on-the-side. This is thinking, reasoning, and acting—without leaving your terminal . Let’s break it down. 1. What Is Copilot CLI? The Microsoft Copilot CLI is the bridge between terminal efficiency and AI-powered reasoning . Instead of jumping between your terminal, Chat Client, and documentation tabs, you stay focused—and let Copilot do the heavy lifting. At its core, Copilot CLI lets you: Ask questions in natural language Generate commands you don’t remember Understand commands you inherited Reason over local project files Interact with cloud and DevOps resources Getting It Most developers sta...
Post a Comment
Read more

Modern HTML Replaced Your UI Framework (You Just Didn’t Notice)

-
Image
You Don’t Need a UI Framework Anymore Modern HTML & CSS Are the UI Library For years, the default answer to “How do I build a UI?” has been: Use React Use Angular Use a component library like Telerik, MUI, or Bootstrap That advice made sense 10 years ago . It makes far less sense today. Modern HTML and CSS have quietly absorbed huge portions of what UI frameworks used to justify themselves for — and most teams haven’t noticed. This post shows how far plain HTML + CSS has come, how much payload you can avoid , and why building a native, framework-agnostic UI library is now not only possible — but often the better architectural choice. This is a continuation of a previous post, Beyond AI: Why HTML Elements Still Boost Productivity in Blazor The Hidden Cost of “Just Use a Framework” Before we even look at code, let’s talk about downloads . Typical UI stack sizes (approximate, min+gzip) Stack Download Size React + React DOM ~120–150 KB React + common UI libs 300–600 K...
Post a Comment
Read more

Why Repository Abstractions Usually Hurt Blazor Apps More Than Help “You didn’t decouple EF Core. You just hid it badly.”

-
Image
 “You didn’t decouple EF Core. You just hid it badly.” I’ve built this architecture. More than once. Early in my Blazor projects, adding repository abstractions felt like the responsible thing to do. The code looked clean. The layers were clear. Code reviews were easy. Then the app grew. The team changed. Performance started to matter. That’s when the repository layer stopped helping—and started getting in the way. This article isn’t about theory. It’s about what I’ve learned the hard way, maintaining long-lived Blazor applications. Why I Used Repositories (And Why They Felt Right) I didn’t introduce repositories because I was careless. I did it because: Books recommended them Talks showcased them Juniors expected them “Clean Architecture” diagrams normalized them And early on? They worked. That’s the trap. The Year-Two Problem The pain never shows up in month three. It shows up when: Queries need tunin...
Post a Comment
Read more

Stop Hardcoding AppSettings: A Clean Pattern for Blazor Environment Configuration

-
Image
  If your Blazor app works locally but breaks in Azure, there’s a good chance configuration is the real bug. Blazor developers often treat configuration as a startup concern —something you wire up once and forget. That works… until you add environments. or feature flags. or secrets. or a second app. Then the configuration quietly turns into a distributed liability . Let’s talk about why hardcoded AppSettings patterns don’t scale—and a cleaner, environment-aware approach that actually survives real projects. The Common (But Fragile) Pattern Most Blazor apps start like this: // appsettings.json {   "InCounter": 5,   "FeatureFlagStyleTable": true } Var styleTable = configService.Value.FeatureFlagStyleTable; At first, this feels fine. Then you add: appsettings.Development.json appsettings.Test.json appsettings.Production.json Azure App Service settings Feature flags Secrets in Key Vault Suddenly: ...
Post a Comment
Read more

Stop Asking for Real-Time Data (You Probably Don’t Need It) Or: Why “real time” is one of the most expensive words in software architecture.

-
Image
  The uncomfortable truth After decades of building enterprise systems, here’s an observation that makes some people uncomfortable: Most people who ask for “real-time” data updates don’t actually need real time. What they want is confidence , responsiveness , and trust — not millisecond precision. And yet, the moment the phrase real time enters a requirements meeting, costs go up, architectures get complicated, and teams quietly inherit a system they now have to babysit forever. What people say vs. what they actually mean When someone says: “We need this data in real time.” They usually mean: “I don’t want stale data.” “I don’t want to refresh the page.” “I want to react quickly.” “I want to trust what I’m seeing.” None of those requires true real-time infrastructure. They require fast-enough data and good UX . Once you cross into true real time , you introduce: Persistent connections Stateful servers Fan-out scaling challenges Reconnection logic O...
Post a Comment
Read more