[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 февраля я проведу бесплатный вебинар: «Актуальные навыки системного аналитика. Возможности и перспективы развития», где расскажу про востребованные навыки для аналитика, их рост и подходы к развитию, а также поделюсь своим опытом. Запись на вебинар доступна по ссылке.
Что будет на вебинаре:
Поговорим о необходимых аналитику знаниях и навыках
Рассмотрим подходы к их развитию
Поговорим о том, как специалисту расти на практике в реальных задачах
В обоих случаях целые 44% опрошенных, представившихся системными аналитиками (почти половина) проголосовали за вариант «мнеприходилось погружаться в код своих коллег и читать его».
А если учесть, что и в сообществе и на Хабре треть опрошенных (35% и 40% соответственно) проголосовала за вариант «посмотреть результаты», то получим около 70% аналитиков, сталкивавшихся с такой необходимостью и это колоссальные цифры! 🤯
О чем же они говорят?
☹️1. Плохая документация
На это могло повлиять множество факторов. Как основные: или отсутствие аналитиков, или сложный запутанный домен, или команда работала в режиме «стартап», когда главное было пилить как можно быстрее новый функционал для бизнеса. Или все вместе взятое .
☹️2. Плохие процессы
Возможно, что в команде не были должным образом выстроены процессы проектирования, разработки и тестирования:
отсутствовали соглашения по проектированию и описанию требований
отсутствовала культура тестирования (напомню, что хорошо описанные требования на разработку являются основой для формирования тест-кейсов, и хорошие QA будут требовать документацию от аналитиков).
Что делать?
Отсутствие документации — это большая возможность для прокачки скиллов: как хардов, так и софтов.
В целом в таких ситуациях я использую следующий порядок действий:
Получить доступ к стенду тестирования и посмотреть, какой функционал уже имеется в системе.
Определить круг стейкхолдеров и подготовить вопросы для их интервьюирования.
Изучить таск‑трекер (условная Jira) на предмет следов разработки (можно узнать о том какие сервисы и фичи были сделаны ранее)
Поговорить со всеми разработчиками и узнать, какие сервисы они разрабатывают/разрабатывали на проекте и вообще что они о нем знают.
Изучить систему контроля версий (например GitLab или BitBucket) — позволит найти сервисы и их код.
Изучить конфигурации сервисов. В них, как правило, будут URL-адреса интеграционных и иных взаимодействий (БД, брокеры итд).
Изучить API, если есть описание. Если нет, то придется погружаться в чтение кода.
На этом этапе очень полезным станет отрисовка схемы микросервисов и определение структуры моделей данных в БД.
На схему микросервисов будет необходимо нанести сервисы, стрелочками изобразить взаимодействие между ними, и желательно написать имя используемого метода и его URL.
БД можно описывать в табличном виде или в виде ER-диаграмм.
Во время чтения кода вы можете использовать информацию из предыдущих пунктов, чтобы восстановить и задокументировать бизнес-процессы так, как они реализованы на самом деле.
Если вы хотите лучше понять, чем занимается системный аналитик, или недавно работаете в этой области и ищете новые инструменты и подходы, держите подборку.
«Системный аналитик» — на бесплатной части курса вы познакомитесь с этапами работы над проектами, увидите, чем занимаются аналитики, и узнаете, как выглядят результаты их работы.
Чем занимается системный аналитик — разбираем ключевые задачи этой профессии на примере создания навыка для виртуального ассистента.
Полезные материалы
Работа с API: 17 полезных ссылок для системного аналитика — материалы, которые помогут разобраться в основах работы с API, документировании REST API, использовании форматов данных XML и JSON, а также в инструментах вроде Swagger.
Гайд для системного аналитика
Этот цикл статей поможет разобраться в работе с требованиями на всех фазах проекта. Мы рассмотрим пример на основе банка, чтобы показать, как документировать требования, подбирать инструменты анализа и использовать удобные решения вроде Wiki и таск-трекеров.
Часть 1: Инициация— разбираем, как определить бизнес-цели, собрать пользовательские требования, выбрать уровень их детализации и заложить основу для последующих этапов.
Часть 2: Планирование и исполнение— учимся декомпозировать требования, распределять задачи между членами команды и управлять изменениями в проекте с помощью таск-трекеров.
Часть 3: Контроль — разбираем методы проверки, тест-дизайна и рецензирования, которые помогут избежать ошибок.
Друзья, приглашаем на бесплатный вебинар «Введение в архитектурные стили разработки». Обсудим ключевые архитектурные стили: их свойства, преимущества и недостатки, а также разберем примеры применения.
📅 Дата: 27.01.2025
⏰ Время: 17:00-18:00 (Мск)
На вебинаре обсудим:
✔️ Слои,
✔️ Микросервисы,
✔️ Событийно-ориентированные архитектуры,
✔️ Стили каналов и фильтров,
✔️ Классную доску и другие стили.
👨🎓 Спикер: Луговской Андрей — специалист в области разработки ПО.
Вебинар «Аналитик в команде. Актуальные проблемы и их решения»
15 января я проведу бесплатный вебинар: «Аналитик в команде. Актуальные проблемы и их решения», где я расскажу о проблемах в задачах системного аналитика и подходах к их решению. Запись на вебинар доступна по ссылке.
Что будет на вебинаре:
Поговорим о совмещении различных ролей системным аналитиком
Разберем нестандартные задачи аналитика и подходы к их решению
Рассмотрим необходимые навыки и перспективы развития
Поговорим о том, с какими сложностями может столкнуться аналитик сегодня
Вебинар «Аналитик в команде. Актуальные проблемы и их решения»
15 января я проведу бесплатный вебинар: «Аналитик в команде. Актуальные проблемы и их решения», где я расскажу о проблемах в задачах системного аналитика и подходах к их решению. Запись на вебинар доступна по ссылке.
Что будет на вебинаре:
Поговорим о совмещении различных ролей системным аналитиком
Разберем нестандартные задачи аналитика и подходы к их решению
Рассмотрим необходимые навыки и перспективы развития
Поговорим о том, с какими сложностями может столкнуться аналитик сегодня
Почему совершать ошибки — полезно: рассказывают наставники Практикума
Каждая ошибка — это шаг вперёд, если сделать из неё выводы. Это знали и наши наставники, которые превратили свои неудачи в ценный опыт. Делимся двумя историями:
Тест, который не работал Рассказывает Дарина Кухтина, наставница на курсе «Аналитик данных»
Я руковожу отделом аналитики в мобильном геймдеве. Мы запустили А/В-тест для игровых автоматов, чтобы проверить разные расстановки. Более успешные слоты поставили в начало. 3а две недели эксперимента не произошло никаких изменений.
Оказалось, что всё это время обе группы получали одну и ту же расстановку, потому что мы не добавили изменения на продакшн. После этого неудачного теста мы сделали новую успешную расстановку и до сих пор ей пользуемся.
Выводы:
Нужно пользоваться своим продуктом: заходить на сайт или играть в игру, над которыми идет работа.
Ошибка может быть в любом месте.
Чем раньше заметить ошибку, тем лучше. Это экономит время, а время — деньги.
Никому нельзя верить, даже себе.
Самокаты начали сигналить по всему городу Рассказывает Андрей Шевченко, наставник на курсе «Инженер по тестированию»
Команда тестировала новую фичу для кикшеринга самокатов перед продакшном. Тогда мы не нашли одну из моделей самокатов и не перезапустили сервисы после доработки.
Со следующим обновлением они перезапустились сами, в том числе единственная модель, которую мы не протестировали. Две тысячи самокатов сигналили два часа подряд. Было неприятно, но мы быстро собрались и вместе устранили проблему.
Выводы:
Команда всегда тебя поддержит.
Если ты где-то облажался, то облажалась вся команда.
Окружение важно! Покройте проверками максимум.
Перезапускайте сервисы после обновлений.
Ошибок не допускает только тот, кто ничего не делает.
Есть ли ошибка, которая помогла вам стать лучше? Расскажите об этом в комментариях.
Системный аналитик — проблемная должность на рынке.
Руководители и команды зачастую не знают, какие именно функции такой специалист должен выполнять, а сами аналитики не понимают, какие компетенции развивать. В разных компаниях к системным аналитикам порой предъявляются диаметрально противоположные требования.
За 8+ лет работы системным аналитиком, участия во множестве собеседований и общения с коллегами я пришла к выводу, что путаница возникает из-за того, что за условным названием "системный аналитик" сегодня скрываются как минимум пять специализаций. Давайте поделюсь, как я их вижу, и буду рада, если вы расскажете, как это выглядит у вас.
1. Инженер по требованиям
Функции: систематизирует и описывает требования в информационной системе, пишет документацию, помогает разработчикам понять, что именно нужно реализовать. Отвечает за полноту и согласованность требований. Управляет изменениями требований.
Инструменты: вики-системы, таск-трекеры, BPMN, UML, системы разработки интерфейсов
2. Фича-овнер (фича-лид)
Функции: управляет жизненным циклом фичи или подсистемы. Определяет цели и дорожную карту развития подсистемы. Координирует работу фича-team, создающих и поддерживающих подсистему. Это продукт-овнер "на минималках". Отвечает за функционал на всех стадиях: от проработки идеи до внедрения и поддержки.
Функции: роль близка к архитектору, но, как правило, с узким фокусом на конкретный набор подсистем. Создаёт архитектуру системы, продумывает её компоненты и взаимодействия, моделирует процессы. Отвечает за документирование и актуальность схем архитектуры.
Инструменты: C4 Model, PlantUML, вики-системы, системы для моделирования процессов
4. Проектировщик баз данных
Функции: собирает и документирует требования к обработке и хранению данных. Строит модели данных, проектирует структуры БД с учётом, в том числе, и нефункциональных требований. Заботится о связях и нормализации.
Инструменты: SQL, инструменты для проектирования баз данных, вики-системы
5. Проектировщик интеграций
Функции: работает там, где есть потребность в интеграциях. Разрабатывает схемы и спецификации взаимодействия между системами, продумывает форматы данных и их трансформации. Документирует API. Помогает команде настраивать интеграционные тесты и валидирует их результаты.
Инструменты: OpenAPI, средства управления запросами к API, стек для управления логами и анализа данных
Это не устоявшаяся терминология и тем более не жёсткое разделение. Однако, судя по вопросам на собеседованиях и картам развития СА (раз, и два), такие границы довольно очевидны.
Что даёт понимание разделения ролей системного аналитика?
Для аналитиков:
Задайте себе вопрос: в какой роли вы чувствуете себя наиболее уверенно? Понимание своей специализации и зон роста поможет вам:
выбирать компании и проекты с подходящими задачами;
чётко выстраивать своё профессиональное развитие.
Например, я знаю, что как проектировщик баз данных я пока скорее джун, но в интеграциях и работе с требованиями могу уверенно брать задачи для уровня сеньора. И для моих текущих обязанностей это идеальный набор.
Для команд:
Вы лучше понимаете, как взаимодействовать с аналитиком, учитывая его специализацию. Да и в целом становится яснее, кто именно появился или уже работает в вашей команде.
Для руководителей:
Это помогает чётче формулировать задачи и искать специалиста под конкретные потребности, а не пытаться закрыть всё одним человеком.
Я считаю, что разделение ролей системного аналитика — это ключ к более ясному и эффективному взаимодействию всей команды. А вы?
25 декабря я проведу бесплатный вебинар: «Разработка требований к интеграции в практической задаче», где мы рассмотрим проработку и описание требований на практике с реальным кейсом. Запись на вебинар доступна по ссылке.
Что будет на вебинаре:
Подробно разберем процесс работы с требованиями в интеграционных задачах
