Kotlin *

Погряз в боли настройки DI в многомодульных проектах и решил написать собственный велосипед на Kotlin Symbol Processing. Рассказываю, как поэкспериментировал с генерацией кода, победил R8/ProGuard, добавил compile-time валидацию графа и что из этого вообще получилось

Каждый разработчик, работавший с проектом, где одни модели мапятся в другие, знает эту боль: добавил поле в модель и пошёл обновлять десятки мапперов вручную. Переименовал параметр - компилятор взрывается ошибками, и ты снова правишь код руками. Мапперы - это “мёртвая зона”: они пишутся механически, но при этом легко ломаются и не приносят никакой ценности бизнесу. В статье я расскажу о том, как мы от этого ушли и какие результаты получили

Представьте классическую ситуацию: вы запускаете корутину для фоновой задачи (например, сетевого запроса) и хотите подстраховаться от падений. Как бы мы сделали в синхронном коде — обернули бы в стандартный блок try/catch блок кода, в котором может быть ошибка:

Привет, Хабр! (И тебе, 1С-ник, который открыл статью только чтобы убедиться, что пока точно не надо изучать новый продукт. И тебе, питонист, который сейчас будет морщиться. И тебе, мобильный разработчик, который уверен, что без Kotlin/Swift нормальное приложение не родится - держи кружку крепче.)

Эта статья будет посвящена технологии, на которой можно написать своё мобильное приложение за пару дней. И я вам на примере реализованного мною полноценного проекта логистического приложения покажу, что сейчас из себя представляет эта технология на нашей родной КИРИЛЛИЦЕ, и что на ней можно сделать прямо сейчас. И самое главное, как…

Тема 1. Как выглядит Kotlin Coroutine без макияжа

Тема 2. Kotlin suspend функции

Тема 3. Kotlin Coroutine диспетчеры и потоки: где выполняются корутины?

Что будет, если запустить тяжелую фоновую обработку данных, а пользователь закроет экран? Если мы не контролируем этот процесс, потоки продолжат работу, сжигая батарею, процессорное время и создавая утечки памяти.

Для решения этой проблемы в Kotlin применяется концепция Structured Concurrency.

В статье я разберу, как писать тесты, используя Playwright. И покажу все на собственном примере.

Когда наш продукт стал сложным, мы столкнулись с тем, что релизы стали затаскивать на прод баги. Чтобы не “тестировать на пользователях” и минимизировать человеческий фактор, мы решили автоматизировать самые частые пользовательские сценарии, используя Playwright. 

Давайте перейдем к сути и начнем писать тесты на Playwright.

Разбираемся с Kotlin Corouitines - какие идеи заложены и чем отличается CoroutineContext от CoroutineScope

Почему Spring-приложение запускается медленно, и на каком именно этапе оно тупит?

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

Представьте, перед вами задача – после авторизации пользователя навигировать его на главный экран, или показать snackbar, например, об ошибке.

В Android для таких событий есть специальное название – One-Time Events, или же просто Effects – события, которые мы отправляем UI из ViewModel и хотим, чтобы они обработались ровно один раз.
И они отличаются от состояния экрана! Состояние существует всегда, а effect отправляется и обрабатывается единожды; в состоянии существуют данные, с которыми user взаимодействует, или которые повторно могут отображаться на экране, когда как effect — совершенно противоположное.

Моделировать такой паттерн можно несколькими способами: через состояние, SharedFlow или Channel. В этой статье мы разберем на простом примере каждый подход и обсудим минусы и плюсы, а также обсудим лучшее обходное решение!

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

Разбираем типичные ошибки Kotlin‑бэкенда и показываем, как сохранить предсказуемое поведение сервиса.

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

Практически каждый современный AI-агент, будь то Claude Code, Cursor, Codex, Gemini CLI или OpenCode, предлагает один и тот же механизм расширения своих возможностей - напишите Skill, опишите процесс решения задачи, добавьте примеры, подключите документацию и агент начнет выполнять эту работу значительно лучше.

Десятилетиями мы учили разработчиков, что Markdown - это документация. Средство общения между людьми. Формат, который не исполняется и никак не влияет на поведение программы, а затем неожиданно оказалось, что один Markdown-файл способен изменить проект сильнее, чем сотни строк кода и здесь индустрия практически мгновенно наступила на старые грабли.

Приветствуем, Хабр.

