This is the full transcript of the Laravel News podcast episode #32 - “Laravel Shift with Jason McCreary”
Jacob Bennett: [00:00:30] Hey everyone! Welcome back to the Laravel News podcast. Today on the show we have Jason McCreary with us. Jason was at Laracon2016, and gave a talk called YAGNI which, if you haven't heard the acronym I have been using it since that talk. It was a great talk, and he is also the guy that is behind Laravel Shift, which we have also talked on this show a little bit about. So we wanted to have him on to talk about the shift that he created for 5.4, as well as some of the other things that are going on with [00:01:00] that. Jason, welcome to the show.
Jason McCreary: Hey, thanks.
Jacob Bennett: For anybody that's not familiar you, could you tell us a little bit about what you do, where you're from, what you're currently working on?
Jason McCreary: Yeah, yeah. So I'm Jason McCreary, as you said. I like to go by Jay Mac, which basically is just a nice little abbreviation of the name. A mash-up of the first and last. It was actually given to me a couple years ago, because basically everywhere I work there's three other developers that are named Jason, and in face, at my most recent [00:01:30] job there was a guy that actually, his name mashed together is Jay Mac as well, so ...
Jacob Bennett: Oh no.
Jason McCreary: It was one of those things where he was like, "Okay, look. I'm just gonna go by Jason. You can take Jay Mac, 'cause it sounds like you've really used this before.
Jacob Bennett: That's funny.
Jason McCreary: So I'm totally fine with just Jay Mac.
Jacob Bennett: Alright, perfect. I guess we wanted to - there's probably people who have heard us talk about Laravel Shift before, but for [00:02:00] people who have maybe not listened to the show before, can you give us a little intro of what the idea is? What the concept is behind Laravel Shift?
Jason McCreary: Yeah! So Shift is basically an automated way to upgrade your Laravel applications. I recently added some human services with that, which is basically where I kind of help you do that. But for the most part I would say, far majority, like 95% of them, people just use the automated service.
Effectively what happens is, you sign-in [00:02:30] with Git - or sorry, GitHub - Bitbucket, GitLab, and basically say, "Look, I want this repository and this branch to be upgraded to whatever versions." So in this case let's say Laravel 5.4, and about I'd say 90 seconds later you get a pull request with all of the updates that say, "Okay, here's everything that was changed." They're nice and broken out, and clean commits, and anything that it couldn't reliably upgrade, it's gonna give you a PR [00:03:00] comment and say, "Look, go check out this file. Here's what changed. See what you might need to do."
Jacob Bennett: What version was it that you started this at. It was in the 4's, I think, wasn't it?
Jason McCreary: Yeah, so about two - I guess it was two conferences ago, at PHP[World], which is in the fall in DC, I gave a talk on All Aboard Laravel 5. That was basically the big shift from 4.2 to 5, and Taylor was there, and basically [00:03:30] I caught up with him after the talk, and just kind of said, "Hey, are you aware of anybody that made any scripts for this? 'Cause a lot of this stuff was obviously moving directories, and renaming a bunch of classes, and adding some name spaces, and I found a few blog posts, but nobody had really made some scripts.
I've used PHP for about 15 years now, so I mean, I've gone through a lot of frame works. And I remembered back in the day where CakePHP gave you a migration script as part of the frame work.
Jacob Bennett: [00:04:00] Nice.
Jason McCreary: It wasn't 100%, but it did the stupid, tedious stuff right.
Jacob Bennett: Yeah.
Jason McCreary: So anyway, Taylor was like, "Hey, you know, I'm not familiar with anything like that, but I'd use it." And I was like, "Here we go."
Jacob Bennett: Nice. There you go, yeah.
Michael, have you had a chance - I know you've used this in the past before. What was the process like for you? What version were you using? Or actually, maybe you did it all manually?
Michael Dyrynda: Yeah.
Jacob Bennett: I'm trying to remember, have you had a chance to use it?
Michael Dyrynda: No no, you're the poster child for Laravel Shift, [00:04:30] and I just dreamed that I could use Laravel Shift.
Jacob Bennett: It is true, I am the poster child for it.
Michael Dyrynda: Yeah, Jason and I have briefly spoken about it in the past, and our situations a little annoying, 'cause we're using hosted GitLab that is buried behind VPNs, so it makes it a bit tricky to use it. I just went through myself, upgrading one of our core applications from 5.1 to 5.3, and when the time is available to me, eventually up to 5.4.
[00:05:00] Upgrading Laravel itself is not the tricky bit, it's everything that sort of pieces in around it I felt, that was the time consuming stuff. And then obviously making sure that everything that relies on things that may have changed between those releases, that still continues to work. I definitely know the value of it.
Jacob Bennett: Yeah, we'll talk about that a little bit, too. Kind of a lot of the headache that you ran into going into your Laravel Shift is that you guys had bee on 5.1 [00:05:30] for three versions, so we'll talk about LTS a little bit later in the show. But before we get into that, there's a couple other things we wanted to talk about.
As Jason said, the Shift process is that you get this pull request to your repository, which is really nice if you're familiar with, or used to doing code reviews. It feels very much like you're doing a code review on the Shift. So you can see all the files that have changes, and you get the comments on - a lot of times what I have found, it can't, as you said, reliably shift - would be [00:06:00] the configs, so it's kind of difficult if you've got custom configuration in there to shift that stuff for you, so a lot of times it'll list out like, "Hey, you're broadcasting. PHP needs to be upgraded. Here's a link to the newest version, so that you can compare it real quickly against yours."
And a lot of times what I'll end up doing with those is I literally just copy and paste the newest one in there, and then just put my little configuration values back in. I've found that doing it the opposite way - which, basically trying to scan myself between the two, [00:06:30] and find out where they're different and replace just those spots - is actually a lot more error prone than just copying and pasting the whole thing and then moving my stuff back into it. You know what I mean?
Michael Dyrynda: Yeah.
Jacob Bennett: So, anyway. Do you wanna talk at all about the cost? That's one of the things that's really been crazy to me, is that - really since the platform started, it's been very, very reasonable to shift anything. So maybe talk about the price point. What's your reasoning behind that?
Jason McCreary: Definitely. A lot of people give me trouble about the pricing, [00:07:00] it's really funny. And there's catch there, right? Basically what we're talking about is just things like a couple bucks. In some cases it's free. I think the most expensive one is like, $19, and that's like 4.2 to 5.0, which is gonna take you probably eight hours of work, so unless you're making 30 cents an hour it ain't worth it.
Jacob Bennett: Right, right.
Jason McCreary: Right?
Jacob Bennett: Yeah.
Jason McCreary: And I'm aware of that, and it's one of those things where - you know, it's a balance, right? I have PHP Shift as well, which kind of goes [00:07:30] between the PHP versions, and that thing, I'll just be honest, is shit. It's made like $5. Doesn't even cover the hosting costs. Anyways, the point is what I realized is that as open source products and so forth, you wanna be careful about charging for things right? So I think that's a little of it, but I think most of it is, I really just wanna make it a no-brainer, right? Like it's more of the Google long tail approach.
So [00:08:00] effectively, instead of trying to take a base camp approach where I want $1,000 a year from 1,000 clients, I'd rather just have $10 from 100,000 Laravel developers that know that this is totally worth their time. It's the same dollar amount in the end, but I just think that's a cleaner approach in my mind.
Jacob Bennett: That's pretty cool. Yeah, I've never - I mean we've talked about - I know we talked about it last year at Laracon. That totally makes sense, though. You want it to be such a - you don't want it to [00:08:30] have to be a decision, really, that has to be made. Like on the part of the developer. Like, "Eh, can I convince my boss to let me do it this time, it would be so helpful." It's literally a no-brainer. So anytime that there's an upgrade, it's like, "Ah, I bet Shift will have - you know, Laravel Shift in the next couple days, I'll just wait for that, and then spend the $5 it is to update." You know?
Jason McCreary: There's also the balance of expectations, like if I charge $99 for Shift, and it doesn't get some of the configuration files to your point, or if I can't just run composer update and it works, [00:09:00] I'm gonna be answering some emails like, "Hey man, this didn't work for me."
Jacob Bennett: Yeah.
Jason McCreary: Whereas I feel like right now, the emails are very positive. Like, "Man, this thing is awesome, I would pay 10 times more than this, blah blah blah." So I don't know, it's just a more positive feedback loop, currently. I think I've only ever issued two refunds, and even then I did that. It was my choice to issue that refund. They didn't request a refund.
Michael Dyrynda: Yeah.
Jacob Bennett: Yeah.
Michael Dyrynda: And these are things that, in the same way that when changes [00:09:30] are made in the frame work that might seem innocuous, someone might submit a poor request. It gets vetted by other developers and things like that, and it gets pushed into the frame work, and then suddenly someone has got some obscure use case that was relying on that particular functionality that has now changed. These are all kinds of things that as more developers are using Shift, you're gonna pick up on them. And that then obviously increases the power, and the usability of Shift itself, [00:10:00] so it's good to keep getting that feedback as well.
Jason McCreary: And that's a good point, 'cause as awesome as the upgrade guide is, it doesn't list everything. And over time, Shift, just by it's sheer users and sheer feedback, I'm always making patches.
Michael Dyrynda: Mm-hmm (affirmative).
Jason McCreary: I mean, it's going to get far more - especially if you use it a week after the official release. It's gonna pick up way more than what you would've seen in the upgrade guide alone. To your point, it's gonna pick up these [00:10:30] little functions that changed inside, like the route helper, and all these things.
Michael Dyrynda: Yeah.
Do you - when you find these things, do you end up contributing them back to the framework? To the upgrade guide or anything like that, or do you make mention of them to Taylor?
Jason McCreary: Yeah. There's definitely been a few PR's I've made against the upgrade guide over the years. It's a balance, I guess. I think Taylor really likes to keep that pretty tidy, but I have noticed over the last few versions that there are some, I guess more [00:11:00] generic you might call them, like paragraphs. For example, I noticed in 5.4 at the very bottom it's like, "Hey go check out this compare on GitHub between the old 5.3 app and the new 5.4 app." Which is basically what - I've talked to him, that initially that's kind of what Shift does is basically compare those two.
Michael Dyrynda: Yeah.
Jason McCreary: So it's interesting to see that some of these things are making their way back into the upgrade guide. Which is great! I think there was a migration script, too, that I contributed back for some of the session tables back [00:11:30] in 5.3. So some of it goes back in.
Michael Dyrynda: Yeah, cool.
So that's the framework itself, so we can go all the way from, is it 4.1 or 4.2 right through to the latest, and each step gets a little bit more expensive. The older the version is that your on ...
Jason McCreary: Yeah I do that on purpose, just, I really believe on kind of being on the latest version, or at least towards the latest version. So yeah, as a new version of Laravel comes out, I think the old versions go up about 10%, [00:12:00] which really, again we're talking about $2, but ...
Michael Dyrynda: Sure.
Jason McCreary: Yeah, 4.2 to 5.0 is the most expensive, but it also is the largest shift.
Michael Dyrynda: Cool. So that's in terms of framework version to version. What about - one of the other shifts that you've got available is the Lumen to Laravel Shift. Do you see a lot of usage with that?
Jason McCreary: I put out the Lumen shifts, I think probably late fall, so you can go from the first version of Lumen, which I think was 5 all the way up to ... I don't [00:12:30] even know if 5.4 is out right now, is it?
Jacob Bennett: I'm not sure, honestly.
Jason McCreary: I don't think so, at least as far as I know. But anyways, it will take you to the latest version. But similar to the PHP shift, it's one of those things where it's probably only gotten a dozen users, so that lead me into maybe making a Lumen to Laravel Shift. Well not maybe, I am making a Lumen to the Laravel Shift.
Jacob Bennett: Yeah, I'm looking forward to that one coming out. We have a Lumen application that has been a pain [00:13:00] in my side to maintain. 'Cause every time I go in there I'm like, "Okay, I'll just do this little thing." It's like, "Dangit! I'm not in Laravel, I'm in Lumen, and I keep forgetting." And it's not a ton of things. It's just a couple things that are convenient and nice to have, that it's just I get confused between those two. And, I pretty much just don't want to deal with it.
it was like when Lumen first came out I was like, "Oh this is the new Hotmix, I gotta try this out." And it just doesn't matter. The speed benefit is great, but it's - you know, we're talking milliseconds [00:13:30] of difference here, between response times for the stuff that I'm dealing with.
Jason McCreary: Exactly. I mean, I'm gonna put a blog post out on this, and I have - I'll disclaim immediately like, "I have no inside information about this at all. This is just my personal believe." But, I think you're gonna see a Lumen get merged back into Laravel, and I think you're gonna potentially see some configuration options inside Laravel to get you that speed boost back that Lumen gives you out of the box.
Plus, I just think that as [00:14:00] the frame work evolves itself, as Lumen - sorry, as Laravel evolves it's gonna be one of those things that - you know, performance is just gonna get more and more baked in.
Jacob Bennett: Mm-hmm (affirmative).
Jason McCreary: Especially with speed increases in PHP itself. I mean, as soon as you adopt 7 only, you're gonna get a speed boost there.
Jacob Bennett: Yeah.
Jason McCreary: I think for a far majority of users, of Laravel developers, that extra boost that you're talking about by using Lumen is really not going to show up.
Jacob Bennett: Mm-hmm (affirmative).
Yeah, and it's pretty telling as well, that you've only had 12 [00:14:30] Lumen shifts, as opposed to how many thousands of Laravel shifts?
Jason McCreary: Yeah, exactly.
Jacob Bennett: Yeah. One of the things that you've kind of talked about, and you released this last year I believe, is the developer Shift platform. I was wondering if you could talk a little bit about that? I looked into it a little bit, but I don't think I ever really wrapped my head around it. So if you could tell us what that is, and what's behind that?
Jason McCreary: Sure, yeah. I guess, I probably put a blog post out early [00:15:00] this year - maybe late last year, I've been doing a lot of different things with shift, kind of reviving it. Took a little break to make some videos, which I guess maybe we'll talk about here in a little bit.
Jacob Bennett: Sure.
Jason McCreary: The developer platform effectively, the simplest way you can think about it is it's gonna be an App Store. So effectively, developers can go and say, "Okay, well, you know I want to make a shift that does this." So I'm gonna give them access to an API that's gonna allow them to do some of the [00:15:30] things that Shift does under the covers. Things like: Copying files, merging files, figuring out differences between files, making commits, PR comments. All the things that you would need to build a Shift would be available in this API, and it's gonna have a façade feel. So it's gonna be Shift Facade, with all of these methods on it.
The point is, is that I get a lot of ideas from people and I just don't have the time to keep up with them all.
Jacob Bennett: Yeah.
Jason McCreary: And I love making the core shifts, and that's obviously where [00:16:00] a lot of value is, but even just going off and making these package shifts, or some of the micro-shifts, or even some of the Lumen shifts, they just didn't really end of being worth my time, but maybe another developer that's more involved in the Lumen community, that sub-community, might be able to push that shift a lot better. And it'll be a revenue sharing model, or you can make it free if that's what you want, but I just thought it would be a nice way to open up the platform a little bit, take some of the stress off me to [00:16:30] expand the platform, and give that opportunity to developers, and also an opportunity to maybe make some money.
Jacob Bennett: Very cool, okay, that's helpful! I figured that it was kind of something like that, and is that currently available for anybody who wants to use it?
Jason McCreary: It's really very Alpha right now, I'm just in an enrollment process where I'm trying to build a little buzz. I've got a newsletter going out, there's a couple hundred people on it. I need to send one soon, 'cause it's been a week or two now. Basically, I'm [00:17:00] really hoping to have that ready, probably mid-March where you can start sand boxing your ideas. But I do want to say that it would be important to go and get on that mailing list, because it is going to be an exclusive platform, meaning that unlike the App Stores, I'm not gonna have 75 Shifts that do the same thing. There'll be one Shift, and so long as you're doing a good job with that shift, that is your domain.
Jacob Bennett: Very cool.
Michael Dyrynda: Awesome.
[00:17:30] Here's one thing that seems to come up quite a bit, and that is the LTS versions of Laravel. I touched on that earlier, how much of a pain that was for me, getting up to date, and it looked for a little while there towards the end of last year, where there wasn't going to be another LTS version of Laravel, but we've had the announcement now, in the last couple of weeks, that Taylor is going to forge ahead for version 5.5 being an LTS. Your thoughts on Long [00:18:00] Term Support, Jason?
Jason McCreary: My thoughts are probably the same as Taylor's.
Michael Dyrynda: Mm-hmm (affirmative).
Jacob Bennett: Mm-hmm (affirmative).
Jason McCreary: I guess maybe - what does he call it, an anti-pattern?
I definitely understand what's being said there. It's one of those things - I wrote a blog post about LTS I think early last summer, which basically - it was kind of a catch title, just that it was a trap. And so what I mean by that, and what I think probably what Taylor shares by saying an anti-pattern, is you [00:18:30] are buying into technical debt, right? You're basically saying, "Look, I'm going to be on a version that's older than the current released version." Which is stable, right? It's out there, it's feature-rich. But that this point, if you're running LTS, which is 5.1, and by the time the next LTS comes out, which'll be 5.5, you're effectively four versions behind.
Michael Dyrynda: Yeah.
Jason McCreary: Now thank goodness something like shift exists, because you don't [00:19:00] have to go do all those individual things yourself. You can probably pay a sum total of maybe $17 and you'll be there, and it's no problem. But I think in general it's just one of those things where, it doesn't make sense to me, from a developers perspective, but I will say I do understand LTS from an enterprise, or an organization perspective.
Jacob Bennett: You've probably worked at organizations - I mean you've been doing PHP for 15 years, or whatever you said - what are some of those - 'cause that's the feeling [00:19:30] I've got, too. Is that this is a requirement of some of these enterprises. What's the benefit? Just help me understand. For an enterprise level sort of thing, all this stuff is locked in it's version? So like, "Hey, for the next three years we don't have to mess with the frame work, we're done with that piece. Now we can just work on our domain?"
Jason McCreary: Well, I work in an enterprise right now that, honestly, they don't use PHP, because they have deemed, or [00:20:00] certain groups within the organization have deemed PHP insecure, whatever that means. These are people higher up than me, so we just kind of roll with it. And so I think to that point, it's one of those things where it's the support aspect of it, I believe, is what the sales pitch is. At least, that's what it would be for our organization, is that, "Hey, okay, this thing has two years worth of support."
And to your point, that also means not only is that keyword [00:20:30] of 'support' there, but also the fact that we don't have to go change this, right? I think a lot of big organizations maybe don't have the clearest picture on what an open source project truly is, and so they look at it as maybe from a chaos perspective, than more of a, "Hey, we have, like, thousands of developers helping on this, right? Like, supporting this and making it better." To them it's more maybe, again [00:21:00] that organized chaos approach.
To slap a sticker on something, or a stamp on it, and say, "LTS! This has two years of support, and three years of bug fixes, or whatever." I think it just makes the higher-ups feel better about it. That's just my take on it, if that makes sense, as a lowly developer.
Jacob Bennett: Yeah that makes total sense.
Jason McCreary: And so for those reasons, if you want to use Laravel, you need LTS. And so I completely support it from that perspective, and like I said, when the next LTS version comes [00:21:30] out, hopefully you'll take a peek at Shift, and help yourself along the way.
Jacob Bennett: It is funny, I was talking to one of the guys that I work with, and he had worked at a web shop maybe five, six years ago, and - so JQuery was the big thing, right? And it was open source, and they would not use it, because their idea was like, "Wait, everybody can like, see the code? Like, isn't that - you could get hacked!" It's like, "no, no, no. Like, no. This is good code, because everybody can see [00:22:00] the code. Because people who're way smarter than our developers are looking at that, and fixing anything that needs to be fixed, 'cause they're using it, too."
So they literally made the guy that I work with write his own JQuery, pretty much, because they didn't want the code to be out in the open, I guess? I don't know, you can just decompile the stuff that's already included. I mean you're downloaded all of it anyway, so I don't know. It's just silly.
Michael Dyrynda: Yeah. Not made here.
Jacob Bennett: Right, exactly.
Jason McCreary: [crosstalk 00:22:27] bro.
We had a similar [00:22:30] argument. And these are the, you know they sound silly on the surface, but these are real conversations that happen in larger organizations, and it's just - again there's been some decisions made over the years, that have kind of snowballed into these somewhat silly situations. But you have to work through them, and again if - I think it's a smart move by saying, "Okay look, I can't turn my back on these people, or this community. I want to make sure everyone has access to use Laravel, so here's a version [00:23:00] that we're gonna support long term."
I think it makes sense for reach. But I think if you're a regular developer and not necessarily working for an enterprise, I still maintain that it's a trap. It's technical debt, and you're gonna be missing out on years worth of features just to be on some version that has a couple letters behind it.
Jacob Bennett: For sure.
Michael Dyrynda: Yeah, definitely. And I think it's important. And I spoke briefly with Taylor about it the other day, and you know we sort of share [00:23:30] the same - all of us here share the same thought process on this and that. If you're in a position where you can be on the most recent version of Laravel, then I certainly would, and Taylor certainly would, quite vocally. You know? Stay on the most recent, because you're gonna get support. Those current versions are always gonna be actively developed, while they're the current versions, and it makes your process of moving to the next version that much easier.
So definitely [00:24:00] - as you say, there are certain situations where the choice is out of the developers hands, where you need that long term support for whatever reason, and so there's definitely a market there for it. And it's good that Laravel is in the position to where it can cater to developers that want to keep quick on their feet, and also organizations - you know that enterprise sort of level, that need to have that longevity and support of big [inaudible 00:24:28] platforms I guess.
[00:24:30] On LTS as well, someone did ask me on Twitter about the packages. You had the first party packages like Cashier Passport, those are not covered by LTS, so it's the frame work itself, so just to cover those bases off.
Jason McCreary: Which is think is really interesting, because packages, in a way, making LTS versions - 'cause LTS 5.1 for example, wouldn't be end of life by the time LTS 5.5 comes out. So if you're a package developer, [00:25:00] you're effectively making three versions of your package now to be Laravel package developer. I just think it's a little bit of stress, maybe. So it's - I think there's going to be interesting things that might have to happen in the ecosystem to truly support those different versions, right? And I would assume that if you're a package developer when 5.5 LTS comes out that you stop 5.1 LTS, but you just never know, right? It's just an interesting dynamic. I think it can create some questions.
Jacob Bennett: Yeah, good point.
[00:25:30] Well, Jason, we wanted to thank you so much for coming on the show with us this morning. I know that you have another platform that you're working on right now, and I thought maybe you could tell us a little bit about that before we let you go.
Jason McCreary: Definitely. It's one of those things that I kind of picked up on when, I guess, I made Shift. I really thought that the PR and using Git as the backbone, was brilliant. You know, I was all, "Man, this is awesome, it's gonna be great."
Michael Dyrynda: It is, by the way.
Jason McCreary: "The customers are gonna love this." You [00:26:00] know? And - thank you.
But what I really found - and I'm gonna talk about this at Laracon online here in a couple weeks, I'm really excited about that - what I found was that just as many questions as I was getting about upgrading Laravel, and Laravel specific questions, I got an equal number if not, maybe recently, even more questions about what's a PR? How do I check out this branch that it made? What if i want to merge in this commit? Hey, I don't want this one [00:26:30] commit where you did some reformatting, how can I get rid of that?
So it was really interesting, because all of these are Git related questions, and what I realized is that we just don't really know Git as much as we might think we do. There's a really great XKCD comic that I reposted the other day that I saw in an article, but basically it's like, "Hey, memorize these commands, if you screw things up just copy your files to another folder and re clone the repo." You know? And we laugh, because we've all done this, right? [00:27:00] We've all been there. I've done it dozens of times myself over the years.
So what I did was, I kind of took everything that I know about the commands, the Git commands, and turned it into about a 50 video series called Getting Git. And effectively it runs over all the core commands, and then there's a sub-series of, I call Everyday Git, where I basically start going over everyday scenarios that you're gonna encounter when you use Git. So everything from simply setting up your terminal to have the fancy branching [00:27:30] and stuff built into it, the clean and dirty states, but also things like maybe branching models, or how to even work with GitHub in an effective way.
And in classic Jay Mac pricing style, it started out as $9. Well, it was $9.17 that I called the Git price, which is effectively 1337 for Git, but now it's about $29 now that the video series is done, which I think is still a pretty good deal. That's a one time price, [00:28:00] you get access to all the videos, and the Everyday Git videos are basically - I'm gonna continually add to them anytime I come across a Git scenario that I think needs some explaining.
Jacob Bennett: Yeah, it's great to have a resource where I can point people who have never - like they don't even know what Git is, I'm introducing it to them for the very first time. It can be difficult to find a great place that will walk through all of it with them, from beginning to expert level, and anywhere in between.
And it was cool how you structured it, too. Basically you take each command, and do [00:28:30] a little mini-video series on it. So you have an intro, like, "This is what it does." And then you have another video that goes through all of the options, and everything that you might possible ever do with it. So yeah, it looks like it's structured in a really nice format, and looking forward to getting all the way through it.
Jason McCreary: Yeah, I definitely wanted to make it for, you know, not only beginners that could start with Git It, you know 'cause that's where it starts, but if you are more familiar with Git and you just want to go in and choose your own adventure and say, "Well I want to know more about Git rebase." And you can just jump right to those [00:29:00] videos. And to your point, there's a ENIT video, and then there's master version of that video just to play on the GIT terms.
Jacob Bennett: Ah, I see. I get it now. A master versions, makes sense, okay.
Jason McCreary: Git it.
Jacob Bennett: The humor was lost on me.
Well, again, thanks for comin' on the show today. It was really great talkin' with you. We are huge fans of Laravel Shift, and will continue to use it in the future. Hopefully it does really well for you, man.
Jason McCreary: Thanks. And Michael, a lot of the times people that are on GitLab servers, that is something I want to look into supporting [00:29:30] in the future, but most people will temporarily clone it over to just a private thing on GitLab.com or Bitbucket. I know that's probably what I told you before, but ...
Michael Dyrynda: Yeah. But that corporate overhead and red tape, my friend.
Jason McCreary: Oh, I understand. I've had some people, like I said, they ask. It's just one of those things, in all the considerations, that's like, "I don't know." There's only like, one person a month that asks. So I gotta deal with volume.
Michael Dyrynda: For sure.
Jacob Bennett: Well, we look forward [00:30:00] to seeing you at Laracon online in a couple weeks, and look forward to your talk there, man.
Jason McCreary: Cool guys, yeah. I appreciate it.
Jacob Bennett: Thanks for comin' on.
Michael Dyrynda: See ya.
Jacob Bennett: So we've got a couple other news items this week from Laravel News. Michael, do you want to start with Laracon Online?
Michael Dyrynda: Yeah. So we talked with Ian Landsman in the last episode about Laracon Online, and they had just passed, I think 1,500 or so ticket sales. In the last two weeks they have now crossed to the 3,000 developer mark, which is a big [00:30:30] testament to there being a big, big market for this, so congratulations to Ian and the rest of the folks that helped get this off the ground.
The ticket price that was $10 has, I believe, gone up now to $20. Which is - I tweeted the other day that Laracon Online would be a steal at twice the price. And even now at $20 I still think that's true.
There is a post on Laravel News which goes through all of the conference swag, which [00:31:00] is now being announces, so there's a whole heap of different offers from Linode, from Nexmo, from Bugsnag. Pop-up co. Which we spoke about with Ian. And also Black Fire and Postmark. So jump onto Laravel news, and we'll put a link in the show notes that basically covers all of that stuff off, so you can have a look at what you're going to get for your $10 or $20, depending on when you purchased your ticket.
Jacob Bennett: Very cool. Something that was introduced in 5.3 that I wanted [00:31:30] to talk a little bit about is these stacks. So this has been something I've used recently actually, where you can declare in your blade - in your blade file you have an @stack, so it's a stack directive, so @stack, and then you name it. It's almost like what you would do if you @yield, so if you were pushing a section in there. So a common thing that you might have is a side bar, so you'd say, "@stack(sidebar)"
And then what you can do is that other places in your other blade files that maybe extend one of those parent files, or are component [00:32:00] pieces, you can say, "@push(sidebar)." And what that will do is take whatever the contents of that section there that you have, in the @push(sidebar), and it will take whatever is in there, and it will push that onto that stack that you had to find somewhere else in your blade file.
So that was cool. It was a little bit dependent on the order in which your templates were rendered though, so if you said, "Push push push," you would end up with those things in order 1, 2, 3, [00:32:30] in how they came in.
Well, sometimes, depending, you want to have something at the very top. So your options are either to make sure that that piece of the template gets rendered first, or in 5.4.10 a new prepend directive has been added. So instead of saying, "Push(sidebar)," you can now say, "prepend(sidebar)." Instead of pushing it onto the end of that stack, it will prepened it onto that stack. So that's kind of a cool feature. I can imagine that being used - if, for example, you weren't [00:33:00] concatenating all your scripts with mix or with Elixir, if there was a library that you needed to be available at the very top of your stack, you could prepend it to the very top to make sure that it loaded before the rest of them did.
So there's some really cool uses that you could have for that, and there is a blog post out there on Laravel News, which we will put in the show notes as well.
Michael Dyrynda: Yeah, definitely.
Laravel Collections "when" Method
Jacob Bennett: Speaking of things pushed into Laravel 5.4, Michael do you want to talk about the "when" Method on collections?
Michael Dyrynda: Yeah, so I discovered this "when" Method in the eloquent [00:33:30] QueryBuilder a little while ago, and tweeted about it. I was pretty excited with it. Basically what the "when" Method does is it allows you to conditionally run a query based on some variable. So where you would previously do a check, I guess to see if some parameter exists in your request, you would assign that to a temporary variable and then go, "if request has whatever, then append this to your query." So using the "when" Method allows you to basically inline [00:34:00] that within your existing collection.
I did have cause to use that similar functionality within the context of a collection a little while ago, and discovered that the method didn't exist. I wrote it initially as a macro in my application, but ended up submitting it as a pull request on the back of the work that Tom Schlick had done to get it into the QueryBuilder, so that is now available on the collections as well. So you can have a look at the blog post that we'll put in the show [00:34:30] notes that basically explains this in greater detail, 'cause trying to explain code verbally doesn't work very well.
Jacob Bennett: Exactly.
Michael Dyrynda: We'll put the link in the show notes, but essentially, what the "when" Method would allow you to do is to, yeah, basically just avoid having to declare temporary variables in your collection pipeline code.
Jacob Bennett: Which we all know is one of the greatest evils, declaring temporary variables.
Oh man, it seems like everything - there's so many ways to get around it. [00:35:00] It's really funny to see Adam Wathan do some of his stuff, because at times he'll do some silly stuff just to get around temporary variables.
Michael Dyrynda: He always finds a way.
Jacob Bennett: Yeah. No conditionals, no temporary variables.
If you saw any of the tweets that Adam had coming out this week, you saw that he's been working on sort of a payment thing. And kind of related with that, Stripe released a new set of - I don't even know what you want to call it. I don't even know if it's a new set of things. It's called Stripe Elements. And so [00:35:30] it's almost like a component, I suppose is what you'd call it, right?
Michael Dyrynda: Mm-hmm (affirmative).
Jacob Bennett: Where you have a single field that will now allow you to accept the credit card, the month, the date, the expiration, or the month and year of the expiration, I think even the zip code and things like that. It kind of changes around the way that you might have had to do your forms before, where previously your options were either to use their Quik Stripe checkout, where you click a button and it does the little pop-up. [00:36:00] Or make your own custom form. This kind of is a little bit of an in between, right? It's still provided by Stripe, and maintained by Stripe, but it's not a pop-up on your page. So it's kind of cool. It looks like it works really, pretty well.
One of the things that's pointed out here that is a point that I'd like to make, is that Stripe very clearly warns you, when you are building your own custom forms, that you do not want to give your custom forms that contain sensitive data, you custom form elements that contain sensitive [00:36:30] data, you do not want to give them a name property.
So when you submit a form to your server, your server will submit all of those based on the name that is given to that form element. So if I have an email, I can say input type = email, name = email, and when I go to submit that my server will pick up the contents of that form element as email, and post it to my backend, right? Well, one thing that Stripe suggests is, they say basically if you're collecting a credit card number, or [00:37:00] if you're collecting a CV or whatever it is, in your own custom forms do not give those form elements a name.
Stripe Test Tokens
One other kind of related thing that Eric had blogged about, and I didn't find out about until just this morning actually, is that I had made a package a little while ago called Stripe Test Tokens. And I don't even know if you could call it a package. It's really just a little, tiny helper library. Stripe will allow you to send through a number of different test card numbers. So [00:38:00] for example, 424242424242, whatever. If you've ever had to do testing before with stripe, that number may sound familiar. You type in that number and that will do a successful transaction. They have a couple of different numbers that you can type in. I always think of them like cheat codes, right? So you've got this special number that you type in, and it will give you a type of exception, or it might be a valid Visa, or a valid MasterCard, or it might say, "Hey, the zip failed on this." Or it's an expired card, or something [00:38:30] like that.
You might want to test to see how you're going to handle those types of exceptions, and it can be a little bit difficult to mock those exceptions in your tests, unless you can do it some way like this. So Stripe Test Tokens essentially allows you to create those test tokens really easily, and then post to your application and see how your application reacts to them. You should check that out. It's on GitHub, we'll link it up in the show notes.
Michael Dyrynda: So the next item that we've got here, is talking a little bit about [00:39:00] a recent report from CloudFlare that they had been leaking custom HTTPS sessions. So under certain circumstances, their edge service were running past the end of a buffer, and returning memory that contained some private information, like HTTP cookies, or authentication tokens, and things like that. And, you know, obviously HTTPS, this stuff should be protected. But some of the data had actually been cached by search engines, so CloudFlare has been very quick, [00:39:30] and very transparent, in reporting and detailing what happened in this situation, what they are doing to work on it, and so they've jumped on the problem and they've reduced it down to where the issue was happening. It has been fixed out, it has been brought out to any customers that were affected by it. So there is a blog post on Laravel News that goes over the details of this. There's also a list of some of the more popular domains that were effected.
Laravel News does use CloudFlare, but was not [00:40:00] one of the effected sites. So Laracasts was on that list as well as one of the affected ones, so probably for peace of mind, it might be in your best interest to update your password.
Jacob Bennett: Yeah, I think so. That's what I've read. I mean, there was a couple of posts I've seen around like, "Yup, you should definitely change passwords."
Michael Dyrynda: Yeah.
Jacob Bennett: If nothing else.
Michael Dyrynda: Yeah, passwords, private messages, AVI keys, and other sensitive data were leaked. So certainly, if you're using Laracasts, it's an idea to [00:40:30] probably go and update your password.
Jacob Bennett: Yup.
Michael Dyrynda: Laravel.com is one of the sites using CloudFlare, but obviously you don't log into that, so not too many issues there, but certainly yeah, have a look at the blog post, which will outline all of the top, popular sites that were affected by this.
Jacob Bennett: Very cool, thank you.
One of the articles that was on Laravel News this week, which I found pretty interesting, is called "No Really, It's Okay to Be Unavailable." And she talks about the challenges we face living in an uber connected world, [00:41:00] and how it can almost be seen as unprofessional to be unavailable. And she just kind of points out, "No, it's really, it's actually a good thing, for you to disconnect." And I've actually been reading a book called Deep Work, which has been really, really interesting. It talks about this exact thing. The ability to unplug, and to not be distracted. So they really encourage things like, maybe schedule your day.
Well, [00:41:30] let's be honest, right? None of us could just shut off email and be totally fine. It's part of our job. So instead of saying, "Hey, shut off email for the whole day, and just get work done," which would be great, it basically says schedule your day around being, "for the first half of the day I'm gonna do email, and for the second half of the day, literally shut everything off." Shut off your Twitter, shut off your email, shut off all of that stuff, and just focus on deep work. Non-distracted, deep work.
One of the things that they've said, which was really interesting to me, and has been a cool [00:42:00] exercise - so the thing that some people do, is they will schedule break times from the internet. They'll say like, "I'm not gonna do Facebook for a month." Or, "I'm not gonna do Twitter for a couple days, or whatever." Instead of scheduling breaks from the internet, schedule internet time. Meaning, I will only get on the internet during these 15 minute periods during the day. So if it's not within that 15 minute period, you can not get online. Even if you have an issue.
It's because the [00:42:30] internet, and Twitter, and stack overflow - it's so like, what's the word I'm looking for, like, alluring. You always go there looking for something, and end up 10 pages later, and 20 minutes later, like, "Oh my word, where did that time go?"
Michael Dyrynda: Yeah.
Jacob Bennett: So they encourage you to say, "Okay, don't schedule your breaks, schedule your internet time."
So that solved [00:43:30] that problem for me, so I'm not tempted to go look at other stuff, I just look at the documentation. Solved my problem.
But second of all, if you have a problem that you must be able to get online for, just do something else. Come up with something else that you need to get done. There's plenty of other things to be done, and do that. And what this allows you to do, this kind of allows you to rewire your brain to not be so distractable, and so distracted.
So anyway, Deep Work is the book that I'm reading. It's a really good read. And then, of course, this post that was put out on Laravel News this week, [00:44:00] "No Really, It's Okay To Be Unavailable." Both really good to read, and just to think about.
Even, I think, Matthew Trask was tweeting the other day about not being able to code on the plane, because he didn't have access to documentation, so Matthew, if you're listening, read a docx to io will probably be helpful for you next time.
Jacob Bennett: Yeah, I heard about a guy who actually had a book to write, and so what he did was he booked himself a flight to Tokyo. A round-trip flight. And wrote the entire [00:45:00] way over, and wrote the entire way back, 'cause he knew he wouldn't have internet access. It was a quick way for him to be like, "Okay, I can do this."
Didn't Taylor even say something about that? I think he did. He said he got something done on the plane ride from the US to the UK for the Laracon UK. There was something, or the LaraconEU, or whatever.
Michael Dyrynda: [inaudible 00:45:19] Last, when we spoke with him a couple weeks ago, yeah.
Jacob Bennett: Okay. Yeah, so he said that he got something done during that time. So there really is some value to being able to just unplug from the internet, and just do work.
Michael Dyrynda: Yeah.
Jacob Bennett: Well, I am all out [00:45:30] of talking points for today. Michael, you got anything else for us?
Michael Dyrynda: I think that's it.
Jacob Bennett: Thank you, everyone, for listening. If you liked the show, please rate us "up" in your podcatcher of choice. Five stars is always helpful. You can find the show notes for this episode at Laravel dash news dot com slash podcast slash 32.
If you have any questions or things you'd like for us to talk about in future episodes, feel free to hit us up at Laravel News or our individual twitter accounts. As always, Michael it's great talking to you, man. Thanks for taking the time out today.
Michael Dyrynda: [00:46:00] Cheers, no worries, you, too.
Jacob Bennett: Alright.
Alright, thank you everybody so much for listening. Which episode are we on?
Michael Dyrynda: 32.
Jacob Bennett: 32? Thank you everybody. Thank you everyone so much for listening, this is [00:46:30] ... Thank you everyone for listening, if you liked the show, please rate us up in your podcatcher of choice. Five stars is always helpful. You can find the show notes for this episode at Laravel dash news dot com slash podcast slash 32. I think I got all that right. Michael, is that right?
Michael Dyrynda: Yep, you got it right first time, Jake.
Jacob Bennett: First time. If you have any questions or things you'd like for us to talk about in future episodes, feel free to hit us up at Laravel News, or [00:47:00] our individual Twitter accounts. As always, Michael it's great talking to you, man. Thanks for taking the time out today.
Michael Dyrynda: Cheers, no worries, you, too.
Jacob Bennett: Alright. First try.