На Highload услышал упоминание про timeout propagation и вспомнил, что давно хотел эту тему поднять.
В чем суть - где-то настроен timeout, и для того, чтобы upstream сервисы знали про него - мы передаём его в заголовках, также как и traceId. Наилучшее место для создания этих заголовков - входной шлюз. Или API Gateway - именно так сделали в Avito. Передать таймуат можно двумя способами - как длительность, X-Timeout = 5s или как время - X-Deadline: 06.12.2024 14:55:45. Второй вариант проще обрабатывать на upstream серверах, т.к. не нужно вычислять сколько из первоначального таймаута осталось, но требуется синхронизация времени на всех серверах.

Казалось бы - добавили таймаут, пробросили по цепочке, сервисы знают дедлайн и могут прервать обработку и не тратить лишние ресурсы, если результат уже не нужен. Вот он профит.

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

#reliability #timeout

Всем привет!

Уже писал про импортозамещение в ПО:

1) IDE https://t.me/javaKotlinDevOps/353
2) Spring plugins https://t.me/javaKotlinDevOps/358

Две ремарки - термин импортозамещение сильно скомпрометировали, но другой более удачный я пока не придумал) И некоторые из описываемых продуктов разрабатывались не для импортозамещения, но события последних лет дали неплохой импульс для их развития.

Так вот, на Highload-е нашёл 2 аналога GitLab/GitHub:

1) GitVerse от Сбера. Как и GigaIDE находится в процессе разработки, в частности аналог Git Actions планируют допилить в ближайших релизах, сейчас для настройки требуется много ручных действий. Две основные фишки: интеграция с GigaCode и облачная IDE на основе VS Code, доступная в рамках бета-тестирования. Для облачной IDE нужен аккаунт и настройка в облаке Сбера - cloud.ru. И к сожалению не поддерживается Java - зато есть Python, Go, С#. Интерфейс аскетичный, но подсветка синтаксиса, AutoComplete, работа с тестами, отладка и консоль есть. Пока все бесплатно, конечно временно) Еще фишка - доступно AI ревью кода https://gitverse.ru/docs/collaborative-work/code-review/#ai-ревью И в целом ревью неплохое - я скормил ему кусок кода "с запахами", и AI нашел там 6 багов из 18. Минус: все работает медленно - думаю сказывается бесплатность и статус беты.

2) GitFlic от Астра (которая Linux). В нём есть Ci/CD, реестр артефактов, статический анализ кода (названный почему-то SAST), REST API и интеграция с Telegram и JIRA. И платная версия, позволяющая добавлять более 5 человек в private репозиторий плюс расширенную поддержку https://gitflic.ru/price Пока нет полноценно баг-трекера, обещают сделать. Еще плюс - тут я быстро нашел как разрешить force push, в отличие от GitVerse)

GitFlic на данный момент выглядит законченным продуктом, но у GitVerse есть свои плюсы - см. выше. Плюс тесная интеграция с облачным провайдером cloud.ru

#импортозамещение #git

В нескольких недавно выпущенных русскоязычных книгах замечаю отдельное упоминание о научном редакторе, являющимся практикующим ИТ инженером. Аллилуйя!) Google translate и студентов лингвистических вузов маловато для качественного перевода) Надеюсь, это станет стандартом

#books

Всем привет!

Читаю сейчас книжку Open Telemetry, первая глава, вступление о том, зачем все это нужно.
Обычно во вступлении не так много ценной информации, но бывают исключения)

Нашел сравнение Open Telemetry с DevOps. Казалось бы, что может быть у них общего? Кроме того, что DevOps инженеры настраивают Open Telemetry систему совместно с разработчиками и сопровождением.

Ответ - идеология.

Для начала - что такое DevOps?
Набор инструментов - да. Но в первую очередь идея о том, что для быстрого деплоя приложения на ПРОМ важно сотрудничество Dev и Ops, а также забытых в этой формуле Test и Sec)

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

Читаю дальше)

Ввожу новый тэг -
#telemetry

Всем привет!

Есть много способов получить данные из БД с помощью JPA:
1) JPQL
2) JPQL Native Query
3) HQL
4) Spring Data JPA Repository
5) Criteria API
6) QueryDSL
...

Предположим, нам нужно вернуть набор строк. Задать параметры запроса можно по-разному, а итог будет один - List или другая коллекция (Collection) с набором данных. Верно? Не совсем)
Если посмотреть на список возвращаемых Spring Data JPA данных https://docs.spring.io/spring-data/jpa/reference/repositories/query-return-types-reference.html#appendix.query.return.types то там можно увидеть много чего интересного. В т.ч. Stream.
А вот пример его использования: https://vladmihalcea.com/spring-data-jpa-stream/
Аналогично можно вернуть Stream и из обычного JPA - см. метод getResultStream, вот пример: https://thorben-janssen.com/jpa-2-2s-new-stream-method-and-how-you-should-not-use-it/

Зачем это может быть нужно?

Во-первых это просто красиво... Шучу. Если вы используете Stream в бизнес-логике - то кажется логичным использовать их и при обращении к БД.
А во-вторых: главная особенность стриминга - равномерная выборка данных. И в каждый момент данных в обработке будет одна запись.
Рассмотрим кейс, когда нужно обработать на клиенте миллион записей.

Ремарка: если у вас такой кейс - подумайте, нет ли проблем в архитектуре. Данные лучше обрабатывать на сервере СУБД. Если все же проблем нет - продолжим)

Так вот, какие у нас варианты:
1) вытащить на клиент миллион записей. Запрос к БД будет один, она выдержит, но с неплохой вероятностью можно убить клиент через Out of Memory.
2) организовать пагинацию, например, вот так: https://www.baeldung.com/spring-data-jpa-iterate-large-result-sets. Данных на клиенте в моменте не много, по размеру страницы, но запросов к БД ... тысяча.
3) использовать стримы. Запрос к БД один, данных на клиенте немного. Не обязательно одна запись, но в любом случае немного, детали ниже.

К слову, стриминг по БД с JPA аналогичен перемещению курсора по ResultSet в JDBC. С накладными расходами и плюшкам, которые дает сессия JPA, конечно.

И про объем данных на клиенте. Казалось бы - вытаскиваем записи поштучно. Но если не указать fetch size - объём предварительной выборки - для некоторых СУБД Hibernate вытащит на клиента все данные за раз, и мы вернемся к варианту 1 (((

#jpa #java_streams #rdbms

Всем привет!

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

И предновогодний пост будет снова про 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