Joel Clermont (00:00):
Welcome to No Compromises, a peek into the mind of two old web devs who have seen some things. This is Joel.

Aaron Saray (00:08):
And this is Aaron. One of the important things to do as a programmer is to constantly keep learning and we've talked about that a lot.

Joel Clermont (00:21):
Sure.

Aaron Saray (00:21):
So you learn new things and your mind expands and you learn new techniques and everything. But I think it's important to understand that that doesn't mean that all the stuff you've learned so far is always going to be "right" or what you still believe is best practice and all that kind of stuff. I'll give an example, right? I learned about using Docker for deploying and developing apps from a gentleman who worked in a Fortune 500 company. We had many, many different versions of different apps going out and they were all balanced and there was all these different clusters of things. And because of that, he kind of had best practices in mind or best practices for a large-scale sort of deployment in mind.

Joel Clermont (01:13):
We're talking like more than one drop in that digital ocean?

Aaron Saray (01:17):
Yeah, it was all AWS and multiple... I mean, it was something like when you deploy code, you could then see the Docker containers spinning down and new ones coming up. There was always at least three or four running at one time so you'd have different versions of code. Anyway, point is that he taught me a lot about how to do this with kind of like larger-scale stuff or things like that. One of the things he taught me about was that each one of the Docker containers should do a thing. I had a Docker container for NginX and I had Docker container for PHP, and for MySQL, and all those different stuff. And you kind of swapped those out. That's kind of how we do our projects now, is we tend to have kind of a separate one for each, depending on the setup. I was kind of bought into that and I just really kind of dragged my feet on the fact that someone would think about combining all those. A person talked to me the other day and they're like, "Why don't you just put it all in one Docker container again? Like, MySQL and everything like that. Just like you did with Virtual Box and just call it good, it's just a small container."
I said, "I can't do that because that's not best practice." So because I'm always learning, I'm always watching and reading things. I was going to this course servers for hackers.com ran by a person in the community, Fideloper. And he was talking about his sort of way that he'll combine certain things on a Docker container, among others. So he might have a separate one for MySQL, which makes sense to me, but he'll always combine engine Nginx and PHP. I was like, "Argh, I can't buy into this," and then he started to explain why. His reasons were for Nginx to properly serve PHP files, it has to see the PHP file and know it's a PHP file than to say, and then PHP needs access to it. Technically those two things actually need to be able to see the files so if you keep them separately, you have to mount the code on both of them, versus if you combine them. And he goes, "Nginx is made to not be that resource intensive so it's really not a big deal to have an Nginx instance just not doing anything on maybe queue workers. It's barely anything and it saved you tons of time in management." I listened to that and I was like, "I don't like this."
And then I started thinking, "You know what, why don't I like this? Actually, I kind of trust what he's saying and it makes perfect sense." And maybe there's a middle ground of like, you keep separate containers for certain things but things that kind of go together. Then I just said, "You know what? I think I was wrong." I think that for the type of stuff that I do mostly, I was wrong to always have such separate containers all the time.

Joel Clermont (04:06):
You realize I'm recording this so I'm going to use that clip later. Where Aaron said, "I was wrong."

Aaron Saray (04:11):
I thought I was watching your face and you go like, "Oh, we have a lot of projects with separate containers. What are you trying to tell me?"

Joel Clermont (04:18):
Yeah, I'm kind of going through the same mental process you're describing. Because I'm like, "But no, Aaron. Aaron, no."

Aaron Saray (04:24):
But the whole point here is this is an example and you can still disagree with either one of these points. But it's important for us as developers to understand that as we grow through our journey of being a developer, that we're going to learn new things and have new insights and people are going to explain stuff to us differently. The best programmers can be fluid and change their mind when presented with new information. It doesn't make you a great programmer to only be stuck in your way as a best practice if you never re-evaluate it.

Joel Clermont (04:54):
Yeah, I think that's fair. But it's also a good point to make because sometimes we put these best practices up on this pedestal where they're just not to be challenged. Because either we heard it from a reputable source or maybe through personal experience we even found it to be a best practice. But like you said, "Things change."

Aaron Saray (05:14):
Right. I think we've talked in other episodes too that there are reasons for things. So if you have a reason for a best practice, then you're challenging the reason, you're not necessarily challenging the practice.

Joel Clermont (05:26):
Sure, yeah.

Aaron Saray (05:26):
So you're saying like, "Does this reason still make sense?" and whatnot. If you're adhering to best practices... I mean that's great when you first start out. You don't understand why but your job then is to immediately start down a path of understanding why this best practice is the thing that you're implementing so that you can buy into it wholly.

Joel Clermont (05:47):
Well, and the context you started setting this up with a best practice in a Fortune 500 Company with dozens or hundreds or thousands of containers might be different than me and you shipping an app for a much smaller company using far fewer resources. The best practices should, I think, be context-sensitive too. That's an important thing that you mentioned at the beginning there.

