Сущности (entities) и сервисы (services) как основа распределенной логики для MVC шаблона проектирования

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

Сущности и сервисы

Сущности

Поскольку задачи стали более сложные и комплексные, а данные в БД хранить все невозможно, то было принято решение о создание сущностей статичных данных в проекте. Суть простая — в определенном месте хранятся базовые статичные данные, которыми можно оперировать в PHP коде, а в БД заносятся их англоязычное представление.
В базовом представлении класс Entity.php может иметь следующий вид:

declare(strict_types = 1);  namespace entities;  class Entity { 	protected static $map; 	 	public static function getMap():array { 		return static::$map; 	} }

Наследники его должны реализовать свойство $map, которое будут получать следующим образом:

E1::getMap();

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

Сервисы

Сервисы предназначены для хранения бизнес логики приложения. Помимо этого, сервисы можно использовать как логика отдельная от фреймворка. Сервис — это набор методов, который реализует логику приложения. Условия, которые были определены сервису:

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

В лучшем случае, контроллер должен передавать сервису все необходимые данные, но может возникнуть такая ситуация, что ему потребуется самостоятельно обратиться к какой-то модели, чтобы получить данные. Ничего страшного в этом нет, но лучше придерживаться логики, что маршрутами данных оперирует контроллер.
По умолчанию сервис не реализует никакую стандартную логику, поскольку является уникальным исполнением части проекта. Поэтому, было принято решение, что базовый класс сервиса не будет создан. Хотя, стоит отметить, что базовые классы лучше создавать, даже если они будут пустыми. Это объясняется тем, что может наступить такой момент, что всем наследникам надо будет иметь одинаковую логику или выполнять какой-то метод. Чтобы не производить во всех классах изменения в области наследования, проще изначально сделать наследование от базового класса, в котором реализовать данную ситуацию куда менее сложнее и дешевле в области временных ресурсов.
В общем представлении поток данных в предлагаемой архитектуре можно представить следующим образом:
Схема обмена информацией архитектуры MVC с сущностями и сервисами

  1. Данные или запрос поступает в контроллер.
  2. Контроллер общается с моделью, сервисом и сущностью в двунаправленном порядке. Тут он получает и отдает какие-то данные.
  3. Сервис отдает данные в контроллер, получает или отдает данные в модель.
  4. Контроллер отдает полученные данные в представление.

Таким образом, получается, что данные и принцип работы приложения распределен между базовыми элементами MVC и новыми.

Заключение

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

ссылка на оригинал статьи https://habr.com/ru/post/514670/

Сервис на языке Dart: flutter web-страница

Оглавление

  1. 1. Введение
  2. 2. Backend
  3. 2.1. Инфраструктура.
  4. 2.2. Доменное имя. SSL
  5. 2.3. Серверное приложение на Дарт
  6. 3. Web
  7. 3.1. FlutterWeb страница (мы находимся здесь)
  8. 4. Mobile

Подготовка

В прошлый раз мы закончили на том, что наш веб-сервер получил доменное имя и научился устанавливать безопасное соединение с клиентом. Однако нам пока совсем нечего показать нашему будущему пользователю. Хотя мы уже можем поделиться идеей стартапа и сообщить дату релиза MVP. Для такой задачи подойдёт информационная web-страница. Напишем её на Dart с использованием фреймворка FlutterWeb. Все наши клиентские приложения сервиса станут расширением именно этой страницы. Постараемся вести разработку максимально адаптивно и структурировано, чтобы развитие и сборки под нужные платформы (web-android-iOS) стали просто рутиной.



Начнём с установки Flutter:

  • Установим git
  • Склонируем репозиторий с beta версией Flutter командой
    git clone https://github.com/flutter/flutter.git -b beta
  • Для запуска команд flutter из командной строки необходимо указать в операционной системе путь до его исполняемых файлов. Откроем переменные ОС, для этого начнём вводить «изменение переменных среды текущего пользователя» в строке поиска

    В окне выберем переменную Path и нажмём Изменить. В открывшемся списке создадим новую строку с адресом до исполняемых файлов flutter в файловой системе, например C:\flutter\bin

  • Установим расширение VScode для flutter
  • Перезапустим VScode (чтобы применились новые переменные ОС) и в терминале проверим состояние flutter командой
    flutter doctor

    здесь самое важное, что flutter установлен в beta версии (с поддержкой web разработки)

  • Теперь активируем веб разработку командой
    flutter config --enable-web

