Не так давно мы проводили Яндекс.Блиц – соревнование по алгоритмическому программированию. Соревнование удалось: в финал пробилось более трёхсот участников, из которых двое сумели решить все предложенные задачи! Двадцать финалистов приехали в офис Яндекса, познакомились с руководителями различных сервисов и больше узнали об устройстве современных поисковых систем.

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

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

Квалификацию ML-блица можно будет пройти с 11 по 17 июня, а 23 июня состоится финал. Итоги соревнования будут подведены 25 июня. Для участия необходимо вовремя зарегистрироваться!

Почти три года назад мы выложили в опенсорс DivKit — наш BDUI‑фреймворк для отрисовки интерфейса приложения из ответа сервера. С его помощью вы можете описать элементы, состояния и анимации на бэкенде. Приложение получит это JSON‑описание и отобразит его.

Мы не перестаём развивать DivKit и за последние месяцы добавили несколько важных функций. О них расскажем в статье.

Привет, меня зовут Никита, я iOS‑разработчик в Яндекс Диске. В прошлый раз я рассказывал, как мы начали свой путь в SwiftUI. Теперь настало время рассказать ещё об одном фреймворке, который мы затащили в свой проект параллельно со SwiftUI, — Combine.

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

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

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

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

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

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

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

В этой статье я расскажу, как мы построили модель для генерации субтитров и на что нам пришлось пойти, чтобы она стала потреблять в 5 раз меньше оперативной памяти. А ещё поговорим про квантизацию свёрток и трансформеров и почему fp16 не так прост, как кажется.

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

Зрелым командам такие метрики ощутимо помогают:

• замечать периоды низкого перформанса команды и нехватку ресурсов;

• следить за такими показателями, как общая забагованность сервиса, время реагирования на различные события, количество задач, которые одновременно может обрабатывать команда, и за другими важными моментами;

• сравнивать показатели работы команд в подразделении перед предстоящим периодом ревью.

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

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

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

Помимо обзорной информации, под катом — истории о том, почему нельзя просто взять и добавить настройки в виджет (спойлер: можно случайно удалить виджет установившим его пользователям), и как даже новейшие Swift-only API иногда страдают от наследия Objective-C. Материал будет полезен как тем, кто привык разбираться во всём новом, находя готовые гайды в интернете, так и тем, кто предпочитает официальную документацию.

Несколько лет назад мне потребовалось очень качественно кластеризовать относительно неплотные графы среднего размера (сотни тысяч объектов, сотни миллионов связей). Тогда оказалось, что алгоритма с подходящим набором свойств просто не существует, несмотря на всё разнообразие методов, придуманных человечеством за многие десятилетия. Имеющиеся решения работали либо просто очень плохо, либо очень плохо и к тому же медленно.

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

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

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

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