Алгоритмический трейдинг давно превратился в новую форму цифровой мечты. Сегодня буквально каждый второй новичок уверен, что достаточно найти «правильный» индикатор, запустить Python-скрипт, подключить API биржи - и рынок начнёт стабильно печатать деньги.

Реальный рынок уничтожает такие системы с пугающей регулярностью.

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

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

Друзья, привет! Возвращаюсь с продолжением.

В первой части мы разобрались, как поднять локальную LLM и пробросить к ней внешний доступ. Но до настоящей интеграции в продукт так и не добрались — модель работает, а что с ней делать дальше, непонятно. Сегодня исправляем это.

Поговорим про графовую инфраструктуру на базе локальных моделей — и не только локальных. Любых, поддерживающих OpenAI-совместимый протокол.

А теперь вопрос: что, если вам достаточно хорошо научиться писать граф — и вокруг него автоматически поднимется REST API, появится интерфейс для тестирования, трейсинг и мониторинг?

У меня на полке стоит NanoPi Fire3 — старинный SBC с Linux на борту. С течением времени он неизбежно обрастает периферией разной степени бесполезности. Среди прочего, конечно же, в нем прописался экранчик LCD2004 (даже два) со светодиодной подсветкой, который освещал ночную квартиру, как прожектор.

С одной стороны — удобно ходить в туалет, не включая свет, с другой — захотелось гламура, как в мобилке, чтобы, чем меньше вокруг света, тем тусклее была бы подсветка. Для этой цели нужно этот свет как‑то измерять, так что ассортимент периферии было решено расширить датчиком освещенности VEML7700. О том, как я приспосабливал его к делу, и пойдет речь далее.

С нашего последнего разговора прошло пять недель. Вы, дорогой читатель, наверняка подумали, что ваш покорный слуга всё это время бездельничал. Но это не так.Сразу после публикации прошлой статьи ко мне обратился подписчик по имени Сергей. Он занимается лазерной резкой металла и после прочтения материала решил, что я смогу проапгрейдить его алгоритмы расчёта. Очевидно, после прочтения моих статей вы уже поняли: как охотничий пёс при виде зайца не может остановиться, так и я при виде интересной задачи просто не могу пройти мимо. Получив задачу, я вник в суть и сделал то, что мы с вами так любим, — полноценный веб-сервис. Написан он в лучших традициях хакерского стиля: с динамическим обновлением и, конечно же, «заряженным» движком под капотом.

Я начал с requests.get() к Hysteria2 API, а через месяц получил рабочий VPN-сервис: FastAPI, React, PostgreSQL, JWT, Docker Compose, несколько VPS-нод, сбор трафика и автодеплой. А ещё выводы о работе с ИИ: где он ускоряет разработку, как улучшить качество кода и почему без собственного понимания проект быстро превращается в месиво.

Логическим продолжением будет изучение (не побоюсь этого слова) сердца машинного обучения: градиентного спуска.

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

Дано: государственная аттестация, бумажные бланки, никакого онлайн-контроля. Классический способ фальсификации: ученик начинает работу сам, потом часть дописывает кто-то другой: сосед, нанятый человек, преподаватель. Проверяющий смотрит на текст, но не оценивает почерк.

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

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

⚡ Архитектура монорепозитория для параллельного исполнения торговых стратегий

Статья описывает архитектуру эмулятора биржи. Эмулятор ускоряет время в 6300x раз и запускает такую же торговую стратегию как в prod без изменений. В статье описаны практики структурирования кодовой базы для командной работы

B-Tree O(log n) , memcache lookupO(1), монорепозиторий, SRP, линейное расширение кодовой базы при модернизации

Добрый день, коллеги!

Разрабатывали очередной аутсорсный заказ и в процессе разработки поняли с командой, что это может быть довольно интересным универсальным продуктом. В статье (без подробностей) расскажу, что изначально делали и что получили в итоге.

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

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

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

Django, пожалуй, самый популярный фреймворк для разработки на Python. Да простят меня «питонисты» и «джависты», если я рискну сравнить важность этого фреймворка для Python c важностью Spring для Java.

