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:07):
And this is Aaron.

Joel Clermont (00:16):
As you know, Aaron, I'm a pretty boring person. One particular thing which we're going to talk about today, I just like kind of doing things the default way. I'm probably a little unique in terms of developers in that I tend to not have strong opinions about things. I mean, not always but sometimes. Even here I'm being boring that I can't take a side whether I have strong opinions or not. But I think there is actually some benefit in sort of sticking with the defaults. Now that could be in your code editor, in your terminal, in your framework of choice, all sorts of different ways you could apply this. But I think there's a benefit in sticking with the defaults unless you have a very specific reason not to. And I'm just using that to kind of kick it off. I think you know that about me and here's your chance to kind of vent your frustration with me about that personality quirk.

Aaron Saray (01:11):
Well, one of the things that you mentioned about keeping with the defaults that I have seen that's worked pretty well... well, a couple. One is then if you have default project, new developers come in and they generally know how it works. And we've talked about that before, stop making stuff so complicated you're not the only developer ever that's going to touch this. The other thing is you're a fan of using Laravel Shift to upgrade your projects and one of the things you'd mentioned is, "Try not to change your default configuration files because it makes that harder to upgrade" Maybe if you're going to have some unique configurations, put them in a separate file that might be named after your app instead of putting it in the app one." I've seen that as a benefit. But there is a specific... I mean, if you turn off defaults you have to have a specific reason, a repeatable, rational reason I think, to do that. And I wasn't always that way either. I thought I knew better but you have to have a specific, repeatable, rational reason to turn off those defaults. And I can think of one as an example. When I run a PHPUnit, I tend to turn on by default the functionality to stop on failure.
A lot of projects are set that that doesn't so I think that the concept or the idea is that you'll run all your unit tests and if three fail and the rest are passing, great. You only have three to fix the rest of your tests pass. And even there's functional inside a PHPUnit, I think, that you can turn on like, run only my failure. Though there's sort of a caching functionality. So theoretically it should make the tests suite go faster as you're developing and working through it. The first time it really got to me but then I found it a few more times is that sometimes the failure is a legitimate failure and it stems from the fact that you've written your code incorrectly. And then your other tests that are passing even in other parts of your test suite are passing accidentally or you've written those tests incorrectly. So when you go and do that, and then you change your code is PHPUnit, are those tools are going to be smart enough to know to run the other falsely passing tests?

Joel Clermont (03:25):
No.

Aaron Saray (03:25):
It's not, yes.

Joel Clermont (03:27):
It will not.

Joel Clermont (03:27):
But if you have... Let's just say you have something that always returns true and luckily you have some tests around that that check for the true and false state and those are failing, I don't want to move on beyond that. Because there might be code later on its testing, a of couple different flows of that in a more integrative way that is accidentally passing and now it's just going to look past. So that's kind of one of the defaults that I picked to turn off or on.

Joel Clermont (04:00):
I also accept that deviation from the defaults. At first, I think maybe we even argued about this a little bit at first because... I mean, just to kind of take the other side for a little bit. I could see some limited circumstances where you might want to see all the failures. For example, if something fails in CI, maybe theoretically it would be nicer to see that these four tests failed instead of just which of the first failed. But certainly-

Aaron Saray (04:28):
I got to interrupt there because doesn't really matter. As soon as one fails-

Joel Clermont (04:32):
It doesn't matter, no.

Aaron Saray (04:32):
... I want my CI to immediately stop because I don't want it doing any more work. And when CI fails on the very first thing that's the key to me that I need to bring this project back into my local state and work through the issues. I see what you're saying but I disagree.

Joel Clermont (04:48):
And I was just kind of maybe a standard for somebody listening to this and yelling at their Zoom or whatever they're listening to this on.

Aaron Saray (04:56):
At Zoom.

Joel Clermont (04:58):
But, yeah. I mean, you make a good point because technically if you're on a CI platform, you know GitHub Actions or something, you are paying per minute. Now, maybe you never exceed your free tier and it doesn't matter but why run it the extra few minutes? The other scenario, and again I'm just kind of reaching for things to have you-

Aaron Saray (05:18):
Smash down.

Joel Clermont (05:19):
I'm thinking of a particular project where the tests were kind of slow and maybe it took 9, 10 minutes and then it fails at 97%. You're like, "Oh." So you still go fix it and then you rerun it again and now it fails at 98%. So that was one time where I think it would've been nice to know that there was maybe two failures lurking for me instead of just the one. I mean, that's kind of an edge case because, number one, make your tests faster. And number two, that doesn't happen that often that it's right at the end two different times.

Aaron Saray (05:53):
And I can see what you're talking about with that, but it still suffers from the same thing. What if that test at 98% was something that affects something else-

Joel Clermont (06:00):
Sure.

Aaron Saray (06:00):
... and you need to remember to run those again? I guess we're just really digging in on this particular topic, the other thing about it is with PHPUnit in your test base or your class-based tests, it runs in a predictable fashion, so in a predictable order. So in that case depending on how you have your tests organized or whatever, you probably could have ran at a folder level. Like run PHPUnits based tests, features, admins\blogs, you know if it was like that was the last thing or whatever. And just run those four tests or those five tests that are in that folder again while you are developing and fixing those issues. It can't be overstated enough that just target the test that's failing and run it over and over until it passes. I'll be honest, in cases like you're talking about with that I generally have a good feeling that my other tests are going to continue to pass so that's why we have CI set up as well. I'll test over and over that section and then I'll push it out to CI and go, "If it fails, I'll just find a way to blame Joel."

