Kotlin *

Kotlin Coroutines - разбираемся с диспатчерами и обработкой ошибок, а так же обсудим некоторые важные нюансы возникающие при работе c корутинами

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

Телефон на руле — самая дорогая и хрупкая деталь. Руль живёт ударами, падениями, судьба вашего флагмана за пару тысяч баксов решается дешёвым зажимом, который ослаб на кочках. Даже без драматичного «вылетел на асфальт» хватает постоянного дребезга: стекло и корпус после пары сезонов уже не скажут вам спасибо.

А если повезёт не ушатать смартфон, то со временем неизбежно деградирует оптическая стабилизация. Мото и жёсткий велоруль дают вибрацию, под которую модуль камеры просто не проектировали. Со временем OIS “устаёт”: люфт, стук при встряхивании, мыло на видео. Держалка с амортизацией смягчает, но спектр двигателя и дороги никуда не девается.

Ну и в довершение — привычный бытовой ад: блики от глянца, неизбежно выгорает дисплей, батарея погибает.

Мне нужно было другое. Не смартфон на траверсе, а маленький экран в периферийном зрении: куда свернуть и через сколько метров. Телефон пусть лежит в кармане или сумке, а за навигацию отвечает штука, которую не жалко и в которой нет OIS за полцены флагмана.

И ещё одно, для меня принципиальное: я не хотел менять навигатор. Я езжу в 2ГИС (дальше добавлю Яндекс). Пробки, избранное, привычный поиск — всё уже есть. Идея «скачай наше отдельное приложение, там свои карты» меня бесит. Значит, нужен мост: привычный навигатор на телефоне → крошечный HUD на руле.

Друг в другом городе, вы оба хотите досмотреть сезон. Обычно это заканчивается одним из двух сценариев. Либо демонстрация экрана в Discord: картинка мылится, звук сжат до стерео, а у второго зрителя всё безбожно фризит. Либо обратный отсчёт «на счёт три жмём плей», после чего через десять минут выясняется, что у одного диалог уже на пару секунд впереди.

Я сделал совместный просмотр в своём self-hosted медиацентре Avalon MediaCard. У каждого участника идёт оригинальный поток без пережатия напрямую с сервера, а бэкенд следит только за тем, чтобы все зрители находились ровно в одной точке фильма. А если это сериал, комната никуда не исчезает: она сохраняется вместе с текущей серией и секундой, чтобы в следующий раз можно было продолжить ровно с того же места.

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

Иногда от модели нужен не красивый ответ, а быстрое решение. Пропустить запрос или заблокировать, выбрать маршрут, оценить результат, отфильтровать документы для RAG.

Для этого появился Spring AI TypeSafe. Проект интегрирует Jev API, который отвечает на типизированные вопросы числовыми значениями и не генерирует текст.

Привет! Меня зовут Ирина, я Android-разработчик в SimbirSoft. Хочу поделиться с вами опытом разработки новых функций и рефакторинга существующих модулей Android-приложения компании «Юрент» — одного из крупнейших в России сервисов аренды электросамокатов (кикшеринга).

Добавление нового сценария (фичи) в мобильное приложение без создания технического долга — это искусство баланса между скоростью выпуска и архитектурной чистотой. С одной стороны, менеджмент требует выпустить новую фичу «еще вчера». С другой –  разработчики знают: любой новый экран или бизнес-логика, втиснутые в устаревший код без рефакторинга, завтра превратятся в источник багов и архитектурный хаос. Конечно, совсем без какого-либо техдолга вести разработку не получится, это утопия, но все-таки можно постараться свести его к управляемому техническому долгу. В нашей практике мы выделяем для этого четкий бюджет времени в спринте, чтобы новый код не превратился в «архитектурный бетон», который никто никогда не тронет. В этой статье я покажу, каких принципов разработки мы придерживались, чтобы избегать неуправляемого технического долга, и продемонстрирую эти принципы на примере задачи по добавлению промокнопки на главный экран приложения.

Материал в первую очередь ориентирован на специалистов Mobile Team Lead/ Tech Lead, так как именно им предстоит принимать архитектурные решения и защищать их перед менеджментом.

Это наш опыт миграции со Spring Boot 3.5.12 и Spring Cloud 2025.0.1 на Boot 4.0.6 и Spring Cloud 2025.1.x в большом коммерческом проекте, дополненный ссылками на официальные изменения Boot 4. В спорных местах ссылки стоят прямо в тексте, а в конце есть раздел «Источники».

