Python *

Многие Telegram-боты, особенно связанные с криптовалютами, используют HTTP-запросы для взаимодействия с внешними API. В этой статье мы разберем, как на этом можно построить MITM-атаку для подмены кошельков, чеков и перехвата данных, почему это работает, и какие меры защиты стоит применять разработчикам и пользователям. Рассмотрим реализацию на Python с использованием mitmproxy.

Telegram-боты стали неотъемлемой частью экосистемы — от новостных каналов до торговых платформ. Однако архитектура многих ботов, особенно тех, что используют популярные библиотеки вроде aiogram или python-telegram-bot, часто подразумевает выполнение внешних HTTP-запросов для обработки команд (например, для проверки баланса или генерации платежного адреса).

Если такой бот использует сторонний HTTP/HTTPS-прокси, все его запросы и ответы проходят через промежуточный сервер. Это открывает возможность для атаки «человек посередине» (MITM), когда злоумышленник может не только перехватывать, но и модифицировать трафик в реальном времени. На практике это может привести к подмене криптокошельков, платежных реквизитов или токенов доступа.

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

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

Интроспекция активно используется во фреймворках, логировании, тестах, dependency injection контейнерах и отладчиках. При этом многие разработчики пользуются ей неосознанно.

Разберем, что это такое, зачем нужно и как применяется на практике.

После негодования по поводу реализации паттерна Repository в обучающих материалах, а именно скудность функционала, я решил, что нужно расширяться и это привело к тому, что появился ORM Query Builder, о котором подробно расскажет вам эта статья.

При работе с Python да и другими языками программирования часто возникает необходимость ускорения выполнения кода, масштабирования обработки данных или работы с большим количеством сетевых запросов. Именно в Python для решения этих задач существуют три базовых метода. Это: threading, multiprocessing и asyncio. На первый взгляд – механизмы схожие. Но при детальном разборе ясно, что они решают принципиально разные задачи, опираются на разные модели исполнения и обладают своими ограничениями. В статье расскажу об особенностях каждого метода – будет интересно и познавательно.

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

Стало немного больно.

Поэтому я написал xlea…

Привет!
Сегодня расскажу о GoMCP — production-grade альтернативе официальному MCP SDK от Anthropic. Спойлер: получилось в 10 раз быстрее, с multi-tenancy и enterprise-фичами из коробки.

100K+ tool calls/sec (vs ~10K у Python SDK)

Security hardening: input validation, audit logging, rate limiting

Multi-tenancy: изоляция namespace + квоты

3 адаптера: stdio (MCP v1), gRPC, HTTP REST

213 тестов, 430+ Full Ralph итераций

Привет, Хабр! Сегодня хочу поделиться историей о том, как желание автоматизировать рутинную работу привело меня к созданию собственного инструмента FullMute и, как следствие, к первым серьезным выплатам на платформах bug bounty.

Как многие начинающие исследователи, я начал с хаотичного ручного поиска уязвимостей: проверял заголовки, искал известные пути к админкам, пытался угадать версии CMS. Это было неэффективно, медленно и сильно зависело от везения. Мне нужен был «компас», который бы проводил первоначальную разведку за меня и давал четкие цели для атаки. Так родилась идея FullMute.

Превращаем LLM в CatBoost: как ансамбль из маленьких моделей (7B) пытается побить Gemini 3 flash

Почему не классическое MOE?

Я проанализировал свои промпты за последние два месяца и заметил паттерн: современные задачи к LLM стали мульти-итентными . Я прошу в одном сообщении: "Возьми данные X, примени логику Y, напиши код Z и оформи в JSON". Архитектура MoE в таких случаях плывет (если мы говорим о single-turn конечно). Single-pass модели часто не справляются, так как не могут реверснуть свой ответ и перепроверить себя перед ответом. К тому же роутер может отдать запрос не тому "эксперту", может неправильно чанковать (условно), в целом мы это и наблюдаем в gemini 3. Текущая предложенная архитектура бустинга решает эту проблему через последовательную ответственность. Первая модель (черновик) пытается сделать всё сразу (и ошибается), вторая (Критик) проверяет выполнение условий постфактум, третья (фиксер) работает с тз критика и исправляет ответ. Такой цикл может длиться от 2 до множества операций, что может значительно экономить ресурсы и улучшать качество ответа (изначальный тезис). При этом даже SOTA-модели пытаются решить всё в один проход, и именно поэтому они «плывут» на сложных мульти-интентных задачах. Текущий подход - итеративное улучшение ответа между разными моделями. Но, пожалуйста, держите в голове что это не классический бустинг и к тому же этап инференса, а не обучения.

Пару ремарок которые можно пропустить если вы и так знакомы с терминами и dl/ml и не интересуетесь архитектурой:

27 января вышла LM Studio версии 0.4.0 и это обновление принесло долгожданную функцию параллельной обработки запросов через continuous batching. Это критически важное обновление для production-использования локальных LLM, которое обещает значительное увеличение пропускной способности. Теперь можно не просто "крутить модельку для себя", а разворачивать реальные multi-user сервисы.

Но как это работает на практике? Я провел комплексное исследование на своем домашнем ПК, сравнив производительность ROCm и Vulkan, а также влияние количества потоков на пропускную способность (TPS).

Спойлер: Разница между ROCm и Vulkan оказалась шокирующей — до 2 раз в пользу ROCm, а правильная настройка потоков дает +50% бесплатной производительности.

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

