Django *

Григория Петрова, Python-некроманта, совмещающего деятельность директора по техническому маркетингу (по-простому — деврела)  компании Evrone и члена программного комитета Moscow Python Conf знают уже не только питонисты.

Время от времени Григорий возглавляет Программный комитет конференции Python, меняя Валентина Домбровского, нынешнего главу ПК. Так было заведено много лет назад, чтобы каждый председатель не закостенел в организации конференции, выборе докладов и генерации идей.

Мы встретились с Григорием и узнали много интересного. Про трех китов предстоящей конференции Moscow Python Conf++ 2021. Про нейрофизиологию, которая всегда поможет. Про что будет хайп и зачем организаторам нужна фасилитация. Разумеется, мы поговорили про Python (спойлер: асинхронное программирование и Django тоже будут). Узнали, какие нас ждут доклады и какие боли питонистов будут утолены —  обо всем этом читайте под катом.

Многие проекты на Django начинаются просто: есть база данных и к приложению, которое крутится на сервере, идут обращения. Например, так начиналась Dodo IS (информационная система компании Додо Пицца, где работал автор сегодняшней статьи). Но если использовать Django из коробки, можно натворить много бед и встретить пачку антипаттернов. Возможно, вы встречали такое на старых legacy-проектах.

Евгений Пешков развивает сообщество DDD-практиков, рассказывая, какие проблемы решает Domain-Driven Design (предметно-ориентированное проектирование) в современном мире. На конференции Russian Python Week 2020 он выступил с рассказом об этом. Кстати, 19 августа пройдет встреча DDDevotion-сообщества, присоединяйтесь, будем о чем поговорить.

В сегодняшней статье будет его рассказ про то, как устроен Domain-Driven Design и какие инструменты использует, чтобы наиболее точно описать требования бизнеса и сам бизнес.

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

Вы сейчас закономерно заметите: “А чего ж ты сразу не сделал автодеплой? Там же все просто!”. 

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

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

Каков логичный первый шаг, если хочется сделать быстрее и не погружаться в литературу очень глубоко? 

Здравствуйте, дорогие читатели хабра и хаба про django. Да, эта статья о фреймворке для перфекционистов с дедлайнами и о том, как в нём не хватает асинхронности. По духу это больше похоже на Enhancement Proposal (менее формальный, чем он мог быть) или RFC, так что, если Вы любите подобные вещи, то Вам может быть интересно.

Вопросом добавления асинхронности сама Django Foundation тоже интересовалась. Дискуссии вылились в DEP-09, который описывает текущий примерный roadmap. Я даже неожиданно обнаружил, что мой этот пост ему не противоречит. Просто о нативной поддержке асинхронности там не очень много и написано. Это считается там последним этапом, до которого ещё нужно дойти. Напоминает мем про то, как рисовать сову: вначале рисуем два круга, потом дорисовываем остальное.

Но давайте, всё-таки, попробуем сделать django асинхронным. Точнее, django orm. Забыл сказать: я считаю django orm главным препятствием на пути django к асинхроннности. Это, как-никак, наибольшая по объёму часть. Потом, именно orm содержит тот набор допущений и характерных черт, которые делают django узнаваемым, как минимум.

Значит, orm. Драйвера базы данных нужны асинхронные, но такие, конечно, уже есть.

$ yappa deploy

Все. 

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

8-й по счету PyCon Russia пройдет 5-6 сентября в Клязьма Резорт. Как всегда, встречаемся старой и новой тусовкой питонистов, отдыхаем на природе, поем песни под гитару и пиво, слушаем, какие проекты и как пилят в разных компаниях, и прокачиваемся на мастер-классах.

В этом году программу разделили на 2 тематики: разработка на python и ML& Data Science. 

Смотрите, чем живет и куда двигается python-сообщество.

Небольшой тутор о том, как передать данные из бэка на django на vue и как с помощью django сёрвить этот самый vue.

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

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

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

Важный момент: мы говорим о работе сериалайзера только на чтение, то есть когда он отдаёт пользователю информацию из базы данных (БД) сайта. О работе на запись, когда данные поступают извне и их надо сохранить в БД, расскажем в следующей статье.

Код учебного проекта, который используется в этой статье, доступен в репозитории на Гитхабе.

Меня зовут Стас Гаранжа, я выпускник курса «Python-разработчик» в Яндекс.Практикуме. Я хочу помочь начинающим разработчикам, которые приступили к изучению Django Rest Framework (DRF) и хотят разобраться, как устроен этот фреймворк.

Я готовлю цикл статей, в которых расскажу о разных сторонах работы DRF. У меня пока нет значимого практического опыта для описания всех изюминок при работе с этим фреймворком, поэтому в основе статьи — исследование, обобщение и по возможности непротиворечивое изложение того, что у DRF под капотом.

В этой статье разберёмся, как сделать REST API на базе Django Rest Framework, чтобы получить по GET-запросу набор записей из базы данных (БД). Иными словами, рассмотрим, как DRF работает на чтение (о том, как с помощью него создавать, изменять и удалять записи в БД, поговорим в отдельной статье).

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

При работе над django-проектом, есть ряд must-have сторонних библиотек, если не хочется бесконечно изобретать велосипед. Средстав отладки sql запросов(debug-toolbar, silk, --print-sql из django-extensions), что-нибудь для хранения древовидных структур, переодических/отложенных задач(кстати, cron-like интерфейс есть у uswgi. EAV всё ещё бывает нужен, хотя часто его можно заменить jsonfield. И одна из таких крайне полезных вещей, но почему-то реже обсуждаемая в сети - FSM. Не так часто почему-то сталкиваюсь с ними в чужом коде.

<cut>

Практически у каждой записи в БД есть некоторое состояние. Например, для комментария это может быть - опубликован/удален/удален модератором. Для заказа в магазине - оформлен/оплачен/доставлен/возврат и т.п. Причем переход из одного состояния в другое часто бывает размазан по коду и в нем присутствует бизнес-логика, которую надо обильно покрывать тестами(всё равно придется, но можно избежать тестирования элементарных вещей, например, что заказ может перейти в состояние "возврат денег" только после того, как он побывал в состоянии "оплачен".

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

Вот пример кода из тестов библиотеки django-fsm

Пролог

- Глянь, статью на Хабр подготовил.
- Эм... а почему заголовок на английском?
- "Предметно-ориентированное проектирование, Гексагональная архитектура портов и адаптеров, Внедрение зависимостей и Пайто..."

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

--

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

Моя попытка организации системы управления продуктами на сайте c PrestaShop

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

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

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

За описанием процесса создания такой менеджмент системы приглашаю под кат.

Меня зовут Алексей Казаков, я техлид команды «Клиентские коммуникации» в ДомКлик. В большинстве приложений, с которыми мне приходилось иметь дело, при взаимодействии с БД не ограничиваются лишь драйвером, который позволяет выполнять сырые запросы. Для удобства и избавления от SQL-запросов внутри, например, Python-кода дополнительно используют библиотеки (Object Relational Mapper, ORM).

Это первая статья в серии, посвященной различным ORM. Начнём мы с DjangoORM.

После того, как мы закончили разработку веб-приложения, оно должно быть размещено на хосте, чтобы общественность могла получить доступ к нему из любого места. Мы посмотрим, как развернуть и разместить приложение на экземпляре AWS EC2, используя Nginx в качестве веб-сервера и Gunicorn в качестве WSGI.

Для написания данной статьи был изучен очень большой пласт материала, разбросанного по всему Интернету, по форумам, чатам, сайтам-блогам, stackoverflow. Я собрал все воедино, так как это пригодится и мне и очень надеюсь, что другие разработчики на Django, также, останутся довольны данным материалом. Если есть что добавить (улучшить) или поправить, пожалуйста, пишите в комментариях или в Диалоги ( личные сообщения ) Хабр.

Мы рассмотрим: "Тестирование handler 404" в окружении разработчика, "Формсеты и динамическое добавление форм", а также "Экспорт данных в PDF с поддержкой кириллицы (русских символов / букв)".

Значительная часть моих ежедневных действий на компьютере и смартфоне выполняется с помощью приложений Microsoft. Отправить электронную почту, создать заметку в календаре, просмотреть файлы в облачном хранилище, обменяться сообщениям в рабочих группах — все эти операции так или иначе выполняются приложениями Microsoft. Нравится мне это или нет, все мои данные хранятся в Microsoft Cloud. У Microsoft имеется полезный инструмент — API-интерфейс, предоставляющий доступ к большей части таких данных и позволяющий управлять ими, так почему бы им не воспользоваться для получения полезной информации?

В этой статье представлено полное руководство по созданию собственного приложения Dashboard с использованием API Microsoft Graph и Django для анализа данных платформ OneDrive, Outlook и др.

Если мы хотим передать данные из Django в JavaScript, мы обычно говорим об API, сериализаторах, вызовах JSON и AJAX. Обычно дело усложняется наличием React или Angular на фронте.

Но иногда вам нужно сделать что-то быстро и грязное – построить диаграмму и не задумываться над инфраструктурой одностраничного приложения.