SQLite *

В 0.11 мы сорок раундов гоняли ИИ-ревьюеров по коду и нашли много багов. Но у каждого ревьюера было своё представление о том, что значит «правильно». В 0.12 мы начали с другого конца: записали шестнадцать инвариантов, которые обещает наша MCP-память, а затем две модели из разных лабораторий десять дней искали контрпримеры. Засчитывалась только находка с воспроизведением. Рассказываю, что они сломали (Windows посчитала NUL терминалом), во что это обошлось и что мы сознательно оставили в Known issues.

Прошлый раз я писал про то, как заложил в схему БД поля под синхронизацию, которой пока нет. Синхронизации до сих пор нет, зато вышли два обновления: 0.2.0 и 0.2.1. В этой статье про три вещи, на которых пришлось подумать: переносимую папку с данными, бэкапы и импорт из Notion и Obsidian. Nookly — локальное приложение для заметок на Flutter: страницы, блоки, таблицы, канбан, поиск. Данные лежат в SQLite на устройстве, без облака.

Полгода назад я в одиночку начал делать Nookly — локальное приложение для заметок на Flutter: страницы, блочный редактор, таблицы с канбан-видом, полнотекстовый поиск. Ключевое требование с самого начала: всё работает офлайн, данные не покидают устройство. В этом посте — не про сам продукт, а про два инженерных решения, которые могут быть полезны: как спроектировать схему БД так, чтобы синхронизация потом не потребовала переписывания половины кода, и как собрать лендинг вообще без шага сборки.

11 недель назад я начал делать социальную сеть, в которой гражданство зависело только от имени.

Если тебя зовут Егор, Георгий или одной из форм имени, происходящего от Georgios, то это место для тебя, 100%! Остальные становятся Наблюдателями: могут читать, реагировать, писать в личку, жить в своих районах — что-то вроде ВНЖ.

На этом месте проект вполне мог закончиться хорошей шуткой, которой и являлся ИЗНАЧАЛЬНО. Но пользователи начали спрашивать, кто здесь главный.

Так в Егороде появился мэр. Потом люди спросили, кто выбирает мэра. Появились выборы.

Затем — партии, депутаты, кабинет, указы, вето и импичмент, а социальная сеть начала подозрительно напоминать государство, состоящее преимущественно из Node.js, SQLite и людей по имени Егор.

Сейчас в проекте около 11,9 тысячи регистраций, обычный DAU — примерно 30–35 человек, кодовая база выросла примерно до 210 тысяч строк, 176 таблиц и 2625 тестов.

И именно небольшой ежедневный онлайн в итоге сильнее всего повлиял на архитектуру, потому что город на 30 человек может позволить себе довольно простую инфраструктуру.

Но он не может позволить себе переставать существовать, когда эти 30 человек уходят спать.

У мессенджера MAX нет публичного API со статистикой каналов. Числа есть у каталогов-агрегаторов, но они чужие и заморожены с 10 июля. Нам нужен был свой ряд подписчиков — и мы полгода снимаем его каждую ночь с публичного data-эндпоинта max.ru.

Ниже — как устроен сбор и четыре места, где мы ошиблись. Самая дорогая ошибка стоила трёх ночей молчащего ряда при зелёном логе и exit 0: парсер на любую неудачу писал один статус not_found, а под него попадали три разных события — канала нет, max.ru сменил формат, нас затроттлило. Пока они не разделены, скрипт ничего не измеряет — он производит число, похожее на измерение.

В марте я уже выкладывал материал про свой ранний проект - AAF (Autonomous Agent Framework). Это был базовый эксперимент, на котором я обкатывал концепции локального контекста и вызова инструментов. За прошедшие месяцы я переписал архитектуру с нуля, учтя накопленный опыт, и сформировал новый фреймворк - JAWL (Just A While Loop).

Если посмотреть на актуальный ландшафт опенсорсных автономных агентов, выделяются два интересных проекта: OpenClaw (созданный Питером Штайнбергером) и Hermes Agent (от Nous Research).

Перед сделкой с альткоином мне обычно нужно быстро ответить на два вопроса: есть ли у цены выраженное направление и происходит ли в монете что-то заметное прямо сейчас. Смотреть для этого десяток страниц на разных биржах неудобно, поэтому я собрал небольшой сканер.

Пользователь отправляет тикер и получает три результата: направление активность и итоговый статус.

Несколько месяцев назад я начал делать небольшой сервис для контейнерной логистики.

Изначальная идея была довольно простой: заменить бесконечную публикацию одних и тех же грузов и свободных машин в рабочих чатах нормальным поиском.

Так появился ГрузоБот это сервис для грузоотправителей, экспедиторов и перевозчиков, работающий через мессенджер MAX.

Сейчас проект уже находится в бета, но продакшене, поэтому хочу рассказать не столько о самом сервисе, сколько о том, что оказалось под капотом и с какими задачами пришлось столкнуться при разработке.

Я довольно давно вожусь с сервисами вокруг товарных данных: делаю price‑matrix (обработка прайсов поставщиков) и CatalogLoader (парсеры сайтов). InventoryMod вырос из той же темы, но с другого конца — не «собрать и разобрать данные», а «вести по ним складской учёт».

