As always - pure gold! Thank you for sharing. I would like to see more episodes like this - a real life problem and real life solutions and approach. 🙏
You need to run a virtual cloud server, with a kubernetes container, with a docker container, which runs a Java VM, in which you run a Jython interpreter. The software environment should be virtual at all levels.
Might as well start with docker compose for your first lines of code. If you ever need to migrate to k8s in the future it will be far less work than the cost of dragging deployment complexity through the first iterations.
This is great material. Identifying the types of decisions that are worth exploring. Low investment offshoots. Then making choices that increase clarity without creating artificial restrictions. All on repeat. The former construction architect in me definitely recognizes the preliminary design process!
I think that if the 1st month isn't you alone or with like 2 other people experimenting via code in the basement somewhere, you're doing something wrong. Time to market is extremely important unless said otherwise. So is your own experience with your product and a clear vision. So is getting the architecture at least partially right. And you can't really do either of those things, unless you do a deep dive into what it is you want to be doing to get at least a bit of experience(with the tech, with the domain knowledge, with the problem statement, with the market). I wrote this blind before watching, wonder if I'll get beaten with a stick now.
Good to hear that's mostly the same thing. I wouldn't introduce any indirection at first if you don't have to, though. It just complicates the program, you can just swap the implementations inline. Unless you're doing something really sophisticated(like when you have to rely on polymorphism to do the program logic), you don't need to use interfaces right from the get go.
This is VERY idealistic. I would say the most important thing is to know when to cut corners and when not to. This means you need to understand the purpose, and not just cargo cult. eg a full pipeline and with full test suite may not make sense. CICD is good if you have a larger team that is working on the same code base, if you have a small team or they are working on different codebases then this is not as important. So build out the pipeline later... probably not a month 1 task. Test whats critical/central and skip the rest... you can add to it later... probably not a month 1 task.
Actually starting a green new project. It's a 2D/3D(2D sprites but in a 3D world) sprite video game on Unity engine(C#). I'll try to apply TDD in it. I apply TDD in my personal projects but I can't do it in video games(not exactly). I'm currently finishing another game in Unreal in C++ and it's very hard to do TDD in it: the docs on how to do it don't exist and I do need the world running to realistically test anything other than pure library code. And even then most library code for the things I need requires the running world.
As always - pure gold! Thank you for sharing. I would like to see more episodes like this - a real life problem and real life solutions and approach. 🙏
Month 1: Debating furiously whether to use K8s or not 😂
Kubernetes works well only if is transparent to the developers
You need to run a virtual cloud server, with a kubernetes container, with a docker container, which runs a Java VM, in which you run a Jython interpreter.
The software environment should be virtual at all levels.
Might as well start with docker compose for your first lines of code. If you ever need to migrate to k8s in the future it will be far less work than the cost of dragging deployment complexity through the first iterations.
@@manuelcop Hypothetically speaking, yes, but I don't believe this is a realistic scenario.
Emphasis on "furiously". 😂
This is great material.
Identifying the types of decisions that are worth exploring. Low investment offshoots. Then making choices that increase clarity without creating artificial restrictions. All on repeat. The former construction architect in me definitely recognizes the preliminary design process!
I think that if the 1st month isn't you alone or with like 2 other people experimenting via code in the basement somewhere, you're doing something wrong. Time to market is extremely important unless said otherwise. So is your own experience with your product and a clear vision. So is getting the architecture at least partially right. And you can't really do either of those things, unless you do a deep dive into what it is you want to be doing to get at least a bit of experience(with the tech, with the domain knowledge, with the problem statement, with the market).
I wrote this blind before watching, wonder if I'll get beaten with a stick now.
Good to hear that's mostly the same thing. I wouldn't introduce any indirection at first if you don't have to, though. It just complicates the program, you can just swap the implementations inline. Unless you're doing something really sophisticated(like when you have to rely on polymorphism to do the program logic), you don't need to use interfaces right from the get go.
This is VERY idealistic. I would say the most important thing is to know when to cut corners and when not to. This means you need to understand the purpose, and not just cargo cult. eg a full pipeline and with full test suite may not make sense. CICD is good if you have a larger team that is working on the same code base, if you have a small team or they are working on different codebases then this is not as important. So build out the pipeline later... probably not a month 1 task. Test whats critical/central and skip the rest... you can add to it later... probably not a month 1 task.
Actually starting a green new project. It's a 2D/3D(2D sprites but in a 3D world) sprite video game on Unity engine(C#). I'll try to apply TDD in it. I apply TDD in my personal projects but I can't do it in video games(not exactly). I'm currently finishing another game in Unreal in C++ and it's very hard to do TDD in it: the docs on how to do it don't exist and I do need the world running to realistically test anything other than pure library code. And even then most library code for the things I need requires the running world.
Great video. Thanks.
I liked!
Nice, thank you
Great explanation.
This is indeed the only way to create advanced software that really works
I bet he doesn’t say fire your only senior engineer
Great video; thank you.