 I'm so excited to be here today and opening this Lighting Talk session. I'm Dmitry Filipov, PyCharm product manager. In this talk I'm going to show you some of the essential PyCharm features that make many Django developers more productive. So here I have a very simple Django Pulse project opened in PyCharm. And the very first feature I wanted to show you is Django Managed Py Console. You can get it by hitting Control Alt R. Here's it. You can just start typing the task name. It also completes everything. It also provides you the options you have for this task. Here's the app name. So our application. It also supports the fuzzy search and completion so you can just type the middle part or the task name and it will also complete it. You can also hit Control Q and it will give you a quick documentation for that task. So here we have, okay, one two three, one two three. 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 detail 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 Control 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 a PyCharm debugger. It can be used to debug the Python code without node 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 about here too, okay. 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 are 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 words 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 East is, 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 indentation instead of the 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, you know, we're 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, you know, 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 migrations. 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 Pi Texas code base. So if you're in Texas on the 25th or 27th, come to Pi Texas. 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 precompilation process is kind of like the precompilation step that's necessary for something like CoffeeScript. So our first new feature is fat arrows. Fat arrows are a new shortened function syntax. Fat arrows 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 fat arrow functions are actually really useful. When you combine fat arrow 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, fat arrow 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. Template 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 used 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 super syntax 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 one, four, and two. This one is actually wishful thinking because this is only a proposed language feature. The currently proposed syntax for JavaScript decorators 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 even Flake 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, right? 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, you know, 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 least view, the generic least 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 where you have, in this case, would be PEP 8 or Flake 8 errors. For example, the least 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 and 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 missed one letter and I get a huge exception, I don't understand. You get saved 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'll make it easy for every developer using the same plugins as you to have the same linting capacities. So next one is forget and mercurial. 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, add, commit, checkout, push, 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 comment or a comment your coworker did or whatever. And then Emmett, you know, become a CSS, HTML, William Nelson, right? So you can expand CSS selectors into full HTML, every evasion for pretty much any rule and free prefixes in case you need to, you're not using auto-perfects or something like that. So for example, this is bootstrap. It's super useful for me for prototyping, lowering it to and stuff like that. But in the first line on the top, you can see I 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 in 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 were gonna 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 and 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 in 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, worked 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.io. We do mental healthcare at scale and I'm gonna 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 wanna test whether or not they are gonna fail or whether they're gonna 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 wanna see patients. So why do we care about this? We care about this because we wanna meet the needs. We wanna rapidly meet the needs of consumers, of the customers, and we wanna prove that that works before, but quickly, because we're in startup 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'm 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 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 like an authorization decorator. And hey, we're gonna add a REST controller, our 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 serialization, the REST serializer. So what that's gonna do, but 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 gonna 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? Enter transaction test case. So transaction test case is imported from the same place you get test case. You just say Django.test 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. And so what we do to ensure that this doesn't happen is we can create like a hundred 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.io. 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 gonna 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 tests is a pretty bad idea. One of the obvious reasons is that it's gonna slow down your tests, but more importantly, if your remote endpoint is not available, the test is gonna fail. So like for example, if you have a service architecture, you don't want to need to put up your various services to make your build pass. Here's an example of a simple setup for HTTP. Let's say we wanna call the Django project URL. So we decorate the test method with HTTP that activate, 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 wanna 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 creatorcat.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 gonna 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 gonna 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 create, I have a create owner endpoint that is gonna turn that variable to true when it's called. I have a create cat endpoint that is gonna return a 404 if bob does not exist yet, and it's gonna 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 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. That's all I have for you today, so thank you. Hi everyone, my name's James Tauber. I'm on Twitter at Jay Tauber. I work for a company called Eldarion. It's one of the sponsors of this conference, but I'm not gonna be talking about Eldarion. I'm gonna 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 Django cons and might not be familiar with what PNACs is all about, I'm gonna start off talking a little bit about PNACs in general 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 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, and 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 lick-it-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, and you're not having to build any of the infrastructure around that, you can focus on the core learning algorithms. So we are gonna 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. That's a library I recently released which aims to help to do filtering from various data sources in Django by using structured URLs. So before I 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, you pass it to the back end, the back end will do the magic. All right, 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, so where 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 low-cups that contains exactly 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 back end, 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, the last example where the column is joined, usually it would probably be a date time column, maybe in database, but since the lookup is here, 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 OREM, 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 OREM 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 relationships, 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 OREM 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. 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 work 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 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. You get the routing client from the cluster and from that point on, it works exactly as any other Redis client. You just execute commands and we'll automatically go to the right node. This however is serialized. So if you target, so we for instance have like 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're 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 as client and it will just execute against them. You can also explicitly target with a fan out specific nodes. So if you want to 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.rita.docs.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 do some SQL code and then you plot something, 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 my Python notebook, you can do in your code wiki. And so that means you've got obviously the full power of Python, which is amazing. Also pandas for data manipulation and so forth. And it has some syntactic sugar to make SQL really easy and it actually is gonna support multiple languages. Also, 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 markdown. So you can just quickly like gather data from a couple sources, put a little markdown to render some HTML. And of course, if you wanna 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 wanna 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 wanna 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, you get your results. 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. 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 sales person 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'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 could imagine that 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 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 wanna 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 a 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 gonna open source this, 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 B-Ware, 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, and you can inspect that information while the test suite is actually running. Now, Cricket was built using TKInter, which is the widget toolkit which comes out of the box with Python, but TKInter has some quirks. So 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. Now, it's still very, very early days, but you can use it on OSX, on Linux, and if you're squint hard enough, Windows, all from the same source code base. Now, there are lots of other widget toolkits out there, QT, WX, so you have to really have a good reason to write a new one. Being pure Python is one of those reasons that'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, and that's probably not enough. So a little over a year ago, I tried 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, and so for the last year, most of what I've been doing on this project has been looking at Python on mobile, and that works been going pretty well. On iOS, there is now a patch in the ticket tracker, and they're 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, we'll 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. So I'm not just interested in mobile though. I want Python, I want to 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 a 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, they have language parity between the client and the server without having to dirty your hands writing JavaScript. Want to take it for a 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 yackered. Well, alas, 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 president of 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 jangoproject.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 employer does donation matching. Thank you very much.