^{В данной статье будем рассматривать технические детали графических API Metal, API Vulkan и многопоточное программирование, от читателя требуется знание перечисленных технологий.}

Всем привет! Я Андрей, разработчик 3D-графики в 2ГИС.

Если вы пишете рендер на C++ и у вас есть отдельный RenderThread, то, скорее всего, вы уже сталкивались с подобным: данные грузятся в фоне, а вот создание GPU‑ресурсов всё равно происходит в потоке отрисовки через прямое обращение к графическим API Vulkan, Metal, Direct3D 12. И пока RenderThread в длинном цикле создает буферы и текстуры, он не рисует — он стоит, пока не обработает список загруженных ресурсов.

У нас это выглядело так на типичной средней сцене: до появления первого кадра на поток отрисовки приходило 532 текстуры и 2713 буферов, которые удерживали 45 МБ и 20 МБ временной памяти в RAM соответственно. Всё это нужно было доставить до GPU, создать наборы буферов и текстур, далее всё освободить и только потом начинать собирать батчи и рисовать.

В статье разберём, как мы вынесли создание буферов и текстур на потоки загрузки, что для этого дает Metal, почему в Vulkan всё сложнее, и какие ограничения по особенностям работы графических API пришлось учитывать.

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

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

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

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

SonarQube подключен, дашборд есть, анализ запускается на каждый MR, но никто не пользуется. В таком случае проблема не в инструменте. Проблема в том, что между «Sonar работает» и «Sonar приносит пользу» — пропасть из-за отсутствия договорённостей. Я видела это на нескольких проектах и расскажу, что конкретно превращает декоративный дашборд в работающий механизм контроля качества.

Статья будет полезна QA, разработчикам и тимлидам, у которых SonarQube уже есть, но результаты анализа живут и ни на что не влияют.

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

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

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

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

Меня зовут Даня. Я продуктовый дизайнер команды Транспорт и сейчас расскажу, как мы собирали зелёную волну: от первого скетча до запуска.

В этой статье рассказываю, почему одной LLM оказалось недостаточно и как мы связали языковую модель с данными, API и интерфейсом геоаналитической платформы.

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

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

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

У меня такой идеей было реализовать вменяемое ожидание готовности страницы. Не конкретного элемента — а страницы целиком. В один прекрасный момент мне предоставилась такая возможность...

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

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

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

Я, Стас Мозгель, руководитель B2C‑продуктов, делюсь тем, как работает наша продуктовая культура изнутри: всё про процессы, культуру и принципы, которыми руководствуемся. 

Привет, это снова Даша, руководитель iOS QA в 2ГИС. Но на этот раз не одна, прихватила с собой лида разработки iOS — Витю. 

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

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

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

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

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

Когда вы прокладываете маршрут в горах в 2ГИС или рассматриваете вид на дом в 3D, вы вряд ли задумываетесь, что под капотом карты происходит серьёзная вычислительная работа. За каждой формой рельефа — тысячи треугольников, интерполяции и алгоритмы, которые превращают цифровую модель местности в реалистичную поверхность.

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

В этой статье расскажем, как мы пересмотрели подход к данным, зачем нам понадобился нерегулярный меш, что общего у RTIN с Делоне и почему даже рельеф иногда приходится «чинить».

Всем привет! Меня зовут Ира Карачакова, я тестировщик в сервисе бронирования отелей Отелло.

В этой статье рассказываю, как у нас в команде выстроился процесс работы с нестабильными фронтовыми e2e-тестами: от простых перезапусков в CI до системы алертов, карантина и отслеживания стабильности.

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

Привет! Меня зовут Оля, и я AQA в Отелло. В тестировании с 2018 года, а технические собеседования на все QA грейды — от trainee до lead — я провожу с 2021. Когда-то давно, ещё будучи студенткой вуза, я попала в IT-компанию через стажировку. Тогда на одно место в компании претендовали 700 человек, и в итоге работу получили только четверо — я была одной из них. Поэтому я знаю не понаслышке, сколько времени и сил нужно вложить начинающему тестировщику, чтобы получить первую работу. 

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

• Как выбрать свою первую компанию.

• Красные флаги работодателя на собеседованиях.

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

• Как подготовиться к собеседованию с помощью AI.

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

Как дать пользователю ответ на конкретный вопрос с помощью гео-аналитики? Идеальный ответ — это заходишь в сервис, нажимаешь одну большую кнопку и сразу видишь ответ на свой вопрос. Но, как и в любой сложной системе, в реальности всё устроено сложнее.

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

Расскажу, как мы:

• отказались от устаревших слоёв в пользу виджетов,
• пересобрали интерфейс вокруг единого дашборда,
• внедрили независимую логику для виджетов,
• переехали на сетку, виртуализацию и архитектуру, вдохновлённую микросервисами,
• сделали миграцию незаметной для пользователей.

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

Валера — обычный разработчик. Немного любопытный, немного уставший, но явно не из тех, кто боится экспериментов. В какой-то момент он услышал о вайбкодинге и подумал: «А что, если и правда можно запускать интерфейсы, API и базы без единой строки кода?» Скачал Cursor, начал писать промпты — и тут началось…

Начал писать промпты. Первый — ошибка. Второй — тоже ошибка. Третий — казалось бы, заработал, но тут Cursor попросил: «А теперь исправь всё вручную». И в этот момент Валера понял: что-то пошло не так.

Когда Валера уже собрался удалить всё к чёрту и переехать в тайгу, ему явился древний Курсор, Луция Папирий Курсор. Он пообещал научить его античной мудрости вайбкодинга. Так начался Новый путь...

Не так давно на запланированном звонке в зуме в присутствии команды коммуникационного дизайна 2ГИС, а также арт-директора, тимлида и любопытствующей публики прошла защита проектов на курсе «Основы шрифта». Дизайнеры показали шрифты, которые они проектировали в течение трёх месяцев и рассказали, как ими можно пользоваться.

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

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

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