Русский
Открыть в Telegram
((java || kotlin) && devOps

(java || kotlin) && devOps

@javaKotlinDevOps · канал · Технологии · в индексе с 15.09.2026
339подписчиков−2 за неделю
104средний охват поста
30.7%ER — охват к подписчикам
6постов за 30 дней
(
(java || kotlin) && devOps
Когда я впервые увидел 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_tests
142 ·
(
(java || kotlin) && devOps
Ссылка
нажмите — покажем
Два факта про безопасность AI. Первый - есть исследование, где говорится, что 45% сгенерированного AI кода содержит классические программные уязвимости из OWASP Top 10 https://www.veracode.com/blog/genai-code-security-report/ Причем за 2 года с 23 по 25 год ситуация практически не изменилась. В отличие, например, от процента компилируемого кода. Второй факт - сообщение агента вчера при работе с Claude Opus, процитирую: Напоминаю по факту: я запустил sudo cat /etc/gitlab-runner/config.toml, чтобы проверить extra_hosts, и в выводе целиком приехала строка token = "glrt-X…". Надо было сразу grep -v token — дальше я так и делал, но эту строку уже не отменить. Итог: токен в 2 файлах транскрипта сессий (~/.claude/projects/**.jsonl) плюс в бэкапе /etc/gitlab-runner/config.toml.bak.20260810, который создал я. Главное, а не файлы на диске: он был в моём контексте, то есть ушёл в API Anthropic. Локальной утечкой это уже не назвать. Дайте новый токен — впишу и перезапущу, privileged/volumes не тронув. Или сделайте сами, если не хотите гонять его через меня второй раз — что, учитывая причину ротации, разумнее. Что меня удивило? 1) я не спрашивал агента про уязвимость 2) он понимает, что утечка токена на сервера Anthropic (не в репозиторий с кодом) - это все равно утечка 3) в сообщении мне секрет был замаскирован 4) он предлагает заменить токен мне самому Лед тронулся) А ведь тот же SAST\DAST и сканирование на секреты в CI pipeline никто не отменял. Плюс скилы на проверку безопасности кода. P.S. Я в посте немного сгустил краски, есть менее известное, но более новое исследование, где процент уязвимого кода у лучших моделей снизился до 24 - https://aclanthology.org/2026.acl-long.1107/ Что лишь подчеркивает мою мысль. Т.е статистика подтверждает изменения к лучшему. P.P.S. Как бы не прийти к тому, что основной задачей разработчика станет получение и подстановка токенов) #ai #security
116 ·
(
(java || kotlin) && devOps
Ссылка
нажмите — покажем
Новости стандартизации AI агентов Я уже писал про плагины, они же расширения https://t.me/javaKotlinDevOps/614 И из этого поста видно, что стандартизации особой не было. Даже названия два. И вот, стандарт появился - https://agent-plugins.org/ Стандартизируется структура папок и файлов, структура предлагается такая: my-plugin/ ├── plugin.json ├── skills/ │ └── summarize/ │ ├── SKILL.md │ ├── scripts/ │ └── references/ ├── mcp.json └── com.example.client/ └── hooks/ Есть возможность добавить в плагин скилы, MCP и описание. Стандарт можно расширять: настройками в plugin.json и скриптами в com.example.client - хуки, например. Расширения опциональны, AI агент может игнорировать, если не понимает формат. Почему стандартизировали только skills и MCP? Это уже зрелые стандарты, в отличие от хуков, субагентов, команд. Хотя AGENTS.md тоже стандартизирован, но его поддержки почему-то нет. И определились наконец с названием - все же плагины. Буду теперь их так называть) Вот список поддерживающих стандарт AI агентов https://agent-plugins.org/compatible-clients Из известных для разработки - Cursor, Codex, VSCode и Copilot. Не хватает Claude Code, Gemini, Qwen. Резюме - стандартизация неизбежна. P.S. Но это не решает проблему - как одновременно пользоваться разными AI агентами. Папки то у них разные, и внутри не все стандартизировано. Но тут тоже есть наработки. #ai #ai_agents
115 ·
(
(java || kotlin) && devOps
Ссылка
нажмите — покажем
Тренды агентостроения. Уже был пост про общие команды у топовых coding агентов https://t.me/javaKotlinDevOps/603 Так вот, на примере Claude Code и Codex появился новый кандидат на унификацию. Встречаем ... /import Что именно импортируется? Оба умеют импортировать скилы, файлы контекста (напомню, Claude еще не поддерживает AGENTS.md, поэтому импорт пока актуален), MCP, команды и субагенты. Codex еще умеет импортировать хуки, настройки, плагины, проекты и чаты. В общем практически все. Импортируют у друг друга, а еще Claude у Gemini, а Codex у Cursor. Видимо, именно их считают основными конкурентами. Другие агенты импортировать не умеют, пока что, и я уверен, скоро подтянутся) Почему решил обратить внимание на эту команду. 1) конкуренция между агентами и стоящими за ними LLM моделями усиливается. Покупка Grok-ом Cursor-а в эту же копилку. 2) стандартизации пока нет - субагенты, команды, хуки, настройки, проекты и история чатов - явные кандидаты 3) как решение для одновременной работы в нескольких агентах - лучше, чем ничего, но не идеально. Т.к. при любом изменении в любом из агентов нужен новый ручной импорт и не факт, что он ничего не поломает. 4) ну а переход от одного агента к другому конечно же сильно облегчается #ai #ai_agents
145 ·
(
(java || kotlin) && devOps
Можно ли чему-то научиться у AI? Базовый ответ - да, т.к. в LLM в процессе обучения попало множество документации и кода, который я, например, никогда не видел. Да, в сжатом виде, возможно искаженном, но в любом случае это огромный объем знаний. Но я сейчас про более конкретные вещи. Например, тесты. Ключевой момент, что агент пишет десятки тестов на каждую фичу. Кроме стандартных unit и интеграционных я заметил парочку новых типов. 1) тесты на миграцию БД - включая откат миграции. Простые, накатывают миграцию, проверяют, что новый объект появился\исчез в БД. Польза не то, чтобы большая, но есть. Ломаться часто не должны, т.к. каждый такой тест проверяет свою версию БД. 2) AST тесты - т.е. тесты с синтаксическим анализатором кода, проверяющие, что в методе не делается что-то лишнее. Или делается что-то обязательное. Часто такие тесты можно реализовать передачей в тестируемый метод spy-объекта. Но не всегда. Для меня было открытием. Самому такие тесты писать сложно, AI - примерно также, как и другие. Тесты скорее всего будут хрупкими, т.к. зависят от структуры кода. Но для проверки отдельных ключевых инвариантов проекта, над которым работает множество людей - это лучше, чем JavaDoc. 3) тесты, проверяющие документацию, генерация которой - тоже функция приложения. Например, admin guide. Наличие, формат. Тоже свежая мысль, IMHO. Самому - точно руки бы не дошли до таких тестов, а с AI - почему бы и нет. Последний кейс пограничный - то же самое можно сделать и скилом. И такие приемочные скилы (они же evals) - это тоже своего рода тесты, просто реализованные в другой форме. Просто они могут не просто вызвать скрипт, а еще и проверять требования к проекту с помощью LLM. И даже в случае LLM, которая недетермирована, это лучше, чем просто пару строк в README.md. #ai #ai_agents #testing
103 ·
(
(java || kotlin) && devOps
Ссылка
нажмите — покажем
Заметки про LiteLLM. Во-первых - это не LLM) Это SDK, предоставляющий унифицированный доступ к LLM провайдерам - типа Spring AI - и AI прокси. Вот второй use case и рассмотрим. Для чего нужна прокси? 1) независимый от провайдера подсчет токенов. В теории и стоимости токенов, если это API тарифы. Т.к. у подписок свои абстрактные единицы измерения. Даже если они называются одинаково - кредиты - они не равны между собой и не переводимы в токены. 2) конвертация API, например, Anthropic-OpenAI, для тех провайдеров, кто не поддерживает Anthropic API нативно. На всякий случай - единого API к разным LLM нет, несмотря на некую похожесть. Ну и OpenAI API наиболее распространен сейчас, т.к. они были первые. 3) единая точка для настройки различных провайдеров LLM - URL, секреты, список доступных моделей. И, соответственно, легкое переключение между провайдерами. Это мои кейсы, а еще можно организовать многопользовательский доступ, лимиты, подключить для всех MCP серверы и даже умную балансировку между моделями. Последнее особо интересно, но руки пока не дошли. Теперь собственно заметки: 1) поддерживает подписки Anthropic и вроде бы OpenAI. Ну и API ключи, но это опция по умолчанию. Важно отметить, что все китайцы дают доступ к своим подпискам по API ключу - Qwen, Kimi, GLM. А вот у Claude и OpenAI подписка = OAuth авторизация, которую несколько сложнее проксировать из-за наличия нескольких ключей и их постоянной ротации. А подписки - это наше все, цена в 4-10 раз дешевле, чем при оплате за токены у одного и того же провайдера. 2) документация - отстой 3) есть UI, там можно смотреть логи, статистику, настраивать модели, проверять их доступность. Логировать может как в формате access logs, так и с данными - последнее включается отдельно 4) есть своя база моделей и провайдеров, но ориентация на американский рынок, китайских провайдеров мало 5) большая часть проблем возникает на стыке агента и прокси. Хотя этот момент в документации постарались раскрыть - вот пример отдельная… Читать полностью →
98 ·
(
(java || kotlin) && devOps
Заметки по LiteLLM - вторая часть. 1) в лучших традициях open-source из коробки LiteLLM запускается на 0:0:0:0 - т.е. доступна снаружи. Решается параметром --host 127.0.0.1 2) логирование ошибок на троечку - вместо одного конкретного сообщения они логируют исключения на нескольких уровнях, в итоге часть сообщений об ошибках нужно просто игнорировать. В debug режиме много дублирования - одно и тоже http сообщение появляется в логах несколько раз. Справедливости ради, как раз debug режим позволил мне найти причину ошибки с зацикливанием запроса на прокси. 3) очевидно, чтобы хранить статистику - нужна БД. В инструкции по инсталляции об этом сказано вскользь. Как и том, что кроме отдельной database еще нужно ставить Prisma - Node.js ORM с функционалом миграции БД. Это при том, что приклад написан на Python. И более того - из исходников Prisma нужно собрать бинарь для накатывания миграции. Как это сделать - я выяснил с AI-шкой. 4) цену запросов для неизвестных для системы провайдеров LLM можно вбить прямо в config.yaml - файл настроек. Это хорошо. Плохо то, что после этого LiteLLM все равно будет ругаться на отсутствующие тарифы. Т.е. понять что все работает можно запустив агента и посмотрев статистику по тарифам 5) для подписки Anthropic стоимость считается по тарифам API. На первый взгляд странно. Но с другой стороны - у подписки вообще нет стоимости токена, вместо этого есть оставшийся лимит. А видеть стоимость полезно для оценки насколько выгодна подписка. 6) LiteLLM смешивает понятие формат API и провайдер. Т.е. невозможно задать провайдер Deepseek и формат API Anthropic. В данном примере: - model_name: deepseek-v4-flash litellm_params: model: anthropic/deepseek-v4-flash api_base: https://api.deepseek.com/anthropic оба этих параметра определяются по model: anthropic/ Т.е. либо преобразуем формат в OpenAI (как нативный формат Deepseek) и есть раздельный учет по провайдерам в статистике, либо без преобразований, но все сидят на одном пров… Читать полностью →
94 ·
(
(java || kotlin) && devOps
Ссылка
нажмите — покажем
Еще про стандартизацию AI. Как говорил ранее - стандарта для настроек агентов сейчас нет. .claude, .codex, .qwen, .gigacode, и внутри структура немножко отличается, как минимум название файла с контекстом и расположение настроек MCP. Когда же наступит счастье, в смысле стандартизация? Точно не скажу, но процесс идет) Пока идет в разных направлениях, увы. 1) https://agentsstandard.com 2) https://dotagentsprotocol.com/ 3) https://github.com/jackby03/agentic-collaboration-standard 4) https://github.com/bgreenwell/dotagents И это я особо не искал) у всех папка называется .agents, у всех внутри есть папка skills. Далее - разнообразие. Из интересного - поддержка .agents есть в Kilo Code и Codex. Из практических рекомендаций - вполне можно уже сейчас хранить скилы в .agents/skills тем более, что и сам формат скилов стандартизирован. И делать симлинки на родные папки для несовместимых агентов. #ai #ai_agents
96 ·
(
(java || kotlin) && devOps
И снова рубрика "Находки из Python". Как вы думаете, что делает вот такая конструкция? @pytest.mark.xfail(strict=True, reason = "будет исправлено в задаче TASK-100") def test_function(): Она "фэйлит" прогон, если тест пройден) Зачем это нужно - если из-за частичного рефакторинга некий код перестал работать. И нужно отследить момент починки в следующих релизах. Т.е. как только чиним код - тест начинает падать, мы снимаем xfail. Если тест просто "скипнуть" - это можно забыть сделать. Плюс если упала группа тестов - то ее можно пометить одинаковым описанием и убедится, что починились все. Стандартного функционала для этого нет, но можно поиском по проекту. Видится, что полезно в плане контроля тестов. Есть конечно радикальный вариант - вообще избегать отключения тестов, но жизнь - сложная штука). Отдельно про параметр strict. Если его поставить в false - получаем тест, который не ломает запуск ни при успешном прогоне, ни при падении. Зачем это может быть нужно? Для flaky тестов, которые невозможно починить здесь и сейчас. Тут конечно у меня вопросики, т.к. такое действие - прямой путь к тому, что про flaky тест мы просто забудем. А в итоге контроль над тестовым набором, наоборот, ухудшится. Я сразу стал искать - есть ли аналог в Java? В JUnit из коробки нет, иначе бы этого поста не было) Но есть в JUnit Pioneer: @Test @ExpectedToFail("будет исправлено в задаче TASK-100") void testFunction() { Это аналог strict режима. Не strict режима нет, что IMHO к лучшему. Обе аннотации позволяют задать исключения, с которыми тест должен упасть. Python вариант также позволяет задать condition: @pytest.mark.xfail(condition="not config.getvalue('db')") def test_function(): ... В Python интерпретатор есть в runtime, в отличие от Java (там в runtime только компилятор из байт-кода в нативный), поэтому это проще сделать. Мой вердикт - штука полезная. #python #java #python_gems #unit_tests #junit
108 ·
(
(java || kotlin) && devOps
Еще один пост о вреде Boolean флагов) Почему еще один - я за последние пару лет точно видел несколько таких постов) Но хочется немного обобщить и накинуть практических советов. В чем суть? Есть такая рекомендация - вместо нескольких Boolean флагов у одной сущности лучше использовать поле state с Enum типом. Почему? Я бы даже поставил вопрос по другому - по каким признаком можно понять, что пора заводить state? 1) есть запрещенные или не имеющие бизнес-смысла комбинации флагов. А число комбинаций растет линейно. Например 3 Boolean поля = 8 комбинаций 2) при установке одного из флагов приходится сбрасывать другие 3) при установке приходится проверять другие флаги 4) флаг X1 был сделан для использования в guard условии специально в модуле Y1. Флаг X2 - в модуле Y2. Но со временем в модуле Y2 приходится проверять оба флага. Это может быть альтернативой для одного из двух предыдущих вариантов. Видится, что при любой такой проблеме стоит задуматься о добавлении единого state и расписывании переходов между его значениями (state machine). В идеале - линейной цепочки переходов. И вообще говоря правило можно обобщить. Если у сущности есть несколько Boolean или Enum полей, для которых начинают возникать проблемы, описанные выше - это повод к их объединения в один большой Enum. И Enum тут усугубляет ситуацию: 3 Enum с минимальными 3 значениями у каждого - это уже 27 комбинаций. Можно даже это паттерном назвать - схлопывание состояний) #antipatterns #patterns
124 ·
(
(java || kotlin) && devOps
Ссылка
нажмите — покажем
PostgreSQL наносит ответный удар) Я думаю все слышали про NoSQL, предлагающие альтернативные реляционной структуре способы хранения данных. И отъедающие долю рынка у реляционных СУБД. Но есть и обратный процесс. Уже писал про расширения для PostgreSQL. Так вот, возможность хранить NoSQL данные добавляются, как правило, с их помощью. Что у нас есть на данный момент? Рассмотрим работу с разными типами данных: 1) time series - TimescaleDB. time series = временная метка и значение какого-то показателя. Самый яркий пример - метрика. Особенности при работе с такими данными: объем данных - т.е. автоматический retention и сжатие, быстрая работа с длинными рядами - простое разбиение на партиции\чанки, агрегация данных из коробки 2) embeddings - pgvector. Хранение embedding в базе и конечно же векторный поиск по ним 3) полнотекстовый и нечеткий поиск по тексту - встроенные типы данных tsvector и методы из pg_trgm - получаем упрощенный аналог ElasticSearch (OpenSearch). На объемах уровня логов скорее всего упадет, но на меньших... 4) графы - в 19-й версии появилась поддержка SQL/PGQ. Т.е. по сути простой графовый VIEW. Данные хранятся по классике в таблицах, но есть удобный синтаксис для запросов по графу. https://www.postgresql.org/docs/19/sql-create-property-graph.html 5) пространственные данные (spatial) - PostGIS 6) document oriented DB - jsonb конечно не полноценный аналог, но запросы по вложенному JSON писать можно. А если еще добавить сюда Citus - то и шардирование получим, что для таких данных видится частым требованием из-за объема. К чему это я? Не к тому, что все базы данных убьет PostgreSQL. Вряд ли. А к тому, что если техстек ограничен и там есть PostgreSQL (а он там есть) - до какого-то масштаба можно обойтись одной базой данных. И здесь появляется жирный плюс. Рядом - в той же или даже соседней схеме - можно положить реляционные данные и менять все вместе в одной транзакции. Никаких оркестраторов и хореографии, докатов, никакого двухфазного коммита. … Читать полностью →
1 · 122 ·
(
(java || kotlin) && devOps
Сколько стоит AI агент? Для кого-то - бесплатно. Платит работодатель. Кому-то хватает минимальной подписки. 20 баксов в месяц. Ну или 2-3 минимальных подписки. Для переключения аккаунтов и агентов даже специальные утилиты придумали - CAAM — Coding Agent Account Manager и CASR — Cross-Agent Session Resumer. Кому-то нужен план подороже - за примерно 100 баксов в месяц. Подороже, но в целом не дорого. Ему в минус разве что увеличенная вероятность блокировки играет. Но ведь есть ещё доступ по API. А там миллион входных токенов может стоить те же 20 баксов. Например, у ChatGPT Astra или Claude Fable. А хватит этот миллион на одну задачу. Да и то, декомпозированную) Ладно, это все же топ модели. А сколько будет в месяц стоить работа по API с обычными моделями тех же Claude и Codex? Разница же навскидку многократная. Вдруг подписки прикроют. Датацентры же окупать надо) Мой эксперимент - пустить трафик Claude подписки через LiteLLM прокси и поработать в обычном режиме 2 недели. Claude прокся всегда считает по API-ным тарифам. Поработал. Примерно 700 баксов насчитал. А у меня в параллель ещё Codex с ChatGPT с такой же нагрузкой и ценами. Т.е умножаем на 2. И ещё на 2 чтобы месяц получить. Уже 2800. А ещё у меня на подхвате 2 китайские модели для кодинга по плану и в случаев, когда упираюсь в лимиты основных моделей. Баксов 100 накинуть надо. Итого округлим 3000$. А это между прочим зарплата миддла в России. Если ЗП белая - то затраты работодателя будут x2. Для чего работодатель платит за AI? Чтобы было больше фичей. И чтобы сэкономить. Точно от внедрения AI не ждут повышения расходов в средне и долгосрочной перспективе. А это значит, что чтобы дать топовые модели за "честную" стоимость 2 миддлам нужно уволить третьего( И хочу подчеркнуть, что это не безлимит. Я с такой схемой периодически в лимиты упираюсь. Условный безлимит я думаю ещё в x2 обойдётся. Но тут важно понимать, что при разработке с AI свободное время вроде бы появляется, но при этом когнитив… Читать полностью →
3 · 122 ·
(
(java || kotlin) && devOps
Ссылка
нажмите — покажем
Забавный факт, цитата: AI context windows have grown from 512 tokens in 2017 to 2,000,000 tokens by 2026 (factor ~3,906; fitted lambda = 0.59/yr; doubling time ~14 months). Over the same period, human Effective Context Span (ECS) -- a token-equivalent measure derived from validated reading-rate meta-analysis (Brysbaert, 2019) and an empirically motivated Comprehension Scaling Factor -- has declined from approximately 16,000 tokens (2004 baseline) to an estimated 1,800 tokens (2026, extrapolated from longitudinal behavioural data ending 2020. Или не забавный( Отсюда: https://arxiv.org/abs/2603.26707 Хотя конечно же конкретное окно - лишь один из параметров, определяющих силу LLM. И 2 млн сейчас - это не эффективное окно, а максимальное. Но все равно сравнение интересное. #ai
100 ·
(
(java || kotlin) && devOps
Блеск и нищета AI разработки. Мне легко понять эйфорию менеджеров по поводу AI. Без разработчиков, в диалоге с AI можно создать работающее приложение. Только за токены плати. Ну да, конечно, надо выбрать workflow для разработки, evals настроить, контекст проекта. И, вуаля, роботы работают, отдыхает человек) И сроки ускоряются. Но ещё я использую AI для реальной разработки. Сделал свой workflow из двух фреймворков - OpenSpec и Superpowers. Написал свои evals скилы под каждый проект и универсальные. Настроил контексты - проектные и глобальный. Провожу ревью создаваемых спецификаций, смотрю код периодически. Разработка идёт конечно же быстрее. Но при этом я чётко понимаю, что качество кода ниже, чем если бы я его писал полностью руками. Почему так? Если свести все причины в одну, то может сформулировать так - очень сложно построить полноценный контекст проекта. Сильная модель с 100% настроенными правилами работы в проекте с большой вероятностью написала бы код, близкий к моему. Но есть нюанс - 80+% правил находится в головах разработчиков. Некоторые из них разработчики не осознают как правила работы в проекте) И это как раз становится заметно, когда модель делает что-то не так. Конечно, чем больше работаешь над проектом с ИИ - тем больше эти правила будут формализаться. Но это не дни, скорее месяцы. К правилам относятся и ADR - когда-то принятые в проекте решения, которых надо придерживаться. И архитектурные и инфраструктурные требования компании. И многое другое. Можно на эту проблему посмотреть с другой стороны. Воспомним количество принимаемых во время разработки решений. Это могут быть десятки на простой фиче. При разработке с ИИ очевидно часть этих решений будет принимать агент. Иначе человек будет блокером в процессе. А чтобы агент принял правильное решение - под каждый кейс должно быть настроено правило. Рецепт если хотите. Если рецепта нет - модель примет решение сама. Может хорошее, а может увеличивающее техдолг и превращающее сервис в legacy. Очевид… Читать полностью →
90 ·
(
(java || kotlin) && devOps
Ещё про небезопасный AI) Задача - запустить трафик в k8s с Istio через egress для 2 интеграций. Плюс egress отвечает за SSL origination. Обязательное условие: маршруты должны быть отдельными - порты и все манифесты. Агент меня понял, обсудили делали, он написал спецификацию на основе моих вводных. Вычитываю спецификацию... 2 VirtualService, 2 ServiceEntry... Вроде все ок. И вдруг - 2 ergress?!? Вопрос агенту - что это? Ответ: ну ты же просил разделить маршруты. Плюс у каждого маршрута в теории свои сертификаты, и т.об. мы физически разграничили доступ к ним. Даже наша кибербеза никогда не была такой безопасной) Агента удалось переубедить вопросом: интересно, с таким подходом - отдельный прокси на порт - сколько миллионов проксей в Google?) Ладно, это скорее курьез. Но вот еще пример. Когда проектировали интеграцию с Vault агент предложил для каждого клиента - приклад и egress - сделать свой ServiceAccount. Развести по разным пользователям по сути. Ровно по той же причине - разграничить доступ к секретам. Кто до такого уровня безопасности доходил?) Идея, кстати, хорошая, но есть минус - нужно прописывать все эти кастомные ServiceAccount в Vault. С default проще. И вишенка на торте - агент не только предложил установить права на файл секрета 400 (это база), но ещё и на каталог с секретом 700 поставить. А в прикладе проверить эти права! Т.е такими правами мы запрещаем удаление и создание нового секрета каким-то взломанным sidecar-ом. Круто! Но есть же ещё родительский каталог - /vault/secrets в случае Vault. И если там есть права на запись - уязвимость остаётся? Нет - в прикладе предлагается ещё и owner секрета проверять. А т.к у нас естественно runAsNonRoot: true и запрет повышения привилегий (это тоже база), то сменить пользователя невозможно. И если все сайдкары кроме Vault запускать под другим пользователем - подмену сразу будет видно. P.S. Проверять за агентом конечно же нужно в любом случае #ai
1 · 64 ·
(java || kotlin) && devOps
Ссылка
нажмите — покажем
Хотел бы прокомментировать новость в следующем посте и выводы Алексея по ней. Для начала - согласен с выводами. Релиз PG задержался впервые за много лет не из-за того, что AI нашел баги в новых фичах (а раньше не находил). А потому, что с AI стало сильно легче искать и эксплуатировать уязвимости. Раньше до нахождения уязвимости и появления риска проходили годы - сейчас недели. И это еще одно подтверждение следующей мысли. Главная проблема внедрения AI для разработчика не в том, что AI еще слаб, а менеджеры требуют больше фичей, обосновывая это требование появлением AI. Точнее на данном этапе в отдельных командах это так, но это явление временное. Т.к. AI улучшается. Основная проблема в том, что сильный AI забирает у человека относительно простую работу - писать код. Подчеркну - относительно! А вот самая трудная работа - проектирование и ревью - остается за человеком. И ее станет сильно больше. Почему? AI пишет много кода) Причем проблема сильнее именно в ревью - объем ревью растет сильнее, чем количество фичей и кода, т.к. LLM хороши в поиске уязвимостей. В общем случае, чем больше этапов производственного процесса мы отдаем машине - тем сильнее растет объем ревью. Когнитивная нагрузка растет. Как ее уменьшить - писал выше, тут важно найти баланс между качеством и временем на ревью. Что тоже является отдельной задачей, повышающей когнитивную нагрузку на разработчика))) #ai #postgresql
25 ·
(
Почему PostgreSQL 19 не вышел в сентябре и каким боком тут AI? Октябрь уж наступил, а постгреса всё нет! Последние пять лет мажорные версии Постгреса аккуратно выходили в сентябре. Как часы — у меня это всегда вызывало восхищение. В этом году будет задержка, причем часть новых фич будто в спешке откатывают. А в блоге Snowlake (облачная дата-платформа) появилась статья, примерно следующего содержания. Мол, PostgreSQL 19 не выйдет в привычный осенний срок и задержится на недели, а возможно, и на месяцы. Главная причина в том, что в ходе беты откатили много крупных функций (53 отката против примерно 44 у PG18), а другие ещё серьёзно перерабатываются. Большинство откатов вызваны ошибками в дизайне, неверными результатами запросов или проблемами совместимости, обнаруженными при ревью уже после коммита. Отличие от прошлых лет, по её словам, в том, что откаты пришлись на поздний этап и затронули громкие функции вроде графовых запросов SQL/PGQ и GROUP BY ALL. Значительную роль сыграли ИИ: инструменты помогают находить баги и готовить воспроизводимые тест-кейсы, а исправления слишком велики, чтобы успеть к релизу. Томаш Вондра, один из коммиттеров PostgreSQL, написал блестящий ответный пост, в котором оспаривает утверждение из блога Snowflake, будто функции Postgres 19 откатывают из-за того, что ИИ-инструменты находят в них сложные ошибки. Автор считает, что неверное определение причины мешает решить настоящую проблему. Проанализировав историю предыдущих откатов, Томаш замечает (и приводит даже графики), что в целом количество откатов не то чтобы какое-то необычное, но необычно то, когда именно они произошли. Обычно откаты происходят сразу после апрельской “заморозки” релизной ветки для нового функционала, а в этом цикле почти ничего не происходило вплоть до резкого всплеска в сентябре. Изучив все 12 недавних откатов и обсуждения в почтовых рассылках, только 4 случая можно отнести к «ИИ» или «возможно ИИ». Большинство же откатов вызваны обычными ревью от людей, а т… Читать полностью →
24 ·
(
(java || kotlin) && devOps
Рекомендую отличную статья по оптимизации скорости вставки в БД на примере PostgreSQL https://habr.com/ru/companies/axiomjdk/articles/1010606 . Виден последовательный, основательный подход. Я думаю многие откроют для себя что-то новое. Например, unnest. У меня вообще с ним интересно вышло - примерно с разницей в один день мне AI-шка этот вариант подсказала, а на следующий на статью наткнулся) Что бы хотелось добавить по своему опыту - есть еще один, достаточно радикальный способ ускорения вставки данных. Отказаться от их хранения у себя) Я не шучу. Примеры: - считать и сохранять только нужные агрегаты - вытаскивать только необходимое. Потенциальный выигрыш может даже превысить тот, что предлагается в статье. Еще что интересно - на своей инсталляции PostgreSQL, без оптимизаций, и сильно слабее описанной в статье конфигурации, я получил примерно те же 15000 записей в секунду на один поток. И тема оптимального числа потоков и ее связь с числом ядер и типом диска требует отдельного исследования. RAM как мне видится, особо влиять на запись не должна. #db #postgresql
48 ·
(
(java || kotlin) && devOps
G1 - долгая дорога к покорению мира) Недавно вышла новая Java - 27-я. Не LTS, изменений не так много, большая часть - мелкие оптимизации. Скорость работы Java - это понятная боль, не зря же появился тот же Rust. Где, кстати, нет Garbage Collector, но это уже другая история. Так вот. Одно из значимых изменений 27 версии - G1 стал сборщиком мусора по умолчанию. ... Так, а раньше разве не он был? Смотрим историю G1. Появился в Java 6. Стал выбором по умолчанию в Java 9. Но ... не для всех. А только для серверных окружений. Что под этим понимается? Не менее 2 ядер и 2 Гб памяти, доступных приложению. Т.к. в условиях ограниченных ресурсов Serial GC был эффективнее. И вот в новой Java 27, вышедшей в сентябре 2026 года, разработчики допилили G1 настолько, что он включается сейчас по умолчанию для любых окружений. 9 лет прошло. Такой интересный факт. А выводы такие. 1) Java - это совместимость, это не быстро, и мы про это знаем) 2) Параметры JVM для высоконагруженных приложений лучше задавать явно. И включать в процедуру НТ. #java #jdk #gc
106 ·
(
(java || kotlin) && devOps
Еще одно интересное нововведение в Java 27. Сейчас, благодаря развитию ИИ, тренд на безопасность. И разработчики JVM решили быть в тренде) JFR - Java Flight Recorder. Профилировщик - инструмент, сохраняющий набор событий, возникающий в Java приложении, с их таймингом в файл. Входит в состав OpenJDK, доступен всем. Казалось бы - при чем тут безопасность? Вопрос в данных, сохраняемых JFR. Там же могут быть пароли и прочие секреты? Могут. Так вот, начиная с Java 27 JFR сам маскирует все секреты, которые находит. Ищет он в следующих местах: 1) jdk.InitialEnvironmentVariable — начальные значения переменных окружения; 2) jdk.InitialSystemProperty — начальные системные свойства, включая информацию о командной строке; 3) jdk.JVMInformation — аргументы запуска JVM и приложения. Ищет вот такие ключи по умолчанию: - *api*key* - *auth* - *credential* - *password* - *private*key* - *secret* - *token* и заменяет в них значения. Почему по умолчанию? Можно расширить список ключей для маскирования значений в них через параметр -XX:FlightRecorderOptions:redact-key. Можно также задать шаблон для значений: -XX:FlightRecorderOptions:redact-argument Используется glob шаблон, не Regexp. Как по мне начинание хорошее, облегчает использование JFR на ПРОМ. Благо, накладные расходы у него небольшие. Не 100% гарантия, но если есть проблема с согласованием от ИБ - должен помочь. Сужает поверхность атаки. #java #jdk #profilers
127 ·
(
(java || kotlin) && devOps
Еще одна интересная штука из последних JDK - правда не 27, а 26 - LazyConstants https://openjdk.org/jeps/526 В чем суть? Вот пример кода - было\стало: // OLD: static final OrderController ORDERS = new OrderController(); // NEW: static final LazyConstant<OrderController> ORDERS = LazyConstant.of(OrderController::new); или так: // OLD: private static volatile OrderController instance; public static OrderController getInstance() { if (instance == null) { synchronized (OrderController.class) { if (instance == null) { instance = new OrderController(); } } } return instance; } Т.е. мы получаем из коробки: 1) ленивую инициализацию - Lazy 2) технический признак константы над формально обычным полем - Constant 3) однократное вычисление значения - как бонус. Признак константы (@Stable) дает возможность провести различного рода оптимизации для компилятора и JIT. Работает как с обычными, так и с static полями. Можно подумать, что это подсмотрено в Kotlin - конструкция by lazy. В плане boilerplate-less кода - возможно да. Но у Kotlin это синтаксический сахар, в котором реализована ленивая инициализация и однократное вычисление. Но нет признака @Stable, по крайней мере на данный момент. Как по мне - штука полезная. Вспоминается один монолит, в разработке которого я лет 10 назад принимал участие. Монолит был большой, разрабатывало его под сотню человек. И периодически кто-то добавлял в один из классов static поле с тяжелой инициализацией, которая падала при старте из-за того, что нужных ресурсов еще не было. #java #jvm #lang
96 ·
(
(java || kotlin) && devOps
Ссылка
нажмите — покажем
Давно не было провокационных постов от Егора Бугаенко на канале, ловите https://youtu.be/JRMnoQvFfKU С чем хочется поспорить? Первое и самое главное - не уверен, что AI разработка приведёт к исчезновению документации к коду. Аргумент Егора: раз код сейчас не читает человек, а машина быстро разбирается в любом коде - документация не нужна. Тут сразу уточнение - я бы расширил понятие документация. Документация для меня это и Java, и тот же Openspec, и любые другие документы по архитектуре. И я, кстати, вижу в AI чатах мнения, что OpenSpec не нужен. Так вот, если документацию убрать - получаем 2 проблемы: 1) ок, человек не читает код. Но ему все равно нужно что-то читать, если pull request не элементарный. Егор говорит о неких простых артефактах, из которых сразу видна суть изменений. Типа архитектурной схемы в yaml. Хорошо если такая есть, и она описывает все возможные изменения в проекте. Но если это невозможно - вот тебе новая SDD спецификация или дельта в существующую. 2) идея "код содержит всю правду" IMHO утопична. Причем не важно, кто писал этот код. Всегда есть исключения. Всегда есть то, что в код пока (!) не вошло. Намерения пользователя в конце концов. Этому место в документации. Как по мне основная проблема сейчас - избегать дублирования в документации, делать ее компактной. Чтобы не было - одна и та же мысль есть и в JavaDoc, и ещё в 3 спеках. AI любит дублировать. А идея отказаться от документации вообще красива, но утопична. Вторая спорная мысль - все PR делают роботы, разговаривать с ними не надо, делаем своих роботов для отсева кривых PR. С одной стороны все к этому идёт. А с другой - PR появился из-за чьего-то намерения. Намерение остаётся за человеком. Канал для связи с этим человеком все равно нужен, пусть и не в рамках многодневной переписки в PR. А вот над чем стоит подумать: 1) с увеличением числа изменений master будет ломаться чаще. Нужны правила для агентов по его автоматической починке. 2) большие pull request всегда были болью, о… Читать полностью →
85 ·
(
(java || kotlin) && devOps
Ссылка
нажмите — покажем
Чем Codex лучше Claude Code? Я последние пару месяцев использую в работе оба, и замечанию некоторые отличия. Сразу скажу - по качеству рассуждений и кода я особой разницы не вижу. Хотя есть мнение, что ChatGPT как модель слабее для разработки. По рейтингам это не очевидно. Сравните статистику по агентам https://oss-arena.vercel.app/ и по моделям https://canaryarena.ai/leaderboard/agent. Но по факту я вижу, что у разработчиков более популярен Claude. Ну и Cursor еще. И отсюда растут ноги у преимущества Codex. Разработка - это основная отрасль, куда уходят токены. И, соответственно, зарабатываются деньги провайдерами моделей. Вот пример более менее свежей независимой статистики по OpenRouter: https://robinlllll.github.io/ai-coding-adoption/dashboards/openrouter.html Момент замера выбран странный, в лидерах непонятная tencent/hy3-preview, но смотреть нужно в раздел App category breakdown. Вот статистика от Claude https://www.anthropic.com/economic-index#us-usage?state=dc Тут доля поменьше, но все равно самая большая. Поэтому для OpenAI (создателя ChatGPT) потеря этого рынка - очень плохо. И они пытаются его переломить - завлечь разработчиков в Codex. И наконец к сути. Лучше Codex тем, что у него есть т.наз. resets. Это возможность сбросить оба лимита токенов по подписке - дневной и недельный. А подписка, напомню, это наше все - за смешные деньги куча токенов. Как оно работает? Фича появилась в июне этого года. Reset копятся, у них есть срок годности. Сколько накопилось можно увидеть по команде /usage. Там же можно сбросить лимиты. Ничего такого у Claude нет, там только акции по временному увеличению контекстного окна (было в августе этого года). Причем reset копятся так хорошо, что я их не успеваю тратить) И еще момент - есть автоматические reset. То ли это массовый автоматический подарок. То ли это баг и после использования reset срабатывает и новая дата (+7 дней от сброса), и старая. Не знаю, но они есть) Ясно, что это маркетинг и попытка догнать конкурента.… Читать полностью →
45 ·

Открытая публичная лента из поискового индекса ChatCrawler — «Google по публичному Telegram»; обновляется по мере обхода площадки. Время — UTC.

Только публичный контент, официальный API Telegram. О проекте · Вопросы · Границы индекса · Убрать страницу из выдачи · Каталог · Поиск · Как мы считаем