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

«Управление сложностью — сама суть программирования компьютеров.» — Брайан Керниган

Стадия финального тестирования

Мы находились на этапе финального тестирования проекта IoT‑датчика — устройства для умного дома с 128 КБ ОЗУ, которое отслеживает температуру, влажность и качество воздуха. Прошивка прошла все функциональные тесты. Юнит‑тесты: зелёные. Интеграционные тесты: зелёные. Энергопотребление: в пределах спецификации.

Последним требованием был тест непрерывной эксплуатации в течение 72 часов. Мы подготовили в лаборатории двенадцать устройств, настроив их на отправку данных датчиков каждую секунду, и оставили их работать.

Спустя три дня я пришёл в лабораторию, ожидая собрать логи тестирования и завершить проект.

Но вместо этого выяснилось, что все двенадцать устройств аварийно выключились.

В консоли последовательного порта на каждом устройстве была одна и та же ошибка:

[72:14:23] malloc failed: out of memory
[72:14:23] Fragmentation: 45%
[72:14:23] System halted

У меня cкрутило желудок. Проект планировалось выпустить через две недели. Я в точности знал, что произошло, и понимал, что решать проблему будет очень трудоёмко.

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

Особенно остро этот вопрос стоит для NGFW — самого сложного и полнофункционального продукта в линейке сетевых СЗИ. Наши коллеги уже делились опытом в этой области. Мы расскажем о своём подходе: как мы сопровождали разработку и тестировали режимы работы сетевых СЗИ с помощью собственного генератора трафика.

Задумывались ли вы когда-нибудь о том, что на самом деле происходит под капотом, когда вы рендерите приложение React? Мы знаем, что React строит дерево DOM и отображает UI на экране, но как React конструирует это дерево и как он эффективно обновляет его при изменении состояния?

В этой статье мы рассмотрим React Fiber — основной движок согласования (reconciliation) React. Мы рассмотрим, как React строил DOM до v15, недостатки этой ранней стековой (stack) модели с точки зрения производительности и то, как асинхронная архитектура Fiber решает эти проблемы, начиная с React v16 и до React v19.

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

Здравствуйте, уважаемые читатели.

В мае мы выпустили 2-е издание (на русском языке - первое) фундаментальной книги Дениса Бахвалова "Оптимизация производительности современных процессоров". Денис Бахвалов, легендарный в узких кругах разработчик процессоров из компании "Intel", ведёт классный англоязычный блог Easyperf, в котором рассуждает на разнообразные темы, связанные с профилированием процессоров, поиском узких мест, машинным кодом, а также со своей книгой. Сегодня предлагаем вам перевод одной из самых глубоких и стратегически важных статей этого блога, многие аспекты которой подробнее раскрыты в книге. Далее - от автора

В своем курсе CS50 профессор Малан в течение одной из лекций наглядно демонстрировал что такое программирование — он усадил несколько добровольцев из аудитории и они вместе делали бутерброд (или сАндвич, кому как угодно). На просторах интернета еще много было видео про отцов‑программистов, которые делали так же бутерброды по инструкции своих детей. Суть подхода везде была такова, что программирование — это составление четких инструкций для компьютера к исполнению, которые он не может интерпретировать как‑то иначе. Как мне кажется, эта концепция хороша, но для скриптов или для разбора отдельных методов/функций, но не для создания программ в целом. Мне захотелось найти более общую метафору для программирования.

(Рассуждения приведены относительно языка Java)

Представим, что мы строим здание. Если конкретнее — жилой многоквартирный дом. Из чего он состоит? Любому зданию нужны фундамент и каркас — это основа. Как это соотнести с программированием — наверняка вы слышали о таком слове, как фремворк, которое почти дословно можно перевести как каркас. Каркас может отличаться в зависимости от требований застройщика, особенностней окружающей среды, температурного режима, а также бюджета. Дом можно построить на фундаменте из свай, железобетонной плите, стены можно сделать из кирпича, пеноблока и т д. Точно так же для программы можно выбрать основу — Spring для приложения, Cucumber/JUnit для автотестов.

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

В четверг я допоздна сидел над рабочей задачей и рассчитывал на помощь ChatGPT, чтобы закончить побыстрее. Открываю чат — о, привет, «This model's response is unavailable». VPN, который до этого честно работал полгода, решил лечь именно в этот момент. Перезапуск, смена сервера, ещё один перезапуск — тридцать потерянных минут и задача, которую пришлось доделывать до трёх ночи.

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

Пошел на принцип: никогда, вот именно НИКОГДА больше я не потеряю доступ к ChatGPT из-за VPN. Ошибка сервера OpenAI, погасший в доме свет, метеорит, ударивший в системный блок — ок, тут я бессилен. Но вот сломанный VPN больше не будет мне преградой.

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

Я успел побывать по обе стороны. Сначала несколько лет разбирал алерты в SOC — сидел на потоке срабатываний и решал, что из этого инцидент, а что шум. Потом ушёл в разработку и последние годы пишу сами детекты — те правила, которые генерируют эти срабатывания. И вот что забавно: пока не начал писать алерты сам, я был уверен, что понимаю про них всё. Оказалось — почти ничего.

Эта статья — про несколько вещей, которые выглядят совершенно по-разному в зависимости от того, с какой стороны экрана ты сидишь. Будет полезно и аналитикам, которые ругают «криворуких вендоров», и разработчикам, которые не понимают, почему их идеальное правило ненавидят в SOC.

ИИ уже умеет за минуты генерировать сотни строк кода, но скорость ревью от этого не выросла. Разбираем семь ошибок, из‑за которых AI Code Review пропускает реальные дефекты, создаёт ложное чувство безопасности и постепенно превращает проверку кода в формальность.

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

Практический разбор двух ключевых подходов к spec-driven development: как устроены их рабочие процессы, насколько они расширяемы и в каких местах и OpenSpec, и Spec Kit всё ещё оставляют вас один на один с агентом.

В первой части мы разобрали язык, компилятор и байткод SwiftII — Swift-подобной среды для Apple II 1977 года. Но чтобы на этой машине действительно писать код, одного интерпретатора мало: клавиатура без строчных букв и обратного слэша, дисплей без половины нужных символов, 64 КБ памяти, которые приходится переключать банками. Во второй части — как автор всё это обошёл (собственный редактор, файловый браузер, ввод через диграфы) и, отдельно, как весь проект собирался с помощью Claude Code и Codex: честный разбор, где ИИ реально помог, а где им пришлось управлять вручную.

Учителей физики в России стало вдвое меньше за двадцать лет: 61 тысяча в 2002 году против 31 тысячи сейчас, и треть из них пенсионного возраста. ЕГЭ по физике сдают 91 тысяча человек — это 37% от плана приёма в технические вузы. Некому учить, некому сдавать, некем заполнять инженерные специальности. Круг закручивается сам на себя.

Python давно стал почти стандартным инструментом для машинного обучения, анализа данных и научных задач. Однако в вычислительно сложных проектах его производительность быстро становится ощутимым ограничением. Поэтому под привычными NumPy, PyTorch и другими инструментами значительная часть вычислений выполняется компонентами на C, C++ или CUDA. Особенно заметно это становится, когда готовых библиотечных функций недостаточно и высокопроизводительные операции приходится писать самостоятельно.

Несколько лет назад за решение этой проблемы взялась компания Modular, представившая Mojo — новый язык, внешне очень похожий на Python, но построенный иначе. Первую публичную версию показали в 2023 году, после чего проект довольно быстро менялся, а некоторые его конструкции успели исчезнуть или несколько раз поменять форму. Теперь этот этап формально завершен: 11 августа 2026 года вышел Mojo 1.0. Первая стабильная версия стала хорошим поводом разобраться, откуда вообще взялся этот необычный проект и зачем понадобился еще один инструмент для высокопроизводительных вычислений.

Задача звучала просто: получить список компаний определённого профиля в конкретном городе — с сайтом и способом связаться. Не телефоном, а email / Telegram / WhatsApp.

Итоговый скрипт — примерно 400 строк: Playwright для Maps, requests + BeautifulSoup для сайтов, регексы для контактов, txt на выходе. Ниже — не туториал "как повторить", а список мест, где всё ломается.

Вот весь конвейер целиком, с отмеченными точками отказа — дальше по статье разберём каждую:

Очередная история про AI и разработку, но с конкретикой. Mattermost на Team Edition, три ежедневные боли: нельзя нормально ответить на сообщение в канале, не видно прочитал ли коллега, для созвона кидаешь ссылку на локальный Jitsi с отдельной авторизацией.

За день собрал три плагина в Cursor: reply с цитатой, галочки доставлено/прочитано, голосовые комнаты на Pion прямо в server‑плагине. Личная инициатива, не тикет в бэклог. Коллегам понравилось, мне в копилку.

Рассказываю, почему не переезжали на другой мессенджер, как задавал рамки AI (опыт с медиа помог), и где плагины не работают: спойлер, нативные приложения.

P. S. про обложку. Превью для Habr тоже сгенерировал AI. Оно, конечно, вообще не похоже на настоящий Mattermost: другие цвета, другой UI, будто мессенджер из параллельной вселенной. Но мне так понравилось, что решил оставить. Пусть будет из разряда «ожидание vs реальность» или «Mattermost, который мы заслуживаем».

Представьте: в пятницу вечером руководитель уверенно сообщает, что переход со Spring Boot 3.5 на 4.0 будет простым и его можно закончить за выходные. Скорее всего, вы уточните, на чём основана такая оценка, и напомните о несовместимых изменениях.

Теперь заменим руководителя на GitHub Copilot или другую большую языковую модель (LLM). Она предлагает рефакторинг метода, новую зависимость или готовый шаблон реализации. Ответ выглядит аккуратно и звучит уверенно. Модель не предупреждает, что может ошибаться. Возникает вопрос: проверяем ли мы такой код столь же строго, как заявление руководителя, или сразу принимаем его?

По данным отчёта Sonatype за 2026 год, 27,76% из 36 870 сгенерированных LLM рекомендаций по обновлению зависимостей ссылались на несуществующие версии этих зависимостей. Получается, одна из трёх-четырёх зависимостей — выдуманная. И проблема не ограничивается зависимостями: та же ложная уверенность может присутствовать в любой строке кода, созданной ИИ.

В комментариях к моей статье про уход сына из школы половина спора шла о том, что такое семейное образование вообще, а вторая половина — об уверенности, что так поступают семьи с проблемами. Я полез в данные. Здоровье как причина перехода — 5%, последнее место в списке. 85% родителей с высшим образованием, 34% предприниматели, главная причина у 52% — претензии к школьной системе. Заодно разбираю разницу между семейным, надомным и самообразованием и смотрю, что за год случилось с рынком детского образования.

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

Машина Тьюринга (МТ) не сферический конь в вакууме программистского бытия. Она не про «единички-нолики» и елозанье вдоль ленты, а про гимнастику мозгов для программистов. Продолжим тему МТ, начатую в [1]. Ее программирование увлекательная и, без сомнения, серьезная работа по созданию алгоритмов при миним миниморум средств на их реализацию Тем и привлекательна. Особенно на этапах обучения алгоритмическому мышлению.

Продолжим тему нахождения наибольшего общего делителя (НОД) двух чисел для МТ. Только теперь это будет обычное программирование. По счастью ли по совпадению нужный нам алгоритм приведен в книге Н.Вирта [2]. Его блок-схема (БС) приведена на рис. 1. Обычная и ни чем не примечательная БС и совсем простой алгоритм. Особенно в сравнении с рассмотренными для МТ. Привел он его, преследуя другие цели, но сейчас не это главное.

Что видит трансформер: крокодила, лодку или силуэт человека? Проверяем BLIP на визуальных иллюзиях.

Наверняка многие видели картинки‑тесты, которые предлагают по тому, что первым бросилось в глаза определить характер, какое полушарие доминирует или что‑то еще. Обычно на этих изображениях находится несколько объектов или один объект меняется в зависимости от «угла» обзора. А что будет, если попросить трансформер описать эти картинки? Что «увидит» он и на что он «обратит внимание»?