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

Самая продаваемая консоль поколения имела худшую архитектуру памяти, самая технически грамотная продалась хуже всех, а самая простая в разработке принадлежала компании которая никогда раньше не делала консолей. Вы наверное узнали тут PS2, GameCube и Xbox.

Иногда шутят, что когда разработчик переносил игру с Xbox на PS2, то первое что он делал это выбрасывал систему управления памятью и писал новую с нуля, потому что 32Мб плюс 4Мб плюс 2Мб не помещается в 64Мб.

Для чтения этой статьи вам не потребуется знать ассемблер или работать с конкретными SDK. Достаточно понимать, что такое указатель, чем стек отличается от кучи и что рендерить геометрию параллельно с её обновлением плохая идея, и что классические GPU и CPU паттерны работы по-разному нагружают память.

Там, где в тексте встречается псевдокод, он нужен для иллюстрации концепции, а не как готовый код для компиляции. Я уже подзабыл конкретные константы и названия буферов на каждой платформе, но паттерн работы всегда был примерно одинаковый.

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

В этой статье поделюсь своим опытом и намеченными планами.

Всем привет, меня зовут Михаил, я back-end разработчик в ОТП банке. Сегодня хочу рассказать о профдеформации - о том, как разработка перестраивает мозг без спроса.

Разработка - это не восьмичасовой найм. Это перепрошивка, о которой никто не предупреждает на собеседовании. Мы видим, как всё работает за кулисами. А потом вдруг ловим себя на том, что с женой разговариваем эндпоинтами, а в очереди к врачу видим легаси-монолит.

И знаете что? Это не лечится.

Дальше - несколько моих личных симптомов. Пишите в комментариях свои, уверен, что у каждого такое было!

Есть проекты, которые рождаются не из практической необходимости, а из глубоко нездорового вопроса: а можно ли сделать это совсем не тем инструментом?

Обычно, если человек хочет показать в браузере видео, он берёт video. Если хочет покадровую анимацию — пишет немного JavaScript. Он же служит и для потоковой передачи данных. Но все эти подходы слишком нормальные, а потому и недостаточно интересные.

Поэтому давайте поставим себе задачу чуть более сомнительную, чем следовало бы: воспроизвести Bad Apple в браузере без JavaScript вообще, опираясь почти целиком на CSS и немного на серверную магию.

Ну и чтобы окончательно не сбивать градус абсурда, бекенд мы тоже не будем писать на чем-то скучно-прагматичном. Если заниматься таким делом, то с достоинством: C++26 и Boost.Beast.

Результат посмотреть можно тут и на GitHub.

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

Поэтому, в этой части начнем с самого простого – пакета atomic.

Концепции вокруг атомарных операций на уровне CPU я рассматривал здесь, поэтому советую почитать. Там мы даже пишем свой атомарный AND.

!Важно! Мы будем разбирать на примере src/internal/runtime/atomics, то есть внутреннего пакета, а не того, который представлен нам как пользователям(потому что в исходниках я не нашел реализации). Но по большей части операции одни и те же.

Go-сервис может идеально проходить функциональные тесты и уверенно отвечать на локальных прогонах, а потом внезапно развалиться под 1000 RPS: p99 улетает в секунды, в логах появляются таймауты, throughput проседает, а часть запросов вообще не получает HTTP-ответа.

В статье разберём, как подойти к такой деградации без гадания: прогнать нагрузку через vegeta и wrk2, правильно прочитать p50/p99 и status codes, проверить пул соединений к базе, настройки HTTP-клиента, горутины, GC, таймауты и быстро понять, где именно сервис начинает терять устойчивость.

Это перевод статьи Питера Штайнбергера (@steipete), того самого автора OpenClaw, которого недавно купили в OpenAI – "Shipping at Inference-Speed". Этот пост, как мне кажется, спустя полгода после публикации читать только интереснее – потому что то, что он описывает как первые впечатления и вау-эффект от работы с агентами для производства кода, а так же методы для работы с ними – сейчас уже в мейнстриме. Если вы активно пользуетесь агенсткими системами в разработке, то многое из описанного для вас стало привычно; этот пост помогает освежить воспоминания о том, как все было в мае прошлого года – и как сильно все изменилось к декабрю.

Rust давно перестал быть языком энтузиастов. На нём собраны куски ядра Linux, движки баз данных и аналитики (TiKV, Materialize, Polars), бэкенды Cloudflare и Discord. Под Rust пишут прошивки для ESP32 и STM32, фронтенд через WebAssembly, инференс LLM.

Microsoft переписывает части Windows, AWS строит на Rust Firecracker и Bottlerocket, Google пускает его в Android и в дерево ядра. По зарплатам Rust пятый год держится в верхнем дециле Stack Overflow Survey, и семь лет подряд - самый любимый язык разработчиков.

«Задача абстракции — не быть расплывчатой, а создать новый семантический уровень, на котором можно достичь абсолютной точности», — Эдсгер Дейкстра

Взрывной рост количества промахов кэша

При определении топологии сети для обхода 500 коммутаторов нашей системе требовалось 37,5 миллисекунды. Вроде бы это не так медленно, если не учитывать количество промахов кэша: 8,5 миллиона. При 500 узлах это 17 тысяч промахов на узел.

Структура данных была фундаментально неподходящей для этой задачи.

Работа инструмента была простой: определение топологии сети при помощи обхода графа соединённых устройств. У каждого коммутатора было до 48 портов, а нам нужно было при помощи поиска в ширину найти все доступные устройства из начальной точки.

Реализация была как по учебнику — список смежности со стандартным BFS. В случае сети из 500 коммутаторов (в среднем по 12 соединений у каждого) статистика была такой: 8,5 миллиона промахов кэша на 500 узлов. Это 17 тысяч промахов кэша на узел!

Я переписал этот код, реализовав графовое представление, учитывающее кэш. Результаты: код стал в 3,75 раз быстрее, а количество промахов кэша уменьшилось в 7 раз.

В этой главе мы поговорим об эффективном описании и обходе графов.

Реактивность может значительно упростить реализацию надёжных программ. Давайте рассмотрим, что нам нужно для её реализации и какие парадигмы реактивного программирования бывают…

Вайбкодинг (vibe-coding) — это круто, пока вы в потоке, и ИИ делает за вас рутину. Но за видимым “Vibe!” и “func() { return code.gen.ok() }” могут скрываться фатальные ошибки. Мы разобрали 5 критических проблем — от архитектурных косяков и уязвимостей до ленивых промптов и потери контекста.

Продолжение разбора реального кода с собеседования. В первой части разобрали 8 проблем concurrency и memory: race conditions, утечки горутин, проигнорированный mutex, TOCTOU. Это была первая половина из 21 бага в одном сервисе на 150 строк.

Сегодня — вторая часть. Тут нет страшных race conditions, но есть то, что выдаёт уровень разработчика на собесе: отношение к ошибкам, валидация, API design, graceful shutdown, observability. Эти баги не упадут “вдруг” в продакшене — они будут тихо пилить вам костыль за костылём, пока кто-то не сядет переписывать. Актуально для Go 1.26.

Напомню итог первой части: из 8 багов про concurrency на интервью нашёл 7, пропустил только TOCTOU race. В этой части из 13 багов пропустил два: package applike с func main() (то, что код не компилируется — банально не посмотрел на объявление пакета) и отсутствие slog (просто не зацепился за log.Println, а зря). Остальные 11 — поймал. Расскажу, какими паттернами в чтении кода я их вылавливал.

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

Обычно те, кто выбирает направление разработки в IT, идут учить Python, Java или JavaScript. 1С в этот список не попадает: платформа и профессия, связанные с ней, часто воспринимаются менее «модными», хотя по сложности и масштабу задач это не всегда справедливо.

Но в 2026 году есть несколько обстоятельств, которые влияют на восприятие 1С. На российском рынке у 1С очень сильные позиции, особенно в учёте и ERP (Enterprise Resource Planning — система планирования ресурсов предприятия). Зарплаты 1С-специалистов в 2025–2026 годах заметно выросли, а на уровнях мидл и сеньор они стали сопоставимы с доходами в других популярных IT-направлениях. 

В этой статье мы делаем честный обзор того, как сегодня обстоят дела в 1С-разработке, какие преимущества и недостатки есть у этого направления и стоит ли учиться на программиста 1С.

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

В этой статье расмотрим как создавать типы используя Reflection.Emit и реализовывать методы через Expression Trees

Дебаты, касающиеся программирования с применением агентов, в основном касаются подбора инструментария — какую IDE, какую модель, какой CLI использовать и т.д. Гораздо меньше внимания уделяется более интересному вопросу: а сохраняет ли в таких условиях актуальность сам подход к структурированию кода, которому нас учили, если у той штуки, которая теперь пишет код, ограничена долговременная память, а также ограничено контекстное окно? Более того, агент зачастую должен добиваться прогресса по задаче, не имея «перед глазами» всей системы.

Ниже проанализированы различные архитектуры кода — TDD (разработка через тестирование), OOP (объектно-ориентированное программирование, ООП), FP (функциональное программирование, ФП), MVC (модель-представление-контроллер), MVVM (модель-представление-модель представления), микросервисы, событийно-ориентированная архитектура, CQRS (раздельная обработка команд и запросов), гексагональная архитектура, разработка через поведение (BDD), предметно-ориентированное проектирование (DDD). Они отсортированы по показателю прикладной полезности в условиях, когда программирует не человек, а агент.

Самая дорогая ошибка моего B2B SaaS имела ровно одну строчку

Самая дорогая ошибка моего B2B SaaS имела ровно одну строчку: TENANT_ID = “tenant-1” в config.py. Полтора дня поиска бага показали, почему multi-tenant архитектуру нужно закладывать с первого коммита. Разбор трёх архитектурных решений для multi-tenant SaaS в регулируемой отрасли — tenant_id helper, PostgreSQL EXCLUDE USING gist против double-booking, 152-ФЗ как код на FastAPI и SQLAlchemy.

Снова и снова возвращаюсь в одну и ту же точку. Мне становится скучно на работе в найме. Работаешь несколько лет в одной компании, меняешь команды и проекты в надежде, что что-то изменится. Не помогает — меняешь компанию и роль. Но потом все возвращается на тот же круг. Можно назвать это выгоранием, но это слишком широкое понятие. Я захотел копнуть чуть глубже.

В Python всё — объект. Но как язык понимает, что делать при сложении двух классов через +, вызове len() или обращении к несуществующему атрибуту? Вся магия скрыта под капотом dunder-методов. Мы собрали полный гайд для разработчиков любого уровня: от правильной инициализации и перегрузки операторов до создания собственных дескрипторов, контекстных менеджеров и жесткой оптимизации памяти через slots. Никакой воды, только практика, живые примеры и то, что реально спрашивают на собеседованиях.

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

C3 переходит к использованию типов со знаком по умолчанию, но почему? Разве как минимум для размеров правильнее не использовать беззнаковые типы? Попытаемся ответить на этот вопрос.