Kotlin *

В парадигме ООП объекты взаимодействуют друг с другом. Первоначальная идея такого взаимодействия, впервые появившаяся в языке Smalltalk, заключалась в том, что объект A отправлял сообщение объекту B. В языках, разработанных позднее, используется вызов методов. В обоих случаях возникает один и тот же вопрос: как объект ссылается на другие объекты, чтобы достичь желаемых результатов?

В этой статье я рассматриваю проблему передачи зависимостей объекту. Я рассмотрю несколько вариантов и проанализирую их преимущества и недостатки.

Привет! Меня зовут Бромбин Андрей. В этой статье мы рассмотрим порождающие паттерны ООП. Обсудим, что такое хороший дизайн и почему не стоит начинать всё с нуля каждый раз, когда перед нами новая задача. Также разберёмся, где эти паттерны действительно помогают и какую пользу несут — всё это с наглядными примерами на Java, приближёнными к реальным.

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

Когда только начинаешь разрабатывать под Android, самые неприятные баги появляются не из-за опечаток, а из-за систематических ошибок. Хардкод строк и цветов, корутины, которые живут сами по себе, попытки писать Compose по старинке, как старые view — всё это превращается в технический долг, который мешает развивать продукт. 

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

Команда Spring официально представила поддержку Jackson 3 — одного из крупнейших обновлений в экосистеме JSON для JVM. Уже начиная с Spring Boot 4 и Spring Framework 7, Jackson 3 становится версией по умолчанию, а Jackson 2 помечается как deprecated. В новом переводе от команды Spring АйО поговорим про нововведения — улучшенную безопасность, переход к JsonMapper, отказ от MappingJacksonValue, поддержку новых API и настройку через builder-интерфейсы.

Мир программирования разнообразен, и новичкам сложно выбрать первый язык. Важно понять свои цели и предпочтения, чтобы сделать правильный выбор и уверенно начать.

Сложность языка зависит не только от его особенностей, но и от вашего опыта и готовности разбираться в материалах. Объективного критерия нет.

Часто сложность связывают с уровнем языка: низкоуровневые ближе к машинному коду и требуют работы с памятью и процессором, что сложнее, но даёт больше контроля. Высокоуровневые проще в использовании благодаря большим стандартным библиотекам и готовым решениям. Однако эта классификация не всегда однозначна и вызывает споры.

Как превратить UI Kit из дизайнерского артефакта в живую систему, где обновление стиля в Figma автоматически обновляет код на Android.

В статье — наш путь от ручного копирования палитр до генерации типобезопасных токенов через KotlinPoet, Gradle-плагины и Figma JSON.

Расскажу, как бизнес получает скорость и консистентность, как темная тема перестаёт быть болью, и почему iOS может безболезненно присоединиться к этой архитектуре.

ИИ в разработке уже не новость, а обыденность. На этом фоне набирает обороты другая тенденция — запускать модели локально. Причины понятны: приватность кода, работа без интернета, предсказуемая задержка и никакого вендор-лок. Вы контролируете, какая модель у вас крутится, какие данные она видит и что именно отправляется «наружу» (спойлер: ничего).

Обратная сторона тоже есть. Большие модели прожорливы: им нужны CPU/GPU, память.. Настройка окружения, версии — всё это ложится на вас. Но хорошая новость в том, что для задач автокомплишена не всегда нужен «монстр» на десятки миллиардов параметров. В связи с этим появились легковесные модели, которые шустро работают на обычном рабочем ноутбуке и при этом прекрасно справляются с рутиной в IDE.

В этом гайде от команды Spring АйО вы узнаете, как настроить локальную LLM для вашей IDE, будь то IntelliJ IDEA или OpenIDE. Я буду использовать последнюю.

Протокол Model Context Protocol (MCP) стремительно развивается, и вопросы его безопасности становятся всё актуальнее. Чтобы упростить реализацию защиты MCP-серверов в проектах на Spring AI, был запущен инкубационный проект spring-ai-community/mcp-security. В новом переводе от команды Spring АйО рассмотрим, как защитить MCP-сервер с помощью OAuth2 или API-ключей, а также как развернуть собственный MCP-совместимый Spring Authorization Server.

Привет! Меня зовут Бромбин Андрей. За последние годы у меня накопилось достаточно материалов, практик и ошибок — иногда красивых, но всё же ошибок. Этого хватило, чтобы собрать маршрут до грейда Middle.

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

Признаться, честно: тут и для меня нашлось, что подтянуть.

Спустя восемь лет после JUnit 5 выходит новая версия популярного фреймворка. JUnit 6 — это не просто обновление, а переход к современной экосистеме Java и Kotlin. В новом переводе от команды Spring АйО узнаем, что новая версия требует Java 17+, унифицирует версии компонентов, удаляет deprecated API и внедряет поддержку JSpecify для строгого null-safety.

Kick (Kotlin Inspection & Control Kit) – это кроссплатформенный модульный набор инструментов отладки, встроенный прямо в приложение. Он позволяет отображать нужные переменные в плавающем окне, инспектировать логи, сетевой трафик, базы данных SQLite/Room, файловую систему и т.д. Kick фактически заменяет множество разрозненных утилит единым решением: больше не нужно переключаться между разными программами или консолью – все необходимые средства собраны в одном интерфейсе. Это снижает сложность диагностики: тестировщик получает полный обзор состояния приложения на Android, iOS и Desktop из одного окна.

Вот и время для заключительной статьи этого цикла. В предыдущих статьях мы рассмотрели нашу мотивацию, всю техническую информацию и поделились инсайтами при создании масштабируемого бизнес-решения в виде кроссплатформенного SDK. В этой небольшой статье хотелось уделить внимание иным аспектам, таким как адаптация процессов команды KMP и смежных команд, которые являются заказчиками, немного поговорить про подходы к тестированию и контролю качества, CI/CD и т.д.

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

В предыдущих статьях мы рассматривали технические и архитектурные аспекты при создании Kotlin Multiplatform SDK, но немаловажной частью остается работа с UI и ресурсами в таком SDK, особенно если он поставляется сразу в несколько продуктов.

Да, в Compose Multiplatform есть базовая работа с ресурсами: можно работать со строками, картинками и файлами по аналогии с Android проектами, однако что делать, когда для каждого продукта под одним и тем же ключом локализации должна срываться своя строка? В этой статье мы поделимся своим подходом и инсайтами.

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

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

Эта статья будет особенно полезна тем, кто хочет понять, как на практике реализовать feature-first подход в KMP проекте, как правильно организовать DI, навигацию и работу с ресурсами в многомодульной архитектуре.

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

В прошлой статье было много текста о том, почему мы стали смотреть в сторону кроссплатформенной разработки и почему мы в 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 занимаюсь мобилками уже более десяти лет, и в этой статье я поделюсь с вами нашей внутренней кухней: как мы ищем инженерные решения, какого класса задачи мы решаем. Хочу поделиться нашей новой разработкой, которая, как мне кажется, может быть полезна сообществу.