Make three/two separate settings files
Ideally, you want to have a base settings file. This has all the important juicy settings stuff. Now, create an empty file called local.py in the same directory. And a third called prod.py. Both of these will import everything (with *) from base.py.
In your local file: DEBUG = True, ALLOWED_HOSTS = [‘localhost’, ‘127.0.0.1’, ] or wherever you do your local development on.
in your prod file: DEBUG= False, production database info is here. Some other details about deployment too.
Note: make sure you don’t EVER commit your settings files. Simply add the directory your settings files are in to your .gitignore. God forbid your server/database passwords ever ended up on Github and you got hacked!
Don’t be afraid to use Mixins — with models
Don’t get me wrong, I hate seeing mixins being used all over the gaff too. But it sometimes helps to use them. If you don’t know, a mixin is basically a class that can be used by other classes without being a parent. OK, that sounded complex.
Django models are pretty good at what they do. And part of the reason they’re so good at what they do, is because they allow three different types of inheritance: abstract, multi-table inheritance (one-to-one field) and proxy models (by setting proxy to true).
Mixins are abstract. That is to say, when you use a mixin with a model, you’re not actually creating a new table. You’re basically saying, hey, this method, or that method (get_url) should be accessible to this model (Shop/Product). These are really good when you know that doing a bit of logic will be super super common and you want to abide by DRY!
class UrlMixin(object):
def get_url(self):
pass
class Shop(UrlMixin, models.Model):
# insert some fields about shops here
class Product(UrlMixin, models.Model):
# insert some fields about products hereMinimise trips to database
Trips to the database cost money. They also cost time. When you’re doing your views, keep this in mind. There’s no point doing shit ton of queries every time you need a blessed thing done. Sometimes, it’s must easier to do an initial query and to build dictionaries that you can 1) pass into your context and 2) do other cool stuff with. That way, you’re not paying an arm and a leg in database fees and your customer isn’t waiting.
When writing a view, keep in mind how many trips are needed. Have that thought be at the back of your head.
Use the Python Debugger
pdb is a blessing. I love it so much, I wanna name my first child after it. Anytime I get a bug, I reach for pdb. And unlike IPython’s debugger, it doesn’t cause the entire system to break when you want to leave the session or change a bit of code in your IDE.
//this is how you import it
import pdb; pdb.set_trace()// here are some commands you can use
s ---> takes a step, stops at the next line
l ---> list the source code, or 11 lines in the immediate area
c ---> keep going until something stops you or you finish
Use the Shell
It’s import to get into the habit of using the shell to figure stuff out. Mostly, data problems. You can import models directly and do queries. You’ll find that your python skills get better, as does your ability to write awesome querysets. I think more than that though, it helped me gain a deep understanding of just how incredible Python is at being an OOP language it is.
You go into the shell and nothing is in scope. You bring things in. You manipulate them. You ask them, who are you, what can you do, who are you connected to, is possible that I can manipulate you to do other stuff. Once my experimentation is done, I got to the IDE and write out nice and clean code!
//my three favourite things to use in the shell!
locals() ---> shows you the local variables. (in scope)
dir(xx) ---> shows you what is available to xx.
type(xx) ---> what type of thing xx is In fact, I usually have three terminals open. One for my server. One for git. And one for the shell. To get into the django shell, just type the following in the directly where the manage.py file is.
python manage.py shellBefore writing a new app, see if it exists!
There are a lot of really clever people. And if you’re thinking about writing a new app, do a simple search on google. Has someone come across this problem before and have they written an open-source app for it? I promise you they have! This has saved me so much time, honest. There is literally a library or an app for everything!
Don’t be scared to use open source apps.
Follow things — don’t take their word for it.
I use Pycharm. It has a neat feature. You can basically click on any class or function. When working with Django, and you’re trying to figure out how a specific form works, it helps to look up who it inherits from. Look at the methods on there. Who does that inherit from? Can that help me understand how cleaned_data works and if it gets run before or AFTER is_valid?
This came in very handy the other day when I was trying to understand how reversing viewset urls work. Severals levels deep, you get to this bit of code, which says, hey, just add “-[method]” to whatever the basename. It helps to look sometimes!
Use a cache buster or write one
For your own sanity and the sanity of your customers, implement some type of cache buster please! You don’t want them looking at static files from three months ago. There are loads of those floating about. Maybe though, you can write your own.
Keep your templates short and sweet
Import from other templates! Don’t have huge template files. It’s not easy on the eyes and it probably means that you’ll write not very good code. Import from other templates by using
{% extends "base_template.html" %}
{% include "some_other_template.html" %}For goodness sake, use unit tests!
Testing is a bit long, yes. But please! Get into the habit of doing them. Imagine a world in which you are constantly testing your website and you catch stuff WAY before your customers see them. Automated tests let you do that.
