Собрали в одном месте самые важные ссылки
и сделали Тренажер IT-инцидентов для DevOps/SRE
Рано или поздно, разработчик на Django встречается с проблемой: как сделать так, чтобы пользователи не могли изменять или удалять, а то и вовсе не видели разных объектов одного и того же типа.
Допустим, ваш проект касается хранения информации о проектах. Разные пользователи входят в разные проекты и не должны видеть информацию о другом проекте. Один и тот же пользователь может входить в несколько проектов и иметь разный статус в разных проектах — где-то он может только просматривать информацию, а в других — править данные. В каком-то проекте пользователь зарегистрирован как персонал проекта, а в другом — только как потребитель его услуг. Уровень доступа соответственно, должен быть совершенно разным.
Этими вопросами занимаются несколько пакетов, мы рассмотрим один из них — Django-Access. Все, кому это интересно, приглашаются под кат.
Заметка о переопределение пользовательской модели в Django, а также описание некоторых нюансов, которые нужно учитывать при разработке третьесторонних библиотек для Django, которые используют пользовательскую модель.
Небольшая заметка о том, как поправить queryset форме администрирования admin.ModelAdmin или UserAdmin . Собственно разницы никакой, поскольку форма UserAdmin наследована от admin.ModelAdmin . Но тем не менее покажу на примере UserAdmin
Перевод статьи: Leonardo Giordani – Multiple inheritance and mixin classes in Python
Недавно я пересмотрел три своих старых статьи о представлениях на основе классов Django (class-based views), которые написал для своего блога, обновив их до Django 3.0 (вы можете найти их здесь), и еще раз обнаружил, большое количество кода использующего классы mixin для улучшения повторного использования кода. По своему опыту я понял, что миксины не очень популярны в Python, поэтому решил изучить их лучше, тем самым освежив свои знания теории ООП.
При написании приложений на Python, для работы с базами данных часто используются объектно-реляционные мапперы (ORM). Примерами ORM являются SQLALchemy, PonyORM и объектно-реляционный маппер, входящий в состав Django. При выборе ORM довольно важную роль играет её производительность.
Оригинальная статья: PAWEŁ FERTYK – Getting started with Django middleware
Django поставляется с множеством полезных функций. Одним из них является механизм middleware (переводится как промежуточное программное обеспечение). В этом посте я кратко объясню, как работает middleware и как начать писать свой собственный.
Исходный код, включенный в этот пост, доступен на GitHub.
Python, хоть и мощный, но всего лишь инструмент, который позволяет писать выразительный самодокументируемый код, но не гарантирует этого, как не гарантирует этого и соблюдение PEP8. Когда наш, казалось бы, простой интернет-магазин на Django начинает приносить деньги и, как следствие, накачиваться фичами, в один прекрасный момент мы понимаем, что он не такой уж и простой, а внесение даже элементарных изменений требует все больших и больших усилий, а главное, что эта тенденция все нарастает. Что случилось, и когда все пошло не так?
Динамическое создание моделей или полей к уже существующей модели в ORM Django редко встречаемая задача, но иногда специфика бизнеса требует ее реализации. К примеру может возникнуть необходимость получение данных из внешней БД и при этом сами данные могут иметь либо очень большее количество полей (более 100), либо иметь постоянно меняющиеся поля. Но вы должны быть осторожны, если пойдете по этому пути, особенно если ваши модели настроены на изменение во время выполнения. В этой статье я рассмотрю ряд вопросов, которые следует учитывать при создание динамических моделей.
Когда я впервые столкнулся с Flask, у меня сразу возник вопрос по построению архитектуры проекта.
Прочитав пару статей на Хабре (https://habr.com/ru/post/275099/ и https://habr.com/ru/post/421887/), я вспомнил свой опыт создания проектов на Django, и решил сделать инструмент, благодаря которому не придется задумываться об архитектуре, но при этом можно будет использовать все возможности Flask.
Оригинальная статья: Luke Plant – Double-checked locking with Django ORM
Шаблон блокировки с двойной проверкой может быть полезен, когда:
Этот пост о том, как можно реализовать этот шаблон в Django, используя функции ORM и блокировки на уровне базы данных. Шаблон может использоваться с любой другой ORM, но я проверил его только с Django, и подтвердил, что он работает, как и ожидается, используя PostgreSQL.
Очень часто можно услышать о методах тестирования, таких как TDD, и о том, как тестировать бизнес-логику приложения. Однако тестирование производительности приложения – это совсем другая задача. Есть много разных способов, но самым общим подходом считается создание среды, в которой можно проводить DDoS-атаку на свое приложение и наблюдать за его поведением. Это очень интересная тема, но это не то, о чем я хочу сегодня поговорить. Сегодня мы рассмотрим более простой тест, тот, который вы можете сделать с использованием юнит-тестов Django по умолчанию: то есть тестирование количество обращений вашего приложения к базе данных.
Речь пойдет о том, как мы поддерживаем здоровье кодовой базы в проекте с безумными требованиями к скорости и постоянно меняющимися задачами. Мы поговорим про TDD, SOLID и KISS там, где люди меньше всего к этому готовы — в стартапе, который доставляет стройматериалы
В этой статье я бы хотел рассказать как можно реализовать автоматический контроль над изменениями данных в проектах построенных с использованием Django.
Джанго это мощный фреймворк для создания веб-приложений. Изначально Django был создан для того, чтобы быстро создавать, например, новостные сайты (или другие сайты, который нужно создавать максимально быстро). И после нативного PHP не покидает ощущение, что ты едешь на очень быстрой машине разработки. Чтобы посмотреть все его возможности для быстрой разработки, мы с вами попробуем создать простое Todo — приложение.
Шаблон проекта на Django – это естественный способ решения проблем, которые возникают, когда формат Django-проекта по умолчанию уже не отвечает требованиям. Сегодня в этом руководстве вы узнаете, как создать свой собственный проект из шаблона.
Недавно передо мной встала задача написать на Python web-приложение для разделения счёта в ресторане между участниками трапезы. Так как нужна DB для хранения данных о заказах и пользователях, встал вопрос выбора ORM для работы с базой. Разработка велась на Flask, так что сразу отметается Django ORM и выбор изначально пал в сторону SQLAlchemy. С одной стороны эта ORM почти всемогущая, но за счет этого она довольно тяжела в освоении. Помучившись с алхимией какое-то время, я решил найти более простой вариант, чтоб разработка пошла быстрее. В итоге для проекта была выбрана Pony ORM.
В данной статье описано использование легковесных инструментов для публикации сайта на Django - gitea, drone
Конфиги. Все хранят их по разному. Кто-то в .yaml, кто-то в .ini, а кто-то вообще в исходном коде, подумав, что "Путь Django" с его settings.py действительно хорош.
В этой статье, я хочу попробовать найти идеальный (вероятнее всего) способ хранения и использования конфигурационных файлов в Python. Ну, а также поделиться своей библиотекой для них :)
Словил себя на мысли, что несмотря на то, что большинство моих веб-приложений работают на aiohttp.web, их настройка происходит в лучших Django традициях
Я занимаюсь разработкой и поддержкой сервиса уведомлений. Сервис написан на Python3 и Django. Помимо транзакционных писем, пушей и сообщений, сервис также берёт на себя задачи по массовым рассылкам коммерческих предложений (не спам! trust me, отписки у нас работают лучше подписок) пользователям, давшим на это согласие. Со временем база активных получателей разрослась до более миллиона адресов, к чему почтовый сервис не был готов. Я хочу рассказать о том, как новые возможности Python позволили ускорить массовые рассылки и сэкономить ресурсы и с какими проблемами нам пришлось столкнуться при работе с ними.