Python *

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

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

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

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

Привет! Меня зовут Денис. Уже юолее 5 лет работаю Senior Product Analyst в крупнейших IT-компаниях России, включая Тинькофф. Разрабатывал системы аналитики с полного нуля, провёл огромное количество A/B тестов и знаю всю внутреннюю кухню больших корпораций изнутри.

Я совершил множество ошибок на своём пути – и теперь здесь, чтобы помочь именно тебе их избежать и пройти этот путь быстрее!

A/B-тесты давно стали стандартным инструментом в продуктовой и маркетинговой аналитике. Но на практике большинство ошибок происходит не на этапе запуска эксперимента, а при анализе результатов. Чаще всего причина в том, что статистический метод выбирается «по привычке», без учёта типа метрики и свойств данных.

В этой статье я собрал практическую логику выбора методов анализа A/B-тестов. Без углубления в теорию, но с пониманием, почему в одном случае работает χ², а в другом t-test может привести к неверным выводам.

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

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

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

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

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

В первой части мы написали базовый поиск gRNA с фильтрацией по GC-составу. Работает, но тупо: все кандидаты в диапазоне 40-60% считаются равнозначными. В реальности это не так.
Сегодня добавим систему скоринга — будем ранжировать gRNA по качеству, учитывая позицию нуклеотидов и особенности U6-промотора. Потом подключим NCBI BLAST, чтобы проверять кандидатов на off-target: не порежет ли Cas9 что-нибудь лишнее в геноме.
Тестировать будем на гене CCR5 — том самом, который отредактировал китайский учёный Хэ Цзянькуй в скандальном эксперименте 2018 года.

Отдел планово-экономический тратил 6 часов каждый месяц на поиск ошибок в ценах МПЗ. Вручную проверяли 500 позиций из 16,000, пропуская критичные аномалии. Я автоматизировал процесс через связку SQL + MCP + Claude AI. Теперь система за 15 минут находит все отклонения, выявляет паттерны мошенничества (дробление закупок, откаты) и даёт план действий с оценкой ROI. Первый запуск выявил потенциал экономии 650K — 1.6M руб/год. Под капотом — техническая реализация с кодом, SQL‑запросами и примерами AI‑анализа.

Это Docker-шаблон для Python + Poetry, рассчитанный на реальную работу, а не учебные примеры: воспроизводимое окружение, удобный dev-workflow, отдельные сборки под прод, dev, Jupyter и AI-инструменты.

Автор использует его в основном для DS/ML-задач, где важнее скорость и предсказуемость, чем экономия пары мегабайт образа. Шаблон обкатан в бою, экономит время и легко кастомизируется под свои нужды.

👉 Репозиторий на GitHub:
https://github.com/jamm1985/vim-python-docker-template

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

Docker помогает изолировать окружение, но сам по себе он не решает Python-специфичные задачи. Его нужно правильно наполнить: учесть работу Poetry, кеширование зависимостей, структуру проекта и базовые практики, которые одинаково хорошо работают и в разработке, и в продакшене. Именно такой шаблон мы и будем собирать дальше.

В этой статье мы шаг за шагом соберём базовый Docker-шаблон для Python с Poetry, который удобно использовать и для разработки, и для прода. В основе будет минимальное и воспроизводимое окружение, а всё остальное - Vim как IDE, Jupyter, AI-инструменты вроде Codex или Gemini - вынесено в отдельные образы и слои, которые можно подключать по мере необходимости. Начнём с самого главного - разберём Dockerfile и поймём, как собрать прочную и расширяемую базу для Python-проекта.

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

Несколько лет назад я наткнулся на статью про CRISPR‑Cas9 и домашние биолаборатории — люди буквально у себя дома экспериментировали с редактированием генов. Я бэкенд‑разработчик, биологию последний раз открывал в школе, но желание разобраться никуда не делось. В этой статье разберёмся, как работает CRISPR на минимальном уровне, и напишем CLI‑утилиту на Python для поиска потенциальных guide RNA — «наводчиков» для молекулярных ножниц Cas9.

Рассмотрим две проблемы при изучении иностранного языка. Это освоение грамматики и увеличение словарного запаса. Они не единственные, но важные. Про способы погружения в грамматику, на языке оригинала, можно прочитать в моей статье: «Уроки французского и пересоздание данных для изучения иностранного языка с помощью обучающей программы «L'école»», в https://habr.com/ru/articles/972594/ .

Там идея простая. Мы берем хороший учебник на языке оригинала, разбиваем текст на короткие смысловые фразы, снабжаем их фонетическим слогоделением и буквальным контекстным переводом (БКП). Затем, озвучиваем данные, например, с помощью TTS, для, в данном случае, обучающей программы «L'école» и создаем двуязычные html-тексты с транскрипцией (фонетическим слогоделение) или, другими словами, небольшую книгу в формате html.

Идея изучения грамматики основана на двух принципах:

– Мы читаем, громко, вслух фонетическую транскрипцию (предварительно осваиваем фонетический алфавит с помощью представленных уроков) и смотрим подстрочный перевод. Это для html-книг. А при работе в обучающей программе, мы можем, при желании, еще набирать текст руками (используя метод «запоминание руками», в режиме «Конспект»), слушать и проговаривать вслед интерактивную озвучку. При этом, не обязательно даже стремиться запоминать текст, при наборе его руками и повторении озвученной речи, уроки запоминаются «сами собой», особенно, если к ним периодически возвращаться.

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

Автоматизированное тестирование API часто начинается с простых решений в виде коллекций Postman или скриптов на коленке. Такой подход работает на старте, но быстро исчерпывает себя.

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

Статья поделена на три части.

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

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

Универсальный автогенератор тестов API на базе Schemathesis

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

Цель этой статьи — максимально подробно и практично разобрать реальный Python‑проект автоматического трейдинга. Это рабочий бот, который непрерывно анализирует рынок Binance Futures, ищет сигналы по открытому интересу (Open Interest), применяет набор защитных фильтров, работает с множеством пользователей одновременно, управляется через Telegram‑интерфейс, и при необходимости открывает реальные сделки через API биржи BingX.

Я последовательно разберу всю логику и все функции основного файла main.py, объясняя, как и зачем они реализованы именно так.

«Почему моя функция "помнит" данные из прошлого вызова?» — этот вопрос задает почти каждый, кто начинает глубоко изучать 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 с подробными пояснениями для начинающих питонистов, которых нет у автора.

Всем привет! В этой статье я собрал практические фишки работы с Telegram Mini App: что здесь реально проще, чем в обычном вебе, какие возможности Telegram дает из коробки, и что чаще всего вызывает затруднения при разработке.

Информационный хаос в геопространственной сфере

Задумывались ли вы, как в эпоху, когда мы можем мгновенно найти любую информацию в интернете, поиск спутникового снимка конкретного поля, леса или города за определённую дату до сих пор напоминает квест? Всего несколько лет назад мир геопространственных данных представлял собой хаотичный ландшафт изолированных архивов, каждый со своим уникальным форматом данных, структурой папок, проприетарным API и системой метаданных. Чтобы проанализировать один и тот же регион по данным разных спутников, учёным и инженерам приходилось тратить до 80% времени не на сам анализ, а на «добычу» и приведение данных к единому виду. Эта проблема интероперабельности (совместимости) была главным тормозом для развития целых направлений: от оперативного мониторинга чрезвычайных ситуаций до долгосрочного изучения климата.

Именно из этой «боли» родилась идея SpatioTemporal Asset Catalog (STAC) — Каталога пространственно‑временных активов. Изначально это была не инициатива госорганов или крупных корпораций, а практический ответ сообщества разработчиков и аналитиков на ежедневные сложности.

Материал будет интересен молодым специалистам в области ДЗЗ — будущим геоинформатикам, экологам, data scientist'ам. Знакомство с STAC перестаёт быть опциональным, это становится базовой цифровой грамотностью в области геоинформатики и наук о Земле, таким же необходимым инструментом, как, например, умение работать с SQL для backend‑разработчика. Это язык, на котором будет говорить «цифровая копия» нашей планеты, и те, кто освоит его первыми, получат ключ к решению самых амбициозных задач XXI века.

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

А в начале я не планировал становиться разработчиком макропада.

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

Однако, когда дело касается локального запуска, думаю, далеко немногие из нас запускают модели в BF16 через vLLM на Nvidia H100. А значит, все эти красивые результаты по бенчмаркам на практике, вероятнее всего, очень далеки от того, что мы получим на практике.

И я решил это проверить.