Всем привет!

В продолжение предыдущего поста попробую сам себе возразить.
Предположим, что наши DevOps инженеры так круто настроили pipeline, что все атрибуты, которые должен настроить разработчик, параметризованы и могут быть легко настроены разработчиком. Например, с помощью чартов Helm. Хотя по большому счёту не важно.
Значит ли это, что разработчик может расслабиться и не изучать все эти ваши Deployment, Service, EnvoyFilter, VirtualService и прочие? Мой ответ - нет. И вот почему.
1) если рассуждать дальше, то и Docker разработчику не нужен. Пусть его же DevOps-ы настраивают. А я на Tomcat встроенном запущу. Но вспомним в чем суть Docker - единая среда у разработчиков, тестировщиков и ПРОМа. Что позволяет избежать большой части ошибок, возникающих из-за разницы настроек окружения. Не всех, но большого числа
2) окей, Docker пусть будет. А k8s? Но идея та же. Приложение в облаке ведёт себя по другому, чем в standalone. Его может в любой момент прибить k8s и поднять на другой node. А это ограничивает возможности локального кэширования. В облаке несколько приложений может работать параллельно. Это нужно учитывать, например, при чтении из топика Kafka. Более того число подов может меняться - см. HorizontalPodAutoscaler. Еще момент - по умолчанию у нас ephemeral storage и надеятся на то, что те же логи сохранятся после перезапуска, нельзя. Ещё момент - одно из Cloud Native требований - быстрый старт приложения, опять же из-за потенциального перезапуска в любой момент. На этот момент не всегда обращают внимание, хотя варианты улучшения времени запуска есть, см. серию постов выше. И это я вспомнил навскидку, возможно что-то ещё упустил.

Надеюсь, я вас убедил. Если нет - жду в комментах)

#dev #devops

Всем привет!

Я иногда даю ссылки в своих постах на википедию. Ясное дело, что 100% гарантии достоверности статей в вики никто не даст. Народное творчество. Но в большинстве своем техническая (!) информация верна. Но есть забавные нюансы.

Ищу информацию по алгоритмам, используемым в Rate Limiters. Есть такой алгоритм - Token Bucket. Есть статья по нему https://ru.wikipedia.org/wiki/Алгоритм_текущего_ведра
Алгоритм статья описывает в целом верно, хотя и добавляет туда сетевой специфики, видимо автор создал ее разбираясь в работе сетей, например QoS.
Но посмотрим на название. Алгоритм текущего ведра. Токен = текущее?
Причем проблема не в творческом переводе. У меня уже была ссылка на статью с описанием основных алгоритмов https://habr.com/ru/articles/448438/
Смотрим туда Leaky Bucket - протекающее ведро. Вполне логичный перевод. Но у нас же Token bucket. Или алгоритм маркерной корзины, что собственно мы и видим в первой же строчке статьи вики. Это два разных алгоритма. А статья создана в 2008 году, сразу с неправильным заголовком.

Что в итоге - в итоге путаница. Если "загуглить" заголовок - https://yandex.ru/search/?text=Алгоритм+текущего+ведра то мы увидим условно 5 ссылок на Leaky Bucket и 5 ссылок на Token Bucket, причем последние - это копии статьи с русскоязычной вики в других вики.
Второй вывод - мало просто скопировать википедию...)

#wiki

Всем привет!

Ну что, началось)
https://www.piter.com/collection/all/product/programmirovanie-na-python-s-pomoschyu-github-copilot-i-chatgpt
Ок, ещё одна книжка про ChatGPT. Смотрим аннотацию: «Используя GitHub Copilot, можно простым языком описать, что должна делать программа, а искусственный интеллект тут же сгенерирует ее.
Узнайте, как создавать и улучшать программы на Python с помощью ИИ, даже если прежде вы не написали ни строчки компьютерного кода.». И ещё: « Глава 4 — первая из двух глав, в которых вы научитесь читать код на языке Python. Действительно, Copilot будет писать код за вас, но вам нужно уметь читать его, чтобы определить, будет ли он делать то, что вы хотите. И не волнуйтесь: Copilot поможет вам читать код!»
И это не ролик, не статья, целая книга...
Войти в IT, если с первого раза не получилось) Интересно, на собесах Copylot уже используют?)
Меня только один вопрос мучает: если человек не захотел или не смог освоить язык программирования (фреймворк) - как хорошо он сможет спроектировать сервис или алгоритм?

#llm #dev

Всем привет!

Недавно я уже писал о пользе стандартизации на примере формата данных для сохранения информации о микросервисе - https://t.me/javaKotlinDevOps/291 (cyclonedx). А еще в одном посте - про работу с исключениями - упоминал библиотечку для вывода информации об ошибке в API - https://t.me/javaKotlinDevOps/310 (jdoctor).
Так вот - стандартизация добралась и сюда)
Во-первых, как выяснилось - уже с 2016 года есть стандарт "Problem Details for HTTP APIs" https://datatracker.ietf.org/doc/html/rfc7807
Во-вторых - в Spring Boot 3, т.е. с 2021 года, появилась его имплементация. Вот неплохая статья, описывающая детали https://www.baeldung.com/spring-boot-return-errors-problemdetail
Если вкратце - ответ при ошибке будет иметь стандартизированный вид похожий на такой:
{
"type": "about:blank",
"title": "Bad Request",
"status": 400,
"detail": "Invalid request content.",
"instance": "/sales/calculate"
}

Библиотеки, решающие подобную задачу в Java уже были:
1) упомянутый ранее https://github.com/melix/jdoctor,
2) https://www.wimdeblauwe.com/blog/2022/12/01/the-error-handling-spring-boot-starter-library-vs-spring-6-problemdetail/
...
Но я думаю, что именно данное решение - от Spring, да еще по стандарту - имеет шансы распространиться достаточно широко и популяризовать данную практику.

Что еще хочется отметить:
1) стандартизация - это хорошо. Каждый поставщик API разрабатывает формат для ответа при ошибке, каждый потребитель - специфический код обработки ошибок для всех вызываемых сервисов. А при этом понятно, что формат информации об ошибке мало зависит от бизнес-процесса
2) еще в 2018 году в Сбере формат ответа для REST запроса был стандартизирован. Это круто. Не круто то, что формат отличается от RFC. И то, что область его применения была ограничена общением с фронтом

#standardization #java #problem_details

Всем привет!

Я часто вижу в проектах лишние настройки. Как правило, они попадают в проект следующими путями:
1) скопировали из каркаса\образца\соседнего сервиса не задумываясь - нужны эти настройки или нет. Да, принцип "работает - не трогай" встречается и у разработчиков)
2) решили явно прописать какие-то настройки, так сказать для надежности

Я считаю, что так делать не надо. Почему?

1) лишние настройки раскрывают нам лишние детали, которые или не нужны вообще, или нужны, но не сейчас. Повышается когнитивная сложность кода. Знать все детали своего сервиса - это хороший подход, был, лет 10-20 назад. Сейчас ПО очень сильно развилось в плане специализации, количество зависимостей среднего проекта - несколько сотен, поэтому знать все детали просто невозможно.
2) следствие из сказанного выше - ухудшается читаемость кода. Да, это моя любимая тема. Мы чаще читаем код, чем пишем. Настройки тоже часть кода.
3) среди скопированных настроек могут быть не нужные в данный момент. Код легко меняется, ТЗ меняется также легко, поэтому добавлять что-то "на вырост" не стоит
4) портянка настроек, в которую что-то постоянно добавляется, может превратится в некий аналог "большого кома грязи", который будут боятся трогать. Как разработчики, так и сопровождение. Чтобы этого не допускать - настройки нужно чистить. Чтобы меньше было чистить - не нужно добавлять лишнее. Как-то так)

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

#clean_code #configuration #conv_over_conf

Всем привет!

Снова попробую сам с собой поспорить ... санитары, ау ... так ли хорош принцип convention over configuration.

