 Hello, and thank you for sticking with me. I know that it's almost lunchtime and everyone is hungry. So I would like to start this one with a story. I had this great-grandmother. She was very nice and elegant old lady. And she was telling me the story how she got married to my grandfather. Back then, the marriage was arranged and her father did not agree with her choice. Because my great-grandfather was very poor. So she ran away from home, married him anyway. And by December they had their firstborn. And it was time for the harvest. And she needed to work anyway because they didn't have money. So she was going there with the baby, hanging the crow on a tree, and working the whole day under the sun. And she was telling me that there is no way that I can understand how she survived that, because we don't do that anymore. No one is going to do that manually. But when I was a kid, I grew up in a small village, and I had the chance to be on one of these machines that are doing that now. It's air-conditioned inside. And it's doing the job that otherwise hundreds of people should do manually. And it's doing it so fast. It's a very powerful machine. So that's just a small example how machines and automation help our life. In our job as developers, we probably can't do such a huge automation like this one. But still there are so many tools that can make our life easier and help us do our job faster and not repeat manually all the tasks that we have to do every day. So there are a few things that we can automate. We can spend less time on developing code, and we can track errors easily. We can check for all the standards that we need to keep. And, of course, we need version control. It's a very good idea after that to test our code and deploy it safely where we need it. So, how many of these tools do we need? There is not a great answer on that question. There are a ton of different tools there, and you announced all the time. And, well, it really depends on our organization, on our specific team case, and the projects type, and so on. So, just enough is the best answer, I think, like it depends what you need to customize, what you need to do every day, and how exactly your organization works. But still, I hope that the things that I found useful in my development job will help you at least give you ideas how to do that for your case. So, let's start with the very basics, the editor. Whatever you prefer, if it's IDE or it's a text editor, it depends on the preferences. And I struggled with IDE for several years. One day, he started making more noise than the washing machine. So, I decided that it's a better idea to find something quite, and something that I can extend and customize for my specific case. So, my choice is ATOM. It's a new editor built by GitHub, and it's actually a specialized version of Chromium that is designed to be text editor instead of a browser. It's highly extendable, that was the idea behind it, to be very easy to use, so even a school kit can use it, and also to be very extendable. As talking of flexibility, we can look at the editor plugins, almost every editor has it. And ATOM is even easier, because it has built-in package manager, so you can search for packages and install them inside the editor, or also start writing your own. And a few that can save you a little time. Terminal plus brings Terminal to your editor, so you can browse over to Terminal while you're writing code. Outcomplete, it's small thing, but it's very important. It can be installed for different languages, and there are several written for WordPress, for the WordPress hooks and actions. And, of course, the documentation, Dogbroker. It's a very useful tool that allows you to leave comments in the code for documentation to explain the next people how this is working. If you're starting to write a comment, and the next line in your code is function declaration, it will automatically detect it, and add lines for documentation, for the parameters, and so on. And stalking as code that will be more readable, let's take a look on the standards. There are so many that we keep. PHP standards, JavaScript, standards for WordPress, of course. And we will, from time to time, forget them. So tools to keep this in mind is like PHP code sniffer. It's essential development tool, and it's actually created by two scripts. One is checking the code for errors, and detect violations of particular standard. There is, of course, standard for WordPress, which you can download and install. And the other script is actually helping you to automatically fix the styling or code problems. There are also linters. There are small programs to detect styling errors in the code, and you can add them as a package in your editor, and see in real time when you are writing code warnings and errors if you missed something. You also have GS Hint. It's a tool for JavaScript development, and it helps you detect problems in the code as code grows very big. You can't actually check every line, and debugging takes a lot of time. So GS Hint helps in defining bugs and showing you where there are problems. To automate more things in one actual tool, you can use Go, which is a task built runner, and it actually can automate everyday tasks like minifying, erlifying, and wife rewarding of the browser every time when you change the code. Of course, there is also Grunt, which is kind of the same thing. There are both Node.js built task runners. Grunt was around for a longer time. It also, as Gulp has a ton of plugins, there are different opinions, and one people prefer one versus other because of how exactly the configuration is written. So what you prefer here is on your choice. And after all these, let's take a look on the version control. Version control is essential for every development. So you can... Version control is a system that records changes in the files, and allows you to recall specific version later. So you can track when changes are made, who made them, who introduced the problem, and so on. And of course, you can recall the old version if something goes really wrong. Some useful tools that you can add in your editor is git time machine. It helps you travel in time. So it shows you a plot of commits over the time, and clicking by them is showing you every change in that file that happened in the particular commit. Another one is merge conflicts. Two, it detects merge conflicts introduced by git merge, helps you to navigate through them, to choose your version, their version, combination of both, and then, of course, at end stage, the ready changes. And let's take a look on how we actually start working. We need a worker install. And there is no crazy fast way to do that. Let's say that you have 10 colleagues, they already installed a ton of plugins, they configured the WordPress install, and they're in the middle of the project. You need to join them, and you need to have the exact same thing locally. There are different tools that can help with that. At Cloud Favorite, we use Capstrano customization for that. It's usually used as a development, but it's also automation tool written in Ruby, but can be used in any language. And while we customize it to be able to create and set up worker installs with just several commands, that are just some of them, so it can help you create worker install, grab the database from a local server that already your colleagues supported there, so you have the same database ready. It also helps you to update that database if you're making changes and so on. Also, if there is a new version of WordPress announced and you want to test your project on it, you can change it with just one line command. It will just grab the version from the official WordPress repository, install it, and you have all the configs set up. Similar is to think you can do with Mac revigrant, you can actually mimic your production environment, and you can start developing the code on it. It's vagrant HHVM environment tool, and you also will have caching options as varnish and memcache, testing options, debugging, and so on. Also, setting up a worker install is pretty easy. You need just to set up a configuration file and run vagrant. And of course, here's WPCLI, which is a managing command line tool for WordPress. It has a ton of useful commands. Some small examples are for, of course, WPCLI, which can install WordPress for you locally and so on. And of course, plug-in install the entity management with a lot of sub-commands, so you can disable, enable teams, install them, and so on. And as going to the next level with that, there is a new tool that is in development called WPCLI, which is actually introducing the REST API in a command line tool. It detects how to discover the REST API endpoints and register commands for them, so you can use the REST API in your command line. At some point, I hope that this will be able to help us create local databases from production environments, for example, to be able to test the production changes locally, but that's still in the future. And after we've done that, we've created a worker install and we've done our changes. It's time to test the code. And here is time for another story. I had the honor to have this guy as our CTO for a while and one time in our call, he said something about testing that I want to share with you. He said that in his many years of experience, in a long-term project, it's most likely one of the two things to happen. Either the client will change his mind about some smallish part of the functionality to who that happened. Everyone, I guess. And either the developer will forget how exactly the code was written and what it exactly does. That's one of my favorite Stack Overflow comments from a page with hilarious comments in the code, so I guess that this happens to everyone, too. So, yeah, testing is really important and we'll talk about mostly acceptance testing. So, with acceptance testing, we can test new features, check compatibility with old code and actually check it from different points of view how the users are actually using our code. So, code exception is a tool for that. It's actually a full testing tool. You can do unit tests, functional tests and acceptance tests. In the terms of acceptance testing, there are a few models that you can use. PHP Browser is one of them. It actually is PHP Scrappers, it sends and receives requests. So, you can test a lot of things with it, not everything, of course. You can do assertions if some elements are on the page or they are not. You can also fill forms, send them and so on. It has some limitations, like if the fields are not informed, it can't actually fill them. It can't click on URLs if they're not in specific text and so on. So, here helps Web Browser with Selenium server. It actually is a model that helps you run Web Browser from PHP. So, it actually performs the actions that you need in particular scenario that you want to test, and it performs it in the browser. It's slower than PHP Browser, but it helps for testing of complete application with a lot of JavaScript. And also, there is WP Browser, which has all these useful models for specifically testing WordPress. It's also on GitHub in its open source, and there is a huge study on the code section side about the WordPress-specific testing. So, you can take a look and choose which one will be best for your case. So, after we finish with the testing, there is the next step, the deployment. So, we have been to the stage with the FTP deployment or just even changing something in the WordPress editor. But after all this effort to create clean code, test it and so on, we need, of course, a safe tool to deploy it. There are a ton of deployment tools, and I'll mention just two. The first one is, again, Capistrano. I obviously like it. And it actually has so many useful things. So, you can choose on which stage to deploy, like you can have dev, staging, production, or whatever stages you need. It also saves the release, how many you need and so on. So, if something goes wrong, you can just go back. Also, you can see in links some folders that you don't need in the deployment, like a Prodors folder. So, it's not touched during the deployment, and you can ignore files, of course, that you don't need to go on the server. It's not very easy to learn it, but it works really well on most of the cases. Of course, if you don't want to spend that much time to learn and set up a specific deployment tool, you can, of course, use what you already know, Git. So, you can set up just your server, like a new remote, and just Git push the code there. It's also more safe than FTP deployment because you can go back, and most of the hosts are supporting it. So, there are a lot of pros and cons on all that. There are a lot of white and black things. It requires a lot of time to learn these tools. It requires time to set up them. It requires time to teach your new members of the team how to use them. But if you do all this effort, and if you automate most of the things that you do every day, and it works really well for your specific case, writing a code can be just like a symphony. Thank you. I'm Ivelina. That's my Twitter handle. I work at Cloud Favorite.