Если вы, смотря 16 задание, закрываете сайт, на котором готовитесь к ОГЭ по информатике, вам стоит прочитать эту статью. Кстати, вам будет полезно, даже если вы хотите структурировать свои знания. Чтобы понять эту статью, вы должны знать: циклы while и for, условные операторы if, elif, else, базовые команды, базовая работа с переменными и типами данных на Python.

Спойлер: это было наивно. Но путь оказался ценнее результата.

Вы собрали RAG-пайплайн: загрузили документы, нарезали на чанки, сгенерировали эмбеддинги, подключили векторную базу. Задаёте вопрос — модель отвечает уверенно и подробно. Показываете заказчику, тот в восторге. Потом начинается тестирование на реальных вопросах, и оказывается, что на половину из них система отвечает мимо: то находит не тот документ, то находит правильный, но не тот кусок, то вообще ничего релевантного не достаёт и модель уверенно галлюцинирует.

Каждый раз проблема не в модели (GPT-4 и Claude отвечают хорошо, если им дать правильный контекст), а в retrieval — в том, как мы ищем релевантные куски документов. Модель отвечает ровно настолько хорошо, насколько хорош контекст, который ей подсунули.

Рассмотрим три основные причины.

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

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

В этой статье разберём, как автоматизировать исходящие звонки. Клиенту, получившему услугу,  звонит голосовой робот и проводит короткое анкетирование. Результаты опроса сразу попадают в рабочую таблицу, а если клиент остался недоволен, управляющий дополнительно получает СМС и может быстрее разобраться в ситуации.

Стек решения: Python 3.10+, Flask, requests, python-dotenv, SQLite, YCLIENTS API, голосовой робот и SMS API МТС Exolve, MWS Tables.

При проведении пуско‑наладочных работ на объекте Инженерам часто приходится иметь дело с «солянкой» различного оборудования на линиях RS-485, передающих данные по Modbus RTU на «средний», или «верхний» (в BMS\SCADA) уровни.

Написали программу, которая умеет искать Modbus RTU устройства по COM‑порту, а так же через преобразователи интерфейсов с протоколами Modbus RTU over TCP и Modbus TCP. Прописали IP адрес и порт шлюза, выбрали протокол и готово.

Месяц назад мне в личку прислали фишинговую ссылку под MAX. Разобрал её, попутно вынес устройство протокола: опкоды, формат фрейма, флаги push-подписки, антибот-эвристики. Через две недели применил это знание к мирной задаче: собрал в том же мессенджере своего AI-секретаря, который пишет первым коллегам, бронирует столики и ведёт переписки до результата.

Всё через User API без регистрации, MCP-сервер на семь тулов, рабочий репозиторий с граблями. Делюсь инструкцией.

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

Для разработчика генерация музыки — это отличная практическая задача. Работать с сырым аудио (waveform) вычислительно тяжело и требует сложных архитектур, но при использовании формата MIDI задача сводится к обработке последовательностей. Это делает процесс похожим на работу с текстом в NLP: мы берем дискретные токены (ноты, аккорды, паузы), находим между ними связи и предсказываем следующие шаги. Главный плюс — результат обучения модели можно в буквальном смысле услышать.

Цель этой статьи — построить с нуля простую и понятную рекуррентную нейросеть на базе архитектуры LSTM. Мы разберем полный цикл: загрузим сырые данные, подготовим их для обучения, напишем нейросеть, которая научится улавливать закономерности в мелодиях, и заставим ее сгенерировать новую нотную последовательность.

Наш стек технологий:

Мой знакомый Николай держит на Ozon магазин постельного белья. Со стороны всё нормально: оборот есть, товар продаётся, кабинет не пустует. А денег в конце месяца — нет. Не «мало», а непонятно куда они делись.

Я стал разбираться — и понял, что это не его частная беда. Полный P&L по каждому товару никто не считает: на каталоге в 500–2000 позиций это часы в неделю. Товар крутится в топе по обороту — но оборот ничего не говорит о марже: после возвратов и рекламы он годами уходит в минус, в полной слепой зоне. Инструментов на рынке хватает, но почти все просто показывают ещё одну P&L-таблицу — много цифр, красиво, и ровно ноль ответа на вопрос «и что мне теперь с этим делать».

