?

Log in

No account? Create an account

Ёбаная хипстота

мар. 8, 2016 | 12:35 am

Вот есть в NPM пакет: https://www.npmjs.com/package/date-now

Вот, грубо, его исходник:
module.exports = now

function now() {
    return new Date().getTime()
}

Там всё хорошо и правильно - есть CI, документация, тесты, контрибьюторы, релизы, лицензия MIT блять.

Тест есть вот такой:
test("date", function (assert) {
    var ts = now()
    var ts2 = Date.now()
    assert.equal(ts, ts2)
    assert.end()
})

Я проверил - вероятность того что наебнётся - примерно 0.00015.

И так в ноде, сука, всё.

Ссылка | Оставить комментарий {22} |

За реляционные базы

мар. 6, 2014 | 11:48 am

Идея хранить и оперировать данными в виде табличек - охуенна. У данных в таком виде есть куча полезных свойств - они нормально кладутся на диск, они сериализуемы, их можно весьма эффективно менять одновременно сохраняя удобные инварианты, их можно разглядывать в любой момент времени, можно рисовать понятные простым людям квадратики и стрелочки. Можно даже сделать DSL про алгоритмы поверх этих данных, который будет самостоятельно решать все эти ваши проблемы с O(n^2).

Проблема реляционной алгебры и SQL-баз - в полном отсутствии средств абстракции. Есть такое слово - "денормализация". Когда вы слышите это слово - читайте его так: мы будем закатывать вручную солнце, т.к. ни в одной БД нет средств абстрагирования. Все что мы имеем - вьюхи, триггеры, и хранимки - все это годами затачивалось под использование неграми с мотыгами на закате. Белому человеку от идеи трогать это своими ухоженными руками, делается грустно.

Приведу пример. Есть связь User->Order->OrderLine. Имея OrderLine, в нормализованной базе, мы не можем достать UserID, не сходив по двум связям. На практике, если потребуется, UserID скопируют и в OrderLine, будут вручную следить чтобы у OrderLine был тот же UserID что и у Order, и будут называть "денормализацией". Что по моему скромному мнению, в текущей ситуации торжества науки, светодиодов и айфонов, выглядит полным беспросветным пиздецом.

Мне грезятся альфа-бета-комбинаторы для реляционных данных. "Эту колонку клади в обе таблицы", "эти две таблицы физически лежат в одной", "readonly-поле createdBy заполняется при коммите", и т.п. Механизм, который позволит делать из одной кучки таблиц, удобной с точки зрения производительности, другую кучку, удобную для мозга. С прозрачным чтением и записью туда-сюда.

Вариант с альфа-бета-реляционными комбинаторами не претендует на единственное возможное решение проблемы. Сама проблема в том, что на данный момент ни ORM, ни вьюхи, ни триггеры, ни NO-SQL базы, ни блокнотик, ни dev\null, ничего из существующих технологий не позволяет забывать про то, как тщательно их разработчики раскладывают битики на диск.

У нас есть SSD, гигагерцы процессоров. Есть стандартная модель элементарных частиц. Вокруг планеты летают кругами предварительно разогнанные до гигантских скоростей куски из металла и наноэлектроники. А мне ни одна технология не позволяет положить уже хуй на эти битики и оперировать данными удобно, с транзакциями, не думая про планы запросов, и не занимаясь всякими ручными "денормализациями". В 21-м веке любой программист, хранящий важные данные - негр с мотыгой на фоне тросника и заката.
Метки:

Ссылка | Оставить комментарий {20} |