Случалось ли вам, выполняя какую-то задачу, понять, что самый простой путь — нажать Сtrl+C, Сtrl+V: перетащить из соседней папочки пару файлов, поменять пару строчек, и будет ок? Повторялось ли это ощущение? Я хочу рассказать о том, как боролся с этой проблемой и к чему пришёл вместе с командой. Назовём это решение «универсальные компоненты» (если у кого-то будет более удачное название для концепции, жду в коментариях). Примеры буду приводить в основном на React, но концепции будут общие.

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



Почему в распределённом обучении нельзя доверять утилизации GPU? Почему переход в эру распределённого обучения — фундаментальный сдвиг парадигмы мышления, к которому должен быть готов каждый ML-разработчик? Ещё больше «Почему» и ответов на них — под катом.

Сегодня мы выложили в опенсорс систему управления базами данных YDB — плод многолетнего опыта Яндекса в разработке систем хранения и обработки данных. Исходный код, документация, SDK и все инструменты для работы с базой опубликованы на GitHub под лицензией Apache 2.0. Развернуть базу можно как на собственных, так и на сторонних серверах — в том числе в любых облачных сервисах.



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

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

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



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

Первые попытки, которые мы предприняли, должны были решить проблему малой кровью. Этот подход оказался наивным, но он принёс нам опыт, которым я хочу поделиться с другими разработчиками в этом посте. Под катом расскажу, почему работа над доступностью — это прежде всего работа над UX, а уже во вторую очередь — над API. Покажу примеры, когда эвристики системного скринридера приносили больше вреда, чем пользы. Объясню, почему для работы над доступностью нам потребовалась помощь ещё и бэкендеров.

Приложению Яндекс Go ещё далеко до идеала, нерешённых проблем хватает. Но, надеюсь, накопленный нами опыт поможет другим.

В сентябре мы рассказывали Хабру о том, как наша команда помогает преодолевать языковой барьер с помощью перевода видео. Эта функция позволяет автоматически переводить видео так, чтобы зритель сразу слышал русскую речь. Пользователи встретили новую возможность тепло: ролики с переводом смотрят больше 200 тысяч раз в день.

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

Очень много вопросов по этой теме. Оно и понятно: информации мало, противоречивых интерпретаций много. Для нас тема защиты соединений с сайтами близка. Мы пишем на Хабре об этом уже лет восемь. Например, в своё время мы первыми поддержали DNSCrypt прямо в браузере, первыми начали предупреждать о неизвестных корневых сертификатах в системе, первыми включили шифрование трафика для незащищенных Wi-Fi-сетей.

Поэтому сегодня мы расскажем сообществу о происходящем чуть более подробно. Тем, кто очень спешит и хочет получить короткие ответы, достаточно прочитать начало поста. Поехали.

Коротко о главном

1. Национальный удостоверяющий центр выдаёт сертификаты на домены только тех организаций, которые явно это запросили. Полный список этих доменов публично доступен по адресу www.gosuslugi.ru/tls.
2. Яндекс Браузер применяет национальные сертификаты не для всего рунета, а только на тех сайтах, которые есть в списке на www.gosuslugi.ru/tls. Попытка применить сертификат на других доменах приведёт к стандартной ошибке и недоступности сайта для пользователя.
3. Национальные сертификаты используют общепринятую открытую криптографию и работают по стандартным правилам (это обычный RSA с длинным ключом, ровно такой же, какой выписывают другие центры сертификации).
4. Мы работаем над поддержкой стандарта Certificate Transparency и планируем создать публичный лог, в который будут вноситься все выпускаемые национальным центром сертификаты. Мы надеемся, что другие представители индустрии поддержат эту инициативу и запустят дополнительные публичные логи. Это позволит добиться прозрачности в работе с национальными сертификатами.

_{По запросу [форма] мы должны угадать, что именно нужно покупателю: выпечка, наращивание ногтей, косплеить медсестру или калибратор кубов бетона. Задача — быстро понять, кто перед нами и что сделает человека счастливым.}

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

Человек может:

• Формулировать требования к покупке по мере сравнения вариантов.
  
  
  Пример с соковыжималкой

  Предположим, он ищет соковыжималку, но ещё не знает, какие они бывают. По мере изучения товаров он примерно начинает понимать, что хочет. На старте у него нет ни фиксированного бюджета, ни требований, только мечта. Дальше нужно сопоставить мечту с конкретной карточкой товара. С точки зрения метрики покупки, пользователь будет довольно долго бесцельно бродить в начале — но мы понимаем, что эта часть была очень важна, там он изучал предложение и понимал, как устроен мир.
