Latest / North Meets South Web Podcast / Verbs, stolen chargers, and Laravel 11

Transcript

Verbs, stolen chargers, and Laravel 11 · North Meets South Web Podcast

• 0:00
  Michael: Hello. I am Michael Dyrynda.
• 0:02
  Jake: And I'm Jake Bennett.
• 0:03
  Michael: And welcome to episode 153 of the North Meet South web podcast.
• 0:10
  Jake: There it is. You did it. We got it. Hey. I'm gonna request that we go full on, full intro music from this one.
• 0:16
  I'm I'm I'm just Who was it?
• 0:18
  Michael: Someone commented on it last time.
• 0:20
  Jake: What'd they say?
• 0:21
  Michael: Someone someone agreed with you about the the full intro song.
• 0:25
  Jake: I just love it.
• 0:26
  Michael: I can't remember who it was.
• 0:28
  Jake: It's a really good one. And you know what else? I was listening to no plans to merge, and they have a really cool intro song, and I love listening to it. It's you know, that whole little clapping thing? It's really fun.
• 0:39
  Michael: Yes. It's really fun. I've never it's funny when I hear a podcast at, like, one time, because I listen to all of my podcasts at 2 and a half times, because I listen to far too many of them. And so as a result, I listen to them at a high speed, and every now and then I'll hear a podcast or Rhee and I listen to the same podcasts, you know, some of the parenting ones and things like that. And so I will hear her listen to them.
• 1:05
  I'm going, oh god. Is that what they sound like?
• 1:08
  Jake: Right. Right. That's I
• 1:10
  Michael: get that from my boss at work. He's like, oh, it's so weird hearing your voice at one times. Can you talk faster?
• 1:16
  Jake: Yeah. Can you talk at 1 and a half times speed, please? The funny thing is doesn't it all doesn't it sort of, like, you know, it used to be when you'd put, like, a record, like, when you're a kid, where you put a record at, like, 1 and a half speed with some of like chipmunk voices. Right? And it doesn't do that anymore.
• 1:29
  It like keeps, it maintains the the tone of the voice. It just speeds it up. Right? So, It's, it's like this, the tone is the same. It's just, yeah, it seems like you're talking slow.
• 1:41
  Michael: Mhmm.
• 1:41
  Jake: Yeah. Yeah.
• 1:42
  Michael: I think it was Justin Jackson. I'm gonna say it was Justin Jackson
• 1:45
  Jake: Okay.
• 1:45
  Michael: Who who who agrees with you on the on the audio.
• 1:48
  Jake: Well, if it's Justin Jackson, I kinda have to, you know, defer to him. He is, like, the podcast guy. Yeah. He is indeed. So, first and foremost, kudos to mister Michael Dorinda for editing our podcasts for all of these many years.
• 2:06
  Thank you so much for doing so. And also the last Laravel News podcast sounded really freaking good. I don't I was like I was listening to it, and I'm like, this is, like, the best it sounded in a long time. And I was like, did you do anything special to it? And you're like, I don't know if I did anything special to it really, but it sounded much better.
• 2:22
  And so Oh, good. Anyway, I was just thinking about it. I was like, thanks for thanks for editing all those. It's it's a lot of work. I really, really
• 2:27
  Michael: appreciate it. Hopefully, this one comes out pretty well. I, I don't know if you saw that other podcast that I did. We we interviewed Ripples.
• 2:33
  Jake: Yeah. As Aaron Aaron Francis.
• 2:35
  Michael: Interviewed Aaron Francis, which was a was a great chat, but I thought if if he's gonna try harder, then I need to try harder. And so for
• 2:43
  Jake: that
• 2:43
  Michael: episode, and I will probably do it with this one as well. Not that I don't think anyone watches the video that that we know published for this episode, but or for for this show, but I think it was just a bit of fun to so I'm trying to learn how to use DaVinci Resolve because I've got some marketing stuff that I need to do for Laracon AU coming up, and I thought, well, I may as well use this as an opportunity to kind of learn the tools so by the time it comes to doing those things, you know, I have a reasonable understanding, but it makes doing multicam editing very simple, and it syncs everything up so I can just, if I wanted to, we ended up stacking the videos so that we had, you know, side by side and things like that.
• 3:24
  Jake: It looked really good. Yeah. It looked solid.
• 3:27
  Michael: You can if you want to, essentially go through and, like, just click the camera that you wanna focus on.
• 3:37
  Jake: Mhmm.
• 3:37
  Michael: And it's a bit harder in in that kind of podcast when when people are talking, like, there's a conversation rather than just a sing singular talking head. You know, you don't wanna hear in the background some going, yeah or, mhmm, or, you know, the agreement. You kinda wanna see that person, I think. But you can, if you're doing lots of switching, just like click camera 1, click camera 2, and, like, bounce between them, and it just handles all of it, syncs it all up. And, yeah, I think I took some of the tips that I learned from Aaron's screencasting.com course, in terms of, like, ducking video or ducking audio under the next video clip and things like that.
• 4:12
  I think it made the transitions look a bit nicer. You know, having Aaron nodding whilst someone talks under him in in a full frame, and then so I don't know. It was just a bit of fun to play around with it.
• 4:24
  Jake: That's pretty cool. I we, we have the because DaVinci is made by Blackmagic, I think. Right? DaVinci Resolve is Blackmagic. Right?
