Привет! На связи Никита Ильин из Spectr, Backend-разработчик с опытом более 5 лет.
Один из проектов, с которым мы работаем, — IBP-платформа для планирования и прогнозирования спроса и продаж в ритейле. В статье поговорим о конкретной реализации для одной из задач в рамках этой платформы на Python и Django. При этом сама концепция может быть реализована абсолютно на любом фреймворке или платформе: Spring, .NET, Laravel.
Сегодня мы поговорим о магии, но не той, что преподают в Хогвартсе. Речь пойдет о создании волшебника, точнее многошагового мастера форм в Django, который позволяет пользователю шаг за шагом продвигаться к желаемому результату. Эта статья расскажет, как использовать django-formtools для реализации волшебства на вашем сайте.
А причем тут магия? Узнаете чуть позже.
Если вбить фразу «python разработка» в поисковую строку, можно найти огромное количество курсов по данному направлению. Дело в том, что все курсы являются платными и, как правило, имеют ценник в несколько десятков тысяч рублей.
Чтобы разбавить обилие платных курсов, мы подготовили для вас программу обучения «Python-разработчик с нуля», которая состоит только из бесплатных курсов.
Я не буду спрашивать, как вы попали в такую ситуацию. Я в неё как-то попала, значит, и вы тоже могли. Я просто расскажу, как из неё выбраться.
Итак, у вас есть джанго-приложение, апишка к нему, и вы хотите написать автотесты на пайтест, находясь вне этого джанго-приложения. Погнали.
Примерно 5 годами ранее появления FastAPI была обнародована идеология построения легковесных микросервисов на Django, которая стала актуальной только после внедрения асинхронности в этом фреймворке.
Хотя в последней (на момент написания статьи) версии Django 5.0.5 асинхронно решается только часть задач, но уже сейчас можно начать создавать асинхронные микросервисы воспользовавшись технологией µDjango.
В этой статье поговорим о существующих подходах к рендерингу веб-форм в Django.
Обсудим подходы с использованием стандартных средств Django, а также применим сторонние средства для продвинутого управления рендерингом форм на примере пакета django-crispy-forms и фронтенд библиотеки bootstrap 5.
Привет, Habr!
В этой статье мы научимся использовать Markdown вместе с Django на примере блога. Она написана для новичков, для базового ознакомления. Её в формате .md можно скачать в моём развивающемся Telegram канале.
Markdown — это простой язык разметки, используемый для создания форматированного текста (например, HTML) с помощью текстового редактора. Кстати, эту статью я писал, использую синтаксис Markdown)
Всем здравия! Сегодня будет рассмотрена авторизация с помощью сессий между Django и React, которые находятся на разных доменах, т.е случай "cross-origin". Я в двух словах донесу принцип работы, причины появления концепций и технологий описанных здесь, оставлю ссылки на более подробные источники и приведу код конкретной реализации с объяснением своих шагов. Кого интересует полный код, он находится на GitHub.
Привет, Хабр!
Мульти-тенант (multi-tenancy) — это подход, который позволяет одному экземпляру приложения обслуживать множество клиентов или арендаторов (тенатов). Каждый арендатор изолирован от других, имея возможность кастомизации под свои нужды, при этом основной кодовой базой и инфраструктурой делится между всеми.
Когда применять эту замечательную концепцию? Если говорить простыми словами, то мульти-тенант подход наиболее ценен для SaaS-продуктов, когда одно и то же приложение предоставляется разным клиентам, и каждый клиент работает со своим набором данных. Все это серьезно экономит ресурсы на обслуживание инфраструктуры, тк все изменения вносятся централизованно и мгновенно становятся доступны всем клиентам.
В Django мульти-тенант реализовывается довольно часто и для этого есть библиотека django-multitenant.
Итак, что же поменялось за чуточку больше чем полгода? Если мы будем говорить об актуальности - ничего. Django до сих пор, а скорее всего так будет и всегда, остается "на плаву". Большая часть вакансий для back-end разработчика на Python имеет в себе требования по знаниям Django. Говорить вечно о том, что он удобен, постоянно поддерживаем, дает довольно обширный функционал и так далее - бессмысленно. Все основные моменты я упомянул в первой части.
Ладно, вступление в сторону! Лучше обсудить то, что изменилось с Django за это время.
Самое грандиозное из этого - выход Django 5! По сути скачок на пятую версию не принес в фреймворк особо крупных изменений, но парочку моментов хочу подчеркнуть. Первое и самое важное, на мой взгляд, это то, что разработчики решили добавить больше асинхронности без подключения таск-менеджеров. Для этого они добавили несколько декораторов и методов. Хотя это немного, на мой взгляд, противоречит самому принципу работы Django (напоминаю: Django синхронный фреймворк и для того, чтобы сделать очередь задач, нужно подключать таск-менеджеры, например, Celery), но тем не менее, это все равно крутой шаг в эволюцию. Надеюсь, что разработчики и дальше будут двигаться в этом направлении.
Далее, не могу не упомянуть очень важный момент - совместимость с Python. Django 5 будет работать только с версиями Python 3.10 и выше. Django 4.2.x - последняя версия, которая работает с Python 3.8 и 3.9.
Остальное я могу отнести в одну кучу: добавление фасетных фильтров в админке, упрощение шаблонов для отрисовки полей формы, прикольная, на мой взгляд, функция для значений по умолчанию, вычисленных базой данных, и еще пару приколюх с БД. Все остальное и более подробно вы сможете почитать в официальной документации. Я же не буду все разжевывать, так как отойду от темы статьи.
Привет, Хабр!
В Джанге существует множество глубоко укоренившиеся привычек, которые кажутся правильными на первый взгляд, но в долгосрочной перспективе приводят к серьезным проблемам в производительности, масштабируемости и безопасности проекта. Эти решения могут казаться удобными костылями или временными фиксами, но на самом деле они создают технический долг, который со временем будет только расти, усложняя все с каждым разом.
Умение избегать этих привычек – это основополагающие элементы компетентности, гарантирующие, что проекты будут не только удобными для пользователя, но и устойчивыми к проблемам.
Рано или поздно любой сервис задумывается о расширении аудитории. И часто возникает вопрос языков, т.к. единого для всех стран не существует. В целом, это довольно стандартная задача для разработчиков, когда компания начинает работать на международную аудиторию. В случае с Django, который славится универсальностью, есть стандартное решение, но действительно ли оно хорошее, как можно его улучшить и с чем вообще придётся столкнуться во время процесса — обо всём этом расскажу. Меня зовут Камиль, я более трех лет был техническим директором и главным backend-программистом продукта Zonesmart, а с начала 2023 года продолжаю управлять разработкой этого продукта уже в составе Kokoc Group.
Всем привет!
Продолжаю публиковать странные и непонятные статьи.
Но вдруг, кому-то пригодится.
Поехали...
Хочется поговорить о времени, как о состоянии системы.
Но для начала нужна вводная: первая из них — временнАя переменная. С чего стартуем? Стартуем с дебага, как и я когда-то. Сидишь, трейсишь программу, и в дебаге у тебя есть несколько инструментов для похода по исходному коду: какой-нибудь step over, step into, run to cursor, step next. Ну, вроде все есть, но как бы: а где step back? Вы никогда не пролетали в отладке мимо того, что отлаживаете? И сколько раз приходилось перезапускать отладку? Может, я один такой… несчастливый?
Как раз, проблема в том, что обратные операции неочевидны. Процессоры, (может я и неправ, это просто гипотеза), не могут работать в обратном направлении по исходному коду. Операция степени в обратном направлении - это извлечение корня, например. Возможно, поэтому у нас нет такого очевидного и удобного, лично для меня, инструмента - как вернуться на строку назад от текущей…
Что может помочь? Например, какие-нибудь инструменты логирования. Мы берем область памяти, которая выделена для хранения значения переменной, и записываем в “блокнот”, что там происходит. В этом такте одно значение, в следующем другое… Мы формируем логи, так сказать.
Когда мы объявляем переменную, она будет “работать” с момента объявления до момента окончания работы исходного кода (выхода из подпрограммы или удаления этой переменной). Ее значение в процессе может быть многократно изменено без возможности восстановления. Обычно нас это устраивает, и значения в дебаге нас интересуют только в текущий момент. Обычно это говорит о том, что значение “вечно”, оно было таким всегда, даже если один такт назад это было не так.
Когда-то давно я уже делал авторизацию в Django и думал, что знаю о ней всё, но то была ошибка и оказалось, что я вообще ничего не знал и пользовался готовыми инструментами Django из коробки.
Когда я начал писать авторизацию для своего сайта, я столкнулся с тем, что в интернете есть информация и по JWT токену и по самой реализации авторизации, однако все реализации, найденные мною были нагромождены ненужным кодом, который мало относится к основной идее, либо одна из частей реализации будь то BackEnd или FrontEnd были плохо раскрыты. Поэтому я решил написать эту статью.
Подробное описание шагов при деплое web-проекта на Django с PostgreSQL, Nginx, Gunicorn.
Задачи статьи - агрегировать информацию из мануалов по деплою, избавить читателя от повторений ошибок и описать теоретически, для чего делаются те или иные шаги, чтобы избежать бездумного копирования и вопросов "почему у меня не работает".
Всем привет! Это вторая статья из цикла статей о разработке приложений в нашей компании. В первой статье я рассказал Вам про общую архитектуру некоторых наших проектов. В данной статье хочется описать наши варианты решения часто встречающихся задач в рамках Django + Vue приложения.
В этой статье исследую технологию SSO. Начинаю с разбора концепций аутентификации и авторизации. Рассматриваю как они работаю в контексте Django.
После прохожу путь от описания как работает SSO простыми словами, до разбора протоколов используемых в SSO.
В итоге делаю реализацию SSO с Django, объединять Django и Keycloak.
В прошлом году TestRail прекратил предоставлять и продлевать лицензии компаниям из России, поэтому мы в YADRO решили разработать собственную тест-менеджмент систему TestY. Опирались на опыт работы с другими сервисами, чтобы добавить тот функционал, которого не хватало нашим командам тестирования. За несколько месяцев написали core-часть системы и выложили ее в open source, чтобы другие компании и разработчики, для которых актуален вопрос лицензионной чистоты используемого софтай, пользовались решением и развивали его.
В этой статье рассказываем об отличиях TestY от других TMS и преимуществах нашей системы для команд любого размера. Спойлер: в TestY могут одновременно работать 300 тестировщиков — система справляется. Для тех, кто хочет опробовать TestY в своей команде, в конце статьи есть короткая инструкция, как ее развернуть.
Все мы знаем что такое клиент-серверное приложение, на тему их создания написано не мало статей. В этой статье хотелось бы поделиться с вами наработками нашей компании, которыми мы пользуемся в своих Django проектах.
