Всем привет!

Я снова вернулся)

И предновогодний пост будет снова про AI и Java.

Для начала про LLM. Чтобы LLM дала осмысленный ответ - ей нужен правильный промт и побольше контекста. Не даром в новых версиях моделей объем контекста растет - возьмем тот же Gemini с 1 млн токенов.
Но с точки зрения разработки - важен не только объем, но автоматизация работы с контекстом, т.е. некая бизнес-логики. Например, если мы делаем свой агент и у нас несколько источников точных данных, которые мы хотим скормить модели. И эта бизнес-логика скорее всего будет похожая у разных агентов...
LLM - область достаточно молодая, стандарты в ней зарождаются прямо сейчас. Встречайте MCP https://spec.modelcontextprotocol.io/specification/ - сайт стандарта - и https://habr.com/ru/articles/862312/ - интро на русском.
Он стандартизирует в первую очередь транспортное API - клиент и сервер - для работы с источниками точных данных и LLM. Содержит ряд готовых серверов для работы с файловыми данными, СУБД, веб-поиском.

Как это все относится к Java? А вот как: есть Spring AI, уже писал про него https://t.me/javaKotlinDevOps/241 Он дает универсальное API для обращения к различным LLM. Сейчас туда добавили - в статусе experimental - Spring AI MCP https://docs.spring.io/spring-ai/reference/api/model-context-protocol.html
Причем добавили достаточно быстро, хотя до Python конечно же далеко. Вообще поддержка Python, я полагаю, появилась вместе со стандрартом)

P.S. Да, вспоминая Kotlin в названии канала - если посмотреть примеры Spring AI - получите, распишитесь: https://github.com/spring-projects/spring-ai-examples/blob/main/kotlin/

#llm #spring

Всем привет!

Прочитал статью про работу с секретами в Java: https://habr.com/ru/companies/sberbank/articles/870116/
Лично я из статьи подметил три интересных момента:

1) Сейчас много говорят о безопасной разработке. Книги, доклады на конференциях… Что имеем на практике? Вот есть понятная рекомендация — хранить пароли не в String, а в char[]. Так как String — это объект, и его содержимое будет в heap dump до очередной уборки мусора. А уборка мусора проходит в несколько этапов, и принудительно вызвать её мы не можем. А char[] мы можем очистить сразу после использования. Так вот — в статье у нас есть embedded Tomcat, Jersey HTTP client и Hikari pool. Три широко распространённых компонента, требующих секретов при работе. Сколько из них поддерживают передачу секретов в char[]? Увы, только Jersey client. И это уровень фреймворков и библиотек, на бизнес-уровне всё будет ещё хуже.

2) Перегружаемые настройки Spring Cloud, работающие через @RefreshScope и описанные мною ранее, подходят, увы, не всегда. Основная проблема — передача секрета в компоненты, инициализируемые сложно, однократно при старте или некорректно обрабатывающие событие обновления секретов — например, сбрасывающие активные клиентские сессии.

3) Кроме @RefreshScope изобрели ещё два “велосипеда", причём оба в Spring Boot: SSL bundles и Spring Cloud Vault. Первый предназначен для работы с хранилищами сертификатов, второй — для работы с HashiCorp Vault. Оба поддерживают обновление секретов на лету. Все три инструмента взаимодополняют друг друга, хотя и не покрывают 100% кейсов.

#security #spring

Всем привет!

Разбираясь с HashiCorp Vault, понял, что многие, как минимум я, недооценивают его. Что такое Vault? В первую очередь — безопасное хранилище секретов. Аутентификация и авторизация, хранение всех данных в зашифрованном виде. Причём до ввода мастер-пароля администратором само приложение не имеет к ним доступа. Это всё понятно.

Но есть ещё киллер-фича: автогенерация секретов. Архитектура Vault оперирует понятием движка (engine) для работы с различными секретами. Рассмотрим, как ротация сделана для разных движков.

Движок для работы с сертификатами — PKI engine — умеет перегенерировать сертификаты с истекающим сроком. Вот документация: https://www.hashicorp.com/blog/certificate-management-with-vault

Database engine умеет создавать «одноразовых» пользователей в СУБД с помощью фичи под названием dynamic secrets: https://www.hashicorp.com/blog/why-we-need-dynamic-secrets. «Одноразовых» — то есть с ограниченным временем жизни, на один типовой сеанс работы с БД. Причём API Vault позволяет продлить время жизни пользователя для синхронизации с временем сессии. Не уверен, что любая БД выдержит такой режим работы, но видится, что эта функция сильно увеличивает безопасность работы с БД. Может возникнуть вопрос — как Vault их создаёт. ANSI SQL — это хорошо, но диалекты отличаются, да и в конкретной компании могут быть свои правила. Тут всё просто — SQL-запрос для создания пользователя и выдача ему необходимых прав создаются администратором Vault. Естественно, нужно задать логин и пароль администратора СУБД, под которым будут выполняться эти запросы. Но кажется, Vault вполне можно считать безопасным местом для их хранения. Больше деталей здесь: https://www.baeldung.com/vault, а в части интеграции со Spring Vault — здесь: https://www.baeldung.com/spring-cloud-vault.

Также есть возможность ротировать пароли доменных пользователей, используя Active Directory engine — см. https://developer.hashicorp.com/vault/docs/secrets/ad.
И обычные пароли: https://www.hashicorp.com/resources/painless-password-rotation-hashicorp-vault. Странно, что для последнего нужен внешний плагин, но такая возможность есть.

Итого: автоматическая ротация секретов и распространение их с помощью Vault Agent (в виде сайдкаров или JAR-библиотек) выглядят крутой фичей в плане безопасности и упрощения работы администраторов. Наверняка на этом пути будут подводные камни, но путь однозначно верный.

#security #vault #spring

Всем привет!

Нашел хорошую статью и проект, показывающий как должны работать компоненты телеметрии (OpenTelemetry) в связке:
Статья: https://habr.com/ru/companies/otus/articles/761334/
Проект: https://github.com/marcingrzejszczak/observability-boot-blog-post

Слава Docker, развернуть все это у себя на машине можно в пару кликов) Что настоятельно рекомендую сделать.

На что хотелось бы обратить внимание:
1) на одном дашборде собраны трейсы, метрики и логи
2) из лога по атрибуту traceId можно провалится в трейсы и наоборот
3) на панели метрик нужно присмотреться к "ромбикам" - это т.наз. exemplars - метаданные метрики, включающие связку метрики и трейса. И естественно из метрики тоже можно провалиться в trace.
4) еще удобная фича - на большом мониторе можно раскрыть рядом окно трейсинга и логов. Я не про 2 окна ОС, а это встроенная фишка Grafana
5) достаточно удобный формат работы с телеметрией в коде: открываем контекст OpenTelemetry, что приводит к тому, что автоматически формируются идентификаторы трейсов и добавляются ко всем метрикам и логам внутри контекста. Открыть контекст можно как императивно - вызовом метода, так и декларативно - аннотацией.

Ну и ложка дегтя - если брать последний коммит из репозитория выше, то там перешли на OpenTelemetry протокол для метрик, в котором exemplars не поддерживаются. Чтобы увидеть все в сборе надо откатиться на несколько коммитов, но при этом зафиксировать версию образа Grafana Tempo (сервер для трейсинга), т.к. последние его версии похоже не поддерживают Zipkin протокол, на котором работают exemplar) Похоже, стандарт становится зрелым прямо сейчас.

#telemetry

Всем привет!

Возвращаюсь к теме хранения секретов — вот ещё неплохая статья https://habr.com/ru/articles/872128/
показывающая, что если вы «доросли» до вопроса управления секретами, вариантов немного.
Если вы находитесь в коммерческом облаке — Google, AWS, Azure, и скорее всего Яндекс, VK, Сбер — там будет встроенное хранилище секретов, и логично его использовать. Иначе — все дороги ведут в Vault.
Если рассмотреть альтернативы из статьи:
1) Docker Swarm умирает, проигрывая Kubernetes.
2) BuildKit — технология в себе, закрытая в плане сообщества и документации.

#security #vault

Всем привет!

Я не открою Америку, если скажу,  что ИТ-шников не хватает, а поток людей, «входящих в ИТ», растёт. Процесс начался не сегодня. Один из основных стимулов — уровень зарплаты. И у этого процесса есть следствия.

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

Влияет ли на этот образ массовый найм людей, пришедших за высокой зарплатой? Очевидно, да. Ремарка: я не говорю, что все «вошедшие в ИТ» пришли за длинным рублём. Но очевидно, что массовый найм приводит к росту доли таких людей.
О ком я говорю? Это люди, которые работают строго с 9 до 6. Даже если проект «горит». Не хотят выходить за пределы своих обязанностей, причём обязанностей, как они их поняли. Возможно, не любят или ненавидят свою работу.
К чему это приводит?

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

Что с этим делать?

Есть работающий рецепт от Яндекса — алгоритмы на собеседованиях, работа по T-shape после найма, личная ответственность за вывод фичи в продакшен. Подходит не для всех компаний.

Для остальных я вижу один вариант: отсев на собеседованиях и испытательном сроке по soft skills. То есть и эксперт на собеседовании, и ментор должны плотно работать с новичком. На собеседованиях с этим могут помочь HR-ы. Понятно, могут помочь, а могут и не помочь) Хотя кажется, должны.

P.S. Ещё есть надежда на ChatGPT)

#it #найм

Всем привет!

Ну что, AI уже заменил джунов
https://habr.com/ru/news/876162/
?
А если серьёзно - это третий шаг в эволюции LLM:
1) запрос-ответ по данным модели
2) обогащение ответа модели актуальным результатами поиска (AI search, например, Perplexity или SearchGPT) или результатами из локальной базы знаний (RAG)
3) AI agent - не просто отдаёт отчёт, но и делает что-то полезное, но рутинное. В IDE, локальной сети или в интернете. По запросу или в фоновом режиме.

Что ж, движение в верном направлении.
Вот пример агента не из мира разработки https://t.me/disruptors_official/2177
Главное, чтобы качество Junie было на уровне, на данный момент AI - не самая сильная сторона JetBrains.

P.S. GigaCode, к слову, идёт туда же. Один из лидеров - Cursor AI. Позволяет восьмилетним детям писать код))) https://vc.ru/services/1456812-vosmiletnie-deti-teper-mogut-sozdavat-prilozheniya-s-pomoshyu-iskusstvennogo-intellekta-obzor-ii-instrumenta-dlya-programmirovaniya-cursor

P.P.S. Вопрос. Если заменить всех джунов - откуда возьмутся миддлы и сеньоры?)

#llm

Всем привет!

В последнее время все чаще вижу, как LLM в IDE используют для генерации каркаса приложения. Казалось бы - это же задача генератора, а не LLM. Какого-нибудь Spring Initializr (https://start.spring.io/) Почему он этого не делает, а ограничивается по сути только pom-ников или *.gradle?

Потому что это отдельный сервис, требующий поддержки. Который со временем - по мере развития библиотеки, фреймворка или платформы, для которой он предназначен - будет обрастать все более сложной логикой. Обновился фреймворк - нужно обновлять генератор. Появился смежный компонент - будут запросы на добавление интеграции с ним. И при этом генератор все равно будет ограничен в возможностях. Возьмем тот же Amplicode - контроллеры, обработчики ошибок и тесты для Spring приложения он генерировать умеет, что-то еще - нет. Со временем возможностей для генерации будет больше, но 100% кейсов не будет покрыто.

А LLM в теории может сгенерировать что угодно, главное "скормить" ей побольше типового кода. Ключевое слово здесь - типового. Т.е. какую-то сложную логику тоже можно сгенерировать в LLM, но если размер диалога будет в 10 раз больше сгенерированного кода, а время - сравнимо, есть ли в этом смысл? Да, модель нужно будет периодически "подкармливать", но видится, что эту процедуру можно автоматизировать взяв за исходные данные открытый код из того же github.

Есть еще нюанс. LLM - это аналог MP3 128 kBit Joint Stereo ))) Сжатие с потерями. Это если что моя оценка вида "пальцем в небо", очень может быть степень сжатия больше. Распаковка - генерация кода - тоже приведет к потерям. Как проверить, что потерь нет - компиляция, тесты, а главное - предварительная оценка того, насколько типовой код нужен. В итоге для простых задач мы получаем универсальный генератор. И это круто!

P.S. Может показаться, что я наехал на Spring Initializr. Нет, штука полезная. Фактически Spring задали стандарт на рынке - все конкуренты Spring сделали свои инициализаторы: https://code.quarkus.io/ и https://start.microprofile.io/ И в Enterprise я видел попытки сделать свои инициализаторы разной степени успешности.

