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 для получения логов.

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

1. OpenAI может работать с вашей базой, например, вики техподдержки, но её надо векторизовать. Получится, что модель только ищет по ней и может отвечать фрагментом исходника, но может его обрабатывать как текст (то есть сравнивать, анализировать и тому подобное).
2. Дальше можно использовать подход QA Retrieval Chain для работы с векторной базой. Работает это так: задаём вопрос, LLM формируют запрос к векторной базе, мы вынимаем из неё данные, подкладываем их в вопрос как контекст и передаём в LLM, а они формируют ответ.

1. Какого размера промпты могут быть, сколько, какие лимиты, как их частично обходить.
2. Как подключается база, как закидывать реально большие документы, как эмбеддится вектор, на каких языках это происходит и тому подобное.
3. Разные API.
4. Агентная модель GPT Engineer и АutoGPT.
5. Фреймворк лангчейн (построение цепочек запросов и разбиение макрозапроса на сотни).

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

Сегодня расскажем о том, как в мобильной версии Squadus реализовали востребованную функцию — «прыжок к сообщению» в чате (jump to message).

Для чего современным чатам нужна эта возможность? Прыжок позволяет «отмотать» чат от цитируемого сообщения к оригиналу. Открыть чат, который игнорировался пару дней, не с последнего сообщения, а с момента прошлого открытия. Или отыскать в истории нужное сообщение двухгодичной давности, которое во время жаркой дискуссии можно привести собеседникам как сильный аргумент. Наконец, благодаря функции пользователь может оказаться в нужном чате и на нужном месте в истории сообщений, просто кликнув push-уведомление.

О технических аспектах реализации «прыжка к сообщению» читайте под катом.

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

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

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

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

То, что ChatGPT может автоматически генерировать что-то, что хотя бы на первый взгляд похоже на написанный человеком текст, удивительно и неожиданно. Но как он это делает? И почему это работает? Цель этой статьи - дать приблизительное описание того, что происходит внутри ChatGPT, а затем исследовать, почему он может так хорошо справляться с созданием более-менее осмысленного текста. С самого начала я должен сказать, что собираюсь сосредоточиться на общей картине происходящего, и хотя я упомяну некоторые инженерные детали, но не буду глубоко в них вникать. (Примеры в статье применимы как к другим современным "большим языковым моделям" (LLM), так и к ChatGPT).