Григорий IT | Dev & Tutor

И так баг за багом... #meme

Поскольку автор канала ударился в диджитал-номадизм, по нашему - цифровое кочевничество, на канале также в скором времени появится рубрика на эту тему Ну а пока давайте небольшой опрос, чтобы мне понять интерес к этой теме #digitalnomad

👨‍💻 Celery: как вынести тяжелые задачи из API в фон Погружаемся в тему и рассматриваем конкретные примеры вместе с Григорием, преподавателем школы 📌Записаться на занятие к Григорию можно здесь

🎮 Как мы внедрили геймификацию в работу преподавателей Геймификация давно вышла за пределы игрового пространства - В Duolingo тебя мотивируют серии дней, XP и лиги - В Яндекс Плюсе - задания, баллы и уровни - В фитнес-приложении Strava - челленджи, прогресс и достижения По сути, обычные действия превращаются в понятную систему целей, наград и наблюдения за своим прогрессом Мы решили попробовать похожий подход внутри INNOPROG - только применить его к работе преподавателей и сделали систему внутренних баллов - иннопрожек (IP)

Преподаватель работает как обычно, а система сама смотрит на его показатели - проведённые занятия, сданные отчёты, отправленные записи занятий, взаимодействие с учеником вне занятий в чате и т.д.

На основе этих показателей считается эффективность работы за день и автоматически начисляются IP

То есть это не просто "провёл урок - получил баллы" - у каждого показателя есть свой вес

А дальше самое приятное - накопленные IP можно тратить во внутреннем магазине Сейчас в качестве награды пока что используются промокоды, однако сама механика позволяет спокойно расширять каталог чем угодно ——— ⚙️ Немного про разработку По итогу нашей работы получился отдельный сервис внутри онлайн-платформы INNOPROG, который:

- собирает данные о работе преподавателей из внутреннего API INNOPROG

- каждый день автоматически формирует статистику

- начисляет внутреннюю валюту

- ведёт полную историю операций

- считает "ранги" преподавателей метрики эффективности

- следит за лимитами промокодов

- позволяет покупать награды за накопленные IP

Причём, механика работы такова, что статистику нельзя просто один раз посчитать и забыть - например, отчёт или запись занятия могут появиться не сразу, а спустя несколько дней Поэтому система периодически пересчитывает и при необходимости корректирует начисления Плюс важно было сделать так, чтобы случайный повторный запуск расчётов ничего не ломал и не начислял IP по много раз - это кстати называется идемпотентностью

Идемпотентность - это когда повторный запуск одной и той же операции не приводит к дополнительным изменениям состояния

В нашем случае это значит, что повторный пересчёт не должен второй раз начислить те же IP

Под капотом у всего этого дела: - фронтенд на React👩‍💻 + TypeScript 👩‍💻 - серверная часть на FastAPI👩‍💻 - БД PostgreSQL👩‍💻 - APScheduler для ежедневных автоматических расчётов 🕓 - Docker для контейнеризации 👩‍💻 - GitHub Actions для автоматического запуска тестов при изменениях в бэкенде⚙️ До окончательного релиза на онлайн-платформе INNOPROG, деплоил бэк сервис через Railway - удобная штука для запуска небольших проектов в облаке

Деплой - процесс развёртывания проекта в облаке, чтобы он постоянно работал онлайн и стал доступен пользователям

К посту как раз прикрепил демонстрацию того, как всё это в итоге выглядит со стороны преподавателя 👆 Ну и заодно хвалюсь своими показателями за неделю, о гордыня-гордыня😁 Я взял на себя разработку бэкенд-части сервиса, но работали мы в команде вместе с Артемием (@MifmanRu) и Вадимом (@VadimKokorev) Вадим, как фронтендер проекта, сделал удобный и наглядный интерфейс - как раз на видео можете его оценить Артемий взял на себя руководство разработкой и взаимодействие с INNOPROG по административной и бизнес-части проекта

У Артемия, кстати, тоже есть свой канал - https://t.me/codeshadowcources, можете заглянуть 👀

Мне вообще нравится такой тип задач, когда с нуля строишь систему с достаточно большой внутренней логикой - экономикой, аналитикой, автоматическими расчётами и многим другим Проект получился интересный, запустили его недавно, сейчас активно тестим и ждём фидбэк от наших пользователей - преподавателей👨‍🏫 #project #backend #python #fastapi #database

Автор с головой погрузился в себя, работу и поездки, но молчание не могло продолжаться вечно Накопилось много чего рассказать-показать, чем поделиться Ожидайте новых постов, друзья, уже с этой недели

⚡️Aiohttp: ускоряем работу с API в Python Представь ситуацию: ты разрабатываешь бэкенд веб-платформу, которой необходимо регулярно делать по 10 запросов в 10 разных API - При обычном использовании requests мы отправляем первый запрос, ждём ответа, потом второй, потом третий и так далее... - А можно сделать так: пока один API обрабатывает наш запрос, программа может переключиться на работу с другими запросами Вот для таких задач и существует aiohttp

