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

Разберем способ удобного хранения 35 000 файлов домашней коллекции, которая используется на 3 ПК и 2 телефонах с использованием git-annex.

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

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

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

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

Кроме технических графиков, вас ждёт ещё и наглядная разница в работе алгоритмов сжатия на примере «Рика и Морти» и «Джона Уика».

Поддержка языков с направлением текста справа налево (RTL), таких как арабский, — важная часть разработки Android-приложений. C помощью следующих шагов можно легко настроить RTL.

Большое слово — Mocap

Backend Driven UI (BDUI) — это подход, при котором сервер управляет не только данными приложения, но и формирует интерфейсы, включая экраны, верстку, реакции на действия пользователя и переходы между экранами. Клиентская часть сводится к рендерингу интерфейсов на основе полученных с сервера данных.

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

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

21 августа команда Yandex Cloud в формате Technical Preview открыла пользователям облака доступ к сервису для хранения, обработки и трансляции видео Cloud Video. Это инфраструктура для работы с видео, которая включает хранилище для контента и метаданных, видеоплеер, сервисы мониторинга и аналитики, CDN, а также возможности автоматической генерации субтитров и перевода. Сервис разработан на базе видеоплатформы Яндекса, которую компания запустила в 2016 году для использования во внутренних продуктах.

Меня зовут Константин Петряев, я разработчик в Yandex Infrastructure, и в команде видеоплатформы я 6 лет занимаюсь разработкой плеера. Моя коллега Оля Попова уже рассказала об истории его создания с нуля. А в этой статье я подробнее расскажу про задачу повышения качества видео в плеере. Остановлюсь на том, как мы боролись с тем, что стандартные прогнозы качества потокового видео всем нам «врут», и как научили плеер выдавать наилучшее возможное качество видео для пользователя, с учётом параметров сети и других менее очевидных вводных.

Вот уже несколько недель я разрабатываю серверную поддержку коротких видео для компании Bluesky.

Основное назначение этой фичи – обеспечивать потоковый показ небольших (максимум 90 секунд) видеороликов. Показ должен быть бесплатным и при этом не слишком накладным для нас.

Чтобы укладываться в эти ограничения, мы попытались использовать сеть доставки видео-контента (CDN), которая могла бы нести основное бремя поддержки той полосы передачи данных, которая обеспечивала бы показ потокового видео по требованию.

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

К нам обратился заказчик из сфера развлекательного видеостриминга с интересной проблемой - у него сервера падали не одновременно. А очень хотелось бы добиться синхронности.

Сервера, которые смущали заказчика работали в роли бэкенда для хранения видеофайлов. По сути, это было множество узлов, содержащих десятки терабайт видеофайлов, которые предварительно были нарезаны в разном разрешении конвертерами. Затем, все эти миллионы файлов отдавались во внешний мир с помощью nginx + kaltura, что позволяло перепаковывать на лету mp4 в сегменты DASH/HLS. Это позволяло хорошо переносить даже высокие нагрузки, отдавая плеером только нужные сегменты без резких всплесков.

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

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

Я, как разработчик сервиса вебинаров, постараюсь в этой статье помочь разобраться с этими проблемами, по средствам P2P-сетей.

Привет, Хабр.

Последнее время DevOps и CI/CD де-факто стали повсеместным стандартом независимо от размера команды, в интернетах хватает статей, почему это важно, в чём собственно идея, полезных практик и других материалов. Я же решил подойти с несколько другой стороны и максимально доступным языком на практических примерах рассмотреть отдельные задачи и их решения в рамках концепции.

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

Кому, собственно, это может пригодиться? Я бы сказал, что почти кому угодно, кто хочет организовать ту компоненту CI/CD, которая отвечает за построение и релизный цикл базовых образов внутри инфраструктуры вашей компании или даже персональных проектов (зародился он именно в процессе приведения в порядок моих пет-проектов).

Какой практический пример может быть без публичного репозитория с MIT-лицензией? Если вам не интересно читать статью, то можно прямо из превью перейти по ссылке и напитаться кодом. Репозиторий же можно копировать как целиком, так и кусками, буду только рад, если он кому-нибудь пригодится. На любые вопросы — готов ответить в комментариях или issues.

Мобильная разработка под iOS особенная: собрать приложение можно только на macOS, среда разработки по сути только одна, большая часть принятого в сообществе тулинга написана на Ruby, свой пакетный менеджер появился только пару лет назад. Тяжко.

А когда речь заходит про автоматизацию тестирования и сборок — тушите свет: Xcode Cloud появился полгода назад и почти ничего не умеет, популярные облачные решения могут месяцами не обновлять стек на новые мажорные релизы среды разработки или ОС (вставить ссылку на тред где гитхаб не может привести новую макось уже полгода), а ценник при этом может быть в 10 раз больше, чем за машинки на Linux. Ещё тяжелее.

Меня зовут Леха Берёзка, я iOS-техлид в Додо Пицце и сейчас я расскажу как мы собрали свой CI на М1, с виртуализацией и на полном нативе.

