Как запустить поисковый сервис, если у тебя всего три недели, а данные нужно агрегировать с десятков источников, каждый из которых работает по своим правилам? Как обойти жёсткие лимиты партнёров, которые ограничивают запросы в 500 RPM и p99 до 5 секунд, когда для быстрой загрузки первых результатов нужно минимум 1000 RPM? Как справиться с геопоиском, когда традиционные решения вроде Elasticsearch не подходят?

В 2022 году 2ГИС запустил сервис бронирования Отелло, и перед нами стояла амбициозная цель — не просто создать поиск, а сделать его быстрым, надёжным и масштабируемым, чтобы успеть занять место на рынке. Спойлер: мы справились. В этой статье расскажем, как именно.

Материал будет полезен бэкенд-разработчикам и продакт-менеджерам, которые сталкиваются с задачами интеграции сложных данных, высокой нагрузки и оптимизации поисковых алгоритмов. А если тебе понравится наш проект, рассмотри нашу вакансию — мы в поисках Senior Golang Engineer. 

В 2ГИС мы знаем: лучшие продукты создаются вместе с пользователями. Уже почти 7 лет наше комьюнити помогает нам дополнять и актуализировать справочник. Мы называем этих людей спецагентами — они уточняют информацию, пишут отзывы, добавляют фотографии и делают 2ГИС удобнее для миллионов пользователей. 

И мы захотели вовлечь ещё больше людей в развитие продукта. Так появился новый краудсорсинговый инструмент — Telegram-бот, который мотивирует пользователей добавлять фото к местам и организациям. Запуск показал, как правильно выстроенный краудсорс может решать бизнес-задачи, масштабироваться и вовлекать пользователей. Этот кейс будет полезен продакт-менеджерам и маркетологам, которые ищут новые способы роста и взаимодействия с аудиторией.

Неприятная ситуация: продукт проходит тщательную проверку на всех этапах разработки, а после релиза всё равно возникают неожиданные ошибки… А ведь это происходит, потому что тестирования на ранних стадиях (shift-left testing, «влево») не всегда достаточно, чтобы гарантировать стабильность продукта. Поэтому важно учитывать и тестирование в продакшене (shift-right testing, «вправо»). 

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

Привет! Я Егор Ерусланов, Qt-разработчик.

В Android-приложение 2ГИС мы добавили новый режим PiP (Picture-in-Picture, или «картинка в картинке»). С PiP наши пользователи смогут следить за маршрутом в маленьком плавающем окне на основном экране. Например, когда нужно быстро прочитать сообщение или включить подкаст и при этом сохранять фокус на навигации. Режим PiP — это не просто «приятная мелочь», а функциональность, которая подстраивается под новые требования пользователей навигатора. 

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

Привет, меня зовут Сергей Загребин, я из команды разработки графического движка 2ГИС. Кроме рендеринга, мы также отвечаем за формат доставляемых офлайн- и онлайн-данных. В этой статье расскажу, как мы игрались со способом разбиения картографических данных на тайлы и искали баланс между размером офлайн-пакетов и производительностью в рантайме.

Надеюсь, этот материал будет полезен не только тем, кто занимается доставкой картографических данных, но и всем, кому интересно, как работает карта 2ГИС.

В 2ГИС продакт-менеджеры отвечают за полный цикл фичи: важно не просто запустить её, но и рассказать о ней. Подробно, честно, с деталями: как появилась идея, какие были сложности, что в итоге получилось и какие первые результаты. Это не просто «мы добавили кнопку, и теперь всё классно» — это история про поиск решения, процесс, ошибки и инсайты. 

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

Меня зовут Вера Романцова, я работаю в 2ГИС в команде компьютерного зрения. Мы создаём ML-модели и сервисы, которые автоматизируют работу с картами и данными. 

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

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

🌚 Кто такой менеджер данных и чем он занимается.

🦾 Как эта роль помогла нашей команде ML-инженеров.

