
Similar endpoints, swagger pages, and a DevOps fail
After an unexpected debugging session, some thoughts on APIs, similar endpoints, swagger, and an ugly DevOps fail.

After an unexpected debugging session, some thoughts on APIs, similar endpoints, swagger, and an ugly DevOps fail.

Funny how a little due diligence mixes so well with a healthy interest in avoiding unnecessary future work.

I heard a story recently, where a team was asked, after spending months adding a set of features to a codebase, to remove a specific feature from very early on in the project, right before the release date. Other features had been built around it and on top of it. Without necessarily even intending too, the devs that came after that code was written would’ve had to understand it in order to add to it. I don’t know what the outcome was, but that’s not an easy ask. ...

A look at if/else, switch/case, pattern matching, other options … and which is best. (spoiler: none ;) )

C# has been getting a lot of pattern matching love in recent years, like with list patterns in C# 11. The problem is knowing where and how to use it.

When what we’re trying to accomplish fails, the extra knowledge and clarity we get just by making the attempt is a win all by itself.

Generic attributes increase the flexibility of a very early .NET feature. Let’s try using them and see how it keeps our code DRY.

When sending notifications in a WinForms app, a MessageBox is the only way to go… or is it? Let’s get creative and see what else we might do.

Writing async code whenever possible is great, but how do we do it when we’re stuck with legacy (and very synchronous) code?

It’s trivial to register a dependency in a .NET API, but it’s important to clarify a few terms that drastically change a dependency’s lifetime.