Давайте знакомиться! Меня зовут Игорь. Я разработчик кроссплатформенных мобильных приложений в компании Smartex. В этой статье я расскажу о NativeScript, основных преимуществах платформы и ее недостатках.

Материал будет полезен не только разработчикам, которые уже пишут приложения на React Native, Ionic, Framework7, а также тем, кто собирается погрузиться в разработку кроссплатформенных мобильных приложений на JavaScript.

Погнали!

Свой путь в кроссплатформенную разработку я начал за пределами Smartex, с Cordova + Framework7.

Framework7 это как и Ionic просто UI-библиотека для создания интерфейса которая в последующим просто отрисовывается через WebView. Само приложение (общение с API платформы) создается на платформе Cordova или Capacitor, как раз они и создают экран с WebView и транслирует туда HTML.

Framework7 прекрасно работает с Vue, но по ряду причин он начал меня подбешивать. Я хотел найти инструмент именно для нативной разработки, а не на технологии основанной на WebView. Стал смотреть в сторону Angular, и какие вообще есть на рынке технологии для разработки нативных кроссплатформенных приложений с Angular под капотом. Так я и познакомился с NativeScript.

С постоянным ростом размеров дистрибутивов игр и увеличением числа игроков по всему миру, разработчики сталкиваются с необходимостью эффективной дистрибуции своих продуктов. Одним из подходов, которые обеспечивают высокую скорость и надежность передачи данных, является использование протокола BItTorrent. В данной статье я хочу рассмотреть как разработчики и операторы онлайн-игр могут воспользоваться (и частенько пользуются) данной технологией для оптимизации процесса распространения и поделиться опытом ее построения.

Привет, меня зовут Мария, когда-то я работала на шахте, потом на заводе, а 3.5 года назад пришла в Ozon Tech. Сейчас я старший Golang-разработчик в команде product-facade. Это самый высоконагруженный сервис маркетплейса, но так было не всегда.

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

Всем привет! Попробую написать трилогию покорения основ Python, отражающую мой путь любителя с “паяльником”. Тут не будет основ, чистого кода, отсылок к требованиям PEP-8, практически не будет ООП.

Всех суровых Senior’ов, читающих данный материал, прошу понять и простить. Я не работаю и никогда не работал разработчиком (по крайней мере пока, но открыт к предложениям:)), не учил алгоритмов (кроме пузырька) и многого не знаю. Мне просто интересно, как мне кажется, “программировать”, а иногда даже хочется поделиться своим опытом.

Итак, что же мы будем делать. Это будет новостной ТГ-канал - новости в него будут попадать с новостного сайта с RSS-лентой. Администратор сможет модерировать новости, прежде чем они попадут в канал через ТГ-бот. Также возможна реализация автоматического рерайта/перевода новостей при помощи Chat-GPT или иной текстовой AI.

В процессе работы мы “пощупаем” работу с внешними библиотеками (их будет достаточно много) и виртуальным окружением venv, спарсим RSS-ленту и страницу новостей, заглянем в мир асинхронного Python, коснемся основ работы с SQLite и даже попробуем задеплоить нашего бота на VSD-сервер через Docker-контейнер.. если у меня хватит на описание всего этого времени и сил:)

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

Для хорошего старта всем начинающим и слабо ориентирующимся в синтаксисе Python рекомендую посмотреть вводный курс CS-50. Тут ссылка на свежую версию на-английском, на просторах YouTube есть более древняя, но переведенная на русский версия.

Доброго вам времени суток! Меня зовут Валерия, я фронтенд-разработчик из компании Doubletapp. Год своей жизни отдала на разработку видеоплеера с рекламными интеграциями. На старте была только спека, дока, единственная статья на Хабре, поясняющая за рекламу, и огроменное желание заказчика накрутить оную на видеоплеер. Пришло время и вас поближе познакомить с рекламой.

Статья подойдет тем, кто хочет разобраться в специфике работы VAST и VPAID, настроить кастомное управление рекламой, разместить видеорекламу отдельным блоком на сайте (out-stream) или разбить видеоролик рекламными интеграциями (in-stream).

  • Инструментарий, или Основные ингредиенты
  • Подробнее о VAST
  • Запускаем рекламный блок на странице (out-stream)
 • Подключаем IMA SDK
  • Инициализируем
  • Обрабатываем ошибки
  • Обрабатываем событие ADS_MANAGER_LOADED
  • Запрашиваем и воспроизводим рекламу
  • Продвинутое управление (въезжаем в обработку событий рекламы)
  • Локализация
  • Адаптивность
  • Обработка событий
• Разбиваем видеоролик рекламными паузами (in-stream, VMAP)
  • Подробнее о VMAP
  • Подключаем VMAP к видеоплееру
  • Ручное управление стартом рекламы
  • Особенности VPAID

Привет! Меня зовут Денис, я мобильный разработчик в СберМаркете. Пишу на React Native и люблю анимации, ведь они дают жизнь нашим проектам :)

В этой статье попробуем разобраться, что же все таки работает быстрее: React-Native-Reanimated или Animated + useNativeDriver: true.

Будем сравнивать FPS, нагрузку на процессор, оперативную память и воспользуется EventQueue для получения логов.

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