Отзыв на курс Advanced, запоздалый немного, но вот только созрел)

Когда отзыв приходит не сразу — это тоже хорошо.
Значит, человек не просто посмотрел курс, а пожил с ним.

Вот кусочек одного такого отзыва на курс Advanced:

«Сейчас пробую свои собственные проекты писать по этой же структуре и все реально легко работает, прописал основные моменты и дальше остается только описывать апишку и шаги тестов, все работает красиво с первых дней)».

✔️ Вот за это я и люблю поздние фидбэки.

Курс отлежался в голове, прошёл через пару шишек, и вдруг всё встало на свои места.

Читаемость, структура, простота — это не случайно.

🔥Вот ради этого и делался Advanced.
Весь курс построен так, чтобы после него можно было не “переизобретать”, а спокойно писать API-тесты на понятной архитектуре, без боли и гадания, «как бы тут лучше».

И самое приятное — когда люди возвращаются за следующей ступенью.
Значит, не просто зашло, а стало частью рабочего процесса.

Спасибо за отзыв — и жду на 🏆 про-уровне, когда придёт время.

Полный отзыв можно прочитать тут.

——————————-

📱 TG-сообщество

📱 Обучение

📱 Отзывы

“Ты не хуже, просто у тебя не было нужного тренера.”

Недавно мой ученик написал:

«К нам пришёл человек с 4 годами опыта в автотестах — и он знает ровно столько же, сколько я.»

Он добавил:

«я хотел сказал, что с таким учителем как ты я развил потенциал и опыт меньше чем за год.»

Это не про меня. Это про силу правильного подхода.
Про то, как практика, структура, и обучение дают больше, чем 4 года «просто работы».


Что даёт результат быстрее опыта в вакууме?
• Фокус не на инструментах, а на понимании архитектуры
• Практика, приближённая к реальным задачам на проекте
• Преподаватель, который объясняет


Если ты:
• Хочешь не просто «писать тесты», а строить фреймворки
• Чувствуешь, что время идёт, а прогресса нет
• Или уже в тестировании, но хочешь расти как инженер —
присоединяйся.

Ты не отстаёшь. У тебя просто ещё не было правильной траектории.

——————————-

📱 TG-сообщество

📱 Обучение

📱 Отзывы

Fuzzing тестирование API

В этом канале мы с вами рассматриваем преимущественно темы автоматизации тестирования API.

У меня все никак не доходили руки рассказать про инструмент, который вы возможно даже использовали и который занимается fuzzing тестированием.

🔍 Что такое фаззинг-тестирование?

Фаззинг (fuzzing) — это метод автоматического тестирования, при котором программа проверяется на уязвимости и ошибки с помощью передачи случайных или полу-случайных данных на вход. Цель — найти краш, утечку памяти, неожиданное поведение или уязвимости безопасности.

🧩 Виды фаззинга:

- Мутационный фаззинг — изменяет существующие входные данные (например, искажая корректный JSON).

- Генеративный фаззинг — создает данные с нуля на основе спецификации (например, OpenAPI/Swagger).


А теперь собственно про сам инструмент.

⚡️ Schemathesis — фаззер для API

Schemathesis — это инструмент для тестирования API, основанный на OpenAPI/Swagger-схеме сервиса. Он автоматически генерирует тестовые сценарии и "обстреливает" ваш API некорректными или неожиданными данными, чтобы выявить:

- Ошибки сервера (500 Internal Server Error)
- Уязвимости (SQL-инъекции, XSS)
- Проблемы валидации
- Неожиданное поведение

🚀 Как работает?

1. Берет схему OpenAPI/Swagger.

2. Генерирует корректные и некорректные запросы на основе property based testing.

3. Отправляет их в API и анализирует ответы.


🔧 Пример использования:

pip install schemathesis  
schemathesis run https://example.com/openapi.json  

Или с кастомными параметрами:

schemathesis run --checks all --max-response-time 5000 http://api.example.com/schema.json

💡 Зачем это нужно?

- Находить баги до продакшена.
- Улучшать отказоустойчивость API.
- Автоматизировать тестирование безопасности.

На практике имеет смысл использовать скорее если вы вылизываете свое API и у вас есть ресурсы, чтобы упороться, кривые схемы будут порождать огромное количество ошибок которые с высокой долей вероятности никто не будет править.

Инструмент безумно простой в использовании и очень эффективный, в целом можно внедрить отдельной не блокирующей гитлаб джобой с заделом на будущее. Кстати недавно обнаружил, что он еще умеет в GraphQL

