Для начала я расскажу вам немного про App Inventor, а потом мы напишем первое приложение, где будем кормить кота.

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

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

Предположим у нас имеется: Arduino Leonardo – 1 штука, Bluetooth модуль – 1 штука, Android смартфон – 1 штука. Ключевое отличие Leonardo от остальных ардуин заключается в том, что она поддерживает протоколы HID, а по-простому может притворятся мышкой или клавиатурой. Выглядит это примерно следующим образом:

#include "Mouse.h" // импортируем библиотеку работы с мышью
void setup(){}            // ничего не настраиваем
void loop()
{
 Mouse.move(10, -15, 3);  // сдвигаем курсор на 10 пикселей вправо, на 15 пикселей вверх и колесо на 3 оборота
}

Как видим все крайне просто. Метод Mouse.move(X, Y, WHEEL) принимает три относительных параметра: 

X – величина смещения в пикселях по оси X (отрицательные значения сдвигают влево)

Y – величина смещения в пикселях по оси Y (отрицательные значения сдвигают вверх)

WHEEL – величина смещения колеса прокрутки (отрицательные значения сдвигают в другую сторону)

Но сама по себе идея двигать курсор ничего не стоит, если не мы его контролируем, а значит нам нужно непосредственно HID (Human Interface Device), или по-простому устройство ввода. В нашем случае мы его сделаем из смартфона, «написав программу» в среде AppInventor, но, предварительно, разберемся с железной частью и напишем скетч для Arduino. Данные в Leonardo со смартфона мы будем отсылать по bluetooth. Модуль bluetooth можно использовать любой подходящий, наиболее популярным решением является HC-05(06). Подключаем по следующей схеме:

В рамках программы по унификации установленных серверных систем встала задача по переделке почтового сервера. Вдумчивое изучение мануалов и руководств показало довольно любопытный факт – нигде не было найдено однозначно достоверного руководства или подобия Best Practice по развёртыванию почтовика.

Мануал пошаговый, основывается на внутренней документации компании и затрагивает совершенно очевидные вопросы. Гуру могут не тратить время, ноу-хау здесь нет – руководство является сборной солянкой и публикуется только потому, что все найденные руководства по развёртыванию почтовика напоминали картинку о том, как рисовать сову.

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

Соответственно для реализации такой системы перед администратором ставятся задачи: во-первых, каким образом эти логи собирать, во-вторых, каким образом с ними удобно и централизованно работать. Благодаря достаточно развитой связке ELK (Elasticsearch + Logstash + Kibana), уже не раз описанной на Хабре, у администратора имеются инструменты для удобного поиска и отображения всей присутствующей в логах информации. Поэтому ответ на вторую задачу имеется изначально, и остается лишь решить задачу по сбору логов.

Так как в моем случае требованием к системе было отсутствие клиента на серверах, и то, что логи требовалось вытаскивать с Windows-серверов, то в качестве инструмента сбора был выбран родной для Windows — powershell.
Исходя из этого была составлена следующая модель сбора и отображения информации из логов: логи удаленно собираются с серверов powershell-скриптом, после чего складываются в виде файлов на хранилище, далее средствами ELK (Elasticsearch + Logstash + Kibana) происходит их обработка и отображение.

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