Python *

Здравствуйте.

Думаю многие видели, что буквально только что, claude решили резко поменять политику и отключить работу своего решения в сторонних приложениях. То есть даже подписчики их платной подписки за 100 usd, среди которых был и я, теперь не могут использовать удобные безлимитные(в рамках лимитов) решения.

В основном это было сделано из-за безумно популярного агентского решения openclaw, которое в связке с claude sonnet/opus просто идеально. Работало это так. Подключаешься через oauth токен, для claude code и используешь все возможности подписки.

Теперь же claude выдает ошибку LLM request rejected. Они конечно на сайте выложили 100 usd, как компенсацию всем тем людям, что теперь будут вынуждены платить огромные суммы за extra usage, но это все равно не решение.

Идея

Так как работать, так невозможно, мною было решено реализовать прокси сервер для подключения к апи claude через браузерную сессию и сделать для него апи в совместимом openai формате. Чтобы легко можно было интегрировать, как сторонний провайдер в openclaw.

Реализация была поручена одному из лучших моих агентов, по имени Гарри c наибольшим кол-вом накопленного опыта по мере множества моих проектов и работ. Да пока что за их 100 usd бонусный лимит extra-usage.

Max запустили как полноценную альтернативу Telegram для российского рынка, с открытым Bot API. Разработчики оказались перед классической дилеммой: поддерживать двойную кодовую базу или выбрать одну платформу, теряя аудиторию второй.

Типичная ситуация выглядит так: есть готовый Telegram-бот на aiogram, и нужно запустить его ещё в Max. Варианты неприятные — либо дублировать код, либо писать тонну адаптеров вручную, либо мириться с расхождением фич между платформами.

Библиотека obabot предлагает другой путь: один код — два мессенджера.

С завидным постоянством в тематических каналах возникают вопросы про 429 и 50x HTTP ошибки при получении данных из API WB или OZ. Коллеги интересуются, нет ли особого параметра, секретного метода или “золотого” часа, когда гарантированно можно получить данные без ошибок.

Увы, нет. Поэтому надо искать пути решения. Самый очевидный из них - относиться к 429 и 50x как к штатной ситуация и соответственно ее обрабатывать программной логикой.

Пример функции опроса API может выглядеть както так:

Возможность делать скриншот — это базовый минимум, который есть во всех современных смартфонах. Даже у героев вечных споров, iOS и Android используются похожие комбинации «Громкость + Кнопка питания». Разве что на iOS используется «+», а в Android — «-».

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

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

У меня был Nokia 6303 classic — стильный телефон с металлической крышкой на платформе Nokia Series 40 (S40). Мой путь с этим телефоном разошелся, но спустя почти полтора десятка лет я решил, что хочу разобраться в технологиях, которые использовал, будучи школьником. 

Я нашел в продаже б/у Nokia 6303 classic и погрузился в тему.

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

Индустрия пытается лечить это костылями: наращивает контекст до миллионов токенов или заставляет модель «подумать шаг за шагом» (Chain-of-Thought). Я решил проверить эту архитектуру на прочность. Собрал локальный измерительный стенд LOCK-R, вооружился Теоремой Байеса и поймал современные LLM за руку.

В этой статье я математически докажу, почему одиночные агенты структурно уязвимы, как токены размышлений заставляют их врать самим себе еще искуснее, и почему паттерн «Слепого Судьи» - это единственный способ вылечить AI от предвзятости. Тестируем на локальной Qwen-9B и фронтирной GPT-5.4.

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

В этой статье я покажу, как собрать связку простых Python-скриптов, которые стягивают данные из обоих API и сводят их в единый дашборд. Никаких громоздких BI-систем и баз данных только хардкор, requests и pandas.

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

Привет, Хабр и читатели!
Сегодня я попытаюсь сделать с вами диалект LISP.

Я думаю, что я достаточно хорошо понимаю как его сделать.

Мы реализуем там TCO, FEXPR функции и dynamic scoping.

Во многих fullstack-проектах на Next.js и Django авторизация разваливается в одном и том же месте. На фронте удобно использовать NextAuth, потому что он закрывает формы входа, OAuth, серверную сессию и клиентские хуки. На бэкенде хочется иметь обычный JWT-контур на Django REST Framework, чтобы защищать API, работать с access и refresh токенами и не привязывать бизнес-логику к фронту. В итоге часто получается неприятная схема: пользователь логинится через NextAuth, потом отдельно логинится в Django, потом где-то вручную перекладываются токены, а через пару недель вся эта связка начинает ломаться на refresh, logout и OAuth.

Что делаем. Пользователь проходит один вход на фронте, а дальше фронт уже работает с токенами Django как с единственным источником доступа к API. Без второй формы входа, без ручного хранения access token в localStorage, без отдельного костыля под Google OAuth.

Разберем рабочую схему, в которой NextAuth отвечает за пользовательскую сессию на фронте, а Django остается владельцем API-авторизации и выдает JWT. На credentials-входе NextAuth сразу получает access и refresh от Django. На Google OAuth фронт сначала пускает пользователя через провайдера, потом синхронизирует его с Django и тоже получает пару токенов. После этого все запросы идут через один axios-клиент, который сам подставляет access token, сам обновляет его через refresh и сам завершает сессию, если refresh уже недействителен.

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

