Kotlin *

В прошлой статье было много текста о том, почему мы стали смотреть в сторону кроссплатформенной разработки и почему мы в Instories выбрали именно Kotlin Multiplatform (далее — KMP) для своего решения.

Кратко напомним контекст и продукты: Instories — мобильный видеоредактор для маркетологов, SMM‑специалистов и блогеров. Контектс проекта: желание получить ряд SDK (мы называем их Kit‑ами, по сути это разные сборки SDK для разных продуктов, со своими ресурсами, фичами и дизайн системой) для наших уже существующих приложений, которые содержали бы в себе коробочные фичи (и бизнес‑логику, и UI), готовые к подключению, а также были бы легко расширяемыми и переиспользуемыми для разных приложений компании.

Мы выбрали использовать многомодульную архитектуру, чтобы каждая фича была инкапсулирована в своем модуле и не влияла на другие фичи, а также разделили проект на несколько крупных пакетов: kits, core и feature. В данной статье мы рассмотрим первые два пакета с технической точки зрения, а также поделимся причинами и инсайтами для выбранных решений.

Я написал свою альтернативу звонкам в WhatsApp и Telegram — полноценный Android-клиент на WebRTC с поддержкой P2P-аудио и видео, STUN/TURN, сигналингом и собственным UI.

Забудьте про «корпоративные мессенджеры»: проект JOPA Call (👉 «Just One Peer App») работает напрямую, без лишних посредников.

Реализовано: peer-to-peer соединения, fallback через TURN, мини-preview окна камеры, управление потоками и адаптивное видео.

Макс и его «супераппы» могут курить в сторонке — теперь у меня есть свой звонок-клиент, который не зависит от гигантов.

Все уже прекрасно понимают, что Amplicode — неотъемлемая часть тулинга для разработки в OpenIDE, IntelliJ IDEA Community Edition и GigaIDE на Spring Boot. Но стоит установить Amplicode в IntelliJ IDEA Ultimate и ваша, казалось бы, идеальная IDE станет ещё мощнее и удобнее.

В современном мире мобильной разработки скорость вывода новых функций на рынок становится критическим фактором успеха. Особенно это актуально в контексте быстро развивающихся технологий, таких как AI, где промедление может стоить конкурентного преимущества. Рассказывать будем на примере нашего продукта Instories — мобильного видеоредактора для маркетологов, SMM-специалистов и блогеров.

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

Именно с такими вызовами столкнулась наша команда, когда мы начали искать способы оптимизации процесса разработки для iOS и Android платформ.

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

Семплирующие профили не показывают реальное число вызовов и их длительность — а значит, мимо может пролетать важная боль. В новом переводе от команды Spring АйО на примерах показано, как включить инструментальную трассировку в async-profiler и что даёт новая фича latency: от ловли неожиданного System.gc() и источников OutOfMemoryError до точного замера «долгих» вызовов с порогом и разбором в JMC через JFR-события. 

Разбираем накладные расходы, хитрости вроде interval, практичные кейсы (почему ArrayList.contains и AbstractSet.removeAll могут внезапно стать O(N*M) и как это починить), а ещё сравниваем подход async-profiler с нововведениями в рамках JDK 25 (JEP 520), где последний имеет ряд недостатков.

Если вам нужны точные пути выполнения и реальная latency без убийства продакшена — это must-read.

Привет, Хабр! Меня зовут Александр Наумов, я руковожу разработкой мобильной платформы в VK Tech и Mail. В VK занимаюсь мобилками уже более десяти лет, и в этой статье я поделюсь с вами нашей внутренней кухней: как мы ищем инженерные решения, какого класса задачи мы решаем. Хочу поделиться нашей новой разработкой, которая, как мне кажется, может быть полезна сообществу.

