Сегодня я буду писать о Django — фреймворке, который верно служит мне на протяжении последних пяти лет. Он помог мне преуспеть в разработке высоконагруженных решений, используемых сегодня миллионами пользователей.

Действительно, Python не очень «быстрый» язык программирования, однако он прост, удобен и люди его любят. С точки зрения производительности, он не может быть таким же быстрым, как Go или Node.js, но это становится несущественным, если рассматривать современные инфраструктуры и модульную разработку.

Поскольку я уже несколько лет варюсь в этом «котле разработки на Django», я пришел к нескольким ценным выводам, которыми собираюсь с вами поделиться.

Привет, Хабр! Меня зовут Алексей Назаров. Я занимаюсь автоматизацией в отделе администрирования инфраструктурных систем в Национальной системе платежных карт (АО НСПК) и хотел рассказать немного о наших внутренних продуктах, которые помогают нам развиваться.

Если вы еще не читали пост про нашу инфраструктуру, то самое время! После прочтения этого поста я бы хотел рассказать о некоторых внутренних продуктах, которые мы разработали и внедрили.

13 лет назад начался эксперимент по использованию Python в больших сервисах Яндекса. Эксперимент получился удачным (кто бы сомневался!) и Python начал свое победное поползновение по сервисам компании. Яндекс.Афиша, Яндекс.Погода — через некоторое время сервисов стало очень много. Вместе с ними начали появляться «лучшие практики» и «устоявшиеся подходы» к решению задач.


В докладе я вспомнил эволюцию Python в компании: от первых сервисов, запаковывавшихся в deb-пакеты и раскатывавшихся на голое железо, до непростого монорепозитория с собственной системой сборки и облаком. Еще в рассказе будут Django, Flask, Tornado, Docker, PyCharm, IPv6 и другие штуки, с которыми мы сталкивались на протяжении этих лет.

Вместо предисловия

Началось всё с того, что мне предложили в рамках предмета "Основы веб-программирования" поучаствовать в проекте, вместо проделывания лабораторных работ и курсовой, поскольку я заявил о том, что хотел быть делать нечто отдалённое от общего курса (и так уже достаточно знаний было по связке DRF + Vue, хотелось чего-то нового). И вот в одном из своих PR на github я решил использовать полнотекстовый поиск (задание намекало на это) для фильтрации контента, что заставило меня обратиться к документации Django в поисках того, каким же образом лучше это дело реализовать. Думаю, вы знаете большую часть из тех методов, что были там предложены (contains, icontains, trigram_similar). Все они подходят для каких-то конкретных задач, но не слишком хороши в, именно, полнотекстовом поиске. Пролистав чуть ниже, я наткнулся на раздел, в котором говорилось о взаимодействии Django и Pgsql для реализации document-based поиска, что меня привлекло, поскольку в постгре встроен инструмент для реализации этого самого [полнотекстового] поиска. И я решил, что скорее всего, django просто предоставляет API к этому поиску, исходя из чего такое решение должно работать и точнее и быстрее, чем любые другие варианты. Преподаватель мне не слишком поверил, мы с ним поспорили, и он предложил провести исследование на эту тему. И вот я здесь.

Здесь на Хабре много различных инструкций по использованию Django. Эти инструкции часто включают много кода и представляют последовательность шагов, которые нужно сделать, чтобы создать проект.

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

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

Проблема

Мне в ходе разработки часто приходится работать с моделями, в которых должны быть изображения. Для удобной организации я использую древовидную структуру папок. В целом, Django предоставляет инструмент для работы с изображениями. Например, вот вопрос на Хабр Q&A о том, как работать с пикчами в Django: использовать ImageField

class Article(models.Model):
     title = models.CharField(max_length=255)
     content = models.TextField()
     img = models.ImageField(upload_to='/article', height_field=100, width_field=100)

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

Проблема

Всем привет. При разработке API для очередного веб-портала я взял свой привычный стек:

• Django
• django-rest-framework

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

Такой подход позволяет пользователям не заводить несколько учетных записей для каждой роли, что зачастую было бы невозможно, ввиду ограничений на модель: уникальный email или номер телефона.

