Python *

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

Для этого в Python используют классы. С их помощью описывают, какие данные есть у таких сущностей (объектов) и что с ними можно делать. Это и есть объектно-ориентированный подход — программа строится вокруг объектов и их взаимодействия.

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

Осенью я начала готовиться к будущему выходу из декретного отпуска, купив курс Яндекс.Практикума «Продвинутый Go-разработчик». Сейчас я еще в процессе прохождения курса и недавно сдала первый дипломный проект, но уже сейчас могу сказать, что разработка ПО вышла на другой уровень за время моего отпуска длиной почти в 2 года. В разработке сервисов появилось много приятных фишек, которые мне нужно освоить. В данной статье я хочу описать то, какие изменения я уже заметила в разработке ПО и что я уже смогла почерпнуть из курса практикума.

Начать хочется с максимально актуальной темы — это использование нейронных сетей. Без них в современном мире разработки(и не только) теперь никуда. Когда я уходила в декретный отпуск, то только малая часть разработчиков активно использовала их, сейчас это повсеместно. Вот пару примеров того, как они уже облегчают нам жизнь.

Недавно я заметил такую штуку: знакомые фрилансеры и маленькие студии разработки частенько теряют заказы, да и организовано у них всё так себе. Сообщения находятся то в одном сайте, то в другом, программисты в Discord сервере, заказчики и прогрев в Telegram, но при этом ещё надо в какую‑то CRM заходить и там ещё что‑то тыкать щёлкать. В общем — мест много, запутанно всё и не удобно.

Подумал: «А что если сделать CRM, которая работает ИЗ телеграма?» Клиент отправляет заказ боту, менеджеры видят в веб‑интерфейсе, программисты предлагают цены, все получают уведомления. Всего два места, но при этом заказчику вообще не надо об этом думать, он в телеграмме, там где уже зарегистрирован. Красиво же?

И я начал.

Всем привет, меня зовут Максим Шаланкин, Machine Learning Team Lead в команде финтеха Big Data MWS. Внутренняя аналитика в финтехе живет в режиме постоянной гонки: новые клиенты приходят, ведут себя по‑разному, а бизнесу нужно быстро понимать, чем группы с разными сценариями отличаются друг от друга. При этом значительная часть работы аналитика — это однотипное сравнение когорт и поиски закономерностей в табличках и графиках. Фоновый LLM‑агент, который умеет сам поднимать данные, запускать статистические проверки и возвращать готовые инсайты, заметно сокращает путь от данных до решения.

Под катом — разбор, как устроен такой background‑агент для анализа активности новых клиентов, на чем он основан, как мы минимизируем галлюцинации и почему выбрали архитектуру, похожую на Claude Skills, а не идем в сторону MCP‑подхода.

На дворе 2025 год. Мы привыкли к f-строкам и тайп-хинтингу, но всё ещё тащим в продакшен привычки из Python 3.6.

Вы знали, что блок else в цикле for выполняется вовсе не тогда, когда «цикл не сработал», а наоборот? А что громоздкий try-except pass для игнорирования ошибок — это антипаттерн, который заменяется одной элегантной строкой из стандартной библиотеки?

В статье — топ-5 прагматичных фич (от match/case с гардами до itertools.batched), которые позволяют писать декларативный код и выбрасывать лишние if и флаги. Никакой воды, только примеры «Было / Стало».

От монолита к модулям: строим масштабируемую архитектуру AI-агентов с FastMCP и LangChain

Год бума AI-агентов показал: самая большая проблема — не галлюцинации, а архитектура. Когда инструментов много, а агенты распухают, копипаста и сложность тестирования убивают скорость разработки.

Хотя экосистема LLM в основном ориентирована на Python, мы нашли Go исключительно подходящим для производственных развертываний. Наша инфраструктура на базе Go обрабатывает миллионы ежемесячных запросов LLM с минимальной настройкой производительности. Помимо хорошо документированных преимуществ Go (см. отличное изложение Роба Пайка о преимуществах Go), три возможности оказались особенно ценными для нагрузок LLM: статическая проверка типов для обработки выходных данных модели, горутины для управления параллельными вызовами API и интерфейсы для построения составных конвейеров ответов. Вот как мы реализовали каждую из них в нашем производственном стеке.

Эта статья — не про "как я выучил Python за неделю", а про реальный инженерный путь: от первых экспериментов с ChatGPT API до production-ready систем, которые обрабатывают тысячи запросов в день. Я расскажу про конкретные проекты, инструменты, пайплайны и главное — про ошибки, которые стоили мне времени и денег.

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

Привет, Хабр! Cегодня я хочу поговорить о самом непонятном и переоцененном термине в мире архитектуры — Domain-Driven Design (DDD). Я объясню его так, чтобы стало понятно даже джуну, и покажу на реальных примерах, чем он отличается от других подходов.

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

Сегодня я хочу поговорить о самом вайбкодинге как о явлении, вызывающем бурю эмоций в IT-сообществе. Этот термин, придуманный и популяризированный Андреем Карпатым в начале 2025 года, быстро стал нарицательным. Для одних это будущее, для других — синоним «говнокода». Но так ли страшен вайбкодинг, как его малюют?