1) Первое возражение я уже упомянул в предыдущем посте. А как же полный контроль над настройками проекта? Мало ли что там в значениях по умолчанию.
Ответ: при текущей модульности и сложности ПО - это видимость контроля. Невозможно вынести все настройки в один файл. А даже если и возможно - как потом с этим работать?
С другой стороны достаточный набор модульных и регрессионных тестов плюс нагрузочное тестирование дает некую уверенность, что все настроено верно. А тесты нужны в любом случае.

2) Если система прячет от нас настройки - она менее гибка, и в нестандартном use case ее придется настраивать "через одно место". И это в самом деле важный момент. convention over configuration не означает, что разработчик компонента спрятал все настройки в "черный ящик". Это неправильный convention over configuration. Правильный - разработчик продумал некие настройки по умолчанию, удовлетворяющие основные use cases, но оставил возможность подтюнить при необходимости.
Это может быть application.yaml в Spring Boot, код на Kotlin или Groovy DSL в Gradle или даже написание плагина в Maven. Последний кейс может показаться антипримером - настроить что-то под себя достаточно сложно. Кто-нибудь делал свой Maven плагин?) Но как раз за это многие и любят Maven - сделать из скрипта сборки "большой ком грязи" на Maven гораздо сложнее, чем в том же Gradle. Так что кажется, что и такой вариант допустим.

#conv_over_conf #configuration

Всем привет!

И "последняя серия" про convention over configuration.
Я уже говорил, почему стоит придерживаться данного принципа разработчику и команде в целом. Но можно посмотреть чуть шире.

1) с настройками приложения могут работать люди, не относящиеся к команде - тестировщики, DevOps-инженеры (да, они не должны этим заниматься, но занимаются), сопровождение ПРОМ. И у них будут похожие проблемы:
а) слишком много настроек
б) не понятно, что важно, что нет
в) не понятно, у всех одинаковые настройки (скопированные из каркаса) или у кого-то есть особенности, требующие, чтобы на них обратили внимание. По-хорошему, все это должно быть описано в документации к релизу, но случается всякое)

2) если ты разработчик какой-то библиотеки или сервиса, то вывалить на пользователей сотню настроек, давая им возможность все кастомизировать "под себя" - самый простой, но не самый правильный вариант. Даже если ко всем настройкам есть подробная документация, но как я уже написал выше - случается всякое) Правильный подход - подумать, как этим сервисом будут пользоваться. Это на самом деле критическая проблема. Не для всех, для того же open sourse проблема видится не критичной - библиотека, которую неудобно использовать, скорее всего не пройдет "естественный отбор". А вот в "кровавом enterprise" проблема вполне себе существует. Не всегда пользователи могут отказаться от использования какой-то части платформы. Так вот, чтобы понять оптимальные настройки по умолчанию - надо поставить себя на место пользователя. Или собрать обратную связь, или пользоваться своим продуктом. Т.об. принцип convention over configuration способствует движению в правильном направлении. Хотя конечно не является гарантией.

Вот теперь пожалуй всё)

#configuration #conv_over_conf

Всем привет!

Запилил небольшое сравнение AI чатов для задач разработки.
https://gitverse.ru/javadev/ai-tools-comparision/content/master/README.md
Почему в Git - потому что там есть полноценный Markdown и таблицы.

Фокус на бесплатных инструментах - для тех, кто хочет попробовать. Сравнение функциональное + бенчмарки, без реальных запросов. По реальным задачам сделаю отдельный пост.

Пока мне больше всего нравится Perplexity. Работает без VPN, есть ссылки на источники, под капотом несколько мощных моделей, можно загружать книжки для пересказа и есть упор на точный поиск в интернете. Далеко не все инструменты в принципе умеют искать в интернете. Но даже те, что умеют - часто галлюцинируют. Примеры:
1) что нового в Java 22 - все, кто умеют искать, ответили более менее точно
2) первая тройка на Олимпиаде 2024 и разбивка по медалям - точно ответила только Perplexity, остальные показали рандомные цифры и даже страны.
Из минусов - в бесплатном режиме есть 5 запросов в режиме Pro в день, но нет выбора модели. Т.е. какая модель использовалась - понять невозможно. Но отвечает неплохо.
По VPN - это может быть критично, если уже сидишь под рабочим VPN.

