В первой части статьи мы заложили фундамент.

В этой части статьи мы переходим от сценариев к архитектуре целых тестовых библиотек: подключаем lifecycle-хуки, вводим @Context и @Inject, создаём Step Library и автоматизируем запуск целых слоёв.

Что, если бы автотесты читались как сценарий?
Что, если бы каждый шаг был понятен, каждая метка — на месте, а отчёт — пригоден не только для QA, но и для бизнеса?
Так появился Scenax — DSL-фреймворк поверх Vitest и Allure, превращающий тесты в читаемые сценарии.

В этой статье проведены параллели между обработкой ошибок в feign и reactivefeign клиентах на примере реализации starter, который реализует аутентификацию по OAuth 2.0 в spring reactive подходе. В этой статье не будет описания реактивного стека. Если Вы хотите разобраться, какие есть преимущества и зачем его применять, рекомендую посмотреть эту серию статей. В этой статье не будет сравнения реактивного и нереактивного подхода. Для этого есть такая статья. В этой статье я хочу показать, что перевод компонентов на реактивность - несложная задача по рефакторингу, которая не займет много времени. Добавить монетку в копилку того, что перевод на реактивность - процесс, основные затраты в котором нужно сделать на первом шаге, когда Вы решаетесь применять этот подход, а адаптировать существующие компоненты просто.

Привет, Хабр! Все мы наблюдаем стремительное развитие больших языковых моделей (LLM), которые находят широкое применение для решения различных NLP задач, включая создание вопрос-ответных систем и чат-ботов.

В компании АльфаСтрахование мы начали активно использовать LLM для создания умных консультантов и в этой статье хотим поделиться нашим практическим опытом в одном из ключевых аспектов — оценке качества ответов чат-бота.

Это статья описывает опыт миграции традиционного приложения java spring на Spring reactor стек. О специфике разрабатываемой информационной системы, уже подробно рассказывал. Кратко о системе - смешанная сервисно-микросервисная архитектура. Чтобы получить бизнес результат, требуется вызвать микросервис, который вызывает сервис, который вызывает набор микросервисов для формирования ценностного набора данных. Получается цепочка вызовов. Сервисы и микросервисы разрабатывались на традиционном технологическом стеке, без использования реактивного подхода.

Мое знакомство с реактивным подходом произошло в 2022 году. Плюсы и минусы я осознавал, как мог. В рамках разрабатываемой системы мне было сложно найти ему точку применения. Тогда сложилось понимание, что в существующих рамках реактивный подход не даст возможности эволюционных изменений. Если его применять, то применять ко всему и сразу, как постулирует реактивный манифест.  Даешь революцию! Это было заблуждение. Его я не смог разрушить, даже изучая документацию и статьи. Чего-то релевантного моей ситуации в открытых источниках я найти не мог. Этой статьей постараюсь предложить путь и убедить сомневающихся, что долго раздумывать не стоит. Делайте смелый шаг на пути к реактивному стеку.

Очень много в последнее время слышно замечаний в адрес PHP – мол, медленный, тяжелый, неповоротливый, все давно микросервисы на Go/Java/(нужное подставить) пишут. В этой статье я постараюсь расписать плюсы, минусы и результаты нашей попытки ускорить проект на PHP с использованием RoadRunner.

Это статья-туториал. Рассмотрим в ней, как сделать компонент, который поможет забыть о необходимости дублировать механизмы аутентификации и авторизации. Цель статьи - реализовать starter, который можно будет легко и удобно подключить к Spring Boot проекту. Предлагаемая цель актуальна?

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

Хочу рассказать, как мы реализуем на практике контакты по спецификации OpenAPI, стараемся следовать подходу Contract First и в целом разрабатывать так, чтобы удобно было как разработчикам в команде, так и всем, кто использует наши сервисы. В статье описана генерация Java и typescript, а так же конфигурации maven.

Контракты OpenAPI — спецификация, которая позволяет описывать интерфейс взаимодействия с сервисом в виде REST. Или не REST, тут зависит от задачи и ее реализации.

Вдаваться в историю появления спецификации и ее развития не буду. Если кратко — эта спецификация позволяет описывать контракт взаимодействия с сервисом с помощью yaml‑синтаксиса. А с помощью OpenAPI generators можно генерировать из такого описания клиент‑серверные интерфейсы на различных языках. На данный момент последняя версия OpenAPI — 3.1.0 — является наиболее удобной и структурированной, позволяет описывать контракт с помощью JSON. Мы осознанно используем версию 3.0.3. Почему? Расскажу далее.

Эта публикация – практический кейс c кратким туториалом по реализации TLS-соединения, на основе российских стандартов шифрования, основанных на компонентах КриптоПро (CP). Статья не содержит рекламы или попытки сподвигнуть к выбору конкретных компонентов. Я столкнулся с задачей реализации шифрованного подключения к системам бюро кредитных историй (БКИ) в части оценки платежеспособности физических лиц. У меня было ограничение - необходимо было использовать КриптоПро (CP). В процессе реализации задачи открыл для себя несколько интересных моментов. Процесс их "открытия" был чарующим и загадочным. Чары мне обеспечил CP, а с загадками помогали службы поддержки БКИ и CP. Этой статьей хочу помочь сэкономить время и сделать прозрачным процесс реализации шифрованного подключения. В начале статьи дам небольшой теоретический экскурс. Если Вас интересуют детали реализации, то сразу переходите к разделу "Установка и настройка CP компонентов", код, приведенный в статье выложен тут. Приятного чтения.

