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 помогает: