urgent php #1: generics, mago, the pipe operator, the action pattern, and brent prefers pest

What's up, beautiful PHP people? Welcome to the very first episode of Urgent Podcast. A new podcast that was started this morning without brand permission. Are you okay with that, Brent? [laughter] I'm fine. I'm fine. I do wonder what is so urgent about this. Well, there is no urgency, but we are going to discuss the urgent topics of PHP. So, we love PHP. You love PHP too. So, you know, I thought we would make this official like making this like a real name and real podcast. We are going to have this on audio and yeah let's just jump straight into the hot topics of today. Okay so Brandt PHP is about having generics okay or not we don't know yet or not or not or not. Can you just summarize a little bit what is the current state of generics in PHP 8.6? We've got dog block generics right so so we they are very helpful so many people are using them. uh static analysis tools are out there. They integrate with the doc blocks and life as well. They are a very useful tool for static analysis and we just want better syntax and that's what all of this is about and yeah the discussion on externals for well 10 years now is you know PHP is an interpreted language. It it does everything on the fly at runtime. There's no compilation step and that's fine. That's that's the power of PHP. But generics are not really a a runtime tool. They are a very useful tool for static analysis for when you're writing the code, not when you're running the code. We want proper syntax, but many people think that if there is syntax in PHP regarding the type system, it also be should be checked at runtime, which for generics is just a crazy thing to do. Just it's so much performance overhead, it doesn't work. So yeah, that's that's the state. There is a new RFC and we'll see. We'll see. It's, you know, I'm I'm I'm going to tell you if this doesn't succeed, we're not getting generics. This is the the I don't think so. This is the best. This is what we need. This is the RFC. This is the best generic. This is the best RFC ever. The RFC adds syntax for generics and then says we don't do anything with the syntax at runtime except for reflection, which is very very useful. Um, but we don't do any type checking on generic types. just hand that off to very very good and and very uh decent static analysis tools that already exist. Now my opinion about generics. So as you said the current state of generics in PHP is that we have no built-in feature for that and we rely on PHP annotations for generics. So we have generic uh PHP indentations that were written by [clears throat] tools like PHP stand and SOL and we have been using them like I use generics all the time but through documentation now PHP never had generics like we never had generics on PHP as a built-in feature and now we are having this well we have been seeing a lot of RFC's to add generics and I think all of them failed because there is some serious concerns about generics like what happens with existing projects uh how is the adoption of generics across Ross across the ecosystem and I honestly think this RFC we are seeing right now is probably the best proposal yet regarding generics just because they are type erased. Now what what means being type erase generics and for those who are not familiar with the topic type generics means that PHP stands would be able to see those generics on the code itself and we as a human beings we would be seeing generics as well just like Typescript. However, at runtime, if the generics are wrong, PHP won't fail the compilation. Okay. Now, this adoption is not something unheard of like Python have implemented generics this way. Are you familiar with any other language having implemented generics this way? I think uh there was one. Yeah, I was familiar and now uh I forgot [laughter] but I think there's another Python is the biggest example. Oh yeah, Python is the biggest biggest example and I'm actually super fan of this idea of type is generics because Laravel for example and even Symfony their biggest biggest frameworks out there they would be able to add generics to their current interfaces and it wouldn't break anything and I think this is just fantastic as an idea meaning that it would feel like generics for everyone else you know but it wouldn't break existing code imagine things like WordPress uh Drupal Laravel Symphfony everyone implementing generics, but it wouldn't break the PHP ecosystem. You know what I mean? So, WRFC, man, I love this one. What what people need to understand about generics, Nuno, is that if if you're not used to using a type system and you're not used to using a static analyzer and it includes an IDE, you're you don't really realize how much power you're missing out on because correct um we we can infer so much information just by looking at the types system. This is this is actually like a field in mathematics uh where it's called category theory where um we can just look at code and based on the type definitions we can um we like get more information about what that code is doing without running that code. Right. Um so generics add like a whole layer on top of that like a whole layer of flexibility that well many PHP developers uh that many PHP developers are actually already used to because we're using generics in production projects in frameworks the biggest frameworks likely like Symfony they are using generics the syntax just sucks a lot an additional problem by the way with generics these days is that there are a couple of static analyzers PHP stand Um uh fan is another one although it's a lot lot smaller. Mago is now on the rise a little bit and then there's PHP Storm as well who it's also a static analyzer but at runtime and and close source but um there are these different tools and they all kind of do their own thing. 95% of the syntax is consistent but then the the 5% of edge cases they have their their own little tags and their own little ways of working with things. These small differences are just because there is no official specification. No one is saying this is what generics in PHP looks like. I think like we just discussed about generics in PHP. And I think like Brent, correct me if I'm wrong, but our general opinion is that the RFC looks fantastic. This is the best [clears throat] RFC ever to add generics to PHP. And if this one doesn't work, we probably will never get generics in the PHP history. Basically if I mean if this doesn't work then I don't think anything will this is what we need. This is the only viable approach that will work for PHP in a performant way and yeah um agree Brent you mentioned Mago I want to know like I'm using PHP stand I use PHP stand level max on packages I use PHP stand level six seven on web applications I've tried Mago Brent I've tried Mago and a lot of people speak about Mago as being something like fantastic coming to the PHP industry I have tried Mago and a lot of our project and I must say it was just a lot of false positives basically um just because we don't have an extension So how is MAGO working for you though? Very well. Very well. So MAGO is a it's a it's a llinter, a formatter and a static analyzer all in one for PHP written in Rust. So that are a lot of words, but it's um it's really fast. It's still a work in progress, right? It's just a couple weeks or months ago there was the first version of Mago that like the first major version tagged released. It's really nice. Um, but yeah, I mean for Laravel, Laravel is doing a lot of weird things internally, which is good. It's just part of the framework. No. Yeah, you do. You you can't make that face. The creator of Tempest PHP say that Laravel is making a lot of weird [ __ ] Laravel is doing a lot of magic underneath the underneath it. Yeah. So, and and that's good. It's it's what makes Laravel Laravel. That's totally fine. But um yeah like Laravel has always had like a little bit of issue with static analysis out of the box for all you need to understand but yeah it comes with also historical reasons right like uh um historically the concept of type safety wouldn't even didn't exist even on PHP when laval was first conceived basically. Yeah. uh but also like you know some of the Laravel magic it's actually it's just not understandable in terms of type safety you know the type safety first introduced in PHP with PHP stand and sol and everything was very basic type safety uh meaning that they would assume that you know um they would just didn't support any kind of magic but now Laravel is better with with PHP stand and thanks to LA stand of course um see that's what I mean you need you need something like Laran in between as an extension for PHP stand to make sure that everything works so if that would come for for Mago then Laravel support would be great and I'm sure you would love uh to use MAGO over PHP stone. It's actually I find it a lot better. Yeah, I've been hear I've been hearing that from people saying that Mago is indeed a much much better addition to the PHP ecosystem. I cannot wait until to be like fully ready and to have it like at full speed. I just want to add that people may think like Label is a lot of magic. Tools like React or Vue, they're equally a lot of magic and Typescript by its nature does not support Vue or React. They need plugins as well. So, it's not that different from that. We have a question from the chat for you by the way. We have a question from the chat. Okay. So, El Milson is saying the following. What is the one thing Tempest PHP does that made you build it instead of using Laravel? That's a good question. Well, speaking about magic, uh I guess that would be the biggest thing. Just just I I uh I was so looking forward to to using something that was straightforward and just didn't rely on the thing. And I I want to make something clear. There is nothing wrong with Laravel relying on so much magic. I'm not saying that as a bad thing, right? That's just that's that's the way the framework evolved. and and it's clear that so many people like it because see how successful the framework is. The thing is me coming from a like and preferring a more static analysis kind of workflow where I want my code to be properly type checked to be more strict. I starting from scratch what I did with Tempest and and then just building on top of the the like maybe a bit more modern PHP with all the the the recent type uh system changes and stuff like that. Um it just it feels more natural to me but it's it's not making any judgment on Laravel for that. I know I know and I also think like building your own framework is always a good experience regardless of the outcome. The outcome for Tempest it looks like it's been successful but uh regardless of the outcome it's always a good idea to build your own framework. Also to understand like how big and how much useful things like symfony and laval are. If you use native PHP is just a [ __ ] nightmare. brand. I want to jump into the pipe operator. I want you to be honest with me. I want you to be honest with me. Okay, be honest. What do you think about the pipe operator? Oh, I want to like it. I really do. And I think I will like it more when PHP 8.6 comes with partial function application where it's just easier to use it. But honestly, and I'm using it. I'm using it in and I actually try my best to use it. And when I in PHP storm, there's this inspection that tells me, hey, you're chaining three or more functions. Maybe you want to refactor to the pipe operator. So, and then and then I do that and it looks nice in in theory, but then when you look at the weird syntax that you need to use with the short closures, with the brackets around the short closures, it just it's it's in practice doesn't really gain anything to be honest. Um, and that's what I say when with partial function application, which is a feature that will make the like the syntax you need for the pipe operator a lot a lot more cleaner. It will be better. So, let's ask that question next year and and then see how I think about it. But for for now, you see, dude, you just said something like it really resonates with me, which is I really want to like it. Honestly, I love Larry. I actually love the creator of that RFC. I love the idea behind it. But when I compare like the old syntax in the new one, like no way I like the new one. The old syntax just looks much easy to understand. You know what I mean? And you know hopefully with partial function application things are going to improve a little bit on the pipe operator. Although I I I just think like if you need another RFC to make the pipe operator make sense like I just think like there is so much more things that are important for the PHP you know talking for example about multi-line short closures. you know. Mhm. Multi-line short closures are like three four lines of code to the PHP itself in terms of PHP source code. I mean and for every single one of us will be so useful like we all want multi-line short closures. I I literally did a video to the PHP internals like as a message. This is what people want. People want generics. People want multi-line short closures and DD on the core. This is what people want. They stop navigating through pipes operators and partial function whatever. People literally want this. This is what all all people want in a beautiful website if I'm honest. So yeah, I don't I [laughter] don't I I don't know man. I've been thinking a little bit about this and um I also proposed to the PHP internals to move to GitHub. There's a lot of things we need to talk about here, but uh so a couple of things couple of things. Uh first of all, I think you just said that you agree a little bit with me that the pipe operator is kind of, you know, not um not a great, you know, maybe something up to discussion a little bit more or should have been held to a discussion a little bit more. Uh what do you thought about multilenture closures though? like when I first proposed it like three years ago. Yeah, it's already been three years, Nuno. We just need it. I mean, I don't understand how it is a discussion. Did you see that there's a new RFC uh called scope functions that kind of introduce uh multi-line short closures but with more limitations? Did you see that? Oh, it's it's not it's not voted on. No, the the thing with scope functions is that they they look like multi-line short closures on like on first look, but when you then look at how they handle scope and stuff like that, it's not exactly the same. It's it's actually it's not a closure. It doesn't close over its uh over its scope. So, it's it's it's cool, but um probably will also lack a little bit. Are you super familiar with RFC? Yeah, I read through it uh last week. So if I have a collection and that collection relies on outside scope, can I just reference a variable like normal inside without having to do the use thing? Yes. Is a syntax as clean as my RFC? Yes, it's exactly the same actually. Yeah. So the the only thing that differs, Nuno, is when you if you return such a short closure, which it's not a closure. If you return that from a function and then try to call it, that doesn't work because the the uh the short closure you created, the scope function doesn't have access to the inner scope of that outer of that function it was declared in anymore. It's a bit it's a bit difficult to explain without visuals, but um so it's more limited, but actually for it works pro. Yeah, for both use cases it will just work. So it's really great. Moving forward, uh we talked about multi-line short closures. We talked about uh mango generics, pipe operator. I want to focus a little bit of discussion now on PHP security issues and composer security issues actually. So uh we have seen a lot of security issues on the various ecosystems out there JavaScript uh Python as well now and PHP. They are coming for PHP hardcore man. Okay, they are coming for PHP. This is a serious thing and I think like I don't think people realize how serious this topic is right now. Just the fact that you can do a composer update and suddenly your AWS secrets, your SSH key, your crypto wallet, like all the stuff you have as important in your laptop can literally go elsewhere across the world and be used against you. Like for me, this is one of this should be like top number one's priority PHP foundation wise laval symfony. We should just literally focusing everything we have on this stuff right now. And we are at Laravel by the way. At Lavel we take this very seriously and we have made a lot of improvements in the past couple weeks in light in all of this. But um you know composer is about to did you see the article of composer 2.10 which feature did you did you thought that was most useful in this area? And I think the minimum age release thingy. Um, it's something that's that's used in npm as well where you can configure that you only want to pull in package updates when they have a certain age. Uh, and so not pull everything in as soon as it's released, but maybe wait a day or a week or might even uh just to be sure that someone else has run into issues if there are any. Um, that that is a very good feature and so I'm I'm happy that's that's uh available now. 2.10 was released uh last week I I think. So um you just have to run composer self update. So and another thought I have uh Nuno is that the foundation now I don't know if you saw this but uh they got a grant from the Linux foundation to the PHP foundation to actually spend the next 6 months on security as well. And so they have yeah they have a dedicated person now at the foundation who's going to um yeah just work around security both in PHP and open source uh for PHP. So it's it's it's really good. It's really necessary. Things are changing so quickly and yeah it's it's uh a clear consequence of how AI models are helping people discovering security issues and some of those people are very good and other people are have rather bad intentions. So right um that that's true that's true. I also feel like this just shows how weak our open source system was a little bit, you know, like just the fact that some random dude across the world can tag a new release um with malware and every suddenly everyone just pulls that thing in is it is scary and I'm happy that uh composer PHP foundation and you know we internally at Laravel Symphfony as well we are doing some stuff to make sure we are safe and all of us can be safe and maybe I will share some of this stuff I have been working on with Laravel in the future but I've you know with Lavel mode which is something I've just released and other stuff I have done there is a lot of security improvements we have done like literally and uh maybe I will do an article about that topic but uh have you tried Moch by the way or not yet? No, not yet. That's the is it that the rust tool thingy? Yeah. So I've written a tool on rust which what it does it just pulls all of these different data from your GitHub account and will tell you what you need to enable to make your GitHub account more secure. It's actually a very interesting tool like if you are not using it just use it because it's very interesting. What it does is the following like when we look at attacks like you saw the tenstack got hacked for example. Yeah. When you look at tenstack the problem with ten stack is that they have a lot of safeguards disabled like a lot of them. That's why they got hacked typically like to get hacked you need to have a lot of little they exploit various things at the same time. You know what I mean? So what my tool does is that it it makes you enable a lot of different security things on GitHub. So if one of them is disabled, the hacker cannot go around because there is one more safeguard in place. Even if that one is disabled, there is another one in place which prevents things from from escalating a little bit. So it just basically secures our entire organization. So if you have one one thing suggestible to exploitation, the hacker can still do anything. And this is what I have learned through this journey of developing Laravel mode is that a lot of this stuff that we are talking about is called defensive on depth. Like if you implement safe safeguards over safeguards things are going to just be safe by nature because the hacker needs to exploit a lot of stuff. You know what I mean? U still on this topic um so composer as you said implemented security measures. One of them being the the release cool down let's call it that way which is you go there and you say I just want to pull something got released more than 10 days ago in that way at least every time you pull something new we'll have to be on the market already for 10 days so that's one thing uh composer also did another thing which is very crucial in my opinion which is they've they've implemented aido internally so when a package let's say nuno releases numador collision Collision will be subject to a deep examination from Aikido which is a company who detects virus and malware on packages and if collision tag was tacked with malware composer will immediately untag the release like bam gone. So this combined with the 10 days thing of cooldown people will never get malware in their systems. So well never say never Nuno never say never right but yeah and another good thing I like about the composer changes as well is that they will show like who uh which package authors have proper two-factor authentication enabled for example that there's GitHub stuff is more secure than the default setup which I think is a a good thing you you might want to look out for in the future when you're deciding whether you want to use a package or not. I just want to add one more little thing here. I I will be with Niels the co-creator of pack composer and packages next week and u we I'm going to interview it for the channel. So if you don't want to miss it out subscribe the channel but um I I want to go with them through all of these things they are implementing to discuss with them but also like to propose my solution. My solution to all this problem is not distribute packages if they are not being confirmed through multiffactor notification. This is what I think will be the nuclear solution but it will actually work across the entire ecosystem. So package developers in my opinion every time they tag they tag a release on GitHub they should receive an email saying did you actually want to distribute this over packages and they say yes and packages will say perfect now give me the two factor notification from your mobile device like if we have this in place people would have to act not only your laptop but you have to hack as well your device which is very difficult in my opinion so anyways um very happy about everything we're doing on the PHP ecosystem regarding regarding security by the way. Yeah. I mean some things went wrong but it's clear that in a very short amount of time they are now also doing a lot of things right and and trying to fix it and taking a lot lot of good steps I would say. Moving a little bit to the action pattern uh brand I I want to discuss the action pattern with you a little bit. So I recently released a video showing how the action pattern can be useful but I have many questions. By the way in the past you mentioned that you invented this pattern. I want to ask you why. Because I was solving a real life problem. You know, I was I was building a uh um kind of a CRM invoicing system for an an hotel chain in Belgium here where I live. And um [snorts] we we just we were sitting down with a client and they were sharing all these use cases, right? And they actually they they wrote like a PDF of of I think 200 pages of like what the the the application should do. And Wow. Yeah. Yeah. Yeah. There were there were these like all these things that should happen, right? Business logic basically. And we were wondering where are we going to put this because it was very clearly written in their PDF document. And this is the these were the things that the client cared about, right? They didn't care about whether we stored things in models or whether we used controllers to to do like make the app accessible via HTTP endpoints. Like they don't care about all of those technical things. They cared about solving their business problems and and so we wanted to to model that as like first class citizens within our application so that we could uh clearly have an overview of all the things that the the app could do. basically uh test those things in isolation as well. And and at the time I was reading about functional programming a lot and I just really like the idea of um having a function uh which could be considered a small program on its own where it gets some input, it does something with that input and it returns some output or maybe some side effects like storing stuff in a database or I don't know. Um, and I really just liked that mindset, that simplicity of a function. So I translated that to to PHP with invocable classes at the time. Um, which were kind of like functions, but then you also had like the class its constructor and its internal state which normal functions don't have. And and that was pretty useful because now I could compose actions from other actions and inject stuff into them, which is the dependency injection pattern. uh which made testing super easy and composing actions together ma became a lot easier and then it just all clicked together and then I I wrote this small book Laravel beyond crud where actions were were a pretty uh pretty big topic there and and I don't know it it it kind of people seem to like the approach and now people all over the place are talking about it uh which I think is a good thing it's it's such a simple thing to do I didn't invent it by the way because it's just it's just an invocable class or a class with an exec cute matter or whatever whatever you want to call it. Doesn't really have to be an invocable class, but just something that does something in your application. It takes some input, generates some output. It can be kind of tested in isolation. It can be uh used wherever you need to in your controllers, but also your console commands. And I uh yeah, I really like that action pattern. You just said I think like you said, you didn't invented it. Although I must say like you prove that it worked. I think you know I think like when we when you first start talking about it and I did as well around that time. I think like there was this concept of the action pattern written on books and even Taylor was starting to say like oh you know this is actually a very good thing but like being actually proven on paper like on real applications. I think you spy at the time like all this Laravel OGs almost I was also starting to implementing it on real projects we actually said something like oh this is like a real concept we have done it we have used it on real projects and it's actually mind-blowing I have used the action pattern on real projects laval cloud for example is fully on the action pattern by the way completely on the action pattern all the way through like everything you do on Laravel cloud every time you click on a button that goes through the action pattern through chain of actions as well. Everything is tested on the action pattern and it's rock solid. Like I actually love it. I think like if I were to build an application tomorrow would be on the action pattern. On the other hand, other patterns for web apps like events for example, they look very good on books but I'm going to tell you I have done applications using the action the the events events and you know just doing event oriented and it's a [ __ ] nightmare. Like it's truly a nightmare um to maintain overtime just because what what end ups happening with events in general is you are doing this behavior and then suddenly you have this side effect which you didn't know even existed now sending an email to uh to a person that you didn't even expect it to. In the other hand, something like actions is just explicit. Like you go there, you want to you want to have a booking system, you go to the create booking and you see exactly what it does. I like that so much. Yeah, exactly. It's right there. It's there's no side effects. It's just right there. Yeah. And we had like hundreds of actions uh in in those applications, but it was just so um you could just see at a glance what the thing was doing and and so yeah, I'm totally with you there. So that was the action pattern. I want to move to a last topic here uh which is talking a little bit about Tempest PHP. You mentioned obviously like in it's just a little bit more simple than Laravel uh for you and you like it more. Um I want to ask you like in terms of tooling in Tempest PHP. Um what are you using right now? you you recently changed to Mago, but are you fully on Mago even for linking and uh well uh the Tempest framework itself not yet but like all the new packages that we're making like the the site packages are just fully on Mago and it works. How about for new users like if I start a new project on Mago what do I get on Mago on Tempest what do I get? Uh, MAGO. Interesting. So, a new Tempest PHP user gets MAGO for linking, formatting, test, uh, not testing, but um, I mean, you're you're free to do to use anything you want, of course, but with the in the default application scaffold, there's there's MAGO and PHP unit as test, I assume. Yes, PHPUnit. actually like I the best thing where we it's it's still a to-do to to um maybe switch to pest uh in the future. I don't have a strong opinion about it, Nuno. Um I like I understand both sides. Uh I know you're on the pest side of course but um but yeah it's um but we we do have uh some people who are using tempest together with pest and they made a couple of changes and sent some pull requests to make sure that it worked with more compatible basically right yeah and it works as far as I understand I don't use it myself but people who do they they say that it works there was like one or two bugs in the framework that we had to fix to make sure that they passed you you know past php like I I honestly think like is very likely to be the the most complete testing framework in the world. Not it's across PHP you know like even across JavaScript across Python like nothing comes even close to pass PHP at the minute mutation testing parallel testing browser testing have you tried browser testing on past no but I have a question about that the browser testing stuff but is is that like Laravel specific or or framework agnostic so at the so it's framework agnostic but if you want to share the server this is the interesting thing about browser testing on past which is you probably have built-in testing on p tempest php don't Don't you like would you do you have assertions on tempest PHP that you can do assertions? Yes. Yeah. Yeah. Okay. So with browser testing on past you can use imagine glal you can do user factory and then acting us and then do visit and that thing will happen with a user that you just created and you will be already logged in because you have done acting us and then you can do your browser testing like actually with a chrome browser and just click on buttons and then you can go all the way down and have things like assert email got sent assert database hash. So all this stuff is is possible because the server running the test is the same server serving HTTP requests. I'm using event looping and there's a bunch of science here. But uh it's mind-blowing like honestly you try it once and you will be like what the [ __ ] like this is so much better than versus what I've been doing in the past things like you know playright or whatever browser testing have you used it is just mind-blowing. And you can combine this with parallel testing too which is just insane honestly. So this is my past four this is like out there already but what I am bringing for past five which I cannot tell you there is a past five coming yes in Lakon US it will be mind-blowing like at all levels this will be the most advanced thing ever seen across ever testing in the [ __ ] century you know what I mean you will see like uh it's insane okay has [snorts] can can I ask has it something to do with AI no of course not like all the all the all all the success of past PHP have been because I don't focus on hype like browser testing. Everyone was talking about AI and [ __ ] When when I show browser testing, people were like, "Wo, you know, and this stuff I'm showing right now will have like the vanilla feeling of lot of announcements, but it will be not AI, you know, not hype. It's really something you will start using tomorrow at 9:00 a.m. It will be fantastic. So, very happy excited about this topic. By the way, this is the first episode of Urgent PHP, a podcast that I'm starting with Brent, uh, one of my favorite peoples ever. We are doing PHP verse. Do you want to share a little bit about PHP verse B? Go ahead. Dude, no, no. It's only a couple days away. It's uh on on Tuesday, we're going to host uh an online conference on YouTube on my channel PHP annotated. Uh we'll have speakers from all of the PHP community. Um we have uh of course Fabiana from from Symphony. Uh Jeffrey and Ashley from more the Laravel side are coming. um uh that uh from WordPress, from Drupal. Uh we're truly bringing ev everything together and we want to host a conference to show how great and amazing and diverse the PHP community is. Uh so yeah, we're going to live stream it on PHP annotated on YouTube if if YouTube works. Let's hope it does. Uh otherwise, we will have like serious problems. Um and yeah, everyone can just can just join. We're giving away Hang on. Hang on. Hang on. Oh boy. Oh boy. Oh boy. So, uh, we we we made these Lego elephants and we're going to give away some during PHP verse. So, if if you want one of these, uh, come come join the live stream. And uh there will be like all the talks will be super amazing, super accessible for everyone, not just for like the the small sub communities. We really asked our speakers to try to engage with the PHP community as a whole and and so I'm super looking forward to it. It's going to be great. It's going to be great. PHP verse happening next week. Be sure you go to PHP verse website. Just Google it. We'll be the first one appearing on the thing. Uh Shad, um it was awesome to be here with you all today. This is the first episode of urgent PHP. This will be uh diffused across all the audio platforms once I figured out which audio platforms it is even for podcast which I don't know yet but I will figure it out. Um that was it for us today. Sh also write in the comments below what do you think about this format if you like it if you like this kind of advanced topics. I'm going to be honest I love to discuss with brand only advanced stuff. So if you think this is something you guys like go all the way down uh add the comment on that topic. Click on the like button. Love you all. And catch you guys next time. Peace out. Bye-bye.