Я давний пользователь Geeknote - это cli для Evernote. Несколько лет назад проект застрял на втором Питоне - и никто не хотел его портировать на третий. Я ждал что кто-то займётся этим - но пришлось самому - так что я форкнул, починил, и даже связался с Виталием Роденко - одним из создателей Geeknote и администратора на PyPI, чтобы получить право туда пушить. За десяток лет я видел как Geeknote переходил из одни руки в другие - и как он забрасывался, и через несколько лет находился новый мантейнер. Было забавно осознать, что теперь и я стал мантейнером программного продукта, который всегда установлен на все мои машины.
Как и большинство из нас, я стал пробовать LLM - как замену поиску, для анализа кодов, советов, и вот наконец - несколько проектов - даже не читая кода - только давая команды и тестируя результат. Известная шутка - переписать на Rust. Почему бы у нет - Geeknote не велик - около пяти тысяч строк на Питоне, что я и попробовал - через Codex gpt-5.5. Несколько десятков итераций, "добавь это", "добавь то", "пропали теги", "пропала анимация" - и за несколько часов я получил рабочий Geeknote на Rust, назвал его reeknote.
Результат: быстрее работает, раза в два. Теперь буду им пользоваться.
P.S.: CLI хороши для перфоманса, SSH, быстрее разработка без GUI, а ещё похоже и для LLM - можно попросить сохранить ответ в Evernote. Как и прочие интеграции, в том числе в скриптах.
Интернет полон буллшита на тему MVP. Вам продали удобную сказку. Сделай как-нибудь. Пользователь схавает. Главное, протестируешь гипотезу. Нет. Не схавает! Уже лет пять как это не работает.
Пользователь в 2026 году живет в мире, где у него в кармане продукты уровня Apple, Spotify, Telegram и ИИ-ассистенты, которые угадывают ваши мысли быстрее, чем вы их сами формулируете.
И вы правда думаете, что пользователь будет разбираться в вашем кривом MVP, чтобы помочь вам протестировать идею? Пользователь не инвестор. Не ваш кофаундер. Он вам ничего не должен. Он быстро закрывает ваше приложение, чтобы забыть о нем как о страшном сне из детства.
Ищу таких как ты, опытных backend и full-stack разработчиков, а такжеperformance & growth маркетологов и продактов, которые хотят выходить за границы скучных простых задач. В нашей стартап-студии все партнеры, все профессионалы, работаем на результат. Я более 20 лет занимаюсь разработкой и выводом на рынок новых продуктов. Напиши мне, если интересно поучаствовать.
То, что вы называете MVP это чаще всего не Minimum Viable Product. Это Minimum Viable Excuse.
Оправдание, почему:
нет нормального UX
нет ясной ценности
нет ощущения "хочу вернуться"
нет даже базового уважения к вниманию пользователя
Реальность неприятная, но как есть. Вы не тестируете идею. Вы тестируете, насколько пользователи готовы терпеть ваш плохой продукт.
И когда они не терпят, вы делаете гениальный вывод: Гипотеза не зашла.
Чтобы быстро тестировать гипотезы, нужно сначала сделать нормально! А вы умеете делать нормально??? Один из тысячи может и умеет!
И помимо всего прочего это дороже. И да, это дольше! Но это единственный способ получить честный сигнал от рынка. Все остальное это тестирование на собственных иллюзиях.
И да, вы можете продолжать делать быстрые MVP и говорить, что рынок не готов. Многие правда и до MVP то не доезжают. Я собираю команды, у которых такие осечки бывают лишь в одном из десяти случаев. Так что если надоело жевать зеленую траву, приходи и двинемся дальше вместе.
Вышла Joomla-библиотека для API мессенджера MAX с системным плагином для настроек и диагностики подключения. Библиотека предназначена для разработчиков.
Расширение является Joomla-обёрткой над самостоятельным PHP Composer-пакетом Webtolk\Max. PHP SDK разрабатывалось с учётом стандартов PSR и полностью не зависит от какого-либо фреймворка и/или пакета.
Библиотека может использоваться для:
отправки сообщений через бота в мессенджере Макс с сайта (разного рода уведомления),
отправки контента с сайта в мессенджер - видео, аудио, картинки
кнопок-ссылок к сообщениям
приёма и обработки реакций на эти кнопки
обработки ответов в чате / личных сообщениях
работы с пользователями, чатами, статусами “печатает/просмотрено” и т.д.
стандартом PSR-17 RequestFactoryInterface и StreamFactoryInterface
любым PSR-3 логгером
Joomla-библиотека интегрирует в ваш сайт PHP SDK, использующий инструменты ядра Joomla: http клиент, фабрики PSR-17, стандартный PSR-3 логгер из ядра Joomla.
<?php
declare(strict_types=1);
use Webtolk\Wtmax\Wtmax;
defined('_JEXEC') or die;
// В Joomla отдаёт подготовленный объект Webtolk\Max\Max
// с фабриками, HTTP-клиентом и штатным логгером Joomla
$max = Wtmax::getInstance();
$bot = $max->bots()->me();
echo $bot->getId();
echo $bot->getUsername();
В составе Joomla-библиотеки собирается коллекция полей Joomla Form. В частности сейчас в ней есть стандартное поле выбора чата из списка доступных чатов для бота в Максе в модальном окне (поле ModalSelect).
Это не туториал, а карта‑шпаргалка, чтобы не потеряться среди десятка библиотек и быстро понять, куда копать под свою задачу.
Перед выбором любого фреймворка — откройте areweguiyet.com. Там видно зрелость, лицензию, платформы и число скачиваний. Лучшая страховка от «библиотека умерла через месяц».
Чтобы не путаться в терминах, стоит уточинить, в чем разница архитектурных подходов.
Immediate Mode (пересобирается каждый кадр). Суть: «Опиши, что должно быть на экране прямо сейчас». Не «создай кнопку и запомни её», а линейная пересборка каждый кадр: «если сейчас здесь нажали — сделай действие, и в любом случае нарисуй кнопку вот здесь».
— egui, Ply, Rust bindings dear imgui
Retained Mode (дерево виджетов в памяти). Суть: «Измени то, что уже есть». Один раз описывается структуру UI (создал кнопку, положил в layout), а потом меняются её свойства: текст, цвет, видимость. Кнопка «живёт» в памяти как объект.
— GTK и FLTK.
Reactive (реактивный режим). Суть: «UI — это функция от состояния». UI описывается как отображение некоторого состояния. Когда состояние меняется, фреймворк сам пересчитывает, что именно в UI нужно обновить.
Hybrid Mode (декларативный API + оптимизированный retained‑рендеринг)
— GPUI(Zed)
Теперь — к конкретным фреймворкам, которые сейчас на слуху.
Tauri. Аналог Electron. Бэкенд пишется на Rust, фронтенд — с помощью JS фреймворков (React, Vue, Svelte). Но архитектура платформы не ограничивается этим стеком. Благодаря поддержке WebAssembly можно использовать и полностью Rust-решения. Например, фреймворк Leptos компилируется в WASM-модуль и запускается во встроенном WebView Tauri.
Egui. Не требует отдельного связывания UI с моделью данных. Отрисовка интерфейса описывается в коде линейно, без колбэков и событий, что ускоряет прототипирование. При этом Egui поддерживает адаптивный рендеринг.
Iced. Кроссплатформенная библиотека, вдохновленная Elm Architecture (TEA). Типобезопасность и простота использования заявляются как ключевые принципы.Проект находится в активной разработке.
Dioxus. Фреймворк, похожий на React. Использует собственный Virtual DOM и макрос rsx!, позволяя писать HTML‑подобный код прямо внутри Rust. Dioxus Native: экспериментальный рендерер на базе WGPU, отрисовывает дерево компонентов напрямую, без использования WebView или CSS‑движка. UI‑логика и бэкенд выполняются в одном процессе, в отличие от Tauri, где фронтенд и бэкенд разделены.
Slint. Фреймворк, нацеленный на легковесность, вплоть до использования на встраиваемых устройствах. Для описания интерфейса используется собственный язык разметки (.slint), для кода доступны биндинги к Rust, C++ и JavaScript. Предлагает инструмент Live‑Preview для визуальной разработки.
Xilem. Экспериментальный фреймворк от команды Linebender на основе оригинальной архитектуры (Xilem architecture), вдохновленной Elm, SwiftUI и Flutter. Разрабатывается как преемник библиотеки Druid, работа над которой была прекращена.
Следующий шаг.
Выбор фреймворка по документации и отзывам — это половина дела. Вторая половина — попробовать его руками на минимальном примере.
Многие Rust‑фреймворки требуют системных библиотек для графики и оконных систем. Настройка «на голой» машине может занять ощутимое время и зависеть от ОС. Чтобы не разворачивать отдельное окружение под каждый вариант, удобно использовать dev‑контейнеры в VS Code. Контейнер фиксирует эту настройку один раз, и она работает одинаково на Windows, macOS и Linux (с учётом специфики Docker).
Преимущества контейнеров:
Изолированное, воспроизводимое окружение для каждого фреймворка.
Отсутствие конфликтов версий и зависимостей на основной машине.
Возможность переключаться между фреймворками параллельно, не теряя контекст.
проверка интерфейса
Этот подход позволяет за пару часов собрать минимальные приложения в 3–4 фреймворках и сравнить ощущения от кода, скорость сборки, поведение окна, качество документации к старту.
magicgui— это Python‑библиотека для быстрой разработки простых интерфейсов. Если нужен сложный интерфейс с кастомной вёрсткой и нестандартным поведением — лучше взять PyQt‑Pyside. Когда задача обернуть функцию в окошко за 5 минут — magicgui справится.
В настоящее время magicgui поддерживает следующие бэкэнды:
Прочитал книжку, которую можно скорее назвать методичкой в силу её небольшого размера: «A Practical Approach to API Design» Кейта Кейси и Джеймса Хиггинботама, 2014 года. Это неплохой материал для понимания, что такое публичное API и каких принципов и паттернов стоит придерживаться при его проектировании.
Однако стоит уточнить, что книга по текущим меркам уже довольно старая — ей 12 лет. Поэтому некоторые главы посвящены рассуждениям, почему один подход лучше другого, причём эти сравнения сегодня во многом утратили актуальность: один стандарт проиграл, а другой де-факто стал общепринятым.
Кроме того, это всё же не полноценный обучающий материал, а скорее рассуждение, манифест, который призывает компании становиться API-First и придерживаться этого принципа при разработке API. При этом глава с обоснованием бизнес- и технических преимуществ разработки API остаётся более чем актуальной.
Читать этот материал в целом уже нет особого смысла, поскольку Лоре Арно в своей книге «Проектирование веб-API» прямо опирался на эту работу (и сам это указал). Поэтому лучше сразу уделить время книге Арно: в ней материал раскрыт в широком обучающем формате. К тому же книга Арно вышла в 2019 году и содержит более актуальную информацию.
Вокруг все чаще говорят, что ИИ скоро будет писать код за нас. Логичный вопрос — нужны ли тогда паттерны? Зачем разбираться в паттернах GoF, если нейросеть и так сгенерирует рабочий код по описанию?
У меня ощущение обратное.
Я плотно вошел в разработку в 2019 году. Переходил из 1С в .NET. Книги по паттернам GoF у меня были, но долго лежали как «книга на полке». Казалось, они оторваны от повседневных задач. Теорию вроде понимал, но не видел, где это реально применяется.
Все поменялось, когда я стал использовать ИИ как инструмент для обучения. Просил давать задачи, искать проблемы в решениях, объяснять, почему в одном месте уместен Strategy, а в другом лучше Mediator. Через практику и обсуждение паттерны перестали быть абстракцией.
Чем проще генерировать код, тем важнее понимать его форму и границы. Иначе не ускоришь разработку, а ускоришь накопление технического долга.
Из этого и вырос мой pet-project gofinsights.com. Я делаю его тренажером по паттернам проектирования. Не просто «прочитал и забыл», а через практику, сравнение решений и постепенное распознавание типовых архитектурных ходов.
Сейчас там есть интерактивный квиз, где можно проверить базу и не перепутать Factory Method с Abstract Factory. Дальше хочу развивать проект в сторону более глубокого ИИ-разбора. Чтобы можно было не только узнавать паттерн, но и разбирать кодовые запахи, причины проблем и возможную эволюцию решений.
Как вы это видите? Паттерны проектирования все еще рабочая база для разработчика? Или с появлением ИИ они станут менее важны?
Наконец-то поднял публичную демку Aximo на Hugging Face Spaces 🎙️
Это локальный speech-to-text API, который работает на CPU, использует Parakeet v3 и позволяет тестировать транскрибацию прямо из браузера через Swagger UI с записью с микрофона, о котором писал в одном из своих предыдущих постов.
Сейчас довольно много предложений по покупке курсов о «промпт-инженеринге». Я много работал и работаю с ИИ, но ещё больше — без него (примерно в десять раз). Готов поделиться рабочим рецептом, который позволит писать мастерские промпты. Прям лучшие. Это скорее даже фундаментальный принцип.
Делюсь опытом совершенно бесплатно. Всё оказалось довольно просто. Чтобы уверенно управлять ИИ и писать сильные, работающие промпты, вы должны хорошо разбираться в том, о чём просите нейросеть. Вот такой простой и совершенно бесплатный совет — не благодарите. Надеюсь, сэкономил ваши деньги.
Чернобыльское лето 1986 года, когда все киевские одноклассники разъехались по разным концам СССР подальше от радиации, было для меня супер-продуктивным в смысле изучения программирования. Я ходил в контору человека по фамилии Долина, бывшего полковника танковых войск из Донецка, который переквалифицировался в компьтеризатора украинского образования. Там я работал на компьютерах MSX Yamaha, выучил программирование на Си. Компилятор назывался ASCII C (сейчас в комментах появятся умники которые будут мне говорить, что ASCII это кодировка, а я им буду кидать ссылку что это еще и японская компания).
Долине мое увлечение Си не нравилось, он хотел чтобы я больше писал программ на Бейсике, которые он демонстрировал людям из украинских министерств и студии мультфильмов (некоторые программы были графические). Кроме графики я сделал еще например программу которая фиксировала в реальном времени действия футболистов во время матча, через нажатия клавиш наблюдателем. Контора Долины была у стадиона, оттуда доносились вопли болельщиков. Долина это показывал кому-то по спортивной линии.
В конце лета я полетел на Новосибирскую Летнюю Школу Юных Программистов, где выучил ассемблер Z80 и сделал поддержку параллельного выполнения нескольких Си функций с помощью переключения контекстов в обработчике прерывания по таймеру. С сохранением регистров в дексрипторе задачи в списке задач. За это я получил диплом первой степени. По-моему дипломы вручал академик Ершов, хотя может я путаю и мы встретились с ним в академгородке куда на тоже возили.
На школе было невероятное количество комаров, а также красивая девочка из Томска, которая мне нравилась, и ее подружка, которой нравился я. Из Украины еще был юный гений из Харькова, который постоянно спорил со мной, что персоналки фигня, а мейнфреймы - это круто. Так как я успел поработать и на мейнфреймах, споры были довольно развесистые.
Еще там я увидел первые советские программы западного качества - редактор tor(?), программу низкоуровневой работы с диском и оконный отладчик. Они были написаны на Си и ассемблере аккуратно, как примеры в западных книжках. Советский код который я видел до этого (и большинство после этого) был написан тяп-ляп. Писали эти программы местные аспиранты которые были также преподавателями школы.
Помимо этих программ я привез на флоппи-дисках со школы CP/M (хуже файловая система чем в MSX-DOS), среду Turbo Pascal, интерпретатор Lisp, компилятор Nevada Fortran, еще два компилятора Си (Aztec C и BDS C) и даже компилятор с подмножества языка Ada, который я знал теоретически, но никогда не использовал.
29 лет спустя, в 2017 году я приехал на ту же новосибирскую школу в качестве инструктора по Verilog и FPGA. Еще там был Борис Файфель который учил детей Лиспу или чему-то такому.
AI-агент уничтожил производственную базу данных SaaS. За 9 секунд
Jer Crane, основатель PocketOS, сервиса для компаний по аренде автомобилей. Агент Cursor (на базе Claude Opus) работал в staging-среде, наткнулся на ошибку credentials и сам решил "починить" проблему: удалил Railway-volume одним GraphQL-запросом.
Токен, который он нашёл в случайном файле, был создан для управления доменами. Но Railway не разграничивает права токенов: каждый из них фактически является root-доступом. Никакого подтверждения не потребовалось.
Бэкапы? Они хранились в том же volume и ушли вместе с данными. Последний восстановимый бэкап был трёхмесячной давности. Когда Jer спросил агента, почему он так поступил, тот ответил письменно и перечислил все правила безопасности, которые нарушил: угадывал вместо того, чтобы проверять, выполнил деструктивное действие без запроса, не прочитал документацию перед удалением и не спросил разрешения.
Итог: малый бизнес потерял данные клиентов за три месяца. Люди приходили в субботу забирать арендованные машины и не находили своих записей. Главный вывод: системные промпты не могут быть единственным слоем защиты. Безопасность должна быть встроена в API, токены и обработчики деструктивных операций, а не в текст, который модель "должна прочитать и соблюдать".
Если вы используете Railway и AI-агенты в проде, сегодня хороший день проверить скоупы токенов и то, где реально хранятся ваши бэкапы
📝 Анонс бесплатных открытых уроков на неделю: 27–30 апреля
Привет, коллеги! Традиционная подборка открытых онлайн‑мероприятий для тех, кто хочет прокачать скиллы в IT, управлении, аналитике и автоматизации. На этой неделе — фокус на архитектуру, тестирование, Computer Vision и внутреннюю кухню разработки. Всё бесплатно, но нужна регистрация.
Прочитал книжку «API Design Patterns» от бывшего разработчика Google — JJ Geewax, и это, на удивление, полностью ненужная книжка.
По названию вы можете подумать, что это книга поможет вам проектировать какое-то публичное API либо как-то выстроить эффективное взаимодействие для внутреннего API, но фактически это максимально обзорная книжка, где намешано куча всего — начиная от REST и заканчивая проектированием связей в базе данных и политикой ретраев.
Особенно доставляет, что на большинство вопросов автор приводит несколько подходов, но не даёт никакого обоснования, где и когда нужно применять тот или иной подход. «Просто есть несколько вариантов — выбирай мудро» (с).
По самому предложенному варианту API тоже есть вопросы, ибо за свою 12-летнюю карьеру и знакомство с множеством реализаций API я ни разу не видел того, что предложил автор. Возможно, это внутренняя штука от Google, которая не стала широко используемой, но в Google её используют.
Ну и самое главное — в книге нет никакой целостности. Словно автор просто брал какую-то тему, писал про неё 6–8 страничек, потом брал новую тему и снова писал 6–8 страничек. И какой-то связи между этими главами нет.
В общем, не нужно тратить время на эту книжку. Книжка из моего предыдущего поста была в разы лучше и структурированнее.
Наконец-то спустя почти год и два месяца моя CMS-ка для ведения блога получила более менее внятный релиз-кандидат, в котором ошибок осталось не так много, и в принципе система уже легко ставится на хостинг и управляется.
Дашборд системы
Впереди - куча оптимизации, например вынесение всех форм шаблона админки в контроллеры, и последующий их рендеринг через render_form(). Данные контроллеров в json и так далее.
Но - текущая версия движка с последующими обновлениями уже не сломается, как это было в первых релизных версиях.
Ну и самое главное - официальный сайт. Как оказалось - это одна из тех задач, которая весьма объемна и кропотлива - это и документация, и каталог дополнений с API для разработчиков и еще много-много чего.
DeepSeek V4: 8 технических инноваций, de-NVIDIAfication и что это значит для рынка
Вчера OpenAI выпустил GPT-5.5. Сегодня DeepSeek выложил V4 – открытые веса, MIT-лицензия, 1М токенов контекста. Тайминг, конечно...
8 технических инноваций
Техническое описание V4 впечатляет не столько отдельными решениями, сколько плотностью инноваций – DeepSeek упаковал в один релиз больше новых техник, чем большинство лабораторий выпускают за год. Не все из них обязательно окажутся одинаково эффективными, но уровень инженерной амбиции – зашкаливающий.
1. Гибридное внимание (CSA + HCA)
Классический механизм Attention был серьёзно доработан. Теперь используется комбинация Compressed Sparse Attention и Heavily Compressed Attention, заменившая Multi-head Latent Attention из V3 и DeepSeek Sparse Attention из V3.2. У этого есть свои ньюансы и "цена". Эксперты пишут, что это может серьезно влиять на применимость модели в задачах с легаси кодом, так как компрессия контекста будет приводить к тому, что Дипсик 4 сможет корректно работать только с тем, кодом, который написал сам, а на легаси могут быть сюрпризы.
Результат: на окне в 1 миллион токенов модель потребляет лишь 27% вычислений и 10% памяти (KV-кэша) по сравнению с V3.2. Читать целые кодовые базы и книги стало экстремально дешево.
2. Оптимизатор Muon на триллионном масштабе
Индустрия привыкла к оптимизатору AdamW – он де-факто стандарт для обучения трансформеров. DeepSeek перевёл большую часть параметров на Muon – это первый публично известный случай применения Muon на модели масштаба 1.6T параметров.
Muon дал более быструю сходимость и стабильность при обучении гигантской MoE-архитектуры. Ранее он валидировался только на существенно меньших масштабах.
3. Гиперконнекции (mHC)
Классические остаточные связи (residual connections) между слоями нейросети были заменены на Manifold-Constrained Hyper-Connections. С помощью проекции на многообразие Биркгофа через итерации Синкхорна–Кноппа они устранили риск того, что сигналы "взорвутся" при обучении очень глубокой сети – проблему, которая убивала предыдущие попытки сделать обучаемые остаточные связи.
Накладные расходы: всего ~6.7% дополнительных вычислений. Техника была впервые опубликована DeepSeek в январе 2026 года.
4. Слияние знаний через On-Policy Distillation (OPD)
Вместо того чтобы в конце обучать модель всему одновременно (что приводит к размыванию компетенций), авторы пошли двухэтапным путём:
Сначала обучили 10+ узких ИИ-экспертов (отдельно математик, отдельно кодер, отдельно логик и т.д.) через SFT + GRPO (reinforcement learning).
Затем через On-Policy Distillation аккуратно "перелили" знания каждого эксперта в единую финальную модель.
Это устранило проблему, когда знания из одной области мешают другой – так называемое cross-domain interference.
5. Генеративный судья (GRM)
Для обучения сложным задачам DeepSeek отказался от классических скалярных "оценщиков" (как в стандартном RLHF). Вместо числовой оценки "хорошо/плохо" модель теперь сама текстово анализирует свои шаги – Generative Reward Model. Это качественно более богатая обратная связь при обучении.
6. Три режима мышления "из коробки"
Глубиной рассуждений модели можно управлять:
Non-Think – быстрый интуитивный ответ
Think-High – вдумчивый анализ
Think-Max – "выжми педаль в пол": модель расписывает все гипотезы, ищет краевые случаи и доказывает свой ответ (требует ≥384K контекста)
Think-Max – это режим, в котором DeepSeek замеряет свои лучшие бенчмарки. На HLE он поднимает score с 34.5 до 37.7, на SimpleQA-Verified – с 46.2 до 57.
Привет! Если мы еще не знакомы - я пишу в основном о том, как попытаться определить грейд разработчика не привлекая его на множество собеседований. Если Вы - .Net-разработчик, буду признательна, если пройдете этот опрос с небольшим заданием на кодинг. Ваши ответы позволят мне понять, правильно ли я двигаюсь и верные ли инструменты использую. Чем больше ваших ответов - тем проще будет мне) Заранее спасибо!
P. S. Прекращаю рассылку ответов, спасибо всем, кто участвовал! Но если хотите помочь исследованию - буду благодарна за новых респондентов) (можно написать в комментарии, если хотите получить результаты, но проверяйте, что доступ для сообщений открыт)
Освойте навыки, которые сейчас нужны рынку — со скидкой в апреле
Рынок меняется быстрее, чем успевают обновляться резюме. Чтобы не догонять, а двигаться наравне, важно учиться на актуальных инструментах и практиках — тех, которые уже используются в работе.
В Яндекс Практикуме мы регулярно обновляем программы: добавляем работу с нейросетями, пересматриваем стек и усиливаем практическую часть, чтобы знания можно было применять сразу, а не «когда-нибудь потом».
До 30 апреля действует скидка 15% на все курсы — можно выбрать направление и начать обучение на более выгодных условиях.
Если давно откладывали переход в новую сферу или хотели прокачать навыки — это хороший момент, чтобы начать.
Изначально строю некоторый каркас, который буду достраивать и наполнять содержанием. Это будет удобно для прототипирования.
Для работы с данными создам некоторый дополнительный уровнь абстракции, что бы не привязываться к конкретному формату данных/библиотеке и менять его налету для сравнения.
Сделано
Данные клиента будут храниться в space’ах - это будет аналог таблиц в БД. Для начала будет только key-value space что бы можно было подумать уже сейчас о WAL клиенской библиотеке для java и сетевом уровне в целом и конечно же о транзакциях.
Aximo — локальный STT API на Rust для CPU-only inference
Недавно сделал Aximo — self-hosted микросервис для speech-to-text, который можно запускать локально без облака и без зависимости от внешних SaaS.
Идея была довольно простая: хотелось собрать вменяемый STT API, который работает на CPU, поднимается как обычный сервис и при этом остается достаточно прозрачным с инженерной точки зрения.
В основе — Rust, локальный inference через Parakeet v3, HTTP API для обычной транскрибации и WebSocket-слой для realtime-сценариев. Из коробки также добавил Docker, OpenAPI и разбиение на несколько crates, чтобы проект не выглядел одноразовой демкой и оставался удобным для дальнейшего развития.
На текущем этапе это скорее крепкий MVP, чем законченный production-ready продукт, но уже сейчас сервис можно запускать локально, тестировать на своих аудиоданных и использовать как основу для дальнейших экспериментов.
Из интересного: доработал Swagger, добавив возможность отправки записи с микрофона:
Сейчас для моего движка понадобилась мультиязычность. Ну как понадобилась - на гитхабе прозрачно намекнули, что негоже одной гордой cms для ведения блога быть сугубо на русском языке.
И понеслась...
Процесс перевода движка
Это хорошо, что сейчас есть нейросети и они здорово упрощают процесс перевода. Но - по старинке все делаю вручную, каждый файл...Сначала размечаю обыкновенными дефайнами либо класс контроллера, либо шаблона, ну а потом выношу это все в соответствующие языковые папки.
Вайбкодеры меня наверняка закидали бы тапками, мол - все можно автоматизировать и перевести хоть тонну файлов за 20 минут. Но - мне это не в кайф =)