Так появился SKUmind — сервис, который сводит прибыль по каждому SKU и говорит, что с ней делать. Под катом — почему я выкинул привычную для BI логику на правилах, как собрал консилиум из трёх AI-моделей разных вендоров с арбитратором, как реверс-инжинирил Ozon API двумя параллельными сессиями Claude и почему ревью кода теперь съедает 60–70% времени.

Всем привет!

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

В конце статьи я оставлю ссылку на свой DEV-блог, если захотите узнать больше о соло-разработке SaaS продуктов.

Первым делом давайте разберём пару интересных замечаний с прошлой публикации и проработаем их. Если что, версия шаблона, которую мы улучшаем в гите в коммите 55505089d7fee07e1579839b2983b7c8f4227d7c.

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

ИИ может торговать на бирже в плюс — и мы это проверили в ходе эксперимента на 6 моделях. Разбираем автономного ИИ-трейдера по косточкам — архитектура, инструменты, результаты запусков и готовый код. Запустите своего агента торговать на виртуальный капитал 3 млн рублей на «Финам Арене» уже сегодня — лучшим денежные призы.

Настройка CI/CD часто кажется новичкам чем-то сложным и доступным только DevOps-инженерам. На самом деле автоматизировать рутину Python-проекта можно всего за полчаса. В этой статье мы по шагам разберем, как с нуля настроить GitHub Actions для простого FastAPI-приложения: от автоматического запуска тестов и быстрого линтера Ruff до сборки Docker-образа и публикации его в Docker Hub.

В этой статье я покажу как собрал на Python Telegram-бота, который превращает 15-30 минут работы в ворде (борьбой с выравниваниями, шрифтами, отступами и пр.) в 5-минутный диалог. Никаких сложных CRM, никаких конструкторов с долгим обучением. Только async, последовательное управление состояниями, регулярные выражения и генерация готовых Word-файлов.

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

Базовые LLM проходят отдельное safety-training и RLHF-выравнивание. Но production-бот, построенный поверх модели, добавляет новый attack surface: system prompts, память диалога, RAG, tools, webhook-логику и внешние API. Именно этот orchestration layer часто становится слабым местом. Вот данные:

Из анализа 14 904 кастомных GPT:

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

Очевидно, мнения могут быть разными, поэтому поделюсь кейсами, которые наблюдал лично:

1. В компании Х у нас было 4 человека, которые ещё до эпохи ChatGPT с нуля за несколько месяцев собрали полноценный AI-стек:
— fine-tune собственных LLM на своих датасетах
— свой TTS/STT на своих датасетах
— генерацию лиц и deepfake
— MLOps-инфраструктуру и пайплайны

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

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

2. Теперь компания Y: AI-продукт уровня "обёртка над ChatGPT" команда из 15 человек уровня джун-миддл запускала около года. Потом ещё полгода доводила до нормального качества.

Сравним экономику:

Вариант 1:
4 senior’а х $8k х 4 месяца
≈ $128k до запуска

Вариант 2:
15 человек x $3k x 15 месяцев
≈ $675k до конкурентного качества продукта

Разница бюджета в 5 раз, разница в скорости запуска в 4 раза в пользу сеньёров.

Маленькая сильная команда:
— вышла на рынок быстрее
— строила собственные технологии
— накапливала engineering leverage
— могла быстро pivot’иться при необходимости

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

Какие выводы:

1. Лично я верю в сеньёров и быстрые запуски. Причём раньше 1 сильный инженер мог заменить 2–3 средних, а сейчас с помощью ИИ вполне может дать ещё больший эффект.

2. Больше людей не значит быстрее. Скорее наоборот: выше уровень сотрудников — выше скорость принятия решений и разработки — выше ROI — больше пространства для инноваций и поиска точек роста бизнеса.

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

Если не согласны — с удовольствием подискутирую.

Привет, Хабр! (И тебе, HR, который ставит в вакансию «Python, SQL, Linux, Docker, K8s, Spark, Airflow, английский C1, опыт 1-3 года, зарплата 40-60К». Особенно тебе.)