• 4:32
  Yep. And so we use a lot of the Blackmagic, tools with Blackmagic cameras. We have the, ATEM Mini Extreme, I think is what it is. And so it's like got 8 different inputs. It's got a couple different USB-C outputs, one to a clean webcam.
• 4:47
  You can, you can customize what they are, but one's like a clean webcam output. The other one goes to, like, a little, a little, storage drive. Right? A little USB, storage drive. And so it outputs all of the videos, in both your, so your display, like, whatever you have as your displayed version, but then it also outputs all the outputs all the raw and the just the video feeds individually.
• 5:11
  Right? But I think we could what you can do after the fact is in DaVinci Resolve. I think you can also hook up the ATAM Mini and sort of use that as your switcher. So you can, like, video 1, video 2, video 3, video 4. And and you can actually find those pretty cheap.
• 5:24
  They've got some of the older ones on eBay, you know, like they've got a 10, mini pro, or they might have just, like, a smaller one. That's just got, like, 3 or 4 inputs, and that actually might be perfect instead of having to click around. And I know you're a tech head. You love all the you love all the gear. I know.
• 5:38
  Friends,
• 5:45
  Michael: to do the live streaming of PHP[Tek] in previous years, and every time he mentions it, the on the PHP Ugly podcast, I I get up the Blackmagic website. I'm like, well, I could
• 5:55
  Jake: buy Yeah, man.
• 5:56
  Michael: Business You know what? Business expenses now. It would be hard to buy
• 6:00
  Jake: see. We might have an old one. We might have an old one around.
• 6:03
  Michael: I should see. It's just I I thought I could pick up one of the cameras to use the the cameras, like, just the cheap single, and it's, like, I think it was, like, $900. I thought it's not unreasonable Yeah. But it's it's just the body, like, all of the advertising lenses are way
• 6:21
  Jake: more expensive than the bodies.
• 6:22
  Michael: All of the advertising on their store and all of the photos show the cameras with the lenses, and they don't Yes. Like Canon and Sony, they all say body only. Like, it's very clear that it's body only. It's not until you, like, really dig into it that you find out, oh, no. This is just the body, and you've gotta, like,
• 6:40
  Jake: go and
• 6:40
  Michael: figure out where to buy the camera the
• 6:41
  Jake: the lens. Some freaking prime lens. You know? Yeah. Like
• 6:45
  Michael: But having the ATEM would be cool even, you know, if if for no other reason than to just be able to do input switching. But Yeah. Like, we've got really nice for this is is pretty easy. And, like, the the DaVinci software is really nice, and I'm surprised at how much functionality they pack into it for free. And it's, like, you don't really hit any of the limitations that would make you want to pay for the, for the for the studio version, which is, like, the $300 software version.
• 7:10
  Jake: So Even $300. I mean, like, isn't that so much? I feel like it used to be back in the day, like, if you wanted Adobe, Final Cut Pro or whatever, it was like a $1,000. Cut.
• 7:19
  Michael: Yeah. Yeah. You know
• 7:19
  Jake: what I mean?
• 7:20
  Michael: It was just like crazy. Now, it's still expensive to buy. Like, Final Cut is is probably $400 or $500 or something like that Australian. To get to get what you get out of it is incredible. And, like, the main reason I used it was that I got the I got an ad somewhere whether it was Twitter or Facebook for all of these plugins, and you could get them in Premiere Pro or DaVinci or some other tool.
• 7:42
  And I was like, oh, it was $80 on sale from 500. I thought, yeah. Okay. That'd be that'd be cool. But I messaged a friend of mine who, like, he does video editing for a living, and I said, I am not smart enough to use this software.
• 7:57
  It took me 10 minutes to figure out how to put a title into the Dude,
• 8:00
  Jake: I the timeline. So Yeah. I don't mess with that. I usually use like, if I'm gonna supposed to do something quick and and fast, I just use Adobe Rush anymore, if I have to. The problem is I don't wanna install Adobe Creative Cloud on my machine because it's like cancer.
• 8:13
  It just takes over the machine eventually. Oh, it's a whole thing. Yeah. And so I just don't do it anymore. I just I give it to somebody else to do.
• 8:21
  Hey. Can you go edit this real quick for me? Or I'll literally do it on my phone. Sometimes I'll just do it on my phone. It's easier that way, and it's just an app that point.
• 8:27
  So at least it's, like, contained sandboxed into this one little spot in your phone. You can start to install it, and you're done. So anyway, anyway, that's that. So, yeah, Ripple's podcast, really cool. I was actually I didn't get a chance to watch all of it, but I did see that you guys had done so with, with Aaron, and so looking forward to watching that one.
• 8:46
  That's that's pretty cool. So we had talked about, before we started the show, talking about a couple things today, verbs being one of them. So Eric, let's talk real quick about Eric Barnes too. So Eric Barnes has like a studio now. What is this?
• 9:02
  Like, he's got this sweet little co working space studio that he set up, and he did a first, like a vlog, not a vlog, like, a video podcast with Daniel Coborn who apparently had a layover, right close there, and it looked really super solid. It it looks good.
• 9:17
  Michael: He's got the lights there. He's got the
• 9:18
  Jake: Yeah.
• 9:19
  Michael: The 3 cameras. Yeah.
• 9:21
  Jake: So I'm I'm curious if that's his whole setup or if he I think they said, like, in the co working space, it's just like you can reserve it or something, and then
• 9:28
  Michael: Yeah. So I don't know.
• 9:29
  Jake: It was
• 9:30
  Michael: I I did ask him about it. There is, like, a podcast studio in there, but he's also rented out, like, an office space in there that looks really cool, which he will do. I see because it's got, like, a a white brick wall on one end of it. I said, don't touch that wall. Like, that's the background.
• 9:46
  Jake: Just leave it. That's the background.
• 9:47
  Michael: Whatever you're doing. Throw some lights at it, put a desk in front of it, and and you're all set. So I think, you know, that's where he's gonna do, you know, the the Laravel News content that he's doing. He's got the podcast therapy. He's gonna get people in.
• 10:00
  I think that that the hard part will be getting people to him to to do that, but I I like the idea of it.
• 10:08
  Jake: Eric, if you're listening, I'm game. Next time I'm anywhere near, I'm coming to visit. I'd love to see your space. That'd be pretty cool. So but Daniel Coulbourne was on there, and he talked about the origins of No Plans to Merge, like, their the name of the podcast, why they called it that.
• 10:22
  And he also talked about Verbs a little bit. I again, it's one of those things. I keep saying this. I didn't get a chance to listen to the whole thing. I've I've seen enough to know kind of, like, what's on it, but I didn't actually listen to the whole thing.
• 10:32
  But he talked a little bit about verbs, which is this package that he's been working on for the last while, and I thought maybe we could talk a little bit on the show today. Have you looked at verbs very much? I know that he did a talk at AU, which he had a little bit of problem with, like, partway through. And so he didn't get to get to get through all the demo that he was hoping for. I know he did one at EU as well.
• 10:55
  And, again, I didn't get to watch that one either. But have you gotten a chance to look at verbs very much or or mess with it? I installed it today, just started playing with it.
• 11:03
  Michael: Yeah. Not not used it, but what I saw like, I did I did see his talk at lauriconau, not in person, but I've watched the recording after the fact. And I I like I like the proposition that it gives you event sourcing without all of the complexity of event sourcing, without all of the the terminology, I think, is is a big like, you learn it and you get past the terminology, but I think the terminology is a blocker in terms of developer experience for picking it up. But I think for the the kind of work that you do and and the kind of work that I do
• 11:47
  trying to retrace steps of, like, how did we get into something or whatever. And and being able to have the event stream there would certainly make things easier, but it's just there's too too much stuff on in terms of building what we need to build functionality wise for the application to be able to go and figure out how we're gonna retrofit stuff in there. And I know I know that his talk, I think, at Europe was Laracon EU was was around, like, bringing this stuff in incrementally, and there are probably places that we could
• 12:22
  Jake: do it Interesting. Bit
• 12:23
  Michael: by bit, but there's there's just so much on that it would be, you know, a multi month project to to kind of, you
• 12:31
  Jake: know,
• 12:31
  Michael: where we could bring that in.
• 12:32
  Jake: Yeah. I think it is interesting, like, because, you know, most of the most of the applications that you're going to need something like this in are probably applications that have been around for a while. If you're just starting a brand new application, okay, sure. Maybe, maybe you need this, but I think most people who are just starting an application are sort of in rad mode. You know, they're just trying to get something out the door.
• 12:52
  Right? So they're not necessarily worried about event sourcing at this point. Maybe they should be, maybe they shouldn't, and maybe verbs actually makes it easy enough where you can kind of start with it. That's possible. I've been talking about this project that we have coming up.
• 13:05
  I suppose I can talk about it a little bit, but we do have a greenfield project that we're gonna be working on, Jordan Brill and myself, who Jordan's my boss, my buddy that we've been working together for, like, the last 13 years. And so we have this product that we're gonna be building, and it's really interesting because we've got this you know, it's completely greenfields in front of us. And so it's the reason part of the reason I'm writing about reading about about verbs is because it would be really nice to have that traceability and to be able to just see that throughout there. The other the other day, we were talking about, on the Herbal News, time zones and, how to manage those. And that's another thing that would be really nice to have in there, is how to, you know, handle time zones.
• 13:42
  I saw I saw somebody on Twitter talking about this the other day, and you'd mentioned, like, hey. There's a really great package for this actually that we just talked about. So, verbs seems like one of those things that could be really useful if we baked it in from the beginning instead of having to retrofit it. And what you were talking about too is I think Daniel's goal here is really, like you said, to bring event sourcing to the masses. Right?
• 14:03
  And, they actually have a whole page in their docs called combating jargon. Right? And the idea here is that in traditional event sourcing, there's a lot of complicated wording that can make it hard to just get started. Right? So the, one of the things that they really tried to do in verbs was to abandon a lot of that for more simpler, more simple and obvious, terms.
• 14:23
  Right? So they're getting away from aggregates or aggregate roots, and they're calling those now state in verbs. There's this idea of projectors. Right? And so what they're doing that instead of saying something as a projector, they're saying, well, when you call the handle method, that's where you're actually updating your database models.
• 14:40
  Right? And so you have reactors. And so they, they're, they're just basically taking all of these things that were sort of maybe difficult to understand or, or words that you hadn't heard before and not necessarily dumbing them down, but sort of mapping them to things that, as a Laravel developer, I'm already familiar with. Right?
• 14:57
  Michael: Yeah.
• 14:58
  Jake: Even something like using like having a method called handle. I'm very familiar with that because I know that's what I use for jobs. That's what I use for commands. It's just, it feels normal. It feels, very approachable.
