Привет! Я Катя, тестировщица в 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, значит перейти на продукт от этого же производителя будет легко.
В статье я расскажу, что из себя представляют эти инструменты — об их метриках, отчётах в режиме реального времени, документации и графическом представлении. И расскажу, какой из них мы выбрали.
Денис Яковлев из JetBrains показывает новый питерский микрорайон «Балтийская жемчужина», где всё что нужно — в двух шагах от дома. А ещё рассказывает о трудностях переезда из Сибири и плюсах удалёнки.
Привет, это снова Даша. В прошлой статье я рассказывала о том, как наняла в команду 7 джунов. Но просто привести людей в команду недостаточно, надо чтобы они в ней ещё и прижились. Для погружения джунов в работу мы выработали процесс. Он состоит из четырёх этапов и длится от принятия сотрудника до полугода работы в компании. Об этом процессе я сегодня вам расскажу.
Фронтенд-разработчик Андрей Мелихов — ведущий ютуб-канала «Девшахта» и участник подкаста «Веб-стандарты» — рассказывает, куда идти за вкусными пирожными, как «Девушка с веслом» помогла ему попасть в Яндекс и показал, где на Петроградке окунуться в атмосферу IT.
Привет, я Даша — QA-лид команды iOS. Им я стала полтора года назад. За это время больше всего меня впечатлил наём сотрудников. Сфера была новой и я набила в ней шишек. Из опыта удалось вывести несколько правил, которые помогли не сойти с ума от поиска, отбирать хороших джунов и обучать их так, чтобы люди оставались в команде и приносили пользу проекту.
Осенью команда 2ГИС участвовала в конкурсе в рамках AI Journey, который организовали ребята из Сбера. Команды учеников школ соревновались в решении ML-задач разных сервисов — Ситимобила, Sber AR/VR, Neurolab, Работы.ру и многих других.
У нашей задачи — распознавания направления движения по полосам на двух дорожных знаках — было 23 решения. Но я расскажу только про финальные, к которым ребята и мы в итоге пришли.
Начну без спойлеров, но с вопроса — как думаете, какое решение победило в конкурсе?