Всем привет! Меня зовут Евгений Степанов, и я Python Full Stack-Developer в компании PVS-Studio. В этой статье вы узнаете, что нужно сделать, чтобы за полгода стать Python backend-разработчиком. После прочтения данной публикации у вас будет чёткий план, который останется только реализовать. Поехали!
Очень абстрактное описание, что такое Wagtail CMS и почему с ней стоит познакомиться разработчикам на Django. Вкратце, Wagtail позволяет в кратчайшие сроки сделать сложные проекты, CMS активно развивается, ее поддерживают настоящие профи.
В результате выборов, которые завершились 19 сентября был сформирован большой массив данных, которые могут рассказать исследователям интресные истории. В статье представлен проект и прототип веб приложения для анализа и визуализации данных выборов в Государственную Думу 2021. В проекте используется фреймворк Django и набор библиотек : Pandas, Matplotlib.
Итак, у нас есть идея потрясающей и всем необходимой батарейки для Django. После того, как мы написали весь код мы готовы релизнуть нашу батарейку в PyPI. Однако перед этим мы должны разобраться с несколькими моментами.
Django - отличный фреймворк, но он, на самом деле, толком не дает, да и не должен давать, ответ на вопрос, каким образом лучше всего хранить вашу бизнес-логику. Хранение бизнес-логики в моделях или views имеет множество недостатков, которые обычно начинают проявляться при росте кодовой базы проекта. Чтобы решить эти проблемы, разработчики часто начинают искать способы выделения бизнес-логики в своем приложении.
В этой статье я хотел бы попробовать дать стартовую точку на пути выделения слоя бизнес-логики у себя в приложениях и навести на новые мысли тех разработчиков, которые считают выделение этого слоя в своих приложениях чем-то излишним.
Так же хочу обратить внимание, что цель данной статьи не в том, чтобы дать правила, которым требуется слепо следовать, но в том, чтобы указать направление. Сервисный слой и в принципе его наличие, это такая вещь, которую нужно адаптировать под нужды вашей команды, компании и бизнеса.
На самом деле, изложенный далее текст относится не только к Django-проектам. Разрабатывая веб-приложения, используя другие инструменты, вроде Flask, люди используют те же концепции веб-разработки, причём часто именно в таком же виде, как они реализованы, в Django - views, request-response объекты, middlewares, модели, формы.
Если вы хотите открыть собственный интернет-магазин, достаточно пойти в Google, и вы получите несколько десятков готовых технических решений. При этом не имеет значения, что вы планируете продавать. Рынок предлагает массу продуктов для создания интернет-магазина или маркетплейса «под ключ».
Продуктов среди готовых предложений для желающих открыть собственную торговую интернет-площадку действительно много. Но когда ты хочешь открыть маркетплейс (рынок в интернете, где много продавцов и покупателей), оказывается, что любой готовый продукт надо дописывать еще минимум полгода, чтобы он закрыл хотя бы часть твоих потребностей.
Переделывать за кем-то гораздо сложнее, чем создавать с нуля. А когда продукт написан своими руками под конкретные задачи, то он получается максимально производительным и гибким. Поэтому когда я задумался об открытии первого строительного маркетплейса (не путать с интернет-магазином!), я решил пойти своим путем, и писать начинку для него с нуля самостоятельно, чтобы сразу делать все, как нужно мне и не зависеть от сторонних программистов.
Я хотел создать экосистему и объединить на своей площадке уже существующие на рынке продукты: 3PL-логистику, банкинг и систему ЭДО. При этом я видел маркетплейс максимально простым, то есть не перегруженным лишним функционалом. Вот основные задачи, которые я ставил перед разработчиками.
Бесплатная, с открытым исходным кодом библиотека DjangoAdminGeomap предназначена для отображения объектов на карте в админке Django.
Существует полноценный многофункциональный ГИС фреймворк GeoDjango. При его использовании в админке Django можно отображать объекты на карте. Однако GeoDjango имеет большой список зависимостей от различных библиотек и особенности установки этих библиотек на различных платформах.
Если вам требуется только отображение объектов на карте в админке Django, то можно использовать библиотеку DjangoAdminGeomap. У нее нет дополнительных требований к именам и типам данных полей в таблицах базы данных и отсутствуют зависимости при установке.
Для отображения картографических данных DjangoAdminGeomap использует JavaScript фреймворк OpenLayers. Источником картографических данных являются данные проекта OpenStreetMap.
В предыдущей статье я писал веб-приложение и совершенно бездумно реализовал там авторизацию, построенную на JWT. В этой статье я хотел бы устроить небольшое погружение в технические детали того, как это устроено, перебрать разные альтернативы.
Достаточно несложно в React нарисовать форму, где можно позволить пользователям вводить свои учетные данные, включающие в себя логин и пароль. Не стоит практически никаких усилий, чтобы на 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 окружения), я решился на автоматизацию.
Каков логичный первый шаг, если хочется сделать быстрее и не погружаться в литературу очень глубоко?
$ 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