Как знают наши постоянные читатели, в последние пару лет мы регулярно заходим на территорию языка Kotlin. Базовой литературы по Kotlin сейчас достаточно, но сегодня мы хотим презентовать вам новинку для настоящих профессионалов — «Асинхронный Kotlin». Книга подготовлена Яной Седовой @Ioanna на основе её собственного курса «Kotlin Coroutines & Flow для Android: от основ до production» размещённого на платформе «Степик». Яна Седова активно работает с этой платформой, вот, что она успела на ней разместить.

Статья настоящий разбор-детектив: почему неблокирующий API может блокироваться, как потерять монитор после деоптимизации JIT, почему try-catch иногда важнее коллбэков, и как решать сложные проблемы новыми концепциями мышления. Приятного чтения!

Недавно я опубликовал в Google Play приложение 99.9% исходного кода которого написано AI. Это не просто "поделка на коленке за выходные": нативное (Kotlin), больше 50 экранов, сложная анимация, мультиязычность, расширяемое.

Этого удалось добиться через очень подробную спецификацию. Каждый экран был отрисован дизайнером, для каждой кнопки есть описание какие API дернуть. Стоило ли оно того? Давайте посмотрим на цифры.

Всем привет! Меня зовут Алексей, я техлид Android-направления в компании Домклик.

Этой статьёй я открываю цикл материалов, в которых будут собраны мысли, советы и инструкции о том, как сделать приложение и процессы его разработки измеримыми, как находить «узкие места», диагностировать проблемы и причины их возникновения, а также фиксировать их наличие. Минимум кода, сложных терминов и «rocket science» — только практический опыт и наработки по различным метрикам.

Несмотря на то, что IntelliJ IDEA уже несколько лет официально недоступна в России, она по-прежнему остаётся одной из самых популярных IDE среди разработчиков. На днях вышла свежая версия 2026.2.

В релиз вошли новые инструменты для работы с ИИ-агентами, изменения в отладчике и автоматизация ряда повседневных операций. Также появилась поддержка Java 27, Kotlin 2.4, TypeScript 7, будущего Gradle 10 и обновления для Spring, Terraform и Docker Compose.

В статье пройдемся по основным изменениям.

Наконец-то неплохо продвинувшись в написании своего мультиплатформенного приложения Modern Money мне понадобилась аутентификация для Kotlin Multiplatform.

Хотелось иметь один API для PIN-кода и биометрии, а под капотом использовать Android Biometric Prompt, Windows Hello, Touch ID.

Так появился Koncierge — набор KMP-модулей biometric, auth и auth-compose

Казалось бы, задача довольно стандартная: объявить expect-класс и написать несколько actual-реализаций. На Android это примерно так и получилось. А вот Windows Hello, JVM-модуль и публикация всех артефактов заставили немного разобраться в том,

В многомодульных Gradle-проектах рано или поздно появляются вспомогательные классы для тестов: фабрики тестовых данных, билдеры, хелперы. Такие классы не относятся ни к продакшн-коду, ни к обычным тестам. Логично было бы переиспользовать их сразу в нескольких модулях, но классическая модель Gradle этого не позволяет: тестовые артефакты одного проекта нельзя просто так подключить как зависимость в другом. 

На самом деле Gradle умеет решать эту задачу из коробки без вспомогательных проектов и хитрых конфигураций. Начиная с версии 5.6, тестовые фикстуры стали в Gradle полноценной сущностью первого класса, и весь этот пласт боли можно убрать буквально несколькими строчками в build.gradle.

Плагин java-test-fixtures заводит в модуле отдельный SourceSet, а другие модули подключают эти классы через лаконичный DSL. При публикации Gradle даже собирает отдельный *-test-fixtures.jar для независимых проектов. В статье на примерах показано, как расшарить тестовые хелперы между модулями, избавиться от дублирования и при этом сохранить чистые архитектурные границы. Если вы устали таскать тестовый код из модуля в модуль, то Вам точно пригодится.

Аннотации в Kotlin — это не только @Deprecated и @Suppress. Разбираемся, где живут SOURCE, BINARY и RUNTIME, чем KSP отличается от kapt, как compiler plugins меняют код и какие практические задачи можно закрыть генерацией: debug menu, удаление экспериментов и каталог performance-метрик.

В первой части мы разобрали философию KMP, обсудили лестницу развития проектов и выяснили, почему не стоит шарить ViewModel. Теперь давайте заглянем в код и поговорим про то, с чем столкнутся разработчики при выполнении ежедневных задач.

Это вторая, практическая, часть из двух. Здесь про то, как организованы слои, какие контракты уходят в Swift, как готовить SKIE, как устроены обработка ошибок и DI, что с модульностью, скоростью сборки и тестами.