 Okay, so thank you Luca. Hi everyone. I Realized that I'm the only obstacle between you and the coffee. So Sorry about that. I'll try to be quick and Yeah, so just let's start. Luca already introduced me I am Michele from Italy. So I move all my hands in a strange way and I work for the auto which is a small not so small actually firm in Chizena, which I don't expect you to know where it is. But Well, what to do? We are a software house specialized in web projects. So less or more we do this. No, wrong slide. That's the card one. Okay, we use open source technologies like PHP, JavaScript, Node.js, other PHP frameworks like symphony and and obviously WordPress. Okay, so let me ask a question. How many of you are developers? Could you raise your hand? Well, good a lot. And which is your platform? Which laptop or workstation do you use? How many of you are Windows users? Mac users? Okay, Linux? Yeah, good. Okay. And how many of you just want me to stop asking question? Yeah, good. Not so much. Well, are you satisfied with your workflow with working with several platform and installing your project and configure it on your platform? Well, we found out that in our case, project setup and configuration can be a bit painful and time consuming. I mean, WordPress installation is really pretty straightforward and fast. But as time passes, if the project grows in complexity, well, it might be get a little difficult. And, for instance, if you installing some plugins, like the Twitter cache, which maybe use man cache or stuff like that, again, it's not so easy to configure it. And things get a little worse. If you have several clients, and this means several projects you are following and working on. I mean, don't get me wrong. Having several projects is great. But if you try to put them all in one machine, well, we found out that it's a bit painful because you waste time for configuring every time on your machine. And maybe if you're part of a team, this operation is repeated again and again and again and again and again and again and again. Okay, that's probably fine. But it's just a waste of time and money. And our job is to try to deliver value for our clients by releasing software. Okay? Again, another problem we find out with having all the projects in one machine, on your physical machine, is that basically trying new things is difficult. Okay? Without messing things up. Okay? Let's say I'd like to try the new PHP interpreter released by Facebook, HHVM. How many of you have heard about that? Okay, not that much. Okay, my opinion is quite cool. It's a really performant interpreter which can give you a really good performance increase. And as you heard before, in the previous presentation, speed is important. Okay? So what if you want to try on my machine? Yeah, I have to maybe mess things a bit. Yeah? HHVM. VM. That stands for E-pop virtual machine. Okay. Or let's say I'd like to try this plugin, but I'm afraid that thing will get messed. Yeah. How can I do that? Okay? There is a way to do better. Okay, can we do better? Yeah, well, we found a way. Virtual machine can help you in this task because every virtual machine is a clean, separated environment. Okay? And you can configure it, installing it. And if things doesn't work, you just can destroy it and recreate it. And you don't have problem of conflicting projects. Okay? Conflicting libraries. You can try a new version of a plugin or new version of PHP or whatever you want. So that's cool. But still, installing and configuring, again, virtual machine manually is a really boring task. Okay? We are in the same loop. We are the same before. But there is a really nice tool, which is called Vagrant. That can help us in this task. Basically, Vagrant is a command line tool for managing virtual machine. It supports several are called providers, which are basically programs that can run your virtual machine. Have you ever heard about VirtualBox? VMware or stuff like that? You can also create a virtual machine on the cloud, for instance, on Amazon EC2, if you want. That's really cool. Let's see how it works. Yeah, well, from the command line, you just need to Vagrant in it, and you pass a string, which is basically the name of a box. I'll call this in a bit. After that, with Vagrant up, a virtual machine will be created and configured for you. You basically have to do nothing. You are done. Okay? You have a virtual machine ready to work. If you want to change and customize, as you probably will, the configuration of the machine, all the information are in a file called Vagrant file, which is created when you issue the Vagrant in it command. Okay? I don't expect you to be able to read everything, but don't worry about that, because I'll cover the main configuration you will see here. You see here. Let's start from the boxes. Okay? A box is basically a virtual machine with a really basic configuration, okay, that will be used as a template for your project. So you're basically here saying, okay, just please create me a new virtual machine starting from this template. I should call pre-seize64, which is the Ubuntu distribution, the Ubuntu release. You can choose different standard templates, and they have a really basic configuration, common configuration, in particular, all have a pre-configure used, which is called Vagrant, with the password Vagrant, so you can enter in the machine. You can search available boxes here on Atlas by Ashikorp, which is the company which develops Vagrant. There are really, really a lot of boxes, starting from the really basic configuration, so you have a really plain and empty machine, or going to a fully configured machine with PHP, the web server, everything you need. So it's up to you. Another quite good site, in my opinion, where you can look for boxes, is VagrantBox.es. These are not official boxes, so, yeah, just, you can take a look at that, but I prefer the first one. Okay, so let's go on. Another parameter we can customize is how we can reach the machine, so we can decide which IP address assigned to the machine, and we can decide also if the machine we are going to create is public, which means that is visible on the network as a real physical machine or is private, which means that the machine will be available and will be seen only by our physical machine. Okay, I prefer the latter because for security reasons, okay, but if you need to maybe share or you just want you to show something to your colleague or your team, yeah, just go for a public network and you're done. Another really, really important thing, it's possible to share a directory, one or more directories, actually, from your physical machine to the virtual machine, okay, with this directive. It's really cool, in my opinion, because you can still use your favorite IDE, okay, you don't need to go to log into the virtual machine and maybe use a Luzi editor, you can still use your favorite IDE because the code will be both on your machine and in the virtual machine. And it will be updated in real time, so you don't have to do nothing. There are three main ways in which this sharing can be done. Every provider has his own, sorry, has his own native way to do this, let's say virtual box has his own way, one way or another, and so on. There is NFS, which is a network protocol for sharing the file systems, but it doesn't work so well on Windows, so sorry, Windows users. Or ErSync, which is again a tool for syncing two directories, two remote directories. What else? Yeah. Which is a nice configuration, if you, how many of you use GitHub, Bitbucket or service like that, okay, if you're working with private repositories, you for sure have an SSH key installed on your machine, and if you want to use it on the machine, you don't need to, on the virtual machine, sorry, you don't need to copy that with this configuration, you're basically telling, yeah, just forward, so use the key I have on my machine in the virtual machine. This means you can clone your repository from GitHub inside the virtual machine without any further configuration. Again, it's quite cool in my opinion. Okay, here are some common sense settings. You can change the host name of the virtual machine you're going to create. This is quite common, in my opinion, if when you log into the virtual machine, if you're using the command line, you have to see that you are inside it, okay? Otherwise, there will be a default name assigned, and if you have a lot of VM on your workstation, you will maybe do not get actually on which machine you really are. And you can choose to customize how many resources you want the assigned to the virtual machine here. Basically, we are saying that we want to assign four gigs of RAM and four CPUs. Another really, really cool things, which is a really time saver, in my opinion, is, okay, I have my virtual machine, but probably now I need to configure it again. So I need to start to install a patch, or my SQL, or whatsoever. Yeah, you can do it, and actually, I will show you that I feel I've done it one time, you can share it with your other team, so probably it's fine, but there is another way to do that that is more efficient, and it's provisioning. Provisioning is about configuring and installing software on the virtual machine, okay? In an automatic way. There are a lot of tools that allow you to do that. Puppet, Chef, Ansible, or you could do that by batch scripts. It's really, really cool. Here, there is an example of configuration with Puppet, and here's this Puppet code, which basically does two things. One, install a database, and two, creates a file. Okay, here's an example of how you can configure and start software in a fully automated way on your machine, and you do need to do basically anything else. Okay, it makes sense to you. Just want to have coffee. Okay? Okay, me too, so. Okay, so let's keep now through the most common comments, sorry. Again, I already showed you, vagrant init and vagrant app, okay? The first create a base vagrant file in the root review project, and the second one basically spin up the machine and install all the software. If the machine is already created and is already active, and you just want to reprovision it, because maybe you changed some configuration, vagrant provision is the command to do that. When you have done with the work, and you just go out of the office and have a beer, you can stop the virtual machine with vagrant alt. The machine will not be destroyed. It's still here, and it's still working and all configured. So the next time you will start it with another vagrant app, all the work you have done will be here. If you change some configuration on the virtual machine itself, let's say I want to give the machine more RAM, let's say 8 gigs instead of 4. Well, after that, you need to vagrant reload in order to reload the machine and apply the changes. If something goes wrong, or basically you just want to free space, you don't need the machine anymore, you can vagrant destroy it, and the machine will be totally destroyed. So on the next vagrant app, that will be recreated from scratch. So let's go, let's skip to some common usage pattern. We tried the first one. You have one virtual machine, and you have one project. Okay. Here is an example of a possible code layout. Let's call about that. In the root of the project, you have the vagrant file, and you have another directory, which is called the vagrant by convention, but you can call it however you want, which contains the further configuration, for instance, puppet files, or other configuration files, everything you may need to configure, or that might be useful for the virtual machine you're going to create. And then there is the rest of the code. In this case, the rest of the WordPress code. It's plain simple. So basically, when you want to start working from the command line, you go to the root of the project, you vagrant app, and you're done. In this case, you need to configure the folder in this way. Basically here, we are saying that we want to share the current directory to, well, a directory inside the virtual machine. So in this case, our working directory will be shared inside the machine on the virtual machine. So this is a pretty common pattern. I've seen it in a lot of different situations. Every project is self-contained in this way, which is quite cool. But you might end up having a lot of virtual machine, and if configuration doesn't change that much, maybe it's a waste of space. So there is another quite common pattern, one virtual machine and project. The layout is a bit different, as you can see. Basically, you have all the configuration regarding a set of projects in a separate directory or probably in a separate repository. You have a vagrant file and, again, a vagrant directory. And then you have several projects at the same level. Well, basically, when you want to start working, you go on the VM config directory, you vagrant app, and then the machine will be split up. After that, inside the virtual machine, you will have all the project which are the same level. In this case, project one, project two, project three, and so on. In order to this thing to work, you need to configure the share folder in this way. So basically, we are saying that the parent directory should be shared on slash var slash www. When you enter in the virtual machine with vagrant SSH, if you go on slash www, you will see all the project directories all there. This setup is quite useful if you have a project with very similar configuration, and you don't need to duplicate that. And for related project, let's say you are using, for instance, WordPress as a backend for creating posts and pages and stuff like that. And there is another application that using rest APIs gets article and posts from WordPress. In this case, this application are related in some way, so it might be a good idea to create one virtual machine for us both. So after that, let's say you have created, configured, installed your machine, and now, probably, if you work alone, you are done. But if you work with a team, you probably want to share this with your other colleagues. Well, you have two ways of doing that. The first one is the, let's say, the lazy way, okay? So I have already done the configuration and it's present on the project, as I showed you before. So basically, your colleagues downloads, check out the code, vagrant app, and the machine gets recreated. And you are done. Still, you can do a little better, in my opinion. There is a pattern called, that's more golden image, okay? So, after you created and configured the virtual machine, you can pack it and distribute it to your team. How can you do that? Well, it's quite simple. With vagrant package, again, in the root of your project, and you choose a name, in this case, it's my box. It's not really a clever name. But still, it works. And you're done. Okay, we've recreated a fully configured virtual machine for your provider. So if you're using virtual box, for instance, the box will be compatible with virtual box. And after that, you can put the virtual machine in a USB key or put it online and whatever. Your teammates can download it and add it to their local machine with vagrant box ad. The name of the box and the path of the file. And inside their vagrant file, they can choose the box you have created. And they're done. When they start the machine, there will be the machine totally created and configured. They don't need to do anything else. Okay, still makes sense? I hope yes. Okay. What else? Yeah, another couple of things. Yeah, if things gone wrong, or if you want to test something with your colleagues, there's a way to share your local machine to open it to the internet. The command that allows you to do that is vagrant share. There are basically two ways, HTTP or SSH. In both, you will give less or more a link, you can pass to your teammates, and they will be able to enter the machine or to view it. That's actually I've never used that, but actually only one time, but maybe it's useful. Okay, what else? Ah, plug-in. Well, plug-ins are a really cool way for vagrant to extend its functionalities. There are really, really a lot of plug-ins available, ranging from new providers, okay, you can create the auto machine, for instance, and put it on Azure, on Amazon, on Rockspace, whatever you want. Provisionals, so Chef, Puppet, Ansible are available by default, but there are much more you can enable by installing plug-ins. And various kind of management, for instance, host management. In particular, I will return it on it in a bit. If you want to check what are the available plug-ins, there are two links. How do you install a plug-in? Well, it's quite simple, actually. Vagrant, plug-in, install, and the plug-in name, and you're done. I recommend installing two plug-ins, which works very well. If you're using Virtobox, VB Guest, it's a way to keep updated the guest edition on the machine, which is a tool used by Virtobox to manage shared folder and stuff like that. It's quite important to keep people updated. And if you install it, it's done it automatically, so just install it and forget. The second one is host manager. And this is quite cool because it modifies your local host files, which means that, well, as I said before, we have assigned an IP number to the virtual machine, but at least for me, when I work with my project, I like to open my browser, enter a real name, real domain name, and then view the site and working on. Yeah, with that plug-in, you can do it automatically. Let's see how it works. This snippet of code is meant to be put again in the Vagrant file. There are two main important things. The first one, just check the plug-in is installed because maybe your teammates still don't have it. And if you don't put this check, Vagrant will complain about that. It won't work. And the second one, the last line of code, basically here we are saying, just please add www.myproject.local to your host file. So when a Vagrant app, in an automatic way, this host name will be added. And if I open my browser and put this name, it will work. I will access the site, the project inside the virtual machine from my browser. Okay. So there is not much more I want to tell you. Just drop up what I'm telling you so far. So you try to configure your project. Well, we found out that Vagrant can help you, especially if you are a team. Okay. You don't have to do the same things manually again and again and again and again. Which is quite cool. If you are alone, well, the nice things about Vagrant is that you don't have to actually share an environment between all your projects. Okay. And you have time for trying new things, experiment because you spin up a new virtual machine, try something, if it doesn't work, well, you destroy it and you're done. And you're not messing with the other projects. If you work in a team, that's again really, really good because you can share configuration and in general knowledge about your project quite easily. So I suggest you to give it a try. Okay. So I'm done. That's all. Thank you for listening. And if there are questions, I am here. And after that, after the coffee, I will answer to all your questions. Thank you. Just a quick question. What's your thoughts on using Vagrant versus Docker for WordPress development? Okay. Which is the best, are you saying? Or why should we use Vagrant? Why should we not use Docker? Should we use both? Should we choose one? Yeah. Okay. Well, if you're using Docker in production, so yeah, just use it in your machine because it's simple. Okay. But yeah, please. Well, we tried it and it's quite good, especially for testing in particular. We do a lot of automated testing. It's Docker it quite more fast than Vagrant because virtual machine can spin in minutes. Docker works in seconds. But setup is a little bit more complicated. Okay. But still, again, if you are using Docker in production, I suggest you to use even in development. Or if you're doing a lot of testing, Docker can help you. Actually, Vagrant supports Docker as a provider, which means that you can create Docker containers configuring it in the Vagrant file. But since Docker works only on Linux, because it's based on a technology which is available only on Linux, if you're trying to use it on a Mac, actually, it will create a virtual machine and install it Docker inside it. So it will be a less performant that the ideal way which is use it on Linux and you're done. Yeah, I've seen it use it in some cases, especially for testing, which is really, really performant. It's a good tool. There is next question here in the front. Can you talk about how you integrate S. O. N. or get into the virtual box so that you actually push changes to the machine? Okay, thank you. Well, actually, I'll go back some slides, some slides. Yeah, with this configuration, actually, you're telling to Vagrant that you want to use the key that are on your machine inside the virtual machine. So if you have your GitHub key is configured here, they will work inside the virtual machine inside the machine, you just need to install it. And then you get clone your repository and it will work because when you log in on the machine with Vagrant, the keys you have here will be magically imported inside the VM and you have to do nothing. Okay, I answered your question. That's more. Well, thank you very much. Thank you.