Recent Articles

What is the Asynchronous Request-Reply Pattern Over the years I’ve often needed this pattern, I just didn’t know it had a name. Oftentimes, we’d like to kick off long running process from the user interface to your backend server. The problem is that HTTP isn’t great at handling long-running processes. Case in point, the default timeout on the HttpClient class is 100 seconds. What I’ve typically done is simply extend the timeout to something ridiculous to ensure that my process won’t time out.

The Problem Imagine one day you wake up to reports from customers saying that their trial accounts have expired too early. How much earlier? About six (6) hours. First of all, you ask yourself why would they wait till the last few hours of a 30-day trial, but I digress. You load up your developer environment and get to work. The Set-Up You’re using Entity Framework to get all the expired accounts from your Azure SQL Server database so that you can deactivate them (made up scenario, but bear with me):

When talking about the Dependency Inversion Principle, the D in SOLID, we have a pretty good idea of what dependencies we’re trying to abstract away. OrderRepository or SendGridEmailClient are easy examples of implementations we should abstract away. It also overlaps well with the Single Responsibility Principle, since data access for orders and sending emails are separated from the business logic where they are used. The C# implementation of this would involve making these classes implement the appropriate interfaces, e.

Introduction First off, let me make a few assumptions if you’re reading this article and trying to mock with Entity Framework 6: You’re on a legacy codebase. If you weren’t you’d be using Entity Framework Core and the In-Memory Provider. You’re not utilizing Database Migrations. If you were, it may probably be easier to create a new database and run tests using localDb. Your schema is extremely large. With a large database schema (often seen in legacy systems) data setup can become extremely difficult.

A Little Background I’m usually a stickler for best practices, but automated testing is something that has eluded me in my professional career for a long time. I typically work on legacy, line of business applications. So automated testing was never a priority. I’ve tried and failed to introduce various development teams to automated testing. Legacy applications are inherently difficult to test. Most everything I’ve read about automated testing points to trivial examples of testing and something like add (1, 2) and making sure the output was 3.

As developers, we sometimes tend to want to throw our latest, new-found tech toy at every problem. After recently converting this blog from a WordPress site to a static HTML site using Hugo, of course I’ve decided to try this elsewhere. Here’s what I learned. Benefits of Static There are a lot of examples (1, 2, 3) showing the difference between Static Site Generators (SSG) and a CMS like WordPress. The pros of static sites are easy to see:

As you can see from the last post, this blog hasn’t been updated in a while. For all intents and purposes, it’s a static site. So why not take this opportunity to test out static site generators? For this, I’m using Hugo. There’s been a lot of stuff going around with these, but I haven’t had a chance to test them out. A dead blog is a perfect place for this.