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

В апреле 2026 года Canonical раскрыла 44 CVE в uutils — реализации GNU coreutils на Rust, которая поставляется по умолчанию с версии 25.10. Большинство из уязвимостей обнаружилось при внешнем аудите, проведённом перед выпуском 26.04 LTS.

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

Примечательно то, что все эти баги оказались в кодовой базе на Rust, написанной людьми, которые знают, что делают, и ни один из багов не был отловлен механизмом проверки заимствований, clippy lints и cargo audit.

Я пишу эту статью не для того, чтобы покритировать команду разработчиков uutils. Ровно наоборот: мне хочется поблагодарить её за публикацию результатов аудита с подробностями, благодаря которым все мы можем научиться чему-то новому.

Кроме того, на нашем подкасте Rust in Production недавно был вице-президент по разработке Ubuntu Джон Сигер, заслуживший похвалы слушателей за честный рассказ о состоянии Rust в Canonical.

Если вы пишете системный код на Rust, то эта статья будет самым сжатым анализом того, где сейчас заканчивается безопасность Rust.

Если ваш ИИ-агент при каждом вопросе начинает grep-ом по всему проекту — у меня есть для вас одна штука. SocratiCode — это MCP-сервер, который индексирует кодовую базу через Qdrant и даёт агенту нормальный поиск вместо построчного чтения. Разобрал, как он устроен внутри, потестировал на нашем монорепе и сравнил с обычным режимом Claude Code

Когда CRM в Битрикс24 начинает открывать список сделок по 10 секунд, обычно первым делом подозревают сервер, нагрузку или саму платформу. Но на практике узкое место часто лежит ближе к базе: фильтры по UF-полям без индексов, лишние JOIN, неявный LIKE в ORM, N+1-запросы и обработчики, которые внезапно превращают массовое обновление в нагрузочный тест.

В статье разбираем, как подойти к проблеме системно: включить slow query log, прочитать EXPLAIN, найти реальные причины тормозов и точечно ускорить CRM без миграции и бессмысленного наращивания железа.

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

Я веду список советов по агентному кодингу: правила и ориентиры для тех, кто только начинает работать с Codex, Claude Code, Pi или любым другим агентом. Каждый пункт — обобщённая рекомендация, применимая к агентному программированию в целом. Хочется, чтобы уроки оставались актуальными по мере того, как улучшаются модели и инструменты.

Ниже — текущий список: 10 уроков агентного кодинга. Десять — красивое круглое число, хороший повод опубликовать.

using в C# выглядит как универсальная страховка от утечек ресурсов, пока объект живёт строго внутри одного метода. Но стоит вернуть его наружу, передать в фоновую задачу, положить в коллекцию или доверить DI‑контейнеру — и привычное правило начинает работать против вас.

В статье разберём типичные сценарии, где IDisposable превращается в источник нестабильных багов: закрытые раньше времени соединения, гонки с Task.Run, утечки обработчиков и тот самый HttpClient, который лучше не создавать на каждый запрос.

Привет. Меня зовут Николай Пискунов, я руководитель направления Big Data и эксперт курса Cloud DevSecOps по безопасной разработке от Академии вАЙТИ Beeline Cloud. Сегодня я хочу поделиться историей создания одного интересного проекта — клиента для облачного сервиса Ollama.

Разбор минимального пользовательского Task для C++20 coroutines: выбор promise_type для void и value-результата, политики initial_suspend(), хранение coroutine_handle, final_suspend(), сохранение результата и исключения, а также границы текущей реализации.

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

Миграция большого iOS-проекта с Objective-C на Swift кажется понятной задачей ровно до тех пор, пока не начинаешь считать объём. В нашем случае это были 10 тысяч файлов, сотни тысяч строк кода и постоянная необходимость не останавливать развитие продукта. Ручной подход работал слишком медленно, поэтому мы начали автоматизировать миграцию с помощью LLM — и в итоге превратили её из бесконечного техдолга в воспроизводимый процесс.

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

Меня зовут Андрей Сикерин, я руковожу одной из групп iOS-разработки Яндекс Браузера. Вместе со мной статью писала Елизавета Мазулова, разработчица из нашей же команды. Она создала систему промптов для миграции, ревью, рефакторинга и автоматизации тестирования. Вместе мы расскажем, как устроен весь процесс изнутри: от выбора порядка миграции модулей до контроля качества через тесты.

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

Написал гайд для тех, кто хочет понять нейросети изнутри. Создаем свой ИИ для распознавания цифр на чистом Python всего в 50 строк кода. Вся математика на пальцах!

Вы прочитали гайд по Cursor, посмотрели демку Claude Code, посчитали в голове экономику и решили: пора. Спускаете в команду указание — попробовать на следующей итерации. Через две недели смотрите на цифры и видите, что lead time не сократился, а вырос. Полетели странные инциденты в трекер. Двое лучших разработчиков ходят с лицами «я же говорил». На ретро звучит сдержанное «нам нужно больше времени, чтобы оценить эффект». На самом деле это значит «уберите эту штуку».

Знакомо? Это типичная картина внедрения ИИ в инженерной команде через администрирование. Проблема не в инструменте, не в моделях и не в скептиках. Проблема в том, что push‑модель (принуждение) внедрения системно не работает с разработчиками высоких грейдов — и чем сильнее ваша команда, тем хуже она работает.

