Поиск багов в Островке, как и в других компаниях, во многом опирается на автоматизированные тесты. Но при этом в тревелтехе есть свои особенности тестирования.

Внешние интеграции

Поставщики отелей, бронирования билетов, трансферов, автомобилей… для пользователя все они должны взаимодействовать бесшовно.

Внутренние интеграции

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

Реалистичные данные для тестов

Иногда нужно тестировать, используя данные, максимально близкие к настоящим. Их сложно достать, поэтому приходится изобретать. Например, при тестах бронирования авиабилетов мы заказываем реальные билеты за реальные деньги. Важно успевать отменять бронь после тестирования.

НО!

...самые интересные истории могут родиться даже не из-за обилия сервисов. Есть у нас услуга: автоотмена бронирования отелей до истечения срока бесплатной отмены в отеле (попап: Эта фича, позволяет нам сократить финансовые риски партнёров, которые могут забыть отменить бронирование сами; тогда оно станет невозвратным.). Как-то осенью в одном американском отеле эта отмена стала срабатывать на час раньше. Мы сверили часовые пояса: все было в порядке, проверили еще кучу мелочей. Но нашли ответ именно в согласовании времени. Хотя большинство штатов США переходят на летнее и зимнее время как остальной мир, отдельные штаты это игнорируют — и проблемный отель находился как раз в одном из них.

Хотите узнать больше о работе QA-инженеров в Островке? Пишите в комментариях и эта тема получит шанс заиметь свою статью в блоге :) И на наш Телеграм-канал подписывайтесь!

А если вы или ваши друзья хотите скать частью QA-команды Островка, то обратите внимание на эти открытые позиции в нашей компании:

• QA Engineer в команду CheckOut

• QA Engineer в команду Маркетинга

Исследуй неизведанные пути на О! Хакатоне

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

На О! Хакатоне, который пройдёт с 28 сентября по 5 октября, участников ждут испытания на оригинальных маршрутах по миру тревел-теха и встречи с экспертами. А победители получат призы.

Мы зовём в путь прежде всего Middle-разработчиков на Python и Go, разработчиков на других языках, девопсов, аналитиков, продактов. В путь можно отправиться как в одиночку, так и командой до пяти человек. А если у вас нет команды, но вы хотите сотрудничать на хакатоне с другими специалистами, мы поможем подобрать единомышленников после регистрации.

Участников ждут два трека, два алгоритма, которые необходимо разработать. Один должен менять стоимость бронирования, учитывая влияние на цену ряда факторов — срок до поездки, время года и других. Задача второго — собирать данные о номерах из разных отелей и категоризировать по разным параметрам. Призовой фонд каждого трека — 500 000 рублей, которые поделят три лучших решения. 

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

Хотите почувствовать себя первопроходцами? Регистрируйтесь на О! Хакатон до 19 сентября.

Чем занимаются Go-специалисты в Островке?

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

• Адаптируют API различных поставщиков к внутреннему API сервиса. Внешние поставщики отелей используют разные технологии: GraphQL, XML, SOAP, WTF. В каждом API своё время ответа, свои коды ошибок и ещё много кастомного. 

• Поддерживают и правят существующие интеграции. Протокол сменился, или (куда реже) коды ошибок стали другие — всё надо держать в актуальном состоянии и при необходимости править.

• Уменьшают технический долг. Это задачи, связанные с библиотеками и рефакторингом. Есть правило — на одну итерацию должно приходиться 75% продуктовых задач и 25% техдолговых.

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

• Обмениваются знаниями внутри компании. В Островке есть активности, напрямую не связанные с работой. Например, канал в слаке #dev-golang и еженедельный книжный клуб.

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

Что почитать начинающим разработчикам на Go

Привет, Хабр! Меня зовут Алексей Артамонов, я лид команды интеграции в «Островке». Сделал подборку, что можно почитать для старта работы с Go:

• «The Go programming language» — азы для старта. Хотя синтаксис в Go простой, важно уметь из этих простых вещей собирать сложные конструкции. 

• Effective Go — практическое пособие для создания тех самых сложных конструкций.

• «Сто ошибок в Go» — ещё одна хорошая книга. Заход со стороны «как делать не надо».

• В различных обучающих программах очень много внимания уделяют монолитам, микросервисам и в принципе архитектуре. Но правда в том, что джун или мидл вряд ли столкнётся со столь глобальными задачами. Ему важнее уметь разбить свою логику по классам, пакетам, модулям. Важно писать качественный код. Для этого обязательно рекомендую книгу «Good code, bad code».

