Python *

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

В данном отчёте экспертов 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 действительно возвращает ранги элементов массива.

Существуют десятки утилит для очистки метаданных (от ExifTool до встроенных средств ОС), но у всех них есть общий минус — они требуют ручного действия.

В результате родился MetaPure — фоновый демон для Windows, который перехватывает файлы в буфере обмена в момент копирования и бесшовно выжигает из них метаданные, прежде чем вы нажмете Ctrl+V.

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

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

Разница между «бот работает» и «ботом пользуются» — это UX. В этой статье разбираем, как сделать так, чтобы пользователь не думал, а просто проходил сценарий. Поговорим о первом сообщении, кнопках и их группировке, сценариях вместо команд, FSM (машине состояний), текстах и обратной связи. А также покажем официальные цветные кнопки и премиум-эмодзи из Bot API 9.4, которые теперь доступны всем. В конце — чеклист для проверки вашего бота.

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

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

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

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