Также выглядят интересными ChatGPT, Deepseek Coder и Mistral.

Еще замечания:
1) YandexGPT добавил как гарантировано доступный в России, хотя сам Яндекс для разработки ее не позиционирует. И еще забавный момент - в Алисе последняя версия YandexGPT доступна ограничено, а в Cloud - похоже что нет. Более того, она и отвечает лучше на "той же" версии модели по вопросам разработки. Лучше, но все равно слабее иностранных конкурентов.
2) GigaCode - это отдельная модель, отличающаяся от GigaChat. Доступна только через плагин IDE. Ребята неплохо развиваются, хотя и с упором на AutoCompletion, а не режим чата.
3) Copilot c сайта выглядит как вариант ChatGPT, отстающий от него по версиям, и главное - не заточенный под разработку, а под интеграцию с продуктами Microsoft. Скорее всего Copilot из GitHub - это другая, дообученная модель. Но, увы, только платная https://github.com/features/copilot
4) размер контекста модели - понятие растяжимое. Напомню - контекст определяет размер запроса, ответа и памяти модели в рамках текущего диалога. Почему растяжимое - не столько из-за того, что считается в токенах, а токен не равен слову. Похоже каждый инструмент интерпретирует это число по-своему - вот тут интересно насчет ChatGPT https://habr.com/ru/articles/758890/ Вот что пишет Perplexity: By default Perplexity reads at least 4000 tokens per question but it can read many more with file upload. Longer pasted text is converted to a file automatically.
5) если инструмент показывает источник ответа - не факт, что ответ в точности такой, как в источнике. Но в любом случае источник полезен.
6) Deepseek Coder и Mistral не так известны, но заточены под работу с кодом и неплохо работают судя по бенчмаркам, поэтому и попали в сравнение

P.S. Я не спец по ML инструментам, я только учусь)

#ml #tools

Всем привет!

Немного мыслей по AI моделям.

Вышло довольно много open source моделей - LLama от запрещенной Meta, Mistral, DeepSeek, Grok 1 от Twitter. Еще есть Gemma от Google - легкая, возможно не самая новая модель, специализированные модели от OpenAI. Это хорошо, так как дает возможность подключения к разработке моделей команд, не имеющих большого числа денег на GPU. Дообучение моделей (fine tuning) дешевле первичного обучения. Запуск уже обученной модели - тоже дешевле. Плюс open source - это гарантия, что к AI будет доступ даже если сервисы, описанные мной ранее по тем или иным причинам закроются. И Мета конечно выделяется среди остальных тем, что отдала в open source последнюю тяжелую (большое число параметров) версию модели.

Второй момент: в тестах и в новостях сравниваются 2 группы моделей - общего назначения и специализированные. Общего назначения - ChatGPT, Claude, Gemini, Llama, Grok, DeepSeek, Mistral, YandexGPT, GigaChat. Специализированные, на примере разработки - DeepSeek-Coder-V2, Codestral, CodeLlama, Phind, GigaCode. Можно сделать вывод, что модели последнего поколения достаточно мощные, чтобы хорошо справляться со специализированными задачами, типа написания кода. Но любую модель всегда можно подтюнить, и тогда она или превзойдет модель общего назначения или будет сравнима с ней даже имея меньший размер (требуя меньше железа).

Еще тренд - разделение моделей на легкие и тяжелые. Например, LLama 8b, 70b и 405b, это число параметров в billions. Т.е. есть понимание, что большие модели - это дорого в облуживании, при этом во многих случаях применяются для "стрельбы из пушки по воробьям". Некоторые модели позиционируются как доступные для запуска локально. Локально с правильной видеокартой или AI чипом https://ru.msi.com/Landing/AI-Laptop/nb конечно)

#ml #ai #llm

Всем привет!

Поговорим снова о микросервисах. Я уже писал, почему не стоит делать слишком мелкие микросервисы https://t.me/javaKotlinDevOps/305
Но встает закономерный вопрос - "сколько вешать в граммах", в смысле - а какого размера должны быть микросервисы?
Обозначим нижний и верхний предел, а для этого придется вспомнить DDD.

Для начала рассмотрим понятие ограниченного контекста (bounded context). Это связанный набор сущностей из реального мира, для наименования которых используется "единый язык" (ubiquitous language) - непротиворечивый набор терминов. Эти сущности описываются в аналитике, тест-кейсах и превращаются в классы в нашем сервисе и в таблицы в БД. Контекстом как правило занимается одна команда - так проще всего поддерживать "единый язык". И за микросервис тоже должна отвечать одна команда. Т.е. ограниченный контекст - это отличный кандидат на микросервис. Но при этом у одной команды может быть несколько микросервисов. И контекст может быть достаточно большим. Т.е. у нас есть верхняя граница микросервиса.

Теперь рассмотрим понятие агрегата - группу сущностей, имеющую уникальный идентификатор, изменение которой производится атомарно. Т.е. агрегат - граница транзакции в БД. А т.к. возможность делегировать управление транзакцией СУБД - это очень крутая штука, то разделять агрегат между разными БД не стоит. При этом один микросервис = одна БД. Поэтому агрегат - нижняя граница микросервиса.

#microservices #ddd

Всем привет!

Редко даю ссылки на другие каналы, но сейчас сделаю исключение.
Папка с каналами коллег из Сбера - https://t.me/addlist/Hjh12dzfjzhmY2Qy
Сразу скажу - Java и в целом бэк-разработку тут не ищите.
А вот если хотите расширить кругозор - аналитика, тестирование, веб-разработка, облака, AI, менеджмент - есть из чего выбрать.
Выбирайте!)

Всем привет!

Вопрос - где применяется подход DDD?
Аналитика, разработка, тестирование. Конечно архитектура АС, с нее все начинается.
Но это еще не все.
Есть такой класс систем как Data Warehouse (DWH) или аналитическое хранилище данных. В это хранилище попадают данные из всех бизнес-сервисов компании для дальнейшего анализа. Т.об. мы разделяем оперативную БД и аналитическую, снимая лишнюю нагрузку с оперативной БД. Особенность Data Warehouse - технологии обработки и хранения данных отличаются от используемых в системах оперативной обработки данных. Hadoop, Greenplum, ClickHouse... А значит нужны специалисты, которые подготовят хранилище под ваши данные и настроят синхронизацию с оперативной БД. Но эти специалисты не знают ваш домен, в отличие от команды. Плюс они часто становятся "бутылочным горлышком". Плюс структура данных постоянно меняется...
Что делать?
Data Warehouse специалисты готовят инфраструктуру, а за подготовку и синхронизацию данных, актуальность их структуры и способ предоставления этих данных потребителям отвечает бизнес команда. Это же ее bounded context. Подход называется Data Mesh. Вот неплохая статья на эту тему https://habr.com/ru/companies/vk/articles/720652/
P.S. На самом деле DevOps в своем идеальном виде о том же - DevOps инженеры готовят инфраструктуру, а за сборку и деплой отвечает команда.

#ddd #data_mesh

Всем привет!

Cуммирую серию постов про DDD - https://telegra.ph/Izuchaem-DDD--predmetno-orientirovannoe-proektirovanie-08-30

#ddd #books #book_review

Всем привет!

Сегодня расскажу про еще один поучительный факап из моей практики.

Более 10 лет назад. Стартап. Я на данный момент и СТО, и разработчик в одном лице. Есть задача, задача в целом понятна. Декомопзирую на микросервисы и подзадачи, начинаю пилить. Дохожу до XML binding - преобразования XML в объекты и обратно. Да, тогда API в основном были XML. Решил погуглить - что сейчас есть на рынке. Кроме известного многим JAXB нахожу JiXB. Не известный тогда, и тихо умерший сейчас. Читаю описание и нахожу бенчмарк, показывающий что он ... не помню точно, но скажем в 1.5 раза быстрее JAXB. Думаю - о, круто, надо брать. Начинаю прикручивать к Spring приложению. Наталкиваюсь на кучу подводных камней - это не работает, то не работает, документации мало, ошибки не информативные и не гуглятся, т.к. сообщества особо нет. В общем убил неделю на прикручивание к проекту одной библиотеки. В итоге все заработало, конечно. А проект не был доведен до работающего состояния и так и не взлетел - как по бизнесовым причинам, так и по причине неготовности к нужному моменту.

Итоги. До сих пор стыдно за такое проектное решение. Стыдно по следующим причинам:
1) напомню, речь про стартап, т.е. нужно быстро создать работающий прототип, а не исследовать новые технологии
2) преждевременная оптимизация - данных по требуемому RPS и доступному железу на тот момент у меня не было. Нагрузочное тестирование не проводилось. Стал бы JAXB узким местом - далеко не факт
3) использовать в промышленной разработке новые, не доказавшие свою зрелость библиотеки - это риск. Очень важны сообщество (ответы на stackoverflow, а сейчас в AI чате) и работающие без бубна связки, например, Spring+конкретная технология. А риск во-первых должен быть оправдан - см. предыдущий пункт, а во-вторых - должен быть сценарий отката. Если библиотека по факту оказалась сырой - не надо заниматься реверс-инжинирингом, плодить костыли, героически превозмогать трудности. Лучше откатится на какой-то надежный вариант.

#fuckup #xml #java

Всем привет!

Наткнулся сегодня на еще одну книжку про AI. Что опять?)
Для начала у нее интересное название - "Охота на электроовец" https://markoff.science/#book
Но есть еще две причины, по которым я решил про нее написать.
1) книжка научно-популярная - история развития AI и обзор текущего состояния. До сих пор не встречал таких. При этом написана программистом (бывшим программистом судя по текущей должности). Кажется, для вкатывания в тему, если есть пробелы\проблемы в математическом образовании - неплохой вариант.
2) автор - Сергей Марков - из России, что встречается не часто. Более того - автор живет в России на данный момент. Т.е. его можно в теории встретить на какой-либо конференции и позадавать вопросы. Ну и проблем перевода точно не будет)

Скачать можно бесплатно, бумажную версию скоро выпустят тут https://dmkpress.com/catalog/computer/data/978-5-93700-333-1/
Я лично планирую прочитать.
Да, о минусах - иллюстрация на обложке для электронной версии .. ну такое. Ну и 2 тома, 1200 страниц - не всякую дорогу осилит идущий)

P.S. Угадайте, в какой компании работает автор?)

#ai #books

Всем привет!

Давненько не было постов на канале, что поделать - конец квартала, авральный режим on.
Но я вернулся) К делу.

Java всегда славилась своим boiler plate кодом. Ремарка - конечно же не только boiler plate, но сейчас про него и про борьбу с ним. Борьба идет, и в Java 16 (а точнее в Java 14 но в режиме preview) появились records, они же записи.
Делаешь вот такое объявление:
public record Point(int x, int y) {}
и получаешь из коробки конструктор, getter, equals(), hashСode() и toString().
Т.е все то, что раньше приходилось писать руками или использовать Lombok. Ага, Lombok. Т.е. он стал не нужен? Не совсем. Если внимательно глянуть на список того, что под капотом делает record, то можно заметить, что там нет setter-а. Т.е. record - это иммутабельный объект и value object. Две записи с одним и тем же набором полей всегда равны. Это не баг, это фича. Маленькое дополнение - record еще меняет классический getter c getXyz на просто xyz(), но это детали. Еще дополнение - вот тут среди прочих фичей Java 17 достаточно интересно о работе с record https://habr.com/ru/companies/jugru/articles/652821/

Т.е. получается, что record заменяет @Value из Lombok.

Но не заменяет:
1) полноценный @Data - изменяемый класс без boiler plate

2) кейс, когда мы не хотим все сразу getter, toString() ... а хотим только часть этих методов

3) @Builder - тут проще показать, чем объяснять:
Person.builder()
.name("Adam Savage")
.city("San Francisco")
.build();

4) @Log - простое добавление логгера в класс

5) и наконец @SneakyThrows - если вы не любите checked exception

#java #lombok #boiler_plate_free

Небольшое дополнение по Java records. Как известно, Java - это огромное количество библиотек и фреймворков и, следовательно, вопросы совместимости.
Так вот. Spring Boot Web записи поддерживает, как в контроллере, так и в http клиентах. Java сериализация естественно, это же часть спецификации Java. Jackson сериализация. Mapstruct. И Spring Data JPA, там где это возможно, учитывая иммутабельность https://www.baeldung.com/spring-jpa-java-records
Что я забыл? Наверное забыл, но 3 года прошло - поддержку должны были уже запилить)

#java #spring

Всем привет!

Увидел у коллеги аналитика в канале интересное мнение. Разработка - это синоним унижения, т.к. у вас всегда что-то не будет работать.
С мнением не согласен)
Посыл, что что-то всегда не будет работать - абсолютно верный. Причём сломаться может даже сборка проекта, в котором ещё ничего не меняли. Т.е. разработка ещё не началась, а уже что-то сломалось) Обидно)
Только на мой взгляд такая ситуация - это вызов. И в т.ч. и в этом кайф от разработки.

P.S. Но как я писал ранее в посте примере про внедрение проблемной технологии (крепостное слово Jixb): если решение вызова занимает неделю или две, вместо пары дней, и все это время команда ждёт - вы свернули не на ту дорогу. Не всякие вызовы стоит принимать)

#dev

Всем привет!

Продолжим про тестовые библиотеки. Достаточно часто возникает задача проверить в тесте структурированные текстовые данные. Я про XML, json и yaml как самые распространённые варианты. XML первым указан по старшинству, а не распространённости) И он пока ещё жив.

Зачем для этого нужно специализированная библиотека:
1) текст может отличаться формированием - пробелами и переносами строк. Иногда это важно при сравнении, но часто нужно проигнорировать
2) могут быть «лишние» тэги/атрибуты - которые не должны участвовать в сравнении
3) может отличаться порядок тэгов
4) может стоят задача проверить только отдельные элементы в дереве, или их количество

Одной библиотеки для всех форматов нет, но есть две - XMLUnit и JsonAssert. Так думал я, пока не начал копать тему глубже. И искать, чем же можно проверить yaml. Оказывается, есть «более лучшая» замена JsonAssert, которая:
1) умеет и в json, и в yaml, причём может сравнивать json и yaml. И также сравнивать с Java обьектом
2) умеет все это делать в стиле Assert/Truth, он же method chaining. А это облегчает как написание условий проверки благодаря auto competition в IDE, так и их чтение. А возможно в некоторых случаях позволит отказаться от BDD фреймворка.
3) прозрачно работает с разными источниками данных - строка и файл
Встречайте - ModelAssert https://github.com/webcompere/model-assert
И более подробно https://www.baeldung.com/json-modelassert
Что интересно - автор сам написал статью на baeldung и ссылается на неё в документации.
Ещё важный момент - подчеркивается совместимость библиотеки со Spring MockMvc и Mockito. Возможно даже ради этой поддержки автор и запилил совместимость с Hamcrest. И последнее - отдельно продумано тестирование json с guid. Во-первых можно игнорировать различия конкретных значений uuid (они могут генерироваться в каждом тесте), во-вторых легко написать проверку формата uuid.

А что же XML - вот хорошая статья по XMLUnit https://www.baeldung.com/xmlunit2
Он может примерно то же самое, но без method chaining. Но зато с валидацией по схеме (xsd). Что кстати неплохо характеризует отличия в подходах к работе с XML и json)

#unittests #rare_test_libs #XML #json #yaml