Программирование *

Надоели чат‑боты, которые только болтают? Создаём настоящего ИИ‑помощника: читает файлы, ищет в сети, запоминает всё. LangGraph + MCP — пошаговый гайд для Python‑разработчиков. Меньше теории, больше работающего кода.

— Два готовых агента: классификатор вакансий + файловый помощник
— Поддержка Ollama, OpenAI, DeepSeek — выбирайте любую модель
— Асинхронная архитектура с обработкой ошибок
— Полная интеграция в Python‑проекты без no‑code конструкторов
— Код готов к продакшену: логирование, retry‑механизмы, конфигурация

От настройки окружения до рабочего агента за час.

Недавно прошла 108-я встреча TC39, на которой было продвинуто 9 предложений на разные стадии стандартизации — от сырых идей (Стадия 0) до полностью утвержденных возможностей (Стадия 4).

Ниже краткий обзор этих предложений и того, что они могут привнести в JavaScript.

Я больше года использовал Cursor. Подробно изучил все его возможности и лучшие практики работы с инструментами и... отказался от всего этого в пользу Claude Code.

Уже несколько недель я полностью работаю в Claude Code вместо Cursor. И, честно говоря, возвращаться совсем не хочется. В этой статье я расскажу, как использую Claude Code и поделюсь своими советами по его максимальному использованию.

Представьте, что у вас есть бэкенд-приложение с REST API и вы хотите обращаться к нему не только с локальной машины, но и из интернета — через браузер, Postman, фронтенд или мобильное приложение. Для этого можно настраивать маршрутизацию, туннелирование, искать белый IP — или просто задеплоить приложение в облако. Под катом — пошаговая инструкция, в которой развернем Java-приложение на облачном сервере и пошагово пройдем весь процесс — от сборки до запуска и обращения к API извне.

Начиная с версии 3.12 Python поддерживает такой тип объектов, как бессмертные (Immortal). Бессмертными объектами являются глобальные константы, такие как None, False, True, а также некоторые другие объекты. Если вам интересно, что это за объекты, как ими становятся обычные смертные, где они используются и как повлияли на CPython — добро пожаловать.

Недавно работал в команде, занимавшейся разработкой встроенного ПО. Это ПО в значительной степени основывалось на конечных автоматах, которые десятками были разбросаны по множеству функций. И хотя такая архитектура весьма распространена в разработке встраиваемых систем, в особенности систем без ОС, я задался вопросом: неужели нет способа выразить поток управления более чисто?

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

Меня не покидала мысль: «А не будет ли проще написать логику в виде последовательной программы, ожидающей события и возобновляющей выполнение с места остановки?»

Естественно, в проекте не допускалось использование RTOS, посему традиционный подход применения потоков или систем блокирования для управления конкурентностью не рассматривался. Но я знал, что должна быть некая золотая середина.

Ваш проект взлетел. Первые пользователи превратились в тысячи. Тысячи стали десятками тысяч. Метрики в дашбордах рисуют красивую кривую, устремленную вверх. Но есть и другие кривые, которые ползут вверх с не меньшей скоростью. Время ответа сервера. Количество ошибок 502 и 504.

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

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

В этой статье не будет примеров кода и конкретных архитектурных приёмов. Но если, читая книги и статьи по Domain Driven Design, вы недоумеваете «зачем это всё вообще», возможно, у меня есть для вас ответ. Правда, боюсь, что он вам не особо понравится.

Разработчики всё чаще полагаются на ИИ-помощников, чтобы ускорить повседневную работу с кодом. Эти инструменты умеют автозаполнять функции, предлагать исправления ошибок и даже генерировать целые модули или MVP. Тем не менее, как многие из нас убедились, качество вывода ИИ во многом зависит от качества предоставленного запроса. Плохо сформулированный промпт может привести к нерелевантным или общим ответам, в то время как хорошо составленный — дать продуманные, точные и даже креативные решения для кода.

Под катом Эдди Османи, ведущий инженер Google, выделяет ключевые шаблоны запросов, повторяемые фреймворки и запоминающиеся примеры, которые нашли отклик у разработчиков.

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

Команда Spring АйО перевела статью от JetBrains, в которой анонсировано важное обновление: начиная с версии 2025.3, IntelliJ IDEA будет распространяться в виде единого дистрибутива, вместо отдельных версий Community и Ultimate. 

Теперь каждый разработчик получит более мощный, гибкий и удобный инструмент «из коробки», независимо от подписки. Open source-компоненты по-прежнему доступны, а новая модель обещает улучшенный user experience, бесплатный доступ к большему числу функций и упрощённый процесс сборки из исходников.

