dair_targ_one


Манускрипт

Let's pray that heaven is on our side!


Орфография
dair_targ_one
Это ортография. Примерно как ортодонтогогия, ортопедия или ортонормировка.

О понятии времени в базах данных
dair_targ_one

Наше понятие времени — это такой наглядный способ представления частичной упорядоченности событий. Причём, поскольку релятивистские эффекты вокруг нас не особо заметны, то по наивности мы пытаемся упорядочить события полностью. В таком случае правильным будет задавать не вопросы вида «что случилось до 12:00», а вопросы вида «что случилось до того, как часы пробили 12:00».

Отсюда проистекает желание создать «транзакции». Отсюда же проистекают и попытки создать системы из нескольких серверов, данные на которых в любой момент времени «согласованы».

Таким образом выходит, что:

  1. База данных должна сохранять входящие сообщения как есть, а не пытаться что-то из них придумать («нам сообщили о том, что вчера была совершена транзакция, сразу после того, как часы пробили 12:00»).
  2. Нужно сохранять не «время получения сообщений», а то, какие события являются причинами, а какие — следствиями других. Событие-причина уже должно быть в базе в момент прихода события-следствия.
  3. Любой запрос к базе данных должен приводить к появлению события-ответа. Таким образом у базы автоматически появляется возможность и необходимость для каждого ответа знать причины именно такого ответа, а не другого.
    • Когда нас спросили о том, какие транзакции были вчера, а часы ещё не пробили 12:00, то мы ответили, что транзакций не было.
    • Когда нас спросили о том, какие транзакции были вчера, а часы уже пробили 12:00, то мы ответили, что транзакциb были.
    • Когда нас спросили, какие запросы были сделаны на текущий момент, то мы перечислили все предыдущие пункты.
    • Когда нас спросили, какие запросы были сделаны на текущий момент, то мы перечислили все предыдущие пункты.
  4. Из п.3 следует, что один запрос может являться причиной другого, а все запросы должны быть отражены в базе данных.

Открытыми остаются вопросы о правильной репликации (master-master) и шардинге такой системы. Как это правильно сделать?

P.S. Подскажите, где можно найти внятное математическое описание отношения причинности?


Ещё раз про базы данных
dair_targ_one

В продолжение прошлого поста.

  1. Каждый экземпляр приложения при работе с БД открывает сессию, в которой должны быть указаны название и версия приложения, а так же уникальный идентификатор этого приложения.
  2. Типы записей. Хорошо бы иметь алгебраические типы, функциональные и возможность ссылаться на другие записи в БД -- это какое-нибудь обобщение? Как это правильно называется?
  3. Тогда для каждой записи в БД хранить следующие поля:
    1. Идентификатор сессии
    2. Уникальный идентификатор записи
    3. Время создания записи по версии БД
    4. Сами данные
  4. Сами сессии также должны быть единообразно доступны в БД, наряду с остальными пользовательскими данными.
  5. Если строго соблюдать принцип, согласно которому пользователь имеет право только добавлять новые записи (insert) и делать выборки (select), то можно получить БД, которая обладает неподделываемой исторической картиной о том, кто, когда и что делал.
  6. Выглядит разумным поддерживать последовательности, описывающие изменения состояния некоторой сущности. В этому случае требуется поддерживать как упорядоченный во времени список состояний, так и предоставлять быстрый доступ к последнему -- текущему -- состоянию сущности.
  7. Индексация данных (в т.ч. индексация по значениям функциональным значениям) так же упрощается, поскольку сами данные полагаются неизменяемыми. В итоге такая БД может обладать достаточно простой масштабируемостью и репликацией.
  8. Остаётся вопрос о том, действительно ли требуются в такой БД транзакции? У меня складывается подозрение -- что нет, достаточно только атомарных операций или вообще запросов состояния на определённый момент в прошлом. Однако, такое поведение очевидно конфликтует с желанием иметь несколько master-экземпляров БД внутри единого кластера.

Дополнение: это всё называется Insert Only Database Design.


Работа с RDBMS
dair_targ_one
В текущем проекте практически удалось воплотить в жизнь "экстремистскую" версию работы с RDBMS: разрешены только операции INSERT и SELECT без возможности модификации и удаления. Хотя несколько модификаций всё-таки осталось, но надеюсь сотворить наконец приложение, которое честно хотя бы тем, что не меняет историю.
Итого: правильные ограничения -- это руководства.