• 15:08
  So, I love that about the package, but there, I will say, like, I've read through the first page a couple of times and I'm still I'm not there yet. Of course, I will say I've only given it, like, 30 minutes. Right? That's that's where I'm at. Quick start is easy.
• 15:22
  I feel like they've actually done a really good job in trying to explain it. The, the, the docs aren't only like, here's how you get started with it. It's really explaining here is our methodology, here is, the approach that we're taking to this, and they try and, teach you the ideas behind event sourcing as well as how to utilize the package. So it's it's pretty cool. So I am just getting started with it, but it looks like if I, like, if I'm just giving you my first pass on kind of how this how this works, it looks like you fire events, right?
• 15:54
  Of course, event sourcing is going to be heavy on events. That event can contain some data that you're going to put on it. I will say that it's it's cool that they extend a thunk verb event for each event that you have. It's not a Laravel event. It's a thunk, verbs event, and there is some really cool, it's a cool API for how you can do that.
• 16:15
  So you call the event, double colon fire, and then you can pass in as named arguments, any items that you had set as public values on that particular event. So that's really cool. It, it feels really nice and feels very simple and clean for anybody coming behind you to look in and be like, oh, okay. I'm injecting a customer ID into this event. So there's that.
• 16:37
  But then past events, what you have is these states. So this is where, this is an in memory sort of thing. This is not in your database. So you have events, then you have states, then you have models in your database last. So that's that's kind of how it works.
• 16:54
  And so these states are in memory, and, it actually, in addition to updating state, it also is responsible, and this is where I'm getting fuzzy. The event, I think, is responsible for knowing whether or not it should fire itself, like there's a validate on the event and then an apply on the event if it determines it should be fired, and that will update a particular piece of state. And then the state itself, I think I think, has a handle method that will then update your database. So I think those are the couple pieces, and I and Michael said this, I apologize for anybody watching this, I've got my laptop on a stand, and so anytime I touch anything, it's wobbling like crazy. So sorry about that.
• 17:43
  Let's pull, like, image stabilization on this after the fact. But I think that's the way it works. Events, are fired. They have their own ability to be able to pull in a state and then use that state to validate whether or not they should be fired or not. And then once they fire, the state is responsible for updating some state in memory and then the state itself will call apply, and at that point is when you actually save it to the database.
• 18:07
  The idea here too is that you should be able to basically delete all of your models and replay the events to get back to the same state you were at before. So the models are sort of like a side effect. They're just like it doesn't even matter. If you were to nuke your entire database except for the events table, you should be able to replay all of your events. They should go through those states.
• 18:26
  And then as long as you have the you know, that apply that's kind of handling your your database stuff, it'll it'll rebuild your entire database as it should be.
• 18:35
  Michael: Yeah. Yep.
• 18:35
  Jake: So that's pretty cool. And I think that's one of the big benefits.
• 18:37
  Michael: Right? The Yeah. One of the big benefits of this of event sourcing is that you can reconstitute the current state of your database in the event that you need to change some behavior or you need to inject some new behavior. You know, you wanna suddenly, you want to go, how do we report on this data historically? You don't have it.
• 18:58
  Mhmm. You can add the Yeah. I guess, the event handler, whatever whatever that is, and then apply that transition or that change to the model historically. And then suddenly you've got a new table that has this new information there that may not have existed. And so I think that's the the the power of it, depending on whether you make that live or if you're doing that on some kind of, like, replica where, you're doing it for reporting and things like that.
• 19:27
  You know, being able to reconstitute the world as you know it because you've got that historical data of, like, this model was created on this date, and it was updated to, you know, this thing at this time, and some status changed, and some column was up there. Like, all of this information being stored in your events table allows you to then replay and introduce new understanding of that data retrospectively. And then Yeah. The you know, you talked about the the projectors and the and the reactors and things like that. If that I forget the terminology, but, like, the thing that that is side effects.
• 20:04
  Like, you can go back and replay creating a model retrospectively without also triggering the event that sends an email to your customer, you know, that, okay, we we're we're replaying the state of the database, but we're not replaying those those side effect things, sending emails, text messages, etcetera, etcetera. Those are all side effects that kind of can be omitted whilst still reconstructing the state of the database. So there's there's definitely a lot of power to it, and and I I think there are certainly industries that it applies to. Finance, insurance, those kinds of things where you need to kind of track the state of things happening, not just the state that they're in. But as as we said at the top, you know, it's it's difficult to retrofit that onto existing data.
• 21:01
  But you've gotta make the decision either at the start or from, like, some date that, you know, we are now doing this so that you can have that behavior in your application. So, yeah. It seems similar to
• 21:12
  Jake: to also how you guys migrated the snowflakes. Right? I mean, that was, like, sort of a multi week or whatever it was migration that you guys made. It seems similar to what you would have to do if you wanted to jump onto this event sourcing bandwagon after the fact.
• 21:25
  Michael: Yeah. Yeah. You have to have to certainly play out. And and, like, the snowflakes kind of enables us to be able to do that a little bit if we wanted to. I mean, it it it would have worked regardless.
• 21:35
  I think the snowflakes are just useful because especially with events. If you're firing events for, you know, a few 1000 users that are actively using your system, they, you know, they're doing lots of different manipulations to the data. You're gonna have a lot of events there. So the snowflakes kind of help in terms of actually being able to store an incrementing not an incrementing, but, like, an ID for those events for as many as you're gonna have, you know, before you run out of numbers effectively. So
