DjangoCon US 2015: Lightning Talks - Part 2
CC Attribution 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 purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Filippov, Dmitry
Bailey, Paul
Hunner, Trey
Rivas, Eduardo
Sumner, Jeff
Saldana, Francisco
Merx, Raphael
Tauber, James
Shubernetskiy, Miroslav
Ronacher, Armin
Sterne, Brendan
Keith-Magee, Russell
Lightning Talks Dmitry Filippov "Django assistance in PyCharm" Paul Bailey "End the Holy Wars of Formatting" Trey Hunner "JavaScript is Becoming Pythonic" Eduardo Rivas " Sublime Text Django" Jeff Sumner "Texas Swim Center" Francisco Saldana "Keeping Fast Fast: Rapid Iteration with TransactionTestCase" Raphael Merx "Mocking Outbound Requests with HTTPretty" James Tauber "Building a Learning Management System with Pinax" Miroslav Shubernetskiy "Filtering in Django" Armin Ronacher "rb - Scaling Redis in Python" Brendan Sterne "Code Wiki" Russell Keith-Magee "Professional Yak Coiffure"
 I'm so excited to be here today and opening this Lighting Talk session. I'm Dmitry Filipov, Python product manager. And in this talk, I'm going to show you some of the essential Python features that make many Django developers more productive. So here I have a very simple Django Pulse project opened in PyCharm. And very first feature I wanted to show you is Django Managed Py Console. You can get it by hitting Ctrl Alt R. Here's it. You can just start typing the task name. It all completes everything. It also provides you the options you have for this task. Here is the app name. So our application. It also supports the fuzzy search and completion so you can just type the middle part of the task name and it will also complete it. You can also hit Ctrl Q and it will give you a quick documentation for that task. So here we have Django. Okay. One to free. One to free. And here how it works. Another cool thing about PyCharm is that it has really rich navigational capabilities. So you can go to everywhere, go to insert for any file or model or method just by clicking double shift. For example, let's go to the tail view. We can also go to the template by just clicking this small icon here. We can go back by clicking this one. Choosing the right one. We can go to the URLs by clicking Ctrl B, going back. And this is really useful to go around your code. Another great thing and a great feature in PyCharm that many Django developers like the most from the feedback that I've got is the PyCharm debugger. It can be used to debug the Python code without note up, but it also can be used to debug Django team plays. So just let's go to the team plate. Put some break points right inside the editor here, here and here and run the Django server in the debug mode. PyCharm automatically opens the browser. So we go here. And this is a point when PyCharm debugger stops the execution and we have everything here. You can inspect your variables. You can move them to watches. You can even set values for them. Like right here too. And do other ordinary things like stepping through your code, navigating to the next break point, all the usual stuff. So here how it works. And the last but not the least thing I wanted to show you is how I run my tests. So I'm navigating with search everywhere to my test file. You can see the bunch of tests here. I'm just creating new run configuration. It would be Django test configuration. Give it a name test. PyCharm recognizes all the tests in your file and in your project actually. You can run it. And you can see that all tests are passed. You can see the progress here, the test results here. You can navigate to any test. Right from here, break it, run it. Result failed. Fix it. Run it again. And now we're all set. So this was just a quick demo of PyCharm capabilities. Please feel free to... I don't know why it doesn't work. Okay. Please feel free to visit our website to learn more. Follow us on Twitter. If you have any questions, I'll be around. And please feel free to request any features you might have in mind. They are very welcome. So thank you very much. Okay. My name is Paul Bailey and I'm going to talk about ending the holy wars of formatting. So I know this was mentioned at least in one other talk and we had two talks about style. But if you've never seen the Beyond Pep 8 video from PyCon 2008, it's great by Raymond Heddinger, he talks about going beyond just format spacing and going into better architecture decisions and things that you should do to make your code better. And one of the great quotes from the talk is, pepe unto thyself and not unto others. So use it as a tool to make your code better, but not necessarily to beat other people down. But there's a problem with this. Where Python Aces, I mean one of the big reasons we get into Python is because we love elegant code. Some of us are probably OCD and like to like have everything lined up exactly. We get kind of mad when things go over 80 characters. And so we are wasting mental energy and as developers a lot of times we're fighting styles in code reviews. Maybe we're spending too much energy on spacing and things that don't mean as much. The naming talk was great today. That's definitely something you want to focus more energy on than some of your just trivial formatting things. And then also we have developers that are maybe doing Python that are coming from another background, they have different sense of style, older, newer developers, different languages. And styles change over time. Also I kind of want to use this to basically say like I have a secret confession. I like two space indentations instead of four. Yes, but exactly. Wow. At least it's not three space indentation. I think that's like the worst. Yes, I know. It's awful. But there is a solution. We don't have to waste our time and our mental energy on just trivial formatting issues. We can auto format our code and have a consistent style throughout our whole code base with not much work. So this was actually popularized by the Go format tool written for Go. And there's actually a tool for Python that was released in March by Google. It's called yet another Python formatting. Actually they don't have that anywhere in there. I'm assuming that's what it means. So there's a link to the GitHub. You can also pip install it. And also we're web developers. So we're probably doing JavaScript formatting. There's a JavaScript formatting tool by RDO called JS format. And so just to kind of run through a little example here, I'm the web chair for PyTexas. So I went ahead and ran this on the PyTexas code. And it is a newer tool, like I said. So some of the options or features aren't there yet. So I wrote a little script that basically lets me, you know, I don't want to run formatting on migration. That's generated code. So let's just skip some of that. So you know, I put a few options in there that aren't in the default tool and made this little script. You can copy this and kind of, you know, use it to your own risk. But there's three different styles of coding that come with the tool by default. There's a Google, there's a Pepe, and there's a Chromium style, which all have their own default configurations. There's a million different options that you can kind of style with it. And I know, there you go. I set my two spaces. So what's it? Sure. I guess I don't know the Mac command. There we go. Yeah. So I mean, you can pass it like a JSON or dictionary type object, and it has, you know, hundreds of little tweaks that you can do to it to get the style that you want. And all of your formatting will, then all of your code base will be on that formatting. So this is fairly boring, but here you go. Have it come up here. This is all of the kind of white space changes that it did to the PyTexas code base. So if you're in Texas on the 25th or 27th, come to PyTexas. It's in College Station. And that's the end of my talk. My name is Trey. I'm going to show you how JavaScript is becoming a little bit more like Python. A word of warning, I will be going very quickly, and there are code examples on almost every slide. So ECMAScript is a language specification that JavaScript is based on. In this presentation, I'm going to show off features that were added in ECMAScript 6, which is also known as ECMAScript 2015. ECMAScript 6 isn't yet supported by any browsers, but you can start using it today. You just need to use Babel. Babel allows you to compile your ECMAScript 6 code down to ECMAScript 5 code, which is understood by all modern web browsers. This pre-compilation process is kind of like the pre-compilation step that's necessary for something like CoffeeScript. So our first new feature is FatArrows. FatArrows are a new shortened function syntax. FatArrows can be used kind of like Lambda functions in Python. They also have a longer syntax, but I'm going to only show off the short syntax in my slides today. We don't use lambdas very often in Python, partially because we don't use callbacks very often. In JavaScript, callbacks are used all the time, so FatArrow functions are actually really useful. When you combine FatArrow functions with JavaScript's array methods, they can serve a similar purpose to list comprehensions in Python. In addition to being easier on the eyes, FatArrow functions inherit the this binding of their outer scope. For anyone who has wrestled with JavaScript function binding, that's a really big deal. With template strings, you can now do string interpolation in JavaScript. So this is kind of like Python string's format method, except that template strings in JavaScript interpolate using the current scope automatically, unlike Python string format. JavaScript strings also allow you to make multi-line strings, so this is kind of like Python's triple-quoted strings. You can do string interpolation at the same time as well. JavaScript did not use to have a class syntax. It does now. This is what it looks like. Of course, no class implementation is complete without a properly loaded foot gun, so JavaScript also supports inheritance. I actually think the supersyntax is a little bit more elegant in JavaScript than it is in Python. You can see that in both of those methods there. I realize this is a lot of code. You can look at the slides afterwards. JavaScript now has a spread operator. This is similar to Python's argument unpacking operator. In Python, it's the asterisk symbol. In JavaScript, we use three dots. You can use this to unpack an array into the arguments of a function call. You can also use the spread operator to unpack one array inside of another array. In this example, combined would be the array 1, 2, 3, 4. The rest operator is basically the opposite of the spread operator. Again, instead of an asterisk, this uses three dots in JavaScript. This allows us to make a function that can take a variable number of arguments. So for example, our most difference function here takes any number of arguments. In this code example, we're using the rest operator once and the spread operator twice. JavaScript now allows you to specify default parameter values. This does not mean that JavaScript has keyword arguments. It doesn't. These are just default values for positional arguments. Just like Python, JavaScript now has iterable unpacking. You can unpack arrays into multiple variables or you can use this for multiple assignment or for variable swapping. Here X, Y, and Z would be 1, 4, and 2. This one is actually wishful thinking because this is only a proposed language feature. They're currently proposed syntax for JavaScript decorators. It looks just like Python's decorator syntax. So hopefully JavaScript will have decorators soon. JavaScript actually has modules now. They're properly namespaced and they work pretty similar to the way modules work in Python. So unlike many other languages, importing and namespacing, just like in Python, are linked together in JavaScript. So whenever you import something, it's going to be namespaced. So I just showed you a small handful of new features supported by JavaScript. You can learn more about Babel and about ECMAScript 6 or ECMAScript 2015 and try it out right from your web browser by going to the Babel website. Feel free to reach out to me on Twitter if you have any questions about this. All right. I'm here to talk a little bit about sublime text and how you can convert it into a more Django-friendly text editor or even an IDE. So I'm going to be focusing in three main plugins, Anaconda, something for Git or Mercurial if you're into that, and Emmet. So first of all, what you get for free when you're using sublime text to work with Python or Django, you get snippets, sync text highlighting multiple edit points, regex search, code folding, all that stuff. Right. So Anaconda is like the biggest one which you're going to install and you're going to get auto competition, go to definition, find usages of a function or the class or variable, display signatures of classes and functions, get a doc string for anything that you have in your environment, and live PEP 8 or your inflake 8 hinting in your code. So here I'm demonstrating two features. For example, in the first one on the top, you can see I'm importing from Django DB models import and let's say I want to know which are my options regarding integer fields. So I just type some integers and I get the competition for every single possible integer field I can get. So it's easier if you don't remember where to find some stuff in Django, like where is resolve, where is the generic views. And the second example you can see on the first line, I've imported the list view, the generic list view, and I can get the doc string right there in case you need help knowing what, getting a little hint on how to use it. The little white outlines you see in the second screenshot, they show the, where you have, in this case would be PEP 8 or flake 8 errors. For example, the list view I have imported by having been using it, so you can detect right as you write your code. If you're importing anything, I'm not using it, or defining a variable, I'm not using it, or a typo which has been in me many times where I just think I've defined a variable, but it turns out I just miss one letter and I get a huge exception. I don't understand. You can say from that with this. You can also get a full report on your PEP 8 and flake 8 errors. So for example, you can see if you're not complying with line lengths or whatever. You can also set your own rules here because I know not everybody follows every single little error that PEP 8 gives you. So for example, I'm using 89 characters there. You can do pretty much whatever you like. There's a configuration file. You can commit it to your version control, and that will make it easy for every developer using the same plugins as you to have the same linting capacities. So next one is for Git and Mercuro. You get VCS gutter, that is, little indicators right beside your line numbers. I'm showing later. You can do any VCS operation from the command palette, so you don't need to open a terminal or a separate application to do any of this at commit checkout, push, blame, diff, or log. So here, for example, if you see on the top one, on line 14 and 15, I have two little plus signs. Those are new lines. And then on line 17 and 18, I have a little red marker. You can see I deleted some lines there. So it's easy to see which code you've been touching before committing. And then I have a diff right in Sublime Text when I can see which lines I changed in a previous commit or a commit your coworker did or whatever. And then MET, you know, become a CSS, HTML, William Nelson, right? So you can expand CSS selectors into full HTML, every evaluation for pretty much any rule, and free prefixes in case you need to, you're not using auto-perfixes or something like that. So for example, this is Bootstrap. It's super useful for me for prototyping, lowering it to something like that. But in the first line on the top, you can see I've written a CSS selector, class container, class row. Then I want to have three four-column grid cells with an H2 and then a paragraph. Just hit Tab and you get a full HTML structure out of it. So it's super easy to get prototyping. It helps a lot with when you're working with templates too. And this is for prefixing. You know if you're using something new as Flexbox, you can simply prefix any CSS property with a dash and you will get automatic prefixing with the current browser support. So yeah, that's it. Thanks. I work here at the University of Texas and just a quarter mile east of here, there's the Texas Swim Center where we have, oh, it magically fixed itself. Sorry, where we have a million and a half gallon pool that all of our athletes can train in. And as part of that pool, they have a Longhorn Aquatics Club where they help recruit the next generation of Texas athletes. So we have six to 17-year-olds who come in and use the pool routinely. And they were actually doing like manual check-ins and getting really long lines and they requested that we build them a badge system just like the athletes had so that they could print out badges for everyone. They could scan in, solve all those line problems. We're kind of a new Agile team. We decided to try and apply best practices, listen to our user experience person and we started out by developing personas and writing user stories like we'd never done for the first time. We had some fun with it and there are a couple of the personas that we created, some of the user stories we wrote. And as we really thought about the people who are going to be using the center, we realized that our customer had sent us way too detailed a spec that in fact the badges weren't needed at all for these people. There were only about 600 of them. We ended up doing pen numbers. It saved us. We didn't have to do credit card processing for lost badges and fees for those. We didn't have to deal with printers by not just diving in and starting on exactly what they told us. It was a big lesson for us. So, badges, we didn't do any badges. This is what we ended up building. We had some JavaScript that we really enjoyed but I guess they wanted slides so there's no live demo here. Of the taking photos, we ended up using just the webcam and the HTML5, new audio and video capture and one of our lessons learned there. I don't think it's really ready for prime time but luckily for the Swim Center, there's really sort of three computers that it runs on. So we're able to easily say you must use the latest version of Chrome, the latest version of Firefox. And then it was able to work and so here's one where I took my picture afterwards. And as you can see, I haven't paid. Also that's not actually me. One of the other best practices we tried to do was actually for the first time write tests and do code reviews. So I was really proud of the part over on the right there where you can see we actually have tests. It's very exciting, maybe not for all of y'all but for us it was. And that we got together and almost every line of code we wrote, we reviewed together, looked over it and I was really excited to go and start looking at metrics to try and figure out, okay, of the bugs reported, how quickly were we able to respond when we actually had test frameworks and stuff. And the answer was we didn't have any bugs submitted during user acceptance test and during our first couple of weeks of production. So we couldn't get that metric. So if anyone else out there is still not quite in the doing tests, doing code reviews, I highly encourage you to do it. So my conclusions take the time to understand the requirements, to think about things before you just dive in. Capturing audio and visual on HTML5, I didn't think it was quite ready for prime time. But it looked great for a couple of computers that we could keep up to date. And code reviews and testing, if folks aren't trying them, please do so. Thank you. Hi. My name is Francisco Saldana. I'm a full stack developer for Ginger I.O. We do mental health care at scale. And I'm going to give a brief presentation about keeping fast things fast, performance, keeping performance degradation from affecting your rapid iteration with transaction test case. Okay. So what is fast? Fast is different to different things to different people. For product, fast is rapid iteration on new ideas. We want to test whether or not they are going to fail or whether they're going to succeed. Fast for users is user experience. We don't want users to be seeing like these loading indicators on their screens. So I make a product for doctors. Doctors don't have the time to wait for their web pages to load. They want to see patients. So why do we care about this? We care about this because we want to meet the needs. We want to rapidly meet the needs of consumers, of the customers. And we want to prove that that works before, quickly, because we're in start-up mode. We believe in beautiful user experiences so that because we want users to have, we know from the data that users will navigate away from our site. We will lose users if we don't provide them a latency-free, quick user experience. And there's a famous social network application founder that believes in this move fast and break things thing. So I am an engineer. And as an engineer, I really want to build systems that are reliable, that are stable, and that our customers can depend on. So how do we do this? How do we move fast without breaking too many things? So my proposal is, so Django gives us a lot of tools for that. I'll show you one of them. So here's your standard issue endpoint. We have the view function here. And we have an authorization decorator. And hey, we're going to add a REST serialization here to put data out. So it happens to be really, really slow because our user model is too big or something like that. And so we add a little optimization here to only get the fields that we need. So iteration happens. And one of us adds a new field to the REST serializer. So what's that going to do? So the problem is, now it's really, really slow. What happened? It turns out by adding this field with this optimization, this REST controller is now going to make a per user query. That's really bad. Even though it doesn't break the behavior of the endpoint, even if the endpoint passes all of the tests of correctness, it makes the performance incredibly bad. So how do we prevent that from happening? Consider transaction test case. So transaction test case is imported from the same place you get test case. You just say Django.tests import transaction test case. Make one of your tests inherit from it. And you get this awesome little utility function called assert number queries, assert num queries. So what we do to ensure that this doesn't happen is we can create like 100 users using like a user factory and then we can run our endpoint inside of this assert num queries context and it will report to us, it'll actually fail the test if the number of queries is not what we're expecting. So instead of getting performance degradation that gets reported to us through the support system, our continuous integration system actually catches this before we roll it out to production. So continuous integration for the win. It helps with mitigating problems with rapid iteration and it catches these degradation errors. Thank you so much. My name is Francisco Saldana. I'm available. I'm at Ginger IA. Thanks. All right. So building Django apps, we often find ourselves mocking requests for our server. Now what happens when we are the ones making requests to the outside world? Like we need a mocking tool for that. Today I'm going to talk about HTTP that lets you do exactly this. My name is Rafael and I work for a company called Capricity. So making real HTTP requests in your test is a pretty bad idea. One of the obvious reasons is that it's going to slow down your tests. But more importantly, if your remote endpoint is not available, the test is going to fail. So like for example, if you have a service architecture, you don't want to need to like put up your various services to make your build pass. Here's an example of a simple setup for HTTP. Let's say we want to call the Django project URL. So we decorate the test method with HTTP that activates. And then we can use the request module for example to make a request to that URI. And in the end, HTTP has by default returned a 200. And this test is going to pass without making a single request to the outside world. Now what about if we want to test that our remote endpoint has been called and that it's been called with like specific arguments? So imagine that I have a create cat method and this create cat method is supposed to call a remote endpoint on create a cat.com slash API. So I registered that URI. I make it return a 201 by default. I call my create cat method. And at the end of my test, I can test that the URI has been called and that the create cat method supply the name in the request body. Now what if we want the response that is mocked by HTTP to depend on the request that we made? So HTTP uses callbacks for that. And you can use it to almost create a simple mocking of the remote server. So coming back to the create cat example, let's say that the cats that we create remotely need to have an owner. But so I'm going to send a request to slash owners slash Bob slash cats. But the owner Bob can not exist in the remote server, in which case that endpoint is going to return a 404. And my create cat method is supposed to call that endpoint. And if it gets a 404, create Bob and then try again. So to do that, I can set a variable Bob exists and I set it to false at the beginning because Bob does not exist yet. I have a create owner endpoint that is going to turn that variable to true when it's called. I have a create cat endpoint that is going to return a 404 if Bob does not exist yet. And it's going to return a 201 if Bob does exist. So I use those callbacks in my HTTP that register URI functions. And then I can use my create cat method and at the end of my test, I can assert that Bob has indeed been created. If you're making requests with the request module, I would encourage using responses, which is pretty much does the exact same thing as HTTP but marks the request module itself instead of marking at the socket level. And I've heard that HTTP does not work well with Python 3, but responses does. So I'm sorry if I have for you today. So thank you. Hi, everyone. My name is James Tauber. I'm on Twitter at JTauber. I work for a company called Eldarion. It's one of the sponsors of this conference, but I'm not going to be talking about Eldarion. I'm going to be talking about PNACs and specifically nascent efforts to build a learning management system with PNACs. Now for those of you who haven't been to early JN Ocons and might not be familiar with what PNACs is all about, I'm going to start off talking a little bit about what PNACs are generally before diving into the learning management system. So PNACs provides what a lot of sites have in common so you can focus on what makes your site different. It's an open source project started that I started in 2008 with a bunch of other people to really supercharge Django development by providing all the kinds of things that you find yourself writing again and again in websites, whether it's things like profiles or notifications, announcements, teams, invitations, favoriting referrals, all of that kind of stuff PNACs aims to provide for you. So it's an ecosystem of reusable Django apps at its core, but it's also a bunch of project conventions, default templates using Bootstrap so you can get up and running really quickly, and starter projects, Django project templates that pre-combine certain reusable apps so you can get running right away. And even if you're not interested in the specifics of the learning management system stuff, PNACs is something you can use for pretty much all of your Django projects. Certainly I have for the last seven years and hundreds of other people have as well. Back in 2008, at the very first DjangoCon, I gave a talk about PNACs, it was the first talk about PNACs, and I had this slide that basically showed that these PNACs apps could naturally group into certain application domains, things like social networks, intranets, e-commerce and so on. But one of the use cases that I gave back in that talk was learning management. It was something that I saw as a possibility, but it's only been recently that we've actually really dived into learning management. What do I mean by a learning management system? I really mean any web application that facilitates learning. It could be online learning in a small environment, it could be a MOOC, it could be something that's used as a complement to face-to-face training and so on. But it's a web application that enables all of that kind of stuff. And I think of it really as having two aspects to it, the management system and the learning system. So the kinds of things that you typically get in the management system part of a learning management system are groups, enrollment, calendaring, announcements, profiles, messaging, blogs, forums, document management, submission boxes. What's interesting about all of those things is they're fairly generic things and they're exactly the kind of thing that PINACS has already, to a certain extent, provided either already or could very easily add. And so one of the things that we're doing as part of the PINACS open source project is bringing together these existing components, writing some additional ones in order to, you know, basically build an open source learning management system in Python and Django. But as well as the management system side of things, there's also the learning side of things that focuses more on activities that individual students do. Things like building quizzes, organizing things into learning paths, having adaptive learning, spaced repetition, all that kind of stuff, as well as gamification, things like levels, points, and badges. Now, again, PINACS does some of this already, especially the gamification stuff. We're trying to bring all that together to provide an open source learning management platform based on Django. So just a really quick example, one of the things that we're doing for the learning activities is a really pluggable object oriented architecture where you can basically say, I want a Lickert style quiz here where I give five options, but you can plug in what's the provider that tells you what question to ask what student when. You're not having to build any of the infrastructure around that. You can focus on the core learning algorithms. So we are going to be sprinting on this in particular, as well as PINACS in general. And I certainly encourage you all to join us there if you're interested specifically in learning management systems or what PINACS can do in general to help your Django development. PINACS project you can follow on Twitter. The URL is pinaxproject.com. Two GitHub repos you should know about, one for the overall LMS and one specifically for these pluggable learning activities. And that's it. Thank you very much. Hey, guys. So my name is Miroslav. By the way, great pronunciation of my last name. Very few people get that. So thumbs up. Why is it going automatic? All right. So I'll be talking about Django URL filter. This library I recently released which aims to help to do filtering from various data sources in Django by using structured URLs. So before we get to some examples of what that means, some use cases, why would you want to have filtering at all? So it's pretty useful when you have pagination. For example, Django admin, instead of seeing lots of, lots of, lots of pages, you might want to see a subset of the data. So filtering comes in pretty handy. It's also pretty useful in APIs, especially when you're doing bulk operations. So you want to update particular resources, but not all of them. So filtering comes in handy. It's also pretty nice when you're moving the filtering logic to the client side. For example, in Angular or React applications, users can use drop downs and text boxes or whatever to construct filtering criteria. So then all the client side needs to do is construct the filtering URL. We pass it to the backend and the backend will do the magic. So in order to accomplish all of that, this library tries to make a few promises and let's go over all of them one by one. So first promise, it tries to make the URLs as human-friendly as it can possibly can. By default, you can filter where the, you're filtering by fields having particular values. So for example, you can filter where ID is equal to one. You can also filter negated filters. Your ID is not one. You can also apply custom low-cups where ID is either one, two, or three. And you can do other standard Django or M-wokups like contains, exact, all the other goodness of Django. Another promise it makes is tries to make the filtering as safe as it can possibly can. So before actually doing any filtering in the backend, all the values submitted are validated by using Django form fields. So for example, since ID is an integer field to validate string digit one, we would use integer field for validation. Some more funny examples, last example where the column is joined. Usually it would probably be a date time column, maybe in database. But since the lookup is a year, we would use the integer field to validate 2015 versus date time field. Another promise it makes, it tries to make it as easy as possible to filter unrelated models. So for example, in this case, you're filtering, you're carrying user models, but filtering in an attribute in the profile model, so it comes in pretty handy. And as you might have noticed, a lot of these filters look a lot like Django or M, and that's because they are. That was the whole point of the design to make it as simple as possible. And I think Django or M does a really awesome job of making these filtering operations really easy. You don't have to think about joins and all this mean to one relationship. You just say, I want to filter that. So this library tries to do the same thing in the URLs. And finally, it makes the last promise that it's data source agnostic. What that means, it completely decouples parsing URL and validating all the filtering clauses to actually filtering data. What that means is you can filter data not only from Django or M or query sets. You can filter other sources of data. So for example, there's a work in progress right now to add support to filter SQL alchemy query objects. But you can add the filter backend to filter pretty much anything else. It could be Mongo collection, Python lists, Redis database, anything else you can think of. Also, out of the box, it comes in with a bunch of integrations. One of them is Django rest framework. So if you ever use Django filters library, it's very similar. You just supply a custom backend, fields you want to filter on, and it'll just do the magic. You can also use the library directly. It's pretty easy to use. You just construct a class for a filter set, instantiate it, give it a bunch of data, give it a query set, and then call the filter method, and it'll do the filtering. And that's about it. You can find more information on the documentation. Here's the link. Or you can ask me some questions on Twitter. And finally, a shameless plug, a word for dealer track. We're super excited to be sponsoring this Django con for the first time. So if you haven't stopped by, make sure to stop by our booth. We actually haven't made a bunch of pins. So if this is my favorite one, a cat Django knot. So if you haven't run out of them already, make sure to grab one. I think it's pretty cool. Thanks so much. Hello. How many of you are using Redis? How many of you have so much data that doesn't fit on a single server? Well, it will happen at one point that you have so much stuff that doesn't fit on one server. And why does it all have to? So basically, the whole point of RB, it's called the Redis Blaster. And it's basically a simplified version of talking to multiple Redis servers in a very convenient way. The idea is that you distribute the data set across multiple different servers, and you can basically have more Redis data than you can fit into the RAM on a single machine and do this a very convenient way. So it's not Redis cluster, but it is based on the same idea in the sense that you take the key and you distribute it across multiple different nodes that you have. The idea is that the library will automatically figure out the most efficient way to get the data from these individual servers by automatically building Redis pipelines, depending on which server you target. And when it's possible, it will also merge commands together. So if you do get, get, get, get, get, it will auto do and get to the right nodes. So even if the keys go to very different nodes, it will automatically build the pipelines. It's available on PyPI as RB. And the idea is that you just create this cluster. So the thing with RB is that it's completely based on PyRedis. So if you have used PyRedis before, this is exactly the same. It just wraps PyRedis in a more convenient way. So you, all you have to do is you create the cluster. You create it as many nodes as you think you will have at one point, and then you can point them to the same servers if necessary. And from that moment on, you can either use the routing client, which is the most convenient way for just getting very basic understanding of how it works. If you get the routing client from the cluster and from that point on, it works exactly as any other Redis client, it just execute commands and will automatically go to the right node. This however is serialized. So if you target, so we for instance have this 32 different nodes we target. So this will do 32 requests one after another, which is not ideal. As an alternative, you can use the mapping client, which you use with, with block. So it's just to with cluster map as client, and that client will then not return the response immediately. It will insert return promise objects. And then only after the with block ends, it will actually go out and send the request to the servers. We don't use G event in Century Anywhere. So because we are not really based on that, but this in itself does asynchronous IO behind the scenes for you, which is very convenient. So it doesn't actually spawn any threats or anything of that sort. And then just to do anything, you have this promise objects at the end of the map call you guaranteed that the value on it is resolved, but you can also attach callbacks if you want. You can also target all the machines at once. So if you want to flush the databases on all the machines, which is kind of scary, you can just do this cluster all its clients and, and it will just execute against them. You can also explicitly target with the fan out specific nodes. So if you want, for instance, to see which operating systems run on these particular hosts, you can just do that. And then the promise object is a dictionary of the host ID to the individual response that came back from it. And that's pretty much all. You can get the docs at RB.RitaDocs.org and the packages on PyPI available on the open source license. And if you haven't used Century yet, you should definitely look at what we're doing. We have the booth out there and we also sponsored the conference. So have a look at it as well. Thank you. Hey, folks, my name is Brian Stern. I work for Indeed. And I really, really believe that everyone should be able to automate the boring stuff with Python, not just developers, but like salespeople and marketers and client support and all that kind of stuff. And so we piloted something I think may be interesting to y'all. It's a concept like a code wiki. And so what is it? Well, a collection of self-contained pages of useful code. And for example, some marketing person might need to know like what are, you know, Indeed, what are the top 10 things that people are searching for right now? And that's really just a SQL statement and a print statement. And so that's like a document that you could put into a code wiki and then run it and so forth. Or maybe you want a graph. So you, you know, do some SQL code and then you plot something, you know, that could be a document in a code wiki. It might be useful for someone to gather this data. The code wiki idea is based on my Python notebook and if you don't know what that is, it's a JSON document that has basically an input cell where you put some Python in there. And then when that runs, it puts the output in a matching output cell and then another input cell, output cell comes from the scientific community and it's awesome. And so these form the basis of pages in the code wiki. And so anything that you can do in Ipython notebook, you can do in your code wiki. And so that means you've got obviously the full power of Python, which is amazing. Full pandas for data manipulation and so forth. And it has some syntactic sugar to make SQL really easy and it actually is going to support multiple languages. Also you know, you gather data from multiple sources and then you want to really easily output them. And so it supports some syntactic sugar for like putting HTML templates in there. And this is something we added, mark down. So you can just quickly like gather data from a couple sources, put a little mark down to render some HTML. And of course if you want to iterate through results coming from SQL or some other data source like Google spreadsheets, you can use Django templating and then that will use that to generate this nicely formatted output. A really neat extension of this idea is if you've got a page in a code wiki and it does something useful, but what if you want to change one of the parameters? So you want the top search terms but not in the US in France. Okay, well why don't we make these pages parameterizable and we did it by convention, the first cell in the ipython notebook. If you assign things, that becomes a parameter to that notebook. And then what you can do is you can basically have a page in your wiki that runs in a dashboard mode. When someone goes to it, it says, oh, you know, enter the parameters and run it. And then it'll run with those parameters. So for example, that plotting, you know, document, here it is with three parameters. You can choose what country you want to look at and the date range for this particular search. It's, you know, a pilot project. We kind of released it out there just to see what would happen. And it turns out that lots of people really jumped on this idea and started to automate the boring parts of their jobs, pulling data from different services, filtering, joining and so forth. And so this is what it looks like in dashboard mode. You know, you go to the page, you can enter your queries. It has defaults. You hit go. It's defaults. And one of the other neat things is, well, what if you could just subscribe to this daily? So the idea is like, I want this report to show up in the morning. And so you can easily put in some parameters, click, click, click, click, click, and then we have it on a cron and it just automatically runs and emails you. We have a configurable permission system. So some people can just run these dashboards but not see the code behind it. Other people can see the code. And the idea is that it's a shared learning environment. So people go to this and see, like, what did you do to automate part of your job? Oh, let me copy that. And so, like, a salesperson can take an existing one, make some modifications, and now they've got something useful for them. Our security people, this is what they said. So obviously, you know, you're running, like, user-supplied code on a web server. So what we had to do was isolate the code. And so what we do is we, like, drop an iPython notebook, which is just JSON, onto a queue. And we've got a cluster of Docker containers that basically spin up, run it, take the JSON output, and send it back, and then get rid of the container. And we also run those in a restricted VLAN. So you've got some security around where the code actually runs. And you can imagine that, you know, with the Power Python, you can access data basically from anywhere and join it together. So you can do some really interesting things here, like, here's an example that, you know, goes to a particular Indeed page using Selenium right from the code wiki that goes to a page, takes a picture, and emails it to me. So if I want to just check the state of a particular page every day. This has sort of unleashed the Kraken. We now have, I think, over 500 of these documents. And we've got people from all over the organization writing them. It's been really interesting to sort of see the take off of this concept of, like, this shared code wiki thing. So that's it. We're going to open sources. But it's not quite ready yet. And if you're interested in this concept, I'm happy to talk more about it if anyone's interested. So thank you. All right. So, yeah, my name is Russell Keith McGee. At this point, you probably know me from my work on Django. What you may not know is that I've also got an interest in user interfaces, especially native user interfaces. My motivation here is to develop tools that follow the UNIX philosophy of doing one thing and doing it really well, but with a humane and pretty user interface on front of it. I've been collecting these experiments for a while under the heading of a project called Beware because my end goal is to have a wide range of IDE-like pieces, test runners, debuggers, maybe even a text editor, but as standalone tools, not as one great big monolithic integrated IDE. The journey started for me two years ago when I released a tool called Cricket. Cricket is a GUI test runner for Python. You pip install Cricket into your virtual environment. You run it on your project and it throws up a GUI like this, which discovers all of your tests and allows you to run the test suite. You can then see the full structure of your test suite and the tree on the left-hand side. You can see the progress of the test suite as it runs. You can see which tests are passing, which ones have failed. You can inspect that information while the test suite is actually running. Cricket was built using TKInter, which is the widget toolkit which comes out of the box with Python, but TKInter has some quirks. That started for me a very long process of yak shaving. The first step was a new widget toolkit called Toga. Toga is a cross-platform 100% system-native, Python-native widget toolkit that you can install using pip install Toga. It's still very early days, but you can use it on OSX, on Linux, and if you squint hard enough, Windows, all from the same source code base. There are lots of other widget toolkits out there, QT, WX. You have to really have a good reason to write a new one. Being pure Python is one of those reasons, and it's mildly compelling. QT and WX aren't pip installable because there is a great big binary component that needs to exist. Toga is 100% pure Python. That's probably not enough. A little over a year ago, I decided to try and make Toga work on mobile platforms. So that you would be able to write cross-platform iOS and Android applications in Python. Now, of course, in order for Toga to work on mobile platforms, Python needs to work on mobile platforms. So for the last year, most of what I've been doing on this project has been looking at Python on mobile. That works been going pretty well. On iOS, there is now a patch in the ticket tracker, for the Python ticket tracker, that enables iOS build support in the main tree. That's also been wrapped up into a separate project, so you don't have to wait until that patch is merged into the tree. It's completely, it will work completely standalone. And about a month ago, I announced a tool called Briefcase to make the process even easier. Briefcase is a distu-tools extension that will convert any project with a setup.py file into a working native iOS mobile project, including installing all of the local native dependencies. And just quietly also works on OSX, so you can get a standalone.app that you can distribute with a fully self-contained version of Python. Now, on Android, it's a little bit more complicated. Android really wants you to use Java. There is a patch for Android that lets you run Cpython on Android, but it doesn't really work that well for various reasons I can't go into here. But I do have something up my sleeves that will address this. I'm not announcing it now. I will be on Saturday when I'm at the Vancouver Pie Day. So watch this space. And if you want to know more, I am susceptible to having drinks bought for me. I'm not just interested in mobile, though. I want Python all the things. So what about the browser? Well, I've got a story there, too, as well. A couple of weeks back, I announced a project called Batavia. Batavia is an implementation of a Python virtual machine written in JavaScript. Unlike projects like Sculpt, Brighton, or PyPyJS, it's tiny. It's just 10 kilobytes of compressed JavaScript. And it allows you to run Python bytecode in the browser. Why would you want to? Well, let's imagine you've got a Django form. That form is a validate method implementing some client-side validation logic written in Python. You want to have client-side validation that matches. Well, you can use introspection on the server side to extract the bytecode for the validate method, ship that to the client as part of the rendered page, and then run it in the client's browser. And presto, you will have language parity between the client and the server without having to dirty your hands writing JavaScript. Want to take a first spin? We'll go to see if our friends at Microsoft. You can visit batavia.azurewebsites.net, see a working demo, type in some Python 3 code, hit run, and it will run that Python 3 in your browser. So that's my YACOd. Unless I have but two hands with which to shave. So I definitely want help. If any of this sounds interesting, please come and get in touch. One more thing. As I said before, I sometimes do Django as well. One of those roles is present at the DSF. One of the things that DSF does is the DSF Fellowship. There is a program where the DSF pays to have Tim Graham work full time on Django. Django Fellowship however costs money. We did a fundraiser at the start of the year. It was extremely successful, but that money is starting to run out. So this is a shakedown. If we want the Fellowship to continue, we need to keep raising money. If you want to use Django commercially, we need your company. We need you to help us pay Tim. We think he's worth every penny, and then some. We hope you agree. If you want to contribute, head to DjangoProject.com. There you'll have a couple of options. As in January, you can donate once off, but we've now added the ability for monthly subscriptions. If you can, we're really lucky to take that one up because that lets us establish a baseline income rather than having to do burst fundraising all the time. There's also some options for your Amazon Smile and Benevity if you can do your employee does donation matching. Thank you very much. Thank you.
 I'm so excited to be here today and opening this Lighting Talk session.  I'm Dmitry Filipov, Python product manager.  And in this talk, I'm going to show you some of the essential Python features that make  many Django developers more productive.  So here I have a very simple Django Pulse project opened in PyCharm.  And very first feature I wanted to show you is Django Managed Py Console.  You can get it by hitting Ctrl Alt R. Here's it.  You can just start typing the task name.  It all completes everything.  It also provides you the options you have for this task.  Here is the app name.  So our application.  It also supports the fuzzy search and completion so you can just type the middle part of the  task name and it will also complete it.  You can also hit Ctrl Q and it will give you a quick documentation for that task.  So here we have Django.  Okay.  One to free.  One to free.  And here how it works.  Another cool thing about PyCharm is that it has really rich navigational capabilities.  So you can go to everywhere, go to insert for any file or model or method just by clicking  double shift.  For example, let's go to the tail view.  We can also go to the template by just clicking this small icon here.  We can go back by clicking this one.  Choosing the right one.  We can go to the URLs by clicking Ctrl B, going back.  And this is really useful to go around your code.  Another great thing and a great feature in PyCharm that many Django developers like the  most from the feedback that I've got is the PyCharm debugger.  It can be used to debug the Python code without note up, but it also can be used to debug  Django team plays.  So just let's go to the team plate.  Put some break points right inside the editor here, here and here and run the Django server  in the debug mode.  PyCharm automatically opens the browser.  So we go here.  And this is a point when PyCharm debugger stops the execution and we have everything here.  You can inspect your variables.  You can move them to watches.  You can even set values for them.  Like right here too.  And do other ordinary things like stepping through your code, navigating to the next  break point, all the usual stuff.  So here how it works.  And the last but not the least thing I wanted to show you is how I run my tests.  So I'm navigating with search everywhere to my test file.  You can see the bunch of tests here.  I'm just creating new run configuration.  It would be Django test configuration.  Give it a name test.  PyCharm recognizes all the tests in your file and in your project actually.  You can run it.  And you can see that all tests are passed.  You can see the progress here, the test results here.  You can navigate to any test.  Right from here, break it, run it.  Result failed.  Fix it.  Run it again.  And now we're all set.  So this was just a quick demo of PyCharm capabilities.  Please feel free to...  I don't know why it doesn't work.  Okay.  Please feel free to visit our website to learn more.  Follow us on Twitter.  If you have any questions, I'll be around.  And please feel free to request any features you might have in mind.  They are very welcome.  So thank you very much.  Okay.  My name is Paul Bailey and I'm going to talk about ending the holy wars of formatting.  So I know this was mentioned at least in one other talk and we had two talks about style.  But if you've never seen the Beyond Pep 8 video from PyCon 2008, it's great by Raymond  Heddinger, he talks about going beyond just format spacing and going into better architecture  decisions and things that you should do to make your code better.  And one of the great quotes from the talk is, pepe unto thyself and not unto others.  So use it as a tool to make your code better, but not necessarily to beat other people  down.  But there's a problem with this.  Where Python Aces, I mean one of the big reasons we get into Python is because we love elegant  code.  Some of us are probably OCD and like to like have everything lined up exactly.  We get kind of mad when things go over 80 characters.  And so we are wasting mental energy and as developers a lot of times we're fighting  styles in code reviews.  Maybe we're spending too much energy on spacing and things that don't mean as much.  The naming talk was great today.  That's definitely something you want to focus more energy on than some of your just trivial  formatting things.  And then also we have developers that are maybe doing Python that are coming from another  background, they have different sense of style, older, newer developers, different languages.  And styles change over time.  Also I kind of want to use this to basically say like I have a secret confession.  I like two space indentations instead of four.  Yes, but exactly.  Wow.  At least it's not three space indentation.  I think that's like the worst.  Yes, I know.  It's awful.  But there is a solution.  We don't have to waste our time and our mental energy on just trivial formatting issues.  We can auto format our code and have a consistent style throughout our whole code base with  not much work.  So this was actually popularized by the Go format tool written for Go.  And there's actually a tool for Python that was released in March by Google.  It's called yet another Python formatting.  Actually they don't have that anywhere in there.  I'm assuming that's what it means.  So there's a link to the GitHub.  You can also pip install it.  And also we're web developers.  So we're probably doing JavaScript formatting.  There's a JavaScript formatting tool by RDO called JS format.  And so just to kind of run through a little example here, I'm the web chair for PyTexas.  So I went ahead and ran this on the PyTexas code.  And it is a newer tool, like I said.  So some of the options or features aren't there yet.  So I wrote a little script that basically lets me, you know, I don't want to run formatting  on migration.  That's generated code.  So let's just skip some of that.  So you know, I put a few options in there that aren't in the default tool and made this  little script.  You can copy this and kind of, you know, use it to your own risk.  But there's three different styles of coding that come with the tool by default.  There's a Google, there's a Pepe, and there's a Chromium style, which all have their own  default configurations.  There's a million different options that you can kind of style with it.  And I know, there you go.  I set my two spaces.  So what's it?  Sure.  I guess I don't know the Mac command.  There we go.  Yeah.  So I mean, you can pass it like a JSON or dictionary type object, and it has, you know, hundreds  of little tweaks that you can do to it to get the style that you want.  And all of your formatting will, then all of your code base will be on that formatting.  So this is fairly boring, but here you go.  Have it come up here.  This is all of the kind of white space changes that it did to the PyTexas code base.  So if you're in Texas on the 25th or 27th, come to PyTexas.  It's in College Station.  And that's the end of my talk.  My name is Trey.  I'm going to show you how JavaScript is becoming a little bit more like Python.  A word of warning, I will be going very quickly, and there are code examples on almost every  slide.  So ECMAScript is a language specification that JavaScript is based on.  In this presentation, I'm going to show off features that were added in ECMAScript 6,  which is also known as ECMAScript 2015.  ECMAScript 6 isn't yet supported by any browsers, but you can start using it today.  You just need to use Babel.  Babel allows you to compile your ECMAScript 6 code down to ECMAScript 5 code, which is  understood by all modern web browsers.  This pre-compilation process is kind of like the pre-compilation step that's necessary  for something like CoffeeScript.  So our first new feature is FatArrows.  FatArrows are a new shortened function syntax.  FatArrows can be used kind of like Lambda functions in Python.  They also have a longer syntax, but I'm going to only show off the short syntax in my slides  today.  We don't use lambdas very often in Python, partially because we don't use callbacks very  often.  In JavaScript, callbacks are used all the time, so FatArrow functions are actually really  useful.  When you combine FatArrow functions with JavaScript's array methods, they can serve a similar purpose  to list comprehensions in Python.  In addition to being easier on the eyes, FatArrow functions inherit the this binding of their  outer scope.  For anyone who has wrestled with JavaScript function binding, that's a really big deal.  With template strings, you can now do string interpolation in JavaScript.  So this is kind of like Python string's format method, except that template strings in JavaScript  interpolate using the current scope automatically, unlike Python string format.  JavaScript strings also allow you to make multi-line strings, so this is kind of like  Python's triple-quoted strings.  You can do string interpolation at the same time as well.  JavaScript did not use to have a class syntax.  It does now.  This is what it looks like.  Of course, no class implementation is complete without a properly loaded foot gun, so JavaScript  also supports inheritance.  I actually think the supersyntax is a little bit more elegant in JavaScript than it is  in Python.  You can see that in both of those methods there.  I realize this is a lot of code.  You can look at the slides afterwards.  JavaScript now has a spread operator.  This is similar to Python's argument unpacking operator.  In Python, it's the asterisk symbol.  In JavaScript, we use three dots.  You can use this to unpack an array into the arguments of a function call.  You can also use the spread operator to unpack one array inside of another array.  In this example, combined would be the array 1, 2, 3, 4.  The rest operator is basically the opposite of the spread operator.  Again, instead of an asterisk, this uses three dots in JavaScript.  This allows us to make a function that can take a variable number of arguments.  So for example, our most difference function here takes any number of arguments.  In this code example, we're using the rest operator once and the spread operator twice.  JavaScript now allows you to specify default parameter values.  This does not mean that JavaScript has keyword arguments.  It doesn't.  These are just default values for positional arguments.  Just like Python, JavaScript now has iterable unpacking.  You can unpack arrays into multiple variables or you can use this for multiple assignment  or for variable swapping.  Here X, Y, and Z would be 1, 4, and 2.  This one is actually wishful thinking because this is only a proposed language feature.  They're currently proposed syntax for JavaScript decorators.  It looks just like Python's decorator syntax.  So hopefully JavaScript will have decorators soon.  JavaScript actually has modules now.  They're properly namespaced and they work pretty similar to the way modules work in  Python.  So unlike many other languages, importing and namespacing, just like in Python, are linked  together in JavaScript.  So whenever you import something, it's going to be namespaced.  So I just showed you a small handful of new features supported by JavaScript.  You can learn more about Babel and about ECMAScript 6 or ECMAScript 2015 and try it out right  from your web browser by going to the Babel website.  Feel free to reach out to me on Twitter if you have any questions about this.  All right.  I'm here to talk a little bit about sublime text and how you can convert it into a more  Django-friendly text editor or even an IDE.  So I'm going to be focusing in three main plugins, Anaconda, something for Git or Mercurial  if you're into that, and Emmet.  So first of all, what you get for free when you're using sublime text to work with Python  or Django, you get snippets, sync text highlighting multiple edit points, regex search, code folding,  all that stuff.  Right.  So Anaconda is like the biggest one which you're going to install and you're going to  get auto competition, go to definition, find usages of a function or the class or variable,  display signatures of classes and functions, get a doc string for anything that you have  in your environment, and live PEP 8 or your inflake 8 hinting in your code.  So here I'm demonstrating two features.  For example, in the first one on the top, you can see I'm importing from Django DB models  import and let's say I want to know which are my options regarding integer fields.  So I just type some integers and I get the competition for every single possible integer  field I can get.  So it's easier if you don't remember where to find some stuff in Django, like where is  resolve, where is the generic views.  And the second example you can see on the first line, I've imported the list view, the  generic list view, and I can get the doc string right there in case you need help knowing  what, getting a little hint on how to use it.  The little white outlines you see in the second screenshot, they show the, where you have,  in this case would be PEP 8 or flake 8 errors.  For example, the list view I have imported by having been using it, so you can detect  right as you write your code.  If you're importing anything, I'm not using it, or defining a variable, I'm not using  it, or a typo which has been in me many times where I just think I've defined a variable,  but it turns out I just miss one letter and I get a huge exception.  I don't understand.  You can say from that with this.  You can also get a full report on your PEP 8 and flake 8 errors.  So for example, you can see if you're not complying with line lengths or whatever.  You can also set your own rules here because I know not everybody follows every single  little error that PEP 8 gives you.  So for example, I'm using 89 characters there.  You can do pretty much whatever you like.  There's a configuration file.  You can commit it to your version control, and that will make it easy for every developer  using the same plugins as you to have the same linting capacities.  So next one is for Git and Mercuro.  You get VCS gutter, that is, little indicators right beside your line numbers.  I'm showing later.  You can do any VCS operation from the command palette, so you don't need to open a terminal  or a separate application to do any of this at commit checkout, push, blame, diff, or  log.  So here, for example, if you see on the top one, on line 14 and 15, I have two little  plus signs.  Those are new lines.  And then on line 17 and 18, I have a little red marker.  You can see I deleted some lines there.  So it's easy to see which code you've been touching before committing.  And then I have a diff right in Sublime Text when I can see which lines I changed in a  previous commit or a commit your coworker did or whatever.  And then MET, you know, become a CSS, HTML, William Nelson, right?  So you can expand CSS selectors into full HTML, every evaluation for pretty much any  rule, and free prefixes in case you need to, you're not using auto-perfixes or something  like that.  So for example, this is Bootstrap.  It's super useful for me for prototyping, lowering it to something like that.  But in the first line on the top, you can see I've written a CSS selector, class container,  class row.  Then I want to have three four-column grid cells with an H2 and then a paragraph.  Just hit Tab and you get a full HTML structure out of it.  So it's super easy to get prototyping.  It helps a lot with when you're working with templates too.  And this is for prefixing.  You know if you're using something new as Flexbox, you can simply prefix any CSS property  with a dash and you will get automatic prefixing with the current browser support.  So yeah, that's it.  Thanks.  I work here at the University of Texas and just a quarter mile east of here, there's  the Texas Swim Center where we have, oh, it magically fixed itself.  Sorry, where we have a million and a half gallon pool that all of our athletes can train  in.  And as part of that pool, they have a Longhorn Aquatics Club where they help recruit the  next generation of Texas athletes.  So we have six to 17-year-olds who come in and use the pool routinely.  And they were actually doing like manual check-ins and getting really long lines and they requested  that we build them a badge system just like the athletes had so that they could print  out badges for everyone.  They could scan in, solve all those line problems.  We're kind of a new Agile team.  We decided to try and apply best practices, listen to our user experience person and  we started out by developing personas and writing user stories like we'd never done  for the first time.  We had some fun with it and there are a couple of the personas that we created, some of the  user stories we wrote.  And as we really thought about the people who are going to be using the center, we realized  that our customer had sent us way too detailed a spec that in fact the badges weren't needed  at all for these people.  There were only about 600 of them.  We ended up doing pen numbers.  It saved us.  We didn't have to do credit card processing for lost badges and fees for those.  We didn't have to deal with printers by not just diving in and starting on exactly what  they told us.  It was a big lesson for us.  So, badges, we didn't do any badges.  This is what we ended up building.  We had some JavaScript that we really enjoyed but I guess they wanted slides so there's  no live demo here.  Of the taking photos, we ended up using just the webcam and the HTML5, new audio and video  capture and one of our lessons learned there.  I don't think it's really ready for prime time but luckily for the Swim Center, there's  really sort of three computers that it runs on.  So we're able to easily say you must use the latest version of Chrome, the latest version  of Firefox.  And then it was able to work and so here's one where I took my picture afterwards.  And as you can see, I haven't paid.  Also that's not actually me.  One of the other best practices we tried to do was actually for the first time write tests  and do code reviews.  So I was really proud of the part over on the right there where you can see we actually  have tests.  It's very exciting, maybe not for all of y'all but for us it was.  And that we got together and almost every line of code we wrote, we reviewed together,  looked over it and I was really excited to go and start looking at metrics to try and  figure out, okay, of the bugs reported, how quickly were we able to respond when we actually  had test frameworks and stuff.  And the answer was we didn't have any bugs submitted during user acceptance test and  during our first couple of weeks of production.  So we couldn't get that metric.  So if anyone else out there is still not quite in the doing tests, doing code reviews,  I highly encourage you to do it.  So my conclusions take the time to understand the requirements, to think about things before  you just dive in.  Capturing audio and visual on HTML5, I didn't think it was quite ready for prime time.  But it looked great for a couple of computers that we could keep up to date.  And code reviews and testing, if folks aren't trying them, please do so.  Thank you.  Hi.  My name is Francisco Saldana.  I'm a full stack developer for Ginger I.O.  We do mental health care at scale.  And I'm going to give a brief presentation about keeping fast things fast, performance,  keeping performance degradation from affecting your rapid iteration with transaction test  case.  Okay.  So what is fast?  Fast is different to different things to different people.  For product, fast is rapid iteration on new ideas.  We want to test whether or not they are going to fail or whether they're going to succeed.  Fast for users is user experience.  We don't want users to be seeing like these loading indicators on their screens.  So I make a product for doctors.  Doctors don't have the time to wait for their web pages to load.  They want to see patients.  So why do we care about this?  We care about this because we want to meet the needs.  We want to rapidly meet the needs of consumers, of the customers.  And we want to prove that that works before, quickly, because we're in start-up mode.  We believe in beautiful user experiences so that because we want users to have, we know  from the data that users will navigate away from our site.  We will lose users if we don't provide them a latency-free, quick user experience.  And there's a famous social network application founder that believes in this move fast and  break things thing.  So I am an engineer.  And as an engineer, I really want to build systems that are reliable, that are stable,  and that our customers can depend on.  So how do we do this?  How do we move fast without breaking too many things?  So my proposal is, so Django gives us a lot of tools for that.  I'll show you one of them.  So here's your standard issue endpoint.  We have the view function here.  And we have an authorization decorator.  And hey, we're going to add a REST serialization here to put data out.  So it happens to be really, really slow because our user model is too big or something like  that.  And so we add a little optimization here to only get the fields that we need.  So iteration happens.  And one of us adds a new field to the REST serializer.  So what's that going to do?  So the problem is, now it's really, really slow.  What happened?  It turns out by adding this field with this optimization, this REST controller is now  going to make a per user query.  That's really bad.  Even though it doesn't break the behavior of the endpoint, even if the endpoint passes  all of the tests of correctness, it makes the performance incredibly bad.  So how do we prevent that from happening?  Consider transaction test case.  So transaction test case is imported from the same place you get test case.  You just say Django.tests import transaction test case.  Make one of your tests inherit from it.  And you get this awesome little utility function called assert number queries, assert num queries.  So what we do to ensure that this doesn't happen is we can create like 100 users using  like a user factory and then we can run our endpoint inside of this assert num queries  context and it will report to us, it'll actually fail the test if the number of queries is  not what we're expecting.  So instead of getting performance degradation that gets reported to us through the support  system, our continuous integration system actually catches this before we roll it out  to production.  So continuous integration for the win.  It helps with mitigating problems with rapid iteration and it catches these degradation  errors.  Thank you so much.  My name is Francisco Saldana.  I'm available.  I'm at Ginger IA.  Thanks.  All right.  So building Django apps, we often find ourselves mocking requests for our server.  Now what happens when we are the ones making requests to the outside world?  Like we need a mocking tool for that.  Today I'm going to talk about HTTP that lets you do exactly this.  My name is Rafael and I work for a company called Capricity.  So making real HTTP requests in your test is a pretty bad idea.  One of the obvious reasons is that it's going to slow down your tests.  But more importantly, if your remote endpoint is not available, the test is going to fail.  So like for example, if you have a service architecture, you don't want to need to like  put up your various services to make your build pass.  Here's an example of a simple setup for HTTP.  Let's say we want to call the Django project URL.  So we decorate the test method with HTTP that activates.  And then we can use the request module for example to make a request to that URI.  And in the end, HTTP has by default returned a 200.  And this test is going to pass without making a single request to the outside world.  Now what about if we want to test that our remote endpoint has been called and that it's  been called with like specific arguments?  So imagine that I have a create cat method and this create cat method is supposed to  call a remote endpoint on create a cat.com slash API.  So I registered that URI.  I make it return a 201 by default.  I call my create cat method.  And at the end of my test, I can test that the URI has been called and that the create  cat method supply the name in the request body.  Now what if we want the response that is mocked by HTTP to depend on the request that we  made?  So HTTP uses callbacks for that.  And you can use it to almost create a simple mocking of the remote server.  So coming back to the create cat example, let's say that the cats that we create remotely  need to have an owner.  But so I'm going to send a request to slash owners slash Bob slash cats.  But the owner Bob can not exist in the remote server, in which case that endpoint is going  to return a 404.  And my create cat method is supposed to call that endpoint.  And if it gets a 404, create Bob and then try again.  So to do that, I can set a variable Bob exists and I set it to false at the beginning because  Bob does not exist yet.  I have a create owner endpoint that is going to turn that variable to true when it's called.  I have a create cat endpoint that is going to return a 404 if Bob does not exist yet.  And it's going to return a 201 if Bob does exist.  So I use those callbacks in my HTTP that register URI functions.  And then I can use my create cat method and at the end of my test, I can assert that Bob  has indeed been created.  If you're making requests with the request module, I would encourage using responses,  which is pretty much does the exact same thing as HTTP but marks the request module itself  instead of marking at the socket level.  And I've heard that HTTP does not work well with Python 3, but responses does.  So I'm sorry if I have for you today.  So thank you.  Hi, everyone.  My name is James Tauber.  I'm on Twitter at JTauber.  I work for a company called Eldarion.  It's one of the sponsors of this conference, but I'm not going to be talking about Eldarion.  I'm going to be talking about PNACs and specifically nascent efforts to build a learning management  system with PNACs.  Now for those of you who haven't been to early JN Ocons and might not be familiar with what  PNACs is all about, I'm going to start off talking a little bit about what PNACs are  generally before diving into the learning management system.  So PNACs provides what a lot of sites have in common so you can focus on what makes your  site different.  It's an open source project started that I started in 2008 with a bunch of other people  to really supercharge Django development by providing all the kinds of things that you  find yourself writing again and again in websites, whether it's things like profiles or notifications,  announcements, teams, invitations, favoriting referrals, all of that kind of stuff PNACs  aims to provide for you.  So it's an ecosystem of reusable Django apps at its core, but it's also a bunch of project  conventions, default templates using Bootstrap so you can get up and running really quickly,  and starter projects, Django project templates that pre-combine certain reusable apps so  you can get running right away.  And even if you're not interested in the specifics of the learning management system stuff,  PNACs is something you can use for pretty much all of your Django projects.  Certainly I have for the last seven years and hundreds of other people have as well.  Back in 2008, at the very first DjangoCon, I gave a talk about PNACs, it was the first  talk about PNACs, and I had this slide that basically showed that these PNACs apps could  naturally group into certain application domains, things like social networks, intranets, e-commerce  and so on.  But one of the use cases that I gave back in that talk was learning management.  It was something that I saw as a possibility, but it's only been recently that we've actually  really dived into learning management.  What do I mean by a learning management system?  I really mean any web application that facilitates learning.  It could be online learning in a small environment, it could be a MOOC, it could be something that's  used as a complement to face-to-face training and so on.  But it's a web application that enables all of that kind of stuff.  And I think of it really as having two aspects to it, the management system and the learning  system.  So the kinds of things that you typically get in the management system part of a learning  management system are groups, enrollment, calendaring, announcements, profiles, messaging,  blogs, forums, document management, submission boxes.  What's interesting about all of those things is they're fairly generic things and they're  exactly the kind of thing that PINACS has already, to a certain extent, provided either  already or could very easily add.  And so one of the things that we're doing as part of the PINACS open source project is  bringing together these existing components, writing some additional ones in order to,  you know, basically build an open source learning management system in Python and Django.  But as well as the management system side of things, there's also the learning side  of things that focuses more on activities that individual students do.  Things like building quizzes, organizing things into learning paths, having adaptive learning,  spaced repetition, all that kind of stuff, as well as gamification, things like levels,  points, and badges.  Now, again, PINACS does some of this already, especially the gamification stuff.  We're trying to bring all that together to provide an open source learning management  platform based on Django.  So just a really quick example, one of the things that we're doing for the learning  activities is a really pluggable object oriented architecture where you can basically say,  I want a Lickert style quiz here where I give five options, but you can plug in what's  the provider that tells you what question to ask what student when.  You're not having to build any of the infrastructure around that.  You can focus on the core learning algorithms.  So we are going to be sprinting on this in particular, as well as PINACS in general.  And I certainly encourage you all to join us there if you're interested specifically  in learning management systems or what PINACS can do in general to help your Django development.  PINACS project you can follow on Twitter.  The URL is pinaxproject.com.  Two GitHub repos you should know about, one for the overall LMS and one specifically for  these pluggable learning activities.  And that's it.  Thank you very much.  Hey, guys.  So my name is Miroslav.  By the way, great pronunciation of my last name.  Very few people get that.  So thumbs up.  Why is it going automatic?  All right.  So I'll be talking about Django URL filter.  This library I recently released which aims to help to do filtering from various data  sources in Django by using structured URLs.  So before we get to some examples of what that means, some use cases, why would you want  to have filtering at all?  So it's pretty useful when you have pagination.  For example, Django admin, instead of seeing lots of, lots of, lots of pages, you might  want to see a subset of the data.  So filtering comes in pretty handy.  It's also pretty useful in APIs, especially when you're doing bulk operations.  So you want to update particular resources, but not all of them.  So filtering comes in handy.  It's also pretty nice when you're moving the filtering logic to the client side.  For example, in Angular or React applications, users can use drop downs and text boxes or  whatever to construct filtering criteria.  So then all the client side needs to do is construct the filtering URL.  We pass it to the backend and the backend will do the magic.  So in order to accomplish all of that, this library tries to make a few promises and let's  go over all of them one by one.  So first promise, it tries to make the URLs as human-friendly as it can possibly can.  By default, you can filter where the, you're filtering by fields having particular values.  So for example, you can filter where ID is equal to one.  You can also filter negated filters.  Your ID is not one.  You can also apply custom low-cups where ID is either one, two, or three.  And you can do other standard Django or M-wokups like contains, exact, all the other goodness  of Django.  Another promise it makes is tries to make the filtering as safe as it can possibly can.  So before actually doing any filtering in the backend, all the values submitted are validated  by using Django form fields.  So for example, since ID is an integer field to validate string digit one, we would use  integer field for validation.  Some more funny examples, last example where the column is joined.  Usually it would probably be a date time column, maybe in database.  But since the lookup is a year, we would use the integer field to validate 2015 versus date  time field.  Another promise it makes, it tries to make it as easy as possible to filter unrelated  models.  So for example, in this case, you're filtering, you're carrying user models, but filtering  in an attribute in the profile model, so it comes in pretty handy.  And as you might have noticed, a lot of these filters look a lot like Django or M, and that's  because they are.  That was the whole point of the design to make it as simple as possible.  And I think Django or M does a really awesome job of making these filtering operations really  easy.  You don't have to think about joins and all this mean to one relationship.  You just say, I want to filter that.  So this library tries to do the same thing in the URLs.  And finally, it makes the last promise that it's data source agnostic.  What that means, it completely decouples parsing URL and validating all the filtering  clauses to actually filtering data.  What that means is you can filter data not only from Django or M or query sets.  You can filter other sources of data.  So for example, there's a work in progress right now to add support to filter SQL alchemy  query objects.  But you can add the filter backend to filter pretty much anything else.  It could be Mongo collection, Python lists, Redis database, anything else you can think  of.  Also, out of the box, it comes in with a bunch of integrations.  One of them is Django rest framework.  So if you ever use Django filters library, it's very similar.  You just supply a custom backend, fields you want to filter on, and it'll just do the magic.  You can also use the library directly.  It's pretty easy to use.  You just construct a class for a filter set, instantiate it, give it a bunch of data, give  it a query set, and then call the filter method, and it'll do the filtering.  And that's about it.  You can find more information on the documentation.  Here's the link.  Or you can ask me some questions on Twitter.  And finally, a shameless plug, a word for dealer track.  We're super excited to be sponsoring this Django con for the first time.  So if you haven't stopped by, make sure to stop by our booth.  We actually haven't made a bunch of pins.  So if this is my favorite one, a cat Django knot.  So if you haven't run out of them already, make sure to grab one.  I think it's pretty cool.  Thanks so much.  Hello.  How many of you are using Redis?  How many of you have so much data that doesn't fit on a single server?  Well, it will happen at one point that you have so much stuff that doesn't fit on one  server.  And why does it all have to?  So basically, the whole point of RB, it's called the Redis Blaster.  And it's basically a simplified version of talking to multiple Redis servers in a very  convenient way.  The idea is that you distribute the data set across multiple different servers, and you  can basically have more Redis data than you can fit into the RAM on a single machine and  do this a very convenient way.  So it's not Redis cluster, but it is based on the same idea in the sense that you take  the key and you distribute it across multiple different nodes that you have.  The idea is that the library will automatically figure out the most efficient way to get the  data from these individual servers by automatically building Redis pipelines, depending on which  server you target.  And when it's possible, it will also merge commands together.  So if you do get, get, get, get, get, it will auto do and get to the right nodes.  So even if the keys go to very different nodes, it will automatically build the pipelines.  It's available on PyPI as RB.  And the idea is that you just create this cluster.  So the thing with RB is that it's completely based on PyRedis.  So if you have used PyRedis before, this is exactly the same.  It just wraps PyRedis in a more convenient way.  So you, all you have to do is you create the cluster.  You create it as many nodes as you think you will have at one point, and then you can point  them to the same servers if necessary.  And from that moment on, you can either use the routing client, which is the most convenient  way for just getting very basic understanding of how it works.  If you get the routing client from the cluster and from that point on, it works exactly as  any other Redis client, it just execute commands and will automatically go to the right node.  This however is serialized.  So if you target, so we for instance have this 32 different nodes we target.  So this will do 32 requests one after another, which is not ideal.  As an alternative, you can use the mapping client, which you use with, with block.  So it's just to with cluster map as client, and that client will then not return the response  immediately.  It will insert return promise objects.  And then only after the with block ends, it will actually go out and send the request  to the servers.  We don't use G event in Century Anywhere.  So because we are not really based on that, but this in itself does asynchronous IO behind  the scenes for you, which is very convenient.  So it doesn't actually spawn any threats or anything of that sort.  And then just to do anything, you have this promise objects at the end of the map call  you guaranteed that the value on it is resolved, but you can also attach callbacks if you want.  You can also target all the machines at once.  So if you want to flush the databases on all the machines, which is kind of scary, you  can just do this cluster all its clients and, and it will just execute against them.  You can also explicitly target with the fan out specific nodes.  So if you want, for instance, to see which operating systems run on these particular  hosts, you can just do that.  And then the promise object is a dictionary of the host ID to the individual response that  came back from it.  And that's pretty much all.  You can get the docs at RB.RitaDocs.org and the packages on PyPI available on the open  source license.  And if you haven't used Century yet, you should definitely look at what we're doing.  We have the booth out there and we also sponsored the conference.  So have a look at it as well.  Thank you.  Hey, folks, my name is Brian Stern.  I work for Indeed.  And I really, really believe that everyone should be able to automate the boring stuff  with Python, not just developers, but like salespeople and marketers and client support  and all that kind of stuff.  And so we piloted something I think may be interesting to y'all.  It's a concept like a code wiki.  And so what is it?  Well, a collection of self-contained pages of useful code.  And for example, some marketing person might need to know like what are, you know, Indeed,  what are the top 10 things that people are searching for right now?  And that's really just a SQL statement and a print statement.  And so that's like a document that you could put into a code wiki and then run it and so  forth.  Or maybe you want a graph.  So you, you know, do some SQL code and then you plot something, you know, that could be  a document in a code wiki.  It might be useful for someone to gather this data.  The code wiki idea is based on my Python notebook and if you don't know what that is, it's a  JSON document that has basically an input cell where you put some Python in there.  And then when that runs, it puts the output in a matching output cell and then another  input cell, output cell comes from the scientific community and it's awesome.  And so these form the basis of pages in the code wiki.  And so anything that you can do in Ipython notebook, you can do in your code wiki.  And so that means you've got obviously the full power of Python, which is amazing.  Full pandas for data manipulation and so forth.  And it has some syntactic sugar to make SQL really easy and it actually is going to support  multiple languages.  Also you know, you gather data from multiple sources and then you want to really easily  output them.  And so it supports some syntactic sugar for like putting HTML templates in there.  And this is something we added, mark down.  So you can just quickly like gather data from a couple sources, put a little mark down to  render some HTML.  And of course if you want to iterate through results coming from SQL or some other data  source like Google spreadsheets, you can use Django templating and then that will use  that to generate this nicely formatted output.  A really neat extension of this idea is if you've got a page in a code wiki and it does  something useful, but what if you want to change one of the parameters?  So you want the top search terms but not in the US in France.  Okay, well why don't we make these pages parameterizable and we did it by convention, the first cell  in the ipython notebook.  If you assign things, that becomes a parameter to that notebook.  And then what you can do is you can basically have a page in your wiki that runs in a dashboard  mode.  When someone goes to it, it says, oh, you know, enter the parameters and run it.  And then it'll run with those parameters.  So for example, that plotting, you know, document, here it is with three parameters.  You can choose what country you want to look at and the date range for this particular  search.  It's, you know, a pilot project.  We kind of released it out there just to see what would happen.  And it turns out that lots of people really jumped on this idea and started to automate  the boring parts of their jobs, pulling data from different services, filtering, joining  and so forth.  And so this is what it looks like in dashboard mode.  You know, you go to the page, you can enter your queries.  It has defaults.  You hit go.  It's defaults.  And one of the other neat things is, well, what if you could just subscribe to this daily?  So the idea is like, I want this report to show up in the morning.  And so you can easily put in some parameters, click, click, click, click, click, and then  we have it on a cron and it just automatically runs and emails you.  We have a configurable permission system.  So some people can just run these dashboards but not see the code behind it.  Other people can see the code.  And the idea is that it's a shared learning environment.  So people go to this and see, like, what did you do to automate part of your job?  Oh, let me copy that.  And so, like, a salesperson can take an existing one, make some modifications, and now they've  got something useful for them.  Our security people, this is what they said.  So obviously, you know, you're running, like, user-supplied code on a web server.  So what we had to do was isolate the code.  And so what we do is we, like, drop an iPython notebook, which is just JSON, onto a queue.  And we've got a cluster of Docker containers that basically spin up, run it, take the JSON  output, and send it back, and then get rid of the container.  And we also run those in a restricted VLAN.  So you've got some security around where the code actually runs.  And you can imagine that, you know, with the Power Python, you can access data basically  from anywhere and join it together.  So you can do some really interesting things here, like, here's an example that, you know,  goes to a particular Indeed page using Selenium right from the code wiki that goes to a page,  takes a picture, and emails it to me.  So if I want to just check the state of a particular page every day.  This has sort of unleashed the Kraken.  We now have, I think, over 500 of these documents.  And we've got people from all over the organization writing them.  It's been really interesting to sort of see the take off of this concept of, like, this  shared code wiki thing.  So that's it.  We're going to open sources.  But it's not quite ready yet.  And if you're interested in this concept, I'm happy to talk more about it if anyone's  interested.  So thank you.  All right.  So, yeah, my name is Russell Keith McGee.  At this point, you probably know me from my work on Django.  What you may not know is that I've also got an interest in user interfaces, especially  native user interfaces.  My motivation here is to develop tools that follow the UNIX philosophy of doing one thing  and doing it really well, but with a humane and pretty user interface on front of it.  I've been collecting these experiments for a while under the heading of a project called  Beware because my end goal is to have a wide range of IDE-like pieces, test runners, debuggers,  maybe even a text editor, but as standalone tools, not as one great big monolithic integrated  IDE.  The journey started for me two years ago when I released a tool called Cricket.  Cricket is a GUI test runner for Python.  You pip install Cricket into your virtual environment.  You run it on your project and it throws up a GUI like this, which discovers all of your  tests and allows you to run the test suite.  You can then see the full structure of your test suite and the tree on the left-hand side.  You can see the progress of the test suite as it runs.  You can see which tests are passing, which ones have failed.  You can inspect that information while the test suite is actually running.  Cricket was built using TKInter, which is the widget toolkit which comes out of the box  with Python, but TKInter has some quirks.  That started for me a very long process of yak shaving.  The first step was a new widget toolkit called Toga.  Toga is a cross-platform 100% system-native, Python-native widget toolkit that you can  install using pip install Toga.  It's still very early days, but you can use it on OSX, on Linux, and if you squint hard  enough, Windows, all from the same source code base.  There are lots of other widget toolkits out there, QT, WX.  You have to really have a good reason to write a new one.  Being pure Python is one of those reasons, and it's mildly compelling.  QT and WX aren't pip installable because there is a great big binary component that  needs to exist.  Toga is 100% pure Python.  That's probably not enough.  A little over a year ago, I decided to try and make Toga work on mobile platforms.  So that you would be able to write cross-platform iOS and Android applications in Python.  Now, of course, in order for Toga to work on mobile platforms, Python needs to work on  mobile platforms.  So for the last year, most of what I've been doing on this project has been looking at  Python on mobile.  That works been going pretty well.  On iOS, there is now a patch in the ticket tracker, for the Python ticket tracker, that  enables iOS build support in the main tree.  That's also been wrapped up into a separate project, so you don't have to wait until that  patch is merged into the tree.  It's completely, it will work completely standalone.  And about a month ago, I announced a tool called Briefcase to make the process even  easier.  Briefcase is a distu-tools extension that will convert any project with a setup.py file  into a working native iOS mobile project, including installing all of the local native  dependencies.  And just quietly also works on OSX, so you can get a standalone.app that you can distribute  with a fully self-contained version of Python.  Now, on Android, it's a little bit more complicated.  Android really wants you to use Java.  There is a patch for Android that lets you run Cpython on Android, but it doesn't really  work that well for various reasons I can't go into here.  But I do have something up my sleeves that will address this.  I'm not announcing it now.  I will be on Saturday when I'm at the Vancouver Pie Day.  So watch this space.  And if you want to know more, I am susceptible to having drinks bought for me.  I'm not just interested in mobile, though.  I want Python all the things.  So what about the browser?  Well, I've got a story there, too, as well.  A couple of weeks back, I announced a project called Batavia.  Batavia is an implementation of a Python virtual machine written in JavaScript.  Unlike projects like Sculpt, Brighton, or PyPyJS, it's tiny.  It's just 10 kilobytes of compressed JavaScript.  And it allows you to run Python bytecode in the browser.  Why would you want to?  Well, let's imagine you've got a Django form.  That form is a validate method implementing some client-side validation logic written  in Python.  You want to have client-side validation that matches.  Well, you can use introspection on the server side to extract the bytecode for the validate  method, ship that to the client as part of the rendered page, and then run it in the  client's browser.  And presto, you will have language parity between the client and the server without having  to dirty your hands writing JavaScript.  Want to take a first spin?  We'll go to see if our friends at Microsoft.  You can visit batavia.azurewebsites.net, see a working demo, type in some Python 3 code,  hit run, and it will run that Python 3 in your browser.  So that's my YACOd.  Unless I have but two hands with which to shave.  So I definitely want help.  If any of this sounds interesting, please come and get in touch.  One more thing.  As I said before, I sometimes do Django as well.  One of those roles is present at the DSF.  One of the things that DSF does is the DSF Fellowship.  There is a program where the DSF pays to have Tim Graham work full time on Django.  Django Fellowship however costs money.  We did a fundraiser at the start of the year.  It was extremely successful, but that money is starting to run out.  So this is a shakedown.  If we want the Fellowship to continue, we need to keep raising money.  If you want to use Django commercially, we need your company.  We need you to help us pay Tim.  We think he's worth every penny, and then some.  We hope you agree.  If you want to contribute, head to DjangoProject.com.  There you'll have a couple of options.  As in January, you can donate once off, but we've now added the ability for monthly subscriptions.  If you can, we're really lucky to take that one up because that lets us establish a baseline  income rather than having to do burst fundraising all the time.  There's also some options for your Amazon Smile and Benevity if you can do your employee  does donation matching.  Thank you very much.  Thank you.
