WEBVTT NOTE Created by CaptionSync from Automatic Sync Technologies www.automaticsync.com 00:00:00.246 --> 00:00:03.686 align:middle Okay. So, Hi everyone. 00:00:03.686 --> 00:00:09.316 align:middle Thanks for joining this talk about PHP. 00:00:09.316 --> 00:00:14.956 align:middle First, a little bit about myself. 00:00:15.386 --> 00:00:18.226 align:middle I'm Portuguese, I'm Pedro Magalhães, by the way. 00:00:18.796 --> 00:00:20.726 align:middle I'm Portuguese, I'm 33 years old. 00:00:20.926 --> 00:00:25.006 align:middle Uh, I'm a PHP developer at the Dutch company called Emesa during the day 00:00:25.356 --> 00:00:27.476 align:middle and I'm a PHP contributor by night. 00:00:27.766 --> 00:00:28.596 align:middle Some nights, at least. 00:00:29.476 --> 00:00:37.096 align:middle Um, I authored one rejected RFC, which was to get rid of that small "b", uh, 00:00:37.096 --> 00:00:42.076 align:middle before the strings because in PHP you can always put a "b" before any string. 00:00:42.646 --> 00:00:47.476 align:middle Uh, and this is a relic from the past when this was introduced for forward compatibility 00:00:47.766 --> 00:00:51.316 align:middle with PHP 6 and the binary strings and the unicode strings. 00:00:51.946 --> 00:00:55.276 align:middle And that never happened as we all know, there is no PHP 6, 00:00:55.566 --> 00:01:01.896 align:middle but the "b" is still there 10 years now and it still doesn't do absolutely anything. 00:01:02.786 --> 00:01:05.286 align:middle But I tried to get rid of it, and people didn't want to get rid of it. 00:01:05.436 --> 00:01:06.286 align:middle So, it stays. 00:01:06.856 --> 00:01:13.406 align:middle Uh, and well, also one approved RFC - it's the first one that was approved for 8.0. 00:01:13.886 --> 00:01:17.956 align:middle And uh, yeah, I also tried to contribute a little bit to other open source projects, 00:01:17.956 --> 00:01:21.876 align:middle like I have my very own badge of Symfony code contributor. 00:01:22.396 --> 00:01:25.646 align:middle And, yeah, I like games, and beer, and technology. 00:01:26.616 --> 00:01:28.336 align:middle Yeah, okay. 00:01:28.546 --> 00:01:34.546 align:middle So in this talk it's called changing PHP and changing PHP can have two meanings, uh, 00:01:34.546 --> 00:01:36.066 align:middle and I'm going to talk about both of them. 00:01:36.066 --> 00:01:41.086 align:middle So one of them is as an objective, um, changing is something in a state of becoming different. 00:01:41.686 --> 00:01:45.536 align:middle And so we will talk a little bit about how PHP is changing lately. 00:01:46.116 --> 00:01:47.936 align:middle Um, and then as a verb. 00:01:48.176 --> 00:01:52.606 align:middle So I really like this definition to make the form, nature, content, future course, 00:01:52.606 --> 00:01:57.546 align:middle etc of something different from what it is or from what it would be if left alone. 00:01:58.146 --> 00:02:00.676 align:middle So this is the two parts of the talk. 00:02:01.396 --> 00:02:07.796 align:middle So, let's start with the first one - with changing as an objective and, um, 00:02:07.856 --> 00:02:09.326 align:middle let's start with a reality check. 00:02:09.726 --> 00:02:11.796 align:middle So this is where we stand today. 00:02:12.666 --> 00:02:21.086 align:middle Um, 5.6 has 24 more days of security updates and then 5 is done for, forever. 00:02:21.836 --> 00:02:24.886 align:middle 7.0 is already out of security updates. 00:02:25.296 --> 00:02:28.456 align:middle Even though there will still be one less release, uh, 00:02:28.456 --> 00:02:31.486 align:middle that was not planned, but there will still be 7.0.33. 00:02:31.986 --> 00:02:34.856 align:middle Um, but yeah, that's it for 7... 00:02:34.906 --> 00:02:40.636 align:middle for 7.0. Then 7.1 is already security only since five days ago. 00:02:41.406 --> 00:02:46.876 align:middle So, currently the only actively supported version of PHP is 7.2 - 00:02:46.876 --> 00:02:49.166 align:middle is the only one that is getting actually bug fixes. 00:02:49.746 --> 00:02:54.166 align:middle But, the good news is 7.3.0 is released today. 00:02:54.506 --> 00:02:57.266 align:middle It's not announced yet, uh, on the website. 00:02:58.226 --> 00:03:01.256 align:middle Um, but, but it will be later today. 00:03:01.316 --> 00:03:07.516 align:middle I promise, by night you can have 7.3 in production during the social event we can do it. 00:03:07.516 --> 00:03:10.326 align:middle Um, and yeah, it will be, it will be nice. 00:03:10.366 --> 00:03:11.526 align:middle But yeah, it's really, really great. 00:03:11.646 --> 00:03:13.696 align:middle It's a great timing that 7.3 is released today. 00:03:14.466 --> 00:03:17.666 align:middle So because of that, let's talk a little bit about PHP... 00:03:17.726 --> 00:03:19.496 align:middle about 7.3. 00:03:19.596 --> 00:03:23.346 align:middle Um, and let's talk about some of the things that it will bring. 00:03:24.096 --> 00:03:30.786 align:middle So, one of the first that I want to mention is JSON_THROW_ON_ERROR as it kind of advertises, 00:03:30.786 --> 00:03:36.226 align:middle it will be possible to pass chase and throw an error to json_encode() and json_decode(). 00:03:36.876 --> 00:03:40.166 align:middle And it will start throwing exceptions instead of you having to go out 00:03:40.166 --> 00:03:43.356 align:middle and check json_last_error() if something wrong happened. 00:03:43.916 --> 00:03:46.566 align:middle And, well, yeah, sometimes it did, sometimes it didn't. 00:03:46.876 --> 00:03:51.686 align:middle And a lot of the libraries for handling JSON are pretty much just wrapping this up, 00:03:52.156 --> 00:03:55.056 align:middle just checking the json_last_error() and then throwing it for you. 00:03:55.506 --> 00:03:57.436 align:middle But now, PHP can do it by itself. 00:03:58.336 --> 00:04:02.406 align:middle Then for the OCD ones among us. 00:04:02.406 --> 00:04:06.406 align:middle Now you can use a trailing comments in a function calls. 00:04:07.046 --> 00:04:11.996 align:middle Um, so your, your diffs are going to be much nicer now because you don't have 00:04:11.996 --> 00:04:14.756 align:middle to add a comment to the previous line and all of that. 00:04:15.506 --> 00:04:21.296 align:middle I, yeah. For some people it may be, it may be useful or nicer. 00:04:22.496 --> 00:04:27.076 align:middle Then, array_key_first() and array_key_last() also as the name advertises, 00:04:27.076 --> 00:04:30.056 align:middle it gives you the first and the last keys of an array. 00:04:30.656 --> 00:04:35.906 align:middle Um, and um, yeah, without changing the internal pointer of the array. 00:04:36.096 --> 00:04:38.516 align:middle So, the array stays in the same place where it was. 00:04:39.086 --> 00:04:40.326 align:middle And this way you can check it. 00:04:40.596 --> 00:04:45.756 align:middle It has, didn't fortunate decision in my opinion, of returning NULL, 00:04:45.756 --> 00:04:51.126 align:middle in case you pass an empty array, I would prefer to throw something, but mostly it's, 00:04:51.126 --> 00:04:53.716 align:middle um, it's, um, it's a good addition. 00:04:54.316 --> 00:04:56.686 align:middle And also, flexible heredoc. 00:04:57.186 --> 00:05:03.136 align:middle Uh, so for heredocs and nowdocs, um, you can now use this, uh, 00:05:03.136 --> 00:05:06.326 align:middle this syntax where the difference is that the closing marker. 00:05:06.606 --> 00:05:10.416 align:middle So, in this case, the end no longer has to be followed by a new line, 00:05:10.696 --> 00:05:15.356 align:middle so you can actually now close the function call that you are doing a after the closing marker. 00:05:15.826 --> 00:05:21.766 align:middle And the other thing is that the closing marker, I'm basically specifies, um, 00:05:21.836 --> 00:05:23.696 align:middle the indentation of the rest of the text. 00:05:23.846 --> 00:05:31.356 align:middle So, in this case, because END is not really at the, at the, um, at the first column, um, 00:05:31.396 --> 00:05:33.776 align:middle and it is at the fourth column, it means 00:05:33.776 --> 00:05:36.826 align:middle that C will only have one space before it when it's printed. 00:05:37.256 --> 00:05:42.716 align:middle So, basically, the closing marker now dictates, um, where the, um, 00:05:43.126 --> 00:05:46.956 align:middle where the intention starts for all the text. 00:05:47.116 --> 00:05:53.176 align:middle Then, uh, SameSite cookies - it already existed in Symfony since 3.2. 00:05:53.336 --> 00:06:00.796 align:middle So, this is not news for a lot of you, um, and since 4.2, there was 3.2 is already 00:06:00.796 --> 00:06:05.226 align:middle from two years ago and 4.2, it also added support for that 00:06:05.306 --> 00:06:07.136 align:middle for session and "remember me" cookies. 00:06:07.946 --> 00:06:11.976 align:middle And the SameSite cookies for those of you who don't know, basically it's a way 00:06:11.976 --> 00:06:15.616 align:middle to prevent a cross site request forgery. 00:06:16.236 --> 00:06:20.776 align:middle And, uh, basically the way that it works is that if you put it too strict, uh, 00:06:20.776 --> 00:06:22.866 align:middle the cookie won't be sent if the request is cross site. 00:06:23.016 --> 00:06:26.286 align:middle So, if you are on a different website and you'll make, um, yeah, 00:06:26.286 --> 00:06:31.466 align:middle you click a link to your website, the cookies want to be sent with that request. 00:06:32.536 --> 00:06:38.746 align:middle Um, but because that will be really unfriendly in some cases, uh, you also have the Lax 00:06:38.786 --> 00:06:43.606 align:middle which allows the cookie to be sent if this is considered a safe request and it's safe request 00:06:43.606 --> 00:06:49.876 align:middle in this case is mostly a GET request, or any "read" request that is a top level navigation 00:06:49.876 --> 00:06:54.566 align:middle so that when you are on Gmail, for instance, and you click on the Twitter link, 00:06:54.896 --> 00:07:00.076 align:middle you stay logged in because, uh, if even if they use the SameSite, if it is Lax - 00:07:00.306 --> 00:07:02.316 align:middle than your cookies will also be sent. 00:07:03.936 --> 00:07:09.086 align:middle But, in PHP, this is the current signature of the setcookie() function. 00:07:10.206 --> 00:07:13.436 align:middle And so we wanted to add one more - SameSite. 00:07:14.446 --> 00:07:15.346 align:middle Can I join you guys? 00:07:15.746 --> 00:07:17.116 align:middle And the guy said: No! 00:07:17.956 --> 00:07:22.726 align:middle So we had to come up with the, with the alternative syntax for this because this was, 00:07:22.726 --> 00:07:24.736 align:middle this went to vote and it was rejected. 00:07:25.236 --> 00:07:30.386 align:middle And so, the solution that ended up coming forward was this one of setting the cookie 00:07:30.996 --> 00:07:33.766 align:middle and you get the name, the value, and then an array of options. 00:07:33.876 --> 00:07:37.746 align:middle And the array of options is of course, all the other options, so $expires, $path, $domain, 00:07:37.746 --> 00:07:40.866 align:middle $secure, $httponly and $samesite. 00:07:41.516 --> 00:07:44.826 align:middle More on 7.3. 00:07:44.826 --> 00:07:48.236 align:middle In this case, so, we have a while($foo), switch($bar), 00:07:48.546 --> 00:07:50.636 align:middle case "baz", and then we have a continue. 00:07:51.446 --> 00:07:54.596 align:middle Who here thinks that the continue will continues the while(). 00:07:54.596 --> 00:07:58.686 align:middle Who thinks it will continue the switch()? 00:08:00.276 --> 00:08:04.876 align:middle Okay. Well, that was not a lot of confusion but in case it is confusing 00:08:04.956 --> 00:08:06.436 align:middle because it can be confusing to some people. 00:08:06.906 --> 00:08:09.536 align:middle Now it will throw also a warning letting you know of that, 00:08:09.926 --> 00:08:14.826 align:middle that the continuous the switch() is just a break and it asks you if you wanted to, 00:08:14.906 --> 00:08:19.546 align:middle if you meant continue to because then you, as with continue and with break, 00:08:19.546 --> 00:08:22.156 align:middle you can add the number to say the number of loops that you want 00:08:22.156 --> 00:08:26.596 align:middle to break out of or continue from. 00:08:27.266 --> 00:08:30.806 align:middle Another thing also in reflection, in errors, uh, 00:08:30.806 --> 00:08:33.726 align:middle you would see before you would see integer and boolean. 00:08:33.816 --> 00:08:35.426 align:middle But that's not really what you typed down. 00:08:35.736 --> 00:08:39.016 align:middle So now it's, it matches what you use as well. 00:08:39.016 --> 00:08:42.876 align:middle So, now they are always called int and bool, which is nice. 00:08:43.826 --> 00:08:48.136 align:middle Then we have a new password hashing algorithm if you build it with the, 00:08:48.136 --> 00:08:51.506 align:middle with the password Argon, with the lib... 00:08:51.506 --> 00:08:52.506 align:middle Argon library. 00:08:52.656 --> 00:08:55.326 align:middle Then you can also use now the PASSWORD_ARGON2ID. 00:08:56.946 --> 00:08:59.936 align:middle Um, in FPM, there are also some changes. 00:09:00.106 --> 00:09:07.726 align:middle The entire logging of FPM was refactored and right now you can set the log limit variable 00:09:07.726 --> 00:09:12.476 align:middle to define what will be the maximum length of a line on the log, um, 00:09:12.526 --> 00:09:17.086 align:middle which prevents some before you could lose some information because of, 00:09:17.086 --> 00:09:18.526 align:middle because of the line that was too big. 00:09:18.906 --> 00:09:20.876 align:middle And right now this solves that problem. 00:09:21.336 --> 00:09:25.716 align:middle And also it allows you now to not decorate the workers outputs 00:09:25.906 --> 00:09:30.626 align:middle because PHP would also always add some information to the, to the output of the workers 00:09:30.896 --> 00:09:33.536 align:middle and now you can actually specify that you don't want that. 00:09:34.636 --> 00:09:40.506 align:middle Um, besides that, also FPM finally got the getallheaders() supports, which is basically 00:09:40.506 --> 00:09:45.416 align:middle to give you all the requests heathers and well, it didn't work in FPM. 00:09:46.906 --> 00:09:52.746 align:middle Then, another interesting one is the hrtime(), which is the highest resolution monotonic clock 00:09:53.046 --> 00:09:57.706 align:middle and the monotonic clock, basically, it's a clock that's always goes in the same direction. 00:09:57.976 --> 00:10:03.346 align:middle That is a guarantee so that it's not affected by a daylight saving and stuff like that. 00:10:03.386 --> 00:10:05.526 align:middle It will always, always, always goes forwards. 00:10:06.006 --> 00:10:09.816 align:middle Um, and it starts at the unspecified point in time, in the past. 00:10:10.496 --> 00:10:13.336 align:middle It's not important, it's just that you can measure it twice 00:10:13.396 --> 00:10:18.666 align:middle and we will get the most precise difference between those two times possible. 00:10:19.186 --> 00:10:22.276 align:middle So this is really useful also to measure stuff, of course. 00:10:22.816 --> 00:10:29.676 align:middle And of course there are a lot of bug fixes and performance improvements and stuff like that. 00:10:29.676 --> 00:10:30.716 align:middle But who cares? 00:10:31.636 --> 00:10:34.496 align:middle I'm, this is the truth. 00:10:34.646 --> 00:10:38.246 align:middle And sometimes it's also the truth for contributors, like, ah, yeah, 00:10:38.246 --> 00:10:41.246 align:middle I want to do something new and shiny, but yeah. 00:10:41.866 --> 00:10:45.916 align:middle So, but this is mostly what I have to say about a 7.3. 00:10:46.616 --> 00:10:50.376 align:middle About 7.4 which is coming one year from now. 00:10:50.376 --> 00:10:54.046 align:middle So holds, you have to sit down a little bit to wait for that. 00:10:54.186 --> 00:10:58.066 align:middle But, uh, there it is already showing a lot of very interesting stuff. 00:10:58.896 --> 00:11:01.836 align:middle The first one that I would like to talk to talk about is about the preload, 00:11:02.146 --> 00:11:05.956 align:middle which is already accepted and it's already merged in the master. 00:11:06.586 --> 00:11:12.626 align:middle Um, and it was developed by Dmitry Stogov and to quote what he said 00:11:12.626 --> 00:11:13.936 align:middle because I think it's a good definition. 00:11:14.536 --> 00:11:19.276 align:middle So on service startup, before any application code is run, we may load the certain set 00:11:19.276 --> 00:11:24.386 align:middle of PHP files into memory and make their contents permanently available to all subsequent requests 00:11:24.646 --> 00:11:28.106 align:middle that will be served by that server or the functions in classes defined 00:11:28.106 --> 00:11:33.116 align:middle on these files will be available to requests out of the box exactly like internal entities. 00:11:33.756 --> 00:11:36.116 align:middle By example, the string length or, or the exception class. 00:11:36.416 --> 00:11:37.696 align:middle And what does this mean exactly? 00:11:37.696 --> 00:11:44.276 align:middle So, currently, on 7.3, um, so PHP starts and the first request comes. 00:11:45.096 --> 00:11:49.556 align:middle And I imagine that on your index.php where your, your requests are arriving, 00:11:49.816 --> 00:11:55.786 align:middle you do a new A. These will trigger the autoloader because it doesn't know about it yet. 00:11:55.976 --> 00:11:58.876 align:middle So it will trigger autoloader: Hey, what, what is A? 00:11:59.116 --> 00:12:00.846 align:middle And your autoloader imagined 00:12:00.846 --> 00:12:06.556 align:middle that it is composer's autoloader a will then find that file and include it. 00:12:07.126 --> 00:12:12.846 align:middle The file is compiled into OP codes and those OP codes are stored in the OPcache. 00:12:13.526 --> 00:12:21.646 align:middle And after that it will run the constructor of A on the subsequent requests you do new A again. 00:12:21.936 --> 00:12:28.576 align:middle It will again triggered the autoloader, it will, um, the autoloader will include A.php 00:12:28.706 --> 00:12:32.046 align:middle but this time we don't need to compile it anymore because it's already on OPcache. 00:12:32.296 --> 00:12:36.576 align:middle So now we load the OP codes from OPcache and we run the constructor. 00:12:37.146 --> 00:12:40.046 align:middle On 7.4 with preloads. 00:12:40.476 --> 00:12:44.726 align:middle So we, when we start PHP, we can pass these, uh, these setting, 00:12:44.726 --> 00:12:49.796 align:middle or we can have this ini setting saying opcache.preload and the file in this case, so, 00:12:49.886 --> 00:12:53.046 align:middle for this example, I'm just preloading A.php directly. 00:12:53.356 --> 00:12:55.316 align:middle Typically, it would preload the file, 00:12:55.566 --> 00:12:58.386 align:middle that would include all the other files that you want to preload. 00:12:58.656 --> 00:13:02.066 align:middle You can only specify one file and then that file is responsible 00:13:02.246 --> 00:13:04.476 align:middle for preloading the rest of what you want. 00:13:04.606 --> 00:13:09.866 align:middle But in this case, for the sake of simplicity, let's say that we just preload A.php, 00:13:10.566 --> 00:13:14.536 align:middle and at this point A.php is compiled and it's in memory. 00:13:14.866 --> 00:13:19.176 align:middle So for the first request, when you do new A, it runs A, um, 00:13:19.176 --> 00:13:22.106 align:middle A constructor because it already knows what it is. 00:13:22.106 --> 00:13:23.916 align:middle It already, it's already loaded in memory. 00:13:24.406 --> 00:13:26.756 align:middle It doesn't need to hit OPcache at all. 00:13:27.196 --> 00:13:32.156 align:middle So, yeah, all the requests are now immediately... 00:13:32.246 --> 00:13:34.586 align:middle you don't have these intermediate steps. 00:13:35.156 --> 00:13:38.726 align:middle This, of course, there're the downsides, uh, all the files that are preloaded, 00:13:39.086 --> 00:13:42.916 align:middle if you want to change something in them, uh, you need to restart PHP. 00:13:42.916 --> 00:13:45.266 align:middle So, there is no way to invalidate these files. 00:13:45.846 --> 00:13:51.126 align:middle The only way to change them is by restarting PHP. 00:13:52.836 --> 00:13:57.146 align:middle Then, typed properties, finally. 00:13:57.666 --> 00:13:59.976 align:middle Um, so yeah, it, it's happening. 00:14:00.236 --> 00:14:03.626 align:middle I'm sorry if you're having a recruiter speak flashbacks. 00:14:04.336 --> 00:14:06.026 align:middle Um, but yeah. 00:14:06.096 --> 00:14:06.826 align:middle So, it's happening. 00:14:06.826 --> 00:14:08.776 align:middle It's going to be on 7.4. 00:14:09.256 --> 00:14:14.766 align:middle Um, and some, some interesting things, so, object types, uh, 00:14:15.126 --> 00:14:18.886 align:middle cannot have a default value unless they are nullable and indicates 00:14:18.986 --> 00:14:22.716 align:middle that they are nullable then you can use null as a default, 00:14:22.806 --> 00:14:28.316 align:middle but you cannot set a default values for, for thing, for properties that are 00:14:28.316 --> 00:14:32.016 align:middle of a specific class and they will not be null. 00:14:32.536 --> 00:14:36.526 align:middle They will be undefined if you don't define them in your constructor. 00:14:36.936 --> 00:14:42.316 align:middle So we have a new states for, for properties which will be undefined, 00:14:42.646 --> 00:14:47.336 align:middle which you shouldn't really encounter if, if you ever encountered undefined is 00:14:47.336 --> 00:14:50.366 align:middle because someone forgot to set the property on your constructor. 00:14:50.686 --> 00:14:53.786 align:middle It shouldn't happen, but, it, uh, it is there. 00:14:53.786 --> 00:14:57.666 align:middle And, currently this is still being discussed. 00:14:57.706 --> 00:15:00.476 align:middle Uh, but this one was already voted, was already accepted. 00:15:00.586 --> 00:15:05.416 align:middle It's not merged yet because they are still struggling with some implementation details. 00:15:05.766 --> 00:15:08.506 align:middle And the other one, it's currently on discussion. 00:15:08.506 --> 00:15:11.346 align:middle So this one I cannot tell you that it will happen for sure, 00:15:11.346 --> 00:15:14.256 align:middle but I'm pretty confident it will, which is about variance. 00:15:14.856 --> 00:15:19.086 align:middle So in this case, so we imagined that we have a class A, grandparents 00:15:19.086 --> 00:15:21.236 align:middle and then we have a class B which is the parents. 00:15:21.236 --> 00:15:23.176 align:middle And then we have a class C which is the child. 00:15:24.246 --> 00:15:28.446 align:middle And then we define an interface and that interface receives a B, 00:15:28.696 --> 00:15:35.476 align:middle and it returns a B. We can now, well with variance, we can extend these interface 00:15:35.816 --> 00:15:42.626 align:middle and we can use a contravariance on the, on the, on the, on the parameter types, 00:15:43.216 --> 00:15:46.586 align:middle which means to go up one or multiple levels, so... 00:15:47.386 --> 00:15:50.366 align:middle and, uh, for the return type you can go down. 00:15:50.366 --> 00:15:51.576 align:middle So that's covariance. 00:15:51.936 --> 00:15:54.216 align:middle And, basically, these does not break the, 00:15:54.216 --> 00:15:59.516 align:middle it does not violate the Liskov substitution principle because currently you could already, 00:15:59.516 --> 00:16:03.706 align:middle even just when you have the type hint and on the child, you could just remove the type hint. 00:16:04.246 --> 00:16:08.666 align:middle But this is now more complete, so it will actually, like if your parents can deal 00:16:08.666 --> 00:16:12.536 align:middle with the B, then your child can deal with something that is greater than a B 00:16:12.956 --> 00:16:18.646 align:middle and then can deal with it as the same way that if your parents returns a B, 00:16:19.306 --> 00:16:24.706 align:middle it's safe for the child to return to the C because the C is also a B. So it never breaks, 00:16:24.706 --> 00:16:27.826 align:middle it never violates the Liskov substitution principle. 00:16:29.876 --> 00:16:36.176 align:middle Okay. So for 8.0, um, there is already a change. 00:16:36.176 --> 00:16:42.226 align:middle So I said that, uh, the RFC, um, I have an RFC that was accepted for 8.0 00:16:42.496 --> 00:16:44.756 align:middle and it's very simple, but it's basically about this. 00:16:44.756 --> 00:16:49.056 align:middle So if we have an array with the, with this initial structure, 00:16:49.056 --> 00:16:54.896 align:middle and then we add one more element to this array, uh, what will be the index of these new element. 00:16:57.676 --> 00:16:59.036 align:middle You wish, but it's not. 00:16:59.226 --> 00:16:59.916 align:middle Currently, it's not. 00:17:00.506 --> 00:17:05.076 align:middle So, as the documentation says: If no key is specified the maximum 00:17:05.076 --> 00:17:09.086 align:middle of the existing integer indexes, uh, is taken and the new key will be 00:17:09.086 --> 00:17:12.876 align:middle that maximum value plus one, but at least zero. 00:17:13.436 --> 00:17:19.986 align:middle And I really, really, really disliked this and so I got rid of that part. 00:17:20.206 --> 00:17:25.436 align:middle So, on 8.0, uh, it will be minus 41 while currently it's still zero. 00:17:25.736 --> 00:17:32.046 align:middle And because this may bring some, uh, yeah, BC breaks, um, this was, uh, 00:17:32.186 --> 00:17:35.956 align:middle this was a slate that for, for a new major version. 00:17:36.866 --> 00:17:40.486 align:middle But for the rest of 8.0, um... 00:17:41.056 --> 00:17:50.306 align:middle OK, I have to switch modes. 00:17:50.976 --> 00:17:57.496 align:middle Well, I want you to contribute to, to PHP and to help shape up 8.0. 00:17:57.496 --> 00:18:00.476 align:middle So now it's really the right time to do that. 00:18:00.476 --> 00:18:08.606 align:middle 7.4 still being developed so you can still introduce new deprecations for 7.4 for things 00:18:08.606 --> 00:18:11.276 align:middle that you really wanted to change on 8.0. 00:18:11.666 --> 00:18:13.216 align:middle So now it's a good time to do that. 00:18:13.816 --> 00:18:19.496 align:middle And so, let's talk a little bit about how you change PHP, about the verb part of it. 00:18:20.546 --> 00:18:25.096 align:middle Um, but first I'm going to tell you a little bit my first, about my first contribution 00:18:25.166 --> 00:18:27.446 align:middle and tell you a little bit the story about my first contribution. 00:18:28.016 --> 00:18:30.826 align:middle Um, and it was like these. 00:18:30.826 --> 00:18:36.606 align:middle So, one afternoon, in an office somewhere, uh, we were having a security scan, um, 00:18:36.606 --> 00:18:39.206 align:middle and certain requests were hanging on certain conditions. 00:18:39.976 --> 00:18:45.306 align:middle Um, and basically it boiled down to the fact that the text protocol 00:18:45.306 --> 00:18:49.656 align:middle of Memcached cannot really handle new lines in the keys properly. 00:18:50.526 --> 00:18:54.916 align:middle Um, and yeah, because it would hang or it would even allow injection. 00:18:54.916 --> 00:18:57.806 align:middle So this is actually, this was an, uh, 00:18:57.806 --> 00:19:02.896 align:middle an injection for Memcached was possible to, to abuse these, to get that. 00:19:03.156 --> 00:19:05.616 align:middle And this was easy to fix on our side, right? 00:19:06.076 --> 00:19:09.386 align:middle So just, okay, don't accept new lines in the keys. 00:19:10.116 --> 00:19:14.286 align:middle Uh, but yeah, I started wondering like why, why does PHP let these through? 00:19:14.406 --> 00:19:16.586 align:middle What, what, yeah, why would they do that? 00:19:17.726 --> 00:19:23.216 align:middle Um, and so, luckily in the PHP world, we are in the world of free software 00:19:23.606 --> 00:19:29.026 align:middle and two of these freedoms specify that you are free to study how the program works 00:19:29.206 --> 00:19:32.356 align:middle and change it so it does your computing as you wish. 00:19:32.706 --> 00:19:37.916 align:middle And I wish Memcached to not be vulnerable to injection and then the freedom 00:19:37.916 --> 00:19:40.366 align:middle to distribute copies of your modified versions to others. 00:19:40.366 --> 00:19:44.326 align:middle By doing this you can give the whole community a chance to benefit from your changes. 00:19:44.796 --> 00:19:47.536 align:middle Well, so let's, let's try to get that for everyone. 00:19:48.066 --> 00:19:52.326 align:middle And so I started looking at the code of the PHP Memcached extension 00:19:52.756 --> 00:19:58.316 align:middle and I was positively surprised to figure out that, well it's not rocket surgery. 00:19:58.316 --> 00:19:59.146 align:middle It's not that hard. 00:19:59.686 --> 00:20:04.006 align:middle And the change in the end, in terms of code, ended up being just these 00:20:04.006 --> 00:20:09.796 align:middle and maybe it's not very well visible, but I think that this is reasonable for anyone. 00:20:09.876 --> 00:20:11.746 align:middle This is not very complicated. 00:20:12.286 --> 00:20:16.586 align:middle It's C, it's a little bit, syntax is a little bit different from a PHP, but in this case, 00:20:16.586 --> 00:20:23.816 align:middle not even that much and this was all that was needed to, to cover that, to cover that hole. 00:20:24.056 --> 00:20:28.246 align:middle So then, um, well now what do I do with this? 00:20:28.586 --> 00:20:33.096 align:middle Uh, I emailed the security@php.net because this is a security concern 00:20:33.216 --> 00:20:36.126 align:middle and they told me, yeah, just open a pull request. 00:20:36.436 --> 00:20:41.326 align:middle Don't mention that it is about security, just open a pull request and uh, 00:20:41.326 --> 00:20:43.206 align:middle and we will merge it eventually our. 00:20:43.206 --> 00:20:43.996 align:middle Okay, sounds good. 00:20:44.356 --> 00:20:51.206 align:middle So I did, I opened the pull request, and it got merged, and since PHP Memcached 3.0.0, 00:20:51.576 --> 00:20:53.946 align:middle that's the problem no longer occurs. 00:20:54.266 --> 00:20:54.966 align:middle So, that's nice. 00:20:55.116 --> 00:20:58.686 align:middle So it's no longer vulnerable to at least this type of injection. 00:21:00.036 --> 00:21:03.936 align:middle Then about your first contribution. 00:21:04.076 --> 00:21:10.026 align:middle First, I wanted to know, did anyone of you already contribute to PHP anything in any way? 00:21:12.156 --> 00:21:13.256 align:middle Maybe you did, but. 00:21:13.536 --> 00:21:17.856 align:middle Okay. So, let's, uh, first things first. 00:21:18.696 --> 00:21:21.296 align:middle Subscribing to the mailing list is pretty much essential. 00:21:21.296 --> 00:21:23.636 align:middle So this is where all the discussions about PHP happen. 00:21:24.206 --> 00:21:27.576 align:middle Uh, this is where the RFCs are presented. 00:21:27.576 --> 00:21:30.206 align:middle This is, uh, yeah, where a lot of these discussions happen. 00:21:30.526 --> 00:21:34.046 align:middle This is also a nice place to get help if you're trying to fix a bug 00:21:34.046 --> 00:21:38.806 align:middle and you cannot figure a step out, you can always mail internals 00:21:39.156 --> 00:21:40.606 align:middle and there is these very nice website, 00:21:40.676 --> 00:21:45.566 align:middle externals.io that basically just exposes the internals to the outside. 00:21:45.566 --> 00:21:47.516 align:middle Is a nice way to read the mailing lists. 00:21:47.516 --> 00:21:52.456 align:middle It does the whole treating thing and yeah, it's, it's very nice to, to read there. 00:21:52.866 --> 00:21:58.816 align:middle But you can always subscribe to the mailing list on php.net/mailing-lists.php. 00:21:58.816 --> 00:22:02.696 align:middle So this is, for me, it's a good first step. 00:22:04.046 --> 00:22:06.866 align:middle Then, helping with the documentation. 00:22:07.206 --> 00:22:12.416 align:middle Sometimes there is ambiguous language that should be fixed or updated documentation 00:22:12.836 --> 00:22:15.396 align:middle or you can help with translations to your own language. 00:22:15.396 --> 00:22:22.006 align:middle If it's not english and it's missing something and you can visit edit.php.net, 00:22:22.486 --> 00:22:27.676 align:middle and it gives you this fancy interface with the facebook like button 00:22:27.676 --> 00:22:32.256 align:middle where you can actually edit the documentation there and you can submit your patch to review 00:22:32.916 --> 00:22:39.466 align:middle and then anyone with a php.net account, if they find that this makes sense, they can merge it. 00:22:39.846 --> 00:22:43.076 align:middle And then the website is a rebuilt every 24 hours. 00:22:43.186 --> 00:22:46.046 align:middle So it might take a while, but eventually your change will be there. 00:22:46.616 --> 00:22:50.706 align:middle There is talks of possibly migrating these to GitHub, which would make sense 00:22:50.706 --> 00:22:52.166 align:middle and make things a little bit easier. 00:22:52.526 --> 00:22:54.846 align:middle But on the other hand here you can also do it anonymously. 00:22:54.846 --> 00:22:56.406 align:middle So we'll see. 00:22:56.486 --> 00:22:58.126 align:middle We'll see what will happen with that. 00:22:59.736 --> 00:23:02.316 align:middle Then - reporting bugs. 00:23:03.226 --> 00:23:05.986 align:middle So, we do have bugs.php.net. 00:23:06.656 --> 00:23:12.196 align:middle Um, and yeah, as with any bug reporting, 00:23:12.646 --> 00:23:16.056 align:middle you should try to always provide the minimum reproducing code. 00:23:16.226 --> 00:23:19.796 align:middle So, okay, this is all you have to do to have this problem. 00:23:19.796 --> 00:23:26.336 align:middle Any other useful information and of course what you expect versus what you actually got. 00:23:26.966 --> 00:23:31.276 align:middle And in this case it's a, it was a bug reported by Nicolas, 00:23:31.626 --> 00:23:33.686 align:middle caused by me and fixed by me as well. 00:23:34.846 --> 00:23:35.486 align:middle So that was nice. 00:23:36.716 --> 00:23:44.346 align:middle Then, um, you can also answer bug reports provided that you have an email address or not. 00:23:44.346 --> 00:23:48.166 align:middle Maybe you don't really that and that you have some basic mathematic skills - 00:23:48.856 --> 00:23:51.216 align:middle you can solve that problem you can contribute. 00:23:51.806 --> 00:23:57.086 align:middle Um, and yeah, I mean sometimes you just know how to reproduce it with less codes. 00:23:57.396 --> 00:24:00.426 align:middle Sometimes you just, you see that the person 00:24:00.426 --> 00:24:02.956 align:middle that posted the question is not giving you enough information, 00:24:02.956 --> 00:24:07.436 align:middle is not giving anyone enough information so you can tell: Hey, can you, please, be more specific 00:24:07.436 --> 00:24:10.026 align:middle or anyone can, can help with this. 00:24:10.026 --> 00:24:12.966 align:middle So replying to bugs is all, so really, really nice. 00:24:13.946 --> 00:24:20.716 align:middle Um, and then who's doing it here, also doing it on StackOverflow, answering people 00:24:21.066 --> 00:24:23.776 align:middle or on a, on the chat of StackOverflow. 00:24:24.426 --> 00:24:26.056 align:middle Um, those are good. 00:24:26.216 --> 00:24:28.036 align:middle Those are good places to help out as well. 00:24:28.646 --> 00:24:31.786 align:middle And then about fixing the bugs themselves. 00:24:32.166 --> 00:24:33.716 align:middle So, PHP is on GitHub. 00:24:34.886 --> 00:24:36.086 align:middle It's a, it, it's true. 00:24:36.086 --> 00:24:38.466 align:middle it's a mirror of git.php.net. 00:24:38.466 --> 00:24:43.456 align:middle But it has pull requests, you can just do your change, open a pull request, 00:24:43.806 --> 00:24:47.626 align:middle like with any other project and the change can be merged. 00:24:48.146 --> 00:24:50.646 align:middle So, yeah, it's pretty simple to start off. 00:24:51.466 --> 00:24:56.816 align:middle Um, to help you with the, with your diving into the PHP source. 00:24:57.346 --> 00:25:00.286 align:middle Um, there are some helpful tools. 00:25:01.156 --> 00:25:08.496 align:middle One of them is LXR, which is a way to look at the code a little bit like an advanced idea 00:25:08.496 --> 00:25:12.876 align:middle because you can click on anything and it will take you to that function. 00:25:12.876 --> 00:25:18.186 align:middle And yeah, you can see that one on the room11.org, lxr.room11.org. 00:25:18.816 --> 00:25:27.816 align:middle Um, Room11 is the PHP room on the StackOverflow chat and a lot of PHP maintainers 00:25:27.816 --> 00:25:30.096 align:middle or contributors are also their daily. 00:25:30.656 --> 00:25:32.986 align:middle Uh, so it's also a nice place if you're trying to dig in 00:25:33.386 --> 00:25:37.106 align:middle and you don't, um, yeah, you need some help. 00:25:37.376 --> 00:25:39.006 align:middle It's a good place also to find that help. 00:25:40.766 --> 00:25:45.776 align:middle Then, you also have 3v4l.org, uh, which is really, really, really great. 00:25:46.056 --> 00:25:50.806 align:middle It's a, yeah, it's a website where you can run a snippet of code and it will run it 00:25:50.806 --> 00:25:58.106 align:middle on 200 plus PHP and HHVM versions so you can see exactly when a behavior was changed 00:25:58.546 --> 00:26:00.286 align:middle in which versions did that happen. 00:26:01.076 --> 00:26:06.846 align:middle Um, and the shout out to Sjon for, for making this and making it available. 00:26:07.956 --> 00:26:13.946 align:middle Then, you also have wiki.php.net, which has a lot of useful resources if you want to dig in. 00:26:14.436 --> 00:26:17.626 align:middle Uh, so yeah, so is a recommended reading. 00:26:17.676 --> 00:26:22.156 align:middle It has some things that are a little bit outdated, but yeah, you will always be able 00:26:22.156 --> 00:26:24.906 align:middle to find the interesting documentation there. 00:26:25.226 --> 00:26:29.706 align:middle And also on the, on the, on the repository of PHP source itself. 00:26:30.066 --> 00:26:33.726 align:middle It also has the contributing file and it also has some nice information 00:26:34.366 --> 00:26:40.616 align:middle and from these I would say to use your favorite editor to avoid any religious wars. 00:26:41.496 --> 00:26:42.096 align:middle I did this. 00:26:42.726 --> 00:26:47.226 align:middle Um, so yeah, just use your favorite editor as long, in my opinion, 00:26:47.226 --> 00:26:52.216 align:middle as long as you can debug properly with it, uh, feel free to choose whatever you want to use. 00:26:55.396 --> 00:26:56.956 align:middle Then, writing tests. 00:26:57.276 --> 00:26:59.326 align:middle So, PHP tests look like this. 00:26:59.436 --> 00:27:01.006 align:middle This is a .phpt file. 00:27:01.646 --> 00:27:04.186 align:middle Um, they have a pretty simple structure. 00:27:04.696 --> 00:27:10.376 align:middle So, basically, here we see it is, it has the test name, the script itself, 00:27:10.376 --> 00:27:12.406 align:middle what it will do and what it expects. 00:27:13.046 --> 00:27:13.616 align:middle It's all good. 00:27:13.806 --> 00:27:19.146 align:middle It will pass if the, what expects is not there, uh, it will fail. 00:27:19.376 --> 00:27:21.706 align:middle You have another, you have a bunch of other sections. 00:27:21.706 --> 00:27:25.596 align:middle You can have EXPECTF instead of expects to define it in a format. 00:27:26.366 --> 00:27:30.206 align:middle You can have INI to change some INI setting specific for this test. 00:27:30.736 --> 00:27:34.526 align:middle Uh, you can have a SKIPIF so to, to run a little snippet. 00:27:34.526 --> 00:27:38.326 align:middle And if, uh, if the output is "skip" - then the test is skipped 00:27:38.706 --> 00:27:41.286 align:middle because the extension is not there or for whatever reason. 00:27:41.956 --> 00:27:47.096 align:middle And then you can run the entire test suits if you run... 00:27:47.256 --> 00:27:53.626 align:middle make tests on the repository or if you want to only test a specific test or a bunch 00:27:53.626 --> 00:27:55.166 align:middle of tests that are related to each other. 00:27:55.496 --> 00:28:00.216 align:middle You can also use the run tests, um, well make test uses run tests, 00:28:00.216 --> 00:28:04.086 align:middle but then you can use run tests directly to specify that you will only want 00:28:04.086 --> 00:28:09.346 align:middle to run a certain type of or certain tests. 00:28:10.996 --> 00:28:14.086 align:middle Then, proposing changes. 00:28:14.086 --> 00:28:16.176 align:middle So this is the RFC process. 00:28:16.386 --> 00:28:18.656 align:middle RFC stands for request for comments. 00:28:19.176 --> 00:28:24.306 align:middle Um, and yeah, your approach should go a little bit like this. 00:28:24.306 --> 00:28:28.286 align:middle So the first thing to do is to check what happened the last time that this was discussed. 00:28:28.286 --> 00:28:30.766 align:middle PHP is a pretty large project. 00:28:30.886 --> 00:28:35.516 align:middle It has been around for a lot of years and most likely what you are thinking about, 00:28:35.516 --> 00:28:39.716 align:middle somebody's already thought about and maybe it was already discussed. 00:28:39.716 --> 00:28:42.596 align:middle So that's always a good starting point is to figure out: Okay, 00:28:42.656 --> 00:28:46.346 align:middle what happened the last time that someone brought this up? 00:28:46.346 --> 00:28:48.656 align:middle Then, if you're convinced, okay, nobody really, 00:28:48.656 --> 00:28:53.256 align:middle nobody talked about these are the reasons why they rejected it before are not valid anymore. 00:28:53.936 --> 00:28:57.666 align:middle Uh, you should email internals and introducing your proposal and listening 00:28:57.666 --> 00:29:03.586 align:middle to feedback a little bit like this first phase of, uh, of feedback and actively listen 00:29:03.586 --> 00:29:06.126 align:middle to the feedback and try to adjust your proposal to that. 00:29:06.986 --> 00:29:12.326 align:middle Then, uh, you can write the RFC itself on the wiki 00:29:12.516 --> 00:29:15.416 align:middle and it will produce a fancy document looking like this. 00:29:16.136 --> 00:29:20.246 align:middle Um, and yeah, and here you should really detail everything that has to be said 00:29:20.246 --> 00:29:26.626 align:middle about the proposal, like a feature, uh, what, what if it has any, uh, BC breaks. 00:29:27.036 --> 00:29:31.366 align:middle If it, if it has any future scope, like in the future we could also do this, 00:29:31.366 --> 00:29:33.696 align:middle this and that, the proposal itself. 00:29:34.056 --> 00:29:41.916 align:middle So, yeah. Um, and then, uh, preferably, this is not mandatory, 00:29:41.916 --> 00:29:44.456 align:middle but preferably you would also implement our proposal. 00:29:45.206 --> 00:29:47.976 align:middle Uh, but this is, as I said, it's not mandatory. 00:29:48.186 --> 00:29:53.576 align:middle It happens sometimes people propose things even if they cannot implement it. 00:29:54.036 --> 00:29:58.556 align:middle Um, and then someone else will pick up the implementation, most of the times. 00:29:59.246 --> 00:30:06.236 align:middle Um, versus the SameSite cookie - a thing that I talked before, it was proposed by someone else, 00:30:06.506 --> 00:30:10.106 align:middle but then they couldn't come up with a, with a implementation and I ended up, 00:30:10.106 --> 00:30:12.716 align:middle I ended up implementing that myself. 00:30:12.916 --> 00:30:15.036 align:middle That with the options, a rare. 00:30:15.916 --> 00:30:21.726 align:middle Um, then, you should start your discussion period, which should be at least for two weeks. 00:30:22.106 --> 00:30:28.306 align:middle And, uh, well listen again to feedback, change things that have to be changed or fight people 00:30:28.306 --> 00:30:31.406 align:middle until they said that, they say that it's not needed to change anymore. 00:30:32.096 --> 00:30:35.466 align:middle Um, and then you can start the voting period. 00:30:36.126 --> 00:30:38.666 align:middle The voting period should also last for at least two weeks. 00:30:39.326 --> 00:30:43.136 align:middle Um, people go to the wiki and they can vote on it. 00:30:43.556 --> 00:30:47.486 align:middle Uh, you can, uh, you don't need to have a php.net account to vote. 00:30:47.856 --> 00:30:52.946 align:middle You just need to have a wiki account to vote and some people that are not directly contributors 00:30:52.946 --> 00:31:00.296 align:middle to PHP versus Fabien has, has the, um, the possibility to vote on the, on the RFCs. 00:31:00.906 --> 00:31:05.306 align:middle So, if it is accepted, the PR gets merged into, into PHP. 00:31:05.436 --> 00:31:08.916 align:middle And that's pretty much it. 00:31:09.136 --> 00:31:14.666 align:middle Um, I would appreciate any feedback that you have about the talk in that JoindIn a link 00:31:15.226 --> 00:31:17.716 align:middle and a, yup, I would take questions. 00:31:17.846 --> 00:31:19.506 align:middle Does anyone have any questions? 00:31:20.806 --> 00:31:30.796 align:middle Uh, they will start at 0 if you don't say anything. 00:31:30.796 --> 00:31:33.486 align:middle They will start at 0 anyway. 00:31:33.696 --> 00:31:37.956 align:middle Uh, this will only change if for the first keys that you use are negative, right? 00:31:37.956 --> 00:31:38.806 align:middle No, sorry. 00:31:38.806 --> 00:31:43.516 align:middle Okay. Yeah, that's why we'll wait for a major version. 00:31:43.516 --> 00:31:58.926 align:middle Right? So, instead of like I propose these initially for 7.2 I think yet, 00:31:59.696 --> 00:32:02.086 align:middle and they're like: Oh, of course not. 00:32:02.446 --> 00:32:04.676 align:middle It's not an a minor. 00:32:04.676 --> 00:32:05.686 align:middle Are you crazy? 00:32:05.826 --> 00:32:06.666 align:middle Oh, hey, sorry. 00:32:06.756 --> 00:32:10.806 align:middle Uh, then, well, then I do it in a major. 00:32:10.806 --> 00:32:12.116 align:middle Is that fine? 00:32:12.116 --> 00:32:15.886 align:middle Yeah, on a major is fine, okay. 00:32:15.886 --> 00:32:17.506 align:middle Then I'll do it in a major. 00:32:17.876 --> 00:32:22.496 align:middle So, yeah, so that's basically the reason why we will wait for 8.0 to do this change. 00:32:22.786 --> 00:32:26.826 align:middle Because, yeah, it might break some things, or some people if they write code, 00:32:26.996 --> 00:32:31.056 align:middle like if you write code, if you're using implicit keys to add things to the array 00:32:31.276 --> 00:32:35.786 align:middle and then you use an explicit key to access it - you're probably doing something wrong. 00:32:35.786 --> 00:32:38.766 align:middle Right? I mean if you don't care about the keys, you don't care about the keys. 00:32:38.986 --> 00:32:41.286 align:middle Or either you care or you don't. 00:32:41.686 --> 00:32:42.326 align:middle Make a choice. 00:32:42.726 --> 00:32:43.906 align:middle But, yeah. 00:32:44.006 --> 00:32:44.766 align:middle Anything else? 00:32:52.486 --> 00:32:53.406 align:middle Yup. I shouldn't say. 00:32:53.656 --> 00:32:58.606 align:middle Come on, I did all the effort to not say, but okay, I use the VS code. 00:32:59.516 --> 00:33:01.076 align:middle Uh, and it works really well for me. 00:33:01.446 --> 00:33:05.036 align:middle I use it on Linux and it integrates really well with the GDB for debugging, 00:33:05.376 --> 00:33:09.836 align:middle so I can just add breakpoints and it breaks and I can see the state of the entire application. 00:33:10.196 --> 00:33:11.816 align:middle For me, it works really, really well. 00:33:12.466 --> 00:33:16.046 align:middle But yeah, I won't say more than that. 00:33:17.396 --> 00:33:18.726 align:middle Anyone else? 00:33:19.076 --> 00:33:23.066 align:middle Yup. No, not strong. 00:33:23.276 --> 00:33:28.956 align:middle Uh, actually like probably if I will have to write C outside of the PHP context, 00:33:29.256 --> 00:33:30.976 align:middle I would be a little bit lost to be honest. 00:33:31.486 --> 00:33:37.016 align:middle Um, but yeah, it's uh, I don't have a strong background in C. I learned a little bit 00:33:37.016 --> 00:33:38.776 align:middle about it in school, but that was it. 00:33:38.896 --> 00:33:43.096 align:middle And by day I work with PHP, so that's what I'm used to. 00:33:43.676 --> 00:33:46.686 align:middle But uh, yeah, as I said before, it's not rocket surgery. 00:33:46.786 --> 00:33:48.546 align:middle It's not that complicated. 00:33:48.546 --> 00:33:55.116 align:middle It's, yeah, you'll get used to it quickly I would say. 00:33:55.356 --> 00:33:56.886 align:middle Anyone else? 00:33:58.686 --> 00:34:08.706 align:middle Okay. Well, then that's it. 00:34:09.776 --> 00:34:13.496 align:middle Thank you.