🔜 Когда такой специалист может понадобиться вам.

🔎 Как найти подходящего кандидата на эту позицию.

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

Меня зовут Лёша, и я занимаюсь тестированием в 2ГИС. Моя команда работает над сервисом по бронированию отелей Отелло. В этой статье я расскажу, как использовать кастомные локаторы, чтобы тесты оставались стабильными и поддерживаемыми даже при изменениях в приложении. В примерах я использую Python, но не стоит пугаться, если вы не знакомы с этим языком, каких-то сложных операций мы сегодня выполнять не будем.

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

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

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

Привет! Меня зовут Катя, я тестировщик.

Когда я только пришла работать в 2ГИС, я занималась тестированием фронтенда карты. Всё было чётко и понятно, ведь был один проект. Но когда я переключилась на тестирование бэкенда, ситуация радикально изменилась. В работу команды, связанной с пользовательским контентом, входило 30+ проектов разного размера и приоритета, с разным уровнем покрытия тестами. Из общего только, что все проекты разработаны на Go, а автотесты — на Python.

Ситуация была настоящий «омагад🫣». Даже опытным сотрудникам было сложно ориентироваться в каждом проекте, не говоря о новом члене команды. Это приводило к неприятным последствиям. Например, перед внедрением фич мы часто не могли прогнозировать время тестирования и оценивать необходимые усилия. Бизнесу давались одни сроки, но на практике они сдвигались из-за неожиданно обнаруженных проблем. В результате доставка фич на бой затягивалась или срывались сроки, нарастал техдолг, и вся эта вакханалия повторялась по кругу.

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

Привет! Я Иван Косолапов, тимлид команды ETA/RTA. Мы часть сервиса Data Science и занимаемся анализом данных и машинным обучением для задач навигации в 2ГИС.

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

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

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

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

Расскажу, как решая эти задачи, мы добились более точного отображения автобусов на карте в 2ГИС, упростив существующую на тот момент сложную систему.

Мы делаем карты 2ГИС реалистичными, чтобы приложение максимально детально отражало город вокруг: чтобы у зданий были не гладкие стены, а настоящий фасад, в парках росли деревья и стояли лавочки, а скульптуры выглядели точно так же, как и в реальности. Такая реалистичность помогает в навигации: гораздо проще сравнивать то, что ты видишь в реальности, с моделью этого здания, а не с гладкой коробкой. Поддержка освещения объектов, которую мы добавили на 2gis.ru — ещё один шаг к реалистичности.

Расскажу, чего мы добились на сегодня, на какие компромиссы пришлось пойти и чуть-чуть о том, что под капотом движка освещения и теней.

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

Меня зовут Денис Федоров, я тестировщик в команде 2ГИС ПРО, сервисе геоаналитики для бизнеса. Рассказываю, что такое гит-хуки, чем они могут быть полезны и как их можно реализовать у себя. 

Привет, меня зовут Андрей Рягузов, в 2ГИС я разрабатываю внутренние продукты для актуализации справочных данных на .NET.

Несколько лет назад для работы с настройками мы в команде пользовались самописным методом. Пока приложения были простыми, нас всё устраивало, однако при масштабировании начали вылезать неприятности. Так мы начали искать альтернативу.

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

Привет! Я Катя Глушанина, тестировщик в 2ГИС. В далёком 2019 год в нашей компании было не так много сотрудников, а тестировщиков в веб-отделе — ещё меньше. Мы все работали в офисе, много общались и решали вопросы на месте. Ламповость атмосферы была включена по умолчанию. Компания начала расти, и с этим пришли новые вызовы. Стало больше команд, тестировщиков, появились удалённые сотрудники.

Это привело к трём «побочным эффектам»:

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

Нет обмена знаний. В распределённых командах могут чаще придумываться велосипеды.

Чувство изоляции. Одному дома может быть грустно: даже мем не с кем обсудить.