Haskell beyond hello-world
dair_targ_one
Повредил на выходных правую руку и теперь на больничном. Сидеть скучно, поэтому немного позанимался хаскелем: код читает из файла значения свойств по их ключу. Поскольку всё на compileonline.com, то особо сторонних модулей пока не попользовать -- а то был бы regex.

Read more...Collapse )

Ну и эта мысль от ivan_gandhi про типы возвращаемых значений и паттерн-матчинг вместо Maybe и кодов возврата понравилась. Действительно лучше сказать компилятору, что ты хочешь, а не подразумевать и удивляться, почему он не понял.

Только вопрос остался: вот с этими типами как быть, когда какие-то тупые операции нужны, которые для Maybe уже описаны? Ну там catMaybes? Это ж на каждый чих прийдётся такое заново писать.

Письмо из зоопарка
dair_targ_one
Работа каждого военнослужащего расписана на весь срок службы, у каждого есть научный руководитель, составивший солдату план по интересующей армию проблематике. <...> Вячеслав практик: проверяет гипотезы, поливая вращающийся ротор компрессора подкрашенной тушью водой. Маркер позволяет увидеть вредоносную турбулентность. -- Научная рота разработала цифровые самолеты

[reposted post]Касательно полевых лагерей
twower
reposted by dair_targ_one
Некоторое время назад скинули ссылку на статью в НВО http://nvo.ng.ru/realty/2013-11-29/1_roofs.html (рекомендую прочесть полностью). Там главный вопрос следующий: почему не прекращаются попытки приобрести немецкие полевые лагеря, если есть отечественные наработки от ЗАО «НПП «Проект-техника»? Мол, немецкий лагерь не выдержал испытаний зимой и плохо себя показал.

По немцам. Есть информация, что закупками занимался Департамент планирования и координации МТО. В Керхер отказались работать напрямую, потому что их не устроила цена. Была создана фирма Хоккер, российский представитель фирмы Röder Zelt. Через нее был закуплен лагерь в Чебаркуль. Если в оригинальном лагере использовалась техника Miele, то в итоговом варианте взяли турецкие и китайские аналоги. Как они себя показали и как показал себя в целом лагерь, не могу сказать, нет информации. Напомню только, что изначально предсказывались проблемы с эксплуатацией из-за отсутствия у нас специальных подразделений для оной (подробнее читать здесь, там же можно посмотреть и фотографии лагеря).

По отечественным вариантам. К сожалению, в исходной статье по ссылкам подробно повествуется только об отдельных компонентах лагеря, но не о системе в целом. О ней как-то совсем мельком. Было бы неплохо увидеть лагерь от ЗАО «НПП «Проект-техника» в сборе. Я даже готов о нем написать. Есть информация, что с отечественными предложениями тоже не все идеально по качеству.

По отмене заказа на немецкие лагеря. В этом году со многими заказами так, очень-очень много ошибок в документации. Наверняка Сердюков на дому ворожит и заставляет людей ошибаться ;)
По ошибкам и отечественнным поставщикам. Планировалось закупать и отечественные комплекты лагерей от того же "Омнимеда", но они комплектовались беднее немецкого и заказ опять же был отменен из-за ошибок в документации (в частности, неверно указаны размеры палатки и площадь).

[reposted post]Почему тракторный завод останется в Канаде
babkin_k
reposted by dair_targ_one
Путин попросил написать записку о том, почему Ростсельмаш не переносит производство тракторов из Канады в Россию. Сравнить условия.

Думаю, эта информация будет интересна и вам.



ЗапискаCollapse )

Data flow или около того
dair_targ_one
Пропаганда functional programming шагает по планете. Там и сям оказывается, что используем мы монады, пусть и очень неправильно. И кабы их использовали как нужно и в явном виде, то всё было бы здорово. Ну, например, асинхронные вызовы, которые возвращают что-то типа Future[Either[Result, Error]].

Но вот только как-то не получается понять, как можно в удобоваримом виде записывать текстом графики data flow. Что-то вроде "Инициируем асинхронные запросы A и B. При удачном завершении A инициируем запрос C. А по завершении C и B отдаём ответ". Отсюда вопрос: как можно удобно записывать ветвления вида "результат предыдущей операции одновременно использовать в двух последующих"? В виде последовательного текста это выглядит не очень. В виде визуального редактора AST?

Home (Roberto Cacciapaglia-Nuvole di luce & Atlantico) - YouTube
dair_targ_one

You are viewing dair_targ_one