В новом переводе от команды Spring АйО команда Spring делает важное объявление — RestTemplate уходит в прошлое. С выходом Spring Framework 7.0 разработчики официально заявляют о плане поэтапного прекращения поддержки одного из самых популярных HTTP-клиентов в экосистеме. Его место занимает RestClient, современный fluent-клиент с расширенными возможностями: API-версионирование, гибкая конфигурация конвертеров, группы HTTP-интерфейсов и новый тестовый клиент RestTestClient.

Кроме того, в Spring Boot 4.0 появятся отдельные стартеры для каждого типа клиента, а RestClient теперь можно удобно переиспользовать с уже существующей инфраструктурой RestTemplate.

Привет, Хабр! Вы когда-нибудь тратили слишком много драгоценного времени на поиск нужного testTag в иерархии Compose Screen? А потом ещё полдня чинили тесты после каждого чиха в UI? Или, может быть, несколько недель ждали, пока в дизайн-систему добавят недостающий тег или семантику, чтобы вообще начать писать свой UI-тест? Если вы хоть на один вопрос ответили «Да», эта статья для вас. Давайте навсегда покончим с этой рутиной и займемся более креативными задачами!

Цель статьи — НЕ представить очередной фреймворк написания UI-тестов для приложений на Android, а упростить их написание с помощью всем знакомого Page Object. Мы будем прятать рутину поиска нужных компонентов и одновременно повышать устойчивость тестов к изменениям. Всё для того, чтобы тесты стали удобнее, надёжнее и проще поддерживались.

Меня зовут Дмитрий Омельченко, я Android-разработчик в Райффайзенбанке. Несколько лет назад мы с командой начали внедрять автоматизацию тестирования в приложение online-банка, и за это реализовали несколько интересных решений, об одном из которых хочу вам рассказать.

Привет, Хаброжители! Хотите писать код один раз и запускать его на Android и iOS, сохранив нативное качество и производительность?

В этой книге вы освоите все шаги разработки полнофункциональных кросс-платформенных приложений с помощью Kotlin Multiplatform SDK — от создания проекта с нуля до миграции существующих нативных решений. Подробные инструкции, архитектурные подходы и реальные примеры помогут уверенно работать с общими модулями, многопоточностью, сетевым слоем, хранением данных и Compose Multiplatform для iOS.

Особое внимание уделено использованию нативного и общего кода в кросс-платформенном приложении, применению expect/actual, тестированию с Kotest, оптимизации разработки с помощью KSP, плагинов компилятора и ИИ-ассистентов. Вы узнаете, как создавать и публиковать собственные KMP-библиотеки, а также получите краткий справочник по Kotlin и Swift, чтобы уверенно ориентироваться в обеих экосистемах.

В Android-проектах Koin остаётся одной из самых популярных DI-библиотек, особенно в MVP/MVI и Compose-приложениях. Она проста в настройке, гибкая и хорошо работает в больших кодовых базах.

Но многие команды, стремясь к модульности и тестопригодности, начинают активно использовать функции loadKoinModules() и unloadKoinModules(). И здесь разработчики часто натыкаются на странную ошибку -_-

Когда вы открываете Netflix, кажется, что всё уже готово — но на самом деле под капотом разворачивается сложная архитектура, которая адаптирует главную страницу в реальном времени. Команда Netflix перешла от статичной генерации страниц к умной системе, основанной на GraphQL-мутaциях, клиентской нормализации кэша и триггерах обновлений. Благодаря этому подходу, пользовательский опыт становится глубоко персонализированным, отзывчивым и масштабируемым.

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

С момента официального объявления Kotlin как предпочтительного языка для Android‑разработки в 2017 году язык стремительно завоевал популярность не только в мобильной сфере, но и в автоматизации тестирования.

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

Shenandoah — это высокопроизводительный сборщик мусора с низкими задержками, разработанный компанией Red Hat и впервые внедрённый в OpenJDK. Он был создан с целью минимизировать задержки на протяжении работы приложения, что особенно важно для приложений с высокими требованиями к производительности и отзывчивости. В новом переводе от команды Spring АйО рассмотрим основные особенности Shenandoah, его работу, настройку и примеры использования.

