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.

In the System.Reactive.Disposables namespace (part of Reactive Extensions), there’s a small and useful Disposable class. It has a Create method that takes in an Action and returns an IDisposable instance. When that instance is disposed, the action is called. It’s a nice way of creating an ad-hoc IDisposable. I use them often for creating a scope in code where something should happen at the end of the scope. Here’s an exceedingly trivial example:

This recent Abbot Blog Post covers abbot-cli a new open source command-line tool. abbot-cli makes it possible to work on Abbot skills in your local editor. In that post, I mentioned that when you retrieve a C# skill to edit locally, the tool writes a few aditional files on your machine.

UPDATE: there might be an easier way now. App Service Managed Certificates now supports apex domains. I’ll give it a try and report back.

In my last post, I wrote about writing a sparkly skill in Abbot. That was fun! But Abbot isn’t only about fun. After all, our company name is A Serious Business, Inc. Seriously, that’s the name. So it’s about time I show you how to get to some serious business with Abbot.

In my last post, I wrote about some of the interesting elements of C# we take advantage of to make argument parsing in Abbot with C# nice.

Most Bot skills strive for a more natural language feel to arguments passed them. For example, to remember something with Abbot you can use @abbot rem haacked's blog is https://haacked.com. And then later recall it with @abbot rem haacked's blog. Or just @abbot rem haacked because Abbot uses fuzzy matching.

Collaborative work is difficult enough when located together in an office. It can present new challenges when working remotely. When I worked at GitHub, one powerful tool we used that left a lasting impact on me was ChatOps. In fact, GitHub may have created the concept. If not, they were certainly one of the first.

It is notoriously difficult to make decisions in a distributed asynchronous manner. It’s hard enough for me to make decisions by myself. Now introduce more people and timezones and you have yourself a hot mess. People tend to meet an online proposal with the silence of indifference. Or the silence that’s a result of the bystander effect as everyone waits for someone else to chime in.

On Twitter the other day, David Anson asked,

When I deploy software, I’m lazy. Very lazy. This is why I lean heavily on Continous Deployment (CD) to automatically test and deploy software when it’s merged into my main branch. I don’t have time to deploy code by hand. So gauche!