Category: технологии

JSON зло

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

Недавно я задавался вопросом, почему на старом смартфоне(с андроидом 4.4) происходят постоянные сетевые сбои - дело просто в таймауте, который у меня выставлен на 5 секунд.
Просто один только парсинг json'а сжирает гораздо больше времени...

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

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

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

Выбираю Gluon, нет не клей.

Сегодня не совсем обычный день ночь, и я объявляю свой дом безъядерной зоной начало разработки клиента на основе той же JavaFX в купе продуктов компании Gluon https://gluonhq.com/.

Давно к ним приглядывался, но раньше не было стимула, теперь он есть в виде Huawei P Smart 2019 https://consumer.huawei.com/ru/phones/p-smart-2019/. Да, я не люблю Андроид, но еще больше я не люблю современные поделия до которых опустился Apple, тем более за огромную сумму.

Если вкратце, эти ребята обещают, что единожды написанный код будет работать на десктопах, Android устройствах и IOS устрйоствах без какого либо веба.  Здорово да? Мои давние тесты для десктопа и Android показали, что это вполне реально. Правда для Apple устройств нужен Mac. Может быть в будущем он у меня будет, а может мы в конце концов наберем команду и Mac будет у другого разработчика, что тоже не плохо.

Итак,  у меня есть библиотека со всем функционалом необходимым клиенту, необходимо обновить UI - вью и контроллеры. И главное - у меня есть ровно та же среда разработки, тот-же язык и те же инструменты(как например SceneBuilder). Из изменений только дополнительный плагин Gluon и немного больше требований по коду.

Я серьезно считаю, что это просто бомба. Но почему же тогда оракллл закрыл бесплатную лицензию для их бинарников JDK8 и вырезал JavaFX в свежих версиях Java? Почему основные разработчики оракл вводят всякие ламбда хулямбда но не расширяют JavaFX на все платформы? Почему при оракл JavaFX не развивался никак существенно? Хм, лично я считаю потому, что такие компании как оракл, мелкопакостные и гугел никогда не ставили себе цель сделать нашу жизнь лучше, в отличии от Sun Microsystems.

P.S. Вот что интересно, большинство ПО которое я использую в работе создало Sun Microsystems.

Update: Вот так выглядит новый клиент(на gluon), видно разницу?



Все основное реализовано, осталось допилить мелочевку.

Java контроллер на Android

Сегодня прошли первые успешные запуски контроллера под Андроидом.

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

По сути, теперь контроллер можно развернуть как на любом компьютере так и на любом Андроид устройстве. Понятно, что будут исключения, но на мой взгляд, многие проблемы будут решены. Сейчас я только приступаю к обкатке проекта на различных версиях Андроида. На данный момент Java контроллер запущен и отлично себя чувствует на DEXP Ixion M450 с Android 5.1, под рукой также есть один из первых Huawei с 4-ым Андроидом, позже обкатаю и на нем.

Стоит также сказать, что шел я достаточно долго к этому. Изначально проект контроллера создавался под JRE7, и имел код который может быть выполнен только на PC. Теперь весь код адаптирован под JRE6(необходимо для 4-го Android'а) ну и большая часть кода выведена в отдельную библиотеку без какой-либо привязки к ОС. Также были отдельно скомпилированы все библиотеки устройств, шлюзов и сервисов под Андроид (формат .dex)

И да, я знаю, что Андроид полон сюрпризов, и он потребует много времени. К примеру я потратил более суток, но так и не смог заставить работать корректно сеть с использованием архивирования потока Inflater/Deflater. В эмуляторе Nexus 4 все отлично а вот на Ixion M450 попросту через секунду помирает установленное соединение.
Пришлось поддерживать два типа соединения с сжатием и без.

Пы.Сы. Немного удивлен, я забыл сообщить, что у меня также недавно реализован облачный контроллер. Каждый проект может иметь один облачный контроллер, который выполняется на моем сервере(в облаке). Потом чуть подробнее отпишусь.

Обновление:
Java контроллер также успешно запустился на Huawei U8860 Honor с Android 4.0.3, думал его разобрать да выкинуть, но видимо нет, еще поработает в виде контроллера.

RADIUS и что он здесь забыл

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

То что я там делал - большинству местных специалистов даже и не снилось, современным - тем более, так как к вебу никакого отношения это не имело, чаще даже транспортный протокол использовался UDP, а не TCP(и на это есть причины, и они актуальны и сегодня).

Но я увлекся, к делу, сразу предупреждаю, пишу по памяти давности этак лет 10.

RADIUS, у всех есть вики, можно 'умных' людей почитать там, я же скажу проще - это сервис, выполняющий Авторизацию, Аутентификацию(да,да, есть разница) и Аккаунтинг.
К ви-фи прямого отношения не имеет, быстрее к модемным подключениям, но так-как сервис выполняет необходимые задачи и по сегодняшний день, то применим и к ви-фи и к другим решениям, где нужен ААА.
Беда только в том, что он(протокол) древний как мамонт, к примеру размер пакета(запрос, ответ и т.п.) не может превышать 256 байт, в это же время мы используем для авторизации сертификаты на сотни килобайт или уже на мегабайты?...

Хотя, можно считать что тоже во времена мамонтов, был разработан DIAMETER.
Юмористы хреновы, RADIUS расшифровывается как Remote Authentication in Dial-In User Service, в то время как DIAMETER просто в два раза круче. :)
Он реально круче, но используется только подальше от глаз современных ИТ специалистов пишущих, прости госпаде на PHP или на Ардуино к примеру. Да и от глаз современных потребителей тоже, в лучшем случае на своей ви-фи точке вы найдете RADIUS Accounting рядом с RADIUS Authentification/Authorization
Это я к тому, что развитие ИТ остановилось лет так 15 назад, наверное даже больше. Мы до сих пор сидим на устаревших базовых протоколах, которые не рассчитаны на современные объемы информации и количество хостов и сервисов. При этом маразм крепчает, но это отдельная тема.

