Python *

Привет всем заглянувшим!

В этой статье я поделюсь опытом автоматизации API‑тестирования связкой Postman + Newman, но с небольшим «секретным ингредиентом». Мы не просто будем запускать коллекции в Jenkins напрямую, а используем универсальный Python‑скрипт, который превращает стандартный прогон в мощный инструмент мониторинга.

В чем «фишка» этого подхода?

Обычно Newman выдает довольно сухие отчеты. Мой скрипт выступает в роли умной прослойки: он обрабатывает результаты тестов на статус‑коды, собирает данные и упаковывает их в наглядный Allure‑отчет. Более того, здесь добавлена функция почтовых уведомлений, чтобы контролировать состояние системы, не заходя в Jenkins.

У меня есть RAG‑сервис: проверяет фактологические утверждения в бизнес‑отчётах против реальных источников — SEC EDGAR, World Bank, FRED, Wikipedia. Это капстоун LLM Zoomcamp (DataTalksClub). Курс закончился, оценку поставили (peer review, 42/42), а я решил дотянуть проект до состояния «не стыдно показать на собеседовании как рабочий код», а не просто «закрыл критерии оценки курса».

Garmin записывает почти всё: сон, HRV, стресс, Body Battery, пульс на тренировке, каждый подход в зале. ChatGPT ничего этого не видит. Чтобы спросить у него, как прошла неделя, нужно было сначала открыть Garmin Connect, переписать цифры руками и вставить их в чат.

Один вечер, один скрипт. Забрать сон и HRV за сегодня, сложить в файл. Никакой архитектуры, просто раздражение от того, что данные есть, а спросить их некому.

Сейчас это открытый пайплайн: локальный кэш, агентный Telegram-бот, локальная модель на Ollama, веб-мастер настройки, Windows-дистрибутив и заявка на акселератор Sber500. По пути пришлось несколько раз пересобрать саму задачу.

У меня было 48 часов видеозаписей учебного курса и простая мысль: пересматривать это я не буду никогда. Сырой транскрипт немногим лучше — болото на сотни страниц. Я собрал конвейер, который превратил записи в Obsidian-вики: 47 связанных статей, и каждое утверждение в любой из них — в двух кликах от места в записи, где это было сказано.

Привет, Хабр! (И тебе, IT-шник, который хочет разобраться, что в 2026 вообще здесь происходит? Сейчас разберёмся, но легче тебе от этого не станет).

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

Здесь будет всё, зарплаты, актуальные стеки и то что уже никому не нужно, прогнозы, тренды, и многое другое, будет интересно...

Дисклеймер: не читайте эту статью, если вы фанат традиционных ценностей и от заголовка уже хотите написать в комментах, что мне стоит изучить базу и отучиться в меде. Читайте эту статью только если вы прогрессивный, веселый и любите необычные проекты ♥ Статья носит исключительно научпоп-инженерно-юмористический характер. Не используйте самодельные скрипты для постановки диагнозов (хотя сходить на ПЦР-тест или к врачу после них никто не запрещает)!

Скажите, вы же тоже ожидали большего от интерпретаций коммерческих ДНК-тестов типа Genotek, 23andMe, Atlas? Ну вот и я не была в восторге от того, что я на 4.2% скандинавка, мне вреден арахис, и скорее всего я люблю кинзу.

В этой статье я расскажу, как я на диком азарте построила свой пайплайн анализа генома. Мы пройдем от пересборки координат и импутации 40 миллионов маркеров на суперкомпьютере TOPMed до укрощения памяти Node.js, чтобы скрипт не умер от 43 ГБ данных, а я покажу, как все устроено под капотом. Осторожно, много блоков кода и дисклеймеров!

Статья об архитектурных подходах, позволяющих упростить back-end разработку больших и сложных систем на языке Python путем применения принципов Domain Driven Design и архитектуры модульного монолита, которые позволяют раз и навсегда избавиться от спагетти-кода, распределить задачи по присущим им областям, обозначить границы между слоями системы, тем самым снизив когнитивную нагрузку на разработчиков. А также развеять миф о том, что данные паттерны возможно реализовать лишь в строго типизируемых языках, а так же специально разработанных под эти задачи фреймворках.

Я незрячий и пользуюсь двумя Braille eMotion 40. На одном устройстве мне стало тесно в рамках штатного набора программ, поэтому я сделал доступный диспетчер APK и автономный установщик для Windows. Рассказываю, почему для интеграции понадобился отдельный пакет-мост, как я проверял опасные операции и какую часть работы взял на себя GPT Codex.

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

Одни слишком простые, другие заточенные на одну стратегию, не нашел чего-то такого, что было бы как минимальной базой для начала

Не учить одной конкретной стратегии, а собрать минимальный рабочий фреймворк, который можно взять за основу и дальше развивать под себя

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

И да - всё это попробуем сделать примерно за 60 минут Вся необходимая информация будет здесь, никуда переходить не нужно - статья полностью самостоятельная

Спойлер: Собранный бот заработал за 5 минут 22 цента, сделки приложил в конце статьи, можно их проверить если сомневаетесь

Статья посвящена разработке радиолюбительского протокола связи на базе OFDM (Orthogonal Frequency-Division Multiplexing). В ней рассматривается процесс создания физического уровня, сложности, с которыми пришлось столкнуться, а также его испытания в эфире.

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

