Бесконечность схем данных

Расскажу об одной боли при разработке и проектировании ПО — преобразованиях данных между их схемами. Буду говорить о серверах, как наиболее наглядном и знакомом мне примере, но соображения можно распространить на весь софт.

Для демонстрационных целей местами может случиться некоторое преувеличение.

Рассмотрим простейший проект, этакий минимальный набор:

• один тип клиентов;
• один сервис;
• одно хранилище.

Данные, соответственно, ходят в обе стороны:

• между клиентом и сервисом;
• между сервисом и хранилищем.

Сколько схем данных вы тут видите?

Далее

GraphQL & Python

Как и собирался, полез разбираться с GraphQL.

Смотрел на него в контексте Python, поэтому возможны искажения — технология родилась, как и многое сейчас, в мире JavaScript — референсная реализация на этом языке сделана.

Далее

Подписал письмо в поддержку Столлмана

Подробно описывать ситуацию не буду — она много где уже разжёвана. Начать раскопки можно с хабра.

Само письмо: https://rms-support-letter.github.io/

Подробнее о письме на русском, с толикой теории заговора.

Далее

Тарантога: первый блин

Продолжаю прототипировать свои идеи. Ожидаемо, первый блин вышел комом: и по срокам и по качеству. Однако получилось опробовать описанные ранее концепции, посмотреть что работает, а что нет.

Фактически, реализована база знаний для хранения метаинформации, GUI для её просмотра, пара агентов. И много нареканий к выбранному пути :-)

Поэтому попробую переосмыслить архитектуру Тарантоги.

Далее

Yet another Тарантога

Не только я пытаюсь собрать всю свою информацию в одном месте.

Вот описание созданной за год инфраструктуры от другого энтузиаста.

Знакомство с блогом karlicoss и подтолкнуло меня делать собственный велосипед. Всегда приятно узнать, что ты не один такой упоротый :-) Там же я позаимствовал пару базовых концепций.

В отличии от меня, karlicoss избрал более прагматичный подход:

• Поставил во главу угла data liberation — освобождение данных — получение копий всех сущенственных данных, которыми пытаются владеть облака и прочие сервисы. Возможно, логика в том, что владение данными первично, а как их обработать всегда можно придумать.
• Не пытается (пока) изобретать универсальные форматы или универсальный софт. Просто делает инфраструктуру экспорта, хранения и обработки информации, которая работает. То есть у него получается сеть из источников, экспортёров, обработчиков и дашбордов.

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

Но из того, что чего-то не вижу, не следует, что этого нет.