У меня есть коллекция музыки, которой нет ни в одном стриминге: FLAC, японские альбомы, редкие релизы. Слушать её хотелось так же удобно, как Spotify, с телефона и компьютера, с текстами и итогами года. Готовые решения закрывали задачу по кусочкам, поэтому я написал своё: Nami — плеер для Android, Windows и Linux и собственный сервер на Rust. Внутри: синхронизация между устройствами через одну SQL‑таблицу вместо девяти, караоке‑тексты с выравниванием по словам нейросетью прямо на телефоне, фуригана и ромадзи для японских песен, bit‑perfect‑вывод на USB‑ЦАП и сервер, который занимает 69 МБ памяти.

Привет! Меня зовут Александр Каненков, я backend-разработчик в компании Домклик.

После перевода сервиса со второго Spring Boot на третий (а у кого-то уже и на четвёртый) мы с командой заметили следующую картину: HTTP-запрос журналируется с traceId, цепочка собирается в трейсе, но стоит сработать задаче Quartz — в журналах worker-потока гордо красуется [NoTrace, NoSpan]. Задача исполняется «в никуда» — без единого идентификатора, вне какого-либо трейса, и связать её с запросом, который её запланировал, невозможно.

Давайте разберём по шагам, почему это случилось и как починить так, чтобы работало и с RAM (in-memory), и с JDBC job store.

Мой телесуфлёр для Android называется Суфлёр. Он распознаёт речь на телефоне и прокручивает текст по голосу поверх Instagram, TikTok или системной камеры. Во время записи видео Android отдаёт микрофон камере, и Суфлёр получает звук параллельно с ней через службу специальных возможностей. Такое исключение описано в разделе 5.4.5 Android CDD. Место в сценарии Суфлёр находит, выравнивая восемь последних распознанных слов по всему тексту. Ещё в статье есть правила, которые понадобились трекеру для английского языка.

Как силами двух разработчиков создать мессенджер под шесть платформ на Compose Multiplatform и Go. Рассказываем об оптимизации бандла до 10 МБ, разработке собственного SFU на pion/webrtc и синхронизации сообщений на слабых сетях.

🔥 Выходит Java 27!

• Compact Object Headers включаются по умолчанию. Метаданные каждого объекта становятся компактнее, что может уменьшить потребление heap примерно на 20% и снизить нагрузку на GC. Раньше для этого требовался флаг -XX:+UseCompactObjectHeaders.

• G1 становится сборщиком мусора по умолчанию во всех окружениях. Раньше JVM могла выбирать Serial GC на машинах и в контейнерах с небольшим количеством ресурсов. Поэтому после обновления стоит перепроверить память, паузы и CPU именно на маленьких инстансах.

• JFR начинает автоматически скрывать чувствительные данные. Пароли, токены, API-ключи и секреты в аргументах JVM, переменных окружения и системных свойствах больше не должны случайно попадать в запись Flight Recorder.

Покупал GoIP, чтобы разобраться с телефонией на своём железе, а в итоге написал три проекта: сервер для GSM-шлюзов, клиент к нему из одной кодовой базы на Android, iOS, десктоп и браузер, и шлюз, через который внутренние номера FreePBX звонят обычными звонками Telegram

Привет, Хабр!

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

Так появилась идея заранее просчитать ряд систем, сохранить результаты и потом эти результаты выдавать из базы данных. И я так и поступил. Выбрал температурный диапазон пошире (до 3000 К), 2 базы данных веществ (с газами и без).

Сначала запустил программу на перебор по парам всех возможных элементов из таблицы Менделеева, и для каждой пары запускал расчёт их взаимодействий. Расчёт длился около суток.

После я проделал то же самое с 3мя элементами. Расчет занял около недели.

Четыре элемента рассчитывались около месяца.

Прикинув, сколько займёт расчёт 5ти элементов, я решил закончить на 4х.

После этого сделал бэкенд на сайт по извлечению соответствующего результата.

С одной стороны этот функционал бесплатно закрывает множество основных потребностей, с другой стороны рекламирует более сложные расчёты.

