Python *

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

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

История о том, как сделать видимыми ошибки yt-dlp, которые молча умирали в логах воркера. Bridge на 200 строк, классификатор content vs infra, борьба с alert-fatigue.

В прошлой статье я показал, как защищен 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. Везде свой интерфейс, свои правила, своя изоляция.

Вторая статья цикла о внутрянке Celery: на этот раз — зелёные потоки (gevent/eventlet). Как gevent и eventlet работают под капотом Celery, что такое Hub, monkey patching и почему autoscale для гринлетов бесполезен. А ещё — неожиданный бенчмарк: prefork против gevent на одном ядре. Спойлер: gevent проигрывает, но не спешите его хоронить. Для тех, кто выбирает пул под свои задачи. А пойду готовить докер-селери-кубер-автоскейл.

Все мы начинали писать на 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, браузера и фронтенда. 

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

Вы можете замокать aiohttp.ClientSession._request и получить зелёный CI. Но этот тест всё ещё не доказывает, что у вас работает timeout. И не доказывает, что клиент переживёт обрезанный JSON. И не доказывает, что retry реально делает три HTTP-запроса через сокет.

В этой статье я прогоняю один и тот же сценарий через пять уровней тестирования внешнего API — от DI-заглушки до настоящего HTTP-сервера — и показываю, где каждый уровень врёт.

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

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

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

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

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

Так сложилось, что я люблю играть в волейбол и активно снимаю свои игры и тренировки.

У любителей обычно стоит стационарная камера на штативе, которая захватывает всю площадку (или почти всю) в формате 16:9. При этом современные соцсети потребляют контент вертикально (9:16) и короткими роликами около минуты.

Задача: быстро делать вертикальные видео из любительских волейбольных съёмок.

Центральный объект внимания в волейболе — мяч. Значит, нужно определять начало розыгрыша и дальше уверенно следить за мячом. Если сопровождать мяч и делать кроп из 16:9 в 9:16 — получаем готовый вертикальный ролик.

При изучении темы детекции объектов почти сразу попадаешь на семейство YOLO. Отличные модели. В предобученных весах есть класс sport ball.

Но возникает проблема. Площадка 18×9 метров, диаметр мяча — 65–67 см. Чем дальше мяч от камеры, тем он меньше на изображении и тем хуже его определяет YOLO.

Человек легко отслеживает мяч даже на сложных кадрах, потому что видит движение и контекст последовательности. А при покадровой обработке YOLO часто «теряет» маленький объект.

На первом этапе мы попробовали superframe — три grayscale-кадра, записанные в RGB-каналы. Это позволило явно подсветить движущиеся объекты.