 Well, hello. Good morning. Everyone can hear me. Raise your hand if you can understand what I'm saying. Okay, good. It's a good start. So today I'm going to be talking to you about PHP 7, which in my opinion is absolutely awesome. It's a really awesome job that the guys from the PHP team and the Zend company team have put a lot of effort into this. I think it's a fantastic job and I wanted to show you today some strategies on migrating systems and specifically with migrating systems for PHP 7. At the moment who's using PHP 7 in their job with production? So not that many. Okay, so who's using PHP 5 right now in their job? Pretty much everybody. Okay, so everybody hopefully will get some kind of value from this talk today. Very quick introduction. That's me on Twitter. So if you want to take any pictures of what not, that would be awesome and yeah, take some pics. These are a few things I'm involved in. I contribute to PHP, the new PHP website. It used to be really old and busted and now it's the new hotness as of a few years ago. I do things on PHP 5. PPI framework is a project that I work on and I organise a conference in Scotland where I'm from. So this is Scotland. It's made notice I'm not really South English, I'm from the UK. So this is a picture of Scotland, very typical. And yeah, some more random pics. And this is a picture of me, my three children. My oldest son, his name is Kyle. He wrote his first PHP script two weeks ago. He's five. So next one, Kyle. I think there's a camera there. So PHP, right? PHP is getting a lot of, what's the word? Steff competition, I would say, from other languages. Languages coming up, languages disappearing. Languages getting better, faster and slower. And PHP has been getting a lot of criticism from one way or the other, whether it's speed, whether it's usability, right? And also this is quite a picture that sums things up, right? So there's Python. Python's faster than PHP, so you should choose that. Ruby's got, you know, you can bootstrap things faster than Ruby. So yeah, but PHP 7, in my opinion, completely blows this away. So you've got another one, a book in one, right? So this is from the internet. Well, what happened? Can we put that down a little? Maybe? Can we put the lights down a little bit? Awesome, thank you. Okay, so yeah, PHP 7, right? Awesome to speed performance, and this is WordPress. This, for me, sums up everything you need to know. Of course, this is only one example. It's Mandelbrot Fractal, which is just an algorithm, some kind of thing. Doesn't really matter. The point is that PHP 7 completely blows all the other languages out of the water in this specific case, right? So I'm pretty excited to be here today and to share some experiences and to hopefully get everyone as quick as possible onto PHP 7. So this is a quick summary of what I've tried to do, tried to summarise what the talk will consist of in the main sections. So we're going to look at what will break, what potentially can break when you do upgrade, or if you do upgrade, how to identify and check the compatibility of your existing systems and to, is it compatible with PHP 7 and also identifying what needs to change in order to get there. Also benchmarking and monitoring, and that's pretty important. And we will see why once we go into the talk in more detail. Once you've got actually PHP 7 ready codes, the important part is about packaging that up properly and being able to distribute that around and deploying that onto systems that are, maybe you currently have live traffic on your production systems to disrupt that by potentially upgrading PHP 7. So it's about deploying things correctly from a code perspective and maybe from a database perspective. So these are a few things. There is basically all the details you need to know or on the PHP.net website. And this is a screenshot. So if you just google for migration 7.0 or whatnot, it's there. So everything else I'm summarising today, but everything you need to know should be there. So one of the most important changes in PHP 7 is behaviour. Some features were added, some things were taken away, but the most important thing that's hard to actually deal with is behaviour and if behaviour changes, that's not something you can just easily identify usually. But fortunately we can detect this. I'm going to show you how. PHP 7, we added something called an abstract syntax tree. Ignoring the underlying details, basically what that means is we put an intermediate layer between the PHP code that you write and the engine that actually parses it, allowing us to inspect at a very in-depth detail what your code is doing, how it's performing, what the data types are, what variables are doing. That's what that abstract syntax tree was the benefit that it gives us. So we inverted the logic of how variables are interpreted by the ASD and by the engine, and that's why I'm highlighting this to you today. So this is an example. All right? So looking at, ignoring the first line, but if you go to the second line, you'll see that the old behaviour, it would evaluate the right side first with the brackets, and then resolve that, and then whatever that becomes, like a string, then it would call that on foo. But now in PHP 7, it evaluates the left side first. So whatever, for looking at the second example, whatever foo bar, dollar foo dollar bar becomes, then it will call baz on top of that. You understand? It takes a little time maybe to look at it for a while. Again, it's all on the website, so go look at it. It's important to know. We removed a few things, so your code will, if you're using the dash e modifier and preg replace, which is eval, which is like the devil, and you shouldn't use it, we removed that. That's completely gone now, and the recommended practice is to use this callback system. So if you're using that already in your systems, it's something to look out for. We also deleted this, if you are unfortunate enough to be using a system that's using this variable, it's being deleted also, so that will break. We also become more strict on using octals, dealing with octal values. You can see here, this becomes, in PHP 5, it becomes 375, and the reason is because 8 is not a valid octal number, because octal goes from 0 to 7. So 8 gets chopped off, and somehow that values are 375. In PHP 7, it actually says, 8 is not a valid octal number, so we're just going to throw a new error, so it's a good thing, but you need to be aware of it, because if something was silently failing before, it's not going to silently fail any further. It will just throw a parse error at the exception. There's new reserve keywords, so if you have anything in your system that's using these types of things, classes, objects, not variables, but keywords, these are reserved in the language, so you'll get a parse error. From a behavioural perspective, we added throwables internally, so now it used to get like e underscore warning, e underscore fatal, e underscore, whatever. There are no longer errors anymore, there are exceptions. Everything now inherits from a throwable interface, and we have this generic error now, and then you've got different types of errors, and the same with the exception, and then exception has different types. Okay? So, about compatibility, is your code ready, or is it not ready? How do we do this? So, there's a tool called Fan, so Rasmus Lerddof, the creator of PHP, he wrote this tool called Fan, PHP Analyzer, lose your hand if you've seen and heard of this tool before. Fan, okay, some of you, this is awesome, and it uses this new feature called this new abstract syntax tree to inspect your code, and identify the behavioural changes. You know all these things I identified before that I've changed in PHP 7? This tool will tell you if your code is doing that. Right, pretty awesome. It needs a PHP extension, and it runs out on PHP 7, because PHP 7 has an AST. So, you need the PHP 7 system, you need to compile the AST, it needs to come with the AST extension, and then then you can run Fan, which is just a PHP library. So, in order to get a PHP 7 system, there's two very convenient ways. Rasmus Lerddof, again, he created a vagrant system called PHP 7 Dev, and it's a vagrant image, and you just, it's a virtual machine, you just pop in, and it has loads of different versions of PHP inside, so you can easily switch between them. So it's very convenient. Also Docker, won't go into too much detail today about Docker, but Docker is a very convenient way to switch and use different versions of PHP on demand without installing anything on your actual computer. So this is what I've got on my machine. This is a Macbook. It has PHP 5.5, but right now I'm running Fan on all my code, which is using Docker. So this thing in the middle here is actually a Docker container. It didn't create, it got it from the web. Inside the Docker container, it has PHP 7.0, it has the ASD extension compiled and it has the Fan library built in. What I'm doing is I'm taking the code that's on my computer, like any directory, any project I have right now, I run up one command, it takes the code, it puts it into the container, runs the stuff and then outputs a report for me and the fan will tell you what is not broken. So I created this very, very small script on my computer and it's just called FanDocker. This is the Docker command underneath. Basically it takes the present working directory which is where my project lives, where I currently am and it puts inside the container to a directory, MountSource and what happens is when this container here by a company called Cloudflare, when it runs it's going to execute a script called RunFan and I built this myself. This is what it does. It's very basic. Again, this is all from the Fan documentation. It's really like, you know, Fan101 is very simple. But I, in my current directory I don't just have PHP files. I have JavaScript, CSS, I have images. So I don't want Fan to try and analyse all these things and take a long time. So I wrote this find thing to give me all PHP files recursively and file list. And then I just used the file list here and I do dash O to analysis.txt. So this is actually running inside the Docker container. All right? But what happens is because in the previous slide you see I done this dash V, it's called a volume in Docker. What that means is it takes my code and puts it in the container and if anything changes on my system it will automatically update in the container and vice versa. Anything that happens in the container will happen on my computer. So inside the container where I done dash O, analysis.txt put that back on to my machine. Did that make sense at all? Raise your hand if you understood what I said there. Okay, good. Docker is very difficult to explain if you've not heard of it before. So this is the overall picture. So I'll put this code on GitHub. My user name is my surname is Dragunus on GitHub and you just run one command this command here and you can run Fan on anything. You don't have to install anything on your machine. You get PHP 7 and Fan. Okay, and this is just some of the analysis.txt, just the output file. These are some things that was coming up with on one of the projects I had. It's clearly weird and it's not PHP 7 compatible but it just gives you an example. Fan will throw out exceptions for all the things that are not PHP 7 compatible. All right. So once you get to the point where you're running Fan and you are going around and you're fixing tweaks and you're tweaking things and you're fixing bugs in your code and you're making it PHP 7 compatible. When you get to the point where it is compatible and you can run a PHP 7 system the important part is before you'd make any changes put some monitoring in place some benchmarking. Now there's two main factors. We can use Apache Bench or we can use JMeter. Is anybody here use Apache Bench? Okay, and what about JMeter? Okay. But a little bit less of a JMeter there. So they are both different tools. I have a command here where I have two Docker containers running on my machine one's PHP 5.6 and one's PHP 7.0 and they are on different host names. All right. So I run Apache Bench. I send some traffic to my thing and I tell it to output to this PHP 5.out and PHP 7.out files. Now this is useful because we can put the .out files into other pieces of software and we can generate some graphs. So this is a Linux tool called GNUplot. GNUplot, well you see he down here is like PHP 7.out so we can actually create graphs out of the .out data on the fly. That's pretty awesome. They are two completely independent tools but they work very well together and as a result you know you just create your legends at x axis and your y axis and then you get something like this. It's just a PNG file. This example of course is like Apache versus engine X but you can see the same difference if it was PHP 5 versus PHP 7. So that's Apache Bench. JMeter is good, also has a GUI tool so you can set up JMeter to send traffic to your sites to benchmark the speed difference because before you actually say should we or should we not move to PHP 7, you actually want to identify what the difference is how much value is in actually switching. So this is just JMeter, one of the interfaces and you tell it there's a CSV file there so that could be like a .out file but that's the results so you just give JMeter a results file and then it creates more awesome graphs. So you can get more creative more analysis, more results and actually come up with if you're if this is in your job and you're trying to pitch to your business, to the business how much value they will get this is where you want to start before actually start moving over. Also in addition to this if you're in development or a staging or testing or production environment you have ELK also known as ELK stack and basically your PHP app sends stuff to LogStash and then that forwards it onto Elasticsearch and it stays in there as a database and then you have Kibana which is a dashboard for visualising data. I wanted to quickly show this on my machine so I have an ELK stack here I'm using Docker compose on my laptop I run this and I didn't install it on my computer but it's running it's putting up Elasticsearch and LogStash in Kibana and they're listening on some ports on my machine and now I have another tool here another tool that isn't running on Docker called weavescope hopefully this works so this is actually a tool called weavescope a weavescope is actually a visualisation tool for Docker and it shows you all your containers and it shows you the traffic between your two containers so I'm going to try and put up weave again if it works it'll be awesome but if not then fair enough, live demos don't really work ok so that's scope running alright so these are three Docker containers that I've spun up on my machine and it shows you the traffic between them so if I had a PHP application like another Docker container which is like a PHP 7 app you would see that can pop up somewhere on here and it would show you that it's speaking to LogStash and you see there's a line between these guys that's because LogStash is connected via TCP to that so this is an awesome visualisation tool for Docker you can run this on your local machine which is what I'm doing right now you can run this on remote servers as well so if you're using Docker on AWS or other systems and you're remotely connected and you can see all the CPU and memory this is free and you can download it on your machine so I just wanted to highlight that this tool is awesome also ok we'll go back to the slides but yeah I didn't install anything on my machine I just run one command and I had three different services running and I had a visualisation tool to show that it's pretty awesome right so this is Cabana you can create graphs out of the data does it for you but you get more rich interfaces so this is say you're on production right now and you want to start logging where your PHP 5 system is the response times every request how long it takes you want to set something up like this so that when you do switch to PHP 7 you can compare you can see if there's been a problem you can roll back if there's a bug that you haven't really fixed yet ok so so far part of this process we have a PHP 7 app maybe we have some benchmarking we have some graffing or we have some monitoring in place how do we actually get a code from on our laptops to production that's where continuous integration systems come in at the moment who is doing some form of continuous integration as in like testing using Jenkins maybe bamboo or something like that continuous integration is really just automation around running your tests any kind of test interface tests it can be unit tests as long as you have tests that's a good start and there's pipeline tools for this so what we do is typically we have continuous integration pipeline so what that means is we have different series of steps in our pipelines that do a certain task for us to check our code every time we make a change and we push to our repositories it will trigger a series of jobs to analyse and identify our code and there's ant which is a very popular one and also there's a PHP one called Fing anybody here using ant on Jenkins anyone using Fing a few more hands for Fing Jenkins has this thing called Job DSL which I want to tell you about so in Jenkins you have to manually with the interface go and create jobs and put right down all the code and all the steps inside that this is what it looks like so I have one job here called all tasks or you want to have lots of little small jobs this is awesome because you don't need an interface any longer to go around and click on Jenkins you can write code and you can say what will happen what will happen, what order and if it fails then it will stop and you'll get a failure so this is Job DSL this is actually Gruby script the language Gruby script but as you can see it's very easy to use so contains an education pipelines this slide is about if you have a pipeline already that just runs tests or tries to like does the home page of my application load port 80 and does the home page load does it rather than getting a 500 error and it falls over what I'm recommending is for a strategy is you do the same for PHP 7 and PHP 5 all right have them in parallel just because you're not switching today doesn't mean you will not want to switch to PHP 7 in the future or near or long term future so run them in parallel so every time you push to your branch you get the results for PHP 5 what you care about today but you also see for the future have I broken something for PHP 7 so this is kind of where I'm going with the rest of the talk is you want to run them in parallel you want it out it's called running parallel pipelines all right so first step of your pipeline we have prepare preparation of the environment run some tests if the tests are good and we say that our software is okay we package up that code and then we deploy it somewhere it could be a staging server or a testing server or a production server for that brave so the prepare step is usually something like this so if you go on some unit tests again you do the same in parallel so if anything PHP 7 breaks you'll know about it in the background so just keep that in mind then we have tests so usually the testing phase of our software looks something a little bit like this lots of different types of testing here from unit testing to PHP spec to B-hack to code-ception to interface testing with MINT Selenium so the packaging phase is very important there's two methods of doing deployments you can either tell a remote server just to pull down your code and update it but the problem with that is if you pull down code on a testing server run tests and you see the code is good and then you tell it again to pull down the code on a remote server there could have been a change say you're pulling from a branch say the branch is called versioned one and on your testing server go back one on your testing server you're testing branch one and it's good if you just connect into a remote server and do git pull or subversion pull or whatever someone could have pushed to that branch and you were not you've no way for you to know about that so that's why doing pulling down code on the end server is not a good strategy and that's why packaging is important tools to do packaging with so we have the basic which is actually one of the most stable because it's the simplest which is just really creating a zip of all your code or a tar or a G zip or whatever compression you have and then you can r-sync that to any server in the world that you have a connection to alright but the important thing is that you're taking your code that you tested and you know that this code is solid and it's really really working really well and you move that to any server alright that's really important other options we have Artifactory, Artifactory is used more so in the Java world anybody here used Artifactory? okay a few hands, Artifactory is an awesome tool really it's just like a storage storage tool and you just push things into it and then you pull things down you pull it on from whatever server you want so it's just like a push pull mechanism another very solid option is that once you create a tar of your code or a zip of your code you can use Amazon S3 is anybody doing, is anybody pushing any of their code to Amazon S3 now? okay not that many Amazon S3 is cheap, it's affordable but the important thing is you only need to if say you have 10 servers and you want to update your code on 10 servers you don't have to push your code 10 times you can push it to one central location S3 now let's say that your code is not just in one country or region let's say your product is you have servers in Singapore and some in Germany and some in America then pulling your code down from Amazon S3 which may be hosted in like the United States will cost you lots of money because you're taking it over regions this is where you put a CDN in front of it the CDN the point of a CDN content delivery network is it detects where you are in the world and Amazon will just distribute the code to all your S3, your code to all the regions in the world that makes sense and then whatever server pulls that down it will be the closest server to that so that's why you can also not just take advantage of CDNs for the users like serving them to see images and stuff but you can also do it for yourself and that means it's faster and it's cheaper so that's a good point also if you're using Docker again it's like Artifactory Docker is a Docker registry it's a central location and every time you test code and you say this is good you package it up, you do a Docker build you build it up and you push it into a registry and then on any other server on the internet you just do the Docker pull very similar to Artifactory GitLab is free it's open source, it's an awesome tool also has a storage feature just like Artifactory so you don't need to pay money for S3 because GitLab has a building so something you can think about as well anybody here using GitLab yeah, lots of hands, awesome so once we have code and we've packaged it and we've chosen the tool kits we like chosen what makes sense for us this is more a picture of a more solid pipeline all right? I give a git review over here a developer does a push, he pushes code and then it executes tasks you do your tasks like I was saying whatever tests make sense for you and then you run jobs there's a job and it's doing lots of jobs and it's testing your code and inspecting it running fan, running PHP unit, running or whatever and then it will package up your code and this is where your artifacts go so you create an artifacts here and then you just take your artifacts and put them in this little box and then you just put them to any server you like once the artifact is there it has a unique name you can put it anywhere you like you don't need to start doing git pools on all different servers package it up and then it's a redistributable thing and it's solid and then you can go put it on a QA server for testing or staging for security testing for example before you do production so deployment now that you have your code and it's packaged up and you're happy with it and you want to start pulling it down you can use Ansible which is a really good tool it's not the greatest tool but it is pretty good Ansible you can have a list of servers that you want to manage and you say okay run this command on all these servers and it can use this rsync so it can connect to a central storage server that you have running a hard drive on the internet somewhere and it can just start rsyncing and pulling down your tar file and unpacking it so that's a good strategy also we can use rpms or dev files which is also very solid so you can do apt get update install or yum for example on centos and so this is also a very solid way to package up your code and put it into versioning systems so rather than just having tar balls flying around you can actually create rpms out of your code pull from artifactory pull from amazon s3 directly or you can pull from the cdn again I was saying it's probably cheaper and faster docker very interesting get lab storage here's some more tools for using capestrano is a good tool has some drawbacks but is anybody here used capestrano more hands awesome there's also something called webestrano which is an interface allows you to see history and manage your deployments so I recommend you check that out if you're using capestrano right now go check out webestrano it's built on Ruby and Rails again but it's a pretty awesome tool it uses docker underneath but it's an orchestration platform built by google that they donated to the linux the linux foundation like the open source community driven linux foundation and now the guys are taking it on so cubanates is absolutely awesome and has a lot of features very very good features also in comparison to cubanates you have docker swarm docker swarm is how you manage your code you have a docker image package it, you put it in the registry and you say I want these 1,000 servers to have the copy of this code and docker swarm will do it for you so cubanates they do things differently but it's the same there's another awesome tool called salt stack anybody heard of salt stack before okay who said a puppet or chef more hands this is better than them and it blows that ansible out of the water salt stack out ansible is not very good because you need port 22 open you need ssh, you need a login ansible just use ssh keys to login to the servers as you and then start running commands on them salt stack ansible salt stack doesn't even use port 22 so you can just like don't even have that port open so it's more secure they're called agents and little agents they sit on all your servers and they have a central salt stack server called a reactor or something like that or a master and it communicates in real time with all the agents and all your servers and it knows what's happening it knows if they're under lots of ram or what not it's really awesome technology so I do recommend you check it salt stack if you're using chef or puppet or ansible go and check it salt stack also it's yamol syntax so it's as powerful as chef and puppet you need to write Ruby code you can use yamol so it's powerful like yamol like ansible but it has all the awesome features so I want to highlight some salt stack there so there's two types of deployment strategies I want to highlight today we have plugin deployments and rolling update deployments so this is basically you have PHP 5 running right now on production and you already have PHP 7 code that you've packaged and you want to update your servers but you don't want zero downtime right? I'm talking like milliseconds you don't have to bring any servers down and then bring up PHP 7 systems like literally no downtime okay who here has heard of plugin deployments okay this is plugin deployments alright plugin deployments is this is central like a load balancer alright and the blue one is PHP 5 in production it's working what happens is we get green and green is like the new guy alright and what we do is we put green into production and internally or under the hood we're not so there's a load balancer and load balancer sending traffic to all your blue all your blue servers what we do is we put green ones in there and we test them we put health checks in them to make sure that you can ping them they respond to hasted dp 200 ok the home page is loading also we can be a bit more in depth and use smoke tests so smoke tests are who's heard of smoke tests okay smoke tests are basically tests that don't like it pretends to be a user but it doesn't do anything important it's can I go to the home page can I click on the navigation can I log in can I update my profile but it's not going to be doing things like can I buy ecommerce items can I go to the shopping can I buy things right that's going to like do real money things because it's a real production server so what you can do under the hood is this new PHP 7 environment that I've loaded I can do more tests because once it passes the smoke tests then it flips a switch like that alright so the blue becomes the green and the green becomes the blue and then what happens is you have monitoring in place with that elk stack the elastic search logs-cabana and you monitor that and if the green one is good that's fine but all of a sudden if the new environment PHP 7 environment is actually causing problems you're getting errors you're getting exceptions in your logs you can flip the switch back you see so that's why we have blue and green alright you've got the new guy you have the guy on backup he's on standby and then you just flip the switch back and the load balancer will stop sending traffic to the old guy and it'll switch it so that makes sense so that's blue green deployments now we have rolling update deployments this is how you get the zero downtime because when you flip that switch with the blue green deployments there is a problem that could happen switching everything to the new so it's more risky rolling update deployments is something that's built into Kubernetes or who's here using AWS Amazon web services keep your hands up if you're using elastic beanstalk under the hood elastic beanstalk is a system that has a load balancer and it has all your servers underneath and if you push updates to one of the servers it does this rolling update system under the hood so rolling update is this what it does is say you've got three servers running in production right now what it will do is this is a load balancer it's sending the traffic to all three of your servers because they're all PHP 5 but when you say do a rolling update with PHP 7 it will take the middle one and it will take it out of the load balancer it will say I am no longer giving you traffic because then we're going to perform a rolling update on you it will upgrade PHP 7 it will put PHP 7 it will pull down your package your code and put it on there then you can run some health checks you can run some smoke tests, you can do whatever you like there's no more pressure you can see when you're ready and then when you say I'm ready it puts it into the load balancer and he's getting PHP 7 traffic and then it moves to the next guy and does the same so then you'll have one PHP 7 and then if you do the same it will have two PHP 7s but you still get the PHP 5 and if any of these failed or health checks you can flip the switch back so things like Kubernetes, Amazon Web Services they do this for you by default but you can roll your own there's lots of tools to do this so that is rolling updates and they're more safe because if the PHP 7 won't start failing at least you still have PHP 5 once still there serving traffic and it's not like flipping a switch and everything's there does that make sense? so that's two by two deployment strategies next and finally so if you have any questions this is probably the last slide so if you have any questions I think there's microphones so feel free to stand up and go to the mics this is a tool called Ghost and GitHub built this has anybody heard of this? it's G H is there a name here? no it's G H dash O S T has anybody heard of this before? okay this is awesome GitHub just announced this open source like last month they use it in GitHub to do migrations in all your repositories with zero downtime and how do they do it? see you have a database migration on a production server and it's going to take one hour to execute or it's going to slow down it's going to slow down your queries because you're deleting columns or you're adding data what Ghost does it uses replication and it's for MySQL by the way it's so smart so this is your current server in production this is where your customers actually getting the data from it creates a ghost table it creates a master slave relationship and this is called the ghost table the ghost table is here it's a replica and MySQL keeps masters and all the slaves in synchronous by using binary logs so it uses the binary log to update so what it does is it clones your current database and it makes a slave out of that and then runs the migration on the slave and it will do that and it will stay there forever until your migration is finished and then when your migration is finished and the binary log is synchronised so the slave is fully synchronised with the master it will flip them back round so therefore your migration the thing you're doing your migration on it's doing it in the background with zero downtime when ghost says ok the ghost table is now the most up to date one it will flip the switch and then the master will become it will go away and the new replica will become the master did that make sense this is awesome technology and it's really good and that's what GitHub have been using this whole time and they've just open sourced it so I do recommend you check that out as well I'll just quickly go to the internet in a sec but yeah I think we're done hopefully you got some value from that the slides will be online so check twitter I'll put the link up and all the things I mentioned all the tools and technologies will be there so I hope some of you got something from that and yeah thank you for your time alright thank you Paul hi everyone I don't know if all of you have been here yesterday but I'm Sherry I'm your emcee for today any questions for Paul you can just speak out loud I can probably hear you or you can meet him during lunch and ask him all the questions you have hi so the question was Amazon S3 is it just for static files like images and stuff or can you put serve PHP files from there you can't serve PHP files from there because it's just it just gives you what you ask it for so it's just like a CSS file right so you can actually change that but exactly you need a server you need engine X or FPM or Apache to actually take the PHP and run the PHP engine and give you back whatever you want the example with S3 was you take your code and you create a zip file or something and then you put it on S3 and then from any place in the world you can just pull that as long as you have the correct permissions or use the CDN in front of it anyone else that has questions there are mics at the back so just head up and no one this is the tool I didn't put the name on the slide I just wanted to wrap up with that last slide there this is GitHub ghost it's just been open sourced and it's already got that many stars and this is ghost so that was that just to wrap up and I'll tweet the slides so you can get all the reference on all the materials thank you thank you Paul now let's invite up our next speaker Timothy Chandler