Поискал, что есть из того, что может пригодиться.
...
Так в итоге появился мой опенсорсный проектик

Зощенко умел писать точно, коротко и смешно. Попробовал с помощью Python математически установить лексические средства, которые делают язык писателя столь особенным и смешным.

Привет, Хабр! Меня зовут Андрей Горлов, я CEO IT-компании «Альтеркод» и программный эксперт курса «Python-разработчик» в Яндекс Практикуме. Недавно мы провели рефакторинг программы: добавили больше практики, обновили версии фреймворков и сделали обучение более сбалансированным для студентов.

В этом материале мы с продуктовым лидом Александром Скугаревым кратко расскажем об изменениях. Текст будет полезен тем, кто хочет узнать больше о том, как устроено онлайн-образование в IT, и всем, кто думает об обучении Python в Практикуме.

Полгода назад написал первую статью про RBACX — RBAC/ABAC-движок авторизации для Python. С тех пор вышло 25+ релизов, и библиотека стала заметно мощнее: добавил ReBAC с поддержкой OpenFGA и SpiceDB, пакетную проверку прав, ИИ-генерацию политик из OpenAPI-схемы, Redis-кэш, async Django, шортхэнд для ролей и закрыл три security-бага. Рассказываю что, зачем и как это вообще делается в одного.

Вы уверены, что ваш “случайный” пароль действительно случайный?

Я тоже так думал — пока не полез разбираться, как Python на самом деле генерирует случайные значения. Оказалось, что привычный random — это не про безопасность вообще. Это генератор, который только выглядит случайным, но при определённых условиях может быть воспроизведён. Что даст нам возможность предсказать все будущие пароли и прошлые.

В статье я последовательно разбираю:

• почему классическая “энтропия пароля” часто вводит в заблуждение;

• как устроен Mersenne Twister и в чём его фундаментальная проблема;

• почему даже хороший seed (через os.urandom) не делает random безопасным;

• и что на практике можно (и нельзя) восстановить, имея время генерации, код и несколько паролей.

Я попытался воспроизвести реальную атаку: восстановить seed по временной метке и набору сгенерированных паролей. Спойлер — всё оказалось сложнее, чем кажется.

Отдельно показываю, где проходит граница между «кажется надёжным» и «действительно криптостойким», и почему secrets — это не просто «рекомендованный модуль», а принципиально другой класс генерации.

В этой статье рассмотрены две недавние атаки на цепочку поставок, направленные на пользователей популярных пакетов PyPI — litellm и telnyx. Также авторы предоставили рекомендации для разработчиков и сопровождающих проекты на Python о том, как подготовиться и избежать подобных инцидентов в будущем.

Пришёл в проект, там легаси погоняет легаси. Спагетти такие что уже в рот лезут. Отчёты по филиалам открывались 30 секунд. Команда реально боялась нажать кнопку в рабочее время, а вдруг база ляжет.

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

Первое, что я сделал: открыл EXPLAIN ANALYZE.

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

Окей, задача понятная. Первым делом пошёл к тем, кто делал это приложение.

Индустрия ИИ переживает бум мультиагентных систем. Кажется, рецепт AGI найден: просто соедините 10 умных нейросетей в команду, дайте им роли, и они свернут горы.

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

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

Так появился опенсорсный проект llm-coordination-harness - строгий измерительный стенд (measurement rig), который доказывает, что у общения нейросетей есть своя физика, которую можно и нужно измерять.

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

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

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

Добавили отложенные сообщения — пишешь текст, выбираешь время, и сообщение уходит само. Работает во всех типах чатов.

Поле ввода сообщений переработали: обновлённая панель форматирования, поддержка диаграмм и опросов прямо из тулбара.

На бэкенде пересобрали хранение данных о прочтениях и добавили индексы под основные запросы — снизилась задержка и ускорился вывод информации.

Когда проектов в GitLab становится много, довольно быстро появляется одна и та же задача: найти, где используется конкретный API, URL, env-переменная или конфигурационный параметр.

Пока репозиториев мало, всё просто: открыл поиск, ввел строку, получил результат. Но когда проектов уже больше сотни, а нужные вхождения лежат не только в коде, но и в YAML-конфигах, Helm-чартах, .env и JSON-файлах, жизнь становится менее романтичной.

Первый лобовой вариант — просто скачать все проекты локально и искать по ним через grep, ripgrep или IDE. Работает, но тащить 100+ репозиториев на локальную машину ради одной проверки — идея так себе. Ноутбук, скорее всего, энтузиазма не разделит.

Мне хотелось искать прямо поверх GitLab, без локального зеркала всей группы репозиториев. Я начал с просмотра готовых вариантов, а в итоге пришёл к своему гибридному краулеру: код ищется через GitLab API, а конфиги добираются отдельным глубоким обходом файлов. В результате поиск по 100+ проектам сократился с часов до нескольких минут.

Иногда в программировании встречаются трюки, которые отлично работают, но почти нигде не объясняется — почему.

Один из таких приёмов в NumPy — вычисление рангов элементов массива с помощью двойного argsort: argsort(argsort(x)). Этот однострочник часто рекомендуют на форумах и в ответах на Stack Overflow, однако строгого объяснения обычно не приводят.

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