• 22:03
  Jake: Yeah. And I think so, like, if I'm thinking about it too, I'm I'm thinking about, like, how could you retroactively put this into place? I guess what you could do is you could almost fire an event for each of the models that you already have in place and say something like migrating to verbs event.
• 22:16
  You know what I mean, for this particular model or whatever, and then you could fire an event that would then handle the state and the the the updating of the particular thing, and then that would be a state that you could that would be an event that you could replay. The event itself would basically just house all of the values that you were migrating over to this new thing. And, then if you need to replay that, it's got all the data inside of that event that was fired, and and there you go. And I was wrong on that, by the way. It seems like the event itself is what handles everything.
• 22:44
  So it's like the event gets fired, and the event's life cycle sounds like it's like this. There's an authorized hook to ensure that the current user is allowed to fire an event. So the event gets fired, authorize, then validate. So validate if this event should be fired or not. And then you have while it's in the midst of firing, you have this apply, which will update the state, the state that we talked about before, and then, you have a fired hook that happens after the apply, and then after fired, you have handle.
• 23:16
  I know, and that's, maybe that's a lot, but handle is where you would actually do the database updating, but it all happens on the event itself. The event is responsible for knowing how to do all of those different things. I the one of the reasons I'm really, really interested in reading about this too is I feel that there is a play for event sourcing and state machines do work together. Right? They do.
• 23:41
  And I'm curious if Daniel's ever run into a situation where he didn't want to necessarily have to inspect the previous state of the thing in order to know what to do next. Right? So in his example, he gives this idea of, the user has been on a trial before. So like if I say user subscribed to a trial, right, that's the event that gets fired. In his validate step, what he's saying is grab the current state of the customer and look to see, do they currently have a subscription?
• 24:14
  Is the subscription started at null? Okay. Good. And, oh, sorry. Or or is the subscription started at more than 365 days ago?
• 24:25
  Meaning, they can only do a subscription, a trial subscription once a year. Right? Mhmm. And if it's not, then don't allow them to do a subscription. Right?
• 24:34
  K. So in that case, you're having to inspect the previous state to know whether or not they can do it, right? Whether or not they can do that thing. So I'm I'm looking into this because I really wanna see if there's any way for me to integrate state machines into this event sourcing sort of stuff or not. And I'm not educated enough on it yet to know for sure, but what I will say is that it seems, number 1, super well documented.
• 25:00
  I really it's been really enjoyable to read the documentation. It feels like I'm talking to Daniel in a Telegram chat, like it's very clear, and it's like littered with, Daniel isms, it feels like. And so really great job on writing up the documentation, and I'm just super excited to dig into it more. It's it seems like they've spent a lot of time making the API really clean, And, so, yeah, excited to dig into it more and kinda see if it's something we can use in our greenfield application, for sure, but something that we could use to even replace some of this bespoke non standardized, way of handling events that we have in some of our existing applications. I think it would be a lot cleaner and a lot more testable.
• 25:41
  So Yeah. Yeah.
• 25:42
  Michael: Yeah. For sure. Yep. Yep. Yep.
• 25:44
  Yeah. It'd be interesting to to follow along that journey and see how how you do go once you start getting into the weeds a bit more and figuring out how it actually works properly in in your context.
• 25:56
  Jake: For sure. For sure. The one other thing I wanted to talk about tonight, I there's a couple. I mean, one of the one of the stupid ones that I wanted to talk about was, do you find that your kids ever take your chargers for your iPads or for your, like so we have no? They don't ever?
• 26:11
  No? No. No. Tell me how you do this.
• 26:14
  Michael: Well, I mean, our kids are not really old enough. They're only allowed to have the iPad when they're sitting on the couch or or, at the at the table. Right? So the iPad only ever goes from the charger to wherever they're sitting. And then when they go to bed at night or they finish you know, we go out, they they plug it in to charge.
• 26:31
  So they don't they don't even make off with the chargers. I think once they get more mobile with their devices, when they're a bit older, then, yeah, that that may be a problem. But at the moment,
• 26:42
  Michael: no.
• 26:42
  Jake: I think the trick is teaching them to plug it in once they're done. My kids, it's just they leave it wherever, like, they were with it last. It's, like, it's in one of 5 places. Right? Mhmm.
• 26:53
  And so they're always dead. That's the issue. They're always dead. And so they're always, like, scrounging around for a charger, and they don't wanna stand by where it's charging. They wanna go somewhere.
• 27:02
  Yeah. Exactly. And so it's, like, then they can't find a charger, and so they just go find 1. And the place where they find 1 where they know they're always gonna find 1 is, like, next to my bed stand. It's It's like, there's a charger.
• 27:13
  I'll use dad's, and I'm like, what the world? So I'm like, there's gotta be a product out there on the market that allows me to lock my charger to, like, the wall. And and then I was reading on that, and some people were like, if you can't tell your kids to not take your charger and they don't and they, you know, and they listen to you, then you've probably got bigger problems going. Like, maybe that's true. Maybe that's true.
• 27:35
  Maybe the issue is not my kids. Maybe it's that I need to just, you know, explain to them how to respect people's property. I don't know.
