 Yeah, so as I said, I'm gonna talk about programming your infrastructure. And that is treating your infrastructure like the programs that you're actually running on them and treating it in a writing maintainable code for your infrastructure. So I wanna start out by just talking about a scenario that you might face in your company. Oh, no, one slide that I didn't start at last minute. I actually wanna talk about sharing. So we've seen the columns method in the past, the columns acronym. Developers have a lot of things to share with us. And so that's what we're gonna try and do today is take something from developers. So the scenario that I was talking about, you have to build some new infrastructure. You decide, hey, I'm gonna automate it with Chef. I'm gonna write this really awesome Chef code. And everything seems like it's unicorns and butterflies. But three months later, you run into some problems when the head honcho says, hey, we need to add some more capacity. One of the other engineers tries to run your cookbooks, but they fail, you end up with services not running, and everything starts to break. And not even you really even remember what that Chef code was doing in the past. The problem that you ran into is that good code there in the corner is really hard to get to. And you didn't quite get there. Writing good code is really difficult, but programmers have been doing it for quite a while and they've gotten pretty good at writing that maintainable code. And one thing to do with that is to keep in mind, somebody else can end up with your code and they might be a psychopath to know where you live. So to actually get into writing maintainable code, Sandy Mets in the Ruby community, she had five rules that she had written at some point where she basically says to keep our code small, keep our code reusable. Because at the end of the day, we are gonna change jobs and we are gonna have somebody else maintaining our code. That's just the truth of the world. As you see there, 4.6 years is not a terribly long time. So yeah, we have to start with small and reusable code. And that means if we're writing a cookbook that installs Elasticsearch, it should install Elasticsearch. It shouldn't install Logsdash or anything else. Your recipe for Elasticsearch should do just that. Because in six months, you're not gonna remember what everything was doing. You should be able to look at those files and start to comprehend them very simply. The other part of that is that we have to start commenting our code. We can't just have a recipe that's nothing but code because at times we're gonna have to do weird and janky things like write a long Ruby block that just waits for Elasticsearch to be green before we continue on. So keep track of what you're doing. And keep track of the code zombies that you commit. You know at times when we're commenting code, we'll actually comment out blocks of code and those will sit around and frankly all they do is cause confusion. So don't be afraid of the delete key in your programming because why we use version control and things like that. Because at the end of the day, we can always go back to code that used to be in the repost story. And yeah, there are all these tools for this. In Chef, we have ReboCop and Chef's Back and Food Critic and things like that. So now that we've talked about writing maintainable code, are we really writing the best code that we can write? Not quite, we don't actually know if it works yet. We have to start testing our code and writing automated testing and really getting in there and making sure that our code works. So there's three methods of tests that we usually talk about. There's unit testing, which is simply how does that code work in a vacuum? Integration testing, which kind of gets into how does it work with the rest of our project? Not acceptance testing, which talks really about how does that code work in the wild and does it work in the wild? We also get into our code coverage, which simply says how much of my code is actually being tested. That gives you hints as to when things break, where are they broken? And the hint is, it's the code that's not being tested. Anybody who says, do I have time to do this? If you say that you don't have time, you're wrong. Because debugging issues in staging or in production is gonna take a lot longer than actually writing the test themselves. Again, we have lots of tools available to us because how much do we love our tools? Chef has InSpec and Ansible has InSpec too. But there's molecule and infinite numbers of tools. So now that we've done this, we are now testing our code. We're now writing good, commented code. We can put it down for six months, go work on something else, or go sit on a beach and take it and get drunk off our asses. And then we can come back, we can come back for a code. So I fit a lot into this talk, but there's a lot of people who are a lot smarter than me at doing this kind of stuff and they've been doing it for a long time. Definitely pick up Keith Morris's new book, Infrastructure as Code, if you haven't yet. It's a fantastic read. So as I said before, I'm Dave Long, Dave J. Long on Twitter. I'm back at the Caged Data booth outside for the rest of the afternoon. So come and find me a love talking about this kind of stuff.