За годы работы разработчиком я сталкивался с разными подходами к тестированию. В этой статье я хочу показать, какие практики кажутся мне неэффективными, и объяснить, как довольно просто писать надёжные тесты, которые дают и хорошее покрытие, и устойчивость. Статья может быть полезна не только Python-разработчикам, но и инженерам-программистам в целом.
Так сложилось, что я люблю играть в волейбол и активно снимаю свои игры и тренировки.
У любителей обычно стоит стационарная камера на штативе, которая захватывает всю площадку (или почти всю) в формате 16:9. При этом современные соцсети потребляют контент вертикально (9:16) и короткими роликами около минуты.
Задача: быстро делать вертикальные видео из любительских волейбольных съёмок.
Центральный объект внимания в волейболе — мяч. Значит, нужно определять начало розыгрыша и дальше уверенно следить за мячом. Если сопровождать мяч и делать кроп из 16:9 в 9:16 — получаем готовый вертикальный ролик.
При изучении темы детекции объектов почти сразу попадаешь на семейство YOLO. Отличные модели. В предобученных весах есть класс sport ball.
Но возникает проблема. Площадка 18×9 метров, диаметр мяча — 65–67 см. Чем дальше мяч от камеры, тем он меньше на изображении и тем хуже его определяет YOLO.
Человек легко отслеживает мяч даже на сложных кадрах, потому что видит движение и контекст последовательности. А при покадровой обработке YOLO часто «теряет» маленький объект.
На первом этапе мы попробовали superframe — три grayscale-кадра, записанные в RGB-каналы. Это позволило явно подсветить движущиеся объекты.
В первой части была создана инфраструктура для запуска машинного обучения. Там же была создана БД с данными для использования в примерах.
В данной части будет искаться, какой тип файлов вызывает увеличение нагрузки. При этом, зная, какой именно тип файла был указан как вызывающий нагрузку.
Будет использоваться машинное обучение в Apache Spark.
Вы всё ещё используете map и filter с лямбдами в 2026 году? Подготовил большой гайд по анонимным функциям в Python: от самого первого lambda x для новичков до разбора байт-кода, замыканий и жестких антипаттернов, за которые бьют по рукам на код-ревью.
Всем привет! Меня зовут Макс, я Lead Backend и автор YouTube-канала PyLounge.
Это третья часть мини-серии о Django-миграциях. В первой части мы готовились к миграциям и разбирались с конфликтами, во второй чинили типичные подводные камни. Если их не читали, то рекомендую начать именно с них, а затем вернуться сюда.
В этом же материале поговорим о самом интересном: что происходит, когда python manage.py migrate запускается в 17:30 в пятницу на проде, под 3k RPS и таблицей в 200 миллионов строк.
Расскажу какие блокировки в PostgreSQL берёт каждая операция Django, что внутри atomic = False, как пишется правильный паттерн expand-migrate-contract, зачемнужны AddIndexConcurrently, AddConstraintNotValid, SeparateDatabaseAndState и как обновлять данные на больших таблицах.
P.S. примеры намеренно упрощены, чтобы влезли в статью и не задушили. В реальной жизни всё ещё хуже - но шаги те же.
P.S.S. При подготовки этого материала ни одна продовая база данных не пострадала.
PLC-Tracer новый взгляд на Ladder логику. Это бесплатный браузерный инструмент диагностики для ПЛК Allen-Bradley (ControlLogix, CompactLogix, MicroLogix и PLC-5). Он разбирает и визуализирует лестничную логику как в офлайн-режиме, так и по данным из живого контроллера. Инструмент умеет записывать состояния переменных в реальном времени через прямое подключение к ПЛК и воспроизводить сессии в режиме офлайн.
Все началось с прикола, я сидел с друзьями и подумал, а вот было бы прикольно запихать разные модели нейросетей в один чат и заставить их думать, что они реальные люди и работают в корпорации. Весь смысл был в том, чтобы это были действительно разные модели и пользователь мог просто между ними переключаться по запросу. Для начала мне нужно было найти зоопарк апи ключей с бесплатными лимитами. Я прошерстил весь интернет и в итоге нашел относительно норм варианты: Groq для LLama, Google AI Studio для Gemma и Gemini. В целом в это время код был простой, правда все время происходил забавный баг, когда пользователь переключался между моделями, одна модель не хотела отдавать очередь другой и просто притворялась ею, но я в целом без трудностей поправил это через системный промт. Однако до конца у меня исправить это так и не получилось, видимо, мои модели слишком тупые.
Эта часть про то, как я пилю бэкенд, учусь на этом и получаю эмоциональные качели.
Для начала, напомню о себе: после 12 лет отсутствия в сфере я решил вернуться к своему базовому образованию – инженер-программист. Что-то приходится «вспоминать с нуля», но я не люблю начинать изучение полностью с теории, я больше экспериментатор.
«Если что-то может пойти не так, это обязательно случится». Мы не пытаемся предотвратить отказ, мы проектируем систему так, чтобы отказ одного элемента не валил конструкцию целиком.
В предыдущих статьях мы разобрали AutoML на задаче о Титанике и показали систему мониторинга моделей. Это были туториалы по компонентам OutBoxML. Сегодня я хочу подняться на уровень выше и поговорить о принципах, на которых эти компоненты и вся система держатся. И поговорить про это через мой опыт в судостроении и страховании.
Представь: пятница, вечер. Ты запускаешь CI для последнего пулл-реквеста, идёшь наливать кофе, возвращаешься… а билд упал. Один тест. Ты перезапускаешь проходит. «Флаки», — вздыхаешь ты и ставишь лейбл flaky. На следующей неделе история повторяется. Потом ещё раз.
Мы привыкли, что нестабильные тесты — это неизбежное зло. Их ловят повторными прогонами, а если повезёт вырезают. Но знаешь, что реально бесит? В 80% случаев корень проблемы можно найти, просто посмотрев на код теста.
Я написал инструмент, который это делает автоматически. Без логов CI, без истории прогонов — только AST и машинное обучение.
Назвал его FlakyDetector. Первая версия была исследовательским прототипом (про него у меня выходила статья на Хабре). А теперь — это полноценный продукт: CLI, веб-дашборд, CI-интеграция и даже React-фронтенд. И да, он open source.
Давай разберёмся, как это устроено.
Я три года пилю Telegram-бот для одного B2C-продукта. В пятницу вечером маркетолог попросил убрать запятую — я потратил двадцать минут на одну запятую, потому что текст был размазан по семи питон-файлам. И тут меня переклинило. Так появилась библиотека, где все диалоги бота живут в одном YAML — с клавиатурами, медиа, условиями и опциональной очередью под лимит Telegram. Выложил на PyPI, делюсь.
В прошлой статье я поделился своими наработками в области работы ИИ с CAD-программами (в моём и нашем случае, SolidWorks). В этот раз поделюсь практическими результатами на примере тестового ядра своей программы.
В статье поделюсь тестами программы, опишу интерфейс и поделюсь мыслями о дальнейшем развитии.
Каждый спринт мы экспортируем JSON из Kibana, листаем сотни записей и говорим себе, что потом превратим их в тест-кейсы, но потом никогда не наступает.
Логи содержат реальные API-вызовы. Настоящие endpoint’ы, реальные payload’ы, настоящие статус-коды из продакшна. Это ближайшее к спецификации описание того, как система ведёт себя на самом деле. И почти ничего из этого не становится автотестом. Потому что переводить вручную дольше, чем идёт спринт.
Я устал от «потом», написал secure-log2test, CLI-инструмент, который читает экспорт Kibana и генерирует готовый pytest-файл. Одна команда. Работающие тесты.
Главное ограничение, которое определило весь дизайн: никакие данные не покидают машину. Никаких вызовов LLM API. Никакого облака, всё локально.
Построение прогноза последовательности (графика) это тема отдельной книги, поэтому в статье я только слегка коснусь двух подходов:
- построение прогноза по одной точке, используя цикл;
- построение прогноза на весь период одним махом.
И постараюсь пояснить на примерах, почему один из них скорее всего будет пустой тратой времени.
Начинающим разработчикам строки обычно кажутся едва ли не самым простым, что есть в языке программирования. Возможно, причина в том, что знакомство с новым языком зачастую начинается с вывода на экран строки Hello, world!.
«Это же просто набор символов, заключённый в кавычки!» — обычно восклицает джуниор Python-разработчик.
Но в Python всё немного интереснее. И за простым синтаксисом скрывается большой набор возможностей, правил и нюансов. Более того, если посмотреть внимательнее, окажется, что в Python целый зоопарк строковых представлений и связанных с ними особенностей.
Привет, я Евгений Бартенев, автор и техлид курса «Python-разработчик» в Практикуме. В этой статье последовательно разберу, какие бывают строки в Python, чем они отличаются друг от друга, какие возможности дают и какие подводные камни могут встретиться в работе с ними. Поговорим и о базовом использовании, и о важных деталях, которые стоит помнить каждому разработчику.
В логистике проблема часто не в том, что нет данных.
Проблема в том, что данные разбросаны по разным местам.
Одни заявки лежат во внутренней системе, другие — в закрытых кабинетах грузоотправителей, третьи — на тендерных площадках, четвёртые приходят через Excel‑выгрузки, пятые доступны только через веб‑интерфейс. Где‑то есть нормальный HTTP‑обмен, где‑то данные спрятаны за фронтендом, где‑то приходится читать DOM‑таблицу, а где‑то сначала кажется, что всё просто, пока не выясняется, что цена приходит в копейках, маршрут состоит из трёх точек, а тип кузова записан как «тент 20т, верхняя загрузка».
Для менеджера всё это выглядит не как единый рынок грузов, а как набор вкладок в браузере.
Открыть один кабинет. Потом второй. Потом третий. Проверить направление. Сравнить цену. Посмотреть дату. Понять, где реф, где тент, где просто «20 тонн». Не забыть про аукцион, у которого скоро истекает время. Потом всё равно перенести результат в таблицу или открыть внутреннюю панель.
В какой‑то момент стало понятно: нам нужен не ещё один парсер, а единая витрина.
Так появился внутренний агрегатор заявок — условный «Авиасейлз для логистики».
Продолжаем рассмотрение, того как правильно оценивать качество ИИ систем, в данной части поговорим про метрики характерные для RAG системы. Способах оценить полноту, точность и соответствия выдачи контексту в подобной системе. На примере библиотеки RAGAS, с разбором того, как эти метрики работают изнутри.
Спор. Деньги. Двое людей не сошлись характерами и зашли в арбитраж. На разбор у двух живых арбитров ушло три недели с переменами арбитров, отпусками, скандалами и тремя параллельными переговорами сторон.
После того как вердикт уже был вынесен, я прогнал то же самое дело через свой Telegram-бот на Claude Sonnet 4.6. Те же скриншоты, та же фактура, никаких подсказок.
Бот выдал тот же вердикт за двенадцать минут. Не на 100%, но суть совпала: кто прав, кто что должен сделать, какой срок, что при неисполнении.
Прогнал ещё четыре старых дела три из четырёх совпали дословно. В четвёртом ИИ даже нашёл деталь которую упустил живой арбитр.
Внутри статьи: архитектура с двумя ИИ (секретарь на Haiku отсеивает мусор, арбитр на Sonnet выносит решения), куски кода с промптами, дебаунс через asyncio чтобы бот не бомбардировал участников ответами, проверка криптотранзакций по 12 блокчейн-сетям параллельно, изолированные приватные группы через Telethon-userbot.
И главный вопрос в конце: пора ли увольнять живых арбитров?
Поговорим о том, как превращать последовательности пользовательских событий в векторы, зачем обучать BERT на «языке» клиентского поведения и почему embedding‑пространство может неожиданно начать отражать будущую ценность пользователей
Gunicorn кажется простым, пока не сталкиваешься с эксплуатацией: внезапные ошибки 502, зависшие воркеры и странное поведение при перезапусках. За этими симптомами стоят вполне конкретные причины — от медленных клиентов и отсутствия буферизации до особенностей реализации GThread и механики Graceful Shutdown.
В этой статье разберём реальные сценарии отказов, посмотрим, как менялась архитектура GThread в разных версиях Gunicorn, и соберём практичную конфигурацию с Nginx, Docker и Kubernetes, которая ведёт себя предсказуемо под нагрузкой.
