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!

I enjoy writing silly chat bots. To indulge my silliness, I’ve been exploring the Microsoft Bot Framework. Overall, it’s a pretty good framework, but I’ve had some weird bugs here and there. It’s unclear to me if they’re my fault or not. So to dig into them, I cloned the microsoft/botbuilder-dotnet to my machine and ran all the unit tests. It’s what I do.

Marc Andreessen wrote a recent cri de cœur to start building to solve the biggest problems we have. I believe the overall sentiment is a good one.

In a recent post about remote work, I noted the importance of writing things down.

With all this recent emphasis on remote work, you can be forgiven if you think proponents (like myself) are a bit Pollyannaish about the benefits of remote work. Even so, you have to admit that preventing the collapse of civilization from a pandemic is a strong benefit to add to the list. Whodathunkit? Given that many are now required to work from home, it makes sense to try our best to make it work. This is the motivation behind my series of posts about remote work.

Facebook, Microsoft, Google, and Amazon just told its Seattle area employees to work from home for the next three weeks to reduce the risk of spreading the coronavirus. Lucky for them, I’m working on a series of post that will help.

Working from home is a hot topic right now. If you’re a manager letting your people work from home, you may have concerns. How do you ensure that people are working? How do you create a good remote work environment? Are your people really not wearing pants?

For years you tried to convince the powers that be that working from home is just as productive if not more so than coming into the office. You cited article after article full of evidence to support your claims.

Professor Laurence J. Peter wrote The Peter Principle in 1968 as satire critical of management and management practices. Over time, cynical folks latched onto it as a universal law of nature. Here’s how Professor Peter stated the law he named after himself,

Today’s my birthday so naturally the topic of burnout comes to mind. For the past couple years, I’ve been coping with varying degrees of burnout. This is not to be confused with being a Burner which is something else entirely.

A few days ago, my daughter was in a real funk. It breaks my heart to see her struggle. Fortunately, I knew exactly what to do, “build a mobile app!”

Quick! How many ways are there with .NET Core to encode parts of a URL? Here’s a list I came up with.

Sometimes you just need to submit a form and update a portion of your web page without a lot of fuss and muss. Today, you have a lot of options for dynamically updating the DOM based on changes made on the server. You could use React, Vue, Angular, SignalR, and Blazor.

Developer tools that understand code semantics have a lot of potential. They have potential to make developers more productive and reduce the friction and drudgery of our craft. But it can be difficult to put these tools to use in practice. Many of them require a steep learning curve to use. It would be nice if we could automate the benefits of some of these tools. You can see where I’m going with this.

UPDATE: At the bottom is an update that works for EF Core 5.0.2 and above that doesn’t rely on internal interfaces.

In my last post, I showed how to flow claims from an external identity provider (also referred to as a login provider) to your application. My post walks through how to bring over the claims every time the user logs in. But why would I want to do this?

I love it when a website lets me use my Google, GitHub, or Facebook account to log in. Chances are, I’m already logged into those sites, so it’s one click to log into a new site. This is a great experience for users. It reduces the friction to registration and loggin in to your site. They’re less likely to clam up.

Azure has a neat feature that runs Azure Functions from a package file (aka a zip file). This same feature also applies to Azure Web Apps, though you wouldn’t know it from the documentation. The Run from Package docs only mention Azure Functions. The GitHub issue that announced the feature makes it clear this also applies to Web Apps.

When you merge two branches, there may be conflicting changes between the branches. Git can often resolve these differences without intervention. For example, when each branch has changes to different files or lines of code.

Raise your hand if you enjoy merge conflicts. I’ll go out on a limb and guess that nobody has a hand up. If you do have your hand up - first, you look silly right now. I can’t see you. And second, you’re being contrarian. Nobody likes merge conflicts. They’re a hassle.