software development

In my latest Azure/Terraform post, I touched on how I solved the “Chicken and Egg” problem with Terraform: how you need cloud resources in order to store Terraform state, but you can’t use Terraform to generate those cloud resources. This post details the solution to that problem.

I recently blogged about using Terraform to manage resources in Azure. To be honest, my implementation was okay, but it could definitely improve. This post is an update on how I’ve updated the structure and usage of Terraform within projects.

I have always believed that Delivery is one of the most important aspects of software development. I blogged about it previously (My Core Values). Software delivery isn’t just putting the bits into the final resting location; it must also include the infrastructure provisioning to explicitly define where the bits will actually land. Terraform helps bridge that gap, especially given a public cloud offering like Azure.

As hinted at in a previous post, I have transitioned from hosting dynamic web applications in a cloud hosting service (like AWS Elastic Beanstalk or Azure App Service) to hosting static websites in my document storage location of choice (Amazon S3 in this case). This post discusses my development process for a project like this.

I am a firm believer in delivery high-quality code at all times. As such, anytime the committer of code isn’t the only person looking at the code before it goes live, we can be reasonably certain that the quality of the code will increase.

Back in the day (high school and early college), I ran one of the state’s largest track and field databases. All of the entries were entirely crowd-sourced (before crowd-sourcing was a thing), and it was used pretty heavily.

Some background: I run a couple of websites in Amazon Web Services (AWS). These include my photography website project, MorrisPhotos.com. This post is a quick overview of how I managed to save ~$55/month in AWS charges.

In my current job, I’m frequently asked to interview new candidates to join our development organization. One of the first questions that always gets asked, either by me or one of my colleagues, is “What level is this person interviewing for?” There really are only two answers for this question where I work: Developer or Senior Developer.

Precursor: I’ve been working with a significantly large legacy codebase for over three years now. Here are some tips, tricks, and general pointers to make sure you don’t make the same mistakes I’ve made with legacy code.

Some backstory before I go into the details here: I am a track and field coach. I run a website that displays track and field statistics throughout the state of Ohio. I am a lead software engineer for a large ticketing company. All of these add up to my current project: building a competitive product to Hy-Tek’s Meet Manager.