TomasHuk

Вообще при работе с демонами делается следующая схема.
1. Любой демон при старте записывает свой PID в какой-нибудь файл и работает.
2. По крону, допустим каждые 5 секунд, запускается менеджер, который считывает файл(ы) с записанным PID и проверяет жив ли процесс. Если процесс жив, то менеджер завершает свою работу. Если процесс умер, то он поднимает демона, и завершает свою работу.

Я увлекся пайтоном может с 2 месяца назад. Я написал на нем себе для компьютера ассистента с распознаванием речи(очень глупого, но все же он облегчает мне жизнь), написал парсер погоды(и встроил в ассистента), хотел поиграться с нейронными сетями, но понял что 2 месяца - это довольно короткий срок, и решил лучше подучить как пайтон, так и всякую теорию, которая может пригодиться программисту. Думал про написание вирусов, но даже не приступил, потому что вспомнил, что питон не компилируется, и получается вирус должен всегда носить с собой интерпритатор, который много весит(для вируса). Я думаю пайтон больше подходит для частного пользования, всяких научных исследований и других полезных штуках, чем для написания вирусов. Для вирусописания лучше использовать языки из семейства Си, т.к. в мире много компов с операционной системой Windows.
Если что неправильно написал, не бейте сильно, я еще маленький программист.

Бекенд - делает серверную логику,
Фронтенд - делает клиентскую логику,
Верстальщик - верстает сервис, по макету, нарисованному дизайнером
Дизайнер - рисует дизайн сервиса

По 1му каждый. Можно убрать верстальщика и оставить только фронтенд разработчика, при условии, что тот умеет верстать(хотя, он должен уметь верстать, но, некоторые уже не любят этим заниматься).

Тз, откуда мне знать, как его правильно составить, если я не знаю весь функционал вашего сервиса, пускай он и похож на другие. Для начала выпишите себе весь функционал, опишите работу этого функционала, что с чем должно взаимодействовать. Какой должен быть личный кабинет, что в нём должно быть, сайты, на которых размещено окно, графики какие-то или ещё что-то. Если вообще не знаете, то я бы на вашем месте сначала изучил сервисы, которые вы привели в пример. Как и что у них сделано, выписал бы минусы того сего, плюсы какие у них, отличие друг от друга. Эти данные использовать для построения своих требований для своего сервиса.

Порядок действий.
1) Описали всю логику сервиса, ПОЛНОСТЬЮ, до мельчайших деталей, прям каждую писечку!!!! Всё всё всё. После прочитать раза 3 от начала до конца, 100% появятся правки или дополнения. Все функции по монетизации, тарифы, личные кабинеты, конструктор самого окна, функционал вставки этого окна и всё всё всё. Ибо никто не станет вам на добром слове вносить изменения в созданную прогерами архитектуру проекта, потому что вы, не удосужились вписать новое требование в тз. С вам, что логично, потребуют доп плату уже к той, что была оговорена в начале.

2) Ищите дизайнера. Нашли? Отлично! Тогда:
1.1) По вашему тз делается прототип, того, что и как будет расположено на сайте, где какие элементы. Это как первые наброски, чертёж, если угодно.
1.2) На основе этих набросков рисуется макет, утверждается дизайн сервиса.
1.3) Утвердили все страницы, все элементы, все всё всё. У вас уже есть то, как выглядит ваш сервис.

3) Берём фронтенд разработчика + бекенд разработчика
Тут нужно подойти ответственно. Хорошего разработчика порой трудно найти, часто, хорошие стоят дорого, дешёвые сделают тяп ляп и ваш сервис станет очень сложно менять и дополнять в будущем.

Нашли? Отлично!
Обсуждаете с ними, что и как будет, и что вы вообще хотите. Показываете им 2м тз, макеты. Они между собой, на основе этого тз, распишут план работ, сроки, вёрстку, а так же, как и что будут реализовывать и что им может понадобиться. Как будут работать эти всплывающие окна, куда какие данные будут отправлять и т.п.