Думаю добавлю урок с этим инструментом в курс Advanced, лишним не будет)

——————————-

📱 TG-сообщество

📱 Обучение

📱 Отзывы

Всем привет!
Поздравляю с прошедшими майскими праздниками, но.

Майские - закончились. Время включаться.

Шашлыки -были. Отдых - был.
Теперь - время расти как инженер.

Сегодня стартует новый поток курса по API-автотестированию.
И это последний день, когда можно впрыгнуть в этот поток.

После этого набор закрываю.

Если ты хочешь:
- разбираться в архитектуре
- писать уверенный продакшн-код
- не просто “ковыряться в Postman”, а строить фреймворки

Переходи по ссылке и выбирай нужный модуль.

Успей сегодня.

Работаем.

——————————-

📱 TG-сообщество

📱 Обучение

📱 Отзывы

“Если оно ходит как утка… 🦆” — питон не требует паспорта.

А вы знали, что Python поддерживает несколько видов типизации? 🤔

Например:
- 🦆 Утиная
- 🦢 Гусиная
- 📜 Статическая утиная типизация
- 🔍 Статическая типизация

В этом посте поговорим про ту типизацию, которая изначально была в Python — Утиную.

Одно время я все никак не мог понять, что это такое. Если вы уже в теме — отлично! Если нет — сейчас расскажу.

Python — язык про поведение, а не про формальности. 

Здесь не так важно, от какого класса ты наследуешься.
Важно, что ты умеешь делать!

Пример:
Представь, тебе нужна "последовательность": список, массив, колода карт — не суть.

Python не будет проверять, наследуешься ли ты от `list` или `collections.abc.Sequence`.

Он просто попробует вызвать:

- __len__()
- __getitem__()

Если получилось — значит, ты "последовательность". ✅

class FrenchDeck:  
    def __init__(self):  
        self._cards = []  

    def __len__(self):  
        return len(self._cards)  

    def __getitem__(self, pos):  
        return self._cards[pos]  

🔎 Обратите внимание:  этот класс ни от кого не наследуется!

Но его можно:
- перебирать в цикле,
- брать срезы,
- передавать в `sorted()`, `random.choice()` и т.д.

Потому что он ведёт себя как список!

То есть тебе просто нужно реализовать нужные методы — и этого достаточно.

🦆 Что такое утиная типизация?

“Если что-то ходит как утка, крякает как утка — значит, это утка.”

Такой подход даёт гибкость:
- Можно писать адаптивный код без лишней иерархии.
- Главное — понимать, какие "протоколы поведения" ждёт от тебя Python.

Хочешь разбираться в таких концепциях глубже?
Учись читать поведение, а не только сигнатуры!

——————————-

📱 TG-сообщество

📱 Обучение

📱 Отзывы

Гусиная типизация — когда утки 🦆 недостаточно
(а интерфейс всё-таки нужен)

В Python есть утиная типизация — “если выглядит как утка и крякает как утка — это утка”.
Это удобно. Но не всегда безопасно.

Название «гусиная типизация» возникло как противопоставление «утиной»: если утиная типизация в Python ориентируется на поведение объекта (если у него есть нужные методы — значит, подходит), то гусиная делает акцент на происхождение — как в биологии, где гусей и уток раньше классифицировали по внешнему сходству, но позже стали объединять по общим предкам (кладистика). Аналогично в программировании: два класса могут иметь одинаковые методы (например, draw()), но с разным смыслом — и потому они не обязательно взаимозаменяемы. Гусиная типизация требует явного указания интерфейса через абстрактные базовые классы (ABC) — чтобы быть уверенным, что объекты действительно «родом» от нужного интерфейса, а не просто «выглядят похоже».

Иногда нужно чётко сказать:
“Я реализую этот интерфейс” — и получить защиту на уровне кода.

Вот тут появляется гусиная типизация 🦢.

Что это такое?

Гусиная типизация — это подход к проверке типов во время выполнения, основанный на использовании абстрактных базовых классов (ABC).

Да, в Python нет ключевого слова interface, но есть модуль abc, который позволяет создать интерфейс через абстрактный класс.

Пример:

from abc import ABC, abstractmethod

class MessageSender(ABC):
    @abstractmethod
    def send(self, message: str) -> None:
        pass

class TelegramSender(MessageSender):
    def send(self, message: str) -> None:
        print(f"Отправлено в ТГ: {message}")

