После провала в ИТ - Я наблюдал за происходящим. Потом перестал наблюдать. В итоге понял, что наблюдение за происходящим не является оплачиваемой услугой.
А потом решил немного изменить собственную жизнь.
Вместо разработки программ я собираюсь заняться механизированной уборкой участков. Буду помогать людям справляться с высокой травой, зарослями и другими последствиями многолетнего запустения.
В общем, решил попробовать работу, результат которой видно сразу.
Как государство помогает начать своё дело
Для открытия небольшого бизнеса существует социальный контракт. Можно подготовить бизнес-план, объяснить, чем собираешься заниматься, и запросить средства на необходимое оборудование.
Я решил воспользоваться этой возможностью.
Конечно, деньги сами по себе не гарантируют успеха. Заказчиков ещё нужно найти, расходы — посчитать, а работу — выполнить. Но это шанс попробовать создать небольшое дело, не начиная с нуля на собственные средства.
Cоциальный контракт
Зачем столько оборудования?
Одной машиной трудно справиться со всеми задачами. Поэтому я подбираю комплект техники для разных видов работ.
Главная задача — расчищать заросшие участки. Дополнительные инструменты помогут работать в узких местах, убирать растительные остатки и предлагать другие услуги в зависимости от сезона.
Летом можно заниматься травой и кустарником, зимой — уборкой снега.
При выборе техники важно не только то, как хорошо она работает сегодня, но и то, пригодится ли она в дальнейшем. Покупать дорогие инструменты ради одного сезона было бы странно.
Инструменты от государства
А где брать заказчиков?
Вот здесь начинается обычный бизнес.
Нужно рассказывать людям об услугах, размещать рекламу, договариваться о работе и учитывать расходы. Сезонность тоже имеет значение: летом больше работы с растительностью, зимой — со снегом.
Пока это план, который предстоит проверить на практике. Сначала найти клиентов, затем выполнить заказы и посмотреть, сколько денег остаётся после расходов.
Никакой гарантированной прибыли здесь нет. Зато есть понятная задача: сделать участок чище и получить за это оплату.
Хороший план?
И что теперь с ИТ?
Я не разлюбил компьютеры и не собираюсь забывать программирование. Просто решил попробовать себя в другой сфере.
Раньше я создавал программы, которые должны были облегчать людям работу. Теперь попробую облегчать её с помощью садовых инструментов.
В конце концов, иногда проще не ждать, когда появятся подходящие условия, а самостоятельно найти дело, которое можно начать.
Не потому, что её невозможно создать. А потому, что между разговорами о технологическом суверенитете и реальными потребностями пользователей зияет огромная дыра.
Я работаю в муниципальной сфере и вижу, как люди используют устаревший, нелицензионный и плохо поддерживаемый софт. Не от хорошей жизни: нужно печатать документы, вести таблицы и выполнять работу. А подходящего доступного ПО часто просто нет.
Тем временем ИТ-отрасль обсуждает цифровизацию, отечественные платформы и искусственный интеллект. На разработку выделяют гранты, крупные проекты получают финансирование. Но что происходит с небольшим разработчиком, который самостоятельно создал полезный продукт?
не нужна
Импортозамещение ради работы или ради отчётности?
Отечественное ПО необходимо там, где важны безопасность, поддержка и независимость от иностранных поставщиков. Но сама установка российского продукта ещё не означает, что работа стала удобнее.
Можно внедрить новую платформу и продолжить вести реальные процессы в старых программах и таблицах. Формальные показатели выполнены, а повседневные проблемы остались.
Это не значит, что все крупные ИТ-проекты бесполезны. Но освоенный бюджет и количество внедрений не равны реальной пользе для пользователя.
Государственные программы поддержки существуют. Однако грант — не универсальный способ профинансировать любую полезную разработку. Есть требования, процедуры и ограничения. Закупки требуют готовности к внедрению, а независимому разработчику зачастую негде взять ресурсы даже на поиск первых пользователей.
Получается замкнутый круг: чтобы доказать востребованность, нужны внедрения; чтобы провести внедрения, нужны деньги и доступ к заказчикам.
всё работает!
Что я называю разработкой русской ОС
Я не пишу собственное ядро Linux и не собираюсь заменять Windows на уровне драйверов. Я создаю открытую среду для разработки персональных ERP-систем — генеративный фреймворк, позволяющий собирать прикладные инструменты под реальные задачи.
В основе — PHP, JavaScript, MySQL/MariaDB и обычный хостинг. Система позволяет создавать совместимые модули и использовать нейросети для генерации кода по техническим контрактам.
Нужен складской учёт — создаём модуль. Нужны заявки, имущество или учёт участников — добавляем соответствующую функциональность. Не требуется покупать огромную корпоративную платформу, чтобы автоматизировать небольшой рабочий процесс.
Я называю это разработкой русской ОС не в буквальном смысле операционной системы, а как создание собственной открытой рабочей среды — инструментов, которые можно изучать, менять и развивать без привязки к единственному поставщику.
модули
Если софт нужен, почему он никому не нужен?
Предположим, независимый разработчик создал работающий продукт. Есть код, архитектура и реальные сценарии применения.
Кто поможет провести испытания? Кто оплатит внедрение? Кто познакомит разработчика с первыми пользователями?
Если таких механизмов нет, технически успешная разработка может оказаться экономически невостребованной. А затем её невостребованность легко «доказать»: никто не купил — значит, никому не нужно.
Но отсутствие покупок не доказывает отсутствие потребности. Возможно, продукт просто не получил доступа к пользователям и ресурсам, необходимым для внедрения.
В теории отечественный софт нужен всем. На практике его ненужность легко доказать, если не создать условий, в которых он может стать востребованным.
не нужен
Вместо заключения
России нужны собственные операционные системы там, где они действительно необходимы. Нужны прикладные программы, открытые инструменты и независимые разработчики.
Но недостаточно объявить разработку стратегически важной и выделить деньги на отдельные проекты. Нужен понятный путь от работающего прототипа до реального пользователя: испытания, внедрение, обратная связь и дальнейшее развитие.
Мой проект — один из примеров того, что независимый разработчик способен создать собственный технологический продукт. Но его дальнейшая судьба зависит не только от качества кода.
Возможно, нам не столько не хватает русской операционной системы, сколько работающей системы поддержки тех, кто уже создаёт отечественный софт.
Технологическая независимость начинается не с названия продукта и не с галочки в отчёте. Она начинается тогда, когда созданный инструмент может найти пользователя, решить его задачу и продолжить развиваться.
Началось всё с попытки хранить персонажей, места и события вымышленного мира. А пришло к вопросу: можно ли описать не только сам мир, но и разные способы понимать происходящее в нём?
Для начала — эксперимент на этой статье
Вы читаете этот текст. Что вы в нём видите?
Возможно, пытаетесь понять идею. Тогда будете спрашивать: «Что автор называет реальностью? Как это может работать?»
Возможно, оцениваете статью как публикацию. Тогда раньше самой идеи заметите заголовок, длину абзацев и качество иллюстраций.
А возможно, первая же ошибка в пунктуации испортит вам впечатление. И это не означает, что ошибка не существует или что на неё нельзя указывать. Просто в этот момент главным предметом оценки стало качество текста, а не предложенная мысль.
Статья одна. Люди могут прочитать одни и те же слова. Но вынести из встречи с ними совершенно разное.
Вот это я и называю разными точками зрения.
Не местом, откуда смотрят. Не устройством глаз. А способом выбирать важное, понимать увиденное и оценивать его.
эксперимент на этой статье
А при чём здесь реальность?
Я предлагаю такую рабочую формулировку:
Реальность — это неопределённость в границах, заданных правилами.
Звучит сложно. Возьмём простую ситуацию: в архиве пропала карта.
Что произошло на самом деле? Мы пока не знаем. Её украли, переложили, взяли для работы или никогда не клали туда, где её теперь ищут.
Это неопределённость. Но она не бесконечна: у нас есть время, место, участники, двери, записи о выдаче и другие условия. Они задают границы того, какие версии вообще возможны.
Теперь добавим точки зрения.
Хранитель архива видит нарушение порядка: предмета нет на положенном месте. Следователь видит вопрос о том, кто и когда получил к нему доступ. Автор приключенческой истории видит начало загадки. Человек, которому карта нужна прямо сейчас, видит сорванные планы.
Важно: это не четыре разные карты и не четыре разные физические вселенные. Это разные способы выделить значимое в одной ситуации. Из-за этого люди зададут разные вопросы, проверят разные версии и совершат разные действия.
при чём здесь реальность?
Можно ли записать точку зрения как правило?
Представим, что мы создаём маленький мир для истории или игры. В нём есть персонажи, архив и пропавшая карта. Обычно программа умеет хранить факты: «карта принадлежит Эшу», «архив закрыт», «событие произошло вечером».
Но для меня интереснее следующий шаг. Описать не только факты, но и правила, по которым ситуация приобретает значение.
Например:
Для хранителя существенно, лежит ли предмет на своём месте.
Для следователя существенно, кто имел доступ.
Для Эша существенно, можно ли продолжить путь без карты.
Для читателя существенно, какие сведения ему уже сообщили, а какие пока скрыли.
Такая точка зрения — не готовое мнение вроде «хранитель обязательно обвинит Эша». Это способ разбирать ситуацию: на что обратить внимание, какие вопросы задать, по каким признакам сделать вывод.
И способ этот не намертво приклеен к человеку. Тот же хранитель может сначала оценивать пропажу как нарушение учёта, а потом — как угрозу другу. Точка зрения может измениться, когда меняется его задача.
Зачем здесь метамоделирование
В обычной программе разработчик заранее придумывает все виды записей и все способы их обработки. Вам достаются готовые поля: «имя», «дата», «место».
В моём проекте основа намеренно простая: объекты и их свойства. Персонаж — объект. Карта — объект. Событие — объект. Описание того, как показывать данные, — тоже объект.
Идея метамоделирования — дать возможность описывать сами правила описания внутри системы. Сегодня для мира важны вещи и их владельцы. Завтра — обещания, подозрения, оценки или способы понимать происходящее. Не хочется каждый раз начинать с переписывания всей программы.
Конечная цель — интерфейс, в котором можно задать правила ситуации и спросить:
Что здесь возможно, что исключено, что неизвестно — и как меняется набор значимых возможностей при выбранной точке зрения?
«Точка» здесь — не обязательно место на карте. Это может быть конкретное состояние истории: какие факты известны, какие условия действуют и какой способ понимать ситуацию мы сейчас применяем.
Зачем здесь метамоделирование
Что уже есть, а что пока задумано
Сейчас система уже позволяет хранить мир как связанные объекты и свойства. Можно создавать разные представления одних и тех же данных: например, список персонажей или хронологию событий. ИИ может помогать превращать мои обрывочные рассказы в набор таких записей.
Но расчёт пределов ситуации и работа с концептуальными точками зрения пока остаются целью проекта. Я не хочу выдавать таблицу персонажей за готовый двигатель реальности.
Чтобы к этому прийти, системе понадобится различать как минимум три ответа: «возможно», «исключено правилами» и «пока недостаточно данных». А также помнить, что оценка ситуации с какой-то точки зрения не равна факту о самой ситуации.
Это важно и при работе с ИИ. Если я написал «хранитель счёл исчезновение карты кражей», ИИ не должен записывать «карту украли». Он должен сохранить разницу между событием, оценкой хранителя и тем, что на самом деле ещё неизвестно.
Так что такое реальность?
Я не претендую на окончательный ответ философам и физикам. Мне интересна практическая версия вопроса: как построить модель, в которой не нужно заранее знать всю историю, но можно понимать границы возможного?
И как добавить к ней ещё один слой: способы, которыми участники этой истории выделяют смысл в происходящем.
Для одного читателя эта статья — попытка объяснить проект. Для другого — повод поспорить с определением реальности. Для третьего — слишком длинный текст с неудачной картинкой.
Статья от этого не переписывается сама собой. Но то, что станет событием при встрече с ней, зависит в том числе от точки зрения читателя.
С этого, кажется, и начинается интересная часть конструктора.
Итак, продолжая тему любительской разработки русских операционных систем, расскажу об одном варианте использования. Но сегодня не будет инструкции, какие кнопки нажимать. Хочу поговорить об идее: что, если выдуманный мир можно не только описать, но и собрать из его собственных правил?
Вы придумали героя. Он живёт в городе. Город построен вокруг старого маяка. Однажды маяк замолчал, и герой отправился искать причину.
Пока это просто история. Но стоит задать несколько вопросов — и за ней проступает целый мир:
Какие ещё города существуют?
Кто обслуживает маяки?
Все ли маяки могут замолчать?
Что меняется для людей, когда это происходит?
Мир появляется не тогда, когда написано много страниц. Он появляется тогда, когда вещи в истории начинают быть связаны друг с другом.
как создать мир?
Список покупок, который внезапно стал вселенной
Начнём с чего-нибудь попроще. Допустим, у вас есть список покупок:
Хлеб — две штуки. Молоко — один пакет.
Обычное приложение считает, что этого достаточно: у товара есть название и количество.
Но вам понадобился срок годности. Потом — любимый магазин. Потом — пометка «этот сыр больше никогда не покупать». А потом выяснилось, что корм для кота, лекарство и подарок другу вообще неудобно описывать одинаково.
Проблема не в списке. Проблема в том, что кто-то заранее решил, какие свойства бывают у вещей, а ваша жизнь с этим решением не согласилась.
Теперь представьте обратный подход. Не программа навсегда определяет, что такое «товар», а вы по мере необходимости описываете, какие вещи встречаются в вашем мире и что вам о них важно знать.
Для хлеба важен срок годности. Для подарка — кому он предназначен. Для лекарства — дозировка. Для странного камня из фантастического рассказа — почему он светится рядом с маяком.
Вот здесь и начинается метамоделирование.
Моделирование — это когда мы описываем вещи.
Метамоделирование — когда мы можем описывать ещё и способы описания вещей.
Звучит как круг из учебника философии. На практике это вопрос: «А что, если завтра в моём мире появится нечто, для чего я ещё не придумал полей?»
Список покупок, который внезапно стал вселенной
История не обязана помещаться в анкету
Представим, что я рассказываю про Эша — летучую мышь, которая исследует старый архив.
Сначала я знаю о нём немного: имя, занятие, место жительства. Потом вспоминаю, что Эш боится темноты. Да, летучая мышь, которая боится темноты. Мне нравится это противоречие.
Ещё позже появляется запах мокрой бумаги в архиве, пропавшая карта и разговор с Линой, после которого Эш перестаёт кому-либо доверять.
Если я заведу на героя жёсткую анкету, мне придётся заранее решить, где у неё графа «запах, с которым связано худшее воспоминание». Скорее всего, такой графы не будет.
А в живом мире новые свойства появляются вслед за мыслью автора, а не по расписанию разработчика приложения.
При этом мир — не просто мешок подробностей. Эш связан с архивом. Карта связана с исчезновением. Исчезновение связано с разговором. И, возможно, разговор изменил героя.
Можно описать каждого по отдельности. Но интересное происходит между ними.
История не обязана помещаться в анкету
Мир можно рассматривать с разных сторон
Представьте комнату, полную людей. Один человек составляет список гостей. Другой выясняет, кто с кем знаком. Третий пытается восстановить, кто первым заметил дым из кухни.
Комната одна. Люди одни. Но ответы на вопросы получаются разными.
С вымышленным миром так же.
Можно посмотреть на него как на список персонажей. Можно — как на последовательность событий. Можно — как на карту мест. А можно спросить: какие предметы переходили из рук в руки и меняли ход истории?
Это не четыре разных мира. Это четыре взгляда на один.
И здесь важная часть идеи: способ смотреть на мир тоже можно считать частью его описания. Не только «существует Эш» и «существует карта», но и «покажи мне все события, связанные с картой, в порядке их появления».
Не обязательно каждый раз изобретать новую программу, чтобы задать новый вопрос к своей истории.
Мир можно рассматривать с разных сторон
А если история рождается вслух?
Люди редко придумывают миры аккуратными таблицами.
Обычно это выглядит так:
«Там был архив… или бывшая станция? Эш пришёл туда после ссоры с Линой. Хотя, кажется, ссора случилась позже. И ещё там всё время пахло дождём».
Это не плохой материал. Это нормальный процесс придумывания.
ИИ может помочь заметить в таком разговоре персонажей, места, события и возможные связи. Но ему нельзя поручать последнее слово. Он слишком охотно превращает неуверенное «кажется» в уверенное «так и было».
Хороший помощник должен уметь сказать: «Вот что ты точно рассказал. Вот что я лишь предположил. А вот здесь ты сам пока выбираешь между двумя версиями».
Именно поэтому живой мир нельзя просто «сгенерировать» и забыть. Автор остаётся автором — даже когда ему помогает машина.
Если вам знакомы проекты вроде LLM Wiki, сходство здесь в желании сделать разрозненные рассказы обозримыми. Разница в интересующем нас вопросе: не только «какую статью написать об этом мире?», но и «из каких вещей он состоит и как они связаны?». Статьи и такая карта мира могут прекрасно существовать рядом.
А если история рождается вслух?
Так как всё-таки создать мир?
Не начинать с энциклопедии на тысячу страниц.
Начать с чего-то маленького. С героя, который боится темноты. С маяка, который однажды перестал работать. С карты, которую кто-то потерял — или спрятал.
Потом спросить, что это за вещи, какие у них свойства и что между ними произошло.
А когда окажется, что прежних способов описания уже не хватает, придумать новые. Не подгонять историю под готовые клеточки, а позволить клеточкам расти вслед за историей.
В этом для меня и состоит идея метамодели мира. Не в том, чтобы загнать воображение в базу данных. Наоборот: дать ему достаточно гибкую опору, чтобы вчерашняя случайная мысль завтра могла стать частью большой, связной вселенной.
Есть очень удобный способ продавать публике почти любую научную фантазию...
загрузили...
Берём настоящий научный объект. Добавляем сложные слова. Показываем красивую демонстрацию. А потом делаем вывод, который из демонстрации вообще не следует.
И если всё это делают люди с научными степенями, публика почему-то перестаёт задавать главный вопрос: «А где доказательства?»
Сейчас отличный пример — история о том, что учёные «загрузили мозг плодовой мушки».
Звучит как фантастика. Но давайте на секунду уберём авторитет учёных и посмотрим, что означает сама фраза.
Что значит «загрузить мозг»?
Если мы действительно загрузили мозг, у нас должна получиться работающая модель конкретной нервной системы, способная взаимодействовать с телом примерно тем же способом, каким исходная нервная система взаимодействует с живым организмом.
А для этого недостаточно знать, какие нейроны с какими соединены.
Нужно знать, как информация входит в нервную систему и как из неё выходит. Какие сигналы приходят от глаз, усиков, мышц и внутренних органов. Как нервная система связана с периферией. Как её активность превращается в движение мышц. Как движение тела меняет ощущения. Как состояние самого тела снова меняет работу нервной системы.
То есть нужен замкнутый контур:
тело → нервная система → тело → нервная система.
Без этого у нас нет организма. У нас есть модель некоторой части его нервной системы.
А что тогда показали?
что загрузили?
Получили карту связей нейронов — connectome. На её основе построили математическую модель нейронов, подключили её к виртуальному телу и сделали интерфейсы между мозгом и этим телом.
Причём сама Eon описывает систему именно так: используются существующие модели мозга и тела, некоторые связи между активностью мозга и движениями выбраны вручную, а ходьба опирается на уже существующие контроллеры, обученные имитировать ходьбу мухи. Компания прямо называет нынешнюю систему исследовательской и демонстрационной платформой и пишет, что она пока не доказывает, будто одной структуры мозга достаточно для восстановления всего поведения мухи.
То есть перед нами не «муха, которую достали из мозга и запустили».
Перед нами сложная искусственная система, в которой данные о мозге мухи являются одной из частей.
И это принципиальная разница.
муху?
Самый простой тест
Представьте, что завтра мы возьмём другую нейросеть.
Оставим то же виртуальное тело. Те же органы чувств. Те же интерфейсы. Те же контроллеры. Подберём параметры — и получим муху, которая тоже ходит, ест и чистит лапки.
Что доказывает её поведение?
Что эта конкретная нейросеть является мозгом мухи?
Нет.
Оно доказывает только то, что данная совокупность моделей и интерфейсов способна воспроизводить определённое поведение.
Чтобы доказать больше, нужно проверять, насколько внутренние процессы модели соответствуют процессам настоящего мозга: не только результат движения, но и работу нервной системы, реакции на новые ситуации, последствия вмешательств и так далее.
Именно необходимость такой проверки Eon сама сейчас признаёт.
И вот здесь начинается самое интересное
Научная часть этой работы может быть совершенно настоящей и интересной.
Но из этого совершенно не следует рекламный заголовок «мы загрузили муху».
Это классический научно-популярный фокус:
реальный результат → громкая интерпретация → публика запоминает интерпретацию.
А затем сама громкая интерпретация начинает восприниматься как установленный научный факт.
Причём авторитет «учёные сделали» фактически подменяет объяснение того, почему мы должны считать заявленный вывод доказанным.
Именно поэтому научные заявления нужно оценивать не по количеству докторских степеней у авторов и не по красоте видео.
А по гораздо более скучному вопросу:
что именно было измерено, что именно было построено и какой именно вывод из этого следует?
зачем?
В случае с «загрузкой мухи» ответ пока гораздо скромнее, чем обещает заголовок:
создана виртуальная система, использующая модель нервной системы мухи.
Это уже само по себе можно исследовать.
Но «мы загрузили мозг» — это не результат измерения. Это название, которое результату дали.
И вот эту разницу почему-то очень любят забывать именно тогда, когда на ней можно хорошо хайпануть.
Сразу ответим на самый вероятный первый комментарий:
«Это нейросетевое говно».
Возможно. Но давайте сначала разберёмся, что именно перед нами, зачем оно сделано и почему вообще работает.
Это не очередной «убийца 1С». Не огромная корпоративная платформа. Не конструктор сайтов с тысячей кнопок. И не архив со случайными файлами, которые нейросеть сгенерировала за один вечер.
Это небольшой standalone-фреймворк для создания персональных ERP-систем.
Проще говоря: у вас есть сайт, база данных и какая-то реальная работа. Например, нужно учитывать людей, вещи, заявки, питание, пропуска, машины или деньги. Вы кладёте в корень сайта папку `erp`, добавляете файл `erp.php`, указываете доступ к базе — и получаете отдельную админку.
А потом описываете нужный рабочий процесс обычными словами и создаёте для него модуль.
Кодт в лесу
Что такое персональная ERP
ERP принято представлять как страшную дорогую систему для завода, банка или торговой сети.
В действительности ERP — это просто программа, которая помогает управлять работой:
кто приехал;
кому что выдали;
сколько осталось на складе;
кто поел;
кто оплатил;
какая заявка выполнена;
кто отвечает за задачу;
что произошло сегодня.
Большинство маленьких организаций решает эти вопросы с помощью таблиц, бумажек, сообщений в Telegram и памяти одного уставшего человека.
Персональная ERP не пытается заранее знать, как устроена ваша жизнь. Она собирается под конкретную задачу.
Нужно учитывать склад — подключаем модуль склада. Нужно сканировать QR-коды на кухне — подключаем сканер. Нужен редактор участников — добавляем редактор. Не нужно — не устанавливаем.
Почему standalone
Современная разработка иногда выглядит странно. Чтобы показать таблицу из базы, предлагают установить Node.js, Docker, Redis, десятки тысяч npm-пакетов и небольшой Kubernetes.
Наш подход проще:
PHP;
нативный JavaScript;
CSS;
MySQL или MariaDB;
обычный недорогой хостинг.
Система не требует отдельного сервера приложений, сложной сборки или постоянного фонового процесса.
Главный сайт может быть каким угодно: старым, новым, самописным или собранным на CMS. ERP живёт отдельно и обращается к нужной базе данных.
Это не плагин для конкретной платформы. Это переносимая административная среда.
Почему «генеративный фреймворк»
Обычно фреймворк даёт программисту классы, функции и документацию.
Генеративный фреймворк дополнительно даёт контракт для нейросети.
В нём написано:
куда положить файлы;
как устроен API;
как проверяются права;
как делать запросы;
как оформлять интерфейс;
как работать без связи;
как не создавать дубликаты;
как очищать таймеры и обработчики;
как безопасно загружать файлы;
как писать SQL;
какие технологии запрещены.
После этого новый модуль можно описать человеческим языком:
Создай модуль склада. В нём есть предметы, остатки, выдача и возврат. Предметы выдаются участникам из таблицы chains. Администратор редактирует склад. Обычный пользователь оформляет выдачу. Интернет может пропадать. Операции нельзя терять и нельзя записывать дважды. Интерфейс предназначен в первую очередь для смартфона.
Модель получает это описание вместе с контрактом и создаёт совместимые файлы:
При необходимости она также создаёт SQL-миграцию и фрагмент конфигурации.
Это не означает, что нейросеть теперь волшебным образом стала программистом, бухгалтером и директором склада. Она остаётся инструментом. Результат нужно проверять на реальных данных и реальных сценариях.
Но большая часть скучной технической работы уже формализована.
Живая Машина
Почему проект русский
Не потому, что PHP изобрели в Рязани. И не потому, что в коде должны быть берёзы.
Проект русский по своей практической среде:
обычный shared-хостинг;
старый сайт, который нельзя переписать целиком;
ограниченный бюджет;
нестабильный мобильный интернет;
работа со смартфона;
необходимость запустить всё быстро;
реальные люди, которые не хотят читать инструкцию на сто страниц;
интерфейс, который должен работать в поле, в палатке, на складе или в лесу.
Это не попытка повторить дорогое западное корпоративное решение в уменьшенном виде. Это попытка сделать полезный инструмент из того, что доступно почти везде.
Русский здесь — это не про изоляцию. Это про язык, условия и инженерный подход: меньше церемоний, больше работающего результата.
Почему open source
Потому что систему нельзя честно называть персональной, если её хозяин не может посмотреть код, изменить его и забрать свои данные.
Открытый проект должен позволять:
установить систему на своём сервере;
подключить собственную базу;
написать свои модули;
изменить существующие;
не платить за каждого пользователя;
не зависеть от исчезновения чужого облачного сервиса;
хранить данные там, где решил владелец.
Работа там, где интернет работает плохо
Один из главных сценариев проекта появился не в красивом офисе, а в лесу.
Там связь может быть такой:
интернет появился;
человек нажал кнопку;
интернет исчез;
запрос вроде бы ушёл;
ответ не пришёл;
человек нажал ещё три раза.
Если обычная система не готова к этому, она теряет операцию или создаёт четыре одинаковых записи.
Поэтому важные полевые модули используют локальную очередь. Каждая операция получает уникальный идентификатор. Если запрос отправится повторно, сервер узнает его и не создаст дубль.
Так работают:
QR-сканирования;
сообщения;
выдача имущества;
отметки присутствия;
другие операции, которые нельзя просто забыть.
Интерфейс может сразу дать человеку визуальный и звуковой ответ. Когда связь восстановится, очередь синхронизируется с сервером.
Но сервер всё равно остаётся последним источником истины. Именно он окончательно проверяет права, остатки и лимиты.
Что уже умеет система
Базовая редакция включает несколько живых модулей.
Люди - Таблица участников, слои, поиск, статусы и быстрое редактирование.
Редактор участника - Контакты, даты, питание, фотография, комментарии и назначение QR-ключа.
Сканер - Работа с камерой смартфона, локальная очередь событий, допуски, лимиты и последующая синхронизация.
Пользователи - Управление учётными записями, ролями, доступными модулями и типами сканеров.
Чат и ИИ - Общий и приватные чаты, файлы, изображения, автономная очередь сообщений и серверные вызовы языковых моделей.
а так-же, канбан, блог, ежедневник, интергации с внешними АПИ и парсерами... и всё что придёт вам в голову.
Новый функционал не вшивается в одно огромное ядро. Он добавляется отдельными модулями.
ERP для организации лесных мероприятей
А нейросеть здесь всё-таки пишет код?
Да.
Как когда-то код стали писать с автодополнением, библиотеками, Stack Overflow и поисковиками.
Разница в том, что языковая модель может получить не один вопрос, а целый технический договор. Если договор хороший, результат становится заметно предсказуемее.
Плохой подход:
«Нейросеть, сделай мне ERP».
Хороший подход:
«Вот архитектура, ограничения хостинга, API-контракт, правила безопасности, схема данных, жизненный цикл модуля и требования к плохой связи. Теперь реализуй конкретный модуль».
Нейросеть не заменяет архитектуру. Наоборот: без архитектуры она особенно быстро производит кашу.
Генеративный фреймворк — это не фреймворк, который сам мечтает и программирует по ночам. Это система, подготовленная к тому, чтобы человек мог использовать генерацию кода контролируемо.
Это уже готовая корпоративная платформа?
Нет.
Проекту ещё нужны:
автоматические тесты;
установщик и миграции;
нормальная документация;
аудит безопасности;
стабильная система обновлений;
демонстрационная сборка;
больше универсальных модулей;
проверка на разных версиях PHP и MariaDB.
финансирование и покровительство
Но он уже решает реальные задачи. А это важнее красивой презентации, в которой пока не работает ни одна кнопка.
Главное
Идея проекта очень простая:
Не человек должен полностью перестраивать свою работу под огромную ERP. Небольшая ERP должна собираться вокруг реальной работы человека.
Для этого необязательно начинать многолетнюю разработку и покупать серверную стойку.
Иногда достаточно:
папки `erp`;
одного роутера;
доступа к базе;
нескольких модулей;
хорошо составленного контракта;
внимательной проверки результата.
Да, часть кода (и эта статья) создана при помощи нейросетей.
Но лопату тоже сделал не тот человек, который сейчас копает ею яму. Вопрос не в том, каким инструментом пользовались. Вопрос в том, понимает ли автор, что он строит, может ли это проверить и помогает ли результат людям.
Если помогает — значит, это уже не «нейросетевое говно».
Это инструмент.
А хороший инструмент можно открыть, разобрать, починить и приспособить под себя.
На кухне осталась посуда. Ребёнку через сорок минут в школу. Один взрослый не выспался, второй уже опаздывает на работу. Еда в холодильнике есть, но завтрак никто не приготовил.
И тут персонаж решает не мыть тарелки.
Не потому, что сломался ИИ. Не потому, что игрок забыл поставить команду в очередь. А потому, что он устал, вчера уже убирался, считает распределение обязанностей несправедливым и обещал ребёнку помочь с уроками.
Я попробовал сделать игру, в которой подобное поведение — не ошибка, а основа симуляции.
Рабочее название проекта — «Домашний уклад».
Не кукольный дом, а живая система
Обычно в симуляторе жизни игрок выбирает персонажа и говорит ему:
Проснуться → сходить в туалет → приготовить завтрак → поесть → помыть посуду → пойти на работу
То есть персонаж остаётся куклой, а игрок становится его внешней волей.
Мне хотелось сделать наоборот.
Члены семьи должны сами:
замечать собственные потребности;
оценивать обстановку;
помнить об обязанностях;
учитывать отношения;
выбирать доступное действие;
жить с последствиями своего выбора.
Игрок не управляет человеком напрямую. Он управляет условиями его жизни.
Можно купить посудомоечную машину, изменить распорядок, перераспределить обязанности, выделить личное время или решить, что сейчас семье важнее деньги, а не идеальная чистота.
Но нельзя просто схватить Павла невидимой рукой и заставить мыть тарелки.
Павел — субъект. Пусть пока очень примитивный, но уже обладающий собственной логикой.
Минимально достаточный человек
Игра не пытается честно смоделировать человеческое сознание. Для этого не хватит ни компьютера, ни моей жизни.
Вместо этого используется минимальная модель субъектности.
У каждого персонажа есть несколько внутренних состояний:
энергия;
голод;
стресс;
близость;
автономия;
здоровье.
А также более устойчивые черты:
ответственность;
общительность;
любовь к порядку;
потребность в независимости.
При выборе действия персонаж примерно оценивает:
Насколько мне это сейчас нужно? + Привык ли я это делать? + Обещал ли я это сделать? + Поможет ли это близкому человеку? + Считаю ли я это своей обязанностью? − Сколько потребуется сил? − Насколько мне это неприятно? − Что я не успею сделать вместо этого?
После этого он выбирает действие самостоятельно.
Это не настоящий разум. Но если причинно-следственная связь достаточно понятна, игрок начинает видеть не набор коэффициентов, а характер.
Не кукольный дом, а живая система
Игрок управляет не людьми, а укладом
В этой игре игрок — не один из родителей и не всемогущий бог.
Скорее, он представляет собой волю домашнего хозяйства.
Его инструменты:
планировка квартиры;
покупка предметов;
семейный бюджет;
распорядок дня;
общие приоритеты;
распределение ответственности;
крупные жизненные решения.
Например, нельзя приказать:
«Мира, немедленно приготовь ужин».
Но можно договориться, что готовка — её ответственность.
И даже после этого Мира может отказаться. Если она истощена, перегружена или считает договорённость несправедливой, формальное назначение не превращает её в робота.
Тогда игроку придётся менять систему:
передать готовку Павлу;
снизить другие обязанности Миры;
купить готовую еду;
приобрести бытовую технику;
пожертвовать частью дохода ради свободного времени;
временно согласиться на менее чистый дом.
Здесь нет идеального решения. Есть только разные последствия.
Дом одновременно является миром и интерфейсом
Графически игра вдохновлена компактными менеджмент-стратегиями с изображением здания в разрезе.
Весь дом виден сразу:
Спальня | Гостиная
Ванная | Кухня
Рабочая зона | Детская
Каждая комната — не просто декорация, а функциональный блок системы.
Кухня преобразует продукты, время и энергию в готовую еду. Спальня преобразует время и покой в восстановление. Рабочее место превращает силы человека в деньги и стресс. Гостиная может создавать близость — или конфликт.
Игрок смотрит на дом как на живую кибернетическую схему.
Люди в ней не фишки. Они сами перемещаются между помещениями и используют доступные возможности.
Игрок управляет не людьми, а укладом
Главный ресурс семьи — не деньги
Деньги важны, но настоящий дефицит — время и внимание.
У каждого человека только один день.
Если Павел берёт дополнительные смены:
Доход растёт → Павел сильнее устаёт → меньше участвует в быту → нагрузка переходит на Миру → у Миры исчезает личное время → растёт раздражение → ухудшается атмосфера дома → Лена получает меньше спокойного внимания
Дополнительная работа была рациональным решением. Семье действительно нужны деньги.
Но локально правильное решение может сделать всю систему менее устойчивой.
Именно это меня интересует больше всего: момент, когда простые и понятные действия образуют сложные последствия, которых никто не планировал.
Даже еда — это цепочка
Персонаж не должен терять деньги в тот момент, когда ест домашний ужин. Деньги были потрачены раньше.
Полная цепочка выглядит так:
Работа → деньги Деньги + время → покупка продуктов Продукты + время + энергия → готовые порции + грязная посуда Готовая порция → снижение голода Грязная посуда + время + энергия → чистота
Если никто не купил продукты, готовить не из чего.
Если продукты есть, но никто не приготовил еду, ребёнок всё равно останется голодным.
Если еда приготовлена, но вся кухня завалена посудой, бытовая нагрузка никуда не исчезает — она просто перенесена в будущее.
Так из нескольких простых преобразований появляется домашняя экономика.
Главный ресурс семьи — не деньги
Что такое семейный климат
Кроме индивидуальных состояний, у дома есть общий эмоциональный климат.
Это не ресурс, который можно потратить, как деньги. Скорее, это температура семейной среды.
На неё влияют:
средний стресс;
близость;
совместное время;
неравномерность бытовой нагрузки;
накопившиеся конфликты;
забота;
выполненные и нарушенные обещания.
Климат меняется медленно.
Одна ссора не уничтожает семью мгновенно. Но если напряжение сохраняется, оно начинает воздействовать на всех:
Стресс людей → ухудшение климата → дома труднее отдыхать → стресс растёт ещё сильнее
Получается опасная петля обратной связи.
Но возможен и обратный процесс:
Помощь → снижение нагрузки → меньше раздражения → больше возможностей для общения → восстановление близости → улучшение климата
Игра заключается не в том, чтобы один раз заполнить шкалу счастья. Игрок должен заметить, в какой контур попала семья, и изменить условия раньше, чем система начнёт воспроизводить собственный кризис.
Что такое семейный климат
Семья как единый организм
В какой-то момент субъектом становится не только отдельный человек.
Вся семья начинает вести себя как организм:
Семейная система — Похожая функция
Доход — Получение энергии
Еда — Поддержание жизнедеятельности
Домашний труд — Обслуживание организма
Забота — Восстановление и развитие
Распорядок — Внутренний ритм
Семейный климат — Общее психическое состояние
Накопления — Запас устойчивости
При этом внешне благополучная семья может быть внутренне хрупкой.
Дом чист. Деньги есть. Ребёнок накормлен.
Но всё держится на одном человеке, который работает, готовит, убирает и заботится об остальных.
Система выглядит эффективной — до первой болезни.
Что считается победой?
Я не хочу делать единственную шкалу «идеальной семьи».
Потому что тогда игра очень быстро сообщит, что существует один правильный образ жизни.
Вместо этого семья постепенно формирует собственные ценности:
близость;
безопасность;
свобода;
порядок;
образование;
карьера;
взаимопомощь;
личное пространство.
Нельзя максимизировать всё.
Семья, постоянно проводящая время вместе, может подавлять автономию. Карьерный успех может уничтожить свободное время. Идеальный порядок может держаться на хроническом истощении одного человека.
Вопрос игры не в том, насколько семья совершенна.
Вопрос в другом:
Какой она стала — и какой ценой?
Что считается победой?
Что уже есть в прототипе
Сейчас собран браузерный MVP:
PHP;
JavaScript;
MySQL;
запуск на обычном хостинге;
автономная симуляция в браузере;
автоматические сохранения;
комнаты, действия и предметы, описанные в базе данных;
самостоятельный выбор действий персонажами;
приоритеты и распределение обязанностей;
бытовые ресурсы;
нагрузка;
семейный климат;
хроника событий.
Большую часть новых действий можно добавлять без переписывания движка.
Например, объект «посудомоечная машина» не просто повышает абстрактное счастье. Он изменяет конкретные процессы:
меньше времени на уборку → ниже бытовая нагрузка → больше времени на отдых → меньше стресс → выше вероятность общения
То есть предмет становится не бонусом, а вмешательством в систему обратных связей.
Самый важный тест
У проекта есть простой критерий качества:
Если игрок ничего не делает, устойчивая семья должна продолжать жить самостоятельно.
Игрок нужен не для того, чтобы отправлять каждого персонажа в туалет. Он нужен в моменты, когда меняется сама жизнь:
родился ребёнок;
кто-то заболел;
изменилась работа;
закончились деньги;
приехал пожилой родственник;
семья переехала;
старый распорядок перестал работать.
Прежнее равновесие разрушается, и приходится создавать новое.
Именно это я хочу симулировать: не идеальную семью, не бытовую рутину и не кукольный домик, а живую систему автономных людей, вынужденных делить пространство, время, труд и заботу.
Самый важный тест
Пока это только MVP, но сама модель уже начала выдавать маленькие истории, которых никто заранее не писал.
И теперь мне интересно:
Хотели бы вы играть в симулятор, где персонажи могут отказаться выполнять ваши планы?
Что должно сильнее всего влиять на атмосферу семьи?
Нужны ли прямые приказы хотя бы в экстренных ситуациях?
Какие жизненные события стоило бы добавить первыми?
Где проходит граница между интересной автономией и раздражающим поведением ИИ?
Потому что создать послушную куклу относительно просто.
Гораздо интереснее создать кого-то, с кем придётся договариваться.
Современные ИТ-системы — как стеклянные замки. С виду — красиво, технологично. Но стоит одному звену снаружи сломаться — всё рушится.
Сайты на React внезапно перестают работать, если отключён CDN. Системы на Firebase теряют доступ к данным из-за санкций или блокировок. Даже популярные open sourceбиблиотеки в любой момент могут получить «вредоносный» коммит — и кто в этом виноват, непонятно.
В 2023–2025 году мы массово увидели: бизнес, построенный на open source фреймворках, может быть выключен удалённо, под видом «хакерской атаки» или обновления зависимости. И ты ничего с этим не сделаешь — не ты владелец, не ты решаешь.
А что, если сделать систему, которую никто не может отключить?
— Без зависимостей. — Без фреймворков. — Без сборки. — Без интернетподключения. — Без слепой веры в чёрный ящик.
Систему, которая принадлежит только тебе.
Систему, в которой интерфейс, логика и знание — одно и то же.
Систему, которую ты можешь прочитать глазами, от начала до конца.
Так появилась Живая Машина — не продукт, а подход.
2.Источник идеи
Всё началось не с идеи, а с ощущения. Ощущения, что все эти CRM, CMS, таск-трекеры, админки и документообороты — не про человека. Это не помощники, а бюрократические барьеры, накладываемые поверх живой деятельности.
Я прошёл путь от системного администратора в больнице, до начальника ИТ отдела в НИИ микроэлектроники, работая в разных местах — от турфирм до производств. И в каждом из них видел одно и то же: люди приспосабливаются к ПО, вместо того чтобы оно подстраивалось под них.
Постепенно в голове сформировался образ альтернативы — системы, которая:
говорит на человеческом языке;
адаптируется под конкретную профессию или проект;
не нуждается в сборке из сотен пакетов и зависимостей;
может рождаться и развиваться в диалоге — как организм, а не как шаблон.
Всё это сформировалось в концепцию: цифровизация мышления. Не просто автоматизация задач, а осмысленное продолжение умственного труда, где ИИ не замещает, а усиливает. Где ты — субъект, а не пользователь чужих решений.
Так появилась Живая Машина — платформа, которая не мимикрирует под интеллект, а растёт вместе с ним.
3.Архитектура проекта
Проект «Живая Машина» вырос не из шаблона, а из практики: он собран вручную, как мастерская система, без использования чужих фреймворков, чтобы контролировать каждый элемент логики. Это не очередная CMS или CRM, а информационно-операционная оболочка, ядро которой — древовидная база знаний и модульная визуальная среда.
База знаний: дерево вместо реляционной клетки
Вместо сложных взаимосвязанных таблиц — иерархия объектов, где каждый элемент может быть:
текстом (описание, заметка, статья),
кодом (скрипт, выражение, формула),
таблицей (структурированные данные),
сущностью с галереей, ценой, метками, языковыми вариантами.
Это дерево расширяемо: объект может включать в себя другие объекты, а информация привязана к смыслу, а не к схеме.
редактирование происходит встраиваемыми компонентами (WYSIWYG-редактор, галерея, метки, таблицы),
диалог с системой строится как логическая навигация по структуре смыслов.
AI-интеграция: нейросеть как соавтор
В каждый модуль встроены хуки для LLM:
подсказки при заполнении,
структурирование текста,
автогенерация и embedding-индексация,
ведение диалога с системой на основе текущего контекста.
Лог чата и содержимое базы становятся единым потоком мышления.
Простота и автономность
Проект написан на чистом PHP + JS без внешних зависимостей, использует SQLite/MySQL и легко переносим:
можно запускать на оффлайн-сервере, в локальной сети, в Raspberry Pi, на смартфоне
нет зависимости от npm, docker, react, node — только HTML, CSS, JS.
Это система, которую нельзя выключить удалённо, нельзя заразить обновлением и можно прочитать целиком — включая весь код
4.UX и интерфейс
Живая Машина строится не вокруг привычных компонентов фреймворков, а вокруг логики восприятия и действия. Интерфейс напоминает классические файловые менеджеры: дерево сущностей, карточки, области редактирования. Ничего лишнего. Всё под рукой, и всё можно изменить.
Это не просто ностальгия — это уважение к скорости, ясности и мышечному чувству. Каждый экран — это не страница, а рабочее пространство. Каждая сущность — это не просто объект, а живая запись с телом, голосом, связями и метаданными.
Редактирование встроено прямо в контекст. Не нужно переключаться между режимами. Открытое — значит редактируемое.
Дерево — главное окно. Оно отражает логику мыслей и отношений, а не просто структуру файлов.
Галереи, редакторы, визуальные компоненты — встроены как "органы" каждой сущности: можно добавить фото, текст, поля, действия, не покидая редактора.
Диалоговые элементы (в будущем) позволят включать LLM-агентов прямо в рабочий процесс: чат с объектом, с проектом, с мыслью.
Такой UX требует дисциплины, но даёт свободу. Это не витрина, а инструмент. Не витраж, а верстак. Пользователь становится не зрителем, а мастером процесса. Именно так и должна выглядеть информационная операционная система.
5.ML-интеграция и смысловой поиск
Ключевое отличие «Живой Машины» от обычных CRM и CMS — не в интерфейсе, а в глубине понимания. Система способна работать не только с формальными структурами, но и с неструктурированными данными, превращая их в управляемое знание через смысловой анализ.
Вся база знаний автоматически индексируется embedding-моделью (например, на базе BERT или OpenAI Ada), что позволяет реализовать поиск по смыслу: вместо точного совпадения ключевого слова пользователь может задать идею, фразу или даже обрывок мысли — и получить релевантный результат.
Этот слой интеграции дополняется нейросетевыми агентами. Они могут:
давать пояснения к структуре или содержимому;
подсказывать теги, заголовки, категории;
анализировать текст и генерировать черновики на его основе;
выявлять дубликаты, противоречия или неполноту;
предлагать улучшения на основе намерений пользователя.
Смысловой поиск работает не как инструмент, а как часть самого мышления в системе — органично вплетён в процесс. Это позволяет, например, быстро найти подходящий шаблон ответа клиенту, инструкцию к действию или ранее использованную формулировку.
6.Практические сценарии: кейсы использования
Живая Машина — это не абстрактный фреймворк, а уже проверенный инструмент в реальных условиях. Ниже — примеры её применения в жизни и бизнесе.
Первый MVP был создан для реальной турфирмы из Санкт-Петербурга. Система позволяла управлять каталогом туров, визуальным наполнением, сезонными ценами, сопутствующими товарами и заявками от клиентов. Благодаря древовидной структуре, интерфейс напоминал файловый менеджер, где туры были «папками» с вложенным смыслом.
Особенности:
Упрощённое создание карточек туров и маршрутов
Быстрый визуальный редактор описаний и изображений
Автоматический расчёт цен на основе параметров
Генерация ссылок и лендингов по шаблону
Отслеживание спроса в виде смысловой карты
Кейc №2: Образовательная среда для тьюторов
Система была адаптирована под педагога-наставника, работающего с несколькими учениками. Каждый «объект» становился учеником, а его вложенные элементы — программой, упражнениями, материалами, комментариями.
Возможности:
Ведение диалога с каждым учеником в формате «живого журнала»
Поиск по смыслу в материалах и записях
Индексация личных достижений и заметок
Мгновенное переключение между «контекстами»
Кейc №3: Мастерская и CRM для ремесленника
Ремесленник (например, мастер пирсинга) использует систему как каталог работ, клиентов и задач. Каждое изделие или кейс клиента — это объект с вложенной историей, фото, описаниями, отзывами и повторяющимися действиями.
Инструменты:
Интерактивный журнал клиентов
Каталог с визуальной навигацией по стилям
Формирование рекомендаций на основе прошлых процедур
Автоматизация типовых операций (цены, сроки, статусы)
Общая мысль
Живая Машина не навязывает модель — она подстраивается под структуру мышления конкретного пользователя или профессии. В этом её сила. Она способна «оживить» даже самую рутинную работу, превратив её в диалог с цифровым отражением самого себя.
7. Сравнение с существующими решениями
На фоне привычных CRM-систем и фреймворков, «Живая Машина» выделяется не набором фич, а принципом построения:
Ключевое отличие: проект не стремится конкурировать с промышленными решениями по внешнему виду или скорости разработки, а предлагает новый подход — основанный на прозрачности, смысловой логике и доверии к системе как к партнёру, а не «чёрному ящику».
8. Заключение и перспективы
«Живая Машина» — это не просто технический проект. Это попытка нащупать новые формы взаимодействия между человеком и цифровой средой. Не встраивать ИИ в существующие шаблоны, а построить платформу, где сам ход мышления, действия, повторяющиеся паттерны становятся структурой — живой и расширяемой.
В мире, где большинство систем или чрезмерно усложнены, или слепо повторяют старые парадигмы, «Живая Машина» предлагает минимализм, открытость и гибкость. Она показывает, как может выглядеть ИИ-усиленная среда, если начать с простого: с дерева знаний, с диалога, с логики смыслов — а не с нейросетевых оверкиллов.
Платформа уже доказала свою применимость: от туристического e-commerce до внутренней CRM для креативных мастерских. Но потенциал — куда больше:
образовательные среды, где ученик взаимодействует с живой базой знаний;
сценарии самоорганизации малых команд;
цифровые ассистенты, адаптированные под уникальные роли и цели;
формирование цифрового следа профессии, ремесла, подхода.
Мы не строим очередной UI. Мы создаём пространство, в котором идеи могут жить, развиваться и работать.
9. Присоединяйтесь: ваши мысли важны
Мы верим, что Живая Машина — не просто технологический эксперимент, а задел на будущее, где человек и ИИ работают в связке как партнёры, а не конкуренты. Но нам нужен ваш взгляд, критика и идеи.
Вы разработчик? Расскажите, что вам удобно, а что требует доработки.
Вы исследователь? Поделитесь гипотезами, как можно развивать диалоговые интерфейсы и смысловую навигацию.
Вы предприниматель? Представьте, как ваша команда могла бы использовать такую систему в реальной работе.
Вы просто интересующийся? Спросите — и мы покажем, как она устроена изнутри.
Мы открыты для обсуждения, сотрудничества и критики. Вы можете протестировать MVP, задать вопрос, или даже внести вклад в код — напишите нам.
