UML Design *

Скажу честно: я не понимал, зачем нужны SKILL-ы для LLM-агентов. Вот с MCP все понятно: полезная вещь, с помощью которой можно дать LLM доступ к базе данных или к Figma. Единственный недостаток: чтобы не тратить много токенов, желательно не подключать сразу 30 MCP-серверов. И вообще, лучше отключать лишние и подключать только те, которые действительно нужны для задачи. В этом свете SKILL-ы казались мне бесполезным оверхедом, который жрет токены как не в себя. В TikTok часто видел россказни в духе: подключи такой SKILL или сразу целую пачку, и будет тебе счастье. У меня сразу возникала мысль: если подключить их все, лимиты по подписке будут заканчиваться не к обеду, а уже утром.

Всем привет! Скажу честно: я как программист очень устал читать горы текста, которые выдают ИИ-кодинг-агенты. Это прямо больно. В частности, когда ты просишь создать файл plan.md, в котором необходимо описать, что нужно сделать, чтобы написать код с нуля или добавить новую фичу в уже существующий проект, я получаю простыню текста в формате Markdown. Ни прототипов интерфейсов, ни диаграмм, которые визуально объясняют, как все работает и выглядит. Читать - тоска зеленая. Вот куда интереснее смотреть на прототипы UI-интерфейса и диаграммы со стрелочками, которые показывают, как всё работает. Как говорят, лучше один раз увидеть, чем сто раз услышать - пардон, прочитать.

Я сделал редактор, в котором диаграмма последовательности превращается в презентацию с голосом диктора. Диаграмму можно писать кодом Mermaid или собирать мышью, а потом выгрузить как видео или как сайт на GitHub Pages. Попробовать можно здесь.

Всем привет! Меня зовут Анатолий, я работаю ИТ-архитектором в Сбере. Занимаюсь развитием направления клиентской лояльности. Сразу же отмечу, что в этой статье не идёт речь о фундаментально правильных решениях. Скорее, наоборот, речь идёт о решениях компромиссных.

В целом, зрелость архитектурной культуры организации можно оценивать соответствием некому условному уровню. 

Если в вашей компании уже живёт полноценная система для архитектурных решений в виде Aris, Sparx Enterprise Architect или их аналог, и она умеет всё, что нужно: описывать бизнес-сценарии, собирать связанные с ними решения, показывать и согласовывать их с заказчиками, а потом аккуратно складывать в единый архитектурный репозиторий, то тогда, скорее всего, эта статья не для вас. Вы и так всё это проходили.

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

Как описывать не только сервисы и связи, но и реальные бизнес-сценарии внутри распределённой системы? Показываю Magic Flows в Viaduct: пошаговые потоки данных, визуальный плеер на C4-модели, автоматическая sequence diagram и документация, привязанная к конкретному процессу.

Если вы начинающий программист и у Вас нет машины, то лучшее решение - машина Тьюринга (МТ)! Я в этом вам помогу, а еще Макконнел. Но и не только он один.

Первая моя статья на Хабре о машинах Тьюринга это про тяжелый грузовик [1]. А оно такое надо? Начинать лучше с чего-то полегче. Этим и займемся. Хотя основа или, так сказать, базис по большому счету будет один. Но, ведь, между карьерным самосвалом и самой простой «инвалидкой» тоже есть много общего? И то и другое явно не самолет.

В монографиях Макконнела [2], Карпова [3] и еще много где устройство МТ расписано по винтикам, которых не так уж и много. Я, например, когда-то начинал с книги А.Трахтенброта [4].  Также можно, не мудрствуя лукаво, запустить эмулятор МТ. Их  в Инете найти не сложно. И сразу погонять, не вникая в «винтики». Но это для самых отвязных, т.е. тех, кто не боится снести крышу.

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

Подобие конструктора можно найти у Карпова Ю.Г. Но это пара набросков на псевдокоде. Мы же возьмем конкретный язык и конкретную реализацию. А для совсем уж ленивых будет доступен код по ссылке на Git-репозитарий.

