Kotlin *

Старый код редко лежит бесплатно. Даже если его никто не вызывает, он попадает в поиск, ревью, CI, локальный запуск и голову каждому новому разработчику. Разбираю на примерах: DTO, endpoint’ы, которые «скорее всего не используются», deprecated events, конфиг-поля, Docker/CI-хвосты и продуктовые фичи «на будущее».

Как проверить, что ИИ-агент в IDE работает, если на одинаковые запросы LLM отвечает по-разному? Ответы модели недетерминированы, а интерфейс и бизнес-логика вполне детерминированы, и их нужно тестировать отдельно.

Мы делаем ИИ-агента, встраиваемого в JetBrains IDE. В статье расскажу, как мы выстроили UI-автоматизацию плагина так, чтобы тесты ловили регрессии в интерфейсе, бизнес-логике и при этом не «моргали» из-за нестабильности LLM.

Рано или поздно каждый Android‑разработчик сталкивается с задачей «одно приложение — много сборок»: white‑label‑решения, региональные версии, отдельные сборки для разных магазинов приложений, демо для клиентов, внутренние окружения.

Встроенный механизм product flavors в Android Gradle Plugin отлично справляется со своей задачей — пока количество вариантов умещается в голове и в паре экранов build.gradle.kts.

В этой статье я разберу подход, при котором конфигурация flavors строится динамически: список вариантов и их параметры живут вне build.gradle.kts.

Это часть 2. Первую часть смотреть по ссылке.

Данная статья является второй из цикла по описанию особенностей построения приложений с использованием идей, описанных в книге «Искусство неизменяемой архитектуры: теория и практика управления данными в распределенных системах».

Описание создаваемого ТЕСТОВОГО / ТРЕНИРОВОЧНОГО приложения и базовые сокращения можно найти в начале первой части.

В рамках данной статьи будет описана задача реализации аутентификации внешних клиентов/сервисов с помощью сертификатов и идей «неизменяемой архитектуры».

Что такое аутентификация и ее отличие от авторизации можно уточнить по этой ссылке.

Всем привет! Меня зовут Михаил, я главный эксперт в ОТП банке.

Несколько лет я мечтал поработать на Kotlin. Мне это удалось — был большой проект РЖД, я вкатился, писал код, радовался. Kotlin мне правда понравился.

Но давление менеджеров, нереальные сроки и просто выгорание вынудило меня выходить на рынок, и я пошёл искать работу… и тут меня ждал сюрприз. Вакансий, где нужен чисто Kotlin, в России — единицы. А те, что есть, чаще ищут Java/Kotlin с упором на первую.

В этой статье — моя история: как я вкатывался в Kotlin без подготовки, как мне понравилось, и почему я всё равно сейчас пишу на Java. Читайте, если думаете о переходе, — возможно, это поможет скорректировать ожидания.

Поехали!

В прошлой статье я сравнивал Paginator с Paging 3 на кошачьем уровне: «вот простой фид, смотрите — три строки вместо тридцати». Это полезно для первого знакомства, но не отвечает на главный вопрос: а как оно себя поведёт, когда продукт начнёт требовать то, ради чего люди обычно и пишут свой велосипед поверх Paging 3?

В этой статье я беру мессенджер — потому что мессенджер это честный полигон. Там есть:

Когда я начал делать кредитный трекер, казалось, что финансовая математика — самая простая часть проекта. Формула аннуитета есть в любом учебнике, Excel справляется за пять минут.

Я ошибался.

Небольшой контекст: до этого я довольно долго не делал ничего для Android — работал в других областях, экосистема успела заметно измениться. Вернуться оказалось неожиданно приятно: Compose после нескольких лет XML-вёрстки ощущается как глоток свежего воздуха, KSP вместо KAPT работает заметно быстрее, а Room с Flow и корутинами — это уже совсем другой уровень удобства по сравнению с тем, что я помнил. Так что статья отчасти и про это: как выглядит возвращение в Android-разработку после перерыва.