• Приходить с примерным бюджетом и выбирать что-то под него, например, при поиске подарка. В этой ситуации у пользователя даже нет мечты, он ходит по категориям и ищет что-то, что его «зацепит».
• Более-менее точно понимать, что хочет купить (часто вплоть до модели товара), но искать лучшее предложение.
• Знать модель товара и проверять, насколько честна цена на неё, насколько хороши отзывы и так далее.

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

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

Без лишних слов, прямо к делу — вот какие новые вкусности будут нас ждать в C++23:

• std::expected — новый механизм сообщения об ошибках без использования исключений и без недостатков кодов возврата.
• constexpr-математика — теперь на этапе компиляции можно доставать разные части чисел с плавающей запятой, копировать знаки и округлять числа.
• std::ranges::to — результаты работы алгоритмов можно легко превратить в контейнер.
• std::views::join_with — добавление разделителя между элементами.

Что мы не увидим в C++23, на что ещё можно надеяться и что ещё приняли в текущий черновик стандарта? Всё это ждёт вас под катом.

Test-driven development — по-прежнему спорная тема. Часто встречается обоснованное, в общем-то, мнение, что такая разработка нужна только большим компаниям, потому что только у них достаточно ресурсов для создания и поддержки большого количества тест-кейсов. Но сегодня на примере iOS-приложения Маркета я покажу, что стремление как раз обратное: хочется, чтобы тесты поглощали как можно меньше времени разработчиков.

Меня зовут Даша, работаю в команде iOS-разработки Яндекс.Маркета. Два года назад мы поняли, что без автотестов нам тяжело: с их помощью мы снизили вероятность крешей после релиза и ускорили регрессионное тестирование. Релизы приложения происходят еженедельно, и это большая нагрузка на тестировщиков и разработчиков — протестировать всё руками и быстро внести правки за несколько дней не получилось бы. Я постараюсь порефлексировать и рассказать, как эволюционировал наш подход к UI-тестам за это время, и, более конкретно, какие работы мы провели для их «улучшения»: почему решили избавиться от JSON-моков и как справились с этой задачей.

Привет! В этой статье я расскажу об устройстве асинхронных движков с корутинами и без них. Для начала сосредоточимся не на конкретном движке, а на том, почему во всех популярных языках программирования появились корутины и чем они так хороши. Это может быть интересно не только C++-разработчикам, но и всем, кто занимается разработкой сетевых приложений или интересуется архитектурой современных фреймворков.

Пройдёмся по разным архитектурам построения серверов — от самой простой синхронной к более интересным, посмотрим на типичную архитектуру корутинового движка, а после окунёмся в дебри C++ и взглянем на самое страшное на примере нашего фреймворка userver.

Пишем синхронный сервер

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

void naive_accept() {
  for (;;) {
    auto new_socket = accept(listener);

    std::thread thrd([socket = std::move(new_socket)] {
      auto data = socket.receive();
      process(data);
      socket.send(data);
    });

    thrd.detach();
  }
}

Привет! Меня зовут Сергей Кляус, и я как разработчик виртуальной сети сопровождаю создателей приложений, размещённых в Yandex.Cloud. При этом диагностические возможности самого облака ограничены: мы не видим метрики пользовательских виртуальных машин, например количество TCP retransmissions, а записывать и анализировать огромные дампы всего сетевого трафика с помощью tcpdump дорого и трудно из-за ограничений безопасности.
К счастью, динамическая трассировка позволяет получить лучшее от двух миров: исполнять произвольный код в момент увеличения метрики, а в самом коде печатать тело пакета. Например, недавно мы диагностировали проблемы с TCP-соединениями у одного из наших managed-сервисов, и оказалось, что теряются на самом деле UDP-пакеты. Гипотеза требовала уточнения, хотя корреляция между ростом метрики и сбоем была поначалу очевидна. В современном Linux динамическая трассировка реализована через eBPF и утилиту BPFTrace, но постепенно мы накопили набор типовых сценариев их использования и сделали обёртку над BPFTrace. Она называется skbtrace и доступна на GitHub. Про неё я и расскажу под катом.

Data Transfer Object — модель данных, которые мы передаём из одного слоя приложения в другой. В Яндекс Go мы активно используем DTO. Предположим, нужно отобразить в UI приложения для вызова такси экспериментальную кнопку с двумя свойствами — надписью на кнопке и ориентировочным временем ожидания такси. Тогда в сетевом слое надо написать примерно такую DTO-модель:

struct OrderButtonExperimentDTO: Decodable {
   let buttonTitle: String
   let estimationMinute: Int
}

