Артём Клименко

https://getsentry.com/welcome/ - шикарное высокоуровневое решение, но на мой взгляд оно не предназначено для лоигорования сразу всего, чтоб потом решить что нужно, скорее логировать туда ошибки, вами самим определённые события и прочее (предоставляется и как услуга, так и на своём сервере развернуть можно)

Для более общих случаев возможно стоит глянуть в сторону logstash.
Ну и познакомится с такой вещью как https://ru.wikipedia.org/wiki/Syslog

за первые 3 пункта ничего вам не скажу, по 4-му:
bender.astro.sunysb.edu/classes/python-science
www.astro.cornell.edu/staff/loredo/statpy
собственно питон в этой области популярен не потому что он питон, а из-за существующих инструментов, уже на которые ложится пайтон, со всем тем за что его любят и не любят

ещё на данный момент обратите внимание djbook.ru/rel1.8/ref/settings.html#append-slash

htmlbook.ru/html/ol

как таковые родные перечисления появились только в 3,4, но есть бэкпорт https://pypi.python.org/pypi/enum34 вплоть до 2,4
Но вполне возможно вам хватит и атрибутов класса?

class A(object):
    B = 0
print A.B  # 0

Если вы заранее знаете какие поля обязательно будут и вас интересуют только они, почему просто не создать собственный класс с этими параметрами, __init__ которого будет принимать на вход эти параметры в нужном порядке, и *args - в который попадёт всё остальное, что при желании можно сохранить или проигнорировать.
если волнует выделение памяти используйте __slots__

Собственно очевидные варианты, работа с ресурсами - файлы. конекты к бд, они уже все готовы для работы с менеджерами контекста.

допустим так: Как мониторить медленные и прожорливые места скрипта?

как видится мне:

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

Про разницу между PostgreSQL и Oracle ничего не скажу, но рекомендую к прочтению: postgresql.leopard.in.ua

потребление памяти: https://pypi.python.org/pypi/memory_profiler

Для замера времени выполнения в боевых условиях использую обычно такой менеджер контекста:

class Profiler(object):
    def __init__(self, message_format='Elapsed time: {:.3f} sec'):
        self._message_format = message_format

    def __enter__(self,):
        self._startTime = time.time()

    def __exit__(self, rtype, value, traceback):
        print(self._message_format.format(time.time() - self._startTime))

использовать крайне просто:

with Profiler():
    <код время выполнения которого необходимо замерить>

1. Код программы почти не нуждается в изменении.
2. минимальные накладные расходы(крайне важно поскольку "нормальные" профилировщики сильно всё затормаживают, но и выдают гораздо более детальную информацию)
3. замерит время в любом случае, если даже произойдёт исключение.
4. аналогичную конструкцию(с минимальными изменениями для работы с logging) использую и в продакшене.

хех, сам пишу аналогичные вещи =)
Начать несомненно с описания самого главного, оборудования.
Какое оборудование вы хотите хранить?
---Составить список моделей, производителей
какие параметры будут его характеризовать?
---Какие различные параметры каких типов.
И тут надо принять одно из самых главных решений в области хранения параметров, как оно должно быть представлено в БД.
Если всегда одни и теже параметры, то одна таблица с необходимыми полями, если существуют группы оборудования со своими наборами параметров, и их не много и не будут они расширятся, то отдельные таблички с описанием параметров отдельного типа оборудования. И *барабанная дробь* самый универсальный случай, когда каждая модель может иметь произвольный набор параметров, модели создаются через конструктор, тут опять несколько вариантов, или организовать EAV, или допустим хранить шаблон параметров и сами значения в json (в постгре какраз удобно), или самое сложное но и гибкое, разнесение по отдельным типам в бд разных типов параметров, с кастомным поведением для каждого. - честно говоря реализация последнего вам уже до конца года хватит ^^
Собственно по каждому типу параметров определится с его особенностями, допустим будут ли у вас адреса, если да, просто текстом будет хранится или из некой базы подтягиваться (ФИАС прикрутить допустим), можно будет выбрать только дом или можно будет привязать оборудование к кварталу или улице, что делать если нет определённого адреса? хранить ли геокординаты?. Если нужны ip адреса, просто это ип, или необходимо указание к какой подсети он относится, связанно собственно с системой учёта ip адресов.
Какие поля будут уникальными, какие обязательными для заполнения, какие доступными только для чтения, как сообщить пользователю об этих особенностях.

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

Вопрос на чём вы хотите сосредоточится?
Если хотите разобраться с Вёрсткой, не используйте готовые фреймворки, почитайте про БЭМ, попробуйте less или sass, реализуйте хоть страшный но свой интерфейс, протестируйте в разных браузерах. Потом натяните нормальный css фреймворк, попробуйте кастомизировать под себя.
Неплохой задачкой было бы построение RESTapi для вашего сервиса, с версионностью, поддержкой метода INFO... И взяв хороший js фремворк, организовать общение страницы и сервера именно через апи.
К гиту лучше всего привыкать сразу, и желательно поробовать работать используя такой подход habrahabr.ru/post/106912
БД само собой делать в 3-й нормализованной форме, контролируйте сколько и каких запросов бд, разберитесь с EXPLAIN и как работают составные индексы, да и собственно различные виды индексов в постгре, и да попробуйте использовать ОРМ(с фласком видимо прямая дорого к sqlalchemy).

з.ы. извиняюсь за сумбур =)

djbook.ru/rel1.8/topics/db/optimization.html
https://docs.djangoproject.com/en/1.8/topics/db/op...

Пробовал django-mptt, но после пары дней тестов отказался, при попытке создать из 40к элементов порядка 700 деревьев, период беспроблемной вставки составлял элементов 500, потом начинали вылитать исключения, с включением отложенной перестройки дерева, период увеличился до 1500 элементов. на этом знакомство закончилось. По моим впечатлением вещь удобная, но когда данные редко меняются, и их не особо много.
В итоге ограничился собственными костылями в виде полей root, parent, lvl, и хитрый order. чего более чем хватало для моих нужд(но это меньше чем то что предлагает django-mptt).

совершенно спокойно, в одном случае динамически был создан данный атрибут, в другом случае никто его не создал, вот его и нет.
Небольшой совет, лучше всего все(если есть такая возможность) используемые атрибуты класса явно задавать внутри __init__, инициализируя либо пустыми значениями, либо значениями по умолчанию.