Aaron Saray (06:12):
Another example I can use is that, I'm a huge fan of contracts, interfaces, implementing different things. Laravel makes use of that too as well. You know, you can implement (should queue 00:06:25) and then a thing will queue, and stuff like that. There's a lot of use for that. However, it's one of those things like if you have a hammer everything looks like a nail. I've built projects before where I made basically an interface for every single thing that was ever injected. My mindset it was, "Well, I build these injections based off the contract and then the actual concrete implementation is what's bound," and et cetera.
And there's a lot of good things in that way of doing stuff, but it just got more complex so I had to make another file for every single thing. Then I was reading again and I just came across stuff that I've read a million times before and it just kind of clicked differently and I had to change my mindset. Which was, yeah, interfaces are great but you want to use it for notifying a specific or kind of mentioning a specific functionality like Laravel does, like should queue, things like that, so identifying something of a class. Or if you are reasonably certain you're going to swap that out at some point. If you built something, let's just say like a Twilio service, and that service integrates with Twilio and you've named it Twilio Service, there's no reason to make a contract for that because you're not going to use a different tool and name it Twilio, you know. They're not going to be the same and you're probably going to stick with that vendor too. The idea that you might swap out your text, probably not. I mean, maybe payment methods, we've done that a lot. But even so, those are pretty big projects in general where you're probably touching a lot more than just the public interfaces.

Joel Clermont (08:06):
For sure, yeah. You mentioned, Laravel does this too so it just gave me a thought. Like, it kind of backed to that idea of having a reason. Sometimes the reason we do something is because we see other people doing it. But I was just like, as you were kind of talking through the evolution of how you viewed these contracts/interfaces, it's changed. And looking at Laravel, not everything there has a contract. Some things are concrete, right? So just calling that out because I know us programmers... maybe this is just me, but there's this tendency to kind of copy what other people are doing or what you see done elsewhere in a code base. Even if it's the framework you're building on top of. So I just like that idea of coming back to having you reason, understanding like, "When does this provide a benefit and when is it just unnecessary ceremony that's not really adding any benefit to the code?"

Aaron Saray (09:03):
I think the last thing I wanted to kind of wrap this all up with is more about working with your fellow teammates or the community and stuff too in regard to this... I'm not trying to be the attitude police but part of the maturing as a programmer too is understanding that you're going to experience these things and other people are going to experience those same things too. If someone changes the way they do something and maybe they have a reason, try to take a little time to understand why they've changed something. Not be like, "That's dumb," or, "You didn't know that already?" Or whatever.

Joel Clermont (09:42):
Sure.

Aaron Saray (09:42):
Because you're going to experience the same sort of things too. So it's incredibly difficult, in my experience, and incredibly humbling to be known for a specific set of best practices in a way and then change that. It's already stressful to kind of be like, "Well, everyone knows I am the guy who writes contracts." And then all of a sudden you're like, "Well, I've been hammering everything that wasn't a nail? Haven't I?"

Joel Clermont (10:08):
Yeah.

Aaron Saray (10:09):
If you care about your craft, it's already probably personal that you maybe felt you were wrong now and there's some humility and there's some little heartache with that, I guess, at least for me. So you don't need to pile on that as other people, just be happy that the person you're working with is kind of learning and growing.

Joel Clermont (10:27):
Yeah, I find social media is very reasonable in that regard. There's never any hot takes or anything overly opinionated. A very reasonable place to have a dialogue.

Aaron Saray (10:40):
It's the best place to mention that you were wrong.

Joel Clermont (10:43):
Exactly.

Aaron Saray (10:51):
I've done this before and I'm sure you have. I guess I don't know, but I'm probably certain. But what is the deal when you're trying to indicate that something is good, like a big physical thing that you slap it?

Joel Clermont (11:08):
Oh, can you give me an example?

Aaron Saray (11:09):
Like, and you're like, "Ah, that's good." Slap-slap. Or, I guess like kicking the tires, for example, too. Like, that's a... You kick the tire." Or just like when people are like, "Ah, that's a trusty car," and they hit the roof or something.

Joel Clermont (11:24):
Okay, all right.

Aaron Saray (11:25):
Why do we hit things to indicate that it's a good thing? I don't get that.

Joel Clermont (11:31):
Does that apply to people? Like, if we like somebody, we can kind of slap them on the back a little bit, right?

Aaron Saray (11:36):
Oh, yeah, you do. Like, if you shake your hands, then maybe you tap them or whatever.

Joel Clermont (11:39):
Yeah.

Aaron Saray (11:41):
Right. And that's different than the man hug, which is you bring a person close and you just kind of beat them on the back a little bit. Just, "Yeah, I'm not going to hug you but I'm show you I love you by slapping you."

Joel Clermont (11:52):
I can relate. Yeah, I do those things, you're right.

Aaron Saray (11:56):
Why though?

Joel Clermont (11:57):
There's a deeper philosophical meaning.

Aaron Saray (11:59):
Yeah, I don't know. It just seems like counterintuitive too. "This is a good thing, so I'll punch it."

Joel Clermont (12:04):
Yeah. When you say it like that, it does not make sense.

Aaron Saray (12:09):
Would you like to overpay for an eBook? Well, you won't at masteringlaravel.io.

Joel Clermont (12:14):
In fact, two of the eBooks are completely free, but you can pay if you want. So if you really want to overpay, that is an option for you.