0.86.0-beta.1 - это большой бета-цикл: агент получил единый дом в интерфейсе, у Yttri появился первый плагин (интеграция с Obsidian) и сама платформа плагинов, на Mac с Apple Silicon заработал альтернативный локальный движок MLX, а голосовой ввод и запись прошли через плотную серию фиксов стабильности. Ниже - по разделам, что из этого видно пользователю.
В феврале я публиковал первую статью про Yttri: что это за приложение, зачем я его делаю и почему мне не хватало Obsidian, Notion, почтового клиента, таск-трекера и AI-чата по отдельности.
Тогда это был первый публичный заход в бета-тестирование. Первая сотня мест ушла быстрее, чем я ожидал, а комментарии оказались полезнее любой внутренней аналитики. Люди спрашивали про локальность данных, закрытый код, запуск без Ollama, связь задач с письмами и заметками, синхронизацию, доверие к приложению и вообще про то, не слишком ли это большой комбайн.
С тех пор Yttri сильно изменился. Это уже не просто «единый интерфейс для всего», а более взрослая local-first среда: с открытыми markdown-данными, локальными моделями, агентом, почтой, задачами, заметками, финансами, записями встреч и нормальной доставкой тяжёлых AI-компонентов.
Сейчас я расширяю бета-тестирование и хочу позвать новых пользователей.
Yttri часто сравнивают с Notion, Obsidian, ChatGPT и облачными сервисами транскрипции - и это логично. В этой статье я разбираю, где эти инструменты реально выигрывают, а где упираются в ограничения: интернет, приватность, стоимость, разрозненность данных и «проект по настройке плагинов».
Сравнение без холиваров: облачные workspace (Notion/Coda/Confluence), локальные конструкторы (Obsidian/Logseq/Joplin), standalone AI-чаты (ChatGPT/Claude/Gemini) и транскрипция как сервис (Otter/Whisper API/Trint). Плюс - почему Yttri решает другой класс задач: единый локальный контур (заметки + почта + календарь + задачи + финансы + встречи), офлайн-режим и AI внутри пространства (RAG + tool calling + локальные модели).
Если вы выбираете «что взять под конкретный сценарий» — эта статья сэкономит время.
Устали прыгать между Jira, Confluence, Notion, Calendar и почтой? Я написал Yttri — мощный комбайн на Rust + Tauri для управления всей цифровой жизнью. Локальный AI, графовая база знаний, приватность и никакой облачной зависимости. Рассказываю, как объединить хаос в одну систему и почему Local-First победит.
Привет, Хабр! В предыдущей статье я рассказывал, как портировал модель синтеза речи Qwen3-TTS на Rust. Тот проект (RustTTS) получился достаточно успешным — один бинарник, мгновенный старт, никаких Python-зависимостей.
Естественным продолжением стала обратная задача — распознавание речи (ASR, Automatic Speech Recognition). Логика казалась простой: у Qwen есть и TTS и ASR, архитектуры похожи, опыт с Candle уже есть, значит справимся за пару недель. Ну... не совсем.
Что будет, если выкинуть Python-обвязку и сделать TTS по-взрослому?
Я взял Qwen3-TTS и за месяц собрал RustTTS: компактный бинарник, быстрый старт, стриминг и контролируемый инференс без “venv на 2 ГБ”.
Покажу, как устроен пайплайн (text → tokens → audio), где реально узкие места, какие оптимизации дают эффект, и почему RTF на CPU может быть конкурентным, если не стрелять себе в ногу архитектурой.
В этой статье я расскажу, как я для себя понимаю архитектуру десктоп-приложений — и почему в какой-то момент Rust перестал быть «языком, который я когда-нибудь посмотрю», и стал практичным решением.
Сразу оговорюсь: это не попытка доказать, что «Electron — зло», а Rust — «спаситель». Это скорее дневник архитектора, который хотел собрать удобный продукт и по дороге несколько раз наступил на грабли. Некоторые грабли были с подогревом.
OpenCode классно задуман, но сейчас страдает от нестабильности и плохой работой с моделями/контекстом. Droid от Factory заметно стабильнее в типичных задачах и аккуратнее работает с контекстом. Но и у него есть «детские болезни» на отдельных конфигурациях CPU/Windows.
Разбираю в деталях в чем суть. Делюсь личным опытом двух месячного использования.
Современные подходы к разработке программного обеспечения диктуют необходимость быстрого внедрения и изменения бизнес-сценариев прямо в продакшене. Особенно это критично для систем, где логика процессов часто корректируется — например, в финансовых, маркетинговых или рекламных платформах.
Одним из наиболее удобных инструментов для этого сегодня является оркестрация с использованием BPMN-диаграмм, где визуальное моделирование бизнес-процесса превращается в исполняемую логику.
Каждый архитектор сталкивается с вечной дилеммой: как правильно документировать архитектуру, чтобы она была понятна людям и одновременно пригодна для автоматизации? Сегодня разберем три основных подхода и выясним, когда какой использовать.
Современная документация архитектуры должна решать множество задач одновременно. Она должна быть понятна разработчикам, архитекторам и бизнесу, поддерживать версионирование, интегрироваться в CI/CD процессы и оставаться актуальной.
Привет, коллеги! Сегодня хочу поделиться с вами своими размышлениями о терминальном AI-агенте OpenCode и его сравнении с другими популярными решениями на рынке. После нескольких месяцев активного использования различных AI-инструментов для кодирования, могу с уверенностью сказать: OpenCode — это действительно что-то особенное.
Use Case (сценарий использования) – это метод описания взаимодействия пользователя (или другого актора) с системой для достижения определённой конкретной цели. Проще говоря, Use Case описывает, кто и что делает с системой (или что система делает в ответ), чтобы пользователь получил нужный результат.
В контексте анализа требований Use Case выполняют важную роль: они переводят разрозненные требования в последовательность действий и реакций системы, понятную для всех участников проекта. Таким образом, Use Case помогает: