Гуманный аналитик

🎬 Подборка видео-собеседований

Некоторое время назад я задался вопросом, что происходит на рынке труда, поспрашивал вокруг (например, здесь). И информация такова, что ряд крупных компаний с конце прошлого года резал проекты вместе с сотрудниками.

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

🔶 T-Банк | Junior системный аналитик
🔶 Предположительно МТС | Middle/Middle+ системный аналитик (реальное 🔥)
🔶 Просто тестовое | Middle/Middle+ системный аналитик

Также рекомендую ознакомиться со следующим:
🔶 Моя предыдущая подборка собесов
🔶 Разговор с рекрутёром о найме в 2025

И на закуску несколько видео про System Design. Обычно в таком формате аналитиков не спрашивают, но отдельные элементы дизайна могут встречаться. Если же вы будете претендовать на позицию архитектора, то вероятность столкнуться с такого рода задачами сильно возрастает.

🔶 Lamoda Tech | Доклад про проектирование систем
🔶 T-Банк | Доклад про то, как подготовиться к собесу
🔶 T-Банк | Моковый собес – проектирование системы бронирования номеров в отелях
🔶 T-Банк | Моковый собес – проектирование системы проведения A/B-тестирования

#подборки #собесы #проектирование

Сегодня хочу поделиться с вами статьёй Алекса Сюя (автора книги по системному дизайну) на тему различных видов API. https://blog.postman.com/api-protocols-in-2023/

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

Отдельной похвалы заслуживает иллюстрация в стиле "всё в одном". Помимо смыслового наполнения Алекс с помощью различных размеров секторов на круговой диаграмме проиллюстрировал относительное распространение той или иной технологии по состоянию на конец 2023г. Собственно, эту картинку я и прикрепил к данному посту.

Также, пользуясь случаем, напомню, что ранее я делал достаточно глубокое сравнение веб-сервисов (ссылка). Так что материалы должны неплохо дополнять друг друга. Пользуйтесь 😉

#интеграции #сервисы #проектирование

📖 "Мифический человеко-месяц, или Как создаются программные системы" Фредерика Брукса

Ну вот добрался я до обзора этой довольно известной работы.

🌟 Содержание. Книга достаточно интересна хотя бы тем, что позволяет посмотреть на историю развития индустрии разработки ПО и проследить за мыслями о сложностях и размышлениями, которые возникали на этом пути у автора.

На страницах книги чëтко прослеживаются идеи, которые годы спустя мир узнал уже под "этикетками": Agile, микросервисная архитектура, быстрое прототипирование, выпуск пилотов/MVP, версионирование, инкрементальная разработка и пр. Всё ли это придумал Брукс? Конечно, нет, но, как минимум, это занимало его мысли.

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

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

🍯 Ложка дëгтя. Во-первых, слог автора не всегда простой. Но точно не критично. Во-вторых, не все мысли и термины понятны и релевантны современности. 1-е издание книги (а это костяк) вышло в свет в 70-е годы, а значит опирается на ещё более ранний опыт и подходы. Что тут можно сказать: если какая-то глава вообще "не идёт", еë (благодаря тому, что это независимые эссе ☝️) можно пропустить без особых потерь для понимания остальной части книги.

🧙‍♂️ Резюме. Не смотря на всю "бородатую" историю, книга, как я уже отмечал, будет полезна широкому кругу читателей от разработчиков до менеджеров. В конце концов, многие до сих пор полагают, что добавление людей в проект линейно и предсказуемо уменьшит сроки на его выполнение.

📜 Бонус для тех, кто любит читать выжимки и краткие изложения. В Википедии для вас есть 2 коротенькие статьи по материалам данной книги. Читаем здесь и здесь.

#книги #методыуправления #программирование #нетленка

Не знаю, как у вас, а я в последние дни часто наблюдаю сложности с доступом к ресурсам в сети. И это касается не только веб-сайтов, но и работы различных приложений на телефоне: вместо элементов UI с контентом отображаются мерцающие контуры. Знакомо? Вот по этому случаю у меня для вас краткий ликбез 🤓.

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

#uxui #термины

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

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

#психология

Вчера Сбер представил руководство по созданию AI-агентов. В документе излагаются:
🔹 теоретические основы разработки AI-агентов;
🔹 имеющиеся архитектурные подходы;
🔹 принципы разработки мультиагентных систем.

Скачать данный гайд можно в соответствующем разделе базы знаний официального сайта (ссылка). Также для удобства продублирую данный документ в первом комментарии 👇.

P.S. Когда я в прошлый раз размещал подобного рода документ от Google (ссылка), кто-то их подписчиков поставил дизлайк 😳. Скромно надеюсь, что данная работа ему понравится больше.

#книги #ai #сбер

🤔 Мысли об устойчивости и интерпретациях этого понятия

Много лет назад применительно к разработке сетевых протоколов был сформулирован принцип устойчивости (robustness principle), известный как закон Постела (Postel's law). Его формулировка: "Будь консервативен в том, что делаешь, и либерален в том, что принимаешь от других".

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

На стороне получателя же это можно трактовать так, что надо подходить гибче, игнорировать незначительные нарушения и предусматривать план "Б", не "падая" по пустякам. Какие это могут быть действия (моя версия):

💡 Игнорировать неизвестные (дополнительно появившиеся) поля, свойства, параметры. Причина их появления может быть самой разной, в том числе развитие схемы API.
💡 Использовать, где это возможно по смыслу, разумные умолчательные значения и типы данных, допускающие неопределённое значение (nullable).
💡 Обрабатывать отсутствие некритических для сценария значений (иллюстрация на примере скрытия кнопки в GUI здесь).
💡 Применять схемы проверок данных, игнорируя незначительные ошибки, не влияющие на семантику (например, лишние пробелы, неверный регистр символов, отличный от ожиданий формат даты-времени).
💡 Быть готовым принимать иные, но совместимые типы данных, например, когда числовые и булевы значения поступают в форме строк.
💡 Не закладываться на порядок следования ключей в объектах JSON, даже если в примерах ваши смежники всегда выдерживают один и тот же порядок.
💡 Если это несущественно, игнорировать вложенность полей (скажем, если поставщик данных практикует частую модификацию структуры, а вам требуется по ID найти небольшое число полей).
💡 Стараться мягко обрабатывать неопределённости, когда поступают неполные и/или противоречивые данные (например, восстановление состояния по доступным данным, запрос недостающих данных, организация переспросов клиента).
💡 По возможности предусматривать обобщённую логику обработки при отсутствии обязательных параметров (например, если нельзя ответить конкретному клиенту специфически, поскольку в запросе не был передан его идентификатор, то можно ответить более общо на ту же тему).
💡 Предвидеть возможные нарушения хронологии при асинхронном взаимодействии (условно, логически второе событие может поступить раньше первого) и дублирующие/повторные данные.

Наверняка, список можно продолжить, но я остановлюсь на этом.

Что ещё ☝️
Поскольку списка официальных и авторитетных рекомендаций нет, то практика применения принципа устойчивости складывается по принципу: "Я художник, я так вижу". В частности, мне довелось несколько раз столкнуться с мнением, что намеренная передача внутри JSON различных типов в форме строк (например, вместо true нужно "true") — это тоже следование принципу устойчивости.

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

#проектирование #интеграции

UR🙃, или разбираемся с URL, URI и URN

На днях в очередной раз запнулся о термин URI и решил наконец разобраться в вопросе. Обратился к определениям.

📌 URI (Uniform Resource Identifier) — унифицированный идентификатор ресурса. Это общий термин, охватывающий два типа идентификаторов ресурсов: URL и URN. URI служит для уникальной идентификации любого ресурса независимо от способа его нахождения или адресации.

📌 URL (Uniform Resource Locator) — адрес конкретного местоположения ресурса в сети Интернет. URL определяет конкретный путь к ресурсу, включая протокол передачи данных, доменное имя сервера и путь к файлу/странице.

📌 URN (Uniform Resource Name) — уникальное название ресурса, которое не зависит от физического расположения ресурса. Оно используется для постоянного именования объектов вне зависимости от их текущего местонахождения в Интернете.

Определения прекрасные, но, поскольку лично у меня всё равно вопросы остались, решил углубиться и порассуждать. И вот к чему я пришёл.

💡 URL предназначен для точного указания физического местоположения ресурса в сети. URL указывает на ресурс, ключевое — это "где" (место, адрес). Если ресурс перемещён, доступ к нему прекращается (получаем "битую" ссылку) и нужен новый URL.

Примеры: путь к файлу (file://C:/Users/boss/Downloads/pic.png), адрес в интернет (https://t.me/humane_analyst/222), электронная почта (mailto:unsubsribe@spam.ru) и т.д.

💡 URN служит для однозначного определения ресурса независимо от его текущего физического размещения. URN называет объект, ключевое — это "что" (идентификатор, имя). Если ресурс перемещён, его глобальная идентификация остаётся неизменной.

Примеры: UUID, пространства имён (xmlns="http://www.w3.org/1999/xhtml", Namespace="http://www.contoso.com/" и т.п.), постоянные идентификаторы изданий и публикаций (ISBN, ISSN, DOI) и т.д.

💡 Следствие из ранее озвученного: один и тот же идентификатор не может удовлетворять требованиям URL и URN, то есть не может быть способом доступа и идентификатором ресурса одновременно. В этой связи пространство имён при всей его внешней схожести с URL (см. выше) таковым не является, это исключительно URN.

💡 Фундаментально разные цели URL и URN приводят к тому, что с позиции объектно-ориентированной парадигмы URI является родительским классом для классов URL и URN. URL и URN, соответственно, — это дочерние классы (подтипы) для URI. А поскольку примеры URL и URN существуют (см. выше), то URL и URN — это конкретные классы.

💡 URI не сводится к паре URL и URN, есть и другие URI.

Пример 1. Data URI используется для встраивания небольших файлов непосредственно в тело веб-документа. Data URI уникально не идентифицирует ни положение, ни внедряемый файл. Соответственно, Data URI не является URL и не является URN. Вместе с тем ограниченная специализация Data URI и его общность с URI позволяют считать Data URI экземпляром (объектом) класса URI.

Пример 2. Номер телефона в соответствии со спецификацией RFC 3966 (tel:+79211234567) является только URI. Номер телефона не является URL, так как не содержит компонентов для идентификации ресурса в Интернет, и номер телефона не является URN, поскольку URN только называет ресурс, но не говорит, как к нему добраться (а номер телефона позволяет понять, как можно провзаимодействовать с ресурсом и предложить совершить звонок).

Следствие: URI — не просто базовый класс, как говорилось выше, но ещё и конкретный класс.

💡 На практике терминология часто является взаимозаменяемой. Поэтому, говоря, например, про веб-адреса, можно оперировать как термином "URL", так и "URI". Это согласуется с приведёнными выше рассуждениями.

💡 Строго говоря, чтобы идентификатор мог считаться URI, URL или URN, он должен соответствовать определённым форматам.

#проектирование #термины #любопытное

Читаю "Мифический человеко-месяц" Брукса и хотелось бы поделиться выдержкой из конца главы 16. Уж больно она мне понравилась.

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

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

#требования #стейкхолдеры

Друзья, кто-то понимает, что происходит с рынком труда?

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

Автора одного из таких постов даже знаю лично. Буквально несколько месяцев назад он радовался карьерному росту, а тут — бац! — и сократили его вместе с его командой. 🤔

⚡ Покорение новых вершин

Спешу поделиться новостями. Я стал серебряным призёром премии ECDMA Global Awards 2025 в номинации Outstanding Achievement in Technology Innovation! 🏆

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

#события #достижения

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

На текущий момент я сформулировал следующие контринтуитивные факты, осложняющие этот процесс.

🤭 Авторы документации не всегда знают, как работает их система
С учётом того, что практика водопадной разработки становится редкостью, а сложность ПО растёт, многие принятые решения могут остаться "в головах" аналитика и других членов команды (даже если они изначально планировали подразгести завалы и описать позднее). Более того, пройдёт время и детали забудутся. Печальное следствие: уточнение вопросов по документации может увести вас по ложному пути и утвердить в ошибочном знании.

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

Другая причина. Почти всегда новая версия документации разрабатывается на основе предыдущей, и автором не во всех местах могут быть качественно внесены правки (не актуализировано название поля, приложенный макет экранной формы отражает промежуточное видение, JSON с примером обновлён, а пояснение к нему — нет и т.п.)

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

🤯 Документация разработчиков сервиса может не быть полной для потребителя
Казалось бы, этот пункт противоречит ранее сказанному. Но нет. Разные производственные цели у 2-х смежных команд (даже если речь идёт о командах поставщика и потребителя одного и того же сервиса) могут приводить к появлению моделей, не подходящих для смежников. Например, если для полноценной работы с сервисом потребителю дополнительно требуется выстроить взаимодействие с третьей стороной, то этот факт может быть упущен во внутренней документации поставщика сервиса (подобный пример я разбирал в видео).

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

📜 Microsoft в феврале объявила о прорыве в области квантовых технологий, представив чип Majorana 1. Как сообщалось в различных медиа, в основе технологии находятся майорановские фермионы, предсказанные в 1934 г., однако ряд учёных выразил скепсис и возмущение из-за обнаруженных нестыковок в официальной информации. В общем, будем наблюдать.
Подробнее: здесь и здесь.

📜 Протокол авторизации OAuth 2.0 (Open Authorization 2.0) официально стал стандартом RFC. Несмотря на то, что в силу уже сложившейся практики применения данного протокола это мало что меняет, сам этот факт можно считать шагом в сторону унификации.
Подробнее: здесь.

📜 Компания из России создала фотолитограф с разрешением 350 нанометров, сообщается в телеграм-канале мэра Москвы Сергея Собянина. Это первая ласточка, которая в перспективе может позволить создавать в нашей стране собственную микроэлектронику.
Подробнее: здесь.

📜 В Китае запущено массовое производство атомных батареек размером 15х15х5 мм. Данный элемент питания должен прослужить 50 лет. Источником энергии выступает не встречающийся в природе изотоп никель-63, продуктом полураспада которого является нерадиоактивная медь-63, что серьёзно упрощает дальнейшую утилизацию батареек. Но не только КНР смотрит в этом направлении. Буквально 2 дня назад стало известно о разработке из Южной Кореи на базе безопасного углерода-14.
Подробнее: здесь и здесь.

📜 Японская компания Kawasaki анонсировала разработку робо-коня Corleo, на котором можно ездить. Под капотом этого внедорожного "скакуна" водородный двигатель и искусственный интеллект, позволяющий анализировать препятствия и балансировать положение в пространстве. Интересно, при появлении этой разработки на рынке нужно ли будет открывать новую категорию прав?
Подробнее: здесь.

📜 Учёные предложили способ терраформирования Марса. В основе идеи лежит использование наночастиц графена и алюминия, способных нагреть атмосферу красной планеты, что в конечном счёте должно привести к возможности жизни. Не уверен, что это случится в ближайшие годы, но идея колонизации Марса, судя по всему, по-прежнему занимает умы исследователей.
Подробнее: здесь.

📜 Выяснилось, что компания OpenAI, разработавшая ChatGPT, добавила в тексты, генерируемые их моделями, своего рода водяные знаки. Предположение состоит в том, что это сделано намеренно с целью маркировки происхождения текстового контента. Однако реализация вышла спорной, её довольно быстро обнаружили и буквально каждый может эти водяные знаки стереть.
Подробнее: здесь.

#дайджест #4ir #ai #технологии

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

В зависимости от контекста смыслы вкладываются самые разные. И я для себя уложил их вот в такую картину.

#архитектура #майндмап

Немного актуального 😆

#ai #юмор #жиза

📖 "Создание событийно-управляемых микросервисов" Адама Беллемара

Какое-то время назад завершил чтение этой книги и вот, наконец, выбрал время написать о ней свои впечатления.

💡 Содержание. Данная работа описывает создание распределённых систем сквозь призму потоков данных. И если под микросервисами обычно подразумевают отдельные небольшие приложения, общающиеся по сети (как правило, это REST), то здесь автор излагает концепцию и соответствующие паттерны событийно-управляемых архитектур (Event-Driven Architecture, EDA). Всё вращается, скорее, вокруг данных и операций над ними, нежели вокруг функциональности.

Книга относительно небольшая, но это не должно вводить в заблуждение. Погружение в событийный подход и идеи использования брокеров сообщений (кстати, автор настаивает на термине "брокер событий") отнимают довольно много времени и сил. Но это не единственное, что причинит боль. Об этом ниже.

💡 Минусы. Здесь вынужден остановиться подробнее, чтобы ненароком не создать рекламу. Вот они.

👉 Терминология. Автор в стремлении донести мысли вводит собственные термины, в которых порой начинаешь путаться. Плюс на страницах книги легко можно встретить слова вроде "квинтэссенция", "дуальность", "эмерджентность" и "петля гистерезиса".

👉 Слог. Очень тяжко читать длинные предложения типа "масло масленое" с кучей некритичных для понимания слов. Пример (а их много!): "При этом команды могут чрезмерно полагаться на платформу коннекторов для получения и приёма данных и отказаться от рефакторинга своих приложений в собственные приложения, управляемые событиями". Почему "получение" и "приëм" отделены, почему тут хочется отрефакторить (не переделать, не трансформировать) код в своë (а раньше чужое было?) приложение? Или вот: "Все совместно используемые данные публикуются в наборе потоков событий, образуя непрерывный поток..." Так поток или набор потоков — вопрос. Или вот ещё: "...процесс производства нового потока событий..." Звучит как что-то из области тяжёлого машиностроения.

👉 Перевод. Ну, камон, зачем писать вещи типа "масштабное управление микросервисами", когда речь не о масштабах, а масштабировании? Или зачем терзать читателя пассажами вроде такого: "Потребители данных используют ссылку на индексный ID для доступа к данным"? В этом случае, видимо, на масло масленое от косноязычного автора наслоился неудачный перевод. Также часто по тексту видна калька с английского вроде "производство в поток" или "нижестоящий потребитель". А то, что "перезагрузка темы" означает, перечитать топик брокера сообщений с начала, я лично долго не мог понять.

👉 Непоследовательность. К примеру, на странице 100 слово "отфильтровать" предполагает неуспешность проверки и отбрасывание некоторых данных, а уже на следующей странице "фильтр" это про то, что "соответствует необходимым критериям". Для тех же, кто дочитает до 189 страницы, увидит, что фильтрация это что-то вроде сходящегося шлюза или конъюнкции нескольких условий, синхронизирующих параллельные потоки...

Другой пример: на одной странице в рассуждениях используется поле updated_at, а на соседней (при схожих обстоятельствах) — уже updated-at. К слову, опечатки в книге тоже есть.

💡 Резюме. Если вы уже глубоко в теме, то, возможно, эту книгу есть смысл прочитать, чтоб поразмышлять о разных аспектах и неочевидных решениях (хотя туманные формулировки снизят радость знания). Однако ж если вы только планируете погружаться в проблематику событийно-управляемых архитектур и пока слабо представляете себе, что такое брокеры и при чём тут Кафка, то эта книга точно не для вас. Она очень тяжёлая, причиняет много боли и страданий, приходится постоянно возвращаться, перечитывать. В общем, рекомендовать эту книгу к обязательному прочтению не могу.

#книги #архитектура #интеграции

😲 Как не ошибиться в своём имени

Заполняя форму на сайте СФР (это то, что многие по привычке называют пенсионным фондом), столкнулся с ошибкой валидации. Ошибка гласила, что фамилия не соответствует данным СНИЛС. Я перепроверил, всё было правильно.

Но тут вспомнился случай, который произошёл несколькими месяцами ранее на Госуслугах. Тогда не принималась буква "Ё" (сообщение гласило, что используется недопустимый символ) и я посчитал, что это из-за того, что они не учли эту букву у себя при валидации. Тогда я обращался в их техподдержку и анализ привёл к неожиданным результатам.

Суть. Если в вашем ФИО есть буква "Ё", то сложность может возникнуть при заполнении данных с этой буквой. Проблема не в самой букве, а в том, что некоторые производители виртуальных клавиатур для мобильных телефонов не вывели кириллическую букву "Ё" на эту самую клавиатуру. Как же так, спросите вы, ведь при зажатии клавиши с буквой "Е" всплывает вариант с "Ё". Вот тут и кроется проблема.

То, что на некоторых клавиатурах визуально выглядит как русская "Ё", на самом деле является латинской буквой "E с умляутом" (другое название — "E с диерезисом", подробнее). То есть ситуация такая же, как с кириллической "Е" и латинской "E". Побочный эффект: коды этих двух символов различаются и проверка не проходит.

Напоследок хочется сказать, что данная история наталкивает на мысль о том, что при выполнении валидации полей, содержащих ФИО, можно рассмотреть возможность автозамены на "правильную" букву или разработки более специфических сообщений для пользователя. В противном случае этот ребус решат точно не все.

#любопытное

Читая на одном из ресурсов (не буду говорить где) объяснение, зачем нужны очереди и брокеры сообщений, поймал себя на мысли, что автор не оговаривает различий между очередями и топиками. Всё подаётся в куче в контексте событийного взаимодействия. И это натолкнуло на мысль написать данный пост. Поехали!

Очередь (queue) и топик (topic, она же "тема") — это различные подходы к организации взаимодействия между системами.

📌 Очереди предназначены для взаимодействия "точка-точка". Это когда один отправитель посылает сообщение строго одному получателю. Здесь можно привести аналогию с отправкой корреспонденции через классическое отделение почты: только один человек передаёт конверт, бандероль или посылку сотруднику почты и только один получатель (адресат) получит это отправление от сотрудника уже у себя на почте.

📌 Топики предназначены для организации отправки сообщений по принципу "публикация-подписка" (она же "издатель-подписчик"). Это когда отправитель посылает сообщение во вполне определённое место (в брокер сообщений), однако он заранее не знает, подписан ли кто-то на чтение этих сообщений или нет. Более того, подписчиков может быть больше одного и их число может меняться со временем. Если продолжать аналогию с почтой, то можно вспомнить, что каждый может оформить подписку на журнал или газету и регулярно получать свой свеженький экземпляр, отправляемый соответствующим издателем. Аналогия не самая точная, но позволяет понять, что процесс получения одним подписчиком никак не связан с процессом получения другими, а экземпляры каждого подписчика одинаковы.

📌 Что ещё стоит отметить.

👉 Во-первых, очереди обеспечивают обработку входящих сообщений по принципу FIFO ("первый пришёл — первый вышел"). Топики же обеспечивают подобное упорядочение только в границах разделов (партиций, partitions), из-за чего соответствие FIFO можно считать условным.

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

👉 В-третьих, у очередей и брокеров сообщений изначально разные цели. Очередь была придумана для асинхронной интеграции между двумя системами в форме отправки сообщений (отправляется информация о произошедшем событии или "команда" получателю). В то время как брокеры сообщений создавались для реализации построения событийно-управляемых архитектур, в том числе для задач потоковой обработки несколькими независимыми системами. Поэтому, если совсем схематично: сообщение ➝ очередь, событие ➝ топик.

#интеграции #архитектура #термины