I learned django app development a little bit.
Compared with rails, django lacks considering development convironments.
When you want to prepare separate files for development, and production, you have to create your settings yourself.
And you have to create database in your terminal, of course that’s why you need to prepare local db environments as well.
In that way, I felt django cost higher to learn than rails.
These are what I think are important steps.
1. split settings.py
On default, django makes settings.py for you. But it is meant to be used in development environment.
When you deploy your app to production(like heroku, linode, amazon ec2,etc.), you might need to disable Debug mode, and switch database to production. On Rails,
$ ENV=production your action ....
it is enough. but in django, you need to tweak import.
In settings.py, you can add the following at the end of settings.py:
try: from #yourappname.settings_local import * except ImportError: pass
This overrides setting entities. if you uses version control, it is better to exclude or ignore settings_local.py.
You can name this file as you like. whatever you set for developemnt, it never affects deploment environments.
2. prepare templates
Django template system is not intuitive.
First, you have to specify template directory paths in settings.py. These are absolute paths.
Second, you specify template file in your views.py. These are relative paths from paths you wrote in the first step.
The important point is that template dir is not associated with views. So you can put template dirs outside app, anywhere in your file system. It would be confusing for rails users.
This is my preference :D. I know ecosystem in pytyon3 is much smaller than pytyon2.
But in the future, python2 will be deprecated. Obviously, pytyon3 dev is getting active in these days
So I recommend you to invest your time in learning pytyon3 in advance.
Now that Django supports pytyon3 officially, you can go for python3 whenever you want.
We apologize for the impact to affected customers. While we are proud of the last three years of availability on DynamoDB (it’s effectively been 100%), we know how critical this service is to customers, both because many use it for mission-critical operations and because AWS services also rely on it. For us, availability is the most important feature of DynamoDB, and we will do everything we can to learn from the event and to avoid a recurrence in the future.