📋 Подводные камни YAML

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

Ситуацию быстро локализовали, а результат вскрыл факт того, что YAML не так уж и прозрачен. Полученный тогда опыт и другие неочевидности, собранные из открытых источников, я попробовал собрать в кучу. Надеюсь, будет полезно. А вот и сама "куча" 🤭: https://telegra.ph/Pitfalls-of-YAML-03-27.

Кстати, я ранее делал пост со сравнением ряда текстовых форматов. Там YAML тоже есть, так что рекомендую.

#форматы #статьи #гайды

В этом году, насколько я могу судить, искусственный интеллект переживает очередную волну интереса. И если раньше всё крутилось вокруг ML, то в последнее время всё чаще в фокусе находятся AI-агенты.

В свете этого хочу поделиться вышедшим в этом году документом (в оригинале — whitepaper) от компании Google. Это достаточно понятное чтиво, которое позволит понять идею и принципы, на которых строятся AI-агенты.

Ссылка: здесь, ссылка для скачивания: здесь.

Для удобства в первом комментарии к данному посту 👇 размещу переведённую на русский язык версию. В целом неплохо, но в примерах на Python есть ляпы (может, ИИ переводил?👀), так что по необходимости рекомендую обращаться к оригиналу.

#книги #ai

Прочитал в одном профильном ТГ-канале новость о создании обширного глоссария для системных аналитиков с призывом пользоваться. Подумал, что это, наверное, неплохо. Да, с одной стороны, есть глоссарий в конце BABOK, но, быть может, у ребят больше уклон на технику?

И вот добрался я до оного (ссылка). Первое, что насторожило, это изображённый робот. Почему? Но этот вопрос стал проясняться, когда я при беглом пролистывании увидел термины: "дым-тест" 🚬, "загрузка баланса" 💰, "релиз-ноты" ♪♬. А чего только стоит красивое русское слово "рефайнмент"! В общем, рука-лицо…

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

Остаётся только вопрос: неужели нельзя было "причесать" созданный нейронкой текст? 🤷‍♂️ Даже если предположить, что это не нейронка, а условный гугл-переводчик, то от этого не легче.

📣 CodeFest 15 в Новосибирске

Друзья, спешу с новостью. Как вы, наверное, знаете, 31 мая – 1 июня в Новосибирске пройдёт 15-й по счёту CodeFest. А вот и сама новость: программа секции по системному анализу свёрстана. Поэтому, если кто-то ждал определённости, чтобы решить, идти ли на конференцию, то вот она 👉 https://15.codefest.ru/program/sa

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

#события #выступления #анонсы #codefestru

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#любопытное

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

📜 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 #технологии

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.iss.one/humane_analyst/222), электронная почта (mailto:[email protected]) и т.д.

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

Примеры: UUID, пространства имён (xmlns="https://www.w3.org/1999/xhtml", Namespace="https://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, он должен соответствовать определённым форматам.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#психология

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