The art of simplicity

There's a moment when you clone or pull a repository on Windows and Git throws an error like this: error: unable to create file some/very/deeply/nested/path/to/a/file.ts: Filename too long Nothing wrong with your code, nothing wrong with the repo. It's Windows. Why does this happen? Windows has a default path length limitation of 260 characters (the infamous MAX_PATH ). Git operations that create files with a full path longer than that — cloning, checking out, pulling — will fail with this error. Repositories with deeply nested folder structures (think node_modules, or generated code) hit this constantly. The fix: enable long paths in Git Git has a config setting for exactly this: core.longpaths . You have two ways to set it, depending on your rights on the machine. System-wide (requires Administrator privileges): git config --system core.longpaths true User-level (no Administrator required): git config --global core.longpaths true If y...

Recently I was wiring up a YARP reverse proxy in front of a couple of Aspire-managed services: an API and an Angular frontend. Aspire gives you service discovery for free, so the obvious move is to point your YARP clusters at the logical service names instead of hardcoded URLs. My first attempt looked like this: "Clusters": { "api-cluster": { "Destinations": { "api-destination": { "Address": "https+http://api" } } }, "frontend-cluster": { "Destinations": { "frontend-destination": { "Address": "https+http://angular-frontend" } } } } The https+http:// scheme is the standard Aspire service discovery convention: try HTTPS first, fall back to HTTP. It works fine when you're resolving endpoints through HttpClient . Unfortunately YARP doesn’t like this configuration. After setting it up with these values ...

While doing some pair programming to integrate OpenTelemetry tracing to a .NET application, we had a discussion on how to use the ActivitySource . It looks simple. You new one up, give it a name, start an activity, done. The discussion started when we added a second ActivitySource with the exact same name in a different class. This made us wonder: "Are we duplicating traces now? Is this a memory leak? Do we need a singleton?" So we decided to dig deeper. This post is what we learned… What ActivitySource actually is ActivitySource is part of System.Diagnostics , not part of the OpenTelemetry NuGet packages. Microsoft built tracing primitives directly into the BCL, and OpenTelemetry's .NET SDK simply listens to them. This is why you can add distributed tracing to a library without taking a dependency on OpenTelemetry at all. An ActivitySource is a factory for Activity objects, and an Activity is .NET's name for what OpenTelemetry calls a span.(don’t ask m...

UI generation and background coding agents are two of the "AI" tools that really changed my way of working. Together, they close a gap that's been annoying me for a while: the coding agent still needs someone to describe what the UI should look like, and that someone is usually me, typing a wall of text into an issue and hoping for the best. Google Stitch generates UI screens (HTML/CSS, Tailwind, Flutter, SwiftUI, whatever…) from a prompt or a sketch. The GitHub Copilot coding agent picks up an issue and produces a pull request in the background, without you sitting in the editor. In this post we look at how to connect the two through MCP, so the coding agent stops guessing at layout, spacing and colors, and starts reading an actual design spec. Here's how to wire it up, and where it still needs a human in the loop. My first approach: screenshots in the issue body My first attempt was to design something in Stitch, paste a screenshot into a GitHub issue, and ...

We run Dependency-Track for vulnerability analysis across our projects. One day, the OSS Index integration stopped working. No API calls, no analysis results, just this in the logs: An error occurred decrypting the OSS Index API Token; Skipping [projectName=Balansen - BatchConsole, vulnAnalysisLevel=PERIODIC_ANALYSIS, projectUuid=14ba5633-58c2-45fe-9f04-e4ab0b28375e, projectVersion=DEV] javax.crypto.BadPaddingException: Given final block not properly padded. Such issues can arise if a bad key is used during decryption. BadPaddingException is Java's polite way of saying: "I tried to decrypt this with a key, and it's the wrong key." The API token itself was fine. The key used to decrypt it wasn't. The wrong assumption Our first instinct was to re-enter the OSS Index credentials in the UI and assume a fat-fingered token was the culprit. That didn't help. The error came back on the next analysis run, right after we restarted the container for an unrelated...

Dimension tables don't stay still. A customer moves city, a product gets reclassified, a salesperson switches regions. The question is never whether this happens, it's what you do with the old value once it changes. That question has a name: Slowly Changing Dimensions (SCD). If you haven't already, it's worth reading my first post about what SCDs actually are and the full set of types first — this post assumes you already know the difference between Type 1 and Type 2 and want to get straight to implementing Type 2 in Fabric. Until recently, implementing Type 2 in Fabric meant either building a Dataflow Gen2 with a chain of merge steps, or writing a PySpark notebook against Delta tables. Both work. Both also mean you're maintaining custom logic per table, forever. Fabric's Copy job now has SCD Type 2 built in as a write method. No merge statements, no derived columns for surrogate keys, no alter-row logic. You pick a write method from a dropdown. This pos...

Being new to data warehousing, I never heard about the term "Slowly Changing Dimensions" before. It sounded like academic jargon. It isn't. It's one of those concepts that, once it clicks, explains half the weird design decisions you'll see in any reporting database. This post is the explainer I wish existed before I had to learn it the hard way: by breaking a report Facts and dimensions, the short version Data warehouses generally split data into two kinds of tables. Fact tables hold the things that happened: an order, a sale, a support ticket, a click. They're typically just numbers and foreign keys — quantity, amount, a reference to which customer, which product, which date. Dimension tables hold the descriptive context around those facts: who the customer is, what the product is called, which region a salesperson covers. A fact on its own is nearly meaningless. "47 units, customer 1182, product 309" tells you nothing until you jo...