InventoryMod — учётная система для склада: товары, остатки, движения, заказы, закупки, инвентаризация, отчёты. Начал где‑то в середине апреля 2026-го с расширения для Chrome с локальной базой (первый коммит в git датирован 19 мая — до него первая версия довольно долго собиралась «в столе»), потом добавились мобильное приложение и полноценный SaaS с сервером.

Главная проблема, с которой я жил всё это время, формулируется просто: как не писать три раза одну и ту же бизнес‑логику, когда база данных в каждой среде своя. Где‑то SQLite прямо в браузере, где‑то удалённый сервер по HTTP.

Дальше разберу на реальном коде из репозитория, как из query‑модулей выводится API‑контракт, почему я в итоге слез с IndexedDB на SQLite‑WASM и что творилось с транзакциями в резервировании остатков. Про сам продукт скажу ровно столько, сколько нужно для контекста.

Забыли забрать ежедневные гемы или потеряли счёт круткам до гаранта? Рассказываю, как я решил собственную проблему и разработал GachaPoint — бесплатный офлайн‑компаньон для Genshin Impact, Honkai: Star Rail и Zenless Zone Zero без бэкенда и рекламы.

В статье разбираю техническую изнанку проекта для Android (Java / Architecture Components): Зачем использовал «плоскую» таблицу в SQLite (Room) для календаря и как это ускоряет выборки за один запрос, Почему для сетки дней кастомный GridLayout оказался удобнее RecyclerView, Как настроить точные ежедневные напоминания через WorkManager с учётом жестких ограничений Doze Mode в Android 12/13+.

Исходники проекта открыты, буду рад обсудить архитектуру и UI‑решения в комментариях!

Последние несколько лет я, похоже, одержим двумя темами: а) Nix в качестве инструмента для исследования новаторских идей, требующих возможностей перестройки мира; б) замена ELF на SQLite в качестве формата исполняемых файлов. Возможно, вы заметили, что эти две идеи хорошо сочетаются друг с другом.

Я изучал вторую идею в рамках своей диссертации, однако реакции окружающих оказались довольно разочаровывающими. Радикальные идеи сложно продвигать, ведь приходится бороться с инерцией давно устоявшегося решения.

Одним из результатов этого исследования стал инструмент sqlelf, позволяющий декларативно исследовать файл ELF при помощи SQL. [Я написал статью arXiv:2405.03883, которую мне не удалось опубликовать]. SELECT name FROM elf_symbols вместо возни с readelf и grep. Это оказалось на удивление просто благодаря использованию виртуальных таблиц для ELF, однако мне всё равно было интересно исследовать формат файлов ELF. Но всё же я понимал, что можно сделать нечто гораздо большее.

Меня всё не покидала эта мысль, а в свете прогресса LLM мне показалась привлекательной идея исследовать эту тему глубже. В частности, мне было любопытно, что будет, если мы заменим ELF на SQLite в качестве формата исполняемых файлов?

Не просто «база данных, описывающая исполняемый файл», а реальный файл, с которым можно сделать chmod +x и запустить его.

Сайт не сломан. Он открывается. В логах чисто, ошибок нет — просто ты кликаешь по вкладке и успеваешь заметить, что кликнул.

Я померил: страница кабинета грузилась 2,1 секунды. При этом сервер отдавал HTML за 30 миллисекунд. Первый час я искал не там — потому что померил не ту страницу.

Всё решил один замер. Я дёрнул один и тот же CSS-файл десять раз с кукой сессии и десять раз без неё: 55 мс против 14 мс. За файл с диска. Оказалось, аутентификация делала SELECT, UPDATE и COMMIT в SQLite на каждую картинку и каждый скрипт — сорок раз за страницу, чтобы сорок раз переписать один и тот же таймстамп.

Вторым тормозом был Tailwind, который компилировал стили в браузере у каждого посетителя. Стало 0,9 секунды.

А потом я сел делать скриншоты для этой статьи и за двадцать минут нашёл ещё два бага, которые спокойно жили в проде. И чуть не уронил чат, исправляя найденное.

Код открыт

Цена запроса не зависела от того, что ищешь: фильтр стоял над GROUP BY. Теперь отсечение идёт до агрегата, на трёх движках, без единой правки в коде приложения. До 100 раз на диапазоне по дате и в 5,3 раза на полной выборке в MS SQL Server.

Есть класс проблем производительности, который не видно на маленьких данных и невозможно не заметить на больших. Наш выглядел так: запрос искал один редкий номер заказа среди сотни тысяч объектов ровно столько же, сколько поиск, не находящий ничего. Избирательность условия не влияла на время. Совсем.

Причина оказалась в форме сгенерированного SQL. Значения props живут построчно, и запрос сначала сворачивает их в широкую строку через GROUP BY, а уже потом применяет фильтр. Условие стояло над агрегатом, то есть фильтровало результат свёртки, а не колонку. Индексу там зацепиться не за что: к моменту проверки движок уже прочитал и свернул все значения всех объектов схемы. Триграммный индекс по строкам лежал без дела.