Под катом — технический разбор того, как на самом деле устроен кредитный калькулятор внутри Android-приложения. С реальным кодом, реальными компромиссами и честным признанием того, что мы намеренно упростили.

Если коротко: пагинация — это когда вы не грузите 100 000 товаров из каталога одним запросом, а показываете их страницами по 20–50 штук и подгружаете следующую порцию, когда пользователь домотал до конца.

Звучит как задача на полдня. На практике — по-разному.

Я пишу мобильные приложения уже давно, и каждый раз, когда в новом проекте появлялась пагинация, рядом с ней через месяц-другой появлялся один и тот же набор багов и ad-hoc-решений. Флаги isLoadingNextPage, isLoadingPrevious, isRefreshing, isEmpty, hasError, hasNextPage. Попытки «просто заменить элемент без перезагрузки страницы». Восстановление позиции после убийства процесса. Прыжок на конкретную страницу по deeplink.

На Android есть Jetpack Paging 3, и его берут по умолчанию. Но как только вы выходите за рамки «загрузи следующие 20 элементов на скролле вниз» — начинается интересное. А если ваш проект — Kotlin Multiplatform, то Paging 3 вообще не ваш вариант: это Android-библиотека, она не едет на iOS.

Я расскажу про опенсорсную библиотеку Paginator, которую делаю последние несколько лет. Она работает одинаково на Android, JVM и iOS из одного commonMain, закрывает сложные сценарии из коробки — и даже на самой обычной ленте настраивается короче, чем Paging 3. Это не поход против Paging 3 и не попытка что-то кому-то доказать. Это просто описание того, что есть другой инструмент, и он делает то же самое компактнее.

Всем привет! С вами Анна Жаркова, руководитель мобильной практики ГК Юзтех. Что ж, за последние полгода мир разработки и мир ИИ скакнули и ушли далеко вперед. Теперь знания работы с агентами, умение написать не только правильный промт, но и собственные скиллы (навыки) для этих агентов, готовить свои mcp для погружения в контекст задачи, проекта, становятся не только полезными, но и обязательными для разработчиков и IT-специалистов. Уже многие используют как специальные IDE с ИИ-агентами (Claude, Cursor, Windsurf и т.п), так и встраиваемые в привычные VsCode и AndroidStudio в виде плагинов. Можно не ограничиваться готовым настраиваемым функционалом, а пойти дальше и написать свой собственный агент. И сегодня мы поговорим про такое решение, использование специального фреймворка от JetBrains Koog для разработки свои агентов. С его помощью мы создадим агент для генерации простых KMP приложений и кросс-платформенных задач и подключим к плагину Continue dev.

Небольшой спойлер: сам агент был написан при участии Cursor, и про нюансы его создания читайте в конце статьи.

В статье рассмотрим кто сегодня выигрывает битву за бэкенд: сравнение синтаксиса, разбор производительности, а главное — честный прогноз на 2-3 года. Если выбираете стек для нового проекта или думаете, учить ли Kotlin вдогонку к Java, — эта статья для вас!

Продолжаем серию «Kotlin для новичков». Сегодня разбираем фундамент, без которого не обходится ни одно приложение: строки и коллекции. Как правильно резать подстроки, форматировать JSON, чем List отличается от MutableList и зачем enum в Kotlin круче, чем в Java. Заглядывайте, будет полезно!

Один экран в приложении, а на бэкенде несколько REST-вызовов, куча эндпоинтов и ответы, где 90% полей не используются. Теряем в скорости, усложняется фронтенд и приходится версионировать контракт, когда меняется формат данных.

GraphQL предлагает другой подход: один API-эндпоинт и запрос, в котором клиент сам указывает, какие поля ему нужны. Это снижает overfetching, уменьшает количество сетевых затрат и упрощает договоренности между фронтом и бэком за счет схемы как явного контракта и живой документации.