Итак, опишем возникшие перед нами проблемы:

1. Один пользователь – несколько профилей.
2. Как организовать права каждого из профилей.
3. Доступ к одним тем же ресурсам от разных профилей.

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

Доброго дня!

Меня зовут Соболев Андрей и сегодня мы с вами создадим простую «плюшку» к Django, которая будет проверять, что на фотографии именно лицо человека (что бывает полезно в куче ситуаций).

Для этого нам понадобится OpenCV и 5 минут свободного времени. Поехали.

Django ORM (Object Relational Mapping) является одной из самых мощных особенностей Django. Это позволяет нам взаимодействовать с базой данных, используя код Python, а не SQL.
Based on schegel.net

Для демонстрации опишу такую модель:

from django.db import models

class Blog(models.Model):
    name = models.CharField(max_length=250)
    url = models.URLField()

    def __str__(self):
        return self.name

class Author(models.Model):
    name = models.CharField(max_length=250)

    def __str__(self):
        return self.name

class Post(models.Model):
    title = models.CharField(max_length=250)
    content = models.TextField()
    published = models.BooleanField(default=True)
    blog = models.ForeignKey(Blog, on_delete=models.CASCADE)
    authors = models.ManyToManyField(Author, related_name="posts")

Перевод статьи подготовлен в преддверии старта курса «Web-разработчик на Python».

---

Если в вашем приложении есть какой-то длительный процесс, вы можете обрабатывать его не в стандартном потоке запросов/ответов, а в фоновом режиме.

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

Доброго дня!

Меня зовут Соболев Андрей и сегодня я вам расскажу как мы приготовили .pre-commit hook на нашем проекте.

Вступление

Для начала пару слов, о том что такое в целом хуки (hooks) и для чего они могут быть нужны. Git «из коробки» предоставляет инструмент, который умеет запускать ваши скрипты при наступлении какого-либо события (к примеру пуш на сервер и т.п.)

.pre-commit это удобная надстройка над дефолтным git pre-commit hook, которая запускает скрипты описанные в .pre-commit-config.yaml перед созданием коммита. В теории звучит просто, перейдем к практике.

Вступление

---