DjangoCon_US_2015_-_Lightning_Talks_-_Part_2_Peo-n4spSRA_0_167.png DjangoCon_US_2015_-_Lightning_Talks_-_Part_2_Peo-n4spSRA_168_407.png DjangoCon_US_2015_-_Lightning_Talks_-_Part_2_Peo-n4spSRA_408_803.png DjangoCon_US_2015_-_Lightning_Talks_-_Part_2_Peo-n4spSRA_804_4271.png DjangoCon_US_2015_-_Lightning_Talks_-_Part_2_Peo-n4spSRA_4272_4559.png DjangoCon_US_2015_-_Lightning_Talks_-_Part_2_Peo-n4spSRA_4560_5087.png DjangoCon_US_2015_-_Lightning_Talks_-_Part_2_Peo-n4spSRA_5088_5135.png DjangoCon_US_2015_-_Lightning_Talks_-_Part_2_Peo-n4spSRA_5136_6383.png DjangoCon_US_2015_-_Lightning_Talks_-_Part_2_Peo-n4spSRA_6384_8423.png DjangoCon_US_2015_-_Lightning_Talks_-_Part_2_Peo-n4spSRA_8424_8591.png DjangoCon_US_2015_-_Lightning_Talks_-_Part_2_Peo-n4spSRA_8592_8699.png DjangoCon_US_2015_-_Lightning_Talks_-_Part_2_Peo-n4spSRA_8700_8879.png DjangoCon_US_2015_-_Lightning_Talks_-_Part_2_Peo-n4spSRA_8880_8927.png DjangoCon_US_2015_-_Lightning_Talks_-_Part_2_Peo-n4spSRA_8928_10379.png DjangoCon_US_2015_-_Lightning_Talks_-_Part_2_Peo-n4spSRA_10380_10499.png DjangoCon_US_2015_-_Lightning_Talks_-_Part_2_Peo-n4spSRA_10500_12311.png DjangoCon_US_2015_-_Lightning_Talks_-_Part_2_Peo-n4spSRA_12312_14663.png DjangoCon_US_2015_-_Lightning_Talks_-_Part_2_Peo-n4spSRA_14664_14927.png DjangoCon_US_2015_-_Lightning_Talks_-_Part_2_Peo-n4spSRA_14928_15695.png DjangoCon_US_2015_-_Lightning_Talks_-_Part_2_Peo-n4spSRA_15696_16775.png DjangoCon_US_2015_-_Lightning_Talks_-_Part_2_Peo-n4spSRA_16776_17243.png DjangoCon_US_2015_-_Lightning_Talks_-_Part_2_Peo-n4spSRA_17244_17711.png DjangoCon_US_2015_-_Lightning_Talks_-_Part_2_Peo-n4spSRA_17712_18635.png DjangoCon_US_2015_-_Lightning_Talks_-_Part_2_Peo-n4spSRA_18636_19859.png DjangoCon_US_2015_-_Lightning_Talks_-_Part_2_Peo-n4spSRA_19860_20159.png DjangoCon_US_2015_-_Lightning_Talks_-_Part_2_Peo-n4spSRA_20160_21707.png DjangoCon_US_2015_-_Lightning_Talks_-_Part_2_Peo-n4spSRA_21708_22139.png DjangoCon_US_2015_-_Lightning_Talks_-_Part_2_Peo-n4spSRA_22140_22427.png DjangoCon_US_2015_-_Lightning_Talks_-_Part_2_Peo-n4spSRA_22428_23699.png DjangoCon_US_2015_-_Lightning_Talks_-_Part_2_Peo-n4spSRA_23700_25511.png DjangoCon_US_2015_-_Lightning_Talks_-_Part_2_Peo-n4spSRA_25512_27863.png DjangoCon_US_2015_-_Lightning_Talks_-_Part_2_Peo-n4spSRA_27864_29939.png DjangoCon_US_2015_-_Lightning_Talks_-_Part_2_Peo-n4spSRA_29940_31271.png DjangoCon_US_2015_-_Lightning_Talks_-_Part_2_Peo-n4spSRA_31272_32255.png DjangoCon_US_2015_-_Lightning_Talks_-_Part_2_Peo-n4spSRA_32256_32387.png DjangoCon_US_2015_-_Lightning_Talks_-_Part_2_Peo-n4spSRA_32388_33335.png DjangoCon_US_2015_-_Lightning_Talks_-_Part_2_Peo-n4spSRA_33336_33683.png DjangoCon_US_2015_-_Lightning_Talks_-_Part_2_Peo-n4spSRA_33684_38927.png DjangoCon_US_2015_-_Lightning_Talks_-_Part_2_Peo-n4spSRA_38928_39275.png DjangoCon_US_2015_-_Lightning_Talks_-_Part_2_Peo-n4spSRA_39276_42395.png DjangoCon_US_2015_-_Lightning_Talks_-_Part_2_Peo-n4spSRA_42396_43487.png DjangoCon_US_2015_-_Lightning_Talks_-_Part_2_Peo-n4spSRA_43488_46415.png DjangoCon_US_2015_-_Lightning_Talks_-_Part_2_Peo-n4spSRA_46416_48047.png DjangoCon_US_2015_-_Lightning_Talks_-_Part_2_Peo-n4spSRA_48048_48827.png DjangoCon_US_2015_-_Lightning_Talks_-_Part_2_Peo-n4spSRA_48828_49391.png DjangoCon_US_2015_-_Lightning_Talks_-_Part_2_Peo-n4spSRA_49392_51059.png DjangoCon_US_2015_-_Lightning_Talks_-_Part_2_Peo-n4spSRA_51060_52535.png DjangoCon_US_2015_-_Lightning_Talks_-_Part_2_Peo-n4spSRA_52536_55955.png DjangoCon_US_2015_-_Lightning_Talks_-_Part_2_Peo-n4spSRA_55956_56087.png DjangoCon_US_2015_-_Lightning_Talks_-_Part_2_Peo-n4spSRA_56088_56483.png DjangoCon_US_2015_-_Lightning_Talks_-_Part_2_Peo-n4spSRA_56484_61547.png DjangoCon_US_2015_-_Lightning_Talks_-_Part_2_Peo-n4spSRA_61548_63431.png DjangoCon_US_2015_-_Lightning_Talks_-_Part_2_Peo-n4spSRA_63432_63743.png DjangoCon_US_2015_-_Lightning_Talks_-_Part_2_Peo-n4spSRA_63744_64919.png DjangoCon_US_2015_-_Lightning_Talks_-_Part_2_Peo-n4spSRA_64920_68063.png DjangoCon_US_2015_-_Lightning_Talks_-_Part_2_Peo-n4spSRA_68064_68579.png DjangoCon_US_2015_-_Lightning_Talks_-_Part_2_Peo-n4spSRA_68580_69215.png DjangoCon_US_2015_-_Lightning_Talks_-_Part_2_Peo-n4spSRA_69216_69287.png DjangoCon_US_2015_-_Lightning_Talks_-_Part_2_Peo-n4spSRA_69288_69719.png DjangoCon_US_2015_-_Lightning_Talks_-_Part_2_Peo-n4spSRA_69720_71735.png DjangoCon_US_2015_-_Lightning_Talks_-_Part_2_Peo-n4spSRA_71736_73271.png DjangoCon_US_2015_-_Lightning_Talks_-_Part_2_Peo-n4spSRA_73272_74495.png DjangoCon_US_2015_-_Lightning_Talks_-_Part_2_Peo-n4spSRA_74496_75791.png DjangoCon_US_2015_-_Lightning_Talks_-_Part_2_Peo-n4spSRA_75792_75935.png DjangoCon_US_2015_-_Lightning_Talks_-_Part_2_Peo-n4spSRA_75936_75995.png DjangoCon_US_2015_-_Lightning_Talks_-_Part_2_Peo-n4spSRA_75996_76235.png DjangoCon_US_2015_-_Lightning_Talks_-_Part_2_Peo-n4spSRA_76236_76355.png DjangoCon_US_2015_-_Lightning_Talks_-_Part_2_Peo-n4spSRA_76356_76439.png DjangoCon_US_2015_-_Lightning_Talks_-_Part_2_Peo-n4spSRA_76440_77303.png DjangoCon_US_2015_-_Lightning_Talks_-_Part_2_Peo-n4spSRA_77304_80543.png DjangoCon_US_2015_-_Lightning_Talks_-_Part_2_Peo-n4spSRA_80544_83315.png DjangoCon_US_2015_-_Lightning_Talks_-_Part_2_Peo-n4spSRA_83316_83603.png DjangoCon_US_2015_-_Lightning_Talks_-_Part_2_Peo-n4spSRA_83604_84647.png DjangoCon_US_2015_-_Lightning_Talks_-_Part_2_Peo-n4spSRA_84648_84743.png DjangoCon_US_2015_-_Lightning_Talks_-_Part_2_Peo-n4spSRA_84744_84803.png DjangoCon_US_2015_-_Lightning_Talks_-_Part_2_Peo-n4spSRA_84804_85019.png DjangoCon_US_2015_-_Lightning_Talks_-_Part_2_Peo-n4spSRA_85020_85021.png