Newest first, grouped by year. Search or filter by topic.
KC Star V2 leaked aggregate rows because base facts and rollups shared one table. V3 gives aggregates a dedicated SalesAggregationFact table with its own SCD2 - and the fix is as much about what SalesFact loses as what the new table gains.
KC Star V2's measure formulas read like window functions - SUM(...) OVER (PARTITION BY SaleType) - but the implementation is plain GROUP BY. Here is how CreateAggregatedFacts actually builds the aggregates, and why the formula strings deliberately lie.
KC Star V2 stores base facts and aggregates in one table and tells them apart by a NULL. When it expires old aggregates, that one distinction turns out to be a distinction short - per-SaleType aggregates never retire, duplicates pile up, and V3 gets its reason to exist.
To compute per-SaleType aggregates, KC Star V2 lifted one dimension out of the row store and made it a real column. Here is the renumbering it forced, what it did to the version hash, and the honest tension of un-inverting one attribute in a schema built on inversion.
KC Star V1 declared eight measures and computed four. V2 computes all eight - base measures and aggregates together in a single SalesFact table. Kicking off the series on the version that made the warehouse analytical, and started the trouble that V3 had to fix.
I ported KC Star V1 to SQL Server to prove the inverted star schema was an idea, not a PostgreSQL trick. HASHBYTES for digest, cursors for FOR EACH ROW, expire-then-insert instead of MERGE - the port taught me as much about both engines as the original did.
KC Star decides whether to rebuild a sale's measures by hashing its dimension state and comparing. Here is how the version hash works, why two of them coexist in V1, and how the same timestamps that version history also power time travel.
The heart of KC Star is two tall, narrow tables and two lookup tables. Here is how a sale becomes seven dimension rows and a handful of measure rows, and how a view pivots them back into something you can read.
KC Star V1 has no ETL job and no application code. Two PostgreSQL triggers explode sales into dimension rows and version them on change - and the gaps between what they do and what I claimed they do are the most instructive part of V1.
What if dimensions and measures were rows instead of columns? Introducing KC Star, a PostgreSQL data warehouse I evolved through nine versions, starting with the inverted foundation - SCD2 history, SHA-256 fingerprints and time travel included.
Pactify.AspNetCore in one sitting: an attribute, an assembly scan, and a /pacts/{provider} endpoint that serves your contract classes as live JSON - plus what a runtime contracts endpoint is really for.
The series retrospective - what a thirty-file library taught me that a full-featured one couldn't, Pactify's honest limit list versus PactNet, the broker maturity ladder, and the org-shaped question hiding under the tooling.
A line-by-line read of Pactify's matching engine - top-level-only body comparison, header names that ignore your casing option, nested objects that can never match, and two format-string bugs that crash the error path.
How a pact travels from the consumer's pipeline to the provider's - Pactify's file and HTTP publishers, Pact Broker URL anatomy, and the unchecked response status that makes a failed publish silently pass your build.
The provider side of Pactify - how CreateFor<Startup> hosts your whole API in memory with TestServer, why interactions verify concurrently, the SmartFormat trick behind endpoint templating, and the discovery that Given(...) never runs.
An annotated tour of the JSON document Pactify produces - the serializer settings that shape it, the snake_case field inherited from Pact v1, and the unusual decision to ship the consumer's matching options inside the contract itself.
A walk through Pactify's PactMaker fluent API - the two-interface builder trick that hides Build() from you, why the consumer test always passes, and the uninitialized-object surprise inside WithBody<T>().
The retrospective: after ten parts inside DevMentors' real-time feeds sample, the honest scorecard - five decisions worth stealing for real systems, the sharp edges catalogued in one place, and the concrete backlog that separates this teaching codebase from a production deployment. Part 11 closes the FeedR deep dive.
Unit tests mock what you assume, end-to-end tests tell you too late - consumer-driven contract testing closes the gap, and a small open-source .NET library called Pactify is the clearest way I know to learn how it works. Part 1 of a series.
FeedR ships three ways to run its six services - pm2, Project Tye, and a deliberately split pair of docker compose files - plus per-service Dockerfiles and an environment-keyed configuration layer that lets the same build run on localhost and inside a compose network. Part 10 of the FeedR deep dive.
FeedR threads a correlation ID from a YARP transform through HTTP middleware and into Pulsar message metadata - and quietly loses it at the Redis hop in the middle. Tracing exactly where the chain holds and where it breaks is the best observability lesson in the sample. Part 8 of the FeedR deep dive.
How do you assert that an endpoint published an event when publishing is a side effect with no return channel? FeedR's end-to-end test answers with WebApplicationFactory, a real Redis round-trip, and a TaskCompletionSource - plus the timeout and determinism traps the sample leaves open. Part 9 of the FeedR deep dive.
Where FeedR's data graduates from tick to fact: the aggregator's pricing handler, a second messaging seam with envelopes and metadata, Apache Pulsar as the durable tier, and the notifier's acknowledge-as-you-go consume loop. Part 7 of the FeedR deep dive.
FeedR pushes live prices to clients through a gRPC server stream: a four-message proto contract, fixed-point decimals, dual Kestrel endpoints, and an event-to-stream bridge that busy-spins - plus the channel-based rewrite it's asking for. Part 5 of the FeedR deep dive.
FeedR's weather feed is the pattern for every external integration: poll a REST API inside an IAsyncEnumerable, guard it with a typed HttpClient and Polly retries, translate its JSON at the boundary, and republish it as a push. Plus the retry clause I can't defend and a hard-coded API key with a lesson in it. Part 6 of the FeedR deep dive.
