Kotlin *

Когда я начал делать кредитный трекер, казалось, что финансовая математика — самая простая часть проекта. Формула аннуитета есть в любом учебнике, 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-проекте.

Когда я впервые всерьёз сел писать AGSL под Android, ощущение было очень странное. С одной стороны - современный графический конвейер, RuntimeShader, RenderEffect, красивые эффекты и весь этот техно-киберпанк. С другой - шейдерный код живёт внутри строковых литералов, uniform-ы приходится объявлять и привязывать вручную, а отладка периодически начинается с философского вопроса: «в какой именно строке я сейчас всё сломал?»

В какой-то момент я поймал очень «кин-дза-дзовское» настроение: вроде перед тобой космическая технология, а инструменты ощущаются так, будто тебе выдали гравицапу без инструкции и сказали: «ну ты это... лети». Можно, конечно. Но хочется, чтобы летели не только самые упорные.

Собственно, так и появился RedByteFX. Я сделал его не только ради собственного удобства. Мне хотелось решить ещё одну задачу: сделать AGSL более массовой и понятной технологией для Android-разработчиков. Потому что в нативном виде AGSL мощный, но психологически для многих выглядит как «не трогай, это на Новый год». А мне хотелось, чтобы к шейдерам можно было подойти без дрожи в коленях и без ощущения, что сейчас придётся разговаривать с господином ПЖ на древнем пацакском наречии.

Последние годы FeignClient и RestTemplate были де-факто стандартом для вызова внешних API в Spring. Но теперь появился нативный Http Interface Client — и я решил проверить, можно ли им заменить Feign без потери удобства.

В новом переводе от команды Spring АйО рассмотрим утечки памяти в Java.

Не секрет, что GC освобождает только недостижимые объекты. Утечка в Java начинается там, где объект уже не нужен, но на него все еще есть цепочка ссылок от живого потока.

Симптомы обычно одинаковые: куча растет, GC срабатывает чаще, паузы увеличиваются, финал - java.lang.OutOfMemoryError: Java heap space.

В целом вывод такой, что нужно смотреть график heap в VisualVM/JVisualVM/JConsole, снимать heap dump (jmap), в Eclipse MAT запускать Leak Suspects и проверять цепочки удерживающих ссылок.

Каждое Android-приложение, которое хранит данные на устройстве, рано или поздно сталкивается с базой данных. Встроенная SQLite — надёжное решение, но работа с ней через SQLiteOpenHelper требует написания SQL-запросов вручную, преобразования курсоров в объекты и постоянного контроля за закрытием соединений. Это отнимает время и довольно часто вызывает ошибки.

Google предложил библиотеку Room, которая является оберткой над SQLite и реализует паттерн ORM (Object-Relational Mapping). В этой статье мы на конкретном примере сравним, как выглядят операции добавления и чтения данных на чистом SQLite и на Room. Вы увидите, почему Room избавляет от «шаблонного кода» и делает работу с БД простой и безопасной.

Знакомо, правда? Мечтаешь создать невозможное: уникальное, новое, то, чего ещё нет на рынке. И при этом чтобы это было твоё «детище», твой продукт, которым ты будешь гордиться и который станет по-настоящему стоящим и полезным для мира.

Думаешь, анализируешь, ищешь вариант, генерируешь идеи… Но всё не то. И каждый раз сталкиваешься с тем, что это уже кто-то реализовал. Да ещё и так круто, что подступиться страшно.

В этой статье я расскажу о проектировании мобильного приложения "Balance" по методу колеса жизненного баланса — от выбора идеи до кликабельных прототипов и тестирования.

Изучая UI/UX-дизайн, маркетинг и рынок в целом, я пришла к главному выводу: уникальность заключается не в том, чтобы придумать то, чего никто никогда не делал, а в том, чтобы сделать так, как никто другой не делает: удобно, красиво, с душой. И для этого не нужна команда дизайнеров. Только вы, ваше желание и правильные шаги.

Продолжаем серию «Kotlin для новичков»!

В прошлых статьях мы настроили IDE, разобрались с переменными и типами данных, научились управлять потоком программы через условия и циклы. Пришло время сделать следующий шаг — освоить функции.

В этом туториале вы узнаете:

▪️ Как объявлять функции и чем это отличается от Java.
▪️ Что такое именованные аргументы и значения по умолчанию (и почему это круто).
▪️ Как работает стек вызовов и области видимости.
▪️ Главные best practices, которые используют в разработке.