Купер.тех

⚽️Выспались и готовы работать — или смотрели вчера ночью футбол? Чемпионат мира в 2026 году получился богатым на яркие моменты, а интернет, как обычно, быстро превратил их в мемы. Мы не смогли пройти мимо и собрали футбольные кадры, которые слишком хорошо описывают корпоративную жизнь.

💭 Лучше спросите Евгения React Native — важный стек для нашей мобильной разработки, а лучший способ поговорить о нём — задать вопросы человеку, который видит и техническую сторону, и продуктовый контекст. Поэтому решили сделать короткий Q&A с Евгением Прокопьевым, руководителем группы мобильной разработки: 🟢Как изменился React Native за последние 2–3 года? Можно с уверенностью сказать, что фреймворк повзрослел: апдейты сейчас проще и чище, если вы уже переехали на новую архитектуру. В комьюнити выделились явные лидеры по разработке самых актуальных пакетов, и они активно их поддерживают. Около года назад React Native завершил переезд на новую архитектуру, и перформанс сильно подрос, особенно на старых девайсах. 🟢Есть технология, за которой ты следишь? Что сейчас must have? В последнее время появляется много интересных решений. Они закрывают разные проблемы, например: • react-native-streamdown — для быстрого рендера MD-формата. Очень актуально в наших реалиях, например для чата с ИИ; • react-native-nano-icons — удобное решение для рендера SVG-иконок. Поддерживается полное API SVG Multicolor; • nitro-modules — их нельзя назвать чем-то новым, но я хочу всех призвать писать нативные модули с помощью этого API. 🟢AI сейчас везде — внедрился ли он и в мобильную разработку? У мобильной разработки есть некоторые ограничения по сравнению с веб-разработкой — например, тестирование вёрстки или целого флоу. Но комьюнити активно развивает это направление. Например, библиотека argent даёт возможность агенту подключаться к девайсу и протыкивать флоу: его можно сохранить в YAML и потом использовать как e2e-тесты, читать логи Metro, профайлить код. Плюс сейчас в библиотеках комьюнити часто можно встретить файлы для LLM, что упрощает интеграцию. В общем, флоу, где ты можешь отдать ссылку на Figma и получить хороший результат, выглядит реальным. 🟢Куда, как ты думаешь, это всё будет развиваться? Как уже говорил, фундамент React Native сейчас стабилен, все критически важные старые проблемы закрыты. По мне, сейчас всё идёт в сторону: • ещё более широкой кроссплатформы: десктоп, HarmonyOS, TV; • упрощения написания под GPU — тут проекты типа TypeGPU и возможность использования Three.js; • API стилизации, которая при этом как будто становится всё более похожей на веб; • Hermes в сторону AoT-компиляции — Hermes V1 здесь пока что только первый шаг; • и, конечно, более глубокой интеграции с ИИ. А если вы тоже работаете с React Native, делитесь в комментариях: что радует, что всё ещё хочется починить и за какими инструментами следите?

📝 Не сошлись в отчётах: как дебажить метрики У отчётов тоже бывают свои «галлюцинации»: метрика называется одинаково, запрос выглядит правильно, формулы проверены, а цифры почему-то не совпадают. Прежде чем превращать такие данные в продуктовые решения и задачи для разработки, нужно понять, где именно они разошлись. Лилия Ивановская, старший продуктовый аналитик в команде, где ищут точки роста бизнеса на основе данных, рассказывает, как быстро дебажить такие расхождения: 1️⃣ Сначала понять, что именно сравниваем В е-grocery легко незаметно запутаться даже в одинаково выглядящих метриках: — выручка: gross vs net (до/после промо, отмен, субсидий); — заказы: оформленные vs собранные vs доставленные; — товары: заказанная корзина vs фактически доставленные позиции (с учётом ненайденных товаров, которые были заменены/отменены); — время: учитываем ли мы часовой пояс или приводим все к московскому времени; — разные идентификаторы: в одном сервисе используются одни идентификаторы сущностей, в другом — другие. Поэтому первым шагом лучше убедиться, что совпадает не только название метрики, но и её смысл. 2️⃣ Упростить запрос до примитива В отчётах и запросах всегда есть несколько слоев: сырые данные (логи заказов/событий) ➔ агрегация метрик по разрезам ➔ финальный расчет метрик с учетом фильтров. Если цифры не сходятся, то идём вниз: — берём одну таблицу (например, таблицу с заказами); — убираем все JOIN и фильтры; — проверяем базовую агрегацию; — затем добавляем шаги обратно по одному. Расхождение почти всегда появляется на одном конкретном слое трансформации. 3️⃣ Проверить кардинальность JOIN’ов Одна из самых частых причин расхождения — JOIN, который ведёт себя не так, как мы от него ждали. Например, кажется, что связь должна быть 1-к-1, а на деле получается 1-к-N. В e-grocery это можно понять по разным признакам: в одном заказе может быть несколько позиций, товар при сборке могут заменить, часть товаров могут отменить, а у заказа может быть несколько событий со статусами. Если не учесть это в логике соединения таблиц, цифры начинают незаметно расходиться. Обычно это видно по симптомам: выручка как будто немного выросла, заказов стало подозрительно больше, а средний чек начал «плавать». В такой момент стоит проверить не только условие JOIN, но и то, сколько строк получается до и после него. 4️⃣ Сравнивать не агрегаты, а строки Когда в одном отчёте 100 млн, а в другом 102 млн, сама по себе разница почти ничего не объясняет. Гораздо полезнее найти конкретные заказы, события или товары, которые эту разницу создают. Что делать? — вместо того, чтобы спорить на уровне итоговых чисел, берём разницу двух выборок до строк; — ищем, какие идентификаторы заказов есть в одной строке, но отсутствуют в другой; — проверяем, на каком шаге они появились/исчезли; После этого несложного шага часто сразу видно причину ошибки: отмена, а может дубль события или JOIN. Возможно какие-то вещи являются базовыми, но про них стоит вспомнить лишний раз, чтобы тратить меньше времени на работу и не беспокоиться за отчёт.

🔄 Всё, что вы забыли обновить, будет использовано против стабильности Когда сервисов много, метрики, дашборды и алерты должны меняться вместе с системой. Иначе это очень быстро превращается в проблему доверия к данным. В новой статье, Вячеслав Литкович, руководитель группы SRE-инженеров, рассказывает, как мы выстраивали SLO-подход в большой продуктовой инфраструктуре. Поговорим про: 📌 первые SLI и дашборды 📌 error budget и почему он не всегда удобен в ежедневной работе 📌 бизнес-процессы, которые нельзя описать одной метрикой 📌 странные кейсы с Kafka, inbox/outbox и низким трафиком 📌 автогенерацию Grafana-дашбордов 📌 декларативные индикаторы и эскалации как код 🏃 Читайте на Хабре!

⏰ Разработка без стресса — кажется, что это невозможно Не всё в разработке решается новым фреймворком или ещё одним сервисом. Иногда стоит немного пересмотреть то, как мы сами работаем. Собрали пост про вещи, которые кажутся базовыми, но о них очень легко забыть в круговороте задач и созвонов. А какими приёмами пользуетесь вы, чтобы сохранять своё душевное спокойствие? Делитесь в комментариях!