«Преждевременная оптимизация — корень всех зол, но преждевременная пессимизация является им не в меньшей степени». — Андрей Александреску

Проблема перераспределения

Динамические массивы (векторы C++, ArrayList в Java) — одна из самых полезных структур данных. Они сочетают в себе удобство для кэша, присущее массивам, с гибкостью динамического изменения размера.

Однако у них есть скрытые затраты, связанные с перераспределением.

Однажды я работал над агрегатором логов встраиваемой системы. Система накапливала сообщения логов в динамическом массиве и периодически скидывала их на флэш-накопитель. Кажется, всё просто, не так ли?

Но производительность была ужасной. Система тратила 60% времени на realloc().

Мы создали парсер openui‑lang на Rust и скомпилировали его в WASM. Логика была здравой: Rust быстрый, WASM в браузере даёт скорость, близкую к нативной, а наш парсер — разумно сложный, многоэтапный конвейер. Почему бы не захотеть его на Rust?

Но оказалось, мы оптимизировали не то, что нужно.

В прошлую пятницу я объяснял джуну, почему его код на отсортированном массиве работает в шесть раз быстрее, чем на неотсортированном. Тот же массив, тот же алгоритм, и те же данные. Просто в другом порядке. Джун смотрел на меня как на сумасшедшего и, честно говоря, я его понимаю.

Потому что ответ звучит безумно: процессор внутри вашего ноутбука постоянно пытается предсказать будущее. Буквально. Он гадает, какая ветка if выполнится ещё до того, как условие будет вычислено. И на отсортированных данных ему угадывать проще.

Ну, давайте разбираться.

В новом выпуске отладка iOS-приложений на практике и решение для установки сторонних приложений на Android от Google, Remote Compose и Copy-On-Write, эффекты рисования и градиентного рендеринга, неверная реализация MVVM, рынок труда для джунов в 2026 году и многое другое. Заходите!

Пятница, 17:40. Билд красный, GitLab живой, curl отвечает за полсекунды — а git clone из контейнера молча висит две минуты и падает. Все инструменты говорят «всё ОК». Виновник — 50 байт, о которых никто не подумал.

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

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

В конце статьи будут ссылки на доп. материалы из реальных дизайн-систем, откуда я брал информацию.

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

Привет! Меня зовут Алиса, я преподаю писательское мастерство и много помогаю начинающим авторам. Для этого я обращаюсь к работам мастеров слова, особенно по вопросам формирования индивидуального авторского стиля (идиостиля), чаще всего к лекциям известного фантаста Дэна Симмонса из цикла «Пиши хорошо». 

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

В этой статье я собрала только те писательские техники из его лекций, которые помогут вам проявить свой идиостиль, а кроме того, разберу стиль самого Симмонса на примере его романа «Гиперион» и по тем же критериям, которые он предлагает в своих лекциях. 

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

Миф про O(1)

Говорят, что хэш-таблицы обеспечивают поиск за O(1) — константное время, вне зависимости от размера. В теории они идеальны.

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

Я оптимизировал таблицу символов для компилятора. Таблица символов использовала хэш-таблицу с 1024 бакетами, и у нас было примерно 500 символов. Расчёты выглядели отлично: средний размер бакета = 500/1024 ≈ 0,5, поэтому большинство операций поиска должно выполняться за один запрос.

Но профилировщик рассказал иную историю...

Простой вопрос, который разделяет инженеров и «операторов фреймворков»

Дисклеймер для опытных: если вы знаете ответ – внутри реальный кейс, как этот баг сломал мой паспорт в проде, и история с собеседования, от которой хочется плакать.

Atomic Heart делали 200 человек с бюджетом $50 млн. Hail to the Rainbow — один разработчик, 6 лет, почти без бюджета. Я взял интервью у Сергея Носкова и разобрал этот кейс как руководитель отдела разработки: продуктивность, деньги, выгорание и результат, который сложно отличить от AAA.

Логирование есть практически в каждом C++ проекте. Почти любой сервис, демон или библиотека рано или поздно обрастает строками вроде LOG_INFO(...) или logger.debug(...).

Чаще всего библиотека выбирается по привычке или популярности — spdlog, quill, easylogging++ и т.п. При этом редко кто проверяет, какую цену приложение платит за логирование.

В высоконагруженных системах логирование может выполняться:

Привет, Хабр! Последние несколько лет мы наблюдаем за захватывающей, но тревожной гонкой вооружений между разработчиками средств обхода блокировок и инженерами цензуры (ТСПУ в РФ, GFW в Китае). Ситуация накаляется: после участившихся сбоев в работе Telegram, риск полной блокировки мессенджера в России перестал казаться «страшилкой» и перешел в разряд рабочих сценариев. Уже сейчас иногда умудряются блокировать даже VLESS. Если завтра подобные инструменты «выключат» полностью, нам понадобится что-то принципиально иное.

