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

Казалось бы, что между ними нет ничего общего, но это не так. Абсолютно все эти компоненты объединяет одно — языковая модель. Чем выше её качество, тем выше скорость ввода, а значит, и пользователь будет чуточку счастливее.

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

Голосовые ассистенты активируются «по имени» — это всем привычно. Но как быть, если нужно несколько раз повторять команду из одного слова? Например, чтобы настроить музыку, говорить каждый раз «Алиса, громче» и «Алиса, дальше» утомляет. Кроме того, в некоторых сценариях важна скорость выполнения действия: например, когда нужно включить свет в комнате. 

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

Лавка — сервис быстрой доставки продуктов. Один из важнейших сценариев использования сервиса для покупателя — это поиск. Примерно 30% товаров добавляются в корзину именно из его результатов. А ещё, если в пользовательской сессии был успешный запрос в поиск, вероятность совершения заказа вырастает на 10–15%. То есть, если клиенту нужен конкретный продукт и он его быстро находит через поиск, вероятность совершения заказа становится выше.

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

Привет. Я Марат Сибгатулин — сетевик в Яндексе, работаю в команде Yandex Infrastructure. И сегодня я расскажу вам одну поучительную историю.

Жили были два сервера. Да и не сервера вовсе, а виртуальные машины. Жили не тужили, добро наживали, скриптами разными обрастали. Три года они трудились на славу облака да во имя автоматизации. Пока не наступили чёрные дни для RAID-массива на гипервизоре.

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

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

Меня зовут Лена и я фронтенд-разработчик Яндекс Музыки. В этой статье я расскажу про особенности работы SmartTV и разработки под них на примере свежей фичи, которую мы назвали Время клипов. Теперь в приложении вы можете посмотреть клипы любимых артистов и открывать для себя новых исполнителей, которые подходят вам по настроению.

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

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

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

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

Всем привет! Меня зовут Шико, я работаю в Яндекс Маркете в команде Android-разработки. Сегодня я расскажу историю, которая случилась в 2021 году. Как-то раз я вызвался добавить в мобильное приложение AR (то есть, дополненную реальность). Оно нужно, чтобы товар можно было «примерить» в интерьер.

Сначала я расстроился: показалось, что ничего особо интересного не будет — всего-то подключить ARCore и делов. Но это ровно до тех пор, пока не выяснилось, что большинство файлов моделек было в USDZ-формате, а ArCore на тот момент с ним не работал. То есть, когда на iOS в процессе разработки таких проблем не возникало, нам нужно было придумать способ перевести существующие модельки в другой формат — GLB. Казалось бы, скачай конвертер и нажми на кнопку «Конвертировать». Не тут-то было. 

И в этой статье я расскажу, какие методы конвертации я пробовал, почему они не подошли и с чем не смогли справиться Blender и Unreal Engine. Спойлер: в итоге мне пришлось написать собственный плагин и я покажу его код.

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

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

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

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

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

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

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

Сегодня мы выпускаем в open-source собственную библиотеку MockWebServer DSL. Она помогает удобно писать обработчики запросов на бэкенд в Android-тестах.

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

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

Пост рекомендуется к прочтению:

— мобильным разработчикам и техлидам, чтобы почерпнуть идеи для реализации метрик и ускорения приложений;

— продуктовым и техническим менеджерам для осознания, что можно довольно дешёвыми способами ускорить приложение;

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

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

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

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

Всем привет! Меня зовут Иван Ситкин, я бэкенд-разработчик в Едадиле. Сегодня я хочу поделиться с вами историей написания очередной панели администрирования и как из этого мы собрали подходящие подходы и практики.

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

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

А теперь вы готовы погрузиться в эту кроличью нору.

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

Меня зовут Полина Белобородова, в Яндекс Go я руковожу командой аналитики новых продуктов в рамках эффективности платформы. И сегодня расскажу про то, как мы придумывали, тестировали и запускали тариф для поездок с попутчиками «Вместе».

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

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

Раздел «Транспорт» — один из самых популярных в Яндекс Картах: там автобусы, троллейбусы и трамваи перемещаются прямо по карте в реальном времени, а для каждой остановки есть виртуальное табло. Можно посмотреть, сколько ещё ждать транспорт, или понять, когда лучше выходить из дома, чтобы его не пропустить. А если оказались в незнакомом районе — узнать, как быстрее добраться домой, и сразу найти ближайшую остановку или станцию метро.

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

Привет, меня зовут Сергей Качеев, я старший разработчик в отделе сетевой инфраструктуры Яндекса. Сегодня я расскажу целый сетевой детектив о том, как мы искали баг, который убивал DNS сервер Unbound. Приготовьтесь, он будет долгим.

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

В самом начале на графиках нагрузочного тестирования я увидел очень плохие результаты: случайным образом абсолютно все запросы нагрузочного теста таймаутились, но сервер, который был под нагрузкой, никак не реагировал на проблему. Как выяснилось позже, по чистой случайности я допустил ошибку в конфигурации нашего плагина Pandora, и в итоге он сам ходил в DNS на каждый запрос, чтобы узнать ip адрес тестируемого сервера. Возможно, это сыграло мне на руку и помогло найти первую из проблем, а потом и вовсе задало вектор поисков остальных багов. А в Unbound их накопилось достаточно.