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

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

На часах 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. Давно увлекаюсь темой надёжности софта и аппаратуры, математикой, инструментами и методами, применяемыми для разработки ПО и логики с гарантированными, заранее определёнными свойствами.

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

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

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

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

Идея сделать что-то для автопрома выросла не на пустом месте. Невозможно оставаться в стороне, когда в компании есть Карты, Навигатор, Музыка, Погода, Поиск, голосовые технологии и многое другое; если совместить всё это — может родиться что-то полезное.

Поиски будущего продукта

Что требуется за рулём? Сколько людей — столько и мнений, но обычно всем нужны навигация, музыка и рекомендательные сервисы. Первым делом расписали сценарии обращения к системе за рулём: опросили коллег и знакомых, собрали фичреквесты от пользователей продуктов и личный опыт команды. Потом систематизировали огромный пул сценариев — и получилась сценарная таблица знаний о продукте.

17 ноября 2018 года. Нас четверо. Настроение у всех приподнятое — прошли первый этап ШРИ, Школы разработки интферфейсов. Он состоял из лекций и домашних заданий: осваивали разные фронтендерские и околофротендерские технологии, инструменты, Скрам. Знали, что всё это придётся применять в боевом проекте на втором этапе. Но одно дело знать, и другое — действительно реализовать этот проект за ближайшие 5 недель.

Что делать, если ваш запрос к базе выполняется недостаточно быстро? Как узнать, оптимально ли запрос использует вычислительные ресурсы или его можно ускорить? На последней конференции HighLoad++ в Москве я рассказал об интроспекции производительности запросов — и о том, что даёт СУБД ClickHouse, и о возможностях ОС, которые должны быть известны каждому.



Каждый раз, когда я делаю запрос, меня волнует не только результат, но и то, что этот запрос делает. Например, он работает одну секунду. Много это или мало? Я всегда думаю: а почему не полсекунды? Потом что-нибудь оптимизирую, ускоряю, и он работает 10 мс. Обычно я доволен. Но все-таки я стараюсь в этом случае сделать недовольное выражение лица и спросить: «Почему не 5 мс?» Как можно выяснить, на что тратится время при обработке запроса? Можно ли его в принципе ускорить?

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


— CatBoost у нас живет на GitHub под лицензией Apache 2.0, то есть открыт и бесплатен для всех. Проект активно развивается, сейчас у нашего репозитория больше четырех тысяч звездочек. CatBoost написан на C++, это библиотека для градиентного бустинга на деревьях решений. В ней поддержано несколько видов деревьев, в том числе так называемые «симметричные» деревья, которые используются в библиотеке по умолчанию.