Вы помните свое первое собеседование? Я свое помню отлично, преподаватель дольше обычного гонял мою плис в симуляторе Keil-C, придирался к любой мелочи, докапывался до каждой запятой в коде прошивки. А потом начал гонять по алгоритмам трассировки печатных плат, которые мы должны были проходить только в следующем семестре. Я уже мысленно готовился на допсу, видно же что валит, как и предыдущих двух одногруппников. Но в конце сдачи лабы по проектированию мк преподаватель спросил хочу ли я делать "железное железо для железной дороги?" (с). Студенту второго курса ИТМО, которого кормили родители, и подрабатывавшего разгрузкой вагонов ночами, это было сродни офферу в гугль. С тех пор я много раз побывал с обеих сторон стола, и в качестве испытуемого, и как придирчивый лид (отнюдь этим не горжусь, но и не стыжусь), и как группа поддержки у коллег из соседних отделов. Всегда хотелось надеяться, что наши собеседования - это не таинственные квесты, где каждая задача - это каст сложного заклятия, а ошибки не выкидывают с данжа.

Но сначала сказка о том, как к нам попал Миша: однажды в славном городе Панкт-Сетербург погромист-джедай по имени Михаил отправился на собеседование в компанию "Кодозавры". Он был уверен, что знает все, и даже изучил новейшие фреймворки "NoScript" и "Unreal С--". Как он думал, ничто не может его остановить. Когда Миша пришел на собеседование, его встретил HR-менеджер по имени Анна. Она с улыбкой спросила: "Расскажите, как вы бы пояснили своей бабушке, что такое мьютекс?". Ага, прям с порога наш доблестный HR накинул Мишке затравочный вопрос. Ну а чё, это ж сказка, герои на белых самокатах и все такое...

В мире программирования существует огромное количество багов, и если бы каждый баг стал бабочкой, то программеру в раю уже давно оставлена пара полян для развития навыков энтомолога. Несмотря на все совершенства этого мира: компиляторы, pvs‑studio и другие статические анализаторы, юниттесты и отделы QA, мы всегда находим способы преодолеть преграды кода и выпустить на волю парочку новых красивых и удобных видов. Есть у меня txt файлик, которому очень много лет, и куда я складываю интересные экземпляры. Все примеры и действия описанные в статье вымышленные, ни один стажер, джун или студент уволены не были. Hello, World! Where are your bugs?

