Всем ведь приходилось заниматься улучшением производительности? Для игр особенно актуально, ну может какая-то три-в-ряд не страдает этим. Как обычно серебряной пули нет, начинаем со структур данных, алгоритмов, спускаемся ниже если не помогает, придумываем SoA, AoS шаблоны. Если проблема не решается, подтягиваем профайлеры и предметно разбираем узкие места, но все чтобы мы не делали зачастую таким узким местом всегда будет "железо". Можно сколько угодно оптимизировать другие места, но CPU c его гигагерцами будет простаивать 90% времени если его неправильно "кормить" данными. Одной (только одной из проблем) проблемой организации эффективной работы с данными будет меньше, если знать и уметь работать с кэшами разных уровней. Тут на вики описано, как "на пальцах" быстренько убить перф на обходе массива, простого и общего решения для такого обхода нет. Можно и дальше увеличивать размер кэша, что собственно и делают (гдето здесь на хабре была новость, что Интел при переходе на L1 кэш размером 32кб, заново спроектировал блок доступа к нему, сорян не нашел ссылку), но это дорого, неэффективно на масштабах современных процов, и всегда найдутся данные, которые этот кэш отравят, опять. Интересно как починить? го под кат...

В 1957 году писатель-фантаст Роберт Хайнлайн так представлял себе людей XXI века: «Делала перерасчет прочности гидропонических оранжерей, но выходило с ошибками. Дважды забывала логарифмы, так что пришлось лезть в таблицу».

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

Зато, чтобы обрести эту сверхспособность, не требуются укусы радиоактивных пауков — достаточно просто прочитать эту статью, а уж пригодится ли в жизни — решайте сами. Может быть в нужный момент калькулятора под рукой не окажется, а может быть просто захочется произвести впечатление на коллег небрежно брошенной фразой: «Корень седьмой степени из пяти это примерно 1,25». Хотите научится быстро считать? Тогда добро пожаловать под кат!

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

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

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

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

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

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

Но внезапно я открыл для себя тот факт, что не во всех ошибках моя вина. То есть да, это моя голова думает код, это мои руки печатают этот код, но ошибка идёт не от меня. Ошибка заложена ещё раньше, вообще задолго до меня, а иногда даже задолго до моего рождения.

Сейчас я вам это покажу. Будет интересно, но впереди много боли. Я предупредил.

Знакомая ситуация? Вы открываете файл контроллера на 2000 строк. Там перемешаны SQL-запросы, HTML-разметка, бизнес-логика и комментарии на ломаном английском. В голове начинает играть тревожная музыка, а внутренний голос шепчет: “Закрой это немедленно, пока оно не сломалось”.

В психологии это называется “когнитивная перегрузка”. Мозг просто отказывается парсить такое количество переменных одновременно. Раньше программистам приходилось часами медитировать над распечатками кода, как сыщикам, пытаясь прокачать навык “Внутренняя империя”.

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

Здесь мы разберем 6 фундаментальных паттернов промптинга, которые вытащат вас из любой ямы.

Все знают эту историю. 1945 год, инженер Перси Спенсер стоит рядом с магнетроном в лаборатории Raytheon, у него в нагрудном кармане шоколадный батончик, батончик тает. Нормальный человек выкинул бы шоколадку и пошёл дальше. Спенсер притащил попкорн. Зёрна начали лопаться. Потом он сунул туда яйцо, и оно взорвалось коллеге в лицо. Через пару месяцев Raytheon подала патент. Всё, микроволновка изобретена.

Эту историю рассказывают везде. Она в каждом научпопе, в каждом ролике на ютубе, в каждой подборке «10 случайных изобретений». Но вот что рассказывают сильно реже: большинство людей неправильно понимает, как она НА САМОМ ДЕЛЕ греет.

Я вот неправильно понимал. Десять лет жил с красивым объяснением в голове, которое оказалось неправильным.

«Связанные списки — это goto структур данных.», — авторство приписывают разным системным программистам.

История из учебника

Все студенты, изучающие computer science, узнают о связанных списках на первом курсе по структурам данных. Их описание звучит привлекательно:

Преимущества (согласно учебникам):

- Вставки и удаления за O(1) в известных позициях

- Динамический размер: увеличиваются и уменьшаются согласно необходимости

- Пространство не тратится впустую: можно распределять ровно столько, сколько нужно

