В этой статье поговорим о существующих подходах к рендерингу веб-форм в 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? Вы никогда не пролетали в отладке мимо того, что отлаживаете? И сколько раз приходилось перезапускать отладку? Может, я один такой… несчастливый?
Как раз, проблема в том, что обратные операции неочевидны. Процессоры, (может я и неправ, это просто гипотеза), не могут работать в обратном направлении по исходному коду. Операция степени в обратном направлении - это извлечение корня, например. Возможно, поэтому у нас нет такого очевидного и удобного, лично для меня, инструмента - как вернуться на строку назад от текущей…
Что может помочь? Например, какие-нибудь инструменты логирования. Мы берем область памяти, которая выделена для хранения значения переменной, и записываем в “блокнот”, что там происходит. В этом такте одно значение, в следующем другое… Мы формируем логи, так сказать.
Когда мы объявляем переменную, она будет “работать” с момента объявления до момента окончания работы исходного кода (выхода из подпрограммы или удаления этой переменной). Ее значение в процессе может быть многократно изменено без возможности восстановления. Обычно нас это устраивает, и значения в дебаге нас интересуют только в текущий момент. Обычно это говорит о том, что значение “вечно”, оно было таким всегда, даже если один такт назад это было не так.
Всем привет!
Продолжаю публиковать странные и непонятные статьи.
Но вдруг, кому-то пригодится.
Поехали...
Хочется поговорить о времени, как о состоянии системы.
Но для начала нужна вводная: первая из них — временнАя переменная. С чего стартуем? Стартуем с дебага, как и я когда-то. Сидишь, трейсишь программу, и в дебаге у тебя есть несколько инструментов для похода по исходному коду: какой-нибудь 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 проектах.
Я закончил курсы "Fullstack разработчик на Python" от одной известной компании. Обучение завершено успешно, но не было ощущения полноценности — на курсах не учили, как сделать самостоятельно деплой приложения на Django. И никто из студентов не задавался эти вопросом 😁
Так что я решил закрыть этот вопрос и все-таки пройти путь по развертыванию django-приложения, так как, возможно, больше никогда такого случая не представится. Потом я уже могу не вернуться к этой теме, так как это потребует мучительного вспоминания и повторного прохождения материала. Все должно быть вовремя.
В этой статье я хочу дать небольшой гайд для выпускников подобных курсов и заодно рассказать про российский облачный сервис (еще раз внимательно прочитал их статью и увидел, что она опубликована буквально за 3 недели до моих тестов - то есть мне повезло).
Сегодня у нас вышел второй официальный пост о прогрессе в разработке уже на самом сайте
Продолжу рассказывать о развитии Капибары, опенсорсном проекте, цели которого воспроизвести лучшее что было на пикабу и не наступить на их же "грабли". Первая часть здесь: https://habr.com/ru/articles/759598/. Вторая часть здесь: https://habr.com/ru/articles/773234/
🌟 Сегодня у нас в арсенале кое-что интересное. 🌟
Новый редактор
Привет! Меня зовут Александр Кулагин. Я не занимался разработкой профессионально, но заинтересовался созданием нейросетей. После изучения основ Python, NumPy и TensorFlow я захотел попрактиковаться на реальных задачах. Так я решил создать проект, который оценивает, какие компании потенциально заинтересованы в сотрудничестве с конкретным бизнесом.
В этой статье я расскажу о процессе создания проекта: от поиска заказчика и сбора данных до финального этапа — создания веб-интерфейса. Проект претерпевал много изменений, потому что реальность вносила коррективы: иногда у меня не хватало знаний, иногда изначальное решение просто нельзя было применить.
В этой статье поговорим о том, что такое кэширование и о его преимуществах, как настроить кэширование в Django, какие бэкенд-системы поддерживают Django, а также о лучших практиках кэширования. Материал будет полезен в первую очередь начинающим веб-разработчикам.