Сразу оговорюсь: это не «серебряная пуля» и не коммерческий продукт. Это концепт для обсуждения инженерами, обладающими критическим мышлением. Мы будем говорить не о том, как смотреть YouTube в 4K, а о том, как создать сверхнадежный «канал последней надежды» для условий цифрового ГУЛАГа.

В Островке мы используем ИИ в разных задачах — от автоматизации внутренних процессов до продуктовых сценариев — и периодически рассказываем об этом на Хабре. Например, как строим вспомогательные системы на базе LLM и RAG или применяем ML в продукте.

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

Ниже мы перевели и адаптировали материал Алекса Эверлёфа — инженера, который систематизировал подходы к проектированию ИИ-систем за последние несколько лет.

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

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

Примечание. Часть текста была подготовлена с помощью Gemini 3 Pro, но финальную версию автор полностью вычитал, проверил и отредактировал, чтобы она точно отражала его опыт и выводы.

Картинка: Thuringius

Что первым вам приходит в голову, когда вы слышите словосочетание «кумулятивная струя»? 

Наверняка возникают ассоциации исключительно военного толка, не так ли? ;-) Однако, знаете ли вы, что кумулятивный эффект невероятно распространён и применяется практически повсеместно?

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

Это не отдельная статья, а продолжение статьи про теорию объектов в с++, почему объекты в плюсах такие какие есть. Все завершенные главы я также выкладываю на github'e в английском и русском варианте. Продолжаем разбираться в теории С++...

Отдельного разговора заслуживает идентичность объектов, потому что в реальном мире конкретные сущности обладают идентичностью и Сократ останется Сократом независимо от того, перекрасил ли он волосы, сменил адрес или умер, а государство остаётся тем же государством, даже если меняет флаг, конституцию или размер населения. 

Чтобы отразить это в программе, объекты, представляющие конкретные сущности, нуждаются в своём определении идентичности, которая отделена от текущего состояния. Удобный способ ввести такую идентичность будет сделать некий токен идентичности, уникальное значение, которое выражает "кто это", а не "в каком он сейчас состоянии". Таким токеном может быть, например, адрес объекта в памяти, индекс в массиве, или табельный номер сотрудника в кадровой системе и проверяя равенство токенов идентичности, мы фактически проверяем тождественность объектов: один и тот же объект или разные. 

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

В подразделении, где я работаю, есть традиция - новичку при онбординге вручается ссылка на Wiki с легендарными багами, приведшими к заметным последствиям. Недавно мне пришла в голову идея сделать такую же страницу, но уже со ссылками на Хабр, потому что на русском о багах пишут с бОльшим огоньком. Но, увы, оказалось, что каскадному падению серверов AT&T 15 января 1990 года внимание как-то не уделено. А ведь история получилась, прямо-таки эпическая.

Итак, 15 января 1990 года из-за одной строчки кода телефонная сеть AT&T получила 9 часов даунтайма, 70 миллионов несовершенных звонков, а общий убыток насчитали в $60 миллионов еще не инфляционных долларов. И нет, там не было неудачного релиза, развернутого сразу и везде. Все было гораздо интереснее.

Приветствуем, Хабр.

Сегодня мы хотим напомнить вам об одной важной книге, которую в очередной раз допечатали в январе текущего года: «Создание событийно‑управляемых микросервисов». Мы пытаемся развить эту тему в разрезе «для начинающих архитекторов», рады были бы пообщаться с потенциальным автором, который также разделяет наш интерес. Чтобы был более понятен интересующий нас уровень сложности и круг тем, предлагаем ознакомиться с переводным обзором этой темы; статья сентябрьская, найдена в блоге «The Scalable Thread».

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

У некоторых может закрасться вопрос: почему я этим занимался зимой. Но я привык жить по пословице «готовь сани летом, телегу – зимой». Да и ремонт внутри дома идет неспешно, есть время для того чтобы пораскинуть мозгами и придумать ландшафтный дизайн. Как раз к маю закончу, смогу расчистить участок и предоставлю бразды правления жене – она уже мечтает разводить тут сад и огород.

От старого подсобного хозяйства мы сразу открестились – хилые кустарники, которые росли раньше, нас не вдохновляют. Решили оставить только две яблони и груши в середине участка. А вот чем занять остальные 10 соток изначально было непонятно. Я вижу одно, жена – совсем другое. Поэтому как и на предыдущих этапах, пришлось погружаться в тему и изучать тонкости планирования.

Многие из нас умеют отлаживать код, искать утечки памяти и оптимизировать запросы. Но когда дело доходит до отношений, мы часто пытаемся запустить legacy-систему без документации. Этот текст как попытка написать API reference для человеческой привязанности. Без воды, с метафорами, понятными тем, кто мыслит системами.