Давно хотел написать на эту тему пост, но никак не мог найти веский повод. И вот сама жизнь подкинула повод, который приходится учитывать всем без исключения.
Учитывая вирусную угрозу и реальные потери в результате болезней сотрудников многие компании начинают задумываться о выводе сотрудников на удаленную работу, но есть в этом то, что отталкивает руководителей и собственников:
- Слабый контроль за сотрудниками (Отсутствие обратной связи, слабые коммуникации и т.п.);
- Неумение сотрудников контролировать себя и работать самостоятельно;
- Сложность организации коммуникаций для выработки решений (совещания, обсуждения и пр.);
- Другое.
Можно долго говорить о повышении квалификации руководителей, развитии доверия, о применении специального ПО для контроля удаленных сотрудников и т.п., но в итоге это не приводит к качественному взаимодействию с удаленными работниками и не дает ощущения командной работы.
В процессе работы над множеством проектов выработал для себя типовую структуру Django проекта, которая удовлетворяет всем моим требованиям и удобна как для разработки так и для поддержки.
Как всегда я использую свой стандартный стэк: Debian/Ubuntu + Python 3.* + PostgreSQL + NGINX + virtualenv + Django
Структура моих проектах основывается на рекомендациях Two Scoops of Django 1.11 с учетом моего стека и выглядит следующим образом:
Часто в проектах использую JSON поля PostgreSQL.
При этом в админке Django они отображаются так как лежат в базе. Выглядит это примерно так:
{
"1": "\u041f\u0435\u0440\u0432\u044b\u0435 \u0434\u0430\u043d\u043d\u044b\u0435",
"2": "\u0412\u0442\u043e\u0440\u044b\u0435 \u0434\u0430\u043d\u043d\u044b\u0435"
}Естественно это не по человечески и хотелось бы видеть в нормальном виде.
Для этого делаем следующее:
Это картинка сопровождающая 500ю ошибку на моём сайте.
Если Вы видите ее не в этом списке постов, то будьте уверены,
я уже занимаюсь проблемой ее вызвавшей.
Иногда случаются ситуации когда данные в базе проекта уже есть и их надо связать с новой моделью, причем обязательной связью один ко многим.
Можно конечно временно обозначить связывающее поле ForeignKey как blank=True и заполнить после того как в новой модели появятся данные, а потом убрать blank=True.
Но это куча лишних действий и две миграции вместо одной.
Можно сделать тоже самое одной миграцией с добавлением в новую модель первой записи.
Для этого надо выполнить следующие шаги:
На VDS одного из проектов который я поддерживаю и который крутится на моем хостере по умолчанию (firstvds) недавно произошел сбой.
Сбои на VDS сами по себе явления необычные, а тут прям все "колом встало".
В результате разбора ситуации оказалось что сбойнула файловая система.
Файловую систему оживил но уперся в другую проблему. Postgres отказался запускаться и писал что-то типа:
