Python *

В конце статьи Python скрипт для сохранения заметок.

Последняя шлюпка с «Титаника», чтобы утащить с ЖЖ свои и чужие мысли на жесткий диск, пока «эффективные менеджеры» окончательно не пустили всё на дно.

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

Декабрьские конвульсии администрации — введение сегрегации пользователей, разделение на касты и монетизация каждого вздоха — стали последней каплей. Это больше не дом, это режимный объект с пропусками. Я принял решение об уходе, забирая с собой всё, что нажил непосильной графоманией.

После 10 лет внедрения BI-систем (Qlik Sense, Power BI, Data Lens) я понял одну вещь: дашборд — это не решение. Это данные для решения. А между данными и решением — пропасть, которую преодолевает человек.

В этой статье покажу, как построил RAG-систему с чат-интерфейсом для базы из 600 000 записей техники из Федресурса. Без философии — только архитектура, код и грабли.

Matplotlib — это мощно, но часто «многословно». Чтобы превратить стандартный график в нечто презентабельное, приходится писать десятки строк настройки осей и легенд.
В этой статье я собрал практическую шпаргалку (Cookbook) по библиотеке Seaborn. Разберем, как одной строкой строить красивые Heatmap, Boxplot и Pairplot. Минимум теории, максимум готовых рецептов (copy-paste), которые покроют 90% задач аналитика.

Как сделать надёжную очередь задач без Rabbit/Kafka, используя только Postgres? Разбираю боевой паттерн: FOR NO KEY UPDATE SKIP LOCKED для конкурентного забора, lease/heartbeat для возврата задач после падений и backpressure, чтобы воркеры не съели память.

Ещё раз о ЦП для машинного обучения в эпоху дефицита мощностей GPU

Недавние успехи в области ИИ зачастую связывают с появлением и эволюцией графических процессоров (GPU). Архитектура GPU, как правило, включает тысячи ядер для многопроцессорной обработки, высокоскоростную память, выделенные тензорные ядра и пр. Такая архитектура особенно хорошо подходит для рабочих нагрузок, связанных с ИИ и машинным обучением, которые отличаются высоким потреблением ресурсов. К сожалению, из-за резкого роста разработок в области ИИ также наблюдается всплеск потребности в  GPU, из-за чего возник их дефицит. В результате разработчики систем машинного обучения всё активнее изыскивают альтернативные аппаратные платформы, на которых можно было бы обучать и эксплуатировать модели. В таком качестве используются, например, выделенные специализированные интегральные схемы (ASIC) для работы с искусственным интеллектом, такие как облачные тензорные процессоры Google, Haban Gaudi и AWS Trainium. Притом, что эти варианты позволяют значительно сэкономить, они подходят для работы не со всеми моделями машинного обучения и, подобно GPU, также остаются дефицитными. В этом посте мы вновь обратимся к старым добрым классическим процессорам (CPU) и вновь поговорим о том, насколько они адекватны применительно к современным ML-моделям. Безусловно, ЦП обычно не так хороши для обслуживания связанных с машинным обучением рабочих нагрузок как графические процессоры, зато их гораздо проще приобрести. Если бы удалось гонять на ЦП (хотя бы некоторые) из таких рабочих нагрузок, то продуктивность разработки в целом удалось бы значительно повысить.

Реляционная модель обычно ассоциируется с аккуратными строками и столбцами, но на практике ей регулярно пытаются скормить то, для чего она будто бы не предназначена. В этой статье — эксперимент на грани здравого смысла: разложить фильм на пиксели, превратить кадры в строки и посмотреть, что получится, если к видео применить привычный SQL. Без обещаний пользы и универсальности — зато с честным разбором того, где такой подход неожиданно работает, а где начинает сопротивляться сама природа данных.

С инженерной точки зрения поиск работы — это процесс с низкой энтропией. Есть входящий поток данных (JSON с вакансиями) и есть необходимость отправить ответный сигнал (POST-запрос с откликом). Задача кажется тривиальной для автоматизации: написал парсер, настроил cron, пошел пить кофе.

Однако, если вы попробуете автоматизировать отклики на крупных job-board платформах (особенно на hh.ru) в 2026 году, вы столкнетесь с серьезным противодействием. WAF (Web Application Firewall), анализ TLS-отпечатков, поведенческая биометрия и теневые баны — это реальность, которая убивает скрипты на requests за пару часов.

В этой статье разберем архитектуру решения, которое позволяет автоматизировать процесс отклика, используя подходы RPA (Robotic Process Automation), мимикрию под поведение пользователя (Human Mimicry) и LLM для обхода смысловых фильтров.

(Дисклеймер: Статья носит исследовательский характер. Мы не призываем нарушать правила площадок, а разбираем технические методы эмуляции браузера).

Привет, Хабр! Когда начинаешь новый проект на FastAPI, всё кажется простым: пара моделей Pydantic, несколько эндпоинтов — и готово. Но через полгода и 20 000 строк кода оказывается, что базовая валидация размазана по всему приложению, бизнес-логика перемешана с обращениями к БД, а тесты пишутся со скрипом.

Сегодня я хочу поделиться конкретными архитектурными паттернами и приёмами, которые я неоднократно использовал в своих проектах. Они не усложняют простые задачи, но делают жизнь в долгосрочной перспективе несоизмеримо легче.

Каждый раз, когда мы пишем «быстрый скрипт на коленке», мы тратим время на одни и те же вещи: настройку логов, парсинг конфигов и создание прогресс-баров. В этой статье разберем 10 легковесных утилит (от tqdm до beartype), которые закроют рутинные задачи и позволят вам сфокусироваться на логике, а не на «обвязке».

Home Assistant позиционирует себя как локальную систему. Но я столкнулся с ситуацией, когда локальная функция (Samba) не работает из-за облачного сбоя. При этом я вообще не использую облако. В статье описываю как обошёл эту проблему за 5 минут, когда за день разобрался в причине.

Мне очень нравится Home Assistant как система управления умным домом, потому что она позволяет не зависеть от облаков и от падений интернета. Это не просто слова - с 2017 года я использую умный дом в обычной двухкомнатной хрущевке, и в основном всё работает. Но это скорее тестовый полигон для меня - я сам там не живу и поэтому очень ценю то что Home Assistant можно настроить один раз и если не обновлять, то несколько лет всё может спокойно проработать. А на этих новогодних каникулах у меня было время и я решил полностью обновить все дополнения и прошивки. Как оказалось зря - паранойя безопасности ломает определение Home Assistant как автономного сервиса, который можно использовать локально.

Одним солнечным днём мне прилетела задача - написать асинхронный механизм выгрузки данных по API.

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

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

В финале прихожу к решению, которое в итоге оказалось стабильным и продакшн-реди.

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

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

В классическом варианте мы собираем весь датасет целиком, делим на обучающую и тестовую выборки, обучаем модель, измеряем качество — и внедряем в прод. Здорово, если данных немного и они разом доступны. А если данные льются непрерывно?

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

Динамическая типизация — это весело, пока ваш проект не вырастает до 100к строк и вы не начинаете ловить AttributeError: 'NoneType' object has no attribute 'get' в три часа ночи. В 2026 году аннотации типов в Python — это уже не «бюрократия», а вопрос выживания и адекватного рефакторинга.

Списки (list) и словари (dict) — это фундамент Python, но часто мы заставляем их делать работу, для которой они не предназначены. Если вы до сих пор пишете if key not in d: d[key] = [], используете list.pop(0) на больших данных или пытаетесь запомнить, что в вашем кортеже лежит под индексом [3], — эта статья для вас.

«Почему моя функция "помнит" данные из прошлого вызова?» — этот вопрос задает почти каждый, кто начинает глубоко изучать Python. На первый взгляд, пустой список в аргументах кажется логичным дефолтом, но на практике он превращается в мину замедленного действия. В этой статье мы разберем механику работы атрибута defaults, поймем разницу между временем определения и выполнения, и выясним, почему None — это не просто отсутствие значения, а спасение вашего кода от непредсказуемых багов.

