Django *

Первый шаг

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

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

Я работаю, в основном, с Python/Django стеком, поэтому все примеры будут, в первую очередь, применительно к этому набору. Также ключевые технологии: Ubuntu (17.10), Python3 (3.6).

Содержание:

• Логи (logrotate)
• Демоны (systemd)
• локальные настройки

1. Об идее проекта – зачем я это сделал, какие есть аналоги, но почему мне они не нравятся.
2. Архитектурных решениях, какие возникли трудности, как были решены.
3. Что получилось в итоге и стоило ли оно того, дальнейшее развитие.

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

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

Всем привет!

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

Когда мне понадобилось реализовать этот функционал, оказалось что существует не так много туториалов, особенно на русском, в которых бы описывалось как сделать регистрацию по email, отправку верифицирующего письма, сброс пароля и другие, в общем то вполне обычные вещи.
Я решил исправить эту несправедливость.

Привет всем!

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

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

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

Практически каждый человек сталкивается с ведением какого-либо учета, сбором и анализом данных: от использования таблиц в экселе до работы с данными в клиент-банковском приложении. Повсеместно для такого учета используются различные системы управления базами данных (СУБД).

В статье я хотел бы рассказать о своем пути поиска такой системы.

Наступила осень, и, несмотря на хорошую погоду, наши зрители потянулись за новым видеоконтентом. Бекенд-серверы, обслуживающие эмбеды с видео, стали упираться в CPU. С криками "а-а-а" прибежали системные администраторы и начали отбирать у отдела разработки ноутбуки и десктопы, грозясь поставить их в датацентры "на усиление". Разработке это конечно всё не понравилось и все поувольнялись с этой хренью решили что-нибудь сделать.