В 3.7.1 появился шаг, который ...

И так, что мы имеем и для чего же собственно эта статья? Когда человеку ставят задачу в духе «Придумай пароль» — он берет и генерирует самостоятельно некую псевдослучайную последовательность, что в будущем именуется паролем (или с помощью генераторов паролей, которые встроены во все популярные браузеры, или с помощью установленных утилит). Казалось бы, можно и так понять, что самые часто используемые слова в духе «мама», «папа», «пароль» и другие — вполне объяснимы. Это то, что нас в большинстве своем объединяет, а потому может намного чаще встречаться в паролях. Не все люди хотят заморачиваться и отказываться от простых и понятных аналогиях. На примере старшего поколения моей семьи (бабуле) могу хоть сколько раз подтвердить, что ее излюбленный пароль был именем дочери и годом ее рождения.

А ведь в таких псевдо случайных генерациях можно встретить «проблему раскладки» (то, что проанализировано было в русском сегменте только в 2025 году следующими лицами: Леа Мюллер, Аушриус Юозапавичюс, Владимир Охримчук, Стефан Зюттерлин в работе «Поиск в словаре с использованием преобразованных русских слов на клавиатуре QWERTY», P. S. я мог допустить ошибки в переводе информации, за что прошу прощения). Если кратко, то это создает некую «маску», зная которую можно облегчить взлом. Подобные словари встречаются в открытом доступе, и еще чаще встречаются в недоброжелательном сообществе за разные суммы денег.

Широкое распространение СМИ в сети привело к формированию группы тематических экспертов — лидеров общественного мнения — блогеров. Их задача — оценка и анализ фактов, подача информации через призму собственного мнения.

Закономерно, мысленное упражнение, как человек, оставивший след в истории, оценил бы тот или иной современный факт.

Офлайн-хранилище со сложным графом и outbox: быстрый старт в MAUI и в браузере, базовые операции и почему в этой роли EF Core только мешает.

Курьер спустился в подвал склада — связи нет. Кладовщик третий час принимает поставку в зоне, где вайфай добивает через раз. Пользователь заполнил форму на четыре экрана и нажал «Сохранить» в момент, когда сервер уехал на деплой.

Приложение должно продолжать работать. Значит ему нужна своя база на устройстве: не кеш ответов, а полноценное локальное хранилище, где живут незавершённые документы, локальные состояния и очередь изменений на отправку — тот самый outbox, который дошлёт всё, когда связь вернётся.

И вот тут начинается знакомое.

История о том, как сервис логирования Discord-серверов прошёл путь от сложной связки MySQL + PHP + Python до простого решения на Python + SQLite в одном Docker-контейнере — и почему упрощение стека того стоило.

Когда говорят «энтерпрайз-стек на .NET», обычно имеют в виду зоопарк: база от одного вендора, шина от другого, ORM с миграциями, отдельный оркестратор, ещё что-нибудь для наблюдаемости — и клей между всем этим, который пишешь сам и потом сам же чинишь по ночам.

Мы пошли другим путём и последние полгода собираем это как одну согласованную экосистему: типизированное хранилище redb поверх Postgres/MSSQL/SQLite, интеграционный движок redb.Route (наш ответ Apache Camel под .NET) и рантайм redb.Tsak с дашбордом, hot-reload и кластером. Три слоя, один код, один стиль.

Сегодня вышла версия 3.3.0 — синхронный бамп всей экосистемы. Это не «добавили пару фич»: это релиз, в котором мы починили то, что молча не работало под нагрузкой (и это, пожалуй, главное), добавили два новых транспорта, довели до конца RAG-петлю для LLM и сделали конкурентность на любом источнике. Ниже — по делу, с кодом.

И сразу главное: с версии 3.3.0 все Pro-решения бесплатны. Никаких лицензий, никаких ключей, никакой регистрации — просто ставишь пакет и юзаешь. Change tracking, bulk, продвинутый кэш, аналитика, кластер Tsak с координатором и failover — всё включено из коробки, в разработке и в проде одинаково. dotnet add package redb.Postgres.Pro — и оно работает. Никакого пейволла, никакого лицензионного сервера, ничего активировать не надо.

Эта статья прежде всего будет полезна студентам и начинающим специалистам.

В отрасли разработки программного обеспечения под системным дизайном (System Design) понимают процесс проектирования архитектуры, компонентов, баз данных и связей информационной системы. Цель системного дизайна - обеспечить масштабируемость, отказоустойчивость и высокую производительность системы, в том числе при росте нагрузки. В этой статье я затрону базовые задачи системного дизайна - как спроектировать и разработать систему так, чтобы она обладала архитектурой, чтобы развитие и поддержка системы не приносила много страданий, чтобы доработки не ломали действующий функционал.

"Если вашего бизнеса нет в Интернете, то вас нет в бизнесе! Скоро на рынке останется два вида компаний: те, кто в Интернете и те, кто вышел из бизнеса." 

А потом вдруг интернета не стало и нужно было срочно что-то придумать для работы нашей ERP-системы оффлайн