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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Нейронные сети сегодня уже не какая-то магия из научных статей. Они стоят за рекомендациями в сервисах, распознаванием изображений и, конечно, за LLM-моделями, которыми мы пользуемся каждый день. Но знакомство с ними у многих происходит через готовые библиотеки такие, как PyTorch или TensorFlow: написал пару строк кода — модель обучилась — всё работает. А что именно произошло внутри обычно остаётся загадкой.

Feed-forward нейронная сеть (FNN) — одна из самых базовых архитектур, на основе которой исторически выросли более сложные модели: DNN, CNN и многие другие современные подходы. Хотя сама по себе она редко используется в практических задачах в чистом виде, именно через неё проще всего понять фундаментальные принципы обучения нейросетей.

В этой статье мы реализуем нейронную сеть прямого распространения с нуля, используя только Python и NumPy — без готовых ML-фреймворков. Такой подход позволяет на практике увидеть, как работают основные концепции и принципы нейронных сетей. Погружаясь одновременно в математику и программирование, вы сможете получить более глубокое понимание того, что происходит внутри модели во время обучения и предсказаний.

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

Задача: человек регистрируется, оплачивает, получает ключ на почту и сразу подключается. Без ручной работы с моей стороны. Под капотом — FastAPI, Marzban, PostgreSQL, React, ЮKassa, Resend. Расскажу про архитектуру, грабли и неочевидные решения.

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

TL;DR: В этой статье мы возьмем новейшую Gemma 4 31B, которая в оригинале весит 62 ГБ, и заставим её работать и выгружаться на бесплатном Kaggle с лимитом диска в 57 ГБ. Спойлер: нам придется удалять исходники прямо во время работы Python-скрипта.

Когда в FastAPI-проекте появляется нормальная авторизация, код быстро начинает расползаться в стороны.

Сначала все выглядит терпимо: один Depends(get_current_user), один Depends(get_enforcer), одна ручная проверка. Потом роутов становится больше, правил доступа становится больше, и внезапно половина endpoint’ов начинает содержать не бизнес-логику, а обвязку вокруг нее.

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

В итоге я собрал casbin-fastapi-decorator — тонкий слой над Casbin для FastAPI, который позволяет описывать authorization через декораторы.

Идея простая:

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

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

В какой-то момент становится очевидно:

Это продолжение предыдущей публикации про реставрацию ruGPT3XL. Для тех кто не читал, кратенько, я конвертировал древний Megatron-LM чекпоинт в HuggingFace-формат, залил веса на HF, накатил поддержку GGUF в llama.cpp и подумал, что всё. Но нет.

По ходу тестов, проведённых разными людьми удалось выявить ряд недоработок, которые я по мере обнаружения правил, ну а после того, как удалось получить стабильную и рабочую версию мне захотелось решить одну старую проблему, которая меня в ruGPT3 моделях очень беспокоила, это проблема маленького контекста в смешные 2k токенов.

Решил поднять контекст до 8k.

Недавно перед нами встала задача быстро реализовать микросервис для конвертации видео. Стандартным решением для таких целей является FFmpeg, который умеет читать файлы чанками (запросы HTTP Range) с URL и выводить результат в stdout. Поэтому я решил попробовать подход с потоковой конвертацией.

Важно уточнить, что под «потоковой обработкой» здесь подразумевается передача данных в виде последовательности чанков (Chunked Streaming), а не классический Continuous Streaming, как в случае с live-видео.

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

Игра «Жизнь» — это простой клеточный автомат, поэтому она должна хорошо поддаваться GPU-ускорению. Правила просты: каждая ячейка в двухмерной сетке или жива, или мертва. На каждом шаге мы подсчитываем живых соседей ячейки (включая диагонали). Если ячейка жива, она остаётся живой, если живы два или три её соседа. В противном случае она умирает. Если клетка мертва, она оживает, если живы ровно три соседа. Из этих простых правил возникает потрясающий объём сложности, о котором написаны подробные статьи.

Для простоты я буду рассматривать только сети N×N и пропущу вычисления на краях. Всё будет работать на Nvidia A40, а бенчмарк производительности я буду проводить при N=2¹⁶. Пока мы будем хранить каждую ячейку в виде 1 байта, поэтому весь массив займёт 4 ГБ.

Весь код выложен в репозитории GitHub.