 Our next speaker is Melanie Crutchfield, who joins us from San Diego, where she organizes the local Python user group and Django girls, and I think somehow also has a day job. She is also the creator of FIVEUP, which is a free Django-powered service that sends you happy texts every day. She enjoys helping people learn how to program and is running a pretend lawn-centered conference called Grasscon that also somehow happens to be right here in Petaluma this weekend. So you should ask her how you can attend. Melanie is going to share lessons on how to get started and how not to get started with Django as a beginner, so please make your feel welcome. Thank you. I know we're all nervous, I can tell. You have that whole, like, will I like this, or will I hate it, or will I cry? But I gave this talk once before, and only, like, one person cried, so. It was me in my hotel room earlier. Wasn't me. I don't do that stuff. There was totally me. Anyway, now that we got the vulnerability out of the way, and we're all best friends, I'm going to give a talk now. I'm Melanie, and that presentation is unexpected, so we'll see how the rest of this is going to go now, in fact. I've also gone over my face. It's still there. I am a newish Django developer. I don't know why you're here. It's possible you came for donuts, and instead you got just madness, which is also tasty, but we don't have donuts here unless someone has them and didn't tell me because they're mean. But if you're here for Django and Python or for donuts, I know what I want you to get out of this talk. Here it is. Not too long ago, I was diving face and brains first into my very first Django project. There was a lot of chaos. I know it seems unlikely, but it's true. There was confusion and calamity and carrots. Not so much on the carrots, actually, but I like alliteration, and it was just swirls of expletives and face palms and general madness, and I made a lot of really costly mistakes that, it turns out, are decently avoidable. So that's what I am to give you. I want to take you through the beat by beat postmortem of all of my flailing mistakes so that you may avoid crying on your keyboards and vomiting on your rubber ducks. Not that I did that again because I'm super cool. Here we go. First up is throwing house parties without causing anaphylaxis, as one does. I was told to use something called a virtual environment, which I disregarded immediately because I, if I believe in anything, I believe in laziness and climate change because of science, and that the toilet paper goes over and not under because I am a decent person. That's what I'm saying. I also didn't totally understand what a virtual environment would do for me, and I certainly wasn't going to unlazy myself for no good reason. So let's take a look at that really quick. So a quick note on this. This is a rather long analogy, so we're all just going to pretend that we love long analogies because we're best friends and you want to give me that. Thank you very much. And you especially like the ones with bad drawings. You guys are great. So let's say that you've built a big, lovely house with a massive living room. It's like super big. It's so big that you haven't even bothered to make other rooms because why? The living room is big enough. And so you have some friends and they come and they say, we would like you to host a party in your gigantic living room to which you think, great, I have plenty of room because again, my living room is large. So you tell them, OK, your friends tell you what they need for you to provide. They need classical piano music. They need ham sandwiches. And critically, they cannot have any peanuts because every last one of them is terribly allergic. You can do that. You're an adult. So here comes the second group. They also would like you to host a party for them in your big living room. They need classical string music, turkey legs and bottle rockets for some reason because they're odd. Everything works fine. The music is a little bit different. The food is a little bit different, but it doesn't harm anyone. The bottle rockets, as we discussed, is quite strange, but no one gets hurt. So that's fine. So when the next group comes and asks and they say, we would like to have a party in your living room. You say, I'm super good at this. There's kind of already two of them there. Obviously, this is my jam. They've thrown the same party elsewhere and they have all their own stuff. They don't need you to provide anything. So you just let them do their thing. However, it turns out that while you weren't looking, the third group has thrown a whole host of peanuts everywhere. And your first group is dead. They're so sad. Like they got sad and then died. How does any of this relate to Django? I don't even know. I do know. I do. I promise. The first group of friends is your first project, right? Everything works. Everything's fine. It's all by itself. The second group is your second project, which is a wee bit different, but not a big deal. But the third project will say maybe it has a different version of Django or a different version of Python. And once you've installed the requirements file, your first project blows up, which is a bummer. Which brings us back to virtual environments. The logical solution for not becoming a mass murderer via pine peanuts in your house is to build rooms. And you put each party in its own room and then no one kills each other, which is ideal for throwing parties just in case anyone was thinking not. Virtual environments will do the same thing for development. You can look this up in the documentation, but here are some quick basics. I'm not going to go over how it works in Python 2 because we're all using Python 3, right? Of course, we are long-lived app strings. Good job, everyone. That's correct. Virtual environments are built into Python 3, so we don't have to install anything extra. We just type Python 3 dash m, v-e-n-b, and then the name of your virtual environment, which is full of peanuts, in this case, ops. You need to activate the environment. Otherwise, Django is just going to grab whatever is hanging out on your system. And that's like going back into the living room instead of going into the rooms you've so thoughtfully built. So what we'll do is we'll type source, and then the name of your project, bin, activate. And when we press Enter, it will tell us that we've activated the virtual environment by putting the name of the environment at the beginning of the prompt. So now we can wreak havoc all we want. Now, there's another tool that, although it involves installing a separate thing, which interferes with my laziness, it actually enables more laziness later. So I've started using it. It's called virtualM for wrapper. And we install it with pip install virtualM for wrapper. And then, oh my god, we have to take another step by adding some stuff to your bash profile, which you can look up later, but it looks like this. So this is two steps now, and I'm getting exhausted. But it allows us to do this. When we want to make a virtual environment, we type mkvirtualM and the name of the environment. And it both creates the environment and activates it. Holy moly. Then later, if we want to work on it again, we type work on and the name of the environment. And it activates it. So then we don't have to do that whole project name, bin, something else. I don't remember. It's much easier. Did you forget the name of your environment? Of course you did, because you're a human person. And that's fine. You just type work on, and then it reminds you, because it's not a human person. It's a computer. So that's great. OK, what did we learn here? Use virtual environments, and no one gets hurt. OK, I do want to mention pip nth, which is a new fancy thing that all the kids are into. It's like a mashup of pip and virtual environments. And I think it does your taxes or something. I don't know. You might want to double check on that last one. Moving on. Saying no to sea monsters and yes to pregnant daddy sea horses with Django. When I started my first project, I understood myself to be making a web app. You're building an app. Got it. So when you're looking at the commands that you use to create a Django project, we use start project to start it. And then we use start app, which is obviously still kind of your web app, I suppose. So in my mind, we started a project. We started one app. And then we would shove everything into that one app, because why would you need more than one? Well, there are lots of things that you typically need to do in a Django project. In FiveUp, my tiny little baby project, I have to store a collection of messages that I curate. I have to store messages that users enter. And I have to schedule and send messages. Providing this functionality requires a bunch of models and views and other fun stuff. And if I try to make one and only one app, it starts to look kind of monstrous. If you just have one file for your models and everything, it just gets bigger and bigger and bigger. And the same thing is going to happen with your views. So now when you go back to try to change something specific, it's kind of like a miserable task and scary. We use apps to avoid this horrible, disfigured mess. But we don't want to do it just arbitrarily. Like, this is getting weird. Let's start another one, because that's also not going to help you find the code that you want. So what we do is think about each thing that needs to happen. And we'll put each thing into a separate app. So with FiveUp, I started off with everything jumbled into one app called FiveUp, because I'm creative. But eventually, I transitioned to have an app for curated messages, an app for custom user messages, and an app for sending messages, as well as an authentication kind of monstrosity that I made and accidentally named F-U-O. Because my project is called FiveUp, and I was, anyway. So what we've done is, instead of taking our baby seahorses and gluing them to the dad's head and neck and tail and feet. Nope, not feet. We've left them all as their little adorable selves and put them in the protection of the daddy seahorse. And there it is, and it's real cute. I know. OK, so I know it real quick. I decided on this analogy before I looked up a daddy seahorse and they are terrifying looking. So unless you really like nightmares, don't look that up. Protecting your velociraptors with Django. In my voyage through my first Django project, I came across a blog post that told me to save all of my static files locally. Sorry, person who wrote that. I lost the blog post and I forgot your name and you shall die in obscurity. No, I'm kidding. You're so sad. But for real, I don't know who it was. So this means when I was using Bootstrap, in addition to linking to the CDN, I would save everything locally, recalling that I'm excessively lazy. This did not sound like something I wanted to do. I mean, why? I will tell you why. So let's say that I found this amazing jQuery thing, something that does this, something that does nothing, something that's the worst. Nope, it's not that. Okay, this is sad. I'm going to take you on a visual journey in your mind now because we're best friends and that's what we do for each other. So when I got to this slide, I said something interesting and I prepared you for something exciting. And then in your mind, a dinosaur appeared over here and it went across the screen and you said, wow. Right? I know. My thing was like a modal, which is way more boring than the dinosaur that you just created in your minds because you're wonderful, incredible people. So anyway, we're just going to go with this now. So I saw this dinosaur and I made it and everyone wept with joy because it was so beautiful. And then I went to a coffee shop to continue working on my amazing dinosaur that you have all seen with your eyes. It turns out though, I couldn't find the Wi-Fi password and so I was like, I don't know, the barista looks busy, but I'm working on a local server and so I don't need that. I don't need the internet. It doesn't own me. So I started up my local server and I go to the old like one, two, seven, blah, blah, blah, only to discover that my brilliant dinosaur, that we have all seen, is gone and everything looks like it's 92 and it wasn't a great year. So surely I have done something horrible, right? Because I'm a beginner and I have done multiple horrible things at this point. So I just start ripping apart my code because that's logical. I mean, why not? And I just dig through there and I'm like, I'll change all of the things. I don't fix it. But eventually I came to my senses and realized that I needed Google because she is my mother and I asked the barista for the password and I go and look it up and I like did one thing maybe and then turned on my server and refreshed the page and what did we see? Remember, you can see this dinosaur and I pressed the thing and the dinosaur went across the screen and everyone said, Wow! I know, right? Tears of joy. And that's when it clicked that the only problem I had was that I didn't have an internet connection and all of my files, all of my CSS files and my JavaScript files and all of the anything that matters visually files couldn't be accessed. All of my independence from the internet was a lie. She is my mother. If I had saved all those files locally I wouldn't have had that problem. Which brings me neatly into the next topic. Terrified abandonment of dreadful mistakes. All of this madness was happening on my one and only copy of my code, my master branch. So let me remember that lady that was like, I'm gonna fix that thing. Not that my project is like a priceless worth of art, but like we probably both should have made a copy first. And remember all the ripping apart I described? It was a lot. And while my renewed internet access brought my dinosaur back that we can all see. There it goes. Yeah, I know. Some of you have lost your enthusiasm for the dinosaur. The internet didn't solve all the new problems that I have created because I had followed this rabbit hole of fixing non-existent problems and I didn't know how to get back. Which isn't great. And I honestly don't know how I fixed it. But since that time, I've discovered what we can basically use as Git's version of a panic button. It's Git branching and it's amazing. Instead of taking all of my anxious confusion and destroying all of my work that I have to go back and figure out how to fix, I could have done this. Git checkout to dash B to create a new branch called something normal. Like, oh my God, what have I done? And then I can commit my disastrous changes to this trash branch that I created with an appropriate Git message, something like made a giant mess of things or created a dumpster fire. And then I can check out the master branch and pretend that none of this ever happened, which is what I do with all of my mistakes. I may not watch the video of this later. At this point, I've gotten into habit most of the time. Of creating a branch before I get myself into a mess. So let's look at how that would go. We're gonna kill the velociraptor right now because some of you don't like it. I'm just kidding. You're all fine, but we're gonna kill it anyway. I would start a new branch called kill the velociraptor. I would make my changes and once I've confirmed that I haven't screwed anything else up, I would commit them and then check out the master branch and merge the changes. You may need a different workflow based on the team that you're working with or some other parameter, but the point is if you're gonna make changes, make a new branch, unless you love drama, then knock yourself out. Okay, last two. Being suave and mysterious with Django. Surely I couldn't have destroyed more than this, right? I mean, gracious. But that's wrong and I did because I'm an overachiever and this one feels tricky. Like it feels like I've been tricked. I know that's not the case, I think, but it was actually made worse by the fact that I'm using it like somewhat responsibly. What could it possibly be? Allow me to take you to my settings file. Note the comment here that appears when you start a project. Security warning. Keep the secret key used in production secret. It doesn't explicitly tell us how to do this, so when it got time to deploy, I thought, well, that's a really cute idea that I don't know how to do. Goodbye, let's push that up. Why not? I know. As it turns out, this project also needed my email address and my email password. That was such a loud noise. For good measure, I went ahead and put in some API keys and a portion of my seventh grade diary because why not? Please don't shame me. Okay, that's happening right now and it's on the internet now, but whatever. Enjoy my shame, new best friends, and hopefully we can save you some of this trouble in the future. I think you get my point now, but this is awful as evidenced by the gasps, so let me tell you at least one way to not do it. Like many things, there are multiple different ways to do this, so I'm just gonna tell you what I do. Here we go. Okay, remember when we talked about virtual environments? We all remember this, it was not too long ago. Aside from keeping people from dying of peanut allergies metaphorically, they can also hold our deepest, darkest secrets that way you do not push them into production and they're not gonna be in your get history, which is what happened to all of my things. So we're gonna go to the activate script. For me, since I'm using virtual end wrapper, all of my virtual environments are in an Ms folder. So we'll find that at Ms slash extra peanuts, been activate, and we're gonna open that up and then we're gonna add this little bit to the end. Here we are exporting a variable secret key with clearly a super secret value because it says I'm super duper sacred. Now in our settings file, we're gonna add this function. I'm pretty sure this is what's recommended in two scoops of Django, which is excellent. So if you don't have a photographic memory, you can look it up there. So now instead of putting our secret key in that settings file, we're going to put that function and it is going to find the environment variable that we had set in the activate script and we're all set. It's very super fancy and mysterious. When you deploy, you're gonna set those environment variables wherever you've deployed also. In Heroku, they're called config variables, but they might have other names depending on where you're at. Find that place, set the values, and then whether you're working locally or if you're deployed, all of your environment variables are there to keep your secrets for you. Okay, very last thing. We've made it, making friends with Django, like we all are now. None of this would have been possible, even at all, without the San Diego Python user group and the San Diego Pilates and of course our blessed mother, the internet. But most important of the three are definitely Pilates and the San Diego Python user group. This is where I've gone nearly every Saturday for the last three years to get encouragement and inspiration and camaraderie. Our Saturday study groups are what made me believe that I could do any of this to begin with. And I've found a place where it's okay to be at whatever level you're at. Our study group is absolutely why I'm here. I can't overstate how valuable and important and wonderful our community is. I wanna share with you this thing that I worked on for literally six hours. So I couldn't figure out why I could submit my form, but it wouldn't actually create a record. It was very frustrating and I worked on it for a long time and then I went to study group and 60 seconds brought me this. Y'all like laughing at me. I mean, we're best friends, that's fine. Six characters, that is one character for every hour I spent. So special thanks to Micah, who also enjoys laughing at me, but helped me out with that. And the amazing thing is I was able to do a similar tiny fix for a new developer that came to our study group a couple years later. And that is why we need community. I'm still learning. I hope I never give up the title of learner because I find it helps me be kind and generous with myself. And I think the most costly mistake any of us could make is to stop expecting mistakes and start demanding perfection from ourselves. In the words of Brene Brown, there's no innovation or creativity without failure, period. So in conclusion, I wish you tidy development environments, adorable Django project structures, internet proof velociraptors that everyone can see, easy get escape routes, mysterious secret keys and passwords, super smart friends, and lots and lots of mistakes. Just hopefully not these exact ones. Thank you. So here is one of our lovely Petaluma-designed camelbacks with the North Bay Python logo on it. I was sitting in front of one of the former BDFLs of Django and he assures me that he's quite pleased to know how to be suave and mysterious using Django. It's apparently eluded him all these years. So thank you very much for your talk. Thanks, Melanie again.