aiohttp - это библиотека для асинхронной работы с HTTP в Python, с её помощью можно как отправлять HTTP-запросы, так и поднимать свой web-сервер

Главная фишка тут именно в асинхронности Допустим, у нас есть несколько адресов:

import asyncio
import aiohttp


async def get_site(session, url):
    async with session.get(url) as response:
        print(url, response.status)


async def main():
    urls = [
        "https://python.org",
        "https://github.com",
        "https://google.com"
    ]

    async with aiohttp.ClientSession() as session:
        await asyncio.gather(
            *[get_site(session, url) for url in urls]
        )


asyncio.run(main())

Что здесь происходит? 👇 1. Мы создаём одну клиентскую сессию (ClientSession) 2. Делаем сразу несколько запросов через asyncio.gather() - функцию, которая запускает несколько асинхронных операций вместе и ждёт, пока они завершатся 3. И не ждём, пока каждый запрос полностью закончится перед запуском следующего 4. Пока мы ждём ответ от одного сайта, Python может переключиться на обработку другого запроса В этих задачах aiohttp будет особенно полезен: - работа с большим количеством API - парсеры и сбор данных - микросервисы - Telegram-боты - любые задачи, где программа много ждёт сеть Чем это лучше обычной библиотеки requests? 1. Если нужно сделать один-два запроса, то requests может подойти:

requests.get(url)

2. Но если запросов сотни, код на requests много времени просто ждёт ответа от API, а с aiohttp это время ожидания можно использовать для выполнения других запросов

Важно: aiohttp не делает сам HTTP-запрос быстрее, выигрыш появляется за счёт того, что во время ожидания выполнения одного запроса программа может заниматься другими

Подводя итог, можно сказать следующее: requests - простая и удобная библиотека для обычных запросов и небольших скриптов aiohttp - библиотека помощнее, которая нужна в ситуациях, когда начинается серьёзная асинхронная работа с сетью А какие асинхронные библиотеки вы использовали в своих проектах?

Сериализаторы простыми словами Слово страшное (много букв ааа), но если совсем по-простому его пояснять, то сериализатор - это переводчик между Python-объектами и данными, которые уходят или приходят через API Зачем он нужен? Представь, что ты разрабатываешь web-сервис и у тебя есть некая переменная-словарь в Python-коде:

user = {
    "id": 1,
    "name": "Алексей"
}

И перед нами стоит задача: нужно отправить эту информацию на смартфон пользователя через API Но есть загвоздка - приложение на смартфоне пользователя не понимает Python-структуры (в т.ч. переменные), как тогда быть...🤷‍♂️ Ответ прост - превратить данные в текст формата JSON И тогда пользователь получит на своё устройство что-то вроде такого текста:

{
  "id": 1,
  "name": "Алексей"
}

И уже с текстом ему будет проще справиться, чем с какими-то там python-объектами и python-переменными Вот это превращение Python-объекта в JSON и называется сериализацией Работает это и в обратную сторону: Например, когда пользователь заполняет форму регистрации и нажимает кнопку "Отправить", мы по сути шлём на сервер данные в виде JSON-текста:

{
  "name": "Алексей",
  "email": "Aleksey@mail.com"
}

Но важный момент - перед тем как сохранить эти данные в базу данных на сервере, нужно как минимум проверить - все ли поля в форме заполнены и корректный ли тип у данных (не написал ли пользователь слово "Привет" в окне для ввода возраста) А если вместо возраста пришло слово "Привет", сериализатор сразу скажет: стоп, тут ошибка, возраст должен быть числом Например, с помощью библиотеки Pydantic можно описывать структуру данных и превращать объект в словарь/JSON:

from pydantic import BaseModel

class UserRegister(BaseModel):
    name: str
    age: int

data = {
    "name": "Алексей",
    "age": 25
}

user = UserRegister(**data)

print(user.model_dump())
print(user.model_dump_json())

☝️Тут мы описываем, какие поля ожидаем, и какого они должны быть типа. Таким образом, сериализатор обычно делает две вещи: 1. Готовит данные для отправки из сервера клиенту 2. Проверяет данные, которые пришли от клиента на сервер Поэтому в backend они используются почти в каждом запросе к API

