tgindex

(java || kotlin) && devOps

описание

Полезное про Java и Kotlin - фреймворки, паттерны, тесты, тонкости JVM. Немного архитектуры. И DevOps, куда без него

← к каналу@javaKotlinDevOps
342
подписчиков
Охват к подписчикам
29,8%
ERR
Реакции к просмотрам
0,52%
31 на 50 постов
Пересылки к просмотрам
0,25%
15
Постов в день
0,4
всего 104

Где отзываются чаще

доля реакций к просмотрам
  • 18 июн.Чем нам конкретно поможет AI? В данном случае я говорю про помощь в разработке. Уже писал про написание, а главное поддержание актуальности в документации https://t.me/javaKotlinDevOps/565 Теперь пришло время поговорить про другую важную штуку - TDD. Что это - Test Driven Development - я думаю знают все. Знают, но не используют. Почему? Особенно хочу подчеркнуть один момент. С кем бы я не говорил на эту тему - общаясь по работе или на собесах - никто не сказал: "Да фигня этот ваш TDD". Все знают, все пробовали, но никто не применяет на работе. Почему? Ответ видится таким. Есть задача. Есть ограниченное время. Которое можно потратить на проектирование, кодирование, тесты, отладку, документирование. Есть такой закон с немного странным названием - закон Паркинсона. Он гласит: «Работа заполняет всё время, отведённое на неё». И он применим в ИТ) Увы( Так вот - что в первую очередь будет выкинуто, чтобы успеть вовремя? Очевидно документирование и тесты. А оптимизировать тесты (и документацию) проще, если они запланированы на самый конец. И прощай TDD( Да, все понимают, что тесты - это хороший способ документировать код, это помощь при будущих рефакторингах, это сетка, предотвращающая сползание в легаси. А TDD - способ гарантировано иметь тесты и тестируемое Java API. Но ... нет времени. А далее сервис медленно, но верно превращается в легаси. Вспоминается грустный анекдот: "... А чё тут думать! Трясти надо!" К чему я веду? AI уже берет на себя большУю часть кодирования. AI быстро пишет код. AI не лень писать тесты. Точнее как - конечно же лень, любая LLM модель натренирована на получение быстрого результата, это экономика. Но вопрос решается правильным промтом (контекстом или скилом если быть точным). И режимом рассуждений (reasoning), предотвращающим забывание агентом правил игры. Собственно, уже есть фреймворки, например, упомянутый мной https://t.me/javaKotlinDevOps/589 superpowers, в котором TDD встроен как обязательная часть процесса разработки: brainstorm-планирование-TDD-ревью-commit. Итог: документирование и TDD - две вещи, которые разработка с AI перемещает из области "надо, но мы не успеваем" в базовую практику. #ai #tdd #agile #documentation2,83%
  • 25 июл.Рубрика: "малоизвестные фичи IDEA". В меню "File" можно найти такой пункт как "Remote Development". Сразу скажу - только в Ultimate версии. Два основных вопроса - что это и зачем это? Начнем с первого. Это клиент-серверная IDEA. На вашем компе поднимается компонент Gateway - тонкий клиент IDEA с идентичным интерфейсом, являющийся, как следует из его названия, шлюзом к серверу. К серверу можно обращаться по 3 протоколам: 1) ssh - удаленный сервер 2) WSL - для тех, кому нужен полноценный Linux на Windows, как бы странно это не звучало 3) Dev Containers - если нужна изолированная среда локально. Про Dev Containers, к слову, стоит написать отдельно, эта штука менее популярна, чем те же Test Containers. У Gateway к слову отдельный бинарник и отдельный файл настроек (vmoptions). Что за сервер? Это по сути полноценная инсталляция IDEA на Linux. При настройке подключения в родительской IDEA нужно выбрать версию remote IDEA, она должна совпадать с версией на рабочем месте. Там опять же свои настройки (idea.properties и vmoptions). Занимает порядка 3 Гб. Перед инсталляций будет проверка на системные требования, из важного - минимум 4 Гб ОЗУ должно быть свободно. В вылетающием warning есть слово "рекомендовано", но по факту при несоблюдении этого требования инсталляция падает. Это логично, т.к. основная работа будет на сервере, при оценке требуемой ОЗУ нужно отталкиваться от ресурсов, требуемых при обычной локальной разработке по вашим проектам. По функционалу - из того, что заметил работает все. Плагины, рефакторинги, генерация, поиск, переходы между классами, run configurations, встроенные linter-ы (вкладка Problems), полноценная работа с git, консоль (естественно, доступны те консоли, что есть на удаленном сервере)... Т.к. это разные бинарники с обычной IDEA - это разные окна, причем открыть новое окно Remote Development можно только из основной IDEA или прямым запуском. Теперь главный вопрос - зачем это нужно? Для начала зачем нужно было до эры AI - ага, не опять, а снова))): 1) запуск сборки на полноценном Linux если рабочий комп на Win 2) разработка на слабом ноуте - монитор правда все равно нужен нормальный, как и клавиатура с мышью 3) запуск сборки в песочнице (чтобы не ставить серверное ПО на рабочий комп) Ну а в настоящий момент к этому всему добавляется одно важное применение - запуск AI агента на зарубежном сервере с постоянным IP, без VPN (но с регистрацией), что дает нам: а) уменьшение вероятности блокировки б) не нужно постоянно перещелкивать VPN для доступа к ресурсам разработки, к которым нет доступа из-за санкций и\или VPN в) AI агента можно запуска в yolo режиме (без подтверждений), предварительно настроив запрет force push и удаления master ветки г) в такой схеме можно вести "non-stop" разработку в 2 режимах: полное погружение (анализ и ревью кода) с компа в IDE и контроль работы агента в остальное время - переписка с агентом с телефона, например, в дороге или на прогулке. Можно даже голосовухи агенту записывать, если мобильный клиент позволяет) Важное условие - чтобы сессия агента не рвалась при закрытии крышки ноута нужно запускать ее в tmux (очень полезная штука, рекомендую). Подводные камни: а) коннект по ssh, который обычно режут в корпоративной сети б) местонахождение удаленного сервера стоит синхронизировать с VPN, используемым для оплаты подписки и локального доступа в) сервер стоит денег, но небольших, сравнимых со стоимостью базовой подписки на AI. #idea #ai2,68%
  • 13 мар.без подписи2,26%
  • 3 маяMCP - новая проблема. Есть такой стандарт для стандартизированного добавления кастомных тулов - MCP. Он позволяет разрабатывать тулы на любом языке и выставлять их наружу, для использования агентом, по протоколу JSON-RPS через http (независимый удаленный сервис) или stdio (дочерний процесс). Вроде бы крутая штука. Если бы не детали реализации) Главная проблема такая - по стандарту MCP сервер выставляет метод tools/list, возвращающий список тулов в формате name, description, inputSchema. В чем проблема? Предположим мы выставляем в MCP API какой-то серьезной системы. Например, Atlassian. Сколько там методов? А какого размера у них inputSchema? А контекст не бесконечен, более того, после заполнения 50% контекста качество ответов ухудшается. Т.е. подключив пару тяжелых MCP серверов есть шанс сразу же, с первого запроса, снизить качество работы LLM. А MCP могут и не пригодиться в данном сеансе работы. Вторая проблема - агент подключается ко всем MCP при старте, вызывая ряд методов (initialize, tools/list) что требует времени. Слышал по этому поводу мнения, что MCP нам вообще не нужны. Я бы сказал - такие MCP - да, не нужны. А в целом идея хорошая, не все скилами можно реализовать из-за сложности и вопросов безопасности. Что делать? 1) несколько профилей агента, с разным набором MCP серверов. Возможно даже lite версию вообще без MCP (Claude Code через --strict-mcp-config --mcp-config '{}', Gemini\Qwen Code через --allowed-mcp-server-names '{}'). 2) переписать MCP на skill если это простая прокси к внешнему API. Скил может включать в себя Python скрипты. Агенты такие скилы неплохо пишут. Скилы сделаны "по уму", там в контекст по умолчанию выставляется только name и description, содержимое SKILL.md и другие файлы добавляются по мере необходимости. Этап подключения для скилов отсутствует, это просто специализированный промт. 3) lazy load описаний и схем тулов, сделанный на уровне агента. Claude Code, видимо по принципу "Я тебя породил, ..." реализовал это первым https://vc.ru/ai/2864901-claude-code-i-mcp-lazy-loading-uluchshaet-ai-agentov. Итоги, цитата: Контекст при старте: экономия до 95%. В одном реальном кейсе — с 51 000 токенов до 8 500. Точность на Opus 4: с 49% до 74% на MCP-бенчмарках с большими библиотеками инструментов. Точность на Opus 4.5: с 79,5% до 88,1%. Максимальное описание инструмента: ограничено 2 КБ Причем lazy load включается тоже lazy - когда описания MCP tools начинают занимать более 10% контекстного окна. Красиво) Причем есть предложение дальнейших оптимизаций: https://github.com/anthropics/claude-code/issues/44536 Включая: а) грузить description скилов тоже лениво. Тут видится противоречие, по стандарту именно description содержит информацию когда подгружать скил. Имя конечно тоже должно быть адекватным, но оно может быть очень коротким. С другой стороны, если имена нескольких скилов лексически\семантически похожи - ленивая загрузка будет работать, т.к. агент загрузит оба скила и далее уже по описанию выберет правильный. б) ленивое подключение к MCP - тут понятно в) профили агентов - это стандартизация решения номер №1. Сейчас это несколько разных папок с агентами, а должны быть - несколько файлов профиля. г) загрузка тулов\скилов по условию (только при написании тестов, например) д) динамическая выгрузка Ну в общем полноценное управление памятью, т.е контекстом) Есть похожие issues и для других агентов, пока в статусе Open https://github.com/openai/codex/issues/2335 https://github.com/anomalyco/opencode/issues/17482 4) решение на уровне стандарта MCP. Вот тут все плохо, идут обсуждения, но конкретных предложений нет. Вот предложение https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1576 Вот еще одно https://github.com/orgs/modelcontextprotocol/discussions/532 Но до реализации дело не дошло. Вывод - AI агенты активно развиваются. #ai #ai_agents #mcp #ai_agent_context_management2,02%
  • 9 июл.Только сейчас понял, что в канале ни разу не встречается аббревиатура SDD. Казалось бы не встречается, ну и ... ладно, но SDD сейчас "на хайпе", придется рассказать. Да и TDD был, DDD был, BDD был. Тем более штука интересная. Я бы даже сказал полезная. Вначале расшифровка: SDD - Spec Driven Development. Т.е. в основе разработки лежит спецификация. Казалось бы - любая команда, которая пишет аналитику уже работает по SDD? Нет. Ключевое отличие - спецификация хранится вместе с кодом, версионируется и поддерживается в актуальном состоянии. По сути развитие подхода Everything as Code (EaC). Были Infrastructure As Code, была Architecture As Code, теперь добрались до аналитики. Отдельные вопросы: - мы храним спеки по отдельным фичам, как их объединять если новая фича - доработка старой? AI агент или человек? - как получить все аналитику из отдельных фичей? Отдельный скил? Тут может возникнуть вопрос - канал то про разработку? Сейчас все будет) Второе отличие - над аналитикой совместно работают разработчик и аналитик, т.е. устраняем разрыв между ними и сопутствующие потенциальные потери информации. Устраняем ли потери времени - под вопросом. С одной стороны разработчику не надо тратить время на вникание в аналитику, с другой - тратится время на совместную работу. В худшем кейсе когда фича реализована не по аналитике - точно выигрываем. Третий важный момент - именно спека, лежащая в проекте идет на вход AI агенту как основной артефакт. Наравне с описанием проекта в контексте (AGENTS.md) и проектными скилами. Еще полезный побочный эффект: при SDD больше вероятность, что ADR - architecture decision records - будут сохранены рядом с кодом в процессе совместной проработки фичи. Вообще говоря, ADR как практика появилась еще в 2021 году, автор Майкл Нюгард (Michael Nygard), но ее широкого распространения я не вижу. История принятия ключевых архитектурных решений часто живет в головах сеньоров, которые их приняли. И теряется с их уходом. Или просто со временем. Что не есть гуд. Что еще важно - тема SDD идет в паре с AI разработкой, поэтому неудивительно, что уже есть готовые SDD фреймворки. Их много, но самые известные - OpenSpec и SpecKit. И они предлагают разные workflow для работы над фичей. Но об этом в следующей серии. Сейчас хотел бы отметить, что если спека пишется AI агентом совместно с аналитиком, это требует меньше участия разработчика. Т.к. агент видит код проекта, знает язык и фреймворки, и что-то может подсказать сам. Но конечно же не все. P.S. Еще 22 буквы свободно))) #ai #dev_workflow1,96%
  • 20 июл.compact vs clear Я снова про AI-шку и две типовые команды у большинства агентов /compact vs /clear. Первая сжимает контекст, вторая начинает новую сессию. По сути это два способа борьбы с энтропией - раздутием размера контекста и последующим ухудшением качества ответов агента. А ухудшается оно по статистике где-то в районе 50% контекста. Ну и борьбы со стоимостью тоже, если вы сами платите за модель) Т.к. весь контекст при каждом запросе уходит на сервер, хоть и считается по особому тарифу (cashed). Если запустить /compact в Claude Code - удивляет (неприятно) скорость его работы. У меня это обычно более минуты, ближе к 2. Почему так - сжатие стало умным, т.е. вся история сессии скармливается LLM, и она выбирает важное. Можно указать это важное, явно передав текстом /compact "сохрани план работ и архитектурные требования". Для сжатия похоже используется та же модель, что и сейчас в сессии - по крайней никакой другой информации я не вижу. Это точно есть в Claude Code, и думаю скоро будет у всех) К слову, есть готовые хуки, определяющие оптимальную точку для /compact с простой, я бы даже сказал "наивной" реализацией: создается PreToolUse hook для операций Edit|Write, счетчик, как только число вызовов превышает порог (50 по умолчанию) - пишем в контекст рекомендацию вызвать /compact. Но вернемся к сжатию. Умное - это хорошо, но вместе с этим долгое и более дорогое. Плюс что-то важное все равно может пропасть из контекста. К чему я веду - /compact видится костылем, помогающим, если вы неправильно декомпозировали задачу (story). Или пошли на поводу у модели, когда она предложила добавить в план работ еще А, Б, С... Решив, что раз это дешево - почему бы не сделать сразу) А ведь преждевременную оптимизацию и YAGNI никто не отменял. Итог: навык декомпозиции задач с AI остается таким же важным, как и был без нее. Бейте задачи на части, план работ и текущее состояние храните в файле (а SDD фреймворки так и делают), чаще вызывайте /clear. #ai #ai_agents1,87%
  • 27 маяПрошла неделя и Auto Mode раскатили на все тарифные планы. Круто! P.S. Интересно, что там за модель-классификатор для определения опасности команд работает. Есть подозрение - что Haiku, самая дешевая из тройки моделей Claude Haiku-Sonnet-Opus. P.P.S. А еще одно радостное событие - аналогичная фича появилась в Qwen Code 0.16 https://github.com/QwenLM/qwen-code/releases/tag/v0.16.0 И раз уж заговорил про Qwen Code - они догоняют ведущих агентов (Claude Code и Codex) еще в нескольких моментах: а) параллельная работа над подзадачами через worktree (там, где это возможно, конечно же) б) Goal-driven workflow (/goal) в) /rewind с восстановлением файлов Причем если с /rewind отставание в 9 месяцев, Auto Mode - 2 месяца, а /goal - меньше месяца. В общем все агенты взаимно обогащаются фичами друг друга. И это хорошо! #ai #ai_agents1,71%
  • 28 апр.без подписи1,68%
  • 7 авг.Когда я впервые увидел embedded Kafka, то подумал: Круто, жаль, что такого же нет для PostgreSQL. И был не прав, спасибо, коллега просветил. Встречаем Zonky Embedded Postgres https://github.com/zonkyio/embedded-postgres Подключается как Java зависимость. Можно управлять версией PostgreSQL. Поддерживает ОС Darwin, Windows, Linux, Alpine Linux и Intel и ARM архитектуры. Легко подключается в тесты и утилиты миграции БД через rules. @Rule public SingleInstancePostgresRule pg = EmbeddedPostgresRules.singleInstance(); @Rule public PreparedDbRule db = EmbeddedPostgresRules.preparedDatabase( LiquibasePreparer.forClasspathLocation("liqui/master.xml")); Также можно работать напрямую с объектом БД: try (EmbeddedPostgres pg = EmbeddedPostgres.start(); Connection c = pg.getPostgresDatabase().getConnection()) { ... } Как по мне - крутая штука, и вот почему. Рассмотрим альтернативы: 1) обычная инсталляция PostgreSQL - есть момент с правами, плюс единая инсталляция на компьютере разработчика - это shared ресурс на несколько проектов и риск поломки БД 2) Docker - опять же может не быть необходимых прав, плюс Docker - это тонкая, но все же прослойка. Которую нужно запустить и которая немножко жрет ресурсы. В нашем случае по факту Постгря ставится в папку target/build, т.е. есть изоляция по проектам, плюс переустановка делается обычным clean. Ну и отсюда к следуют минусы - на скачивание и распаковку в папку target нужно время. Ну и время жизни такой инсталляции ограничено. Поэтому идеальный кейс - тесты на живой БД. #db #postgrrsql #integration_tests1,05%
  • 3 авг.Рубрика - приколы с AI агентами. Есть шанс, что станет постоянной. И сразу преамбула - да, агенты часто смешно косячат. Даже самые сильные, типа Claude Code с Claude моделью. Но это не значит, что они бесполезны. Правильный подход - понимать причины этих косяков и нивелировать их правилами в контексте и evals-ами. Так вот, AI очень любит нарушать принцип DRY - Don't Repeat Yourself. Вот прямо хлебом не корми. При создании новой фичи с большой вероятностью там появится копия существующего инфраструктурного кода. Или даже несколько - в каждом новом классе\файле. Как с этим бороться - описать существующий код для переиспользования в контексте. Или добавить скил. Или и то, и другое, что вообще мне кажется одним из основных паттернов при работе с агентами. В данном случае я пошел по второму пути. С агентом, естественно, мы обсудили проблему и сделали скил. Скил включает в себя хук, который ищет дубли. Плюс файл с реестром типовых дублей. И собственно сам текст скила. Т.е. я в скил положил типовые примеры, которые нужно переиспользовать. В скил, который должен решить проблему дублирования. Что вы думаете? В скиле эти примеры появились в 3 местах!))) После моего ревью агент признал косяк, поиронизировал над собой, убрал один дубль и сделал автогенерацию другого из единого источника правды. Но сам факт... Что касается причин такого поведения. Мне видится такая: для LLM дублирование - это сигнал. Сигнал, повышающий важность информации. Даже есть такая техника промтинга. Т.е. пока ей явно не скажешь, что это проблема - LLM это проблемой не считает. Есть еще идеи, почему они так работают? #ai #ai_agents #dry #ai_fuckup0,99%
  • 13 июл.И последнее по SDD. Последнее, но важное. SDD - это упор на актуальную спецификацию. Т.е. на аналитику. Из 5-10 шагов по SDD workflow к чистой разработке относится один - /opsx:apply и /speckit.implement соответственно. Достаточно ли этого? Для простых фичей, но при этом имеющих свою аналитику - да. А для более сложных есть superpowers) С TDD, параллельной разработкой в разных worktree, с расширенным код-ревью и отладкой И в обоих случаях он отлично ложится в workflow, заменяя собой упомянутые выше шаги. И ложась т.об. в середину процесса. Два нюанса: 1) brainstorming из superpowers в такой схеме становится ненужным и заменяется аналогами из SDD фреймворков 2) writing-plans (из superpowers) нужно оставить, так как это разная детализация. В SDD таски написаны на уровне аналитика, а writing-plans пишет классы, импорты, тесты, команды запуска скриптов. По сути из плана, созданного через superpowers, написать код может любой джун. И ему даже скучно будет) Или самая дешевая модель. Тогда может возникнуть другой вопрос - а нужен ли план, созданный SDD фреймворком? В целом не обязателен. Но если он создается одной командой с другими артефактами - можно и оставить. Или подтюнить соответствующий скил. Еще одно важное замечание. Я встречал случаи, когда superpowers тоже относят к SDD. Нет, ну формально конечно спека по итогу brainstorming создается, как и план по итогу writing-plans. Но это спека и план с деталями реализации, т.к. superpowers прям заточен под разработку. Поэтому на мой взгляд по факту это не SDD фреймворк. Ну или как минимум - не SDD для команд, где есть явная роль аналитика. И последний момент - нужно ли использовать два фреймворки - OpenSpec + superpowers - в связке? А точнее когда нужно их использовать? Ответ в общем очевиден - для достаточно больших фичей, когда в репозитории по итогу разработки фичи должна остаться спецификация. Либо это требование организации, либо решение команды. #ai #ai_harness #dev_workflow0,90%
  • 7 июл.Пару слов про хуки в AI агентах. Набор событий у каждого агента свой. При этом тут тоже идет унификация и базовый набор хуков, кажется, определился: * PreToolUse * PostToolUse * SessionStart * UserPromptSubmit - начало обработки пользовательского запроса агентом * Stop - его завершение. Я про большую тройку (Claude, Codex, Gemini и примкнувшего к ним Qwen Code). Тут надо отметить, что PreToolUse/PostToolUse вызываются на любой tool, включая вызов bash, редактирование файла и даже TodoWrite. Хук получает на вход информацию о совершаемом действии и может делать 3 вещи: 1) блокировать действие или сессию (все хуки выше это умеют, некоторые безусловно, некоторые - через рекомендацию для агента) 2) добавить что-то в контекст 3) ничего не возвращать, а, например, просто записать логи. Для чего можно использовать? Мои варианты: 1) свой механизм разрешений (PreToolUse) 2) блокировка сессии после проверки среды (SessionStart, только у Codex\Claude) 3) подгрузка контекста в сессию, в т.ч. после ее сжатия (SessionStart) 4) телеметрия, аудит (PostToolUse, Stop) 5) валидация промта пользователя (UserPromptSubmit) 6) валидация ответа модели с возможностью его перегенерации (Stop) 7) замена тула при неправильном ответе (PostToolUse) 8) проверка формата данных, например, при записи в файл (PreToolUse) 9) запуск любых линтеров при окончании работы агента (Stop, SubagentStop) 10) запрет на изменение определенных файлов (PreToolUse) 11) просьба агенту обосновать, зачем он выполняет то или иное действие (PreToolUse) 12) запрет на переход к следующему шагу если не выполнены необходимые действия на текущем, реализация state machine (Stop, SubagentStop) 13) вывод информации о текущей сессии, подсказки о сжатии или начале новой (Stop) 14) кэширование результата работы тулов, включая MCP (PreToolUse) 15) обогащение промта пользователя (UserPromptSubmit) 16) независимое хранилище истории диалогов (PostToolUse, Stop) и наверняка многое другое, что мне не пришло в голову) В общем мощный механизм. Можно использовать готовые хуки из плагинов, а также есть поле для их доработки и создания своих. #ai #ai_agents0,90%