Latest / The Laravel Podcast / Laravel 11, Reverb, Herd Windows/Pro, & Other Laracon EU Recap

Transcript

Laravel 11, Reverb, Herd Windows/Pro, & Other Laracon EU Recap · The Laravel Podcast

• Matt Stauffer: All right, everybody, welcome back to Laravel podcast season six. This is episode 10, where we're going to talk about lots of stuff, but one of the primary things is Laracon EU just happened. And we've been talking so much about, these conferences. It's really exciting to actually have one that Taylor, you were at and you spoke at, but before all that, hi, I'm Matt Stauffer, one of your co-hosts and Taylor, you want to say hi to the people? Taylor Otwell: Hey everybody, Taylor Otwell. Matt Stauffer: Taylor Otwell back in the studio. Okay, so Taylor, you went to Laracon EU. It was not just back in Amsterdam, but it was at that same venue, the one that goes out over the water, right? It's B-I-M. Is it Bimhuis? Bimhuis? I don't know how you say it. Taylor Otwell: Yeah, so BIMHUIS is one of the venues in this complex, but there's a larger theater that Laracon has graduated to. So the BI MHUIS is the original Laracon EU venue from like 2013. It only holds a couple hundred people. Matt Stauffer: That's why I was so surprised I saw a picture of it, and I was like, that doesn't make sense. Taylor Otwell: We were in a different theater in that building that held, you know, like 700 people. Matt Stauffer: Okay. And if you go to LaraconEU, we'll put this in the show notes, but if you go to LaraconEU Twitter, you will see that they have a list to, or a link to a photo gallery there. First of all, their photographer did the thing, but second of all, they really, like, I mean, I say they, but I guess you, because you're kind of one of the people running it, but like, it was gorgeous. Just visually stunning conference. Like, I'm really excited to see, I'd mentioned last time about what I like about people, you know, the websites being really good, but I'm also like, the graphics were good, and the lights were good, and the shirts were good, and just really nice seeing that like the level of excellence we have in this community for conferences is pretty freaking fantastic. So for whatever role you played, good job. Whoever else is listening who had a role, good job to y'all too, because it looked great. Um, so let's talk about Laracon EU for a little bit. So I was on my honeymoon. So I, normally I ask questions here that I often know the answers to just cause it's fun to, you know, fun way to get good answers, but I don't actually know anything right now. So talk to me a little bit about what Laracon EU is like. I know it ended with you giving a Laravel 11 update. So we'll talk about that a second, but outside of that, what was it like? Any standout things you want to share with us or anything? Taylor Otwell: Oh gosh, I mean, there were so many cool people there. And it was just like the typical fun gathering of like high energy Laravel devs that are just excited to be doing Laravel stuff. All of the talks were good. I mean, I'll share a little bit about my keynote, because that's what I know most about. So I, of course, talked about Laravel 11, which we're releasing here in just about two weeks, I would say. So we're kind of putting the finishing touches on that documentation wise over the last week or two. So, you know, brief highlights of Laravel 11 are streamlined application structure where there's much fewer files out of the box in a default Laravel application. You know, there's only one service provider, the app service provider, there's actually no... No, like boilerplate middleware included out of the box until you actually create your own middleware So it really puts the focus like on your own application and not so much Laravel like sort of infrastructure and boilerplate out of the box which I think is much simpler mental model, but you know less concepts to learn out of the box. We also talked about Reverb, which was, you know, first unveiled at Laracon EU, was the first time we kind of pulled the curtains back and shown what that was. And that is a first-party WebSocket server for Laravel applications. We have had event broadcasting for a long time in Laravel. I don't even, maybe since like 2015 or 2016 or something. And basically it lets you, you know, you have events in your Laravel application that you dispatch on the back end and you can mark them with a should broadcast interface. And that will broadcast them over WebSockets to your front end using like the same event name and automatically serializing the same data out to your front end WebSockets to listen to. And that's really convenient because it lets you share all that same event terminology on your backend and frontend. So we had all of that, but we never actually had the WebSocket server piece maintained by us here at Laravel. We always recommended you use Pusher or Ably or like a third-party community maintained package like Laravel WebSockets. So we're super excited to bring this out as sort of a first-party WebSocket package finally. And the cool thing is, one, it's written in PHP, but two, it's super fast and scalable. So Reverb was primarily developed by Joe Dixon, and it's built to be horizontally scalable. And I think it's one of the first PHP WebSocket servers to actually work like this. So you can basically... run it on a single server if you want to, but if your application starts to outgrow that server, you can add multiple servers and then they all communicate with each other via Redis PubSub to distribute the messages across each other, you know, in a balanced way. So you can actually run, like we run Forge and Envoyer on a single small server. And we send millions of messages a week. So we don't actually even use this feature ourself. Because even with all the messages Forge sends, we run, I think, 2,000 or 3,000 simultaneous connections on Forge. And it's just a small 4-gigabyte server. And it's only at 10% of CPU. Matt Stauffer: See, I figured that would be not even the number of messages, but the number of concurrent threads. I figured you'd hit some sort of PHP threading thing. So I'm very, very curious to learn more about that. Taylor Otwell: Yeah, and that's all documented. So when our documentation comes out in a few weeks, it talks about how to increase sort of the file limits of not only your operating system, but nginx. Okay, and you can handle you know, you can handle 10,000 simultaneous connections on a single small server. Matt Stauffer: That's amazing. I had no idea. Okay, well that's fantastic, and I definitely remember a couple people in the community doing their own ones, and it being sort of like, I don't think they were in PHP, but if they were, they were certainly kind of like outside of the space of what we normally work in. And I've even talked to folks, including Thiery Laverdure, who's run those, and it's sort of like a... I don't know, it always felt like a stopgap, right? It was never like a, you know, this is the thing we're going to use, we're all going to maintain, and it never kind of picked up a lot of steam. So to have an officially supported one is very exciting. Do you think it's the sort of thing where, you know, because in the past with Forge, there were templates, you know, like there's the Minecraft template, the WordPress template. Is it the sort of thing where it's going to require a Horizon-style, you know, checkbox or a template or whatever? Or is it more just spin up a server, install this on it as if it were a Laravel app? You know, no big deal. Taylor Otwell: Yeah, so there's kind of like two ways to do it, and we've already built these Forge integrations which will be released, you know, around the same time that Reverb comes out. So one way is to have like your application and your Reverb server running on the same machine. So you provision one Forge box, you install your Laravel application like normal. Laravel Reverb is a dependency in your composer file of your Laravel application. Forge will detect, you know, via our new application panel that you're using Reverb and give you a little checkbox to start the Reverb server and you're pretty much like done, you know. Matt Stauffer: I love this. Taylor Otwell: The other option is to create a server that's specifically going to only be your Reverb server and your application is going to run on another machine So that's a little bit more of like a robust use case and both are handled in Forge really nicely so you could do it either way. Matt Stauffer: Is this something is it also going to be Vapor compatible? Taylor Otwell: So WebSockets on Vapor are an interesting thing. No, it's not really Vapor compatible, at least on day one. We started thinking about ways to do that. So like if you wanted to run reverb for a Vapor application, you need to put the reverb stuff on a traditional server and then have your Vapor application connect to it. But I think, you know, like with serverless, In theory, the idea is that you're supposed to embrace a serverless mentality. So probably you would want to use actually a serverless solution like Pusher or Ably, where you don't really have to manage servers. So philosophically, I feel like that would be more the direction you would want to go with Vapor. But I know, of course, a lot of people are going to want to run their own Reverb servers regardless. And who knows? Maybe we'll come out with a Reverb cloud someday. Matt Stauffer: I mean, we get so many clients always asking us, should I start with Vapor or should I start with Forge? And I'm always kind of queuing up a list of like, obviously, Vapor has some baseline really incredible future protectiveness that you're doing. But there's always some limitations. And these are the types of things where I'm like, yeah, well, if you're on Forge, you can just run Reverb, right? But you could also just run your own Reverb and Vapor. So even if it's ideologically not perfectly compatible, you can certainly do it. OK. Very good. Well, as someone completely ignorant about Reverb, is there anything else that, you know, obviously this is the TLDR version, but is there anything else exciting about reverb that you want to share or have you kind of covered the basis of it here? Taylor Otwell: No, I mean, I think that's the basics of it. I just see it as sort of filling a gap in the ecosystem where we didn't have a first party answer that felt like sort of a big missing piece where we were having to send people to third parties for a pretty kind of important part of your application story if you're using WebSocket. So I'm excited to have it kind of in the family as a first party package. Matt Stauffer: I love it. I mean, honestly, very transparently, I have been a little bit reticent to use WebSockets of any sort because of how costly a lot of the third party solutions are. So this isn't just like, oh, there's an onboard way to do it. I'm just like, oh, I feel like you just put WebSockets and, you know, PubSub and all kind of stuff onto my plate for projects that I don't think could have afforded it in the past. So I'm really excited about the world that kind of opens up having one that I can maintain myself. Especially that you can run on the same server. I didn't know that until right now. So that's fantastic. Yeah. Love this. Taylor Otwell: Yeah, totally. Matt Stauffer: Great. Okay. What else? So anything else about Laravel 11 that you shared other than what you've shared on the podcast before and what you shared here? Taylor Otwell: You know, I mean, we walked through a variety of not only the application structure stuff, but just new features in Laravel 11. So like, let me pull up some of the highlights here. Matt Stauffer: I assume we're getting into videos live at some point, right? Taylor Otwell: Yes, I know they were recorded. There is more to it than just the application structure. So like, just to give you a kind of a rundown of some of the highlights, like we introduced per second rate limiting, which was contributed by Tim McDonald. I demoed that. So previously in Laravel 10, you could actually only define rate limiters at like the per minute granularity. You couldn't define something, you know, something that could run 10 times per second. So in Laravel 11, the rate limiter goes down all the way to second level granularity. There's also a new health route in Laravel 11. Matt Stauffer: Let's talk about that. Taylor Otwell: So the bootstrap app file, which is sort of a new concept in Laravel 11. The bootstrap app file exists in Laravel 10, but it really doesn't do much. Whereas in Laravel 11, it's sort of like this single point of high level configuration for your application. So the health route, you know, in the Bootstrap app file, there's just like a health directive that points to the up route. And it just like it's automatically defined for you and you can use this for like uptime monitoring. If you're using something, some sort of container orchestration thing like Kubernetes, you can use this as your uptime health check for your application. It was inspired by the same feature in Ruby on Rails 7, which was a pretty recent release of Ruby on Rails that came out. So a pretty cool little addition to the framework. I also contributed steps towards graceful encryption key rotation. Matt Stauffer: I was just about to ask about that. Taylor Otwell: Yeah, so this is kind of a technical one. But right now, like if you have a Laravel 10 app, and people are logged into the app, and you change the app underscore key environment variable, like the master encryption key for your app, everyone will be logged out of the app because Laravel encrypts every cookie in every response that we send to the browser. So you can't really get away from encryption if you're building a Laravel app. So in Laravel 11, I introduced an app previous keys environment variable, which is just a comma delimited list of your previous encryption keys. And basically what happens is that when Laravel encrypts data, it always uses the current app key that's live. But when it decrypts data, it will try the current key first. And if that doesn't work, it will try to decrypt the data using your previous keys. So basically what that means is, imagine you rotated the key and put your old key in the previous key's environment variable, and then a request comes into your application. Laravel will fail to decrypt the cookie data using the current key, so it will try the previous key and succeed, and then when it re-encrypts on the way out, it will use the live key. So all the sessions are being gracefully migrated to the new key. And it's the same way with like encrypted database table data, you know, when it tries to decrypt it will try the current key and then all of the old keys and then if you save it back to the database, it will be saved using the current key. So it doesn't, it's like a step towards I think more features that we could introduce for encryption key rotation like we don't have this this is part of the story, but in the future I could imagine us having helpful utilities for actually migrating all of your story database data to your new encryption key in some sort of robust way. Yeah. Yeah one-off migration, you know, yeah, but this is part of the story to take us that way. What else? Laravel prompts has a new integration with our validator. So we introduced Laravel prompts at Laracon US. Jess Archer built it. And it's basically like, you know, beautiful CLI prompts for Laravel Artisan. And now you can validate all of those prompts in a really simple way using the Laravel validator. So that's new in Laravel 11. And there's a variety of other things, but you know, that's kind of the highlights. Matt Stauffer: One thing that I saw people talking about, and I wanted to hear, they said that SQLite is the default database, and I wonder if you could talk about that, because if somebody reads that phrase and doesn't know what it means, they go, wait, are we supposed to use SQLite in production for all our apps? Can you talk about that change? Taylor Otwell: Yeah, so basically what it is, is when you do Laravel new my app in Laravel 11, you'll be presented with a prompt for which database you want your app to use. And it will say like MySQL, SQLite, Postgres, or SQL Server. And in Laravel 11, the default selected database will be SQLite. And so there's a couple of different reasons for this. One of them is over time, the database drivers for things like cache and sessions and queues have gotten more and more robust, especially queues, to where you can use the database driver for queues actually in production in a robust way without any sort of locking problems. And I really wanted people to be able to start Laravel applications and use all of the features offered by Laravel without needing to install any additional software, whether that's a database like MySQL or Postgres or Redis for queuing or caching or anything like that. So in Laravel 11, when you create a new Laravel application, the migrations are run for you automatically because it's a SQLite database and we don't have to worry about if MySQL is installed or not. So your database is ready to go right after you run Laravel new. And you can start using caching, queuing, your sessions are stored in the database where it's easy to inspect them right out of the box in a pretty much production ready way. Like if you kept using the database drivers in production, that would be totally fine. Even if your production database was, you know, MySQL or Postgres or something. So it basically just gets you to the full Laravel experience out of the box with nothing else required, which was my goal across every operating system, because this kind of ties into the next, maybe the next part of our conversation. But at Laracon EU, I also introduced Herd for Windows, you know, which was built in collaboration with Beyond Code. And I wanted the story to be the same across all operating systems, where even on Windows, when you create a new application, We're using SQLite by default for local development, so you don't really have to think about installing MySQL Postgres on Windows, which may be more cumbersome than Mac, I'm honestly... I think it is. You know, I'm not totally the most up-to-date Windows person, but that's kind of the general idea behind the SQLite thing. Now, I should caveat it all. Sorry, I'm getting kind of long-winded here. Matt Stauffer: No, dude, go ahead. Taylor Otwell: I should caveat it all by like, this is only really relevant when you first run Laravel new. Because when you run Laravel new MyApp, if you just hit the arrow key up and pick MySQL, it's going to update your environment file, your config files to all be MySQL, and you never think about it again. So it's sort of like a one-time decision. And then once you make that decision, you're really not going to notice it again, you know, for the rest of your development experience. And it's the same with PEST and PHP unit, like the Laravel installer. In Laravel 11, the selected thing by default is PEST, but if you just arrow down to PHP unit and select that, all of your tests will be PHP unit. And then another cool thing is in Laravel 11, the make test artisan command, You don't have to tell it whether you're using PEST or PHP. It just knows based on what's in your application and will create the correct test format, you know, from that point forward. So it's just another one of those one time decisions you make and then you never have to think about it again because everything's automatic. Matt Stauffer: Yeah, and I really appreciate the fact that this change to SQLite by default continues the same story of the simplification of the structure of all the files. For those who don't know, SQLite can be stored in memory, or more commonly, it can be stored on the file system. So when you have a SQLite database, there's a file in your project called database.sqlite, or production.sqlite, or whatever, that is actually containing all the data, which means, like Taylor said, you don't need to spin up a new dependency stack, which means you don't need Homebrew or whatever else you're going to use, DB Engine or whatever, to spin up that thing. And so if someone were to install Hurd or Valet or whatever else, and nothing else, and then use Laravel new and use SQLite, because for the longest time, the story has been It'll all work until you try and open up your app, until you try to run your migrations, and then you have to go set up your database, right? And it's always been the second thing that you need to do on top of it. And now with this story of like, especially for a new user, and maybe a seasoned user says, look, I've already got MySQL running. I prefer MySQL. Great. Like this is not a reason to stop doing that. But for a new user, they now have a much simpler set of files. They have way less things they have to learn and they have one less dependency and one less major dependency they need before their Laravel apps are up and running. And as I've had conversations with folks, sometimes private, but often even on podcasts with JavaScript people, they're always like, Laravel's cool, but there's so many freaking files. And I'm like, yeah, well, here's what they all do and they get it. But it is really exciting for me to see the fact that you're asking these questions of like, Sure, there's all these files that they have reasons for them, but like how many of them are actually needing to be touched on your average app? And you kind of looked at those that are not often needing to be touched. And you're like, let's just move those out of the front of your vision when you start a new app. So I'm really excited about this beginner friendliness, not just because of like, cause often we say beginner, you think of like a young kid or whatever, but also beginner, like allowing other people in the industry who may have been doing this for 20 years to enter into the Laravel world and understand what's going on more easily. Regardless of what you're doing, it's easier to get started with Laravel today, with Laravel 11, right? And I see that across the whole story, and I like that. Taylor Otwell: Yeah, and that's exactly the case for some of those middleware we had in the application, where you had an entire file, like for example, the TrimStrings middleware class. Its only reason for existing is because it contained one property called Accept, where you could list the attributes that you didn't want to be trimmed. So it's like, do we really need an entire class in your application just for this one property? Like, can we just move this to a configuration method in your bootstrap file? If you even need to change it, I've never changed that in my entire life of writing Laravel applications. But if you needed to do it, couldn't we just do that somewhere else and simplify things? So yeah, I'm excited about it. Matt Stauffer: I know this is tiny, but I saw in the Laravel news write-up that you also got rid of Doctrine's dbal thing. And I know it's silly because it's just dependency, but like the number of times that I've run into that, oh, you're doing a thing that requires Doctrine d bal to be installed. I'm just like, it's minor, but I'm glad I'd never have to deal with that ever again. I don't know. So. Taylor Otwell: Yeah, that was a pretty large dependency to keep up with. And we had an open source contributor that did a lot of the work of like relieving us of that dependency and adding all of the functions we needed into Laravel to actually list indexes, list tables, list columns, all of that. Matt Stauffer: Oh, that's awesome. All right, so you did mention, or at least there was one mention at some point that the support story was impacted. We don't have LTS things anymore, right? Every single release is just exactly the same as all the other releases, right? Taylor Otwell: Right, yeah. Matt Stauffer: Two years of security fixes, 18 months of bug fixes. So that basically, at this point, we could just say, you're gonna get security fixes until two years out. Easier to understand easier predict we run something called l aravelverions.com I think it's dot com and it's literally like oh everything's a lot simpler than it used to be It's a lot easier for people to know. Okay. I think that was it for my questions. Um, let's talk about Herd. So you mentioned H erd for windows, but I also know that Herd pro came out. Can you tell us a bit more about kind of like what the I mean real quick update? What is Herd if somebody doesn't know and then also kind of what's going on with the new changes that you've all been adding into Herd? Taylor Otwell: Yeah, so Herd is a local development environment for building Laravel applications. So thus far, it's been a Mac desktop application that you download from herd.laravel.com. You install it onto your system and bundled within this application is PHP, Composer, the Laravel installer, maybe a couple other things that you need to run Laravel applications. And it doesn't use anything like Docker or homebrew under the hood. Everything is literally bundled into the Mac application that you install, which is really great because you go to the store, you buy a new laptop, you only need to install Herd to start building PHP applications with Laravel. Now, it is basically a a UI and bundled application for PHP in the spirit of Laravel Valet, where you have a folder on your computer that contains all of your sites, and when you make a new Laravel app in that folder, it's just automatically available in your browser at folder name.test. So it's super fast, super cool, super easy to use. And at Laracon EU, we introduced Herd Pro as well as Herd for Windows. So which one do you want to talk about first? Matt Stauffer: Let's start with Herd for Windows since I think it's simpler. Taylor Otwell: Yeah, okay, so Herd for Windows, you know, over the years, I mean, you know this with Laravel Valet, It felt like we had this really great development story on Mac, especially, where we had all these great tools like Valet, where they installed PHP for you. It was super easy to route to sites and all of this good stuff. And for the longest time, Windows developers, which make up, I think, the majority, actually, of Laravel developers, statistically, have always been like, what about Windows? What about Windows? Of course, I wanted to bring something great like this to Windows, but I didn't use Windows. I didn't have any really know-how about how to build any of this for Windows. And so when Marcel built Laravel Herd for Mac, I was kind of in his ear like, what about a Windows version? Because I think they have a Windows Tinkerwell, one of their other desktop applications. And so he actually got this to work. He prototyped it for a while and the rest of the team at Beyond Code. And it's basically, you know, everything about Laravel Herd for Mac just ported to Windows. So it includes PHP, it includes the Laravel Installer, it includes Composer, and it doesn't use, like, WSL or Docker or anything like that under the hood. It's true, like, Herd for Windows with all of the same features as the Mac application. You download it like a Windows executable. You install it just like any other normal Windows software. It's in your system tray. You have all of the same configuration settings where you can change which PHP versions are used for which sites and all of that good stuff. So super nice. I actually brought a Windows laptop on stage at Laracon to demo this. That's awesome. Whooped it out of my backpack. Yeah, I bought it specifically for this . Yeah, so that's Herd for Windows. And now Herd Pro is basically some power user features that are that are paid at it's a paid add on for Laravel Herd so you buy a license, and then within L aravel Herd you activate your license to unlock these pro features. And some of the things that includes are things like an email debugging graphical UI . So when you send an email from your Laravel app, Laravel Herd can intercept it and show it to you in an inbox within Laravel Herd so you can actually see the entire email, all of the headers, and actually click around on the email if it has buttons or whatever, just like a normal web inbox. It also includes a dump server, so it brings up this window within Herd where anytime you run the dump function in your Laravel app, it doesn't show up in the browser window, it's dumped out into the Herd debugging dump window. It has a built-in log viewer for all of your Laravel applications for the, like, your laravel.log file. And then another really cool feature is it has zero configuration xdebug support. So, In Herd Pro, if you have this enabled, you open up PHP Storm, and you set a breakpoint, and it just hits the breakpoint, and everything works automatically. Like, you don't have to configure any complicated Xdebug stuff, no configuration files, everything just works. So that's, I think, the last kind of, like, main feature of Laravel Herd that I can think of. So pretty cool stuff. If you need those kind of features, it's like an upgrade you can unlock. Matt Stauffer: I love it. And some people have asked me on Twitter, um, you know, how do I feel about Herd? They're like, I, you know, I still use Valet, blah, blah, blah. And I'm like, y'all, Herd, I've said this before, but let me say it again. Herd is Valet. It is the Valet code base with the pieces that interact with Homebrew replaced with pieces that interact with its own local dependencies that it has cached, wrapped in a graphical universe interface. Like, It is literally, like I talked to Marcel, it's a fork. And we even talked about bringing the fork and Valet back together. We were trying to do it. I don't know if it's gonna happen in the end, but in the end, it's Valet, right? So like, someone is not, you know, disrespecting the work of Valet or being unfaithful by moving to Herd, because Herd is Valet. It's just Valet wrapped up in a graphical user interface. And one of the cool things about it that Valet doesn't offer is that Valet has always been limited by homebrew. And the best work we've done in the last few years, and the majority of my rewrites in the last two versions of Valet, had been making the layer between the user and homebrew deeper and stronger, so that homebrew's weirdnesses affect you less negatively. But in the end, it's still homebrew. Like, I made fixes around homebrew, we made debugs around homebrew, but in the end it's still homebrew. Which means... It's slow because Homebrew's recompiling things from scratch and it still can have bugs. And it got way less bugs in the past, much faster in the past. All those things are great. One of the nice things that's really nice about Herd is that if you are using php8.1 and you want to use php8.2, it doesn't have to recompile anything, right? Like the time it takes to, in Herd, to switch from php8.1 to 8.2 is less than a second. It's freaking wild how fast it is because it's just linking two binaries. That's it. Pretty amazing. Um, I have not used He rd enough to really say if there's any shortcomings of it, you know? Uh, I know that there's been some things that still had to be kind of ironed out at the very beginning. But as, like, the maintainer of Valet, I just want to tell everybody, like, Herd is Valet. Herd is not competing against Valet. There's no, you know, whatever. And there are some benefits to using Herd that Valet doesn't have. And there might be some benefits to Valet that Herd doesn't have. I don't know. But, like, if you're interested in it, go use it. Seems kind of hot to me. That's how I feel about it. So. All right . Next step, hiring updates. How are things going with hiring for Laravel? Taylor Otwell: Yeah. So, you know, to give some context, I don't know how long ago it was, maybe a month ago or more that I tweeted, we were looking for like a VP slash director of engineering here at Laravel. Um, so yeah, I'm pumped to say that we actually got an offer accepted yesterday for that position as Director of Engineering, which will help take a lot off my plate. Um, as far as the day to day management of our development team, working on things like Forge and Vapor and allow me to focus a little bit more on overall strategic vision and product focus, as well as continue maintaining the open source framework, which is really, I'm the main person that still does that on a day-to-day basis. So we also had a few other positions accepted. We're bringing on an infrastructure engineer, a customer success manager. So I'm excited about these positions, a finance manager. It's kind of a business type position. So I'm super excited to start building up the company a bit more because we have some ambitious stuff we want to tackle this year. And we are going to be hiring just developers and engineers. We're probably going to hire a graphic designer. Put up, you know a call for resumes on these positions. I don't know if it will be out by the time this podcast release but if you're interested in that if working at Laravel sounds like something you would really enjoy then, you know throw your name in the hat once you see that because we'll definitely be bringing on a handful of new developers as well. Matt Stauffer: Sounds like a dream man. I love if I if I did not have my own company, I would be jumping all over that because I I mean, everyone knows that, right? I actually saw, I haven't seen it, but I saw that there was a talk at Laracon AU that's called Working at Laravel. I'm just like, yeah, sure. It's just talking about, you know, I guess you guys don't have soccer tables and everything, ping pong tables, but like, it just still sounds like a dream. So yeah, y'all put in your resumes, please. Okay, cool. So that's hiring. And then the last thing was Laracon US. You opened up ticket sales yesterday and you also released a new round of the speakers. Talk to me about how is everything going? How's ticket sales going? How you feeling about the speaker lineup? How is everything else planning going? Taylor Otwell: I Think everything's going really good. I mean like me. Let me calculate this. So we're at Something like okay, we're at 500 even seats filled . So that is more than half filled because I think we can only hold something like 950 in this venue so we're we're past halfway after roughly 24 hours of ticket sales . That's a lot of tickets sold, you know, so I'm, I'm actually pretty pumped about that. I knew that, you know, we sold tickets really fast last year, we sold them a little bit faster this year, but more or less the same, let's say between last year and this year, but I kind of had prepared myself for a little bit of a drop off just because last year, Nashville was the first Laracon in like four years. I think people were excited to get back out there and there was kind of some pent up energy. And now this was kind of like, okay, now we're kind of back in the groove. And maybe some of that excitement had like, faded a little bit. But I mean, it doesn't seem to have. Yeah. So yeah, we also introduced so yeah, I mean, If you're interested in coming to Laracon, definitely get your tickets sooner rather than later, since they are selling so quickly. I know quite a few people missed out last year that wanted to come just because we did totally sell out last year. On the speaker front, I announced a few new speakers yesterday. I sort of like soft launched a few new speakers. I only announced one, which was Adam Wavin, who will be back on the Laracon stage after quite a while. I think we'll probably do like a Q&A or panel discussion. I'm not sure if he'll prep a full talk. We'll see but he will be on stage in some capacity doing something. I also soft launched a few more speakers, which I will tweet about. But you know Jess Archer from the Laravel team Luke Downing who is an instructor at Lara cast Daniel Colbourne who has ThunkDev, a Laravel agency, and created a few Laravel packages, like Verbs, kind of a event sourcing type package for Laravel. Joe Dixon from the Laravel team, who primarily works on Vapor, and also developed Laravel Reverb. And then Philo Hermans, he spoke at Laracon EU, and is a really awesome Laravel developer, LiveWire expert, has built some cool things in the Laravel ecosystem. And we're still, you know, not done selecting. Yeah. Yeah. Amazing hair for sure. We're still not done selecting speakers. So right now we're at 10 announced and we will finish with a total of 18. So, you know, it's not too late to throw your name in the hat for, you know, a Laravel or Laracon speaker position. We still have the CFP talk submission form up on the website if you're interested in that. Matt Stauffer: Love it. So one of the things I always recommend for folks who are considering to be conference speakers for the first time, and I want to hear your thoughts about this, Taylor, is that the easiest way to get in, well, first of all, is to submit. Like, you're never going to get in if you just kind of keep talking yourself down. But the second thing is, if something like Laracon is potentially your first time speaking and you don't have a reputation as a speaker, it could be a little bit harder for someone to choose you. So give evidence, you know, local talks and YouTubes and stuff like that so someone can see what you're like as a speaker. Is there anything else that someone who's interested in breaking into the speaker scene can do other than talking at local meetups, talking at Laravel Live, speaking on YouTube? Is there anything else that would be helpful or is that the main thing they should do? Taylor Otwell: I think the types of talks that are submitted make a pretty big difference. General talks that are applicable to almost everyone in the room always, of course, have more value than something that's pretty niche that might only apply to 50 people in the room out of 900, you know? So those kinds of talks are always greatly appreciated. You know, like an example of the most general kind of talk, which I think I've mentioned before, would be like, 10 ways to supercharge your Laravel development experience, you know, like everyone, there's a Laravel developer. It's really practical talk that presumably everyone can benefit from. Whereas like a more niche talk would be like, ten ways to build iOS native apps using Swift. It's not super relevant to the audience. So that's the advice I have. But it is true that a conference-like Laracon, which is the largest PHP event in the United States at this point. It is hard to select a speaker without like some of those local meetup talks that have been recorded and that we could go watch to see like, you know, what's the speaker like? How's the content? How's the flow of the delivery? You know, so realistically, that is definitely very helpful. Matt Stauffer: Yeah. And if you don't have a local meetup, literally write a talk and go give it on YouTube, right? Taylor Otwell: Yeah. Matt Stauffer: It's not the same as a stage, but it's really close, you know? Taylor Otwell: So yeah, that's definitely, that's honestly just as valuable. Matt Stauffer: Love it. All right. Well, that's the last of things on my list. Oh, is there anything else about Laracon US you want to talk about before we wrap? Taylor Otwell: You know, not really. Yeah. Just keep an eye out for more speakers and definitely get your tickets if you plan on coming. Matt Stauffer: Yes. Also get your hotels. Um, we thankfully this is going to be a little bit of a bigger city, but we've had people run into difficulty getting hotel rooms close enough to the venue. So we just booked, we do, um, the last year and we're doing again this year, we booked T ightens onsite and Laracon at the same time, because we're flying people some far so far away. We're just like, let's just knock it all out. We had to book a venue an hour and a half outside of town for the onsite, which is like not the end of the world, but it's, it's just cause like, there's just, it's hard to get spots for lots of people. So if If you're an individual, maybe less of a concern. If you're bringing a team, get those hotels soon, man, because they book up real quick. Taylor Otwell: Especially if there's like another conference in town, you know, besides Laracon, then they can really book up. Matt Stauffer: Well, I'm excited to experience Deep Ellum I'm very excited to experience this concert venue and of course this conference venue and of course It's always just good to be together, especially as having FOMO from L aracon EU you and I'm like, oh man Thankfully, I'm going to L aravel Live UK. So I'm like I'm gonna get some conferences before before US. I'm looking forward to that. I know Eric Barnes will be there too. All right, well, it was good catching up with you. And I'm wondering, you said in two weeks, we might be recording our next one, like on the day or right after the day you announce, or you have released, I might even postpone it, so we can like, like you'll release it and we'll record the next day. So hopefully the next time you all hear from us, it'll be right around the time, we'll be recording right around the time the release of Laravel 11 happens. We'll have some more thoughts about it then. Taylor Otwell: Yeah, should be fun. Matt Stauffer: Well thanks for hanging Taylor and thanks all y'all for listening. Taylor Otwell: See ya.