This is well documented by them which is why a majority of the apps doing this are released outside of the App Store. I built something similar, and I just publish it separately https://github.com/moxiebytescode/speakeasy.
Why would anyone assume a new model is dropping when their status page is showing elevated errors? Are they that sloppy that they just let their status systems report failures when they are the ones deploying new infrastructure / models / etc?
That’s fair and I do enjoy that part of it as well. It’s just that I think it’s trivial and I’ve been coding since about 7-8 years old and been in the industry professionally for over 20 years. My underlying point I left out is that I already understand most of the problems I’m trying to solve from a coding perspective.
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.
I get the authors spirit of this article, but a statement like “ People who love using AI to create software are loving it because they don’t value the act of creating & understanding the software.” Just kinda comes off as insulting.
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.
You got it! I’m serious about feedback, so please post anything that you think might be helpful on the YouTube comments or on the GitHub repository. I’m doing this with the sole purpose to help people and learn how to be a better teacher :)
Absolutely, that’s the ultimate goal and those are great ideas. Thanks for the feedback.
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.
Personally after using docker compose since it came out I’m excited to see the evolution of local Kubernetes development. I’d scrap even dealing with trying to make something as limited as docker compose do what you want. I’d focus on moving towards local Kubernetes development.
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
A quick overview of local K8S development using Turborepo, Tilt, web appplication / API using NextJS, NodeJS workers service, Postgres, RabbitMQ, and event based auto scaling using Keda.
Updated the architecture for the deployment model for millions of hospital devices. It originally required service techs to take a thumb drive to a hospital with the update and manually using a series of installers and scripts to perform tedious steps that could take days to update one device… usually with errors because the steps were not followed correctly.
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.