CBV хороши для приложений, которые делаются для повторного использования. Сколько раз сталкивался: есть некое приложение, в нем вьюха, и хочется немного изменить ее поведение. И вот тут вьюхи на функциях предстают как черный ящик — на входе параметры, на выходе — HttpResponse, с которым уже мало что можно сделать. Хорошо, если автор предусмотрел какие-то параметры, с помощью которых можно кастомизировать поведению вьюхи. Иначе остается только переписывать весь ее код ради небольших изменений
Делаю вывод, что статью вы не читали. Если бы прочитали, то увидели бы, что init-скрипт уже есть, что он при запуске поднимает все проекты, для которых найдет конфигурации в /etc/uwsgi/apps-enabled (на самом деле там симлинки на файлы конфигурации в /etc/uwsgi/apps-available), что любой проект можно запустить/остановить/перезапустить с помощью /etc/init.d/uwsgi start|stop|restart project_conf_name. И логи там ротейтятся, я вас уверяю. Как-то так вобщем
Структура каталогов как в статье только для примера. Можно и по-другому организовать.
По пунктам:
1. Переопределяем uid и gid
2. Статья как раз об этом
3. А это решается правами на уровне файловой системы
А как в вашем подходе обеспечивается поддержка разных виртуальных сред для разных проектов?
1. Наблюдатели сами ведут фото и видеосъемку собственными средствами. Но самое главное — отснять протокол. Потом это все выкладывается в сеть любыми возможными способами — во вконтакте, фейсбуке, торрентами и т.п. Продумать схему именования. Смысл в том, чтобы любой желающий мог найти в сети материалы по интересующим его участкам. Судя по комментариям выше, необходимо донести до председателей комиссий и полиции, что съемка на участке не является противозаконной. Но раз власти сами вбросили идею с камерами на участках, то с этим теперь должно быть меньше проблем. Это самый главный этап.
2. Каждый заинтересованный находит в сети материалы, например, по своему участку. Оценивает достоверность этих материалов, а самое главное — итогового протокола. Данные протокола по участку забивает на специальном сайте (лучше на нескольких). На этих сайтах желательно предусмотреть защиту от накруток, например, с помощью подтверждения регистрации через смс. Ну а потом можно и посчитать. Краудсорсинг — великая сила. Думаю, таким образом можно было бы получить достаточно репрезентативную выборку.
Я явно не упомянул в статье, что существует базовый набор пакетов, который добавляется в прошивку по умолчанию. И dropbear в него входит. Чтобы исключить из базового набора какой-либо пакет, его нужно добавить в PACKAGES с минусом. В своем примере я исключил из прошивки wpad-mini, который добавляется по умолчанию, и включил вместо него wpad.
[uwsgi]
plugins = python27
virtualenv = /home/web/envs/example1/
chdir = /home/web/proj/example1/
pythonpath =…
env = DJANGO_SETTINGS_MODULE=example1.settings
module = django.core.handlers.wsgi:WSGIHandler()
uid = user1
gid = user1
example2.ini:
[uwsgi]
plugins = python27
virtualenv = /home/web/envs/example2/
chdir = /home/web/proj/example2/
pythonpath =…
env = DJANGO_SETTINGS_MODULE=example2.settings
module = django.core.handlers.wsgi:WSGIHandler()
uid = user2
gid = user2
По пунктам:
1. Переопределяем uid и gid
2. Статья как раз об этом
3. А это решается правами на уровне файловой системы
А как в вашем подходе обеспечивается поддержка разных виртуальных сред для разных проектов?
2. Каждый заинтересованный находит в сети материалы, например, по своему участку. Оценивает достоверность этих материалов, а самое главное — итогового протокола. Данные протокола по участку забивает на специальном сайте (лучше на нескольких). На этих сайтах желательно предусмотреть защиту от накруток, например, с помощью подтверждения регистрации через смс. Ну а потом можно и посчитать. Краудсорсинг — великая сила. Думаю, таким образом можно было бы получить достаточно репрезентативную выборку.