75мб 250мб, пока не идеально, надо еще webpack-ом прогнать electron слой и его node_modules из конечной сборки удалить оставив только используемое сжатое и минифицированное, тогда получится +- 25мб и 150мб (electron framework жирный, +-140мб), пока на этом приторможу
Да, in-memory называется minilinks, никаких fsync, чистый js. Сейчас допиливаем к ней синхронизатор с local storage и capacitor storage, что бы можно было по bool_exp (диалект всех .select/update/delete функций) указать что синхронить. Плюс теперь она поддерживает { remote: true, local: true } опции и при создании экземпляра подключения Deep и при выполнении любых методов, что позволяет делать изменения сначала на клиенте потом на транзакцией на сервере, по аналогии с Meteor.js minimongo, или при remote: false только на клиенте.
Ты еще помнишь мои стааарые эксперименты с монгой) Приятно. @alhimik45 прав, сейчас там PostgreSQL в продакшен версии. Да у нас есть C++/Rust версия ядра, но мы ее не рекомендуем и она нигде по умолчанию не подключена сейчас, так как еще в разработке. Да она быстрее постгри в сотню ото и больше раз, но пока не релиз.
mp применяется только для деревьев где нужно применять права и правила доступа или иные причины для этого
мы ставили эксперименты с решением проблемы джойнов с помощью партицирования по критериям селекторов, и пробросом критерия какие партиции использовать при поиске
про дедубликацию мы практикуем создание комплексной базы например на википедии, а отдельные сообщения или цельное хранилище конкретного проекта может шифроваться целиком и не использовать само себя быть зависимым от обученной дедублицированной базы
API когда много микросервисов, или в целом размер инфраструктуры, становиться слабым местом для роста. Взаимозависимость типизации, потребность в человеческой интерпритации, написании и рефакторинге, часто зависимым и рекурсивным по системе делает проект многослойным и сложным в управлении. Мы придумали не API, а поместили все описуемые идеи под единственный ассоциативный API, по культуре Data Driven Development, поместив все вычисления на оркестратор под капотом (вместо прямых обращений от кода к коду напрямую используя данные только как вспомогательный слой оперируемый кодом). Переместив уровень API над данными, проблема рефакторинга и взаимозависимости программного кода перешла на уровень связей, где всё совместимо со всем. При необходимости можно создавать локальные Minilinks коллекции как слой кеширования или использовать существующие решения поверх gql, что бы избавиться от дополнительного ожидания завершения транзакций запрашивающим или подписавшимся на эти данные клиентом.
Мы позиционируемся как фонд развития ассоциативных технологий.
Люди которые в нас верят, верят в идею единоописуемости чего угодно ассоциативно. Фреймворк Глубины позволяет это на сквозь связать с любыми языками и средами разработки. Очень скоро мы анонсируем единообразно доступную криптографически распределенную (шаг для нас из web2 к web3) память в едином поле связей. Работаем над мат-теорией Ассоциативности и соединяем ИИшки как GPT, векторые базы данных, семантический анализ, парсинг, рекурсивный анализ (используя нейронки). Вся эта практика для нас - образ жизни.
Думаю, учитывая кто и почему это написал, это реклама образа жизни, и личной мечты которая живет в каждом разработчике - универсальная сквозная всеописующая система, и консультативная среда в которой можно вместе учиться и развиваться.
Для меня как для одного из фаундеров публикация это статьи была сюрпризом. Это инициатива одного из Кадетов Глубины. Мы (основатели и экипаж Глубины) никак не контролируем и не поощраем "рекламу". Однако сами Кадеты оценивают свои действия и в случае если сообщество считает что это ценно присваивает звезды. Обычно это за написание какого-то прикольного пакетика.
Мне не ловко что это воспринимается рекламой. Кто-то хочет дать совет по имиджу, что тут не так? Думаю такая консультация будет полезна Кадетству.
Это лишь значит что из backend developer они станут разработчиками поведений, обработчиков, платных пакетов на которых можно зарабатывать, а не просто продавать код работодателям.
Мы не можем уделять полное время проекту, так-как проект не может себя обеспечивать, мы только нашли ресурсы на то что бы собраться и запуститься. Поэтому некоторые вещи как примеры затягиваются) Сейчас делаю запрошенный в голосовалке пример с мессанжером для следующей статьи. Если дип развернут, то тут можно воспроизвести первые шаги по созданию пакета @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 культуры работы с данными, переосмыслили и предлагаем решение.
75мб 250мб, пока не идеально, надо еще webpack-ом прогнать electron слой и его node_modules из конечной сборки удалить оставив только используемое сжатое и минифицированное, тогда получится +- 25мб и 150мб (electron framework жирный, +-140мб), пока на этом приторможу
Скриншоты содержания билда
Есть что сказать |-o-> будет исправлено, уже в процессе 🫡
Да, in-memory называется minilinks, никаких fsync, чистый js. Сейчас допиливаем к ней синхронизатор с local storage и capacitor storage, что бы можно было по bool_exp (диалект всех .select/update/delete функций) указать что синхронить. Плюс теперь она поддерживает { remote: true, local: true } опции и при создании экземпляра подключения Deep и при выполнении любых методов, что позволяет делать изменения сначала на клиенте потом на транзакцией на сервере, по аналогии с Meteor.js minimongo, или при remote: false только на клиенте.
Ты еще помнишь мои стааарые эксперименты с монгой) Приятно.
@alhimik45 прав, сейчас там PostgreSQL в продакшен версии. Да у нас есть C++/Rust версия ядра, но мы ее не рекомендуем и она нигде по умолчанию не подключена сейчас, так как еще в разработке. Да она быстрее постгри в сотню ото и больше раз, но пока не релиз.
про легковесность да
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 культуры работы с данными, переосмыслили и предлагаем решение.
Готовы ли вы поверить что на самом деле рефакторинга не существует в вашей реальности?