👨‍💻 FastAPI vs Django vs Flask - какая разница? Разбираемся вместе с Григорием, преподавателем INNOPROG Те, кто только делают первые шаги в backend-разработке, часто спрашивают: какой фреймворк лучше выбрать - FastAPI, Django или Flask? И какая между ними вообще разница? Если объяснять по-простому: Django - это фреймворк, в котором вы найдёте много готового: админку, авторизацию, ORM, структуру проекта и другие инструменты для полноценного веб-сервиса Flask - это минималистичный фреймворк, который даёт базу, а дальше вы сами решаете, что подключать и как собирать проект FastAPI - это современный фреймворк на Python, изначально ориентированный на создание API и удобный для backend-сервисов, которые принимают запросы и отдают данные frontend, мобильным приложениям, ботам или другим сервисам Как обычно выбирают между ними? - Если нужен большой сайт или сервис с кучей готовых вещей - чаще смотрят в сторону Django - Если хочется больше свободы и минимализма - берут Flask - Если нужен удобный и быстрый API на Python с валидацией данных и Swagger-документацией, обычно выбирают FastAPI То есть, если совсем кратко: - Django = много готового - Flask = много свободы - FastAPI = удобно делать API ❗️Что выбрать новичку? - Если хочешь базово понять, как работают веб-сервисы, можно зайти через Flask - Если хочешь делать что-то ближе к реальному сервису, смотри на FastAPI - Если нужен полноценный веб-проект с кучей готовой инфраструктуры, хорошим вариантом будет Django Но важно помнить: лучшего фреймворка вообще не существует Есть фреймворк, который лучше подходит под конкретную задачу! А с какого из них начинали вы? Пишите в комментариях к посту 👇

👨‍💻 FastAPI vs Django vs Flask - какая разница? Разбираемся вместе с Григорием, преподавателем INNOPROG Те, кто только делает первые шаги в backend-разработке, часто спрашивают: какой фреймворк лучше выбрать - FastAPI, Django или Flask? И какая между ними вообще разница? Если объяснять по-простому: Django - это инструмент, в котором вы найдёте много всего готового: админка, авторизация, ORM, структура проекта и т.д. Flask - это конструктор, который даёт тебе базу, а дальше ты сам решаешь, что подключать и как всё собирать FastAPI - это современный инструмент под API, особенно хорошо подходит, когда ты делаешь backend для бота, frontend, мобильного приложения или микросервиса Как обычно выбирают между ними? - Если нужен большой сайт или сервис с кучей готовых вещей - чаще смотрят в сторону Django - Если хочется больше свободы и минимализма - берут Flask - Если нужен удобный и быстрый API на Python с валидацией данных и Swagger-документацией, обычно выбирают FastAPI То есть, если совсем кратко: - Django = много готового - Flask = много свободы - FastAPI = удобно делать API ❗️Что выбрать новичку? - Если хочешь базово понять, как работают веб-сервисы, можно зайти через Flask - Если хочешь делать что-то ближе к реальному сервису, смотри на FastAPI - Если нужен полноценный веб-проект с кучей готовой инфраструктуры, хорошим вариантом будет Django Но важно помнить: лучшего фреймворка вообще не существует Есть фреймворк, который лучше подходит под конкретную задачу! А с какого из них начинали вы? Пишите в комментариях к посту 👇

Недавно ко мне обратился заказчик, нужно было реализовать фичу общих корзин для небольшого сервиса доставки ❓Смысл такой: 1. один пользователь создаёт общую корзину 2. получает ссылку или QR 3. скидывает друзьям 4. каждый заходит и добавляет свои позиции 5. а потом создатель оформляет и оплачивает весь заказ Отдельно сделал фиксацию оплаты: создатель видит, кто сколько должен перевести, участники могут отметить перевод, а создатель - подтвердить 🔒После старта оплаты корзина блокируется, чтобы никто уже не менял состав заказа На скрине выше пока черновой интерфейс, но сама backend-логика уже работает #projects

💻Анатомия бэкенда #backend

Всем такого директорства😁 #meme

🐍Универсальность Python подкрепляется широким выбором фреймворков для разных задач #python

Всех с первым днём лета, друзья🔅 Тепло, солнце и водоёмы ждут🥃

💡Друзья, проголосуйте пожалуйста за темы, которые вам было бы интересно изучить, реазизация планируется на фреймворках FastAPI/Django

🤌Mamma mia 🇮🇹 #meme

Маскотом бота стал кот моих родителей Локи😁 Можете проверять, маскот уже добавлен😊 @grigo_it_English_bot #pet

💻Для тех кто на сервере: мини-шпаргалка по HTTP-статусам 📌Сохрани, пригодится #tips

🇬🇧Ну чтож, спустя столько времени у меня наконец добрались руки до бота для изучения английских слов, о котором я писал аж в декабре Возможности бота: ⏺️Интервальное повторение изучаемых слов ⏺️Ежедневные напоминания ⏺️Викторина по изучаемым словам ⏺️Отлеживание прогресса друзей Проект в данный момент работает корректно, поправил множество багов, вы можете его протестировать тут 👉 @grigo_it_English_bot 💬Пишите в лс или тут в комментах, если возникнут проблемы при работе —————— ⚡️Также в ближайшее время планирую создать животного-маскота для данного бота (как Дуо у Дуолинга, да-да), предлагайте своих животных в комментариях 👇 #pet