Django *

Тесты написаны, тимлид рад, а что дальше-то делать? А дальше - автоматизация и отправка отчёта по тестам. Именно об этом мы и поговорим в данной статье, попутно затронув полезный инструмент TestExplorer и декоратор tag.

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

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

Здравствуйте!

Хочу представить вам пошаговую инструкцию по деплою django проекта.

Сразу скажу, что используя мою краткую инструкцию вы не поймете механику развертывания. По сути, это просто список команд для деплоя. Тут не будет никаких подробностей касательно работы UWSGI, NGINX и самого Django. Я просто помогу быстро добраться до цели, а цель у нас одна - задеплоить уже наконец этот **** проект!

В предыдущих статьях мы подробно разобрали работу сериалайзера на основе классов BaseSerializer и Serializer, и теперь мы можем перейти к классу-наследнику ModelSerializer.

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

• автоматическое создание полей сериалайзера на основе данных о корреспондирующих полях модели;
• автоматическое включение в поля сериалайзера тех же валидаторов, которые есть в полях модели, а также при определённых условиях метавалидаторов;
• заранее определённые методы create и update.

Общие принципы работы модельного сериалайзера как на чтение, так и на запись идентичны тому, как работает базовый класс Serializer.

В современных веб-приложениях большинство запросов к базе данных пишется не на сыром SQL, а с использованием объектно-реляционного отображения (ORM). Оно автоматически генерирует SQL-запросы по привычному объектно-ориентированному коду. Однако эти запросы не всегда оптимальны,  и с  ростом нагрузки на веб-приложение встает вопрос их оптимизации. Как раз в ходе такой оптимизации наша команда обнаружила, что документация Django с нами не совсем честна.

Всем доброго времени суток!

В данной статье я хотел бы очень кратенько, без подробностей рассказать про интересный проект, который будучи достаточно простым, сильно увеличивает возможности Django фреймворка. Мне он показался достаточно интересным.

Сейчас хайп вокруг современных javascript SPA фронтенд фреймворков особенно горяч, и во многом эта популярность вполне заслужена, эти технологии позволяют успешно выполнять практически любую задачу. Скорость SPA приложения может быть сравнима с десктоп приложениями, это достигается за счет перенаправления большей части ответственности с сервера на клиента. К сожалению, этот новый подход порождает все более сложные технологии, а работа разработчика, которая когда то была увлекательна и продуктивна стала значительно сложнее и монотоннее. Возможны ли альтернативы современным SPA фреймворкам? Возможно ли создавать полноценные reactive user interfaces быстро, просто и только на джанго? Далее хочу обратить Ваше внимание на интересный проект который может дать ответы на эти вопросы.

Всем привет! Меня зовут Дмитрий Чернышов, я руководитель группы разработки системы «БАРС.Бюджет-Бухгалтерия». Сегодня я поделюсь своим опытом создания обучающего курса для разработчиков.

Недавно я проходил очередное интервью, и меня спросили, пишу ли я на flask, на что я ответил, что я себя люблю, и поэтому пишу на django. Меня не взяли, потому что, кхм, у них, оказывается, много чего было на фласке, и вышло неловко. Да-да, я знаю, фласк крут, потому что он простой, всё что надо ставишь сам, а чего не надо там и так нет, но как по мне, всё равно потом получается django.

И тут, наверно, покажется, что я я свидетель Джанго, хожу по домам, стучу в двери и рассказываю, как круто на нём кодить, но вообще-то нет - Джанго тоже не без проблем... Вот об этом я и хочу поговорить.

Продолжаем цикл статей, посвящённый основам Django Rest Framework. В предыдущей статье мы подробно рассмотрели, как сериалайзер валидирует входные данные.

В этой статье мы закрепим теорию на простом примере, а также затронем те вопросы, которые не успели рассмотреть раньше:

• какое поле сериалайзера выбрать для ForeignKey-поля модели;
• как сериалайзер работает с датами;
• как устроен метод save сериалайзера.

А ещё мы напишем контроллер, который будет обрабатывать запросы к API на создание записи в БД.

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

Поддерживаемые регулярные функции:

Всем привет! Меня зовут Аникин Денис, я тимлид в команде Chat в Райффайзенбанке. А также представитель внутреннего Python-сообщества, так называемый «community lead» (об этом как-нибудь в другой раз). В этой статье я хотел поговорить про отношение к Python среди разработчиков и обсудить все основные претензии, которые очень давно следуют за языком по пятам.

Всем привет! Меня зовут Евгений Степанов, и я 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.