Стоит ли говорит о том, что в НТК я разработал хорошего конкурента тому-же FreeRADIUS? Он даже поддерживал MSCHAPv2, EAP, PEAP, ну вы поняли да... правда это еще одна хорошая технология заживо похороненная, теперь вместо нее у нас идиотизм ввиде авторизации в вифи по веб интерфейсу.

Так, ближе к делу.

Зачем мне вдруг в проекте по автоматизации говорить про RADIUS?
Дело в том, что если ваша Wi-Fi точка доступа поддерживает RADIUS, то мой новоиспеченный сервис на контроллере по данному функционалу может определять прибытие жильца домой. А если ваша точка доступа поддерживает еще и RADIUS Accounting(типа TP-Link eap 110v4 или семейства странноватых Mikrotik) то и убытие.
Т.е. все что нужно для контроля кто когда пришел/ушел - иметь в кармане самый обыкновенный смартфон с включенным Wi-Fi, и все, больше никаких дополнительных железок.

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

О проекте (периодически обновляется)

Приветствую.

Похоже мне стоит кратко описать свой проект.

Проект представляет собой конструктор, под этим термином подразумеваются следующие особенности:
1) Широкая поддержка различных производителей и их устройств.
В проект заложены основы позволяющие его дополнять поддержкой сторонних устройств, в том числе сделанных своими руками.
2) Широкие возможности настройки подключения устройств.
Проект поддерживает большой набор различных интерфейсов подключения. Позволяет подключать конечные устройства через большое количество шлюзов, как простых так и с дополнительно настраиваемой логикой.
3) Контроллер (основной локальный узел управления конечными устройствами) может быть развернут на любом компьютере поддерживаемом Java 6 и выше (это может быть настольный компьютер, сервер, мини компьютер и даже в будущем Android устройство).
Проект позволяет выполнить поддержку всех интерфейсов подобных устройств при этом пользовательский интерфейс описания данных подключений достаточно понятный и не требует специфичных знаний.
4) Возможность как локального подключения клиента к контроллеру, так и облачного, что дает широкие преимущества, как например информирование, сбор статистики и удаленное управление.
5) Финансовая выгода - основные компоненты проекта бесплатны, платными будут дополнительные сервисы, как например разработка доп. функционала под заказ, использование дополнительных веб сервисов, аренда дискового пространства под статистику или разработка нового устройства.
6) Проект не потребует от вас специфичных знаний в электронике или знаний программирования, все достаточно просто и понятно. Однако подразумевается, что Вы имеете некоторое представление в области автоматизации.
7) В рамках проекта также разрабатываются недорогие устройства с существенными особенностями в сравнении с аналогами на рынке.


Основными компонентами проекта являются:
1) Удаленный сервер.
Предоставляет облачное решение (авторизация пользователей,  удаленное управление, мониторинг, сбор статистики и ее выгрузка, информирование, виртуальные контроллеры и тому подобное)
Сервер не распространяется, права на его использование есть только у меня и у компании 'Dipex group'.
На текущий момент заложены три площадки - официальная dipexlab, студентческая dipexlab и моя, для DIY инженеров.

2) Java контроллер.
Программное обеспечение которое можно развернуть практически на любом устройстве поддерживаемом Java 6 и выше.
Размещается на сайте вместе с устройствами автоматизации. Выполняет опрос устройств, управление (в том числе и по заложенным сценариям), передачу данных на сервер либо непосредственно в клиент.
Вся логика управления устройствами заложена в нем (хотя часть может находиться на конечных устройствах),
т. е. не требует наличия сервера(доступа к облаку).
В будущем будет доступен для Android устройств начиная с версии 4.0

3) Клиент.
Выполнен на JavaFX и может быть развернут на многих десктоп устройствах. Является главным инструментом интегратора, содержит детальную информацию о проекте, конструктор для создания проекта и дополнительный функционал, как например выгрузка статистики. Также можно использовать как приложение для мониторинга и управления устройствами.
На его базе будут выполнены решения для мобильных устройств и веб.
Также есть консольная утилита позволяющая получать данные для таких решений как MRTG

Кроме этого, есть сторонние решения для управления устройствами (точки входа). В проекте заложен механизм позволяющий получать информацию об устройствах и управлять ими на базе фраз. На текущий момент реализованы следующие точки входа:
1) Мессенджер Телеграм.
2) Голосовой помощник Алиса.
3) Электронная почта
В будущем будет поднят СМС шлюз, появится СМС точка входа.

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

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



И главное, еще раз, это конструктор.
Он Вам не нужен, если Вы купили комплексное решение от, скажем, Xiaomi. Но если Вы интегратор, или просто увлекаетесь электроникой и решили обвесить свой дом различными недорогими устройствами управления и датчиками, то здесь он в самый раз.
Безусловно, если вы купили, скажем, с десяток RGB WiFi ламп и теперь желаете все это дело объединить, то этот проект Вам также будет очень полезен.
Хотя, Вы в любой момент можете купить ограниченный в функционале готовый контроллер известного производителя  для ограниченного количества и типа устройств заплатив за него значительно больше чем за недорогой мини копьютер.

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

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

У проекта есть юр. лицо http://dipex.ru, есть лаборатория в ДВФУ(C305 - центр проектной деятельности)

UPDATE, 12.08.2019 добавлена информация