Признаюсь честно, у меня как у программиста, хоть и не настоящего, есть недоверие к «no-code» решениям. То есть тем, которые не требуют программирования, где всё можно делать через drag-and-drop и клики мышкой. Разве можно сделать на них что-то серьёзное? Как говорила ещё моя прабабушка: чтобы у кого-то появился «no-code», кто-то другой должен написать «a lot of code», ибо булки не растут на деревьях. 

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

Сейчас нет дефицита в ETL-инструментах. Их точно десятки, а если сосчитать все мелкие стартапы, то может и сотня наберётся. Одни импортируют данные из SQL баз, другие умеют подключаться к разным сервисам, наподобие Google Analytics или 1С, третьи — работают со статическими файлами. Есть и универсальные, которые «всеядны», причём часть из них умеют всё делать без программирования, то есть «no code». Проверенных сейчас найдётся, наверное, с дюжину. А точнее — «дюжина + 1», потому что я написал ещё один (да, в изобретении велосипедов мне нет равных).

TABLUM.IO — это многофункциональный сервис для загрузки и анализа данных, со встроенной визуализацией и автоматизацией. Сервис умеет работать и с базами данных, и со статическими файлами. Но в этой заметке я покажу, как с помощью него можно парсить данные из сервисов, работающих по API, и приведу несколько примеров загрузки и парсинга данных по URL. А в конце расскажу, какие фокусы можно делать с импортированными данными: в частности, как по ним строить графики и отправлять результат по расписанию в Телеграм, Slack или на email. Причём, это будет почти «no-code», т.к. из программирования нам потребуется только щепотка SQL команд для фильтрации лишних данных, а остальное выполняется кликами мышкой, drag-and-drop'ом файлов и магией кода, который Дедушка Мороз напрограммировал вам на Новый Год (старался с самого лета). 

Чтобы было интереснее, попробуем реализовать небольшую, но вполне конкретную задачку. На базе TABLUM.IO соберём информер с ежедневной отправкой графиков и таблиц в Telegram, Slack и на email. Например, это будет информер курсов обмена валют. Хотя по аналогии можно настроить мониторинг продуктовых метрик, состояния сервера, динамики оплат из биллинга, статистики коммитов из гита и многого другого. Было бы откуда загружать данные. 

Кстати, если вам удобнее смотреть видео вместо чтения статьи, есть и такая опция. Хотя в статье примеров будет больше. 

Итак, мы собираем свой информер курса обмена валют, и начинаем с выбора источника данных. Для нашей задачи подойдёт фид с floatrates.com. Он возвращает массив обменных курсов для указанной валюты (в нашем случае — рубля) в формате JSON. Фрагмент возвращаемой структуры приведён ниже:

Для загрузки данных по указанному URL нужно выбрать коннектор URL Downloader и вставить адрес источника данных в форму: 

TABLUM.IO загрузит данные, распарсит их и превратит в SQL таблицу (что немного похоже на магию). Сущность, в которую запишутся данные, будем называть «View».

Небольшое лирическое отступление: каждый столбец при загрузке неструктурированных и нетипизированных данных автоматически получает свой тип. 

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

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

Но вернёмся к нашей исходной задаче создания информера. Текущая таблица слишком объёмная для отправки в мессенджер, поэтому было бы неплохо сократить число валют до нескольких популярных (пусть это будут USD, EUR, GBP), а также убрать лишние столбцы. Для этого нужно сгенерировать новый «View» из текущего. Это можно сделать через SQL-запрос ко «View» со списком курсов валют, выбрав в качестве источника данных «Saved Datasets». 

Подзапросы возможны благодаря тому, что все данные, которые загружаются в TABLUM.IO, превращаются в SQL таблицу. И с ними можно работать, как с обычной БД (синтаксис SQLite3). Для адресации к конкретной таблице нужно указать имя «View» в формате <Dataset_X>.<View_Y>. Например, если текущий датасет имеет идентификатор DS_1247, а вью — V_1001, то общий запрос к данным будет выглядеть так:

SELECT * FROM DS_1247.V_1001

Следующей SQL-командой можно получить значения курсов валют для нашего случая:

SELECT
	  `date` as Date,
	  `alphacode` as Currency,
	  `inverserate` as RUB
	FROM
	  DS_1247.V_1001
	WHERE `alphacode` in (’USD’, ‘EUR’, ‘GBP’)

Теперь таблица компактная, в ней только три столбца и три строки. Можно настраивать периодическую отправку данных в мессенджеры или на email:

Выбираем обновление раз в сутки и в целях демонстрации все доступные каналы (Slack, Telegram и Email).

Чтобы убедиться, что всё работает не дожидаясь следующего дня, можно нажать на «Run Test».

В Телеграм-бот и Slack придут примерно такие сообщения:

А на почту:

Как вы наверняка заметили, данные из табличного вида сконвертировались в текстовое представление. Но данные можно отправлять и в виде картинки с диаграммой или графиком. 

