 Hi! I didn't expect that. That's good though. Okay, I'll be talking a little bit about what is new in Xdebug. How many of you are familiar with Xdebug? Just a show of hands. Okay. It's about 33 here. I've seen you. It's okay. You don't have to worry. Okay, so Xdebug is a tool that helps you debug your PHP applications. Now, I usually can, I can probably talk for a whole day about this, but I only have 50 minutes. So I can only focus on the new things in Xdebug. A little bit about myself. Hi, I'm Derek. I've already done the waving, so I don't need to wave back. I currently live in London. For my work, I work on a MongoDB PHP driver. If you have any questions about MongoDB, feel free to come and find me as well. I'll be around today and tomorrow. I wrote Xdebug. I also implemented PHP's daytime support. Time zones are particularly very annoying if you have to fly all the way across the world to come speak at the conference, because my body thinks it's now seven in the morning. That's great. I like Maps, B, and Whiskey, but we won't talk about that right now. So what I will be talking about is Xdebug. So Xdebug is an extension to PHP. It adds additional information in the form of debugging output, stack traces, but it also allows you to step through a running application while it is going on. Now, if I have some time at the end, I will actually be showing that, but with a limited amount of time, I might not get there. So by default, if you would install Xdebug, you'd suddenly see that whenever you have a warning or notice that it will tell you exactly not only where it is, but all the other function calls how you ended up there, which is kind of handy. Sometimes what you want is that when you get your notice or warning, is that your PHP script doesn't continue running, but instead you want it stopped at the same time, right? As an example here, think about you writing some code that loops to 10,000 different entries that you want to show on the page, for example. Okay, let's make it a hundred. But if you have like a little bit of an error in some of your code, maybe for each iteration of this loop, you might then suddenly show a warning or an error message on screen, which isn't particularly great because you can then see so many error messages that you might not be able to find what the problem is. So what I add is an Xdebug 2.3, which is about two years old now, is a new feature that allows you to, the moment when an error or notice happens, abort the script so that you can see your only single error message without having to wait until all the other things are shown. In addition to this, it also adds a feature that I have run into this where I've written application, pulled in some dependencies with Composer, and one of those libraries in Composer turns off display errors for me, which is really annoying because that means that if I write message in my own code that goes wrong, then I can't see those anymore because I've been disabled by a random library. Now, it is a really bad thing for libraries to do that, but some of them still do that. So by setting these other two settings here, like force error reporting and force display errors, it basically tells PHP ignore what other code does. You won't be able to override these settings. So you would always get your error reporting with the right levels and always get your display errors, which is kind of handy feature. Of course, these things are only be able to set in PHP I and I because otherwise applications will find a way to override these settings at some points. Similarly, with 2.3, I hope to show that, as I said before, that if you're doing the live debugging, you'll see quite a bit more information. You can now set breakpoints on exceptions saying, well, if this specific exception is being thrown in my application, abort the script and show the current status in my ID, which is a very useful thing to have. It also adds some additional information to exceptions and it helps you diagnose some configuration issues, which is, which you sometimes might run into when you have SA Linux installed or something like that. All right, so another big thing that came in Xeboot 2.3 is parts, parts coverage. So let me illustrate this with a demo and this, this ties into PHP unit, if in case you were at the workshop yesterday. So with PHP unit, you can tell it that whenever you run the tests that it also tells you which line of the codes have been executed. This is called code coverage. Code coverage, you don't have to use the PHP unit. You can do directly with a simple script that I've done here. So if you look at the bottom part of this, you see that I use PHP code coverage here and I do two runs. One of them is start with coverage one and one of them is coverage two. And in the first one, I'm calling this if then else method with the arguments true and false. And in the second time, I call them with false and true. Okay, what I'm going to do is, is this function, the function that you see on top here, I'm going to run this twice. And then you get an output something to this, right? You see that both if statements have been covered and all the lines have been covered because if you look at the function, what I'm doing here if a is is true, then they show a is it and then B is true, I show B is it. If I call this twice, once with A set and B unsets and once with A unset and B set to true, that means you still hit every line of your code. However, this is lying to you. It is lying to you because what it doesn't tell you is that you haven't basically tested all possible iterations, right? Because we haven't tested where both A and B are true or where both A and B are false. Now, this, this is something you don't necessarily want to do for all of your methods, but for the methods that are really complicated or are really important for your business logic, you basically haven't tested it well enough yet in some cases. So what I've added a few years ago is something called paths and branch analysis. So the way how this works is if you use XDbook directly, you need to turn it on by extra flag. It's called the branch check flag. And then you get output like this out of XDbook. Now, this is something that you can dump at an external tool. It doesn't do this automatically for you. But it does tell you a few things here. It gives you information about five branches and four possible paths. This is kind of tricky to see. So I have an image instead. So if you look at this function, Tesla PHP. So what are the possible paths through here? You can have A and B being false. You can have A false B true, A true and B false and both of them being true. And that is represented with the different colors in this graph here. So the red one is where A and B are both false. And the purple one is where A and B are both true. And you can see because this is a dotted line, it means that this path hasn't been followed. So now this is visualized as four possible paths. You can see whether the colored line is either dashed, means it wasn't executed. And it is solid while it is executed. So for this simple example, four possible paths, two of them are executed and two of them hasn't been. So this basically tells you if only written half the amount of tests that also covered this function or method. Now there is one problem here. Every time you have an if statement or a loop, you increase the amount of the possible paths by two. So if you have 10 if statements, how many lines do you get on the screen? You get 1,024. Now at that time, it is very difficult to visualize this information, right? Because can you really distinguish 1,024 different colors? It's going to be very difficult to do it. I certainly can't do it. So the visualization of this is something that is a lot harder than it seems. So the problem is that it's quite a powerful way to show which test you can still write. But it's hard to visualize and the other additional point is that it is really, really slow to do. Because when PHP executes things, it doesn't internally really fast. But in order to just part and branch analysis, I need to inject my own code at every single thing that PHP does. Making it really, really slow. So this is why I say this isn't something you want to do for every method that you have. I'll go back to this in a moment. All right, in XD Book 26, which is the current stable release, it added support for PHP 7.2. It has some fixes for variable resolutions that was in there since the PHP 7.0 compatible release. We also don't have PHP 5 support anymore. PHP 5.0 is no longer supported in XD Book because it is an extension that hooks into PHP internals so much, supporting multiple minor versions of PHP can be such a burden and it's simply not worth for me doing this anymore, considering that you can still also just install an older extension if you really still need to use PHP 5. But as Rasmus showed earlier, you really want to use PHP 7 because it's good for the planet, right? And XD Book 26 also added another few minor smaller features. It now does memory profiling. So XD Book profile always done profiling on time, showing you which functions are being slow, but it never really showed which functions take up a lot of memory. So that's a new thing in there. We have garbage collection statistics, which is probably a very niche thing to look at, but it's kind of cool. And on the debugging side, there are a few other things added there as well. So probably the most interesting one is the notifications and warnings feature. This is something that IDEs need to implement, and I know PHPStorm has implemented that. It's a feature that in its debugging console, every time you get a notice or warning or error message, XD Book also sends this notification to the ID so it can visualize this in a debugging console without showing it up on the screen. So that means you still got all the information out of it in case something goes wrong. But it doesn't is not going to clutter either your nicely designed websites or your XML or JSON creating API calls, right? Because if XD Book or PHP would inject information in there, you can't parse it as HTML or RST or anything like that anymore because PHP is just injected an error message into it. So this is kind of handy to have. It now also supports using funny characters and property names. And by funny characters, I mean here, the null character. Some people find it interesting to add a null character into their array keys or property names. And the null character cannot be shown in XML in any sort of form. So we have to come up with a different way of transporting that information. It is also kind of handy. It makes its debugger look a lot better as well. So sometimes people have issues getting XD Book configured to talk to the PHP installation. There are a variant of reasons why this can be the case. It is most often on the IDE side, maybe misconfigured or slightly done wrong or many reasons. But what is a nice thing that on the XD Book site, you can tell it to log all possible attempts to make debugger connections. And it will then tell you whether it can make a connection and it can also log all the communications between the IDE and XD Book. It will also tell you when it can't make a debugger connection and hopefully the reason why it can't make this debugger connection that can be well the hostname is wrong or it can't connect to the IP address and things like that and stuff like that. So the debugging log is probably the first thing you want to look at if you cannot get XD Book to work with in IDE. It is also information I'm going to ask for if you think you have found a bug in XD Book's debugging interface. So PHP 7.2 adds some interesting functionality. Like if you look at how Switch is implemented in PHP, it is basically a chain of if-else statements. So if you do switch A with case one, what it does is if A equals one, echo this information. If A equals two, echo this information. Else if A equals three, you know how this goes, right? The more case statements you have, the more comparisons PHP has to do. Now with PHP 7.1 does, as you can sort of see here, is that it has cases with the statements for each line. Now PHP 7.2, this information, this is called on better in PHP by making a table up front that you can see in this line. It then will compare the correct key, in this case the numbers one to six, and immediately jump to the right location what PHP needs to execute without having to do the if-else statements all the time. Which is really nice and it makes PHP 7.2 faster. Unfortunately it also means that if you would do single stepping through this, you don't see the stops on all the if statements anymore or more annoyingly. If you would do code coverage, you don't see that PHP actually does the comparisons for each case statement. So this is annoying, so I had to fix XD book. Anybody wants to guess how I fixed that? Yeah, it's easy to ignore the operation altogether. So basically make this a non-operation. So sadly, PHP runs a little bit slower again, but then again I argued that if you're running a debugger, you shouldn't be too worried about it being slightly slow anyway because the difference in speed is going to be a lot less than you having to look at what happened and clicking continue a few times. So yes, newer versions of PHP make PHP things go faster but make things more complicated for XD book. So that's my life trying to fix things. Now I've mentioned before that the code coverage with path analysis is actually pretty slow and that is because it literally tries to do everything including all PHP units source code, which you're not really interested in when you're running code coverage for your own project. Or you might not be interested in all the vendor libraries that are pulled in. Like if you're writing, say, your own plugin for Magento, you might not want to do the code coverage for Magento itself. You might only be interested in the own plugin that you're writing. Previous to XD book 2.6, there was no way of restricting code coverage to just the specific locations that you were doing it. So XD book 2.6 has filters for this. So you can configure a blacklist and a whitelist in either a prefix that is based on the part name or on the class name. And the class name then includes the namespace prefixes as well in this case. So there's two different groups for the filters. There's one for code coverage or the other one is for tracing. And if you do the one for tracing, the things that you have configured will also not show up on either the trace log files that you can make with XD book or the stack traces that you see on screen. The type is either a whitelist or blacklist for either the part or the namespace. And then the third argument is an array of filters. So just to show how it works. In my little project, my site project that I'm writing, I use DRAM as my top-level namespace. And I use MongoDB 4 or my MongoDB queries in there. So what I've done here I will configure a filter that says why only for tracing I want to include only all the class prefix that are either the empty string, which means PHP internal functions, or everything that starts with DRAM, or everything that starts with MongoDB slash. And all the rest will then be excluded from this. You can do similar thing for code coverage. So I run code coverage on a project that has a few errors in it at the moment. That's probably because it couldn't connect to the internet, to be honest. And when I run this with PHP 7.2, it takes about four minutes to run. It takes 56 megabytes of data. It is a bit on the slower side. It makes a few network connections as well. So it's sometimes a bit slower. But what I did before XD book 2.6 is would also do code coverage for all PHP units, which then PHP unit probably ignores and deletes from its output, which is what it's supposed to. Now with the filters enabled, it's only runs in two minutes, and it uses half the amount of memory, which if this is a problem for you, this helps a lot. But the only caveat is that you need to set a filter before code gets included. So PHP unit already has a whitelist built in for doing code coverage for specific bits. But it is kind of naive because it just deletes everything else and just doesn't display it. But in order to make this properly work, you need to set the filter before you basically load any PHP unit code at the moment. So what I'm doing here, I'm creating an auto prepend file that I have to prepend setting the filter before PHP unit gets executed here. I know for pretty sure that in the next release of PHP unit, this will done automatically for you. Exactly how is a bit unsure yet, but I'm sure once this comes out, either Sebastian or I will write a little blog post about it tomorrow in a week, apparently. There you go. You hear it here first. All the latest news about PHP. So yeah, this is kind of handy and it saves a lot of time making sure the computer does not do things that are just going to be thrown away anyway. All right, I'm going to go to the next ebook 2.7, which is in beta. It's out support for PHP 7.3. It's going to come out soonish. Probably not before PHP 7.3 comes out, but hopefully very soon after that. Because there's still a few bugs that I still need to fix. The support for 7.3 is kind of important in there. What it also allows you to do now is allow debugging of things that start other processes. So the way how ex-debug connections work, when PHP starts ebook, it will make a connection to your ID. Now, if you would start a process from PHP by using PC and TL exec, for example, or any of the other features, whenever you start a program, all the network connections that have been made will be inherited by the Calt program, which suddenly means that if you create a program, another process, you now have two processes using the same debugging connection. And you can't guarantee in which order things are sent again anymore. Any ID just gives up and doesn't know what to do this anymore. The change in ex-debug is that when it detects that a network connection is made by a different process ID of the process that it's currently runs, it aborts the current connection and then restarts it. So now the ID has two debugging connections independently of the process. So it can then debug these things independently without falling over each other. So it is a very handy thing to do, anything to have if you have things forking other programs. All right, ex-debug as it's open source and free as in free beer. Hopefully ex-debug saves you a lot of time if you have never used this before. A work on ex-debug takes me a lot of time, especially because the clever people that do more things to PHP keeps fixing things to make things go faster, but then that ends up causing more work for me. But that's how it goes. Anyway, how much time do I have left? No more time. So I can't give you a demo right now. If you're interested in seeing a demo, confine me in one of the breaks and I'm happy to show that to you. Do I have time for questions or also not? No, also no time for questions. That's okay, I'll be around here and all day tomorrow. Please come and find me, come and interrupt conversations. I'm happy to talk to you about ex-debug, daytime support, MongoDB, all these things. Thank you for attending and enjoy the rest of the conference.