Python *

Каждый раз, когда начинаешь новый SaaS-проект на Django, первые две недели уходят на одно и то же. Сначала — кастомная модель пользователя с UUID вместо integer PK, потому что потом не переедешь. Потом JWT-аутентификация, настройка SimpleJWT, написание RegisterView, LoginView, LogoutView — всё это уже было в прошлом проекте, но лежит в другом репозитории и просто так не скопируешь. Дальше Docker Compose: сервисы web, db, redis, celery, celery-beat, flower — шесть штук, которые надо поднять и связать между собой. Потом разбираться с Celery, который в новой версии изменил синтаксис конфига. Stripe webhooks с идемпотентностью — отдельная история. Мультиарендность, роли, permissions — ещё неделя.

В итоге к первой рабочей фиче добираешься к концу третьей недели.

Добавь сюда ещё один нюанс: каждый раз это проект с немного другим стеком. Где-то Kafka вместо Redis, где-то allauth с самого начала, где-то биллинг на пользователя, а не на команду. Но ядро остаётся одним: каждый раз перед стартом ты тратишь одинаково одни и те же две недели. Вот это и хотелось исправить.

Я прошёл через это несколько раз и в какой-то момент решил, что хватит. Собрал Django SaaS boilerplate под названием Shipyard — не как набор сниппетов в Notion, а как полноценный, готовый к production репозиторий, который можно клонировать и сразу писать продуктовую логику.

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

Как создать и подготовить пакет к публикации с помощью Poetry и обойти подводные камни которые могут помешать это сделать.

Заголовок: Как я написал локальный редактор IPTV-плейлистов на FastAPI + React 19 (и почему всё состояние хранится по именам)

Хабы: React, FastAPI, TypeScript, Tailwind CSS, Open source, IPTV, Python

Теги: m3u, m3u8, iptv, fastapi, react, hls, epg, drag-and-drop, self-hosted

Взял MacBook Pro M2 Max, 64GB, и задал простой вопрос: какой MLX-сервер реально готов держать Qwen 3.5 35B как локальный API для команды? Оказалось - серверов восемь, каждый в README обещает «blazing fast», а по факту между ними пропасть.

Написал харнесс на Python, прогнал пять итераций на восьми промтах - от AIME до 52k токенов. Single-user тройка идёт ноздря в ноздрю. Но стоит пустить два запроса параллельно - и четыре фреймворка из шести откатываются в очередь, один деградирует до 0.85×, и только один выдаёт честные 2.17×.

По дороге всплыли квадратичный attention в 2026 году, фантомные 14 000 tokens/sec из-за одной строчки в SSE-парсере и зомби-процесс на 20GB RAM, про который молчат все README. Внутри - графики, таблица «что выбрать под ваш сценарий» и репозиторий, чтобы повторить у себя.

В прошлой статье я разобрал почему Claude Code ломает проекты (context drift, отсутствие CLAUDE.md, нет хуков на тесты) и как выстроить защиту от регрессий. Статья попала в топ-5 Хабра за сутки — видимо, проблема задела нерв.

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

Я работаю с 20+ проектами на нескольких VPS-серверах. После того как я замерил, куда реально уходит контекст — картина оказалась неприятной.

В первой части мы развернули инфраструктуру на базе PostgreSQL и VectorChord, настроили базовые CRUD-операции и запустили гибридный поиск с реранкингом.

В этой части мы заменим игрушечные компоненты на локальные SOTA-модели, сохраняя оффлайн-архитектуру и отказываясь от облачных API. Пошагово развернём llama.cpp-сервер для мультиязычного эмбеддинга Jina v4, поднимем нативный реранкер через transformers + PyTorch, подключим чанкер на базе chonkie и, наконец, оценим качество поиска.

Привет Хабр! Меня зовут Владимир и сегодня я буду развивать тему фишечки VectorChord про которую упомянул в предыдущей статье.

В данном материале я покажу, как поднять инфраструктуру с VectorChord, настроить VechordRegistry, написать пайплайны работы с БД, организовать гибридный поиск и добавить простейший реранкинг.

Поехали.

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

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

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

Де-факто у меня получилась моментальная камера, которая печатает фотографии с помощью термопринтера — как чеки на контрольно-кассовых терминалах. Само собой, качество фотографий не такое высокое, как у самопроявляющейся пленки Polaroid. Но своё, гм, очарование у этого тоже есть.

Так вот.

