A long time ago, I wrote a useful set of git aliases to support the GitHub flow. My favorite alias was bdone which would:

PostHog helps you build better products. It tracks what users do. It controls features in production. And now it works with .NET!

Last year I wrote a post, career chutes and ladders, where I proposed that a linear climb to the C-suite is not the only approach to a satisfying career. At the end of the post, I mentioned I was stepping off the ladder to take on an IC role.

I love using Refit to call web APIs in a nice type-safe manner. Sometimes though, APIs don’t want to cooperate with your strongly-typed hopes. For example, you might run into an API written by a hipster in a beanie, aka a dynamic-type enthusiast. I don’t say that pejoratively. Some of my closest friends write Python and Ruby.

The career ladder is a comforting fiction we’re sold as we embark on our careers: Start as Junior, climb to Senior, then Principal, Director, and VP. One day, you defeat the final boss and receive a key to the executive bathroom and and join the C-suite. You’ve made it!

Ever look for a recipe online only to scroll through a self-important rambling 10-page essay about a trip to Tuscany that inspired the author to create the recipe? Finally, after wearing out your mouse, trackpad, or Page Down key to scroll to the end, you get to the actual recipe. I hate those.

C# 11 introduced a new feature - static virtual members in interfaces. The primary motivation for this feature is to support generic math algorithms. The mention of math might make some ignore this feature, but it turns out it can be useful in other scenarios.

This is a follow-up to my previous post where I compared .NET Aspire to NuGet. In that post, I promised I would follow up with a comparison of using .NET Aspire to add a service dependency to a project versus using Docker. And looky here, I’m following through for once!

Recently I tweeted,

When you fail, many people will tell you how failure is a great teacher. And they’re not wrong. But you know what else is a great teacher? Success! And success is a lot less expensive than failure.

One of my pet peeves is when I’m using a .NET client library that uses internal constructors for its return type. For example, let’s take a look at the Azure.AI.OpenAI nuget package. Now, I don’t mean to single out this package, as this is a common practice. It just happens to be the one I’m using at the moment. It’s an otherwise lovely package. I’m sure the authors are lovely people.

This is the final installment of the adventures of Bill Maack the Hapless Developer (any similarity to me is purely coincidental and a result of pure random chance in an infinite universe). Follow along as Bill continues to improve the reliability of his ASP.NET Core and Entity Framework Core code. If you haven’t read the previous installments, you can find them here:

In the previous installment of the adventures of the hapless developer, Bill Maack, Bill faced some code that tries to recover from a race condition when creating a User if the User entity doesn’t already exist.

There are cases where recovery from an Entity Framework Core (EF Core) DbUpdateException is possible if you play your cards right. Play them wrong and the result is heartbreak and tears as every call to SaveChangesAsync rethrows the same exception.

We recently upgraded Abbot to .NET 7 and C# 11 and I’m just loving the new language features in C#. In this post, I’ll give a couple examples of list patterns.

I just finished speaking at my favorite conference, the Caribbean Developer’s Conference. Held in a wonderful resort in Punta Cana, Dominican Republic, it brings together a local and international crowd of speakers and attendees. I’ve gushed about it before.

Over here at A Serious Business, Inc. we’re very serious about security. One principle that’s important to us is what we call the Principle of Least Exposure (not to be confused with the similar Principle of Least Privilege).

When using an ORM with a web app, lazy loading will almost certainly result in hidden N+1 queries. Eager loading is a great way to avoid this, but has its own pitfalls. In particular, for each query, you need to be careful about what you include in the query. If you include too much, you can end up with a lot of data that you don’t need. If you include too little, you can end up with confusing logic. For example, deep in your application code, it may not be clear if a navigation collection has been loaded yet or not. This can lead to unexpected behavior.

Building a startup is easy. You file some paperwork and bam! You’re a startup!

I was minding my own business when @dahlbyk (you may know him from such hits as PoshGit) dropped this comment on an already merged pull request.