Приглашаем на Architecture Meetup #2 — 21 мая в 18:30. Обсудим,почему процесс проектирования настолько сложен, как компании внедряют архитектурные репозитории, зачем нужна собственная система RSMА, а также к чему приводит использование архитектурных паттернов.
В программе:
Опыт внедрения архитектурных репозиториев в разных компаниях: что получилось, какие сложности возникают, сравнение разных подходов и несколько советов, как выбрать и внедрить архитектурный репозиторий.
Рассказа о том, как полностью изменился процесс создания архитектурных решений в банке — от ручного рисования разноцветных «детских» схем в Visio до масштабируемой автоматизации, которой пользуются сотни сотрудников, и зачем понадобилось изобретение собственного монстра Франкенштейна — системы RSM.
Обсудим, почему процесс проектирования ИТ-решений сложно представить в виде фиксированного набора задач, как адаптировать процесс проектирования к разным типам изменений.
Как прийти совсем не к тому результату, который ожидался, даже следуя паттернам и принимая на первый взгляд правильные решения.
Где: Офис Альфа-Банка по адресу Москва, Андропова пр-т., 18 к.3, в трёх минутах пешком от метро «Технопарк».
Присоединяйтесь онлайн и офлайн — зарегистрироваться можно по ссылке.
Что такое чистая архитектура: основные особенности
Чистая архитектура — это подход к проектированию систем, который предполагает независимость от фреймворка и вообще от внешних компонентов. Выделяем слой use-кейсов, слой сущностей, UI и презентер — и теперь эти слои и есть наши фреймворки. Поэтому реальный фреймворк в чистой архитектуре можно использовать как инструмент, а не перестраивать весь проект под его ограничения.
Как, по сути, работает чистая архитектура
Какие еще свойства чистой архитектуры важны:
Тестируемость. Это значит, что бизнес-правила могут быть протестированы без UI, без баз данных, без веб-сервера и без любого другого внешнего компонента. Например, у нас может быть фронтенд на React и мобилка на Flutter — и мы при этом всё равно можем менять контракты, не меняя бизнес-правила.
Чистая архитектура независима от информационных хранилищ. Можно поменять PostgreSQL на MongoDB или на любую другую СУБД. При этом работа бизнес-правил не изменится.
Чистая архитектура — это независимость от внешнего сервиса. По факту слой use-кейсов изолирован от внешнего мира, ничего о нем не знает. А знает только о том, как работать в рамках бизнес-системы.
Большой материал о том, на каком проекте была внедрен этот подход и почему выбрали именно его, читайте в блоге.
Яндекс Практикум вместе с изданием N+1 подготовили тест «Голые данные» — он поможет примерить на себя роль аналитика данных и понять, насколько вам близка эта профессия.
Внутри семь несложных и реалистичных задач: например как определить популярность сериала, спрогнозировать цену на бургеры или оценить выгоду от сотрудничества с блогером.
Тест не требует подготовки и будет интересен тем, кто любит задачи на логику и поиск закономерностей. Если вы пока только выбираете направление в IT, возможно, этот тест поможет увидеть, что аналитика — ваш путь.
На практике посмотрим, как новые открытые LLM (DeepSeek, Qwen и другие) могут помочь с рутинными задачами: от анализа требований до проектирования архитектуры. Сравним их с коммерческими аналогами (OpenAI, Anthropic, Google, xAI) — где они выигрывают, а где нет.
Пройдемся по реальным кейсам: как эти модели помогают быстрее разрабатывать API, поддерживать документацию, оценивать решения. А еще обсудим живой пример проектирования MSA для системы e-commerce .
📅 Дата: 25.04.2025
⏰ Время: 15:00-16:00 (мск)
На вебинаре:
✔️ Как LLM решают конкретные задачи архитектора ПО
✔️ Демонстрация проектирования MSA в диалоге с моделью
✔️ Сравнительный анализ открытых и коммерческих моделей
👨🎓 Спикер: Брейман Александр — эксперт Учебного центра IBS, кандидат технических наук, доцент департамента программной инженерии ФКН ВШЭ.
Как попробовать себя в аналитике: бесплатные вводные части курсов
Работа аналитика зависит от его специализации: кто-то исследует данные, кто-то проектирует информационные системы, а кто-то помогает бизнесу принимать решения. В бесплатных частях курсов можно попробовать себя в каждой из этих ролей.
Аналитик данных изучает массивы информации, ищет закономерности и формулирует выводы. В пробном задании предстоит выяснить, почему на фабрике робокотов массово выходят из строя гаджеты. Вы проанализируете данные, построите визуализации с помощью Python, Pandas и Seaborn и попробуете интерпретировать результаты.
Специалист по Data Science использует машинное обучение для прогнозов и поиска скрытых зависимостей. В вводной части вы решите несколько задач: оцените влияние новой опции в игре, классифицируете клиентов кофейни и проверите эффективность роботов в службе поддержки.
Системный аналитик проектирует информационные системы, помогает определить требования и контролирует реализацию решений. На примере реальной задачи разберётесь, как добавить на сайт магазина посуды отзывы с Яндекс Маркета: нужно ли менять интерфейс, как работают API и как фиксируются требования.
Бизнес-аналитик исследует данные компании, выявляет точки роста и помогает улучшать процессы. В бесплатной части курса попробуете себя в роли аналитика: нужно придумать, как отображать аллергены в составе продуктов в приложении доставки еды. Вы узнаете, какие задачи решает бизнес-аналитик на каждом этапе разработки ПО, как взаимодействует с командой и какие требования формирует.
Вебинар «Топ-5 ошибок в моделировании требований системным аналитиком»
8 апреля я проведу бесплатный вебинар: «Топ-5 ошибок в моделировании требований системным аналитиком», где подробно разберу, какие ошибки наиболее часто системный аналитик допускает при моделировании требований, а также расскажу, как их избежать. Запись на вебинар доступна по ссылке.
Что будет на вебинаре:
Что необходимо знать о моделировании требований
Какие ошибки системный аналитик может допустить в работе
Как моделирование требований влияет на процесс разработки ПО
Как избежать ошибок и повысить качество требований
Рассмотрим возможность использования различных видов баз данных в одном проекте/продукте, какие возможности этот подход открывает и какие вызовы стоят перед командами на пути внедрения и эксплуатации.
[RFC] Открытый формат обмена данными об условиях кешбэка COIN
Многие банки и финансовые организации предлагают своим клиентам программы лояльности и/или кешбэк, тем самым повышая интерес к своим банковским/финансовым продуктам и поощряя клиентов за совершение покупок/оплату услуг. К сожалению нет определённого стандарта представления подробной информации об условиях, которые необходимо выполнить для получения вознаграждения/кешбэка (например, количество или общая сумма покупок или определение принадлежности торговой точки к той или иной категории (например, фастфуд или рестораны)).
Необходимо разработать и согласовать специальный общий и открытый формат обмена данными об условиях кешбэка и программ лояльности банков и финансовых организаций, который могли бы использовать как сами банки и финансовые организации, а также их клиенты и другие компании, которые могли бы разработать дополнительные сервисы по обработке и представлению данных об условиях кешбэка в удобном, доступном и наглядном виде.
Предлагаемое название для подобного формата "COIN" (Cashback (details) Open Interchange - открытый обмен данными о кешбэке).
В качестве формата хранения данных предлагается JSON. Прототип формата опубликован в репозитории.
Демо-сервис базовых возможностей использования формата COIN Кашевар-онлайн
Как организовать обучение аналитиков дизайнерскому ремеслу?
Недизайнерам нет необходимости строить объекты или создавать маскированные области при ретушировании фотографии. Информация о принципах работы с кривыми и инструментах, которые не пригодятся в работе, излишняя. Тогда что должно входить в программу?
№1. Интерфейсы и инструменты. Основной акцент на горячих клавишах, ускоряющих работу (масштабирование холста, выделение объектов и т. д.), массовых операциях (переименование слоёв, выбор одинаковых объектов, редактирование текста).
№2. Подключение библиотек и создание стилей. Создание собственных библиотек позволяет переиспользовать стили текста и цвета.
№3. Группы, фреймы, привязки, autolayouts.Это довольно сложный материал для восприятия — без достаточного опыта работы с графическими редакторами тяжело воспринимать все эти привязки, размеры фреймов и т. д.
Почему решение необходимо. Предположения, ограничения, мотиваторы принятия решения.
# Критерий оценки
Какие приоритеты в принятии решения? Какие из параметров и характеристик системы рассматриваются или используются в принятии этого решения. Какие мотиваторы и ограничения использовались при принятии решения?
# Доступные варианты
Описывает доступные варианты, изученные при принятии решения согласно критерию оценки(обычно используя рейтинг или оценочную функцию), и компромиссы, возникающие за пределами критерия.
# Решение
Сделанный выбор и аргументация в его пользу.
# Последствия
Положительные и отрицательные последствия принятого решения.
# Консультации
В случае привлечения к обсуждению дополнительных участников, их комментарии документируется здесь. Дополнительная информация о приглашенных, не взирая на наличие от них отклика также записывается тут. Консультации обычно проводятся до принятия решения, но документируются в конце шаблона, чтобы своим объемом и свободной формой не затмевать собственно решение, ради которого создается запись.
Большой путь микросхемы: от расчета экономики до post-silicon verification
Первый шаг начинается с подготовки в САПР площади, «коробки», для размещения логики или подсистемы СнК — это так называемая зона ядра (core area). В ее границах расставляют большие макроблоки (PLL, аналоговые части больших интерфейсов вроде PCIe и т. п.), блоки статической памяти (SRAM), а также необходимые физические структуры, которые могут нести не только логические, но и другие функции — электрические, геометрические.
Другой важный этап — это подготовка сетки питания для питания всех транзисторов в схеме. Сетка также ограничивает плотность трассировки сигналов, так как делит с ними одни и те же слои. Топология микросхемы собирается как слоеный пирог: самый нижний слой занимают транзисторы, а выше идут слои металлов, в которых «вытравливаются» дорожки — будущие сигнальные межсоединения.
После подготовки core area и сетки питания, когда разместили контактные площадки, бампы, порты памяти и прочее, мы приступаем к автоматизированным этапам. Первый — размещение стандартной логики и ее оптимизация. Мы получаем логику как результат логического синтеза RTL и размещаем на реальной площади.
После размещения логики нужно провести трассировку ее межсоединений. В зависимости от инструментария это можно делать в той же самой САПР или в другом софте. Здесь виртуальные цепи становятся физическими. Чтобы при трассировке сигналов не пострадали их задержки, нужно просчитать их длину, влияние друг на друга, оптимизировать число переходов между слоями, при необходимости переставить некоторые стандартные ячейки ближе друг к другу.
Весь путь разработки ASIC и SoC глазами тополога — специалиста по физическому дизайну — описал в своей статье Илья Пеплов из дивизиона полупроводников YADRO. А если вы уже чувствуете в себе силы попробовать разработку микросхем на практике, приглашаем на хакатон SoC Design Challenge.
PostgreSQL | SQL-скрипт | Для получения подробного описания таблиц (в виде таблицы) | для системных аналитиков
Многие системные аналитики, приходя на проект, сталкиваются с проблемой что PostgreSQL БД уже создана ранее, а описания таблиц нет, да и доступ к ней дадут не скоро.
В итоге когда дают доступ, начинается анализ каждой из таблиц, чтобы перенести в документацию ее описание.
Я задался вопросом: "Можно ли сразу выгрузить все описания таблиц разом?" Оказывается можно, держите готовый скрипт для postgreSQL:
-- Скрипт получения информации о таблицах БД
SELECT
-- Наименование БД
current_database() as "Наименование БД",
-- Схема данных
current_schema as "Схема данных",
-- Наименование таблицы
relname as "Наименование таблицы",
-- Описание таблицы
obj_description(oid) as "Описание таблицы",
-- Наименование поля/столбца
column_name as "Наименование поля/столбца",
-- Тип данных
CASE
when character_maximum_length is not null
and udt_name = 'varchar' then concat(
udt_name :: varchar(255),
'(',
character_maximum_length :: varchar(255),
')'
)
else udt_name
end as "Тип данных",
-- Описание поля/столбца
col_description(oid, ordinal_position) as "Описание поля/столбца"
FROM
pg_class as a
right join information_schema.columns as b ON b.table_name = a.relname
-- WHERE
-- relname='<наименование таблицы>'
На выходе получим классное описание, которое сможем включить в документацию (например):
| Наименование БД | Схема данных | Наименование таблицы | Описание таблицы | Наименование поля/столбца | Тип данных | Описание поля/столбца |
| --------------- | ------------ | -------------------- | ------------------------------------------- | ------------------------- | ------------- | -------------------------------------- |
| sandbox_db | public | shops | Информация о поставщиках услуг (справочник) | table_id | uuid | Идентификатор записи в таблице shops |
| sandbox_db | public | shops | Информация о поставщиках услуг (справочник) | partner_short_name | varchar(1000) | Краткое наименование компании партнера |
| sandbox_db | public | shops | Информация о поставщиках услуг (справочник) | offers_sales_notes | varchar(50) | Условия продажи товара |
| sandbox_db | public | shops | Информация о поставщиках услуг (справочник) | url | varchar(2048) | URL главной страницы |
| sandbox_db | public | shops | Информация о поставщиках услуг (справочник) | company | varchar(1000) | Полное наименование компании |
| sandbox_db | public | shops | Информация о поставщиках услуг (справочник) | name | varchar(1000) | Короткое наименование компании |
| sandbox_db | public | shops | Информация о поставщиках услуг (справочник) | created_at | timestamp | Дата создания записи (в БД) |
| sandbox_db | public | shops | Информация о поставщиках услуг (справочник) | is_actual | bool | Признак актуальности записи (в БД) |
----
P.s.Плюсы приветствуются, а если уж минусите, то хоть коммент напишите, что не так!
Вариант схемы взаимосвязей между элементами модели для технологического и физического слоев в версии Archimate 3.2
Хочу поделиться итогами последней моей переписки с ребятами из OpenGroup по поводу особенностей применения стандарта Archimate 3.2 для описания микросервисной архитектуры с использованием Docker.
Как оказалось, паттерн, который был предложен 4 года назад с применением элементов Node для моделирования docker-контейнеров после выхода версии стандарта 3.2 стал неактуален - поскольку Node потерял большинство типов связей, которые были для него допустимыми по отношению к Artifact. Спросите, почему этот вопрос встал только сейчас ? Потому что полностью стандарт 3.2 был поддержан в редакторе Archi относительно недавно... плюс как раз появилась необходимость в актуализации старых схем технологического слоя - и тут-то и выяснилось, что больше нельзя показать, что docker-контейнер (Node) реализуется посредством docker-образа (Artifact).
Резюмируя итоги обсуждения с коллегами из OpenGroup:
рекомендуется использовать для моделирования докер-контейнеров элемент Системное ПО (System Software), для которого по прежнему доступно установление связи Реализации от докер-образа (Artifact)
элемент Node остается как элемент для моделирования некоей условной совокупности программно-аппаратных средств (включая физические, "не-ИТ" объекты - т.е. станки и др) - цитирую Jean-Baptiste Sarrodie: "используем Node, чтобы показать что именно будет размещать или предоставлять сервисы, не обращая внимания на то как эта функция будет реализована (приложение, сервер, контейнер и т.д.)". Иначе говоря Node остается некоей логической структурой, объединяющей физические элементы (System Software, Device и др.).
элемент Device рекомендуется применять для моделирования не только физических, но и виртуальных машин (до этого были варианты использовать для "виртуалок" элемент Node) - но возможно в новой версии Archimate что-то уточнится
P.S.: почти месяц назад, 25 января, вышла версия Archi 5.5 - за это время удалось пощупать, и могу сказать, что обновляться стоит.
Из ощутимых улучшений:
возможность удалять на схеме элементы-контейнеры (стиль nested - когда элементы помещаются друг в друга) без удаления вложенных элементов (команда "Delete from view (keep children)" )
инструменты для фильтрации дерева (регулярные выражения, фиксация папок верхнего уровня, учет регистра текста, вовлечение пользовательских свойств элементов и видов) и навигации по нему (вкл/выкл режима синхронизации выбранного в схеме элемента с деревом)
Совсем недавно ИТ-сообщество Global CIO объявило проект Колибри-АРМ по созданию независимой ИТ-инфраструктуры для Forvia победителем конкурса «Проект года» в номинации «Создание и модернизация инфраструктуры».
В новом эпизоде подкаста Колибри-АРМ – последние сплетни новости из жизни команды: запуск свежего релиза, победа в «Проекте года», секретные фичи для последующих обновлений и планы по завоеванию рынка.
Системный аналитик. Мифы и реальная польза для бизнеса (Sravni Podcast)
В новом выпуске поговорили со Светланой Амелькиной, системным аналитиком Сравни. О том, что SA представляет собой в 2025 году – глазами самого специалиста, разработки и бизнеса.
Внутри видео:
О скиллах: что важно знать и уметь SA для успешной карьеры
Взаимоотношения SA с другими командами (разработкой, QA, продактами)
Мифы о системных аналитиках, в которые пора перестать верить
Трудоустройство SA: как и зачем интервьюировать работодателя
Делюсь записью вебинара «Актуальные навыки системного аналитика. Возможности и перспективы развития», где рассказала не только про основные навыки системного аналитика, но также подробно разобрала тенденции, влияющие на требуемые знания специалистов. Запись вебинара можно скачать по ссылке.
4:32 – типы навыков и содержание
6:29 – что включают в себя основы системного анализа
Каждый системный аналитик, при прохождении практической части собеседования, начинает судорожно вспоминать инструменты, в которых можно это быстро сделать, т.к. ему на это отводится всего-лишь 5-10 минут, чтобы:
Вебинар «Актуальные навыки системного аналитика. Возможности и перспективы развития»
11 февраля я проведу бесплатный вебинар: «Актуальные навыки системного аналитика. Возможности и перспективы развития», где расскажу про востребованные навыки для аналитика, их рост и подходы к развитию, а также поделюсь своим опытом. Запись на вебинар доступна по ссылке.
Что будет на вебинаре:
Поговорим о необходимых аналитику знаниях и навыках
Рассмотрим подходы к их развитию
Поговорим о том, как специалисту расти на практике в реальных задачах
