Hey, everyone, and welcome to developer T. My name is Jonathan Cottrell. And today we're going to continue our discussion on the 12 factor app. Number two is dependencies. And number three is config. Number two is referring to explicitly declaring and isolating the dependencies of your application. And number three is referring to storing the configuration variables of your application's deployment in the environment. Rather than in the actual source code. So we're going to dive right into number two, which is dependencies. But before we do that, I want to go ahead and make the disclaimer that 12 factor app is something that came out of the people at Heroku. Now, Heroku is not officially sponsoring this episode or any episodes of developer T currently. So we are not, we're not trying to, you know, push Heroku as a platform. In fact, the 12 factor application can be actually implemented on any given platform. Heroku just happens to support this idea. And there are some good ideas in the 12 factor app in this kind of methodology in each and every one of these 12 factors. Number two is dependencies. And I want to jump straight in and go ahead and get started. Explicitly declare and isolate dependencies. This is incredibly important because it keeps you from bringing in dependencies into your source code. And it also prevents you from trying to monkey patch or overwrite those dependencies. This is a very useful concept that has been used over and over successfully in many, many applications. I can't overstate this. Gem files and package.json, bower.json. Whatever your given manifest file is, those files are incredibly important and you should be doing this. Isolating your dependencies. And what does this exactly mean for people who are relatively unfamiliar? Well, basically any given code base, like we talked about in the last episode of developer T, any given code base usually relies on something third party. There are very few code bases that are actually built from the ground up with no external dependencies. At the very least, they may haveensionension,ensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionensionension And we're specifically talking about web development at the moment. But typically there are going to be package managers throughout pretty much every language. It doesn't matter if it's web development oriented or if it's system oriented. And typically each and every one of those package managers has a way of creating what's called a manifest file. And what a manifest file does is it allows you to determine what things your app needs to run. For example, if you are creating a Rails application and you need to allow users to sign in, but you don't want to hand roll all of the things that are necessary for a user to sign in, you can add the devise gem to your gem file. And simply run bundle install after you've added it to your gem file. Even Rails itself is added to the gem file because you need to have Rails in order to create a Rails application. If you're using PHP, you may want to check out something called Composer, which is a PHP package manager. So taking a bit of a step back, the basic idea is that if you have third party code, if there are libraries or perhaps frameworks that you depend on for your application to work properly, then that code should be managed through something called a manifest file. And when you are starting your application on a new machine, when you actually deploy your application to a new endpoint, then you ensure that that endpoint actually has run that manifest file. Perhaps the most important benefit of doing it this way is that you can take your code to any machine and run that manifest file. At the same time, you may want toension your applicationijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijij a large amount of code that you aren't even changing. Specifically, you won't be adding all of the third-party code to your repository, which would make your repository unnecessarily large. Instead, you allow all of that code to live on the remote hosting servers that that code base is actually relying on to distribute whatever their production versions of their code base are, and your manifest file simply references those endpoints. This makes the overall size of your code base much smaller, which makes it much easier to share with your teammates, and it allows you to update those external dependencies much easier. You simply change the version number in whatever that manifest file is. A great example of this is the package.json file that node applications use. You can change the version number of that file to whatever that manifest file is. You can change the version number of that file to whatever that version application sees, or you can simply use the semantic versioning number, change the version of the third-party tool, and run the install for that manifest file once again, and you'll have the newest version of that tool available to you. Of course, to execute this, you'll want to take a look at the git ignore documentation. This will allow you to ignore the folders where that third-party code is being installed if it is being installed in the same folders as your application code. This is particularly relevant for front-end developers and those of you who are using Node because wherever your package.json file actually is living is where your Node modules will be brought in. So the package.json file and the Node modules folder are going to be in the same directory. You're going to want to make sure that you ignore the Node underscore modules folder in whatever your version control system actually is. I'm assuming you will be using Git and so you'll want to check out the Git ignore documentation. We'll include that in the show notes as well. I'm going to take a quick sponsor break and then I'm going to come back and talk about number three, the third factor in the 12-factor app, which is the configuration, storing your configuration in your environment. We'll be right back. Thanks so much to today's sponsor, Harvest. Do you know where all your time is going? Do you know how much time you're spending on each feature or tweak or bug fix for every client that you work for? You probably don't if you aren't tracking your time. Now, Harvest is a tool that helps you track your time. It's built for developers. It takes the pain out of time tracking for you because with their official Chrome browser extension, you can start a timer directly from the issues that you have already. Now, not only will you understand how much time you're spending on client work, but you'll also be able to turn your billable hours into an invoice from Harvest in minutes. Harvest integrates with PayPal and Stripe to make it easy to get paid. They also have iOS applications so you can take your timers on the go. You can create a free 30-day trial at githarvest.com. Now, after your trial, you can also use the developer T code, T-Time. T-I-M-E to save 50% off your first month. Of course, the link and the code will be in the show notes. Thanks so much again to Harvest, githarvest.com. Thank you so much for listening to Developer T today. Before we jump into number three, the configuration being stored in the environment, I wanted to ask you if you will take just a few minutes to leave a review in iTunes. This is an incredibly important part of the show's survival. We need people to know about the show. iTunes algorithms, you guys are all smart enough to know this. iTunes has a lot of algorithms that determine how shows are displayed to people who are looking for them. One of the most important things for the show to be able to grow and for the show to be able to continue on is if you leave a review. The reviews and the ratings are incredibly important to that algorithm. If you don't mind, please take just a few minutes. The link will be in the show notes. You can go directly to leave a review for Developer T on iTunes. That would be such a big help. Let's jump into number three, storing the config in the environment. The basic test for this is you should be able to push your code to an open source environment and not worry about any of your application-specific credentials being shared. API keys, passwords, any kind of personal information that you have stored in your source code, that should be moved out of your source code and into the environment. The reason for that is because there should be an infinite number of endpoints that your application is actually launched on. This means that your development environment, your testing environment, your staging environment, your live environment, and someone else's environment, all of them could have the same exact code base and read environment variables. In other words, variables that are set specifically as files or as session variables on the environment, the execution environment on the server that you're using. That is where the information needs to be held. It's the most secure in that location and is much less likely to be used by the server. So if you're using a server that is set specifically as a session and is much less likely to be accidentally shared by sharing your code base, by publishing it on something like GitHub, it's also much less likely that someone would be able to read the environment than to be able to read a given file on your server. So perform that test. Perform the test of looking to find any kind of sensitive information or personally identifiable information in your code. But not only is it a very sensitive information, but it's also a very sensitive environment. So if you're using a server that is set specifically as a session or a live environment, then you need to be able to read the environment. So if you're using a server that is set specifically as a session or a live environment, then you need to be able to read the environment. So perform But code that would disallow you from immediately launching your application on another machine with new configuration variables. That configuration should not be in a flat file. It should be at the very least, it should be in the flat file dot env if you're using something to read that file. But even more secure would be if it was in the environment variables of the server. So if you're using a server that is set specifically as a session or a live environment, then you need to be able to whatever the execution environment is that you're using. For example, we'll refer to Heroku. Heroku allows you to set these specifically using their command line interface tool. So always keep your code in that safest state where you can always share it and nobody will be able to see your personally identifiable information, your API keys, your passwords, even email addresses. These are the kinds of things that you want to store in your configuration. And that configuration should not be in the code base, it should be specifically stored in the environment. Thanks again for listening to today's episode of developer T. And thank you to harvest. If you are like me and you have a difficult time tracking your time, harvest makes that just a little bit easier. You can click a little timer from your Trello board or from a GitHub issue. Harvest knows how to track that issue and gives you a detailed report. It integrates with your code base. And then you can also use the payment system. Go check it out, get harvest.com. And make sure you use the coupon T time for 50% off your first month. Thanks again to harvest. And thank you for listening to today's episode. And until next time, enjoy your tea.