Собрали в одном месте самые важные ссылкии сделали Тренажер IT-инцидентов для DevOps/SRE
У Яндекса много самописных сервисов для внутренних задач: Яндекс.Формы, Яндекс.Диск, трекер, календарь. Со временем их решили использовать не только внутри компании, но и за ее пределами. Так появилась платформа Яндекс.Коннект.
Большинство сервисов Коннекта построено на Python V3. В качестве web-фреймворка используется Django, реже Flask и Tornado, а новые чаще пишутся на FastAPI. Сервисы, как и базы PostgreSQL, MySQL и MongoDB, живут в облаке. В качестве очереди сообщений почти везде используется Celery с MongoDB в качестве брокера. Он и стал проблемой.
Многие проекты на Django начинаются просто: есть база данных и к приложению, которое крутится на сервере, идут обращения. Например, так начиналась Dodo IS (информационная система компании Додо Пицца, где работал автор сегодняшней статьи). Но если использовать Django из коробки, можно натворить много бед и встретить пачку антипаттернов. Возможно, вы встречали такое на старых legacy-проектах.
Да, эта статья о фреймворке для перфекционистов с дедлайнами и о том, как в нём не хватает асинхронности. По духу это больше похоже на Enhancement Proposal (менее формальный, чем он мог быть) или RFC, так что, если Вы любите подобные вещи, то Вам может быть интересно.
В этой статье приведен полный список команд утилиты django-admin с кратким описанием.
Для новичка, который осваивает Django, представления на основе классов больше похожи на магию чёрного ящика, по крайней мере, у меня при первом знакомстве сложилось именно такое впечатление. Обильные руководства зачастую показывают, какие атрибуты и методы следует определить в вашем классе, чтобы этот ящик работал на вас, но не дают понимания принципа работы.Я хочу залезть под капот фреймворка и строчка за строчкой разобрать, как же работают представления на основе классов. Надеюсь, что по прочтении, Class-based views уже не будут казаться такими пугающими и я подстегну вас к дальнейшему самостоятельному изучению исходников. Возможно, вы думали о фреймворке как о некой магии, которую невозможно понять, но на самом деле это обычный код, написанный опытными разработчиками.
Продолжаем изучать Django Rest Framework с точки зрения новичка. Мы уже разобрали создание REST API для получения данных из БД, включая отдельную статью о работе сериалайзера. В этой статье расскажу, как с помощью сериалайзера проверить поступившие данные для записи в БД. Валидация в DRF состоит из множества этапов с массой нюансов. Если при чтении покажется, что деталей очень много и картинка в голове начинает плыть, в конце статьи есть обобщающая таблица с кратким описанием последовательности всех проверок.
Для асинхронного Python существует мало полноценных ORM, и им далеко до таких монстров-комбайнов, как DjangoOrm и SQLAlchemy.ORM. Бедность ORM-инструментария для асинхронного программирования заставила многих программистов отказаться от зачастую непонятной им работы с ORM и перейти к более прозрачному взаимодействию с БД. Решение в лоб — написание raw SQL, но в этом случае запросы не будут защищены от инъекций, а запросы, составляемые по бизнес логике с опциональными параметрами, превратятся в конкатенацию строк. Важно найти баланс между прозрачностью выполнения кода, скоростью его написания и читаемостью.
Перевод: Špela Giacomelli (aka GirlLovesToCode) — Permissions in Django Rest Framework В этой статье рассматриваются особенности использования разрешений has_permission
При работе над django-проектом, есть ряд must-have сторонних библиотек, если не хочется бесконечно изобретать велосипед. Средстав отладки sql запросов(debug-toolbar, silk, --print-sql из django-extensions), что-нибудь для хранения древовидных структур, переодических/отложенных задач(кстати, cron-like интерфейс есть у uswgi. EAV всё ещё бывает нужен, хотя часто его можно заменить jsonfield. И одна из таких крайне полезных вещей, но почему-то реже обсуждаемая в сети - FSM. Не так часто почему-то сталкиваюсь с ними в чужом коде.
Иногда приходятся сталкиваться с задачей хранения JSON данных в моделях Django.
Меня зовут Алексей Казаков, я техлид команды «Клиентские коммуникации» в ДомКлик. В большинстве приложений, с которыми мне приходилось иметь дело, при взаимодействии с БД не ограничиваются лишь драйвером, который позволяет выполнять сырые запросы. Для удобства и избавления от SQL-запросов внутри, например, Python-кода дополнительно используют библиотеки (Object Relational Mapper, ORM).Это первая статья в серии, посвященной различным ORM. Начнём мы с DjangoORM.
Значительная часть моих ежедневных действий на компьютере и смартфоне выполняется с помощью приложений Microsoft. Отправить электронную почту, создать заметку в календаре, просмотреть файлы в облачном хранилище, обменяться сообщениям в рабочих группах — все эти операции так или иначе выполняются приложениями Microsoft. Нравится мне это или нет, все мои данные хранятся в Microsoft Cloud. У Microsoft имеется полезный инструмент — API-интерфейс, предоставляющий доступ к большей части таких данных и позволяющий управлять ими, так почему бы им не воспользоваться для получения полезной информации?
В этой статье представлено полное руководство по созданию собственного приложения Dashboard с использованием API Microsoft Graph и Django для анализа данных платформ OneDrive, Outlook и др.
На Хабре очень много статей о том, как создать простейшего Телеграм бота с кнопками меню и логикой, есть инструкции, как это все задеплоить. В этой статье я расскажу, как делать ботов для продакшена, которыми смогут пользоваться сотни тысяч пользователей.
Django — это фантастический фреймворк для создания веб-приложений. Когда вы только начинаете работать с Django, вы можете часто совершать одни и те же небольшие ошибки из-за недостатка знаний. Я написал этот пост чтобы помочь осветить некоторые часто встречаемые мною ошибки в чужом коде.
В этом посте мы рассмотрим часто встречаемые ошибки на примере приложения Django, которое предназначено для управления сотрудниками в различных организациях.
Пару недель назад Django 3.2 выпустил свой первый альфа-релиз, а финальный релиз выйдет в апреле. Он содержит микс новых возможностей, о которых вы можете прочитать в примечаниях к релизу. Эта статья посвящена изменениям в тестировании, некоторые из которых можно получить на более ранних версиях Django с пакетами backport.
Думаю, ни для кого не секрет, что в разговорах опытных разработчиков Python, и не только, часто проскальзывают фразы о том, что Django это зло, что в Django плохая архитектура и на ней невозможно написать большой проект без боли. Часто даже средний Django проект сложно поддерживать и расширять. Предлагаю разобраться, почему так происходит и что с Django проектами не так.
Если вы не используете все возможности Django, то, очень вероятно, вы не пользуетесь SITE_ID. Этому способствуют как убогая официальная документация Sites framework, так и несогласованное с Sites развитие кода Django. Предположу, что Sites скоро будет бездумно снесен свежими «разработчиками» Django, как это уже произошло с модулями Comments (Dj 1.6) или Formtools (Dj 1.8). А, пока этого не произошло, предлагаю вам поразмышлять о возможностях Django Sites framework.
Рано или поздно маленькие приложения разрастаются до нагруженных production-решений, поэтому программисту необходимо заранее продумать стек технологий. Для Python концептуальный выбор стоит между синхронными и асинхронными фреймворками. После появления библиотеки asyncio популярность асинхронных Python-фреймворков сильно выросла, потеснив таких монстров, как Django и Flask, и стало намного проще писать веб-приложения, способные пережить высокий RPS.
Маршрутизация в Django со второй версии фреймворка получила замечательный инструмент — конвертеры. С добавлением этого инструмента появилась возможность не только гибко настраивать параметры в маршрутах, но и разделять зоны ответственности компонентов.