Like many folks finding their way through the COVID-19 pandemic, I’ve recently accepted a job working permanently remote. So for the foreseeable future my workstation will be pulling double-duty for macOS-based software development with a MacBook Pro and Windows-based gaming on a PC.
Absent some sort of alien quantum technology, engineering client-server applications will always mean entertaining the possibility that clients will lag the server by at least one version.
In my last post we covered why CRUD patterns can be inherently difficult to scale. If you’ve reached that point, congratulations, it’s time to upgrade your design. In this post we’ll cover a different kind of data access pattern that’s a little more complicated than CRUD, but offers some benefits that just might make it worthwhile.
“To err is human, but to really foul things up you need a computer.” -Paul R. Ehrlich
One of the most important responsibilities of RESTful web services is that they translate business logic outcomes (and unexpected errors) to the correct HTTP response code. When it comes to accomplishing this in ASP.NET Core, this logic usually ends up in the controller and looks something like this:
I encountered a weird error today attempting to run a .NET Core application hosted in IIS. The error was:
Wednesday, 8:55 AM.
So I got my new blog up and running in a matter of 10 minutes. Of course that doesn’t count all the hours spent deliberating between all the potential alternatives (Medium, WordPress, MkDocs, Blogger, etc). Nor does it count all the prerequisite knowledge it takes to understand how to do, well, anything. Nonetheless, I’m sticking with 10 minutes. I ended up going with Jekyll on GitHub Pages for a…