Darren Broemmer

Because your focus, you should have a relentless focus on your customer. So if it's the web app, they can't take any orders. If it's the sidekick process, it's like, well, that's a little bit better. I can still accept orders and I'm going to hopefully get that business. I might just be a little delayed in getting the shipments out or processing whatever it is.

Because your focus, you should have a relentless focus on your customer. So if it's the web app, they can't take any orders. If it's the sidekick process, it's like, well, that's a little bit better. I can still accept orders and I'm going to hopefully get that business. I might just be a little delayed in getting the shipments out or processing whatever it is.

So having it be its own, if it's valuable like that, right? If I can get benefit from observing it and scaling it separately, then you're in a better spot. If you need to scale up that back-end process, if it's doing more work, then maybe it's nice to have it in a separate deployable unit.

So having it be its own, if it's valuable like that, right? If I can get benefit from observing it and scaling it separately, then you're in a better spot. If you need to scale up that back-end process, if it's doing more work, then maybe it's nice to have it in a separate deployable unit.

But those are the types of considerations that I would look at as opposed to, or in addition to, I should say, the separation of concerns and how easily, how easy is it for me to make code changes if I need to innovate add capabilities?

But those are the types of considerations that I would look at as opposed to, or in addition to, I should say, the separation of concerns and how easily, how easy is it for me to make code changes if I need to innovate add capabilities?

That's a great analogy for separation of concerns. I got to remember that one and use that in the future. The dogs in the fenced-in backyard, I like that. Yep. Yeah, I mean, I think that You brought up a really good point. It's like, well, you know, we're all if we're all in the same backyard, you know, how long will it be until we all, you know, cause problems?

That's a great analogy for separation of concerns. I got to remember that one and use that in the future. The dogs in the fenced-in backyard, I like that. Yep. Yeah, I mean, I think that You brought up a really good point. It's like, well, you know, we're all if we're all in the same backyard, you know, how long will it be until we all, you know, cause problems?

We bump into each other trying to get our work done. You know, one person is cutting the grass in the backyard while the others are trying to play volleyball. It just doesn't work very well.

We bump into each other trying to get our work done. You know, one person is cutting the grass in the backyard while the others are trying to play volleyball. It just doesn't work very well.

And so, you know, we talked about actually like as it gets bigger, it can get more complicated, but you can look at it the other way that as, you know, it's easy when you're getting started to have it all be in, you know, app and lib. It's actually as you get bigger and bigger where it becomes easier. more of a challenge because changing one thing has ramifications in unintended places.

And so, you know, we talked about actually like as it gets bigger, it can get more complicated, but you can look at it the other way that as, you know, it's easy when you're getting started to have it all be in, you know, app and lib. It's actually as you get bigger and bigger where it becomes easier. more of a challenge because changing one thing has ramifications in unintended places.

And that's really one of the big challenges. There's a pretty nice tool that I've been working with or testing out called App Land. And it's open source. You can grab it and it gives you a nice visual map of the connections, the call stacks, and you can see how your components are related. You know, I always like to see, I like to have a visual or mental model in my head of,

And that's really one of the big challenges. There's a pretty nice tool that I've been working with or testing out called App Land. And it's open source. You can grab it and it gives you a nice visual map of the connections, the call stacks, and you can see how your components are related. You know, I always like to see, I like to have a visual or mental model in my head of,

their requests coming in and how the route that they take through the controller and what objects they actually use. And this gives you a nice kind of visual representation of that. This was actually something that I thought about when I first started doing Rails and Ruby, which I mentioned like six, seven years ago. And when you do Ruby or sorry, when you, excuse me, when you do Rails new,

their requests coming in and how the route that they take through the controller and what objects they actually use. And this gives you a nice kind of visual representation of that. This was actually something that I thought about when I first started doing Rails and Ruby, which I mentioned like six, seven years ago. And when you do Ruby or sorry, when you, excuse me, when you do Rails new,

It's interesting. You actually get, I think it's about 50 files with 500 lines of code, give or take. And Rails isn't embarrassed about this either because you can do bin Rails stats and it'll tell you exactly how many files and lines of code there are. So that's a lot of code and a lot of files just to do a hello world, right?

It's interesting. You actually get, I think it's about 50 files with 500 lines of code, give or take. And Rails isn't embarrassed about this either because you can do bin Rails stats and it'll tell you exactly how many files and lines of code there are. So that's a lot of code and a lot of files just to do a hello world, right?

If I was going to compare that to Node.js, for example, I think probably one file, maybe what, like five lines, something like that. But there's also the positive aspect of it that it prescribes a lot of things for me. If I want to find out where a controller action is, I know exactly where to look. If I want to find where the images are located, I already know.

If I was going to compare that to Node.js, for example, I think probably one file, maybe what, like five lines, something like that. But there's also the positive aspect of it that it prescribes a lot of things for me. If I want to find out where a controller action is, I know exactly where to look. If I want to find where the images are located, I already know.