<|°_°|> Вы ещё не уволились? Тогда мы идём к вам

Вопрос о том, заменит ли ИИ системных аналитиков или других специалистов, уже несколько лет будоражит умы. Но тут появился повод посмотреть на вопрос в несколько ином ракурсе. На Хабре вышла статья (ссылка) о том, что в МФТИ разрабатывают платформу на базе ИИ 🤖, которая позволит предсказывать увольнение сотрудников. Для этого предполагается как-то отслеживать производительность, учитывать стаж и другие параметры.

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

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

#ai #4ir

💡 Забота о клиенте, или снова про AI

В текущем проекте задействуется LLM для принятия решения о дальнейших шагах в программной логике. Если не вдаваться в подробности, то выглядит так. Ты передаёшь в языковую модель запрос клиента и дополнительную информацию, включающую список доступных вариантов: <мнемоника; при каких условиях надо предпочесть её>, а модель должна сделать выбор одного варианта. Это своего рода switch-case из языков программирования, только на стероидах.

Так вот. Одна из моделей, на которых тестировал, напрочь отказывалась выбирать вариант "abort_scenario", хотя по описанию именно он лучше всего подходила под ситуацию. Модель с упорством выбирала другой вариант – "make_decision". В какой-то момент меня осенило: надо прямо спросить модель (это же диалоговая штука): почему она выбирает именно это? И, когда я пойму логику выбора, смогу что-то с этим сделать.

Каково же было моё удивление, когда я увидел объяснение.

Оказалось, что модель считала, что при выборе "abort_scenario" клиент вообще не получит ответа на свой запрос и останется неудовлетворённым (к слову, это не так, но модель не знала того, что предполагалось делать потом). Модель целенаправленно выбирала "make_decision", чтобы данный запрос был передан в работу другому специалисту (видимо, человеку), который смог бы уточнить у клиента его потребность и помочь ему.

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

#ai #4ir #программирование

Что-то в этом есть😅

#юмор #жиза

👀 Видишь легаси? Нет. И я не вижу, но он есть.

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

📟 Средства связи. В Японии до сих пор пользуются факсами. Заметьте, в стране, которую многие ассоциируют с качественными автомобилями, роботами и другими передовыми разработками. Но, как говорится, не факсами едиными. Британские врачи всё ещё активно пользуются пейджерами, словно герои из "Доктора Хауса" или "Скорой помощи".

💾 Носители информации. Для создания резервных копий данных в мире по традиции используется магнитная лента. И буквально на днях выходила новость, что одна компания обнаружила, что их регулярно записываемые бэкапы годами не проверялись на возможность восстановления. Хорошо, обошлось без жертв. Ну а как насчёт типов видов носителей? А вот так. Метрополитен Сан-Франциско до сих пор использует дискеты в своей системе управления поездами, а отказываться от них планируется только в середине 2030-х. Удивляет? Меня точно удивляет. Но ещё больше удивляет то, что, как оказалось, на немецких фрегатах типа "Бранденбург", предназначенных для обнаружения и борьбы с подводными лодками противника, до сих пор используются 8-дюймовые дискеты. Ещё раз: не 3.5" и даже не 5.25", а 8"!

💻 Программное обеспечение. Легаси-системы довольно широко используются в промышленности. На своей первой работе, кстати, я удивлялся устойчивой практике использования языка C (именно "Си", никаких "плюсов") для реализации HMI-систем, работающих под Windows XP. И, судя по прочитанному на просторах всемирной паутины, ситуация за минувшие годы кардинально не изменилась.

👨‍💻 Языки программирования. Наверняка многие слышали, что язык Fortran до сих пор имеет широкое прикладное применение в задачах, связанных с математическими расчётами и наукой. Но, выяснилось, что "старичок" COBOL тоже в строю. Именно на нём на Западе написана куча систем в сфере финансов. Приложения, обрабатывающие транзакции, операции по счетам и ведущие расчёты доходности сложных финансовых инструментов – это всё историческая "вотчина" языка COBOL.

Если у вас есть что добавить по теме, обязательно делитесь в комментариях 👇

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

Сегодня мир отмечает необычный праздник — День числа "пи". Это событие посвящено одной из самых известных математических констант — числу π, которое приблизительно равно 3.14 (поэтому и 14-е марта).

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

Сегодня открыл для себя "съедобные" названия элементов UI для разных типов меню. Гамбургер, дёнер, бенто, кебаб и фрикадельки — ну что может быть лучше? 😋

#uxui #любопытное #термины

Разбирая диаграммы последовательности, время от времени наблюдаю 3 повторяющиеся паттерна странного использования фреймов (фрагментов). Вот они.

1️⃣ Фрейм alt используется для опциональных условий. Это довольно частая ситуация. Возможно, авторы не знают или не понимают, зачем использовать opt, когда есть alt.

2️⃣ Во фрейме alt первая секция полностью пропускается. PlantUML, конечно, позволяет выполнить этот фокус, но вот зачем? Возможно, так хотят добиться выравнивания по левому краю всех проверяемых условий?

3️⃣ Вообще не используется break. Вместо этого может использоваться opt или alt. Авторы, видимо, полагают, что если довести стрелку до пользователя, то сценарий закончится.

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

#визуализация #plantuml #кейсы

📋 Подводные камни 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. Уж больно она мне понравилась.

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

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

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