Создание нового проекта и запуск отладки

Создаём новый проект командой

flutter create <название проекта>

Сразу откроем его в VScode командой

code <название проекта>

Откроем файл main.dart в папке lib и запустим отладку командой F5:

Возможно при первом запуске отладки понадобится выбрать Chrome устройством для отладки:

Удалим содержимое файла main.dart. Добавим пустой метод main и корневой класс приложения, возвращающий в методе build() экземпляр MaterialApp:

Далее создадим следующий набор вложенных папок проекта:

Кратко опишем назначение каждой из них:

  • di — механизм для связи между компонентами приложения. Здесь будут создаваться и регистрироваться все необходимые сервисы, репозитории, сетевые клиенты, необходимые для работы приложения. Я буду использовать библиотеку GetIt
  • domain — data-объекты. Классы представления данных
  • res — цвета, строки, импорты путей к картинкам и шрифтам. Всё, что связано со статическими ресурсами
  • service — сервисы для работы с данными
  • ui — интерфейс
  • utils — вспомогательные классы

В файле pubspec.yaml добавим необходимые зависимости:

Подготовка к масштабированию элементов UI

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

Начнём с картинок заднего фона. Их подготовка не входит в тему статьи, поэтому просто оставлю здесь эти две ссылки:

  • Pixabay.com — хранилище контентных фотографий
  • Paint.net — графический редактор

Готовые картинки разместим в папке /assets/images, в файле pubspec.yaml добавим этот путь к ресурсам:

Я предпочитаю доступ к ресурсам в виде дерева c параметрами. В данном случае путь к картинке заднего фона заглушки:

images.background(bool isPortrait).stub

Для этого в папке res создадим файл images.dart с классами адресов картинок:

Для масштабирования размеров интерфейса и шрифтов мы подключили библиотеку ScreenUtil. Её функциональность сводится к двум вещам:

  • Регистрация «базового» размера экрана. Здесь необходимо задать ширину и высоту экрана, для которого ведётся основная верстка и необходимость масштабирования шрифтов.
  • Набор расширений, позволяющий для чисел (num) применить масштабирующий коэффициент. Например 100.w означает, что результатом этого выражения будет для экрана шириной 1920dp => 100dp, а для экрана iPhone8 с шириной 414dp => 100х(414/1920) = 21,6dp. То есть в пять раз меньше. Также предусмотрены расширения для параметра высоты и размера шрифтов.

Создадим файл /utils/screen_util_ext.dart и статический метод инициализации в нём:

Вызов метода инициализации масштабирования добавим в метод build() корневого виджета:

Расширим функциональность библиотеки масштабирования несколькими дополнительными расширениями в файле /utils/screen_util_ext.dart:

Инъекция зависимостей

Пришло время внедрить механизм создания и регистрации компонентов приложения с помощью библиотеки GetIt. В папке lib/DI/ создадим файл di_container.dart. В нём напишем статический метод getItInit() и инициализируем экземпляр контейнера GetIt. Зарегистрируем первый компонент — экземпляр класса Images:

Вызов метода инициализации добавим в main():

Доступ к компоненту Images будет выглядеть так:

Таким же образом зарегистрируем класс с ресурсами строками.

Страница-заглушка

Теперь в папке UI создадим файл stub.dart с классом страницы заглушки StubScreen, расширим базовый класс StatelessWidget и переопределим его абстрактный метод build(). Наша страница представляет собой картинку на заднем плане и два информационных блока перед ней, размещающихся в зависимости от ориентации экрана.

Репозитории и сервис

Для динамического отображения оставшегося до релиза времени необходимо:

  1. Получить с сервера настройки с датами начала разработки и релиза
  2. Создать поток событий изменения оставшегося времени
  3. Объединить эти данные, передав в выходной поток для отображения на UI

Опишем доменные объекты (POJO) для этих данных:

Репозитории для получения настроек и создания потока событий:

Сервис для логики событий:

Зарегистрируем эти компоненты в DI контейнере:

Виджет оставшегося времени

Оставшееся до релиза время можно представить как 4 числа: дни, часы, минуты, секунды. Представим эти параметры в виде перечисления:

Добавим функциональности параметрам с помощью расширения:

Виджет для отображения круговой шкалы, числа и подписи будет анимированным, для этого расширим класс StatefulWidget. Его особенность в том, что Element (построенное и отображаемое представление) соотносится не с самим виджетом, а с его состоянием (State). Состояние, в отличие от виджета мутабельно. То есть его поля могут быть изменены без полного пересоздания экземпляра.

Здесь необходимо уточнить, что такое Animation, AnimationController и TickerProviderStateMixin. Итак AnimationController — обёртка над простым параметром double value. Значение этого параметра меняется линейно в пределах от 0,0 до 1,0 (также его можно менять в обратную сторону или сбрасывать в 0,0). Однако для изменения этого параметра используется специальный объект TickerProviderStateMixin, который является обязательным параметром для AnimationController и сообщает ему, что графический движок готов построить новый кадр. Получив такой сигнал AnimationController рассчитывает сколько времени прошло от предыдущего кадра и вычисляет насколько нужно изменить значение своего value. Объекты Animation подписываются на AnimationController и содержат в себе некоторую функцию зависимости выходного значения от линейного (по времени) изменения значения AnimationController.

Метод инициализации состояния initState() вызывается один раз при создании:

При уничтожении состояния виджета вызывается метод dispose():

Представлением виджета будет стек (Stack), с помещёнными в него AnimatedBuilder для числа и шкалы:

Остаётся реализовать графический примитив в виде дуги:

Добавим 4 таких виджета на экран заглушки:

Сборка и релиз

Перед сборкой приложения необходимо заменить название и описание приложения в файлах ./web/index.html ./web/manifest.json и pubspec.yaml.

Останавливаем отладку и собираем релиз приложения командой

flutter build web

Готовое приложение находится в директории ./build/web/. Обратите внимание, что файлы .last_build_id и main.dart.js.map служебные и могут быть удалены.
Разместим приложение на сервере, подготовленном в предыдущей статье. Для этого достаточно скопировать содержимое директории ./build/web/ в /public/ нашего сервера:

scp -r ./* root@91.230.60.120:/public/

Результат

Исходный код github

Вопросы и комментарии приветствуются. Пообщаться с автором можно в Telegram канале.

Вместо заключения

Наше клиентское приложение уже готово получить первые данные с сервера — сведения о дате релиза. Для этого в четвертой статье мы создадим каркас серверного приложения и разместим его на сервере.

ссылка на оригинал статьи https://habr.com/ru/company/surfstudio/blog/514640/

Суммаризация текста: подходы, алгоритмы, рекомендации и перспективы

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

У нас в компании мы активно работаем над автореферированием документов, в эту статью не стал включать все подробности и код, но описал основные подходы и результаты на примере нейтрального датасета: 30 000 футбольных спортивных новостных статей, собранных с информационного портала «Спорт-Экспресс».

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

Экстрактивная суммаризация

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

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

Перейдем же к описанию некоторых экстрактивных подходов.

Экстрактивная суммаризация на основе вхождения общих слов

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

Итак, на первом шаге разбиваем входной текст на предложения и каждое предложение разбиваем на токены (отдельные слова), проводим для них лемматизацию (приведение слова к «канонической» форме). Этот шаг необходим для того, чтобы алгоритм объединял одинаковые по смыслу слова, но отличающиеся по словоформам.

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

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

Далее ранжируем все предложения по их значимости.

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

Экстрактивная суммаризация на основе обученных векторных представлений

При построении следующего алгоритма уже использовались ранее собранные данные полных текстов новостей.

Слова во всех текстах разбиваем на токены и объединяем в список. Всего в текстах оказалось 2 270 778 слов, среди которых уникальных — 114 247.

С помощью популярной модели Word2Vec для каждого уникального слова найдем его векторное представление. Модель присваивает каждому слову случайные вектора и далее на каждом шаге обучения, «изучая контекст», корректирует их значения. Размерность вектора, которая способна «запомнить» особенность слова можно задать любую. Исходя из объема имеющегося датасета, будем брать векторы, состоящие из 100 чисел. Также отмечу, что Word2Vec является дообучаемой моделью, что позволяет подать на вход новые данные и на их основе скорректировать уже имеющиеся векторные представления слов.

Для оценки качества модели применим метод понижения размерности T-SNE, который итеративно построит отображение векторов для 1000 самых употребляемых слов в двумерное пространство. Полученный график представляет собой расположение точек, каждая из которых соответствует определенному слову таким образом, что схожие по смыслу слова располагаются близко друг к другу, а различные наоборот. Так в левой части графика располагаются названия футбольных клубов, а точки в левом нижнем углу представляют собой имена и фамилии футболистов и тренеров:

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

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

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

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

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

Сравнение экстрактивных алгоритмов

С помощью микрофреймворка Flask (инструмент для создания минималистичных веб-приложений) был разработан тестовый веб-сервис для наглядного сравнения результатов вывода экстрактивных моделей на примере множества исходных новостных текстов. Мною проанализировано краткое содержание, генерируемое обеими моделями (извлекалось 2 наиболее значимых предложения) для 100 различных спортивных новостных статей.

По результатам сравнения результатов определения обеими моделями наиболее релевантных предложений могу предложить следующие рекомендации по использованию алгоритмов:

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

Абстрактивная суммаризация

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

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

Этап обучения

Я не буду подробно останавливаться на математических обоснованиях работы алгоритма, все известные мне модели основаны на архитектуре «кодера-декодера», которая в свою очередь построена с помощью рекуррентных слоев LSTM (о принципе работе которых можно почитать здесь). Кратко опишу шаги для декодирования тестовой последовательности.

  1. Кодируем всю входную последовательность и инициализируем декодер внутренними состояниями кодера
  2. Передаем токен «start» в качестве входных данных для декодера
  3. Запускаем декодер с внутренними состояниями кодера на один временной шаг, в результате получаем вероятность следующего слова (слово с максимальной вероятностью)
  4. Передаем выбранное слово в качестве входных данных для декодера на следующем временном шаге и обновляем внутренние состояния
  5. Повторяем шаги 3 и 4, пока не сгенерируем токен «end»

Подробно с архитектурой «кодера-декодера» можно ознакомиться здесь.

Реализация абстрактивной суммаризации

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

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

Далее тексты и их заголовки разбиваем на обучающую и тестовую выборки в отношении 9 к 1, после чего преобразуем их в векторы (случайным образом).

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

Наконец, выводим результат модели для тренировочного множества. Как можно заметить в примерах, исходные тексты и резюме содержат неточности из-за отбрасывания перед построением модели редко встречающихся слов (отбрасываем для того, чтобы «упростить обучение»).

Вывод модели на данном этапе оставляет желать лучшего. Модель «успешно запоминает» некоторые названия клубов и фамилии футболистов, но сам контекст практически не уловила.

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

Так какой же подход лучше?

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

1. Экстрактивный подход:

Преимущества:

  1. Интуитивно понятна суть алгоритма
  2. Относительная простота реализации

Недостатки:

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

2. Абстрактивный подход:

Преимущества:

  • Качественно реализованный алгоритм способен выдать результат наиболее близкий к ручному составлению резюме

Недостатки:

  • Сложности при восприятии основных теоретических идей алгоритма
  • Большие трудозатраты при реализации алгоритма

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

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

Векленко Влад, системный аналитик,
Консорциум «Кодекс»

ссылка на оригинал статьи https://habr.com/ru/post/514540/

Собираем медиацентр разной функциональности на коленке разной толщины


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

Исходя из всего вышеизложенного, идея собрать дома медиацентр уже не кажется такой устаревшей. Помните, как в старом анекдоте про сибирских мужиков, получивших на тест японскую бензопилу. Ага, блин, сказали суровые хабравчане, увидев заикающийся 4K и пошли стирать пыль со старых хардов. В сегодняшнем тексте мы постараемся максимально концентрировано рассказать о том, как можно сделать медиацентр в середине 2020 года.

Системно задачу про медиацентр можно разложить на три составляющие:

  • На чём смотреть/слушать (железо)
  • Чем управлять (хотелось написать «под чем смотреть», но толкование может быть разным, хотя я о софте)
  • Где что брать.

Вариант 1 (банальный): Смотрим с экрана домашнего компьютера

При всей простоте этого выбора здесь есть несколько подводных камней: стандартные кодеки не всегда позволяют выдать максимальное качество, особенно если вы обновили монитор на экран с высоким разрешением, а любимые видео, бережно хранимые на винте, чего-то не проапгрейдились. Поэтому убиваем сразу двух зайцев: для каталогизации видео используем Kodi (навороченный кроссплатформенный медиацентр, о котором написаны тонны гайдов), а дальше либо используем сборку с добавлением библиотеки MadVR (только Win, последняя сборка датируется 2017 годом и версия 64-бита действительно не всегда стабильна), либо используем VLC-плеер (кроссплатформа) версии 3 и выше.

Благодаря MadVR вы получаете изменение частоты видео под частоту обновления экрана (так называемый Smooth motion делающий картинку более плавной), апскейлинг видео с плохим разрешением, убирание артефактов в виде ступенчатого градиента на поверхностях и многое другое. Реально кодек умудряется неплохо вытягивать видео и пересчитывать поток с современного HDR-потока там, где его не понимает телевизор. Аналогично с VLC — сломано немало копий в споре о том, кто же показывает лучше, поэтому это скорее дело вкуса. Но, имхо, конечно же, MadVR лучше справляется с отображением старых видео с артефактами сжатия.

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

Что же касается MadVR, то на странице проекта есть большой перечень плееров, поддерживающих кодек. Однако именно связка c Kodi позволяет превратить компьютер в подобие медиаплеера.

Дополнительно, отвечая на вопрос, «где брать», рассмотрим торрент-клиент qBittorrent, основанный на принципах Open Source и призванный заменить опостылевший и немного заевшийся мю-торрент. Рассматривать этот софт будем в сочетании с фильмом «Броненосец Потемкин», находящимся в статусе общественного достояния (сюда входят фильмы, вышедшие более 70 лет назад). Использование qBittorrent примечательно тем, что в нем присутствуют две галочки, облегчающие просмотр «налету».

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

Вариант 2: Смотрим с телевизора, планшета/телефона, компьютер раздает контент всем желающим

Существует множество различных медиасерверов, которые могут поселиться на компьютере, проанализировать хранящиеся на винтах папки с контентом и начать раздавать его всем желающим. Мне по-прежнему нравится Plex, позволяющий не только дать доступ ко всему что нужно, но и попутно осуществлять транскодинг — т. е. пересчет видео на лету под разрешение гаджета (привет айфоны в дальних комнатах) или пересчитать дорожку во что-то понятное (привет древние SmartTV с проблемой лицензирования AC3 или DTS).

Несмотря на то что Plex является «ребенком» Kodi, ему удалось превзойти родителя и по внешнему виду, и по удобству работы. Реально, после Kodi, Plex — это просто глоток свежего воздуха.

Отдельный момент: поскольку Plex Media Server можно поднять и на Ubuntu и на FreeBSD, никто не мешает установить его у нас на RuVDS, используя сервер для хранения/бекапа контента. Во-первых, скачивание нужных файлов на VDS идет быстрее, чем на локальный винчестер. Помним, что у нас канал 100 Мбит/с. Во-вторых, возможны сценарии, когда основные сервера перегружены, а до нас банально лучше трафик в том числе во время отпуска. В-третьих, у нас неплохие тарифы на подключение жестких дисков.

Вариант 3: Зачем нам комп, если есть производительный роутер?

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

Как правило, у вас уже есть хороший дальнобойный роутер (а ковидо-кризис показал, что нормальный роутер — чуть ли не главное устройство в доме), скорее всего, в него можно подключить внешний диск и поднять
а) DLNA-сервер, который позволит смарт-телевизорам/телефонам/планшетам получить доступ к домашней библиотеке.
b) В отдельных устройствах можно также поднять торренто/файло-качалку.

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

Отдельным пунктом надо указать, что следует аккуратно подбирать жесткие диски для подключения в роутер. Некоторые модели могут не иметь функции засыпания после длительного бездействия (а вы вряд ли захотите, чтобы ваш винт был активен 24/7/365), или наоборот — не уметь просыпаться после выключения. В любом случае перед покупкой внешнего диска неплохо бы посмотреть форумы на предмет отзывов владельцев связки ваш роутер + ваш HDD.

Вариант 4: NAS для видеопрекрас

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

На рынке существует два явных лидера готовых NAS. Это Synology и Qnap. Оба продают свои устройства без винтов и оба стоят как небольшое крыло от боинга. Учитывая, что брать надо минимум двухдисковый NAS (да здравствует Raid или просто перекрестное копирование нужных папок), то цены существенно кусаются.

Однако, как только вы поработаете с системой, то поймете, что основные деньги платятся не за железо, а за оболочку. У Synology она чуть дружелюбнее, у Qnap — чуть замороченнее, но зато и устройства чуть дешевле.

Описывая возможности современного NAS проще написать, что он не умеет. Это касается как предоставления контента для любых устройств, так и проблем закачки данных. То есть вопросы из начала статьи про то, «чем управлять» и «где брать» у владельцев NAS просто не стоят. Что характерно, на Хабре регулярно возникают топики о том, как люди заморачиваются с бекапом и каталогизацией фото и другого контента. А потом приходят владельцы Synology или Qnap и рассказывают как они счастливы. Это немного подбешивает, но факт остается фактом — если у вас появился NAS, вы от него уже не откажетесь.

Вариант 4.1: Синолоджи? Хренолоджи!

Операционную систему Synology, называемую DiskStation Manager (сокращенно DSM) можно попробовать в виде онлайн-демонстрации или поставить на виртуальную машину. И, поскольку DSM разработана под лицензией GPL, то существует ее форк, называемый Xpenology. Таким образом, можно взять старое железо, записать на флешку загрузчик, который заставит DSM думать, что она стоит на валидном оборудовании и получить отличный и функциональный NAS с постоянно выходящими апдейтами прошивки. Более того, можно сколько угодно расширять количество винтов, ограничиваясь лишь вместимостью корпуса и количеством SATA-разъемов платы, на базе бескулерного процессора.

Сборка компактного 4-дискового NAS на базе Celeron J3355I с пассивным охлаждением

Проблема такого подхода заключается в том, что на «левом» железе без правильных серийников не будет работать транскодинг. Это первое. Народ ищет настоящие серийники на фотографиях реальных NAS на Ebay и прописывает в конфиги, но это уже совсем неэтично. Второе, при апгрейде DSM легко словить ситуацию, когда Synology успело выпилить какие-то драйвера из прошивки и ваша система тупо не стартует после апгрейда. Назад откатиться уже сложнее, потому что DSM ставится в небольшой раздел на каждом диске и успевает обновиться, попутно внеся изменения в загрузчик. Тогда начинаются пляски в подменой драйверов на флешке и прочими веселостями.

Вообще настоящий XPEновод имеет в хозяйстве ненужный жесткий диск малой емкости, который использует в качестве тестового. При выходе нового обновления такой прожженный юзер отключает основные винты и оставляет в системе только тестовый. Попутно делает копию загрузочной флешки. Затем накатывает обновление и затаив дыхание ждет загрузки. Если все ок, то подключаются основные винты и происходит миграция всей системы. Если нет — юзер пробует обновить драйвера паком на загрузчике. Если и тут не получилось, отрубает тестовый винт и подключает основные винты, установив копию старой загрузочной флешки (там тоже не просто копия, а нужно прописывать ID конкретной флешки). Тестовый винт уносится в основную систему, где безжалостно форматируется.

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

Вариант 4.2: Есть вопрос? Open Source!

Поскольку основное достоинство Synology — это красивости и множество модулей, многим людям особо и ненужные, логично поставить на свежесобранный NAS что-то из OpenSource. Уж тут то с обновлениями все хорошо, а при покупке железа вы платите только за железо. На хабре есть множество статей про настройку FreeNas, Nas4Free, OpenMediaVault и еще несколько менее известных сборок.Все они более или менее поддерживают возможность отдачи данных по DLNA, а кто-то даже позволяет поставить на него Flex. 

Пример окна OpenMediaVault. Не так красиво как у Synology или Qnap, но тоже функционально

В любом случае выбор конкретной сборки определяется скорее требованиями к файловой системе (к примеру, ZFS) и требованиями к бэкапам и прочим делам. Так что создание медиасервера тут скорее вторично.

Кстати, поскольку современный NAS — это тот же сервер под управлением Linux, логично настроить синхронизацию/бекап со своим сервером, размещенным на RuVDS. к примеру, через тот же RSync.Лишним такой линк никогда не будет.

Вариант 5: Просмотр видео на телевизоре без SmartTV или что делать, если SmartTV ограниченный

В предыдущих пунктах (кроме самого первого) мы рассматривали варианты, когда телевизор подхватывает переданные ему данные и послушно их показывает. Но что делать, если телевизор все еще неплохо показывает, но «умом» не отличается? В этом случае помогают Android-приставки, коих сейчас много.

Недавно на Хабре выходил гайд, посвященный Android-боксам и тому, какие из них считаются нормальными. Надо отметить, что хорошая приставка может не только «проапгрейдить» старую TV-панель, но и утереть нос многим встроенным смартам. Более  того, внешнюю приставку довольно просто настроить, если хочется чего-то экзотического или просто сменить на свежую по железу/возможностям, тогда как с «мозгами» телевизора такой фокус провернуть практически невозможно.

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

Вариант 6: Прослушивание музыки на качественном ресивере

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

Интерфейс настроек Audio Station, входящей в состав пакетов Synology DSM

Надо только указать в настройках — умеет ли ваша аппаратура понимать только MP3 или же и Flac потянет. Отдельно хочется отметить, что если у вас есть современное устройство, умеющее играть Flac по сети, то вероятно, вы можете воспользоваться стримингом Deezer на тарифе Hi-Fi (255 рублей в месяц за доступ к большой библиотеке Flac-релизов). 

В самом начале текста мы договаривались, что доступ к локальному медиаконтенту является хорошей альтернативой стриминга. Однако «вес» Flac не идет ни в какое сравнение с тем же FullHD-видео и здесь, легко пойти на компромисс. Что же касается Deezer, то тариф Hi-Fi работает далеко не на всех устройствах и должен поддерживаться на уровне прошивки. Актуальный список устройств (c пометкой Hi-Fi) можно найти на сайте стриминга.

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

Выводы

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

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

ссылка на оригинал статьи https://habr.com/ru/company/ruvds/blog/514624/

В Parallels Desktop 16 для Mac появилась поддержка macOS Big Sur

Parallels представила Parallels Desktop 16, включающий поддержку macOS Big Sur, работу приложений с 3D-функциями на базе Metal, возможности обновления ОС, новые функции интеграции Mac и Windows для максимально полного воссоздания среды Windows на платформе Mac.

Ключевые новые функции в Parallels Desktop 16 для Mac

  • DirectX 11 и OpenGL 3: до 20% более быстрая работа DirectX 11 и улучшенная графика по спецификации OpenGL 3 в ОС Windows и Linux.
  • Более длительная работа от аккумулятора: теперь заниматься важными делами можно и в дороге — при запуске Windows в режиме поездки время работы от аккумулятора увеличивается почти до 10%.
  • Автоматическое высвобождение дискового пространства: виртуальные машины (ВМ) можно настроить таким образом, что при их отключении неиспользуемое дисковое пространство будет автоматически высвобождаться.
  • Новые жесты Multi-Touch для приложений Windows: используйте жесты Multi-Touch в приложениях Windows для плавного масштабирования и вращения изображения на трекпаде.
  • Расширенные возможности печати: теперь пользователям доступна двусторонняя печать и более широкий выбор форматов бумаги — от A0 до конвертов.

«Команда разработчиков Parallels потратила более 25 человеко-лет на то, чтобы при помощи инженерно-программных средств реализовать архитектуру macOS Big Sur, модернизировать расширения ядра для обеспечения наилучшей производительности Windows на платформе Mac для пользователей Parallels Desktop 16, — рассказывает Николай Добровольский, старший вице-президент Parallels по проектированию и поддержке. — Среди инновационных возможностей Parallels Desktop 16 мне хотелось бы отметить впервые добавленную поддержку приложений с 3D-функциями на базе Metal в виртуальной машине macOS Big Sur. Почти вдвое увеличилась производительность: до 20% более быстрое возобновление и выключение Windows, отображение графики DirectX и не только».

ссылка на оригинал статьи https://habr.com/ru/company/parallels/blog/514704/