After being fully remote for over 3 years, I traded in fully remote back for full in office in August of this year. I adored full remote, but the velocity, collaboration, and ability to quickly get answers by simply approaching folks and having watercolor conversations feels far more functional.

Repo + docs: github.com/JerrettDavis...

If you’ve ever shipped “just a small experiment” and it turned into a tangled mess, I’d love feedback (or horror stories).

Introducing ExperimentFramework: composable experiment trials with fluent setup + source generators that swap your SuT registrations in DI for a proxy. That proxy gives you an “infinite decorator” surface for routing, telemetry, fallbacks, etc.

Telling was losing. So I did the only responsible thing: built a framework instead of writing a doc.

I argued it’s cleaner to treat experiments as a first-class domain, not a pile of ad-hoc decorators scattered through app code. Core premise: subjects in a trial should be observed, not acted upon.

I'll have to look over dnx a bit more this evening. Thanks for the tip!

I think my next thing will be trying to bake the core dacpac reverse engineering logic right into a task, instead of needing a specific dotnet tool. That would make it pretty much a 1-step process.

And huge props to @erikej.bsky.social's wonderful Entity Framework Core Power Tools library! It's doing the real heavy lifting for all the dacpac to EF Core transformation.

In future revisions, I'll bake the direct DB reverse engineering feature my package as well.

This methodology provides a singular, version-controlled repository that functions as the definitive source of truth for all data access, migration, deployment, and containerization artifacts and considerations within a database-first paradigm, all without requiring boilerplate code.

With just a couple lines of config in your csproj, you can have your project automatically generate ready-to-use entity model partial classes, and the whole process is transparent and nearly fully configurable.

I've been enjoying writing behavior driven tests. Before ever writing a feature or hotfix, I get reproduction and accentance criteria, structure it into Gherkin syntax, and start building test suites that model and change with the problem domain rather than testing how the implement works.

Had to cheat a bit: dotnet build insists on an XML file, so dotnet build MyApp.slncs needs .slncs to be a minimal XML stub (or worse, everything wrapped in CDATA).

I hacked around it with a dotnet tool instead — slncs-build.

If you flash mainline VIAL, no, but there is a fork out there with the appropriate fixes and it maintains wireless/bt: github.com/daskygit/qmk...