Хороший автомобильный маршрут из точки А в точку Б должен, с одной стороны, быть кратчайшим, а с другой — удобным для водителя. Как правильно вычислить время в пути мы уже рассказали, теперь — об удобстве маршрутов: что это такое, как его измерить и как мы его повышали.
У грузовых автомобилей отдельный свод правил, который определяет, куда и по каким дорогам они могут заезжать. Разрабатывая режим построения грузовых маршрутов, мы решали главную задачу — научить алгоритм работать с этими правилами, чтобы пользователи получали наиболее точные результаты.
Я расскажу, как в 2ГИС устроен алгоритм построения маршрутов в целом и как мы адаптировали его под грузовики — например, учили его строить неоптимальные по времени маршруты.
В 2ГИС мы аккумулируем огромное количество геоданных, с которыми взаимодействуют миллионы пользователей ежедневно. Анализируя их, мы можем получить ценную информацию и найти важные идеи для развития городов. Эти данные также полезны организациям.
Чтобы помочь бизнесу и муниципальным организациям, мы решили создать 2GIS PRO — инструмент для GPU-аналитики, с возможностью визуализации огромного количества данных на карте в виде диаграмм и графиков.
Расскажем, как мы получаем такую картинку, как это всё работает под капотом, и посмотрим, на что способен ваш браузер, ведь ему предстоит отображать сотни тысяч объектов одновременно.
Расскажем, как мы получаем такую картинку, как это всё работает под капотом, и посмотрим, на что способен ваш браузер, ведь ему предстоит отображать сотни тысяч объектов одновременно.
Дорожные знаки — один из базовых компонентов любого навигатора. Мы собираем и регулярно обновляем информацию о них: добавляем новые и удаляем неактуальные. Для этого используем кадры с видеорегистраторов, глаза и руки картографов и немного ML-магии. В статье поговорим о том, как мы дополняем нашу карту дорожными знаками, как работаем с данными и формализуем задачи.
Привет, на связи Юля — DevRel 2ГИС. Расскажу, как придумали формат первого DevDay в столице и кто на нём выступил, поделюсь записями и спойлерну, какие мероприятия ждут вас осенью.
Привет! Я Катя, тестировщица в 2ГИС. Расскажу, как мы с командой устроили одиссею в поисках идеальной архитектуры автотестов, атомизировали всё, что можно, один раз свернули не туда, но всё равно нашли лучшее решение из возможных. И не потеряли ни одного тестировщика.
2ГИС — миллионы организаций и геообъектов, которые ищут в поиске. И чем точнее работает поиск, тем лучше для пользователя.
Я Эля Снежкова, лид команды тестирования. Мы проверяем, насколько быстро и эффективно работает поиск в 2ГИС. Расскажу, как мы тестируем, про единорогов в тестировании и как мы измеряем счастье пользователя.
Наш ведущий разработчик — Евгений Самойлов, недавно сходил в гости к Android Broadcast, где рассказал, почему мы в 2ГИС используем Qt. Для тех, кому удобнее читать, публикую выжимку того разговора.
2ГИС — это сложный продукт с картой, поисковым движком, базой данных, транспортными сценариями и многое другое. У сложного продукта — большое UI-наследие. Чтобы 2ГИС выглядел и работал хорошо на всех Android-устройствах, мы используем фреймворк Qt.
Каждое большое приложение однажды сталкивается с задачей — увеличить скорость запуска. Не обошла она и приложение 2ГИС на Android. Расскажу, как команда тестирования искала причины медленного запуска.
Наша команда работает над «лицом» 2gis.ru — WebGL-библиотекой для визуализации картографических данных. В статье кратенько расскажем про WebGL (это важно для понимания особенностей его тестирования), про общий подход к тестированию и непосредственно про особенности тестирования приложения на WebGL [с которыми нам пришлось столкнуться].
Однажды инженер Василий проснулся и понял, что больше не может ждать эти бесконечные пайплайны.
Чтобы отделить ощущения от реальности, он начал собирать статистику — сколько ходят пайпланы, сколько выполняются сами тесты в сервисе фото, а сколько собираются образы. Всё обдумав, он осознал: нужно что-то делать непосредственно с самой сборкой — от пайплайна к пайплайну зависимости меняются редко, а пересобирается всё каждый раз, как в первый.
Картина была такая: от старта пайплайна до непосредственного запуска тестов в сервисе проходило в среднем 7,5 минут. Допустим, за рабочий день каждый член команды (разработчик/тестировщик) запускает 3 пайплайна, а людей в команде — 14. Тогда на сборку образа уходит 5 часов 15 минут.
Василию не подходит.
Мы закончили регрессионное тестирование и со дня на день собираемся начать раскатывать на бой релиз с включенным Metal. Зачем мы это делаем и как всё происходит — рассказываем в статье.
Причина первая: уход на пенсию OpenGL для iOS/OSX. В 2018 году Apple объявили, что прекращают поддержку этого графического API, и это только вопрос времени, когда они удалят его из своих операционок и запретят выкладывать в App Store приложения, использующие GLES (OpenGL for Embedded Systems — подмножество API OpenGL для встроенных систем, например, мобильных устройств). А кому надо впопыхах интегрировать незнакомый API? Правильно, никому. Плюс, нет-нет да и случаются какие-то неприятные падения где-то под капотом OpenGL, починка которых сводится к мольбам, что очередной точечный фикс кода всё исправит.
В первой статье рассказали, почему нам потребовалась автоматическая кодогенерация свифтового интерфейса для C++ в Mobile SDK. Описали инструменты, которые есть в нашем распоряжении, и сделали вывод: лучший промежуточный слой для преобразования на сегодняшний день — это C.
Во второй части рассказываем о собственном инструменте, который поддерживает и Swift, и Kotlin — мы называем его Codegen (да :)).
Это история о том, что подсказка умная, а мы — нет :))
Рассказываем, как мы планировали сделать всё быстро и просто, а получилось как всегда не так. Но мы справились, хоть и не сразу. Речь пойдёт о навигаторе 2ГИС: пользователи строят в нём маршруты и приезжают, куда планировали. Это навело нас на мысль, что хорошо бы предугадывать желание пользователя — предлагать точку назначения и строить маршрут сразу, как только он открыл приложение. Например, пользователь-отец только подумал, что пора забирать ребёнка из детского сада, открыл 2ГИС, а мы ему — готовый маршрут с учётом пробок.
Нужен простенький алгоритм!
В каждой IT-компании стараются повысить технический уровень сотрудников, создать хорошую обстановку для профессионального роста и обмена знаниями. Казалось бы, что здесь всё давно придумано: от конференций и планов индивидуального развития до совместных обедов и пятничных посиделок.
Но у каждого из этих форматов есть свои минусы. Например, конференции проходят не так часто, как хотелось бы, и отнимают довольно много времени, а неформальные посиделки часто проигрывают в приоритетах планам роадмапа.
Мы в 2ГИС придумали собственное решение — и уже четыре года проводим инженерные литературные клубы. Расскажу, что это такое и что мы получаем в итоге.
Весной мы добавили новую подсказку о том, в какую сторону выходить из вагона метро. Меня зовут Влад, я программист С++, и на примере этой подсказки хочу рассказать, из чего состоит жизненный цикл релиза новых фич в 2ГИС. И сколько всего происходит, когда добавляешь — казалось бы — небольшую новую строку с текстом.
В этом году мы много работали над качеством предсказания времени в пути (ETA) в навигаторе 2ГИС и на 30% увеличили количество маршрутов, у которых прогнозное время совпадает с реальным с точностью до минуты. Меня зовут Кирилл, я Data Scientist в 2ГИС, и я расскажу, как максимально точно рассчитывать время прибытия из точки А в точку Б в условиях постоянного изменения дорожной ситуации.
Поговорим про то, как мы постепенно меняли подходы к оценке времени в пути: от простой аддитивной модели до использования ML-моделей прогноза пробок и корректировки ETA. Ввели Traversal Time на смену GPS-скоростей, а ещё проводили эксперименты и оценивали качество изменений алгоритма, чистили мусор из данных и закатывали модели в продакшн. Обо всём по порядку.
Привет, я Артём, ML-инженер. 26 мая 2ГИС зарелизил навигатор для велосипедов и самокатов, одна из его фич — график высот для построенного маршрута. Эта статья о том, как мы получаем этот график.
Привет, я Таня, QA iOS в 2ГИС. Хочу рассказать, как мы починили процесс передачи задач между командами мобильных платформ и подготовки данных. По ощущениям, до починки мы будто ехали по гравийке, а после — выехали на дорогу со свеженьким асфальтом. Поэтому я хочу поделиться нашим опытом и показать, что есть смысл улучшать даже мелкие шероховатости взаимодействия.
Привет, я Оля, QA iOS. Наша команда выкатывает обновления для мобильного 2ГИС и следит, чтобы у него не упала производительность.
Изначально мы отслеживали это уже после попадания приложения в стор, что, конечно, было не очень эффективно. Если происходила просадка, приходилось срочно чинить и перезаливать приложение. Естественно, нам хотелось улучшить процесс и проверять производительность до выхода приложения в стор, а ещё лучше — на каждом этапе создания приложения.
Для этого теоретически подходили два инструмента — MetricKit и Performance Monitoring. Мы решили присмотреться к ним, потому что:
• MetricKit — продукт Apple, а значит будет поддерживаться, пока существует iOS;
• Performance Monitoring — продукт Firebase. У нашей команды есть опыт использования Firebase Crashlytics, значит перейти на продукт от этого же производителя будет легко.
В статье я расскажу, что из себя представляют эти инструменты — об их метриках, отчётах в режиме реального времени, документации и графическом представлении. И расскажу, какой из них мы выбрали.
