Using Keyed Services in .NET 8

.NET 8 is going to ship Keyed Services with Microsoft.Extensions.DependencyInjection, the default IOC container. Keyed services allow developers to register multiple implementations of an interface under different names (or, more generically, “keys”). This is useful in some scenarios. Let’s take a look.

Choosing a DotNet Test Framework

I saw a Reddit post asking which test framework to use: xUnit, NUnit, or MSTest. I’ve used xUnit almost exclusively for years and don’t have firm enough experience with the others to recommend for or against them. Any bias I have against MSTest is probably years out of date. I hear it’s pretty good now!

Instead, I thought I would list my top test framework considerations.

Why AutoFac

I’ve frequently seen a question arise about why anyone would use an open-source dependency injection framework like AutoFac when Microsoft provides Microsoft.Extensions.DependencyInjection (MEDI). Isn’t that good enough?

It’s a fair question. MEDI is a capable dependency injection container and will support most application needs. However, I still find it worthwhile to plug AutoFac in.

Microsoft created MEDI so that framework and library authors could depend on some basic dependency injection capabilities without writing adapters for every popular DI container. Microsoft specified base-level functional expectations, but application developers that wanted more power could use a different tool as long as it could conform to the protocol Microsoft specified. As a result, the MEDI provides a limited feature set by design.

I frequently want more robust capabilities and will install AutoFac to get them.

The rest of this post will highlight some of the features of AutoFac that I particularly like. While not provided out of the box, Developers can emulate many of these features with MEDI, though perhaps clumsily. Some have no analog at all. Sample code is also on GitHub.

Tips for selling your technical vision

My company’s CEO once commented that Architect is a sales position. I think that is a wise observation and applies to most technical leadership roles.

It’s not enough to have good ideas: you need to sell them.

Here are some tips I’ve found that help build consensus and nudge a team in a direction I believe is best.

Using codemods to upgrade legacy code

Last week I helped a client plan an upgrade from an internal custom JavaScript library to a more modern UI framework. The existing code uses a tool called “jingo“ to manage dependencies. We wanted to support modern bundlers that use the new EcmaScript Modules (import and export) syntax. A straight forward mechanical transformation exists but the codebase consists of hundreds of files to convert. It would be tedious, boring work over the course of days. However, I could use codemods to write a script that would convert the syntax automatically.

Adventures in Mastodon Self-Hosting: The Story So Far

A couple months ago a bunch of my most active twitter followers were migrating to the federated open-source social media platform Mastodon. Instead of a single centralized service, its a wide collection of independent instances that are able to “federate” together. Some have compared it to email: You can pick any host (instance) you want, and mostly still communicate with anyone on different hosts. Theres nothing stopping gmail users from sending things to hotmail users, for example.

I found this very interesting and naturally wanted to run my own instance to check it out: thus was born social.mattburkedev.com.

CodeMash 2023 - So You're a New Lead Developer... Now What?

Hi CodeMash attendees! If you’re here you probably came to my talk on Friday about being a new lead developer. We talked at length about building trust through 1:1s and how to give feedback effectively. I really hope it will prove helpful

I had fun speaking with everyone after the session and trying my best to answer your great questions.

The slides are here and I’m also curating some more resources on the talk page.

If you have additional questions, I’d be happy to chat with you further. You can find me on Twitter at @mattburkedev1, LinkedIn and I’m trying out Mastodon on my own instance at @matt@social.mattburkedev.com.

Thanks again to all the hard working CodeMash organizers and sponsors for making it such a great event! And shoutout to my team at Viagio Technologies for teaching me so much and making it possible for me to attend.

Using test hooks for shared fixtures in Jest

I’ve been working on a project that needed some integration tests. Before any tests in a suite run, I wanted to open a connection to the database and do some other setup. At the end of the suite, I wanted to close the connection and tear down cleanly.

Jest has beforeAll and afterAll hooks that run before and after all tests in a test suite, which is basically what I wanted. But I don’t want to copy and paste the same code into every test file. I could of course just export some shared functions, but anytime someone adds a new test they have to remember to implement beforeAll and afterAll correctly. That seems annoying: I really wanted a “mixin” that I could easily bring in that would automatically apply the hooks to the test suite.