Kotlin *

Эта статья — про то, что реально изменилось, и в каком порядке я бы рекомендовал это
трогать. Основано на диффе между (3.3.0) и (8.6.2).

Сегодня я хочу вам рассказать интересную историю из своей жизни про аутстафф. Когда я только начинал карьеру, я попал на стажировку в одну аутстафф-компанию. Проходил я ее 3 месяца, и после успешного завершения спустя месяц попал на проект... мидлом с 4 годами опыта.

Эта статья - про ад и слезы. Про реальный опыт.

Сейчас есть люди, которые без опыта ставят себе 3-4 года и идут покорять горы, думая, что все это очень легко. Конечно, в мое время еще не было ChatGPT, AI-агентов и всего такого (говорю прям как дед), было сложнее. Но дело не в инструментах, а в желании и стремлении. А еще в умении не сломаться, когда на тебя орут, ты ничего не понимаешь, а заказчик думает, что ты мидл с 4 годами опыта.

Сейчас я расскажу, как я не сломался. Хотя был близко. Очень близко.

Поехали!

Это статья от автора библиотеки, поэтому нейтральным разбор не будет. Но это и не рассказ про
конкретный проект — а разбор задач, на которых, на мой взгляд, Paging 3 начинает буксовать, и
того, как Paginator устроен, чтобы эти задачи
закрывать. KMP-библиотека пагинации для Android, iOS, JVM и Desktop. Ниже — почему она появилась
именно как отдельная библиотека, а не как fork или обёртка над Paging 3.

ИИ-агенты пишут код быстрее человека, но кто поручится, что они не устроят cascading failure? Разберем, как в реальном проекте совместить инженерный опыт, архитектурные шаблоны и автономных агентов, чтобы получить работающий функциональный узел, а не груду классов-переростков. Вы увидите подготовку фундамента, декомпозицию задач, диаграммы и тот самый момент, когда ИИ нужно жёстко одёрнуть.

Меня зовут Максим, я Android-разработчик в команде дизайн-системы «БКС Мир инвестиций». В 2025 году у нас шёл большой редизайн: компонентная библиотека росла, команды подключали новые Compose компоненты, а вместе с этим быстро рос и объём UI-тестов.

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

Эта статья про то, как мы решили задачу через Kotlin IR Compiler Plugin. Снаружи решение выглядит почти незаметно: разработчик ставит одну аннотацию, а на этапе компиляции компонент автоматически получает стабильный testTag и тестовые semantics, собранные из его state. В результате у команды стало меньше бойлерплейта в компонентах, меньше риска рассинхронизации между state и тестами, а экранные UI-тесты получили более устойчивый контракт работы с дизайн-системой.

Старый код редко лежит бесплатно. Даже если его никто не вызывает, он попадает в поиск, ревью, 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-паттерн в одну строку это лечит.

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

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

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