Для каких проектов лучше всего подходит Flask, а для каких — Django? Какие особенности Flask можно использовать при разработке веб-приложений наиболее эффективно? Я Алексей Некрасов, лидер направления Python в МТС, автор форка библиотеки flask-combo-jsonapi, программный директор курсов по Python в Skillbox, СЕО Forkway и автор канала Python — учим и работаем.
Доброго времени суток уважаемый читатель. Хотелось бы немного поговорить об оптимизации наших с вам любимых WEB приложений, написанных на нашем горячо любимом и всеми уважаемом фреймворке Django. В частности речь в этой статье пойдёт об оптимизации изображений. А теперь по порядку.
Однажды в поисках примера на React/Django я нашел на Хабре одну интересную статью. Она показалась мне полезной, и я решил дополнить пример из статьи новыми возможностями. В этом сиквеле мы добавим в веб-проект со списком студентов поддержку авторизации и real-time уведомлений на сокетах, улучшим систему Docker-сборки, оптимизируем модель очередей на RabbitMQ и немного пригладим косметику. В результате получим удобный базовый шаблон, с которого вы сможете начинать свои проекты.
Как же объединить Django и Telegram бота в одном проекте?
Этой статьей я хотел дополнить тот маленький клочок информации доступный в интернете по теме создания ботов который мне явно бы пригодился в прошлом. Сегодня речь пойдет о соединения вашего серверного приложения с Telegram ботом на примере языка Python, его фреймворка для разработки серверных приложений - Django и библиотеки для создания Telegram ботов - pyTelegramBotApi.
Пикабу долгое время было уютным уголком для обмена историями, опытом, творчеством, мнениями и эмоциями. Однако ряд нововведений, таких как отмена баянометра, изменение алгоритмов и скрытие отрицательных оценок, привели к потере духа оригинального портала. Многие из нас, пришедшие туда в молодости и теперь ставшие взрослыми, почувствовали, что наши ценности и мнения игнорируются. В ответ на это, мы, группа энтузиастов, создали "Капибару" – проект, который стремится сохранить лучшие стороны Пикабу, предоставляя пространство где пользователи сами решают какой контент "годный" и какой контент хотят видеть в своей ленте.
Сегодня очень многие backend разработчики стали писать именно rest api.
Почему же так? Чем не устраивает обычный django?
Этот вопрос часто возникает у студентов к одному из заданий в самом начале курса «Мидл Python-разработчик» в Яндекс Практикуме. Мы попросили наставника на курсе Евгения Морозова написать подробный ответ. Дублируем его здесь, потому что уверены, что он будет полезен не только нашим студентам.
Потихоньку развиваю проект, основанный на своих (сложных) инженерных изысканиях, опубликованных тут:
Теория разработки информационно-исторических систем с реализацией концепта
и частично, (может, не совсем удачно, но как-то по-проще) описанных тут:
Прикладное использование теории построения информационно-исторических систем
Сразу хочу предупредить, что описанное в статье - еще на разработке, и в проекте появится не скоро.
Поехали!
Сложные и скучные выкладки формул я выдал в прошлой статье. Хотел бы поделится с тем, как я это применяю на своем концепте. Ссылка на него там тоже есть...
Теория разработки информационно исторических систем с реализацией концепта
Боюсь, что без нее начало этой статьи будет не совсем понятной. Хотя там все не просто.
Всем привет!
Занимаюсь разработкой системы построенной на теории, что любые исторические информационные системы (ИИС) построены по одним законам.
Хотел поделится своими теоретическими наработками в этой области. Возможно, я не прав, или глубоко заблуждаюсь, но вдруг мои наработки кому-нибудь пригодятся. Пост может быть очень долгим, выкладки скучными и могут быть непонятны без пояснений. Все что ниже встречается, я реализую на связке Python + Django + Sqlite в своем проекте.
Статус проекта на текущий момент: Proof of concept.
Лицензия - MIT.
Кодовое название: ForTeaToo или 42.
В дневнике разработчика встречается название ForTea (устарело).
Актуальный дневник разработчика тут
Поехали...
Давно устоявшийся и прекрасно показывающий себя фреймворк. Постоянная поддержка, множество пакетов «из под капота», отличный ORM, хорошее распределение компонентов и простота в изучении — вот, что предлагает Django.
Да, все мы знаем, что выходят новые фреймворки, например, FastAPI, который все увереннее закрепляется на рынке, но сможет ли он похвастаться тем, что имеет Django? Например, для нормальной ORM, если вы не хотите писать напрямую SQL‑запросы конечно же, нужно будет воспользоваться sqlalchemy и alembic. В Django же все проще, создай проект и твори! Есть и плюсы FastAPI, но об этом в другой статье, не будем отходить от темы.
Так вот, есть и не такие «молодые» технологии, например, тот же Flask, тоже хорошо закрепился на рынке и стеке разработчиков, но ситуация очень похожа с FastAPI, не хватает простоты и множества удобств. Та же панель администратора — это что‑то с чем‑то, максимально полезный инструмент, который используются все при создании проектов на Django. Так же, стоит отметить приложения в Django, отличный способ разделять основные модули проекта и не ловить путаницу, опять‑таки, не все могут этим похвастаться. Не стоит и забывать об огромном комьюнити пользователей этого фреймворка, я не раз сталкивался с ошибками и практически все находил на том же Stack Overflow. Еще одна, но значительная плюшка — это неплохой перевод на русский язык.
Часто определение разницы между select_related и prefetch_related звучит как “первый для ForeignKey полей, второй для ManyToMany”, однако это описание не раскрывает суть работы этих методов. Ниже я попробовал на примерах показать разницу между этими методами и какое влияние они оказывают на сгенерированный SQL для получения данных.
TLDR: Статья будет в первую очередь полезна тем кто начинает свое знакомство с Django, а также тем, кто использует select_related/prefetch_related в ежедневной работе, но не углублялся в глубь Django.
Я Python Developer в компании Нетрика. В данной статье расскажу, как устроены разрешения в Django и django-rest-framework и как мы используем их на одном из проектов.
По работе активно использую ChatGPT, часто бывает ситуации, когда модель позволяет найти решение, о котором даже не подозревал. В этом году он стал реальными помощником в поиске информации наравне с Google. Если в Google нужно вводить точный запрос и искать в выдаче подходящее решение, то Chat позволяет найти решение по описанию проблемы или проверить гипотезы.
У меня давно было желание поработать с непосредственно с самим API от Open AI и с другими LLM моделями. Решил написать свой чат с возможностью адаптировать под внутренние нужды команды в дальнейшем. Проект выложен в открытый доступ, скачать можно по ссылке. Сам проект находится в активной разработке, так что вы можете писать ваши замечания / пожелания в комментариях или отправить ваш pull request с исправлениями. Будем оперативно исправлять ошибки.
На бэкенде был выбран Python, Django Rest Framework. На фронтенде React, Redux, Saga, Sass. Начнем с бэкенда, им занимался Егор. Далее про серверную часть проекта он пишет от себя.
В данной статье:
Создаем первый наипростейший проект в Django за 5 минут без регистраций и смс. В первый раз у меня на это ушло несколько часов.
Всем привет, меня зовут Абай. Я являюсь Back-End разработчиком в 13LAB.
После прочтения интересной статьи со сравнением NodeJS и FastAPI, у меня появилось желание высказать свое личное мнение об удобстве разработки бэкенда на Python и фреймворке FastAPI.
FastAPI - является легковесным асинхронным фреймворком для Python, который используют преимущественно для разработки API-сервисов. Фреймворк довольно молодой и существует всего лишь 5 лет. До 2021 года не имел большой популярности по сравнению с Flask и Django, но на данный момент уже стал намного востребованнее, что его стали использовать в МAANG компаниях, к примеру...
Как за ограниченное время из готовых компонентов создать и запустить по-настоящему нагруженный проект? Рассмотрим пример метрик, архитектуры, технических ограничений и подходов к проектированию систем на примере проекта «Экологический диктант».
Помогут нам в этом, два главных человека из компании Старботс.рф - Станислав Жуковский, руководитель проекта, и Василий Шалимов, архитектор и разработчик фич в части бэкенда. Они расскажут, как собрали сервис онлайн-тестирования за 2 месяца, вместо 8 плановых, а также про человеческий фактор, с которым они столкнулись во время работы.
Всем привет! Меня зовут Артём. Я бэкенд-разработчик Яндекс Практикума, занимаюсь продуктовой разработкой нашей платформы. Пришёл в команду почти три года назад, когда Практикум только развивался, так что экспериментировать приходилось много.
Например, в 2021 году мы переработали систему контента, чтобы его можно было версионировать и показывать актуальные учебные материалы тогда, когда они будут готовы целиком. Это был достаточно сложный ход, который вылился в немалый даунтайм для сервиса, но в итоге всё закончилось успешно.
Практикум развивается, поэтому миграций накатывать приходится много. Причём применять их часто нужно к достаточно большим табличкам с щепоткой дата-миграций. В этой статье я разберу несколько примеров неаккуратной работы с миграциями в Django и поделюсь, как избежать подобных проблем.
17 месяцев назад я начал свою путь в бэкенд разработку Python. Но спустя время я начал сталкиваться со сложностями в обучении на своей платформе. Первые уроки давались легко, а потом начиналось что-то непонятное в буквальном смысле. Заучивание, записывание, практика одного урока - на это уходили дни. А уроков сотни.
Чтобы найти простое объяснение и понять 10 минутный урок, приходилось несколько часов серфить интернет и потеть над кодом, выявляя правильный путь исправления ошибок. Везде говорят, что в первую очередь нужно учиться искать информацию в интернет. Но сейчас, когда я изучаю Django, даже "перекурив" весь русскоязычный мануал, я не понял ничего. В каждом предложении нужно "гуглить" термины. В сотрудничестве с ИИ я попробовал дать простое объяснение, которое поймет даже первоклассник.
Я только учусь и курс Django пройден наполовину. Все это сделано для тех, у кого тоже возникли трудности.
Развёртывание ПО, или деплой (deploy) — этап в разработке, в Devops в целом, это действия, которые делают ПО готовым к использованию. Если вы умеете в грамотный деплой, масштабирование и управление конвейерами (CI/CD), то ваш софт будет конкурентоспособным.
Далеко не все компании могут позволить себе нанять целую команду DevOps инженеров, чтобы управлять развёртыванием. Но здесь важно не количество разрабов, а качество их знаний. Есть инструменты, с которыми можно эффективно деплоить и без большой команды.
Мы в digital-агентстве успешно используем GitLab CI и Docker для развёртывания ПО в разных средах. Для чего нужны эти инструменты?
GitLab CI позволяет автоматизировать процессы сборки и доставки ПО. Docker — упаковать приложение и его зависимости в контейнеры, что упрощает развёртывание и масштабирование в разных средах. Используя их, вы сократите затраты на найм и оптимизируете деплой.
В этой статье расскажу о нашем опыте и покажу примеры настройки конвейеров CI/CD, как ими управлять с помощью GitLab CI и Docker. А также дам рекомендации, как масштабировать развертывание.