Имея некоторый опыт в построении классических ML и CV-проектов, я решил разобраться в NLP (Natural Language Processing) и собрать свою RAG-систему без использования сторонних RAG-фреймворков (LangChain, LlamaIndex и т.п.). Моя цель - понять, как на самом деле работает RAG под капотом: от разбиения текста до генерации ответа.

Проблема, которую решает RAG

Готовые LLM модели имеют несколько недостатков:

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

Если интервью на английском, добавляется пятый — перевод.

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

Обычный AI‑чат в соседней вкладке в этот бюджет не помещается, и дело не в качестве модели. Посчитайте, из чего складывается задержка: услышать вопрос, переключить окно, напечатать или вставить формулировку, дождаться генерации, прочитать выдачу, найти в ней полезное, вернуться в разговор. Даже без времени на саму генерацию транспортная часть съедает больше, чем у вас есть.

Битва уже идёт, даже если ты этого не замечаешь. Более того, AI уже побеждает!

Старые фильмы про битву против искусственного интеллекта, обычно, рисовали нам классическое поле боя. «И восстали машины из пепла ядерного огня. И пошла война на уничтожение человечества. И шла она десятилетиями…» — наверняка почти все, кто смотрел «Терминатор 2: Судный день» помнят это вступление. Тогда войну с искусственным интеллектом воспринимали как что-то, что будет похоже на то, что мы уже знаем. Но так как «интеллект» искусственный, война идёт по искусственным правилам.

На связи Андрей, руководитель направления безопасности облака в Selectel. В статье расскажу, как работать с индексами Wazuh напрямую через OpenSearch. Такой подход пригодится, когда встроенных возможностей Wazuh уже не хватает: нужно собрать собственный отчет, посчитать статистику по всей инфраструктуре, настроить нестандартный алертинг или выгрузить данные для BI и других внешних систем. Вместо того чтобы обходить ограничения дашбордов, мы научимся работать с тем, где эти данные хранятся на самом деле.

Под катом разберем, какие индексы есть в Wazuh 4.14, как устроены документы внутри них, как безопасно читать данные из Python и не создавать лишнюю нагрузку на кластер. А в конце посмотрим, что изменится в Wazuh 5.0 и к чему стоит подготовить свои скрипты уже сейчас. Небольшой спойлер: индексы там переименовали целиком.

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

На примере FastAPI соберём JSON‑логирование, в котором запрос можно проследить целиком, ошибки — фильтровать по типу, а задержки — анализировать по duration_ms.

Недавно я написал свою систему распределённой обработки задач. Сначала это был учебный проект. Мне хотелось лучше разобраться в очередях задач, координации воркеров, блокировках строк в PostgreSQL, retry‑механизмах и планировании фоновых задач.

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

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

Увеличение количества воркеров с 16 до 32 практически не дало прироста производительности, а при 64 воркерах ситуация стала ещё интереснее: задачи, которые должны были выполняться около 0.5 секунды, начали занимать больше секунды.

Первой моей мыслью было, что я упёрся в PostgreSQL.
Оказалось, что нет.

Вокруг GEO‑продвижения слишком много разговоров о том, как попасть в ответы нейросетей, какие сайты любят ИИ и что нужно сделать для того, чтобы бренд чаще рекомендовали в выдаче. Но чем больше я погружался в тему, тем сильнее меня смущало то, что большую часть таких выводов делают по нескольким ручным запросам. Спросили нейросеть 5–10 раз, увидели несколько знакомых брендов и уже делают выводы о видимости компании.

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

Речь пойдёт про VDI-портал: систему, которая клонирует виртуалки из шаблона, выдаёт их пользователям и гасит простаивающие. Но статья не о нём как о продукте, а об одном вопросе, который на входе выглядит тривиальным: этой машиной ещё пользуются? Ссылка на код будет в конце, одна.

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

Первое решение было очевидным — скрипт по таймауту. Никто не подключён N минут — машина гасится. Понадобилась — поднимается.

Скрипт я написал за вечер, и он даже работал, но по итогу я изобрёл VDI. Только не так, что посмотрел готовые решения и они меня не устроили, — я вообще не формулировал свою задачу как «нужен VDI» и потому не искал. Я решал «пусть виртуалки сами гасятся», а всё остальное наросло само, вопрос за вопросом. Когда стало очевидно, во что это превратилось, переезжать на готовое было уже и поздно, и незачем.

Дальше разбираю вопросы, которые нарастали.

Как быть востребованным Python разработчиком? Какие технологии нужно знать, чтобы легко найти работу? Какие библиотеки и фреймворки уходят в закат и перестают пользоваться популярностью? На все эти вопросы вы получите ответ в этой статье.

Цель статьи: развеять мифы относительно реального применения различных технологий, библиотек и фреймворков в коммерческой Python разработке. После чтения статьи вы научитесь принимать верные решения относительно изучения той или иной технологии, чтобы всегда оставаться востребованным разработчиком.

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

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

Сегодня мы будем говорить преимущественно о таких гигантах, как Django, FastAPI и Flask, а также затронем не менее важные библиотеки: для работы с базами данных, тестирования, сборки проектов. Поговорим о таких противостояниях, как uv vs poetry, pytest vs unittest и других. В общем, будет интересно. Усаживайтесь поудобнее и погнали!

Вы, скорее всего, встречались с кардинально противоположными мнениями: "Django умер, да здравствует FastAPI", "Сейчас на FastAPI уже не пишут, встречай LiteStar", "Вообще на FastAPI особо ничего не пишем, только на Django".