Яндекс

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



— Меня зовут Лёша, я работаю в Поиске и разрабатываю самый главный, наверное, продукт Яндекса — поисковую выдачу.

Мы разбирали старые письма и наткнулись на статью, которую писал Илья Сегалович iseg для журнала «Мир Internet» в далёком 2002 году. В ней он сравнивает интернет и поисковые системы с чудесами света, размышляет о поисковых технологиях и вспоминает их историю. Несмотря на загруженность по работе, Илья написал статью в рекордные сроки и даже снабдил достаточно подробным словарём терминов, который особенно интересно читать в наши дни. Нам не удалось найти электронную версию журнала со статьей, поэтому сегодня мы публикуем её в нашем блоге, первым автором которого, к слову, был Илья.

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

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



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

Иногда люди обращаются к Яндексу, чтобы найти фильм, название которого вылетело из головы. Описывают сюжет, запомнившиеся сцены, яркие детали: например, [как называется фильм там где мужик выбирает красная или синяя таблетка]. Мы решили изучить описания забытых фильмов и выяснить, что сильнее всего запоминается людям в кино.

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

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

Моё имя Олег Ермаков, я работаю в команде бэкенд-разработки приложения Яндекс.Такси. У нас принято проводить ежедневные стендапы, где каждый из нас рассказывает о сделанных за день задачах. Вот как это бывает…

Имена сотрудников может и изменены, а вот задачи вполне себе реальны!

На часах 12:45, вся команда собирается в переговорке. Первым слово берет Иван, стажёр-разработчик.

Иван:

Я работал над задачей отображения всех возможных вариантов сумм, которые пассажир мог дать водителю при известной стоимости поездки. Задача достаточно известная — называется «Размен монет». С учётом специфики добавил в алгоритм несколько оптимизаций. Отдал пул-реквест на ревью еще позавчера, но с тех пор я исправляю замечания.

По довольной улыбке Анны стало понятно, чьи замечания исправляет Иван.

Меня зовут Артём Березин, я разработчик нескольких внутренних сервисов Яндекса. Последние полгода я активно работал с React Hooks. По ходу дела возникали некоторые сложности, с которыми приходилось бороться. Теперь хочу поделиться этим опытом с вами. В докладе я разобрал React Hook API с практической точки зрения — зачем нужны хуки, стоит ли переходить, что лучше учитывать при портировании. В процессе перехода легко наделать ошибок, но избежать их тоже не так сложно.



— Хуки — это просто еще один способ описывать логику ваших компонентов. Он позволяет добавить к функциональным компонентам некоторые возможности, ранее присущие только компонентам на классах.

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



Я Жанна Круглова, экс-разработчик и руководитель группы Буткемпа. Расскажу читателям Хабра, что у проекта под капотом, какие возможности он даёт и как предыдущие участники мучительно выбирали себе команду.

В коде самых разных проектов нередко приходится оперировать временем — например, чтобы завязать логику работы приложения на текущее время у пользователя. Старший разработчик интерфейсов Виктор Хомяков victor-homyakov описал типичные ошибки, которые встречались ему в проектах на языках Java, C# и JavaScript от разных авторов. Перед ними вставали одни и те же задачи: получить текущую дату и время, измерить интервалы или выполнить код асинхронно.



— До Яндекса я работал в других продуктовых компаниях. Это не как фрилансер — написал, сдал и забыл. Приходится очень долго работать с одной кодовой базой. И я, собственно, смотрел, читал, писал много кода на разных языках и увидел много чего интересного. В итоге у меня родилась тема этого рассказа.

На днях состоялся Moscow Python Meetup #66 — сообщество продолжает обсуждать актуальные инструменты, которые усиливают язык и адаптируют его к разным окружениям. В том числе на митапе прозвучал и мой доклад. Меня зовут Наиль, я делаю Яндекс.Коннект.



Рассказ, который я подготовил, был посвящён uWSGI. Это многофункциональный сервер веб-приложений, а каждое современное приложение сопровождается метриками. Я постарался показать, как возможности uWSGI способны помочь в сборе метрик.

Всем привет! Меня зовут Дмитрий Фисько, я разрабатываю Yandex Mobile Ads SDK. Наша библиотека предназначена для монетизации мобильных приложений на платформе Android и iOS. Сегодня я хочу рассказать вам о том, как мы упростили разбор сложных ошибок интеграции SDK в Android-приложения. Возможно, наш опыт пригодится и вам.

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

К сожалению, не все ошибки интеграции SDK можно определить по мониторингам. Если такая ситуация возникает, мы обращаемся к партнёру, чтобы уточнить детали интеграции. Затем мы стараемся определить причину проблем и помочь их решить. Если даже этой информации недостаточно, чтобы определить причину ошибок, мы запрашиваем у партнёра разрешение на реверс-инжиниринг приложения. После разрешения мы начинаем смотреть на работу рекламного SDK в приложении как на чёрный ящик. Просматриваем сетевую активность через proxy, проверяем отображение рекламных view через Layout Inspector и др.

