Pull to refresh
6
0
Иван Сергеевич Глазунов @IvanSGlazunov

Апостол Глубины

Send message

про легковесность да

mp применяется только для деревьев где нужно применять права и правила доступа или иные причины для этого

мы ставили эксперименты с решением проблемы джойнов с помощью партицирования по критериям селекторов, и пробросом критерия какие партиции использовать при поиске

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

API когда много микросервисов, или в целом размер инфраструктуры, становиться слабым местом для роста. Взаимозависимость типизации, потребность в человеческой интерпритации, написании и рефакторинге, часто зависимым и рекурсивным по системе делает проект многослойным и сложным в управлении. Мы придумали не API, а поместили все описуемые идеи под единственный ассоциативный API, по культуре Data Driven Development, поместив все вычисления на оркестратор под капотом (вместо прямых обращений от кода к коду напрямую используя данные только как вспомогательный слой оперируемый кодом). Переместив уровень API над данными, проблема рефакторинга и взаимозависимости программного кода перешла на уровень связей, где всё совместимо со всем. При необходимости можно создавать локальные Minilinks коллекции как слой кеширования или использовать существующие решения поверх gql, что бы избавиться от дополнительного ожидания завершения транзакций запрашивающим или подписавшимся на эти данные клиентом.

Мы позиционируемся как фонд развития ассоциативных технологий.

Люди которые в нас верят, верят в идею единоописуемости чего угодно ассоциативно. Фреймворк Глубины позволяет это на сквозь связать с любыми языками и средами разработки. Очень скоро мы анонсируем единообразно доступную криптографически распределенную (шаг для нас из web2 к web3) память в едином поле связей. Работаем над мат-теорией Ассоциативности и соединяем ИИшки как GPT, векторые базы данных, семантический анализ, парсинг, рекурсивный анализ (используя нейронки). Вся эта практика для нас - образ жизни.

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

Для меня как для одного из фаундеров публикация это статьи была сюрпризом. Это инициатива одного из Кадетов Глубины. Мы (основатели и экипаж Глубины) никак не контролируем и не поощраем "рекламу". Однако сами Кадеты оценивают свои действия и в случае если сообщество считает что это ценно присваивает звезды. Обычно это за написание какого-то прикольного пакетика.

Мне не ловко что это воспринимается рекламой. Кто-то хочет дать совет по имиджу, что тут не так? Думаю такая консультация будет полезна Кадетству.

Это лишь значит что из backend developer они станут разработчиками поведений, обработчиков, платных пакетов на которых можно зарабатывать, а не просто продавать код работодателям.

Знать любой язык откуда комфортно делать gql запросы, как например javascript.
Запустить дип пользуясь gitpod облачным решением для начала отсюда https://ivansglazunov.notion.site/Install-and-Using-8f213fbd532e4c869626b061b691ba2c
Тут можно примерно понять как можно подключиться к deep например из js https://runkit.com/ivansglazunov/deep-runkit

Мы не можем уделять полное время проекту, так-как проект не может себя обеспечивать, мы только нашли ресурсы на то что бы собраться и запуститься. Поэтому некоторые вещи как примеры затягиваются) Сейчас делаю запрошенный в голосовалке пример с мессанжером для следующей статьи. Если дип развернут, то тут можно воспроизвести первые шаги по созданию пакета @deep-foundation/messaging. https://runkit.com/ivansglazunov/deep-create-messaging-package

На выходе будет статья с правами, системой авторов, ответвлений диалога, временем, с размышлениями о том почему именно так, и воспроизводимым сценарием создания проекта прямо из runkit. Но процесс мы публикуем в дискорд, и иногда упоминаем в коментах. В процессе мы просто используем runkit и репозиторий https://github.com/deep-foundation/nextjs для создания приложений работающего в deep.

Мы рассчитывали в альфу сделать терминальчик/notebook как runkit (об этом говорит надпись по левой границе приложения) но мы немного не успели. Добавим в будущих версиях ;).

Когда это понял, забыть уже не получиться. Добро пожаловать в культ глубины.

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

Каждый кто научился думать ассоциативностью, может переносить себя в это пространство, пока сложно, и нужна разработка, но вместе мы сможем прорвать этот барьер. Уйти от sofrware и hardware уровня на концептуальный уровень. Язык изменит свою суть.)

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

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

