🐰 Самый простой способ понять работу RabbitMQ 🐰

В сообществе аналитиков довольно известен этот визуализатор работы Kafka. Я узнала о нём из блога Системный сдвиг, а затем оценила классную рекомендацию по работе с ним от Yet Another Analyst.

Но поскольку я провожу уроки именно по RabbitMQ, стало интересно: А есть ли похожая визуализация RabbitMQ для тех, хочет быстро просто “увидеть”, как оно работает?

Оказывается, есть! И даже несколько:
🔗 TryRabbitMQ
🔗 RabbitMQ Visualizer

Я советую первый. Как с ним работать? Часть 1.


🚦 0. Добавьте producer и queue. Попробуйте соединить их напрямую. Добавьте exchange, соедините всё по схеме: producer → exchange → queue. Что то должно начинать получаться, потому что еxchange — обязательный этап маршрута в RabbitMQ. У связи exchange и queue появился binding — ключевой элемент понимания маршрутизации. Добавьте consumer. Попробуйте соединить consumer с exchange. Что-то снова будет не хватать. Но правильный порядок близок: producer → exchange → queue → consumer.

💥 1. Выберите для exchange тип fanout. Создайте еще 2 очереди и 2 потребителя и привяжите их к exchange. Отправьте сообщение без routing key. Куда оно ушло? Установите разные binding key и отправьте сообщения со случайными с routing key. Что происходит? Удалите один binding. Получает ли эта очередь сообщение? Здесь можно еще поэкспериментировать с ключами, Но основную особенность обменника типа fanout вы уже должны нащупать.

Это первые важные шаги для знакомства с базовой схемой кролика и типом обменника Fanout. Сохраняйте, пробуйте.

В следующем посте расскажу про упражнения для схем с Direct и Topic exchange — не пропустите!

#RabbitMQ #ОчередиСообщений #MessageBroker #SystemAnalyst

🐰 Самый простой способ понять работу RabbitMQ — Часть 2 🐰
🧵 Первая часть

В первой части я поделилась двумя визуализаторами для RabbitMQ:
🔗 TryRabbitMQ
🔗 RabbitMQ Visualizer
И простыми упражнениями, чтобы разобраться с типом обменника fanout.

Теперь давайте посмотрим на обменники типа Direct и Topic.

1) Очистим поле и снова создадим схему: producer → exchange → 3 очереди → 3 consumer'а. Тип обменника — direct. Для binding key укажем key1, key2, key3. Теперь отправим сообщение с routing key = key. Куда попало сообщение? Затем поочерёдно отправим сообщения с ключами key1, key2, key3. Попробуйте также: key1_1, key1.*, key1.#. Если всё сделали правильно — должны появиться мысли про "полное соответствие".

2) Меняем тип обменника на topic. Для binding key задаём: *.low.* , #.spb , *.high.#
Сразу подсказка: . — разделяет ключи, * — заменяет ровно одно слово, # — заменяет 0 и более слов. Пробуем отправлять: key1.low.smr, key1.middle.spb, key2.high.krd, low.smr, key, high и другие. Для полноты картины можно поэкспериментировать с регистром и пробелами.

3) RabbitMQ для практиков: создаём схему с несколькими exchange'ами, соединяем их как на картинке. Пробуем задавать разные типы для обменников, подбирать ключи и очереди, отправлять сообщения с разными routing key. И просто наблюдать, как идёт сообщение. На этом этапе особенно важен подход "А что если?.." и ваша фантазия.

💡 Еще в TryRabbitMQ можно поэкспериментировать с периодичностью отправки и анонимными очередями. Но, на мой взгляд, в визуализаторе эти функции реализованы довольно скучно и не слишком информативно.

📌 В последней части (на следующей неделе) расскажу, что нельзя увидеть в визуализаторе, куда копать тем, кто хочет больше.

#RabbitMQ #ОчередиСообщений #MessageBroker #SystemAnalyst

Как профдеформация и ChatGPT чуть не спасли нам деньги сорвали нам сделку

#выходнойконтент

У нас в семье сейчас важный этап: мы покупаем жильё. Смотрели варианты в разных городах, общались с соседями, ездили на показы. И вот, наконец, тот самый момент: екнуло «хотим». Решили выходить на сделку.

Но поскольку стоимость современной квартиры на дороге не валяется (даже у айтишников), мы, конечно, задавали вопросы и до брони, и еще больше после. Естественно, мы не профессионалы в недвижимости, поэтому изучали «как правильно» и во всю использовали ИИ как помощника.

Как думаете, что могло пойти не так?

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

Там уже мы убеждали, что правда просто хотим квартиру. Дожили.

Моя внутренняя зануда, конечно, уверена: это нормально интересоваться экологическими и геодезическими изысканиями, стоимостью «камер и благоустройства», материалом окон и расположением мусорки (а будет ли сортировка?). А все договора как минимум прогонять через ИИ.

Мой внутренний юморист смеётся: аналитик на работе — аналитик по жизни.

А как у вас проявляется деформация?

📌 Если нужно могу поделиться чек-листом вопросов для покупки жилья. Дайте знать.

#аналитик #недвижимость #chatgpt

🐰 Уже не самый простой способ понять RabbitMQ. Часть 3 🐰
Часть 1
Часть 2

В первых частях я делилась, как легко и быстро разобраться с основами RabbitMQ с помощью визуализаторов. Но у такого способа есть ограничения.

Визуализатор не расскажет: о последнем типе обменников Headers, как устроены dead-letter очереди, какие бывают свойства сообщений, как реализуются режимы доставки at most once, at least once и почему exactly once в RabbitMQ невозможен, что такое федерации, как обеспечивается идемпотентность.

Что делать? Как разобраться и попрактиковаться?

На самом деле, если вы умеете учиться самостоятельно, вам хватит всего двух ресурсов:

1️⃣ Официальный сайт RabbitMQ — там действительно есть всё необходимое: от теории до практики.
2️⃣ CloudAMQP — здесь можно бесплатно развернуть виртуальный брокер и потренироваться с реальным интерфейсом и настройками.

Лично для меня изучение RabbitMQ стало настоящим увлекательным приключением — надеюсь, вам тоже будет интересно!

#rabbitmq #брокеры #очереди #системныйаналитик #интеграции

Статья на хабр, как настроение дня

А как ваше утро понедельника?

Собиралась сделать подборку с конференциями и датами подачи докладов на осень. Но Настя снова сделала это быстрее и полнее)

ChatGPT и отпуск в Калининграде

У нас есть традиция — каждое лето начинать с отпуска в северных регионах.

В этом году выбор пал на Калининград. И за помощью в подготовке к путешествию я обратилась к ИИ!

Как всё происходило:
Сначала я неделю собирала картинки про Калининградскую область в Pinterest на открытой доске. Затем описала чату, какой отдых мы хотим: смесь природы и городов, желание замедлиться, любовь к вечерним прогулкам и джазу, уютные посиделки и много прогулок пешком. Далее дала ссылку на ту самую доску, написала даты поездки и адреса проживания.
Попросила сделать план на хорошую и плохую погоду. А ещё помочь с подбором одежды и мелочей для разных локаций.

📌 В итоге получился вполне удобный план. ИИ реально выручил!

Делюсь с вами уже отредактированной версией (в комментариях), с учётом того, что мы уже вернулись и знаем, что сработало, а что можно было сделать лучше.

Если вы ещё не были в Калининграде — очень советую сохранить мой план и поехать туда в ближайшее время!
Это очаровательное место для отдыха.

И да, замедлиться получилось. 🌿
#отпуск #путешествия #калининград #искусственныйинтеллект #chatgpt

🛠RFC2119 - самый простой стандарт или кладезь информации?🛠

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

Я как любитель простых вещей зацепилась за RFC2119 и его уточнение RFC8174. Они регламентируют использование ключевых слов MUST, MUST NOT, REQUIRED и др. в RFC и некоторых других документах IETF.

❓Что интересного в этом документе❓

1️⃣ Очевидное не очевидно! Казалось бы, максимально чётко всё описано уже в RFC2119, но оказалось, что и это получилось интерпретировать и применять неоднозначно. Поэтому появилось дополнение в виде RFC8174. Наглядный пример: если вам кажется, что вы что-то сделали надёжно и безопасно, стоит дать пользователям просто начать использовать это, чтобы выявить ошибки. А ведь стандарт появился не в самом начале истории RFC, а намного позже, и в его создании участвовали нерядовые сотрудники.

2️⃣ Документ помогает из размытых выражений сделать чёткую мысль. Ещё это попытка привести человеческие слова к "машинопонятным". На этом моменте у вас уже появилась мысль скормить этот стандарт своему ИИ помощнику?

3️⃣ Это попытка прийти к тому самому единому языку из DDD (ubiquitous language), только без DDD. Зато на уровне сразу нескольких индустрий.

4️⃣ Переиспользование требований во всей красе! Теперь такую подачу можно увидеть и в стандартах про сети, и про интеграции, и по UX/UI, и много где ещё.

5️⃣ Не менее интересны пояснения. Например,

"Imperatives of the type defined in this memo must be used with care and sparingly."

“Sparingly”, как подсказал мне переводчик «экономно». Очень интересная формулировка. Как часто мы, как аналитики, думаем об экономности своих требований? А может, уже пора?

6️⃣ Пункт про безопасность я для себя расширила. "Если я где-то использую MUST или SHOULD, нужно проработать последствия, если это не будет выполнено. А если этих последствий нет, то, вероятно, я неверно использовала слово."

7️⃣ Форма написания важна. Важно не просто использовать слова, а ещё и объявить, что именно в таком значении они будут использоваться. Это помогает не искать тайные смыслы там, где их нет, и авторам даёт возможность точнее доносить, что именно они хотели сказать.

Фух.. столько мыслей по такому короткому стандарту, это я еще не начала про RFC7231 рассказывать)

А какие маленькие, но сильные документы заставили вас задуматься и перевернули взгляд на работу?

#RFC #СистемныйАнализ #СистемныйАналитик #требования #документация

Вот и завершился Summer Merge.

Summer Merge - это летняя IT-антиконференция. Концепция проста: собрать с пятницы по воскресенье изнеженных, выращенных на лавандовом рафе айтишников, поселить их в палатки на берегу уже такого родного Русского Берега и устроить настоящий летний лагерь для взрослых.

Здесь есть всё: танцевальные, спортивные, интеллектуальные мероприятия. Каждый вечер - концерты под открытым небом. Иногда отвлекают своими докладами спикеры, но исключительно добровольно :)

Как же люди, привыкшие к офисам с лаунжами и капсулами для сна, добровольно соглашаются на палатки? Все просто! Здесь есть нужная инфраструктура: Души с горячей водой, туалеты, две кофеточки (где, да, раф всё же продают), фудкорт с отличным выбором и бары)

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

Ну и самое главное: здесь встречаются люди из родной и любимой IT-сферы. Это напоминание о том, что мы работаем не с безликими аватарками, а с настоящими живыми людьми.

Как и в прошлом году искренне рекомендую. Как только появятся даты следующего SM бронируйте себе выходные.

#SummerMerge #ITивыезд #ITконференции