Подобно Макконнелу я за «активный обучающий подход». Т.е. следую его заветам. Хотя следовал я им задолго до знакомства  с его идеями. И это даже хорошо, т.к. не отвлекало. В результате я пошел  даже немного дальше. Для анализа алгоритмов использовал не псевдокод, а другой вариант – формальную вычислительную модель и ее реализацию. Такой «математический псевдокод» позволяет делать  анализ проще, глубже и точнее. По результатам написал статью во времена, когда журналы еще издавались [5].

Инструмент: C4 QuietGridLabs. Можно открыть демо без авторизации: проект будет храниться локально в браузере.

Иногда архитектура «есть» — но пользоваться ею невозможно.

На доске лежит схема сервисов. В Confluence живёт описание. Где-то рядом — sequence-диаграмма, которую никто не открывал с прошлого года. ER-модель хранится в другом инструменте. А когда на ревью возникает простой вопрос «какой endpoint обслуживает этот путь?», команда начинает собирать ответ из памяти, догадок, выдумок, ссылок и исходников.

Я больше 15 лет работаю в ИТ, из них около десяти занимаюсь проектированием и системным дизайном. За это время перепробовал немало: Sparx, ArchiMate, Structurizr, Confluence, whiteboard-сервисы. Я не считаю их плохими — у каждого есть свой сценарий и своя аудитория. Но лично у меня постоянно оставалось ощущение разрыва: диаграмма была отдельно, документация отдельно, а живой контекст системы — в голове у людей.

В какой-то момент моими рабочими спасателями стали whiteboard и VS Code, а позже Cursor. В них можно быстро собрать мысль, оставить немного полезного творческого беспорядка и двигаться дальше. Но они не решали главную проблему: хотелось, чтобы система, её связи, сценарии и документация были одной навигационной моделью.

Так появился C4 QuietGridLabs. Это мой экспериментальный редактор, где C4-модель — это каркас проекта. К элементам можно прикреплять документацию, sequence-диаграммы, ER-диаграммы и описание API, а по связям — переходить от общего ландшафта к конкретным участникам взаимодействия.

Детская футбольная школа имеет базу данных детей и их родителей, в которой более 7000 уникальных записей. На данный момент посещаемость, продление абонементов и напоминания об оплате происходять в ручном режиме через ERP‑систему.

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

Цель работы: Автоматизировать процесс контроля оплаты и отправки уведомлений, связав интеграцию ERP‑системы с платежным шлюзом и СМС‑провайдером для увеличения выручки школы.

Проектирование процессов и API‑контракта:

Чтобы автоматизировать процесс и защитить систему от некорректных данных, в наешй работе — это попытки записать ребенка в группу, не соответствующую его возрасту, логика интеграции должна быть строго регламентирована. Валидация данных выполняется на стороне ERP‑системы до того, как транзакция попадет в базу данных.

Схема взаимодействия систем / UML Sequence Diagram

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

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

Внутри 4 практичных артефакта: чек-лист выбора flow, карточка сущности, таблица изменения формы данных и чек-лист точек поломки. А чтобы схема осталась в памяти надолго, я обернула её в кальмара с полипом на лице.

Угадаете, какое изобретение кардинально изменило жизнь человечества?

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

Меня зовут Артур Вартанян, я ведущий контент‑менеджер в компании RUTUBE, арт‑энтузиаст и бывший журналист. В этой статье я вам расскажу, как искусственный интеллект повлиял на нашу культуру и при чем тут изобретение немецкого книгопечатника.

Привет!

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

Если хочет — может раскрыть больше деталей, если нужно наоборот — может скрыть избыточные.

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

Будет PlantUML, JavaScript, HTML и немного разочарования в ИИ :-)

P.S. Не смотрите на то, что читать статью якобы много-много минут. Текста там не много, все код виноват :-)

Введение

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

Но если вы когда-нибудь работали в проекте, который живёт больше пяти лет, в high‑load системе или enterprise‑среде, вы наверняка сталкивались с парадоксом: самые стабильные части системы — это те, к которым никто не прикасается годами.

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

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

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

В рамках исследования я проанализировал ведущий польский сайт (более 4000 вакансий) с вакансиями для IT-специалистов. Отобрал 194 вакансии, где полностью или частично выполняются функции системного аналитика, знакомые российскому рынку. Что получилось…