• 27:42
  Michael: Yeah. No. We're I mean, the our our kids are pretty good with them, in that they will generally plug them in. Like, when Eli leaves for school in the morning, he will plug it in.
• 27:53
  Michael: Good now.
• 27:54
  Michael: Like, if they don't, then either Ria or I will plug them in because nothing worse than them coming home and not being able to use the iPad. Mhmm. It's gone flat.
• 28:03
  Jake: Indeed.
• 28:04
  Michael: They've left it. So, yeah, either either the kids or and as a last resort, Rhea and I, we will plug it in to make sure that it is charged. Like, they when they run out, they run out. It's like, alright. Well, that clearly means you've been using the iPad for too long, so go and find something else to do for a while.
• 28:18
  For sure. But, yeah, not not having too many issues otherwise with it. The Eli's generally very good. It's like, okay. Yesterday, he came home from school, and I and he goes, can I have the iPad?
• 28:32
  I said, you can have the iPad until mom comes home with with Liv from from childcare. Okay. No worries. And as soon as the front door opened, he turned the iPad off. And then I go out there and he's crying.
• 28:43
  Michael: I said, what's wrong, bud? He
• 28:45
  Michael: or no. Rea went out there and went, what's wrong?
• 28:47
  Michael: And she and and he goes, dad said I had to turn the iPad iPad off when you came home. I'm like,
• 28:53
  Michael: yeah. I appreciate that you did it though, even though you're upset about it, and, like, just try and get away.
• 28:58
  Jake: That's awesome.
• 28:59
  Michael: So he's he's generally pretty good. They're pretty good with with their with their limits, and when they're told, you know, you can do it for some period of time. We put the oven timer on, so that it's, like, when that goes off, it's time to turn iPad off kinda
• 29:10
  Jake: Yeah. Yeah. For sure. Our kids know it's like the there's a 15 minute timer typically, like, before if if somebody else is waiting, they know they have to set a timer, and so it's always a 15 minute timer. So Siri is constantly setting 15 minute timers around our house.
• 29:25
  And, you know, with 4 kids and and, like, an iPad charged at a time, it's typically getting passed around quite a bit. Yeah. And so, yeah, fun times. Hey. One of the other things I was gonna ask you about is if you've had the chance to upgrade anything to Laravel 11 yet.
• 29:41
  Michael: No. It's No.
• 29:42
  Jake: No. No.
• 29:42
  Michael: It's on my to do list to do. I did I did actually run through the Laravel 11, like, alpha shift. Jamek and I jumped on a Mhmm. On a Zoom call and went through it just to see, like because we've got a hoofer of an app, which took, like, 30 minutes to run the shift Oh, gosh. Which helped him kind of get into the optimization of the shift.
• 30:02
  So he's got it down to, like, 3 minutes or something. Like, it runs as quick as as the previous ones, but it's doing a lot of stuff. And because of the reflection and the introspection and things like that that it has to do to kinda figure out what it can and can't remove and what it has to change and, like, he he's done a tremendous job to get it to run as
• 30:19
  Jake: soon as possible. Yeah. As quickly as it does and as insanely insightful as it is.
• 30:26
  Michael: Yeah. So we've I've got a a task to do it at some point. So we've got a PHP a point 3 upgrade and a Laravel 11 upgrade, but there's there's other stuff on at the moment. So nothing nothing at this stage. Probably the Laracon website, when that's ready, I'll I'll pop that to Laravel 11, but other than that, not really.
• 30:46
  Yeah. You've I mean, you've got a plethora of apps. I'm sure you've you've moved some
• 30:49
  Jake: of those apps. We have a bunch We have a bunch of apps. And so we've we I think we've got 4 of our apps upgraded to Laravel 11 now, and I thought it would be helpful maybe just to talk about some of the gotchas that we've found, in upgrading that you might want to be aware of. And so my goal really is to have every one of our applications feel like it started on Laravel 11. Right?
• 31:16
  And and JMac has, like, this Laravel fixer that will go through after the fact and say, this looks like it's not exactly set up like the most recent version is, and so you might wanna consider updating this. We're not running that on these applications. We're just doing the shift. But that's my hope is that, like, I want somebody who's coming into this to be able to look at the documentation for Laravel 11, look at our application, and be like, yeah, everything should be in the right spot. Like, I'm looking to find it where I would expect it to be based on the documentation, right?
• 31:47
  And so, we've probably heard of the fact that the configs are drastically slimmed down. And so the only thing that the shift if you're using Laravel shift, which I'm assuming at this point you're using Laravel shift, you'd be ill advised not to, I guess, is what I would say. Shift does a ton of work on the back end, and I will say I agree with J Mac that this is the most comprehensive shift he's ever written. It was wild how much of the stuff it picked up and how good of a job it did diffing our configs and keeping the stuff that needed to be kept and ditching the stuff that needed to be deleted. It was amazing.
• 32:25
  And so I will say that by default, the Laravel shift when it runs will delete most of your configs, if not, I mean, all but, like, just a very few of them. And so the ones that we had sticking around, were database dot PHP sometimes, although not often, like even that it seemed like for the most part, you'd could get away with deleting it and just changing a couple small things, in your PHP unit dot XML or in your ENB that's in production. You can typically get away with just deleting that database dot PHP file altogether and just being a little more careful with your E and B values. But would highly suggest that if you're shifting, try and get rid of all of the configs that is possible for you to do. If you think of it like a golf challenge, right, code golf, where like you try and get something done in the most the fewest amount of lines, That's what, how I'm approaching it.
