Newest first, grouped by year. Search or filter by topic.
Reading the Function App module against its App Service sibling: the shared secure-hosting chassis, the runtime storage account and version knobs that are genuinely new, and what half-populated prod values teach about templates.
The monolith and the microservices share the same command names. Decomposition here was one substitution - resolve a local handler, or publish to a broker - and reading both dispatchers shows exactly what changes.
DShop exists as one deployable and as nine services built from the same requirements. Read side by side, the two builds show which decisions were decisions and which were defaults.
Empty backend blocks, per-environment storage accounts and a state file for every stack-environment pair - how one Azure estate partitioned a thousand Terraform states for blast radius, and what that sprawl cost. Part 3 of the Terraform on Azure series.
Opening the Terraform Module Catalog with the library's flagship: how an App Service module bundles VNet integration, dual managed identities and Key Vault TLS into a surface app teams can fill in but not opt out of.
DevMentors built the same e-commerce shop twice - once as a monolith, once as nine services - with two gateways and two frontends. This series reads the whole estate as one artefact.
How workspace-keyed lookup maps and a single platform-facts JSON file let hundreds of Terraform stacks run identically in dev, staging and prod - and when a forgiving lookup default is the wrong kind of kindness. Part 2 of the Terraform on Azure series.
The conventions that let one Terraform sample library serve hundreds of Azure deployments - a five-file layout, workspace-indexed environments, pinned golden modules and pipeline-first delivery. Part 1 of a series on Terraform for the Azure estate.
The honest ledger for the whole estate - what coordinating through tables actually cost, what genuinely earned its keep, and what I would reach for now instead of using the database as a message bus.
A practical walkthrough of the pipeline that ships this very website: from push to production on Azure App Service, with secrets kept out of the repository and zero manual steps.
Four pipelines run dotnet test against projects with no tests and pass every time, the shared model ships as committed .nupkg files in a folder, one executable has no pipeline at all, and a DLL with no source hides an algorithm pasted inline elsewhere.
The same dashboard KPI is computed by three different formulas across role-variant procedures, rendered on a gauge with a sibling metric quietly deleted - and the fact table beneath it is an accidental Kimball star nobody designed.
The business month runs the 16th to the 15th, so a year-overview proc carries twelve correlated subqueries, five-day-capped weeks, time averaged through float casts and contractor filters that drift by a digit between copies.
One hierarchy, three implementations - a recursive CTE, a view that calls a scalar function on every row, and a whole family of tree procs - plus a relationship flag that is a decimal number pretending to be binary.
Thirty-eight tables, fourteen foreign keys, none on the tables that need them - plus a shipped SSMS template index, auto-tuning suggestions accepted blind, three-state booleans and a demo mode that mutates production master data.
The same database solves the same sortable-paging problem twice - once by concatenating user input straight into EXEC, once with a CASE whitelist, QUOTENAME and sp_executesql. A side-by-side of the wrong and right answer.
UTC timers, IST badge gates, DateTime.Now in one executable and UtcNow in the next, columns that record neither - how a system whose entire product is timestamps got away with never deciding what time it is.
Every five minutes a function hunts for people still virtually swiped in past ten hours and emails them - magic node numbers, an at-most-once flag with a gap in it, and a local config file pointing straight at production.
A 22-character job name, a 20-character column, and an error handler that has thrown on every attempt since the day it shipped - plus the four parallel logging systems that still could not catch it.
When one job needs another to redo work, it leaves a row - an action enum, a rewind date and a Done flag standing in for a message broker, plus the delete-and-replay proc that makes reruns possible.
Four magic strings in an audit column decide which rows the batch jobs may overwrite and which belong to humans - provenance, workflow state and inter-job protocol smuggled into a field meant for names.
The shift calculator writes one report row per employee per day since 2019, inventing blank rows for days nobody badged - a dense date spine built from sentinel values, at the price of one database round-trip per row.
Badge gates record when you arrived, not which shift you worked - so the platform infers it, scoring every candidate shift by L1 distance in time-of-day space and letting the smallest number win.
Leave records arrive late, change and get cancelled - so the sync reaches back into already-approved attendance rows and re-derives them, carefully stepping around human decisions and allowance money.
The leave sync resumes from wherever its own job log last said Success - one table serving as log, watermark and metrics store at once, with recursive pagination on top and an envelope check in exactly the wrong place.
