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

Меня зовут Дмитрий Меситов. Я продуктовый аналитик в ОК, и в этой статье я хочу рассказать о том, зачем нам понадобилась смена стека для мониторинга продуктовых метрик, какие варианты мы рассматривали и какой инструмент выбрали в итоге.

Tracer — модульный инструмент для аналитики ошибок в мобильных приложениях от OK.Tech, который мы представили год назад. За это время в Tracer зарегистрировалось более 1400 организаций и 5000 пользователей. Сейчас решение обрабатывает более 1 млрд событий в день и обслуживает приложения, которые имеют суммарный DAU в 20 млн пользователей. Опыт наших клиентов показывает, что Tracer успешно справляется с поставленными задачами, но мы всё равно не останавливаемся на достигнутом.

Меня зовут Кирилл Попов. Я руководитель направления Android-разработки в ОК. В этой статье я расскажу, какие возможности получил инструмент за последний год, и что мы планируем реализовывать в перспективе.

Привет, Хабр. Меня зовут Давид Чупреев. Я разработчик мобильных приложений в команде Core iOS ОК. 

В работе любого ПО как на iOS, так и на других ОС, важна стабильность и отказоустойчивость. Вместе с тем, полностью исключить сбои и ошибки в работе приложений попросту невозможно. Соответственно, ключевое значение имеет возможность оперативного отлавливания ошибок и их устранения. В этом не обойтись без знания «анатомии» крэшей и понимания принципов работы с ними. В этой статье я расскажу, как устроены крэши в iOS, откуда они берутся и как с ними взаимодействовать.

Про байт‑код написано уже немало. Он везде, и никого этим не удивить: его генерирует компилятор, переупаковывает система сборки, «портит» обфускатор и изредка читают программисты. Естественно, для работы с байт‑кодом есть немало инструментов, которые используются в разных областях и на разных платформах. Среди них и ByteWeaver — инструмент для патчинга байт‑кода во время сборки, который может быть полезен разработчикам под Android.

Меня зовут Александр Асанов. Я Android‑разработчик в OK, Tracer, ByteWeaver. В этой статье я разберу, что такое байт‑код, как и зачем с ним работать, расскажу о ByteWeaver и покажу примеры работы с байт‑кодом.

ОК — большая и популярная социальная сеть. Причем она не только про общение, но и про развлечения: на платформе доступно огромное количество игр и мини-приложений, с которыми аудитория активно взаимодействует. Внутренние приложения и игры ОК использует почти 20 млн человек, и вовлеченность пользователей постоянно растет.

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

Меня зовут Михаил Мосин. Я инженер-программист в ОК. В этой статье я подробно и пошагово расскажу, как зарелизить свое приложение на платформе ОК.

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

Меня зовут Богдан Мащенко. Я Android-разработчик в платформенной команде Одноклассников. В этой статье я расскажу о нашем опыте перехода на AGP (Android Gradle Plugin) и Gradle версий 8.*: что стало причиной перехода, как преодолевали трудности, и что мы смогли получить в результате.

Командная работа при разработке программного обеспечения (ПО) — это не только объединение компетенций и экспертиз, но и общая ответственность за конечный продукт. К сожалению, об этом часто забывают, оставляя проверку качества и соответствие требованиям только на QA-инженеров. Это ошибочная практика, которая нередко заканчивается выкаткой в прод «сырых» продуктов с недочетами и уязвимостями.

С вами снова Алексей Петров, директор по качеству в Одноклассниках. В этой статье я расскажу, как команда может на каждом этапе разработки ПО заботиться о качестве будущего продукта, а также бороться с багами еще до их появления.

Материал подготовлен по мотивам моего доклада на CodeFest. Вы можете посмотреть его здесь.

Написание автотестов — одна из наиболее эффективных практик, которая позволяет проверять работоспособность всех компонентов сервиса и своевременно обнаруживать любые сбои. Но писать много автотестов — не всегда верный подход: тестов должно быть не много, а достаточно. Иначе время и силы инженеров по тестированию и автоматизации будут тратиться напрасно. Но как понять, что автотестов достаточно, и, главное, быть уверенным, что обновление или добавление новых методов внутри проекта не создаст «неотслеживаемые бреши»? Очевидно, что для этого нужна система анализа покрытия автотестами.

Мы продолжаем серию статей об автотестах в ОК (материалы по этой теме мы можете почитать здесь, здесь и здесь). И сегодня рассказываем на примере анализа покрытия автотестами API, как с этими задачами справляется команда ОК.

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

Делимся опытом работы с автотестами в ОК: от подходов к постановке задач до схемы настройки окружения статического анализатора кода.

Материал подготовлен по мотивам доклада руководителя команды автоматизации тестирования ОК Эмилии Куцаревой и младшего инженера по автоматизации тестирования соцсети Евгения Буровникова на ИТ-конференции «Стачка».

Одно из основных преимуществ сферы ИТ — динамичное развитие технологий, которое также стимулирует непрерывно развиваться и специалистов разных уровней и направлений. Поэтому история, когда специалист в рамках одной команды может вырасти от Junior до Senior, встречается часто. Этот путь не всегда быстрый и, главное, не всегда очевидный: в череде событий легко потерять фокус с главного, пытаться стать лучшим во всем и в итоге остаться «среднячком» везде. Избежать этого помогает разработка индивидуальных планов развития (ИПР).

