The art of simplicity

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...

The GitHub Copilot SDK just shipped a new feature: optional memory configuration on session create and resume. Here is what it does, and how it is different from persisted sessions. The wrong mental model first When I heared "session memory" my first thought was "persisted sessions" — the ResumeSessionAsync flow that lets you reload an existing session by ID and continue where you left off. That is not what this is. Persisted sessions are about durability of the conversation itself: close the app, reopen it, pick up the thread. Memory configuration is something different. What memory configuration actually does Memory is a feature of the Copilot runtime that lets the agent read and write facts across turns — a kind of long-running knowledge store that the agent can consult and update during a session. Think of it as the agent's notepad, not the conversation log. The new MemoryConfiguration type exposes a single Enabled flag today. You opt in per se...

The GitHub Copilot CLI keeps getting more capable. One of the newer additions is the ability to schedule prompts, either on a repeating interval or as a one-shot delayed action. Let me walk you through both approaches. Two ways to schedule The /every command schedules a prompt to run repeatedly at a specified interval, while /after schedules a one-shot prompt to run once after a specified delay. Both commands are still experimental. They are only available if you have used the /experimental on slash command, or the --experimental command-line option first. Use the following slash command to enable experimental mode in your session: /experimental on Recurring prompts with /every Use /every when you want Copilot to repeat a task on a cadence during your session. /every 10m Run the test suite and summarize any new failures /every 1h Check for new comments on my open pull requests A number with no suffix is interpreted as minutes — so /every 30 remind me to check for...

In the previous post, we walked through local sandboxing in the Copilot CLI: enable it with /sandbox enable , tune filesystem and network rules through the TUI, and your agent's shell execution is isolated by Microsoft MXC. Simple, useful, done. But if you're building with the Copilot SDK, embedding the agent runtime into your own .NET application, you can't type /sandbox enable into a session you're programmatically orchestrating. So the question becomes: how do you get the same isolation guarantees when you own the host? The good news: sandbox support is coming to the SDK as a preview feature. The entry point is Session.Rpc.Options.UpdateAsync , and it lets you push a sandbox configuration into a running session from code. Preview caveat : this API is behind the experimental surface of the SDK. It's real, it works, but the shape may change before it stabilises. Treat it as preview-quality and don't build production contracts on top of it just yet. Wha...

There's a moment in every agentic workflow where you pause and think: wait, what exactly is Copilot allowed to touch right now? For a long time the answer was: pretty much everything under your working directory and whatever shell commands it decides to run to get the job done. That was fine when Copilot was mostly suggesting code. It's a different story when it's running tools, executing scripts, and modifying files on your behalf. As of June 2026, GitHub has an answer: local sandboxing , now in public preview. It doesn't replace good judgment about what you ask Copilot to do, but it does put a real isolation boundary between the agent's tool execution and the rest of your machine. Let’s explore this feature… Why do we need this? The Copilot CLI has evolved significantly since GA. What started as a smart terminal assistant now has Autopilot mode, /plan , fleet parallelism, rubber duck, and a full agentic harness underneath. When you run Copilot in Autopil...