Представьте: вы ведете автомобиль, а на приборной панели нет ни спидометра, ни датчика топлива, ни каких-либо показателей вообще. Ни-че-го. В принципе ехать можно, но вы не знаете, какая у вас скорость, сколько бензина и есть ли с авто какие-то проблемы. Примерно так выглядит работа с LLM-приложением без инструментов мониторинга: система вроде бы и функционирует, но о ее внутреннем состоянии можно только догадываться. 

Меня зовут Александр Сесоров, я работаю инженером по тестированию в YADRO. Занимаюсь задачами автоматизации оценки производительности, точности и эффективности моделей на различных конфигурациях. Сегодня проведу краткий экскурс в инструментарий Langfuse и на примерах из практики покажу, как превратить оценку качества LLM-приложения из гадания в систематизированный и прозрачный сбор метрик на всех этапах.

Начинаю цикл статей о создании 2д игры-платформера, на основе документации библиотеки arcade. Вначале буду показывать самые простые этапы, могу данные этапы преобразовывать или даже удалять, в итоге будут написаны классы (это ООП) и создан exe файл.

Этапы разработки платформера

1.      Придумать идею игры

2.      Показать простые примеры для новичков в программировании (создание окна и главного героя, элементов игры, подготовка файлов и папок)

3.      Реализация механики персонажа

·       Загрузка текстур и спрайтов персонажа 

·       Реализация движения, прыжков и физики

·       Использование физического движка (PhysicsEnginePlatformer или Pymunk) 

4.      Создание карты и тайлов

·       Используйте Tiled Map Editor для создания уровней 

·       Сохраните карту в той же директории, что и код

·       Добавьте тайловые изображения в подпапку

5.      Добавление игровых элементов

·       Коллизии со стенами и платформами

·       Сбор предметов, монеты

·       Враги и взаимодействие с ними

·       Анимация персонажа

6.      Система сохранения

·       Реализация сохранения прогресса игры

·       Сохранение уровня, здоровья, предметов

7.      Уровни игры

8.      Меню игры

9.      Экспорт в EXE файл

Финансовые рынки редко движутся изолированно. Криптовалюты реагируют на фондовые индексы, золото реагирует на макроэкономику, а внутри крипторынка движение биткоина задаёт направление для альткоинов.

Гипотеза проекта:

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

В современных data-процессах ключевую роль играет обеспечение качества данных. Рассмотрим четыре популярных подхода: DBT, SQL, Python (Pandas/SQLAlchemy) и Great Expectations, оценив их эффективность для различных сценариев проверки данных. 

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

Привет, Хабр! Меня зовут Мария, я Data-инженер в SimbirSoft, и предлагаю для начала немного познакомиться с каждым из вышеперечисленных инструментов.

2025-й был насыщенным: переписывали легаси и тушили проды по пятницам. Сейчас, когда таски в Jira закрываются уже с трудом, самое время выдохнуть и закодить что-то «для души». Никаких кубернетисов и хайлоада. Только Python, библиотека Rich и 100 строк кода, чтобы создать уютную елку с обратным отсчетом прямо в консоли. Сделаем красиво, упакуем в exe и отправим коллегам вместо открытки.

Привет, Хабр! Меня зовут Андрей Басов, я руководитель команды технической поддержки стрима корпоративных продуктов и сервисов в MWS. Вместе со своими коллегами — Тимуром Хабибулиным (data scientist) и Рафисом Ганеевым (senior devops engineer) — занимаюсь технической поддержкой и сопровождением продуктов линейки Partner Experience Platform.

Чтобы улучшить качество наших сервисов, через которые МТС взаимодействует с партнерами, мы вынуждены постоянно внедрять новые решения, растить продукты и развивать их архитектуру, при этом нам важно обеспечивать надежность и стабильность работы ИТ-систем. Это не всегда дается легко, ведь объемы данных растут, и их нужно эффективно обрабатывать. Одной из основных проблем становится анализ логов — текстовых записей. В нашем случае они фиксируют события в работе систем, которые созданы за 25+ лет работы компании, а еще у них различные стеки и архитектурные подходы. 

Объемы данных настолько велики, что проанализировать вручную (например, в OpenSearch/Kibana) даже один продукт практически невозможно, иначе нам пришлось бы просматривать миллионы строк логов каждый день. Поэтому мы решили разработать систему, которая позволила бы автоматически выявлять в логах аномалии — события, не свойственные нормальному функционированию системы. Например, это могут быть следы багов, вызванных новыми релизами, или другие непредвиденные происшествия. Что из этого вышло — расскажу дальше. 

Какие навыки реально нужны в IT? Разбор рынка по данным hh.ru. Мы обработали 393 000 вакансий за 2025 год и делимся результатами: универсальный стек технологий, медианные зарплаты по специальностям и доля удаленки. А еще — техническая реализация нашего open-source проекта для сбора данных.

🐻 Почему 90% торговых ботов умирают после первого деплоя

Статья содержит код, который не просто можно запустить в чёрную на Binance, а в белую на Мосбирже через Альфа-Инвестиции или Т-Банк.

В классическом алготрейдинге рынок часто моделируется как временной ряд: индикаторы, скользящие средние, осцилляторы. Аукционная теория рассматривает рынок иначе — как процесс распределения объёма по ценовым уровням, где цена ищет баланс между спросом и предложением.

Ключевым элементом такого подхода является Volume Profile, а именно Point of Control (POC) — уровень цены, на котором за выбранный период был проторгован максимальный объём. В терминах аукционной теории POC соответствует зоне максимального согласия участников рынка.

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