#llm #ai #code_generation

Всем привет!

Учитывая бурный рост AI - в части возможностей и точности ответов - возникает вопрос: что будет с профессией программиста в частности и ИТ-шника в общем?
Пару мыслей по этому поводу.

1) ИТ-шники никуда не денутся - исследовательские задачи по созданию чего-то нового AI не отдашь по определению, аналитику\промты нужно писать, результат - контролировать, AI агенты - кому-то создавать, pipeline - настраивать. Число задач по автоматизации, их сложность растут и похоже будут расти дальше.

Что изменится?

2) Для начала - должна вырасти производительность. Пример: объяснить почему при наличии AI простая формочка делается несколько дней будет сложно. Хочешь - не хочешь, фичей придется выдавать больше. Можно привести аналогию со станками и конвейером - и то, и другое позволило в разы увеличить объем производства. А если брать более близкий нам пример - появление персонального компьютера, на который не надо записываться в очередь и скармливать ему перфокарты - также сильно увеличило производительность программиста. Получаем реально существующий NZT - ускоритель для мозга или bycicle of mind - за напоминание спасибо @AViIgnatov!

3) Со многими вещами из первого пункта можно поспорить - точно ли нельзя человека заменить машиной? Но вот с чем спорить сложно - машина не может нести ответственность. А во многих отраслях - авиация, космос, транспорт в целом, мирный атом, медицина, финансы - отвечать за ошибку кто-то должен. Авторы LLM модели, очевидно, это делать не будут. Иначе условный Сэм Альтман будет не вылезать из судов. Менеджер, внедривший модель тоже - а как он сможет проконтролировать код, созданный моделью? Да, наверняка есть кейсы, когда можно доверить машине и генерацию, и оценку качества кода, а в случае ошибки - просто дообучить модель и перегенерировать код, а клиентам вернуть деньги. Но это, кажется, небольшая часть существующих ИТ систем. Итого - человек нужен, но ответственность его также возрастет. Похожая проблема, кстати, сейчас с автопилотом - там нет LLM (я надеюсь), но вопрос ответственности при аварии при включенном автопилоте пока не решен.

4) интересный вопрос насчет T-Shape vs узкий специалист. С одной стороны узкого специалиста сложнее заменить, особенно, если его фреймворк не очень распространен. С другой стороны рутина отдается на откуп LLM, поэтому от менеджеров будет ожидание горизонтального роста на смежные специализации. Что можно сказать точно - разработчик узкого профиля, умеющий в аналитику, тесты и не боящийся ПРОМа - точно незаменим)

5) Самый интересный момент - что будет с джунами? Т.к. теперь джун должен уметь не только писать промты, но и проверять качество кода. Это либо повышенные требования к ВУЗу\курсам, или растянутая по времени стажировка, во время которой джун должен "обогнать" LLM. Хорошая новость: если вы - джун время прокачаться до сеньора еще есть)

#it #llm

Всем привет!

Вот только написал, что исследовательские задачи — точно не место для AI, как на тебе https://t.me/andre_dataist/172 )))

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

P.S. Ещё интересны 4 и 5 уровень развития моделей из поста выше.

#llm #ai #it

Всем привет!

Я долго держался, но не написать о Deepseek всё же не смог)

Что хотелось бы отметить:
1) Модели уже больше года, а в январе стали известны (распиарены) результаты её последней версии

2) Начиналось всё с модели для разработчиков, называется Coder, потом был Coder v2

3) Тренд на универсализацию моделей продолжается, сейчас Coder недоступен на официальном сайте, только основная модель

4) В окне ввода промпта можно включить объяснение логики получения ответа — и это новый тренд. По сути это данные аудита. В применении к AI-агенту — данные будут храниться определённое время для разбора полётов

5) И последняя фича DeepSeek — возможность AI-поиска, уже не тренд, а скорее становится базовым требованием

6) Разработчики Deepseek связаны с алгоритмическим трейдингом. С одной стороны, это деньги на разработку модели и железо, с другой — источник знаний для оптимизации модели. В алгоритмическом трейдинге решают миллисекунды

