I have been very busy lately, and actual posts take a lot of time, so I am writing my little thoughts here.

Django + Ajax

1. json.dumps(your_dict) does not like methods in the dict. Say, you commented @property or @cached_property for some function you use in the your_dict. As a result, you get a nasty TypeError: Object of type 'method' is not JSON serializable.
2. DO NOT pass csrf token to AJAX as {{ csrf_token }} on template. Use this getCookie() function.

Django Models

1. Don’t try to cover every little thing. Better set a limit to functionality and launch you app in a week, not in three months.
2. Your excessive queries to the database can be forgiven in the beginning. The more users, the more RAM is needed. And it is an expensive thing to expand all the time.
3. Designing models, you need to know the tasks you need to be doing with them. Yes, you need to make your models look neat and readable, but first and foremost you need your queries to work fast.
4. Don’t make a through=yourtable for a ManyToManyField, if you don’t need it.
5. You may need the through=yourtable if you want to a) assign extra information to the Model to Model relation, or b) if you want to be able to manipulate the changing ManyToManyField data in conjunction with instance’s other data.
6. But if you don’t need it, don’t be afraid to not use through=table argument in ManyToManyField, because Django does not let convert M2M without table to M2M without table in one go.
7. If you need to store an array of elements that you don’t need in your system other than for this particular Model, use ArrayField or JSONField and spend the spared time on petting your dog or whatever.
8. If you need the content of this array further, let them be fields, but make ArrayField or JSONField and store the resulting array there on save (check that everything is ready to be written). I spent hours to simplify a very complex structure and it still took too much time to collect everything I need on page. This option is great, when you need to calculate a lot and it doesn’t change much.
9. Don’t forget that @cached_property does not change within one run, it will hold the first calculated value. If you need it to be cached. make it @property to call repeatedly (say, while saving) and call @cached_property when you need it to be repetitively same (on template).

Django in production

1. You will need separate settings file for sure. But if you spent quite some time on setting it up and still didn’t succeed, just make your default settings.py your production file. For development, create something like mysettings.py and run it like this:

runserver --settings=myapp.mysettings

2. Do you need to have the same migration file both on local and in production? Ideally, yes. But it depends. In the beginning I encountered error I don’t think I will ever be able to emulate right now… so I made hot fixes for models, migrations etc. As some point I even made a script that wiped my server migrations. Safe to say, that day was an divine experience.

What I am saying, for the first project, I would recommend separate migration files. Once you are at the level where you won’t faint at yet another ‘ProgrammingError: column “onetotwo” of relation “one” already exists’, you are good to have same migration files everywhere.

SEO

Make. A. Semantic. Core.

Working with JS/Front-end developer

1. Every kind of set of data should work, and don’t let yourself believe that anybody but you should check that, every kind of dataset. You could’ve done everything the web interface developer said to you, but the client still won’t be satisfied.