You may have noticed that our blog recently got a facelift. While redesigning front end sites is fairly common, in our case, this represented a bigger change. We noticed that we weren't treating our blog with the same principles we apply to the rest of our work. And so we embarked on a journey to find a better way, which lead to our current implementation.

With .NET Core, Microsoft introduced a new way to build pipeline behavior—middleware. Middleware solves many of the challenges with HttpModules, and makes building a custom request pipeline easy. Converting our custom behavior to middleware was fairly easy, but there were a few surprises waiting for us.

The world around us is littered with calls for learning to program. You may think, "I know how to code." Learning to code may be the beginning of the journey, but I posit that even mastering a language should not be the end. It may just be time to learn a new language.

There are lots of different types of tests. There are lots of different types of automated tests. In this post we'll talk about unit tests, specifically a few different types of unit tests and when you might want to use each.

Before we get too technical in our look at migrating to .NET Core, however, let's take a moment to review the architectural choices we made before we tried to switch frameworks. A large part of the reason that we were able to migrate from .NET Framework so quickly was because we separated our application logic from the decisions made by the framework.

As a polygot programmer, I often find myself needing to write code in a language for which I don't have a development environment setup. Usually, this is for a small or short term project. When these situations arise, I use docker to avoid spending time setting up a full development environment that I may never use again.

What sort of software architecture should you be implementing? When looking at industry trends, blogs, conference talks, and the like, it is easy to think that other companies have everything figured out. You'd be forgiven for wanting to copy the success that others are having. But there is no perfect architecture. Everything is a set of tradeoffs; there are only good and bad fits for a context.

This past summer, we converted one of our production webservices from WebApi2 to .NET Core. In this first post, I'll summarize our findings about the platform itself - where it shines, where it falls down, and the little quirks that give it "character". We'll be following up with posts that address some of the technical hurdles we went through in converting our application, as well as some insights we gained when rolling our first application to production.

Destroying your development environment frequently provides a forcing function to ensure that everything is automated, works and prevents manually created state from creeping into your data stores. In this post, I'll share the cost of not doing this as well as tips and code examples to set up your own development environment.

Making HTTP calls to get resources or call APIs is a staple of software development. But if you do not properly abstract the request construction and response handling from the HTTP library that you use, it can be extremely difficult to test.

Getting the size and position of elements in React is not a great story. Each option I researched has at least one gotcha. I'll share the best options I came up with and explain pros and cons of each. First let's take a look at the basic way to get an element's size and position in React.

Technical debt is a widely known metaphor which helps us think about how technical issues hurt our ability to deliver business value via software systems. But knowing the concept is different from actually managing technical debt. Unfortunately, many software teams know that they have technical debt, but don't know what do to about it.