- Гибкость: простота реализации стеков, очередей и других структур

Недостатки (согласно учебникам):

- Поиск за O(n): необходим обход, начиная с головы списка

- Лишняя память: указатели добавляют оверхед

- Невозможность произвольного доступа: нельзя выполнять переходы в произвольные позиции

Вывод из учебника: «Используйте связанные списки, когда требуются частые вставки/удаления и не нужен произвольный доступ».

Вроде бы звучит разумно?

Проверка реальностью

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

Не потому, что ошибочен анализ «О» большого, в нём всё правильно, а потому, что он неполон. Он забывает про оборудование.

Проблема: когда из-за «оптимизации» код замедляется

Начнём с ситуации, в которой могут спотыкаться даже опытные разработчики. Допустим, вы написали на C++ следующий код, который выглядит совершенно нормальным:

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

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

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

Я профессиональный проходитель performance review. И может показаться, что это шуточная статья, но я вообще не шучу.

Приветствую, Хабравчане!

Предлагаю вам окунуться в чарующий мир С++ 23 на Windows 95. Напишем минимальную стандартную библиотеку. Будем использовать современные фичи в коде.

Расскажу как это все работает и для чего это нужно. Старичок SDL 1.2 ещё многое может. Будем использовать его для написания тонкого слоя для графики.

Сейчас все обсуждают Claude Code, Antigravity, Codex, спорят, коллекционируют “скиллы” для агентов. Но на практике у большинства всё ломается на первом шаге: люди пишут “сделай мне приложение” — и получают либо кашу, либо минус лимиты.

Вайбкодинг работает, когда вы управляете процессом, а не просите все и сразу. Базовый рабочий пайплайн простой:

спецификация → план → маленькие итерации → тесты/ревью → фиксация изменений (git)

Ниже - тот самый “скелет”, который можно повторить почти для любого проекта.

Допустим, вы написали код для решения задачи, которая хорошо распараллеливается. Каждый поток занимается своим участком работы и не зависит от других, поэтому потоки почти не должны координироваться друг с другом, за исключением самого последнего этапа, когда требуется объединить результаты. Естественно, в данном случае логично предположить, что чем больше ядер задействуется для такого кода, тем быстрее он выполнится. Вы ставите бенчмарки и сначала прогоняете этот код на ноутбуке. Действительно, оказывается, что он практически идеально масштабируется на всех четырёх доступных ядрах. Затем вы прогоняете его на большой и пафосной многопроцессорной машине, рассчитывая, что производительность будет ещё выше — но убеждаетесь, что на практике этот код работает даже медленнее, чем на ноутбуке, сколько бы ядер под него не выделить. Да, именно с таким случаем мне однажды довелось столкнуться.

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

Для начала давайте поймем, а зачем вообще нам нужна асинхронность и какие проблемы она решает?

Представим какой‑то абстрактный web‑api, который ходит за данными в БД. При однопоточном синхронном выполнении следующий запрос может быть обработан только тогда, когда полностью был выполнен предыдущий, что неэффективно, т.к. вся нагрузка ложится только на 1 ядро процессора, а остальные простаивают.

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

Есть миф, что рефакторинг ломает обратную совместимость. Я 5 раз переписывал редактор графов и не сломал ни одного файла. Рассказываю, как это возможно.

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

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

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

Привет, Хабр!

Сегодня я хочу поговорить про SFINAE, загадочную аббревиатуру из C++. Расшифровывается SFINAE не менее загадочно: Substitution Failure Is Not An Error, по-русски: «неудавшаяся подстановка — не ошибка». Сейчас рассмотрим, почему это правило появилось, как оно работает и как мы можем использовать его себе во благо.

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

В С++ 20 появились coroutines (далее буду называть их корутинами, по‑русски). Если кратко — они позволяют писать асинхронный код также как мы пишем синхронный. При этом асинхронный код это не обязательно должен работать с несколькими потоками. Асинхронным может быть код исполняемый в одном потоке.

Под капотом компилятора корутины — это просто синтактический сахар (syntax sugar). Т.е. корутины не создадут дополнительных потоков. Компилятор заменит корутины вызовом нескольких функций и не более того. Но давайте посмотрим как корутины выглядят в коде.

В этой статье я буду делать простейший таймер на основе корутин. При этом напишу классы, для Awaitable и Promise, которые необходимы для работы корутин.