Early on in my career, I decided to try test driven development (TDD). The first couple days felt great: visions of greener coding pastures filled my imagination, my opinion about my code quality skyrocketed, and all untested code began reeking a putrid stench. Yes, I was that guy: the overconfident junior developer. Over the next couple months, I wrote a massive suite of tests. As the novelty faded, I made a change to my code, saw about forty tests fail, and started fixing all of the failing tests.
You’re reading a Hugo site right now. It’s not hosted in a Google Bucket, but it should be, because Google Bucket hosting costs next to nothing. If I didn’t have an existing server to reuse, I would have used a Google Bucket. For anyone starting out, this is a great way to host a site for almost nothing. Hugo is a static site generator. It takes some local files on your computer and converts them into HTML files in a directory structure that allows pretty URLs without custom routing.
One mistake I made with some of my early projects was starting off with manual deployments. I thought that getting it up and running and delivered was the most important goal, and that a manual deployment would reach it the quickest. Having delivered a significant number of projects since then, I now completely disagree. Always automate from the beginning. You will thank yourself later. Automating first provides a number of clear advantages.
If you’ve worked on any large React project, you’ve probably run into a component or two that gave you quite a headache when you tried to reuse it. I definitely have. It’s almost inevitable when working on a large project with a substantial number of developers. Over the past few years, I’ve put together a list of lessons learned that have helped prevent this problem. It’s far from complete, but it’s substantial enough that it might help someone else.
A production web application should have a number of safeguards in place to prevent failures. Many outages have preliminary symptoms that a proper monitoring solution can detect, and these detections can send alerts to the appropriate people capable of fixing them. Amazon’s CloudWatch service can both monitor systems and also alert when something goes wrong. Let’s take a look at how to set it up. We could go into the Amazon dashboard to do this, but since I have a rule to automate everything that goes into production, I’ll show you how to do it in code.