Сегодня будем препарировать рынок Python-разработки в России. По-настоящему. С графиками, цифрами и верой в светлое будущее.

Здесь будет всё, зарплаты, актуальные стеки и то что уже никому не нужно, прогнозы, тренды, и многое другое, будет интересно...

Поехали.

Календарь, задачи, заметки, почта. Мы используем десятки инструментов, но они не умеют жить вместе. Данные размазаны по сервисам. Команда в Битрикс24, семья в WhatsApp, клуб в Google Calendar. Везде свой интерфейс, свои правила, своя изоляция.

Все мы начинали писать на Python примерно одинаково: создавали пустой список, запускали цикл for, проверяли условие через if и делали .append(). Это надежно, предсказуемо, но по мере роста кодовой базы такие конструкции начинают утомлять — мы тратим 4-5 строк на банальную трансформацию данных, которую можно уложить в одну лаконичную строку.

В этой статье мы подробно разберем встроенный инструментарий Python для работы с итерируемыми объектами: map, filter, reduce, any, all, zip и enumerate.

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

Однако в финансах действует закон сохранения риска. Если у клиента есть право выбора, значит, у кого-то другого этого выбора нет. В структуре банка этим «кем-то» оказывается Казначейство (ALM).

Спустимся на уровень глубже в механику ценообразования банковских продуктов (Transfer Pricing, FTP) и попробуем оцифровать один из самых скрытых компонентов банковской маржи: Cost of Optionality.

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

Когда продакшен падает в три часа ночи, строка ERROR Something went wrong не помогает никому. В статье разбираем, почему привычные текстовые логи быстро превращаются в шум при реальной нагрузке, как перейти на structured logging, зачем каждому запросу нужен request_id и как настроить нормальные JSON‑логи в Python и Go без лишней инфраструктуры.

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

Весь мой путь наполнен любовью к русским разработчикам и открытому коду, а также желанием продвигать российские IT‑продукты (не все конечно).

Сравнил два канонических перевода трагедии Шекспира "Гамлет, принц датский" с помощью Python и NLP.

Признайтесь честно, кто из вас любит рутину? Вы не любите? Вот и я не люблю, поэтому около трёх лет назад я выпустил программный комплекс для ускорения разработки и управления мини-приложениями на Python + PySide6, которые помогают мне в повседневной работе.

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

Содержание

Кэширование — ключевой механизм оптимизации производительности веб-приложений, позволяющий снизить задержки и уменьшить нагрузку на серверы. В этой подробной статье рассмотрим пять основных уровней кэширования, применимых в современных веб-системах. Ты узнаешь о внутреннем и внешнем кэше, кэшировании на уровне reverse proxy, браузера и фронтенда. 

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

Почти каждый сервис, который мы сегодня пишем, ходит куда-то наружу — платёжный шлюз, биллинг, чужой публичный API. И каждый раз, когда садимся писать тесты на этот код, упираемся в один и тот же вопрос: как протестировать клиента, не привлекая внимания санитаров выходя в реальный мир?

Эта статья про то, как выбирать инструмент под эту задачу. Не абстрактно — на одном маленьком, но гордом настоящем сервисе catfact-demo-service, в tests/ которого рядом лежат пять способов протестировать одну и ту же интеграцию. К концу мы их сравним и аргументированно выберем тот, который оставили бы в production-проекте.

Модель может показывать 95–99% accuracy и при этом не решать задачу: особенно если редкий класс важнее всего для бизнеса. В статье разбираем, почему accuracy ломается на несбалансированных данных, как читать precision, recall и F1, зачем смотреть PR‑кривую и confusion matrix, а также как подбирать порог классификации с учетом стоимости ошибок.

Эта статья родилась из работы над AlpinaGPT. Мы недавно зарелизили в нём по-настоящему крутых AI-ассистентов и AI-проекты: с подключаемыми базами знаний, общим контекстом чатов и нормальной памятью между сессиями. Я начал смотреть, как RAG сделан у других — и оказалось, что во многих продуктах на рынке всё гораздо проще и грубее, чем нам кажется. 

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

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