class EmailSender:
    def send(self, message: str) -> None:
        print(f"Письмо: {message}")

Теперь можно сделать проверку:

isinstance(TelegramSender(), MessageSender)  # True
isinstance(EmailSender(), MessageSender)     # False

Хотя EmailSender реализует метод send, он не унаследован от MessageSender.
Python этого не “засчитает” — и это отличие от утиной типизации.

❓Для чего это нужно?
- Когда важно явно указать, что ты реализуешь интерфейс
- Когда нужна статическая проверка типов (например, через mypy)
- Когда hasattr() уже не спасает и хочется чёткости и надёжности

✔ Коротко:
- Утиная типизация — поведение важнее наследования
- Гусиная типизация — поведение + явная декларация через ABC
- Поддерживается isinstance(), issubclass() и статическими анализаторами

В Python можно писать и гибко, и строго — выбор за тобой.

Понимание обеих моделей делает твой код читаемым, надёжным и масштабируемым.

В глоссарии Python есть статья посвященная абстрактным базовым классам.

——————————-

📱 TG-сообщество

📱 Обучение

📱 Отзывы

Статическая утиная типизация — когда нужно понять, что это утка, ещё до запуска.

Мы уже с вами узнали:
• Утиная типизация — “если выглядит как утка и крякает как утка — это утка”
• Гусиная типизация — “эта утка официально записана в реестре как утка” (через ABC)

Теперь познакомимся с третьим подходом — статической утиной типизацией через Protocol.

Что это такое❓
Protocol из модуля typing позволяет описать интерфейс по ожидаемому поведению — без наследования.
Если у объекта есть нужные методы — он считается совместимым.

from typing import Protocol

class Writer(Protocol):
    def write(self, data: str) -> None: ...

class FileWriter:
    def write(self, data: str) -> None:
        print(f"Пишу: {data}")

def save(w: Writer, msg: str):
    w.write(msg)

save(FileWriter(), "Привет!")

Обрати внимание: FileWriter не наследует Writer, но типовые анализаторы (mypy, pyright) поймут — всё ок.
Потому что поведение совпадает.


Зачем это нужно❓
• Статическая проверка интерфейсов до запуска
• Без isinstance() и жёсткой иерархии
• Отлично подходит для тестов, моков
• Совместим с mypy, Pyright, Pylance и другими инструментами
• С полной свободой: хочешь — наследуй, хочешь — просто реализуй нужные методы


Утиная типизация была про “смотрим, что умеет объект”.
Статическая утиная — про “давайте это ещё и проверим заранее”.

✔️ Коротко:
• Protocol — это интерфейс без наследования
• Работает по принципу “если поведение совпадает — значит, подходит”
• Используется для статической проверки типов
• Совместим с mypy, Pyright и другими анализаторами

Можем ли мы проверить, что утка это утка используя протокол в рантайме?
Да например так:

from typing import Protocol, runtime_checkable

@runtime_checkable
class Writer(Protocol):
    def write(self, data: str) -> None: ...

class FileWriter:
    def write(self, data: str) -> None:
        print("Пишу:", data)

fw = FileWriter()

print(isinstance(fw, Writer))  # True

🧠 Статическая утиная типизация помогает писать гибкий, но при этом безопасный код.
Это некий баланс между свободой и контролем.


Более подробно про протоколы можно почитать тут.

——————————-

📱 TG-сообщество

📱 Обучение

📱 Отзывы

Впереди выходные, почему бы не уделить это время тюнингу своего гитхаб аккаунта)

💻 Как оформить GitHub-профиль, чтобы он работал на вас.

Если вы пишете код, GitHub — это не просто хранилище кода. Это ваша публичная визитка. Грамотно оформленный профиль помогает:

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

📌 Что можно сделать:
– Создать README для профиля с краткой информацией о себе
– Выделить ключевые проекты и красиво их оформить
– Добавить бейджи, статистику и немного стиля
– Подчеркнуть свою активность, навыки и интересы

Сделать это довольно просто, достаточно просто создать репозиторий с названием своего GH профиля и положить туда README.

👀 Нашёл пару отличных гайдов, которые помогут навести порядок и сделать профиль действительно заметным:

📄 Как информативно оформить профиль на GitHub?
📄 Оформляем README-файл профиля на GitHub

Но сильно не увлекайтесь, слишком много свистелок перделок тоже не есть хорошо))

Если давно хотели прокачать свой профиль, но откладывали — самое время ✌️
А если уже что-то сделали — кидайте ссылки, интересно посмотреть!