Меня зовут Алексей Петров. Я директор по качеству в Одноклассниках. В этой статье я хочу рассказать о наших подходах к оценке скиллов сотрудников, разработке и использованию планов индивидуального развития. 

P.S. В статье я описываю практику на примере специалистов отдела тестирования. Но подход универсален — вы можете легко адаптировать его под свои задачи и в других специальностях.

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

Меня зовут Елена Пранова. Я инженер по автоматизации тестирования в ОК. В этой статье я хочу рассказать о том, как мы работаем с локаторами для автотестов: каких принципов придерживаемся, чего стараемся избегать и какие правила выработали на своем опыте.

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

Меня зовут Алексей Иванов. Я дизайн-директор в ОК. В этой статье я расскажу о нашем пути от хаоса к структуре в процессах, а также дам практические рекомендации на основе нашего опыта, которые помогут улучшить взаимодействие между командами, сделать работу каждого специалиста комфортнее и эффективнее.

UI-автотесты под Android — отличный инструмент, который позволяет кратно сократить время на проверку разрабатываемых фич и свести к минимуму участие в ручном регрессионном тестировании инженеров по обеспечению качества. Но работать с UI-тестами надо правильно — иначе все может прийти к ситуации, при которой автотесты становятся нестабильными, а их результаты не вызывают доверие.

Меня зовут Эмилия Куцарева. Я — руководитель команды автоматизации тестирования в Одноклассниках (VK). В этой статье я расскажу о нашем подходе к работе с Android UI-автотестами: как устроен запрет мерджа, как смогли стабилизировать тесты, как настроили параметризацию запуска.

Ежемесячная аудитория ОК только в России превышает 36 млн человек. Причём это активные пользователи, которые хорошо взаимодействуют с нашим контентом: ставят Классы, комментируют, делают репосты. Залогом активного отклика во многом является формирование новостной ленты с учетом предпочтений каждого конкретного пользователя.

Меня зовут Дмитрий Решетников. Я тимлид команды рекомендаций в Ленте ОК. В этой статье я расскажу, как выглядит наш пайплайн рекомендации в ленте новостей, о месте item2vec в нём и результатах внедрения такого подхода.

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

Месячная аудитория ОК достигает 36 млн пользователей, и почти половина из них заходит в соцсеть из браузеров — как мобильных, так и десктопных. Поэтому для нас важно, чтобы сайт со всей графикой хорошо работал на любом устройстве и в любом формате. Непрерывная работа над этой задачей позволила нам выработать экспертизу, которой мы готовы поделиться. 

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

Проверка гипотез — неотъемлемая часть работы с продуктом. Но в условиях крупного «живого» проекта, такого как ОК, зачастую возникает не одна, а много гипотез одновременно, которые нужно проверить быстро, без негативного влияния на сервис и с минимальными затратами. 

Для решения таких задач используют разные подходы, в том числе качественные и количественные UX-исследования. При этом количественные исследования часто подразумевают работу с инструментами внешних вендоров, что не всегда оптимально — дорого, есть ограничения по количеству запусков, могут быть проблемы с набором релевантной аудитории. 

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

Рассказываем, что получилось в итоге.

Миграция с «железа» в облако в большинстве случаев уже не кажется чем-то сложным или удивительным — тенденция на развертывание решений в облаке общая и устоявшаяся. Но если с переносом в облачную среду небольших ИТ-компонентов все просто, то в случае с глобальными системами на сотни петабайт данных все несколько иначе — такие кейсы встречаются редко. 

Меня зовут Михаил Марюфич. Я руководитель Data Platform в ОК, отвечаю за инфраструктуру для Big Data и машинного обучения. В этой статье я расскажу о нашем опыте переноса Hadoop с Bare Metal в облако: с чего стартовали, какие варианты рассматривали, как выстроили миграцию и с чем сталкивались в процессе.

Команда ОК изучила материалы конференции RecSys 2023 и сделала разбор наиболее знаковых из них. Первую часть разбора читайте здесь. И подписывайтесь на наш ТГ-канал ML — это ОК. В канале мы выкладываем разборы интересных статей по теме ML и делимся экспертизой, которую накопили за 12 лет в этой сфере.

ACM RecSys — международная конференция, на которой эксперты в области рекомендательных систем делятся своими наработками и исследованиями, задавая тренды развития технологий и подходов. Команда ОК изучила статьи конференции RecSys 2023 и сделала разбор наиболее интересных из них. Первая часть разбора — в этой статье (часть 1). Вторая выйдет в ближайшее время. Если вы хотите читать материалы, как только они появляются, подписывайтесь на канал ML-команды ОК. В канале мы выкладываем разборы интересных статей по теме ML и делимся экспертизой, которую накопили за 12 лет в этой сфере.

Всем привет! На связи снова отдел продуктовой аналитики Одноклассников. Меня зовут Виктория Гордеева, я руковожу этим отделом, и сегодня я бы хотела поделиться нашими болями при проведении А/B-тестов. 

A/B-тесты во многих кейсах сопровождаются разными проблемами — высокой дисперсией в метриках, недостаточным количеством пользователей, некорректной работой «сплитовалки». Для ОК наиболее частой проблемой было нарушение предпосылки SUTVA (Stable Unit Treatment Value Assumption) — из-за большой активности аудитории нам было сложно исключить сетевые эффекты (Network effect) с влиянием одного участника эксперимента на другого. Об этом и поговорим :)