Python *

Я работаю дата-сайентистом 5 лет и до сих пор испытываю боль, когда нужно сделать MVP по временным рядам. Начиная с того, как построить несколько графиков одновременно без «слипшихся» меток по осям, заканчивая поиском подходящего метода очистки ряда от аномалий. И всё это венчает цикл по каждому ряду с бесконечным жонглированием данными между numpy, pandas, sklearn, yet_another_library.

Если вы DS, и тоже, как и я, устали от вот этого всего, добро пожаловать под кат. Я покажу, как написать production-ready код для прогноза 200+ временных рядов от EDA до результата. Разберем на практике, как бороться с аномалиями, ловить смены тренда и в итоге – получить масштабируемое решение, а не очередной «велосипед».

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

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

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

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

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

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 для его применения к LLM.

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

Меня зовут Анатолий Бобунов, я работаю SDET в компании EXANTE. Однажды я пришел на проект, на котором выполнение некоторых тест-сьютов занимало больше часа, настолько медленно, что запускать их на каждый merge request (MR) было просто нереально. Мы хотели запускать автотесты на каждый коммит в MR, но с такой скоростью это было невозможно. В результате мне удалось, за счёт серии небольших, но точных изменений добиться 8,5-кратного ускорения - без переписывания тестов с нуля. В статье расскажу, какие проблемы у нас возникли и как мы их решали.

В 2023 году, исследуя безопасность IoT устройств, я наткнулся на критическую уязвимость в одном из самых популярных брендов IP-камер в мире. Камеры v380 используются миллионами людей — в квартирах, офисах, магазинах, детских комнатах. Они доступны, просты в настройке и работают через удобное мобильное приложение.

Проблема оказалась банальной и пугающей одновременно: учетные данные пользователей передавались по сети в открытом виде. Любой, кто знал ID камеры, мог подключиться к незащищенному relay-серверу, перехватить логин и пароль владельца, получить полный доступ к видеопотоку и даже транслировать заранее записанное видео вместо live feed — как в классических фильмах про ограбления.

Эта статья — технический разбор уязвимости, детальный анализ кода эксплойта и история о том, как правильное раскрытие уязвимостей помогает делать IoT безопаснее.

Можно ли с помощью Python и математических метрик лучше понять поэзию? В этой статье я покажу, как с помощью кода можно количественно сравнить стили Александра Пушкина и Михаила Лермонтова.

Маршак хорошо переводил Шекспира, но насколько он был близок к оригиналу? Сохранен ли у него ритм, размер, смысл и структура? Установлю это математически точно с помощью Python.

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

Всем привет! Меня зовут Артём, и последние 6 месяцев я создавал полноценную веб-платформу для алготрейдинга. Около 95% кода было сгенерировано c использованием современных LLM, большая часть с помощью Gemini 2.5 Pro, ручные правки составили менее 5%

Речь о проекте Depth Sight. Это платформа с гибким визуальным конструктором торговых стратегий, бэктестингом, реальной/бумажной торговлей, мобильной pwa версией и нативно встроенным Ai ассистентом для помощи в создании и объяснении торговых стратегий, а также анализа результатов бэктестов. Эта статья не столько об алготрейдинге, сколько о новом подходе к созданию сложных программных продуктов. Это кейс о том, как человек с видением продукта может в одиночку создать платформу промышленного уровня. Или нет? Предлагаю разобраться вместе.

Вы научились получать и обрабатывать данные. Но что дальше? Как хранить эту информацию надежно, а не в CSV-файлах? Как поделиться результатами своей работы с другими, предоставив им удобный доступ через API? Что делать, если сайт настолько сложен, что Requests не может справиться с его динамическим контентом? И как убедиться, что весь написанный вами код не сломается после очередного изменения?