И мы поняли, что нужно что-то менять.

Привет, меня зовут Андякина Ольга, я QA‑инженер в компании 2ГИС, тестирую сервис по бронированию отелей Отелло. В этой статье расскажу про плюсы и минусы разных подходов к генерации данных и поделюсь хорошими практиками подготовки данных на примере пакета библиотек d42 и нашего проекта. В первую очередь, наш опыт будет полезен тем, кто занимается автоматизацией тестирования фронтенда.

Автоматизированное тестирование сложно представить без использования тестовых данных. Например, при интеграционном тестировании нужно записывать данные в базу и валидировать полученные данные, в нагрузочном — выполнять запрос с уникальными параметрами. Также данные могут потребоваться при фронтенд‑ и e2e‑тестировании, чтобы наполнить блок текстом или ввести ФИО в форму. Есть различные подходы к получению тестовых данных для автотестов, и генерация данных — один из самых удобных и гибких подходов.

Меня зовут Женя Тютюев, я iOS-разработчик в компании 2ГИС. Хочу поделиться, как адаптировал наше приложение под VoiceOver: 

— Делюсь историей про сдвиг парадигмы и как перешёл из стадии «делать, потому что Эпл советует» в совершенно новую — «делать для людей». 

— Как разработал новый вид snapshot-тестирования, чтобы ничего не ломалось при добавлении новых неадаптированных элементов. 

— И описал несколько нюансов, которые важно учесть в работе: escape, динамический расчёт доступности, укрупнение элементов.

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

Привет, меня зовут Роман Брылунов, я QA Automation в команде сервиса транспорта 2ГИС. Мы автоматизируем сервисы транспортных сценариев, таких как построение маршрутов для разных видов транспорта, построение пешеходных маршрутов, решение задачи коммивояжера. Основная часть наших тестов — функциональные тесты логики приложения.

С сервисами общаемся по HTTP, но есть и несколько внутренних сервисов со взаимодействием по gRPC. Все ответы, полученные от сервисов, мы предварительно валидируем перед обработкой в тесте. Для валидации используем библиотеку Pydantic. Это позволяет нам описывать формат взаимодействия с помощью моделей и обрабатывать ответы в виде Python-объектов вместо словаря после стандартного парсинга JSON. Тесты встроены в CI, успешное прохождение тестов является блокирующим условием для влития кода. Таким образом, чтобы внести изменения в API, необходимо актуализировать модели в тестах. В противном случае ответ от сервиса не пройдёт валидацию при прогоне тестов. 

Мы стараемся всесторонне подходить к контролю качества продукта, в том числе хотим, чтобы у продукта была красивая и актуальная документация. У наших сервисов была документация, но она обновлялась вручную. А у нас есть модели запросов и ответов, которые точно соответствуют текущему формату API. Мы подумали, что будет здорово использовать эти модели для формирования документации. Попробовали и успешно внедрили. Расскажу о том, как можно это сделать.

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

Почти в каждом втором собеседовании я слышу следующее:

— Во фронтенде можно максимум вёрстку протестировать отдельно от бэкенда.

— Фронтенд тестируем через end-to-end тесты, но они сложные и нестабильные.

— А как вообще тестировать фронтенд изолированно?

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

В этой статье я хочу рассказать о важности тестирования фронтенда и пользе моков. Мокирование вносит весомый вклад в обеспечение качества приложений 2ГИС, поэтому надеюсь, что этот подход принесёт пользу и другим.

Меня зовут Игорь Буняков, я был фичекрайним за реалистичные дороги в 2ГИС. Недавно они вышли в навигаторе, а позже будут доступны в режиме карт на мобильных устройствах и на 2gis.ru. Реалистичные дороги оказались невероятно большими, невероятно сложными, невероятно красивыми. При этом реалистичность — это не столько про красивость, сколько про функциональность. Мы даём пользователям нашего навигатора новый опыт.

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