——————————-

📱 TG-сообщество

📱 Обучение

📱 Отзывы

Статическая типизация в Python — когда уткам уже не доверяешь 🧊

Python — язык с динамической природой.
Но что, если хочется надёжности уже до запуска?

Добро пожаловать в мир статической типизации.
Без уток, без гусей — просто строгая проверка типов.

🧐 Что это вообще?

Статическая типизация — это когда ты явно указываешь типы переменных, аргументов и возвращаемых значений, а специальные инструменты (например, mypy) проверяют это до выполнения кода.

def greet(name: str) -> str:
    return f"Привет, {name}"

greet("Питон")       # Всё хорошо
greet(123)           # mypy тут же даст ошибку

Python по-прежнему выполнит код, даже если ты передашь int, но анализатор заранее скажет: «что-то не так».

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

📌 Как это работает?
• Используется синтаксис аннотаций (x: int, -> str)
• Проверка идёт снаружи, через инструменты (mypy, pyright, IDE)
• Ошибки ловятся ещё до запуска (в идеале — на этапе CI)

⚖️ Зачем это нужно?
• Уменьшить баги, так как python при запуске не выбрасывает ошибки при расхождении типов.
• Упростить навигацию по коду (IDE покажет сигнатуры, автокомплит и т.п.)
• Улучшить читаемость: ты сразу видишь, что принимает и возвращает функция
• Повысить доверие к чужому коду: «ничего не сломаю, если передам вот это»

На ступени Advanced мы пишем код практически без аннотаций, но на Professional мы уже используем статическую типизацию и инструменты для анализа нашего кода.

🔥 Советы:
• Начинай с простого: добавляй типы в публичные функции
• Используй mypy — он легко интегрируется в проекты
• Не бойся писать Optional, Union, TypedDict, Literal — они реально спасают

✔️ Коротко:
• Python остаётся динамическим, но может быть типизированным
• Статическая типизация помогает ловить ошибки до запуска
• Ты не обязан, но ты можешь — и это делает код сильнее

🎯 Итог:
Утиная типизация даёт свободу.
Гусиная — структуру.
Статическая — уверенность.

А вместе они дают тебе гибкий, читаемый и защищённый код.

Про модуль typing и type hints можно почитать в официальной доке.

——————————-

📱 TG-сообщество

📱 Обучение

📱 Отзывы

Сегодня тестировал библиотеку одного из моих учеников @AndreiDudin с курса Professional.

Записал видео - инструмент автоматизирует настройку линтеров, прекоммит-хуков, генерацию проекта и клиентов к сервисам.

Это первый ученик на курсе, который дошёл до такого этапа - собрал рабочий инструмент, который реально можно использовать в бою. И если честно мне очень приятно наблюдать за тем как это работает))

Проект позволяет автоматизировать ту самую часть которая занимает самую большую часть времени.
И выполняет те вещи, которые обычно приходится делать вручную:

✅ Ставит линтеры и настраивает их по единому стандарту

✅ Настраивает прекоммит-хуки (чтобы не было “залетело в мастер без форматирования”)

✅ Генерирует проектную структуру и клиентов для общения между сервисами

Это уже не просто «учебный проект», это прорыв, ближе к SDET и разработке тулов.

@AndreiDudin один из тех кто пинал меня с этой ступенью и приобрел курс еще до официального старта.
За что ему спасибо.

Горжусь и надеюсь, что это только начало — дальше будет ещё круче 💪

——————————-

📱 TG-сообщество

📱 Обучение

📱 Отзывы

В эти выходные у меня первый выпускник с курса Professional 🥳
Естественно, я радуюсь, как и любой преподаватель)

отзыв на курс по API Professional
Необычный курс. На нем вы не будете писать автотесты) Курс немного про другое: как выстраивать фреймворк, в котором потом будут писаться тесты . И упростить/ускорить развертывание фреймворка с нуля и его интеграцию в CI

Архитектура, полезные либы, линтеры, форматтеры, генераторы кода и подобные вещи. То, что полезно, но приходится собирать из разных мест.

Курс сложный, рекомендую закладывать для себя побольше времени. Но однозначно полезный!
И делать не на винде 😁 т.к. много работы с путями к файлам, а синтаксис несколько различается. Либо держать это в голове. Ну и на ровном месте вылезают разные какие-то "особенности" винды )

Курс рекомендую, очень полезен 👍

Отзыв

Что важно отметить, в курсе действительно собрано очень большое количество информации.