В новом переводе от команды Spring АйО разберем, где GraphQL реально помогает: как уйти от разрастания эндпоинтов, как держать контракт синхронизированным и что делать с типичными проблемами производительности и наблюдаемости, когда данные собираются из разных источников.

«Talk is cheap. Show me the code.»

Недавно мне в руки попала книга «Искусство неизменяемой архитектуры: теория и практика управления данными в распределенных системах». В ней описаны довольно радикальные, но логичные подходы к проектированию: полный отказ от UPDATE и DELETE в пользу INSERT, идентификация сущностей через хеш-суммы и построение распределенных систем без боли.

Чтобы не быть голословным и проверить, работают ли эти концепции в реальном коде, а не только в теории, я написал небольшой тестовый проект. Это не продакшен-решение, а скорее полигон для проверки идей.

В этой статье разберем, как выглядит REST-сервис на Kotlin + Spring Boot, живущий по законам неизменяемости, и к каким результатам это привело.

Почему Dispatchers.IO + Hikari + чуть-чуть лагов БД = каскадная деградация всего сервиса, и как bulkhead-паттерн в одну строку это лечит.

Всем привет! Меня зовут Михаил, я главный эксперт в ОТП Банке.

Думаю, многие из вас сталкивались с легаси, которое нужно дорабатывать и оптимизировать. Сегодня хочу поделиться реальным кейсом как мы ускорили отправку данных в смежную систему.

Разберем всё по шагам, с замерами производительности. Поехали!

Интеграционные тесты зелёные, а после деплоя внезапно «пустые списки» и null в критичных полях — типичный сценарий для микросервисов. В этой статье разберём, как контрактное тестирование с Pact на Kotlin позволяет ловить такие расхождения заранее: от написания первого контракта до его проверки в CI/CD. На практике посмотрим, где подход даёт реальную пользу и какие ошибки чаще всего обесценивают тесты.

"Скоро сказка сказывается, да не скоро дело делается" - говорится в народной пословице. Вот и мы решили не спешить со второй частью статьи по Junit 5 Extensions, а подойти к ней более основательно! Статья будет полезна QA-автоматизаторам, которые хотят глубже понимать работу с расширениями и выжать чуть больше из связки Kotlin + Junit5. Мы пройдем путь от простой реализации condition-выполнения тестов и источников данных для параметризованных тестов до реализации расширения Микро-DI с рекурсивной инъекцией зависимостей.

Как и в прошлой статье, сделаем акцент на практической части реализации расширений для JUnit 5. В качестве языка - Kotlin. Поэтому, достаем бутерброды, наливаем пиво кофе и приступаем!

GitHub, GitLab или Bitbucket — куда податься начинающему разработчику в 2026? Казалось бы, какая разница — Git везде одинаковый. Но когда дело доходит до первого пет-проекта, портфолио или стартапа на троих, выбор платформы решает всё: от скорости сборки до шансов быть замеченным рекрутером.

В этой статье — сравнение лимитов, цен и скрытых фич. Разберём реальные сценарии, таблицу с актуальными данными на апрель 2026.

Что делать, если синхронные REST-вызовы превращают ваши микросервисы в карточный домик? Пора вспомнить проверенные временем паттерны обмена сообщениями. В этой статье разбираем архитектуру Pipes and Filters, Content-Based Router и Idempotent Receiver — те самые кирпичики, на которых держатся надёжные системы. Схемы, best practices для проектирования устойчивых интеграций для Enterprise-разработки.

Почему «собрать требования» невозможно, а итеративный подход — единственный рабочий вариант и чем Agile-требования на самом деле отличаются от классических.

А также:
▫️ Почему фраза «создайте мне систему» — это красный флаг.
▫️ Как постепенное уточнение спасает от «аналитического паралича» и переписывания кода.
▫️ User Story vs Use Case: в чём настоящая разница и что выбрать.
▫️ Схемы итеративного процесса и ролей в Agile-проекте.