7) Ну и наконец — «я же говорил».
Пост про сравнение AI-моделей: https://t.me/javaKotlinDevOps/331. Единственный момент — тогда мне больше понравилась Perplexity. Надо будет сравнить ещё раз)

8) В Perplexity уже встроили модель Deepseek как один из вариантов

9) Deepseek можно развернуть локально, см. инструкцию https://habr.com/ru/articles/878276/. Т. е., в open source выложили всю модель. Удивляют системные требования

10) Ходят слухи, что Deepseek будут внедрять и в одной крупной российской ИТ-компании.

#llm #ai

Всем привет!

AI быстро развивается, интегрируется с традиционным ПО и было бы странно, если бы и для AI не появились ... свои паттерны)
Встречаем, от одного из лучших специалистов по паттернам: https://martinfowler.com/articles/gen-ai-patterns/

Маленький комментарий: да, AI паттерны могут показаться элементарными, но свою роль они выполняют - это некий язык, кубики, из которых строится архитектура приложения/корпоративная архитектура.
Еще хорошо написано про такую важную штуку как оценка (eval). Ведь модели не идемпотентны - могут менять свой ответ на одних и тех же входных данных. А значит традиционные практики тестирования не подходят. Модель тестирующая сама себя - прямой путь к скайнету) А вот если взять другую модель, а для страховки отдать результат на проверку человеком...

#llm #ai #testing #patterns

Всем привет!

Не отпускает меня тема AI)
Напомню, что с одной стороны AI ~= Python, но с другой стороны Java потихоньку подтягивается, о чем я уже писал на канале, см. по тегам.

Вот отличный пример генерации данных с помощью AI с запоминанием контекста на Spring AI https://piotrminkowski.com/2025/01/28/getting-started-with-spring-ai-and-chat-model/
Обратите внимание на "магию" Spring - в части преобразования ответа модели в коллекцию.
А вот тут https://piotrminkowski.com/2025/01/30/getting-started-with-spring-ai-function-calling/
на "магию" привязки функций, забирающих данные из API брокера и с сервиса-поставщика биржевой информации к вызову модели.
Красиво, черт возьми!)

P.S. Интересно, учитывая недетерминистическое поведение модели - всегда ли эта магия работает. Буду проверять)

#ai #java #spring

Всем привет!

Протестировал последнюю версию GigaCode, доступную наружу, небольшой итог.

Что понравилось:
1) неплохо генерирует тесты, подбирает разные входные данные для попадания в разные ветки алгоритма. Не уверен, что полнота покрытия 100%, но неплохо
2) генерирует каркас для Spring приложения - контроллер, сервис, адаптер. Да, AI генерация рулит.
3) можно использовать для подключения новых библиотек по имени класса. Единственный минус - подставляет не последние версии
4) может заменить все println на вызов логгера в файле
5) GigaCode научился работать с контекстом всего проекта, а не только открытых файлов. По факту: на больших проектах не тестировал, но на малых все равно делает ошибки - в autocomplete предлагает несуществующий метод. Похоже имя метода генерируется как производная от названия переменной, в которую сохраняется результат вызова) К слову, встроенный в IDEA бесплатный AI делает ровно те же ошибки. Нужен ретест, но в любом случае это движение в правильном направлении.
6) находит ошибки при вызове /improve. Не все, на моем тестовом файле с порядка 50 ошибками нашел 4. Уже что-то. Предложил использовать try-with-resources, конкатенацию строк заменить на StringBuilder, также нашел проглатывание ошибки без логирования и некорректное удаление в цикле. Также умеет удалять дублирующиеся методы. Но не умеет выносить повторяющийся код в отдельный метод.
7) вызов /review - тут уже интереснее. Я вызывал его до /improve и после. На первом ревью модель нашла отличающийся по сравнению с improve набор проблем. Понятно, для некоторых из них простого фикса нет, но например найденный на ревью возврат null можно было бы пофиксить на improve. Еще интереснее прошло ревью после применения улучшений. Модель поставила под сомнение использование try-with-resources и StringBuilder сказав, что "в данном случае это не имеет большого значения, так как количество строк в файле, вероятно, не очень велико". Как она поняла, что данных мало - непонятно) Вообще говоря, замечание справедливо, в разработке очень редко можно дать однозначный ответ без уточнения деталей. Но как будто бы пропущен вопрос - с каким объемом данных мы работаем? Аналогично, про правку при удалении в цикле - уменьшение счетчика, сказала, что он затрудняет читаемость и может привести к ошибкам. Т.е. 3 из 4 собственных правок под вопросом) Еще модель выдала неверное замечание про то, что try-catch приводит к созданию объекта исключения, хотя по факту он возникает в библиотечном коде, который вызывается внутри try-catch

