HikariCP давно стал де-факто стандартом JDBC connection pooling в JVM-проектах. Но подключить его мало: важно правильно выбрать размер пула, таймауты, maxLifetime, keepaliveTime, leak detection и метрики.
Разбираем, как настроить HikariCP для Java, Kotlin, Scala и Spring Boot, какие ошибки чаще всего встречаются в проде и почему maximumPoolSize нельзя просто копировать из соседнего сервиса.
Привет, Хабр! Меня зовут Данил Чечков, я Team Lead команды High End Meta Backend в «Леста Игры». Мы занимаемся всей web‑составляющей «Мира кораблей». В нашем арсенале огромное количество микросервисов, работающих на Python и Go. Мы отвечаем за покупки в meta‑валюте, авторизацию, стабильность инвентаря и профиля игрока, клановые сервисы, а также многое‑многое другое.
Наш основной продукт — высококачественные web‑сервисы на стыке интеграции с игрой. И, да, интеграция — часть нашей работы.
А ещё мы любим новые технологии и стараемся с ними знакомиться, чтобы оценить, как они могут принести выгоду бизнесу и нам. Одна из таких технологий — LLM
Когда я начинал CodeClone, это был довольно понятный инструмент: найти структурные клоны в Python-коде и не дать им незаметно расползаться по проекту.
Сейчас вышел CodeClone 2.0.0, и это уже другой продукт.
Не “ещё один линтер”, не попытка заменить Ruff, mypy, pytest, Bandit или Semgrep, а отдельный слой ревью: он смотрит на структуру Python-кода, отделяет старый технический долг от новых регрессий, связывает находки с покрытием тестами и дает одну и ту же картину в CLI, HTML-отчете, GitHub Actions, VS Code, Claude Desktop, Codex и через MCP.
Эта статья не про список флагов CLI. Про флаги есть документация.
Здесь я хочу рассказать, во что CodeClone вырос как продукт и зачем вообще нужен такой класс инструмента сейчас, когда разработка всё заметнее смещается в сторону AI-агентов.
Меня просто нечеловечески бесит, когда разработчики оправдывают собственную некомпетентность мантрой «бизнесу надо». Если программист любой степени квалификации, от стажёра — до принципала — использует в качестве аргумента в любой дискуссии фразу «бизнесу надо» — знайте, перед вами тупой самозванец, гоните его в шею. Звучит претенциозно?
Вчера вышел Zed 1.0. Пять лет работы, миллион с лишним строк на Rust, публичная превьюшка, которой ежедневно пользовались сотни тысяч разработчиков, и вот команда Zed Industries во главе с Натаном Собо запостила релиз 29 апреля 2026 года. Я лет пятнадцать живу в IDE от JetBrains. Пробовал VS Code. Пробовал Cursor. Гонял code-server на удалённой виртуалке. Ничего не приживалось. Zed прижился, и релиз 1.0 — нормальный повод объяснить, почему.
Если коротко: больше десяти лет любой «новый» редактор кода — это всё тот же продукт в новой обёртке. Обёртка зависит от того, что продают сегодня: AI, коллаборация, темы, новый вендор. А под обёрткой Electron. Тот же Chromium на каждое окно, тот же JavaScript на критическом пути исполнения, тот же RSS, к обеду уходящий в гигабайты. Sublime Text держал планку нативных редакторов все 2010-е, но это был закрытый продукт одного автора, без нормальной коллаборации и без AI истории. Zed стал первым за последние десять лет убедительным опенсорс-редактором с GPU-ускорением и AI на борту, который пересобрали с нуля и без всякого браузера под капотом. С релизом 1.0 эта ставка наконец сыграла.
Cursor или его аналоги, здорово облегчают написание кода, когда речь идет о каких‑то не очень больших проектах. Но стоит попробовать применить их к серьезному, сложному проекту, состоящему из нескольких репозиториев, и тут же сталкиваешься с тем, что эти «чудеса» оборачиваются просто огромными счетами за токены. Я в этой статье поделюсь, как мне удалось перестать впустую сжигать миллионы токенов. Для этого пришлось собрать и запустить три MCP‑сервера по протоколу Model Context Protocol, что позволило сэкономить до 90% бюджета, при этом совершенно не потеряв в эффективности модели при работе с кодом.
По мере того как современная разработка программного обеспечения движется в сторону непрерывной доставки и микросервисов, цена ошибок возрастает. Нестабильные тесты, плохо масштабируемый код автотестов или неправильное использование инструментов могут приводить к задержкам релизов или к росту количества багов из‑за затрат времени и ресурсов на выявление причин падения автотестов. То, что сначала кажется временным исправлением, впоследствии может обернуться отложенными последствиями для всей команды.
В этой статье мы рассмотрим семь распространенных ошибок, которые совершают начинающие SDET. Разберем не только то, что идет не так, но и почему это имеет значение и как подходить к решению каждой из проблем наиболее эффективно. Цель статьи — помочь начинающим SDET заложить прочный фундамент для эффективного тестирования, основанного на качестве, масштабируемости и взаимодействии с командой.
AI отлично ускоряет написание кода, но в больших проектах это быстро создаёт новую проблему: код появляется быстрее, чем команда успевает его понимать и ревьюить.
Мы столкнулись с этим во время миграции большого исторического проекта на Next.js 15. Вайбкодинг сначала выглядел как идеальное ускорение: модель за минуты переносила страницы, компоненты, хуки и server actions. Но затем на ревью начали прилетать огромные PR с тысячами строк сгенерированного кода.
На детальном ревью выяснилось, что AI часто переносит поведение неточно, пишет собственные велосипеды вместо использования готовых open source решений, не подтягивает дизайн-токены из Figma, не делает Storybook stories и не запускает тесты, если его явно об этом не попросить.
В статье рассказываю, почему проблема не в самом AI, а в отсутствии процесса вокруг него. И предлагаю prompt-first подход: сначала ревьюить короткий промт-план с контекстом, ограничениями, файлами и критериями приёмки, а уже потом генерировать код и открывать PR.
Старый код редко лежит бесплатно. Даже если его никто не вызывает, он попадает в поиск, ревью, CI, локальный запуск и голову каждому новому разработчику. Разбираю на примерах: DTO, endpoint’ы, которые «скорее всего не используются», deprecated events, конфиг-поля, Docker/CI-хвосты и продуктовые фичи «на будущее».
В разработке качество часто ломается не только на самих багах — но и в тех местах, где работа переходит от одного этапа к другому без ясных условий. Задача уже поехала дальше, хотя acceptance criteria ещё сырые. Формально её можно тестировать, но по факту сначала нужно собирать контекст. Пайплайн зелёный, при этом важная проверка вообще осталась за его пределами.
Такие ситуации обычно показывают не частную ошибку, а устройство процесса в целом. Когда важные условия нигде не закреплены, команда расплачивается за это уточнениями, возвратами и лишней синхронизацией. И напротив — если критерии перехода определены заранее, работать проще. Поэтому Quality Gates для нас в Островке — не только способ ничего не упустить, но и понятный маркер того, насколько процесс разработки вообще выстроен и управляем.
Форма у таких гейтов может быть разной: автоматическая проверка, правило в workflow или простой критерий готовности. Важно не как выглядит гейт, а какую точку неопределённости он закрывает.
Под катом — практический разбор того, что вообще можно считать Quality Gate, где такие механизмы реально работают и как подбирать их под задачи команды.
Привет, Хабр!
Меня зовут Александр Сахаров, я директор по работе с партнерами в «Диасофт». Последние пять лет мы строим экосистему Digital Q - набор low-code платформ для enterprise-разработки в микросервисной архитектуре. Внутри у нас около двух тысяч разработчиков, и мы на собственном опыте знаем, что бывает, когда каждая вторая команда изобретает велосипед.
Но в этой статье я хочу показать не только наш взгляд. На конференции Deckhouse Conf 2026 мне удалось собрать за одним столом людей, которые каждый день живут внутри этой проблемы: это руководители в ИТ в крупнейших банках и телеком компаний, помогал мне Артем Гениев из «Фланта», руководитель бизнес-юнита «Экспресс 42» - ребята, которые строят платформу со стороны DevOps и инфраструктуры.
Меня зовут Александр Сахаров, я директор по партнерствам в компании Диасофт. И тезис, с которого начну, довольно дерзкий: старый айтишный треугольник «быстро, дешево, качественно, выберите два» в 2026 году можно закрывать. Правда, с одним условием, о котором почему-то практически не говорят.
На днях мы собрались с коллегами обсудить мифы вокруг искусственного интеллекта. Поговорили про AGI и массовые увольнения из-за внедрения ИИ, но с определенной долей скепсиса. И вот почему. Дело в том, что по свежим данным 56 процентов CIO в мире за последний год не получили от ИИ ни роста выручки, ни снижения затрат. Удивлены?
Если вы часто упираетесь в лимиты Claude Code / Codex и не понимаете, куда улетают токены — этот лонгрид для вас
Да и вообще всем, кто хочет разбираться в современных AI инструментах, будет полезно
Разбираемся
1. Как устроено контекстное окно изнутри: 7 слоёв (от весов модели до MCP и skills)
2. Что такое attention и при чем тут O(n²)
3. Как работает agent loop на примере 4 вызовов модели
4. Почему prompt caching экономит до 10× в лимитах при правильной работе с ним
Сууупер длинная статья
Красные тесты на CI, зелёные локально, time.sleep в каждом втором тесте, а после смены селектора всё равно всё падает? Знакомо. Это не судьба, а отсутствие архитектуры. Разбираем, как превратить хаос из автотестов в промышленный фреймворк: слои, паттерны (POM, Builder, DI), анти-паттерны и работу с окружениями. С примерами на Python.
Ценность квалифицированного программиста смещается в сторону умения проводить обзоры кода. Генерировать код становится проще, но всё так же важно проверять его с точки зрения качества декомпозиции, корректности реализации, эффективности, безопасности. Посмотрим на примере маленького проекта markus, созданного с помощью Claude Opus, почему важно понимать сгенерированный код и уметь видеть, что скрывает красивый текст программы.
Всем привет. В последнее время в одной профессиональной соцсети я все чаще стал натыкаться на посты, связанные с dotnet C# тематикой. К сожалению, эти посты в большинстве своем не содержат полезной информации. Скорее всего они создаются для охвата аудитории с целью привлечения трафика на сторонние платформы по продаже курсов для разработчиков. По-моему, этот способ называется "воронка продаж" (поправьте, если я ошибаюсь). Как правило, эти посты затрагивают какую-то не очень сложную тему и содержат примеры кода. Недавно мне попался очередной пост, в котором автор пытался показать пример использования новой фичи labeled break and continue. Это новая фича, которую добавили в C# 15 (dotnet 11). На момент написания она была принята в Working Set, но финального релиза ещё не было. Ниже код, похожий на оригинал из поста. Он разделен на 2 секции: "как делали раньше" и "как сделать используя новый подход":
Стандартный способ:
Привет. Я фронтенд-разработчик. По мнению тех, кто, по мнению некоторых, перекладывает джейсончики туда-сюда, я крашу кнопочки. Но сам я себя идентифицирую иначе: я тоже перекладываю джейсончики, и у меня всё точно так же, как у них. Даже архитектура. У меня тоже есть контроллеры, сервисы и хранилища, и я также обрабатываю запросы пользователей. Даже больше, я делаю HATEOAS, «тру» RESTful, если хотите. Давайте расскажу, как я к этому пришел.
Когда-то давно я только верстал. Накидывал разметку, добавлял классы, идентификаторы и стилизовал ЦСС-ом. И было хорошо. Потом от меня потребовали динамичности — пришлось добавить JavaScript. И было очень хорошо.
Технологии развивались, и мне хотелось пробовать новое. Я попробовал AJAX. Это было так волнительно... Я сказал бэкендерам: основную разметку жду от вас, а опции для выпадающего списка, например, отдавайте джейсоном по запросу. Они были не в восторге. «Одному HTML подавай, другому CSV, третьему ещё что-то — безобразие!» Но мы нашли компромис. Бэкэндеры сказали: «Вот вам, мол, джейсон, дальше сами как-нибудь». И назвали это REST API.
Сначала было очень круто! Мы, верстальщики, организовались. Мы стали фронтендерами! Конечно же, мы сразу побежали решать ещё нерешённые сто раз решённые задачи. Мы писали библиотеки и фреймворки — четыре миллиона штук! Да у нас даже есть библиотека с функцией для умножения чисел — lodash.multiply. Мы придумывали свои паттерны и архитектуры, например FSD. Короче, мы стали очень крутые.
Но то уже были «мы», а не я. Мне было сложно. Шутка ли, изучать по одному новому фреймворку в неделю? А ведь еще переписывать всё надо, стек-то устарел... В общем, в какой-то момент я перестал поспевать за модой и справляться со сложностью. Переходишь из одного проекта (на React) в другой (на Vue), а там всё иначе. Берешь нового разработчика в команду с опытом в React, например, а ему нужно время, чтобы вникнуть, потому что в его старой команде был другой «стейт-менеджер». Вавилон, никто друг друга не понимает.
Привет! Это снова Михаил Федоров. В первой статье я рассказал про архитектуру QA Assist — системы из 11 AI-агентов для автоматизации тестирования. Во второй — честно показал, как «4 часа подключения» превращаются в неделю корпоративной реальности.
Сегодня поговорим о штуке, которая на первый взгляд не имеет отношения к AI. О пирамиде тестирования. О том, почему классическая теория QA внезапно оказывается критически важной, когда вашим тест-дизайнером становится языковая модель с контекстным окном.
На одном из созвонов потенциальный заказчик поделился болью:
“Меньше чем за год велосити команды внешнего вендора упала в разы. Почему задачи, которые должны занимать 2–3 дня, растягиваются на недели?”
Проект шел уже почти год с участием внешнего IT-вендора. По документам на проекте работала senior-команда: сильные CV, большой опыт, уверенные интервью. Ожидания были понятные - стабильная скорость разработки и предсказуемый результат.
Первые месяцы так и было. Но примерно через полгода начали появляться странные сигналы. Скорость разработки постепенно снижалась. Задачи, которые раньше закрывались за несколько дней, начали затягиваться. Планирование становилось все менее точным. Это не выглядело как резкий провал, а скорее как медленное ухудшение, которое легко объяснить ростом сложности проекта или накопившимся техдолгом. Но динамика все равно вызывала вопросы.
Заказчик решил разобраться и обратился к нам.
Мы посмотрели код, провели техническую оценку команды и разобрали, кто какие задачи закрывает. Важно было не то, что написано в CV, а то, как команда работает на практике.
Картина оказалась неожиданной - около 30% команды были junior-разработчиками.
Не “почти senior”.
Не middle.
Именно junior!
При этом бюджет проекта строился исходя из senior-ставок.
Когда мы начали разбираться, выяснилась еще одна деталь - на замену специалистов заказчик никакого апрува не давал. Часть senior-разработчиков постепенно заменили на junior. Это происходило не сразу, а постепенно, поэтому долго оставалось незаметным. Формально команда оставалась «той же», но по факту ее уровень изменился.
Рефакторинг должен быть скучный и надежный. Надо держаться от искушения обновить библиотеку, починить баг, улучшить стиль. Под катом разбор почему именно такой путь сможет вытянуть тяжелый legacy рефакторинг, а шаг вправо и влево ведет к откату релиза.
