Да кто такой этот ваш 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.

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

Simple Storage Service или S3 — сервис (и одновременно протокол) для хранения данных большого объёма. Для работы использует API поверх HTTP, который позволяет загружать или получать объекты из хранилища.

В проектах с приватной инфраструктурой часто возникает потребность в организации on-premise S3-хранилища. Популярное решение в таком случае это MinIO — удобная и довольно простая в использовании реализация сервиса S3.  Когда нам в RUTUBE потребовалось S3, мы не стали долго думать и взяли MinIO, потому что он стильный, модный, молодежный хорошо себя зарекомендовал на рынке, хорошо документирован и прост в первоначальной настройке и эксплуатации. 

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

За полгода с июля 2024 года большинство аудиторных и технических показателей RUTUBE выросло в разы: количество ежедневных пользователей выросло почти в 4 раза; количество видео, ежедневно загружаемых на видеохостинг — в 3 раза, с 330 тыс. до 1 млн единиц контента; CDN-трафик — в 4 раза и в пиковые часы превышает 7 Тбит/с. Как архитектура сервиса показала себя в условиях продолжительного «нагрузочного тестирования» и как команда переживала такой рост нагрузки, читайте в этой статье.