stokedbits
I’d much rather get into the intricacies of the business use cases, game mechanics, architectural paradigms, than to focus on typing something I’ve done dozens of times before. I think that’s where I’m at with it.
This comes with the assumption that everyone is vibe coding. Which just isn’t the case in the professional circles I’m part of. People are steering tools and putting up guard rails to save time typing. The “creating” part of coding has very little to do with the code, in fact my perspective is that it’s the most insignificant part of creating software.
At the end of the day, how code gets into a pr doesn’t matter. A human should be responsible to review, correct, and validate the code.
Right now I’m just getting my calibrations on learning how to make consumable content. I’ll be upgrading my setup soon to produce higher quality videos thanks to some friends donating some gear to me.
I’ll probably continue out a few more concepts here specifically to local development with this series. Then move on to a new project from start to finish. Maybe like a basic web app game or something that requires common infrastructure. I want to get more feedback data then make something really awesome once I get my bearings.
Right now I’d I were to do a stack it would be with what I’m familiar with. That would be IAC with something like terraform/cloudformation/CDK, then keep it simple with GitHub actions for CI/CD, go into migration/rollbacks/chaos/secops scenarios, and most likely deploy on both AWS (what I’ve used primarily for professional production) and digital ocean for my hobby projects.
This will bring you closer to the deployment stack if you are deploying to Kubernetes. Then also let you leverage tools like kustomize to dry out your configurations.
There are some great projects like tilt, devspace, skaffold, etc that help facilitate deving on a local or remote cluster.
As far as configuration management that can be as simple as cascading kustomize configs or helm. Then leveraging something like vault. The point really is, if you start with Kubernetes you have way more flexibility with tooling and options to do whatever the heck you want.
Shameless plug I recently started a series on local Kubernetes development. It covers some of this with tilt and more. If you would like a specific thing covered here I can add an installment to it. https://youtube.com/watch?v=Nj55RDVwrIE&si=EnSIkaIECMiOmarE
The update was to put all the build steps into source control, decouple all the logic, setup ci/cd to support the changes, and use a series of aws services (greengrass, kinesis, S3, lambda, cognito, systems manager, app sync, Api gateway, cloudfront, dynamo, etc) to facilitate an event driven architecture. Then threw an easy to easy to use gui (nextjs/react) on top of it for the customer support teams to use that was as fail proof as possible with a holistic view of system state and update progress.
Easily saved the company 10s of millions of dollars yearly and update times for the most critical systems went from days to hours. Failure rates went from a problem to a minimal occurrence which we had the observability in place to resolve in future scenarios by adding additional tests for any regression issues found.
Super fun project, learned a lot about AWS. Made a lot of customers happy and hospitals more safe.