У меня дело скорее в скромных потребностях и фундаментальному стремлении к минимализму. Было время, когда я экспериментировал с Obsidian и навернул в нём десятки плагинов, но потом понял, что лично они мне не нужны. Конечно, у других ситуация может быть абсолютно иная.
В Zed прямо много чего нет, чтобы он стал полноценной заменой персональной базе знаний, но думаю это вопрос времени. Mermaid туда подвезли (мой 1.14.2 их рисует, проверил сейчас), CSV table previews появился с 1.17.2. Вообще, как правило, если мне что-то не хватает, я пытаюсь найти какую-то внешнюю специализированную замену, но с графами документов дело не имел, поэтому не подскажу.
Я вот вообще подумываю свои базы знаний вести через Typst и по необходимости отрисовывать оттуда налету то, что мне нужно, благо функционал Tasks там довольно гибкий. А сам Typst умеет в typst query. Мне кажется прикольно, когда базу знаний можно местами распечатать :) И конечно Markdown тоже можно распечатать, если постараться, но всё таки в Typst это из коробки как-никак.
Немало, но смею надеяться, что эти 130МБ используется эффективнее, чем такой же объём скушанный веб-движком. Если честно, я не прям чтобы так хочу использовать как можно меньше оперативки, скорее использовать её эффективно и чтобы интерфейс отзывчивый оставался. Веб ведь за собой не только браузер тянет, но и кучи JS библиотек, которые поди ещё разбери как с памятью обращаются.
Как-то сейчас тяжело надеяться на то что там агенты освоят или не освоят. В смысле - они и сейчас вполне такой проект сделают (особенно, если локально склонируешь референсы и тыкнешь), просто в отсутствии запроса пользователя нафигачат электрона не задумавшись. Но в последнее время есть определённый тренд на GPUI проекты. Это радует.
Tauri конечно лучше чем Electron, но вот бы побольше людей узнали про GPUI и освоили его. Может быть тогда мы наконец-то освободимся от браузерного гнёта в наших системах. Будет как никогда актуально с нынешними ценами на оперативку.
Жаль, что лично для меня локальная генерация музыки оживёт лишь когда появится возможность делать точечные inpaint’ы и extend’ы. Udio мог править микро-участки, чтобы допустим сделать более чёткое произношение какого-то отдельного слова. После создании песни я делал сотни таких правок, чтобы отполировать всё что только можно. Недавно пробовал inpaint’ы через ACE-Step, но такие “патчи” сильно заметны.
Если в Zed Editor открыть папку удалённого сервера как проект, то в рамках одного окна доступна консоль сервера, файлы проекта и ИИ-помощник который сможет взаимодействовать с сервером. Надеюсь, что когда-нибудь они осилят сделать полноценную систему плагинов, чтобы можно было добавить туда дополнительный функционал.
Хм, интересно, а они как-то запрещают публикацию собственных сборок? А то ведь легко кому-то одному это сделать и просто опубликовать. В nixpkgs репозитории по таймауту закрылась issue про пакетирование Cap. Вот интересно, если бы её не закрыли, а сделали, то запуская Cap из nix репозитория должен ли я за него платить?
Настройка получается довольно тяжеловесной. Наверное, имеет смысл так заморачиваться только для долгосрочного сопровождения и там, где вообще есть возможность так сильно перенастроить сервер.
Мне приходилось выдавать root только локальным агентам, поэтому я сделал собственную приблуду (jusdo у меня в профиле на GitHub), которая работает от root, слушает сокет и позволяет выполнить любой рецепт из заранее подготовленного и утверждённого по контрольной сумме Justfile. Можно в любой момент на любой сервер скопировать два бинарника (включая just) + Justfile, а потом запустить вручную.
Тоже использую диспетчеров, но думаю оба способа друг друга дополняют. Диспетчеру сжатие может быть и не нужно, он принимает стратегические решения и мусорный контекст ест редко, а вот модель-разработчик вполне себе может в процессе диагностики чего-то лишнего набраться. Всё конечно зависит от типа задач и композиции, но по сути выдать дополнительный инструмент “compact” тем агентам, которым он может пригодиться лишним не будет.
А что за автоматизации? У меня во всех проектах Justfile с разными часто-повторяемыми рецептами. Чтобы все проверки качества запустить, модели нужно вызвать лишь just check, который в параллель уже 50 команд запускает. На подготовку git workgree и ветки тоже свои рецепты. Но, честно говоря этого не хватает. Хочется прикрутить какой-то честный движок запуска workflow. Присматриваюсь к microsoft/conductor, но не хочется, чтобы движок сам запускал модели. Скорее, чтобы модель имела опорный механизм в виде движка и знала что дальше делать и чтобы некоторые шаги запускались автоматически после перехода процесса в новый узел выполнения. Возможно получится siemens/wfx как-то приспособить. Все сейчас пилят столько нового инструментария вокруг ИИ-агентов, что едва успеваешь за всем этим следить, не то чтобы попробовать.
Смысл плагина как раз в том, чтобы дать модели самой вызывать компактизацию, причём не всей переписки, а только её части. Допустим после полезной ориентациина было 30к, а потом модель начала диагностику и наелась логов, но оказалось, что это был тупиковый путь, а контекста уже 100к. Перед тем как переходить к следующей попытке модель вызывает сама компактизацию части нижних сообщений и после этой компактизации она будет видеть изначальные 30к + столько, сколько напишет сама в суммаризации.
Интересно, насколько в борьбе с этим может помочь плагин, который даёт модели возможность суммаризировать часть контекста. Модель делает запрос к логам, понимает, что там мусор и ничего полезного и сразу суммаризирует результат этого “хода” и продолжает уже с этими знаниями. Какое-то время использовал opencode-dynamic-context-pruning, но ничего не замерял и не добавлял инструкции убирать из контекста подобный мусор. Надо будет попробовать.
А что если вместо PHP-миграции просто сделать mysql < result.sql? Побыстрее должно быть и за лимиты беспокоиться не нужно. Вот бы какой-то готовый скрипт под вычистку SQL иметь, а ещё автоматизировать сбор SQL через консольную утилитку вроде, чтобы не заниматься скучным переключением DBDebugToFile и нажатием кнопки в админке. С таким инструментарием и на проектах поменьше подход вполне сработает.
Звучит как будто подключить на Битрикс проект phpstan экстремально просто, но если вы в коде используете, скажем, метод add наследника DataManager, то можете упасть с ошибкой от phpstan говорящей о том что он не знает этого DataManager. Потом окажется, что в ядре этот DataManager не настоящий, а class_alias'нутый. В итоге приходится через bootstrap-файл phpstan'а вызывать все эти alias'ы после classmap'инга всех нужных модулей.
Ещё одной большой болью является тот факт, что в ядре масса методов, phpdoc'кументация которых врёт. Вот прямо врёт - говорит что возвращает один тип, а по факту возвращает всегда другой. phpstan поддерживает stub-файлы. Ура? Нет.
Why is PHPStan complaining about “Class not found” in a stub file?
Stub files are analysed independently from the rest of your codebase. This means that any type they’re referencing must also be present as a stub, even if you don’t want to override any of its PHPDocs.
В редком случае можно разместить один файл в stub'ы и всё. В реальности, одно за другое целпяется и чуть ли не всё ядро надо описывать. Для решения этой проблемы можно воспользоваться php-stubs/generator, но там тоже начинают возникать проблемы одна за другой, в итоге так это и не поборол.
А что касается pre-commit хука, это только на первый взгляд кажется хорошей идеей. А вот если phpstan думает 5 минут, то становится как-то печально. К тому же, для многих типовой сценарий - коммитить через некий GUI, например в PhpStorm и там рассматривать большие полотна отчёта об ошибках не так уж и удобно.
У меня дело скорее в скромных потребностях и фундаментальному стремлении к минимализму. Было время, когда я экспериментировал с Obsidian и навернул в нём десятки плагинов, но потом понял, что лично они мне не нужны. Конечно, у других ситуация может быть абсолютно иная.
В Zed прямо много чего нет, чтобы он стал полноценной заменой персональной базе знаний, но думаю это вопрос времени. Mermaid туда подвезли (мой 1.14.2 их рисует, проверил сейчас), CSV table previews появился с 1.17.2. Вообще, как правило, если мне что-то не хватает, я пытаюсь найти какую-то внешнюю специализированную замену, но с графами документов дело не имел, поэтому не подскажу.
Я вот вообще подумываю свои базы знаний вести через Typst и по необходимости отрисовывать оттуда налету то, что мне нужно, благо функционал Tasks там довольно гибкий. А сам Typst умеет в typst query. Мне кажется прикольно, когда базу знаний можно местами распечатать :) И конечно Markdown тоже можно распечатать, если постараться, но всё таки в Typst это из коробки как-никак.
Немало, но смею надеяться, что эти 130МБ используется эффективнее, чем такой же объём скушанный веб-движком. Если честно, я не прям чтобы так хочу использовать как можно меньше оперативки, скорее использовать её эффективно и чтобы интерфейс отзывчивый оставался. Веб ведь за собой не только браузер тянет, но и кучи JS библиотек, которые поди ещё разбери как с памятью обращаются.
Как-то сейчас тяжело надеяться на то что там агенты освоят или не освоят. В смысле - они и сейчас вполне такой проект сделают (особенно, если локально склонируешь референсы и тыкнешь), просто в отсутствии запроса пользователя нафигачат электрона не задумавшись. Но в последнее время есть определённый тренд на GPUI проекты. Это радует.
Веду свои заметки в Zed проекте, мне хватает.
Tauri конечно лучше чем Electron, но вот бы побольше людей узнали про GPUI и освоили его. Может быть тогда мы наконец-то освободимся от браузерного гнёта в наших системах. Будет как никогда актуально с нынешними ценами на оперативку.
Добротный подход.
Жаль, что лично для меня локальная генерация музыки оживёт лишь когда появится возможность делать точечные inpaint’ы и extend’ы. Udio мог править микро-участки, чтобы допустим сделать более чёткое произношение какого-то отдельного слова. После создании песни я делал сотни таких правок, чтобы отполировать всё что только можно. Недавно пробовал inpaint’ы через ACE-Step, но такие “патчи” сильно заметны.
Если в Zed Editor открыть папку удалённого сервера как проект, то в рамках одного окна доступна консоль сервера, файлы проекта и ИИ-помощник который сможет взаимодействовать с сервером. Надеюсь, что когда-нибудь они осилят сделать полноценную систему плагинов, чтобы можно было добавить туда дополнительный функционал.
Хм, интересно, а они как-то запрещают публикацию собственных сборок? А то ведь легко кому-то одному это сделать и просто опубликовать. В nixpkgs репозитории по таймауту закрылась issue про пакетирование Cap. Вот интересно, если бы её не закрыли, а сделали, то запуская Cap из nix репозитория должен ли я за него платить?
Настройка получается довольно тяжеловесной. Наверное, имеет смысл так заморачиваться только для долгосрочного сопровождения и там, где вообще есть возможность так сильно перенастроить сервер.
Мне приходилось выдавать root только локальным агентам, поэтому я сделал собственную приблуду (jusdo у меня в профиле на GitHub), которая работает от root, слушает сокет и позволяет выполнить любой рецепт из заранее подготовленного и утверждённого по контрольной сумме Justfile. Можно в любой момент на любой сервер скопировать два бинарника (включая just) + Justfile, а потом запустить вручную.
Тоже использую диспетчеров, но думаю оба способа друг друга дополняют. Диспетчеру сжатие может быть и не нужно, он принимает стратегические решения и мусорный контекст ест редко, а вот модель-разработчик вполне себе может в процессе диагностики чего-то лишнего набраться. Всё конечно зависит от типа задач и композиции, но по сути выдать дополнительный инструмент “compact” тем агентам, которым он может пригодиться лишним не будет.
А что за автоматизации? У меня во всех проектах Justfile с разными часто-повторяемыми рецептами. Чтобы все проверки качества запустить, модели нужно вызвать лишь
just check, который в параллель уже 50 команд запускает. На подготовку git workgree и ветки тоже свои рецепты. Но, честно говоря этого не хватает. Хочется прикрутить какой-то честный движок запуска workflow. Присматриваюсь к microsoft/conductor, но не хочется, чтобы движок сам запускал модели. Скорее, чтобы модель имела опорный механизм в виде движка и знала что дальше делать и чтобы некоторые шаги запускались автоматически после перехода процесса в новый узел выполнения. Возможно получится siemens/wfx как-то приспособить. Все сейчас пилят столько нового инструментария вокруг ИИ-агентов, что едва успеваешь за всем этим следить, не то чтобы попробовать.Смысл плагина как раз в том, чтобы дать модели самой вызывать компактизацию, причём не всей переписки, а только её части. Допустим после полезной ориентациина было 30к, а потом модель начала диагностику и наелась логов, но оказалось, что это был тупиковый путь, а контекста уже 100к. Перед тем как переходить к следующей попытке модель вызывает сама компактизацию части нижних сообщений и после этой компактизации она будет видеть изначальные 30к + столько, сколько напишет сама в суммаризации.
Интересно, насколько в борьбе с этим может помочь плагин, который даёт модели возможность суммаризировать часть контекста. Модель делает запрос к логам, понимает, что там мусор и ничего полезного и сразу суммаризирует результат этого “хода” и продолжает уже с этими знаниями. Какое-то время использовал opencode-dynamic-context-pruning, но ничего не замерял и не добавлял инструкции убирать из контекста подобный мусор. Надо будет попробовать.
А что если вместо PHP-миграции просто сделать
mysql < result.sql? Побыстрее должно быть и за лимиты беспокоиться не нужно. Вот бы какой-то готовый скрипт под вычистку SQL иметь, а ещё автоматизировать сбор SQL через консольную утилитку вроде, чтобы не заниматься скучным переключением DBDebugToFile и нажатием кнопки в админке. С таким инструментарием и на проектах поменьше подход вполне сработает.Разработчик jscpd уже сам его переписал на Rust: https://github.com/kucherenko/jscpd/tree/master/rust Crate: https://crates.io/crates/jscpd
Звучит как будто подключить на Битрикс проект phpstan экстремально просто, но если вы в коде используете, скажем, метод add наследника DataManager, то можете упасть с ошибкой от phpstan говорящей о том что он не знает этого DataManager. Потом окажется, что в ядре этот DataManager не настоящий, а class_alias'нутый. В итоге приходится через bootstrap-файл phpstan'а вызывать все эти alias'ы после classmap'инга всех нужных модулей.
Ещё одной большой болью является тот факт, что в ядре масса методов, phpdoc'кументация которых врёт. Вот прямо врёт - говорит что возвращает один тип, а по факту возвращает всегда другой. phpstan поддерживает stub-файлы. Ура? Нет.
В редком случае можно разместить один файл в stub'ы и всё. В реальности, одно за другое целпяется и чуть ли не всё ядро надо описывать. Для решения этой проблемы можно воспользоваться php-stubs/generator, но там тоже начинают возникать проблемы одна за другой, в итоге так это и не поборол.
А что касается pre-commit хука, это только на первый взгляд кажется хорошей идеей. А вот если phpstan думает 5 минут, то становится как-то печально. К тому же, для многих типовой сценарий - коммитить через некий GUI, например в PhpStorm и там рассматривать большие полотна отчёта об ошибках не так уж и удобно.