И три недостатка:
1) команда /doc Да, она хорошо генерирует JavaDoc по названию и содержанию метода. И да, есть такое правило в SonarQube. Но я считаю, что правило обязательных JavaDoc надо отключать, методы, переменные и классы называть осмысленно, и только в отдельных сложных случаях добавлять JavaDoc. Видимо сделано для ленивых программистов)
2) кэширование. Тестируя /review и /improve на изменяющемся файле постоянно сталкиваюсь с тем, что ошибка уже поправлена, а модель все еще ругается на нее. Да, для review помогает ctrl+enter, непонятно зачем на обновление контекста нужно отдельное сочетание клавиш. А improve по-прежнему пытается исправить уже исправленные ошибки)
3) для improve напрашивается кнопка "заменить", т.к. сейчас приходится выделять все и жать на insert

Вывод - в целом использовать можно.

#llm #ai #gigacode

Всем привет!

Нужно ли хранить информация об архитектуре АС?
Я считаю, что да, нужно.
Почему?
1) контроль интеграций
2) контроль использования компонентов и технологий
3) обмен информацией между командами

Т.к. в канале была серия про AI - вспомним его и сейчас. А что если AI агент будет ходить по репозиториям и собирать информацию об архитектуре в одном месте? В теории да, но есть ряд важных нюансов:
1) доступы ко всем репозиториям. В целом решаемо.
2) достаточность данных в коде для точного определения архитектуры. Трудно решить, часто нужных данных просто нет в коде, т.к. они стендозависимы. Отсюда потенциальные пробелы и галлюцинации.
3) мы получаем слепок AS IS, но TO BE все равно придется рисовать ручками

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

Поэтому пока рассмотрим другие варианты.

Ок, заводим отдельную АС для хранения архитектуры. Есть UI, можно легко описывать компоненты, интеграции и технологии.

Да, я совершенно забыл о главной проблеме - я практически не встречал разработчиков, горящих желанием описать архитектуру. Где-то на уровне техлида появляются такие люди. Техлид по определению отвечает за архитектуру, но встречается он редко(

Что же делать? А пусть команды сами выбирают, кто отвечает за описание. Весьма вероятно, что этим кем-то станет аналитик. Аналитик конечно же знает архитектуру, но сверху, до определенного уровня. Например, на уровне единиц деплоя, технологий точно будут проблемы. Ок, архитектура описана. К чему приведет данных подход? К тому, что в нашей архитектурной АС будет некое представление актуальной архитектуры, неполное, устаревшее сразу после создания. И поддерживать такую архитектуру в актуальном состоянии никто не будет. Если только из под палки. И самое главное - системой никто не пользуется. Но заполнять надо(

Итого - так можно, но не нужно делать.
Какие главные проблемы:
1) нежелание разработчиков работать за пределами IDE. А именно разработчик понимает архитектуру в целом, как минимум с уровня Senior
2) UI представление данных, к которому так просто не применишь diff и которое легко сломать
3) разрыв AS IS и TO BE - релиза и архитектуры

И, соответственно, как их фиксить:
1) у нас есть IDEA и рабочий проект в git, архитектура должна лежать в проекте вместе кодом. Также нужен плагин IDEA для удобства работы с файлами архитектуры
2) по аналогии с Infrastructure as Code, Documentation as code - Architecture as Code. Вообще говоря Everything as Code, но сегодня про архитектуру). Т.е. все в текстовом виде. OpenAPI, PlantUML в эту парадигму отлично вписываются
3) актуальная архитектура хранится в ветке релиза и согласовывается командой на уровне Pull Request (Merge Request). Целевая - в централизованном репозитории, тоже в git. Актуальная архитектура синхронизируется с целевой тоже через Pull Request, но уже с другими согласующими.

Если до сих пор казалось, что я слишком абстрактен - открою тайну, я веду к конкретной системе, о которой недавно узнал - DocHub.
Снова спасибо @AViIgnatov