И конечно же мне после этого захотелось сделать соответствующее мобильное приложение. Быстро сделал WebView обёртку на сайт. Отправил в магазин Гугл – и получил не только отказ, но и удаление всех своих предыдущих приложений.

 Долго пытался зарегистрироваться на RuStore. И потом уже быстро получил отказ, мол WebView у нас не катируются.

Полез разбираться – и оказалось, что с того момента, как я написал последнее нормальное приложение, много чего поменялось. Придётся изучить и Kotlin, и много чего ещё. Либо писать с ИИ. Поэтому мысль о приложении отложил на будущее.

Каждый Java разработчик в том или ином виде сталкивается с проблемой выбора инструментария для работы с БД. Если говорить про ORM-ы, то выбор у нас невелик: Spring Data JDBC или Hibernate. И тут часто возникает набор вопросов:

- Когда выбирать Hibernate, а когда Spring Data JDBC?

- Как дизайнить Aggregate-ы в Spring Data JDBC?

- Что из DDD просто теория, а что реально важно на практике? и т.д.

Мы оттекстовали доклад Михаила Поливаха с прошедшего Spring I/O Barcelona. В докладе обсуждаются все эти и многие другие вопросы, с которыми часто сталкиваются люди при проектировании доменной модели в целом.

Будет полезно, если присматриваетесь к Spring Data JDBC или уже используете его и накопили вопросы.

⚠️ А если хочется глубже погрузиться в разработку реальных приложений, у нас в Академии скоро стартует новый поток «Java в продакшене». 

В новом переводе от команды Spring АйО на простом Java-примере показываем:

– как работает мутационное тестирование с Pitest;  
– почему 100% покрытия недостаточно;  
– откуда берутся выжившие мутанты;  
– почему не стоит прогонять MT по всему проекту;  
– и в каких случаях этот подход действительно окупается.

А ещё как поручить настройку и запуск Pitest AI-агенту с помощью готового skill.

Я пользовался для трекинга фильмов и сериалов Кинопоиском, Trakt, Letterboxd, IMDb, TMDB, MyShows — и по-честному ни один из них не бесил настолько, чтобы стать поводом всё бросить и писать своё. У каждого свои шероховатости: у Кинопоиска в какой-то момент стало слишком много рекламы, а заодно убрали подробную статистику по жанрам и странам, которая раньше была. У Trakt банально медленный сайт, лимит в 1000 фильмов в списке и ограниченные возможности с созданием списков. У IMDb так и не появилось нормального трекинга сериалов. TMDB — просто не нравится интерфейс. С Letterboxd — не могу даже сформулировать, почему, просто не зашло. А MyShows,устраивает почти во всём: удобно, есть оповещения о новых сериях, реклама ненавязчивая, лёгкая подписка для поддержки сервиса.

Так в чём тогда была зацепка? Не в том, что существующие сервисы плохие — большинство из них вполне рабочие. А в том, что ни один не даёт того сочетания, которое хотелось: self-host, где данные и инфраструктура твои, а не чужие; стриминг собственного контента внутри того же интерфейса, где ты его трекаешь; и просто инженерный азарт — я долгое время обдумывал архитектуру гибридной SDUI/BDUI на Kotlin, когда сервер стримит слоты на клиент, а клиент рендерит заранее заготовленные UI-элементы, при этом чтобы приложение ощущалось и выглядело как нативное. Это была отдельная задача, которую хотелось решить независимо от недостатков конкурентов.

Клиент — минималистичный интерфейс с трекингом фильмов и сериалов: статусы просмотра, оценки, свои списки.

Если вы хоть раз работали с крупными KMP проектами, то наверняка хотели обратиться к старым добрым гредл флейворам, которые всем так хорошо знакомы по андроид разработке.

Но спустя 5 минут поисков до вас доходит осознание:Gradle Flavor на KMP нет и не планируется, а вместо них нам достается expect/actual, разбивающий код по платформенным сорц сетам

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

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

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

Большинство лаунчеров для Android повторяют одну и ту же концепцию сетки иконок. Чтобы открыть приложение, нужно листать бесконечные рабочие столы и тянуться пальцем до нужной иконки.

Я решил сделать SwipeLauncher — открытый лаунчер с круговым меню, где любое действие или вложенное меню открывается одним свайпом из любой точки экрана.

В этой статье я расскажу, как проект прошел путь от простого прототипа на 4 стороны света до динамической сетки на Jetpack Compose, с какими подводными камнями Android пришлось столкнуться и как устроена математика свайпов под капотом.