Всем привет. Решил поделиться опытом тестирования логики консьюмеров и продюсеров в стандартном Spring Boot приложении. Я несколько раз подходил к этой задаче с различными вариантами и находил разные подводные камни, которые стимулировали меня искать дальше - более лучшее решение. И вот, в очередной раз прошерстив накопленный опыт человечества (stackoverflow), я реализовал очередной вариант, в котором пока не нашел минусов предыдущих реализаций. В любом случае, поделюсь с вами как я к этому пришел и почему для моих кейсов не сработали другие варианты (или показались хуже последнего).

Дисклеймер. Я сторонник интеграционных тестов при запуске сборки проекта с тестами. То есть это когда для unit-тестов поднимается контекст Spring со всеми плюсами (окружение, максимально похожее на боевое) и минусами (это ДОЛГО запускается и ДОЛГО описывается).

Часть 1. А разве это проблема вообще?

Коротко: ...

Привет. Это статья-туториал про выбор технологии и реализацию проекта нагрузочных тестов для API REST микросервисов. Про себя и специфику продукта, над которым работаю, я подробно описывал тут, когда рассказывал о интеграционных тестах. Здесь этому уделять внимание не буду. Если решитесь продолжать, то Вас ждет длинное чтиво. Результатом потраченного времени и внимания будет понимание того, зачем нужно нагрузочное тестирование, с чего начать, куда двигаться дальше и шаблонный проект нагрузочных тестов, который Вы сможете адаптировать под себя. Все используемые мной технологии в этой статье несут печать Java экосистемы. Это тоже может повлиять на то, решитесь ли Вы продолжать. Поехали ...

Привет, Хабр!

Компания АльфаСтрахование, как и многие другие, столкнулась с необходимостью замены используемых инструментов в связи с санкциями. За последний год мы отказались от Slack в пользу open-source аналога Mattermost, а Jira не без сложностей была заменена на Kaiten.

В нашей команде, которая занимается системой электронного документооборота в части операционных процессов, часто на голосовых встречах и при обсуждении в мессенджере Mattermost возникала необходимость накидать черновики задач в таск-трекер, чтобы потом их дозаполнить. Эта потребность наложилась на мое желание попробовать написать что-то на python, связанное с Chat-Ops.

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

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

По отзывам моих ревьюеров, эта статья ‑ «Инструкция по входу в автоматизированное тестирование и настройка фрейма».

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

Привет, Хабр! На связи разработчик АО АльфаСтрахование. В этой статье я хочу рассказать о мультиаутентификации в ASP.NET Core приложениях.

Нам довольно часто нужно писать .NET Core приложения. Нередко они используются для интеграции крупных систем. А в этих системах частенько свой собственный набор учетных записей (далее УЗ) и инструментов по управлению доступа к ним.

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

Рассмотрим вариант добавления трейсов в Spring Boot 3 приложение с использованием Kafka в качестве транспорта и Zipkin в качестве инструмента для трассировки.

Функциональность соберем в автоконфигурацию для подключения к Spring Boot приложениям.

Всем, привет.  Для самых жаждущих и нетерпеливых эта в этой статье будет про:

• Типы анализа, используемые для/около информационных технологий;

• Систему координат типов анализа и для чего использовать каждый из них;

• Специальные артефакты для каждого типа анализа;

• То, как понять, что в компании/процессе/проекте нужно использовать конкретный тип анализа;

• Акценты и навыки, нужные при использовании каждого типа анализа;

Для тех, кому интересно и хочется сложить причинно-следственные связи, проследить нить рассуждений, то давайте это сделаем. Я Иван. Люблю сферу информационных технологий и стремлюсь развиваться в дисциплинах, задействованных для создания информационных продуктов – анализе, проектировании, разработке. Эти дисциплины влияют друг на друга и на конечный результат - создаваемую информационную систему.

Рассуждая, что такое анализ, какой он бывает, какой тип, в каких условиях использовать и какие навыки нужны для того, чтобы его выполнять, я предположил, что будет полезным систематизировать имеющийся опыт и результаты обсуждения с коллегами, слушателями профессиональных программ развития НИУ ВШЭ, МИСИС, интернет университетов. Так появился следующий обзор. Надеюсь, он принесет вам пользу. Рассчитываю на обсуждение. Присоединяйтесь :-)

Привет, Хабр! В этой статье я хотел бы поделиться опытом нашей команды в части интеграции .NET Core и выше приложений с корпоративным хранилищем секретов HashiCorp Vault.

Наши приложения, как и большинство приложений в компании, используют в процессе работы различные секреты (пароли, токены и т.д.). Их, с точки зрения информационной безопасности, нельзя хранить в коде или на компьютере, на котором запущено приложение. Поэтому в компании используется специальное ПО – хранилище секретов HashiCorp Vault.

В чем суть проблемы, с которой мы столкнулись: решение, используемое ранее для получения секретов из HashiCorp Vault в приложение, было не очень удобным и очевидным

По традиции, для самых жаждущих и нетерпеливых, эта статья будет о:

• С чего начинается построение любой архитектуры?

• За счет чего реализуются потенциальные бизнес возможности?

• Кто нужен для реализации намеченных возможностей?

• Как создать цифровые продукты, которые будут удовлетворять требованиям заказчиков, вписываться в намеченные сроки и бюджеты?

• Из чего должна складываться структура продукта и как он должен реализовывать функциональные требования?

Если нет интереса к предисловию, то переходите к первому "почему". Для тех, кто хочет сложить причинно-следственные связи - добро пожаловать.

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

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