Исходники https://github.com/DocHubTeam/DocHub
Живой проект с описанием архитектуре на примере самого себя: https://dochub.info
Цикл статей на Хабре: https://habr.com/ru/articles/659595/ и далее по автору.
К слову, разработка российская, из rabota.ru

Итого: я не уверен, что DocHub - это серебряная пуля. Не могу гарантировать, что он решит проблему контроля и вообще наличия актуальной архитектуры в компании. Все-таки, повторюсь - очень мало людей хотят описывать архитектуру, во многих командах нет соответствующей роли. Я про факт, а не формальности. Но у данного подхода IMHO шансов побольше, чем у всего, что я видел.

#aac #arch

Всем привет!

Маленький факт. Судя по индексу языков TIOBE мы находимся на второй волне интереса к теме AI. И эта волна существенно сильнее первой.

P.S. Зеленая линия - Java, есть небольшой подъем после длительного спада

#ai #python #java

Всем привет!

Недавно обсуждали с коллегой необходимость JavaDoc\KDoc и в дополнение к высказанным ранее мыслям https://t.me/javaKotlinDevOps/183 возникла еще одна.
Напомню, основная моя идея была такая: массовый JavaDoc бесполезен, он должен быть точечным - там где назначение кода не понятно из наименования.

Немного переобуюсь) Массовый JavaDoc все же может быть полезен. Где? Для для описания монолита. И при одном условии.

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

А условие, точнее 3 условия, такие:
1) при каждой сборке develop ветки должен собираться и выкладываться актуальный JavaDoc. Тут даже мало JavaDoc артефакта, нужен сайт, где его можно прочитать. Например, GitHub Pages\GitLab Pages или аналоги.
2) должна быть точка входа или оглавление, например readme.md.
3) при написании документации и в особенность на ревью кода нужно обращать внимание не на наличие JavaDoc, а на его содержимое

P.S. Но JavaDoc конструкторов - все равно зашквар)

#javadoc #documentation

Всем привет!

Хочу порекомендовать хорошую статью на Хабре о необходимости кэша.
https://habr.com/ru/companies/oleg-bunin/articles/883422/
Со сравнительными тестами Redis, Memcached, PostgreSQL и MySQL.

Из статьи я почерпнул для себя несколько основных тезисов:

1) в наше время получить 1 000 000 rps с сервера на чтение - это реальность. И это круто! Речь про стандартный сервер, а не 100 ядер\1000 Гб памяти как можно было бы подумать

2) реляционные СУБД приблизились к кэшам (key-value noSQL хранилищам если хотите) по скорости чтения

3) как правильно заметил автор: будь он СТО - не разрешил бы использовать СУБД как кэш. И вот почему. Сравнимая производительность БД-кэш достигается при 2 условиях - нет операций записи в БД (а соответственно и блокировок записей) и все выборки идут по первичному ключу (это самая быстрая операция выборки). Казалось бы - соблюдай эти условия и все будет работать. Но ведь у нас СУБД. Окей, GRANT на запись отберем у всех. Но ведь СУБД может сложные JOIN-ы. И это никак не ограничить правами. Там могут быть сложные индексы. И рано или поздно найдется разработчик, которые эти возможности захочет использовать))) И в пике производительность упадет даже не в разы, а на порядки. Например, не провели НТ. Или забыли обновить профиль НТ. С кэшом такого по понятным причинам не произойдет. Вывод - у каждого инструмента свое назначение.

4) проблема неконсистентности данных кэш-БД все равно будет. Поэтому перед тем, как добавлять в систему кэш - стоит подумать, провести НТ и еще раз подумать. Возможно где-то есть или планируется архивная реплика БД. Там проблема констистентности данных решается механизмом репликации .Если часть нагрузки на чтение увести на нее - возможно кэш и не нужен.

P.S. Отдельная интересная тема: PostgreSQL показывает, что принцип число процессов ОС = числу ядер - не аксиома)

#rdbmc #cache #arch_compromises

Всем привет!

Один из достаточно частых вопросов на собеседованиях - расскажите про стримы в Java, их плюсы и минусы. Если говорить о минусах - всегда под вопрос ставится быстродействие. У меня давно было желание его сравнить, но как часто бывает - меня опередили.
Вот неплохая статья про быстродействие стримов: https://habr.com/ru/articles/807647/

