Python *

Мониторинг мониторинга - звучит как масло масляное, но именно этим мы постоянно занимаемся в PingZen. Ведь наш сервис должен быть надёжнее, чем объекты, которые он отслеживает. Если PingZen упадёт, кто сообщит о падении вашего сайта?

Сегодня я залезу под капот тестирования PingZen и расскажу, как мы дошли до 10 900 автоматических тестов (5100 на бэкенде и 5812 на фронтенде). Все цифры и технологии - строго из нашего репозитория . Без хайпа, только факты, код и архитектурные решения.А статью подробнее про Pingzen можете посмотреть здесь

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

Я занимаюсь этим несколько лет. Python, внутренние сервисы, утилиты, автоматизация. За это время появился довольно конкретный взгляд на то, как надо работать. Не из учебника, а через синяки.

Как определить дистрибутив Linux? А что, если имеется только информация о пакетах, установленных на устройстве? История одного «велосипеда» или мы не нашли готового решения.

Представьте, что вам нужно определить дистрибутивы, опираясь исключительно на установленные пакеты. Инвентаризация есть, но данные неполные — часто известно только имя хоста, IP и список установленных пакетов. Операционная система может быть указана как «Linux» без уточнения дистрибутива и версии. О создании алгоритма, работе с KUMA и написании код в данной статье.

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

Но есть более фундаментальный вопрос - кто в системе определяет правила игры?

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

- часть проверок живeт во фронтенде

- часть - в API,

- часть - в промежуточных сервисах

- часть — во временных проверках, добавленных после инцидентов

Добавили новый сервис в цепочку - и изменилось поведение.

Вынесли проверку в отдельный процессинг - и появились состояние гонки.

Перестроили оркестрацию - и неожиданно стала недоступной операция, которая раньше работала.

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

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

Мы отвлекаем существенные ресурсы в поисках решения для проблем.

Как я написал радар межбиржевых спредов на Python и понял, почему 90% публичных ботов считают прибыль неправильно

Привет! Меня зовут Егор Лукьянов, я старший аналитик данных в Ozon Tech. В своей работе я часто сталкиваюсь с проблемой масштабируемости в pandas. Код, который быстро работает на гигабайте данных, начинает невыносимо тормозить на десяти. Уверен, эта боль знакома многим.

Сейчас есть быстрые альтернативы, например, Polars. Я сам пробовал переводить на него свои проекты. Скорость действительно впечатляет, но как в анекдоте есть нюанс: приходится переписывать чуть ли не весь код и привыкать к новому синтаксису. А это большая работа, на которую не всегда есть время.

И вот здесь я наткнулся на FireDucks — библиотеку, которая обещает решить эту проблему, просто заменив одну строку импорта. Звучало слишком хорошо, чтобы быть правдой. После опыта с Polars я был уверен, что где-то должен быть подвох.

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

Реализуем сервис семантического поиска на базе PostgreSQL с расширением PGVector. В статье: настройка БД через Docker, миграции Alembic, асинхронный слой на SQLAlchemy и API на FastAPI. Иллюстрация на обложке - нейрослоп для привлечения внимания

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

Привет! Меня зовут Николай Олигеров, я работаю продуктовым аналитиком в Яндекс Путешествиях. В этой статье я расскажу, как мы применяли PSM (Propensity Score Matching) — статистический метод, который позволяет корректно сравнивать группы, уменьшая систематические различия между ними. Подробно разберу, как выровнять группы теста и контроля с помощью PSM, расскажу о типичных ошибках (например, утечке признаков), дам практические рекомендации по сбору и выбору фич для мэтчинга, а также покажу, как валидировать полученные результаты и оценить их достоверность.

Как запустить AI code review по git diff на своей машине через Ollama - без облака и API-ключей? Установка, конфиг и пример отчёта.

Замысел в том, чтобы написать цикл о 10 программистах, чьи имена не особо примелькались, но чьи заслуги невозможно переоценить. Начну я этот цикл с Эндрю Кучлинга (A.M. Kuchling). Я всегда знал его как автора официального туториала по регуляркам в питоне, пожалуй, лучшего по теме. Но масштаб этого человека куда больше.

ASR-системы в проде - это тяжёлые, специализированные решения под конкретные сценарии. Но что делать, если нужен универсальный инструмент, который умеет распознать длинное аудио, диаризовать спикеров, обработать пачку файлов и при этом не требует целого GPU кластера?

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

Первая часть - про выбор ASR, оптимизацию инференса и практические грабли, с которыми сталкиваешься, когда пытаешься превратить open-source модель в рабочий инструмент.

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

Всем привет! 

На связи София из команды применения больших языковых моделей ecom.tech. Сегодня хочу поделиться одной малоизвестной библиотекой, которую мы волей судьбы откопали на просторах github, попробовали использовать для поиска по нашей кодовой базе, и, о чудо! Это ощутимо помогло нам. Казалось бы, такой маленький шаг для человечества, но такой полезный для нашего проекта.

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

Паттерны — это та вещь, которая моментально выдает уровень культуры кода и понимание инженерных практик. Неудивительно, что на собеседованиях на позицию Automation QA любят покопаться в этой теме.

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

Добро пожаловать в обсуждение! Буду рад конструктивной критике и дополнениям.

История о том, как я создал свою соцсеть. И у меня даже получилось что-то. Видеохостинг, мессенджер, короткие ролики, стена и многое другое

Сидячая работа — профессиональное проклятие разработчиков. Проводя по 10 часов за кодом, мы часто игнорируем «звоночки» от поясницы, пока они не превращаются в полноценные прострелы. После очередного визита к врачу я задался вопросом: а можно ли использовать современные LLM, чтобы упростить жизнь пациенту и наглядно отслеживать динамику лечения?

Так появился Spine Advisor — десктопное приложение на Python, которое использует мультимодальную модель Gemini 3 Flash для «чтения» МРТ и ведения цифрового дневника спины.

Привет! Меня зовут Фаина, я системный аналитик с опытом более 5 лет. В последнее время все чаще стала задумываться как системному аналитику в текущих реалиях применять в работе ИИ. Так началось мое погружение в увлекательный мир LangChain, ИИ, RAG и векторные БД.

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

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

Большинство AI-инструментов — либо облако, либо код под каждую задачу. Coreness Flow строится вокруг событий: пришло сообщение, сработал cron, прилетел webhook — агент находит сценарий по триггеру и выполняет цепочку шагов.

Плагины декларируют вклад в интерфейс через config.json — фронт собирает вкладки и настройки по этим данным, без правки React-кода. Новый плагин — новая вкладка, без хирургии во фронтенде. RAG полностью локальный: BGE-M3 ONNX INT8 + Qdrant embedded в процессе приложения, гибридный поиск офлайн. Разбор архитектуры — API Bus, lifecycle, система сценариев с триггерами и переходами.