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

В конечном итоге встают задачи о фоновой отправке, об изменениях отправителя, приоритизации, повторной отправке сообщения в случае неудачи, частом редактировании по просьбе клиента/маркетологов, прикреплению к письму стандартных файлов в виде каких-то инструкций по применению продукта, или же стандартных документов, отчетов по клиентам, переводам и тд и тп.

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

Для подобных решений существует простая батарейка, призванная решить большинство подобных проблем, и избавить Вас от лишнего кода, сопровождения и нервотрепки.

В данном посте представлен обзор новшеств и особенностей популярного среди Python разработчиков фреймворка Django 1.7. Релиз позиционируется как сообществом, так и основными разработчиками — как наиболее значимый релиз, с момента выхода в свет Django 1.0.

Часто и во многих проектах, используются фоновые задачи. Но в подавляющем большинстве, по какой-то причине не используется никакого мониторинга. Речь идет о таких сервисах как Sentry, NewRelic или же нативный ErrorReporting. Нет никаких отчетов о том, как долго выполняется команда, с какой ошибкой и каким образом был завершен процесс. В итоге никто не знает на сколько корректно работает проект и недоумевают, когда в репортах или в crm не хватает каких-либо данных, или же статистика неполная/неверная. Заметно это не всегда и отнюдь не сразу. То есть обнаруживается на много позже, после сдачи проекта.

Различные дистрибутивы предоставляют свои утилиты, для сборки и установки программ.
Например в Debian/GNU Linux — это debuild и dpkg. В Red Hat Linux — rpmbuild и rpm.
Не редко нам приходится собирать пакеты самостоятельно.
Устанавливать программы через make, в обход системы управления пакетами в дистрибутивах — является дурным тоном.
В случаях, когда мы имеем исходный код, и автор программы позаботился о создании Makefile, можно использовать checkinstall.
Но бывает и так, что автор java приложения, не выкладывает ничего кроме jar файла. Или мы хотим на коленке создать какой-то пакет, и положить в репозиторий, что бы в дальнейшем устанавливать/обновлять его на множестве серверов с различными дистрибутивами. В этом нам поможет утилита под названием fpm.
В чем же ее достоинство? Она из коробки позволяет нам собирать пакеты под различные дистрибутивы и даже операционные системы.

Сейчас поддерживаются:

• deb
• rpm
• solaris
• tar
• directories
• Mac OS X .pkg files (osxpkg)

В данном топике, будет рассказано о пошаговой настройке и конфигурации проекта и сервера с использованием связки pinba-engine + pinboard + django-pinba, для сбора и визулизации статистики проектов на Django.

Все проекты являются бесплатными и их исходный код доступен на GitHub под лицензиями GPL или MIT.

Почему pinba?

В команде есть проекты, которые были написаны на php. Посещаемость у проектов достаточно высокая(свыше 200к). Есть очень много узких мест. Часто после каких-либо обновлений и новшеств, мы получали огромные тормоза, о которых узнавали не сразу. Нужно было решение, которое повернуто лицом к заказчику и программисту. Закачик очень не любит zabbix и munin. Решение нашлось. Это был pinboard и pinba. Заказчику понравилось. Он попросил прикрутить pinba ко всем проектам, которые крутились на django.