Проблемы разработчиков, которые мы решаем на обучении
Многие наши ученики приходили к нам после попыток разобраться в backend’е самостоятельно. Кто-то не мог пройти собеседования, кто-то застревал на тестовых заданиях, а кто-то просто не понимал, что именно нужно учить, чтобы получить первую работу.
Чтобы решить эти проблемы, мы создали понятную систему обучения. В Pytex курсы создают Senior-разработчики для разработчиков. После каждого модуля ученики проходят тесты и на практических заданиях закрепляют материал.
Как итог, к концу курса у каждого из них есть собственные проекты и понимание, как применять полученные знания и навыки в работе.
Наши выпускники проходят собеседования, устраиваются в компании и чувствуют себя уверенно в командной работе, о чем пишут в многочисленных отзывах.
Многие наши ученики приходили к нам после попыток разобраться в backend’е самостоятельно. Кто-то не мог пройти собеседования, кто-то застревал на тестовых заданиях, а кто-то просто не понимал, что именно нужно учить, чтобы получить первую работу.
Чтобы решить эти проблемы, мы создали понятную систему обучения. В Pytex курсы создают Senior-разработчики для разработчиков. После каждого модуля ученики проходят тесты и на практических заданиях закрепляют материал.
Как итог, к концу курса у каждого из них есть собственные проекты и понимание, как применять полученные знания и навыки в работе.
Наши выпускники проходят собеседования, устраиваются в компании и чувствуют себя уверенно в командной работе, о чем пишут в многочисленных отзывах.
👍3❤2🤝2
Что должен уметь backend-разработчик в 2026 году
Как и в любой IT-специальности, требования к специалистам отличаются от компании к компании. Где-то разработчик с опытом 2 лет считается middle, где-то всё ещё junior. Рассмотрим усредненный набор знаний и навыков, по которым обычно определяют грейд:
Junior
На этом уровне от разработчика ждут точного выполнения задач по ТЗ, аккуратного кода и умения учиться. Пространства для архитектурных решений ещё мало — важнее скорость, внимательность и понимание основ.
Middle
Middle-разработчик уже не ждёт подробного ТЗ. Он предлагает решения, оптимизирует архитектуру, умеет разбираться в чужом коде и общается с аналитиками, менеджерами, QA.
Senior
Senior-бэкендер понимает архитектуру не на уровне отдельного приложения. Он влияет на технические решения, менторит команду, ведёт сложные проекты и отвечает за процесс разработки.
Подробнее о разнице в задачах и росте в backend’е расскажем в следующих постах.
Как и в любой IT-специальности, требования к специалистам отличаются от компании к компании. Где-то разработчик с опытом 2 лет считается middle, где-то всё ещё junior. Рассмотрим усредненный набор знаний и навыков, по которым обычно определяют грейд:
Junior
На этом уровне от разработчика ждут точного выполнения задач по ТЗ, аккуратного кода и умения учиться. Пространства для архитектурных решений ещё мало — важнее скорость, внимательность и понимание основ.
Что нужно знать:
✅ Python на уровне уверенного написания простых сервисов
✅ Основы ООП, понимание принципов SOLID на базовом уровне
✅ Асинхронность (async/await) — базовые представления
✅ FastAPI — базовые CRUD-эндпоинты, роутинг, обработка ошибок
✅ PostgreSQL: JOIN, GROUP BY, индексы, транзакции
✅ SQLAlchemy или Django ORM — базовые запросы
Понимание NoSQL (Redis, MongoDB) на уровне базовых операций
✅ Docker: запуск простого контейнера, базовый Dockerfile
Понимание, что такое REST API, HTTP, статусы ответов
✅ Git: ветки, merge request, code review, конфликты
Логирование, работа с зависимостями, структура проекта
Middle
Middle-разработчик уже не ждёт подробного ТЗ. Он предлагает решения, оптимизирует архитектуру, умеет разбираться в чужом коде и общается с аналитиками, менеджерами, QA.
Что нужно знать:
✅ Глубокое понимание Python: генераторы, контекстные менеджеры, async/await, типизация
✅ Понимание паттернов проектирования
✅ FastAPI: асинхронные приложения, middleware, фоновые задачи
✅ PostgreSQL: планы выполнения, оптимизация запросов, индексы, триггеры
✅ Проектирование API, контрактов, интеграций
✅ Использование Redis для кэша, rate-limit, очередей
✅ Работа с SQLAlchemy ORM на продвинутом уровне
✅ Docker: мультистейдж сборка, оптимизация образов
✅ CI/CD (GitHub Actions/GitLab CI/Yandex Cloud)
✅ Базовые знания Kubernetes (часто встречается в 2025)
✅ Pytest: фикстуры, моки, тестирование API
✅ Опыт с брокерами сообщений: Kafka, RabbitMQ
✅ Линтеры: ruff, black, mypy
✅ Умение писать документацию
✅ Участие в планировании, декомпозиции задач
Senior
Senior-бэкендер понимает архитектуру не на уровне отдельного приложения. Он влияет на технические решения, менторит команду, ведёт сложные проекты и отвечает за процесс разработки.
Что нужно знать:
✅ Проектирование высоконагруженных систем
✅ Микросервисная архитектура, событийный подход
✅ Domain-Driven Design (DDD) на практическом уровне
✅ Продвинутый Kubernetes (Helm, Operators)
✅ Балансировка нагрузки
✅ Мониторинг: Prometheus, Grafana, Sentry
✅ Оптимизация на уровне схемы, репликация, шардинг
✅ Redis для сложных задач: очереди, pub/sub
✅ Code review, менторинг, постановка задач
✅ Ведение технических дорожных карт
✅ Понимание влияния архитектурных решений на продукт
✅ Оценка рисков, сроков
✅ Качество SLA, отказоустойчивость систем
Подробнее о разнице в задачах и росте в backend’е расскажем в следующих постах.
❤17
Различия между грейдами backend-разработчиков.
Разбор на реальном кейсе
Разница между Junior, Middle и Senior проявляется не только в навыках, но и в том, как каждый уровень решает одну и ту же задачу. Рассмотрим на примере из практики.
Кейс
Сервис электронных уведомлений столкнулся с проблемой: пользователи жалуются, что письма и push-уведомления приходят с задержкой. В пиковые часы очередь задач растёт, а система не справляется. Нужно понять, что происходит и как стабилизировать работу сервиса.
Junior
Начинающему backend-разработчику нужно поставить чёткое ТЗ: проверить один конкретный модуль или часть очереди. Он сможет:
Middle
Middle-разработчик уже сам исследует проблему, формулирует гипотезы и предлагает варианты решения. Он сможет:
Senior
Senior-разработчик смотрит системно: он решает не только текущую проблему, но и предотвращает будущие. В этом кейсе он сможет:
Важно: как и в любой IT-специальности, требования к специалистам отличаются от компании к компании.
Разбор на реальном кейсе
Разница между Junior, Middle и Senior проявляется не только в навыках, но и в том, как каждый уровень решает одну и ту же задачу. Рассмотрим на примере из практики.
Кейс
Сервис электронных уведомлений столкнулся с проблемой: пользователи жалуются, что письма и push-уведомления приходят с задержкой. В пиковые часы очередь задач растёт, а система не справляется. Нужно понять, что происходит и как стабилизировать работу сервиса.
Junior
Начинающему backend-разработчику нужно поставить чёткое ТЗ: проверить один конкретный модуль или часть очереди. Он сможет:
— Посмотреть логи и найти явные ошибки.
— Открыть код эндпоинта, проверить простые проблемы: блокирующие операции, отсутствие таймаутов.
— Перезапустить сервис, обновить зависимости, протестировать простой случай.
— Написать небольшой скрипт для замера времени ответа.
— Сделать фикс под руководством ментора: вынести тяжёлую операцию в фон, добавить кэш, поправить обработчик ошибок.
Middle
Middle-разработчик уже сам исследует проблему, формулирует гипотезы и предлагает варианты решения. Он сможет:
— Проанализировать узкие места: медленные запросы в PostgreSQL, блокировки, неэффективные ORM-операции.
— Проверить, не упирается ли сервис в ограничение Redis, очередь, лимиты CPU.
— Переписать критичный участок на асинхронный FastAPI, вынести операции в Celery или другой брокер задач.
— Оптимизировать SQL: добавить индексы, CTE, изменить схему таблиц.
— Настроить метрики и алерты: время ответа, длину очереди, ошибки 5xx.
— Внедрить rate-limit, чтобы ни один канал не перегружался.
— Предложить архитектурное улучшение: разделить сервис на два модуля, вынести тяжёлые задачи в отдельный worker.
Senior
Senior-разработчик смотрит системно: он решает не только текущую проблему, но и предотвращает будущие. В этом кейсе он сможет:
— Спроектировать высоконагруженную архитектуру для отправки уведомлений: очереди, ретраи, шардирование, отдельные сервисы под каждый канал.
— Выстроить систему observability: логирование, трассировка, метрики, алерты, дашборды в Grafana.
— Переписать критичные части на устойчивую схему: worker-пул, механизм backpressure.
— Настроить CI/CD, автотесты, нагрузочное тестирование, чтобы проблем не возникало после релизов.
2
Рубрика #проверь_себя
Сегодня предлагаем тебе решить задачу по SOLID🔥
Класс ReportService отвечает только за подготовку отчёта, а конкретный формат вывода передаётся через абстракцию. Какие два принципа SOLID демонстрирует этот код?
Сегодня предлагаем тебе решить задачу по SOLID
Класс ReportService отвечает только за подготовку отчёта, а конкретный формат вывода передаётся через абстракцию. Какие два принципа SOLID демонстрирует этот код?
class ReportExporter(ABC):
@abstractmethod
def export(self, data):
pass
class PDFExporter(ReportExporter):
def export(self, data):
print("Export to PDF")
class ExcelExporter(ReportExporter):
def export(self, data):
print("Export to Excel")
class ReportService:
def __init__(self, exporter: ReportExporter):
self.exporter = exporter
def generate(self, data):
self.exporter.export(data)
Please open Telegram to view this post
VIEW IN TELEGRAM
Пояснение ко вчерашней задаче
Почему же правильный ответ — S, D
Single Responsibility Principle (S):
Dependency Inversion Principle (D):
💬 Ну что, стало понятнее? Или вы сразу решили задачу верно?)
Почему же правильный ответ — S, D
Single Responsibility Principle (S):
ReportService отвечает только за подготовку отчёта, Он не знает, куда и в каком формате происходит экспорт. Экспорт отчёта вынесен в отдельные классы (PDFExporter, ExcelExporter).
Если меняется логика формирования отчёта, необходимо изменить ReportService. Если меняется способ экспорта, тогда достаточно выбрать другой exporter.
Dependency Inversion Principle (D):
модули верхнего уровня не должны зависеть от модулей нижнего уровня, оба уровня должны зависеть от абстракций. Класс ReportService в `__init__` принимает абстракцию ReportExporter, не создавая внутри себя экземпляры PDFExporter или ExcelExporter, можно легко подменить одну реализацию другой. Для добавления новых вариантов ReportExporter менять логику в ReportService не требуется.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍8
Планировал прокачаться в backend-разработке в 2025 году?
У нас для тебя отличные новости!
Если ты только начинаешь путь в бэкенде или уже работаешь, но чувствуешь, что знаний или практики где-то не хватает — мы подготовили для тебя два мощных практических вебинара от Senior-разработчика Артёма Шумейко. Минимум теории, максимум практики, и, как всегда, простым языком на реальных примерах.
💎 16 декабря в 18:00 МСК — «Пишем систему аутентификации и авторизации: сессии vs JWT токены»
На вебинар ты:
— разберёшься в ключевых принципах аутентификации и авторизации через сессии и токены
— вместе с Артёмом Шумейко напишешь приложение, в котором реализуешь оба подхода.
После такого пошагового практикума ты будешь понимать, как строить безопасную систему входа в приложение.
ЗАРЕГИСТРИРОВАТЬСЯ
💎 18 декабря в 18:00 МСК — «5 слоёв кэширования в веб-приложениях»
На вебинаре ты:
— разберёшь теорию кэширования: уровни, механизмы, типы хранилищ;
— поймёшь, где и зачем применять разные виды кэша;
— разберешься, как бэкендер может снизить нагрузку на бэк в десятки раз через кэширование на уровне браузера;
— на практике внедришь 5 уровней кэширования в реальное приложение.
Это тот навык, который отличает джуна от мидла и который особенно ценят работодатели.
ЗАРЕГИСТРИРОВАТЬСЯ
🎉 Всех участников вебинаров ждут подарки.
Обо всём расскажем уже скоро! А пока регистрируйся и следи за новостями канала, чтобы ничего не пропустить
У нас для тебя отличные новости!
Если ты только начинаешь путь в бэкенде или уже работаешь, но чувствуешь, что знаний или практики где-то не хватает — мы подготовили для тебя два мощных практических вебинара от Senior-разработчика Артёма Шумейко. Минимум теории, максимум практики, и, как всегда, простым языком на реальных примерах.
На вебинар ты:
— разберёшься в ключевых принципах аутентификации и авторизации через сессии и токены
— вместе с Артёмом Шумейко напишешь приложение, в котором реализуешь оба подхода.
После такого пошагового практикума ты будешь понимать, как строить безопасную систему входа в приложение.
ЗАРЕГИСТРИРОВАТЬСЯ
На вебинаре ты:
— разберёшь теорию кэширования: уровни, механизмы, типы хранилищ;
— поймёшь, где и зачем применять разные виды кэша;
— разберешься, как бэкендер может снизить нагрузку на бэк в десятки раз через кэширование на уровне браузера;
— на практике внедришь 5 уровней кэширования в реальное приложение.
Это тот навык, который отличает джуна от мидла и который особенно ценят работодатели.
ЗАРЕГИСТРИРОВАТЬСЯ
🎉 Всех участников вебинаров ждут подарки.
Обо всём расскажем уже скоро! А пока регистрируйся и следи за новостями канала, чтобы ничего не пропустить
Please open Telegram to view this post
VIEW IN TELEGRAM
Рубрика #проверь_себя
Класс UserRepository является репозиторием с генератором для постраничной загрузки данных пользователей. Какой результат вернет ручка get_users, если отправить запрос
🔥 — решил
🤝 — не решил
Класс UserRepository является репозиторием с генератором для постраничной загрузки данных пользователей. Какой результат вернет ручка get_users, если отправить запрос
GET /users?batch_size=2&limit=3?from fastapi import FastAPI, Query
app = FastAPI()
USERS = ['alice', 'bob', 'carol', 'dave', 'mia']
class UserRepository:
def __init__(self, rows):
self.rows = rows
def paginated_fetch(self, batch_size: int):
for i in range(0, len(self.rows), batch_size):
batch = self.rows[i:i + batch_size]
yield from (row.upper() for row in batch)
@app.get('/users')
def get_users(batch_size: int = Query(gt=0), limit: int = Query(gt=0)):
data = UserRepository(rows=USERS).paginated_fetch(batch_size=batch_size)
return [next(data) for _ in range(limit)]
🤝 — не решил
Please open Telegram to view this post
VIEW IN TELEGRAM
🤝19
Разработчикам надо знать, как устроена аутентификация «под капотом», и как это самому реализовать и встроить на свой сайт.
И чтобы помочь тебе разобраться в этой теме, школа Pytex организовывает вебинар с Senior разработчиком Артёмом Шумейко.
16 декабря в 18:00 МСК ты разберешься:
— В чём разница между аутентификацией и авторизацией
— JWT vs Session: что выбрать и почему
— Как реализовать регистрацию пользователей
— Как работать с JWT токенами и сессиями
— Как организовать работу с базой данных
— Как всё это корректно подключить на фронтенде
и сразу реализуешь механику на проекте🔥
Чтобы не пропустить ссылку на вебинар, регистрируйся ⬇️
ХОЧУ НА ВЕБИНАР
И чтобы помочь тебе разобраться в этой теме, школа Pytex организовывает вебинар с Senior разработчиком Артёмом Шумейко.
16 декабря в 18:00 МСК ты разберешься:
— В чём разница между аутентификацией и авторизацией
— JWT vs Session: что выбрать и почему
— Как реализовать регистрацию пользователей
— Как работать с JWT токенами и сессиями
— Как организовать работу с базой данных
— Как всё это корректно подключить на фронтенде
и сразу реализуешь механику на проекте🔥
Чтобы не пропустить ссылку на вебинар, регистрируйся ⬇️
ХОЧУ НА ВЕБИНАР
👍8❤3🤝2
#Дайджест
2025 год почти подошел к концу, у кого-то уже в наушниках играет «Last Christmas». Заиграла мелодия в голове? Только честно! 😉
У нас уже готовы крутые активности для тебя: 2 практических вебинара и подарки. Смотри ниже, что тебя ждет на этой неделе и заноси в календарь, декабрь будет интересным.
❄️ Уже завтра в 18:00 МСК пройдет практический вебинар «Пишем систему аутентификации и авторизации: сессии и токены» со спикером Артёмом Шумейко.
Что будет на уроке:
— понятная теория сессиям и JWT токенам
— практика: разберём на реальном приложении, как работает аутентификация
— ответы на вопросы от Senior разработчика
Если ты все еще не с нами, регистрируйся по ссылке ⬇️
ЗАПИСАТЬСЯ НА ВЕБИНАР ПО АУТЕНТИФИКАЦИИ
❄️ 18 декабря в 18:00 МСК вебинар «5 слоёв кэширования в веб-приложениях» со спикером Артёмом Шумейко.
ЗАПИСАТЬСЯ НА ВЕБИНАР ПО КЭШИРОВАНИЮ
2025 год почти подошел к концу, у кого-то уже в наушниках играет «Last Christmas». Заиграла мелодия в голове? Только честно! 😉
У нас уже готовы крутые активности для тебя: 2 практических вебинара и подарки. Смотри ниже, что тебя ждет на этой неделе и заноси в календарь, декабрь будет интересным.
❄️ Уже завтра в 18:00 МСК пройдет практический вебинар «Пишем систему аутентификации и авторизации: сессии и токены» со спикером Артёмом Шумейко.
Что будет на уроке:
— понятная теория сессиям и JWT токенам
— практика: разберём на реальном приложении, как работает аутентификация
— ответы на вопросы от Senior разработчика
Если ты все еще не с нами, регистрируйся по ссылке ⬇️
ЗАПИСАТЬСЯ НА ВЕБИНАР ПО АУТЕНТИФИКАЦИИ
❄️ 18 декабря в 18:00 МСК вебинар «5 слоёв кэширования в веб-приложениях» со спикером Артёмом Шумейко.
ЗАПИСАТЬСЯ НА ВЕБИНАР ПО КЭШИРОВАНИЮ
На вебинаре ты:
— разберёшься в ключевых принципах аутентификации и авторизации через сессии и токены
— вместе с Артёмом Шумейко напишешь приложение, в котором реализуешь оба подхода.
После такого урока ты будешь уметь строить безопасную систему входа в приложение.
🎁 Всех участников вебинара ждут подарки.
Еще не поздно зарегистрироваться на вебинар и получить максимум пользы в декабре⬇️
ХОЧУ НА ВЕБИНАР ПО АУТЕНТИФИКАЦИИ
Please open Telegram to view this post
VIEW IN TELEGRAM
Сегодня в 19:00 МСК пройдет повтор вебинара «Пишем систему аутентификации и авторизации: сессии vs JWT токены» в записи
На вебинаре Senior разработчик Артём Шумейко:
— разобрал ключевые принципы аутентификации и авторизации через сессии и токены
— показал, как реализовать оба принципа в приложениях.
Для тех, кто не успел подключиться вчера, сегодня в 19:00 МСК пройдет повтор в записи, ссылка на вход придет в бот
ЗАПИСАТЬСЯ НА ПОВТОР
На вебинаре Senior разработчик Артём Шумейко:
— разобрал ключевые принципы аутентификации и авторизации через сессии и токены
— показал, как реализовать оба принципа в приложениях.
Для тех, кто не успел подключиться вчера, сегодня в 19:00 МСК пройдет повтор в записи, ссылка на вход придет в бот
ЗАПИСАТЬСЯ НА ПОВТОР
3 проблемы кэширования, о которых часто забывают
Представим интернет-магазин. На главной странице показываются «Топ-товары недели». Если кэширования нет, сервер каждый раз обращается к базе данных и пересчитывает список. Это медленно и тратит ресурсы. С кэшом всё проще: однажды сформированный список сохраняется в быстрый хранилище, и при следующих запросах отдаётся прямо оттуда. Страница загружается быстрее, а база данных получает меньше нагрузки.
Что может пойти не так
Допустим, мы хотим показывать к товарам ещё и рейтинг из внешнего сервиса. Чтобы не дергать его постоянно, мы кэшируем рейтинг. Но если API рейтингов отвечает медленно, приложение зависает в ожидании ответа. Мы ставим короткий timeout: если сервис не успел — отдаем данные без рейтинга. Проблема в том, что рейтинг не попадает в кэш, потому что запрос не завершился. В итоге при каждом запросе мы снова пытаемся достучаться до API → растёт нагрузка.
Когда база «лежит», кэш может спасать, потому что мы просто продолжаем отдавать ранее сохранённые товары. Но если TTL «топ-товаров» истёк в момент сбоя, данные пропадут. Лучше уметь отдавать устаревший кэш чуть дольше: пусть информация не новая, зато пользователь не видит пустую страницу.
Если сотни пользователей одновременно открывают главную страницу, сервер может получить сотни одинаковых запросов на получение «топ-товаров». Без механизма объединения такие запросы будут обрабатываться по отдельности → лишняя нагрузка. Грамотное кэширование позволяет всем «ожидать» результат первого запроса, не повторяя работу много раз.
Если хочешь глубже разобраться в теме и увидеть, как кэширование работает в реальном приложении, присоединяйся 18 декабря в 18:00 МСК к вебинару «5 слоёв кэширования в веб-приложениях».
ЗАПИСАТЬ НА ВЕБИНАР ПО КЭШИРОВАНИЮ
Представим интернет-магазин. На главной странице показываются «Топ-товары недели». Если кэширования нет, сервер каждый раз обращается к базе данных и пересчитывает список. Это медленно и тратит ресурсы. С кэшом всё проще: однажды сформированный список сохраняется в быстрый хранилище, и при следующих запросах отдаётся прямо оттуда. Страница загружается быстрее, а база данных получает меньше нагрузки.
Что может пойти не так
1. Неправильное наполнение кэша
Допустим, мы хотим показывать к товарам ещё и рейтинг из внешнего сервиса. Чтобы не дергать его постоянно, мы кэшируем рейтинг. Но если API рейтингов отвечает медленно, приложение зависает в ожидании ответа. Мы ставим короткий timeout: если сервис не успел — отдаем данные без рейтинга. Проблема в том, что рейтинг не попадает в кэш, потому что запрос не завершился. В итоге при каждом запросе мы снова пытаемся достучаться до API → растёт нагрузка.
2. Пропажа данных во время сбоев
Когда база «лежит», кэш может спасать, потому что мы просто продолжаем отдавать ранее сохранённые товары. Но если TTL «топ-товаров» истёк в момент сбоя, данные пропадут. Лучше уметь отдавать устаревший кэш чуть дольше: пусть информация не новая, зато пользователь не видит пустую страницу.
3. Дублирование запросов
Если сотни пользователей одновременно открывают главную страницу, сервер может получить сотни одинаковых запросов на получение «топ-товаров». Без механизма объединения такие запросы будут обрабатываться по отдельности → лишняя нагрузка. Грамотное кэширование позволяет всем «ожидать» результат первого запроса, не повторяя работу много раз.
Если хочешь глубже разобраться в теме и увидеть, как кэширование работает в реальном приложении, присоединяйся 18 декабря в 18:00 МСК к вебинару «5 слоёв кэширования в веб-приложениях».
ЗАПИСАТЬ НА ВЕБИНАР ПО КЭШИРОВАНИЮ
Сегодня четверг, а значит в 18:00 МСК стартует второй новогодний вебинар с Senior разработчиком Артёмом Шумейко на тему кэша.
На вебинаре ты:
— разберёшь теорию кэширования: уровни, механизмы, типы хранилищ
— поймёшь, где и зачем применять разные виды кэша
— на практике внедришь 5 уровней кэширования в реальное приложение
🎁 Всех участников вебинара ждут подарки.
Еще не поздно зарегистрироваться на вебинар и получить максимум пользы в декабре⬇️
ЗАПИСАТЬСЯ НА ВЕБИНАР ПО КЭШИРОВАНИЮ
На вебинаре ты:
— разберёшь теорию кэширования: уровни, механизмы, типы хранилищ
— поймёшь, где и зачем применять разные виды кэша
— на практике внедришь 5 уровней кэширования в реальное приложение
🎁 Всех участников вебинара ждут подарки.
Еще не поздно зарегистрироваться на вебинар и получить максимум пользы в декабре
ЗАПИСАТЬСЯ НА ВЕБИНАР ПО КЭШИРОВАНИЮ
Please open Telegram to view this post
VIEW IN TELEGRAM
🤝4
This media is not supported in your browser
VIEW IN TELEGRAM
Мы завершили серию новогодних вебинаров с senior разработчиком Артёмом Шумейко
Спасибо всем, кто был с нами на уроках, задавал вопросы, писал комментарии и делился обратной связью 💚
Прочитали под сотню комментариев, что вам зашли эфиры! Мы очень постарались сделать уроки максимально полезными с точки зрения теории и примеров.
Раз вам понравился такой формат, мы постараемся чаще проводить открытые уроки 🙌🏻
Спасибо всем, кто был с нами на уроках, задавал вопросы, писал комментарии и делился обратной связью 💚
Прочитали под сотню комментариев, что вам зашли эфиры! Мы очень постарались сделать уроки максимально полезными с точки зрения теории и примеров.
Раз вам понравился такой формат, мы постараемся чаще проводить открытые уроки 🙌🏻
❤20
Protocol в Python: шпаргалка для разработчика
Если ты до сих пор строишь зависимости через базовые классы и ABC, пора взглянуть на Protocol
Он позволяет описывать поведение без наследования, упрощает архитектуру и делает код гибче и чище.
На картинках всё, что действительно нужно знать про Protocol в Python⚡️
Если ты до сих пор строишь зависимости через базовые классы и ABC, пора взглянуть на Protocol
Он позволяет описывать поведение без наследования, упрощает архитектуру и делает код гибче и чище.
На картинках всё, что действительно нужно знать про Protocol в Python
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM