Python *

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

В этой статье я покажу, как собрать связку простых 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 — это не просто «рекомендованный модуль», а принципиально другой класс генерации.

В данном отчёте экспертов PSF(Python Software Foundation) об инциденте атаки на цепочку поставок популярных пакетов litellm и telnyx вы узнаете технические подробности и рекомендации для разработчиков и сопровождающих PyPI‑пакетов о том, как подготовиться и защититься от подобных инцидентов.

Пришёл в проект, там легаси погоняет легаси. Спагетти такие что уже в рот лезут. Отчёты по филиалам открывались 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 действительно возвращает ранги элементов массива.

Привет. Меня зовут Никита.

Наверняка многим знакома ситуация: кто‑то из друзей или родственников просит «почистить комп», «передалать PNG в JPG» или «раскидать свалку файлов в загрузках».

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

Так появился мое приложение SmartLauncher.

Прежде чем начать, хочу сказать спасибо @metalstiv за вдохновение и отличную статью «DIY мультирум: переключаем ТВ между комнатами с помощью смартфона». Именно после её прочтения у меня созрела идея повторить и немного адаптировать решение под свои задачи — но с одним важным отличием: я решил доверить написание кода и текста искусственному интеллекту.

Python любят за «плавный вход» и огромную экосистему. Но вокруг него было много мифов: от «Python медленный» до «джунам не пробиться без накрутки опыта». В этом интервью я - Александр, автор (телеграм-канала «Shulepov Code»), поговорил с Алексеем Голобурдиным – автором книги «Типизированный Python», основателем канала на Ютубе «Диджитализируй» (170k+ подписчиков) и практиком, совмещающим продуктовую разработку, обучение и эксперименты с БЯМ (большая языковая модель) LLM и ИИ-агентами. В разговоре затронуты: устройство Python и CPython, роль PEP8, корректный подход к изучению Python с нуля, а также ситуации, в которых нейросети действительно помогают, и случаи, когда они формируют лишь иллюзию обучения.

Контролируемая эволюция RAG-системы: оценка mcp серверов и кеширование результатов запрос-ответ

В статье рассматриваются теоритические выкладки как возможно эволюционировать RAG-систему на одном домене (документация 1С). Эволюцию можно расширить на использование нескольких доменов (финансы, бух.учет, юриспруденция, кодинг и.т.п.)

От уравнений до верификации: как мы сравнивали разработанный веб-модуль для анализа потерь в НКУ (низковольтных комплектных устройствах) с нормативной базой

А можно ли рассчитать потери и нагрев шин для оценки тепловыделения в НКУ быстро, точно и прямо в браузере?

Мы решили проверить — и разработали веб-ориентированное расчётное ядро, которое затем сравнили с требованиями ГОСТ.

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

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

На практике инженеры часто оказываются перед выбором:

Нормативные таблицы — надёжно и консервативно;

Дорогие CAE-пакеты (COMSOL, ANSYS) — сложно, точность требует времени и бюджета;

Упрощённые ручные расчёты — быстро, но менее точно.

А что, если объединить скорость, точность и прозрачность в одном веб-инструменте?

В этой статье мы покажем, как на основе физических уравнений мы разработали веб-ориентированное расчётное ядро для теплового расчёта шин, а затем — докажем его точность в сравнении с ГОСТ.