Создайте сервис для воспроизведения данных в реальном времени с помощью SpringMVC, JFugue и WebAudioFont.

Все мы привыкли визуализировать данные в виде изображений / диаграмм. Будь то цена акций компании, растущая или падающая, или количество продаж клиентов за квартал. Мы привыкли определять паттерн по осям X и Y на графике.

А как насчет других способов представления данных помимо изображений? Ультразвуковая обработка данных или слуховое отображение - это термин, используемый для преобразования данных в звук. Вероятно, впервые это стало областью исследований в 1992 году. В том же году была выпущена книга Слуховой дисплей. Это были итоги работы Международной конференции слуховых дисплеев (ICAD).

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

Томас Херман, 2008 предлагает более подробное определение:

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

  • Звук отражает объективные свойства или отношения во входных данных.
  • Преобразование носит систематический характер. Это означает, что существует точное определение того, как данные (и дополнительные взаимодействия) вызывают изменение звука.
  • Ультразвуковая обработка воспроизводима: при одинаковых данных и идентичных взаимодействиях (или триггерах) результирующий звук должен быть структурно идентичным.
  • Система может намеренно использоваться с разными данными, а также может повторяться с одними и теми же данными.

Образец услуги

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

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

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

Вот эти особенности более подробно:

  • Потоковое представление аудио в формате base64 как ответ веб-службы.
  • Воспроизвести в браузере
  • Преобразование времени ответа и определенных событий в конкретные заметки. Высокое время отклика = высокая числовая нота фортепиано. Низкое время отклика = небольшое числовое примечание. Exception и Timeout воспроизводят определенные звуки / ноты. Цель состоит в том, чтобы привлечь внимание к таким событиям.
  • Нормализовать время отклика до диапазона: 50–127. Этот диапазон эквивалентен числовой ноте, которую можно сыграть. Пример: учитывая максимальное время отклика 5000 мс, 5000 проигрывают 127 нот. См. Рисунок 2 ниже.
  • Прочтите файл журнала приложения в том виде, в котором он написан.

В сервисе используются следующие технологии / фреймворки:

Вот основные части кода.

Контроллер:

Index.html

Вывод

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

Однако по мере того, как я читал и думал больше, я начал сомневаться в его практичности. Это полезно? Где на самом деле оправдывает свою реализацию?

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

1. Пользователи с ослабленным зрением.

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

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