Какими инструментами для линтинга и форматирования Python-кода вы пользуетесь? Black, Isort, Flake? Их существует множество, каждый следует своей цели, некоторые могут пересекаться по функциональности. Одни могут нравиться за автономность, другие — за возможности конфигурирования. И наверняка вы слышали о Ruff, который обещается заменить собой все.

Привет, Хабр! Я Гена, Python-разработчик в Selectel. В этой статье я опишу свой опыт перевода проекта на Ruff: что понравилось, что — не очень, к чему готовиться и, если все же решитесь, то как это сделать. Добро пожаловать под кат.

Привет, Хабр! Это Антон Дятлов, инженер по защите информации в Selectel. В одной из предыдущих статей я рассказывал, как настроить скрипт, который через API «Сканер-ВС 6» запустит сканирование, создаст отчеты и отправит уведомление в Telegram. Мы научились запускать сканер по расписанию через cron, импортировать IP-адреса и подсети, получать отчеты об уязвимостях. Такой подход хорошо работал на небольших объемах, но в реальных задачах — особенно в инфраструктурах с десятками и сотнями хостов — быстро всплыли ограничения: скрипт требовал ручного контроля на многих этапах, переход между стадиями (сетевой скан → скан уязвимостей → отчет) приходилось отслеживать вручную, проявилась ошибка в сканере, которая не позволяла корректно удалять ассеты.

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

Привет! Меня зовут Никита Соболев, я core-разработчик языка программирования CPython, а так же автор серии видео про его устройство.

Я продолжаю свой цикл статей на хабре про детали реализации питона. Сегодня поговорим про субинтерпертаторы, их устройство, прошлое и, надеюсь, светлое будущее.

Под катом будет про: новые питоновские API для ускорение и паралеллизации ваших програм, про управление памятью, про дублирование данных. Ну и много C кода!

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

Если вам такое интересно или целиком незнакомо – добро пожаловать!

Перед тем как перейти к рассмотрению предложенных изменений в работе асинхронности в C#, давайте разберемся — зачем все это нужно, как устроено сейчас и какие имеются проблемы, раз разработчики начали искать способы улучшения существующей логики.

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

Представим какой‑то абстрактный web‑api, который ходит за данными в БД. При однопоточном синхронном выполнении следующий запрос может быть обработан только тогда, когда полностью был выполнен предыдущий, что неэффективно, т.к. вся нагрузка ложится только на 1 ядро процессора, а остальные простаивают.

Привет! Я Саша Сергеев, CTO в Профи.ру. И у технических директоров есть мантра: «Используй скучные технологии». Нельзя брать что-то совсем новое: оно не проверено в проде, мало поддерживается. Лучше что-то надёжное. 

Но для ИИ приходится делать исключение: прищуриться и подумать. Делюсь тем, о чем я думаю сейчас. 

Привет, Хабр! Меня зовут Паша, я разработчик Gramax — open source-платформы для управления технической документацией в подходе Docs as Code.

В этой статья я расскажу, как и для чего мы интегрировали Git в браузер, какие технологии использовали и какие технические решения приняли. А если подробнее: почему отказались от IsomorphicGit в пользу libgit2, каким образом мы собрали его под WebAssembly, как он работает с файлами и зачем вообще все это было нужно.

5 июня 2025 года был принят PEP-0734. Судя по информации на официальном сайте, он является продолжением PEP-0554. Этот PEP предлагает добавить новый модуль, interpreters, для поддержки проверки, создания и запуска кода в нескольких интерпретаторах в текущем процессе. А если идти дальше, то он является частью PEP-0684, которые предлагает один GIL на интерпретатор.

Несколько полноценных интерпретаторов работающих рядом. Какие плюсы?

— Один процесс;
— Один тред, но руками можно создавать еще;
— По GILу на интерпретатор, все еще можно получить плюшки настоящей многозадачности по сети;
— Работает с asyncio.

В этой статье вы узнаете как работает эта фича под капотом и в реальном питоне. Приятного чтения!

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

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

Я потратил месяц на создание веб-сайта в Docker и теперь готов поделиться ужасными историями.

У меня есть проблема.

Мой веб-сайт (на котором была опубликована эта статья) в основном обслуживается одним двоичным файлом Rust. Он стал слишком длинным. Каждый раз, когда мне нужно внести изменение, я должен:

Собрать новую статически компонуемую библиотеку (с --target=x86_64-unknown-linux-musl)

1. Скопировать её на сервер

2. Перезапустить веб-сайт

Ситуация, мягко говоря, неидеальная.

Поэтому мне бы хотелось перейти к развёртыванию веб-сайта при помощи контейнеров (будь то Docker, Kubernetes или что-то иное), в духе подавляющего большинства ПО, разворачиваемого в последний десяток лет.

Единственная проблема заключается в том, что реализовать быстрые сборки Rust с Docker не так уж просто.