Joel Clermont (07:07):
That's right, yeah. "He approved this PI, he shouldn't have done that." So take your side again, because actually I do agree with you. But the other thing too is like, let's say you just did a major version upgrade for Laravel or one of your core packages or something, there's a good chance it'll break a bunch of tests. And I think it would be pointless to run your whole test suite locally and see, "Oh, 84 of my 1,500 tests failed," when in reality maybe it's all because the translation strain for a particular validation rule changed from must to may or something like that. So it's going to be kind of a boiler plate find and replace thing that'll fix a bunch of tests anyways. It's like, "Oh my God, I have 84 failing tests." And no, really, you probably have like two or three things you need to fix.

Aaron Saray (08:00):
All right. I when you pull from the archives just to demonstrate to listeners that you've been around for a while. That error changing from may to must I remember that. That was a couple of Laravel versions ago, nice little humble drop there.

Joel Clermont (08:14):
Yeah, that's what I to do. Nice callback. So, Aaron, I'm glad you picked this particular example of PHPUnit just to show I'm not unreasonable and I'm not strongly opinionated that you must use the defaults. There are times where it makes sense to deviate but here's where it boils down to for me and this kind of default path. It isn't really about being boring or vanilla, but it is about not fiddling with things if you don't need to. I know there are people that take great pride in mapping custom shortcuts for PHPStorm to do all sorts of things and that's fine. That's just not me, that's not where I seek productivity or seek to get better as a programmer. I find just kind of sticking with the defaults suites me pretty well for the 95% case and then the 5%, yeah, tweak it. If you have a reason, if you're bumping up against something, I'm not afraid to change it. I just don't go looking for things to change.
If I were to ask you, Aaron, what season are you? Would you have any idea what I'm talking about?

Aaron Saray (09:30):
"Hey girl, what's your season?"

Joel Clermont (09:33):
Sure, along those lines.

Aaron Saray (09:34):
Well, I have two thoughts really. I would go either fall because I like to have like a sweatshirt on or is this a dating show? Or I would say garlic because you can put me on everything.

Joel Clermont (09:50):
I didn't say, "What season do you like?" I said, "What season are you?" Okay, so I'm going to go back to my-

Aaron Saray (09:57):
Well, then I'm winter. I'm winter because I'm just cold and frigid and no one likes me but you put up with me.

Joel Clermont (10:05):
Before my days where I program professionally, I had an IT business where I'd go set up computers for companies and fix stuff. And one of my-

Aaron Saray (10:16):
You were working on computers in '53?

Joel Clermont (10:21):
Oh my goodness. Yep, exactly. And one of the customers was a women's clothing store and this was in the late '90's. And there was this thing where a person has a season as their color palette. Like, what shades of makeup they should wear and what color of clothing they should wear. So it was a whole thing and I had no exposure to until I'm just sitting there working on their cash register computer and I'm hearing these discussions and I'm like, "This is really weird." Okay, so just to kind of set the stage for this company I was working at. I have sort of an embarrassing story to share and I just thought you would get some enjoyment out of it. This clothing store next door, there was a hair salon or something that went out of business so they expanded into that space and it became a day spa or something. So I was over there setting up a new computer and the woman who owns the business was training people that were going to work here. So she's telling them this and telling them you got to do this and you got to do that.
And she's like, "Joel, Joel, this is perfect. Can you come over here for a second?" I'm like, "Okay." So I come over there. Picture the owner of the store, maybe three or four younger women that are going to work there. And she's like we want to do a treatment on your nose. They take my head and they put this creamer, I don't remember even what it was. But at first they're like, "Look at his skin." It's this type of skin and it's that and I was getting extremely uncomfortable. This just popped up into my memory the other day because I'm like, "That was probably one of my weirdest on the job experiences but I did survive it."

Aaron Saray (12:00):
That's what I like about programming though, is you get to experience and learn a lot of different things.

Joel Clermont (12:05):
That's true.

Aaron Saray (12:05):
I worked for a client who worked for... I think I can say this, worked for Boots, which is a pretty big retailer in UK and other places. I went to work for this company because I thought I would be able to work on Subaru stuff. That's kind of how they sold it and I had a Subaru at the time. I was like, "Yeah." And they're like, "Okay, you're going to work on Boots." I'm like, "What?" "Specifically, you're going to work on their makeup stuff." Like, "What?" But as much as I joke about it, it was actually really interesting. I had no idea all of the business logic behind it. We were building these things where they lay out the shelves and the makeup section by shelves and then what are called cassettes. So each individual shelf has three to six different sections and then there's slots inside of there. And it was all actually organized by the makeup companies and brands and stuff with jockey for position based off eyeliner and all that kind of stuff. And we were building the interface so people could send this season's version of their makeup layout. It's pretty interesting.

Joel Clermont (13:13):
See, we do learn a lot being out there in the world.

Joel Clermont (13:19):
Have you ever wanted to dress like Joel? Please don't, but you can learn like Joel.

Joel Clermont (13:23):
We've published some free resources to master Laravel at our site called masteringlaravel.io.