И как я уже говорил он больше про SDET , мы и приводим фреймворк автотестов в порядок, используя лучшие практики и разрабатываем библитеку, которая нам эти тесты с нуля поднимает менее чем за минуту.

Один раз напилив инструмент, мы забываем про проблемы:

- Стандартизации структуры проекта (мы генерируем структуру пакетов проекта)

- Поддержки API клиентов в актуальном состоянии (мы генерируем клиенты и встраиваем их в фреймворк)

- Настройки пайплайнов (мы пишем common pipeline и интегрируем его в шаблоны проекта)

- Написания smoke тестов (мы генерируем код автотестоа)

- Поддержка качества кода (мы настраиваем линтеры, пайплайн и прекоммит хуки)

и многое другое.

Ну, а что касается проблем винды они решаемы, ведь я всегда на связи) ✔️

Я уже открыл запись на следующий поток, который стартует 4 августа.
Хотите не просто писать автотесты, а разрабатывать инструменты, перейти на другой уровень профессионализма, сэкономить часы а может даже и недели времени на разработку автотестов себе или вашей компании жду на тренинге)

Напомню, вы можете согласовать обучение у вашей компании.
У меня уже были ученики из Т-банк, Ингосстрахбанк и других.

——————————-

📱 TG-сообщество

📱 Обучение

📱 Отзывы

Последнее время моей любимой соцсетью стал LinkedIn.

Но, если честно, даже там я чувствую себя не в своей тарелке, потому что он все больше напоминает нельзяграм.

Куча постов в стиле: из-за нейросетей нас всех уволят.
Потом такая же куча постов: да нихрена эти нейросети без человека не могут.

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

Примерно такая же ситуация была, когда я вкатывался в IT, в 2018 году. Я начал вести аккаунт про тестирование в запрещенной социальной сети, у меня в подписчиках было три калеки. Я понял, что нельзяграм - это место еды, жоп, сисек и красивой жизни.

Но потом вокруг IT набрали такой хайп, что аккаунты начали расти как на дрожжах. Но к тому моменту я уже выгорел в этой теме и ушел писать свои кодики в тележку.

Сейчас я всё больше думаю о том, как делать контент, который не только интересен, но и полезен. Хочется писать что-то сложное, чтобы и самому развиваться, и другим помогать. Без хайповых заголовков, без "холиваров ради охватов", а с акцентом на реальную инженерию и глубокие технические темы.

Я могу назвать только двух человек, которые себе не изменяют и за которыми слежу очень давно - это Надя и Артем. И один аккаунт, который мне очень нравится, можно сказать, даже немного завидую - это Егор Векслер (его можете очень просто найти). У него и классная подача, и отменный юмор.

А что касается моего контента - он не про то, как "в два клика сделать какую-нибудь херню нейросеткой", а про техническое погружение в некоторых случаях даже фундаментальные вещи про которые все чаще забывают. У меня довольно сухая информация и если вы здесь я рад, что вам интересны темы, связанные с инженерией, тестированием, автоматизацией, и техническими подходами. Возможно, именно такие люди и помогут мне вернуть веру в ценность технического контента и профессионального комьюнити))

И да, что думаете насчет дублирования контента в разные соцсети? Стоит ли пробовать технические посты в нельзяграм и линк или это совсем не туда?

Ну и поделись, ссылонькой на канал если среди знакомых есть кто пришел в IT не только чтобы зарабатывать 300К\наносек "генерируя код нейросеткой", но и потому что ему реально интересно развиваться в IT-шке.

Ну или может просто причина в том, что я пишу неинтересное говно))

——————————-

📱 TG-сообщество

📱 Обучение

📱 Отзывы

Как вы помните, ранее я проводил опрос о том, какая тема автоматизации тестирования вам была бы интересна.

Ну так вот, вы просили — брокеры сообщений, значит, будут брокеры сообщений!

Кодовая база уже написана, презентации готовы на 40%.

Что будет интересного? Мы будем работать с Kafka и RabbitMQ.

Курс будет независим от ступеней Professional и Advanced, это значит, что он будет максимально емким: никаких Allure, настроек CI и прочего — только брокеры сообщений.

Если в ступени Professional мы уже работали с асинхронным кодом, то здесь я решил раскрыть еще одну тему — многопоточность.

Поэтому рекомендую подтянуть навыки в Python и готовиться к новой ступени!

Курс будет помечен маркировкой Professional, потому что темы сложные.

