О миграциях backend
Недавно смотрел чего за последние годы сделано в области решений для миграций схем и данных в базах данных и как-то мне все решения не понравились. По крайней мере из open source ни одного проекта без косяков нюансов не нашёл.
Поэтому я решил порефлексировать и копнуть глубже — миграции баз данных всегда казались мне частным случаем общей проблемы обновления версий проекта.
Я предполагаю, что вы более-менее понимаете суть миграций в БД и сможете ориентироваться в моих допущениях: явных и неявных.
Первая часть эссе описывает миграции, пользу и проблемы от них. Вторая часть — мои пожелания к идеальной системе миграций.
Что почитать, чтобы лучше кодить?
Экспресс пост в ответ на вопрос.
Кратко: чтобы лучше кодить, надо больше кодить :-) и вдумчиво читать код.
Если чуть подробнее, то вопрос сложный и что-то посоветовать из чтения мне сложно:
- Я уже давно не читал книг для начинающих. Те, что вспомню, могут быть устаревшими лет как 10.
- У меня другой бэкграунд, о котором сейчас расскажу.
Я больше писал, чем читал :-D В итоге, когда я начал читать шаблоны проектирования, я подумал: «и что тут такого, я уже с этим сталкивался», когда листал совершенный код, я подумал аналогично. То есть моя практика обгоняла теорию.
Из книг я читал то, что советовали преподаватели в универе, благо было кому советовать, и то, что считал интересным. Страуструпа, например, 2 раза прочитал.
Верификация частными случаями
Буду говорить в контексте программирования, но соображения можно распространить шире.
Когда мы описываем алгоритм: программу, доказательство теоремы или решение математической задачи — мы строим его описание в рамках некоторой формальной модели. В рамках соглашений и ограничений, которые мы явно или неявно принимаем.
Описать алгоритм вне формальной модели невозможно. Хотя бы потому, что любой язык — уже формализация.
Отсюда вытекает интересная проблема.
Тарантога: второй блин
Потоки данных во второй версии прототипа Тарантоги.
Продолжаю эксперименты. Как видно из заголовка, вторая попытка тоже не удалась, хотя выглядит симпатичнее.
Реализация ушла довольно далеко от описанного в посте о первом блине. В частности, GraphQL не подошёл.
Как всегда, работа породила сторонние результаты. Я подумал об уменьшении сложности работы с данными, вынес в отдельную библиотеку логику работы с предикатами.
Вторую версию концепции я считаю жизнеспособной, но сильно затратной для развития в одного разработчика. Вот если бы меня было несколько, или проект уже существовал в рабочем виде, и надо было только дописывать новых агентов.
Но мы имеем, что имеем, поэтому буду думать дальше. Скорее всего попробую сделать в лоб: минималистично, стандартными подходами без интеллектуальных извращений. Всё-таки представление об инструменте уже несколько раз в голове перекрутил и оно значительно упростилось.
А пока расскажу что получилось на этот раз.
Pydicates: предикаты для Python
Опубликовал небольшую библиотеку для работы с предикатами в Python: github, pypi. Как всегда, под BSD-3.
Позволяет конструировать функции для отложенных вычислений. Например, описывать такие условия: (OwnedBy('alex') | OwnedBy('alice')) & HasTag('game-design').
Делал для себя, так как уже несколько раз в пет-проектах писал костыли для этого дела. Решил сделать один раз правильно и больше не тратить на это время.
Минимальный пример:
from pydicates import Predicate, common
def HasTag(tag):
return Predicate('has_tag', tag)
def has_tag(context, tag, document):
return tag in document['tags']
common.register('has_tag', has_tag)
document = {'tags': ('a', 'b', 'c', 'd')}
assert common(HasTag('a') & HasTag('c'), document)
assert not common(HasTag('a') & HasTag('e'), document)
assert common(HasTag('a') & ~HasTag('e'), document)
assert common(HasTag('a') & (HasTag('e') | HasTag('d')), document)Больше примеров можно найти в репозитории ./examples
API описано чуть подробнее в ./examples/documents_check.py
Больше примеров можно найти в тестах.