В 2016 году меня пригласили помочь с разработкой экшн-очков "ORBI", это такие водонепроницаемые очки с несколькими камерами, которые могут стримить 360видео сразу на смартфон, ну а если с ними поплавать, тоже ничего сломаться не должно. (https://www.indiegogo.com/projects/orbi-prime-the-first-360-video-recording-eyewear#/). Собственно моей задачей было написать алгоритм склейки видео потока с четырех камер в одно большое 360* видео, на тот момент задача не очень сложная, но требующая немного специфичных знаний opencv и окружения. Но статья не об этом, потому что теперь это все оберегаемое IP, а про то как мы легальными и не очень средствами языка С++ писали тестовое окружение для используемых классов и соответственно алгоритмов. Да вы скажете, что там такого - сделал гетеры да тестируй себе на здоровье. А если гетера нет или переменная класса спрятана в private секцию и возможность изменить хедер отсутствует. Или вендор либы забыл положить хедеры, и прислал только скан исходников (китайские друзья они такие), а тестировать это надо? Помножив желание написать тесты на утренний кофф и приплюсовав дикий энтузиазм, можно получить очень много ошибок компиляции интересного опыта. Как говорил один мой знакомый лид: "Нет такого кода, который мы не сможем порефакторить, особенно за утренним кофф".

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

В начале двухтысячных друзья подарили мне Sega Dreamcast, топовую японскую приставку, которая прожила у меня чуть больше месяца, после чего я от неё избавился, сменяв на вторую плойку черного цвета - игр в городе для этого чужеземца в то время было ровно одна - MDK2. И больше местные бизнесмены уездного города N предложить не могли. И только лет через десять, мне выпала возможность попробовать что же это была за консоль, которая полюбилась многим, и оставила теплые воспоминания в сердцах игроков, но прожгла дыру в бюджете создателей. Её жизненный цикл оказался очень коротким, всего 3 с небольшим года, после чего Sega свернула не только производство самой консоли, но и вообще покинула ряды платформодержателей. При том, что сама приставка попала в книгу рекордов по количеству проданных устройств за 24 часа. Сейчас Dreamcast, как и почти все ретро-консоли переживает вторую молодость, энтузиасты умудряются найти почти новые, а иногда и вовсе не распакованные образцы. Что удивительно, до сих пор за счет комьюнити и фанов, существуют сервера для некоторых онлайн-игр. А вот с запчастями все сложнее с каждым годом и даже великий китайский Алибаба не всегда может предложить замену. Не меньшим сюрпризом для меня стало и то, что для приставки все еще выходят игры, и вообще эксклюзивы. Не ждите от статьи какой-то аналитики, просто небольшой экскурс в историю, если вы её еще не слышали. Интересно как так вышло?

Если детство ваше выпало на советско-девяностые, то наверняка игровая консоль "Dendy", которая в девичестве NES (Nintendo Entertainment System в Штатах), Famycom (FAMIly COMputer в Японии), с большой вероятностью была у вас в хозяйстве. Пару недель назад я набрел на "живой оригинал" на местной барахолке, и конечно не мог устоять перед возможностью вернуться в свой 1994. Когда по стране миллионными тиражами шагала армия "фамиклонов", отец с Германии притащил оригинал, чем неоднократно были недовольны мои друзья, потому что консоль часто не "видела" неоригильные картриджи. Немного поиграл, получил порцию ностальгии и пошел смотреть, что там еще было, консольные войны прошли мимо меня.

Приветствую, хабровчане. Долгое время работал в сфере разработки программного обеспечения для систем контроля доступа, охраны акваторий и гидроакустики, поставленных на разных далеких и не очень объектах нашей необъятной родины. Некоторые из систем, приходилось запускать в условиях тундры, тайги и полярного круга, а некоторые в столице. За свои почти 20 лет карьеры, и больше 10 лет «програмировай давай» таких систем, прожил разные моменты, и частью из них хочу поделиться с вами. Предыдущие приключения ездового кота можно почитать здесь. Особо строго не судите, пишу для души...

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

Я давний поклонник сити‑билдеров компании Impressions Games © и Саймона Бредбури, если кто не знает — его гений дал жизнь таким играм как Caesar 1/2/3, Space Colony и всей серии Stronghold, который по сей день трудится в студии Firefly Studios. Цезарь стал хитовым проектом и был продан более чем 400к копий на дисках за два года с 1998 по 2000. Но лучшей игрой серии считается Pharaoh + Cleopatra.

Работая в компании Gaijin несколько лет назад, мне довелось поучаствовать в портировании пары игр компании на консоль Nintendo Switch, тогда вовсю завоевывающую новые рынки. Для меня это стало первым крупным проектом на этой платформе. А с учетом, что ни команда, ни разработчик движка с платформой, системой сборки и вообще экосистемой Нинтендо знакомы не были, то все грабли приходилось искать и бережно на них наступать. Чтобы опробовать возможности новой платформы, параллельно с портированием игры, был написан внутренний middleware (связка dagor engine + nxsdk + jam) и код обрастал всевозможными тестами, build matrix, бенчмарками, прогоном стабильности и другими внутренними проверками. Надо отметить что на момент 2018 года, в самом switch sdk не было реализовано часть posix функций вроде poll и send/receive, и большая часть функций для работы с файлами, posix прослойку нужно было писать самим. Дошли тогда руки и до написания различных бенчмарков для функций стандартной библиотеки, и были замечены некоторые аномалии в поведении части тригонометрических функций в различных режимах сборки. Для справки, sdk использует урезанный вариант musl libc (https://www.musl-libc.org/), все статически линкуется в один большой бинарник clang'ом от Нинтендо 9 версии (2018 год), который потом запускается на консоли. Доступа к исходникам самой libc в исполнении Нинтендо у нас не было, но всегда можно посмотреть дизасм и боле менее представить что происходит.

Получение имени типа, не важно это структура или перечисление, в C++ — проблема. То, что тривиально известно компилятору на этапе парсинга исходников, не получится перевести в человеко-читаемый вид в рантайме. Можно использовать std::type_info::name, который не является переносимым решением, потому что зависит от реализации манглинга в компиляторе. Некоторые компиляторы (например, MSVC, IBM, Oracle) создают "удобное" имя типа, а вот gcc и clang, возвращают искаженное имя, котороe можно преобразовать в удобочитаемую форму с помощью дополнительных функций, например abi::__cxa_demangle. Чтобы вся эта магия работала нужно подключить RTTI, который тоже не всегда доступен, а иногда и вообще-то вреден, потому что сжирает драгоценную производительность, но можно сделать по другому.

В одном из сайд-проектов с использованием imgui понадобилась "вертячка" (loader, spinner, анимация загрузки). Из коробки этот ui-фреймворк таких виджетов не предоставляет, поэтому решил сделать свой: код простой, математики почти нет. Показал ocornut-y, ему тоже понравилось, теперь базовый виджет на очереди интеграции в imgui. Поискал интересные спинеры на разных сайтах для веб-интерфейсов - десятки видов на любой вкус и цвет, есть и 3д, но все в основном или пререндеры в виде (gif) или векторные анимации, которые для отрисовки требует отдельного фреймворка вроде cairo, а алгоритмов или описания как это работает, почти нет. Все спинеры сделаны в стиле "что вижу, то и пою", немного математики синусы/косинусы для координат, и тестировать пока не будет похоже на решение от UI дизайнера. Да-да, я понимаю, что когда космические корабли бороздят просторы большого театра DALL·E 2 рисует "улыбку мадонны", писать что-то на плюсах, да еще для UI...

После небольшой статьи про особенности при работе с кэшем (https://habr.com/ru/post/687146/) мне в личку прилетело несколько замечаний про работу спинлоков и приглашение на собес от пчелайнов, приятно, что технические статьи читают не только технари... лирика. Возвращаясь к обсуждению спинлоков, вышедших за рамки хабра, если это вызвало интерес, почему бы не написать про работу с этими примитивами синхронизации. Тема действительно интересная, да и разработчики придумали более десятка разновидностей спинлоков под разные вкусы и нужды. Все опять будет с тестами и примерами работы. @tbl Линус действительно прав, в юзерспейсе спинлоки "зло злющее", но как обычно есть нюансы...

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