В конце мы напишем интеграционный сценарий проверки flow регистрации, почти со всеми промежуточными этапами. Flow можно будет посмотреть на этой UML-диаграмме.

В общем, готовьтесь будет интересно!

——————————-

📱 TG-сообщество

📱 Обучение

📱 Отзывы

Ложное качество кода

Сейчас многие начали слишком сильно полагаться на нейросети.
Я стал замечать это даже по работам своих студентов.

Сегодня можно просто попросить ИИ:
Сделай мне проект — и он сгенерирует структуру, классы, папочки, комментарии.
На вид — реально как магия. Почти имба.

Но если честно, я и сам довольно ленивый.
Не раз пытался отрефакторить свой код через нейросети.
И пока — ни одной попытки, которую хотелось бы просто взять и влить в мастер.

Например, у меня есть библиотека, о которой я уже упоминал — restcodegen.
Даже если подробно расписать промт, ИИ начинает генерировать лавину кода —
и в какой-то момент даже я уже не понимаю, что и зачем там сделано. Класс на 500-600 строк может разбить на 3-4 файла где в каждом по 500-600 строк!!!

Иногда нейросеть скатывается в оверинжиниринг:
- Создаёт десятки протоколов и абстрактных классов
- Распиливает методы до супер-атомарного состояния
- Пишет публичный метод, который вызывает точно такой же приватный — и ты сидишь и думаешь: зачем?

Для кого-то это может выглядеть как «код сеньора».
Но по факту — это просто усложнение ради усложнения.

Настоящий сеньор знает, когда использовать интерфейсы и паттерны, а когда — просто обычную функцию.

Тем не менее, ИИ — это очень мощный инструмент.
Игнорировать его в 2025 — всё равно что отвергать IDE и писать в блокноте.
Но, как и с любой мощной штукой, важно уметь правильно применять.

Мои рекомендации по использованию ИИ в разработке:
✅ Решайте задачи атомарно.
Каждый шаг — с фиксацией в git.
Если пустить нейросеть в код без контроля — она может перелопатить всё, и предыдущие промты окажутся бесполезны.

✅ Формулируйте чёткую задачу.
Опишите:
— в чём проблема
— какой способ решения вам ближе
— что должно быть на входе и выходе

✅ Задавайте сигнатуры и контракты.
Чем яснее ожидания — тем точнее результат.
Описывайте, какие типы, поля, методы хотите видеть.

✅ Показывайте примеры и паттерны, которые хотите использовать.
ИИ очень хорошо работает по аналогии — покажите, что вам нравится, и он постарается повторить стиль.

ИИ — это очень крутой помощник, который позволяет делать многое, не заглядывая лишний раз в документацию.

Но он не заменяет понимание!!!

Он усиливает тех, кто и так понимает, что делает.

——————————-

📱 TG-сообщество

📱 Обучение

📱 Отзывы

Про Kafka я уже писал.

Давайте теперь поговорим про RabbitMQ 🐰

Несмотря на то, что эту тему я буду разбирать на тренинге по брокерам, думаю, остальным тоже будет полезно.

Основные понятия, которые нужно знать:
• Publisher — публикует сообщения в Rabbit.
Если сравнивать с Kafka — это producer. То есть сущность, которая шлёт сообщения в обменник.

• Exchange — обменник.
Это точка входа всех сообщений в RabbitMQ.
Publisher публикует в exchange, а он уже раскидывает сообщения по очередям с помощью routing_key.

• Binding — связь между exchange и queue.
Через неё мы указываем: какая очередь получает какие сообщения от какого обменника.

• Queue — очередь.
Здесь лежат сообщения, которые ждут обработки.

• Message — сообщение. Атомарная единица данных.
• Consumer — подписывается на очередь и получает сообщения от Rabbit.


Что важно помнить при тестировании❓

Когда сообщение обработано (т.е. закоммичено), оно пропадает из очереди.
И если вы тестируете прямо на боевой очереди, есть риск:

• либо “украсть” сообщение у продового консюмера (если закоммитите его раньше)
• либо просто не увидеть его, потому что прод его уже съел

Что делать ✔️

Создаём свою тестовую очередь и роутим в неё те же сообщения, что и в боевую.
Так можно тестировать спокойно, не мешая логике основного приложения.

Об этом я подробно расскажу на курсе.

Что ещё важно знать❓

Типы обменников.
Но это — в следующем посте 😉

——————————-

📱 TG-сообщество

📱 Обучение

📱 Отзывы