Метрики могут «упасть» даже если вы ничего не меняли в модели.
Разбираемся, как распознать distribution shift и что с ним делать в продакшене.

При решении очередной задачи по небольшой "модификации" ПО- возникло решение запуска его под ВМ. По рукой уже стояла Oracle VirtualBox. Но вот незадача- ПО опознало виртуалку и отказалось выдать триал период. 2 промпта и 3 минуты на копирование и сборку решили проблему.

К тридцатилетию публикации проекта 1994 года, который остаётся самым скорострельным морфологическим анализатором.

Давным-давно, когда Рунет только появлялся, морфологические анализаторы и системы контроля орфографии уже производили вау-эффект: они не только сводили разные словоформы к основной (словарной), но и зачастую умели их склонять/спрягать, описывали грамматику вхождений и предлагали варианты замены ошибочных начертаний. Да и чуть позже, при появлении первого русского морфологического поиска в Интернет – это был Апорт! – на выставках тоже равнодушных не было. Тогда и родился libmorph.

Каждый день регистрируются сотни тысяч новых доменов, поэтому найти среди оставшихся что-то короткое, понятное и незанятое становится сложнее. Хороший домен — это узнаваемость и доверие пользователя. 

Привет, Хабр! Меня зовут Сергей. Я работаю инженером в Selectel, а в свободное время пишу пет-проекты для души. Недавно я прикинул: а что, если прямо сейчас мне понадобится запустить свой бренд или продукт? Первое, во что упираешься в таких раздумьях — это выбор домена. В этой статье я покажу небольшой проект, благодаря которому можно подбирать доменные имена не вручную, а автоматически с применением ИИ-агентов. Удобно или нет, решайте сами, подробности под катом.

Что будет, если столкнуть классический переборный алгоритм упаковки и «математику потока» на базе Numpy? Мы взяли реальный кейс на 398 предметов и проверили: можно ли за доли секунды найти решение, которое окажется дешевле и безопаснее ручного планирования.

Внутри — разбор «Бизнес-Ассемблера», борьба с весовыми лимитами и ответ на вопрос: почему при КПД 61% по объему контейнер может считаться идеально упакованным.

Писать сложные диалоги в Telegram-ботах — это боль из вложенных if-ов, сломанных переходов и бесконечного рефакторинга. В этой статье — как мы вынесли всю логику визардов в JSON и сделали движок, который сам управляет шагами, условиями и навигацией.

Без спагетти-кода. Без привязки к платформе. С возможностью собрать рабочего бота за вечер.

Это вторая часть обзора моделей для задачи синтеза речи (Text-to-Speech). В прошлой части я сравнил 7 Open Source моделей для этой задачи по нескольким критериям. В этот раз я решил посмотреть не только на Open Source-модели, но и на проприетарные TTS-решения.

Рассказываю, как на практике решать задачу NER. На примере извлечения сущностей из резюме пройдём путь от разметки данных до работающего API. Меньше теории, больше практики.

Привет, Хабр!

Каждый, кто работал с бухгалтерией, CRM или просто заводил контрагента вручную, знает эту боль. Вам присылают карточку компании в PDF, договор в DOCX или просто текстовый файл с реквизитами. Задача: достать оттуда ИНН, КПП, расчётный счёт и БИК, чтобы не схлопотать штраф за неверные данные.

Можно нанимать стажёра, который будет перепечатывать это в Excel. А можно довериться машине.

Мы в нашей компании долгое время решали эту проблему для своих внутренних задач (интеграция с 1С и автоматизация документооборота), а в итоге обкатали решение и выпилили в отдельный публичный сервис. Сегодня расскажу, как наш API извлечения реквизитов работает под капотом, покажу примеры кода на 6 языках (включая 1С, куда без него) и честно расскажу о таймаутах и подводных камнях.

Автор: Алексей Кравцов

Полтора месяца назад у меня было семь воркфлоу в n8n для новостного пайплайна. Каждый делал что-то своё. На бумаге красиво. На практике — постоянные затыки. Где-то новость застряла, непонятно где. Исправляешь одно — ломается другое.

Семь воркфлоу — семь точек отказа. И каждая ломается по-своему.

Сегодня та же задача решена иначе: 160 уникальных источников, 7127 записей в базе, 11 воркеров, 5 AI-агентов, локальная LLM на домашнем мини-ПК — и оркестратор, которому я просто пишу задачу в Telegram.

Без n8n. Без ручного управления. Почти без моего участия.

Вот как это вышло.

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

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