Для примера №2 построим график, используя другой набор данных — динамику курса доллара за последние 30 дней с сайта ЦБ, и настроим его отправку в Telegram и Slack. 

Здесь данные также загружаются через URL Downloader, но в формате XML. 

В данном запросе появляется дополнительный параметр root=”Record”, который определяет корневой элемент XML данных, с которого URL Downloader начнёт парсить массив. 

Итак, данные загружены, сконвертированы сервисом в таблицу, остаётся построить график. Это три клика:

Результат:

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

Вот в таком виде будет приходить ежедневный апдейт в Telegram:

URL Downloader — это универсальный загрузчик данных в форматах XML, JSON, CSV, TSV. Для многомерных массивов или древовидных структур ему можно задавать корневой элемент через параметр root в формате

root=”node1>node2>node3”

А также указывать дополнительные HTTP заголовки. Например, мой запрос к сервису JIRA выглядит следующим образом:

(в примере ключ от Basic авторизации я, конечно, немножко поменял)
(в примере ключ от Basic авторизации я, конечно, немножко поменял)

С помощью TABLUM.IO в SQL таблицу можно перевести результат любого API вызова, при условии, что он вернёт данные в форматах JSON, XML или CSV. И, в общем случае, можно загружать данные по URL и с желаемой периодичностью. Вот ещё несколько примеров:

Можно распарсить что-нибудь с GIT, построить аналитику по коммитам и получать апдейты в мессенджер:

Аналогичным образом парсятся RSS/Atom-фиды или погода:

Учитывая то, что современные сервисы работают по HTTP POST, авторизуются по токену и возвращают данные в JSON или XML форматах (всё это сервис умеет делать), TABLUM.IO становится своеобразным «карманным» Zapier, на котором можно реализовать даже несложные пайплайны данных (через API). 

Буду рад, если и вы также найдёте для себя сценарии работы с сервисом.

Кстати, если у вас возникли идеи, как ещё можно использовать возможности TABLUM.IO, напишите в комментариях.

А если вам интересно следить за судьбой проекта, подписывайтесь на Telegram-канал.

Комментарии (5)


  1. slavashock
    10.12.2021 13:37
    +2

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

    В соответствии с no code парадигмой совсем не реализованными остаются функции работы с визуализацией.

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

    Возможно это всё можно реализовать написанием соответствующих SQL запросов, но тогда - это точно не no code.

    При создании графиков не хватает:

    • Настройка крайних значений оси.

    • Нет настройки типа аггрегации значений, по умолчанию это суммирование, что не всегда подходит.

    • Нет настройки аггрегации по какому-либо параметру.

    • Неочевидно назначение кнопок переключения состояния Y2, вероятно это включение вспомогательной оси.

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

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


    1. tablum Автор
      10.12.2021 15:53

      Спасибо за развернутый и конструктивный комментарий, а также предложения. Мне это очень ценно. Отвечу по вашим пунктам ниже:

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

      Вы правы, сейчас нет алертов при выходе за граничные значения. Это будет добавлено чуть позже. Пока все это можно реализовать просто подзапросами на SQL с настройкой отправки данных в один из желаемых каналов (Telegram, Slack, Email). В данной версии это пока доступно как "low-code".

      Настройка крайних значений оси.

      Принял. Это достаточно легко добавить. Думаю, что смогу сделать в ближайшей версии.

      Нет настройки типа аггрегации значений, по умолчанию это суммирование, что не всегда подходит. Нет настройки аггрегации по какому-либо параметру.

      Для no-code агрегации есть функции в выпадающих меню столбцов таблицы. Там можно указать какую функцию применить и по какому полю выполнить группировку. В результате будет сформирован SQL запрос и новая выборка данных в отдельном вью (в отдельной таблице). Это включает в себя и GROUP BY, и популярные оконные функции, наподобие "суммы с накопительным итогом", или "скользящего среднего".

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

      Неочевидно назначение кнопок переключения состояния Y2, вероятно это включение вспомогательной оси.

      Да, это включение второй оси Y. Подумаю, как это сделать более понятным.

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

      Разница будет заметна при 2 и более наборах данных, которые отображаются на графике. Например, можно выбрать несколько столбцов для отображения на оси Y, нарисуются два графика, и для них будет меняться цветовая палитра при переключении кнопками 1/2/3. Еще разницу можно посмотреть на Pie Chart'е или Donut Chart'е, там меняются цвета сегментов. Про белый на белом - не совсем понял, вроде бы цвета всегда отличные от белого (разве что где-то есть неизвестный мне баг).

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

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


  1. laisto
    10.12.2021 17:23
    +1

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


    1. tablum Автор
      10.12.2021 17:41

      Замечание принимается, спасибо. Хотя в статье я постарался рассказать о том, как сделать загрузку, парсинг и визуализацию данных без кодирования. Ровно то, что указано в заголовке. Я не рассказываю историю создания продукта (это было в предыдущей статье), и в заголовке не обещаю сравнения продуктов, для этого бы назвал статью «Сравнение no-code сервисов для …».