"Loom" означает "ткацкий станок" - так назывался проект по добавлению асинхронности в джаву. Тяжёлые системные потоки заменили легковесными виртуальными потоками. Потоки и нити в английском называются одинаково - thread - отсюда название.

Проект успешно внедрили пару лет назад, и я, к сожалению, это полностью пропустил. Основная причина, конечно - что я в принципе не ожидал от джавы никаких прорывов (и оказался на 100% неправ!) Ну и, как бэкенд-разработчик на питоне, я не очень-то слежу за развитием JVM-языков.

Но исправляюсь: Project Loom - это блестящая идея. Учитывая, что его внедрили совместимым образом, и почти не было ломающих изменений. Я считаю, это оптимальная реализация асинхронности для высокоуровневого серверного языка.

Уже почти все использующие JVM языки переехали на новую версию JVM, и, таким образом, на проект Loom: деваться им некуда. Так что, есть надежда, что это изменение откроет новую главу для некоторых из них. Есть также предположение, как оно может повлиять на скриптовые языки, такие как питон. Гипотеза только.

Также, вы узнаете, почему Гвидо ван Россум не ошибся, когда добавлял async/await в питон, а Мацумото — создатель Ruby — тоже угадал, когда, наоборот, отказался от async/await.

Введение

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

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

Статистика выбора технических направлений

Согласно статистическим данным выбора детьми кружков для дополнительного занятия, мы видим, что стабильно из года в года всего 5 - 9 % процентов детей от общего числа, «выбирают» так называемые «научно-технические» кружки. К ним относят математические и физические кружки, робототехнику, программирование, радиотехнику, биологические и медицинские кружки. Но даже выбрав направление нет гарантий, что ребёнок закончит предназначенный для него курс. Почти 60% детей, которые пришли на кружки покидают их, не справившись со сложностью подаваемого материала.

         Согласно социологическим опросам (2023 - 2025 годов) видно, что преобладают люди от 35 лет и старше, которые переучиваются или хотят пойти учиться по техническим направлениям, чтобы сменить профессию. Получается, что только с возрастом человек осознаёт значимость «научно-технических» направлений. Но обучать взрослого человека не тоже самое, что обучать ребёнка 9-12 лет.

Причины низкой популярности

         У каждого поколения должен быть свой подход в обучении. Почему же так непопулярно «научно-техническое» направление среди детей?

В мире потоков всё было просто: threading.local() даёт каждому потоку свои данные. Request ID, текущий пользователь, database connection — положил в thread-local, достал когда нужно. FastAPI, Flask, Django — все так делали.

Потом пришёл asyncio, и эта модель сломалась. В одном потоке выполняются тысячи корутин, и thread-local у них общий. Положил request ID в одной корутине — прочитал чужой в другой. contextvars, появившийся в Python 3.7, решает эту проблему, но механика его работы не очевидна.

Разберём, почему thread-local не работает в async, как устроены contextvars, и какие паттерны использовать.

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

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

Не прошло и дня, как я писал про«AI‑диспетчера» — генерируешь, проверяешь, мержишь. Выглядит замечательно. Но ни слова про секурити. А между тем, произошло достаточно инцидентов, чтобы понять: модель рабочая, но только если ты действительно проверяешь, а не делаешь вид.

А если не проверяешь? Replit удаляет базу данных, Claude Code становится инструментом киберпреступников, а твой стартап оказывается взломан за 16 минут.

Это не статья про «не используйте AI». Это статья про то, почему проверка — не опциональный этап, а ваш последний рубеж обороны.

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

В данной статье я расскажу, с какими проблемами, связанными с бинарником, столкнулось моё решение при запуске на Arch Linux у моих знакомых, и почему у меня оно работает нормально на Debian 12 и 13. Также я разберу преимущества и недостатки текущей реализации, покажу возможные пути решения и альтернативы, а лучшее решение применю на практике.

Я снова попрошу Сергея и Ивана запустить моё приложение на Arch Linux, чтобы проверить его работу.

Заваривайте чай, доставайте вкусняшки — пора «удобрять почву для выращивания помидоров»! 🍅

Дескрипторы — одна из тех фич Python, о которых многие слышали, но мало кто использует напрямую. При этом они лежат в основе @property, @classmethod, @staticmethod, слотов и даже обычного доступа к методам.

Разберём, что такое дескрипторы, как их писать и когда они реально полезны.

Введение: Проблема ручного контроля

На работе одним из постоянных и важных процессов является проверка чеков на подлинность. Их поток достаточно большой (порядка нескольких сотен каждый день) и при этом каждый документ разбирается вручную - это может занимать до нескольких минут на один файл. На дистанции получается достаточно много. К тому же ручная проверка это медленно, дорого, и зачастую с ошибками из-за усталости аналитиков.
Потратив некоторое время на поиск готового решения нашей проблемы я нашел самописные гитхабные репы, которые максимум распознавали текст на картинке, даже не на PDF, платных решений я также не нашел, банки их не светят и естественно не продают.

Я ни разу не технарь (хотя по образованию инженер, ха), но благодаря опыту в антифроде я знал точно, что нужно проверять и как. Поэтому я подумал, что было бы прикольно (а в перспективе и полезно) сделать простенькую ML-ку и потихоньку ее обучать, пет проект который если стрельнет, то принесет пользу, а если не стрельнет - я потрачу время с удовольствием.

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

Фоновая музыка, гул, шипение — классические фильтры с этим не справляются. Нейросети справляются, но падают на длинных файлах. Решение: чанкование + сохранение прогресса. Делюсь инструментом.