Привет, меня зовут Артём, я руководитель одной из групп разработки интерфейсов в Яндексе. Неделю назад на Я.Субботнике я рассказал, как мы использовали SVG для создания внутреннего календаря. Это расшифровка моего доклада, несколько историй из реализации виджета календаря: масштабирование, заливка паттерном, маски, символы и особенности формата.



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

На днях прошла встреча международного комитета по стандартизации C++ в Кёльне. В прошлый раз был принят feature freeze на C++20, так что комитет должен был обсуждать только исправления уже принятых вещей, а добавлять новинки уже в C++23…

… но всё было не так!



Что сделали с std::flat_map; останутся ли страшные ключевые слова co_return, co_await и co_yield; успели ли доделать std::format; в каком виде будут контракты в C++20? Всё это вас ждёт под катом.

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

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

Но иногда водители выходят на линию уже уставшими — например, весь день человек был занят на другой работе, а вечером решил “подрулить”. Что с этим делать? Как понять, что водитель заступает на смену не выспавшись? Можно, например, попробовать оценить, насколько внимательно он следит за дорогой, и определить признаки усталости, например по характеру морганий. Звучит просто? Всё сложнее, чем кажется.

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

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

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

Меня зовут Александр, я руковожу одной из групп разработки интерфейсов в Яндекс.Маркете. Сегодня я расскажу читателям Хабра о нашем опыте решения этих задач. Также рассмотрим пример доставки фичи в продакшн.

Создание и сопровождение общих компонентов — процесс, в котором должны быть заняты множество команд. Руководитель службы общих компонентов Яндекса Владимир Гриненко tadatuta объяснил, как их разработка переросла выделенную команду «Лего», как мы сделали монорепозиторий на базе GitHub с помощью Lerna и настроили Canary-релизы с внедрением в сервисы прямо в CI, что для этого понадобилось, а что ещё предстоит.



— Рад вас всех приветствовать. Меня зовут Владимир, я занимаюсь общими штуками в интерфейсах Яндекса. Про них и хочу поговорить. Наверное, если вы не очень глубоко пользуетесь нашими сервисами, у вас может возникнуть вопрос: что мы все верстаем? Что там верстать?

Привет, меня зовут Стас Макеев. В Яндексе я руковожу разработкой технологии Турбо-страниц, которая обеспечивает быструю загрузку контента даже при медленном соединении. Сегодня я расскажу читателям Хабра немного об архитектуре нашего проекта.

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

Средняя скорость загрузки в российских мобильных сетях составляет 16,26 Мбит/с — это довольно хороший показатель. Но скорость соединения неравномерна, мы всё ещё сталкиваемся с медленным интернетом — 3G, 2G, EDGE. Наверняка вы были в ситуации, когда в кафе или торговом центре, в дороге или на даче сильно снижается привычно высокая скорость: сайты загружаются десятки секунд, а то и дольше.

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

На днях победители чемпионата по программированию, который завершился в начале лета, получили заслуженные призы. Для этого мы позвали их, а также всех остальных финалистов из топ-20 каждого направления в московский офис Яндекса. Ещё раз поздравляем тех, кто сумел выйти в финал.

Тем временем мы подготовили разбор задач чемпионата, которые предлагались фронтенд-разработчикам. Это задачи из квалификационного этапа. Напоминаем, что чемпионат проводился по четырём направлениям: бэкенд, фронтенд, машинное обучение и аналитика.

A. Градусник пробок

Условие

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

Стремление уйти от ручного регрессионого тестирования — хороший повод внедрить автотесты. Вопрос, какие именно? Разработчики интерфейсов Наталья Стусь и Алексей Андросов вспомнили, как их команда прошла несколько итераций и построила тестирование фронтенда в Авто.ру на базе Jest и Puppeteer: юнит-тесты, тесты на отдельные React-компоненты, интеграционные тесты. Самое интересное из этого опыта — изолированное тестирование React-компонентов в браузере без Selenium Grid, Java и прочего.



Алексей:
— Для начала надо немного рассказать, что такое Авто.ру. Это сайт по продаже машинок. Там есть поиск, личный кабинет, автосервисы, запчасти, отзывы, кабинеты дилеров и многое другое. Авто.ру — очень большой проект, очень много кода. Весь код мы пишем в большой монорепе, потому что это все перемешивается. Одни и те же люди делают схожие задачи, например, для мобильных и десктопа. Получается много кода, и монорепа нам жизненно необходима. Вопрос — как ее тестировать?

Как проверить идеи, архитектуру и алгоритмы без написания кода? Как сформулировать и проверить их свойства? Что такое model-checkers и model-finders? Требования и спецификации — пережиток прошлого?

Привет. Меня зовут Васил Дядов, сейчас я работаю программистом в Яндексе, до этого работал в Intel, ещё раньше разрабатывал RTL-код (register transfer level) на Verilog/VHDL для ASIC/FPGA. Давно увлекаюсь темой надёжности софта и аппаратуры, математикой, инструментами и методами, применяемыми для разработки ПО и логики с гарантированными, заранее определёнными свойствами.

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

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