SQLite *

Привет, Хабр! С выходом платформы MAX у разработчиков появилось новое игровое поле. Пока комьюнити спорит о шансах на победу в гонке мессенджеров, маркетологи уже начали переливать туда трафик.

Самая типовая задача для бизнеса сейчас — бот обратной связи. В Telegram эту нишу давно занял Olgram, а вот в Max — чистый лист. Давайте вместе напишем свой аналог. Это отличный кейс, чтобы разобраться с новым API, не углубляясь в лишнюю инфраструктуру.

Стек: Почему все оказалось проще, чем кажется

Для MVP (Minimum Viable Product) мы будем использовать Node.js и официальную библиотеку @maxhub/max-bot-api.

Привет Хабр! В прошлой статье мы детально разобрали функциональные зависимости. Возможно, после нее у вас, как и у многих, остался закономерный вопрос: зачем нам вообще так париться, выискивая эти зависимости? Как это применяется в проектировании баз данных?

Естественно, можно спроектировать базу данных, вообще не заботясь ни о каких правилах. И она даже будет работать! Все будет прекрасно ровно до первого ее реального использования в продакшене. При проектировании «абы-как» возникают три типовые проблемы: избыточность, аномалии обновления, аномалии удаления.

И вот это уже плохо.

У нас есть продукт и нам нужно рассчитать ключевые метрики, которые показывают здоровье продукта:

• DAU/MAU – вовлеченность
• Conversion Rate – конверсия в целевое действие (у нас это создание объявления)
• Retention – удержание пользователей
• LTV – жизненная ценность клиента
• ARPPU – средний доход с платящего пользователя

В статье разберем последовательный расчет с примером синтетических данных и готового кода на SQL.

SQL в 2026: что реально нужно знать аналитику? 🤔
Спойлер: не только JOIN и GROUP BY, а еще и оконные функции, когортный анализ, оптимизация запросов и работа с BigQuery.
Пошаговый план для новичков с бесплатными тренажерами, курсами (да, Карпов там есть) и списком тем, без которых вас не наймут.

Давайте разберем четкий план: что учить, где брать практику и как не потеряться в море информации 👇

Переезд с macOS на Windows для разработчика часто сопровождается болью от потери привычного инструментария. В моем случае решающим стимулом свитчнуться на ПК стала мощная видеокарта. Сейчас мой верный MacBook всё так же лежит на столе и даже подключен к мониторам, но по факту именно Windows (как бы сильно она мне ни не нравилась) стала основной рабочей системой.

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

Штатный инструмент Windows (Win+V) разочаровал моментально: лимит в 25 элементов, отсутствие поиска и полное обнуление после перезагрузки ОС. Поиск альтернатив тоже не увенчался успехом: Ditto надежен, но выглядит как гость из 2005 года, а мощный CopyQ имеет перегруженный интерфейс суровой системной утилиты. Ни в одном из них не было современных функций вроде OCR «из коробки» или базовой интеграции с LLM для обработки текста на лету.

Решение напрашивалось само собой — написать свой велосипед. Но сделать его легким, быстрым и без Electron. В этой статье расскажу о том, как устроен Beetroot — менеджер буфера обмена с бесконечной историей, нативным OCR и AI-трансформациями.

На своем тг-канале я предлагаю подписчикам выбор, какую бредовую идею запилить следующей. На этот раз подписчики выбрали новый челлендж: сделать Git в Telegram. Чтобы можно было через бота инитить проекты, пушить файлы, коммитить — и всё это в публичном канале с тредами.

С практической точки зрения этот проект нахуй не нужен. Есть гитхаб, есть гитлаб, есть куча нормальных инструментов. Но как эксперимент — почему бы и нет? Чисто посмотреть, можно ли заставить Telegram работать как VCS.

Я тогда подумал: «Ну, бот на aiogram, база данных, пара команд — делов то))»

Словари, датаклассы и прочая е*атория

Когда я только начинал, первая мысль была: «Положу всё в JSON, на кой мне база данных?» Ну серьёзно, проектов мало, пользователей немного, файлы текстовые че заморачитватся.

Подергал JSON туда-сюда пару дней и понял: не варик.

Во-первых, конкурентный доступ. Два юзера одновременно коммитят — один из них перезаписывает файл другого. Во-вторых, целостность данных. Если бот упал в середине записи — JSON остаётся в невалидном состоянии. В-третьих, версионность. Хранить историю изменений в JSON — это просто перенести проблему из кода в структуру файла.

Короче, JSON — для конфигов, а не для данных, которые меняются каждую секунду.

Выбор пал на SQLite.

Почему:

В ритейле каждый сантиметр полки – это деньги (буквально). В этой статье я разберу примеры задач, которые решает аналитик в ритейле, и покажу, как их решать на SQL.
Каждая задача сложнее предыдущей для каждой есть код и готовые синтетические данные, поэтому все результаты можно получить самостоятельно, повторив код.

Один разработчик, один AI-напарник (Claude), ноль инвесторов. Рассказываю, как за 4 месяца я построил платформу автоматизации контент-маркетинга с 14 микросервисами, собственной очередью задач на SQLite вместо Redis, мультимодельным AI (MiniMax, YandexGPT, Replicate) и circuit breaker для автоматического fallback между провайдерами. Всё на одном сервере, всё через npm install.

Я делаю локально работающего ИИ-агента и столкнулся с тем, что стандартный подход «закинуть текст в векторную базу, достать по косинусу» для долгоживущего агента не работает: контекст замусоривается, факты конфликтуют, ничего не забывается. Вместо этого реализовал графовую когнитивную память поверх одного файла SQLite: эпизодические и семантические узлы, типизированные рёбра, именованные сущности, гибридный поиск (FTS5 + vector + graph) с Reciprocal Rank Fusion, кривую забывания Эббингауза и фоновую LLM-консолидацию. В статье — полная архитектура с кодом, SQL-схемой и формулами. Код и минимальный пример — в репозитории.

