Искусство создания компьютерных программ
Пять пробелов, которые не видны на архитектурных блок-схемах.
Пользователь нажимает «Place Order» (Сделать заказ).
API возвращает 200 OK. Заказ появляется в базе данных. На странице оформления заказа выводится сообщение «success» (успех). Извне всё выглядит нормально.
А потом в службу поддержки прилетает тикет.
Агент проходит все проверки и сносит то, что трогать было нельзя. Промпт это не лечит — лечит среда вокруг модели. В ноябре я начал собирать такую среду и называл её просто фабрикой разработки. Меньше чем за год из неё выросло почти десять конвейеров, а у занятия, оказывается, есть название: harness engineering. Рассказываю, как оно росло, и показываю схему и скелет в github.
Просто накопилось достаточно новых фич, которые могли бы кому-то пригодиться, но пропихнуть их в апстрим я не смогу. Так получилось, что сам я уже много лет как отошел от разработки mc в виду личных проблем связанных с моими родителями, но кое что недоделанное оставалось. Большой респект ребятам - Андрею и Юре кто продолжаешь тащить апстрим, они большие молодцы и все кто им помогает.
Важно: я пока не нашел времени и сил подготовить скрипты сборки пакетов для разных дистрибутивов и не придумал название для форка (GPL позволяет использовать старое название, но с указанием что это форк и даты отпочковывания)
Ещё важно, что я публикую этот текст с единственной целью - найти тех, кто поможет выявить проблемы при использовании форка на других платформах и дистрибутивах. Сам я пользуюсь на Ubuntu.
В форке Midnight Commander с амбициозным номером версии v6.0.1 появилось несколько крупных нововведений:
Локальный запуск dev-окружения в крупном проекте может превратиться в отдельный квест: несколько процессов, Docker-контейнеры, переменные окружения, порядок старта, ожидание готовности сервисов и отличия между ОС. Даже если у вас есть подобный опыт, это может быть неудобно, долго и утомительно. Новичку же обычно не обойтись без длинной подробной инструкции.
Привет, Хабр! На связи Сергей Зверьков, старший разработчик в «Лаборатории Касперского». Хочу рассказать, как мы решили эту проблему, написав собственный open-source-инструмент — Runium. Суть его в том, что он позволяет описать dev-окружение в JSON-файле. После этого проект можно запускать, останавливать и проверять одной командой.
В статье расскажу, из какой боли вырос Runium, как он устроен, сравню его с другими решениями и покажу пример использования на простом веб-проекте. Приступим!
Всем привет! На связи Михаил Поливаха, технический лидер проекта Axelix.
Я уже выпускал статью по мотивам вопросов в рамках Spring Айо Академии. Так вот, когда мы разгребали отзывы с первого потока, мы также получили вопрос (это не прямая цитата, я лишь передаю посыл в том виде, как я его понял):
А что насчет натуральных ключей в БД? Если, допустим, у меня есть поле, по которому я могу явно идентифицировать запись, стоит ли его использовать как Primary Key?
И я за время дизайна enterprise систем, и за время дизайна Axelix пришёл к выводу: Просто не используйте натуральные ключи вообще никогда. Когда у вас появляется такое желание - выйдите на свежий воздух, пройдитесь, прогуляйтесь, и вас отпустит.
Несколько месяцев пилил pet-проект, который зашёл дальше, чем планировал: файловый ASGI-фреймворк, где дерево папок — это и есть таблица роутов. Сегодня вышла версия 1.0 — с адверсариальным security-аудитом (нашёл у себя pickle RCE и CSWSH), 2329 тестами и нативным async на PostgreSQL. Рассказываю, что внутри и что было больнее всего сделать правильно.
Promise, setTimeout и async/await часто работают совсем не в том порядке, которого ждёшь по коду, а тяжёлая синхронная функция способна заморозить весь интерфейс. Разберём модель цикла событий, которая объясняет эти эффекты и помогает понимать, где возникают блокировки, гонки запросов и лишние задержки.
Началось всё с подборки промтов cursor-vibe-prompts, которую я таскал из проекта в проект копипастой, и в какой-то момент меня настолько утомила эта рутинная процедура копирования из одного окошка в другое, что захотелось чуть упростить себе задачу и вместо копипасты оформить эту историю в формате скилов и вызывать по необходимости.
Так на свет и появился репозиторий rpa-skills, изначально в нём была сборная солянка директорий скилов, которые содержали в себе просто SKILL.md с оригинальными промтами внутри. Но выглядело и юзалось это решение как-то не очень удобно, да и масштабировать захотелось, так что я решился пойти на немыслемое, почитать документацию о том, как правильно собирать скилы и маркетплейсы, о чём и расскажу сегодня вам.
Но обо всём по порядку, для начала покажу как создавать скилы по уму.
Работая единственным QA в команде, в обязанности которого активно входит мониторинг, я столкнулась с проблемами тайм-менеджмента: очень много времени уходит на анализ упавших пайплайнов, заведение однотипных задач, поднятие тревоги, отмена тревоги, потому что проблема уже исправляется и прочие прелести тестерской работы. В один прекрасный осенний денек, сидя на окне и думая о нем (мониторинге), я решила - хватит это терпеть. Посидела, погуглила, вспомнила родительские слова “Хочешь сделать что-то хорошо - сделай это сама”. Что ж таков путь.
В статье разберём основные изменения GoLand 2026.2, а также расскажем, какие возможности для Go-разработки уже доступны в OpenIDE и чего ожидать от её предстоящего перехода на платформу 2026.2.
Как перестать доверять LLM-судье на слово и построить безопасную двухконтурную систему оценки?
Внутри статьи:
Архитектурный паттерн сдерживания: почему у классической нормализации должно быть право вето.
CI-инварианты: как ловить галлюцинации моделей с помощью враждебных фикстур в grounded-judge-gate.
Разбор факапов: три реальных бага проектирования, которые едва не увели систему в ложноположительное пике.
Речь о процедурно‑параметрическом программировании, о котором почти никто не пишет. Я реализовал одну и ту же задачу в ООП и в этой парадигме и сравнил их численно. Одна из метрик разошлась в 6 раз.
Есть код, который физики передают друг другу с 2002 года. Кристиан Мэтцлер из Бернского университета написал набор MATLAB‑функций для расчёта рассеяния Ми, физики, из‑за которой небо голубое, а молоко белое. В 2009-м Стивен Жак обернул его для тканевой оптики, и с тех пор эти полторы сотни строк разошлись по тысячам работ, от атмосферных исследований до лазерной медицины.
RAG уже стал стандартным способом научить LLM работать с собственными документами без дорогостоящего дообучения. Но за кажущейся простотой скрывается множество практических вопросов: как разбить документы на чанки, где хранить эмбеддинги, как организовать быстрый семантический поиск и какую модель использовать на каждом этапе.
В статье соберем полностью локальную RAG-систему на Go, PostgreSQL и Ollama без облачных API и сторонних сервисов. Разберем весь путь — от индексации документов до получения ответа LLM на основе найденного контекста.
«Bad CaRMa» — глава из Dreaming in Code Скотта Розенберга (каламбур на CRM и «карму») про CRM-систему Vision в компании Upstart. Архитектор задумал предельно гибкую схему: одна-единственная таблица DATA, куда сложили все 150+ бизнес-сущностей — 240+ колонок с именами вроде string82 и numeric31, метаданные и данные вперемешку. Схему ведь больше «никогда не придётся менять».
Это вторая часть статьи Путеводитель по чужим STL, возможно будет и третья про разные трюки-хаки с контейнерами, как наберется материал.
Стандартная библиотека плюсов оказалась почти непригодной для игровой разработки и поняли это практически сразу, как попытались её использовать. Крупнейший на тот момент издатель Electronic Arts стал самым известным примером реализации стандартной библиотеки для разработчиков игр (но конечно же были и другие, менее именитые), и силами команд нескольких студий под руководством Paul Pedriana это было претворено в жизнь.
Корни EASTL уходят в Maxis к 1998-му году, когда Пол работая над SimCity 3000, выступал на GDC с докладом «High Performance Game Programming in C++» про кастомные контейнеры, стоимость вызовов и замеры производительности. Единой EASTL тогда ещё не было, но подход, из которого она потом выросла, виден уже там.
До консолидации, даже внутри одной студии, могли существовать несколько параллельных STL-реализаций, разработанных под разные игры, платформы и инструменты. Рискну предположить, что самой полной была реализация от Maxis, как одной из ведущих студий, а в других командах были поменьше, каждая со своими допущениями.
Он же в статьях и докладах упоминал, что EASTL была синтезом практик из этих внутренних вариантов, а не работой одного человека с нуля, и в основе большой EASTL лежит коллективный опыт нескольких инженерных команд, даже если формальным автором финальной публичной версии и статьи остался он один. Конкретные имена соавторов отдельных модулей (аллокаторов, фиксированных контейнеров и т.д.) указаны в репо, но слава досталась Полу.
В прошлой статье мы разбирали, как сделать работу ИИ-агента предсказуемее: зафиксировать требования в спецификации с помощью Specification-Driven Development (SDD), до реализации описать ожидаемое поведение тестами по Test-Driven Development (TDD), а готовый результат проверить и передать отдельному субагенту на ревью.
У такого подхода есть цена.
Подготовка спецификации, написание тестов до кода и отдельное ревью требуют времени разработчиков. Возникают два вопроса: сколько контроля нужно конкретной задаче и когда затраты на него окупаются?
Полагаться только на свои ощущения в таких вопросах очень опрометчиво. В одном из экспериментов разработчики считали, что ИИ ускорил их примерно на 20%. Замеры показали обратное: с ИИ они работали на 19% медленнее.
В статье считаем полную стоимость работы с ИИ-агентом: разбираем, что уже измерено, сколько времени человек тратит на проверку и почему разным задачам нужен разный уровень контроля.
Что показывают эксперименты, если читать их целиком
Заголовки об ИИ в разработке противоречат друг другу: «на 55% быстрее», «на 19% медленнее», «на 26% продуктивнее». Результаты расходятся, потому что исследования проводились в разных условиях и измеряли разные показатели.
Для сравнения я выбрал работы с доступными первоисточниками, описанной методологией и измеримыми результатами. Исследование пул-реквестов стоит отдельно от контролируемых экспериментов: оно показывает, как агенты используются на практике, но не позволяет установить причины полученных результатов.
Несмотря на то, что PyCharm уже несколько лет официально недоступен в России, он по-прежнему остаётся одним из главных инструментов для Python-разработчиков. Недавно вышла новая версия PyCharm 2026.2.
В релиз вошли разработка Python-расширений на Rust, новый отладчик debugpy, интеграция с Pyrefly, поддержка инструментов uv и uvx и многопроектных конфигураций Poetry и Hatch. Также появились мини-карта редактора, генерация проектов с помощью ИИ, менеджер скиллов для агентов и поддержка TypeScript 7.
В статье разберём основные изменения PyCharm 2026.2, а также расскажем, какие возможности для Python-разработки уже доступны в OpenIDE и чего ожидать от её предстоящего перехода на платформу 2026.2.
Мы добавили кэширование, чтобы ускорить работу бэкэнда.
Затем кэширование нарушило авторизацию.
Поначалу ситуация казалась безобидной. Сервису Symfony требовался JWT-токен для взаимодействия с внешним API. Запрос нового токена перед каждым вызовом был неэффективным, поэтому мы сохранили его в кэше и использовали повторно.
При нормальной нагрузке все работало.
При нагрузочном тестировании токен истекал, и несколько запросов одновременно проходили через один и тот же поток. Каждый из них видел пустой кэш и запрашивал у внешнего API новый JWT. Внешний API аннулировал предыдущий токен каждый раз, когда выдавал новый.
После этого часть приложения начала работать с уже недействительными токенами.
Решение заключалось не только в использовании общего Memcached, ведь проблема была не в хранилище, а в праве на обновление общего состояния.
В статье история о том, как мы с командой обнаружили состояние гонки, что изменил Kubernetes в этой проблеме и почему Symfony Lock с повторной проверкой кэша стал недостающей частью архитектуры.
Попалась функция на языке С++. На её примере прям просится показать, что, делая рефакторинг, можно не только эстетично сократить код, но и оптимизировать его. Давайте разомнём мозги, они нам ещё пригодятся, несмотря на эпоху вайб-кодинга. Кто-то ведь должен понимать, как делать надо, а как не надо.