quad_rag_core — лёгкое Python-ядро для локального RAG, которое автоматически отслеживает изменения в папках, индексирует их в Qdrant и поддерживает эмбеддинги в актуальном состоянии. Изначально проект задумывался как инструмент MCP (Model Context Protocol), но стал основой для любой системы локального семантического поиска.

Зачем это нужно

В процессе работы с кодовой базой через LLM-агентов и при необходимости локального семантического поиска по файлам проекта обнаружилась проблема. Инструменты агентской разработки вроде Kilo Code предоставляют встроенную функцию семантического поиска, но в компании заявляют, что в будущем эта функциональность может стать платной. Сразу задумался о том чтобы сделать свою подсистему поиска. Простые запросы к MCP-серверу на поиск и обновление тут не подойдут - система поиска должна иметь полный контроль над контекстом - она должна автоматически узнавать, что файл удалён, функция изменена или добавлен новый документ, без необходимости перезапуска индексации.

От идеи к архитектуре

В начале планировался простой MCP-сервер, который принимает команды поиска и обновления, индексирует текстовые файлы и PDF, использует Qdrant как векторное хранилище и эмбеддит локально.

В ходе проектирования стало понятно: вся логика отслеживания файлов, парсинга, чанкинга и синхронизации с Qdrant — это переиспользуемое ядро, а не часть MCP-протокола.

Так появился quad_rag_core — отдельный Python-модуль, который не знает ничего про MCP или другие внешние интерфейсы, но готов к ним подключаться.

Есть числа, которые полезно знать программистам на Python. Насколько быстро добавляется элемент в список? Как насчет открытия файла? Это занимает меньше миллисекунды? Если ваш алгоритм зависит от производительности, какую структуру данных вы должны использовать? Сколько памяти занимает число с плавающей запятой, один символ или пустая строка? Насколько быстр FastAPI по сравнению с Django?

Это перевод недавней работы Michael Kennedy с подробными пояснениями для начинающих питонистов, которых нет у автора.

Изначально я хотел написать статью про коды Рида-Соломона с иллюстрацией на примере работы QR кодов, в процессе подготовки сделал инструмент для визуализации промежуточных этапов построения QR кодов и обнаружил что у меня уже есть достаточно отсутствующего на хабре материала, в связи с чем немного поменял план. Кому не интересно читать, QR с КДПВ сгенерированы с помощью qr-verbose

pip install qr-verbose

Документация (англ.)

Про QR коды на хабре писали много, например одна из самых популярных статей за всё время "Читаем QR код" и куча переводных статей. К сожалению у этих статей есть кое-что общее: если вы попытаетесь прочитать код версии 4 и больше а также некоторые коды версии 3 следуя описанию из статей, то потерпите фиаско. Не верите? Попробуйте прочитать нижний код с КДПВ.

В статье напомню как устроен QR код и какие проблемы начинаются с версии 3, а также надеюсь, что qr-verbose поможет разобраться тем, кто еще не разобрался.

Сервисы — место, где живет бизнес-логика

Здравствуйте! Идея написать эту статью пришла мне в голову абсолютно спонтанно. Я работаю в компании и, так сложилось, что нас имеет мы имеем DRF монолит на писят два миллиона строк кода. И вот однажды, чью-то светлую голову посетила мысль — «а давайте писать код одинаково». Идея прозвучала чертвоски просто и соблазнительно. С этого момента мы завели себе ишака по имени «Django Service Layer», и все дружно начали на него наваливать. Теперь навалю и вам. Би-бу-бип.

Всем привет! Меня зовут Артем, я Data Scientist компании RAFT. Сегодня я расскажу об своем pet проекте по объяснению правил для настольных игр. Цель данного проекта — понять, как можно собрать RAG агента без использования больших библиотек.