 and speaker, he works in Unices as a solutions manager, lead solutions manager, and he has authored a book on Django best practices for Django beginners and some of the problems that they face. So, over to you Arun. Thank you. Nice piece of dubstep there. Good morning everybody. I'm going to take a quick session on Django. So, when I say quick session, I'm trying to wrap it up in 30 minutes and hopefully we'll have more time for questions. That's usually the more interesting and more interactive part of sessions. So, I think I'll go behind. So, my name is Arun Revindran and as he just explained, it started using Python in 2001. This year keeps changing depending on whether it's a younger person who I'm talking to, I'll just like reduce the years a bit and all that. So, I recently published a book and I'm a developer member of the Django Software Foundation. I blog at arunrocks.com and I tweet at arocks. So, if you have any questions after the talk, you can use the medium of Twitter or even later when you go back you can tweet me about any of the questions you have. So, like I said, this talk is about Django and how we actually create projects, the structures of the projects. So, let's have a quick show of hands. How many of you use the default Django project? Like not used any other, okay, great. How many of you used any third-party Django project layouts? Anyone? Okay. So, how many of you use this awesome thing called the Django edge which I wrote? Okay, great, one guy, fine. And how many of you don't know Django at all? I mean, they could be, fine. So, don't worry, this talk, I'll try to explain everything in a way that a person who doesn't know Django as well as could understand because what we are talking about is very fundamental to programming. It's about how we organize code. It's about project layouts and project organization and in general about web development. So, there are a lot of things, there are a lot of, I mean, a broad audience can understand and we'll not go into very Django-specific things unless it's absolutely necessary. So, like I said, in the next few minutes, I'm gonna talk about what is a project layout, how Django processes a project layout, what happens in the internals in a very neat diagram, what is a default layout with Django gives us and how it has changed over version from the early pre-1.0 versions to the new versions. What are the common pitfalls that we face and creating your own layouts? And I'll talk a bit about my own project Django Edge which I started about a year back. Before I continue, can the people at the last row hear me? I mean, do I need to raise my voice? It's fine, great. Okay, so project layouts, they are known by different names, right? Some people call them project layouts, some people call them project skeletons, project templates, they are not exactly the same but they are roughly the same in this particular presentation. So, when you type Django start project, there is a default set of files which are created for you. There is a simple structure which is created for you. Some directory, some files are created. So that's what I refer to as a project layout. And if you have noticed, this is actually defined inside your Django source code in a place called Django.core.conf.project template. So if you go to the Django source repository, you'll actually find that this project template is sitting there. And when you actually type the command start project, it's actually dynamically creating that for you. So, why are this so important? I mean, most of us don't even give a second thought, we just type this command and it's created for us. I'm a little obsessed about this particular layouts thing because once we actually create a layout, I found that many projects don't change their layouts over time. Why is this important? Because imagine you started working in Django before 1.4 or something like that. When the layouts are completely different from today Django is in 1.8. And the layouts have changed. So if somebody looks at your project, you'll notice that you can actually find out, it's almost like a fossil, a dinosaur fossil sitting there and a good archeologist can tell you which dinosaur it is looking at the bones, right? So you can actually tell from the project structure which version it actually started because the developers never managed to get enough time to actually go and do the reorganization or the refactoring of the code and update it to the new layout. So it's always a good idea to start with the most modern layout and give a bit of time before you actually start creating a layout. And I feel that we don't give much importance to code structure because for most programmers, code structure is a part of user experience, right? It's almost like your user interface when you're working with code. So imagine that a new programmer comes to your project or your team. If they find that it's a very messy project or it's not organized in a very traditional way, they'll find it really difficult to understand what the pre-source code is or your project is. And they'll probably have a lot of questions. The onboarding time gets delayed, your team ramp up gets delayed. Overall, it's going to impact your company. And also on a day-to-day basis, you're working with this code, right? So you would like it to be in a form that is highly structured so that you don't have to think. Already programming is a highly mentally taxing activity. You don't want yourself to really worry about the structure part of it. So that's one thing that you don't want to worry about in your coding experience. And this third thing is about increased complexity. So for many of us who are Python programmers, Django projects are one of the largest code bases that we'll work with, right? So if you include your code, which is generated by Start Project, which sometimes nobody ever reads, I suggest reading it by the way. And then there are third-party projects like connecting to Amazon, connecting to PayPal. All those things are like third-party code, which even runs into thousands of lines. And if you add all these lines, all these moving parts together, you'll actually have millions of lines of code. And if you don't organize it properly, trust me, it's going to be a big model of mess and it's going to be structured all over the place. So when you're working with a large code base, it's always very useful to have this structure and a good code organization in place. And finally, it's a hygiene issue. It's kind of like, if it's neat, it's very easy to work with. Some people are bothered by this whole neatness thing like me, so if it's neat, it's kind of cool to work with. So like somebody said, code should be something like a library or a bookstore. The moment you walk into a bookstore, you should be able to find out, this is the fiction category, this is the non-fiction category, that is the paranormal, this is the superstitious or whatever it is. And you should be able to just walk in and take your book and the whole thing should be very intuitive. You should not put so much time into it. So the same thing applies for code. The moment you open a piece of source code, you should know, this is where the documents are, this is where the source code is, this is where the assets are, these are the templates go. So these things actually help you to understand the code quite faster. So like I promised, I would like to go into a bit of explanation into what happens when you actually run this command. So this is a command for using a custom template, custom project template that I have developed called edge. It starts with Django admin.py. Sometimes you use manage.py for management commands. This start project command, which is the main key command here, and two options, right? The first option is which template you want to use. I would like to use a template which is on GitHub, and I'm just directly going to mention the URL on the command line. And the second thing is which extension should be templatized. So some of the .py files might contain some template specific values like project name, which I'd like to run through a template engine. So all those extensions are listed after the extension option. So that's .py, md for markdown, html for html files, and env for environment specific files. And finally you have my project, which is the project name. You can change that to whatever project name you like. So this is the big diagram which tells you what actually happens. So I try to keep it simple. I'm not going into all the detailed aspects of it. So at the very top, you have typed your command. You're just going to enter into Django code base, which actually parses the arguments. So we use a parser called argParser, argumentParser, which is kind of become standard as the argumentParser. So when it comes to argumentParsers, we are having, I think in last count, about 1,200 argumentParsers, I'm just exaggerating. But there are advantages and disadvantages, and finally we have a rough consensus that argumentParser is the best of the lot. Now what does it pick? It picks up whatever you gave as command line arguments. So the compulsory or the mandatory argument is the name, the project name. The second argument, which usually picks up is the directory. So sometimes when you type, you don't mention the directory, it just creates a new project name base directory. Sometimes you want to create it in the exact same current directory that you're sitting on. In that case, you mentioned dot, or you can mention any other part. And finally the secret key. So the secret key is not mentioned by the user, but it's randomly generated whenever you actually run the program. And this is very important. We'll come to the secret key in a minute. And then it populates something called a context dictionary. So some of us already know what a context dictionary is. In any case, whenever you use a template, for example, instead of hello world, you're going to use hello curly braces name, double curly braces name. So that name comes from a context dictionary, right? So whatever you put in that context dictionary, name is the key and value is say Arun. It'll replace that in that template to become hello Arun, for example. So in this case, the context dictionary is populated with a name and a couple of other things like which project directory it's going to be put into and the usual things that you would expect there to be which is derived from whatever you gave to the argument parser. And it'll also validate that the name is consisting of letters and numbers. So what is happening here is very common to all management commands. So the first two blocks are common to all Django management commands. Next thing is what is specific to this particular start project command or start app command. So as some of us know, start app is also another command for creating an app within a Django project. So if you want to create a new app which is basically doing say user logins, you can call it say login app or you want to create something for creating profiles, you can create profile or anything like that. So when you create an app, the whole process is exactly similar except instead of project, just mentally replace it with an app. So first thing it will check is if you have given a source. So source means what I gave as a template, right? So in this case, the template was coming from GitHub. So it is actually checking whether the source is a URL. If it is a URL, Django actually downloads it using URL retrieve. By the way, this whole thing is used using a design pattern which is implemented inside a class called template command. You can easily read it. I think it is under code.management.base. So what we are doing here is we are simply downloading that file. We're extracting that file. We are getting all the, I think contents inside that zip file. And now we are entering a loop. So this loop is basically walking through each of the files and directories inside that particular archive. So first thing it will check is whether that extension is something that we should templatize. So like I said, .py, .md and all that are templatized, which you have explicitly mentioned. So Django runs it through a template engine. And as we know in Django 1.8, we have a choice between which template engine to use. But remember, at this point in time, the project has not been created. So there will be a very minimal settings.py which has been created, which will actually use the default Django templates. Now the context dictionary which we populated earlier is going to be used here. We are going to render it and we are going to write the file. Similarly, next file, next file, next file and the whole directory trees walked and we'll actually have the initial project structure created. And finally we have cleanup because we downloaded and we created a couple of directories and they are cleaned up. So some of us have worked in Django in the past and we remember that Django used to have a very simple directory structure. They used to be, as soon as you open the project name, you'll actually find that there is manage.py, settings.py, URLs.py, all the project specific things in the one folder and then there'll be probably one small apps folder or something like that. And a major change happened in Django 1.4, right? So some of us remember, all these settings.py, URLs.py got put into a separate folder called projects.under the name of the project. So for example, if I name my project my project, it'll be creating one my project at the top level and confusingly, there'll be another my project inside that and that will contain all these settings specific files. So why did we do this? The reason was a couple of path related issues, right? So we used to create .init.py, we wanted the top level thing to be a package and inside we wanted to create another package for each app. So this created a problem of double imports and the whole thing was like very confusing. We had to do a couple of hacks to make sure that it worked properly. So just to make things very neat, today we just have managed.py outside and everything else is neatly organized into different directories and some people always ask this question, where do I put the common files? So some people create an app called core or some people create an app called main or something like that. So it depends on your style but I find that the project name folder can be used for your common project files. Another interesting change was you can specify the template option. So what we just saw, the template option came in Django 1.4 and the path can be templatized. So as I said, if you mention my project that my project path will be actually created. So again, because of the new template engine flexibility we have, the whole Django 1.1 settings.py file also got changed and now we have some changes when the way things are configured as well. So yeah, there are a lot of changes which are not mentioned here but roughly these are the changes. So now some of you might be wondering, I have used Django and I have not found any problems with the default project. So this is a bit, I'm gonna change your mind. So this is like purchasing your new iPhone and somebody saying, you know what iPhone has these problems which you didn't know when you were buying and now it sucks, right? I have this thing that has so many problems. So probably this might hopefully change your mind to look into what the real nitpicks are about the Django project. So imagine if some of your experience developers, imagine going back in time and thinking about what your first experience when you're working with Django was, probably playing with the tutorial, the polls tutorial, for example. So remember that when you were running run server there were a lot of errors which were coming on the console. Like I cannot find Favicon or some file is missing or something like that. So if you are a beginner, you'll actually be worried like, am I doing something wrong? There are a lot of errors happening. Actually what's happening behind the scenes is the browser is actually checking if these additional things are there and there's nothing wrong with the way things are working. But it puts off some people. It might seem like a minor thing but it actually puts off some people and some people don't know that you have to log in by changing the URL to slash admin and all that. So there are a lot of people who actually created an entire app and they have still used slash admin to use the login to enter into that particular user login process. And this is sad because Django comes with built-in user models and everything is already built in. Authentication is built in. Logging in is built in. Everything is built in. But you don't have to actually go through the whole login screen or the admin screen and the admin interface for a normal average user to actually enter into your Django website. So this is something which bothered me as well. And in case some people actually use the Django admin they'll find that it's a whole new user interface, right? I mean it's like designed sometime like 10 years back or something like that when Django was originally created and it has this weird looking green bar on top which is completely clashing with your color schemes and your designer is like, you know, what the hell is this? This is not what I designed. So the whole experience can be a bit jarring and it should not be, right? It doesn't have to be a completely different experience. And what happens if there is an error page, right? Some of us get confused. So whenever you actually enter a wrong input or whenever you actually visit a wrong URL, Django in development environment actually throws up something called a Django error page. So there's very little debugging. You can do that. You can actually go through the entire stack trace. There's a lot of good information there. But I found that there is nothing to do a live debugging kind of a thing. And finally, print statements, right? Print statements is the bane of Python programming. So when we actually do Django development, if you do print statements, what happens? It comes in a console and you'll find that, okay, I've found a new way of debugging code. Great, let's put a lot of print statements all over my code. And then your code goes for code review and everyone is like, oh my eyes, look at the amount of print statements you put. Just use logging. So you're like, what is logging? Nobody told me about it and all that. So that was another beginner problem which I found. And now, completely different type of users. What if you're actually a serious developer who's using the default project template for production use? So again, you have problems, right? You don't have a different settings file for prod and for dev and for testing and what have you not. And you also have different requirements files and you have different settings for each of these things. So Django never gives you a good direction as to what to do in such scenarios. So I thought there are a lot of tips and advices that people tell you use a package and all that. I thought it's better that that goes into your default project template. So good developers like to do a lot of work and ask little time as possible. And I wanted to create something like a default project which is very easy to use which is already working out of the box. You don't have to spend a lot of time customizing it every time you create a new project. Cookie cutter was a very common solution that many people suggested to me but you have to actually install an additional dependency and you have to go through a series of questions. And I found it to a little cumbersome when we already have something called Django start project which is already built into Django. So some of us from the Rails world understand that Rails also creates a default project, right? So they go by the convention over configuration concept and they create this huge set of files. It's about 20 files and many Rails developers even today don't know what those files are. So Django is going for a completely different approach in which they want to give a very minimalistic set of files. So if you are going to create your own custom project layout, I would recommend that keep the number of dependencies and the number of files as less as possible so that we don't have the whole, there are so many files that I don't know what they do kind of a problem. And again, some people go the other extreme, right? Like they want to create everything modularized, they want to create a lot of design patterns, they want to create a lot of classes and the whole thing is like Java now. So or the granddaddy of all that small talk, right? So we don't want to create it in a very elaborate way. Let's keep it pythonic and not go into too much of design patterns as such. Coming from an author who has written about design patterns. So finally, the production issue, right? So if you remember, Django actually has just two settings, debug true, debug false. So what happens is when you debug is true, that's ideal for development environment. It has a lot of memory usage which is associated with debug information. It is trying to create user-friendly error messages. It reveals a lot of internal details to whoever is facing an error message. All that is great for development. But immediately when you come to production, you have to turn off the debug setting, right? You have to turn it to false. And all these things are optimized away. You'll probably get a very simple error message which says that whatever you gave as the error page will show as an error message. And we'll say something has happened, the admins have been contacted on things like that. But this binary thing is a very unrealistic thing, right? So most of us work in real-world projects which have multiple environments. We have development, staging, production testing, production testing, whatever. So these nuances are not really captured in the default project template. And that is something that we have to address when we are trying to create a custom project template. And of course, many of us know that the settings in each production or staging or development environment will be different. The username, the passwords, and everything would be different. So that has to be captured as well. Now, when you're creating your own project layout, what are the mandatory things? So there are only two mandatory things if you look at it. It's very simple. First thing is that your Django project settings must have a secret key. So this is the most mandatory thing that they suggest because that is key to it, we'll come to it in a moment. And the second thing is the Python path must have all your apps defined in it. So it's a very simple to remember kind of guideline. You should have a secret key, otherwise it'll throw up an error or you should, and the next thing is your app should be on the Python path. So why do Django programmers obsess over the secret thing already? So secret key is very important because it's used in a couple of places. Broadly speaking, it's a very important part of cryptographic algorithms used in Django. Now what are the cryptographic algorithms? Basically signing and password checking and protection of data, right? So form security. So Csurf key is actually generated using a combination of the secret key and a randomly generated salt or something like that. So what happens is every time a new project is created, a randomly generated 50 character string is created which is consisting of alphabets and letters and all that and numbers. And this is combined with whatever is there so that it becomes like a size fingerprint. So it is not, so what happens if you lose or if it goes public? So it is not a very serious problem like your password being public or your admin password being public but it is kind of serious because you can actually guess the patterns and a very smart person can actually figure out what is the next pattern which is going to come out and it can expose your site for attacks. So ideally you should not leave it lying around. Now the problem with the default project layout is it is lying around, right? It is a secret key and it is actually a string which is sitting inside your source control which is like why the hell did they do that? So unfortunately it should not be putting in, your secret key should not be checked into your source control, right? Secret key should be something ideally if you're using 12 factors guidelines which is a very good set of guidelines for any web developer irrespective of your programming language is that your secret key or any secret credential should come from your programming environment. So whatever is set in your environment should actually be read by your program and if it's your password it should be just read from your environment as well. So we have tried to solve this in Django Edge and yeah, this is the problem with checking it into your source code. You just run a search and many of these settings start by file actually have a secret key. So another pitfall that you have to worry about this is not a pitfall, this is about escaping your templates, right? So imagine that you mentioned .html in your start project. Now what will happen is that all your templates will be rendered automatically when it is actually running through that template engine. This is a nightmare, right? So you don't want your templates to be rendered in the start project itself. You want it to be in the template form itself and later when your project is actually running you want it to be actually rendered. So the recommended way for this is actually to use something called a template tag template tag, right? So template tag actually is rendered into a template opening tag, closing tag or variable opening tag, variable closing tag, et cetera. So it's a very helpful way of actually escaping your project template templates. So if you're actually going to use a template as your parameter what you should do is either you should do it manually you should go from right to left. Basically any of those opening tag should be replaced by your template tag. So in your project template it will look something like this at the bottom. You'll have template tag open block then URL something and then template tag closed block. And when it runs through start project it'll be correctly converted into what you want which is basically the URL tag. So I use a script for this and I'm planning to open source the scripts as well. So the problem with any open source project or any solution is that you start out as this lightweight alternative to something. So Chrome is a lightweight alternative to internet explorer or something is an alternate thing it starts off like that, right? And then all these features gets added up and then it becomes equally bloated, equally bad as something. So it's a constant struggle between deciding what you need to be included into your open source project as well as constant demands from people like why don't you add this feature? Why don't you add that feature? So for me the overwhelming requirement is that it should be more minimal than having more features. Still I ended up with a lot but yeah. So how to organize these, right? So these are some of the questions that you have to answer when you are trying to create a default project layout for your company or for your team. So where do all these things go? There are log files, there are documentation, there's static assets. Sometimes people include their virtual environments like as a part of their project layout. What are your package requirements? Environment specific files. And now we have deployment scripts as well. So if you're using Ansible, Puppet, Chef some people include that as well. So ideally a good project layout should be organized in such a way that it should be intuitive that where each of these things go should be automatically known to them the moment you open the project. And this is one of the things that I'm bothered about like how can you reduce the number of dependencies? So I won't be surprised if many of you have seen projects which have over 20 or 30 Django dependencies, right? So Django has a very thriving third party ecosystem. Many practical real world Django projects use lots of third party modules. But the problem with using each and every third party module is that it has a footprint. It has a memory footprint, right? So each time you invoke or whether you use it or not it's actually residing in memory or whether it's paged out or whether it's residing somewhere. It's actually going to increase the memory consumption of yours. So in my opinion an ideal project is the one which uses the minimum number of dependencies that it requires and not anything more. So this is one, the corollary of this is of course that if you have some dependency in your project which is lying around, which you have not used try to prune it away. I mean try to do a refactoring or try to do a code cleanup. Just try to remove that dependency which you're not using anymore. It'll actually speed up your project in sometimes. Finally, we'll come to the work which I've been doing. So this is about the edge project. So you can find it in github, it's github.com, Aerox Edge. And it's just shy of 200 stars. So I'd recommend all of you to go and start it. I'm desperately in need of stars. And this was started last year. I think in another four days it'll complete one year anniversary. And it has been kind of picked up quite well. My idea was to bring a project layout which solves lot of minor annoyances which I mentioned earlier for newcomer as well as for experienced Bangu programmer. To make it better organized, again, it's a very subjective thing, better. Encourage security best practices. Like I said, I'm using 12 factors recommendations here. Batteries included, lot of best practices, lot of good things like logging and debugging things are already included. Lives on the cutting edge. So when I created this, I said this is going to be Python 3 based. Forget Python 2.7 and all that. That's like completely outdated. I'm just going to focus only on Python 3 because Python 3 is the future. Python 3 is going to be everywhere. Unfortunately, that was not true. So people actually forced me to convert it to Python 2.7 and finally, okay guys, I'm going to do it in both. I had to maintain a common code base for both. And today it runs both on 2.7 as well as 3.5. And fun to start, right? So many of us don't like Django because it takes a lot of creating a thing. And finally, you create like this very simple HTML page which has like a very unstyled content and all that. It looks very, I would say uninspiring, whereas a lot of other frameworks have actually caught up and they have this nice bootstrap based front page and everything looks so beautiful and that onboarding experience looks so nice. So I wanted to replicate that kind of fun experience here. So the reason I created this was I was writing my book and I wanted to create a project called Superbook which is basically a Facebook for superheroes. So guys, in case you didn't know, day two of Python is based on superheroes based on my last talk. So I don't know, I was just joking. So it's like Superbook is kind of a Facebook, a social network kind of a platform which I wanted to use for explaining a lot of concepts in my book. And unfortunately, whatever I found was not really updated to use a simple registration. I actually wanted to use this project called Simple Registration which I believe was maintained by Bennett and he's no longer maintaining it. And then Django updated version to 1.7 and it's broke Simple Registration and he simply flat out refused to update it. So either I could have, you know, if only Bennett had updated it to 1.7, Django Edge would not have happened. By the way, a lot of things are like that. So I feel it ended up in a good ending. So how does Edge look? So when you start your Edge project, start out of the box, just creating start project and running your project, it looks like this. So it's trying to give a very professional, a very bootstrappy kind of a look. That's the home page, this is the login page and the bottom is the user profile page. All these things are automatically styled based on whatever theme you choose and the admin page is also styled in a very similar way. And this is a very controversial slide. Some of you might have different opinion about it. There's a concept called pinning when it comes to writing a requirements.txt. So requirements.txt, as many Python programmers know, is where the virtual environment, whatever program you use, actually picks up the dependencies which are needed for your project. And pinning is a concept of mentioning the version numbers. So for example, if you're using Django, you can write Django equals 1.7, double equals 1.7. So this means that you are actually pinning that particular version or that particular package to that particular version. Now, this is highly recommended. Now, there's something called one-ended pinning or open-ended pinning. So what happens is that I usually prefer something called Django greater than or equals 1.7. So I'm trying to say that there's a minimum requirement of 1.7, but in case tomorrow there's a new version of Django coming up, I don't mind if it gets upgraded to the next version. So this is something that is definitely recommended in production, but I strongly believe that if you're actually using it in development, this should be the right way to do it because that is the best time you can actually start experimenting with new things and you can actually start working with a new version of its software. And when you're actually creating a project, you should definitely work on the latest version of that package rather than some outdated version which is still lying in that requirements.txt. So here's a quick list of features. I just wanna go through them very quickly. So like I said, it's bootstrap-based. You have user registrations and sign up. You have better security, logging and debugging. So there's actually logging and debugging already configured into Django Edge so that when you actually create any kind of log messages, it has a proper location and a directory and a structure to go to. Environment-specific config, like I said, we use something called Django environment for which environment variables are actually used for secret or secret key or password-specific credentials. User lookup by email, not username. This always has been a pet peeve of mine. How many of you guys wondered like what does Django need a username and an email when most people actually are fine with just giving a unique email? So I wondered that. So of course in a web application like Twitter or in a forum or something like that, you actually need a username. But many people don't remember that their username was cool guy in 1987 or something like that because they forgot long back. So you probably need your email which you probably use every day and remember. So you're using a custom user model which completely eliminates usernames. And then we have something called user profiles which is a separate place to store user-specific information but which is not used for authentication. Things like your favorite color, your birthday, things like that which are username-specific. And everything is class-based. So a lot of projects are today not using class-based views. There's nothing wrong with not using class-based views but over a period of time, you'll realize that it becomes more easier to reuse your code when it is class-based. So extensively, we have used more mixins and class-based views in Django Edge. And like I said, it works on both two series and three series. On the right, I just want to quickly point out that this is the structure of Django Edge. As you can see, you have docs folder, requirements folder, requirements folder which will contain dev, prod, staging, whatever, different environments. You have in a .env.txt format, right? So settings is in .env format. So again, settings is in a separate folder that also has different files for each environment. And there is a set of apps which are called accounts and two apps you get, accounts and profiles which actually deals with signing in and creating user profiles. And then you have the bootstrap and templates and the usual standard stuff which goes into it. So in case you're interested in other start alternatives for starting up projects, you can use that cookie cutter. There's something called Django hackathon starter. There's Django 1.7 base template, Django project template. Django started very imaginative names. So by the way, my name was, I mean the one name I chose was actually chosen because I want, like I said, I wanted something which is only working on Python 3. So it's like living on the edge kind of a thing. But then another small company, you must have heard of it, stole the name, it's called Microsoft. They used edge browser and to my frustration, right? So they had, of all the names, they had to choose my name, right? And in case you want to check other alternatives, please go to Django packages. There is an entire page for project templates. So finally I want to leave with this thought. I mean, this was written by none other than yours truly. So it's not a code. It's like, it's not about how fast you start your project. It's about finishing what you started, right? So many people love to start projects and I found that it's only important when people actually see your project and it's implemented in front of others. So please finish your projects and make sure that you continue to work on them and organize the layouts. That's all. Thank you. Any other questions? Hello, thanks for your very beautiful presentation. Regarding the secrecy part, you told about protecting the session data. Right. So can we elaborate how this mechanism is achieved or the algorithm behind that or something specific. The protecting is based on when it connects to the third party like Amazon or PayPal. What is the concept behind that? No, it's actually very simple. It's actually a cookie based mechanism. When you actually log into Django, any Django web application, your cookie set something called a session key, right? So that session key is live, is valid throughout the user browsing session. And whenever somebody tampers with that session key, like some of the, what do you call it, XRSF attacks, any of the cross browser attacks which are done, it's very difficult to get that particular key. So if that is not tampered, Django realizes that it is coming from the right same user, it is coming from an authenticated user. So the secret key is actually used for creating that session key. It's actually a signing mechanism, which creates, it's called a nonce. So it's just a one-time long random character. Another thing is that regarding the importing of a template from GitHub. Right. Suppose that should be the master template or I can create a master template in Python and import templates from GitHub as sub template. What is the concept behind that? So we are talking about two kinds of templates, right? So one is what your project layout is. So that contains your Python files, your manage.py and all those kinds of things. That is what I mean by project template. So that is what is picked up from GitHub. Now your regular templates, which are your web pages and all those kinds of things, which are written in Django template language, that can be also completely different. And that will definitely change from project to project or application to application. Okay, thanks a lot. Thanks for the talk. The Django, yeah. Django is not moving faster the way the modern web apps are built. I have seen some talks on Python US that the Django is like, is five to 10 years back than other frameworks. So how do you think, do you have this thinking to make that how modern web apps are built with Django? Like... So if I understand your question correctly, you're saying Python is, sorry, Django is five or 10 years behind other frameworks. Behind other frameworks, like... Okay. So again, I don't think it's a valid claim. So if you're talking about PyCon US, there's usually a talk called why Django sucks. It's a tradition. It's not because they are seriously saying that it sucks. It's because most of the reasons they say it gets fixed in the next version. So it's like a very actively developed web framework, actually. So if you look at two, three years back, whatever talks said that these problems were the way with Django, most of them are rectified by now. And of course, there are some various other reasons you're talking about probably single page apps. Single page applications. Yeah. So if you conduct a survey, I mean recently I read a survey, which is your most popular tools for building a single page app. Most people prefer Django with REST API, Django REST framework as the back end. And at the front end, they can use Angular or ReactJS or whatever that is. But they usually require something which is very strong, very stable. And very few projects are as capable as Django REST framework. So some people use Django purely for Django REST framework as the back end. So unless you have some specific things which, you know, is shortcoming with Django, I still believe that it's a very modern framework. So, DSA is planning to include it in the Django itself, Django REST framework? Core is it? No, I don't think so. I don't think it will be included as a part of core. Recently it went through a major rewrite after a successful Kickstarter. So the API has changed quite a bit. But generally all these things are kept outside the core. Generally they're trying to keep the core as lean as possible. And last few years, a lot of things got removed from core. And that will keep on happening. They want to keep the core as small as possible. So there is some planning to organize Django Core in India, like Django Core in the US or Europe? I have no idea, boss. I don't know. Thank you. Hi, good talk. And it's really interesting. And I follow you and use the Django Edge template. And I, using Django from December last year, and I found that Django can't ever to utilize all the cores of the available in the resources. So do you think that how to use the full the resources and get all the possibilities that our resource can provide? Right. So you're saying in a multi-core machine, it generally doesn't use all the cores or in a multi-processor, it doesn't use all the processor. Is that your question? Yes. So this is a fundamental Python problem. It's not really a Django problem. And most people solve it by using multiple processes. So they'll have, you know, generally if you have a multi-threading model, you'll encounter something called the global interpreter lock, which is a Python problem, right? So all these threads will be trying to use the same processor. Now, if you have multiple processors, you can actually use, sorry, multiple processes. You can actually assign each process to a processor. And you can run, you know, multiple things. Now this means that you have to organize your code in such a way that there's more than one Django running on one machine, right? So how do people do that? People actually divide, clearly divide their project into the back-end processing and the front-end processing. So sorry, background tasks and the foreground tasks, right? So something which is user-facing, like rendering pages and all, will happen in one processor, whereas some other salary task or something like that will be running in the background, which will actually use all the other processes, like video encoding or, you know, something which is slow and takes a longer time. So they generally use up all the processor, trust me. So this is a easy way to do that, but it's not possible because of Python, not because of a Django limitation. Okay. And another problem is that Django is single-threaded. So that's why I need to use another server for that to take it to multi-thread, like Ganycon I used. Right, right. So is there any solution, right, in Django Foundation to make it multi-threaded or it will remain single-threaded all the while? No, no. Actually, Python 3 already has a alternative for Unicorn and G-Event and all that. So they're coming with a module called Async.io or Async.core, which actually becomes abstraction for all these things, like G-Event or Tornado or whatever it is. So this whole event model is actually being abstracted by the built-in library called Async.io. So currently, we are actually trying to figure out how we can use Django, that run server mechanism to actually utilize that. So ideally, Python and Django will actually work together to solve this problem of multi-threading in a very clean manner so that all these other things, if you remember Twisted was also a solution before. So all these guys will actually use a common abstraction based on Python 3. For Python 2, guys, I'm sorry, you are on the end of the road. I mean, I used only Python 2, that's why. Yeah, please upgrade. Last question. Hi. Hi. Yeah. I wanted to know how easy it is to shift a current existing complex project to Django to show us to use the feature like debugging and logging and all that. How easy it is? What is your existing project in? A normal, it has lots of model and all. I have modified it. It's not a web-based application yet. It's a million API centric project. Okay. And it uses the Django admin, customise Django admin a lot. Okay, you already have Django, but you want to use some of these features. Basically, I don't have logging and debugging. Right, right. So that's what I said. I mean, it's an open-source project. It's basically a couple of settings. So what happens is that I create a branch called a feature branch and I actually add logging and then I merge it back to master branch. So if you just go back to the history, you can actually find out what all changes I made and that'll be maybe five or 10 lines at the max to add logging or debugging or whatever it is there. So you can incorporate it in your own project as well. Thanks, Saloon.