Задача — создать пример авторизации пользователя с использованием фреймворков Starlette (https://www.starlette.io/) и Vue.js *, который был бы максимально комфортным разработчикам Django для «миграции» в асинхронный стек.

Почему Starlette? В первую очередь скорость. Starlette ультимативно быстр, и в тестах уступает только BlackSheep (https://pypi.org/project/blacksheep/). Во вторых Starlette весьма прост и писать на нем в силу его продуманности легко и приятно.

В качестве ORM мы будем использовать Tortoise ORM (со моделями и выборками «аля Django ORM»).

В качестве сессионного механизма мы будем использовать JWT.

* Описание фронтенда на Vue.js не входит в данную заметку.

Меня зовут Егор, я Full-stack разработчик в Leader-ID. В этой статье я хочу поделиться простым рецептом по созданию красивого и удобного веб-опросника наподобие тех, что делает Meduza. Он умеет показывать статистику после ответа на отдельные вопросы, подсчитывать общий балл, выдавать комментарии, выгружать данные для анализа и шарить результаты в соцсети. Для реализации этой задачи я выбрал Django, DRF, Python и базу данных PostgreSQL.



Все детали — под катом.

Всем доброго времени суток.

Была задача поднять свой Debian сервер на Nginx для проектов Django 3.х. Перерыв кучу информации в интернете, удалось это сделать соединив рекомендации с нескольких разных сайтов. Если вам интересно почитать, как настроить свой первый сервер для Django-проекта, то — добро пожаловать.

Перевод статьи подготовлен в преддверии старта курса «Web-разработчик на Python».

---

Введение

Сейчас я работаю над очень интересным проектом. И в нем все сложно, потому что сам проект очень масштабный, а я занимаюсь им один в свободное время, при этом работая полный рабочий день. Поэтому я должен быть эффективным. К счастью, я использую Django с его подходом «батарейки в комплекте».

Я использую весь функционал Django, который ускоряет разработку, и я не хотел бы упускать из виду его шаблонизатор. Поэтому бэкенд на Django и фронтенд на JavaScript SPA – это для меня не вариант. Однако даже самый заядлый бэкенд-разработчик должен признать, что некоторые вещи нужно реализовывать на стороне клиента. Незначительные действия пользователя не должны требовать перезагрузки страницы. Помимо этого, некоторые части веб-приложения, которое я создаю, требуют довольно сложного взаимодействия с пользователем.

По традиции, можно было бы смешать Django и jQuery, чтобы получить желаемое поведение. Но сейчас есть более новые технологии JavaScript, такие как React и Vue. Поскольку наша цель состоит в том, чтобы найти фреймворк, который мы сможем использовать вместе с Django не переписывая все с нуля, мы воспользуемся Vue, как более легкой альтернативой. В этой статье я покажу, как начать пользоваться Vue вместе с Django с минимальными усилиями.

Рано или поздно, разработчик на Django встречается с проблемой: как сделать так, чтобы пользователи не могли изменять или удалять, а то и вовсе не видели разные объекты одного и того же типа.

Допустим, ваш проект касается хранения информации о проектах. Разные пользователи входят в разные проекты и не должны видеть информацию о другом проекте. Один и тот же пользователь может входить в несколько проектов и иметь разный статус в разных проектах — где-то он может только просматривать информацию, а в других — править данные. В каком-то проекте пользователь зарегистрирован как персонал проекта, а в другом — только как потребитель его услуг. Уровень доступа соответственно, должен быть совершенно разным.

Этими вопросами занимаются несколько пакетов, мы рассмотрим один из них — Django-Access. Все, кому это интересно, приглашаются под кат.

Антон Патрушев – очень опытный python-разработчик, постоянный член программного комитета PyCon Russia и старый друг конференции. Он работает с языком python уже много лет, начинал свое знакомство с ним в Naumen, теперь является СТО в Spherical, а еще это была именно идея Антона провести PyCon в России.

Мы, организаторы PyCon Russia, поговорили с Антоном на парселтанге, и вот что получилось :)

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

Часть того, о чём тут пойдёт речь, применимо к локализации любых Python-проектов. Разобрав основы, мы поговорим об ускорении работ по интернационализации. В частности — о применении платформы Phrase.



Предполагается, что у читателя этого материала имеется работающее Django-приложение, и то, что у него установлен пакет gettext (установить его можно, например, командой pip install gettext). Если вы раньше не пользовались Django (популярным веб-фреймворком, основанным на Python), то вам, возможно, будет полезно сначала взглянуть на это официальное руководство, а потом вернуться к данной статье.

Предисловие

Nuxt — "фреймворк над фреймворком Vue" или популярная конфигурация Vue-based приложений с использованием лучших практик разработки на Vue. Среди них: организация каталогов приложения; включение и преконфигурация самых популярных инструментов в виде Nuxt модулей; включение Vuex по-умолчанию в любую конфигурацию; готовый и преднастроенный SSR с hot-reloading'ом

Django — самый популярный веб-фреймворк на почти самом популярном языке программирования на сегодняшний день — Python. Сами разработчики позиционируют проект как "Веб-фреймворк для перфекционистов с дедлайнами". Представляет из себя решение "всё в одном" и позволяет в кратчайшие сроки построить MVP вашего веб-приложения.

GraphQL — язык запросов изначально созданный компанией Facebook. В статье будет говориться о конкретных реализациях протокола этого языка, а именно библиотек Apollo для фронтенда и graphene для бэкенда.

О чем и для кого эта статья

Всем привет!

Когда я впервые столкнулся с Flask, у меня сразу возник вопрос по построению архитектуры проекта.

Прочитав пару статей на Хабре (https://habr.com/ru/post/275099/ и https://habr.com/ru/post/421887/), я вспомнил свой опыт создания проектов на Django, и решил сделать инструмент, благодаря которому не придется задумываться об архитектуре, но при этом можно будет использовать все возможности Flask.