Сам план работ, лучше разделить на этапы с вашей стороны. Т.е. Сделали один функционал, проверили, ещё 1 проверили. Разделить всё на задачи. Вам от этого только лучше, т.к. вы видите, что уже реализовано и сам факт того, что процесс идёт. Но повторюсь, нужно эти этапа с прогерами обсудить и принять.

На основе того, что они решат, вам нужно выбрать хостинг. Все хостинги разные, у всей свой функционал, вместе с ними(так как вы наверняка не шарите) нужно выбрать хороший хостинг, т.к. ваш сервис предпологает размещение своих окон на чужих сайтах, а значит, в теории, что разместив таких окон около тысячи, на ваш сервер пойдёт некая нагрузка. Этот вопрос нужно учесть, что бы он в ненужный момент не упал от нагрузки. Скажу сразу, может стоить дорого, но это ваши заботы)))

4) Тестирование
Все всё сделали, ура. Дальше, начинаем тестировать сервис на его функционал. Ошибки и баги будут 100%. Все мы люди, все можем ошибиться, нужно эти ошибки исключить.

5) Выкатка приложения:
Т.к. сайт делался на дев(там, где разрабатывают) версии, осталось выложить сайт на основной домен(Который вы должны ещё приобрести). Выложили, всё настроили, ура. Приложение готово. Далее, реклама, маркетинг, сео и прочая чушь.

P.S. Так как всё это пахнет фрилансом, то будьте готовы, что вас могут кинуть, игнорить, пропадать не известно куда. Не забудьте составить договора с прогерами, где будут описаны все нюансы. А так же, что бы под конец все права принадлежали вам и только, получение всех доступов, данных и т.п. Иначе потом, можете всё похерить и никто вам уже не поможет.

Примерно так))

Советую вам посмотреть в сторону декораторов. Полезно будет как для решения задачи, так и для общего ознакомления с синтаксическими возможностями языка.
Дам пример самого простого декоратора, единственная функция которого "тихо" логгировать любой exception:

import logging


LOG = logging.getLogger(__name__)


def handle_silently(function):
    def wrapped(*args, **kwargs): 
        result = None
        try:
            result = function(*args, **kwargs)
        except Exception as e:
            LOG.error(
                '{}(*{}, **{}) failed with exception {}'.format(
                    function.__name__, repr(args), repr(kwargs), repr(e) 
                 )
            )
        return result
    return wrapped


@handle_silently
def some_function(test):
    return test / 0

Конструкция @handle_silently заменит вашу функцию some_function на функцию wrapped.
Механика работы wrapped является, скорее, антипаттерном, поскольку замалчивать exception совсем и тем более отдавать вместо него None - это гарантированный способ выстрелить себе в ногу. Это просто пример, в боевом проекте я бы посоветовал ререйзить (LOG.error(...); raise) ошибку в декораторе и обрабатывать несредственно в месте вызова функции (логгирование, естественно, можно и оставить).
Для затравки и для демонстрации того, как это может быть полезно - декотораторы могут быть параметрическими (достигается это путём создания фабрики декораторов):

def decorators_fabric(handler_function):
    def decorator(function):
        def wrapped(*args, **kwargs):
            handler_function(function.__name__, repr(args), repr(kwargs))
            return function(*args, **kwargs)
        return wrapped
    return decorator


@decorators_fabric(print)
def my_test_function(arg1, arg2):
    return arg1 * arg2

Нашёл!
Автор: mindw0rk
Рассказ: Незнакомец по ту сторону сети
Рассказ не длинный.

Лучше писать зависимости в requirements.txt и уже этот файлик добавлять в git.
Пример файла (можно с указанием версий через ==, можно без):

Django==1.8.5
django-flat-theme==1.1.1
mysql-python==1.2.5
gunicorn==19.4.1
pytz==2015.6
python-memcached==1.57
django-debug-toolbar==1.4

При клонировании репозитория на другой компьютер или сервер выполните (предварительно создав и активировав нужное виртуальное окружение):
$ pip install -r requirements.txt
Таким образом, вы разом установите все необходимые пакеты.

Дешевле и быстрее купить монитор. потому что подходящий LVDS адаптер придётся долго и нудно искать, я уж не говорю про сборку цепей питания у этой конструкции