В этом гайде — модель вовлечения без революций (далее pull‑модель). Что нужно построить, чтобы синьоры сами выбрали работать с агентом, а через три месяца стали евангелистами. Это не про мотивационные речи и не про премии за процент кода от ИИ. Это про инженерное решение: workflow, инфраструктура и фазы развёртывания, которые проходят фильтр опытного разработчика.

В Go легко написать код, который компилируется, но раздражает при чтении: слишком длинные receiver’ы, странные имена пакетов, лишние повторы в вызовах, хаотичный регистр и utils, который постепенно превращается в свалку. Для начинающего Go-разработчика соглашения по именованию могут выглядеть как набор мелких вкусовых правил, хотя на практике они влияют на навигацию по проекту, читаемость API и стоимость будущего рефакторинга.

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

Привет, Хабр! Последние полгода стало модно создавать новые и переводить старые проекты на рельсы AI-First (или AI-Friendly) стандарта. Уже появляются проекты, которые декларируются как «designed for AI to write». Например, AIR — AI-First веб-фреймворк на Python.

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

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

OpenAI выкатил гайд по промтингу GPT-5.5. Главный тезис: длинные простыни инструкций с ALWAYS/NEVER/MUST не помогают модели — они мешают. Чем подробнее зажимаешь процесс, тем хуже результат. Я полез проверять. Открыл свой рабочий скилл — process-logs, обработка логов ошибок, версия 1.9.0, продакшн. 663 строки, 36 капс-блоков: «CRITICAL REQUIREMENTS», «YOU MUST FOLLOW THESE RULES. NO EXCEPTIONS». Каждый раздел начинается с MANDATORY. Перечитал по новым правилам OpenAI и нашёл четыре проблемы в одной секции из 134 слов: дублирующиеся императивы на одну мысль, judgment-call под видом invariant, нет stopping condition. Переписал — стало 50 слов. На Opus 4.7 и GPT-5.5 короткий вариант даёт лучший фикс на одной и той же ошибке из логов. В статье: разбор 5 ключевых тезисов гайда с прямыми цитатами, диф «до/после» на реальном продакшн-скилле, эксперимент в Google Stitch, который можно повторить за 5 минут, и сверка с тем, что говорит Anthropic про Claude.

Всем привет! В этой статье напишем простой конечный автомат для парсинга HTML. Уровень средний, требуется понимания побитовых операций.

Я работаю проджект‑менеджером в крупной IT‑компании. Я за вечер сделал то, на что раньше ушло бы несколько месяцев работы целой команды. И этот опыт полностью поменял мое отношение к роли разработчика.

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

– PostgreSQL

– Kafka

– RabbitMQ

– Redis

И так далее. Менеджить целый зоопарк таких сервисов локально бывает не очень удобно. К счастью, у команды Spring Boot для вас есть небольшой помошник - Spring Boot Docker Compose.

Комментарий от Михаила Поливахи:

Друзья, хоть на дворе уже Spring Boot 4, мы знаем, что большинство из вас сидит на Spring Boot 3. И мы посчитали очень нужным рассказать о таком Spring Boot инструменте, который, на наш взгляд, делает локальную разработку со Spring Boot намного более приятной.

Расскажу про четыре production‑инцидента на одном куске кода за десять дней. В каждом я думал, что разобрался. Закончилось тем, что я выкинул pg_advisory_lock из retry‑пути и поставил FOR UPDATE SKIP LOCKED. Day‑generation лок остался advisory‑ным, но утечка там не критична — почему именно, разберу в конце. Полезно, если у вас Postgres на Neon (или Supabase, или Aiven serverless) и где‑то по коду есть session‑scoped advisory locks для координации задач между репликами.

Каждый начинающий бэкендер рано или поздно сталкивается с классической болью: «Ну не знаю, на моем компе всё работало, а на сервере почему-то падает!». Решение давно известно — контейнеризация. Но что делать, если от слова Docker бросает в дрожь, а официальные туториалы написаны сухим академическим языком и требуют знания Linux-администрирования?

Мы с нуля напишем простейшее API на современном FastAPI, разберемся, чем «образ» отличается от «контейнера», упакуем наш код в изолированную коробочку и научимся запускать всё это одной кнопкой через Docker Compose. Максимально просто, «на пальцах» и без лишней воды. Заходи, если хочешь деплоить без боли и слез!

Когда я начинал CodeClone, это был довольно понятный инструмент: найти структурные клоны в Python-коде и не дать им незаметно расползаться по проекту.

Сейчас вышел CodeClone 2.0.0, и это уже другой продукт.

Не “ещё один линтер”, не попытка заменить Ruff, mypy, pytest, Bandit или Semgrep, а отдельный слой ревью: он смотрит на структуру Python-кода, отделяет старый технический долг от новых регрессий, связывает находки с покрытием тестами и дает одну и ту же картину в CLI, HTML-отчете, GitHub Actions, VS Code, Claude Desktop, Codex и через MCP.

Эта статья не про список флагов CLI. Про флаги есть документация.

Здесь я хочу рассказать, во что CodeClone вырос как продукт и зачем вообще нужен такой класс инструмента сейчас, когда разработка всё заметнее смещается в сторону AI-агентов.