• Много полезного в книге «Принципы юнит-тестирования». Хорошие юнит-тесты неразрывно связаны с тем, как приложение разбито на модули, какие есть связи и зависимости.

• Два блога-рассылки: GoLang Blog и Awesome Go Weekly.

• Подкасты довольно сложны для восприятия в фоновом режиме. Особенно для новичков. Но если очень хочется: GoTime, GoPodcast и GoGetPodcast.

Обучение пройдёт легче, если уже знать какой-нибудь язык программирования. К примеру, в «Островке» два главных языка — Python и, собственно, Go. Главный секрет — желание и практика. Если хочешь стать программистом — надо сесть и начать кодить. Ни одна книга без практики не поможет стать программистом.

Привет! Меня зовут Ильдар Ломов. Расскажу, чем занимаются ML-инженеры в Островке. Знаю об этом всё, я сам руководитель команды Data Science.

Сейчас портфель ML-проектов Островка —12 штук в нескольких направлениях: от продуктового ML (ранжирование, рекомендации), до больших языковых моделей. 

Состав команды стандартный: ML-инженер, бизнес-аналитик, проджект, продакт. Опционально тимлиды и разработчики.

Работа ML-инженера в Островке — посередине между стартапом с его моделью в jupyter-ноутбуке и корпорацией, где работа с сотнями моделей упорядочена, стандартизирована, вшита в интерфейсы. Можно поработать над серьезным проектом гибко с разнообразием инструментов.

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

Нужно уметь покрывать метриками, следить за проектом на проде, чтобы тот не потерял смысл из-за нестыковок в ТЗ. И работал так, как задумано. 

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

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

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

Привет, я Иван Елфимов, Developer Advocate в Островке. Расскажу про самые полезные open source решения, которые использую я сам и Команда партнерских интеграций.

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

• Один из самых малоизвестных и узкопрофильных компонентов, который мы используем: django-chronograph. Это приложение, позволяющее запускать management-команды из админки. Эта библиотека давно не поддерживается, поэтому мы форкнули её к себе доработали. Возможно когда-нибудь выложим в Open Source.

• Компания Astral создает (точнее пересоздает) отдельные инструменты для питона на языке Rust, заставляя их работать в разы быстрее. Мы уже начали пользоваться и ruff и uv.

• Личная рекомендация от меня: pre-commit. Инструмент очень мощный и полезный, хотя даже там встречается юмор от разработчиков. К примеру, скрипт проверки кода на случайно оставленный print называется «oops, I print it again!»

• Островок готовит к выпуску свой техрадар. Пока он работает в закрытом режиме только для сотрудников, но в планах вынести его наружу. В техрадаре будет информация о библиотеках, прошедших через тесты команды Островка. Они будут сгруппированы по направлениям (frontend, backend, ios/android, аналитика, QA, devops) и каждая из библиотек будет иметь свою стадию: adopt, trial, assess и hold.

Привет, я Иван Елфимов, Developer Advocate в Ostrovok.ru. Расскажу про наш переход на Django 5.0.

4 марта вышел третий security release, когда мы обычно переходим на новые версии библиотек. Мы были готовы к переходу: проверили на декабрьском 5.0.0. что могло сломаться. Из-за некоторых обновлений нам пришлось менять код:

• Раньше мы использовали nulls_last=False. Теперь nulls_first и nulls_last могут быть True или None, поэтому в некоторых местах вместо значений по умолчанию теперь nulls_last = None:

  - nulls_last = False
  + nulls_last = None
    if ordering_by == OrderingField.FIELD_START_AT:
        nulls_last = True

• В сигналах появился новый тип асинхронных ресиверов  (async_receivers), мы добавили его во вспомогательный класс SignalBlocker, которым временно выключаем сигналы.

• Теперь надо явно указывать USE_TZ = False, но это не проблема, мы не используем таймзоны в нашем сервисе.

• Если после refresh_from_db надо дальше по коду использовать закешированные значения из базы данных, появился такой хак:

my_model_obj._meta.private_fields = []
my_model_obj.refresh_from_db()

Новинка, которой воспользуемся в будущем, — расчетные поля по умолчанию (default) в БД. Есть сценарии, где нужно, чтобы поле по умолчанию было не скаляром, а содержало расчётное значение на основе других полей.