• 33:15
  Like, I want to get rid of every config that's possible. So when I did the shift, it's like, oh, the time zone was kept Ditching that, not doing that. Like, I'll put in the env.example. I'll go update it over there. No big deal.
• 33:27
  In the database dot PHP, there is this thing that does timestamp on migrations. It says false, and it was like, if you haven't squashed your migrations, it's possible that vendor packages that publish migrations could republish with a different timestamp, and so we have to keep this in there. I'm like, nope. Squashing the migrations, getting rid of that. Database dot PHP is gone.
• 33:45
  Alright. What else? Right? And so then there's, like, you know, q or broadcasting or horizon or whatever that's in there. And so you just kind of go through and figure out what are the things that I need to change in order to make this the most default it can and get it down to the smallest number of configs possible.
• 34:00
  And when you do, it feels fricking awesome because you got like 2 configs left, and you know that the next time you have to shift something, it's going to be no big deal at all. Now, what I will say is that you need to have github.com/laravel/laravel on speed dial because you're going to be referencing those configs a lot. It's not necessarily easy to get to those default configs from within your code editor, for me necessarily, because mine are, like, in an ignore folder. My vendor, it doesn't index all my vendor folders. Right?
• 34:28
  It would take forever to do that. And so if I search for, you know, logging dot PHP, for example, it doesn't pull up cause it's not in my project anymore. Or if I do have a logging dot PHP, it's only got one option left in it, and I want to compare it to the default options and see what's in there. So you need to really have that repo ready and available to go look at and reference so that you can make the changes to pull it back into line with the default so you can get rid of it. So that's one thing I found really helpful.
• 34:56
  Michael: Tinker well. Tinker well and config, like, config logging, and it will spit everything out.
• 35:01
  Jake: Great idea.
• 35:02
  Michael: I think I think that is, like, the downside of of the change to having the the slimmer configurations is that the configurations themselves are less discoverable.
• 35:14
  Jake: Yeah. It's for sure it is.
• 35:16
  Michael: And, like, there there are there were always bits and pieces in there, s three configuration, the ability to pass things into database config and things like that, where they just weren't obvious, unless you weren't source diving.
• 35:29
  Michael: So I
• 35:29
  Michael: think I think that is probably a bit of a knock on it. I I get it from the perspective of, you know, it slims down the the skeleton, and there's nothing in there that doesn't have to be there for your application to run, like, everything will keep running as it did before. I don't buy necessarily that it's harder for newcomers to the framework because you you never go and look in those conflict files. You never go and change them anyway. But from from a perspective of discoverability, I think it is a bit trickier Yes.
• 35:58
  Than than what it was. I see. It is. Like, you can't just open the file and, yeah, as you say, see what was there and and and figure out what you need change. So, yeah, there's there's a balance.
• 36:08
  I think I think on the whole, what we have now is good. It's just discoverability is is a bit more lacking as a result.
• 36:16
  Jake: It's true. It's true. And it's sort of like a trade off. Right? It's like what do you what's more important to you?
• 36:21
  Is the discoverability of the configuration options more more important, or is the upgradeability of the application more important?
• 36:28
  Michael: And and for how often you're going to change them, like, it's not that big a deal to go and look at the vendor file to figure out, like, what's in there and what you need to say.
• 36:37
  Jake: Typically, the only time you're going to go change them is if you're reading the documentation and it tells you to do so, right? Like if it tells you, oh, if you want this option, go change it here. But most of those are also going to be available to be changed through e and v values. You know what I'm saying? Like, it's just not all that often that you need to change something in a config value that's not also being set by an e and v value.
• 37:00
  Like
• 37:01
  Michael: And there's there's an argument argument to be made about, like, the E and V should, in, like, very aggressive air quotes, only be for things that change from environment to environment.
• 37:13
  Jake: Yes. I
• 37:14
  Michael: Keys, secrets, URLs, like, things like that. So making the entire application environment configurable doesn't make sense from that point of view, but, again, I don't think it's that big a deal. You know? It's using the the dotenv file is a misappropriation of that functionality anyway. Now broadly speaking, you're not quote, unquote, supposed to put things into a dotenv file in production.
• 37:41
  You're supposed to inject environment variables, but the practical the practicality of doing so doesn't make sense. You know, to figure out how to put those things into NGINX so that NGINX injects the the environment variables or putting them into a Docker container or however you're shipping things to production. Like, that just doesn't make sense. And the argument that, you know, if someone gets your dotenv file, it's insecure. Like, everything gets cached down into a flat PHP file anyway in production, typically.
• 38:09
  You've got your, you you know, artisan optimizer or config cache. All of those things, whether in the dotenv file or they're in the comp compiled, you know, bootstrap cache, config dot PHP, they're still in a file. And if you can get to dotenv, you can get to bootstrap cache config. So I think the the security implications of that are not really a concern either, practically speaking.
• 38:32
  Jake: Yeah. I will say one thing that bit me is that when you upgrade to Laravel 11, the default DB connection is now set to SQLite. So heads up on that, because that is something that I didn't necessarily have set in the db, sorry, in the enb because I didn't have to, like the enb was always just set to my SQL by default, so I didn't set the db connection. And so in production, when I was going to deploy these level 11 apps, it'd be like migrating SQLite. And then I was like, what the heck?
