 Thanks for the introduction. As Adam just said, I'm Sebastian. I am currently my main profession is a Django web developer. I've done some Python academic work. I work for a company called Mobify in Vancouver in Canada, which I just moved to about six, seven months ago. And if you want to find me online, I'm usually found as Al Besheed. And the slides for this talk are going to be online on speaker deck. This is the bit.ly link. I'll have that later on the slides as well. But let's find some treasures. What I mean by that is we're all or most of us are familiar with forms and views and all the sort of good things that Django has to offer and the things that we use Django for. But they are an old hat for those of us that have worked with it for a long time as well. So I'm trying to talk about a little bit more about what the hidden treasures are. And what I mean by that is basically when you look through the code in Django, you come across like utility functions and things like that that are implemented in Django to facilitate all those other features. But they might actually be useful in your project or for your use case. And you don't have to write and maintain those little pieces of code yourself. The first question around that is where do you find that? And the way I found those was mostly through either looking at the Django source code itself because I wanted to try and understand this or that piece of code or something went wrong and I didn't quite understand what I did wrong so I had to dig into the code to understand it properly. Class-based view and their nested nature are a very good example for that. And obviously working with smart people that or talking to smart people that told me, oh, basically this thing that you were doing over here, there is something in Django that already does that and you can just use it. And then there is my personal favorite source of information is FunkyBob that I had the pleasure to meet over and over again during my time in Melbourne. But he's like the person to ask questions on IRC and he's a great resource. But generally IRC is a great resource to ask questions. And then there is sprinting at conferences and that goes back to meeting smart people and talking to those people, learning what other people do and picking their brains. So what I'll be doing is I'll just pick a few things out that I've been, that I've found really useful and point out how I've used them and what might be a good way for you to use those. One of my personal favorites probably is the cache property decorator. So it is basically just a decorator. What it does, it's all in the name. It's a property on a class. The return value gets cached so you don't have to re-compute whatever it is inside that function. So this is basically what it looks like. You have your class and instead of using the app property decorator, there is a cache property decorator provided by Django that caches the result of the function. And this can be useful for things like very compute heavy properties or a property that you expose that relates to multiple different tables in a database and you have to aggregate data of some sort or you're accessing another web API and retrieve data that way. So, sorry, as an example, let's take this class of a color object and we have that object has a hex value and we have this amazing remote API that for any given hex value of a color gives you the name and you expose that as a property which means every time you have that, you access that property, you'll make a remote call to the API and this is what it looks like. You create your color, you access the name attribute in this case the property and it makes a request and the next time you request that property, it's doing a remote call to the API as well which is obviously not the most efficient way of doing it and then you get to the point where you think like, okay, I can just cache that somewhere on the object and one of the ways I've done that before is you have an under name on the same object and you check whether that is none or not and then you store it there and only return the cached value after that. But it can be so much easier. It basically comes down to importing the cached property from Django Utils Functional and then just wrapping that property in cached property and it ends up being exactly that. You're basically just doing that remote call once and after that, you have it cached on the property and internally it's basically just cached in the double under dict. The only thing in this specific case to be aware of is query sets which is a thing that has bitten me once or twice. You create a query set, you return that and you think, oh yeah, that's cached so I don't hit the database but that's actually not what happens because the query sets are lazily evaluated which means you're just caching the query set as a wrapper and not the actual database call. If you like in this case retrieve a list of objects, you have to turn that into an actual list or into a set or something like that for it to be cached as an actual list of objects in the cached property. That's it. Basically, all you need to know is Django Utils Functional, Import Cached Property. These links are basically on the slides if you want to look into the slides and find some references, the references, the docs and the sources. This is our first treasure. A next favorite of mine, something that I've used a little bit and found to be used a little bit is the import string in third-party projects. What it does is basically you pass it a string that is a dotted path that points to a class or a function and then it validates that that's a valid path and it returns the imported actual function or class that you point to. In the case of the request library, for example, you could just pass in request.get as a string and what you get back from the import string function is the function object and you can use that exactly the same way you would if you'd import request and use request.get. Where is that going to be useful? As I said, in third-party applications where you're providing functionality to another developer and that developer doesn't have access to the internals of your library, like there is only monkey patching to extend some very custom functionality or things like that that you could do. In this case, it comes in very handy to say in the settings for Django, I can basically specify a function or a class that complies with a specific API and then I can use that instead of the default. As an example, in a web store a product is uniquely identified by a slug that's used in the URL and then you also want to provide your users that you have this web store framework written for to customize that slug and because I'm a sucker for emojis, I want all of my slugs to be emojis. I'm using this custom emoji slugifier and then internally as the person writing that piece of web store framework code, I can basically just take that string and say import string and get back whatever that user has or that developer has written as custom code, pass the values as defined by my API contract and then return that value. There is something that I'm not taking into account here. Import string still raises an import error if there's something wrong so you have to catch that yourself. But it's something that's really useful because you don't have to provide all those little checks and things like that that you have to go through when you do this manually. That's all taken care of by Django. So Django utilizes module loading, import string is all that you need to remember. It's been called import by path previously. I think it was deprecated in 1.6 and it will be removed in 1.9. So there might be some differences in naming there. And this is the second treasure that we found that I found. Hope you... So the next one I want to look at is the lazy function and the lazy object. And we've definitely all used it. And that's because Django settings are basically based on that sort of concept. I'm not quite sure whether that's the reason why the lazy object thing exists in the first place but it's one of the most prominent places where it's used. And what it does is basically it provides a way of delaying the execution of an object by wrapping that callable in another object. So as I said, it's used in the Django functions. And one of the reasons it exists is because the way Django is executed when you load it, some of the pieces that you might rely on in other parts of your code might not be available at that point that you're executing that function. And one of the best examples is the having a reverse lookup for a URL on either the class attribute level or on the module level of your code. Because that code is executed at parse time and you can't really be sure that your URL config is fully loaded at that point. This might actually just return an empty string and you don't really know why. So for... This is a slightly bad example because there is already a reverse under lazy as well as some other under lazy function in Django. But it doesn't really... It's a very easy way to illustrate the sort of problem. And one of the problems with that where I actually had to make or I couldn't make good use of that, I just came across recently which is per user storage. I had a model and a file field on that. But I wanted to store those files in a user specific bucket. So I had S3 and because we don't have per user storage in Django, it was basically a way of, okay, I've got to write a little wrapper and provide that. But S3, especially the Django storage implementation, fell over at that point when I was starting to load my application. And it was like, why? Well, it turned out that the S3 storage would basically... Try to connect to S3 at the point in time when the file was parsed. And then because I didn't have my credentials from the settings file at that point, it would just say, like, I can't really connect without credentials. So because I couldn't put it in any other place, the easiest way to get around that was basically having those three lines of code in there. You write a function that returns the object that you actually want to have. And then you create a simple lazy object. And a simple lazy object will only return and instantiate that object that you return in your function at the point when it's accessed for the first time. And then you can just stick your private storage object, the lazy object, into your file field definition. And it just works. So that saved me a lot of time. And once again, you'll find those two in the util's functional, excuse me, the Django util's functional module. And it's actually fairly easy to use them. And that is our third treasure. And then the last one that I'd like to look at is the request factory. That's actually one of the things that has saved me quite a bit of time in testing. So it's not something that you would actually use in your day-to-day code that you're running in your application, but it's something that will actually help you during testing. So it's also fairly simple . It takes a URL and the HTTP method that you're trying to use. And then from that it creates the Django request object that you're familiar with in your actual code as well. So it behaves exactly the same way, but you don't have to go through a full request response cycle as you would do with something like the client test case in Django. So the easiest way of using it is basically it's in the Django test module and you just import it from there. You use it similar to what you would do with requests, for example. You have a get or a post and you pass in the URL and the parameters that you want to use with that. And as I said, one of the things that I've used it for is testing request-related code, for example, in views and something like that, where you would have to mock quite a lot of functionality of the request so that it behaves like a request, which basically then ends up you writing a lot of mocking code just to get that little piece of functionality when there is something that's already there that can construct it. So one very good use case for that, in my experience, is also writing middleware classes, where you basically have those request responses that are getting passed in and processed in certain ways and they can get fairly complex. So in this case, you have a middleware, you've got your logic in the process request and it expects a request. So you should pass in a request or something that looks extremely similar to what a request looks like. And based on that, sort of having the mocking logic in that can be quite substantial. So one way of getting around that is basically have your test function, import the request factory and then having, creating your request, you can even pass in query parameters or things like that and then you just pass in that request or manipulate that request in some specific way so you know the type of data that you're passing in and you can test against that. And then, obviously, you proceed with your tests as you normally would. And that's basically it. You find it in Django tests and it might make your tests a little bit faster, especially when you're sort of looking at the more unit type, unit test type testing and it saves you a lot of time in terms of mocking things. And the treasure is now all yours. There is obviously there is a lot of additional treasures in the Django code base and especially Django utils is a trough of just like those little functions that clean up your strings and all those types of things that are really, really useful. And maybe just for your specific use case. But some of them aren't quite well documented in the Django docs. So I would encourage everyone to just take a peek under the hood and look at some of those little functions and things like that just to see what is in there and maybe there is something that you see, okay, I've actually written this in five places. Maybe I should just use that. And that got me quicker through my talk than I intended, but that gives you a little bit of time for questions. Thanks. Hello, there we go. So I have a question kind of like to this. Is there anything that isn't a Django treasure you think should be? Is there a pattern you can think of that should go into one of these places you're talking about in Django? Yes. What do you think it is? I think the swappable models are a piece of private API that I really liked because I had a sort of CMS type use case where it was extremely handy from a library perspective to expose or give the user, the developer, the ability to swap out a little bit of customized functionality without having to go through like multi-table inheritance or things like that. Right. So I think that's a very, that would be a very nice piece of code to expose. It makes migrations impossible, but yes. Thank you. Okay, so you mentioned there are these things hidden in Utils. Some of them admittedly we've hidden them because we kind of like people not to use them because then they're officially have to be supported. But for those that are good, how do we get the message out there? Is it just a matter of dropping another line in the docs or is it just going to get lost if that sort of stuff's in there? Well, the ones that I've tried to pick here as well are the ones that have public documentation and are considered public API. So the documentation is there. I'm not quite sure what the best way would be to be more prominent about here is like cash property. I think cash property is actually one of the things that quite a few people know because I think Daniel Greenfield Roy wrote a package that basically provides that functionality outside of Django. So there must be demand of using it outside of Django as well. And some people must know that it exists. I wouldn't know what, it's probably just like telling people more about it and like pointing out when you see somewhere in an open source package that someone's writing something that actually has existing Django functionality. Saying like, by the way, you don't have to maintain that. You can remove those 15, 5, 20 lines of code. So probably a dumb question that everybody else knows the answer to, but I don't. So if you mentioned early on one of the good places to find treasure was the Django IRC channel, where is that? So the IRC channel is on a free node. It's hashtag, well, hash Django for the Django room. And there is a gazillion chat clients out there that support IRC. It depends on like the sort of operating system that you're working on. What your preference is, whether you prefer working in a text environment or more UI type environment. But I think the best way probably is to just search for IRC in the Django docs. And there is a reference there somewhere where to find it and how to set it up. All right, there we go. Just wanted to share one of my little spots for hidden treasures, which is lots of the functions that are exposed to the template tags and filters are also really useful elsewhere in your code base that have nothing to do with display templates like you need to store slugified values in your database for something you can easily go from Django default filters, import, slugify and use that against first, middle, last name or whatever. And lots of those template tags and filters can be imported and used the same way outside of template land. Yeah, yeah, thank you. Awesome, great, thank you.