SQL для аналитика: разбор 4 задач со скриптами и примерами данных

Собрала 4 задачи, которые решала на старте карьеры на реальных проектах, и показываю:
- как обычный GROUP BY превращается в полноценный ABC-анализ;
- как оконные функции помогают увидеть динамику, которую в Excel считать часами;
- как найти неэффективные категории (даже если по цифрам всё "нормально");
- как построить прогноз на паре оконных функций.

Внутри:
- Скрипты с пояснениями;
- Сгенерированные данные (можно скопировать и проверить);
- Пример бизнес-вывода к каждому запросу.

Статья для аналитиков, которые хотят прокачать SQL и понимать, что на самом деле происходит в их данных.

Большинство AI-инструментов — либо облако, либо код под каждую задачу. Coreness Flow строится вокруг событий: пришло сообщение, сработал cron, прилетел webhook — агент находит сценарий по триггеру и выполняет цепочку шагов.

Плагины декларируют вклад в интерфейс через config.json — фронт собирает вкладки и настройки по этим данным, без правки React-кода. Новый плагин — новая вкладка, без хирургии во фронтенде. RAG полностью локальный: BGE-M3 ONNX INT8 + Qdrant embedded в процессе приложения, гибридный поиск офлайн. Разбор архитектуры — API Bus, lifecycle, система сценариев с триггерами и переходами.

Статья представляет компактную математическую нотацию для SQL-препроцессора, разработанную для формирования сложных условных выражений из JSON-конфигураций. Нотация позволяет кратко записывать операции с множествами и интервалами: комбинированные операторы (>=[18,65]), стрелочные символы для интервалов (>> — BETWEEN, >< — NOT BETWEEN) и логическое отрицание через знак минус. Цель — создать интуитивно понятный, непротиворечивый и расширяемый язык запросов. Практическое применение — генерация SQL-кода в препроцессорах, DSL для построителей запросов, компактные фильтры в JSON-API. Рассматриваются сильные стороны и потенциальные проблемы нотации, сравнительный анализ с аналогами (Quist, SQL++, PRQL), выявляется уникальность подхода. Автор приглашает к обсуждению и предлагает сотрудничество.

В статье разберем реальную задачу аналитика ассортимента в ритейле: «Какие товары люди покупают вместе», на учебных данных, с кодом SQL, со всей необходимой математикой и с примером выводов.

Когда я решила стать аналитиком, я не знала про SQL вообще ничего, совсем, базовое образование у меня экономическое и в университете SQL нам никто не преподавал.

В этой статье приведу пример 5 задач, которые меня научили SQL по-настоящему, все они построены на том, с чем работает аналитик ассортимента: товары, категории, продажи и поставки.

В данной статье я покажу код на JS, который не поместился в предыдущей статье, а также перепишу его на TS. Кратко расскажу о преимуществах TS над JS и о том, что необходимо понимать для перехода.

В прошлой статье я также упоминал, что у Сергея получилось запустить мой проект на Tauri в режиме разработки на Arch. Он поделился со мной информацией в issue на GitHub и тем самым внёс вклад в проект. Поэтому я решил попробовать исправить проблему на основе его issue. Заодно расскажу, что такое issue и как оно выглядит.

Заваривайте чай, доставайте вкусняшки — пора «снимать первый урожай помидор»! 🍅

Опубликовал ЧАСТЬ 2: проект вырос из простого SNMP‑опрашивателя в рабочий инструмент для парка принтеров. Теперь есть склад картриджей, журнал ТО, отдельная страница парка и удобные экспорты в Excel. Пишу про реальные боли (цветные МФУ, разные прошивки, потеря данных в CSV) и о том, что планирую доделать

В версии 1.58.0 библиотеки prisma-sql появился метод $batch, который позволяет выполнять несколько Prisma-запросов за один раунд-трип к базе данных.

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

Введение: Проблема ручного контроля

На работе одним из постоянных и важных процессов является проверка чеков на подлинность. Их поток достаточно большой (порядка нескольких сотен каждый день) и при этом каждый документ разбирается вручную - это может занимать до нескольких минут на один файл. На дистанции получается достаточно много. К тому же ручная проверка это медленно, дорого, и зачастую с ошибками из-за усталости аналитиков.
Потратив некоторое время на поиск готового решения нашей проблемы я нашел самописные гитхабные репы, которые максимум распознавали текст на картинке, даже не на PDF, платных решений я также не нашел, банки их не светят и естественно не продают.

Я ни разу не технарь (хотя по образованию инженер, ха), но благодаря опыту в антифроде я знал точно, что нужно проверять и как. Поэтому я подумал, что было бы прикольно (а в перспективе и полезно) сделать простенькую ML-ку и потихоньку ее обучать, пет проект который если стрельнет, то принесет пользу, а если не стрельнет - я потрачу время с удовольствием.

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

Привет Хабр! Возможно вас, как и меня, первое знакомство с функциональными зависимостями в базах данных повергло в легкий ступор. Длинные определения, которые не давались даже после третьего прочтения, излишняя абстрактность, когда на простые и понятные примеры поскупились, и прочее прелести «научного» подхода к объяснению сложных тем.

Пора раз и навсегда разобраться во всем этом. Тем не менее, я постараюсь не упускать детали и, где это уместно, углубиться в тему с головой. Без претензии на академичность, но с претензией на ясность. Начнем.