Django *

Небольшой тутор о том, как передать данные из бэка на 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 на фронте.

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

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

Для написания этой статьи ушло очень много сил и времени. Я натыкался на множество инструкций, как на английском, так и на русском языках, но как я понял, - они все были клонами оригинальной статьи на Digital Ocean. Спросите вы, почему я так считаю, а все потому, что все ошибки и неточности передаются с одного ресурса на другой без всяких изменений.

Сегодня я собираюсь обсудить абсолютно новую для многих пользователей (особенно для питонистов) идею: интеграцию тестов в ваше приложение.

Итак, давайте начнем.

Михаил Корнеев
BestDoctor, создатель и автор канала «Хитрый питон» на You Tube

«Как и любой растущий проект, мы столкнулись с несколькими проблемами:
— кода становится больше, он становится сложнее
— команда растет, приходят люди с разным опытом и привычками
— многие проблемы регулярно всплывают на код-ревью
Эти проблемы нельзя решить мгновенно и решить полностью, но за несколько лет в команде выработался хороший подход — если мы регулярно сталкиваемся с проблемой и ее проверку можно автоматизировать — нужно это сделать.
Подход не новый и кажущийся очевидным, но у многих команд просто не хватает времени, чтобы начать его внедрять. Я расскажу о том, как проверки устроены у нас, как начать внедрять с минимумом затрат и как сделать это частью процесса разработки»

Пару недель назад Django 3.2 выпустил свой первый альфа-релиз, а финальный релиз выйдет в апреле. Он содержит микс новых возможностей, о которых вы можете прочитать в примечаниях к релизу. Эта статья посвящена изменениям в тестировании, некоторые из которых можно получить на более ранних версиях Django с пакетами backport.

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