Хабр Курсы для бэкендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Бэкенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 27
Закреплённые комментарии
В текущей версии Beetroot умеет трансформировать текст через AI — OpenAI и локальные модели (Ollama, LM Studio). В ближайшем релизе добавится Gemini. Но это только начало — вот что планирую дальше:
Глобальные AI-хоткеи. Выделяешь текст в любом приложении → шоткат → результат обратно на место. Исправление ошибок, перевод, переформатирование — без открытия окна, без потери содержимого буфера.
Webhook-пайплайны. Отправка клипа по хоткею в n8n, Make, Zapier или любой HTTP-эндпоинт. Результат возвращается как новый клип.
Примеры:
Скопировал ссылку → webhook достаёт заголовок, описание, OG-картинку → готовый markdown в буфере
Скопировал текст → webhook прогоняет через DeepL → перевод обратно
Скопировал код → webhook форматирует/линтит → результат в буфере
Скопировал email → webhook парсит контакт → добавляет в CRM
Скопировал данные → webhook пишет в Google Sheets / Notion
По сути — clipboard как универсальный input для любой автоматизации.
Фантазировать можно бесконечно.
Буду рад идеям.
Но моя главная цель на ближайшие релизы — полная интеграция с Ollama.
Ollama/LMStudio поддерживают OpenAI-compatible API, так что вам нужно просто добавить в настройки "OpenAI base url" и отправлять к нему запросы по тому же интерфейсу (указывается локальный адрес типа 127.0.0.1:4999/v1). Библиотеки OpenAI обычно поддерживают настройку base url.
Также, как вариант - чем OCR-ить средствами Windows, можно опционально отправить запрос в ту же vision-модель LMStudio (так же, как в OpenAI API). Qwen 3.5 4B вполне неплохо справляется с распознаванием, и работает с приемлемой скоростью что на CPU, что на GPU.
Спасибо! Как раз в свежей версии (v1.4.0) это прикрутил — Ollama, LM Studio и любой кастомный OpenAI-compatible endpoint. Оказалось проще, чем я ожидал, но не без подводных камней: Ollama и LM Studio используют разные эндпоинты для списка моделей (/v1/models vs /api/tags), а reasoning-модели оборачивают ответ в теги, которые нужно вырезать. Плюс пришлось пробрасывать запросы через Rust IPC, потому что Tauri'шный CSP блокирует fetch на localhost из WebView — это было самое неочевидное.
Сейчас добавляю Gemini, дальше другие провайдеры. Технически подключить несложно, основное время уходит на тестирование.
По OCR — нативный Windows API (WinRT OcrEngine) работает мгновенно и без зависимостей, но качество на сложных изображениях ограничено (точно хуже, чем на MacOS). Есть идея сделать автоматическое распознавание текста на всех картинках в фоне — тогда по ним можно будет искать так же, как по обычному тексту.
Кстати, в версии, которая сейчас готовится к релизу, поиск уже работает не только по содержимому, но и по заголовкам окон-источников. Например, можно ввести название Telegram-канала — и найдутся все сообщения, скопированные оттуда, потому что Telegram подставляет название чата в title окна.
Reasoning - да, есть такое. Я предпочитаю вообще по возможности его отключать, потому что медленные ответы получаются...
Насчет списка моделей: через v1/models с читается стандарт, но я бы лично вообще может не заморачивался, пусть пользователь ручками вставит ID (тем более иногда он не нужен), делается это один раз. Главное, чтобы можно было к сторонним обработчикам подключаться :)
Что идет развитие проги - отлично, поздравляю!
фоновую утилиту, которая будет постоянно висеть в трее и отъедать 150-300 МБ оперативной памяти (и это в лучшем случае)
Глянул на свой менеджер для гитлаба на Electron+Angular. ~30 Мб оперативки. Что-то не сходится.
Размер бандла - 130Мб, да сильно больше, но это точно критично в эпоху террабайтных дисков?
Сейчас эти терабайтные диски сильно выросли в цене. Как SSD, так и HDD. И вообще, это уже давняя проблема, что софт разжирел до безумия. Это ужасная практика программирования. Потому как мы получаем не одну разжиревшую софтинку. Куча программ жрут уйму постоянной и оперативной памяти + ресурсы cpu и gpu. Так не должно быть. Это крайне токсичная практика разработки. От неё надо отказываться. Софт должен быть хотя бы минимально оптимизированным. Камон. В эпоху нейронок не проблема сделать красивую и удобную морду на одной из кучи быстрых gui-библиотек.
Я ничего против Electron не имею — это отличный инструмент, на нём написано огромное количество хорошего софта. Просто для себя сделал такой выбор. Как человеку, который писал код для i286 во дворце пионеров, мне морально тяжело видеть инсталлятор на 130 МБ и 300 МБ в трее. Наверное, профессиональная деформация, гонюсь за оптимизацией там, где можно и не гнаться.
Для пары ИИ действий стоит сделать глобальные шоткаты, например выделяешь кусок текста в любом месте, нажимаешь шоткат и получаешь автоисправление ошибок без лишних перемещений и телодвижений, и с сохранением того что было в буфере без изменений. Еще полезен аналогичный вариант с переводом на английский-русский. Тут такое реализовано https://github.com/theurs/ClipGen-m/blob/main/README_RU.md
Отличная идея, спасибо за ссылку! Это уже в роадмапе — глобальные шоткаты для AI-действий без открытия окна. Сейчас кастомные промпты работают через контекстное меню, но в целом весь этот блок буду переписывать.
Помимо встроенных AI-провайдеров, думаю сделать опцию отправки по шоткату webhook в пайплайн (например n8n) и получение результата обратно в виде нового клипа — чтобы можно было строить любые цепочки обработки снаружи.
Супер, спасибо за статью!
Подскажите, пожалуйста, а каким менеджером буфера обмена пользовались на macos?
Спасибо! На macOS пользовался Paste, по сути он и стал главным вдохновением для Beetroot. Ещё Alfred с его Clipboard History. Но Paste — это платная подписка, Alfred Powerpack тоже платный, и оба только Mac. Захотелось сделать что-то похожее для Windows, прежде всего для самого себя, чтобы пользоваться каждый день.
Попробуйте CopyLess 2, вполне годная штука без ИИ прибамбасов. Просто делает свое дело.
сетевые протоколы (SMB/NFS) не гарантируют корректную работу локальных файловых блокировок (locks), критически важных для SQLite
Расскажите, чем вызваны эти опасения.
SQLite координирует доступ через файловые блокировки (fcntl на Unix, LockFileEx на Windows). Сетевые файловые системы реализуют эти блокировки ненадёжно. в FAQ SQLite прямо сказано: "fcntl() file locking is broken on many NFS implementations", а про Windows: "file locking of network files is very buggy and is not dependable". В https://www.sqlite.org/howtocorrupt.html описан механизм: если блокировки работают некорректно, два процесса могут одновременно писать в базу, что ведет к corruption.
В Beetroot база всегда локальная, но пользователи иногда выбирают синхронизируемую папку (OneDrive, Dropbox, Google Drive) как data directory, а это даже хуже, чем NFS: облачные сервисы синхронизируют файлы, а не блокировки, и два устройства могут писать в одну базу не подозревая друг о друге. Поэтому добавил детекцию таких папок и предупреждение при выборе пути.
sqlite сильно пессимизирует и обобщает лет так на 15 😀
Да, блокировки в NFSv3 (которые отдельный протокол NLM, да и сам NFSv3 без сессий) действительно плохо работают вместе с NAT, фаерволами, роумингом wifi со сменой IP адресов, засыпанием ноутбуков. Если таких проблем нет, то даже NFSv3/NLM работает надёжно.
Но современные Linux-ы давно по умолчанию используют NFSv4, в котором блокировки уже часть протокола.
Про Windows faq ссылается на FAT и косяки реализации. Это тоже уже устарело до смешного. Любой современный Windows с NTFS и SMBv3 поддерживает блокировки без каких-либо проблем давно. А с persistent handles клиенты даже перезагрузки сервера переживут.
Верю, скажем, что когда-то были баги в Samba. Но сейчас уже давно ребята из SerNet хорошо работают над Samba. Если только у вас не файловый сервер на каком-то дремучем NAS, то проблем не будет.
Так что сетевые диски точно не нужно запрещать. Предупреждение можно, если хотите 😀
Единственно, если не уже (я не смотрел код), то стоит I/O делать асинхронно, чтобы основной UI не замирал, если вдруг сетевой диск затупил.
Спасибо, чуток поизучал тему глубже, думаю, что вы правы. Ситуация по факту лучше, чем я думал.
Сейчас Beetroot блокирует сетевые диски и UNC-пути при выборе data directory. Решение было defensive, но с учётом вашего разбора про SMBv3/NFS блок избыточен, заменю на предупреждение.
Облачные папки (OneDrive, Dropbox, Google Drive) - это отдельная история: там sync engine копирует файлы между устройствами без координации блокировок. Для них показываю предупреждение, а не блокировку.
По async I/O - всё через Tauri IPC, UI не блокируется при медленном диске. Плюс бэкапы через SQLite Backup API и автовосстановление при повреждении, так что даже в худшем случае данные не теряются.
Киллера фича для меня - вызов по хоткею оккна мультибуфера рядом с позицией курсора, чтобы не прыгать глазами по экрану. Нажал, допустим, F2, не отводя взгляда быбрал нужный клип стрелками и вставил "энтером". Есть и в CopyQ, и в Ditto.
Хорошо бы портабельную версию.
Хорошо бы сохранение паролей из парольных менеджеров сделать опциональным в настройках, кому надо - включит.
Первое уже есть. В Beetroot три режима позиционирования окна: по центру экрана (по умолчанию), следование за курсором и закреплённое окно поверх всех. Переключаются хоткеем или кнопкой в футере. В режиме Follow Cursor окно появляется прямо рядом с мышью, можно выбрать нужный клип и вставить, не отводя взгляда.
Портабельная версия: хороший запрос, пока только installer, но технически ничего не мешает сделать portable-сборку.
По паролям: сейчас Beetroot автоматически пропускает записи из парольных менеджеров (детектирует по специфичным форматам буфера обмена). Идея сделать это опциональным логична. Кому-то может быть удобно наоборот сохранять. Учту.
следование за курсором
Вообще не понял, как это работает. Версия 1.40, "Локальные горячие клавиши работают только когда окно Beetroot в фокусе" -?? У меня окно всегда возникает в центре экрана.
Еще можно попросить настройку размеров шрифта: глаза и мониторы у всех разные, для меня мелковато.
Логика такая: ALT+P и ALT+F - это локальные хоткеи, то есть работают когда окно Beetroot уже открыто. Но переключить режим нужно только один раз, настройка сохраняется. После этого каждый раз, когда вызываете Beetroot глобальным хоткеем, окно будет появляться рядом с курсором (режим Follow Cursor) или оставаться поверх всех окон (Pinned).
Переключить можно и мышкой - в футере две иконки рядом с шестерёнкой.
Размер шрифта уже настраивается: Settings → Appearance → Font Size (6 вариантов от 11 до 18px). Там же можно выбрать шрифт.
А на Linux можно будет завести программу, если отбросить Windows функционал?
Теоретически да, Tauri v2 поддерживает Linux, и основная логика (React + SQLite) кросс-платформенная. Но Windows-специфичного кода довольно много: clipboard monitoring через Win32 API, OCR через WinRT, определение раскладки клавиатуры, извлечение иконок приложений, window management (always-on-top, follow cursor, multi-monitor DPI). Это всё пришлось бы переписывать на Linux-аналоги (X11/Wayland, Tesseract, и т.д.).
Пока в приоритете Windows. Но Linux-порт вполне реален, архитектура позволяет.
В текущей версии Beetroot умеет трансформировать текст через AI — OpenAI и локальные модели (Ollama, LM Studio). В ближайшем релизе добавится Gemini. Но это только начало — вот что планирую дальше:
Глобальные AI-хоткеи. Выделяешь текст в любом приложении → шоткат → результат обратно на место. Исправление ошибок, перевод, переформатирование — без открытия окна, без потери содержимого буфера.
Webhook-пайплайны. Отправка клипа по хоткею в n8n, Make, Zapier или любой HTTP-эндпоинт. Результат возвращается как новый клип.
Примеры:
Скопировал ссылку → webhook достаёт заголовок, описание, OG-картинку → готовый markdown в буфере
Скопировал текст → webhook прогоняет через DeepL → перевод обратно
Скопировал код → webhook форматирует/линтит → результат в буфере
Скопировал email → webhook парсит контакт → добавляет в CRM
Скопировал данные → webhook пишет в Google Sheets / Notion
По сути — clipboard как универсальный input для любой автоматизации.
Фантазировать можно бесконечно.
Буду рад идеям.
Вариант без ИИ возможен? Например через опцию в инсталляторе
Да, AI полностью опционален, он не встроен в ядро приложения и не требует никаких ключей для работы. Beetroot из коробки работает как обычный clipboard manager: история, поиск, starred clips, OCR, темы, трансформации текста (upper/lower/trim/title case).
AI-фичи появляются только если вы сами зайдёте в настройки и настроите провайдера. Без этого никаких запросов наружу, никаких зависимостей от облачных сервисов.
Единственное, что ходит в интернет без AI - это проверка обновлений (раз при запуске, GitHub API). Но и это отключается в настройках. После этого приложение живёт полностью оффлайн.
Отдельная опция в инсталляторе не нужна, потому что AI-код - это буквально один fetch к API, который никогда не вызывается без явной настройки. Ни бинарников, ни моделей, ни SDK в поставке нет.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Под капотом Beetroot: как я написал менеджер буфера обмена на Tauri v2 и Rust с установщиком 6 МБ