А я благодаря Claude Opus и Claude Sonnet больше не пишу код руками, не требуется его теперь и читать тоже, так как всегда можно задавать вопросы AI агенту. Уже более 6 месяцев я разрабатываю своего бота программиста используя Claude модели, и всё это время все свои 500+ репозиториев в open-source и в общественном достоянии поддерживаю используя этого самого бота-программиста, который мне Claude и помог написать. По сути для меня это означает первый реальный шаг к автоматизации автоматизации. Ну и конечно сам бот-программист тоже с открытым кодом и в общественном достоянии. Для меня это первое ПО, которое способно писать себя самостоятельно. Так что я очень доволен что появился ИИ и из программиста я больше трансформировался в тех-лида, который теперь принимает Pull Requests от ИИ и людей. А моя разработка фактически в одиночку помогла мне догнать и обогнать продукты крупных корпораций.
Если раньше я нанимал программистов, чтобы они помогали мне разрабатывать опенсорс проекты, то теперь такой мысли вообще не возникает. AI-агент, который интегрирован с GitHub фактически заменяет человека программиста в привычном мне flow - создать issue - сделать ревью Pull Request и смержить. Теперь я могу больше сфокусироваться на планировании и архитектуре, и поддерживать куда больше опенсорсных проектов фактически в одиночку. Поэтому с приходом ИИ ощущается что за $200 подписки Claude MAX я нанял себе целую команду разработки, которая готова работать по запросу 24/7. И разрабатывает код в десятки раз быстрее чем многие junior и middle программисты. Я может быть плохой senior программист, но за 25 лет программирования я не научился писать код вручную быстрее и точнее чем это делают AI агенты. Зато если их тех-лидить получается эффективнее на порядки.
Снижение цены может увеличить количество пользователей, которым это по корману, а следовательно увеличить общий объём выручки. И я думаю 4-ём человекам точно её должно хватить. В общем проблема кажется более чем преувеличенной.
В статье написано, что выручка упала на 80%. И то что после этого пришлось уволить разработчиков говорит о том, что у них были проблемы с финансовыми показателями и до этого. То что популярность росла (быть на пике сейчас, не значит продолжать рост в будущем), не значит что она растёт сейчас. Фактически ситуация следующая - компания не смогла адаптироваться и обвиняем мы почему-то во всём ИИ, но ИИ используется людьми, и фактический спрос как был, так и остаётся у людей (не важно используют они ИИ или нет). Чтобы выбраться из ситуации им нужно общаться со своими клиентами и находить компромиссы, нужно адаптироваться к рынку.
В конце концов у людей могли кончиться деньги или именно этот фреймворк действительно начал терять свою актуальность. В общем скорее всего мы снова увидим, что эту компанию кто-то купит, или ей придётся обанкротиться. Сейчас сложные времена в геополитике и экономике, так что не удивительно.
То, что мертво, умереть не может. То есть AI не может убить то, что умерло и так до этого. Дело в том, что проект умер не потому что AI появился, а потому что деньги были сожжены, в итоге у проекта не осталось денег чтобы жить дальше. В общем им нужно было фокусироваться на том, чтобы выйти на окупаемость хотя бы, а не продолжать наращивать убытки.
И сокращение разработчиков это ответ на увеличение убытков, то есть попытка сократить убытки, если бы проект был прибыльным, то и сокращать никого бы не пришлось.
И если нет спроса - нужно либо адаптироваться, либо уходить с рынка. AI тут не причём.
Я у себя в опенсорсной разработке своим ботом-программистом использую 6 шаблонов для популярных языков программирования JavaScript/TypeScript, Rust, Python, Go, C#, Java. Это шаблоны репозиториев с заранее настроенным CI/CD, который включает проверки линтерами (что стиль кода соответствует настроенным правилам), форматтерами (что код отформатирован так, как это того ожидается в проекте, то есть в едином стиле), тесты (unit, integration, e2e и т.п.), есть настроенный флоу для changesets с возможностью мержа нескольких версий в одну, если вдруг CI/CD сфейлился. Changesets помогают снизить количество конфликтов между Pull Requests, что позволяет сэкономить AI токены на что-то более важное. Также есть pre-commit-хуки, чтобы гарантировать, что часть проверок пройдёт ещё до того как AI или участник команды разработки попытается закоммитить код. Ну и конечно CD-часть - релизы в пакетные менеджеры/docker hub/helm и поддержка GitHub Releases.
Фактически это CI/CD для командной разработки, который гарантирует, что любой Pull Request будет соответствовать всем заданным стандартам качества.
В AI-Driven Development CI/CD это превращается добавляя одну критически важную проверку, требование чтобы все файлы с кодом и файлы документации были менее 1500 строк, если такого не сделать, то Claude Code CLI не будет способен прочитать исходный код или документацию в одном файле целиком (у него ограничение read tool в 25000 токенов на чтение за один раз), а значит он может упустить что-то при работе с ним. Это так же помогает и людям, так как маленькие файлы проще читать и поддерживать и для людей.
Зачем столько разных ролей я не очень понимаю, мне хватает одной роли AI issue solver в нашей системе и в будущем я планирую добавить роль архитектора. Если решатель создаёт Pull Request и пишет код, то архитектор будет занят исключительно постановкой задач, их декомпозицией, приёмом результатов и композицией частичных результатов в один целостный.
Так что мне лично кажется можно просто применить лучший опыт из того что мы уже всегда делали, но для AI и CI-проверки фактически выполнят роль ревьювера, и будут гарантировать что каждый Pull Request будет содержать минимум необходимых правок их будет легко читать и правки будут соответствовать необходимым стандартам качества.
Мой инструмент с открытым исходным кодом и в общественном достоянии - http://github.com/link-assistant/hive-mind - можете развернуть у себя, или написать мне в личку и дать ссылку на issue на GitHub запущу вам демонстрацию на уже поднятой моей инфраструктуре.
Чтобы получить полную отдачу от нейросетей, нужно не микроконтролить их, а запускать множество задач параллельно. Например мой бот-программист, делает одну рабочую сессию за 15-35 минут, и пока он занят своей работой - я ставлю следующие задачи, делаю ревью уже созданных ранее Pull Requests. Если вдруг нужны правки к Pull Request, я просто даю комментарий в Pull Request и отправляю бота работать дальше, пока сам делаю что-то другое.
И вот тогда, действительно есть прирост производительности, а не расход производительности. Но это уже больше не совсем вайб-кодинг, это уже больше управление командой виртуальных автономных программистов.
То есть один человек может вести параллельную разработку десятков задач одновременно благодаря такому подходу. Или запускать разработку черновиков к сотням задач ночью. То есть можно сделать так, чтобы код писался пока ты спишь.
А худшее что можно сделать это использовать Cursor или Claude Code CLI как их обычно используют - то есть сидеть и давать разрешение на каждый чих и каждую команду. Таким образом вести не более 1-3 задач одновременно.
А можно как-то наоборот привлечь внимание всех AI ботов планеты к нашим репозиториям на GitHub? Очень хотелось бы чтобы наш код стал частью их датасета для обучения. Как отключить этот robots.txt навсегда и принять всех ботов планеты с любовью?
А если посмотреть на это через призму теории связей, где и вершины и рёбра это связи. Получается можно сделать ещё один шаг и объединить оба подхода и исследовать на что способен общий случай.
Поддерживаю, стараюсь всегда использовать атомарные коммиты. То есть включать в один коммит только изменения на одну единственную тему (например связанную с одной фичой), которые в будущем если что могут быть отменены целиком в связи с откатом этой фичи.
Но каюсь, иногда бывает соблазн объединить парочку изменений, и всё-таки бывает, соединяю в один коммент, что нельзя было объединять.
А ещё это помогает в геймификации процесс программирования. К примеру я играю сам с собой в игру, мол, чем больше у меня зелёных квадратиков на GitHub и чем они зеленее, тем лучше. Лучшая стратегия победы в такой игре это делать каждый день минимум один коммит, и тогда ты точно побеждаешь, но вот реальность показывает что это делать не просто. И развивать самодисциплину - то ещё испытание. Но чем меньше коммиты тем проще это делать, тем проще себя мотивировать и проще получать удовольствие от того что коммиты сделаны :) А после этого хочется делать ещё коммитов и ещё :)
А ещё это помогает следовать принципу атомарной ответственности в задачах, если привязывать каждый коммит к конкретной задаче (issue), никогда нельзя будет сделать так, чтобы в нём содержался код связанный с несколькими задачами, это тоже дополнительно дисциплинирует и делает процесс разработки максимально прозрачным. То есть можно будет потом сделать roadmap/project, из которого можно перейти на конкретные issues, а оттуда на конкретные коммиты которые делались в рамках этой задачи.
Я бы попробовал, я не думаю что стоит использовать решение которое хранит всё только локально, можно шифровать и выкладывать в облака других сервисов. Это всё ещё звучит просто.
Теория графов по определению не позволяет ребрам ссылаться на рёбра. Поэтому у нас не графовая СУБД, а ассоциативная. Ассоциативная теория сейчас в разработке: первый черновик (апрель 2022-го), последний черновик (на декабрь 2023-го). Если коротко, общий случай: L ↦ L² (связи-дуплеты), частный случай L ↦ L³ (связи-триплеты).
В ассоциативной СУБД всегда можно добавить любое количество необходимых "легковесных" рёбер между связями/ассоциациями, просто создав связь/ассоциацию между ними. Да, требуется использовать join, однако у нас есть реализация materialized path индексации, которая позволяет снизить нагрузку на joins в SQL. И в целом mp это не единственный способ дополнительной индексации, которую можно наложить поверх связей. Что касается самих join, то наш следующий собственный движок СУБД разработанный с нуля на Rust делает их в 1000+ раз быстрее чем PostgreSQL, за счёт того, что из движка убрано всё лишнее (бенчмарк). И хотя сами легковесные рёбра уже способ оптимизации поиска или индексации, их можно заменить на битовые строки, которые позволят делать очень эффективное пересечение или объединение данных. С этим способом индексации мы тоже будем экспериментировать в новом движке.
И уже когда мы перейдём на этот движок, то все значения привязанные к связям, числа, строки, json и т.п. будут разложены на Дуплеты. И благодаря такому подходу сразу включится дедупликация последовательностей внутри значений, так и между значениями.
Именно поэтому нужно использовать системы, которые возвращают контроль над своими данными пользователю, и позволяют как минимум делать резервную копию, а как максимум позволяют постоянно отслеживать в каких социальных сетях и мессенджерах какие данные пользователя находятся. Эти данные можно использовать повторно, например разбирать переписку на список вопросов и ответов.
Что касается облачного хранилища особо важных файлов их вообще нужно постоянно синхронизировать между системами (например iCloud, Dropbox, Google Drive и т.п.), что фактически и будет создавать дополнительную активность.
Так же даже пусть если ты активен, это всё равно не значит что ты не потеряешь свои данные. Например, VK хранит всего 15 млн сообщений пользователя после этого он теряет к ним доступ, а новые сообщения затирают самые древние.
И так с заголовка: Deep.Foundation - переводится как Глубокий Фундамент. Буквально это оно и значит - глубокий фундамент для любого ПО, а так же в будущем и для всех наук (математика, информатика, физика, философия и т.п.). Мы фонд развития ассоциативных технологий. Почему ассоциативных? Потому что основанных в отличие от нулей и единиц (битов) на связях. На это можно посмотреть как на ассоциативную машины тьюринга, где вместо нулей и единиц на ленте в каждой ячейке находится целая связь. И алфавит таких связей неограничен. Связь это минимальная единица смысла. Из неё можно собирать объекты, она может хранить строгие последовательности в отличие от графов использует всего одну связь для последовательности в 2 элемента, 2 связи для последовательности в два элемента и т.п. Сами элементы не считаются тут, но они тоже связи.
С точки зрения математики мы это воплощение всех функций соответствующих шаблону L ↦ L². Иными словами в сердце Deep, и сам Deep это просто последовательность связей, то есть массив связей. Но так как последовательность может быть упакована в одну связь, то любой экземпляр Deep может быть представлен одним числом, именно поэтому мы можем реализовать Deep поверх любой машины тьюринга. Мы показали на практике, что не существует ни одной структуры данных, которую нельзя представить связями. То есть что угодно - множества, последовательности, деревья, графы, гиперграфы, объекты и даже функции представимы связями. Мы сейчас работаем над тем чтобы это ещё и доказать автоматизировано используя теорию типов и теорию множеств, вот следующий ещё не опубликованный черновик, если интересно.
Всё это упаковано в ассоциативную архитектуру приложений. Что это такое? Это готовый бэкенд и API, в который достаточно залить свои данные и сделать нужный тебе UI и готово приложение под все платформы: Web, Linux, Windows, macOS и скоро Android, iOS, а ещё позже самостоятельная OS с той же архитектурой, полностью настраиваемая и кастомизируемая пользователем.
Зачем подключать? Мы вавилонская башня в контексте программирования, это значит что используя нашу технологию мы можем сочетать мощь всех человеческих ресурсов в программировании. Код для этой системы можно писать на всех языках программирования, плюс она по совместительству уже и IDE.
Иными словами совсем просто - Deep это универсальный инструмент автоматизации, в том числе и для автоматизации самой автоматизации. Мы позволяем делать ПО быстрее чем когда бы то ни было. Вместо того чтобы ограничивать разработчика одним встроенным в систему языком, мы дали возможность подключать все языки вместе с их пакетными менеджерами, это значит ни одна строчка когда, которую вы где-либо когда-либо написали не пропадёт зря, можно использовать всё и сразу в одном месте.
Зачем это надо? Для ускорения реализации любой мечты. Для нас сам Deep стал мечтой, потому что мы хотели запускать сотни стартапов. Но поняли что нам не хватит ресурсов на всё, поэтому эти идеи стартапов у меня лично опубликованы, другие ребята из команды будут получать под остальные идеи инвестиции.
Я объясняю эту суть вам, а не бабушке, ребёнку или петомцу. Но вы уж, пожалуйста, скажите, какое первое слово в том о чём я говорю не понятно именно вам? Давайте я расскажу что это такое.
Да мы не успели довести до совершенства каждую деталь, и именно поэтому нам нужна помощь и мы ищем тех, кому понравилась идея которую мы разрабатываем. Хотите помочь - присоединитесь к нам. Не хотите - покажите где мы ошибаемся, и как сильно мы тут ошибаемся, мы примем это к сведению и будем ошибаться меньше.
Благодарю за понимание.
P.S. Если от такого ответа вопросов стало только больше, это нормально, у нас так уже многие годы напролёт. Поэтому мы и предлагаем зайти в наш Discord, посмотреть все демки и обсудить что конкретно не понятно именно вам. На все вопросы будут ответы.
Вижу проблему, что нет таких площадок, где можно было бы собирать команды под интересные стартапы.
Мы существуем, написал в личку, жду созвона. На тему ребят которые готовы делать что-то «за интерес», да, у нас есть и такие ребята. Действительно помимо того, что у нас быстрее и проще выйти новичкам на доход, для новичков это формирование портфолио и фундамента, на который они могут опереться. Ведь открый исходный код, а тем более если он в общественном достоянии, можно не только показать на следующем интервью у работодателя, этот код можно повторно использовать при необходимости. Ну и конечно же это сразу вклад в обучение будущих нейросетей таких, как GPT. И в этом смысле я не сторонник того, чтобы скрывать свой код от того чтобы его могли использовать для обучения, а наоборот внести вклад в то, чтобы эти нейросети получали для обучения код наивысшего качества. И это в наших общих силах.
А я благодаря Claude Opus и Claude Sonnet больше не пишу код руками, не требуется его теперь и читать тоже, так как всегда можно задавать вопросы AI агенту. Уже более 6 месяцев я разрабатываю своего бота программиста используя Claude модели, и всё это время все свои 500+ репозиториев в open-source и в общественном достоянии поддерживаю используя этого самого бота-программиста, который мне Claude и помог написать. По сути для меня это означает первый реальный шаг к автоматизации автоматизации. Ну и конечно сам бот-программист тоже с открытым кодом и в общественном достоянии. Для меня это первое ПО, которое способно писать себя самостоятельно. Так что я очень доволен что появился ИИ и из программиста я больше трансформировался в тех-лида, который теперь принимает Pull Requests от ИИ и людей. А моя разработка фактически в одиночку помогла мне догнать и обогнать продукты крупных корпораций.
Если раньше я нанимал программистов, чтобы они помогали мне разрабатывать опенсорс проекты, то теперь такой мысли вообще не возникает. AI-агент, который интегрирован с GitHub фактически заменяет человека программиста в привычном мне flow - создать issue - сделать ревью Pull Request и смержить. Теперь я могу больше сфокусироваться на планировании и архитектуре, и поддерживать куда больше опенсорсных проектов фактически в одиночку. Поэтому с приходом ИИ ощущается что за $200 подписки Claude MAX я нанял себе целую команду разработки, которая готова работать по запросу 24/7. И разрабатывает код в десятки раз быстрее чем многие junior и middle программисты. Я может быть плохой senior программист, но за 25 лет программирования я не научился писать код вручную быстрее и точнее чем это делают AI агенты. Зато если их тех-лидить получается эффективнее на порядки.
Снижение цены может увеличить количество пользователей, которым это по корману, а следовательно увеличить общий объём выручки. И я думаю 4-ём человекам точно её должно хватить. В общем проблема кажется более чем преувеличенной.
В статье написано, что выручка упала на 80%. И то что после этого пришлось уволить разработчиков говорит о том, что у них были проблемы с финансовыми показателями и до этого. То что популярность росла (быть на пике сейчас, не значит продолжать рост в будущем), не значит что она растёт сейчас. Фактически ситуация следующая - компания не смогла адаптироваться и обвиняем мы почему-то во всём ИИ, но ИИ используется людьми, и фактический спрос как был, так и остаётся у людей (не важно используют они ИИ или нет). Чтобы выбраться из ситуации им нужно общаться со своими клиентами и находить компромиссы, нужно адаптироваться к рынку.
В конце концов у людей могли кончиться деньги или именно этот фреймворк действительно начал терять свою актуальность. В общем скорее всего мы снова увидим, что эту компанию кто-то купит, или ей придётся обанкротиться. Сейчас сложные времена в геополитике и экономике, так что не удивительно.
То, что мертво, умереть не может. То есть AI не может убить то, что умерло и так до этого. Дело в том, что проект умер не потому что AI появился, а потому что деньги были сожжены, в итоге у проекта не осталось денег чтобы жить дальше. В общем им нужно было фокусироваться на том, чтобы выйти на окупаемость хотя бы, а не продолжать наращивать убытки.
И сокращение разработчиков это ответ на увеличение убытков, то есть попытка сократить убытки, если бы проект был прибыльным, то и сокращать никого бы не пришлось.
И если нет спроса - нужно либо адаптироваться, либо уходить с рынка. AI тут не причём.
Я у себя в опенсорсной разработке своим ботом-программистом использую 6 шаблонов для популярных языков программирования JavaScript/TypeScript, Rust, Python, Go, C#, Java. Это шаблоны репозиториев с заранее настроенным CI/CD, который включает проверки линтерами (что стиль кода соответствует настроенным правилам), форматтерами (что код отформатирован так, как это того ожидается в проекте, то есть в едином стиле), тесты (unit, integration, e2e и т.п.), есть настроенный флоу для changesets с возможностью мержа нескольких версий в одну, если вдруг CI/CD сфейлился. Changesets помогают снизить количество конфликтов между Pull Requests, что позволяет сэкономить AI токены на что-то более важное. Также есть pre-commit-хуки, чтобы гарантировать, что часть проверок пройдёт ещё до того как AI или участник команды разработки попытается закоммитить код. Ну и конечно CD-часть - релизы в пакетные менеджеры/docker hub/helm и поддержка GitHub Releases.
Фактически это CI/CD для командной разработки, который гарантирует, что любой Pull Request будет соответствовать всем заданным стандартам качества.
В AI-Driven Development CI/CD это превращается добавляя одну критически важную проверку, требование чтобы все файлы с кодом и файлы документации были менее 1500 строк, если такого не сделать, то Claude Code CLI не будет способен прочитать исходный код или документацию в одном файле целиком (у него ограничение read tool в 25000 токенов на чтение за один раз), а значит он может упустить что-то при работе с ним. Это так же помогает и людям, так как маленькие файлы проще читать и поддерживать и для людей.
Зачем столько разных ролей я не очень понимаю, мне хватает одной роли AI issue solver в нашей системе и в будущем я планирую добавить роль архитектора. Если решатель создаёт Pull Request и пишет код, то архитектор будет занят исключительно постановкой задач, их декомпозицией, приёмом результатов и композицией частичных результатов в один целостный.
Так что мне лично кажется можно просто применить лучший опыт из того что мы уже всегда делали, но для AI и CI-проверки фактически выполнят роль ревьювера, и будут гарантировать что каждый Pull Request будет содержать минимум необходимых правок их будет легко читать и правки будут соответствовать необходимым стандартам качества.
https://github.com/link-assistant/hive-mind/blob/main/docs/BEST-PRACTICES.md - подробнее документ об этом у меня есть тут со ссылками на репозитории-шаблоны. Всё с открытым исходным кодом и в общественном достоянии.
Мой инструмент с открытым исходным кодом и в общественном достоянии - http://github.com/link-assistant/hive-mind - можете развернуть у себя, или написать мне в личку и дать ссылку на issue на GitHub запущу вам демонстрацию на уже поднятой моей инфраструктуре.
Чтобы получить полную отдачу от нейросетей, нужно не микроконтролить их, а запускать множество задач параллельно. Например мой бот-программист, делает одну рабочую сессию за 15-35 минут, и пока он занят своей работой - я ставлю следующие задачи, делаю ревью уже созданных ранее Pull Requests. Если вдруг нужны правки к Pull Request, я просто даю комментарий в Pull Request и отправляю бота работать дальше, пока сам делаю что-то другое.
И вот тогда, действительно есть прирост производительности, а не расход производительности. Но это уже больше не совсем вайб-кодинг, это уже больше управление командой виртуальных автономных программистов.
То есть один человек может вести параллельную разработку десятков задач одновременно благодаря такому подходу. Или запускать разработку черновиков к сотням задач ночью. То есть можно сделать так, чтобы код писался пока ты спишь.
А худшее что можно сделать это использовать Cursor или Claude Code CLI как их обычно используют - то есть сидеть и давать разрешение на каждый чих и каждую команду. Таким образом вести не более 1-3 задач одновременно.
А можно как-то наоборот привлечь внимание всех AI ботов планеты к нашим репозиториям на GitHub? Очень хотелось бы чтобы наш код стал частью их датасета для обучения. Как отключить этот robots.txt навсегда и принять всех ботов планеты с любовью?
I recommend to rename the title to "Deep Links Theory 0.0.0", as in new article: https://habr.com/ru/companies/deepfoundation/articles/804617, so it will be searchable in English
А если посмотреть на это через призму теории связей, где и вершины и рёбра это связи. Получается можно сделать ещё один шаг и объединить оба подхода и исследовать на что способен общий случай.
Исправлено.
Тогда вот, хвастаюсь своими достижениями :)
P.S.
В моём первом комментарии опечатка: "коммент" ↦ "коммит"
Поддерживаю, стараюсь всегда использовать атомарные коммиты. То есть включать в один коммит только изменения на одну единственную тему (например связанную с одной фичой), которые в будущем если что могут быть отменены целиком в связи с откатом этой фичи.
Но каюсь, иногда бывает соблазн объединить парочку изменений, и всё-таки бывает, соединяю в один коммент, что нельзя было объединять.
А ещё это помогает в геймификации процесс программирования. К примеру я играю сам с собой в игру, мол, чем больше у меня зелёных квадратиков на GitHub и чем они зеленее, тем лучше. Лучшая стратегия победы в такой игре это делать каждый день минимум один коммит, и тогда ты точно побеждаешь, но вот реальность показывает что это делать не просто. И развивать самодисциплину - то ещё испытание. Но чем меньше коммиты тем проще это делать, тем проще себя мотивировать и проще получать удовольствие от того что коммиты сделаны :) А после этого хочется делать ещё коммитов и ещё :)
А ещё это помогает следовать принципу атомарной ответственности в задачах, если привязывать каждый коммит к конкретной задаче (issue), никогда нельзя будет сделать так, чтобы в нём содержался код связанный с несколькими задачами, это тоже дополнительно дисциплинирует и делает процесс разработки максимально прозрачным. То есть можно будет потом сделать roadmap/project, из которого можно перейти на конкретные issues, а оттуда на конкретные коммиты которые делались в рамках этой задачи.
VK тоже позволяет выгрузить свои данные.
Я бы попробовал, я не думаю что стоит использовать решение которое хранит всё только локально, можно шифровать и выкладывать в облака других сервисов. Это всё ещё звучит просто.
Теория графов по определению не позволяет ребрам ссылаться на рёбра. Поэтому у нас не графовая СУБД, а ассоциативная. Ассоциативная теория сейчас в разработке: первый черновик (апрель 2022-го), последний черновик (на декабрь 2023-го). Если коротко, общий случай: L ↦ L² (связи-дуплеты), частный случай L ↦ L³ (связи-триплеты).
В ассоциативной СУБД всегда можно добавить любое количество необходимых "легковесных" рёбер между связями/ассоциациями, просто создав связь/ассоциацию между ними. Да, требуется использовать join, однако у нас есть реализация materialized path индексации, которая позволяет снизить нагрузку на joins в SQL. И в целом mp это не единственный способ дополнительной индексации, которую можно наложить поверх связей. Что касается самих join, то наш следующий собственный движок СУБД разработанный с нуля на Rust делает их в 1000+ раз быстрее чем PostgreSQL, за счёт того, что из движка убрано всё лишнее (бенчмарк). И хотя сами легковесные рёбра уже способ оптимизации поиска или индексации, их можно заменить на битовые строки, которые позволят делать очень эффективное пересечение или объединение данных. С этим способом индексации мы тоже будем экспериментировать в новом движке.
И уже когда мы перейдём на этот движок, то все значения привязанные к связям, числа, строки, json и т.п. будут разложены на Дуплеты. И благодаря такому подходу сразу включится дедупликация последовательностей внутри значений, так и между значениями.
Совсем не обязательно чтобы сервер было в облаке, можно сервер хостить на своём компе и даже сделать его доступным в интернете для своих устройств.
Именно поэтому нужно использовать системы, которые возвращают контроль над своими данными пользователю, и позволяют как минимум делать резервную копию, а как максимум позволяют постоянно отслеживать в каких социальных сетях и мессенджерах какие данные пользователя находятся. Эти данные можно использовать повторно, например разбирать переписку на список вопросов и ответов.
Что касается облачного хранилища особо важных файлов их вообще нужно постоянно синхронизировать между системами (например iCloud, Dropbox, Google Drive и т.п.), что фактически и будет создавать дополнительную активность.
Так же даже пусть если ты активен, это всё равно не значит что ты не потеряешь свои данные. Например, VK хранит всего 15 млн сообщений пользователя после этого он теряет к ним доступ, а новые сообщения затирают самые древние.
И так с заголовка: Deep.Foundation - переводится как Глубокий Фундамент.
Буквально это оно и значит - глубокий фундамент для любого ПО, а так же в будущем и для всех наук (математика, информатика, физика, философия и т.п.).
Мы фонд развития ассоциативных технологий. Почему ассоциативных? Потому что основанных в отличие от нулей и единиц (битов) на связях. На это можно посмотреть как на ассоциативную машины тьюринга, где вместо нулей и единиц на ленте в каждой ячейке находится целая связь. И алфавит таких связей неограничен. Связь это минимальная единица смысла. Из неё можно собирать объекты, она может хранить строгие последовательности в отличие от графов использует всего одну связь для последовательности в 2 элемента, 2 связи для последовательности в два элемента и т.п. Сами элементы не считаются тут, но они тоже связи.
С точки зрения математики мы это воплощение всех функций соответствующих шаблону L ↦ L². Иными словами в сердце Deep, и сам Deep это просто последовательность связей, то есть массив связей. Но так как последовательность может быть упакована в одну связь, то любой экземпляр Deep может быть представлен одним числом, именно поэтому мы можем реализовать Deep поверх любой машины тьюринга. Мы показали на практике, что не существует ни одной структуры данных, которую нельзя представить связями. То есть что угодно - множества, последовательности, деревья, графы, гиперграфы, объекты и даже функции представимы связями. Мы сейчас работаем над тем чтобы это ещё и доказать автоматизировано используя теорию типов и теорию множеств, вот следующий ещё не опубликованный черновик, если интересно.
Всё это упаковано в ассоциативную архитектуру приложений. Что это такое? Это готовый бэкенд и API, в который достаточно залить свои данные и сделать нужный тебе UI и готово приложение под все платформы: Web, Linux, Windows, macOS и скоро Android, iOS, а ещё позже самостоятельная OS с той же архитектурой, полностью настраиваемая и кастомизируемая пользователем.
Зачем подключать? Мы вавилонская башня в контексте программирования, это значит что используя нашу технологию мы можем сочетать мощь всех человеческих ресурсов в программировании. Код для этой системы можно писать на всех языках программирования, плюс она по совместительству уже и IDE.
Иными словами совсем просто - Deep это универсальный инструмент автоматизации, в том числе и для автоматизации самой автоматизации. Мы позволяем делать ПО быстрее чем когда бы то ни было. Вместо того чтобы ограничивать разработчика одним встроенным в систему языком, мы дали возможность подключать все языки вместе с их пакетными менеджерами, это значит ни одна строчка когда, которую вы где-либо когда-либо написали не пропадёт зря, можно использовать всё и сразу в одном месте.
Зачем это надо? Для ускорения реализации любой мечты. Для нас сам Deep стал мечтой, потому что мы хотели запускать сотни стартапов. Но поняли что нам не хватит ресурсов на всё, поэтому эти идеи стартапов у меня лично опубликованы, другие ребята из команды будут получать под остальные идеи инвестиции.
Я объясняю эту суть вам, а не бабушке, ребёнку или петомцу. Но вы уж, пожалуйста, скажите, какое первое слово в том о чём я говорю не понятно именно вам? Давайте я расскажу что это такое.
Да мы не успели довести до совершенства каждую деталь, и именно поэтому нам нужна помощь и мы ищем тех, кому понравилась идея которую мы разрабатываем. Хотите помочь - присоединитесь к нам. Не хотите - покажите где мы ошибаемся, и как сильно мы тут ошибаемся, мы примем это к сведению и будем ошибаться меньше.
Благодарю за понимание.
P.S.
Если от такого ответа вопросов стало только больше, это нормально, у нас так уже многие годы напролёт. Поэтому мы и предлагаем зайти в наш Discord, посмотреть все демки и обсудить что конкретно не понятно именно вам. На все вопросы будут ответы.
Мы существуем, написал в личку, жду созвона.
На тему ребят которые готовы делать что-то «за интерес», да, у нас есть и такие ребята. Действительно помимо того, что у нас быстрее и проще выйти новичкам на доход, для новичков это формирование портфолио и фундамента, на который они могут опереться. Ведь открый исходный код, а тем более если он в общественном достоянии, можно не только показать на следующем интервью у работодателя, этот код можно повторно использовать при необходимости. Ну и конечно же это сразу вклад в обучение будущих нейросетей таких, как GPT. И в этом смысле я не сторонник того, чтобы скрывать свой код от того чтобы его могли использовать для обучения, а наоборот внести вклад в то, чтобы эти нейросети получали для обучения код наивысшего качества. И это в наших общих силах.