В этом исследовании я проанализировал крупнейший немецкий сайт вакансий (более 600 000 объявлений), чтобы определить роли, в которых полностью или частично выполняются функции системного аналитика.

В статье рассмотрены названия позиций, требования работодателей, зарплаты, распределение по индустриям и топ работодателей в Германии. Результаты представлены в виде графиков и сопоставлены с данными по рынку США.

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

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

Заставить профессионала работать? Да тут весь Agile построен на том, да и практика подсказывает, что все манифесты и принципы разработки дают как раз базис для того, чтобы ты развивался "без потолка" и имел свой профессионализм и никто тебя не заставлял работать.

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

А вот тут мы сейчас затронули интересный момент. Кто видел хоть раз, как работает команда профессионалов? Вот они и задают фреймворки, ну, или точнее, фреймворки писались с них.

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

Для создания Scrum, SAFe и прочих фреймворков брались успешные команды внутри компаний и описывался процесс, вычленялись церемонии в духе - "что было важного, без каких встреч не обойтись и наделялась их ценность.

Ну вроде бы, окрестили встречи, возвели значимость, дабы коварный зверь бизнеса понимал что,для,чего и зачем и не снес тебе встречу, поставив свою с девизом "я сейчас сам всем скажу как надо работать"-опс, даже корпоративную культуру внутри компании можно задвинуть, ведь даже ценности Agile есть, а от них можно, в интеграции с HR даже цифровизацию профилей задвинуть и тогда мы можем наложить примерно 2 картинки для того, чтобы понять, как и чем должен обладать кандидат (конкретно, что развивать и как связать с обучением в корп.академии и у провайдеров).

За две недели я собрал бесплатный веб-сервис, который генерирует диаграммы по текстовому описанию — без ручного рисования и без мучений с кривыми картинками от ИИ. Ключевая идея: вместо генерации изображений — генерация PlantUML-кода, затем серверный рендеринг в PNG и выдача пользователю. В статье рассказываю, как я проектировал сущности и сервисы, строил микросервисную архитектуру с очередями, поднимал PlantUML-server и MinIO, настраивал мониторинг и деплой, а также танцы с бубнами вокруг локальной LLM — и как меня спас старый ноутбук с GPU. Отдельно — про боль вайбкодинга: где ИИ-агенты помогают, а где требуют жёсткого микроменеджмента и шаблонов промптов.

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

Я покажу, как некоторые подходы из мира программирования (те самые best practices и идеи из Clean Code) помогают рисовать sequence-диаграммы чище и понятнее. 

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

В статье сначала будет немного теоретических рассуждений на эту тему, идея банальная: сложные задачи нужно декомпозировать. Затем рассмотрим это на конкретном примере, разобьём разработку приложения для HR отдела на три шага: 1) описание процесса приёма сотрудников на работу, 2) описание модели состояний для кандидата при прохождении собеседований, 3) генерация кода.

В заключении опишем профит от моделирования, если вы используете ИИ. И профит от ИИ, если вы занимаетесь моделированием.

ArchiMate — это язык моделирования архитектуры предприятия. Я часто о нём слышал, но никогда не пользовался. Он казался мне очень сложным с очень странной солянкой из разносортных объектов, с замороченным десктопным редактором. Изначально мы даже не рассматривали ArchiMate как первый кандидат на реализацию в нашем инструменте моделирования, а больше склонялись к моделям данных, C4, UML, BPMN. И добавили эту нотацию совершенно случайно. Но пока рисовали примеры моделей для статьи я просто обалдевал на сколько ArchiMate клёвый, какими гениями он придуман и зачем ИТ архитекторам могут быть нужны ещё какие‑то языки моделирования.

Мы попробовали описать разные аспекты нашего программного продукта в этой нотации от миссии и стратегической карты до сценария резервного копирования базы данных. В итоге у нас получилось что‑то среднее между небольшим руководством по ArchiMate и тупой неприкрытой саморекламой. Решайте сами полезно для вас это или нет. Статья получилась очень объёмная, смело пролистывайте не интересные разделы.