DjangoCon US 2016: Day 2: Lightning Talks
CC Attribution - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Daeye, Lucie
Bryzgunov, Rostyslav
McNulty, Tobias
Love, Kenneth
Bane, Joseph
Sitarska, Ola
Calhoun, Rachell
Cronyn, Joe
Day 2 Lightning Talks by Many People
 Come on, y'all! So, hi, I'm Lucie and I'm already missing things. Okay, every time you're doing that. So, yeah. So, hi everyone, I'm Lucie and for the people who didn't saw me at the booth today or yesterday, I'm working for Django Girls. So, I'm their awesomeness ambassador. So, Django Girls is a foundation that helps organize workshops around the world. So, it's free one day workshop for women. We studied two years ago and now we have approximately 6,000 people that went through a workshop. So, I've attended the first Django Girls in Berlin, whether that was a total beginners at programming. And since then, I've organized two workshops in Paris and coached at seven events in Europe. So, I wanted to share with you what I've learned about teaching. So, teaching is happening all the time and not only during beginners' workshop. It could be a friend asking for help or a colleague at work. So, sadly, there is no magic recipe to make you a great teacher that there is a list of things that you should absolutely not do. For example, you may want to grab the keyboard from the hand of someone to show them quicker what you want them to do. You shouldn't do that. Really don't. Don't do it. Because it's rude. You're taking the keyboard from the hand of someone who is currently using it and imagine if it's a laptop, you're currently taking away the laptop. So, don't do that because also it's humiliating. You're literally saying to this person that they won't be able to fix their problem and that's wrong. So, what should you do? If you can't see the screen, ask the person if they can turn the screen or move a little bit. If you need more detail to be able to help them debug the code, ask them or explain them how to do it. For example, you can say, can you show me the log or can you type git status, press enter. So, the main idea is also to teach them tricks so they will be able to debug the code when you're not there. And it's really important because it will also help them build confidence that yes, they can fix stuff. The second thing you may want to do is saying something not nice about the operating system, the software or programming language that people are using. So, let me be clear on that. Someone asked for your help, not your opinion. So, the last time I attended a programming workshop, someone said to me, cool, someone on Linux, that's one less problem. The thing is that was absolutely not true because I spent more than an hour to debug a nasty bug to make things work. And secondly, that's also emitting again for the people that were there, not using Linux, and were starting to think, what is wrong with my OS? So, people coming to programming workshops or looking for help, end up about the skills, knowledge or even legitimacy to ask a question or be on a workshop programming. So, your job is, like I said, to help them build confidence and also make sure they have a great time learning. So, no nasty comments or judging. And by the way, don't even start about trolling with other attendees or learners. Because you're not here to prove you the biggest geek in this part of town. You're here again to help people learn something. So, to resume, not taking the keyboard, not judging, not trolling. That's maybe a lot of dance. So, what can you do? You can help them about building a friendly environment. So, to do that, you must respect the person you teach into. So, don't do sexist, racist or ablaze jokes. No, it's easy, my grandma could do it, or other subtleism. Try to also create a relation where they can feel they can ask questions. To do that, tell them that no, they won't bother you with all the questions because you're here to help them. Also, try to answer the question positively. You can say something like, it's a good question, I'm not sure, so let's check on the internet. And also, don't ever act surprised by the question because they need to know that you want to judge them. Also, try to be in their shoes. Oops. Let's start again. So, try to be in their shoes. Do not use jargon or don't say a thing like, it's simple, you just have to do this. Because it's probably simple for you, but it may not be the case for the person you're teaching to. And finally, building a friendly environment also means checking if the person needs a break or it's getting frustrating. Most of the people are thought during a premium of workshops and spend a whole day in front of the computer. So, don't hesitate to invite them to take breaks. So, be patient, encouraging, and remember that new learners can be slow, which can be really frustrating for you. Try to remember they're going through a lot. So, be ready to repeat and expel things multiple times and also tell them it's okay if they don't know everything. So, be friendly, celebrate small and big victories, and don't ever show your frustration. Keep in mind that you're here to empower them. So, if you want to know more about how to teach programming to someone, you can check our guide, coach.jr.org, and I strongly invite you to go to Nicole Jem's talks tomorrow at 2.20. Thanks for your attention. I'll be talking about using ES6 SCSS in Django another way. So, do I start? You have five minutes. Be keen. Great. Maybe even faster. So, I think some of you already know about Django Compressor. It's a Django application which provides you very nice asset management and static handling stuff. So, I'm using it for a long time, and there is a way to use ES6 and SCSS in it, but you need to write some mapping between some stuff and note commands. It's not very convenient, and I have made my little addition to Django Compressor, which is called Django Compressor Toolkit, and let me just show you the results first. So, here I created just, during the last presentation, one Django project, and we have two Django applications, base and up. So, first, inside base, we have some basic stuff for ES6, for SCSS, and inside another application, we want to use it. We want to import from ES6 from some other Django application, and same for SCSS. We want to have cross-imports between Django applications, because I prefer to keep static inside Django apps, not in one separate folder. So, now about installation. Yeah, you need to install the Python package, and then to configure it, a bit small screen. So, here I just installed my Compressor Toolkit. That's Django Compressor, and that's mine. So, you use this mapping for SCSS and for ES6, and inside Django template, using Compressor, you include just your final application, SCSS and JavaScript, inside which you reuse some other ES6 from another applications. So, that's the insights, and now how does it work? Does it work at all? Yay, it works. The link is read, and ES6 is transpiled, compiled, merged, minified, and executed. And that's a great success. That's it. I suggest you to use it. Great, thanks. So, yeah, my name is Tobias McNulty. I am the CEO at Cactus Group. We are a 30-person Django consultancy based in North Carolina. We have been using Django since 2007, and it's been a really huge part of our success. A number of our staff have contributed back to Django over the years, and this is my pitch to all of you to get involved and contribute. And to show you why I think that's important, I just want to start with a recent example. So, raise your hands and keep them up. How many of you have used a model file field before? Okay, so a lot of people. And now, if you keep them up, how many of you have used that to store a file field in a remote storage like S3 previously? So, also a lot of people. And how many of you had to use the... Or sorry, did not have to use the Django documentation to do that. So, how many of you were able to do that without using the Django docs? So, okay. So, maybe two or three people still had their hands up. So, documentation is very important. A few months back, I was working to move content from a text field into a file field for projects. After reading through the Django docs, like any number of times, I stumbled upon this Stack Overflow post here. You know, the post kind of shows a timeline of a conversation about file field. The first one says, what is the purpose of this file field open method? Somebody else seven months later responds that, you know, the docs are a little bit misleading on that. About a year later, somebody commented, oh, somebody should really raise an issue on this. And then here I am, two and a half years later, struggling through this, trying to figure out what is the purpose of this file field open method. And the docs are unchanged and no issue was ever raised throughout the timeline on this point. So, for those of you who may not be aware, Django has an excellent issue tracker at code.jngoproject.com. If you discover an issue in Django, even if you don't have time to dig into it then, you know, take a few minutes to first, you know, search for the issue and make sure that it doesn't already exist. And then if it doesn't, you know, file a simple report on that. So, I, you know, did my due diligence and submitted that issue. A few weeks later, we had one of our quarterly ship-it days at Cactus. And I spent a few hours, you know, working on this. And within that time, was able to get a PR submitted to Django Mester. And then, you know, with some back-and-forth and code review about, you know, three weeks later, it's not something that you can kind of expect to get in immediately, but within three weeks, this really tiny change to the documentation that I had was merged into Django Core. And, you know, I think this is a really minor change. If this is helpful to at least one other person in the future, I will feel like that investment of my time was worthwhile. And, you know, I also think it's worth to note that this is really just one tiny, tiny change in the history of literally thousands of patches that have helped make Django what it is today. So, speaking of thousands of patches, you know, why do all of these people volunteer their time and energy to contribute to Django Core? For those new to Django, it's a great opportunity to learn and dig into how Django works. You also get free expert code reviews from some of the most knowledgeable people in the community, many of whom are here at the conference this week. You get to feel good, you know, not only about creating something, but also, you know, about being part of this community. And, you know, lastly, of course, contributions to open source projects, you know, however small can help improve your credentials when applying to jobs. If, you know, I've peaked your curiosity and you're wondering where to start, Django has really good docs on contributing, but, you know, those docs, like everything else, could always be improved as well. So, you know, as you get started, you know, trying to set up the unit test suite for the first time, for example, use that as kind of a case study to think through what's working and what's not working, maybe you discover a platform issue that's, you know, specific to your OS. On the subject of documentation, I was talking to Tim Graham yesterday, the Django fellow, and he mentioned that his entire first year of Django contributions was nothing but documentation fixes. I think that's incredible. And, you know, no matter sort of how good Django's docs are, they can always be improved. And, you know, there's two IRC channels. I think the Django Sprint one will be the one that we're using this week. There are also, you know, there's an issue track I mentioned earlier. There are. Do I get extra time? This week there are two types of Django Sprints. Tim Graham is running an informal one in the MBA lounge upstairs. It's a little study alcove just to the left as you come in. It took me a while to find it. And then Thursday and Friday will be the Sprints. Thanks very much and hope to see you around the conference. Alright. So, hi. I'm Kenneth Love. My day job is teaching Python and Django. I get to do it all through video and online, which is kind of cool. It means I don't get a lot of feedback right away, but it's still neat. So, for the past couple of years I've been doing this and I've had hundreds, thousands of students around the world. I've picked up a couple of things that I think are handy for teaching. So, I'm going to share this. I overlap with Lucy. We should have collaborated. First of all, though, I'm not an expert. I very well might be wrong. So, if I am, tell me so that I'll get better. But if I'm not wrong, cool. I lucked into something good. Alright. So, as a teacher, as a developer, trying to teach, one of the problems is that you know too much. So, you've solved problems. You've encountered all these errors, bugs. You've read documentation. You've gotten onto IRC, which is really hard for people now. You've gotten over your imposter syndrome, at least slightly, right? I mean, I still get nervous about teaching. I've been doing it for two years. I've put out 30 courses in two years and I'm still very nervous about teaching people. I'm a bit nervous right now, even, and I know most of you. Beginners don't have any of those advantages, though. They're full of these unknown unknowns. They don't know what they don't know. They don't know how to find out what they don't know. They don't know any of this stuff. That's why they're beginners. That's why they're coming to you to teach them stuff. And, as part of the whole Zenopython thing, you remember how, in the face of uncertainty, you resist the urge to guess? So, you have to kind of resist that. You have to try to guess what they don't know, but find out if you can. Anyway, let's go back to the beginner mindset. This is what you need to get. Bring yourself back to where they are. So, where were you ten years ago, five years ago, six months ago? If you only have the model.objects.all query and a for loop, how would you then filter down the records that have a certain PK or a certain username? Right? Because lots of times they only have those two tools. They know they have those two. They know both of those. But they can't figure out the other stuff or they haven't been told. So, when you're teaching, try to answer three questions. Tell them what you're going to do, what that problem solves. Then tell them why they need to do that or when they're going to need to do that, when that problem is going to come up. And then, of course, teach them how to actually solve the thing. So, you show them that they have lambdas. When would they use lambdas? Why would they use lambdas? Alright. So, then things to avoid when you're explaining. Try to avoid using the word easy, because things aren't easy to beginners. Try to avoid simple, because things aren't simple. None of our stuff is simple. Just and only, as Lucy said, you're not going to just do this thing. It's not only this problem. And all you have to do is a hard one to get rid of, but it's there. Try not to have that. Another point to bring up. Moms aren't dumb. So, don't use moms, grandmas, dads, uncles, grandpas, whatever as examples. All these people are very capable. Just don't. Come on. Didn't Spotify get in trouble for that? Anyway, things to add instead of things to avoid. Try to use diverse and inclusive examples. As Sarone mentioned yesterday, you want to have as big of an audience as possible. You want to get as many people in. Mix in genders. Air towards feminine and non-binary sides on that. We have more than enough male examples already. If you're using visual aids, represent as many different types of people as you possibly can. Genders, races, abilities, have somebody who floats. It doesn't matter. Just bring in stuff. And remember that in the wide world, not everyone fits into a first name and last name. Not all dates show up as a month, day, year. Not all numbers have commas in them. They have decimals instead. I want to share a thing that I got for part of the gender. I got an email from a student about six months ago. They emailed me to thank me for using explicitly the word they as a pronoun choice in a course. They self-described themselves as brown, autistic, and non-binary or genderqueer. And they felt like they didn't exist in the tech world. So it's pretty amazing what one word can mean to someone. So learning is hard. Recognize the achievements that people have. Encourage self-care. Introduce communities, like Kojo here. And thank you. Okay, thank you. So this has my Twitter handle if you want to follow me or not. So a couple things that you kind of need to basically follow along here is we use message order in Millware, specifically RabbitMQ for a lot of our asynchronous tasks and scheduled jobs. And this will communicate with salary queues and exchanges that we have set up. And also just general basic familiarity with PDB. I would love to go into more detail on those types, but I can't. So we have this really cool feature that I stumbled upon and it's called RDB. It basically is very similar to how you would use PDB's set trace inside your code. You just sprinkle it in where you think you're having a problem and it will give you access to the code at runtime. So it was surprising to me how easy this was actually to put in place given all of the different components that have to work together for this to kind of solidify. So I was going to do a quick demo. Basically the steps are that I'm going to start up a rabbit broker. I'm going to start up a salary worker that has the implementation of the task that I want to debug. And then I'm going to apply an async function that communicates with the salary worker to basically start the job. And then I'm going to attach to the RDB session over Tellnet and profit from that. So first is rabbit. So that's very simple. Just rabbit MQ server. Next is my salary worker. I've already got this all set up to work on a test salary queue and I'm just logging in. So that's running. And next I'm going to use Django shell plus and import my task and run it. So you can see I'm doing just passing a message Django con US 2016. And I will now show you the code. It's a very simple task that just prints out the message that it's given. And you can see that I have this that choice already in there. So you'll see back in my my worker it's now waiting for a connection from my tellnet. So it has the port which is now 6905. And there I am. I'm in PDB. And you have basically all of the things that you would normally have from PDB. You would have you know list help step next that sort of thing. So I'm just going to continue here and you can see that it will then print out my message in the log for hello Django con. Thank you. So I'm here to say my name is all. And for the last couple of months I've been working with the DSF code of conduct committee. And today we are announcing quite an exciting thing for us. I'll be Paul Hallett, one of our other members. I did it at Europe. And which was like an hour ago. So we were synchronizing today. And so we've been working for a couple of weeks now. And so I'm going to tell you about what we've been working on and what we do. So let's start with what we do. So the DSF code of conduct committee is just a group of people whose job is to make sure that Django community provides a harassment free experience for everyone involved. We deal with and keep record of code of conduct violations as well as provide support for conference organizers for moderators of Django online spaces like Reddit or mailing lists and to help them keep their members safe. So we're currently seven people scattered across the world. We've got members in Australia and Europe, Africa and States. And it makes arranging meetings very fun. We had one at 8 a.m. today. So today I'd like to tell you a little bit about the thing we've been working on for the last couple of weeks, which is making our internal documentation existing at all and then making it public today. So starting from... So this documentation is going to contain everything from how exactly we are dealing with the issues that are reported to us through establishing on the own call rotation duty we've got now to make sure we don't forget about our own well-being and burnout. So everything is in there. So you can now go and check it out and GitHub. It's open source with a Creative Common license. And I will tell you now very briefly what you can find inside, but I really encourage you to check it out and read it on your own. So in the first chapter you can learn about the structure of the membership of the community. We'll tell you who are the members, when they joined and when their term at the committee ends. You can also find out how members are added and removed from the community. So it's all transparent now. Then we also dive straight into the most important chapter of the whole thing, which is how we handle code of conduct evaluations. And you can learn about our own code duty animation, go through the entire process since the report is made until it's considered closed, as well as learn about the shape-harding and how we make decisions. Then the equally important section is dedicated to the way we keep records. Who has access and for how long and how is there information and where we store it. It's all in there and public. One of the most valuable services we provide to the community is a central record of all code of conduct evaluations that took place in different, often very disconnected parts of our community. So we have done this for a while, but now we are quite officially offering a way for community organizers to reach out to us before their event takes place to make sure that none of their attendees is blacklisted with us. And we also extend this invitation to use the service to other Python communities, not just Django. And last but not least, you can find about how we handle transparency and see statistics of reports and actions taken, as well as a number of blacklisted and black people. And we are still planning to expand on this section in the future, but so we hope that this is just a small step towards something bigger. So what's the goal? We hope that making this documentation public is going to help us raise awareness about the work we are doing, as well as demystify the process of what happens when a report is made. We realize that code of conduct can be scary for some, and we like to show exactly how we deal with issues arising so that the decision to report something is as straightforward and obvious as possible. We also hope that making this transparent, we're going to help other communities outside of Django world to make their processes better, because code of conduct is very important, but only when it's enforced. Just having it published on the website is not enough, and it took us quite a while to figure how this whole thing works, so we hope that we're going to help other communities make this happen. And last but not least, we are looking to improve our processes with your feedback, and I encourage you to take a look at our issues, on our pull requests, and we are excited to see your impact on it. And last, I'd like to thank everyone who painted the SF code of conduct committee, as well as many members of the community who had to make this happen. Alright, hello, I'm Rachel. I'm here to talk about inspiring women to fall in love with programming. I talk fast, and being up here, I'm a little bit nervous, so I'll talk to you faster, but that's okay because most of you are native English speakers. I come from recently Korea, so it's kind of new for me. Okay, so first let me, who am I? I'm Rachel. I studied Spanish and French, Spanish and French in university, and then I taught English in Korea. I also learned Korean, Korean, and then I started studying Python to try to change careers, and now I do Django, so that's kind of my background. Okay, so, anybody know what this is? Have you ever seen this before? It's a job. They're called knocker-uppers, and what they do is they, one of them blows something like a stone or to knock the window to wake people up. Before, we had alarm clocks, and the other one would knock it with a pole. I kind of got inspired by seeing another talk by Sally Williams, and she was explaining that jobs change, and jobs are changing now, too. So, let me talk about this. So, this is something we kind of can relate to. Jobs are changing. This is factory, but also like in banking, traders, it's all starting to change. It's called the Fourth Industrial Revolution, and so let's take a look here at the WEF in January of this year. But I report in five years, not like 20 years from now, it's five years, seven million jobs will disappear, and only two million will be replaced. And this number is because smart technology, robots, etc., but this number will disproportionately affect women because, for example, if this continues, four jobs that men will lose, only one will be replaced, but for women, 20 jobs that will be lost, only one will be replaced. So, that's why it's really important to get more women, not just in the schools and start education, but now. And it's not just programming. It's CS plus X. I'm sure some of you have heard of this, but it's CS plus fashion, CS plus education, CS plus medicine. It's not a separate field. They're all going to be combined. Okay, so, and how can we do that? I'm sure you guys have heard this. Jangle Girls a lot recently, and that's kind of where I come from. Jangle Girls chapter in Seoul, and Jangle Girls is a one-day workshop to inspire women to fall in love with programming. So, what I want to talk today is about what's next. This is our workshop in Seoul. Last year was the first. What our goal is and what I hope to achieve is not just inspiring women, but supporting them on their next step. So, after they're inspired, what do they do? In Seoul, we have a curriculum, first workshop, and then coat camps. And we have a two-month coat camp to go back to the basics and learn Python and Django, HTML, CSS. And then we do two-month base coat camp. It's all free, and with sponsor support, that will focus on making your own project. So, you've learned it. Now, do something with it, and that's the best way to learn it. All right, and here we have, if you go to our website, DjangoGirlsSoul.org. You can see a bunch of about 15 projects came out of that. Websites online, and we even had one Android app. We also did a lot of community events, workshops, regular study meetups on the weekends. So, I want to encourage other cities and other DjangoGirls communities, or you can start your own, to continue education after the workshop. All right, and we learned by doing and master by teaching. We're working on a nonprofit website. I'd like some help if you could, but because our members are all contributing, myself included. This was a participant. She became a coach the next time around, master by teaching. So, how can you contribute? You can be a coach or an organizer in your own city. You can offer sponsorship for our events. You can offer scholarships to your events or other workshops. Also, contribute. DjangoGirls.org slash contribute. You can find other ways to contribute. Or, GitHub DjangoGirls code camp. There's the light leadership nonprofit project for a school in Peru we're making. And also, we're trying to develop a curriculum for supporting women after the workshop. So, I hope I inspired you to help us inspire women to fall in the program. Thank you. So, I wanted to start off today, and I have some notes, but I'm going to try to not look at or follow them very much. Who in the room has used Docker before? You can just see a show of hands. So, I see some hands not up. That's good. Some of you will not know that I don't know what I'm doing. So, I just want to also disclaim none of the code I'm using today is mine, because then it really wouldn't work. Like, really wouldn't work. So, if you haven't used this, I'm not going to teach you anything today. You're just going to see me use Docker, but what I'm really hoping is that it inspires you to try using it, because it's an amazing tool and I love using it daily. And I try to tell everyone who hasn't used it before that they should get out there and try using it. So, this is me, Adjo Cronin, and I worked for CacheDAR in Portland, Maine. So, first off, does installing dependencies ever make you feel like this? I know I've been in a few situations. This was my first Django shop working at CacheDAR, and I think I spent about a month installing things and figuring out, like, oh, I'm missing another system requirement. Oh, I'm missing another system requirement. And it was just really kind of a pain to get up and running. So, fear dependency hell no more, because with Docker, all things are possible. You don't need to install anything. So, regardless of what operating system you're on, it's now supported on Mac OS, it's supported in Windows, it's supported in Linux. So, really, no matter what you're running, it's a great tool to have. And it's time for our first demo. So, let's see if I can fall flat on my face really quick. What I'm going to do is I'm actually going to start a brand new project. So, we're going to do Django admin start project. And can you see that on the big screen, everybody? Is that? Okay. New project. All right. So, we're going to go in the new project. I'm going to create a requirement. I'm going to put Django in it. And save that. And then I'm going to create a Docker file. And I'm going to use the official Docker image. So, all I have to do is say this container is from Django on build. And that's the on build version of the Django Docker container. From there, I can just say Docker build. I'm going to tag it and call it Docker demo. And so, what this is going to do is it's going to run through their Docker container that they've provided, run the steps that they have, and it by default just runs manage.py. So, basically, it's going to do everything for me. I didn't have to write any code. And this project is going to hopefully run without a problem. So, now, I'm going to run my Docker demo. And, of course, it fails because I still have something running. So, one second. Get rid of those. All right. So, my Docker demo is up and running. As you can see, it kind of looks like it's just hanging, but that's because I didn't attach to or watch what's going on in the container whatsoever. So, it's going to be a little bit faster. So, it's going to run on the Django container. So, I'm going to run it. I'm going to run it. So, this is going to run on the Django container. It's going to run on the Django container. So, if you've used Docker, have you used Docker compose? Okay. So, if you haven't used Docker compose, basically, it's an easy way to have an entire configuration file that says run this this way, run that this way. You can have your database, your app, your everything all configured, pre-configured. Yeah, I can do all of this with one command. Whoa. All right. So, we're going to go ahead and try this now. And go back out. And, yeah. Thank you. I'll just go back in with something different. Ah, no. Oh, good call. The nerves are getting to me. So, Docker composing Django. And I'm just going to run Docker compose up. Now, I've already downloaded all of the files from before, which is why you're not staying here for 20 minutes watching things download. I figured that would probably be a good idea. So, it's up. It's running. We're going to go to localhost 80 for this one. And I have a website. So, this is running a database. It's running Django. It's fully functional. And it took me one command in 15 seconds per run. So, if you've never used it before, I highly recommend going and taking a look. And thank you all very much. Thank you. Thank you very much. Thank you very much.
 Come on, y'all!  So, hi, I'm Lucie and I'm already missing things. Okay, every time you're doing that.  So, yeah. So, hi everyone, I'm Lucie and for the people who didn't saw me at the booth today or yesterday, I'm working for Django Girls.  So, I'm their awesomeness ambassador.  So, Django Girls is a foundation that helps organize workshops around the world.  So, it's free one day workshop for women.  We studied two years ago and now we have approximately 6,000 people that went through a workshop.  So, I've attended the first Django Girls in Berlin, whether that was a total beginners at programming.  And since then, I've organized two workshops in Paris and coached at seven events in Europe.  So, I wanted to share with you what I've learned about teaching.  So, teaching is happening all the time and not only during beginners' workshop.  It could be a friend asking for help or a colleague at work.  So, sadly, there is no magic recipe to make you a great teacher that there is a list of things that you should absolutely not do.  For example, you may want to grab the keyboard from the hand of someone to show them quicker what you want them to do.  You shouldn't do that.  Really don't. Don't do it.  Because it's rude.  You're taking the keyboard from the hand of someone who is currently using it and imagine if it's a laptop, you're currently taking away the laptop.  So, don't do that because also it's humiliating.  You're literally saying to this person that they won't be able to fix their problem and that's wrong.  So, what should you do?  If you can't see the screen, ask the person if they can turn the screen or move a little bit.  If you need more detail to be able to help them debug the code, ask them or explain them how to do it.  For example, you can say, can you show me the log or can you type git status, press enter.  So, the main idea is also to teach them tricks so they will be able to debug the code when you're not there.  And it's really important because it will also help them build confidence that yes, they can fix stuff.  The second thing you may want to do is saying something not nice about the operating system, the software or programming language that people are using.  So, let me be clear on that.  Someone asked for your help, not your opinion.  So, the last time I attended a programming workshop, someone said to me, cool, someone on Linux, that's one less problem.  The thing is that was absolutely not true because I spent more than an hour to debug a nasty bug to make things work.  And secondly, that's also emitting again for the people that were there, not using Linux, and were starting to think, what is wrong with my OS?  So, people coming to programming workshops or looking for help, end up about the skills, knowledge or even legitimacy to ask a question or be on a workshop programming.  So, your job is, like I said, to help them build confidence and also make sure they have a great time learning.  So, no nasty comments or judging.  And by the way, don't even start about trolling with other attendees or learners.  Because you're not here to prove you the biggest geek in this part of town.  You're here again to help people learn something.  So, to resume, not taking the keyboard, not judging, not trolling.  That's maybe a lot of dance.  So, what can you do?  You can help them about building a friendly environment.  So, to do that, you must respect the person you teach into.  So, don't do sexist, racist or ablaze jokes.  No, it's easy, my grandma could do it, or other subtleism.  Try to also create a relation where they can feel they can ask questions.  To do that, tell them that no, they won't bother you with all the questions because you're here to help them.  Also, try to answer the question positively.  You can say something like, it's a good question, I'm not sure, so let's check on the internet.  And also, don't ever act surprised by the question because they need to know that you want to judge them.  Also, try to be in their shoes.  Oops. Let's start again.  So, try to be in their shoes.  Do not use jargon or don't say a thing like, it's simple, you just have to do this.  Because it's probably simple for you, but it may not be the case for the person you're teaching to.  And finally, building a friendly environment also means checking if the person needs a break or it's getting frustrating.  Most of the people are thought during a premium of workshops and spend a whole day in front of the computer.  So, don't hesitate to invite them to take breaks.  So, be patient, encouraging, and remember that new learners can be slow, which can be really frustrating for you.  Try to remember they're going through a lot.  So, be ready to repeat and expel things multiple times and also tell them it's okay if they don't know everything.  So, be friendly, celebrate small and big victories, and don't ever show your frustration.  Keep in mind that you're here to empower them.  So, if you want to know more about how to teach programming to someone, you can check our guide,  coach.jr.org, and I strongly invite you to go to Nicole Jem's talks tomorrow at 2.20.  Thanks for your attention.  I'll be talking about using ES6 SCSS in Django another way.  So, do I start?  You have five minutes. Be keen.  Great. Maybe even faster.  So, I think some of you already know about Django Compressor.  It's a Django application which provides you very nice asset management and static handling stuff.  So, I'm using it for a long time, and there is a way to use ES6 and SCSS in it,  but you need to write some mapping between some stuff and note commands.  It's not very convenient, and I have made my little addition to Django Compressor,  which is called Django Compressor Toolkit, and let me just show you the results first.  So, here I created just, during the last presentation, one Django project,  and we have two Django applications, base and up.  So, first, inside base, we have some basic stuff for ES6, for SCSS,  and inside another application, we want to use it.  We want to import from ES6 from some other Django application, and same for SCSS.  We want to have cross-imports between Django applications,  because I prefer to keep static inside Django apps, not in one separate folder.  So, now about installation.  Yeah, you need to install the Python package, and then to configure it,  a bit small screen.  So, here I just installed my Compressor Toolkit.  That's Django Compressor, and that's mine.  So, you use this mapping for SCSS and for ES6,  and inside Django template, using Compressor,  you include just your final application, SCSS and JavaScript,  inside which you reuse some other ES6 from another applications.  So, that's the insights, and now how does it work?  Does it work at all?  Yay, it works.  The link is read, and ES6 is transpiled, compiled, merged, minified, and executed.  And that's a great success.  That's it. I suggest you to use it.  Great, thanks. So, yeah, my name is Tobias McNulty.  I am the CEO at Cactus Group.  We are a 30-person Django consultancy based in North Carolina.  We have been using Django since 2007,  and it's been a really huge part of our success.  A number of our staff have contributed back to Django over the years,  and this is my pitch to all of you to get involved and contribute.  And to show you why I think that's important,  I just want to start with a recent example.  So, raise your hands and keep them up.  How many of you have used a model file field before?  Okay, so a lot of people.  And now, if you keep them up,  how many of you have used that to store a file field in a remote storage like S3 previously?  So, also a lot of people.  And how many of you had to use the...  Or sorry, did not have to use the Django documentation to do that.  So, how many of you were able to do that without using the Django docs?  So, okay.  So, maybe two or three people still had their hands up.  So, documentation is very important.  A few months back, I was working to move content from a text field into a file field for projects.  After reading through the Django docs, like any number of times,  I stumbled upon this Stack Overflow post here.  You know, the post kind of shows a timeline of a conversation about file field.  The first one says, what is the purpose of this file field open method?  Somebody else seven months later responds that, you know,  the docs are a little bit misleading on that.  About a year later, somebody commented,  oh, somebody should really raise an issue on this.  And then here I am, two and a half years later,  struggling through this, trying to figure out what is the purpose of this file field open method.  And the docs are unchanged and no issue was ever raised throughout the timeline on this point.  So, for those of you who may not be aware, Django has an excellent issue tracker at code.jngoproject.com.  If you discover an issue in Django, even if you don't have time to dig into it then,  you know, take a few minutes to first, you know, search for the issue  and make sure that it doesn't already exist.  And then if it doesn't, you know, file a simple report on that.  So, I, you know, did my due diligence and submitted that issue.  A few weeks later, we had one of our quarterly ship-it days at Cactus.  And I spent a few hours, you know, working on this.  And within that time, was able to get a PR submitted to Django Mester.  And then, you know, with some back-and-forth and code review about, you know, three weeks later,  it's not something that you can kind of expect to get in immediately,  but within three weeks, this really tiny change to the documentation that I had was merged into Django Core.  And, you know, I think this is a really minor change.  If this is helpful to at least one other person in the future,  I will feel like that investment of my time was worthwhile.  And, you know, I also think it's worth to note that this is really just one tiny, tiny change  in the history of literally thousands of patches that have helped make Django what it is today.  So, speaking of thousands of patches, you know, why do all of these people volunteer their time  and energy to contribute to Django Core?  For those new to Django, it's a great opportunity to learn and dig into how Django works.  You also get free expert code reviews from some of the most knowledgeable people in the community,  many of whom are here at the conference this week.  You get to feel good, you know, not only about creating something,  but also, you know, about being part of this community.  And, you know, lastly, of course, contributions to open source projects,  you know, however small can help improve your credentials when applying to jobs.  If, you know, I've peaked your curiosity and you're wondering where to start,  Django has really good docs on contributing, but, you know, those docs,  like everything else, could always be improved as well.  So, you know, as you get started, you know, trying to set up the unit test suite for the first time,  for example, use that as kind of a case study to think through what's working  and what's not working, maybe you discover a platform issue that's, you know, specific to your OS.  On the subject of documentation, I was talking to Tim Graham yesterday, the Django fellow,  and he mentioned that his entire first year of Django contributions was nothing but documentation fixes.  I think that's incredible. And, you know, no matter sort of how good Django's docs are,  they can always be improved.  And, you know, there's two IRC channels. I think the Django Sprint one will be the one that we're using this week.  There are also, you know, there's an issue track I mentioned earlier.  There are. Do I get extra time?  This week there are two types of Django Sprints.  Tim Graham is running an informal one in the MBA lounge upstairs.  It's a little study alcove just to the left as you come in.  It took me a while to find it. And then Thursday and Friday will be the Sprints.  Thanks very much and hope to see you around the conference.  Alright. So, hi. I'm Kenneth Love.  My day job is teaching Python and Django.  I get to do it all through video and online, which is kind of cool.  It means I don't get a lot of feedback right away, but it's still neat.  So, for the past couple of years I've been doing this and I've had hundreds, thousands of students around the world.  I've picked up a couple of things that I think are handy for teaching.  So, I'm going to share this. I overlap with Lucy. We should have collaborated.  First of all, though, I'm not an expert. I very well might be wrong.  So, if I am, tell me so that I'll get better.  But if I'm not wrong, cool. I lucked into something good.  Alright. So, as a teacher, as a developer, trying to teach, one of the problems is that you know too much.  So, you've solved problems. You've encountered all these errors, bugs.  You've read documentation. You've gotten onto IRC, which is really hard for people now.  You've gotten over your imposter syndrome, at least slightly, right?  I mean, I still get nervous about teaching. I've been doing it for two years.  I've put out 30 courses in two years and I'm still very nervous about teaching people.  I'm a bit nervous right now, even, and I know most of you.  Beginners don't have any of those advantages, though.  They're full of these unknown unknowns.  They don't know what they don't know. They don't know how to find out what they don't know.  They don't know any of this stuff. That's why they're beginners.  That's why they're coming to you to teach them stuff.  And, as part of the whole Zenopython thing, you remember how, in the face of uncertainty, you resist the urge to guess?  So, you have to kind of resist that. You have to try to guess what they don't know, but find out if you can.  Anyway, let's go back to the beginner mindset. This is what you need to get.  Bring yourself back to where they are.  So, where were you ten years ago, five years ago, six months ago?  If you only have the model.objects.all query and a for loop, how would you then filter down the records that have a certain PK or a certain username?  Right? Because lots of times they only have those two tools. They know they have those two. They know both of those.  But they can't figure out the other stuff or they haven't been told.  So, when you're teaching, try to answer three questions.  Tell them what you're going to do, what that problem solves.  Then tell them why they need to do that or when they're going to need to do that, when that problem is going to come up.  And then, of course, teach them how to actually solve the thing.  So, you show them that they have lambdas. When would they use lambdas? Why would they use lambdas?  Alright. So, then things to avoid when you're explaining.  Try to avoid using the word easy, because things aren't easy to beginners.  Try to avoid simple, because things aren't simple. None of our stuff is simple.  Just and only, as Lucy said, you're not going to just do this thing. It's not only this problem.  And all you have to do is a hard one to get rid of, but it's there. Try not to have that.  Another point to bring up. Moms aren't dumb.  So, don't use moms, grandmas, dads, uncles, grandpas, whatever as examples.  All these people are very capable. Just don't.  Come on.  Didn't Spotify get in trouble for that?  Anyway, things to add instead of things to avoid.  Try to use diverse and inclusive examples.  As Sarone mentioned yesterday, you want to have as big of an audience as possible.  You want to get as many people in. Mix in genders. Air towards feminine and non-binary sides on that.  We have more than enough male examples already.  If you're using visual aids, represent as many different types of people as you possibly can.  Genders, races, abilities, have somebody who floats. It doesn't matter. Just bring in stuff.  And remember that in the wide world, not everyone fits into a first name and last name.  Not all dates show up as a month, day, year. Not all numbers have commas in them.  They have decimals instead.  I want to share a thing that I got for part of the gender.  I got an email from a student about six months ago.  They emailed me to thank me for using explicitly the word they as a pronoun choice in a course.  They self-described themselves as brown, autistic, and non-binary or genderqueer.  And they felt like they didn't exist in the tech world.  So it's pretty amazing what one word can mean to someone.  So learning is hard. Recognize the achievements that people have.  Encourage self-care. Introduce communities, like Kojo here.  And thank you.  Okay, thank you. So this has my Twitter handle if you want to follow me or not.  So a couple things that you kind of need to basically follow along here is we use message order in Millware,  specifically RabbitMQ for a lot of our asynchronous tasks and scheduled jobs.  And this will communicate with salary queues and exchanges that we have set up.  And also just general basic familiarity with PDB.  I would love to go into more detail on those types, but I can't.  So we have this really cool feature that I stumbled upon and it's called RDB.  It basically is very similar to how you would use PDB's set trace inside your code.  You just sprinkle it in where you think you're having a problem and it will give you access to the code at runtime.  So it was surprising to me how easy this was actually to put in place given all of the different components  that have to work together for this to kind of solidify.  So I was going to do a quick demo. Basically the steps are that I'm going to start up a rabbit broker.  I'm going to start up a salary worker that has the implementation of the task that I want to debug.  And then I'm going to apply an async function that communicates with the salary worker to basically start the job.  And then I'm going to attach to the RDB session over Tellnet and profit from that.  So first is rabbit. So that's very simple. Just rabbit MQ server.  Next is my salary worker. I've already got this all set up to work on a test salary queue and I'm just logging in.  So that's running. And next I'm going to use Django shell plus and import my task and run it.  So you can see I'm doing just passing a message Django con US 2016.  And I will now show you the code. It's a very simple task that just prints out the message that it's given.  And you can see that I have this that choice already in there.  So you'll see back in my my worker it's now waiting for a connection from my tellnet.  So it has the port which is now 6905. And there I am. I'm in PDB.  And you have basically all of the things that you would normally have from PDB.  You would have you know list help step next that sort of thing.  So I'm just going to continue here and you can see that it will then print out my message in the log for hello Django con.  Thank you.  So I'm here to say my name is all. And for the last couple of months I've been working with the DSF code of conduct committee.  And today we are announcing quite an exciting thing for us.  I'll be Paul Hallett, one of our other members. I did it at Europe. And which was like an hour ago.  So we were synchronizing today. And so we've been working for a couple of weeks now.  And so I'm going to tell you about what we've been working on and what we do.  So let's start with what we do. So the DSF code of conduct committee is just a group of people whose job is to make sure that Django community  provides a harassment free experience for everyone involved.  We deal with and keep record of code of conduct violations as well as provide support for conference organizers  for moderators of Django online spaces like Reddit or mailing lists and to help them keep their members safe.  So we're currently seven people scattered across the world.  We've got members in Australia and Europe, Africa and States. And it makes arranging meetings very fun.  We had one at 8 a.m. today.  So today I'd like to tell you a little bit about the thing we've been working on for the last couple of weeks,  which is making our internal documentation existing at all and then making it public today.  So starting from...  So this documentation is going to contain everything from how exactly we are dealing with the issues that are reported to us  through establishing on the own call rotation duty we've got now to make sure we don't forget about our own well-being and burnout.  So everything is in there.  So you can now go and check it out and GitHub.  It's open source with a Creative Common license.  And I will tell you now very briefly what you can find inside, but I really encourage you to check it out and read it on your own.  So in the first chapter you can learn about the structure of the membership of the community.  We'll tell you who are the members, when they joined and when their term at the committee ends.  You can also find out how members are added and removed from the community. So it's all transparent now.  Then we also dive straight into the most important chapter of the whole thing,  which is how we handle code of conduct evaluations. And you can learn about our own code duty animation,  go through the entire process since the report is made until it's considered closed,  as well as learn about the shape-harding and how we make decisions.  Then the equally important section is dedicated to the way we keep records.  Who has access and for how long and how is there information and where we store it.  It's all in there and public.  One of the most valuable services we provide to the community is a central record of all code of conduct evaluations  that took place in different, often very disconnected parts of our community.  So we have done this for a while, but now we are quite officially offering a way for community organizers  to reach out to us before their event takes place to make sure that none of their attendees is blacklisted with us.  And we also extend this invitation to use the service to other Python communities, not just Django.  And last but not least, you can find about how we handle transparency and see statistics of reports  and actions taken, as well as a number of blacklisted and black people.  And we are still planning to expand on this section in the future,  but so we hope that this is just a small step towards something bigger.  So what's the goal? We hope that making this documentation public is going to help us raise  awareness about the work we are doing, as well as demystify the process of what happens when a report is made.  We realize that code of conduct can be scary for some, and we like to show exactly how we deal with issues arising  so that the decision to report something is as straightforward and obvious as possible.  We also hope that making this transparent, we're going to help other communities outside of Django  world to make their processes better, because code of conduct is very important, but only when it's enforced.  Just having it published on the website is not enough, and it took us quite a while to figure how this whole thing works,  so we hope that we're going to help other communities make this happen.  And last but not least, we are looking to improve our processes with your feedback,  and I encourage you to take a look at our issues, on our pull requests, and we are excited to see your impact on it.  And last, I'd like to thank everyone who painted the SF code of conduct committee,  as well as many members of the community who had to make this happen.  Alright, hello, I'm Rachel. I'm here to talk about inspiring women to fall in love with programming.  I talk fast, and being up here, I'm a little bit nervous, so I'll talk to you faster,  but that's okay because most of you are native English speakers.  I come from recently Korea, so it's kind of new for me.  Okay, so first let me, who am I? I'm Rachel. I studied Spanish and French, Spanish and French in university,  and then I taught English in Korea. I also learned Korean, Korean, and then I started studying Python to try to change careers,  and now I do Django, so that's kind of my background.  Okay, so, anybody know what this is? Have you ever seen this before? It's a job.  They're called knocker-uppers, and what they do is they, one of them blows something like a stone  or to knock the window to wake people up. Before, we had alarm clocks, and the other one would knock it with a pole.  I kind of got inspired by seeing another talk by Sally Williams, and she was explaining that jobs change,  and jobs are changing now, too. So, let me talk about this.  So, this is something we kind of can relate to. Jobs are changing. This is factory,  but also like in banking, traders, it's all starting to change. It's called the Fourth Industrial Revolution,  and so let's take a look here at the WEF in January of this year.  But I report in five years, not like 20 years from now, it's five years, seven million jobs will disappear,  and only two million will be replaced. And this number is because smart technology, robots, etc.,  but this number will disproportionately affect women because, for example, if this continues,  four jobs that men will lose, only one will be replaced, but for women, 20 jobs that will be lost,  only one will be replaced. So, that's why it's really important to get more women, not just in the schools  and start education, but now. And it's not just programming. It's CS plus X.  I'm sure some of you have heard of this, but it's CS plus fashion, CS plus education, CS plus medicine.  It's not a separate field. They're all going to be combined.  Okay, so, and how can we do that? I'm sure you guys have heard this. Jangle Girls a lot recently,  and that's kind of where I come from. Jangle Girls chapter in Seoul, and Jangle Girls is a one-day workshop  to inspire women to fall in love with programming. So, what I want to talk today is about what's next.  This is our workshop in Seoul. Last year was the first.  What our goal is and what I hope to achieve is not just inspiring women, but supporting them on their next step.  So, after they're inspired, what do they do? In Seoul, we have a curriculum, first workshop, and then coat camps.  And we have a two-month coat camp to go back to the basics and learn Python and Django, HTML, CSS.  And then we do two-month base coat camp. It's all free, and with sponsor support, that will focus on making your own project.  So, you've learned it. Now, do something with it, and that's the best way to learn it.  All right, and here we have, if you go to our website, DjangoGirlsSoul.org.  You can see a bunch of about 15 projects came out of that. Websites online, and we even had one Android app.  We also did a lot of community events, workshops, regular study meetups on the weekends.  So, I want to encourage other cities and other DjangoGirls communities, or you can start your own, to continue education after the workshop.  All right, and we learned by doing and master by teaching. We're working on a nonprofit website.  I'd like some help if you could, but because our members are all contributing, myself included.  This was a participant. She became a coach the next time around, master by teaching.  So, how can you contribute? You can be a coach or an organizer in your own city.  You can offer sponsorship for our events. You can offer scholarships to your events or other workshops.  Also, contribute. DjangoGirls.org slash contribute. You can find other ways to contribute.  Or, GitHub DjangoGirls code camp. There's the light leadership nonprofit project for a school in Peru we're making.  And also, we're trying to develop a curriculum for supporting women after the workshop.  So, I hope I inspired you to help us inspire women to fall in the program. Thank you.  So, I wanted to start off today, and I have some notes, but I'm going to try to not look at or follow them very much.  Who in the room has used Docker before? You can just see a show of hands.  So, I see some hands not up. That's good. Some of you will not know that I don't know what I'm doing.  So, I just want to also disclaim none of the code I'm using today is mine, because then it really wouldn't work.  Like, really wouldn't work. So, if you haven't used this, I'm not going to teach you anything today.  You're just going to see me use Docker, but what I'm really hoping is that it inspires you to try using it,  because it's an amazing tool and I love using it daily.  And I try to tell everyone who hasn't used it before that they should get out there and try using it.  So, this is me, Adjo Cronin, and I worked for CacheDAR in Portland, Maine.  So, first off, does installing dependencies ever make you feel like this?  I know I've been in a few situations. This was my first Django shop working at CacheDAR,  and I think I spent about a month installing things and figuring out, like, oh, I'm missing another system requirement.  Oh, I'm missing another system requirement. And it was just really kind of a pain to get up and running.  So, fear dependency hell no more, because with Docker, all things are possible. You don't need to install anything.  So, regardless of what operating system you're on, it's now supported on Mac OS,  it's supported in Windows, it's supported in Linux.  So, really, no matter what you're running, it's a great tool to have.  And it's time for our first demo. So, let's see if I can fall flat on my face really quick.  What I'm going to do is I'm actually going to start a brand new project.  So, we're going to do Django admin start project.  And can you see that on the big screen, everybody? Is that?  Okay. New project.  All right. So, we're going to go in the new project. I'm going to create a requirement.  I'm going to put Django in it.  And save that.  And then I'm going to create a Docker file.  And I'm going to use the official Docker image.  So, all I have to do is say this container is from Django on build.  And that's the on build version of the Django Docker container.  From there, I can just say Docker build. I'm going to tag it and call it Docker demo.  And so, what this is going to do is it's going to run through their Docker container that they've provided,  run the steps that they have, and it by default just runs manage.py.  So, basically, it's going to do everything for me. I didn't have to write any code.  And this project is going to hopefully run without a problem.  So, now, I'm going to run my Docker demo.  And, of course, it fails because I still have something running.  So, one second. Get rid of those.  All right. So, my Docker demo is up and running.  As you can see, it kind of looks like it's just hanging,  but that's because I didn't attach to or watch what's going on in the container whatsoever.  So, it's going to be a little bit faster.  So, it's going to run on the Django container.  So, I'm going to run it.  I'm going to run it.  So, this is going to run on the Django container.  It's going to run on the Django container.  So, if you've used Docker, have you used Docker compose?  Okay. So, if you haven't used Docker compose, basically, it's an easy way to have an entire configuration file  that says run this this way, run that this way.  You can have your database, your app, your everything all configured, pre-configured.  Yeah, I can do all of this with one command.  Whoa.  All right. So, we're going to go ahead and try this now.  And go back out.  And, yeah. Thank you.  I'll just go back in with something different.  Ah, no.  Oh, good call.  The nerves are getting to me.  So, Docker composing Django.  And I'm just going to run Docker compose up.  Now, I've already downloaded all of the files from before,  which is why you're not staying here for 20 minutes watching things download.  I figured that would probably be a good idea.  So, it's up. It's running.  We're going to go to localhost 80 for this one.  And I have a website.  So, this is running a database.  It's running Django.  It's fully functional.  And it took me one command in 15 seconds per run.  So, if you've never used it before,  I highly recommend going and taking a look.  And thank you all very much.  Thank you.  Thank you very much.  Thank you very much.