Чем популярнее становится FastAPI, тем сильнее критикуют Django. И не просто критикуют. Брезгуют? Пренебрегают? Всего понемножку. Всё чаще слышу, что Django — пережиток прошлого. Любой проект на Django — устаревший мусор. Любой «джанговод» — просто не знает, что тоже устарел. Объективно ли это? Нет, не объективно. Если отвёртка плохо забивает гвозди, это не значит, что отвёртки устарели — просто это не их задача.

Всё началось с подготовки к финалу RuCode – масштабному соревнованию для всех увлечённых алгоритмическим программированием. Погружаясь в разбор заданий прошлых лет, мне кое-что совершенно случайно попало в руки, интересная задача: реализовать шахматы с "туманом войны" в консоли

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

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

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

Привет, Хабр! Если вы работаете с Python дольше пары недель, вы наверняка сталкивались с конструкцией, начинающейся с символа @. Это декораторы — мощный инструмент, который делает код чище, читабельнее и соответствует принципу DRY (Don't Repeat Yourself). Но за элегантным синтаксисом скрывается несколько ключевых концепций языка, которые важно понимать.

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

Я решил подойти к этой задаче как инженер и создать личного ассистента, который бы делал всю грязную работу за меня: 24/7 сканировал Avito, сам оценивал адекватность цены и присылал мне в Telegram только самые сливки.

Так родилась идея проекта Intelligent Deal Finder. В этой статье я познакомлю вас со своим проектом, который решает эту задачу. Эта статья будет ознакомительной.

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

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

Инструмент эксперимента — модель distilbert‑base‑uncased с Hugging Face и это облегчённая, быстрая версия BERT для понимания языка. Мне показалось это практичным выбором для прототипа — позволяет быстро проверять разные способы текстовой разметки без гигантских ресурсов. Цель была чёткая: по текстовому описанию недавней истории торгов предсказать рост цены на следующий день.

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

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

А ещё весь код уже на GitHub.

Всем привет!

Недавно мы с приятелем обсуждали, как устроены рабочие процессы в бигтех-компаниях и какую роль в них уже играет ИИ. Речь в основном шла о зарубежных компаниях — у него там есть знакомые, которые делились опытом изнутри. Один из самых любопытных моментов — использование искусственного интеллекта для предварительного код-ревью в Pull Request: прежде чем коллеги возьмутся проверять изменения, PR уже анализирует ИИ и указывает на потенциальные проблемы.

Эта идея меня зацепила, и я решил изучить, какие готовые решения уже существуют (кроме встроенного в GitHub Copilot). Из более-менее крупных нашёл только PR Agent. Я протестировал его, но по ряду причин он мне не подошёл: хотелось больше гибкости, настройки под свои нужды и возможности запускать всё самостоятельно, без передачи кода сторонним сервисам.

Так родился проект ReVu — self-hosted инструмент для автоматического код-ревью в Pull Request с помощью ИИ. Он универсален, легко кастомизируется и не требует доверять исходный код внешним платформам.

Если вам интересны подобные материалы и проекты, подписывайтесь на Telegram-канал «Код на салфетке» — там я делюсь гайдами для новичков, историями разработки и полезными инструментами.

2 октября 2025 года компания Neuphonic представила NeuTTS Air - открытую модель преобразования текста в речь, которая кардинально меняет подход к синтезу голоса. Главная особенность в том, что она работает полностью локально на обычных устройствах без необходимости подключения к интернету или облачным сервисам.

Привет, хабровчане!

Признаюсь, я не большой любитель vLLM, Triton Inference Server и всяких там NeMo, вместо них я предпочитаю ollama вообще и llama.cpp в частности, поскольку придерживаюсь мнения, что 1-2% потери в точности и отсутствие некоторых плюшек - не так важно, по сравнению с удобством деплоя, спекулятивным декодингом, многократным приростом скорости, динамическим оффлодом в память системы и возможностью запускать модели на любом "ведре", навроде древних зионов, андройдофонов, малинок или, скажем, макбуков.

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

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