В новом переводе от команды Spring АйО рассказывается, как сократить время разогрева JVM с помощью ahead-of-time компиляции (в рамках Project Leyden), а также объясняется, почему традиционные GC-барьеры мешают гибкому выбору сборщика мусора.

Статья содержит интересное решение — GC-независимые барьеры загрузки, которые можно «пропатчить» в рантайме под конкретный GC, обеспечивая совместимость без переписывания кода.

Всем привет! На связи Дима Котиков, ведущий Android-разработчик в Т-Банке. Я все еще люблю разбираться в технологиях, разрабатывать под Android и KMP и пить латте на фундучном молоке :)

Расскажу, как можно шарить File Templates для своей команды, чтобы облегчить жизнь другим и сэкономить немного времени. Причем коллегам ничего самостоятельно не придется настраивать: подтянутый из git-а репозиторий с кодом все сделает сам. Эта статья — бонус к трем предыдущим, в которых я рассказывал, как уменьшить написание boilerplate-кода. Ссылки на них оставлю в конце статьи.

DocxKtm — это Kotlin DSL-обёртка над docx4j для автоматизации Word-документов.

Умеет: создавать документы «с нуля», вставлять текст, картинки, таблицы, колонтитулы, нумерацию страниц.

Поддерживает шаблоны с подстановками и логикой (через встроенный движок на базе MVEL2). По функциональности близко к Python-библиотеке docxtpl, но на JVM и с выразительностью Kotlin.

Если вам надоело вручную генерировать документы в Word — это может сэкономить кучу времени и нервов.

Внутри статьи — моя история создания этой библиотеки.

В новом переводе от команды Spring АйО рассматривается новое крупное обновление Gradle, которое приносит с собой переход на Kotlin 2 и Groovy 4, а также делает кеш конфигурации рекомендуемым режимом сборки. В версии 9 улучшена система отчётности об ошибках, ускорена компиляция Kotlin DSL, добавлена интеграция с Jspecify, снижено потребление памяти и оптимизирована работа с IDE.

Всем привет, на связи команда Explyt. Как известно наша компания предоставляет целую экосистему плагинов для IDEA: это и плагин для поддержки Spring, а также Explyt плагин для написания кода, генерации тестов и интеграции с AI. И нам пришла в голову идея - а почему бы не расширить функциональность Spring плагина с помощью AI ассистента, который есть в Explyt. И если вы используете оба наши плагина, то у вас появятся дополнительные возможности для Spring, позволяющие достаточно хорошо решать типовые задачи, которые возникают в процессе работы, с помощью AI, о которых мы подробно расскажем далее.

PostgreSQL 18 вот-вот выйдет, и это не просто минорное обновление, а настоящий прорыв для разработчиков и администраторов БД. В новом переводе от команды Spring АйО рассмотрим ключевые новинки — асинхронный I/O для ускорения чтения, поддержка UUID версии 7 с улучшенной сортировкой, skip scans в B-tree индексах, виртуальные вычисляемые столбцы и даже OAUTH 2.0 для аутентификации. Всё это делает Postgres ещё более быстрым, гибким и современным.

Представьте себе: вы отлаживаете новый баг в сложном многослойном приложении (например, на Spring). Чтобы воспроизвести проблему, приходится взаимодействовать со всей системой end-to-end: отправлять запрос на эндпоинт или что-то кликать в UI. Юнит-теста, который бы изолировал нежелательное поведение до уровня злополучного сервиса или утилиты, нет. А хотелось бы, чтобы он был: во-первых, воспроизводить баг было бы проще (особенно если UI кликает QA, а не вы), а во-вторых, его потом можно было бы легко превратить в регрессионный и улучшить стабильность системы.

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

Сегодня расскажу о пройденном исследовательском пути, о том, как попробовать нашу экспериментальную фичу в плагине для IntelliJ IDEA, и о том, что у неё под капотом (спойлер: не только LLM).