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

Именно таким и был наш первый MVP в RUTUBE — сервис на базе Whisper, который позволил быстро проверить гипотезу и запустить субтитры в production. Но очень быстро стало понятно, что между «распознать речь» и «сделать субтитры для всего контента» лежит огромный пласт работы.

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

В статье расскажу, почему Whisper не подошел для production, как мы перестроили всю архитектуру и за счет чего смогли выйти на производительность около 1200 видео в час на один ASR.

Угадаете, какое изобретение кардинально изменило жизнь человечества?

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

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

Что должен делать разработчик, чтобы проект, над которым он работает, не имел проблем? Очевидно — нужно просто исправить все баги и больше не писать новых. 

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

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

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

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

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

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

У аббревиатуры BFF кроме Backend for Frontend есть и другая расшифровка — Best Friends Forever. И в контексте статьи это только отчасти шутка. Общение фронтенда и бэкенда не всегда происходит гладко (опустим тот факт, что существует множество мемов о противостоянии фронтендеров и бекендеров): клиент запрашивает данные, бэкенд отдаёт то, что запросили, но часто данных сильно больше, чем нужно, а это значит, что запрос будет возвращаться дольше, фронтенд будет отрисовываться тоже дольше и всё это отразится на опыте конечного пользователя.

А что если между фронтендом и бэкендом построить мостик, который распределит нагрузку и сделает всех дружелюбнее? Примерно в этом и состоит суть паттерна BBF, а в статье разберём подробнее: зачем его внедрять и какую роль он играет в масштабировании современных сервисов; как мы реализуем этот подход в рамках RUTUBE, какой профит он нам даёт; почему мы отказались от GraphQL; в чём отличия от API Gateway и как вообще проектировать такие сервисы.

Можно ли чем-то заменить Nvidia? Если уж не для нейросетей, то для транскодирования видео, которое в медиапроизводстве занимает очень значительное место и требует больших вычислительных ресурсов. 

В этой статье попытаемся выяснить, есть ли у аппаратной платформы NVIDIA альтернативы в задачах обработки и кодирования видео, и можно ли заменить NVIDIA чем-то более доступным во всех смыслах: и по возможности закупки на рынке РФ, и по цене.

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

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

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

Привет! Меня зовут Даша Боровик, я руковожу командой экспертов по клиентскому опыту в RUTUBE. База юзабилити-проблем сервиса — одно из детищ нашей команды. Как и многие в индустрии, мы сталкиваемся со сложностями в управлении CX-долгом и ищем свой подход. 

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

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

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

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

Недавно ко мне обратилась команда дизайна с вопросом о том, как оценить удовлетворенность пользователей новым внешним видом Студии RUTUBE для авторов. 

Существует много известных методологий оценки удобства использования веб-сайтов и приложений (UMUX, SUS и т.д.). Есть также комплексные метрики, где оценка внешнего вида является одним из измеряемых критериев (например, SUPR-Q). Но широко применимых методологий для оценивания именно визуальных характеристик интерфейса, которые подходили бы под наши задачи, нет.

Поэтому мы решили найти или создать методологию оценки восприятия визуальной составляющей дизайна, которая позволила бы узнать мнение пользователей о новом дизайне Студии RUTUBE и могла бы быть использована в будущем для RUTUBE в целом. 

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

В этой статье расскажем, как устроено файловое хранилище RUTUBE с точки зрения SRE, как мы пришли к именно такой конфигурации и как она работает на наших объемах — сейчас это порядка 400 Пбайт и 2 млрд объектов. 

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

Мы, Тимофей Соломенников и Руслан Мирзоев, разработчики онлайн-кинотеатра PREMIER, хотим поделиться своим опытом и на реальных примерах показать, что даёт правильное использование структур данных.

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

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

Меня зовут Даша Боровик. Сейчас я руководитель команды экспертов по клиентскому опыту и доступности в RUTUBE. А пару лет назад передо мной встала непростая задача — внедрить новую роль в компанию и собрать команду с нуля. Я искала материалы, которые бы подсказали мне, что и в какой последовательности делать — но, казалось, ни одна из найденных статей и заметок не подходила мне идеально. 

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

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

Есть только одна маленькая проблема: видеоредактор Yappy кроссплатформенный, написан на Flutter, а до недавнего времени команда фреймворка предлагала только один способ реализовать 2D-скролл — очень не производительный. В статье рассказываю, в чём была была загвоздка, что есть во Flutter сейчас и каких впечатляющих результатов можно добиться собственной реализацией. 

Привет, Хабр! Меня зовут Дмитрий Иванов, я начальник отдела эксплуатации IT-инфраструктуры RUTUBE, что на наши деньги переводится как SRE-тимлид. В этой статье разберу задачу доставки контента и расскажу и решениях, которые помогают нам в RUTUBE. 

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

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

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

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

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

Привет! Меня зовут Костя, я Android-разработчик в онлайн-кинотеатре PREMIER. В процессе работы над проектом PREMIER для AndroidTV я столкнулся с тем, что в Jetpack Compose механизм фокусов — достаточно сложная и неочевидная тема. А информации в интернете об этом очень мало, особенно о специфичных сценариев вроде ТВ-приложений или устройств без сенсорного ввода.

Поэтому я решил разобрать тему фокусов в Compose максимально подробно, чтобы помочь разработчикам лучше понять этот механизм и избежать типичных ошибок. В первой статье на эту тему мы уже разобрали базовую структуру фокусировки в Compose. Теперь пришло время углубиться в технические детали: что именно происходит, когда вызывается requestFocus(), как Compose выбирает элемент для фокусировки и какие изменения были внесены в Compose 1.8, чтобы улучшить этот процесс.

Если вы работаете с приложениями под Android TV, кастомными компонентами или просто хотите лучше понимать, как работает система фокусов, эта статья для вас.

Привет! Меня зовут Костя, я Android-разработчик в онлайн-кинотеатре PREMIER. Среди прочего у нас есть приложение для Android TV. Работая над ним, я столкнулся с тем, что система фокусов в Jetpack Compose устроена сложнее, чем кажется на первый взгляд. Поскольку для ТВ-приложений и устройств без сенсорного управления работа с фокусом играет ключевую роль в навигации, мне понадобилось детально разобраться в теме. Результатами делюсь в статье.

Бизнес без устали тестирует разные гипотезы о том, как логично внедрять customer experience (CX) в производство своих продуктов. От команды к команде опыт подхода к этому «снаряду» отличается. Даже в рамках одной компании бывает, нет единого представления, как «сочетать несочетаемое»: ориентироваться на клиента и при этом зарабатывать деньги.

В RUTUBE мы нашли свой путь: пригласили в продуктовые стримы отдельных сотрудников. Их задача — погружать продуктовую команду в пользовательские запросы и потребности. А фоном — продвигать стратегию (и идеологию) классного клиентского опыта. Мы назвали себя Customer Journey Experts.

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