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

У меня это произошло со скромным всплывающим окном внутри WebView.

Задача была максимально скучной: на экране с WebView пользователь нажимает кнопку “Exit”, а веб-страница показывает попап подтверждения. На старом коде — всё идеально. На браузере — идеально. На новом инфраструктурном слое WebView — попап появляется на миг и тут же закрывается сам, как будто кто-то тайно играет в “крестики” за пользователя.

Никаких ошибок. Никаких исключений.

Просто “блип”… и пустота.

То самое чувство, когда ты нажимаешь кнопку, а мир делает вид, что “ничего не было”.

И это — пролог к истории о том, как два дня моей жизни сгорели на алтаре WebView.

В какой‑то момент простого дашборда уже не хватает. Хочется, чтобы метрики не просто «где‑то красиво лежали», а сами приходили и били в лицо, когда что‑то пошло не так.

Разберёмся с Grafana Unified Alerting, expressions, темплейтами уведомлений и типичными ошибками, которые легко словить, если вы впервые лезете в алерты.

Как приручить WebView: пререндерим экраны заранее (AndroidX WebKit prerenderUrlAsync), меряем не ощущения, а TTVR — время до визуальной готовности — лёгким offscreen-детектором, шлём метрики в Grafana. Внутри — когда и что пререндерить, таймауты/отмена, cookie-политика и готовые сниппеты. На проде — до 2.5× быстрее и меньше «белых экранов».

ANR — это не просто “зависание”, а молчаливый краш, который напрямую бьёт по удержанию пользователей. В статье разбираю, как работает механизм ANR, какие ошибки его вызывают, как анализировать traces.txt, какие библиотеки помогают отслеживать блокировки (ANR-WatchDog, ANR-Spy, Firebase Crashlytics), и как построить процессы, чтобы QA-команда научилась ловить их ещё до релиза.

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

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

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

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

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

Почему 80% бюджета музыкантов уходит в никуда? Агентства, блогеры и менеджеры захлебываются в рутине. Мы показываем, как IWBL меняет правила игры и делает рекламу музыки прозрачной и честной.

Как продвигать треки в TikTok без «залпов» бюджета: форматы, выбор креаторов, волны seed → mid → amplification и метрики. Пошагово для артистов и лейблов.

Рассказываем, как из боли в музыкальном маркетинге родилась IWBL — платформа для рекламы треков через TikTok без лички, скама и таблиц.

Автор: разработчик и фаундер с опытом запуска стартапов в сферах туризма, HR tech, а сейчас — в музыкальной индустрии.

По образованию — Data Scientist, по призванию — Android-разработчик и продукт-менеджер.

Работал в крупных продуктах вроде X5 и Uzum, где впервые познакомился с Kotlin Multiplatform Mobile (KMM). Когда настал момент создавать прототип для своего музыкального стартапа, выбор был очевиден: я уже знал Kotlin, имел боевой опыт с KMM — и хотел быстро двигаться без лишних компромиссов.

Но KMM — не единственный путь.

На столе были и Flutter, и React Native, и даже классическая нативка.

В этой статье я расскажу:

Автор: Android-разработчик с 7+ годами опыта, знающий толк в FrameLayout, merge, include, RecyclerView, а теперь и Modifier.padding.

Jetpack Compose — не просто «альтернатива XML». Это совершенно другой парадигмальный сдвиг в том, как Android отрисовывает и управляет UI. Но чтобы по‑настоящему понять, чем Compose отличается от привычного XML, давайте посмотрим, что происходит под капотом в каждом случае.

A/B-тестирование — это не только инструмент для продуктовых команд. Это суперспособность и для Android-разработчиков. В этой статье рассказываю, как опытные инженеры могут проектировать, реализовывать и грамотно завершать эксперименты, которые действительно влияют на продукт, не захламляя кодовую базу. От Firebase Remote Config до паттернов чистой архитектуры — всё, чтобы делать более умные и осознанные Android-приложения.

🚀 Почему A/B-тестирование важно именно для разработчиков

По сути, A/B-тест — это сравнение двух (или более) вариантов реализации, чтобы понять, какой из них работает лучше. В Android это может быть:

• сравнение разных UI-дизайнов,

• тестирование разных онбордингов,

• проверка производительности оптимизаций,

• сравнение реализаций фич (например, RecyclerView против LazyColumn в Compose).

Вместо «выпустим и посмотрим» — мы выпускаем, измеряем и улучшаем.

🧩 Как встроить A/B-тесты в кодовую базу

Хороший A/B-тест начинается с гипотезы и метрик успеха. Но в инженерном мире нужно думать ещё и о поддержке, масштабировании и разделении логики.

Правильный процесс ревью кода — это процесс итеративного улучшения продукты и контроля.
Контроля того, что:
1) Cоблюдены общие правила и договорённости
2) Решение не избыточное и масштабируемое.
3) Решение покрывает все критерии приемки указанные в описании к задаче

Для начала будет хорошо задать в своей команды такие вопросы:
1) Сколько времени занимает ревью кода для средней (сферической в вакууме) задачи
2) Как вы минимизируете время ревью?
3) Как вы определяете, что ревью конкретной задачи сделано правильно?