• 38:57
  What are you doing? And I was like, I don't wanna use SQLite. And so I had to make sure that I put DB connection in each of those. So that that's so that's one big heads up too. Like, if you're if you don't have DB connection specified, you're gonna have to specify that in your ENB, or you're going to have to in your database dot PHP config, you're gonna have to spell it out that it's supposed to be MySQL by default.
• 39:16
  Michael: I think if you, Laravel, knew an application, it will ask you what database connection
• 39:21
  Jake: you're gonna use. It will. Yeah.
• 39:22
  Michael: It will default to SQLite, but you can specify my SQL. And, like, I will continue to use my SQL just because it's the only real concern in terms of, like, doing something in in, local development that could potentially be different in production. There are some peculiarities around the way that
• 39:44
  Michael: There are.
• 39:45
  Michael: SQLite works that are different enough to MySQL that you don't wanna be catching them in production.
• 39:51
  Jake: Correct.
• 39:52
  Michael: At at the very least, if you're gonna use SQLite locally, you should be using, MySQL in CI, GitHub Actions, or whatever you're using
• 40:02
  Jake: Yep.
• 40:02
  Michael: If you're also using MySQL in production. Like, at the very least, catch those things before you get them into prod.
• 40:09
  Jake: It is true. Yeah.
• 40:12
  Michael: I I think the general sentiment is use SQLite as long as you can use SQLite. And until you need some SQL specific, whether it's Postgres or MySQL specific functionality, the the Laravel grammar that kind of maps all of the different database engines, connection types is pretty robust at this point where you're not gonna run into too many issues unless you're using features specific to a database connection type.
• 40:39
  Jake: Yeah. I will say that we actually had to switch over to MySQL for some of our testing stuff and realized that there was a bunch of tests failing using MySQL that were not failing when we're using SQLite. And that was a bit of a scary moment. It was like, woah. Woah.
• 40:50
  Woah. Woah. Woah. What in the world? Like, have we just been having false passing tests?
• 40:54
  And we were. I mean, that is exactly what was happening. Now they were actually working, but the tests themselves were, like, not checking correctly the stuff that they were supposed to check just because it was just running SQLite instead of MySQL.
• 41:05
  Michael: So Yeah.
• 41:06
  Jake: I I agree with that. I think if you're using it is. It is very much. So, anyway, heads up on that. The other thing then that's so the config is definitely much different.
• 41:17
  The other thing that's different then is that a lot of the service providers, I feel like you're encouraged to get rid of them as much as possible. There is not I think there's 3 service providers in Laravel slash Laravel. There's the app service provider. No. There's one.
• 41:32
  There's the app service provider. That's it. In the default, there is one service provider. That is all. And in the app service provider, you're just kinda doing a couple things, not a whole lot.
• 41:44
  And then most of the things that you're doing in in, in all of your other service providers previously, like your event service provider, you're now encouraged to do in your app service provider. So it's sort of like saying, yeah, I know you had an event service provider before, and maybe that registered some listeners and some subscribers and all that stuff. No. Just do that in your apps. Just do that in your app service provider.
• 42:04
  You know, don't don't necessarily name it. I mean, give it a private method if you want to. That's fine. Sure. But just do it in your app service provider, and so you have one place to look for all the different things that are getting done, and that's fine.
• 42:15
  It is a shift. I will say it is a shift in thinking, but it's not too bad. It's not too bad. And the other thing about it is Laravel has embraced this idea of auto discovery for a while now with listeners and things like that. Previously in your event service provider, you would manually register or manually do those, or like, you know, it used to be like in the, console kernel, you used to register your commands.
• 42:42
  It just auto discovery. Right? So most of the things that you used to have to register through the service providers are just done automatically for you. As long as they're in the default location, they get registered, no big deal. So embrace that embrace that, like, new process and that new methodology, and just try and get down to the service providers that you have to have.
• 43:04
  Try and get some of those things out of that event service provider. Use you know, utilize the auto registration stuff and get down to just the app service provider. Not only that, but, you know, make that a a task that you attempt at least attempt to embrace. Right? Try to do that thing.
• 43:22
  Michael: Yeah. Yeah. We the thing
• 43:23
  Jake: go ahead.
• 43:24
  Michael: We I think, typically, the only thing that we really like, we do some auth stuff in, like, the auth service provider, and we have some macros. Like, we have a stringable service provider, and we have something else that we macro, like the collection service provider, I think, and we put the macros that we are reusing into those just because it makes it easier to go, okay. Where are these macros coming from? And, like, we can go to the collection service provider, or we can go to the stringable service provider, and we know that the macro like, we've got one that that takes a a string input and then does some transformation for when we're presenting it, we can do string of, you know, dollar model arrow mobile number arrow to mobile number, and it will give us a thing that is presented as we would expect to see a mobile number. So those kinds of things, we we tuck into specific providers.
• 44:24
  But other than that, like, other than situations where you're you're doing container bindings, you know, these things are typically for packages, really, the the providers that they can they can bind things to the container and they can do some kind of setup in that way. I don't Or it's just
• 44:44
  Jake: a couple lines. I mean, like, some of these things, it's just not that there's not a whole lot.
• 44:48
  Michael: Yeah. You're not creating a whole new provider for for one thing. And, like, start in the app service provider, and if you need to extract because you've got, you know, 2 or 3 similar things, could it as you say into a private method. And if it if