Правильно написанная модель позволяет разрабатывать разные слои приложения независимо — но нужно следить за актуальностью самой модели на каждом слое. Например, если в коде выше ожидалось не estimationMinute, а estimationMinutes, то клиент не сможет декодировать полученные из сети данные и пользователь не увидит время ожидания. Такую ошибку легко совершить, в n-й раз перепечатывая названия переменных под каждый слой — а разработчики и правда должны рутинно это делать при любом изменении (или расширении) исходного формата данных. Ещё сложнее заметить ошибку на код-ревью.

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

Фулфилмент — весь путь вещи, заказанной вами в интернете, до порога вашего дома. Он начинается где-то на далёком складе: вещь нужно найти, собрать и упаковать. Этот этап не всегда простой, он гораздо менее заметен, чем доставка, но не менее интересен. Сейчас я постараюсь вам это доказать.


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

Меня зовут Илья, я отвечаю за инфраструктуру пользовательских продуктов в Яндекс Go. Мы строим цикл заказа такси — процессы, происходящие под капотом после того, как пользователь нажимает «Заказать». Поиск машины, назначение водителя, изменение адреса, оплата поездки — всё это части цикла. Ещё мы делаем инфраструктуру создания циклов, которая используется в Еде, Лавке, Доставке и других направлениях внутри Яндекса.

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

Как всё начиналось

В 2011 году мы запустили сервис заказа такси. В первой реализации в бэкенде был endpoint /create-order, внутри которого мы создавали заказ, искали ближайшую машину и отправляли заказ водителю (кстати, если вы не знали о том, как устроен поиск водителя, то обязательно почитайте).

Краудсорсинг позволяет размечать данные для разных задач, но популярнее всего, конечно, задачи классификации объектов — текстов и картинок. Обычно в краудсорсинге несколько человек размечают каждый объект, что требует агрегации — выбора верного ответа из представленных. Под катом я покажу, как агрегировать результат разметки с помощью двух алгоритмов: голоса большинства и алгоритма Дэвида-Скина.

Я буду использовать Crowd-Kit — нашу открытую библиотеку вычислительных методов контроля качества в краудсорсинге, которая предлагает реализации разных методов агрегации ответов, оценки неопределённости и согласованности ответов и т. д. Но вы можете воспользоваться альтернативами: spark-crowd (использует Scala вместо Python), CEKA (Java вместо Python) или Truth Inference (использует Python, но предоставляет только категориальные и числовые ответы).

В приложении Авто.ру есть такая фича — панорамы автомобилей. Она позволяет любому сделать 3D-фото своей машины, показать её во всей красе. Как это работает и как нашим коллегам из ML удалось уместить в смартфон то, что раньше требовало целого ангара, напичканного дорогостоящим оборудованием, yaantonn уже рассказывал на Хабре.

Но отснять панораму — лишь полдела. Затем её предстоит воспроизвести, причём сделать это одинаково хорошо и на топовом флагмане, и на бюджетном смартфоне.

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

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

Сейчас мы переходим на следующий уровень: учим Алису управлять эмоциями и стилем своей речи, распознавать шёпот и отвечать на него шёпотом. Казалось бы, что в этом сложного и почему всё это было невозможно ещё несколько лет назад? Вот об этом я и расскажу сегодня сообществу Хабра.

Меня зовут Максим Бабенко, и, может быть, вы знаете меня как преподавателя ШАДа (или как автора рассказа про технологию YT на Хабре).

Мне кажется, почти каждый читатель Хабра либо знаком с теми, кто побывал на собеседовании в Яндекс, либо сам его проходил. Несмотря на это, процесс интервью не всегда очевиден для людей извне, по-прежнему вызывает множество вопросов и окружён мифами. Некоторые из них близки к правде, другие — наоборот.

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

Привет! Меня зовут Наташа, я руковожу разработкой бэкенда страницы yandex.ru. Сейчас у нас в команде больше двадцати человек, которые входят в отдельные группы разработки. Три года назад я впервые стала «тимлидом» маленькой группы из четырёх человек, накопив к этому времени десяток лет опыта в разработке и эксплуатации. Я не стесняюсь сказать, что переход от разработчика к тимлиду дался мне тяжело — и это нормально!

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

Встречайте! Мы выпустили на улицу роботов третьего поколения — модель R3 уже можно встретить в Москве, Иннополисе и США. До конца года мы планируем произвести больше сотни таких роботов, и в дальнейшем будем расширять флот за счёт них.

Меня зовут Алексей, я работаю в Yandex Self-Driving Group: несу ответственность за разработку железа трёх (с половиной) поколений роботов Яндекса. В этой статье я не только коротко расскажу про новое поколение, но и поделюсь историей создания роботов-курьеров. Вы сможете взглянуть их глазами на велосипедиста, узнаете, как собрать прототип из фанеры и трёх гироскутеров, а также почему мы выбрали менее дальнобойные лидары. Всё это я дополню роликами и фотографиями разных этапов разработки. Поехали!