Fullstack разработка: от железа до фронтэнда. IoT in action

14 октября 2018 года прошла девятая встреча сообщества java разработчиков Севастополя JUG.SEV, на которой я выступил с докладом "Fullstack разработка: от железа до фронтэнда. IoT in action".

В докладе я рассказал об особенностях построения решений в сфере интернета вещей (IoT) на примере проекта мониторинга температуры и влажности помещения с помощью сенсоров на базе микроконтроллера esp8266 (Lolin (Wemos) D1 mini) с wi-fi и сервера на Raspberry Pi 3.

Рассказал, как проектировать и создавать сенсоры в железе, как разрабатывать софт для сенсоров с помощью Arduino Framework. Развернул на Raspberry Pi java сервер, который управляет сенсорами, собирает с них значения температуры и влажности по WI-FI и предоставляет интерфейс для настройки и просмотра графиков истории значений сенсоров через web интерфейс.

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

Видео доклада

Презентация

TimescaleDB. Комфортное хранение метрик в PostgreSQL

В статье пойдет речь об opensource базе данных TimescaleDB, которая предназначена для хранения временных рядов. Мы поговорим об особенностях хранения временных рядов, рассмотрим, как устроена внутри TimescaleDB, рассмотрим на примере запись и чтение метрик в TimescaleDB.

В одной из предыдущих статей мы рассматривали одну очень интересную базу данных для хранения временных рядов InfluxDB. Мы говорили о том, что InfluxDB очень гибкая позволяет быстро начать работу и, самое главное, InfluxDB заточена под запись хранение и обработку временных рядов. А что это означает: "заточена под запись хранение и обработку временных рядов"? Давайте разберемся.

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

Семантическое версионирование (Semantic Versioning)

При разработке программных решений встает задача управления изменениями ваших публичных API во времени. Например, у вас есть 2 сервиса А и Б. Сервис А делает запросы к сервису Б по REST API для получения необходимой информации. А зависит от Б, так как для его работы необходима информация из Б. Мы выпускаем новую версию сервиса Б, в которой изменилось API. Как сообщить клиентам сервиса Б, совместим ли API с предыдущей версией? 

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

Для решения вышеописанных проблем можно воспользоваться Семантическим версионированием (Semantic Versioning) - набором правил и требований, которые определяют, как назначаются и увеличиваются номера версии.