Channels

Top 100 Trending New

Categories

Crypto Gaming News Entertainment Music Sports Tech Gambling Bots and mini apps Finance Business Education Lifestyle Health Travel Auto Fashion Jobs Dating Deals and shopping

Stickers

Stickers Emoji Themes Wallpapers

Bots Gifts Tools

Currency

$ USD ₽ RUB € EUR ₴ UAH ₸ KZT ₺ TRY zł PLN ₪ ILS AED AED R$ BRL Rp IDR RM MYR ¥ JPY ₩ KRW CN¥ CNY

Theme

Português (Brasil)

Bahasa Indonesia

Беларуская

Українська

Channels Categories Stickers Bots Gifts Tools

Premium Wiki Glossary Legal

Notifications Settings Log in

(java || kotlin) && devOps: post #632 — TG.ME

(java || kotlin) && devOps@javaKotlinDevOps · 345 subscribers Open in TelegramOpen

[media without text]

t.me/javaKotlinDevOps/632

August 16, 2026

More from this channel

И снова рубрика "Находки из 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 30·Aug 28 Еще про стандартизацию 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 39·Aug 26 Заметки по 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) и есть раздельный учет по провайдерам в статистике, либо без преобразований, но все сидят на одном провайдере. 7) есть важная настройка general_settings: forward_client_headers_to_llm_api: true Она позволяет пробрасывать к провайдеру клиентские заголовки, начинающиеся с x-. Нужна, например, для пробрасывания заголовков Claude Code со списком поддерживаемых клиентом фичей. Вроде бы все хорошо, штука полезная. Но как выяснилось при разборе логов - в процессе пробрасывания есть фильтрация (вырезание) неизвестных для LiteLLM заголовков. Как я понял, это нужно, чтобы резать заголовки с секретами, которые клиент шлет, а в LLM провайдер передавать нельзя по каким-то (каким?) причинам. Резали бы только свои заголовки, типа x-litellm-api-key - ключ для аутентификации в LiteLLM. Это еще пол-беды. Плохо то, что ни отключить, ни настроить эту фильтрацию нельзя. Сейчас у меня все работает, но учитывая борьбу того же Anthropic с не-родными клиентами - потенциально опасная штука. Получилось как список проблем, но конечно же есть и плюсы) #ai #ai_agents 56·Aug 24 Заметки про 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) большая часть проблем возникает на стыке агента и прокси. Хотя этот момент в документации постарались раскрыть - вот пример отдельная статья по подключению Claude с подпиской https://docs.litellm.ai/docs/tutorials/claude_code_max_subscription Ну и на примере этой же статьи можно разобрать ряд проблем: 1) в заголовке статьи явно указана Claude Max, что сразу вызывает вопрос о Pro подписке. А она работает) 2) названия моделей. Они устаревшие, при этом они подаются как список поддерживаемых моделей. На самом деле поддерживаются все актуальные, это же обычный прокси. 3) LITELLM_MASTER_KEY - что это, зачем, как генерировать? Генерировать, к слову, также, как и другие виртуальные ключи - из консоли или в UI. Но виртуальные ключи - это способ разделения трафика от разных агентов в отчетах, а зачем нужен мастер ключ? 4) судя по статье для Anthropic - как преднастроенного провайдера - API endpoint указывать не нужно... Это собственно была главная проблема. Пока я не указал url явно - прокся отправляла запросы по подписке сама на себя, выдавала ошибку аутентификации 401, т.к. второй запрос шел с кредами Anthropic, а не со своими. А ошибка аутентификации вводила в заблуждение, т.к. говорила, что не найден ключ для LiteLLM. И более того, эта ошибка была обвернута в (видимо) стандартную ошибку - что-то типа выбранная модель не настроена. Что еще больше вводило в заблуждение, т.к. она же настроена по инструкции) Еще больше ввела в заблуждение весенняя новость о запрете использования подписки Claude в сторонних агентах и контроле агента на стороне сервера. Я уже начал думать, что и прокси зарубили, но нет) Ну и самое главное на стыке агента и прокси, в моем случае Claude Code: 1) у Claude Code есть 2 режима работы - OAuth и API токены. Переключает их наличие переменной среды ANTHROPIC_AUTH_TOKEN. В целом понятно, но об этом нужно помнить. Секрет LiteLLM либо в ANTHROPIC_AUTH_TOKEN (API), либо в ANTHROPIC_CUSTOM_HEADERS (OAuth). Рабочая схема - завести отдельный shell скрипт для API режима. 2) у Claude Code есть model discovery (включается CLAUDE_CODE_ENABLE_GATEWAY_MODEL_DISCOVERY=1) - запрос доступных моделей у провайдера, прокси в нашем случае. Но агент запоминает только модели, начинающиеся с claude. Зачем, почему - хз. Но пришлось заводить claude-deepseek и т.д) 3) discovery запускается только для API режима. Это логично. И сохраняет список моделей при дальнейшей работе в любом режиме 4) агент не умеет запрашивать характеристики модели, в частности размер контекстного окна. А от его размера зависит в какой момент запустится автосжатие. А для неизвестных агенту моделей (всех в нашем случае) агент считает размер контекста равным 200к токенов. Все способы настройки выглядят как костыли https://code.claude.com/docs/en/model-config#correct-the-window-for-a-gateway-or-custom-model-id Я завел каждую модель с контекстом более 1m в 2 экземплярах - с суффиксом [1m] и без. Первая удобнее, вторая - дешевле. Отображаются в агенте они криво, но главное - работает. Stay tuned, об остальном позже. #ai #ai_agents 71·Aug 20 Можно ли чему-то научиться у AI? Базовый ответ - да, т.к. в LLM в процессе обучения попало множество документации и кода, который я, например, никогда не видел. Да, в сжатом виде, возможно искаженном, но в любом случае это огромный объем знаний. Но я сейчас про более конкретные вещи. Например, тесты. Ключевой момент, что агент пишет десятки тестов на каждую фичу. Кроме стандартных unit и интеграционных я заметил парочку новых типов. 1) тесты на миграцию БД - включая откат миграции. Простые, накатывают миграцию, проверяют, что новый объект появился\исчез в БД. Польза не то, чтобы большая, но есть. Ломаться часто не должны, т.к. каждый такой тест проверяет свою версию БД. 2) AST тесты - т.е. тесты с синтаксическим анализатором кода, проверяющие, что в методе не делается что-то лишнее. Или делается что-то обязательное. Часто такие тесты можно реализовать передачей в тестируемый метод spy-объекта. Но не всегда. Для меня было открытием. Самому такие тесты писать сложно, AI - примерно также, как и другие. Тесты скорее всего будут хрупкими, т.к. зависят от структуры кода. Но для проверки отдельных ключевых инвариантов проекта, над которым работает множество людей - это лучше, чем JavaDoc. 3) тесты, проверяющие документацию, генерация которой - тоже функция приложения. Например, admin guide. Наличие, формат. Тоже свежая мысль, IMHO. Самому - точно руки бы не дошли до таких тестов, а с AI - почему бы и нет. Последний кейс пограничный - то же самое можно сделать и скилом. И такие приемочные скилы (они же evals) - это тоже своего рода тесты, просто реализованные в другой форме. Просто они могут не просто вызвать скрипт, а еще и проверять требования к проекту с помощью LLM. И даже в случае LLM, которая недетермирована, это лучше, чем просто пару строк в README.md. #ai #ai_agents #testing 70·Aug 18

An open web layer over public Telegram — search, stats and channel reading right in your browser, no account, no install.

Not affiliated with Telegram FZ-LLC; all data comes from public sources.

Catalog

Top channels Categories Countries Search

Content

Stickers Emoji Gifts Themes Wallpapers

Help

Tools Wiki Glossary Blockchain Safety Premium Advertisers Advertising

© 2026 TG.ME · G.Media network· Updated 08/28/2026 · v0.2.0 · c9ad1b1

Privacy Terms DMCA & complaints Report a violation

Similar channels

дата инженеретта3.4K subscribers

Synapse Community364 subscribers

Уставший техдир17.2K subscribers

/home/Vzhyx/737 subscribers

Junior QA to Dev3.5K subscribers

Шпаргалки программиста2.2K subscribers

Сова пишет…3K subscribers

rzv Data Engineering3K subscribers