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-каналы. Это позволило явно подсветить движущиеся объекты.

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

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

Будет использоваться машинное обучение в 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. Сегодня я хочу подняться на уровень выше и поговорить о принципах, на которых эти компоненты и вся система держатся. И поговорить про это через мой опыт в судостроении и страховании.

Я три года пилю 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, с разбором того, как эти метрики работают изнутри.