Но мы подумали что то, что мы знаем как все это сделать, еще не значит что от этого мы это заявим будем выглядеть вменяемее для...

> И на минуту заходим в новости. Понимаем что происходит вокруг. Возвращаемся.

Ну да, что бы выглядеть стартапом, для ycombinator. Ага.

Есть желание записать подкаст, пообщаться на эту тему)?

Кстати, а сюда можно в комментарии например ссылку на телеграм комнату выложить если мы решим так сделать? Хм. И если можно, и написать здесь об этом в комментарии, сколько на самом деле таких вот путешествующих по сети в поисках способа поиска способа поиска зайдет туда слушателями.

Прямо сейчас это мета язык представленный в виде сквозной архитектуры. То есть, на ассоциативном языке можно выразить любую структуру? Да. Бизнес логика, как ассоциативная структура, выразима. Да, и плохая эволюция CRM/CMS/ERP, закрытая, с очень ограниченной степенью гибкости доступной без кода, не "золотой век скажем так.". Это вполне естественно быть способными выносить бизнес логику в бд на 1000% для модульной сквозной архитектуры построенной на ассоциативности как на мета языковом слое с подменяемым engine хранения, представления, и выполнения кода. Бизнес логика это самое очевидное, та аудитория которая получит первую волну позитивных впечатлений.

Дип можно противопоставить некоторому целостному решению по backend архитектуре.
Например meteorjs. Или Laravel/Ruby&Rails, но только сразу вместе с настроенной инфраструктурой данных.
С Undertand сравнивать не получается, они предлагают аналитические инстурменты и визуализацию. Мы же даем backend, хранение данных. Так что бы backend больше не требовал разработки в принципе. Влажная мечта ERP/CRM/CMS все всех времен - пакеты/плагины/модули с бесконечной совместимостью друг с другом, и без программиста в качестве смазки между решениями.

Да когда пакетный мендежер выйдет из альфы, когда мы опубликуем совместимые с разными пакетными менеджерами (уже в разработке) решения для публикации и установки пакетов с зависимостями, то все именно так так - это no-code платформа, с феноменальными свойствами совместимости моделей данных и поведения. Где можно писать на любом языке, а для не разработчиков пользование ей сведется к операциям по insert/update/delete связей, которые будут пораждать те или иные ракции как внутри транзакций синхронно так и асинхронно. С феноменально гибкой системой прав... кажется я уже начал переписывать статью)) Упс.

  • Какие ценности? "Открытость" и "прозрачность" точно сформулировано.

  • Какие мультиязыковые культуры? Мы создали альтернативный способ организации миркосервисов вокруг ассоциативных данных. Мультиязыковые - запуск кода на любом языке в определенном контексте связей, с доступом к окружению.

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

    Я боюсь описать весь проект в одном ответе не получиться. Статья и писалась что бы обьяснить по пунктам задачи и решения. И да мы действительно хотим изменить мир, это не беззворд, это факт. И начали мы с backend культуры работы с данными, переосмыслили и предлагаем решение.

Готовы ли вы поверить что на самом деле рефакторинга не существует в вашей реальности?

В конце моего первого ответа я сразу дал ответ на этот вопрос.

Продублирую специально для вас.

Мы будем подерживать кастомные таблички вроде этих string/number, поставляемые вместе с ассоциативными моделями. Единственное ограничение - они не должны использоваться для ссылочны данных, только для хранения данных.

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

Спасибо @lair за внимание к нам и статьям. Очень приятно видеть такие вдумчивые вопросы и интерес.

Мы еще не релизнули packer/unpacker который бы позволял пушить ассоциативные модели с правами и поведением в пакет для пакетных мендежеров.

Сделал за 10 минут пример. Он работоспособен в демке.

Но если представлять как это могло бы быть не придираясь к словам: это были бы типы add, at, time в дополнение к тем что есть в демке. Я бы их добавил в mp нужный для запросов (это в следующей статье как раз). Пунктирные линии - визуализация materialized path вычисленного в триггере в момент когда mp_include добавил к каждому из новых типов.

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

{
  number_aggregate(where: {
        link: {
      _by_item: { path_item_id: { _eq: 37 } },
      type_id: { _eq: 31 },
    },
  }) {
      aggregate {
        sum {
          value
        }
    }
  }
}
{
  "data": {
    "number_aggregate": {
      "aggregate": {
        "sum": {
          "value": 19
        }
      }
    }
  }
}

