This is the full transcript of the Laravel News podcast episode #43 - “Laracon US 2017 wrap, Laravel Horizon, and new versions galore”
Jacob Bennett: Welcome back, everyone. We have been on a little [00:00:30] tiny hiatus, I suppose you can say. It has been a little while since we have been recording podcasts either for the Laravel News Podcast or for our own. So it's good to be back. Michael, are you back in Australia these days?
Michael Dyrynda: Back in Australia and freezing. It was a very big shock to the system after spending three weeks in the US in the middle of our winter, coming back home. As soon as the airport doors opened I said to my wife, [00:01:00] "Can we please turn around and buy a ticket and go back to somewhere warm." Unfortunately that was not allowed. She had to go back to work and I had a new job to start. So here we are back in completely wrong timezones and all rugged out.
Jacob Bennett: Yeah, so how was ... We both are obviously just coming off of Laracon 2017, coming back from New York City. Did you have a good time this year?
Michael Dyrynda: I had a great time. I think it helped that I was there for [00:01:30] longer than just the conference days. Last year was a bit brutal in that respect. But yeah, being able to hang around in the US, being able to check out New York before the conference, and then to still be around in the States after the conference was a lot of fun. We had a great time down in Orlando in Disney World and Universal, even though, I think we were there for six days, we ended up getting rained out on five of those days, to the point where our last day in Orlando we were watching one of [00:02:00] the entertainment at the Disney's Animal Kingdom, and halfway through the last show it rained so hard that they canceled the show. Then we had basically the entire park empty out all at the same time.
Jacob Bennett: Oh, man. I'm so sorry. Yeah, you guys did more traveling in three weeks in the US than I've probably done in my lifetime. Did you land in California? Were you just a short time there? Or did you fly straight to Chicago?
Michael Dyrynda: [00:02:30] We landed in California and then we had a five hour layover before heading straight to Chicago.
Jacob Bennett: So California, Chicago, stayed in Chicago for a wile, got some Giordano's Pizza, went on a little segway tour, got to go see Millennium Park, all that stuff. Left from there, went to Washington DC, got to do all your fun stuff there. Then went to New York City. Then went to Orlando, and then back home.
Michael Dyrynda: Yeah.
Jacob Bennett: That's crazy, that's awesome!
Michael Dyrynda: Yeah, it was a good trip. It was very relaxing. We got back ... We left on the Wednesday. I think we were [00:03:00] up at 4 AM to get our first flight, which was Orlando to San Francisco via Phoenix. So we had a little 50 minute stopover in Phoenix just to change planes basically. Then we had a full 12 hours or so in San Francisco. So I wasn't going to let the opportunity slip, I hired a Tesla Model S and we drove around the bay area. So went out to Oracle Arena, went to see [00:03:30] the Golden Gate Bridge. We drove all the way down to Apple Campus, to Apple Park, to Google and Facebook. Yeah, just had a bit of fun driving around in a car that I probably won't own anytime in the near future.
Jacob Bennett: That's pretty fun, that is pretty fun. I'm going to do something that I do with my kids every night at the dinner table, which is, we do good thing, bad thing. My kids love this. I don't know why. But they always say, "Good thing, bad thing, good thing, bad thing." They want to do this. So we're going to do this [00:04:00] about Laracon this year. So your good thing and your bad thing. So you have to say one good thing, you have to say one bad thing. The reason we say one bad thing is because, like if my kids ... A friend gave me this advice, if your kids come home from school, maybe they had a rough day, you want to give them an opportunity to tell you if something bad happened. It's not just like, "Only ever tell me the good things that happen in your life." So, good thing, bad thing. What was your favorite thing? And what was something that we can improve for next year, Laracon?
Michael Dyrynda: Well, really the good thing was being there. I think that the venue was really good. I think seeing [00:04:30] everyone was really good. Most of the talks were really good. The only real bad thing I think, for me, was that it was only a two day conference this year, so you really had one day less to hang out with everybody. It's really hard, especially once you find a group of people, like I did last year, that I wanted to hang out with. I only get to see them once a year. It was a bit disappointing to only be able to spend a couple of days with everyone. So nothing really bad [00:05:00] about the conference, as such, just not being able to spend as much time with people as you might have liked.
Jacob Bennett: Yeah, I thought, for a good thing, for me, I thought all the talks this year were super, super practical, they were all very useful. There was a lot of good stuff, where it was like, "Oh, we're dealing with an actual code base here. We're looking at something that we can refactor." Or, "Here's a situation that you might run into." And, "Oh yeah, I've run into that five times." Right? So I really enjoyed the talks a lot this year. I thought there was a lot of immediate application, so that was awesome.
[00:05:30] Same thing for me though, bad was like, I don't know, I would have always considered myself like, "Yeah, I'm like a city person, I like the city and stuff." But New York City, I got there early, I was in there like, I got there Friday, was there through Wednesday. Yeah, it's so busy, so busy all the time. That's really fun for a while. But after a little while I was kind of like, [00:06:00] "Oh right, I can do this for a little while, I can hang with these people for a while." By the time I got home I was like, "Oh yeah, it's good to be home, slow down a little bit."
I think of course, that was magnified, being that we were in Times Square and stuff too. So that was a pro and a con too, because there's tons of stuff to do, plenty of places to eat, but it can also be hard to find a table because there's so many people. With only having it two days; I really enjoyed last year that we had that extra day, that day at the beginning that was kind of a ... What did they even call that?
Michael Dyrynda: Tutorial [00:06:30] day.
Jacob Bennett: It wasn't like a science fair [inaudible 00:06:32]. It was tutorial day, yeah. But having three days was pretty awesome. So we'll see, maybe they'll do something like that for this coming year.
Michael Dyrynda: I knew New York's always going to be very busy. But I wonder if it was kind of magnified because it's also summer holidays over there.
Jacob Bennett: Yeah, possibly.
Michael Dyrynda: Like Disney World and Universal was really, really busy. A lot of the rides, there were 80 minutes, 2 hour wait times. I thought, you know, because we had multiple days it [00:07:00] was all right because I could come back, and after figuring out what I wanted to go on, go straight to those rides. But for the most part we just looked at the wait times. My wife doesn't really go on any rides. I said, "I'm not going to have you sit and just wait for two hours for me to go on a ride that lasts for 90 seconds."
Jacob Bennett: That's all part of the fun, man.
Michael Dyrynda: Yeah, it is if you're going to go on the ride.
Jacob Bennett: Yeah, right, right, exactly. That's funny. So wait, did you say that she doesn't do rides? Is that what you were saying?
Michael Dyrynda: No. She went on a few of them. But the majority [00:07:30] of ones that I went on, she was not interested in. So there was this Hulk ride at Universal studios, which was a lot of fun. There was some Harry Potter rides. A traditional rollercoaster, which you sit in a car. There's a ride in Universal studios where basically you're hanging and it's suspended from the top, so your feet are just dangling over space and it just spins you around and upside down and side to side. That kind of thrill is not in her wheelhouse.
Jacob Bennett: [00:08:00] No. Yeah, I've only ever gotten sick on a couple of those sorts of things. But when you get sick like that, it just ruins the rest of your day. It's not worth it, you know. Okay, well, let's jump right in to some of the stuff that's been going on. It has been a couple of weeks since we've had a show. The last show that we had was with all of the "big dogs", right? So, Taylor and Adam and Matt and Jeffrey. I'm not leaving anybody out, am I?
Michael Dyrynda: Taylor, no, that was it.
Michael Dyrynda: Correct.
But what they have is, they have a little blade directive that you just include on your page or in any of your pages, [00:10:00] and it will push all those routes onto your page as an object, and then give you that little route helper at the very top as well, which I thought was pretty neat. So, really looking forward to using that in the future as I have wanted that so many times. I think I've said that a couple of times on both of our podcasts, that that would be so handy, including the time when we had Daniel and Caleb on. So Daniel is the author of this. He had some help from some other folks at Titan Co. But big shout-out to Daniel for putting that out. Thanks, man. I very much appreciate it.
Michael Dyrynda: Absolutely.
Jacob Bennett: I'm not sure if we've talked about [00:10:30] responsible interfaces. I know it has been talked about a little bit. It was talked a little bit about at Laracon. It was talked a little bit about on our previous show with the "big dogs". Do you want to just take a couple of minutes to talk about what that is and why somebody might use it?
Michael Dyrynda: Yeah. So in Laravel 5.5, which, by the way, will be out later this month, August, after and/or around Laracon EU, there is this new responsible interface, and what this allows you to do [00:11:00] is to basically convert any object into a HTTP response and then return that directly from a controller or a route closure. So all it needs is a to response method, and that will represent how the object should be presented in a HTTP response. So previously, where you may have done ...
Jacob Bennett: Maybe you'd use Fractal or something like that, or a presentation class to modify the object properties before you would push it out to your [00:11:30] consumer, right? It seems like to me or feels like to me that this is very much used for API responses, was my take on it. So it's not necessarily like, this is how you modify stuff that you're going to send back to a view. This is stuff that you're going to modify for an API response.
Michael Dyrynda: Yeah, I guess basically it would be a nice way of consolidating any of your presentation logic. So what you would previously have done in a controller, you could then encapsulate in one of these responsible objects and then [00:12:00] just return an instance of that object directly in your controller. I guess it helps keep the size of your controller methods quite small.
Jacob Bennett: Okay, so, trying to think of a good example here. Maybe what you would do is, if my default you would normally return all of the attributes off of a user, so if you were querying to find a user by email, if you said, user where email, so you can put email, and you were just returning that user first or fail. If you had something where you were just going to return a small subset of the values that belonged [00:12:30] on a user or the attributes that belonged on a user, you could do that inside this new class that's going to implement the responsible interface.
If you had any complex logic that was going to be happening, so if in addition to the user, you wanted to go grab their posts and then grab any of the images that belong with those posts, then maybe that's not like a relationship. Maybe you have to query some third party service or something. You could do that inside this class and that wouldn't have to live in your controller [00:13:00] then. So I suppose it could just clean it up, take some of that logic out of your controller and give it a place to live.
Michael Dyrynda: Yeah, just some way of encapsulating any illogic, just so that you're not bloating your controller methods.
Jacob Bennett: Right, it's probably not a great example, but it'll work. I'm sure as we go along we'll find some great places to use it. Really as some people have mentioned, like, "Oh, it can be as a replacement to Fractal." Right? So if you needed to transform some stuff before you had an API response, this would be a great place to do that. So again, just kind of giving you a little bucket to put stuff in, [00:13:30] to take it out of your controller, keep your controllers nice and clean. And also reusable, right? So you could use this response class in other places. So you don't have to re-implement this same logic in other places.
Michael Dyrynda: Yeah, in that way you could package up a user's object and then handle doing the responses of that, and then sharing that between your applications, for example.
Jacob Bennett: Sure. So, Laravel Horizon. So if you were watching Laracon or keeping up with anything that was going on, you are aware that Taylor was going to be announcing what the Laravel Horizon was. [00:14:00] Michael, do you want to tell us what that is?
Michael Dyrynda: Yeah, so Horizon is basically a package you can install into your application that allows you to, quote, "supercharge your queues with a beautiful dashboard and code-driven configuration. So, what you might have previously been done is managing supervisor queues in something like Forge, and figuring out how many workers you have and timeouts and things like that. What Horizon is, is a package that you install into your existing application [00:14:30] and then it allows you to manage your Redis queues purely from configuration in code. So if you ever needed to increase the number of workers or change the queue timeouts or anything like that, you can do it all directly through a config file in your application, and then push those changes out. Then what Horizon will do is automatically bounce your workers and handle that for you.
But it is also a dashboard for monitoring of those jobs. So it will show you how many jobs have been running in the past minute, [00:15:00] in the past hour. It will show you the wait times and things like that on your different queues. But I think probably the most powerful feature that was demoed for this would have to be the way that it manages automatically moving queue workers basically between different queues. So when one queue gets busy and one queue is sitting there idle, Horizon will automatically take the workers form the idle queue and allocate them to the busier one so that you can process those [00:15:30] jobs a lot faster.
Jacob Bennett: Which is really cool, because you may have 20 queue workers running, but 10 of them were supposed to be handling email and 10 of them were supposed to be handling file movement or maybe transcoding or something like that, right? So the first of the month you send out reports to all of your users about how much of their storage they've used, right? So you queue up 10,000 emails to send and it's one in the morning so you don't have anything happening with transcoding, so what would happen is, all of your workers that would normally be transcoding, start moving over magically to your [00:16:00] email queues, and it would auto balance out. So you would have 19 of them working on your email queue and one of them working on your transcode queue. So that's pretty cool, yeah.
I think that the thing that was the biggest one for me was failed job management, that's really huge. So right now it's just been kind of like, it's very manual, and it's very annoying to have to go in and retry failed jobs. You have to go look at the database, and then it's always impossible to read the payload that was coming through, because it's serialized. [00:16:30] Then to retry them you have to log in to your server, you have to SSH in and then you have to PHP artisan queue retry, and then you have to go find the ID of the one that failed and retry it.
Then there's no association between the failed job and the new job. They got pushed on. Unless you're looking at your jobs queue and you note the ID of the one that just came on that you pushed from your failed queues. But it was just, there was no easy way to correlate them, right? So with the failed job management, you can [00:17:00] see your failed job and then when you retry it, it'll show you in that same panel, here's the new job that tried, with the same payload and everything. Then you can see if it passes or it completes successfully. So that's really, really cool. Of note, it does only work with Redis right now. I'm not sure if there is other drivers coming in the future, but it is only sort of a Redis thing right now.
Michael Dyrynda: Yeah, I'm sure that it could be adapted for other drivers in future. I think Redis is probably [00:17:30] a better option just because it's made to be available as a multi-servers setup. I think Beanstalk is kind of a one server situation, makes it a bit tricky, you know, you have to manage different ones. Whereas, Redis is designed to be spread across multiple servers and things like that. So it's a good starting point for it. It's super simple to get set up. If you're on Forge, I believe it's already set up. If you're wanting to do some testing [00:18:00] on your Valet environment, then it's nothing more than a brew install away.
Jacob Bennett: Yeah. So in any case, I'm really looking forward to using it. I think it's going to be great. I already have a couple of things that I'm going to use it for. I was curious to think about, could you use this to monitor multiple applications? But I suppose it would be like, you have one Redis install that's handling ... So maybe you have like a load balance or something like that, but you have only one Redis installation that's handling all your queues probably, you have [00:18:30] multiple queue workers, you know. I was trying to think if there would be a way that I could handle multiple jobs across multiple applications. But I don't think that'd be an ideal situation.
Michael Dyrynda: No, it's not. My understanding is that you install Horizon into each application that you need it to monitor.
Jacob Bennett: Right, it's a package. Yeah, that would make sense.
Michael Dyrynda: Yeah. You don't install Horizon into a single thing, that is like queue.example.com, and that will manage across all of your applications.
Jacob Bennett: I haven't messed with it much. So [00:19:00] how do you get to it? Once you've installed it, let's see here ...
Michael Dyrynda: It's just via Web UI.
Jacob Bennett: Right, I wonder what that is though. Where do you go on your Web UI to get to it. /horizon, Horizon's [inaudible 00:19:15] dashboard is /horizon. So it says, by default you will only be able to access this dashboard in the local environment. Cool. So you can set up whatever you want the Horizon off method to be. So you can say it has to be a logged in user that has this email address. So you can set up like, only [00:19:30] I'm allowed in, or only people in my team who have a role of admin, or whatever.
Michael Dyrynda: Yeah, who'll get into your existing authentications system.
Jacob Bennett: Yeah, cool. Awesome, I love it. I'm going to be using this in a couple of different places then, two or three that I can think of. Now I just have to learn to deal with Redis. I've never done anything with Redis.
Michael Dyrynda: Yeah, I think you'll be fairly set with Redis. You know, from a Laravel perspective it's all driver-based, so it's going to be the same as if you were using Beanstalkd or if you were using something [00:20:00] else that was supported by Laravel. Forge servers are all set up with Redis automatically anyway, so it's just a matter of deploying your application really, and off you go.
Jacob Bennett: Beautiful, love it. Okay, let's see what else we've got here. We're going to try and wrap this up in the next five minutes. We've got to go fast here.
Michael Dyrynda: You can now actually see Taylor's Laracon US keynotes, so we'll link that up in the show notes. But he will do a much better job of explaining the whole thing for us because he's been working on it in secret for quite some time, and [00:20:30] we have not had a chance to get our hands on it a lot just yet.
Jacob Bennett: True story. Okay, you probably use one of these two things, you either use Valet or you use Homestead. Both of them have gotten new versions. So there is Valet 2.0.5.
Michael Dyrynda: Yeah, I think my favorite part about this update is that when you do a restart or you do an install it actually gives you some more feedback as to what's happening. Whereas, previously, it would just sit there and [00:21:00] you would wait, and then it would say it was done. Now it will tell you that it's restarting Nginx or that it's restarting PHP, or that it's restarting DNS mask. So it's nice to get that feedback, just so you don't think it's got stuck.
Jacob Bennett: Yep. In addition, it supports PHP 7.2 now, which is good. We've got a Magento 2 driver, fixes for CakePHP, if you use that. It also will test for Nginx config errors before attempting to restart Valet, so that's kind of cool. So if you've modified your Nginx config, you know, sometimes [00:21:30] you have to run, I don't know what the command is, I can't remember, but there was like this step to verify to make sure that it's actually a good config, Valet will run that for you before it restarts Valet, to make sure that you don't get this like, oh crap, Valet won't start because you have an Nginx config, good luck figuring that out. So yeah, that's pretty cool.
Michael Dyrynda: Yeah.
Jacob Bennett: All right, cool. Also we have ...
Michael Dyrynda: Homestead version 6.
Jacob Bennett: Homestead version 6, there it is, okay.
Michael Dyrynda: So Homestead 6, the biggest change here is that it's now going to support multiple versions of PHP in the same virtual machine.
Jacob Bennett: [00:22:00] Look at that; beautiful.
Michael Dyrynda: So previously you might have had different versions of Homestead for different applications running different versions of PHP. Now you can target the same version across the board and in your Homestead YAML file you can simply specify the PHP version that you want it to use. So it supports three different versions, PHP 5.6, PHP 7.0, and PHP 7.1, and it is literally a matter of adding a PHP key into that Homstead.YAML file and then the supported version [00:22:30] of PHP that you would like to use.
Jacob Bennett: That's really useful. Especially for people who have to maintain a code basis where you have to have something like PHP 5.6, because it could be a pain to switch on Valet between different versions. I know you've got something out there, a blog post and a little screencast on how to do that easily. But this makes it trivial. You just add that key and you're done. Very cool.
Michael Dyrynda: Yeah. And this will probably be nicer, especially for my current environment, just to have a PHP virtual machine. Some of the requirements for the [00:23:00] project that I'm in now mean that it gets a bit hairy to just unlink and switch out the version of PHP that I'm using. So I may need to look at something a little heavier.
Jacob Bennett: Cool. Version 5.4.29 is out, and there are, of note here, we have two new directives, so you have the @auth and @guest directives. So this is something that's just, instead of saying, @if auth check, like that, to see if somebody is logged in [00:23:30] or auth guest to see if they're not logged in and then doing it that way. You just have the @auth and the @guest directives, which will basically package that up for you. So you put @auth and then end @auth. Then you can have like, "Hey, you users logged in, go ahead and display they avatar in the top right corner in the logout menu or something like that. Whereas, if it's guest you could have a login link on the top right corner. Yeah, just makes them nice.
Michael Dyrynda: This is a directive that I've often put into my own applications, and it's the kind of thing that once you see [00:24:00] has been submitted as a pull request into framework, you think, "Yeah, I could have saved myself lots of effort." So I guess that's something to consider, is that if you find yourself doing something project to project, it could be useful to other people. So consider submitting a pull request and helping everyone out.
Jacob Bennett: Yep, good idea. 5.4.32 is out as well. In this one we had custom validation rules, which again, we talked about on the show a little bit. It makes it easier to do customer if directives [00:24:30] in Blade. But the thing that I am most excited about is this temporary URL method that is on the file system adaptor. So I believe this is only implemented with S3 right now, so if you're using AWS S3, what you can do is you can say, once you're using your S3 driver, "Storage:: ..." Then you can say, "disc S3 ..." and then, "temporary URL." Then you pass it the location or the path to the resource, and then a [00:25:00] exploration as the next argument. This will generate a temporary URL for you. So that's pretty cool.
I believe the way that it does that is it uses the SDK to, in the background, go ahead and make a request to AWS S3, and it will generate you this temporary link, S3 will, and then it just returns that to you, which you can use. So, pretty cool. I've had to implement that myself a couple of times, where like I needed to download the SDK and include it in my application so that I could do specifically [00:25:30] this. So it'll be nice to just have it kind of out of the box now.
Michael Dyrynda: Yeah, so the SDK I think had a URL method maybe and all it does is signs a URL. So it creates a signed URL with an exploration so I don't believes it calls out to S3. You basically sign it using your API key and then it's verified when you make the request out to S3.
Jacob Bennett: Hold on, hold on, hold on, hold on. All right, run that by me again.
Michael Dyrynda: So it's not an API request to get a [00:26:00] URL. What basically happens is that you know the name of the file and you've got the parameters to that file. So you sign the request saying, "This is my signature proving that I have access to that file, and I want to make it publicly available for a period of time." So that's where the signature comes in using that key. So it does like a #HMAC over the request and sends that off as the signature, in a similar way to you would with any API request in your application.
Jacob Bennett: So the secret URL portion of [00:26:30] it happens on the Laravel side?
Michael Dyrynda: Yeah.
Jacob Bennett: So Laravel is storing some sort of key that when you come back ...
Michael Dyrynda: It's your API key that you use to access S3. So it uses that to create a signed request.
Jacob Bennett: Right. But doesn't it have to talk to S3 to do that, or no?
Michael Dyrynda: No. Because it's just a HMAC request. Here, look ...
Jacob Bennett: Yes, please send it to me. Maybe my understanding of how this works is flawed. [00:27:00] I'm sure it probably is. But whenever I've had to do this in the past, I've always had to make a ... You know, I used the SDK and said, "Yeah, create a temporary URL for me that expires in 10 minutes."
Michael Dyrynda: Yeah, so all it's doing is using some functionality within that. But it's not making an API request to get a URL, it's just generating one.
Jacob Bennett: You'd better find it now.
Michael Dyrynda: Oh, I will. Because I had to implement it for Google.
Jacob Bennett: See, that's the thing. [00:27:30] You've got to use the Google Cloud Services, so you actually have to know how it works. Me, I'm like, SDK, here's the method, blah, blah, blah, whatever, it works. I think it's making an API call. Sure. Here's the URL, it expires in 10 minutes. Have your way. Poor Michael, having to deal with Google Cloud Services.
Michael Dyrynda: Well, not anymore.
Jacob Bennett: I saw somebody actually the other day singing the praises of Google Cloud Services and stuff. They were like, "Have I mentioned how great it is, the API ..." Or, I can't remember if it was the API, there was like Consul stuff that you can do, I don't remember.
Michael Dyrynda: Yeah, GSU [00:28:00] too, it's all like, they have an API Doc, but it's basically like, here is how to do it, like run this one line GSU tool command, and this is the JSON that it generates. It's not, here is the documentation for the JSON API.
Jacob Bennett: So if you any of you out there in Laravel land are having problems with Google stuff, Michael's the man you need to talk to. Freelance work. There you go. We're going to wrap this up in one minute. So we're going to make it quick. Okay, in version 5.5 there was also something pushed out for pivot [00:28:30] casting. What you can do is, on a model you can have an attribute called casts. Let's give an example here. So let's say you have an array of roles. So I'm doing this, for example, in one of my applications where it's just a really simple trivial thing where I need to have a couple of roles for users and then I can check that. So it's an array, but then I want to store it as such in my database and I just have a text field or something like that. So I cast [00:29:00] that roles attribute to an array in my model. When it does that it'll serialize that array, push it into that field, and when it gets it out it'll de-serialize it.
So on pivots you can store additional information. So if you had users and posts, you have user ID, post ID. You can also store other columns in there on that pivot table. In the case that you wanted to have, let's just use the same example, let's say you wanted to store roles or something like that on [00:29:30] that table, which wouldn't make sense at all in this example of posting users, but let's say you did, what used to happen is you could take it out of that table and it would respect that casts attribute, but when you were putting it into that table you had to manually do the serialization of that array in order to store it on there. Now in Laravel 5.5 there's been a pull request pulled in that it will take care of that for you, both the serializing the de-serializing for those pivot attributes. So [00:30:00] that was the last thing on our list. There's a blog post out there for it. Michael is still looking for the Google stuff. He cannot find it, which means it does not exist, for Amazon stuff. The S3 stuff, it does not exist, he can't find it.
Michael Dyrynda: Oh, I've got it. Don't you worry. It'll be in the show notes.
Jacob Bennett: Oh, he's got it. There we go. All right. Well, everyone, thanks so much again for listening. Good to hear ... No, I don't know. Not good to hear from anybody or see [00:30:30] from anybody, we don't do either of those things. Michael, good to see you.
Michael Dyrynda: Good to see you again too.
Jacob Bennett: Good to see you and hear you. I get to see you on Google Hangouts.
Michael Dyrynda: Yeah, it's been a little while. We spent a couple of days with each other and then we had to have three weeks apart.
Jacob Bennett: Yep, I know.
Michael Dyrynda: As always, thank you very much for listening. You can reach us on Twitter, @LaravelNews, if you have any questions or suggestions for future episodes. You can also reach us on our personal Twitter accounts. If you could like and rate the show 5 stars [00:31:00] on iTunes or your podcatcher of choice, that would be much appreciated, it helps with discovery of the show for new listeners.
Jacob Bennett: All right, everyone. We will see you in a few weeks, and thanks again for listening so much to the Laravel News Podcast. We'll [00:31:30] see you later.
Michael Dyrynda: Goodbye, all.
Jacob Bennett: Never done anything with Redis, I swear, today is like the day of interruptions. You know, phone calls, I've got three in the last minute and a half here. So, hey, it happens, right?
Michael Dyrynda: It happens.