Какие выводы я сделал:

1) тот факт, что на небольшом объеме данных цикл forEach опережает любые виды стримов - ни о чем, им можно пренебречь. Как минимум в 99% случаев. Мне сложно представить кейс, когда объем данных невелик, но нужно выиграть миллисекунды. Скорее всего эти миллисекунды, или даже десятки миллисекунд, мы потеряем на сетевом взаимодействии. У нас же микросервисы, а это значит много сетевых вызовов. Если говорить о причинах - понятно, что на малых объемах данных накладные расходы, которые конечно же есть у стримов, играют роль. И еще момент - чем проще кусок кода, выполняющийся внутри стрима, тем больше отношение накладных расходов стримов к полезному действию.

2) parallelStream в большинстве случаев бьет forEach на больших объёмах данных. Почему так тоже понятно - эффект распараллеливание становится выше, чем накладные расходы на определенном объеме данных.

Итог: стримы можно использовать как вариант по умолчанию, т.к. они улучшают читаемость кода. В высоконагруженных приложениях\ больших объёмах данных имеет смысл смотреть в сторону parallelStream, особенно если есть результаты нагрузочного тестирования. Ну и только на каких-то критичных участках кода, имея на руках результаты НТ, имеет смысл переписать все на циклы

#streams #performance #interview_question

Всем привет!

Случайно наткнулся на старую статью - 2015 год - про переход с legacy на Service Oriented Architecture ака SOA.
И хочу сказать, что это хороший пример развития истории по спирали)

Что в статье актуально?
Заменяем слово SOA на микросервисы, и в целом все, что касается преимуществ микросервисной архитектуры и стратегии перехода на нее - актуально. Микросервисы = SOA 2.0 )))

REST оставляем, SOAP+XML заменяем на gRPC\GraphQL для тех случаев, когда требуется большая производительность и гибкость соответственно по сравнению с REST. К слову, недостаток производительности и гибкости - это основные проблемы SOAP. Ремарка - знаю места, где SOAP еще жив (интеграция с госорганами), но он в любом случае вымирает.

ESB, трудности реализации асинхронного взаимодействия - все эти задачи взяла на себя Kafka. Прорывной инструмент - быстрый, надежный (обеспечивает дешевую персистентность), opensource, простой с точки зрения разработчика. В т.ч. потому, что нет необходимости разрабатывать логику маппинга сообщений на брокере. Да, он реализует только одну из двух основных моделей асинхронного взаимодействия - Publisher-Subscriber - и не реализует Message Queue. Но понятно, что топиками можно пользоваться как заменой очередей, и в большинстве случаев проблем при этом не будет.

Облачные решения - за 10 лет из вызова превратились в новую реальность)

А вызов сейчас - внедрение AI. Как-то так)

#microservices #ai #cloud #kafka #rest

Всем привет!

Возращаясь к тебе legacy.
Давно хотел прочитать книжку Эффективная работа с унаследованным кодом. legacy в жизни разработчика есть всегда (если только он сознательно не ищет только greenfield проекты), поэтому тема полезная. Книга не новая, но судя по отзывам (и по факту как выяснилось) актуальная.

Небольшое введение в тему. Есть 2 способа бороться с легаси - я бы их назвал архитектурный и програмистский. Архитектурный - взять и сделать рядом новую систему, постеменно перетягивая туда функционал и используя такие паттерны как Strangler Application, API Gateway, Decorator, Facade...
Програмисткий - улучшать легаси изнутри, делить его на микросервисы по необходимости и т.д. Это конечно крайности, как правило используется смесь обоих подходов.

Так вот - книга про второй способ. Я ожидал найти там набор практик и паттернов по улучшению легаси. И более того - они там есть. Но главная мысль в книге другая, и она немного неожиданная. Сразу вспомнилась шутка: как только код написан - он уже стал легаси) И так может быть) Если мы даем такое определение легаси - много кода без тестов. Почему? В чем основная проблема легаси? Никто не знает досконально как оно работает, никто не хочет с этим кодом разбираться и, как следствие, его боятся менять. Очевидно, что если кода много и тестов нет - менять его страшно. Бинго. И собственно вся книга о том, как написать недостающие тесты даже если на первый взгляд это кажется очень сложным.

#legacy #book_review