Поиск всех данных что есть

Вставка этой демо структуры в демке. Пока так. В разработке обращение к типам не по id а по package/typename (если сильно упрощать).

Прошу учитывать:

  • сейчас нет некоторых механик, и временный побочный эффект - необходимость указания id

  • пример перестанет работать уже в течении месяца-двух, так как 31, 32... id будут заполнены и вероятно появиться reserved id механика и механика обращения к линкам по package/linkName.

mutation {
  insert_types: insert_links(objects: [
    { id: 31, type_id: 1, from_id: 0, to_id: 0 },
    { id: 32, type_id: 1, from_id: 0, to_id: 0 },
    { id: 33, type_id: 1, from_id: 31, to_id: 32 },
  ]) {
    returning { id }
  }
  insert_type_names: insert_string(objects: [
    { link_id: 31, value: "add" },
    { link_id: 32, value: "time" },
    { link_id: 33, value: "at" },
  ]) {
    returning { id }
  }
  insert_mp_include: insert_links(objects: [
    { id: 34, type_id: 22, from_id: 23, to_id: 31 },
    { id: 35, type_id: 22, from_id: 23, to_id: 32 },
    { id: 36, type_id: 22, from_id: 23, to_id: 33 },
  ]) {
    returning { id }
  }
  insert_demo_user: insert_links(objects: [
    { id: 37, type_id: 14, from_id: 0, to_id: 0 },

    { id: 38, type_id: 31, from_id: 0, to_id: 0 },
    { id: 39, type_id: 31, from_id: 0, to_id: 0 },
    { id: 40, type_id: 31, from_id: 0, to_id: 0 },

    { id: 41, type_id: 32, from_id: 0, to_id: 0 },
    { id: 42, type_id: 32, from_id: 0, to_id: 0 },
    { id: 43, type_id: 32, from_id: 0, to_id: 0 },

    { id: 44, type_id: 13, from_id: 37, to_id: 38 },
    { id: 45, type_id: 13, from_id: 37, to_id: 39 },
    { id: 46, type_id: 13, from_id: 37, to_id: 39 },

    { id: 47, type_id: 33, from_id: 38, to_id: 41 },
    { id: 48, type_id: 33, from_id: 39, to_id: 42 },
    { id: 49, type_id: 33, from_id: 40, to_id: 43 },
  ]) {
    returning { id }
  }
  insert_demo_values:insert_number(objects: [
    { link_id: 38, value: 12 },
    { link_id: 39, value: 7 },
    { link_id: 40, value: 15 },
  ]) {
    returning { id }
  }
}

Получение всего о юзере

{
  links: links(where: {
        _by_item: { path_item_id: { _eq: 37 } },
  }) {
    id
    type_id
    number {
      id
      value
    }
  }
}
{
  "data": {
    "links": [
      {
        "id": 37,
        "type_id": 14,
        "number": null
      },
      {
        "id": 38,
        "type_id": 31,
        "number": {
          "id": 1,
          "value": 12
        }
      },
      {
        "id": 39,
        "type_id": 31,
        "number": {
          "id": 2,
          "value": 7
        }
      },
      {
        "id": 41,
        "type_id": 32,
        "number": null
      },
      {
        "id": 42,
        "type_id": 32,
        "number": null
      },
      {
        "id": 44,
        "type_id": 13,
        "number": null
      },
      {
        "id": 45,
        "type_id": 13,
        "number": null
      },
      {
        "id": 46,
        "type_id": 13,
        "number": null
      },
      {
        "id": 47,
        "type_id": 33,
        "number": null
      },
      {
        "id": 48,
        "type_id": 33,
        "number": null
      }
    ]
  }
}

GUI будет намного приятнее, мы работаем над собственным вьювером, интуитивным управлением, и еще очень много чем. То что доступно сейчас - временно решение для наглядности демонстрации.

Мы будем подерживать кастомные таблички вроде этих string/number, поставляемые вместе с ассоциативными моделями. Единственное ограничение - они не должны использоваться для ссылочны данных, только для хранения данных.

У нас есть транзакции, локи. Об этом будет в следующих статьях.

1

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Works in
Date of birth
Registered
Activity