DjangoCon_US_2016_-_Day_2_Lightning_Talks_by_Many_People_kDg93T4_rtk_0_47.png DjangoCon_US_2016_-_Day_2_Lightning_Talks_by_Many_People_kDg93T4_rtk_48_167.png DjangoCon_US_2016_-_Day_2_Lightning_Talks_by_Many_People_kDg93T4_rtk_168_239.png DjangoCon_US_2016_-_Day_2_Lightning_Talks_by_Many_People_kDg93T4_rtk_240_587.png DjangoCon_US_2016_-_Day_2_Lightning_Talks_by_Many_People_kDg93T4_rtk_588_3407.png DjangoCon_US_2016_-_Day_2_Lightning_Talks_by_Many_People_kDg93T4_rtk_3408_9383.png DjangoCon_US_2016_-_Day_2_Lightning_Talks_by_Many_People_kDg93T4_rtk_9384_11555.png DjangoCon_US_2016_-_Day_2_Lightning_Talks_by_Many_People_kDg93T4_rtk_11556_11687.png DjangoCon_US_2016_-_Day_2_Lightning_Talks_by_Many_People_kDg93T4_rtk_11688_12251.png DjangoCon_US_2016_-_Day_2_Lightning_Talks_by_Many_People_kDg93T4_rtk_12252_14027.png DjangoCon_US_2016_-_Day_2_Lightning_Talks_by_Many_People_kDg93T4_rtk_14028_16007.png DjangoCon_US_2016_-_Day_2_Lightning_Talks_by_Many_People_kDg93T4_rtk_16008_16115.png DjangoCon_US_2016_-_Day_2_Lightning_Talks_by_Many_People_kDg93T4_rtk_16116_16871.png DjangoCon_US_2016_-_Day_2_Lightning_Talks_by_Many_People_kDg93T4_rtk_16872_17831.png DjangoCon_US_2016_-_Day_2_Lightning_Talks_by_Many_People_kDg93T4_rtk_17832_19643.png DjangoCon_US_2016_-_Day_2_Lightning_Talks_by_Many_People_kDg93T4_rtk_19644_20915.png DjangoCon_US_2016_-_Day_2_Lightning_Talks_by_Many_People_kDg93T4_rtk_20916_21623.png DjangoCon_US_2016_-_Day_2_Lightning_Talks_by_Many_People_kDg93T4_rtk_21624_22355.png DjangoCon_US_2016_-_Day_2_Lightning_Talks_by_Many_People_kDg93T4_rtk_22356_32015.png DjangoCon_US_2016_-_Day_2_Lightning_Talks_by_Many_People_kDg93T4_rtk_32016_40955.png DjangoCon_US_2016_-_Day_2_Lightning_Talks_by_Many_People_kDg93T4_rtk_40956_42251.png DjangoCon_US_2016_-_Day_2_Lightning_Talks_by_Many_People_kDg93T4_rtk_42252_42623.png DjangoCon_US_2016_-_Day_2_Lightning_Talks_by_Many_People_kDg93T4_rtk_42624_44015.png DjangoCon_US_2016_-_Day_2_Lightning_Talks_by_Many_People_kDg93T4_rtk_44016_44303.png DjangoCon_US_2016_-_Day_2_Lightning_Talks_by_Many_People_kDg93T4_rtk_44304_44699.png DjangoCon_US_2016_-_Day_2_Lightning_Talks_by_Many_People_kDg93T4_rtk_44700_44939.png DjangoCon_US_2016_-_Day_2_Lightning_Talks_by_Many_People_kDg93T4_rtk_44940_45779.png DjangoCon_US_2016_-_Day_2_Lightning_Talks_by_Many_People_kDg93T4_rtk_45780_47867.png DjangoCon_US_2016_-_Day_2_Lightning_Talks_by_Many_People_kDg93T4_rtk_47868_50855.png DjangoCon_US_2016_-_Day_2_Lightning_Talks_by_Many_People_kDg93T4_rtk_50856_51263.png DjangoCon_US_2016_-_Day_2_Lightning_Talks_by_Many_People_kDg93T4_rtk_51264_51407.png DjangoCon_US_2016_-_Day_2_Lightning_Talks_by_Many_People_kDg93T4_rtk_51408_51875.png DjangoCon_US_2016_-_Day_2_Lightning_Talks_by_Many_People_kDg93T4_rtk_51876_51983.png DjangoCon_US_2016_-_Day_2_Lightning_Talks_by_Many_People_kDg93T4_rtk_51984_52127.png DjangoCon_US_2016_-_Day_2_Lightning_Talks_by_Many_People_kDg93T4_rtk_52128_52631.png DjangoCon_US_2016_-_Day_2_Lightning_Talks_by_Many_People_kDg93T4_rtk_52632_53531.png DjangoCon_US_2016_-_Day_2_Lightning_Talks_by_Many_People_kDg93T4_rtk_53532_53639.png DjangoCon_US_2016_-_Day_2_Lightning_Talks_by_Many_People_kDg93T4_rtk_53640_53807.png DjangoCon_US_2016_-_Day_2_Lightning_Talks_by_Many_People_kDg93T4_rtk_53808_53832.png