 So, I'm getting old, and this is me, and this is in Greenland in the 60s, so I'm actually older than Constance. Basic place, and probably the first person you have met who was born in Greenland. Pretty sure. Me in Greenland? This is our house, because it has to be in a place. Because my father's work, he needed a very radio-silent place. So this very, very remote house in Northern Greenland is the most radio-silent place that you can find. There's lots of antennas around here that study how the lower layers of the atmosphere call the atmosphere. That's like a whole bunch of scientific equipment measuring the atmosphere. There were a few things in this lab that would have killed me if I touched it, so he just told me how to touch those things. And since I'm still around, that worked. And again, that was out of the driveway. My dad and I, so this is where I came from, and the whole family on the dog sled. Big fish. Again, another view of the house. This is a high summer, no snow on the ground, and there's the sun. Most of the year, well, for about a good seven months of the year, it's pretty dark because the sun doesn't come out. And a couple of months in the summer, the sun never sets, and so forth. There was a city way down that road with about 400 people called Kakataswak. That's the name of it. But yeah, that's where I came from, originally. So, ah, don't read my email. My slides are online. Drupal Camp. So, talk to PHP.net, Drupal Camp. If you want to go back to it, I'm on Twitter, at Rasmus. I'll show the link at the end, too. So, I got started in about the 80s. Early 80s, this was my first computer. Timex Sinclair had a whole 1K of memory. 10, 24 bytes, that was it. I was very happy when I got this box. This was a memory expansion module. It added 16K of RAM to my system. It was flaky though, because it was so big and heavy, it would actually sort of fall out. And my memory, while my code was running, would suddenly drop from 17K to 1K. So, I had to make sure that all my critical, basically my critical loop had to be in the first 1K of memory for my code, because I was bound to at some point lose the upper 16K. And then I needed to sort of recreate the data in the upper 16K. And there's no storage mechanism for this thing. So, anything I lost, I'd have to retype. If it turned off, power failure, you lose everything. There's no way to reload it, so you have to retype it. But, I mean, when you only have 10, 24 bytes of memory on the computer, it's limited how much code you can actually get in there and run to begin with. And it's kind of crazy now when we think about it. Every person in the room has one or two devices in their pocket that has thousands of times more memory than the first computer, or the first personal computer. I had a big 20, Commva 64. At some point, I got a haze modem. I was very, very happy to get this super-fast 2400-bod modem so I could connect to BBSs. And my life back then was sitting there watching the Z modem download things very, very slowly. Getting into the 90s, I've been doing a lot of online stuff with BBSs and things in the 80s. And then in the 90s, the internet slowly started to arrive, not to the masses yet. The first very, very sort of fate idea of the internet came with something called Gopher, which was used mostly at universities. You probably used it, Kostas, at some point. It was big for any sort of research papers. At the bottom of research paper, you have all your references. And with Gopher, you could scroll down, cursor keys down, and you could click on the referenced paper, and it would link to that paper at another university server somewhere. So the idea of hyperlinks and linking between documents was there. There were no images. It was completely a text-based system and you used your cursor keys to navigate around. And I did some work on Gopher, but it wasn't until October 1993 when Mosaic came out that it just was obvious to thousands and thousands of people that this would be the big new thing. As soon as we saw a graphical browser, I knew, for example, my parents who live near Toronto and Canada, originally from Denmark, my mother would have her brother send a big envelope on newspaper clippings about once a month, and she would then read the Danish newspapers a month delayed, basically. And as soon as I saw this, I told her, look, you are going to have in a couple of years, you're going to have a computer at home, and you're going to sit down and read today's newspaper on your computer. And I told her this in 1993, and she said, never in my life will I have a computer in my house, that if I had one, if you forced me to get one, I definitely wouldn't use it, because there would be no point. And there's no way I'd be able to read today's newspaper. And, of course, she has a computer today, and she has a tablet, and she has all kinds of things that every single one of these devices, when I told her you're going to get one, she said, no, there's no way I'm going to get one of these devices, because it just doesn't apply to my life. And every single one of these devices that I introduced to her and to my parents in general, they use religiously every single day, and they don't know how they actually live without them beforehand. So it's sort of a very interesting set of sequences that goes back to some of Costa's ideas as well, that things that don't appear, or that appear as toys are not useful initially, to a lot of people who can't sort of see beyond. It catches up to you after a little while. Same with the web. So this was the web in 1993. This was how you programmed the dynamic web page. I don't understand, I don't expect you to read it and understand it, but basically this is a CGI program written in C. There's HTML embedded into the C code, and you had to compile and deploy this code, even if you just wanted to change the look slightly or add a field to your form, you had to recompile and redeploy the CGI C program. This was just too hard. It was too hard for people to understand, especially for people who weren't C programmers. I was a decent C programmer, not a great C programmer, so I was doing a lot of this work. But for me as well, it was just too annoying, especially I was doing some consulting, very, very early internet consulting, and when clients said, well, that's cool, but now we want to change things slightly, it was just too hard to explain to them how to recompile their C code and how to not screw up the C when they started editing this. If they left out a quote or something, it wouldn't compile and they'd call me and say, hey, my code doesn't compile and they're trying to read C compile errors to me over the phone asking how do we fix this? I mean, getting this read over the phone and then trying to picture it and saying, okay, you probably missed a quote somewhere, it was just impossible. It was completely impossible to do. So I needed something better. At that time, most of the world moved to Perl. And Perl had this thing called CGIPM, which is a Perl module for writing CGI programs. And that same code you saw before in C looked like this in Perl. It's easier. You don't have to compile it. So in many senses, it was easier for clients to handle this thing, but it was still programming your HTML. It wasn't just writing HTML and loading up in the browser. It was programming your HTML in Perl. I still didn't like it. And people were kind of calling me crazy at the time, saying, well, what the hell? This is the best way of doing things. I don't think so. I think you can make it easier. So what I wanted was, I wanted the HTML to look more like this. So straight HTML with just a few magic tags tossed in where the dynamic nature actually was. And in this case here, if you wanted to add another field to do something, you just edit the HTML. Normally, you can do a view source in your browser. If there's an HTML error, well, it's an HTML-level error. That's basically a display error. And that wasn't something that, as a client, you needed to call me about. That was asking the other HTML folks in the office what did they screw up? Why is my page not rendering nicely? And it was not part of the dynamic solution at all. It was more so the static HTML than templating. And that was my whole point. I wanted a templating system where the look and feel was left to the client. I would do the complicated back-end system, talking to databases, and doing things like that that the client didn't really understand. They didn't understand OCI, for example, which is the low-level interface to Oracle. That's something for a low-level geek like me to figure out how do I actually talk to an Oracle database. But what I'm going to show to you as a client is just a magical tag. Whenever you want to talk to the database, toss in this tag into your thing that says get products or whatever I call the tag. And that was what I was building. I was building a templating system. And for the geeks, what I was building was the C API for the web. So a set of API calls that would link C code directly to the web server or to this whole templating system that I had built. So there were two customers here. There was the client side, or the client customer that only saw the template level with a very simple templating language. And then there was the back-end geeks where I showed the product as a C API for the web. This entire view of the world failed completely because I could not convince people to write code in C. And I refused for so many years to admit that my whole concept had failed completely. Everyone was focused on the templating side of things, which I thought was crazy. As a C developer, I thought, if you're going to write a complex system, you want a strictly typed, compiled, easily analyzable system, you want to write stuff like that in C or C++. Not in this very hokey templating language that I had invented on top of things. I mean, this was just for display purposes. The whole point here was to separate the look and feel, the templating, from the hardcore business logic. And that was sort of my religion for the first six years of the project or so. Five years maybe. I refused to call PHP a programming language at all. To me, it was a templating system until about 1998 or so. When I finally gave up and said, okay, I have completely failed. Nobody believes in my idea. Everyone wants to use my stupid templating language as if it was a programming language. Okay, let's look at it as a programming language and let's fix it then. All the things that just didn't make any sense. In PHP, I sat down and said, okay, let's bring a team together and let's try to work through it and fix all these issues and try to at least pretend that it's a programming language. So that's where my focus completely shifted. Well, not completely. I had already been working on it, but I really started focusing on the ecosystem overall. So this idea of LAMP came out by 99 or so in early 2000s. LAMP was Linux, Apache, MySQL, and PHP. So the four components that I had focused on making sure that they all worked really, really well together. And it didn't just magically happen. I and a bunch of other people made sure that all the pieces fit and that it worked well together. For Apache, for example, I wrote the mod PHP part, which was the module that you could load into Apache. So instead of having to fork and exec a new process, a new CGI process for every request, it would just be part of the Apache process. So you didn't have to fork a new process, which performance-wise completely blew away everything else. So if you're still doing CGI-PM type things in 99, switching over to PHP with mod PHP, you instantly got an order of magnitude performance increase. And CGI-PM just was dead in the water at that point. A couple of years after that, and to address that, the Perl folks came up with mod Perl, but it took them a few years to catch up and they made a couple of fatal mistakes in it. One of them was that they didn't look at the ecosystem at all. They didn't look at how would this thing be deployed. And in 1999, everybody was on a shared virtual host with some ISP, where the ISP would take a single Apache web server and put hundreds of users on the same web server and just give each user a different virtual host. Mod Perl, if you install mod Perl in this Apache server, it was too powerful. There are different stages of our web request, and each stage inside Apache can do different things. So the very first stage is called URI translation. It basically takes the request and then translates it to the right virtual server to use. If mod Perl is installed and you have access to mod Perl, you can hook into that hook and say, okay, anything for whatever virtual host you want that's coming in, you can grab it. So if you install mod Perl on the Apache server, you cannot run multiple virtual hosts on that server. You have to have one Apache instance per user. And right away, an ISP said, what the hell? Because this was long before containers or anything. That meant that one physical server per customer. So with PHP, you could put 3,000 customers on one server with mod Perl, you could put one. So cost-wise, how much do you think it costs more to, hey, I want mod Perl, okay, you can have it, but it's going to cost you $800 a month. PHP, you can get for $5 a month. Easily, I mean, that's why mod Perl never caught up. At the business level, there are a few places that did catch on. Ticketmaster, for example, and a few places at the business level where they were the only customer, but so many startups started with virtual hosting somewhere. One or two people sat down with a great idea and they started on the $5 a month shared account, shared hosting account. And you start on something with one technology. When you're moving fast as a small startup, it's really hard to completely switch technologies because your customers really don't care what your website is written in, what language is written in, as long as it's doing whatever. When you click on the button on the web page, it does the right thing. That's what they care about. Switching technologies halfway through doesn't make that button click do anything different. It just wastes six months of your time and rewriting everything to basically get to the same spot you were at. And it's six months that you don't have as a startup. By then, the competitor has gone right past you. So that's one of the reasons PHP won. Because of the shared hosting accounts and because the ecosystem was built to make it really, really simple. Another example of ecosystem work was the very first database that I made PHP work with was called MiniSQL, so MSQL. This was before MySQL was around. Also because Oracle was just too damn expensive for most people. So there's this thing called MiniSQL, a guy named David Hughes in Australia had written it. It was a very simple database. And it had no cursors of any kind. And I was looking at it, I was doing, okay, so if you do a select star and you have tons and tons of rows, on a 1999 network, if your database server was on a different server, waiting for 100,000 rows to come across the wire on a very slow network cable, it could take a long, long time. And especially if you did a select star, but you're only going to show the first 10 rows, like on the search results page or something. I need a way to limit it. I need to say, yes, I want a select star, but I only want the first 10 records. So I added this thing called limit to the SQL statement saying, okay, select star limit 10. And I patched this MiniSQL database server and added it to it, and he accepted my patch. And so everyone after that started using limit clauses with PHP. Then MySQL came around. He said, hey, we see PHP. We think we're a much better database than MSQL. We're called MySQL because of... His daughter's name was MOOC, which is a Finnish name. Everyone thinks that MySQL means something else, but the MY is actually a name. Anyway. So he came and said, look, can't you add support for MySQL? We've made it really, really easy for you. We have cloned the MSQL CAPI. So all you have to do in your VI is basically do a search and replace for MSQL and change it to MySQL. And everything should just work perfectly. And he was right. It did. I added MySQL support in probably 45 seconds. He said, okay, now I'll just save this one from MSQL.C, MySQL.C. It worked perfectly. But as soon as I tried the limit clause, it didn't work, of course, because limit was the thing I invented that just didn't exist. And I told him about it. I said, look, it's great that we can now use MySQL, but every PHP site in the world these days uses limit. And you don't have limit. He asked me, what the hell is limit? It's like, wow, it's this thing that limits around the rows. It's like, well, that's not in the standard. It's like, there's a standard? Yeah, there's an NC SQL standard. It's like, there's no such thing as a limit clause in the NC SQL standard. I was like, well, I didn't know that. But I needed this feature, so I added it. And if you want PHP support, then you're going to have to add it to MySQL. I was like, okay, whatever, fine. So then he took like a weekend and he added limit support to MySQL. And for any of you who have done any sort of SQL in the last 20 years, you have hit the limit clause, not just in MySQL. It's now also in Postgres and it's crept into other databases as well over the years, which I find really, really amusing actually. And I still get hate mail from SQL, saying, what the hell is this limit thing? What did you do? Which I find funny. But anyway, that was part of sort of fixing the ecosystem and making things work without looking too much at standards or anything or just solving the problem in front of my nose. I also looked a lot at scaling. And as a geek, as a technological person, scaling up is always interesting. Like how can I make this bigger, faster? There's the other direction that I was more interested in actually because when I build a team and put people onto this project, they were all interested in scaling up because that's a more technically interesting problem to solve. I was always focused more on the scaling down part. How do I scale this down to the weekend warrior who doesn't know anything about any of this stuff but has a really good idea that they want to put up there. They want to put up a website with their idea. How can I make PHP more approachable? How can I make it easier for them and make sure that the learning curve is really, really shallow? And make sure that the first thing they try just works and most systems out there. I was working for IBM in 1999. I was on the WebSphere team. If any of you know WebSphere, it's a very, very complicated Java application server for doing web work. And I think it took me a month before I got my first WebSphere application actually working. When I asked for the documentation, it came on this big shelf on wheels basically. And there was this whole shelf of books. It's like, here you go. Here's the documentation for WebSphere as it is now. And I was a pretty technically savvy person in 1999 even. And I knew the web pretty damn well. It still took me a month to write Hello World in the proper WebSphere way, which was nuts. And I kept complaining. I was always harassing everybody on the WebSphere team going, this stuff is stupid. None of this works. It's too complicated. And they all said, ah, go away. This is how you do things. This is how Enterprise Web should be done. It's like, okay, whatever. Honestly, I didn't last long on that team obviously. I went elsewhere pretty quickly because I just couldn't convince them that it was just too complicated. And that simple is better. Hello World and PHP. You open on the text editor, you type Hello World, save. That's it. It is exactly the same thing. You don't have to do the bracket question mark, Echo Hello World. It is exactly the same thing. Hello World, the text Hello World in the text file. That is a ballot PHP program. You run it and it spits out Hello World. So it's the shortest Hello World of any language anywhere because you can't make it any shorter. There's nothing other than the actual Hello World text in the code. And that's the way it should be. What else should it do? If you put Hello World into a text file and run it as a program, what else would it do? Then spit out Hello World. And if you look at, so you'd say like the first, the weekend warrior who sits down and tries to figure out how do I solve this? You have an HTML page with your, I don't know, your list of your books that you have at home. But now I want to sort my books or maybe I just want to put the date up on the page so you can see when was the last time I changed this list of my books. If you try to think about it, even today, how would you do this in Java? How would you take a static HTML file and figure out and put up the date inside the HTML file of when the file was last changed? In Java, how would you solve that problem? And I've had lots of Java geeks come up with lots of very complicated solutions for how would you solve this problem of injecting the date in the right place inside the existing HTML document. So first you have to parse the HTML document and try to figure out where to actually add the tag. Then you have to get the information about the modified timestamp in the file and everything. It's a good two-to-three-day project. In PHP, how do you add a little timestamp to an HTML file? Well, you put an echo date. You put one tag wherever you want in the HTML and run it and it's fine. It just spits out the timestamp at that point. And there's a function called FileMTime basically that gives you the modification time. But it would take you maybe 10 minutes of reading the PHP documentation online to figure out how to solve this and you're on to the next problem. So that was the work on scaling down. Now, of course, doing both in the same code base gets really, really complicated from the internal's perspective and also lots and lots of fights along the way of not sacrificing either end of the spectrum. So building a solution that works for the weekend warrior but also works for Facebook and Wikipedia, right? That is not easy. And there are a lot of people in this spectrum that are going to be unhappy about some of the trade-offs that were made in being able to reach both ends of the spectrum. It's very, very easy to write a solution that's absolutely perfect for a very narrow part of the spectrum of users. It's really hard to build a solution that works for the entire thing. And that's why one of the reasons you see a lot of criticism of PHP online is that we have made some trade-offs over the years to make it have such a huge reach. And also some of the origins of PHP as a templating language has stuck around and have provided some non-ideal features for the current state of PHP. But even so, it is still the best and easiest way to solve a whole lot of problems around the web. So performance-wise, I've been tracking how we've been doing for the last 10 years or so. So I know this is Drupal, but WordPress is unique in the sense that they are really old-fashioned and WordPress runs on really, really old versions of PHP which is stupid, they shouldn't. It annoys me that they do. But for benchmarking, it's kind of useful that I can go back and check how fast was this code running on 5.3 all the way up through PHP 7.3. So you get an idea of the huge jump in performance we got with PHP 7. So this is request per second with 20 concurrent clients hitting the front page of WordPress with a single post on it. So we went from about 180 or 187 requests per second to 433. And we always strive to have better performance on new versions. And obviously the latency as well has dropped similarly. So 130 milliseconds to serve up the page in 2009 on PHP 5.3, down to 38 milliseconds with PHP 7.3. But even more importantly, especially for today's world of containers, the memory requirements used to be about 140 megs of RAM needed to serve up WordPress. We've shaved that all the way down to 15 megs of RAM. And that drop in memory means that you can use smaller containers. You pay less money to Amazon, to AWS for your hosting once you get onto PHP 7. Is this due to PHP or WordPress? No, this is the same version of WordPress tested against all the different versions. So this is completely due to PHP. So in PHP 7, what we started looking at, with PHP 7, we had some competition from Facebook. So Facebook came up with their own version of PHP called HHVM around this time. And we sat down and go, oh, they're crap. They are fast. And they did it via JIT. So we wrote a JIT. And we figured out that writing a good JIT is really, really, really hard. Writing a bad JIT is still really hard. And apparently we had written a pretty bad JIT because it didn't do anything. It didn't improve performance at all. And we started analyzing it. And we actually got a lot of help from Intel. Intel's compiler team was involved with this and they sat down and we looked at how we're actually using the registers in the Intel chip and how memory was being passed around. And they just said, look, you are just copying memory around everywhere. It's crazy. You keep blowing the stack. You keep doing all the wrong things. So forget the JIT. Fix your memory issues. It was okay, fine. Before we can do any JIT, we have to fix memory issues. So that was where the project shifted to. And then once we fixed memory issues and cleaned up the internals of PHP, we saw, hey, the performance is amazing. And we haven't even started on a JIT yet. So we decided, well, let's not wait. Let's just release it before we have the JIT as PHP 7. And so that's why the memory dropped so much because we cleaned up the internals of PHP so much at that point and completely eliminated copying stuff around. So there's always only a single copy of everything. And because of the opcache was included as default in PHP 7, we didn't even copy it to each process. It would be a single copy in shared memory. So if you didn't change, say you have a huge configuration array, that would sit one time in shared memory. And as long as you don't modify any of those configuration entries, it wouldn't get copied out into the individual requests process. So if you're using FPM or Apache, you have multiple processes running these things and we wouldn't even copy this memory out to the process. That's why you have this massive, massive drop because in PHP 5, each process would need a copy of that memory. In PHP 7, it sticks around in shared memory. We also got stricter about not keeping support around for too long for the different versions because our team is actually pretty small. So we're here today, March 1st. So the only actual supported versions today are 7.2 and 7.3. We're still doing security patches for 7.1, but if you're still on PHP 5 of any version or even PHP 7.0, you're on your own. You may get some LTS support from your Linux distro if you're lucky, but you really should be looking to upgrade to a supported version. Also because it's a hell of a lot faster, especially if you're on PHP 5, but even 7.0 to 7.3, you're going to get a decent performance boost out of it. If the speed doesn't convince you, how about looking a little bit at your kid's future, my kid's future? So there are around 2 billion sites on the web and those 2 billion sites are hosted on approximately 10 million physical servers sitting in data centers all over the world. PHP is on at least half. So the conservative, it's probably on more than that, but let's be conservative and say it's on half servers. Right now we only have about half of the PHP users out there. PHP sites out there have adopted PHP 7.0, which is a bit disappointing to me. I thought the adoption rate would be faster given how much faster it is. So we need it on more. If you look at some of the numbers in the U.S. at least, this is about how much it takes. 3,000 kilowatt hours a year costs about $400. And then you have to also cool the data centers, which generally doubles that cost. So about half a kilogram of CO2 per kilowatt hour. So a 50% adoption, we're using about that much, but let's go all the way to 100%. Let's save that CO2. So upgrade your servers. Convince your ISP. If you're relying on your ISP to upgrade, at least make sure you say, hey, I'm okay to go to PHP 7.0 with my code. But these days there are not that many shared servers out there anymore. Everyone's on the container. And in the container you have full control. So please, please, please look at upgrading your PHP 5.0 stuff to PHP 7.0. It helps everyone, including yourselves, because it's so much faster, and it's just better code. PHP 5.0 has too much of my code in it. PHP 7.0 has a lot less of my code, and the less of my code that's still in there, the better. So please do your part. All right. A few cool things that I've been working on lately. I've been doing some work on static analysis. Very unimaginative name, fan, PHP analysis. You can find GitHub, fan. Easy to install. Composer require devfanfan. There's a little configuration file you can put in. So if you have a normal, composer-based directory structure, with a source structure, we have all your code, and the vendor directory, we hold the third-party code, goes in there. You can tell it, analyze my stuff in source, but exclude analysis for everything in vendor. It'll still load it in, so it gets all the object definitions and things, but it's only going to complain about stuff in the source directory. So you set up a configuration file like this, tell it your target PHP version. This can also help you for upgrading. So even if your code is currently running on PHP 5.6, for example, you can tell it your target PHP version is 7.2, and it will give you errors saying, well, if this was running in PHP 7.2, these are the problems that you're likely to see, but it's also going to give you a ton of other just straight errors that you have, and it checks all kinds of things. So what it also lets you do is enhancing some of these PHP doc type annotations. So for example, with PHP 7, we do have types now, so you can type your various parameters to a function, but all you can do in this case is say, this is an array. In these things, you can say, this is actually an array of integers. So that's one of the enhancements that you can do. And then if you get something that's not an array of integers, the fan will tell you about it statically. So we'll just analyze the code without running it and say, hey, it looks like you're passing in something that's not an array of integers. So here are some of the calls, and you can see that these first calls, they all meet these. This first thing is called a union, because I have two different, it can be a union of either string or an int. So it can take either, or you can't do as a static type. And you can also have something called a shaped array. We basically say, this array has to contain keys, mode, and max. And the mode key has to have a value that's a string, and the max key has to have a value that's an int. So statically, it'll look at these calls and say, hey, these all meet, fine. This is a string, that's fine. This is an int, that's fine. This one's fine as well. It has max, mode, has an integer array, everything's fine. This call, however, the first argument is an array. And fan looks at it and says, wait a second, it has to be either a string or an int. You're passing an array, mismatch. That's why fan gives you this error. On this call, it looks at it and goes, okay, string, that's fine, integer array, that's fine. Uh-oh, this only has max. This hint here says that this array, this argument must have an array that has two keys, max and mode. This only has max, there's missing mode. So that's what this error here is. The array passed in just has max, but the function takes mode and max. So those are just a couple of very simple examples of the types of errors that fan will find. You can write plugins. It comes with a demo plugin, a whole bunch of other plugin examples. There's a dollar-dollar plugin for the strange people out there who don't like dollar-dollar syntax in PHP. I don't understand why. I think it's brilliant. What perhaps wasn't so brilliant was that I made it infinite. You could put as many dollar signs as you want. And for those of you who don't know what dollar-dollar is, it basically lets you, so if you have dollar-A equals A in dollar, then dollar-dollar A is recursive. That wouldn't work. If dollar-A equals B, the string B, and you have dollar-B equals one, then dollar-dollar A is one. Because if dollar-A is B, then you put another dollar sign on that that becomes dollar-B, so that becomes the B variable and does that. But if you try to go beyond two to three, four or five dollar signs, good luck figuring out what the hell that code does. So I probably should have stopped at two and not made it and go further than that. But you can put $37 signs on the road and it's actually perfectly legal PHP, which that wasn't a great idea, but it was so easy to do in the code. I didn't see any reason to restrict it. All right. It also has a Damon mode, which is kind of cool. So for those of you who use PHP Storm, you know that there is some static analysis in PHP Storm and they can find problems as you're typing, basically. If you're a VIM user like myself, you don't have anything like that, except now you kind of do. You can run FAN as a Damon and you can add a little snip, a little macro to your VIM startup file, or VIM RC file, and it can do stuff like this. I would type it, but it's easier just to have it pre-recorded. So here's a little configuration file where I show the plugins that are currently installed. I start the Damon. Once you get the message, it says it's listing. It's ready. And now I'm going in VI. I make a change here and it comes up and says, hey, this had to have integer keys, and it wasn't, and here this had to return an int. Well, I added an int return type and it didn't have one. So you see all the errors pop up so they interact with the inside my VIM session. So that's another little cool feature that you can get from running FAN. All right, you can go look at that video yourself. PHP Spy. Another project I didn't write this one. So it probably works much better than if I had written it. A co-worker of mine at Etsy named Adam wrote it and it's really, really cool. To explain what it does, a very simple example. Here's a PHP program that just sits and sleeps for one second. It sleeps for one second then it exits. If we run PHP Spy on it and tell it to sample every 200 million nanoseconds, it's basically every 200 milliseconds, then we see five sleeps. So basically it prods the process five times a second. It's like, what are you doing? And every time it gets a back trace of what this process is doing. And obviously, all it's doing is sleeping. So we get five sleeps back. That doesn't seem very useful. However, if we run this on... In this case, I was benchmarking WordPress when I was doing this. So I was PHP spying one of my FPM processes that was currently serving up WordPress. So every... And the default is every 99 milliseconds. Not 100, because that can get some weird effects where you exactly miss something. So 99 is a little bit safer. So every 99 milliseconds by default, it checks to see what this process is doing and you get a much bigger back trace, obviously. But even so, it's kind of hard to read. You also get stack frame, memory usage on the stack frames if you want. PHP Spy minus M to figure out where memory is being used. And soon you will have perf and call grind support for that. But what you can do with all this information is create a flame graph. There's a script that comes with it called stack collapse. Another flame graph. Written in pearl, which I think is awesome. And you get an SVG out. And that SVG looks something like this. So this is actually a fan run where it's looking at what was going on, what is fan doing as it's going through. And you can then zoom in on the various parts and see all the different components that are being called inside this process. And at Etsy, we actually end up using this a lot. We have a lot of cron jobs and we also have a lot of gearman jobs that run for a long time. And sometimes they run forever, it seems. And we can't figure out why are these things not ending. And it's very, very handy just to hang PHP Spy off of because you don't need to instrument it. It's not ex-debug where you actually have to run slower or anything. You can run PHP Spy on a production web server and poke the running production PHP process at PM Apache, whatever it is, and you can see what it's doing. And you can get a flame graph of what this process is doing with these backtraces and you can then dig right into what's happening inside this process. So it's a very, very handy tool to figure out what's going on. Where is my PHP program using its time? Where's it spending most of its time? That was PHP Spy. How am I doing? We've just overrun anyway. How long do you need? I'm done. Just how many stories I tell? Yeah, I have one more section. Just on future stuff on PHP 7.4. So the current version of PHP 7.3 came out a couple of months ago. You should all be looking at upgrading to it if you're not already on it. If you're already on it, awesome. I work at Etsy. I know PHP pretty damn well. I'm not quite on 7.3 yet, even on Etsy. So I will be in the next month, month and a half or so. I'll have upgraded Etsy to it. But like Costas was saying, the larger the company, the more moving parts the harder the problems become. We have a lot of unit tests at Etsy and it's a little difficult. Some of them rely on some weird overloading that needed something called test helpers to do the overloading that doesn't exist anymore. So there are some obstacles for Etsy. If you're not reliant on overloading in your PHP unit test and you can upgrade PHP unit easily, there should be no real obstacles for you to get to 7.3. Alright, so PHP 7.4. New things. Type properties. Add a type now on properties. It will be checked. This slide always prompts the question, why not have type variables everywhere? Type check is somewhat expensive. We could easily add type variables everywhere in PHP, but that means that every time you modify a variable anywhere in your code, we have to have an extra hash lookup and an extra type check. That would slow down average PHP execution by probably 25-30%, which does not seem worth it. Type properties is sort of a compromise. You tend not to use a property for example a loop iterator variable like $i++ in a loop. You don't do this $i++ or at least if you do, you're kind of silly. You shouldn't be doing that. So the idea is that properties aren't written to as often as local variables. Properties tend to be set once or maybe via a setter every now and then, but it's not something you continuously set thousands of times. So that's why we can do type properties. It will slow down code a little bit. So we're hoping for some Dmitri magic for getting some performance boost elsewhere at the same time to offset this slowdown. Minor new feature and null coalescing assignment operators. We can do question mark, question mark equals. That would be the equivalent to that line of code. Very minor feature. A much larger feature is we're looking at opcache preloading. And opcache preloading means that you can load a class into PHP on server startup and have it native to PHP essentially. So you don't have any sort of performance hit on this class on a per request basis. With opcache, the performance hit is quite small, but there is still a little bit of taking those opcodes from opcache and registering the class and creating it. By preloading it, you can speed that up a lot. So for something like Drupal, you would probably preload the base Drupal and have some of the other things that are going to change more often, not preloaded on top of it, but maybe all the base Drupal libraries would get preloaded because those hardly ever change. But this feature is really for another thing. It is, for this second feature we're introducing is the FFI foreign function interface. For those of you familiar with other languages, this lets you easily combine PHP and C, which I really like because my initial focus on C. But what this does is you can very, very easily call functions in an existing C library directly from PHP without writing a little wrapper extension. So many of the PHP extensions we have are just very simple wrappers around low level C libraries. That can now almost entirely go away and those C extensions can be written mostly in PHP. So something like, even something as complicated as GD, for example, with the image extension, it might completely disappear in five years and it will just be a normal Composer package that you require if you want GD and it would have a bunch of FFI things. But with the preloading feature, you would preload that in so basically performance wise it would stay the same except if it would now be a completely PHP file, that's much easier for more people to contribute to and to fix. So I wrote a little sample just to make sure the stuff works. I found a library called GIFink that takes and creates an animated GIF. So I wrote a little bit of PHP code but the trick is here. So I'm loading in this file called GIFink.h. It's just a C header file and now I have this weird FFI object I say, okay create a C level array 12 8 byte integers and I add some colors in here because I need that for the GIF I'm making I create a new GIF I go through and I add some frames to it with different colors. So I call this add frame function and I close the GIF. Now this header file that I loaded I actually copied it straight out of the library so this lib GIFink library has a header file that I copied directly. The only thing I added were these two lines I gave an FFI scope and I told it the name of the shared library that they needed to load in and that was it and we see the prototypes for add frame for new GIF and close GIF. That's actually all the functions that are in this library you could also just do a subset of a library and write a little header file like this plus you have this structure of an actual GIF when I run this code I get that which is kind of magical right? That's this very very small piece of code running using no extension no outside extension but loading this in via FFI linking to a C level shared library to do this which is kind of cool and the this is not something you want normal people at your company to start writing FFI code once you start writing C code you can do magically dangerous things you can blow up everything but if you're maintaining a C extension for your company yeah against some local stuff local library of some kind doing the FFI is going to make that work a whole lot simpler alright I'm completely out of time if you can that's the URL for these slides fanphpspy if you're operating to PHP 7.3 please read the upgrading guide and if you find bugs please tell us about them thank you thank you so much